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