[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] GRUU and Grid alternative
On Oct 9, 2006, at 3:47 AM, Brian Stucker wrote:
First, what if the registrar wasn't integrated with the proxy? For
instance, if the registrar is also a separate location server apart
from
the proxy, I think there's a problem. The proxy gets a request and
needs
to resolve the next hop. It sends the request to it's location server,
which then sends back a 302 response to the request that the proxy
uses
to route upon. In this case, the location server has no idea what the
requestor might do with the information, and the proxy has no idea
it's
contacted a registrar. The proxy needed a route, and the location
server/registrar supplied them. How is the proxy to know not to
rewrite
the URI? The 302 response could have returned anything, not just a
registered contact.
The question you're asking: Is the operation of a proxy in processing
a 302 response retargeting or rerouting?
I suspect it is usually rerouting, and therefore the request URI
would not change.
I'm beginning to think that most of our proxy operations are
rerouting, and we should only retarget when we're really intending to
deliver the response to "somebody else".
That said, it seems there are times when a redirect response from a
proxy means "Contact your target at this alternate location" and
times when it means "Please try a different target". We don't
currently have a way to differentiate these cases in the current spec.
Here's an off-the-wall proposal:
We could say that a 302 always indicates a "retargeting" action and
that, for the sake of preserving response identity (that is,
eliminated unanticipated response identity), it SHOULD be returned to
the originating UA rather than acted on by a proxy.
We could also say that a 305 is always a rerouting action and MUST
preserve the response identity, therefore it MAY be acted on by a proxy.
Then we'd set up most "location servers" to send 305 instead of 302.
Second, how does the proposal differ from simply having the UAS's
proxy
include a History-Info entry prior to swapping out the Request-URI
with
the UAS contact? The UAS can then look at the History-Info entry
for the
original URI.
Frankly, I don't expect SBCs to correctly pass History-Info any more
than they correctly pass Via headers. I do however expect them to
correctly pass request URIs.
And with the idea of stacking "request parameters" in H-I or Via, we
potentially get this awful situation where we have to figure out how
to combine multiple parameters inserted in different places by
different proxies. This doesn't occur, at least not the same way, if
the only parameters examined by the UAS are those in the request URI.
--
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 at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip