Subject: [Sip] What is going on with GRUU?

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 21 Feb 2006 23:05:21 -0500

I am revising my I-D on implementing GRUU in UAs, and I'd like to make
sure that I'm up to date on various details.  Can people fill me in on
the following?

The last revision I see of draft-ietf-sip-gruu is 06, submitted on
2005-10-21.  Is there an 07 revision in the works?

Has the "edge router" problem been brought to a satisfactory conclusion?
Or at least from the UA's point of view, can I assume that the routers
will take care of the problem, so that the UAs don't have to make
explicit accommodations for the edge router problem?

I personally prefer that the Supported and Require headers describe only
properties of the UAs, and not properties of the messages per se.
(Although that a UA conforms to an extension may imply something about
all messages it handles.)  draft-ietf-sip-gruu-06 uses these headers to
mark properties of messages, in that a UA must apply "Supported: gruu"
to some requests and not to others.  But I heard a considerable amount
of support on the mailing lists for my attitude.  Does draft-ietf-sip-
gruu-06 still express the consensus of the WG?

Thanks for any information,

Dale

_______________________________________________
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, 22 Feb 2006 00:43:21 -0500

> 2005-10-21.  Is there an 07 revision in the works?

Indeed it is. At the last meeting, we had a group of volunteers meet to 
try and come to conclusion on the whole 
sip-outbound/gruu/route-construct mess that seemed all intertwined 
again. No conclusion was reached there. We had some mail threads shortly 
thereafter, which died down without conclusion. These fired up again a 
few weeks back. There has been some progress, in that at least amongst 
the subset of those still posting on the thread, there has been 
agreement on a general path forward. This would impact gruu-07 and 
sip-outbound, and also route-construct which I will be submitting as a 
wg doc per consensus from last ietf.

> explicit accommodations for the edge router problem?

With the solution we've come up with, yes. The basic idea is that the 
home proxy fixes this up. It does that by, in a mid-dialog request, 
rewriting the r-uri (which will contain the gruu) to the registered 
contact. This has the dual-effect of eliminating the spiraling, while 
preserving the record-routes for usage in all mid-dialog requests. The 
endpoint behavior is unchanged - clients include gruu in their contact, 
thats it. No endpoint record-routing (though I like this idea still, I 
think its premature to couple the entire solution to this significant 
change - its still something we can do later). Edge proxies don't do 
anything special either - just record-routing as normal.

> gruu-06 still express the consensus of the WG?

With the above solution, there is no requirement for the home proxy to 
know whether the contents of the contact are a gruu. As such, the spec 
will relax this constraint around usage in the contact and Supported: gruu.

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

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 22 Feb 2006 22:44:46 -0500

> will relax this constraint around usage in the contact and Supported: gruu.

-06 also prescribes particular usage of Supported and Require in regard
to REGISTER requests, whereas I would take an approach more like this:

+ If a registrar is compliant with this feature, if a contact address has 
+ a +sip.instance field-parameter, the registrar will return it in its response
+ with an appropriate gruu field-parameter.

That is, the presence or absence of Supported/Require would not regulate
GRUU issuing, only the presence of +sip.instance.  This approach would
be non-upward-compatible to some degree, in that if a non-GRUU-aware UA
happens to apply +sip.instance to a contact, the response to the
REGISTER will have a gruu applied to it, which presumably it does not
understand.  (I would argue that any UA should be prepared to ignore
field-parameters that it does not understand.)  On the other hand, this
approach would retain the "pure" interpretation of Supported/Require.

Dale