302 Support in RFC 3665

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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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: sip-bouncesietf.org [mailto:sip-bouncesietf.org]
On 
> Behalf Of Paul Kyzivat
> Sent: 14 March 2008 16:26
> To: Richard Good
> Cc: sipietf.org
> 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 sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org 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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

   From: Richard Good <rgoodcrg.ee.uct.ac.za>

   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.

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

   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.

Yes, it is a fork of the original request.

   My questions are: Is the 302 response not a final
response? Does it not 
   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
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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,
>>
>> 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: sip-bouncesietf.org
[mailto:sip-bouncesietf.org] On Behalf Of 
>>> Paul Kyzivat
>>> Sent: 14 March 2008 16:26
>>> To: Richard Good
>>> Cc: sipietf.org
>>> 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 sip-implementorscs.columbia.edu for
questions on current sip
>>> Use sippingietf.org 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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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: sip-bouncesietf.org
[mailto:sip-bouncesietf.org] On 
>> Behalf Of Paul Kyzivat
>> Sent: 14 March 2008 16:26
>> To: Richard Good
>> Cc: sipietf.org
>> 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 sip-implementorscs.columbia.edu for
questions on current sip
>> Use sippingietf.org 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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip