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

[Miguel Garcia <[e-mail]>]

I just checked the latest SIPit report, and it seems that only 5 
implementations supported reg event, as opposed to 29 that supported 
refer, 23 message-summary, or 14 presence.

Well, this probably indicates that reg-event is not widely deployed to 
justify a solution based on it. Therefore, I don't mind Jonathan's 
solution #2

/Miguel

Jonathan Rosenberg wrote:
> The main question is really to decide on one of two mechanisms:
> 
> 1. use reg-event if you are worried about use cases where this race 
> condition can occur (4-6 in Paul's original email)
> 
> 2. add a parameter to Contact in the register response. Specifically, 
> I'd recommend a Contact header field parameter which indicates the time 
> at which the first contact with a given instance ID was registered to 
> that AOR. This value gets linked with each temp gruu, and when the value 
> changes, all of those temp-gruu get invalidated.
> 
> Solution (2) is much simpler, but not needed if you think you'll always 
> have reg-event anyway. I don't think there is widespread support for 
> reg-event on endpoints yet. It is required by IMS.
> 
> I am somewhat on the fence on this one. I do worry that reg-event is 
> genreally a very heavy solution, and may not see much usage. Option 2 is 
> really trivially done, either in gruu or elsewhere. The main issue is 
> that it is another late change.
> 
> -JOnathan R.
> 
> 
> 
> 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
>>>>
>>>
>>
>> _______________________________________________
>> 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