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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Nov 2006 18:20:45 -0500

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