1 / 10

DTMF-Relay Info-Package draft-kaplan-dispatch-info-dtmf-package-00

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

landry
Télécharger la présentation

DTMF-Relay Info-Package draft-kaplan-dispatch-info-dtmf-package-00

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DTMF-Relay Info-Packagedraft-kaplan-dispatch-info-dtmf-package-00 Hadriel Kaplan

  2. Terminology/Definitions • DTMF: Dual-Tone Multi-Frequency (tones) • KPML: Key-Press Markup Language (RFC 4730) • Hadriel: the messenger (don’t shoot)

  3. 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” 

  4. 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

  5. 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

  6. 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)

  7. 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

  8. 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…

  9. 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

  10. Any Opinions?

More Related