Subject: [Sip] GRUU and Mid-Dialog Requests

From: "Xavier Marjou" <[email-masked]>
Date: Thu, 10 Aug 2006 10:40:01 +0200

Here are my comments for the draft-ietf-sip-gruu-10.txt

One major comment is the following: when I read the uses-cases of section 
4, I derive the requirement that there must be a way to cause "initial" 
requests only to be sent to a specific UA instance. However, REQ 1 of 
section 11 implicitly requires it for both "initial" and "subsequent" 
requests? Why "subsequent" requests must also be sent to a specific UA 
instance? If not needed, this would remove some sections on Record-Routing 
(8.2.2) and the processing of subsequent requests (8.2.3). 

Other minor comments:

p11: in the properties that a GRUU must exhibit, add that the host part of 
the URI must be equal to the host of the registrar that owns the GRUU.

p19: replace "retain" by "copy" (I first understood by "retain" that the 
proxy would "screen" the grid and its value)

p22: add the motivation for mandating Record-Routing at the originating 
home proxy.

p23: "if there were no additional Route header field values ... any PATH 
values that were registered MUST be used". Why is this needed? On an 
initial request, an edge Proxy reached thanks to the Path header field had 
the opportunity to perform a Record-Route in order to be in the Route set 
in subsequent requests. As the previous sentence indicates that the 
remaining Route header for subsequent requests must no be touched, the Path 
does not have to be taken into account for subsequent requests.

p29: Record-Route is missing in 200 of INVITE

p31: idem for 200 of SUBSCRIBE

_______________________________________________
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, 10 Aug 2006 09:29:56 -0400

> (8.2.2) and the processing of subsequent requests (8.2.3). 

subsequent (in-dialog) requests are already sent to a specific UA 
instance by virtue of the Contact header and the Record-Route for the 
dialog. The point of GRUU is to allow out-of-dialog requests to target a 
"specific instance" in the same way that in-dialog requests do. No more, 
no less.

The behavior of subsequent requests when the dialog was established to a 
gruu target doesn't require so much specification because it is existing 
behavior. Its enough to guarantee that the changes introduced don't 
break things that were already working.

> the URI must be equal to the host of the registrar that owns the GRUU.

I don't agree that is a requirement. It could be a different host part 
that maps to the same IP, or a different host part that maps to a 
different IP but the same server, or it could map to a different server 
with access to the same location server.

	Paul