errata logo graphic

Found 20 records.

Status: Verified (6)

RFC3261, "SIP: Session Initiation Protocol", June 2002

Source of RFC: sip (rai)

Errata ID: 316

Status: Verified
Type: Technical

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

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

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

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

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: 2051

Status: Verified
Type: Editorial

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 (1)

RFC3261, "SIP: Session Initiation Protocol", June 2002

Source of RFC: sip (rai)

Errata ID: 4084

Status: Reported
Type: Editorial

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.


Status: Held for Document Update (11)

RFC3261, "SIP: Session Initiation Protocol", June 2002

Source of RFC: sip (rai)

Errata ID: 678

Status: Held for Document Update
Type: Technical

Reported By: Matthew S. Harris
Date Reported: 2006-08-14
Held for Document Update by: Cullen Jennings

Section 25.1 says:

On page 220, it says "The TEXT-UTF8-TRIM rule is used for descriptive
field contents that are n t quoted strings, where leading and trailing
LWS is not meaningful."  (And no, I'm not talking about the "n t"
typo.)  The rule for TEXT-UTF8-TRIM is

 TEXT-UTF8-TRIM  = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
 TEXT-UTF8char = %x21-7E / UTF8-NONASCII

which pretty clearly says that the final character of TEXT-UTF8-TRIM
cannot be whitespace.  TEXT-UTF8-TRIM appears only as the value of a
header field, and the rule for message-header does not generate
trailing whitespace either.

So the text talks about trailing whitespace, which seems reasonable
because whitespace is allowed in many other places, but the grammar
does not allow it.  Was trailing whitespace intended?

It should say:

[not submitted]

Notes:

from pending


Errata ID: 832

Status: Held for Document Update
Type: Technical

Reported By: Marco Ambu
Date Reported: 2006-01-11
Held for Document Update by: Robert Sparks

 

I would like to show you an ambiguity in RFC 3261.

The ABNF for SIP in RFC 3261 page 227 defines header Accept as 
"Accept = "Accept" HCOLON [accept-range *(COMMA accept-range)].

Expanding this form we have:

Accept = "Accept" HCOLON [( (...) *(SEMI m-parameter) *(SEMI 
accept-param) ) *(COMMA accept-range)]

For example we can have

Accept: 
application/sdp;m_extension_parameter=value1;accept_extension_param=value2;q=0.5
We know from RFC 3261 that q is an accept-param.
We don't know how to consider the first two unknown parameters: how to 
distinguish from m-parameter and accept-param?

While in other cases RFC 3261 shows the rules to solve ambiguities (for 
example how to consider the parameters in a Contact URI if the URI is 
not enclosed in angular brackets) I have not found any suggestion for 
this specific case in RFC 3261.

It should say:

[not submitted]

Notes:

from pending


Errata ID: 1682

Status: Held for Document Update
Type: Technical

Reported By: Iñaki Baz Castillo
Date Reported: 2009-02-10
Held for Document Update by: Robert Sparks

Section 20.7 says:

Authorization: Digest username="Alice", realm="atlanta.com",
  nonce="84a4cc6f3082121f32b42a2187831a9e",
  response="7587245234b3434cc3412213e5f113a5432"

It should say:

Authorization: Digest username="Alice", realm="atlanta.com",
  nonce="84a4cc6f3082121f32b42a2187831a9e",
  response="7587245234b3434cc3412213e5f113a5"

Notes:

'response' field in original example has 35 hexadecimal characters while they must be 32:

dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT


Errata ID: 2769

Status: Held for Document Update
Type: Technical

Reported By: Iñaki Baz Castillo
Date Reported: 2011-04-08
Held for Document Update by: Robert Sparks

Section 17.1.2.2 says:

   MUST be passed to the transport layer for transmission.  If an
   unreliable transport is in use, the client transaction MUST set timer
   E to fire in T1 seconds.  If timer E fires while still in this state,
   the timer is reset, but this time with a value of MIN(2*T1, T2).
   When the timer fires again, it is reset to a MIN(4*T1, T2).  This
   process continues so that retransmissions occur with an exponentially
   increasing interval that caps at T2.

It should say:

   MUST be passed to the transport layer for transmission.  If an
   unreliable transport is in use, the client transaction MUST set timer
   E to fire in T1 seconds.  If timer E fires while still in this state,
   the timer is reset, but this time with a value of MIN(2*T1, T2).
   When the timer fires again, it is reset to a MIN(4*T1, T2). Multiplier
   on T1 doubles with each reset so that retransmissions occur with an
   exponentially increasing interval that caps at T2.

Notes:

The original text doesn't clarify that the multiplier of T1 is doubled with each timer reset, so it could be understood that the maximum value the timer takes is MIN(4*T1, T2) which is 2s (so the timer would never reach 4s and the resulting intervals would be 500ms, 1s, 2s, 2s, 2s, 2s, etc).


Errata ID: 3098

Status: Held for Document Update
Type: Technical

Reported By: Alec Davis
Date Reported: 2012-01-27
Held for Document Update by: Robert Sparks
Date Held: 2012-01-27

Section 12.2.1.1 says:

A client could, for example, choose the 31 most significant bits of a 32-bit
 second clock as an initial sequence number.


It should say:

A client could, for example, choose the 31 least significant bits of a 32-bit
 second clock as an initial sequence number.


Notes:

Choosing the most sig 31 bits would violate 8.1.1.5, where initial CSeq number must be less than 2**31

8.1.1.5: The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31.


REVIEWER NOTE (rjsparks@nostrum.com) : It was explicitly the intent to point to the most significant bits. The confusion in this report is not recognizing that the intent is to treat those as a 31-bit integer (which by definition will be less than 2**31). Rather than reject the errata, I'm putting this in hold for document update so future revisions can clarify the point.


Errata ID: 3102

Status: Held for Document Update
Type: Technical

Reported By: Alec Davis
Date Reported: 2012-02-01
Held for Document Update by: Robert Sparks

Section 12.2.1.1 says:

      With a length of 32 bits, a client could generate, within a single
      call, one request a second for about 136 years before needing to
      wrap around.  The initial value of the sequence number is chosen
      so that subsequent requests within the same call will not wrap
      around.

It should say:

      With a length of 32 bits, a client could generate, within a single
      call, one request a second for about 136 years before exhausting
      available sequence numbers. Sequence numbers must not wrap around to 0.
      The initial value of the sequence number (less than 2**31) is chosen
      so that subsequent requests within the same call will not exceed 2**32-1.
      

Notes:

Highlight that within a dialog sequence numbers;
1). can increment to 2**32-1
2). must not wrap around to 0


Errata ID: 3684

Status: Held for Document Update
Type: Technical

Reported By: Colin Fraizer
Date Reported: 2013-07-16
Held for Document Update by: Gonzalo Camarillo

Section 7.3 says:

 Specifically, any SIP header whose grammar is of the form

      header  =  "header-name" HCOLON header-value *(COMMA header-value)

   allows for combining header fields of the same name into a comma-
   separated list.  The Contact header field allows a comma-separated
   list unless the header field value is "*".

It should say:

 Specifically, any SIP header whose grammar is of the form

      header  =  header-name HCOLON header-value *(COMMA header-value)

   allows for combining header fields of the same name into a comma-
   separated list.  The Contact header field allows a comma-separated
   list unless the header field value is "*".

Notes:

That is, remove the double quotes around the word `header-name' in the ABNF.


Errata ID: 3875

Status: Held for Document Update
Type: Technical

Reported By: Varun Bharadwaj S V
Date Reported: 2014-01-31
Held for Document Update by: Richard Barnes
Date Held: 2014-02-15

Section 17 says:

17 Transcations

 - Additionally, in the case of an INVITE request, the client
transaction is responsible for generating the ACK request for any
final response accepting a 2xx response.

It should say:

17 Transcations

 - Additionally, in the case of an INVITE request, the client
transaction is responsible for generating the ACK request for any
final response excepting a 2xx response.

Notes:

Client transaction should generate the ACK except for 2xx responses.It should not accept & generate the ACK for 2xx response.
For Server transaction RFC says - "In the case of an INVITE transaction, it absorbs the ACK request for any final response excepting a 2xx response."


Errata ID: 1471

Status: Held for Document Update
Type: Editorial

Reported By: Iñaki Baz Castillo
Date Reported: 2008-07-14
Held for Document Update by: Robert Sparks

Section 17 says:

Additionally, in the case of an INVITE request, the client
transaction is responsible for generating the ACK request for any
final response accepting a 2xx response.

It should say:

Additionally, in the case of an INVITE request, the client
transaction is responsible for generating the ACK request for any
final response excepting a 2xx response.

Notes:

"accepting a 2xx response" => "excepting a 2xx response"


Errata ID: 1472

Status: Held for Document Update
Type: Editorial

Reported By: Iñaki Baz Castillo
Date Reported: 2008-07-14
Held for Document Update by: Robert Sparks

Section 25.1 says:

The TEXT-UTF8-TRIM rule is used for descriptive field 
contents that are n t quoted strings,

It should say:

The TEXT-UTF8-TRIM rule is used for descriptive field 
contents that are not quoted strings,

Notes:

"are n t" => "are not"


Errata ID: 3237

Status: Held for Document Update
Type: Editorial

Reported By: Kevin P. Fleming
Date Reported: 2012-05-31
Held for Document Update by: Robert Sparks

Section 8.1.3.5 says:

   In all of the above cases, the request is retried by creating a new
   request with the appropriate modifications.  This new request
   constitutes a new transaction and SHOULD have the same value of the
   Call-ID, To, and From of the previous request, but the CSeq should
   contain a new sequence number that is one higher than the previous.

It should say:

   In all of the above cases, the request is retried by creating a new 
   request with the appropriate modifications.  This new request 
   constitutes a new transaction and SHOULD have the same value of the 
   Call-ID, To, and From of the previous request, but the CSeq SHOULD 
   contain a new sequence number that is one higher than the previous.

Notes:

We have had one implementor claim that they are not required to increment CSeq when retrying the request because the RFC says 'should' and not 'SHOULD'. Based on current IETF discussions, though, these should probably be changed to MUST anyway, but that's a much more substantive change throughout the whole RFC.


Status: Rejected (2)

RFC3261, "SIP: Session Initiation Protocol", June 2002

Source of RFC: sip (rai)

Errata ID: 1742

Status: Rejected
Type: Technical

Reported By: Pankaj Jain
Date Reported: 2009-03-25
Rejected by: Robert Sparks
Date Rejected: 2010-05-23

Section 17.1.1.2 says:

Timer D reflects the amount of time that the server transaction can
   remain in the "Completed" state when unreliable transports are used.

It should say:

Timer D reflects the amount of time that the client transaction can
   remain in the "Completed" state when unreliable transports are used.

Notes:

server transaction => client transaction
--VERIFIER NOTES--
The original text is correct. The value (and reason) for timer D is to reflect what's happening in the server transaction. See the discussion of Timer H that immediately follows the text quoted above.


Errata ID: 2910

Status: Rejected
Type: Technical

Reported By: Iñaki Baz Castillo
Date Reported: 2011-08-02
Rejected by: Robert Sparks
Date Rejected: 2011-11-04

Section Table 2 says:

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Contact                1xx           -   -   -   o   -   -

It should say:

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Contact                1xx           -   -   -   m   -   -

Notes:

RFC 3261 says:

Section 12.1: "Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog."

Section 12.1.1: "When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response [...]. The UAS MUST add a Contact header field to the response."

So it's clear that a 1xx response to an INVITE creates a dialog and then it MUST contain a Contact header and mirrored Record-Route headers.

However Table 2 (page 162) says:

Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact 1xx - - - o - -
Record-Route 2xx,18x mr - o o o o -

Obviously Record-Route is optional since in the absence of a proxy doing record-routing, such header will not be present. However Contact header should appear as mandatory (m) for 1xx responses for INVITE rather than optional (o).
--VERIFIER NOTES--
1xx also includes 100 Trying, which cannot establish a Dialog. Contact is not mandatory in 100 Trying responses.


Report New Errata