100 likes | 250 Views
DTMF-Relay Info-Package draft-kaplan-dispatch-info-dtmf-package-00. Hadriel Kaplan. Terminology/Definitions. DTMF: Dual-Tone Multi-Frequency (tones) KPML: Key-Press Markup Language (RFC 4730) Hadriel: the messenger (don’t shoot). The Problem. DTMF is just like other media: It has to work
E N D
DTMF-Relay Info-Packagedraft-kaplan-dispatch-info-dtmf-package-00 Hadriel Kaplan
Terminology/Definitions • DTMF: Dual-Tone Multi-Frequency (tones) • KPML: Key-Press Markup Language (RFC 4730) • Hadriel: the messenger (don’t shoot)
The Problem • DTMF is just like other media: • It has to work • And like media, there is no one global “codec” • 2833/4733, INFO, KPML, Notify-1, Notify-2 • The DTMF world isn’t what we hoped it would be – it has not converged on one solution • It has to be “negotiated”
Why isn’t the World perfect? • DTMF needs to go the signaling path sometimes • SIP applications (calling card, IVR, etc.) • SIP to H.323/BICC/ISUP/etc. • Didn’t we solve this with KPML? • YES!!! • It’s the greatest solution ever devised! We’re geniuses! • But some pesky, horrible people seem to ignore us
What’s wrong with KPML? • Nothing. It’s just not that popular • Why? • Some systems prefer not to create two subscriptions for every call just in case someone presses a button someday • What they have “works” right now, so why fix it? • This is just a button press – why make it more complicated than that? • Lowest-common-denominator usually wins
What else is there? • INFO • At least 2 flavors: “dtmf-relay” is the big one • 3GPP has something too (but not really for this) • NOTIFY • At least 3 flavors, but not as popular • One flavor actually sends 2833 packets as its payload! (yes, each 2833 packet… so many, many Notify’s)
The Proposed Solution • Let the Wookie win: “standardize” the popular INFO one • It’s really, really simple (and it works) • Three ways to do that: • Publish an A-D sponsored RFC • Publish an individual RFC (non-IETF) • Publish an Info-Package • That was why we actually did Info-Packages, after all • Current draft picks #3
Will this succeed? • If we do an Info-Package for dtmf-relay would vendors go do that, vs. just legacy INFO? • I Dunno • Most of our issues/concerns with INFO never really applied to dtmf-relay • The Mime type was unique • The purpose of the INFO was unambiguous • The “negotiation” could be done with Accept header No problem to solve here, move along…
Options • I am not advocating a new mini-WG for this • Though I do have an acronym: Common Info Dtmf-Event-Relay (CIDER) • We could just ignore the whole topic • That hasn’t made it go away