Re: [SIP] draft-rosenberg-sip-guidelines-00.txt
Jonathan Rosenberg <jdrosen@dynamicsoft.com> Fri, 26 May 2000 04:51 UTC
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28387 for <sip-archive@odin.ietf.org>; Fri, 26 May 2000 00:51:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7BAD144370; Fri, 26 May 2000 00:43:09 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (unknown [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3D43344357 for <sip@lists.bell-labs.com>; Fri, 26 May 2000 00:43:07 -0400 (EDT)
Received: from dynamicsoft.com (1Cust112.tnt2.freehold.nj.da.uu.net [63.17.114.112]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA15898; Fri, 26 May 2000 00:49:09 -0400 (EDT)
Message-ID: <392E04E8.9EF7B31@dynamicsoft.com>
Date: Fri, 26 May 2000 01:00:24 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Neil Deason <ndeason@ubiquity.net>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] draft-rosenberg-sip-guidelines-00.txt
References: <392BFE60.8BE09351@ubiquity.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
X-BeenThere: sip@lists.bell-labs.com
Content-Transfer-Encoding: 7bit
Neil Deason wrote: > > This draft states that a probing mechanism should be defined to aid > backwards compatibility when defining new methods. It describes the > mechanism to be used as the UAC adding some header to a standard SIP > request. The UAS places some information in the response if it > understands this header (and thus the extension-method). > > Couldn't the OPTIONS method be used to provide such a probing mechanism > within the standard SIP framework? The response to an OPTIONS request > should include an Allow header entity-field that lists the supported set > of headers, including any extension-methods. Well, Allow lists allowed methods, not new extensions. New extensions are listed in the Supported header. Since this draft was published, there was some consensus on the list that the response to INVITE should probably contain both Allow and Supported headers (and possibly even Accept). The particular application was TRANSFER; it would be nice to know once the call is set up whether the remote side can be transferred. This would allow you to "grey out" the transfer button on the UI, rather than having the user try and then fail. This would eliminate the need for the probing mechanism, and avoid the need for the explicit OPTIONS. Suggested wording: "A 200 OK response to the initial INVITE for a call SHOULD contain the Allow and Supported headers, and MAY contain the Accept header. These will enable the UAC to determine the features and extensions supported by the UAS for the duration of the call. Similarly, the initial INVITE from the UAC SHOULD contain the Allow and Supported headers, and MAY contain the Accept header." -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip
- Re: [SIP] draft-rosenberg-sip-guidelines-00.txt Jonathan Rosenberg
- Re: [SIP] draft-rosenberg-sip-guidelines-00.txt Neil Deason
- Re: [SIP] draft-rosenberg-sip-guidelines-00.txt Jonathan Rosenberg
- [SIP] draft-rosenberg-sip-guidelines-00.txt Neil Deason