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

[Paul Kyzivat <pkyzivat at cisco.com>]

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

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

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