Re: [Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!)

Sanjay Sinha (sanjsinh) wrote:
> Inline ...
>
>   
>>> whereas the
>>> upstream proxy or UAC getting that 3xx is not doing redirection, but 
>>> in fact "recursing".
>>>
>>>       
>> The upstream node is just generating a new request. It really 
>> doesn't know where that request is going, except that the new 
>> request URI was obtained during an attempt to reach the old 
>> one. 
>>     
> Not sure what you mean here? The next request-uri is taken from Contact
> of the redirect response. So it knows where the request is going.
>   

It knows the URI that the request is going to. It doesn't know "who" 
that URI will reach, or what their relationship to the original URI is 
(unless perhaps "History-Info" explains it). However, this is at least 
enough knowledge to be able to prevent the unanticipated response 
problem sometimes, because we can at least check that the identity 
expressed in the eventual response matches that received in the 302. 
Assuming, of course, that the new URI doesn't go through some sort of 
retargeting operation that does not preserve the request identity.

>   
>> We'd actually have more information from a REFER request.
>>     
> How is the Refer-To header different that Contacts in redirect response?
>
>   
We're not really sure where the 3xx response came from. All we know is 
that it was generated somewhere along the path towards the original 
request-URI. REFER, however, is a request instead of a response, so we 
can use the various request-authentication techniques to figure out who 
sent it.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip