RFC Errata
Found 5 records.
Status: Verified (3)
RFC 4028, "Session Timers in the Session Initiation Protocol (SIP)", April 2005
Source of RFC: sip (rai)
Errata ID: 632
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ervin Wittner
Date Reported: 2007-06-25
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08
Section 9 says:
If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one.
It should say:
If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAC is indicating support for timers but is not requesting one.
Notes:
I believe that in the first sentence, the reference to "...the UAS is
indicating support...." should read "... the UAC is indicating
support..."
Errata ID: 1681
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Muthu Arul Mozhi
Date Reported: 2009-02-09
Verifier Name: Robert Sparks
Date Verified: 2010-04-03
Section 13 says:
In section 13 (Example Call Flow) the From tag never changes between the initial INVITE message and the subsequent INVITE messages sent after receiving a 422: message 1 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Supported: timer Session-Expires: 50 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142 message 4 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Supported: timer Session-Expires: 3600 Min-SE: 3600 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142 message 10 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 Supported: timer Session-Expires: 4000 Min-SE: 4000 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314161 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp However, as per RFC 3261, if an initial INVITE generates a non-2xx final response, that terminates all sessions and all dialogs that were created. Hence, these are not re-INVITE messages, rather new INVITE messages and should use a new From tag.
It should say:
message 1 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Supported: timer Session-Expires: 50 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142 message 4 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9 Supported: timer Session-Expires: 3600 Min-SE: 3600 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=2568701785 Call-ID: a84b4c76e66710 CSeq: 314160 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp Content-Length: 142 message 10 INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10 Supported: timer Session-Expires: 4000 Min-SE: 4000 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=5647301796 Call-ID: a84b4c76e66710 CSeq: 314161 INVITE Contact: <sips:alice@pc33.atlanta.example.com> Content-Type: application/sdp
Notes:
-----Original Message-----
From: Paul Kyzivat (pkyzivat)
Sent: Monday, February 09, 2009 10:09 PM
To: Muthu ArulMozhi Perumal (mperumal)
Cc: Radha Krishna Saragadam (rsaragad); Jonathan Rosenberg (jdrosen); Ram Mohan R (rmohanr)
Subject: Re: UAS behavior after sending 422 for initial INVITE
yes, I think so.
Paul
Muthu ArulMozhi Perumal (mperumal) wrote:
> In section 13 (Example Call Flow) of RFC 4028 the From tag never changes
> between the initial INVITE message and the subsequent INVITE messages
> sent after receiving a 422:
>
> message 1
> INVITE sips:bob@biloxi.example.com SIP/2.0
> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
> Call-ID: a84b4c76e66710
>
> message 4
> INVITE sips:bob@biloxi.example.com SIP/2.0
> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
> Call-ID: a84b4c76e66710
>
> message 10
> INVITE sips:bob@biloxi.example.com SIP/2.0
> From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
> Call-ID: a84b4c76e66710
>
> Is this a bug in the RFC?
>
> thanks,
> Muthu
>
> |-----Original Message-----
> |From: Paul Kyzivat (pkyzivat)
> |Sent: Wednesday, February 04, 2009 12:36 AM
> |To: Radha Krishna Saragadam (rsaragad)
> |Cc: Jonathan Rosenberg (jdrosen); Muthu ArulMozhi Perumal (mperumal);
> Ram Mohan R (rmohanr)
> |Subject: Re: UAS behavior after sending 422 for initial INVITE
> |
> |Radha,
> |
> |It is not a reinvite, because a dialog was never established - the
> first
> |call failed.
> |
> |So you are starting a new invite. You can use the same callid, but
> |should use a new from-tag.
> |
> | Thanks,
> | Paul
> |
> |Radha Krishna Saragadam (rsaragad) wrote:
> |> Hi Paul
> |>
> |> My question is for initial INVITE. For initial INVITE if UA
> |> receives 422 and UA want to retry INVITE with new value increased
> value
> |> then what should be the To(with tag), From(with tag) and CallID
> values?
> |> Is it a Re-INVITE or new a Dialog? Section 7.3 says same value for
> |> To,From and CallID
> |>
> |> Regards
> |> S.Radha krishna
Errata ID: 3614
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: José María González Calabozo
Date Reported: 2013-05-06
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-05-21
Section 13 says:
Record-Route: sips:p1.atlanta.example.com;lr Route: sips:p1.atlanta.example.com;lr
It should say:
Record-Route: <sips:p1.atlanta.example.com;lr> Route: <sips:p1.atlanta.example.com;lr>
Notes:
In the examples, all the Record-Route and Route headers are wrong.
They are:
Record-Route: sips:p1.atlanta.example.com;lr
Route: sips:p1.atlanta.example.com;lr
But according with the section "25.1 Basic Rules" of RFC3261 those headers are defined as:
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route)
rec-route = name-addr *( SEMI rr-param )
rr-param = generic-param
Route = "Route" HCOLON route-param *(COMMA route-param)
route-param = name-addr *( SEMI rr-param )
So the headers should be:
Record-Route: <sips:p1.atlanta.example.com;lr>
Route: <sips:p1.atlanta.example.com;lr>
Status: Reported (2)
RFC 4028, "Session Timers in the Session Initiation Protocol (SIP)", April 2005
Source of RFC: sip (rai)
Errata ID: 4744
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chao Wang
Date Reported: 2016-07-19
Section 3 says:
A UAC starts by sending an INVITE. This includes a Supported header field with the option tag 'timer', indicating support for this extension.
It should say:
A UAC starts by sending an INVITE. This includes a Supported header field with the option tag 'timer', indicating support for this extension.If UAC or UAS knows one negotiation of session timer is ongoing, it SHALL not start a new one.
Notes:
Add one more sentence here "If UAC knows one negotiation of session timer is ongoing, it SHALL not start a new one."
Actually in the scenarios of session set-up or session modification, it is easy to see the message exchange of UPDATE and (re-)INVITE, according to this RFC, both of them are allowed for the negotiation of session timer, the decision shall be taken on their own 200 OK. Normally the negotiation of session time of (re-)INVITE is started at first and the UPDATE's will be taken place, from UAS perspective, it needs to treat two negotiations of session timer in-parallel, since there is no kind of mechanism to protect the parameters carried in (re-)INVITE and UPDATE being inconsistent, it brings a problem on UAS that the result of two negotiations might be different specially for the parameter of refresher and also the inconsistency will cause UAS to meet a conflict while it is deciding the parameters especially for refresher on 200 OK of (re-)INVITE. In order to avoid this problem, it is better to disallow a net negotiation of session timer until the ongoing one is finished.
Errata ID: 4056
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lucas Wang
Date Reported: 2014-07-17
Section 8 says:
8. Proxy Behavior Session timers are mostly of interest to call stateful proxy servers (that is, to servers that maintain the state of calls and dialogs established through them). However, a stateful proxy server (that is, a server which is aware of transaction state but does not retain call or dialog state) MAY also follow the rules described here. Stateless proxies MUST NOT attempt to request session timers. Proxies that ask for session timers SHOULD record-route, as they won't receive refreshes if they don't.
It should say:
Session timers are mostly of interest to call stateful proxy servers (that is, to servers that maintain the state of calls and dialogs established through them). However, a stateless proxy server (that is, a server which is aware of transaction state but does not retain call or dialog state) MAY also follow the rules described here. Stateless proxies MUST NOT attempt to request session timers. Proxies that ask for session timers SHOULD record-route, as they won't receive refreshes if they don't.
Notes:
After the "However", it should be a stateless proxy server.