Subject: RE: [Sip] GRUU and Grid alternative

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Sep 2006 09:09:02 +0100

Yes, and it would also make RFC 4458 (Voicemail-URI) applicable in more
situations (without needing to rely on RFC 4244 (History-Info)), it would
make RFC 4244 more usable, and it would also help with the problem Alan
Johnstone is trying to address in his cc-uui draft in SIPPING. Of course,
the existing deployed base will be a problem for some of these applications.

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 27 September 2006 06:50
> To: IETF SIP List
> Subject: [Sip] GRUU and Grid alternative
> 
> During our call on GRUU last week, there was a discussion on 
> this issue 
> that ekr raised, where he would like to see the grid usable 
> outside of 
> just gruu, i.e., with any AOR.
> 
> During the call, I made a suggestion for an alternative solution, and 
> there was agreement amongst those on the call for the 
> proposed approach.
> 
> The basic idea would be to remove the grid mechanism entirely 
> from the 
> gruu draft. Instead, a separate specification would be 
> developed which 
> would allow for loose routing to apply to user agents. So, 
> consider a UA 
> which registers. It would include a contact and a Supported 
> header field 
> with the value "ua-route". The registrar, assuming it 
> understands this, 
> notes that the UA supports UA loose routing and stores the 
> contact. When 
> an incoming call arrives for the AOR, rather than rewriting the R-URI 
> with the registered contact, it pushes the registered contact into a 
> Route header and leaves the R-URI alone (assuming the registered UA 
> supports this mechanism).
> 
> How does this solve the grid problem? Lets say my AOR is 
> sip:[email-masked]. I, as a UA, can mint a URI with some arbitrary 
> parameter, say sip:[email-masked];foo=baz, and hand it out to some 
> correspondent. When a correspondent sends a request to that URI, it 
> arrives at my home proxy. From there, since the R-URI is NOT 
> rewritten, 
> the entire URI, parameters and all, is passed to the UA. Thus, the UA 
> knows the URI that was de-referenced. We wouldn't necessarily have to 
> standardize a specific URI parameter, like grid, to carry the 
> opaque data.
> 
> This trick solves a whole bunch of other problems too. It would 
> eliminate the need for the IMS P-Called-Party-ID header field, and it 
> would help clarify when a request is retargeted (change in R-URI) vs. 
> when its just being delivered to the recipient (no change in R-URI).
> 
> Comments?
> 
> -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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Wed, 27 Sep 2006 15:15:12 -0400

Elwell, John wrote:

> Johnstone is trying to address in his cc-uui draft in SIPPING.

Right. This is exactly why its a generalization of grid; its a more 
general solution for the problem of conveying information to users.

-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

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 27 Sep 2006 17:14:39 -0500

I am liking this idea a lot. It will also help with RFC 4240.

It will certainly be much more understandable, and solves many problems 
at one.

I'm assuming that Jonathan would take the action of removing grid from
GRUU
and generating the draft with the proposal? 

> Sent: Wednesday, September 27, 2006 12:15 PM
> To: Elwell, John
> Cc: IETF SIP List; Alan Johnston
> Subject: Re: [Sip] GRUU and Grid alternative
> 
> 
> 
> Elwell, John wrote:
> 
> > Yes, and it would also make RFC 4458 (Voicemail-URI) applicable in 
> > more situations (without needing to rely on RFC 4244 
> (History-Info)), 
> > it would make RFC 4244 more usable, and it would also help with the 
> > problem Alan Johnstone is trying to address in his cc-uui 
> draft in SIPPING.
> 
> Right. This is exactly why its a generalization of grid; its 
> a more general solution for the problem of conveying 
> information to users.
> 
> -Jonathan R.
> 
> 
> -- 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Sep 2006 18:40:27 -0400

I liked this when it was previously suggested, for reasons unrelated to 
gruu. It does feel like this is the way 3261 should have done things.

BUT, its going to present some compatibility problems for proxies that 
don't expect to encounter Route headers in some contexts. That is 
non-compliant but its out there. In particular, IMS P-CSCFs aren't going 
to be at all happy routing a request outbound to an UE in this way.

Its especially a problem because a UA that requests a GRUU and wants to 
use it is dealing with the the home proxy, and has no good way to even 
understand if an edge proxy is going to present problems. I guess we 
could invent a new option tag and use Proxy-Require to test for it. But 
when the UA discovers its edge proxy is a problem, what does it do?

One option is to simply have no mercy on non-compliant proxies. But if 
it is a big enough problem we may need to seek another solution. (One 
isn't leaping to mind for me.)

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 27 Sep 2006 19:32:03 -0500

> BUT, its going to present some compatibility problems for 
> proxies that don't expect to encounter Route headers in some 
> contexts. That is non-compliant but its out there. In 
> particular, IMS P-CSCFs aren't going to be at all happy 
> routing a request outbound to an UE in this way.

Hi Paul,

Can you describe this in IETF terms for those of us who are
not IMS-conversant?

What is the problem with these proxies and Route headers, and when?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Sep 2006 22:53:26 -0400

> I am liking this idea a lot. It will also help with RFC 4240.

Yes.

> and generating the draft with the proposal? 

Yes and yes.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Sep 2006 09:56:05 -0400

Francois,

I may have spoken too soon. I went back and looked at the relevant IMS 
spec, and it looks like things may be ok there. At the relevant point it 
simply calls for following 3261, and while it certainly doesn't seem to 
anticipate there being route headers in this case it should probably be 
ok. I only looked at a recent version of the IMS specs, not older ones 
that have been deployed, but there is at least a chance that things will 
be ok.

My concern was that IMS does a bunch of stuff to save and verify the 
contents of Vias, Route headers, etc. And it also sometimes uses the 
saved stuff to initiate a BYE message from the middle. (Transitioning 
from being a proxy to a B2BUA. Ugh!) This change could have messed that 
logic up, but it looks like it may squeak through. (Perhaps by dumb luck.)

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 28 Sep 2006 12:00:30 -0500

Excellent. 

Thanks. 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, September 28, 2006 6:56 AM
> To: Audet, Francois (SC100:3055)
> Cc: IETF SIP List
> I may have spoken too soon. I went back and looked at the 
> relevant IMS spec, and it looks like things may be ok there. 
> At the relevant point it simply calls for following 3261, and 
> while it certainly doesn't seem to anticipate there being 
> route headers in this case it should probably be ok. I only 
> looked at a recent version of the IMS specs, not older ones 
> that have been deployed, but there is at least a chance that 
> things will be ok.
> 
> My concern was that IMS does a bunch of stuff to save and 
> verify the contents of Vias, Route headers, etc. And it also 
> sometimes uses the saved stuff to initiate a BYE message from 
> the middle. (Transitioning from being a proxy to a B2BUA. 
> Ugh!) This change could have messed that logic up, but it 
> looks like it may squeak through. (Perhaps by dumb luck.)
> 
> 	Paul
> 
> Francois Audet wrote:
> >  
> >> BUT, its going to present some compatibility problems for proxies 
> >> that don't expect to encounter Route headers in some 
> contexts. That 
> >> is non-compliant but its out there. In particular, IMS 
> P-CSCFs aren't 
> >> going to be at all happy routing a request outbound to an 
> UE in this 
> >> way.
> > 
> > Hi Paul,
> > 
> > Can you describe this in IETF terms for those of us who are not 
> > IMS-conversant?
> >