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

Thanks for your reply Jonathan. Comments inline...

Jonathan Rosenberg wrote:

> 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.

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 ...

> 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."

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

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip