Morning, Thanks for the speedy responses.
I see your point about there being no To Tag in the F4 INVITE and hence a new dialog is formed when the dialog forming response is sent. I was just confused by the fact that the Call ID and From tag were identical for INVITE F4 and the 302. My main issue is one of implementation - when I receive a 302 response can I create an entirely new INVITE with the address in the 302 Contact field as the Request URI - or must I create an INVITE within the same session? From your responses I conclude that I can create a brand new INVITE without contravening the RFC. Thanks and Regards, Richard. Elwell, John wrote: > Richard, > > Notwithstanding what Paul sent, I am confused by your original question, > because INVITE F4 does NOT contain a To tag, so there is no dialog. The > first dialog-forming response leads to a different dialog, because the > To tag is different from that in the 302. > > John > > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Paul Kyzivat >> Sent: 14 March 2008 16:26 >> To: Richard Good >> Cc: [email protected] >> Subject: Re: [Sip] 302 Support in RFC 3665 >> >> >> >> Richard Good wrote: >> >>> Hi, >>> >>> I have a query regarding the 302 (Temporarily Moved) >>> >> message flow shown >> >>> in RFC 3665. >>> >>> Essentially if a SIP client receives a 302 message in >>> >> response to an >> >>> INVITE it should ACK this message and then using the >>> >> address in the >> >>> contact field send a new INVITE request. >>> >>> In the message flow shown in RFC 3665 (see section 3.6. Session via >>> Redirect and Proxy Servers with SDP in ACK) the new INVITE >>> >> request has >> >>> the same To field, From field, To Tag and Call ID - the >>> >> Request URI uses >> >>> the address specified in the Contact field of the 302 response. >>> Essentially this new INVITE is part of the same dialog but has a >>> different Request URI. >>> >>> My questions are: Is the 302 response not a final response? >>> >> Does it not >> >>> end the dialog? Shouldn't the new INVITE have new Call ID, >>> >> tags etc. and >> >>> shouldn't the address from the Contact field be in the >>> >> Request URI and >> >>> To field of the new INVITE request? >>> >> See 3261 section 8.1.3.4. Using the same To, From, and Call-Id is >> *recommended*, but not required. >> >> Note that if the 3xx recursion is done by a proxy along the >> path it must >> be this way, so it seems harmless for the UAC to do as a proxy would. >> >> OTOH, there are cases when it would be good for the To-URI to be >> updated. For instance, if a UAC counts on a proxy at the originating >> side to expand certain URIs, such as speed dial numbers, it would be >> good to do so by redirection, and for the UAC to put the >> expanded number >> into the To-URI, so that the callee will have a clue of where >> the call >> was intended to go. But doing this seems to require some >> indication that >> this is intended - e.g. a special 3xx code for the purpose. >> >> Paul >> _______________________________________________ >> 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
