Dean Willis wrote:
The option tag is used in OPTIONS responses (and in Supported header
fields in other responses) to inform a correspondent that the node in
question supports this extension, potentially leading to a decision as
to which behavior to apply to future requests.
It is also used in Require header fields of requests to cause the
request to be rejected by any UAS that does not understand the
extension. This is potentially critical for applications that find
themselves completely dependent on the extension.
One might ask whether this is critical; after all the INVITE exchange
will tell us what info packages (if any) the far end is willing to use.
What is the difference between not using INFO packages and not
supporting them?
The answer is in the fallback to pre-package INFO behavior. A node
supporting INFO packages will, IIRC (or at least "if I get my way") ,
always use packages when sending INFO. A node not supporting INFO
packages is likely to send old-style un-negotiated INFO, meaning you
might need to be prepared with that behavior. Being informed (by
Supported) which state applies might be useful.
This really can't be so.
I may support a legacy info usage because I need to do so to
interoperate with some class of devices that use it and don't do the new
info stuff. That package works just fine, so there is no reason to
define a new info-package for the same purpose. So that may not get
done. Yet for new functionality I use info packages.
In such an environment I may well use a combination of legacy infos and
info packages.
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
