Re: [Sip] Issue: Expiration of temp-gruu
Miguel Garcia <Miguel.An.Garcia@nokia.com> Fri, 01 December 2006 14:22 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq9Hg-0001Ps-3n; Fri, 01 Dec 2006 09:22:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq9He-0001Pk-Vx for sip@ietf.org; Fri, 01 Dec 2006 09:22:34 -0500
Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq9Hc-0000FB-J5 for sip@ietf.org; Fri, 01 Dec 2006 09:22:34 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kB1EM8Ci010478; Fri, 1 Dec 2006 16:22:27 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 16:22:23 +0200
Received: from [172.21.58.172] ([172.21.58.172]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Dec 2006 16:22:23 +0200
Message-ID: <45703AA0.20007@nokia.com>
Date: Fri, 01 Dec 2006 16:22:24 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Sip] Issue: Expiration of temp-gruu
References: <456E15CD.60805@cisco.com>
In-Reply-To: <456E15CD.60805@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Dec 2006 14:22:23.0115 (UTC) FILETIME=[1E2E85B0:01C71554]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::061201162227-28B1BBB0-117CD105/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Cc: 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
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 > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net 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 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