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

[Paul Kyzivat <[e-mail]>]

Miguel,

So to summarize, it seems you are of the belief that the cases where 
these measures may be inadequate are sufficiently obscure to ignore, and 
that new measures to cover the obscure cases are unnecessary. Is that right?

	Paul

Miguel Garcia wrote:
> For issue 3, I would say that the solution is to avoid the situation, 
> e.g., by registering way in advance before the registration expires. 
> Doesn't RFC 3261 recommends to re-register half time before the 
> registration timer expires.
> 
> Issues 4, 5, and 6 are solved by the reg event. So, shouldn't the GRUU 
> draft have a recommendation on the usage of the reg event to solve them?
> 
> /Miguel
> 
> Paul Kyzivat wrote:
>> 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 [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