Subject: [SIP] draft-rosenberg-sip-guidelines-00.txt

From: Neil Deason <[email-masked]>
Date: Wed, 24 May 2000 17:08:00 +0100

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.

Cheers,
Neil.
--
Ubiquity Software Corporation           http://www.ubiquity.net

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 26 May 2000 01:00:24 -0400

> 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
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Neil Deason <[email-masked]>
Date: Fri, 26 May 2000 09:46:44 +0100

Thanks for your reply Jonathan. Comments inline...

> are listed in the Supported header.

I am not sure I see your point - the probing mechanism defined in the draft is
described only in relation to new methods not extensions. But the response to
an OPTIONS should include a Supported header. This may all be academic though
given the proposed solution ...

> contain the Accept header."

What if an extension method was an "outside of the call" method, so there was
no preceeding INVITE. Is it sufficient just to send the new method and accept
the response you get might be 405 Method Not Allowed?

Cheers,
Neil.
--
Ubiquity Software Corporation, UK           http://www.ubiquity.net

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 28 May 2000 01:58:48 -0400

Neil Deason wrote:
> described only in relation to new methods not extensions. 

Right, thats my point. Your comment was:

> The response to an OPTIONS request

which was that the Allow header should list supported headers. It does
not. It only lists allowed methods.

> the response you get might be 405 Method Not Allowed?

Of course. 

-Jonathan R.