On Nov 24, 2008, at 10:33 AM, Bob Penfield wrote:
The thing that makes me most uncomfortable with an option tag for info-packages is that it is expanding the scope of an option tag from a single well-defined extension/feature to a whole class of features that are not necessarily related. I see it as being analogous to defining an option tag for event-packages that could be used to fail calls because the UAS does not support SUBSCRIBE/NOTIFY.
We have one; SUBSCRIBE. If it doesn't show in the Supported methods, don't send a SUBSCRIBE.
Unfortunately, INFO method support is not enough, as there are prepackage INFO implementations in the wild. So we have three cases to differentiate: No INFO, Old INFO, and new INFO packages.
The other thing that is bothersome is that one day, the calls are failing for your mystery application, the next day they succeed because the UAS was upgraded to support SOME info-package, but not your mystery feature and you will have to terminate successful calls because of it.
But now you can look at the info package negotiation and figure out that it does not support the mystery-package, and tell what other packages it does support (and write the application to adapt to the available packages).
I think we should change the section about OPTIONS to require the UAS to include its supported info-packages in the response if the request had a Recv-Info header. That way you could probe the far end if you really require your info-package to be there.
While that makes perfect sense, it is inconsistent with the use of OPTIONS tags in RFC 3261. I'd like to change that part of 3261 someday . . .
-- Dean _______________________________________________ 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
