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

[Paul Kyzivat <[e-mail]>]

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

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

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?

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.

	Paul

Michael Procter wrote:
> Jonathan Rosenberg wrote:
>> EKR wrote:
>>> This doesn't seem right. "+sip.instance" at best means
>>> "I want to do outbound". More likely it means "here is my instance
> ID".
>>> It's "Supported: gruu" that says "I want a GRUU".
>> No, its instance. It used to work the way you described, in fact.
>> 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'm interested in how this 'one-sided' support for GRUU would work.  My
> initial reaction is that it would lead to odd failures.  
> 
> For example, take the case where UA1 doesn't support GRUU, but registers
> at R1 which does.  R1 generates the GRUU, but doesn't deliver it back to
> UA1, as you describe.  Let's also assume that UA2 has subscribed to the
> reg-event package for UA1 at R1.  This leads to R1 sending UA2 UA1's
> GRUU.  So far, so good.
> 
> Now, for some reason, UA2 wishes to call UA1 using that GRUU.  The
> INVITE gets routed to UA1 as expected.  UA1 answers the call, and in the
> 200, includes a non-GRUU contact.  The ACK from UA2 now can't route
> correctly (as UA1 can't provide a contact that is globally routable!).
> The upshot of this is often (in my experience) a call that seems to work
> for 30 seconds or so, and then gets torn down.
> 
> Similar things happen for subscriptions - the SUBSCRIBE/200 works ok, as
> do NOTIFYs from UA1, but when the time comes to reSUBSCRIBE, it fails
> for the same reason.
> 
> This can be worked around with judicious use of Record-Route, but I
> can't see any mention of this particular case in the draft.
> 
> Is GRUU support for non-GRUU UAs something we need to make work?
> 
> Regards,
> 
> Michael Procter
> 
> _______________________________________________
> 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
> 

_______________________________________________
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