Hi, >I like the idea of being clear where SIP INFO belongs >(arguably only for use with SIP-T) and then having a BCP >which identifies common places where SIP INFO is being used >today, and then references the preferred practice (typically >not using SIP INFO) or work in progress (for example, the >mediactrl work) which will result in new practices. > >The problem from a manufacturer's standpoint is that >customers have existing products (for example, gateways) that >use SIP INFO for DTMF passage and they insist on having >compatibility with these bad practices built into other >products, thus perpetuating the cycle of bad practice. >A BCP might at least point the preferred way out of this mess.
Normally, when we produce BCP type of documents, it's because there is a problem out there (people implement specs in different, uninteroperable, ways etc). Are we aware of real-life problems with using INFO for DTMF (or whatever else it's used for)? People have been doing it for a while (if we wanted to restrict something, it should have been done years ago...), it's fairly simple to implement - and it seems to work. The only problem is that much of the INFO usages are not defined in RFCs, but that's not always the fault of the implementors... Regards, Christer _______________________________________________ Sip mailing list https://www1.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
