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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Jan 2007 16:44:05 -0500

This thread is a month old, but I want to revise GRUU and get this done. 
This is really the only issue that is outstanding, I think.

To refresh everyones memory, the issue being dsicussed is this. 
Temp-GRUU expire when the last contact with the instance ID expires. In 
normal cases, the expiration is known to the UA. However, there are 
cases where there is a forceful de-registration, for example. In these 
cases, the UA will not know about it, and it won't know whether its 
temp-gruu remain valid.

We've seen three proposals for how to deal with this:

1. include a parameter in the Contact header field of the REGISTER 
response, indicating the time at which the first contact with that 
instance ID was registered. When this changes in a REGSITER response, 
the UA knows its older temp-gruu are invalid.

2. the UA uses a reg-event subscription, and it gets a NOTIFY when the 
contacts are de-registered. As long as the UA gets the notification 
indicating that the de-registration has happened, this works reasonably 
well.

3. the UA can use an OPTIONS sent to a temp-gruu to verify that it still 
works

(2) and (3) require no new mechanism, just explanation. (1) would 
require new mechanism.

Now, I was in the process of working through some details on this, and 
ran into problems. In particular, we ultimately need to be able to 
specify an algorithm that clearly tells a UA which of its temp GRUU are 
valid, and which are expired. If we are using the reg-event subscription 
to figure this out, the obvious algorithm would be to expire all 
temp-gruu learned in REGISTER responses prior to this notification. 
However, that is imprecise. What about a REGISTER that happens very 
close in time to the NOTIFY? Indeed, this is very likely to be the case 
when the reg-event is shortening the expiration in order to ask the user 
to explicitly re-REGISTER, but the time was a bit too short and the 
re-REGISTER is close to the boundary. If a NOTIFY comes indicating that 
the contact did expire, how do you *know* if that REGISTER came in 
before or after? You could wait for the next NOTIFY, and try and 
correlate it with the REGISTER you just completed.

One way to do that is with CSeq. The reg-event package includes the 
option of having CSeq numbers. If we assume these are always used (they 
are optional), the algorithm is a bit easier. Each temp-gruu is 
associated with the CSeq of the REGISTER in which it was learned. When a 
NOTIFY comes indicating that the registration has expired, you look to 
see if its a partial or full state NOTIFY. In the case of partial, if 
the NOTIFY explicitly removes a contact, you invalidate all temp-gruu 
learned in register responses prior to or equal to the CSeq in the 
contact. If the case of a full state NOTIFY, if the contact is absent, 
the UA marks all temp-gruu as suspect. On the first NOTIFY that 
indicates the Contact is re-registered (I assume the UA is 
re-registering), the UA invalidates all temp-gruu learned by REGISTER 
responses whose CSeq is less than the one in the NOTIFY. All others are 
considered valid.

This algorithm is assuming some very specific behavior from registrars 
that are doing reg-event with GRUU. Namely, they always send CSeq, even 
when indicating expiration of a contact. We'd need to specify this, 
probably as a note in gruu-reg-event.

Comments on this algorithm? If this is OK I will update GRUU based on 
this and we can ship it. Finally. Really this time.

-Jonathan R.

Scott Lawrence wrote:

> On Mon, 2006-12-04 at 17:15 -0500, Paul Kyzivat wrote:
> 
>>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.
> 
> 
> 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
> original problem statements:
> 
> 
>>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
> 
> 
> 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.
> 
> 
> 
> 

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

_______________________________________________
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: "Andrew Allen" <[email-masked]>
Date: Fri, 12 Jan 2007 19:07:53 -0500

Jonathan

This algorithm looks fine to me.

Andrew

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, January 10, 2007 4:44 PM
To: Scott Lawrence
Cc: SIP IETF; Paul Kyzivat
Subject: Re: [Sip] Issue: Expiration of temp-gruu

works

-Jonathan R.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.