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

Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com> Wed, 17 February 1999 15:32 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id HAA10749 for confctrl-outgoing; Wed, 17 Feb 1999 07:32:38 -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 HAA10744 for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 07:32:36 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id HAA26348 for <confctrl@isi.edu>; Wed, 17 Feb 1999 07:32:35 -0800 (PST)
Received: from nova.dnrc.bell-labs.com ([135.180.131.5]) by dirty; Wed Feb 17 10:27:01 EST 1999
Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by nova.dnrc.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA13448; Wed, 17 Feb 1999 10:26:55 -0500 (EST)
Message-ID: <36CADF25.FC6907AB@dnrc.bell-labs.com>
Date: Wed, 17 Feb 1999 10:24:21 -0500
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Pat.Calhoun@Eng.Sun.COM
CC: Conference Control List <confctrl@ISI.EDU>, Dean Willis <Dean.Willis@MCI.COM>
Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt
References: <199902171328.FAA04774@hsmpka.eng.sun.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Patrice Calhoun wrote:
> 
> >Thats pretty much whats specified in the Donovan draft. THe difference
> >is that the timeout doesn't get reflected in the ACK. THis is not
> >needed, though. The timeout should be echoed in the response, which will
> >be seen by both servers. I think this works just fine. The only issue
> >has to do with backwards compatibility - knowing that SC1 will
> >understand the timer in the response.
> 
> ok, but what is a client sends a timeout of infinity, and the server's policy
> does not allow it to maintain soft state that long for a single session?

I'm not sure what it says in the draft; 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).

-Jonathan R.


-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen