RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (2)

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

Source of RFC: sipping (rai)

Errata ID: 2740
Status: Verified
Type: Technical

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

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.

Status: Reported (2)

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

Source of RFC: sipping (rai)

Errata ID: 4047
Status: Reported
Type: Technical

Reported By: Gergely Szabo
Date Reported: 2014-07-11

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.

Errata ID: 5294
Status: Reported
Type: Technical

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.

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

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

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