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

From: Milinski Alexander <[email-masked]>
Date: Thu, 17 Apr 2003 10:38:51 +0200

Though I have not followed the debate previously, I have a question as follows (and it seems to be independent of the solution chosen):
Consider the example of the call transfer: A calls B, and B wishes to transfer the call to C. Here we need a GRUU for A. However, unless A is a prophet, A will not know that B wishes to tranfer the call to C. So what would be A's motivation to use a GRUU? Is it proposed that GRUUs will (almost) ALWAYS be used in the future for outgoing calls? 
Regards,
Alexander

Alexander Milinski
Siemens

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, April 16, 2003 9:18 AM
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-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
_______________________________________________
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: Fri, 18 Apr 2003 02:46:08 -0400

Milinski Alexander wrote:
> Though I have not followed the debate previously, I have a question
> as follows (and it seems to be independent of the solution chosen): 
> Consider the example of the call transfer: A calls B, and B wishes to
> transfer the call to C. Here we need a GRUU for A. 

In this case, you don't need a GRUU. B would send a REFER in-dialog to 
A, with C's AOR. No GRUU needed.

The case where you do need it is assisted call transfer. There, A calls 
B. A then calls C. A wants to tranfer B to C. This requires A to have a 
GRUU for C, to send in a REFER to B.

> However, unless A
> is a prophet, A will not know that B wishes to tranfer the call to C.
> So what would be A's motivation to use a GRUU? Is it proposed that
> GRUUs will (almost) ALWAYS be used in the future for outgoing calls?

Your question is still a valid one in the context of the assisted call 
transfer case. How does A get the GRUU for C? I believe that the GRUU 
would need to be included as information associated with the dialog. I 
had originally thought that UAs would simply use a GRUU in the Contact 
header of the iNVITE/200 OK, but I think thats a bad idea now. Rather, 
we would need some kind of new header, like UA-Instance or something, 
that conveys this. So, if A calls C, A includes a UA-Instance header in 
their INVITE, and when C answers, C includes one in its 200 OK. You want 
to do it right away to support features like assisted call transfer, 
which will need it later on. You don't want to have to explicitly ask 
the other end for it.

-Jonathan R.