Subject: Re: [Sip] updated GRUU spec

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Mar 2006 11:47:28 -0500

The header field is still supposed to be there, per rfc3261 on general 
usage of supported. I added a sentence to the section you cite making 
this clear.

-Jonathan R.

Karthik Kamaraj - NPD, Chennai wrote:

> Hi Jonathan,
>             Though you have removed description regarding "Supported" header
> with option tag "gruu" in section 8.1.1, the example call flow has
> "Supported" header. If this header is present in the call flow, then I think
> you have to add *a line* which describes this in the draft.
>  
> Please correct me if I am wrong.
> 
> Thanks,
> Karthik
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, March 10, 2006 4:24 AM
> To: IETF SIP List
> Subject: [Sip] updated GRUU spec
> 
> 
> I've submitted an update to the GRUU spec. Until it appears, you can 
> pick it up at:
> 
> http://www.jdrosen.net/papers/draft-ietf-sip-gruu-07.txt
> 
> There are some major changes in here. They are:
> 
> * removal of the instance contact parameter definition, which now lives 
> in sip-outbound. I think this was a huge improvement because of this; 
> gruu works much better now with the dependencies reversed
> 
> * elimination of the edge proxy record-route munging mess. In its place, 
> the home proxy will rewrite the r-uri of mid-dialog requests (which will 
> have the gruu) to equal the registered contact. This is simple to do, 
> eliminates the spiraling problem completely, and requires no complicated 
> procedures to detemrine when to apply it. UA's do not record-route. The 
> mechanism does not address HA and failover for mid-dialog requests (nor 
> does sip-outbound). We are pushing that off, since neither gruu nor 
> sip-outbound was targeted at meeting that as a requirement. This was the 
> conclusion a small group of us came to in some off-line discussions.
> 
> * addition of a "gruu" URI parameter, to flag a URI as being a gruu. I 
> have argued against this a lot up till now. However, seems I was in the 
> minority so in part this reflects group consensus. When reviewing though 
> the handling of the opaque parameter, it turned out things really fell 
> apart in depending on supported as a clue to gruu-ness. Really the root 
> need here is that we have a backwards compatibility issue; it would 
> probably not have been necessary to have a 'gruu' uri param if the 
> Contact URI had the gruu property all along. But the fact that it doesnt 
> is a big driver here. Thus, 'gruu' is similar to 'lr' - both are URI 
> flags meant to address this backwards compatibility issue.
> 
> * as a consequence of the point above, there is virtually no mention of 
> supported header field and its interactions with gruu
> 
> * Removed requirement for inserting Require in 200 OK to REGISTER; a
> UA doesnt HAVE to include gruu in contacts anymore (though its still
> SHOULD)
> 
> * removed bit about future specifications dealing with the fact that
> mid-dialog requests never go e2e, but always through proxies. No one
> is ever going to "fix" this.
> 
> * gruu mechanism doesn't require the sip-outbound mechanisms to be USED 
> with gruu; there is a normative spec dependency, which is different. 
> gruu requires sip-outbound to be used ONLY if you are trying to register 
> multiple contacts to the same instance, for this redundancy feature
> 
> 
> Assuming folks are happy with these changes, there are no open issues 
> I'm aware of.
> 
> 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

_______________________________________________
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