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] > wrote: > Pl. see inline ... > > ------------------------------ > *From:* [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]> 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]] 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] for questions on current sip >> > Use [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 >> > >
_______________________________________________ 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
