Subject: [Sip] [Technical Errata Reported] RFC4028 (1681)

From: RFC Errata System <[email-masked]>
Date: Mon, 9 Feb 2009 09:36:34 -0800 (PST)

The following errata report has been submitted for RFC4028,
"Session Timers in the Session Initiation Protocol (SIP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4028&eid=1681

--------------------------------------
Type: Technical
Reported by: Muthu Arul Mozhi <[email-masked]>

Section: 13

Original Text
-------------
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:[email-masked] 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:[email-masked]>
   From: Alice <sips:[email-masked]>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sips:[email-masked]>
   Content-Type: application/sdp
   Content-Length: 142

message 4
   INVITE sips:[email-masked] 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:[email-masked]>
   From: Alice <sips:[email-masked]>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314160 INVITE
   Contact: <sips:[email-masked]>
   Content-Type: application/sdp
   Content-Length: 142

message 10
   INVITE sips:[email-masked] 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:[email-masked]>
   From: Alice <sips:[email-masked]>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314161 INVITE
   Contact: <sips:[email-masked]>
   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.

Corrected Text
--------------
message 1
   INVITE sips:[email-masked] 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:[email-masked]>
   From: Alice <sips:[email-masked]>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Contact: <sips:[email-masked]>
   Content-Type: application/sdp
   Content-Length: 142

message 4
   INVITE sips:[email-masked] 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:[email-masked]>
   From: Alice <sips:[email-masked]>;tag=2568701785
   Call-ID: a84b4c76e66710
   CSeq: 314160 INVITE
   Contact: <sips:[email-masked]>
   Content-Type: application/sdp
   Content-Length: 142

message 10
   INVITE sips:[email-masked] 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:[email-masked]>
   From: Alice <sips:[email-masked]>;tag=5647301796
   Call-ID: a84b4c76e66710
   CSeq: 314161 INVITE
   Contact: <sips:[email-masked]>
   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:[email-masked] SIP/2.0
>    From: Alice <sips:[email-masked]>;tag=1928301774
>    Call-ID: a84b4c76e66710
> 
> message 4
>    INVITE sips:[email-masked] SIP/2.0
>    From: Alice <sips:[email-masked]>;tag=1928301774
>    Call-ID: a84b4c76e66710
> 
> message 10
>    INVITE sips:[email-masked] SIP/2.0
>    From: Alice <sips:[email-masked]>;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

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4028 (draft-ietf-sip-session-timer-15)
--------------------------------------
Title               : Session Timers in the Session Initiation Protocol (SIP)
Publication Date    : April 2005
Author(s)           : S. Donovan, J. Rosenberg
Category            : PROPOSED STANDARD
Source              : Session Initiation Protocol
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

---

From: Brett Tate <[email-masked]>
Date: Mon, 9 Feb 2009 09:59:46 -0800

The reported error does not sound correct.  If RFC 4028 is incorrect concerning From tag, so is RFC 3261 (section 8.1 and likely other sections) and various other RFCs.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of RFC
> Errata System
> Sent: Monday, February 09, 2009 12:37 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Sip] [Technical Errata Reported] RFC4028 (1681)
> 
> 
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

---

From: Brett Tate <[email-masked]>
Date: Mon, 9 Feb 2009 10:03:21 -0800

Sorry about the repost, I intended to indicate section RFC 3261 section 8.1.3.5.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brett Tate
> Sent: Monday, February 09, 2009 1:00 PM
> To: [email-masked]
> Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681)
> 
> The reported error does not sound correct.  If RFC 4028 is incorrect
> concerning From tag, so is RFC 3261 (section 8.1 and likely other
> sections) and various other RFCs.
> 
> 
> 
> > Cc: Radha Krishna Saragadam (rsaragad); Jonathan Rosenberg (jdrosen);
> Ram
> > Mohan R (rmohanr)

---

From: Robert Sparks <[email-masked]>
Date: Mon, 9 Feb 2009 13:03:48 -0600

I agree - the example is not flawed (at least in the way the errata  
reports).

Muthu seems to troubled by the reuse of the call-id and from tag when  
the initial transaction didn't create a dialog.
While doing so is not required by the specification, nothing makes it  
illegal either.

RjS

On Feb 9, 2009, at 11:59 AM, Brett Tate wrote:

>> Cc: Radha Krishna Saragadam (rsaragad); Jonathan Rosenberg  
>> (jdrosen); Ram
>> Mohan R (rmohanr)
>> Title               : Session Timers in the Session Initiation  
>> Protocol
>> (SIP)

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 09 Feb 2009 16:14:09 -0500

> While doing so is not required by the specification, nothing makes it  

Are we agreed that "doing so is not required by the specification"?  In
RFC 3261, requests that are retried after 401, 407, 413, 415, 416, and
420 responses are required to have the same from-tag as the original
request.  Is 422 different?

Dale

---

From: Brett Tate <[email-masked]>
Date: Mon, 9 Feb 2009 13:25:06 -0800

Based upon the following snippet, my understanding is that RFC 4028 is correctly following the SHOULD.

RFC 3261 section 8.1.3.5 snippet:

"In all of the above cases, the request is retried by creating a new request with the appropriate modifications.  This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. With other 4xx responses, including those yet to be defined, a retry may or may not be possible depending on the method and the use case."

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale
> Worley
> Sent: Monday, February 09, 2009 4:14 PM
> To: SIP

---

From: Muthu Arul <[email-masked]>
Date: Tue, 10 Feb 2009 10:27:22 +0530

If the From tag doesn't change, can the UAS retrain the same To tag as well?
If the new INVITE reaches the UAS before the ACK for the previous INVITE,
what should the UAS do? Should it reject the new INVITE and expect the UAC
to retry again?

I thought it would have been much simpler had the From/To tag changed b/w
the INVITE messages..

thanks,
Muthu

On Tue, Feb 10, 2009 at 2:55 AM, Brett Tate <[email-masked]> wrote:

> "In all of the above cases, the request is retried by creating a new
> request with the appropriate modifications.  This new request constitutes a
> new transaction and SHOULD have the same value of the Call-ID, To, and From
> of the previous request, but the CSeq should contain a new sequence number
> that is one higher than the previous. With other 4xx responses, including
> those yet to be defined, a retry may or may not be possible depending on the
> method and the use case."
>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Tue, 10 Feb 2009 03:14:46 -0500

Pl. see inline ...

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Muthu Arul
	Sent: Tuesday, February 10, 2009 10:27 AM
	To: Brett Tate
	Cc: SIP
	Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681)

	If the From tag doesn't change, can the UAS retrain the same To
tag as well? 
	[Sanjay Sinha (sanjsinh)]  When can UAS retain to-tag, when it
is rejecting *resubmitted* request?
	 
	 If the new INVITE reaches the UAS before the ACK for the
previous INVITE, what should the UAS do? 
	[Sanjay Sinha (sanjsinh)] Since the resubmitted request will not
have a to-tag, even if Call-Id and from-tag is same, it wont match any
ongoing transaction and so should be treated as a new request. 
	 
	Should it reject the new INVITE and expect the UAC to retry
again?
	
	I thought it would have been much simpler had the From/To tag
changed b/w the INVITE messages..
	[Sanjay Sinha (sanjsinh)]  It would have been better, but it is
not illegal for Call-id + from-tag to not change. Besides, it is an
example and should be treated as such.. 
	
	thanks,
	Muthu

	On Tue, Feb 10, 2009 at 2:55 AM, Brett Tate
<[email-masked]> wrote:

		Based upon the following snippet, my understanding is
that RFC 4028 is correctly following the SHOULD.

		"In all of the above cases, the request is retried by
creating a new request with the appropriate modifications.  This new
request constitutes a new transaction and SHOULD have the same value of
the Call-ID, To, and From of the previous request, but the CSeq should
contain a new sequence number that is one higher than the previous. With
other 4xx responses, including those yet to be defined, a retry may or
may not be possible depending on the method and the use case."

		> From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dale
		> Sip mailing list
https://www.ietf.org/mailman/listinfo/sip
		_______________________________________________
		Sip mailing list
https://www.ietf.org/mailman/listinfo/sip
		This list is for NEW development of the core SIP
Protocol
		Use [email-masked] for questions on
current sip
		Use [email-masked] for new developments on the
application of sip

---

From: Muthu Arul <[email-masked]>
Date: Tue, 10 Feb 2009 20:25:43 +0530

Another source of confusion is that section 8.1.3.5 of RFC 3261 says the new
INVITE request SHOULD use same value of Call-ID, To and From as the previous
INVITE request. It is not clear whether it means just the same value of the
URI portion of To and From or also the same tags.

If it means the same tags then it is probably wrong --the new INVITE request
can not have a To tag, since the dialog is already gone.

Muthu

On Tue, Feb 10, 2009 at 1:44 PM, Sanjay Sinha (sanjsinh) <[email-masked]
> wrote:

>  Pl. see inline ...
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Muthu
> Arul
> *Sent:* Tuesday, February 10, 2009 10:27 AM
> *To:* Brett Tate
> *Cc:* SIP
> *Subject:* Re: [Sip] [Technical Errata Reported] RFC4028 (1681)
>
> [Sanjay Sinha (sanjsinh)]  When can UAS retain to-tag, when it is rejecting
> *resubmitted* request?
>
> what should the UAS do?
> [Sanjay Sinha (sanjsinh)] Since the resubmitted request will not have a
> to-tag, even if Call-Id and from-tag is same, it wont match any ongoing
> transaction and so should be treated as a new request.
>
> Should it reject the new INVITE and expect the UAC to retry again?
>
> [Sanjay Sinha (sanjsinh)]  It would have been better, but it is not illegal
> for Call-id + from-tag to not change. Besides, it is an example and should
> be treated as such..
>
> thanks,
> Muthu
>

---

From: Bob Penfield <[email-masked]>
Date: Tue, 10 Feb 2009 11:56:47 -0500

The text in 8.1.3.5 means that the From and To headers in the new INVITE should have the same value including tags as the rejected INVITE. If it was an initial (out-of-dialog) INVITE, there will be no to-tag in the To, and thus the re-submitted request will not have a to-tag either. There is no need to change the Call-ID or the from tag because no dialogs were created.

If it is an in-dialog request, it must have the same tags otherwise it will not match the dialog. This could happen if authentication is required for in-dialog requests and the UAC did not include the credentials, or the credentials are stale.

>From an implementation point of view, it is simpler if the procedures for re-submitting requests for repairable 4xx errors are the same for in-dialog and out-of-dialog requests.

I see no reason to change the Call-ID or from tag.

As for the question "If the From tag doesn't change, can the UAS retrain the same To tag as well?", I would say that UAS should not use the same to-tag for a new request.

cheers,
(-:bob

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Muthu Arul
Sent: Tuesday, February 10, 2009 9:56 AM
To: Sanjay Sinha (sanjsinh)
Cc: SIP; Brett Tate
Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681)

Another source of confusion is that section 8.1.3.5 of RFC 3261 says the new INVITE request SHOULD use same value of Call-ID, To and From as the previous INVITE request. It is not clear whether it means just the same value of the URI portion of To and From or also the same tags.

If it means the same tags then it is probably wrong --the new INVITE request can not have a To tag, since the dialog is already gone.

Muthu

On Tue, Feb 10, 2009 at 1:44 PM, Sanjay Sinha (sanjsinh) <[email-masked]<mailto:[email-masked]>> wrote:
Pl. see inline ...
________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Muthu Arul
Sent: Tuesday, February 10, 2009 10:27 AM
To: Brett Tate
Cc: SIP

If the From tag doesn't change, can the UAS retrain the same To tag as well?
[Sanjay Sinha (sanjsinh)]  When can UAS retain to-tag, when it is rejecting *resubmitted* request?

 If the new INVITE reaches the UAS before the ACK for the previous INVITE, what should the UAS do?
[Sanjay Sinha (sanjsinh)] Since the resubmitted request will not have a to-tag, even if Call-Id and from-tag is same, it wont match any ongoing transaction and so should be treated as a new request.

I thought it would have been much simpler had the From/To tag changed b/w the INVITE messages..
[Sanjay Sinha (sanjsinh)]  It would have been better, but it is not illegal for Call-id + from-tag to not change. Besides, it is an example and should be treated as such..

thanks,
Muthu

On Tue, Feb 10, 2009 at 2:55 AM, Brett Tate <[email-masked]<mailto:[email-masked]>> wrote:
Based upon the following snippet, my understanding is that RFC 4028 is correctly following the SHOULD.

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dale
> Worley
> Use [email-masked]<mailto:[email-masked]> for questions on current sip
> Use [email-masked]<mailto:[email-masked]> for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked]<mailto:[email-masked]> for questions on current sip
Use [email-masked]<mailto:[email-masked]> for new developments on the application of sip

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 10 Feb 2009 12:12:21 -0500

On Tue, 2009-02-10 at 11:56 -0500, Bob Penfield wrote:
> The text in 8.1.3.5 means that the From and To headers in the new
> INVITE should have the same value including tags as the rejected
> INVITE. If it was an initial (out-of-dialog) INVITE, there will be no
> to-tag in the To, and thus the re-submitted request will not have a
> to-tag either. There is no need to change the Call-ID or the from tag
> because no dialogs were created.
>  
> If it is an in-dialog request, it must have the same tags otherwise it
> will not match the dialog. This could happen if authentication is
> required for in-dialog requests and the UAC did not include the
> credentials, or the credentials are stale.
>  
> From an implementation point of view, it is simpler if the procedures
> for re-submitting requests for repairable 4xx errors are the same for
> in-dialog and out-of-dialog requests.
>  

All of the above matches my understanding and the discussions that I've
seen here.
 
> As for the question "If the From tag doesn't change, can the UAS
> retrain the same To tag as well?", I would say that UAS should not use
> the same to-tag for a new request.

I'm sure that the UAS should not use the same to-tag in its response to
the new request -- the first request did not establish a dialog, so the
second request could not be part of that dialog.  And indeed, it would
be difficult to build a UAS that did use the same to-tag, as it would
have to remember the to-tag it used in the first request and use it in
the second -- but nonetheless, if it received two copies of the first
INVITE and rejected both, it would have to use different to-tags for the
two error responses.

Dale