Re: [Sip] Review of draft-ietf-sip-gruu-12

[Jonathan Rosenberg <[e-mail]>]

Its not moot, this is pretty much orthogonal.

However, I believe it works just fine. Lets walk through a call flow.

Lets say you have a UA X that doesn't support GRUU. However it includes 
an instance ID in its registration. The UA has a contact sip:x-contact 
and the registrar assigns a GRUU sip:x-gruu. However, this gruu is not 
returned to UA X and UA X has no idea about GRUU. Some other entity 
using reg-event (say UA Y) learns this GRUU and sends a request there.

This request will have a R-URI of sip:x-gruu, and arrive at the home 
proxy in X's domain. THis proxy, following normal GRUU procedures, will 
replace the R-URI with the registered contact. Furthermore it will 
record-route if there were Path headers. In this case it didn't actually 
need to, but it will anyway. No big deal. Lets say there was one path 
header, sip:edge. So the home proxy puts a record-route in of 
sip:xs-proxy. This arrives at UA X looking like:

INVITE sip:x-contact
RR: edge
RR: sip:xs-proxy

which looks like any other invite would. Now X doesn't do GRUU so its 
contact in the 200 OK will be sip:x-contact:

SIP/2.0 200 OK
RR: sip:xs-proxy
RR: sip:edge
Contact: sip:x-contact

This arrives at UA Y. UA Y will construct its ACK (and all subsequent 
mid-dialog requests) as:

ACK sip:x-contact
Route: sip:xs-proxy, sip:edge

This arrives at the home proxy due to the route header. Since the r-uri 
does NOT contain a gruu, the r-uri is not rewritten and none of the gruu 
procedures in 6.1 of the GRUU spec apply. This gets sent to the edge 
proxy and then to the UA based on standard, normal, mid-dialog request 
routing techniques.

What won't work is that, since UA X doesn't support GRUU, once the call 
is set up to X, things like transfer won't work. But, thats OK, there 
won't be any expectation that it would since the Contact didn't contain 
a GRUU.

So, net/net is that I believe the current text works fine.

-Jonathan R.


Michael Procter wrote:

> To be honest, I don't know.  I noticed temp-gruu lifetime being
> discussed extensively during yesterday's session, but I don't recall
> anything relating to this being raised.
> 
> My concern is purely related to the idea of GRUUs being invented on
> behalf of devices that don't support GRUUs.  I hadn't realized that this
> was possible until I read this from Jonathan:
> 
> : However, we ran into an issue that a UA might register with an
> instance 
> : ID but not support GRUU, and then something is subscribed to reg-event
> 
> : and wants to learn its gruu. So you don't return the gruu to the UA,
> but 
> : you still need to generate the GRUU to deliver in reg-event.
> 
> I think that there are nasty behavioral problems if a gruu is
> distributed on behalf of a UA that doesn't support gruu.
> 
> So, my questions are now:
> 1) Can a registrar create and advertise a gruu for a UA that doesn't
> support gruu?
> 
> 2) If so, how do we arrange things so that the scenarios I've described
> before don't arise?
> 
> Michael
> 
> Paul Kyzivat wrote:
> 
>>Is this discussion moot at this time?
>>
>>	Paul
>>
>>Michael Procter wrote:
>>
>>>Paul Kyzivat wrote:
>>>
>>>>Michael,
>>>>
>>>>There are more cases for this. A fundamental problem is that saying
>>>>"Supported:gruu" says "I support the gruu option". Its at least a
> 
> bit
> 
>>>>weird to try to make it mean "I want you to assign gruus for the
>>>>contacts in this request."
>>>
>>>If a REGISTER message that includes 'Supported:gruu', means 'I
> 
> support
> 
>>>the GRUU option', then I don't think it is particularly weird to
> 
> read in
> 
>>>the additional meaning 'and if you also support GRUUs, please
> 
> perform
> 
>>>the appropriate action'.
>>>
>>>
>>>>Suppose it meant the latter. And suppose there are UAs X and Y both
>>>>registering for the same AOR. X registers first, and indicates
> 
> support
> 
>>>>for gruu, and provides a contact with an instance id. So it gets a
>>>
>>>gruu
>>>
>>>>back for its contact. Then Y registers, indicates support for gruu
> 
> and
> 
>>>>provides a contact with instance id. The response to Y's register
> 
> will
> 
>>>>contain contacts for both X and Y. And it will contain the gruus
> 
> for
> 
>>>>both X and Y. But it didn't cause the assignment of a a gruu for X.
> 
> So
> 
>>>This paragraph appears truncated.  I think I agree with what is
> 
> written
> 
>>>above, but you may not have reached the punch line!
>>>
>>>
>>>>Then consider a similar scenario, only X didn't support gruu. Now
> 
> the
> 
>>>>response to X's register doesn't contain a gruu. But does the
> 
> response
> 
>>>>to Y's register contain a gruu for X's contact?
>>>
>>>I don't think it should contain a GRUU for X's contact, because I
> 
> don't
> 
>>>think a GRUU should be created for X if X doesn't support using it
>>>properly.
>>>
>>>
>>>>As written, the registrar doesn't have to remember anything new.
> 
> The
> 
>>>>decision whether to return a gruu only depends on what is in the
>>>>location service and whether the register request contains
>>>
>>>Supported:gruu.
>>>
>>>I can see that minimising the state required in the registrar is
> 
> good,
> 
>>>but I believe that this approach will lead to odd failures in
> 
> operation.
> 
>>>I discussed a couple of these in my earlier email.
>>>
>>>Back in the pre-GRUU days, if you obtained (by whatever means) a
> 
> contact
> 
>>>uri, you didn't know for certain whether it was globally routable or
>>>not.  But you could try it, and if it worked, you knew it was (at
> 
> least
> 
>>>sufficiently routable for your purposes).
>>>
>>>But with GRUUs invented for non-GRUU-supporting UAs, I think you can
> 
> end
> 
>>>up in a worse position.  Given one of these GRUUs, you can use it
> 
> and
> 
>>>find that it initially works.  But once the dialog is established or
> 
> a
> 
>>>target refresh occurs, it stops working.  It might only stop working
> 
> in
> 
>>>one direction though, and the failure might not be noticed for some
> 
> time
> 
>>>(e.g. an hour for typical subscriptions).
>>>
>>>Some of these bad effects can be countered by careful record-route
>>>behaviour, but I don't think all of them can.  And in a way, the
>>>existence of this GRUU draft proves my point that the problem can't
> 
> be
> 
>>>completely solved by other mechanisms.
>>>
>>>Regards,
>>>
>>>Michael
>>>
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip