Subject: [Sipping] Comment on GRUU requirements

From: Adam Roach <[email-masked]>
Date: Thu, 24 Jul 2003 12:06:04 -0500

While thinking about some of the applications for which
GRUUs would be useful, it occurred to me that many of
them work (or at least, work better) if a GRUU can be
identified as such by simple examination.

For example, let's say I send an INVITE message and
receive a 200 response containing:

  Contact: <sip:ABC.dskia99s8a77dll=[email-masked]>

If I want to be able to send an out-of-dialog request that
I want to go to the same device that my INVITE went to,
I don't know whether I can do so. On the other hand, if
I can look for a URI parameter that indicates that the
URI has GRUU properties:

  Contact: <sip:ABC.dskia99s8a77dll=[email-masked];gruu>

...then I *know* that sending a request to it will arrive
at the appropriate device, even if it's not in the same
dialog.

I would like to see a requirement added along the lines
of:

  REQ xx: It must be possible for any recipient of a URI
  to determine by examination whether it is a GRUU.

/a

_______________________________________________
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: Tue, 29 Jul 2003 13:32:31 -0400

Two points to make here:

First, I am not sure that we actually want to place the GRUU in the 
contact header field. If we do that, we end up with double record 
routing and the elimination of end-to-end signaling once the call is 
set up. What I mean by double record-routing is this. Lets say A calls 
B. B's proxy record-routes. The INVITE gets to B. B inserts a GRUU in 
the Contact in the 200 OK. Now, when A does a re-INVITE, it goes to 
B's proxy (due to the record-route), and then AGAIN to a proxy 
(possibly a different one) because of the GRUU in the r-uri.

I think we need to think of a GRUU as an AOR, its just that its an AOR 
that routes to a specific device instance. Contact header field should 
be used as its currently used - the URI to reach this device within 
the context of this dialog.

Secondly, that said, I do agree we need to hand out GRUUs. I don't 
think its a URI parameter. I think that it would be contextual. We 
definitely need to be able to hand them out between peers in a dialog, 
in which case a new header could be used to carry them. They could 
also be embedded in web pages, in which case the context is the 
surrounding anchor text, meant for human consumption.

To facilitate further discussion, I've written up a brief requirements 
document on GRUU. I added some requrements to distribute GRUUs between 
peers in a dialog. Until it appears in the archives, you can pick it 
up at:

http://www.jdrosen.net/papers/draft-ietf-sipping-gruu-reqs-00.txt
http://www.jdrosen.net/papers/draft-ietf-sipping-gruu-reqs-00.html

Thanks,
Jonathan R.

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

---

From: Alan Johnston <[email-masked]>
Date: Tue, 29 Jul 2003 13:23:02 -0500

At 01:32 PM 7/29/2003 -0400, Jonathan Rosenberg wrote:
>contact header field. If we do that, we end up with double record routing 
>and the elimination of end-to-end signaling once the call is set up. What 
>I mean by double record-routing is this. Lets say A calls B. B's proxy 
>record-routes. The INVITE gets to B. B inserts a GRUU in the Contact in 
>the 200 OK. Now, when A does a re-INVITE, it goes to B's proxy (due to the 
>record-route), and then AGAIN to a proxy (possibly a different one) 
>because of the GRUU in the r-uri.

If we do not use a GRUU in a Contact, then it will not help solve the 
attended transfer problem or the conferencing application - both of these 
use the Contact URI.

If we are not trying to solve these cases, what cases are we trying to 
solve here?

Thanks,
Alan Johnston
MCI

(snip)