IETF Logo Mail Archive

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

Jerome Privat <jerome.privat@bt-sys.bt.co.uk> Wed, 17 February 1999 09:54 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id BAA29165 for confctrl-outgoing; Wed, 17 Feb 1999 01:54:53 -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 BAA29160 for <confctrl@zephyr.isi.edu>; Wed, 17 Feb 1999 01:54:51 -0800 (PST)
Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA11217 for <confctrl@ISI.EDU>; Wed, 17 Feb 1999 01:54:48 -0800 (PST)
Received: from rambo (actually rambo.futures.bt.co.uk) by arthur (local) with SMTP; Wed, 17 Feb 1999 09:51:57 +0000
Received: from mussel.futures.bt.co.uk (actually mussel) by rambo with SMTP (PP); Wed, 17 Feb 1999 09:56:17 +0000
Received: by mussel.futures.bt.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BE5A5A.53624C20@mussel.futures.bt.co.uk>; Wed, 17 Feb 1999 09:46:00 -0000
Message-ID: <c=GB%a=_%p=BT%l=TB-PLUTO-990217094416Z-7991@mussel.futures.bt.co.uk>
From: Jerome Privat <jerome.privat@bt-sys.bt.co.uk>
To: 'Jonathan Rosenberg' <jdrosen@dnrc.bell-labs.com>, "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>
Cc: 'Dean Willis' <Dean.Willis@MCI.COM>, 'Conference Control List' <confctrl@ISI.EDU>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Wed, 17 Feb 1999 09:44:16 -0000
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

It seems to me that what Pat calls an ACK in his email is not really an
ACK as defined in the SIP spec. It is in fact a response (200 OK) going
from the callee to the caller.
I think that what Pat means is just that the timeout period should be
echoed in the response, which is fine.

Jerome
BT Labs

>-----Original Message-----
>From:	Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com]
>Sent:	Wednesday, February 17, 1999 3:40 AM
>To:	Pat.Calhoun@Eng.Sun.COM
>Cc:	Dean Willis; Conference Control List
>Subject:	Re: draft-ietf-mmusic-sip-session-timer-00.txt
>
>Patrice Calhoun wrote:
>> 
>> I am sure that we will get to that one day :). However, I would like to
>> understand why this would not work.
>> 
>> Here is an example:
>> 
>>     SC1 ------> SS1 --------> SS2 -------> SC2
>> 
>> In the above picture, Sip Client 1 (SC1) sends an invite along to its local
>> Sip Server (SS1). The server adds some timeout information to the request
>> and passes this along to SS2. If SS2 is satisfied with the timeout
>>information
>> added by SS1, it will leave it be. If SS2 requires a smaller timeout
>>period,
>> SS2 will modify the timeout value and pass the INVITE to SC2.
>> 
>> SC2 must response with an ACK. This ACK could include the timeout period,
>>and
>> could be checked by either SIP Server to ensure that it meets its local
>> policy. The Sip Servers will assume that the session is destroyed within
>>the
>> timeout period, unless SC1 re-sends another INVITE message.
>
>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.
>
>-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

v2.23.0 | Report a Bug | By Email