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

[Miguel Garcia <[e-mail]>]

Correct. I think so.

/Miguel

Paul Kyzivat wrote:
> 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
>>>
>>

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland

_______________________________________________
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