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

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 protected]> 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 [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip