RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 8 records.

Status: Verified (3)

RFC 3665, "Session Initiation Protocol (SIP) Basic Call Flow Examples", December 2003

Source of RFC: sipping (rai)

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

Reported By: Niels Widger
Date Reported: 2011-03-02
Verifier Name: Robert Sparks
Date Verified: 2011-03-03

Section 3.8 says:

   F11 CANCEL Proxy 1 -> Proxy 2

   CANCEL sip:alice@atlanta.example.com SIP/2.0
   Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0

It should say:

   F11 CANCEL Proxy 1 -> Proxy 2

   CANCEL sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
   CSeq: 1 CANCEL
   Content-Length: 0

Notes:

The Request-URI of message F11 is incorrect according to RFC 3261 Section 9.1: "The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags".

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

Reported By: David Waiting
Date Reported: 2012-07-26
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-04-03

Section 3.8. says:

F18 ACK Proxy 1 -> Proxy 2

ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0

It should say:

F18 ACK Proxy 1 -> Proxy 2

ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0

Notes:

Proxy 1 includes an incorrect Via header in the ACK.

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

Reported By: Gergely Szabo
Date Reported: 2014-07-11
Verifier Name: Francesca Palombini
Date Verified: 2023-11-09

Section 2.1 says:

   F3 REGISTER Bob -> SIP Server

   REGISTER sips:ss2.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
   Max-Forwards: 70
   From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
   To: Bob <sips:bob@biloxi.example.com>
   Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
   CSeq: 2 REGISTER
   Contact: <sips:bob@client.biloxi.example.com>
   Authorization: Digest username="bob", realm="atlanta.example.com"
    nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
    uri="sips:ss2.biloxi.example.com",
    response="dfe56131d1958046689d83306477ecc"
   Content-Length: 0

It should say:

   F3 REGISTER Bob -> SIP Server

   REGISTER sips:ss2.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
   Max-Forwards: 70
   From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
   To: Bob <sips:bob@biloxi.example.com>
   Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
   CSeq: 2 REGISTER
   Contact: <sips:bob@client.biloxi.example.com>
   Authorization: Digest username="bob", realm="atlanta.example.com",
    nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
    uri="sips:ss2.biloxi.example.com",
    response="dfe56131d1958046689d83306477ecc"
   Content-Length: 0

Notes:

A comma (,) is missing before the 'nonce' parameter of the Authorization header.

Status: Reported (3)

RFC 3665, "Session Initiation Protocol (SIP) Basic Call Flow Examples", December 2003

Source of RFC: sipping (rai)

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

Reported By: Yehoshua Gev
Date Reported: 2018-03-22

Section 3.1 says:

BYE sip:alice@client.atlanta.example.com SIP/2.0

It should say:

BYE sip:alice@client.atlanta.example.com;transport=tcp SIP/2.0

Notes:

In Example 3.1, the URI of the Contact header field of the INVITE request (F1) containes a parameter "transport=tcp".
According to section 12.2.1.1 of RFC 3261, this URI should be used as the Request-URI for Bob sending requests within this dialog.
As there is no explicit text about omitting parameters from the URI, the Request-URI should contain the "transport=tcp" parameter.
Hence, the Request-URI of the BYE request (F5) should contain the parameter.

It seems that the this problem was reported some years ago in the sip-implementors list:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-July/013507.html

The same problem appear in other examples, specifically 3.2 and 3.6.

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

Reported By: Johan Kuuse
Date Reported: 2020-07-27

Section 3.9 says:

SIP/2.0  486 Busy Here

It should say:

SIP/2.0 486 Busy Here

Notes:

At three different locations in section 3.9, there are two space characters between the SIP version and the Status Code, instead of one space.

According to RFC 3261, section 7.2, the Status line of a SIP Response, each element is separated by a single SP character.

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

Reported By: Xiaoxi Li
Date Reported: 2022-05-31

Section 3.2 says:

   F5 INVITE Proxy 1 -> Proxy 2

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Max-Forwards: 69

   F7 INVITE Proxy 2 -> Bob

   INVITE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Max-Forwards: 68

   F16 ACK Proxy 1 -> Proxy 2

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76
    ;received=192.0.2.101
   Max-Forwards: 69

   F17 ACK Proxy 2 -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1

   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76
    ;received=192.0.2.101
   Max-Forwards: 68
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl

It should say:

the branch id in the topmost Via header(s) in the F16 F17 messages shouldn't be the same as the via headers added in F5 F7 messages.

the ACK message shall only copy the same branch id in Via if it's for non-200 ok responses. 

this example deviates from the description in RFC 3261 chapter 16.6

Notes:

the branch id in the topmost Via header(s) in the F16 F17 messages shouldn't be the same as the via headers added in F5 F7 messages.

the ACK message shall only copy the same branch id in Via if it's for non-200 ok responses.

this example deviates from the description in RFC 3261 chapter 16.6

Status: Rejected (2)

RFC 3665, "Session Initiation Protocol (SIP) Basic Call Flow Examples", December 2003

Source of RFC: sipping (rai)

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

Reported By: Fritz
Date Reported: 2015-10-30
Rejected by: Ben Campbell
Date Rejected: 2015-11-01

Section 3.2 says:

   F3 ACK Alice -> Proxy 1

   ACK sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=3flal12sf
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 ACK
   Content-Length: 0

It should say:

   F3 ACK Alice -> Proxy 1

   ACK sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK12345
   Max-Forwards: 70
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=3flal12sf
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 ACK
   Content-Length: 0

Notes:

ACK is a new transaction and need a new value for via-branch
--VERIFIER NOTES--
The flow in the RFC is correct. ACK is only a new transaction if the final response to the INVITE was in the 2xx class. In this case, the final response was a 407 - this ACK is hop-by-hop, and is part of the INVITE transaction.

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

Reported By: Benoit Entzmann
Date Reported: 2016-06-30
Rejected by: Ben Campbell
Date Rejected: 2016-06-30

Throughout the document, when it says:

CSeq: 1 BYE

It should say:

CSeq: 2 BYE

Notes:

RFC 3261:
Section 15.1.1 UAC Behavior
A BYE request is constructed as would any other request within a
dialog, as described in Section 12.

Section 12.2.1.1 Generating the Request
A request within a dialog is constructed by using many of the
components of the state stored as part of the dialog...
... Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction

Each direction of the dialog shows CSeq: 1 so whatever is the direction that generates the BYE it must increase the value to 2
--VERIFIER NOTES--
The CSeq numbering space is independent for each peer. Alice's CSeq values do not affect Bob's. The intent of the phrase "in each direction" in the quote is to say that each "direction" has increments independently of the other.

Report New Errata



Advanced Search