RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 15 records.

Status: Verified (7)

RFC 3261, "SIP: Session Initiation Protocol", June 2002

Source of RFC: sip (rai)

Errata ID: 316
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: RFC Editor
Date Reported: 2003-10-03

In Section 25.1:

     digest-uri-value  =  rquest-uri ; Equal to request-uri as
                          specified by HTTP/1.1 

It should say:

     digest-uri-value  =  request-uri ; Equal to request-uri as
                          specified by HTTP/1.1

Errata ID: 1051
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Alexandre Machado
Date Reported: 2007-08-23
Verifier Name: Robert Sparks
Date Verified: 2010-04-03

Section 25.1 says:

    srvr           =  [ [ userinfo "@" ] hostport ]

It should say:

    srvr           =  [ [ userinfo ] hostport ]

Notes:

The character "@" should not appear in this rule since it already appears at the end of the rule "userinfo":

userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"

According to the use of rule "userinfo" in other rules such as "SIP-URI" and "SIPS-URI", the correct place of character "@" is really at the end of rule "userinfo" and not in all other rules using it.

Errata ID: 1073
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Marco Ambu
Date Reported: 2005-12-15
Verifier Name: Robert Sparks
Date Verified: 2010-04-03

 

I would like to show you an error in RFC 3261. I've discussed in
SIP-implementors mailing list too.

in RFC 3261 page 44 par 8.1.3.4 there is an example of URI (contact URI)
with uri headers:

sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>

I've noticed that URI header "Call-Info" has a value with characters not
allowed in uri headers.

The BNF says that an header value must contain characters in   
hnv-unreserved or unreserved or escaped but '<' and '>' are not in that set.

The right example should be the following:
sip:user@host?Subject=foo&Call-Info=%3Chttp://www.foo.com%3E  

It should say:

[not submitted]

Notes:

from pending

Errata ID: 1470
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Iñaki Baz Castillo
Date Reported: 2008-07-14
Verifier Name: Robert Sparks
Date Verified: 2010-04-03

Section 17.2.2 says:

If the TU passes a final response (status codes 200-699) to the 
server while in the "Proceeding" state, the transaction MUST enter 
the "Completed" state...

It should say:

If the TU passes a final response (status codes 200-699) to the 
server while in the "Trying" or "Proceeding" state, the transaction 
MUST enter the "Completed" state...

Notes:

"17.2.2 Non-INVITE Server Transaction" doesn't consider the case in which the transaction state is "Trying" and the transaction receives from the TU a final response.
It's totally possible that TU sends a final response without sending before a provisional response. Note that this case is perfectly valid in the diagram of page 139.

Errata ID: 3183
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Bruno CHATRAS
Date Reported: 2012-04-10
Verifier Name: Robert Sparks

Section 23.4.3 says:

         --boundary42
         Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
              name=smime.p7m
         Content-Transfer-Encoding: base64
         Content-Disposition: attachment; filename=smime.p7m
            handling=required
         Content-Length: 231


It should say:

   --boundary42
         Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
              name=smime.p7m
         Content-Transfer-Encoding: base64
         Content-Disposition: attachment; filename=smime.p7m
            handling=required


Notes:

A Content-Length header is shown for a body-part within a multipart body. But Content-Length is an HTTP/SIP header, not a IANA-registered MIME header and should therefore not appear at that location in valid examples. The length of a body part within a multipart body is determined by MIME framing. A Content-Length header found for a body-part within a multipart body is meaningless and should be ignored.

This was discussed on both the SIP Implementors and SIP Core mailing lists.

Errata ID: 4567
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Christer Holmberg
Date Reported: 2015-12-17
Verifier Name: Ben Campbell
Date Verified: 2015-12-17

Section 20.11 says:

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, the
value "required" SHOULD be assumed. The handling parameter is
described in RFC 3204 [19].

It should say:

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, or if
the Content-Disposition header field is missing, the value "required" 
SHOULD be assumed. The handling parameter is described in RFC 3204 [19].

Errata ID: 2051
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Cullen Jennings
Date Reported: 2010-02-24
Verifier Name: Robert Sparks
Date Verified: 2010-05-23

Section 26.3.1 says:

   Proxy servers, redirect
   servers, and registrars SHOULD possess a site certificate whose
   subject corresponds to their canonical hostname. 

It should say:

   Proxy servers, redirect
   servers, and registrars SHOULD possess a site certificate whose
   subject corresponds to the DNS name other SIP devices will use to reach them. 

Notes:

The term hostname seemed to make some people think if you had two sip servers for the domain example.com with hostnames host1 and host2, the the cert should have host1.example.com when in fact the sip signaling always used exmaple.com and the cert should have a example.com as the name.

Status: Reported (8)

RFC 3261, "SIP: Session Initiation Protocol", June 2002

Source of RFC: sip (rai)

Errata ID: 4275
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Chao Wang
Date Reported: 2015-02-19

Section 15 says:

The caller's UA MAY send a BYE for either confirmed or early dialogs

It should say:

The caller's UA MUST send a BYE for confirmed dialogs

Notes:

In general, BYE shall be handled in the same way as CANCEL if it is for early dialogs.
In case, when BYE is on the way to the destination, the callee probably accepts INVITE, the race condition will occure.
If we follow the procedure as CANCEL, caller shall send ACK for 200 OK and immediately release the session using BYE.
So two BYEs will be triggered in the case, it does not make sense.

Errata ID: 4553
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Christer Holmberg
Date Reported: 2015-12-04

Section 20.11 says:

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand.  The parameter has defined values of
"optional" and "required".  If the handling parameter is missing, the
value "required" SHOULD be assumed.  The handling parameter is
described in RFC 3204 [19].

It should say:

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand.  The parameter has defined values of
"optional" and "required".  If the handling parameter is missing, or if
the Content-Disposition header field is missing, the value "required" 
MUST be assumed.  The handling parameter is described in RFC 3204 [19].

Notes:

SIPCORE discussion: https://mailarchive.ietf.org/arch/msg/sipcore/bn-pRgDyGL2FP_M7eYpyT35zNp4

Errata ID: 5653
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Vimal Chandra Tewari
Date Reported: 2019-03-12

Section 17.1.1.2 says:


Notes:

When a INVITE client transaction transitions to Proceeding state (upon receiving a provisional response), the request retransmission stops (for an unreliable transport) i.e. Timer A is stopped.
However in Proceeding state, Timer B, i.e. Transaction Timeout Timer can still fire if no final response is received in stipulated time in which case the TU should be informed and the transaction should transition to Terminated state.
"Figure 5: INVITE client transaction" in RFC 3261 does not show the Timer B expiry event in Proceeding state. This means that we are saying there is a guarantee that a final response will always be received in Proceeding state which may not always be the case.
In my opinion, the Proceeding state in Figure 5 should be updated to include a Timer B event.

Errata ID: 6645
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Matt Hertogs
Date Reported: 2021-07-20

Section 23.3 says:

Content-Disposition: attachment; filename=smime.p7m
           handling=required

It should say:

Content-Disposition: attachment; filename=smime.p7m;
           handling=required

Notes:

The example for Content-Disposition header is incorrectly formatted according to the BNF.
It is missing a semicolon between each disp-param.
(Relevant section of BNF posted below)

Content-Disposition = "Content-Disposition" HCOLON
disp-type *( SEMI disp-param )
disp-type = "render" / "session" / "icon" / "alert"
/ disp-extension-token
disp-param = handling-param / generic-param
handling-param = "handling" EQUAL
( "optional" / "required"
/ other-handling )
other-handling = token
disp-extension-token = token

This also occurs in 23.4.3

Errata ID: 4084
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Xing Lou Han
Date Reported: 2014-08-15

Section 13.2.2.4 says:

   If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section
   12.2.1.2.

It should say:

   If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section
   12.2.1.1.

Notes:

The procedures of recomputing the route set should refer to the Section 12.2.1.1, rather than Section 12.2.1.2.

Actually in Section 12.2.1.2, there is no procedure of computing route set. Instead, the related procedures can only be found in Section 12.2.1.1.

To avoid misleading, "12.2.1.2" here should be "12.2.1.1" instead.

Errata ID: 4300
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Tamas Horvath
Date Reported: 2015-03-12

Section 24.2 says:

F2 100 Trying atlanta.com proxy -> Alice
(...)
F3 INVITE atlanta.com proxy -> biloxi.com proxy
(...)
F4 100 Trying biloxi.com proxy -> atlanta.com proxy
(...)
F5 INVITE biloxi.com proxy -> Bob

It should say:

F3 100 Trying atlanta.com proxy -> Alice
(...)
F2 INVITE atlanta.com proxy -> biloxi.com proxy
(...)
F5 100 Trying biloxi.com proxy -> atlanta.com proxy
(...)
F4 INVITE biloxi.com proxy -> Bob

Notes:

Figure 1 in Section 4 shows different indexes for the 100 Trying and INVITE messages.

Errata ID: 4379
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: OKUMURA Shinji
Date Reported: 2015-05-28

Section 25.1 says:

Errata ID: 316
digest-uri-value  =  request-uri ; Equal to request-uri
                                   as specified by HTTP/1.1

It should say:

digest-uri-value  =  rquest-uri ; Equal to request-uri
                                  as specified by HTTP/1.1

Notes:

Rule names are case-insensitive.
Request-URI has been defined already.
An original definition is correct.
Alternatively, it may refer to request-target as specified by RFC 7230.

Errata ID: 4637
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Boris Shtrasman
Date Reported: 2016-03-11

Section 23.4.3 says:

        ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
        4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
        n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
        7GhIGfHfYT64VQbnj756

        --boundary42-

It should say:

        ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
        4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
        n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
        7GhIGfHfYT64VQbnj756

        --boundary42--

Notes:

As far as I know a boundary end should end with two dashes as for RFC 3851 for that specific case, hence it should be :

--boundary42--

Report New Errata