Subject: Re: [Sip] Some comments on GRUUs

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Jul 2005 02:18:15 -0400

Dale,

Firstly, thanks for these most excellent and thoughtful comments. I'm 
going to respond to each party separately.

Dale Worley wrote:

> 
> * GRUUs when you don't have an AOR.
> 
> There are times when a UA doesn't really represent a permanent entity,
> and yet it would be useful for it to obtain a GRUU.  (Consider a set
> of UAs that form a distributed monitoring system.)  The current system
> makes obtaining a GRUU inherently part of registration as a contact
> for an AOR.  But as an extension, a registration agent could allow
> registrations whose only effect is to create GRUUs, and not create
> contact points for an AOR.
> 
> A plausible mechanism for this operation is a registration whose To
> address (normally the AOR to which the contact is to be registered) is
> the same as the registration agent's request-URI, "sip:<domain>".
> 
> A simplified example of such a registration and its response is:
> 
>    REGISTER sip:example.com SIP/2.0
>    From: Callee <sip:example.com>;tag=a73kszlfl
>    To: Callee <sip:example.com>
>    Call-ID: [email-masked]
>    CSeq: 1 REGISTER
>    Supported: gruu
>    Contact: <sip:[email-masked]>
>      ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
> 
> 
>    SIP/2.0 200 OK
>    From: Callee <sip:[email-masked]>;tag=a73kszlfl
>    To: Callee <sip:example.com> ;tag=b88sn
>    Call-ID: [email-masked]
>    CSeq: 1 REGISTER
>    Contact: <sip:[email-masked]>
>      ;gruu="sip:hha9s8d=[email-masked]"
>      ;+sip.instance="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
>      ;expires=3600
> 
> After that, the UA at "sip:[email-masked]" could be reached via
> "sip:hha9s8d=[email-masked]".

I agree with Paul here that this seems of limited applicability. It 
would represent an additional feature of gruu, and as such I'd rather 
leave it out of scope. There are numerous ways to do this downstream if 
we should so desire. I'd suggest you write up an I-D on the specific 
motivations if you'd like to pursue it.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Jul 2005 03:34:46 -0400

inline.

Dale Worley wrote:

> * Routing problem.
> 
> Section 8.4.2 of draft-ietf-sip-gruu-03 describes a routing problem
> that can result when a UA uses a GRUU as its target address.  In the
> worse case, shown in Figure 5 of the I-D, assume that a User Agent A
> in domain "example.com" has established a dialog with User Agent B in
> another domain.  Furthermore, domain "example.com" has a home proxy HP
> that maintains and interprets GRUUs in "example.com".  But the home
> proxy can only contact UA A via an edge proxy EP.
> 
> Thus, when UA A established the dialog with UA B, the message flow
> was:
> 
> 	UA B  <---  HP  <---  EP  <---  UA A
> 
> Assuming that both HP and EP Record-Route themselves (EP must R-R
> itself), at UA B the full routing (route-set plus target URI) is:
> 
> 	<sip:hp.example.com;lr>
> 	<sip:ep.example.com;lr>
> 	<sip:[email-masked]>
> 
> (The domain names "hp.example.com" and "ep.example.com" are more
> likely to be absolute IP addresses, but writing them symbolically
> makes the example easier to understand.)
> 
> When UA B sends an in-dialog request to UA A, EP is unable to use the
> target URI to reach UA A and instead sends the request back to HP, the
> server for the domain "example.com".  HP resolves the GRUU to the
> contact address, and forwards the request through EP to UA A.  The
> full flow is:
> 
> 	UA B  --->  HP  --->  EP
>                               |
>                      +--------+
>                      |
>                      v
> 	            HP  --->  EP  --->  UA A
> 
> Fundamentally the problem is that the Contact header in UA A's request
> that established the dialog is being overloaded with two distinct
> purposes.  On one hand, we want it to be a globally-valid URI for
> contacting UA A, a GRUU.  On the other hand, we want it to be the
> final item in a list of addresses of waypoints for routing messages
> within the dialog.  But these two requirements are contradictory --
> because of NATing or AAA (authentication, authorization, accounting),
> there may be no URI that is both gobally routable and usable for
> direct access to the UA.
> 
> There is a fairly simple solution to this:  When establishing the
> dialog, UA A needs to insert a Record-Route that provides its locally
> usable contact address, so as to mask the GRUU that is its target URI.
> Then, the full routing as seen by UA B is:
> 
> 	<sip:hp.example.com;lr>
> 	<sip:ep.example.com;lr>
> 	<sip:a.example.com;lr>
> 	<sip:[email-masked]>
> 
> Then, when an in-dialog request from UA B reaches EP, it will have
> "Route:  <sip:ep.example.com;lr>", "Route: <sip:a.example.com;lr>",
> and a request-URI of "[email-masked]".  EP recognizes
> "ep.example.com" as one of its own addresses and deletes it.  EP then
> sends the request to the next Route address, "a.example.com", which is
> a locally usable address.
> 
> In accordance with normal processing rules, UA A recognizes
> "a.example.com" as one of its addresses and removes the Route
> containing it.  It then recognizes the request-URI
> "[email-masked]" as also being one of its addresses, and processes
> the request.
> 
> Clearly, this mechanism can be used simultaneously by both ends of a
> dialog.
> 
> For the benefit of external diagnostic agents, it may be worth
> defining two URI-parameters, one to mark URIs that are GRUUs, and one
> to mark route-set URIs that are the locally-usable addresses.  For
> example:
> 
> 	<sip:hp.example.com;lr>
> 	<sip:ep.example.com;lr>
> 	<sip:a.example.com;lr;local>
> 	<sip:[email-masked];gruu>
> 
> This mechanism does have the limitation that the true target URIs for
> the dialog are no longer the stated contact URIs and cannot be changed
> during the dialog by a re-INVITE.

This is something I have considered off and on, not so much in the 
context of gruu, but for SIP processing in general, and that is whether 
or not the registered contact ought to have been populated by the proxy 
into a route rather than into the request URI, in which case the request 
URI would be the original AOR. A bunch of problems get solved if you do 
this. For example, the problem that motivated the development of 
P-Called-Party-ID in RFC 3455.

As such, there is at the core here a fairly fundamental change to 
route/contact processing, and using gruu as a vehicle for introducing it.

The main issue I ran into with this was the notion of domain ownership; 
it implied that mid-dialog requests would have a request URI that 
identified a target resource that is really owned by a proxy in the 
domain, yet the request is routed to, and terminates at, a UA that can 
really only claim ownership over its own IP address. This may seem like 
a theoretical problem, but it manifests itself in some of the real 
issues raised by Nils around invocation of services.

Another issue is the one raised by Nils:

Nils Ohlmeier wrote:
> My concerns with such a solution are:
> - how can the UA A determine its address a.example.com? Especially with NAT's 
> between the UA and the proxies this a big problem again, or?

This is indeed a big problem. The solution proposed for this is in the 
sipping-outbound draft, which basically allows the gruu to get bound to 
a connection to the EP rather than to the IP address and port of the UA. 
This means that, in order to be reachable by the proxy, the address the 
proxy uses needs to be the gruu, and that leads us right back to square one.

I suppose a fix for this is this. When the sipping-outbound mechanism is 
in use, a proxy will insert a Path header field value into the REGISTER 
that identifies the "connection" that the client registered through. 
This URI is used by the proxy for incoming requests to route them 
towards that client, more or less ignoring the request URI. Note that 
the Path values are returned to the client in the 200 OK to register. 
So, the client could use that Path value in its record-route value. That 
would solve the nat problem at least.

However, one of the benefits that gruu brings to the table is that it 
adds a layer of indirection for mid-dialog request routing. If you have 
a session in progress and you end up re-registering, possibly to a 
different proxy, mid-dialog requests can still be delivered to you. This 
need arises for some of the mobility use cases, and for various failure 
cases where the client loses its connection to the server. If we put a 
client IP address or a connection URI (as learned from Path) into the 
record-route, we pin the mid-dialog requests to that specific IP address 
or connection, eliminating these benefits.

That said, your suggestion is a simple way to solve an otherwise nasty 
problem. Indeed, you are absolutely correct that the gruu has really a 
split personality; its being used as a way to reach a specific UA 
instance for a mid-dialog request, but also as a way to reach a UA 
instance outside of a dialog. There are, unfortunately, differences in 
the types of features that a proxy might want to invoke on the request 
depending on whether its mid-dialog or an initial request, and that is a 
consequence of this split personality you point to.

The net/net for me is that I think my original proposal, of just 
allowing the proxy to remove its record-route header field in the 200 
OK, is really the simplest. There are a few ways the proxy can determine 
that it is safe to remove the record-route.

-Jonathan R.