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 protected] [mailto:[email protected]] 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 protected]<mailto:[email protected]>> wrote: Pl. see inline ... ________________________________ From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] 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 protected]<mailto:[email protected]>> wrote: 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." > -----Original Message----- > From: [email protected]<mailto:[email protected]> > [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Dale > Worley > Sent: Monday, February 09, 2009 4:14 PM > To: SIP > Subject: Re: [Sip] [Technical Errata Reported] RFC4028 (1681) > > On Mon, 2009-02-09 at 13:03 -0600, Robert Sparks wrote: > > 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. > > 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 > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [email protected]<mailto:[email protected]> > for questions on current sip > Use [email protected]<mailto:[email protected]> 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 protected]<mailto:[email protected]> for questions on current sip Use [email protected]<mailto:[email protected]> 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 protected] for questions on current sip Use [email protected] for new developments on the application of sip
