Subject: [Sip] Question on GRUU

From: "Darshan Bildikar" <[email-masked]>
Date: Thu, 26 Oct 2006 16:00:46 +0530

Quote from GRUU draft

"However, a UA compliant to this specification SHOULD use a GRUU when
populating the Contact header field of dialog-forming and target refresh
requests and responses.  In other words, a UA compliant to this
specification SHOULD use its GRUU as its remote target.  This includes the
INVITE request, its 2xx response, the SUBSCRIBE [6] request, its 2xx
response, the NOTIFY request, and the REFER [7] request, and its 2xx
response"

If a GRUU is to be used in a target refresh request, then should it not be
used in UPDATE too? Isn't UPDATE a target refresh request even though it
doesn't create a dialog?

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Oct 2006 09:23:25 -0400

> used in UPDATE too? Isn't UPDATE a target refresh request even though it

Once a dialog has been established following the above rules, with a 
gruu as the contact, it will normally be used in target refresh requests 
such as reINVITE and UPDATE when there is no intent to refresh the target.

Using a target refresh request to change the target has its own issues. 
I suppose a refresh could remove the gruu as the target and replace it 
with a non-gruu. If no gruu was used when the dialog was formed, it 
potentially could be replaced by a gruu as long as all conditions are 
met with the existing route set - notably the record-routing by the 
authoritative proxy. (Since the route set cannot be changed, if it 
doesn't contain the authoritative proxy you are out of luck in this 
regard.)

Changing from one gruu to a different gruu could conceivably work if 
existing route set covers them both. This would be the case for instance 
if they were both temporary gruus for the same instance id. (But then 
there would be little point in doing it.) If they were gruus for 
different instances with the same AOR, and there is a Path, then it 
would have to be the identical Path for both. This gets progressively 
more complex, and makes my head hurt.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Oct 2006 11:25:03 -0400

All of that said, I think the answer is 'yes' and that UPDATE needs to 
be added to the list.

-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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Oct 2006 11:27:41 -0400

Actually, its in -11 already. The text you are quoting is from -10.

-Jonathan R.

Jonathan Rosenberg wrote:

>> gruu as the contact, it will normally be used in target refresh 
>> requests such as reINVITE and UPDATE when there is no intent to 
>> refresh the target.
>>
>> Using a target refresh request to change the target has its own 
>> issues. I suppose a refresh could remove the gruu as the target and 
>> replace it with a non-gruu. If no gruu was used when the dialog was 
>> formed, it potentially could be replaced by a gruu as long as all 
>> conditions are met with the existing route set - notably the 
>> record-routing by the authoritative proxy. (Since the route set cannot 
>> be changed, if it doesn't contain the authoritative proxy you are out 
>> of luck in this regard.)
>>
>> existing route set covers them both. This would be the case for 
>> instance if they were both temporary gruus for the same instance id. 
>> (But then there would be little point in doing it.) If they were gruus 
>> for different instances with the same AOR, and there is a Path, then 
>> it would have to be the identical Path for both. This gets 
>> progressively more complex, and makes my head hurt.
>>
>>     Paul
>>