Subject: RE: [Sip] Issue: Expiration of temp-gruu

From: "Elwell, John" <[email-masked]>
Date: Thu, 30 Nov 2006 09:10:16 +0000

I guess some of my concerns about temporary GRUUs are starting to creep back
again. It is a question of how they are used. If a UA gives a temporary GRUU
out as a contact on a dialog and expects it to be used only during the
lifetime of that dialog, then refreshing the target if the temporary GRUU is
lost would get around the problem in most cases. There will of course be
race conditions, e.g., the UA sends out a target refresh but the remote UA
has already sent a REFER request to the old target.

What concerns me more is if there are use cases where a remote UA might want
to use a received temporary GRUU long after the dialog has terminated. If
the local UA keeps refreshing its subscription correctly and successfully,
then the temporary GRUU will remain valid. But if it is lost through
circumstances beyond the control of the local UA, then it has no means to
inform the remote UA that it is no longer valid and that a different
temporary GRUU must be used.

One example given in gruu-11 is the use of a GRUU on a web page. If a
temporary GRUU were to be used (presumably on a temporary web page), similar
considerations would apply.

Another concern is if I want to give out a different temporary GRUU to
different remote UAs, so that I can easily turn off individual temporary
GRUUs if I no longer wish to receive requests from the parties concerned.
When I first register I have only one temporary GRUU, so if I want to give
out several temporary GRUUs I would need to refresh my subscription several
times to obtain these GRUUs.

I just have an uneasy feeling that the temporary GRUU mechanism might be
somewhat orthogonal to possible use cases, although I am having difficulty
articulating particular real life use cases.

John 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 29 November 2006 23:21
> To: SIP IETF
> Subject: [Sip] Issue: Expiration of temp-gruu
> 
> After some study, I have encountered a potential difficulty in 
> determining when temp-gruus expire. After discussing this 
> with Jonathan 
> we decided to bring it to the list for discussion.
> 
> As now defined, when you first register you may get a 
> temp-gruu, which 
> will remain valid as long as the registration does not expire or be 
> removed. (Removal is a special case of expiration.) Each time the UA 
> refreshes the registration it may get a new temp-gruu which 
> also remains 
> valid for the life of the registration. The UA can accumulate 
> all these 
> temp-gruus and use them as it sees fit until they expire.
> 
> The problem is: how does the UA know when the registration 
> has ended and 
> the temp-gruus associated with it rendered invalid?
> 
> This seems like a simple question, and in some cases it is 
> simple, but 
> not in all cases. The following are at least some of the ways 
> that the 
> registration can be ended, causing the invalidation of temp-gruus:
> 1) the UA that originally registered may explicitly deregister
> 2) the UA the originally registered may simply permit the
>     registration to expire without attempting to refresh it
> 3) the UA may attempt to refresh the registration, but be too slow,
>     so that the reregistration arrives after the prior one expires
> 4) some other UA may deregister all the registrations, including
>     the one by this UA. (When the UA decides it should refresh the
>     registration it will actually create a new one.)
> 5) the registrar may remove the registration administratively
> 6) the registrar may crash and restart, losing all its registrations
> 
> In each of these cases the previously assigned temp-gruus become 
> invalid. If the UA continues to use them, bad things will 
> happen. This 
> is true both for calls that are active when the 
> deregistration occurs, 
> and calls that are established later. What kinds of bad things happen?
> - requests addressed to the gruu, both in-dialog and out-of-dialog
>    will be undeliverable. (For instance a reINVITE or BYE in an
>    existing call, or an out-of-dialog INVITE/Replaces for a transfer.)
> 
> - request originated by the UA using the invalid gruu will fail
>    immediately because the gruu is invalid.
> 
> - if the UA subsequently reregisters, receives an incoming call, and
>    uses one of the old temp-gruus as its contact, then the call will
>    be established, but subsequent in- and out-of-dialog requests to
>    the contact will fail.
> 
> So clearly it is important for the UA to stop using 
> temp-gruus that have 
> become invalid. How can it know to do that in all of the above cases?
> 
> 1) is straightforward. The UA knows it is deregistering, and should
>     discard any cached temp-gruus. If it has a dialog with one of the
>     temp-gruus as a contact, then it should do a target refresh and
>     supply some working contact. (It really should do this *before*
>     deregistering, and for a pub-gruu as well.)
> 
> 2) the UA should take all the actions mentioned for (1) at or before
>     the expiration time. This should be done a bit early to guard
>     against clock skew problems.
> 
> 3) in this case, it may be impossible for the UA to know whether
>     the REGISTER arrived in time to be a reREGISTER or if it arrived
>     late and was treated as a new REGISTER after the expiration of
>     the old one. (The response to the REGISTER includes nothing that
>     distinguishes the two cases.) About the best that can be done in
>     this case is to check the time at which the response to the
>     REGISTER is received. If it falls after the expected expiration
>     time for the registration, act as if the old registration had
>     expired.
> 
> 4) This is a major problem. Of course, regardless of GRUU, the UA
>     won't be able to receive incoming calls until it decides it is
>     time to refresh the registration. In addition, until the
>     registration reestablished, calls originated with one of its
>     existing gruus will fail. Once the registration is reestablished,
>     it still won't know its old temp-gruus are invalid. The only
>     remedy for this is to subscribe to the "reg" event package,
>     and use the resulting notifications to identify when it has
>     been unregistered. If it does that, it can invalidate all its
>     old temp-gruus, and then presumably reregister.
> 
> 5) this is functionally equivalent to (4), except that perhaps
>     attempts to reregister may fail.
> 
> 6) this is also functionally equivalent to (4).
> 
> The "reg" event does provide a fairly complete solution to 
> this problem, 
> for those that are willing and able to use it. It is not 
> however a 100% 
> reliable solution. Consider case (3), where the UA has a reg event 
> subscription. All is well if the registration expires and a 
> notification 
> is sent indicating that, and then the reregistration occurs and a 
> notification is sent about that. But if they happen very closely in 
> time, it may be that only one notification is sent, reflecting the 
> result of the reregistration. In that case the UA will not be 
> aware that 
> it had been unregistered for a period of time.
> 
> A *complete* solution would, IMO, involve changing REGISTER 
> so that it 
> returns an indication of whether this was a new registration, or a 
> refresh. This could take many forms. For instance the 
> timestamp of the 
> initial registration could always be returned with each 
> contact, as well 
> as the expiration time.
> 
> The big question is whether this is a big enough issue to require a 
> solution now, as part of GRUU, or if it can be ignored as 
> insignificant 
> or postponed to future work.
> 
> I'd appreciate hearing what others think about this. At the 
> moment I am 
> leaning toward doing nothing, at least for now.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> 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
> 

_______________________________________________
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, 30 Nov 2006 14:27:06 -0500

Elwell, John wrote:
> again.

Is your renewed concern related to this particular issue I posted? It 
doesn't seem to be.

Your concern seems to be that temporary gruus are, well, *temporary*.

> It is a question of how they are used. If a UA gives a temporary GRUU

Yes. In most cases this won't be an issue. And I expect that many 
implementations will simply assume that they stay registered and don't 
need to deal with the doing a target refresh because the gruu has been lost.

> temporary GRUU must be used.

Yes, this is the case. Frankly I find it hard to imagine a case where a 
temp-gruu, used for anonymity, is to be used for something long after 
the dialog has terminated. I guess there could be cases, but perhaps 
they aren't so interesting.

Any kind of scheme that allowed temp gruus to live arbitrarily beyond 
the life of a registration would need some other mechanism to support 
their longevity, and also would presumably need some kind of revocation 
mechanism. It would I think need state to be kept in the network.

There may be some use for such a thing. But I think it probably calls 
for a different mechanism. One that probably isn't suitable for everyday 
anonymous calls. So I think supporting that mechanism can be viewed as 
an independent problem.

> considerations would apply.

I guess it depends on how temporary the web page is.

> articulating particular real life use cases.

I think we already hashed these particular issues. There are some 
unavoidable tradeoffs here.

	Paul