RFC Errata
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.