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

From: [email-masked]
Date: Tue, 22 Apr 2003 11:53:58 +0300

Hi,

I agree on the concept that a GRUU needs to be a name rather than a route.

I also have a wild idea to throw into this thread. In the message-sessions work, the MSRP relays have a very similar function to perform, namely getting a unique "end-point-ID" with the BIND request. What if we consider this to be another use case for leasing a GRUU? The only difference would be that the UA would basically be leasing an MSRP URI, and not a SIP URI.

Cheers,
Aki

 > -----Original Message-----
 > From: ext Jonathan Rosenberg [mailto:[email-masked]]
 > Sent: 16 April, 2003 10:18
 > To: sipping
 > Subject: [Sipping] Thoughts on GRUUs, URI leasing and embedded route
 > headers
 > 
 > 
 > 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-l
 > ease-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:p
 > roxy2.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
 > 
_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Apr 2003 02:08:06 -0400

[email-masked] wrote:
> I also have a wild idea to throw into this thread. In the
> message-sessions work, the MSRP relays have a very similar function
> to perform, namely getting a unique "end-point-ID" with the BIND
> request. What if we consider this to be another use case for leasing
> a GRUU? The only difference would be that the UA would basically be
> leasing an MSRP URI, and not a SIP URI.

Heh. Indeed, the idea for using a leasing concept to solve the GRUU 
problem arose out of my involvement in the message sessions stuff, so 
there is a relationship in that regard.

That said, its actually quite important that the leasing operation be 
combinable with registration, since this enables stateless construction 
of GRUU. That would mean that a unified leasing protocol would need to 
also be integrated with the existing SIP registration system. Thus, it 
is not as independent as you would like it to be. Simplicity would argue 
for adding the leasing operation as part of registration, and I'd rather 
do that than try and combine it with MSRP binding.

-Jonathan R.