[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Doubt related to use of Supported and Require header.
On Sep 10, 2008, at 1:45 PM, Paul Kyzivat wrote:
> Robert,
>
> Thank you for this clarification. It is, AFAIK, consistent with
> observed practice. But I have not seen this level of detail written
> down anywhere before.
>
> Paraphrasing you, I guess the primary guarantee is that if you put
> Supported:X in a request, then you must be prepared to have X used
> in the response and/or to have a Require:X in the response. And if a
> Require:X is: in a request and not rejected by the response, or in a
> response following a Supported:X in the request, then that
> establishes an option-specific contract whose scope is defined by
> the option.
>
> Conversely a Supported:X in a response, or in a request and then not
> sealed with a Require:X in a response, establishes no contract and
> so no guarantees of any sort.
>
> But what about OPTIONS? 3261 says:
>
> The SIP method OPTIONS allows a UA to query another UA or a proxy
> server as to its capabilities. This allows a client to discover
> information about the supported methods, content types, extensions,
> codecs, etc. without "ringing" the other party. For example, before
> a client inserts a Require header field into an INVITE listing an
> option that it is not certain the destination UAS supports, the
> client can query the destination UAS with an OPTIONS to see if this
> option is returned in a Supported header field. All UAs MUST
> support
> the OPTIONS method.
>
> ...
>
> Allow, Accept, Accept-Encoding, Accept-Language, and Supported
> header
> fields SHOULD be present in a 200 (OK) response to an OPTIONS
> request.
>
> It would seem that this is just a "best effort" thing, and that
> there are no guarantees. Or perhaps an option should only be listed
> in Supported of an OPTIONS response if it is *always* supported.
So this use of OPTIONS is something that isn't well implemented (at
least not completely - there are several implementation that look for
REFER to decide if they'll offer transfer).
My read of the specs here is that you put stuff in OPTIONS that you
would be able to use/support if it made sense in the context at the
time. It's not a promise that you'll agree to use/support it at any
particular point in time, but an indication that its possible you
will. The utility is in providing a negative : "Don't bother trying to
do this-strange-thing with me, because I can never do that"
>
>
> Thanks,
> Paul
>
> Robert Sparks wrote:
>> lots inline.
>> On Sep 10, 2008, at 12:39 PM, Paul Kyzivat wrote:
>>> [Copying Robert in hopes there is some SIPit experience on this]
>>>
>>> Comments inline.
>>>
>>> Thanks,
>>> Paul
>>>
>>> Vineet Gupta wrote:
>>>> Hi Paul/All,
>>>> I totally agree with the points mentioned in your email. However,
>>>> I still have doubts whether most implementations follow this
>>>> approach or not. *Firstly,* I share the same feeling with you
>>>> with respect to presence of the Supported header in the request.
>>>> The Require and Supported should not have common options in a
>>>> request. Also, Supported in request is required if UAC wants to
>>>> be generous enough to allow UAS to enforce an option, it itself
>>>> does not require.
>>>> However, I was slightly confused by the following statement in
>>>> RFC3261 with respect to the Supported header (Section 20.37 ,
>>>> [Page 178]):
>>>> /"The Supported header field enumerates all the extensions
>>>> supported by the UAC or UAS"/.
>>>
>>> Yeah, it says that. Its also hopelessly naive. Sometimes options
>>> are supported in one context, and not in another. There is no way
>>> to express that. Some examples:
>>>
>>> - An option may be supported for one method but not another.
>>>
>>> - A B2BUA may only support an option if the device on the other
>>> side also supports it. The device on the other side can change
>>> over time.
>>>
>>>> *So, for inter-operatablity reasons, should all the application
>>>> have same options in Require and Supported header or not?*
>>>
>>> I think, *when you can*, you should list all the options you
>>> support all the time.
>> I think we can make this clear. I'm not sure I agree that the specs
>> are that far away from clear on this - I have not seen any real
>> issues with Supported/Require support at SIPits. Here's how I read
>> the text and what I see implemented:
>> * The mechanics of Supported and Require operate at a transaction
>> level. The semantics of any given extension can _use_ those
>> mechanics differently. It's perfectly reasonable for one extension
>> to have a semantic that is scoped entirely to one transaction, and
>> for another extension to have a semantic that spans several
>> transactions (maybe grouped together in a dialog, maybe not). The
>> requirements of each particular extension will constrain the
>> behavior of the endpoints to do the right thing with placing the
>> tokens in the right fields in the right messages.
>> *What you place in a Supported header are extensions you are
>> willing to use in the context of this transaction. The contract you
>> are entering into is that you are willing to start doing the From sip-bounces at ietf.org Wed Sep 10 12:06:51 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id B18B43A6967;
Wed, 10 Sep 2008 12:06:51 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id D02A63A6800
for <sip at core3.amsl.com>; Wed, 10 Sep 2008 12:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600,
BAYES_00=-2.599, J_CHICKENPOX_71=0.6, J_CHICKENPOX_91=0.6,
SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id b9TP5IDRnrrk for <sip at core3.amsl.com>;
Wed, 10 Sep 2008 12:06:49 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net
[IPv6:2001:470:1f03:267::2])
by core3.amsl.com (Postfix) with ESMTP id C0B063A67AA
for <sip at ietf.org>; Wed, 10 Sep 2008 12:06:48 -0700 (PDT)
Received: from [172.16.3.232] (vicuna-alt.estacado.net [75.53.54.121])
(authenticated bits=0)
by nostrum.com (8.14.3/8.14.1) with ESMTP id m8AJ6Z3K039773
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
Wed, 10 Sep 2008 14:06:37 -0500 (CDT)
(envelope-from rjsparks at nostrum.com)
Message-Id: <BE5AA2BC-454A-44D8-9E11-D1D4AFC9D9C6 at nostrum.com>
From: Robert Sparks <rjsparks at nostrum.com>
To: Paul Kyzivat <pkyzivat at cisco.com>
In-Reply-To: <48C815BB.3050002 at cisco.com>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Wed, 10 Sep 2008 14:06:35 -0500
References: <98abe9690809090827k7472c54fm66a557a0ad17d94b at mail.gmail.com>
<48C69F7B.7040307 at cisco.com>
<98abe9690809100256m79c695e2oa44172ffee47565a at mail.gmail.com>
<48C8063D.5070901 at cisco.com>
<3AB996B0-A3A9-47A4-A881-65AC1160E00B at nostrum.com>
<48C815BB.3050002 at cisco.com>
X-Mailer: Apple Mail (2.926)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
mechanism)
X-Virus-Scanned: ClamAV 0.93.3/8210/Wed Sep 10 11:26:19 2008 on
shaman.nostrum.com
X-Virus-Status: Clean
Cc: sip at ietf.org
Subject: Re: [Sip] Doubt related to use of Supported and Require header.
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
On Sep 10, 2008, at 1:45 PM, Paul Kyzivat wrote:
> Robert,
>
> Thank you for this clarification. It is, AFAIK, consistent with
> observed practice. But I have not seen this level of detail written
> down anywhere before.
>
> Paraphrasing you, I guess the primary guarantee is that if you put
> Supported:X in a request, then you must be prepared to have X used
> in the response and/or to have a Require:X in the response. And if a
> Require:X is: in a request and not rejected by the response, or in a
> response following a Supported:X in the request, then that
> establishes an option-specific contract whose scope is defined by
> the option.
>
> Conversely a Supported:X in a response, or in a request and then not
> sealed with a Require:X in a response, establishes no contract and
> so no guarantees of any sort.
>
> But what about OPTIONS? 3261 says:
>
> The SIP method OPTIONS allows a UA to query another UA or a proxy
> server as to its capabilities. This allows a client to discover
> information about the supported methods, content types, extensions,
> codecs, etc. without "ringing" the othethings
>> the token you put in this header implies if the other side decides
>> to require it. There is nothing that prevents you, in general, from
>> deciding to not offer support for something that you've offered
>> support for before. (But an extension may constrain you here once
>> you or your peer has required it)
>> * What you place in a Required header are extensions that you are
>> actively _using_ in the context of this transaction and that things
>> will go wrong if the other side doesn't know it needs to do what
>> the extension requires it to do.
>>>
>>>
>>>> *Secondly, *I had discussed the scope of options mentioned in
>>>> Require/Supported header, in an earlier debate regarding this
>>>> (whether it applies to a transaction/dialog) in this mailing list
>>>> long back. As per my understanding, from RFC3261 the scope of
>>>> Require/Supported header seems to be a transaction only. If we go
>>>> by this assumption, once session in established using 100rel and
>>>> precondition (as per 3gpp call-flow), a re-INVITE request can be
>>>> sent without both these options (if for example the UAC realizes
>>>> that no QoS establishment would be required).
>>>
>>>> However, I got a feeling that most of the implementions go by the
>>>> assumption that Require/Supported extension apply through out the
>>>> dialog.
>>>>
>>>
>>> This is an area that needs some clarification. Some people think
>>> the scope of Supported/Require is a transaction, some a dialog,
>>> some for as long as not changed, ... There is no great clarity on
>>> this in the specs. Its more a matter of observation based on what
>>> behavior is called for in various specs defining options.
>> See above.
>>>
>>>
>>>> Can you let me know in your opinion, what is the general
>>>> consensus on this. *Are most SIP implementations prepared to
>>>> handle change in Require/Supported options in re-INVITE request
>>>> (They ofcourse can still reject such a re-INVITE by sending 420
>>>> Bad Extension/421 Extension Required)?*
>>>
>>> I don't have data on this. Maybe there is some from SIPit.
>> I have seen changes like this successfully exercised at SIPits. The
>> whole answer is wrapped into the endpoints behaving _per extension_
>> in the way the extension tells them to behave. If there's really a
>> problem here, its in the individual extensions if that behavior is
>> not clear. Can you point to a particular extension where that's the
>> case?
>> 100rel was brought up in this thread before. Support 100rel
>> extension itself can come or go as the requestor sees fit for any
>> given transaction. 3262 is pretty clear on that. Now some other
>> extension _using_ 100rel might place more restrictions on endpoint
>> behavior, and the documentation of those requirements has to live
>> with that other extension.
>>>
>>>
>>> Note: this isn't really just about Require/Supported. There are
>>> other headers with similar issues:
>>>
>>> Accept, Accept_Encoding, Accept-Language, Allow
>> Agreed, but again, I've not seen anything break at a SIPit yet
>> because these things change between transactions in a given dialog
>> (though that's not particularly common).
>>>
>>>
>>> Thanks,
>>> Paul
>>>
>>>> Regards,
>>>> Vineet.
>>>> On Tue, Sep 9, 2008 at 9:38 PM, Paul Kyzivat <pkyzivat at cisco.com <mailto:pkyzivat at cisco.com
>>>> >> wrote:
>>>> Vineet Gupta wrote:
>>>> Hi,
>>>> I have a small doubt related to use of Supported and Require
>>>> header. While from RFC 3261 it is clear the Require header is
>>>> used by the UAC and UAS to enforce the extension implemention
>>>> for a particular session, while the Supported header is
>>>> mostly
>>>> used by UAC to express the extensions which can be enforced
>>>> by
>>>> UAS through the Require header.
>>>> My doubt is that, is it *mandatary that every extension
>>>> that is
>>>> present in Require header must be present in Supported header
>>>> *in the request? According to me, presencr party. For example, before
> a client inserts a Require header field into an INVITE listing an
> option that it is not certain the destination UAS supports, the
> client can query the destination UAS with an OPTIONS to see if this
> option is returned in a Supported header field. All UAs MUST
> support
> the OPTIONS method.
>
> ...
>
> Allow, Accept, Accept-Encoding, Accept-Language, and Supported
> header
> fields SHOULD be present in a 200 (OK) response to an OPTIONS
> request.
>
> It would seem that this is just a "best effort" thing, and that
> there are no guarantees. Or perhaps an option should only be listed
> in Supported of an OPTIONS response if it is *always* supported.
So this use of OPTIONS is something that isn't well implemented (at
least not completely - there are several implementation that look for
REFER to decide if they'll offer transfer).
My read of the specs here is that you put stuff in OPTIONS that you
would be able to use/support if it made sense in the context at the
time. It's not a promise that you'll agree to use/support it at any
particular point in time, but an indication that its possible you
will. The utility is in providing a negative : "Don't bother trying to
do this-strange-thing with me, because I can never do that"
>
>
> Thanks,
> Paul
>
> Robert Sparks wrote:
>> lots inline.
>> On Sep 10, 2008, at 12:39 PM, Paul Kyzivat wrote:
>>> [Copying Robert in hopes there is some SIPit experience on this]
>>>
>>> Comments inline.
>>>
>>> Thanks,
>>> Paul
>>>
>>> Vineet Gupta wrote:
>>>> Hi Paul/All,
>>>> I totally agree with the points mentioned in your email. However,
>>>> I still have doubts whether most implementations follow this
>>>> approach or not. *Firstly,* I share the same feeling with you
>>>> with respect to presence of the Supported header in the request.
>>>> The Require and Supported should not have common options in a
>>>> request. Also, Supported in request is required if UAC wants to
>>>> be generous enough to allow UAS to enforce an option, it itself
>>>> does not require.
>>>> However, I was slightly confused by the following statement in
>>>> RFC3261 with respect to the Supported header (Section 20.37 ,
>>>> [Page 178]):
>>>> /"The Supported header field enumerates all the extensions
>>>> supported by the UAC or UAS"/.
>>>
>>> Yeah, it says that. Its also hopelessly naive. Sometimes options
>>> are supported in one context, and not in another. There is no way
>>> to express that. Some examples:
>>>
>>> - An option may be supported for one method but not another.
>>>
>>> - A B2BUA may only support an option if the device on the other
>>> side also supports it. The device on the other side can change
>>> over time.
>>>
>>>> *So, for inter-operatablity reasons, should all the application
>>>> have same options in Require and Supported header or not?*
>>>
>>> I think, *when you can*, you should list all the options you
>>> support all the time.
>> I think we can make this clear. I'm not sure I agree that the specs
>> are that far away from clear on this - I have not seen any real
>> issues with Supported/Require support at SIPits. Here's how I read
>> the text and what I see implemented:
>> * The mechanics of Supported and Require operate at a transaction
>> level. The semantics of any given extension can _use_ those
>> mechanics differently. It's perfectly reasonable for one extension
>> to have a semantic that is scoped entirely to one transaction, and
>> for another extension to have a semantic that spans several
>> transactions (maybe grouped together in a dialog, maybe not). The
>> requirements of each particular extension will constrain the
>> behavior of the endpoints to do the right thing with placing the
>> tokens in the right fields in the right messages.
>> *What you place in a Supported header are extensions you are
>> willing to use in the context of this transaction. The contract you
>> are entering into is that you are willing to start doing the things e/absence of
>>>> Required
>>>> extensions in Supported header does not make any impact on
>>>> UAS
>>>> handling. *Even if it is not mandatory, what is the
>>>> preferred
>>>> approach?*
>>>> This is pretty loosely defined.
>>>> For one thing, Require doesn't necessarily apply to a "particular
>>>> session". The most that can be said with certainty is that is
>>>> applies to a transaction. Often it applies longer, but how long
>>>> isn't well defined.
>>>> Second, there is some asymmetry in Supported/Require, but this
>>>> varies based on the option. Require from a UAC states what it
>>>> requires of the UAS, but doesn't necessarily imply that a Require
>>>> for the same option, coming the other way, would be supported.
>>>> Also, Supported and Require are often used together to do a
>>>> negotiation:
>>>> Supported in a request is paired with Require of the same
>>>> option in
>>>> the response to negotiate its use.
>>>> In most cases there is no requirement to include Supported in
>>>> requests. The main place it is essential is in a 420 response.
>>>> Thanks,
>>>> Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
>> the token you put in this header implies if the other side decides
>> to require it. There is nothing that prevents you, in general, from
>> deciding to not offer support for something that you've offered
>> support for before. (But an extension may constrain you here once
>> you or your peer has required it)
>> * What you place in a Required header are extensions that you are
>> actively _using_ in the context of this transaction and that things
>> will go wrong if the other side doesn't know it needs to do what
>> the extension requires it to do.
>>>
>>>
>>>> *Secondly, *I had discussed the scope of options mentioned in
>>>> Require/Supported header, in an earlier debate regarding this
>>>> (whether it applies to a transaction/dialog) in this mailing list
>>>> long back. As per my understanding, from RFC3261 the scope of
>>>> Require/Supported header seems to be a transaction only. If we go
>>>> by this assumption, once session in established using 100rel and
>>>> precondition (as per 3gpp call-flow), a re-INVITE request can be
>>>> sent without both these options (if for example the UAC realizes
>>>> that no QoS establishment would be required).
>>>
>>>> However, I got a feeling that most of the implementions go by the
>>>> assumption that Require/Supported extension apply through out the
>>>> dialog.
>>>>
>>>
>>> This is an area that needs some clarification. Some people think
>>> the scope of Supported/Require is a transaction, some a dialog,
>>> some for as long as not changed, ... There is no great clarity on
>>> this in the specs. Its more a matter of observation based on what
>>> behavior is called for in various specs defining options.
>> See above.
>>>
>>>
>>>> Can you let me know in your opinion, what is the general
>>>> consensus on this. *Are most SIP implementations prepared to
>>>> handle change in Require/Supported options in re-INVITE request
>>>> (They ofcourse can still reject such a re-INVITE by sending 420
>>>> Bad Extension/421 Extension Required)?*
>>>
>>> I don't have data on this. Maybe there is some from SIPit.
>> I have seen changes like this successfully exercised at SIPits. The
>> whole answer is wrapped into the endpoints behaving _per extension_
>> in the way the extension tells them to behave. If there's really a
>> problem here, its in the individual extensions if that behavior is
>> not clear. Can you point to a particular extension where that's the
>> case?
>> 100rel was brought up in this thread before. Support 100rel
>> extension itself can come or go as the requestor sees fit for any
>> given transaction. 3262 is pretty clear on that. Now some other
>> extension _using_ 100rel might place more restrictions on endpoint
>> behavior, and the documentation of those requirements has to live
>> with that other extension.
>>>
>>>
>>> Note: this isn't really just about Require/Supported. There are
>>> other headers with similar issues:
>>>
>>> Accept, Accept_Encoding, Accept-Language, Allow
>> Agreed, but again, I've not seen anything break at a SIPit yet
>> because these things change between transactions in a given dialog
>> (though that's not particularly common).
>>>
>>>
>>> Thanks,
>>> Paul
>>>
>>>> Regards,
>>>> Vineet.
>>>> On Tue, Sep 9, 2008 at 9:38 PM, Paul Kyzivat <pkyzivat at cisco.com <mailto:pkyzivat at cisco.com
>>>> >> wrote:
>>>> Vineet Gupta wrote:
>>>> Hi,
>>>> I have a small doubt related to use of Supported and Require
>>>> header. While from RFC 3261 it is clear the Require header is
>>>> used by the UAC and UAS to enforce the extension implemention
>>>> for a particular session, while the Supported header is
>>>> mostly
>>>> used by UAC to express the extensions which can be enforced
>>>> by
>>>> UAS through the Require header.
>>>> My doubt is that, is it *mandatary that every extension
>>>> that is
>>>> present in Require header must be present in Supported header
>>>> *in the request? According to me, presence/absence of
>>>> Required
>>>> extensions in Supported header does not make any impact on
>>>> UAS
>>>> handling. *Even if it is not mandatory, what is the
>>>> preferred
>>>> approach?*
>>>> This is pretty loosely defined.
>>>> For one thing, Require doesn't necessarily apply to a "particular
>>>> session". The most that can be said with certainty is that is
>>>> applies to a transaction. Often it applies longer, but how long
>>>> isn't well defined.
>>>> Second, there is some asymmetry in Supported/Require, but this
>>>> varies based on the option. Require from a UAC states what it
>>>> requires of the UAS, but doesn't necessarily imply that a Require
>>>> for the same option, coming the other way, would be supported.
>>>> Also, Supported and Require are often used together to do a
>>>> negotiation:
>>>> Supported in a request is paired with Require of the same
>>>> option in
>>>> the response to negotiate its use.
>>>> In most cases there is no requirement to include Supported in
>>>> requests. The main place it is essential is in a 420 response.
>>>> Thanks,
>>>> Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip