Re: [Sip] Issue: Expiration of temp-gruu
Jonathan Rosenberg <jdrosen@cisco.com> Fri, 01 December 2006 19:08 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDk3-00052r-9N; Fri, 01 Dec 2006 14:08:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDk0-00050s-QA for sip@ietf.org; Fri, 01 Dec 2006 14:08:09 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqDjy-0003q7-2U for sip@ietf.org; Fri, 01 Dec 2006 14:08:08 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2006 11:08:05 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB1J850v006440; Fri, 1 Dec 2006 11:08:05 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB1J80ix026404; Fri, 1 Dec 2006 11:08:05 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 11:08:01 -0800
Received: from [10.32.241.153] ([10.32.241.153]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 11:08:00 -0800
Message-ID: <45707D8A.8020001@cisco.com>
Date: Fri, 01 Dec 2006 14:07:54 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] Issue: Expiration of temp-gruu
References: <456E15CD.60805@cisco.com> <45703AA0.20007@nokia.com> <457057A6.4020804@cisco.com>
In-Reply-To: <457057A6.4020804@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Dec 2006 19:08:01.0078 (UTC) FILETIME=[05342560:01C7157C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8906; t=1165000085; x=1165864085; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com> |Subject:=20Re=3A=20[Sip]=20Issue=3A=20Expiration=20of=20temp-gruu |Sender:=20; bh=Q+Gf5gt/Lc2JxfmDsvyPzrKmiLInjtErKqm+v9AbhDQ=; b=U42uI6zzjMa6aw/vkc30jG+vfob3ExjFL1b4OdF58D6fenL348ZXBMdywho430sSVZ/YiAwd J1paqTtrrUBrW+ui3NqZXRtkeLtduhFTfu2qPsXuR1UXIQDUYCX98M4Y;
Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Cc: Miguel Garcia <Miguel.An.Garcia@nokia.com>, SIP IETF <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
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 sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Issue: Expiration of temp-gruu Paul Kyzivat
- RE: [Sip] Issue: Expiration of temp-gruu Elwell, John
- Re: [Sip] Issue: Expiration of temp-gruu Paul Kyzivat
- Re: [Sip] Issue: Expiration of temp-gruu Paul Kyzivat
- RE: [Sip] Issue: Expiration of temp-gruu Elwell, John
- Re: [Sip] Issue: Expiration of temp-gruu Miguel Garcia
- Re: [Sip] Issue: Expiration of temp-gruu Jonathan Rosenberg
- Re: [Sip] Issue: Expiration of temp-gruu Scott Lawrence
- Re: [Sip] Issue: Expiration of temp-gruu Miguel Garcia
- Re: [Sip] Issue: Expiration of temp-gruu Miguel Garcia
- Re: [Sip] Issue: Expiration of temp-gruu Paul Kyzivat
- Re: [Sip] Issue: Expiration of temp-gruu Dean Willis
- Re: [Sip] Issue: Expiration of temp-gruu Paul Kyzivat
- Re: [Sip] Issue: Expiration of temp-gruu Scott Lawrence
- Re: [Sip] Issue: Expiration of temp-gruu Paul Kyzivat
- Re: [Sip] Issue: Expiration of temp-gruu Scott Lawrence
- Re: [Sip] Issue: Expiration of temp-gruu Jonathan Rosenberg
- RE: [Sip] Issue: Expiration of temp-gruu Andrew Allen
- Re: [Sip] Issue: Expiration of temp-gruu Jonathan Rosenberg
- RE: [Sip] Issue: Expiration of temp-gruu Erkki.Koivusalo
- Re: [Sip] Issue: Expiration of temp-gruu Jonathan Rosenberg