Subject: [Sip] Doubt related to use of Supported and Require header.

From: "Vineet Gupta" <[email-masked]>
Date: Tue, 9 Sep 2008 20:57:54 +0530

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?*

Regards,
Vineet.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Sep 2008 12:08:27 -0400

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

---

From: "Vineet Gupta" <[email-masked]>
Date: Wed, 10 Sep 2008 15:26:07 +0530

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

*So, for inter-operatablity reasons, should all the application have same
options in Require and Supported header or not?*

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

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)?*

Regards,
Vineet.

On Tue, Sep 9, 2008 at 9:38 PM, Paul Kyzivat <[email-masked]> wrote:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Sep 2008 13:39:09 -0400

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

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

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

Note: this isn't really just about Require/Supported. There are other 
headers with similar issues:

Accept, Accept_Encoding, Accept-Language, Allow

	Thanks,
	Paul

> Regards,
> Vineet.
> 
> 
> On Tue, Sep 9, 2008 at 9:38 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> 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?*
> 
> 
>     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.
> 
>     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
> 
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 10 Sep 2008 13:15:42 -0500

lots inline.

On Sep 10, 2008, at 12:39 PM, Paul Kyzivat wrote:

>> 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"/.
>
> supported in one context, and not in another. There is no way to  
> express that. Some examples:
>
>> *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 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.

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

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 <[email-masked] <mailto:[email-masked] 
>> >> wrote:
>>    Vineet Gupta wrote:
>>        Hi,

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Sep 2008 14:45:15 -0400

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.

	Thanks,
	Paul

Robert Sparks wrote:
>>> or not.  *Firstly,* I share the same feeling with you with respect to 
>>> presence of the Supported header in the request. The Require and 
>>> /"The Supported header field enumerates all the extensions supported 
>>> by the UAC or UAS"/.
>>
> 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 
> 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 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)
> 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 
>>> 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).
>>
> 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?
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 10 Sep 2008 14:06:35 -0500

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.
>
> 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  
> response following a Supported:X in the request, then that  
> establishes an option-specific contract whose scope is defined by  
> the option.
>
> sealed with a Require:X in a response, establishes no contract and  
> so no guarantees of any sort.
>
> 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"

>>>> 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.
>>>> RFC3261 with respect to the Supported header (Section 20.37 ,  
>>>> [Page 178]):
>>> 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:
>>>
>>> I think, *when you can*, you should list all the options you  
>>> support all the time.
>> 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:
>> 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  
>> 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  
>> support for before. (But an extension may constrain you here once  
>> you or your peer has required it)
>> will go wrong if the other side doesn't know it needs to do what  
>> the extension requires it to do.
>>>
>>>
>>> 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)?*
>>>
>> 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.
>>>
>>>
>> 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.

---

From: "Vineet Gupta" <[email-masked]>
Date: Thu, 11 Sep 2008 02:23:15 +0530

Hi Robert/Paul,

Thanks for detailed analysis of scope of Require/Supported header as well as
their interpretation. I again agree with all the points mentioned.

I would like to point out another scenario for the Supported header in the
re-INVITE scenario. This case applies to a session which has been
established with both 100rel and precondition as the required extensions.
Now, when one peer wants to start the re-INVITE negotiation, he is not
absolutely sure whether to start the re-INVITE with:

a) Both the 100rel and precondition again in the Require extensions, as the
other peer might need QoS establishment and need a confirmation from the
user before accepting the video invitation.

b) No Required options, as the peer might not be able to support it, or
because the re-INVITE might not neccesarily involve QoS establishment or
user intervention.

One option is that he can do try sending request with with scenario a)  and
then recieving 421 response (bad extension) on which he knows he can only
send re-INVITE request without any extensions.

The other option is to use only Supported extensions in re-INVITE request
depending again the capability of peer, and then leave it upto the UAS of
the re-INVITE request to chose the extensions it wants to use for the
re-INVITE.

I guess this would help out SIP implementations interop with UAs having
different interpretations of scope of Required extensions in use-cases where
the scope is not self evident (because even though the transaction-wise
scope of extensions is agreed to, in many cases its scope is being derived
on the basis of the use-case).

Regards,
Vineet.

On Thu, Sep 11, 2008 at 12:36 AM, Robert Sparks <[email-masked]>wrote:

>> 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.
>>
>> 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.
>>>>> 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.
>>> Supported/Require support at SIPits. Here's how I read the text and what I
>>> see implemented:
>>> 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.
>>> use in the context of this transaction. The contract you are entering into
>>> is that you are willing to start doing the things 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)
>>> 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.
>>>
>>>>
>>>>
>>>> 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.
>>>
>>>>
>>>>
>>> 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?
>>> 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.
>>>
>>>>
>>>>
>>> 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 <[email-masked]<mailto:
>>>>> [email-masked]>> wrote:
>>>>>  Vineet Gupta wrote:
>>>>>      Hi,

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Sep 2008 11:46:17 -0400

Inline.

	Thanks,
	Paul

Vineet Gupta wrote:
> Hi Robert/Paul,
>  
> Thanks for detailed analysis of scope of Require/Supported header as 
> well as their interpretation. I again agree with all the points mentioned.
>  
> I would like to point out another scenario for the Supported header in 
> the re-INVITE scenario. This case applies to a session which has been 
> established with both 100rel and precondition as the required 
> extensions. Now, when one peer wants to start the re-INVITE negotiation, 
> he is not absolutely sure whether to start the re-INVITE with:
>  
> a) Both the 100rel and precondition again in the Require extensions, as 
> the other peer might need QoS establishment and need a confirmation from 
> the user before accepting the video invitation.
>  
> One option is that he can do try sending request with with scenario a)  
> and then recieving 421 response (bad extension) on which he knows he can 
> only send re-INVITE request without any extensions.
>  
> The other option is to use only Supported extensions in re-INVITE 
> request depending again the capability of peer, and then leave it upto 
> the UAS of the re-INVITE request to chose the extensions it wants to use 
> for the re-INVITE.

Well, it seems that if you require preconditions then you also must 
require 100rel. So lets concentrate on the preconditions option.

3312 says:

    An offerer MUST include this tag in the
    Require header field if the offer contains one or more "mandatory"
    strength-tags.  If all the strength-tags in the description are
    "optional" or "none", the offerer MUST include this tag in either a
    Supported header field or in a Require header field.

So, on the reinvite the first decision is whether to use mandatory 
strength-tags. If there is a need to do so, then just Require the 
options and deal with the consequences if the request is rejected.

If not, I think you just put the options in Supported, include your 
preconditions, and see what happens.

> different interpretations of scope of Required extensions in use-cases 
> where the scope is not self evident (because even though the 
> transaction-wise scope of extensions is agreed to, in many cases its 
> scope is being derived on the basis of the use-case).

I just looked to refresh my memory, and I find nothing in 3262 or 3312 
that implies the scope of these options extends beyond the INVITE 
transaction in which they are used.

This does present an obscure problem: suppose you choose to revise your 
session by sending an offer in an UPDATE rather than a reinvite, and you 
also use preconditions, and perhaps even Require support for them in the 
UPDATE. Even though it will take another UPDATE to complete the 
precondition negotiation there is no guarantee that preconditions will 
be supported in a subsequent UPDATE. But this seems to fall into the 
category of "silly" behavior. If you allow an o/a with preconditions to 
begin, there must be an implied contract to continue to allow 
preconditions to be used to reach resolution. I suppose it would be good 
if some future revision to 3312 mentioned this explicitly.

> Regards,
> Vineet.
> 
> 
>  
> On Thu, Sep 11, 2008 at 12:36 AM, Robert Sparks <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>         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.
> 
>         there are no guarantees. Or perhaps an option should only be
>         listed in Supported of an OPTIONS response if it is *always*
>         supported.
> 
> 
>     least not completely - there are several implementation that look
>     for REFER to decide if they'll offer transfer).
> 
>     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.
>                     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:
> 
>                     *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.
>             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 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
>                     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 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?
>             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:
> 
>             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
>                     <[email-masked] <mailto:[email-masked]>
>                     <mailto:[email-masked]
>                     <mailto:[email-masked]>>> wrote:
>                      Vineet Gupta wrote:
>                          Hi,

---

From: "Krishna Prasad Kalluri" <[email-masked]>
Date: Mon, 15 Sep 2008 09:25:09 +0200

Hi Vineet,
 
I think its pretty clear from two paragraphs in section  "8.2.4 Applying
Extensions" of RFC 3261. 
 
Regards
Krishna

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vineet Gupta
Sent: den 9 september 2008 17:28
To: [email-masked]
Subject: [Sip] Doubt related to use of Supported and Require header.

Hi,

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?
 
Regards,
Vineet.