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
