El Martes 07 Abril 2009, Scott Lawrence escribió: > > How is possible a RFC (2976) not being a a standard and a draft being it? > > That RFC only defines the INFO method, but not how DTMF or anything else > is transported using that method: > > The definition of the message bodies or any new headers created for > the INFO method is outside the scope of this document. It is > expected that separate documents will be created to address > definition of these entities.
Thanks for pointing it out. However it seems that, even if something is widely extended (as SIP INFO for DTMF), since it doesn't appear specified in a RFC then a different approach must be approved. Ok, let get more incompatibilities! What is exactly wrong with SIP INFO? it just works! SIP nodes interested in receiving DTMF are, basically, PBX's, media servers (voicemail, conference server...), PSTN gatewasy... It's really easy to expect that most of them implement SIP INFO and RFC2833. Forget DTMF negociation! And now IETF proposes a new way. Ok, something so easy as DTMF will become a new interoperability chaos. An endpoint (phone) is not interested in receiving DTMF (is it ***really***?). But anyway, a phone wanting to receive DTMF could implement SIP INFO and RFC2833, this is very common today. But not, this is not valid since is a working solution not based in a specification (since the specification didn't exist then). Ok, let's make complex something so easy as DTMF. Now the solution for DTMF is KPML with lot of exotic XML and so on. Great, sure it will inmediatelly adopted by most of the vendors and implementation, sure. Sincerelly I cannot understand such things... Best regards. -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
