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

From: Miguel Garcia <[email-masked]>
Date: Fri, 01 Dec 2006 16:22:24 +0200

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 [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Dec 2006 11:26:14 -0500

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:
>> determining when temp-gruus expire. After discussing this with 
>> Jonathan we decided to bring it to the list for discussion.
>>
>> 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?
>>
>> 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?
>>
>> 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.
>>
>> initial registration could always be returned with each contact, as 
>> well as the expiration time.
>>
>> 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
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Dec 2006 14:07:54 -0500

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:

>>> 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.
>>>
>>> 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:
>>> 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?
>>> 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.
>>>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Scott Lawrence <[email-masked]>
Date: Sun, 03 Dec 2006 21:50:34 -0500

On Wed, 2006-11-29 at 18:20 -0500, Paul Kyzivat wrote:

[assorted ambiguous cases that make it unclear whether or not a
temp-gruu is still valid]

> reliable solution. 

A UA that wants to determine whether or not a temp-gruu it has for
itself is still valid can do that test any time: send an OPTIONS request
to the domain of the gruu addressed to that temp-gruu.  If you get the
request back, it's still good.  No change is needed to gruu, and no
support for the reg event package is needed by either the UA or the
registrar.

--

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 04 Dec 2006 16:54:27 +0200

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:
>> 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:
>>
>>> 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:
>>>
>>>> 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.
>>>>
>>>> it returns an indication of whether this was a new registration, or 
>>>> a refresh. This could take many forms. For instance the timestamp of

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 04 Dec 2006 16:49:18 +0200

Correct. I think so.

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Dec 2006 17:15:18 -0500

Scott,

Its certainly true that a gruu can always be tested to see if it works. 
That would however raise the question of when one ought to do the test. 
In normal cases you will know the status of your gruu by regular 
methods, so you would have no reason to test it. So you would have to 
test whenever you thought failure might have negative consequences. Some 
of the times when failure might have bad consequences are: when 
responding to an incoming INVITE, and any time during a dialog. I guess 
you could send an OPTIONS and await the response before responding to an 
INVITE, and it might even be masked by alerting, but it seems kind of 
annoying to have to do that. But no matter how often you do it during a 
dialog you still might miss the moment your gruu becomes invalid and the 
other end of the dialog sends you a message. (Extremely unlikely, but 
possible.)

I think the other existing solutions get "pretty close", and OPTIONS 
doesn't significantly improve on that.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 Dec 2006 01:02:45 -0600

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:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Dec 2006 08:57:05 -0500

> therefore used by the same user?

The timestamp is only in the response to REGISTER. It isn't embedded in 
the gruu itself and so isn't visible to those receiving the gruu as a 
remote target or whatever.

(There is likely a timestamp *in* the gruu as well (along with the AOR 
and instance id), used to determine its validity. But when using that 
technique to construct temp gruus it will be necessary to encrypt all 
that info so that only the registrar/proxy can extract it.

	Paul

>>> 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.
>>> 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,
>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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?
>>>>>> that have become invalid. How can it know to do that in all of the 
>>>>>> above cases?
>>>>>>
>>>>>> reregistration occurs and a notification is sent about that. But 
>>>>>> if they happen very closely in time, it may be that only one 
>>>>>> In that case the UA will not be aware that it had been 
>>>>>> unregistered for a period of time.
>>>>>>
>>>>>> 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 
>>>>>> I'd appreciate hearing what others think about this. At the moment 
>>>>>> I am leaning toward doing nothing, at least for now.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Paul
>>>>>>
>> --Miguel A. Garcia           tel:+358-50-4804586

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 05 Dec 2006 11:30:39 -0500

> doesn't significantly improve on that.

I don't like requiring the registrar to return a timestamp because it's
yet another piece of state that it has to keep for every registration.

I don't think it actually helps all that much - going back to your

> 6) the registrar may crash and restart, losing all its registrations

Case 3 can be avoided by just not waiting too long (overlap by a few
minutes instead of a few seconds - if that's still problematic then you
probably have other problems that are worse anyway).

Cases 4,5, and 6 are essentially all the same from the point of view of
the UA; your registration state at the server is lost because of some
event you are not aware of.  This is true of any registration, and is
not specific to temp-gruu or public gruu; it can happen with a Contact
value you provide without gruu at all.  A gruu is slightly worse in that
loosing the state can affect in-dialog requests for established dialogs,
but I think that's just an unavoidable chance that you take when you
choose to use a gruu of either kind.  Put another way, if you use a
gruu, you accept the fact that you're relying on an additional service
for in-dialog connectivity - it's either worth the benefits or it isn't.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 05 Dec 2006 11:30:39 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Dec 2006 16:07:48 -0500

Scott,

To paraphrase, it seems that you think we have enough mechanism now, and 
don't need any more to deal with the issues raised in this thread. Is 
that right?

	Paul

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 05 Dec 2006 16:20:15 -0500

> don't need any more to deal with the issues raised in this thread. Is 

Yes, that's correct.