RFC Errata
Found 16 records.
Status: Verified (10)
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: 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: Reported (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: 4275
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chao Wang
Date Reported: 2015-02-19
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.
Errata ID: 4553
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2015-12-04
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
Errata ID: 5653
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Vimal Chandra Tewari
Date Reported: 2019-03-12
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: 6645
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt Hertogs
Date Reported: 2021-07-20
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: 6793
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mojtaba Esfandiari.S
Date Reported: 2021-12-21
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: 7529
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Shraddha Soni
Date Reported: 2023-05-29
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.