IETF Logo Mail Archive

RE: draft-ietf-mmusic-sip-session-timer-00.txt

"Dean Willis" <Dean.Willis@MCI.COM> Thu, 18 February 1999 00:06 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA15803 for confctrl-outgoing; Wed, 17 Feb 1999 16:06:26 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA15777 for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 16:06:21 -0800 (PST)
Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA16630 for <confctrl@ISI.EDU>; Wed, 17 Feb 1999 16:06:19 -0800 (PST)
Received: from omta2.mcit.com (omta2.mcit.com [166.37.204.3]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id AAA24549; Thu, 18 Feb 1999 00:02:21 GMT
Received: from dwillispc3 ([166.35.227.103]) by omta2.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19990218000519.OTCN27406@dwillispc3>; Wed, 17 Feb 1999 18:05:19 -0600
From: Dean Willis <Dean.Willis@MCI.COM>
To: Lewis McCarthy <lmccarth@cs.umass.edu>
Cc: Conference Control List <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Wed, 17 Feb 1999 18:05:01 -0600
Message-ID: <003101be5ad2$545f0d20$05808acd@dwillispc3.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <36CB2959.DD2F2946@cs.umass.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

How about renewing at 1/2 T, where T is the minimum time unit on the
proxy chain. If T is greater than 1 minute or so, this should preclude
accidental expirations as the renewal propagates. As T increases, this
gives us a nice backoff on renewals . . .

--
Dean

> -----Original Message-----
> From: owner-confctrl@ISI.EDU
> [mailto:owner-confctrl@ISI.EDU]On Behalf Of
> Lewis McCarthy
> Sent: Wednesday, February 17, 1999 2:41 PM
> To: MMUSIC WG List
> Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
>
>
> Jonathan Rosenberg writes:
> > in a prior email I suggested
> > that each proxy along the chain can decrease (but not increase) the
> > value of the timer. The result is that the timer in the response
> > represents the minimal refresh interval needed by all servers. By
> > definition, this means that every server will receive a
> refresh in time
> > (not true if servers are allowed to increase the interval).
>
> Would there be a need in this approach to account for the delay
> introduced by the length of the chain?  Suppose the proxy
> farthest down
> the chain from the refreshing client happens to want the smallest
> timeout period T of all the proxies.  If the client waits about T time
> before sending the refresh to the nearest proxy, the distant proxy's
> timer may expire before it receives that refresh.
>
> -Lewis
http://www.cs.umass.edu/~lmccarth
--
"we have to yet really seriously debate the constitutional issues and
whether or not we're willing to give up more freedom in order to have
more security" -- U.S. Secretary of Defense William Cohen, 3 Feb 1999

v2.23.0 | Report a Bug | By Email