Subject: [Sip] Re: Questions on GRUU draft 06

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Jun 2006 14:05:20 -0400

My apologies for the very, very long delay in responding, but these are 
good questions here and they deserve to be answered. Responses inline.

Fredrik Thulin wrote:

> Hi
> 
> I have read draft-ietf-sip-gruu-06.txt, and implemented all the 
> applicable parts for my open source proxy (YXA).
> 
> Generally I must say that GRUUs are pretty straight forward, if you 
> don't have to deal with the edge proxy problem (I don't, because my 
> application serving as an edge proxy handles REGISTER itself without 
> forwarding it to a 'home proxy' (distributed location database)).
> 
> I have two questions which I really couldn't find an answer to myself :
> 
> 
> 8.4.1  Request Targeting :
> 
> 
>>If the Request URI is an
>>AOR against which there are multiple registered contacts with the
>>same instance ID parameter, the proxy MUST populate the target set so
>>that there is never more than one contact at a time with a given
>>instance ID.
> 
> 
> Does this means the GRUU specification updates how a proxy should handle 
> requests to non-GRUUs as well?

No - but sip-outbound does by specifying exactly this behavior.

> 
> If two GRUU capable user agents have registered with an AOR, gotten two 
> different GRUUs, and then a request arrives for the AoR (_not_ one of 
> the GRUUs), does this apply? This sounds a bit weird to me.
> 
> Maybe the scenario is about a request to a Request-URI which is a GRUU? 
> That is not perfectly clear to me at least.
> 
> 
> 7.1.2.1  Processing a REGISTER Request :
> 
> 
>>When generating the 200 (OK) response to the REGISTER request, the
>>procedures of step 8 of Section 10.3 of RFC 3261 are followed.
>>Furthermore, for each Contact header field value placed in the
>>response, if the registrar has stored an instance ID associated with
>>that contact, that instance ID is returned as a Contact header field
>>parameter. 
> 
> 
> Why is this needed? The user agent already knows which instance id it 
> supplied, so it can't be for the user agents benefit the proxy puts all 
> the instance ids in there.

In cases where more than one UA exists for a particular AOR, the 
instance ID in the register response allows the UA to find the contact 
(and expiration time) that it registered. Consider two UA, both behind 
NAT, each of which registers a SIP URI of sip:10.0.1.1. In such a case, 
the instance ID is the only thing in the register response that allows 
each UA to figure out what the expiration time for its contact is.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plo: Fredrik Thulin <[email-masked]>
Cc: [email-masked]
Subject: [Sip] Re: Questions on GRUU draft 06

My apologies for the very, very long delay in responding, but these are 
good questions here and they deserve to be answered. Responses inline.

Fredrik Thulin wrote:

> Hi
> 
> I have read draft-ietf-sip-gruu-06.txt, and implemented all the 
> applicable parts for my open source proxy (YXA).
> 
> Generally I must say that GRUUs are pretty straight forward, if you 
> don't have to deal with the edge proxy problem (I don't, because my 
> application serving as an edge proxy handles REGISTER itself without 
> forwarding it to a 'home proxy' (distributed location database)).
> 
> I have two questions which I really couldn't find an answer to myself :
> 
> 
> 8.4.1  Request Targeting :
> 
> 
>>If the Request URI is an
>>AOR against which there are multiple registered contacts with the
>>same instance ID parameter, the proxy MUST populate the target set so
>>that there is never more than one contact at a time with a given
>>instance ID.
> 
> 
> Does this means the GRUU specification updates how a proxy should handle 
> requests to non-GRUUs as well?

No - but sip-outbound does by specifying exactly this behavior.

> 
> If two GRUU capable user agents have registered with an AOR, gotten two 
> different GRUUs, and then a request arrives for the AoR (_not_ one of 
> the GRUUs), does this apply? This sounds a bit weird to me.
> 
> Maybe the scenario is about a request to a Request-URI which is a GRUU? 
> That is not perfectly clear to me at least.
> 
> 
> 7.1.2.1  Processing a REGISTER Request :
> 
> 
>>When generating the 200 (OK) response to the REGISTER request, the
>>procedures of step 8 of Section 10.3 of RFC 3261 are followed.
>>Furthermore, for each Contact header field value placed in the
>>response, if the registrar has stored an instance ID associated with
>>that contact, that instance ID is returned as a Contact header field
>>parameter. 
> 
> 
> Why is this needed? The user agent already knows which instance id it 
> supplied, so it can't be for the user agents benefit the proxy puts all 
> the instance ids in there.

In cases where more than one UA exists for a particular AOR, the 
instance ID in the register response allows the UA to find the contact 
(and expiration time) that it registered. Consider two UA, both behind 
NAT, each of which registers a SIP URI of sip:10.0.1.1. In such a case, 
the instance ID is the only thing in the register response that allows 
each UA to figure out what the expiration time for its contact is.

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

aza
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