Subject: RE: [Sip] GRUU and Mid-Dialog Requests

From: "Xavier Marjou" <[email-masked]>
Date: Fri, 01 Sep 2006 09:35:57 +0200

> Well, that is a separate discussion. For the moment we can discuss 
> what you are proposing with the understanding that it assumes the To 
> URI can be changed in the response.

I agree

> You don't show it, but I am assuming that (5) and (6) have
> To: Callee <sip:[email-masked]
> and that it is changed by the callee for message 7. Is that right?

Yes

> And then Caller is expected to consider the To URI in the response to be
> both the "connected party" and device-specific URI for future requests?

Yes

> In that case, the caller will need some rules for how to use that To-URI.
> What if it wants to present the identity to its user, or save it in a 
> call log for future callback? Does it strip off the opaque parameter?

Indeed, this behavior would need to be described. I don't see any issue to 
save it in a call-log (same case as a URI with a ;user=phone parameter).
I agree there would be an issue with the presentation of the identity if we 
want to also display the instance of the called party to the caller (the 
opaque parameter is, of course, not suited to be displayed in a GUI). 
Nevertheless, this does not make part of the use-cases.

> Assuming that caller also has a gruu, wouldn't it then need to use that
> as the From-URI in (5) and (7).

Yes he probably could do so if he has also successfully registered its GRUU 
AOR.

> I think this proposal mixes up a lot of different things.

Yes: as soon as an important modification happens, different derived 
problems can arise.

_______________________________________________
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: Mon, 11 Sep 2006 08:59:47 -0400

Sorry for jumping in late here. IETF cycles have been dominated by ICE 
work for me.

Firstly, as a bit of history, the main reason we place the GRUU in the 
Contact was that it allowed for interoperability as long as only one 
side - the agent which obtained the GRUU - supported it. As Dale pointed 
out, many implementations today take the contact header field learned 
from a peer, and use it as a target for new requests for features such 
as transfer. This is because the Contact, as defined by RFC 3261, is 
supposed to point to a specific UA instance and indeed is supposed to be 
globally routable too.

The problem we're having is, in reality, it has proven very hard for a 
UA to populate the Contact header field with a URI that is globally 
routable and which points to that specific instance. So, the GRUU spec 
provides a way for a URI to get a URI which meets the properties that 
RFC 3261 requires.

I understand your proposal, Xavier, and its not unreasonable. However, 
the problem is that it will not work with the existing implementations 
which are already assuming the Contact header field as the place to go 
for new requests for features like transfer. Thus, putting the GRUU 
anywhere else, whether its an updated To header field or a new header 
field, won't work.

Indeed, the essence of your proposal is to redefine the To, From and 
Contact semantics such that:

* Contact is a non-global URI for reaching an instance for mid-dialog 
requests only
* To and From are AOR for the initial requests in a dialog, and for 
mid-dialog requests, are modified to have both the identity and GRUU 
properties

This is a not-unreasonable proposal, its just going to not interoperate 
with anything which has assumed these header fields have the properties 
defined in 3261.

Thanks,
Jonathan R.

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