RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 34 records.

Status: Verified (12)

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

Note: This RFC has been updated by RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996

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: 6645
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Matt Hertogs
Date Reported: 2021-07-20
Verifier Name: Orie Steele
Date Verified: 2024-05-03

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: 7529
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Shraddha Soni
Date Reported: 2023-05-29
Verifier Name: Orie Steele
Date Verified: 2024-05-03

Section 25.1 says:

This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8].
The SWS construct is used when linear white space is optional, generally between tokens and separators.

      LWS  =  [*WSP CRLF] 1*WSP ; linear whitespace

It should say:

This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8].
The SWS construct is used when linear white space is optional, generally between tokens and separators.

      LWS  =  [CRLF] 1*WSP ; linear whitespace

Notes:

RFC 2616 states
LWS = [CRLF] 1*( SP | HT )

RFC 2234 states
WSP = SP / HTAB
; white space
RFC 3261 is referencing both for BNF to follow, but looks like a new BNF is stated. So either it should not reference to follow RFC 2616 exactly or follow the same BNF as 2616.

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.

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

Reported By: Xing Lou Han
Date Reported: 2014-08-15
Verifier Name: Orie Steele
Date Verified: 2024-03-29

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: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Tamas Horvath
Date Reported: 2015-03-12
Verifier Name: Orie Steele
Date Verified: 2024-03-29

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: 4637
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Boris Shtrasman
Date Reported: 2016-03-11
Verifier Name: Orie Steele
Date Verified: 2024-03-29

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

Status: Held for Document Update (16)

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

Note: This RFC has been updated by RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996

Source of RFC: sip (rai)

Errata ID: 678
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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: 5598
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Roman Shpount
Date Reported: 2019-01-11
Held for Document Update by: Ben Campbell
Date Held: 2019-02-14

Section 25.1 says:

display-name   =  *(token LWS)/ quoted-string

It should say:

display-name   =  token *(LWS token)/ quoted-string

Notes:

There is a contradiction between the ABNF rule and specification.

The name-addr ABNF rule in RFC 3261 specifies:

name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = SIP-URI / SIPS-URI / absoluteURI
display-name = *(token LWS)/ quoted-string

Based on this, LWS is always required between token and the "<" and the following Name-Address value is invalid: foo<sip:foo@bar.com>

At the same time section 20.10 says:

There may or may not be LWS between the display-name and the "<".

This implies that foo<sip:foo@bar.com> should be acceptable.

I propose to change ABNF rule for display-name to allow no LWS between last token and the "<"

Errata ID: 5653
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Vimal Chandra Tewari
Date Reported: 2019-03-12
Held for Document Update by: Orie Steele
Date Held: 2024-05-03

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: 6793
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Mojtaba Esfandiari.S
Date Reported: 2021-12-21
Held for Document Update by: Orie Steele
Date Held: 2024-05-03

Section 8.1.1.5 says:

The CSeq header field serves as a way to identify and order
   transactions.  It consists of a sequence number and a method.  The
   method MUST match that of the request.  For non-REGISTER requests
   outside of a dialog, the sequence number value is arbitrary.  The
   sequence number value MUST be expressible as a 32-bit unsigned
   integer and MUST be less than 2**31.  As long as it follows the above
   guidelines, a client may use any mechanism it would like to select
   CSeq header field values.

It should say:

The CSeq header field serves as a way to identify and order
   transactions.  It consists of a sequence number and a method.  The
   method MUST match that of the request.  For non-REGISTER requests
   outside of a dialog, the sequence number value is arbitrary. For requests with its credentials after receiving a
   401 (Unauthorized) or 407 (Proxy Authentication Required) response,
  the CSeq header field value MUST increment. The
   sequence number value MUST be expressible as a 32-bit unsigned
   integer and MUST be less than 2**31.  As long as it follows the above
   guidelines, a client may use any mechanism it would like to select
   CSeq header field values.

Notes:

For more clarity and more understanding, It would be nice to have a quiet bit of update in RFC 3261 section 8.1.1.5. Because, the word "arbitrary" in the CSeq value may be confused with the same value as before.

Errata ID: 1471
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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.

Errata ID: 4385
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Krisztian Sinka
Date Reported: 2015-06-02
Held for Document Update by: Ben Campbell
Date Held: 2015-06-05

Section 17.2.1 says:

                               |INVITE
                               |pass INV to TU
            INVITE             V send 100 if TU won't in 200ms
            send response+-----------+
                +--------|           |--------+101-199 from TU
                |        | Proceeding|        |send response
                +------->|           |<-------+
                         |           |          Transport Err.
                         |           |          Inform TU
                         |           |--------------->+
                         +-----------+                |

It should say:

                               |INVITE
                               |-
            INVITE             V send 100 if TU won't in 200ms
            send response+-----------+
                +--------|           |--------+101-199 from TU
                |        | Proceeding|        |send response
                +------->|           |<-------+
                         |           |          Transport Err.
                         |           |          Inform TU
                         |           |--------------->+
                         +-----------+                |

Notes:

The standard states about lifetime of the server transaction:

"Server transactions are created by the
core when a request is received, and transaction handling is desired
for that request (this is not always the case)."(17.2)

So this means that the server transaction is created by the TU (the core). This also means that it is useless to *pass INV to TU* due to that TU itself already has the request.

The same logic should apply to Figure 8. as well.

Errata ID: 4675
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Bruce Florman
Date Reported: 2016-04-21
Held for Document Update by: Ben Campbell
Date Held: 2016-05-05

Section 8.1.1.3 says:

   Examples:

      From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
      From: sip:+12125551212@phone2net.com;tag=887s
      From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

It should say:

   Examples:

      From: "Bob" <sips:bob@biloxi.com> ;tag=a48smh2
      From: sip:+12125551212@phone2net.com;tag=887s6pa
      From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8mtf

Notes:

I know this is more than a little picayune, but...

Section 19.3 says:

When a tag is generated by a UA for insertion into a request or
response, it MUST be globally unique and cryptographically random
with at least 32 bits of randomness.

This implies that the tag value must be at least 32 bits in size.

Section 25.1 says:

token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
and
tag-param = "tag" EQUAL token

Although the actual representation of the tag value is implementation-specific, since there are only 72 characters available with which to encode it, a tag value with only four characters can represent a maximum of 72^4 distinct numeric values, which is less than the 2^32 values that can be represented by 32 bits by a factor of nearly 160.

Even if the implementation chooses to omit "leading zeros" (or something equivalent), the likelihood of three 32 bit random values all falling in the range of values that can be represented in four characters would be less than one in five million. So even if the given examples are theoretically possible for a conforming implementation, they seem rather misleading.

For a "typical" 32 bit random value, even with base74 encoding, the shortest tag value would require six characters. Given that all three examples (which are also repeated almost unchanged in section 20.20) contain no uppercase ALPHA characters in the tag values, the implied encoding is more likely something like base32 or base36, which would require at least seven characters to represent a typical 32 bit random value. So that's how I'm suggesting that the examples be amended.

Status: Rejected (6)

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

Note: This RFC has been updated by RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996

Source of RFC: sip (rai)

Errata ID: 1742
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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.

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

Reported By: Chao Wang
Date Reported: 2015-02-19
Rejected by: Orie Steele
Date Rejected: 2024-05-03

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.
--VERIFIER NOTES--
This behavior was clarified in https://www.rfc-editor.org/rfc/rfc6141#section-5.3

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

Reported By: Christer Holmberg
Date Reported: 2015-12-04
Rejected by: Orie Steele
Date Rejected: 2024-05-03

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
--VERIFIER NOTES--
See https://mailarchive.ietf.org/arch/msg/sipcore/fjlcEaK4zFS3Yelzkqvljl5SxRw/

Errata ID: 5619
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Isabella Damböck
Date Reported: 2019-01-31
Rejected by: Ben Campbell
Date Rejected: 2019-02-27

Section 4 says:

The address 
of the atlanta.com SIP server could have been configured in Alice's
softphone, or it could have been discovered by DHCP, for example.

It should say:

The address 
of the atlanta.com SIP server could have been configured in Alice's 
softphone, or it could have been discovered by DNS, for example.

Notes:

DHCP Server gives away the DNS-Server to use (or sets it with DHCP option) but usually does no address translation itself. It would also be possible to omit the whole sentence.
--VERIFIER NOTES--
DHCP was the intent of the example.

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

Reported By: OKUMURA Shinji
Date Reported: 2015-05-28
Rejected by: Orie Steele
Date Rejected: 2024-03-29

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.
--VERIFIER NOTES--
The original text includes: Errata ID: 316

But the current text matches the suggestion:

https://datatracker.ietf.org/doc/html/rfc3261#section-25.1

Report New Errata



Advanced Search