Subject: [Sip] draft-ietf-sip-gruu-10 comments

From: Cullen Jennings <[email-masked]>
Date: Sat, 9 Sep 2006 13:02:15 -0500

One significant issue...

Would you agree to put in the security section that any UA that is  
sending a request where it has set the From header field value to  
Anonymous MUST not use a GRUU that does not have the anonymous  
property? I suspect the answer to this will be yes - I'm still trying  
to think about the implications of this and trade offs.

Few smaller things:

Section 8.1.1. para 4. I really can't figure out what this says - I  
suspect that I know what is trying to say but when I try to parse the  
paragraph, my stack overflows. Sorry for such a useless comment - I'm  
not exactly sure how to improve it.

Section 8.2.1 para 2, last sentence. I think the term "unknown" is  
not what we want here. Often the device will not be registered, (say  
it is powered off), but the device id will be "known" to the domain  
as it created the GRUU in the past, it still have provisioning  
information for this device etc. It seems like we might want  
something more like "not registered" instead of unknown

Section 8.2.2

I think I am likely confused here. I basically don't see why a simple  
classic sip trapezoid deployment would ever need to Record Route. The  
fact that the GRUU refereed to the "home" domain would cause it work  
get back here. As a side note, I find the terms "home", "edge" etc  
very undefined outside the IMS context. Anyways, I believe this  
section might be all right but I am failing to understand what needs  
to be done and why. If I was a non IMS proxy implementer, I suspect I  
would just ignore this whole section.

Section 8.2.3 - This is probably just my missing something in reading  
this but I did not see how the procession of mid dialog requests was  
different that than 8.2.1. Can we delete this section.

Cullen (with my individual hat on)

_______________________________________________
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: <[email-masked]>
Date: Mon, 11 Sep 2006 09:51:06 +0300

Hi,

While reading through gruu-10, I had quite much the same trouble

>not exactly sure how to improve it.

I think Cullen is right here. The paragraph is difficult to understand
as a whole, it is missing the rationale and has some quite obscure
statements like:

   Barring dynamic mechanisms to discover an outbound proxy, such a
   relationship needs to be configured into the UA.

What is that supposed to mean ?

>would just ignore this whole section.

All this was added to gruu-10, but I was unable to find the rationale
from the draft or the mailing list. I assumed that the GRUU itself would
contain a hostname referring to the domain which has created the
GRUU. Thus all the requests targetted to the GRUU would after all 
be routed to that domain, whether or not that domain is otherwise
included to the Route (via Record-Route). But is this a false assumption
?

So what is the rationale behind the processing described in Section
8.1.1 paragraph 4 and Section 8.2.2 ?

- Would routing towards such a GRUU for some reason fail if the request
  did not visit the domain from which the GRUU was obtained ? If yes,
  why ? 

- Or is it just an optimization to avoid the dialog to be routed at
  first to the outbound proxy which finally resolves the GRUU, just
  to find out that the request must for its final delivery be forwarded 
  to the domain from which the GRUU was obtained ? 

- Or something else ?

If this processing is needed, the draft has at least to provide
a rationale for it, so that the story becomes understandable.

Regards,

Erkki
____________________________________

  Erkki Koivusalo
  Nokia Mobile Software
  tel:+358 40 7571197
  mailto:[email-masked]
____________________________________

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Sep 2006 15:21:48 -0400

Cullen Jennings wrote:

> fact that the GRUU refereed to the "home" domain would cause it work get 
> back here. As a side note, I find the terms "home", "edge" etc very 
> undefined outside the IMS context. Anyways, I believe this section might 
> be all right but I am failing to understand what needs to be done and 
> why. If I was a non IMS proxy implementer, I suspect I would just ignore 
> this whole section.

*If* the topology is a simple trapezoid then I think you are correct.

But if there is a proxy before the originating home proxy, or after the 
terminating home proxy, then the R-R is needed to prevent a spiral.

On the originating side, this can be determined by whether there is a 
R-R present when the request arrives at the originating home proxy. On 
the terminating side that doesn't work, because the potential R-R hasn't 
happened yet, and you can't know in advance if it will happen.

So the problem is that you don't need it in a trapezoid, but you don't 
know if you have a trapezoid.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 14 Sep 2006 17:33:32 -0700

On Sep 11, 2006, at 12:21 PM, Paul Kyzivat wrote:

>
>
> Cullen Jennings wrote:
>
>> Section 8.2.2
>> I think I am likely confused here. I basically don't see why a  
>> simple classic sip trapezoid deployment would ever need to Record  
>> Route. The fact that the GRUU refereed to the "home" domain would  
>> cause it work get back here. As a side note, I find the terms  
>> "home", "edge" etc very undefined outside the IMS context.  
>> Anyways, I believe this section might be all right but I am  
>> failing to understand what needs to be done and why. If I was a  
>> non IMS proxy implementer, I suspect I would just ignore this  
>> whole section.
>
> But if there is a proxy before the originating home proxy, or after  
> the terminating home proxy, then the R-R is needed to prevent a  
> spiral.
>
> On the originating side, this can be determined by whether there is  
> a R-R present when the request arrives at the originating home  
> proxy. On the terminating side that doesn't work, because the  
> potential R-R hasn't happened yet, and you can't know in advance if  
> it will happen.
>
> So the problem is that you don't need it in a trapezoid, but you  
> don't know if you have a trapezoid.
>

But on the terminating side, it seems like the home proxy know there  
is another proxy because it needs to insert that into the route

(I don't spend enough time thinking about this so I assume you are  
right, just trying to make sure I understand)

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Sep 2006 16:42:13 -0400

comment at end.

	Paul

Cullen Jennings wrote:
>> the terminating home proxy, then the R-R is needed to prevent a spiral.
>>
>> the terminating side that doesn't work, because the potential R-R 
>> hasn't happened yet, and you can't know in advance if it will happen.
>>
> But on the terminating side, it seems like the home proxy know there is 
> another proxy because it needs to insert that into the route
> 

Well, the terminating home proxy will know if it is including another 
proxy after it. But it doesn't know if that proxy, or some other proxy 
*it* includes, will R-R.

And even if the home proxy isn't inserting a proxy (e.g. no Path header 
registered), it doesn't really know if the contact that was registered 
is the actual destination, or whether it identifies another proxy.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 17 Sep 2006 22:51:04 -0700

On Sep 15, 2006, at 1:42 PM, Paul Kyzivat wrote:

>>>> simple classic sip trapezoid deployment would ever need to  
>>>> Record Route. The fact that the GRUU refereed to the "home"  
>>>> domain would cause it work get back here. As a side note, I find  
>>>> the terms "home", "edge" etc very undefined outside the IMS  
>>>> context. Anyways, I believe this section might be all right but  
>>>> I am failing to understand what needs to be done and why. If I  
>>>> was a non IMS proxy implementer, I suspect I would just ignore  
>>>> this whole section.
>>>
>>> But if there is a proxy before the originating home proxy, or  
>>> after the terminating home proxy, then the R-R is needed to  
>>> prevent a spiral.
>>>
>>> On the originating side, this can be determined by whether there  
>>> is a R-R present when the request arrives at the originating home  
>>> potential R-R hasn't happened yet, and you can't know in advance  
>>> if it will happen.
>>>
>> But on the terminating side, it seems like the home proxy know  
>> there is another proxy because it needs to insert that into the route
> Well, the terminating home proxy will know if it is including  
> another proxy after it. But it doesn't know if that proxy, or some  
> other proxy *it* includes, will R-R.
>
> And even if the home proxy isn't inserting a proxy (e.g. no Path  
> header registered), it doesn't really know if the contact that was  
> registered is the actual destination, or whether it identifies  
> another proxy.

Ok, but that seems like the advice should be "if you are using the  
path stuff (or the broken 3rd party registrations) to include another  
proxy, then you must R-R".  Making everyone R-R for no good reason  
just seems like a complicated wasted and will slow down systems that  
don't need it.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Sep 2006 08:55:48 -0400

Cullen Jennings wrote:
>>>>> "home", "edge" etc very undefined outside the IMS context. Anyways, 
>>>>> I believe this section might be all right but I am failing to 
>>>>> understand what needs to be done and why. If I was a non IMS proxy 
>>>>> implementer, I suspect I would just ignore this whole section.
>>>>
>> registered is the actual destination, or whether it identifies another 
>> proxy.
> 
> Ok, but that seems like the advice should be "if you are using the path 
> stuff (or the broken 3rd party registrations) to include another proxy, 
> then you must R-R". 

Who is "you"?

The entity doing the R-R is the home proxy. The entity initiating the 
registration is something else.

The home proxy knows nothing about the characteristics of the address 
being registered other than what it can tell by examination of the URI 
itself, which isn't helpful.

The entity requesting the registration may often know that it is 
registering its own address and so it one hop away. But if it is doing a 
3rd party registration then it may well not know one way or the other.

So, at best I think we can try to exploit affirmative statements that 
there are no intervening hops. We have begin to identify cases where we 
make this assumption - notable sip-outbound. So I guess the question is 
whether we should *require* that contacts registered for GRUUs be the 
address of a UA and not a proxy, in order that the home proxy can know 
it doesn't need to R-R.

It gives me heartburn to impose restrictions like this. One of the 
powers of SIP is that you don't need to know whether a SIP URI denotes a 
UI or proxy when using it.

> Making everyone R-R for no good reason just seems 
> like a complicated wasted and will slow down systems that don't need it.

Well, if you omit the R-R because you know requests will be routed to 
you anyway, then no hops are being saved by omitting the R-R.

But it may save something: if you traverse the trapezoid for 
out-of-dialog requests, are using gruus at both ends, but don't R-R, 
then in-dialog requests will each traverse only *one* of the proxies. If 
both proxies R-R, then mid-dialog requests will traverse both.

Whether that works out in practice, and if so whether it is an 
improvement, is an open question.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Sep 2006 09:57:45 -0400

My view on this is that, with GRUU, the home proxy in the terminating 
domain is going to get visited ANYWAY, even with just a trapezoid. So 
there is no penalty to record-routing, besides perhaps the overhead in 
the sip message for the extra bytes. Thus it seems simpler to say that 
you should always do it.

It is a fair point that in mixed mode deployments where not all 
endpoints in a domain support gruu, the record-route would not be needed 
and would introduce an extra hop. I think it would be OK to say that if 
the registered contact was assigned a gruu, then the home proxy has to 
record-route. Would that be OK?

-Jonathan R.

Cullen Jennings wrote:

>> proxy after it. But it doesn't know if that proxy, or some  other 
>> proxy *it* includes, will R-R.
>>
> then you must R-R".  Making everyone R-R for no good reason  just seems 

-- 
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