Subject: [Sip] GRUU and Grid alternative

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Sep 2006 01:49:49 -0400

During our call on GRUU last week, there was a discussion on this issue 
that ekr raised, where he would like to see the grid usable outside of 
just gruu, i.e., with any AOR.

During the call, I made a suggestion for an alternative solution, and 
there was agreement amongst those on the call for the proposed approach.

The basic idea would be to remove the grid mechanism entirely from the 
gruu draft. Instead, a separate specification would be developed which 
would allow for loose routing to apply to user agents. So, consider a UA 
which registers. It would include a contact and a Supported header field 
with the value "ua-route". The registrar, assuming it understands this, 
notes that the UA supports UA loose routing and stores the contact. When 
an incoming call arrives for the AOR, rather than rewriting the R-URI 
with the registered contact, it pushes the registered contact into a 
Route header and leaves the R-URI alone (assuming the registered UA 
supports this mechanism).

How does this solve the grid problem? Lets say my AOR is 
sip:[email-masked]. I, as a UA, can mint a URI with some arbitrary 
parameter, say sip:[email-masked];foo=baz, and hand it out to some 
correspondent. When a correspondent sends a request to that URI, it 
arrives at my home proxy. From there, since the R-URI is NOT rewritten, 
the entire URI, parameters and all, is passed to the UA. Thus, the UA 
knows the URI that was de-referenced. We wouldn't necessarily have to 
standardize a specific URI parameter, like grid, to carry the opaque data.

This trick solves a whole bunch of other problems too. It would 
eliminate the need for the IMS P-Called-Party-ID header field, and it 
would help clarify when a request is retargeted (change in R-URI) vs. 
when its just being delivered to the recipient (no change in R-URI).

Comments?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Wed, 27 Sep 2006 12:31:47 +0200

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

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, so I guess it would 
be covered (my interpretation, RFC3261 doesn't say this explicitly, so 
perhaps worth spending a few words on)

Regards,

Jeroen

> During our call on GRUU last week, there was a discussion on this 
> issue that ekr raised, where he would like to see the grid usable 
> outside of just gruu, i.e., with any AOR.
>
> The basic idea would be to remove the grid mechanism entirely from 
> the gruu draft. Instead, a separate specification would be developed 
> which would allow for loose routing to apply to user agents. So, 
> consider a UA which registers. It would include a contact and a 
> Supported header field with the value "ua-route". The registrar, 
> assuming it understands this, notes that the UA supports UA loose 
> routing and stores the contact. When an incoming call arrives for the 
> AOR, rather than rewriting the R-URI with the registered contact, it 
> pushes the registered contact into a Route header and leaves the 
> R-URI alone (assuming the registered UA supports this mechanism).
>
> arrives at my home proxy. From there, since the R-URI is NOT 
> rewritten, the entire URI, parameters and all, is passed to the UA. 
> Thus, the UA knows the URI that was de-referenced. We wouldn't 
> necessarily have to standardize a specific URI parameter, like grid, 
> to carry the opaque data.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Sep 2006 22:52:54 -0400

[email-masked] wrote:

> 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)
> 

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.

> 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.