IETF Logo Mail Archive

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

"Dean Willis" <Dean.Willis@MCI.COM> Tue, 16 February 1999 20:26 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id MAA12421 for confctrl-outgoing; Tue, 16 Feb 1999 12:26:59 -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 MAA12406 for <confctrl@zephyr.isi.edu>; Tue, 16 Feb 1999 12:26:56 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA11927 for <confctrl@ISI.EDU>; Tue, 16 Feb 1999 12:26:54 -0800 (PST)
Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2]) by omzrelay.mcit.com (8.8.7/) with ESMTP id TAA14637; Tue, 16 Feb 1999 19:25:47 GMT
Received: from dwillispc3 ([166.35.227.103]) by omta1.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19990216202607.IJKP16006@dwillispc3>; Tue, 16 Feb 1999 14:26:07 -0600
From: Dean Willis <Dean.Willis@MCI.COM>
To: Pat.Calhoun@Eng.Sun.COM
Cc: Conference Control List <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Tue, 16 Feb 1999 14:26:01 -0600
Message-ID: <000d01be59ea$919da680$2e8dfea9@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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
In-Reply-To: <199902161534.HAA26159@hsmpka.eng.sun.com>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Pat Calhoun responded:
>> Dean Willis said:
>>Can we at least get some consensus that it IS a problem?
>
> Oh, I agree that there is a problem. I am just not sure that
> the solution
> proposed is the best one. I suppose I need to really
> understand why the INVITE
> approach cannot work to setup soft-state along the proxy
> chain. you state that
> P4 never sees the REGISTER, but I think that the INVITE/ACK
> is sufficient
> for the proxies to build state. Am I wrong?

INVITE is quite sufficient for proxies to build state, just not
sufficient for them to destroy state if the endpoints fail to signal the
state change.

I'm not sure that the proposed solution is the best one either. Two
timer mechanisms and two active status determination mechanisms have
been discussed as alternatives -- now we debate, maybe someday we have a
consensus?

--
Dean

v2.23.0 | Report a Bug | By Email