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