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: [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
