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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
