[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] GRUU and Grid alternative



Brian,

If the original requester used a GRUU as request URI, none but the proxy responsible for the corresponding domain is allowed to rewrite it. It is possible there was some other URI that got rewritten into a GRUU (eg through a 3rd party registration using a GRUU as Contact), but then still what arrives at the home proxy has a GRUU in the request URI.

Regards,

Jeroen

----- Original Message ----- From: "Brian Stucker" <bstucker at nortel.com>
To: "Jonathan Rosenberg" <jdrosen at cisco.com>; <jbemmel at zonnet.nl>
Cc: "IETF SIP List" <sip at ietf.org>
Sent: Wednesday, October 04, 2006 8:30 PM
Subject: RE: [Sip] GRUU and Grid alternative



Maybe I'm missing something here, but aren't the proxies between the UAC and the proxy that would normally rewrite the request-URI for delivery of the request to the final UAS still going to be rewriting the request URI (potentially) along the way?

Doesn't that mean that the UAS doesn't know what the original URI the
UAC specified was? It only knows the URI that existed just before the
proxy that handled routing to the UAS's registered contacts was.

???

Regards,
Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen at cisco.com]
Sent: Wednesday, September 27, 2006 9:53 PM
To: jbemmel at zonnet.nl
Cc: IETF SIP List
Subject: Re: [Sip] GRUU and Grid alternative



jbemmel at zonnet.nl wrote:

> Jonathan,
>
> Yes, I think this would work as a cleaner / more general
solution than
> grid
>
> For the mechanism, the UA would need to insert a 'lr'
parameter into
> its Contact. This is needed for Path proxy traversal, and makes the
> logic at the registrar simpler (i.e. if registered contact URI
> contains a lr then append Route, else rewrite)
>
> Perhaps 'lr' alone could be sufficient (i.e. no Supported) although
> you may want an option tag to detect support for this feature

Indeed. This was going to be my next post.

One of the problems with using Supported/Require in REGISTER,
is that it only works for proxy translation services based on
registrations. Other services, such as routing to a PSTN
gateway, or application routing, are not populated by a
registration. So, how would a proxy know whether to rewrite
the R-URI or push a Route?

The idea, as you suggest, is that if the target URI has a ;lr
parameter, the proxy would push a Route. Otherwise, it
rewrites the request uri. In this case, when a UA registers,
rather than using Supported/Require, it could just place a
URI into the Contact which contains the ;lr parameter.

This works just fine as long as you assume that existing UA
and routing table configurations are NOT using the ;lr
parameter. I got some reports that existing UA were
populating the Contact header field with URIs with the ;lr
parameter, just because they "support" loose routing (RFC 3261).
This behavior would break the idea of using the ;lr flag to
indicate this feature.

A hybrid is to use the ;lr flag just for non-register based
location services, and then use Supported/Require for registrations.


> > One difference with request URI rewriting is that the latter is > automatically a one-time operation: once the URI is rewritten, the proxy > won't rewrite again when the request spirals. For Route this is not the > case. OTOH, if there are any Route headers the proxy shouldn't be > rewriting / adding a route in the first place,

No. Consider the case of a Path headers. In this case, the home proxy
would populate the Route headers from the path set, and then
push the UA
route as the *last* Route header field. But anyway I don't understand
the issue you are raising with spiraling. On each spiral, a new Route
gets pushed. If instead you had R-URI rewriting, the only way the
request would get back to the proxy is if the r-uri pointed to that
proxy, and upon arriving there it would be rewritten again.
So there is
no difference.

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ
07054-2711
Cisco Systems
jdrosen at cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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



_______________________________________________
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