Subject: [Sip] 302 Support in RFC 3665

From: Richard Good <[email-masked]>
Date: Fri, 14 Mar 2008 12:05:54 +0200

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?

Regards,
Richard.
_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Mar 2008 12:25:38 -0400

> 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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 14 Mar 2008 18:10:56 +0000

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-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
> Sent: 14 March 2008 16:26
> To: Richard Good
> Cc: [email-masked]
> Subject: Re: [Sip] 302 Support in RFC 3665
> 
> 
> 
> Richard Good wrote:
> > Hi,
> >

---

From: [email-masked]
Date: Fri, 14 Mar 2008 14:45:19 -0500

From: Richard Good <[email-masked]>

"... and then using the address(es) in the contact field(s) send new
INVITE request(s)."

Yes, it is a fork of the original request.

   end the dialog?

Like any final response, it ends one fork of the original request.
The transaction ends based on the propagation back toward the UAC of
the final response(s).  The transaction is ended when ultimate final
response is returned to the application function in the UAC.  Whether
there is a dialog in existence after that point depends on what the
request and final response was.

Think of the INVITE transaction as a dynamically-growing tree.  In
this instance, the very root of the tree can grow additional branches.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Mar 2008 08:23:05 -0400

Just remember there is a requirement that you track the set of addresses 
you have tried, and not try the same one twice. (E.g. if your receive 
the same address in different 302 responses.)

	Paul

Richard Good wrote:
> 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,
>>
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>>> Paul Kyzivat
>>> 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.
>>>
>>> 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

---

From: Richard Good <[email-masked]>
Date: Mon, 17 Mar 2008 09:07:05 +0200

Morning,

Thanks and Regards,
Richard.

Elwell, John wrote:
>>> 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 
>>     
>>> 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 
>>     
>>> 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 
>>