RE: [Sip] GRUU and Grid alternative

["Brian Stucker" <bstucker at nortel.com>]

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