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

[Dean Willis <[e-mail]>]

Would a third party observing multiple uses of temp-gruu be able to  
correlate them from this time-stamp and therefore make a reasonable  
deduction that all the temp-gruus were bound to the same Contact and  
therefore used by the same user?

Would we care?

--
Dean


On Dec 4, 2006, at 8:54 AM, Miguel Garcia wrote:

> 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
>


_______________________________________________
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