Subject: Re: [Sip] updated GRUU spec

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Oct 2005 11:38:04 -0400

sorry for the delay. More inline.

Jeroen van Bemmel wrote:

> Jonathan,
> 
> Not sure if this has been discussed already, but currently the draft 
> states that in order to determine if the remote target is a GRUU, the UA 
> must look for a 'Supported: gruu' header.

Right.

> 
> Wouldn't it make sense to make this property explicit in the URI itself, 
> e.g. by requiring that a GRUU MUST contain a 'gruu' parameter flag?
> This would address the requirement that "A server in the domain can 
> determine that the URI is a GRUU" (section 6), in fact it would allow 
> any entity to determine that the URI is a GRUU.

We have in fact discussed this a few times. As a general rule, its 
preferable to not include information in the URI itself which describes 
the properties of the resource to which the URI points.

> 
> This would help a UA in all use cases  (4.1 (REFER) for the Refer-To 
> URI, 4.2 for the conference URI, and 4.3 for the Contact information in 
> PIDF) to determine that the URI is in fact a GRUU. I think putting it as 
> a URI parameter may also have benefits in authentication scenario's (it 
> would be included in the digest calculation).

In all of these cases, I don't think the recipient of the URI would do 
anything differently if it knew it was a gruu, as opposed to if it 
didnt. A GRUU is just a URI that has the property that URIs in Refer-To, 
contact and PIDF need to have in order to work right anyway. To date, we 
havent had a way to produce those URI reliably. Now we do.

> 
> Putting it as a question: is REQ 8 broad enough to cover all use cases? 
> Wouldn't "to know that the URI represents a GRUU" also be required 
> outside of a dialog, e.g. when obtaining the URI from a PIDF document?

Actually, if anything, I'd argue that it really ought not be necesary to 
know its a gruu to use it, and thus the requirement is more than we need.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Oct 2005 11:43:44 -0400

inline.

Jin, Haipeng wrote:

> Hi,
> 
> I have a question regarding record-routing treatment in paragraph 2 on
> page 24, quoted as follows.
> 
> 	Similarly, if a request arrives from the client towards the home
>    proxy, the edge proxy would look at the identity of the sender of the
>    request.  If the proxy knows that it is placing itself on the Path
>    for registrations from that AOR, and the request contains a Supported
>    header field with the value "gruu", the edge proxy would insert a
>    Record-Route into the request, and then remove it in the response.
>    Similarly, if the identity of the sender of the request is one for
>    which the client has not put itself on the Path, the edge proxy would
>    keep its Record-Route in the response.
> 
> I guess you really mean:
> 	Similarly, if a request arrives from the client towards the home
> proxy, the edge proxy would look at the the identity of the sender of
> the request. If the proxy knows that it is placing itself on the Path
> for registrations from that AOR, and the request contains a Supported
> header field with the value "gruu", the edge proxy would NOT insert a
> Record-Route into the request but WOULD INSERT it in the response.
> Similarly, if the identity of the sender of the request is one for which
> the PROXY has not put itself on the Path, the edge proxy would INSERT
> Record-Route IN THE REQUEST and keep it in the response.
> 
> The changes are marked in capital letter. I think this is the proxy
> behavior to make sure that the client will have a route set entry for
> its edge proxy, but the remote client will not.

I think its right as written. The idea is that, if the proxy had put 
itself into the Path, then it will already be in the signaling chain for 
mid-dialog requests towards the client. Thus, it shouldn't be in the 
record-route set that is used to reach the client. That is the 
record-route set used by the other side. Thus, the record-route needs to 
be removed from the response.

Thanks,
Jonathan R.