RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata