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

["Michael Procter" <[e-mail]>]

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

_______________________________________________
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