Subject: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Apr 2003 03:17:59 -0400

During the San Francisco IETF, there was a lot of discussion on the 
concept of a GRUU:

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-lease-00.txt

A GRUU, defined in this I-D, is a URI with the property that it routes 
to a specific UA instance. GRUUs are needed for lots of applications, 
like assisted call transfer, presence, and 3g/802.11 roaming (a recent 
application for a gruu identified on the list).

During the meeting, there was a lot of confusion on two points, and I 
want to continue the dialog over email and attempt to clarify them.

1. The I-D talks about temporal scoping. Forget the word temporal. The 
idea really is that a UA should be able to manufacture an infinite 
supply of URIs that route to itself. In the process of that 
manufacturing, it needs to be able to place information into the URI, so 
that it can use that information to determine some kind of context when 
it receives a call to that URI. As an example, if a UA decides to host a 
conference, it needs to manufacture a conference URI that is unique for 
that conference, and identifies the conference.

2. Getting to specifics, there are really two candidate approaches for 
constructing a GRUU. Rohan and Alan advocated the idea of using embedded 
Route headers, thusly:

sip:[email-masked]?Route=sip:proxy1.example.com?Route=sip:proxy2.example.com

A UA would be provisioned with this sequence of routes.

The idea I was trying to promote in my I-D is that there is another way. 
Instead, the UA asks the domain to give it a URI that has the GRUU 
property. The domain can populdate the user portion of this URI in such 
a way that it provides sufficient context for the domain to route the 
request to that UA. THis can be done in a stateless way if the leasing 
operation is combined with a registration. So, for example, when a UA 
registers thusly:

REGISTER
To: sip:[email-masked]
Contact: sip:1.2.3.4

the domain could provide the UA with the following URI in the 200 OK to 
REGISTER:

sip:[email-masked]

When someone sends a request to this URI, the example.com proxy 
recognizes this as a GRUU, and sees that what it needs to do is route 
the request to [email-masked], at their 1.2.3.4 contact. So, it can 
directly send it to 1.2.3.4 from there.

The key idea is that because the domain is the one manufacturing this 
URI, it can construct the user part in any way it likes, including the 
inclusion of context to facilitate stateless routing. Now, inclusion of 
context for stateless routing is just one approach. If a domain wants, 
it can also just create state for each lease. Its a domain policy issue.

One last point here - the draft also talks about the idea that the URI 
returned by the domain can be considered a URI factory. There can be 
some kind of wildcard in the URI, which the user can put anything it 
wants into it, to give the user context.

So, which approach is better? I believe that the leasing approach I 
propose is the right one. Why? Because a GRUU is a *name*. Names need to 
be obtained from the owner of that namespace, especially when you want 
the name to be associated with some specific semantic. The first 
approach, of embedded route headers, is confusing a name with a route. 
It is trying to identify somethign by the way in which you get to it.

As an example of a consequence of this, the way in which a call is 
routed may depend on the caller. For example, a call center may route 
calls through some kind of logging server, which are allocated based on 
the caller's identity. But, with the embedded Route approach, the route 
is bound to the name, so you cannot change it depending on who is calling.

Comments and criticisms?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Apr 2003 15:36:00 +0300

Hi,

Some initial comments. In general, I don't have any major comments on the solution
itself, just some of the technical details.

URI wildcarding
-----------------

First, RFC3261 allows the "*" character in the URI, but it doesn't say anything
about the fact that it should be used for wildcarding only. So, how will the
receiver of the LEASE response, and the Leaser header, know if the "*" (the URI
MAY even contain multiple "*" characters) is to be used for wildcarding, or if
it's simply part of the URI name itself? Before answering this, please read the
following question :)

Second, if you allow wildcarding, I think it is very important (I assume those who
have been working with H.248 agree) to define wildcarding rules. In your example
the FIRST character in the URI is used for wildcarding. Can the wildcarding
character be elsewhere in the URI? And, to come back to the first question, how
does the UAC know which "*" characters are wildcards, and which are parts of the
URI name?

Register
--------

Assume I send a LEASE, but NOT a REGISTER. What will now happen if the proxy
receive a Request, destinated to the URI (the wildcard has been replaced with a
specific value) it returned in the LEASE response?

The reason I ask is because some nodes, especially gateways, do not register - due
to well known facts. A gateway can use wildcarded LEASE, but not wildcarded
REGISTER (of course, one could say that since gateways most often are static
nodes, if GRUU are needed they can be configured in the gateway).

In fact, one could even ask: if we now introduce URI wildcarding, and allow it in
the LEASE command, should we also introduce wildcarded registering? Just a
thought...

Regards,

Christer Holmberg
Ericsson Finland

Regards,

Christer Holmberg
Ericsson Finland

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Apr 2003 18:45:42 -0400

Christer,

I don't know for sure what Jonathan intended, but it isn't necessary to 
have actual wildcarding for this to work. All that is needed is 
agreement on a part of the returned URI that may be filled in arbitrary 
values without altering how requests are routed.

Two ways that come to mind that seem suitable are:

- when proxy/registrar constructs GRUU, it uses a URL parameter to 
indicate it is a GRUU and to carry all required context. The username is 
left empty. The proxy ignores the username field of the URL when routing 
a request URL containing the GRUU parameter. So the endpoint can 
construct URLs from the GRUU, using whatever it wants in the username field.

- we standardize a URL parameter that the proxy/registrar guarantees to 
ignore when routing GRUUs. The proxy probably uses the username portion 
to encode its own context. The endpoint can construct URLS from this 
GRUU by adding a GRUU parameter containing whatever it wants.

I like the first of these better than the second. The registering device 
would get back a GRUU something like:

	<sip:example.com;gruu="cookie-user-1.2.3.4">

and then it could use addresses like:

	<sip:[email-masked];gruu="cookie-user-1.2.3.4">

Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Apr 2003 02:40:57 -0400

> itself, just some of the technical details.

I appreciate the comments, but I think its way to early to worry about 
technical details of the sort you are pointing out. We can figure out 
the right syntax for wildcarding (perhaps along the lines of what Paul 
suggested). ITs the concept thats important. In fact, it is far more 
important at this point to discuss whether or not people think this is 
an important problem, and also whether or not they like the embedded 
route header or lease approaches.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Apr 2003 14:42:13 +0300

Hi,

> >Some initial comments. In general, I don't have any major comments on the >solution

I agree with what you say. I just thought I'd bring the issue up, in case the
wildcarding would be an essentintial part of your proposed solution. But, as Paul said,
it MAY not be needed in the first place...

Some functional comments, though:

To make this work, it is assumed that requests sent in the backward direction really
will be directed via the proxy which issued the leased URI (unless the proxy is able to
"share" the information with other proxies). So, won't we have the same problem with the
Record-Route URI that you now try to solve for the Contact URI - ie we want to make sure
that requests reach a specific node, and not just any node within a specific user
domain?

Regards,

Christer Holmberg
Ericsson Finland

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Apr 2003 02:04:29 -0400

inline.

Christer Holmberg wrote:

> To make this work, it is assumed that requests sent in the backward
> direction really will be directed via the proxy which issued the
> leased URI (unless the proxy is able to "share" the information with
> other proxies). So, won't we have the same problem with the 
> Record-Route URI that you now try to solve for the Contact URI - ie
> we want to make sure that requests reach a specific node, and not
> just any node within a specific user domain?

No.

Just because I ask a specific server for a URI that is routable in the 
domain, does not meant that requests have to go to that specific server. 
  It is a requirement on the administrator of the domain to guarantee 
that the URI will route to the UA instance when used by anyone from 
anywhere. This will frequently require coordinated routing policies 
throughout the domain. Thats fine. Thats why you need to ask for the 
name - to make sure what you get is consistent with those routing policies.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Apr 2003 17:26:00 +0300

Hi,

> name - to make sure what you get is consistent with those routing policies.

Ok, but assume that proxy A still wants a request to be sent via it. Now, it
can do so by inserting its IP address in the Record-Route URI, but aren't the
problems them the same as if the UA would insert its IP address in the Contact?

My question basically is: should it only be possible for UAs to obtain a GRUU,
or should it also be possible for proxies?

I know your draft only talks about UAs, so proxies may be out of the scope of
it, but I would still like to raise the question.

Regards,

Christer Holmberg
Ericsson Finland