Repository navigation
Support for DTMF tones A-D #391
Description
The IETF RTCWEB discussions of which DTMF tones to require resulted in a decision to call for only numeric digits, plus "#" and "*". Currently, the WebRTC spec calls for mandatory support for "0 through 9, A through D, #, and *".
These should be harmonized. Lacking a compelling reason to support the seldom-used A through D tones, it seems we should simply remove them from the WebRTC spec.
Activity
Fix for Issue 391
aboba commentedon Nov 28, 2015
I believe that this issue was addressed in PR 402.
Fix for WebRTC 1.0 Issue 391 A-D in DTMF
rshpount commentedon Nov 28, 2015
There is no reason not to support A-D. Support for A-D DTMF tone generation requires no additional code. These codes, even though they are not present on standard DTMF keypads, are still used by some of the IVR systems for automated entry. It makes no sense to remove already implemented features with no discussion. It probably makes more sense to harmonize in the opposite direction (i.e. change the IETF draft).
fluffy commentedon Dec 1, 2015
The problem with A-D is they are often blocked and don't work consistently so inviting JS programmers to use them is what the moz guys would call a "foot gun issue". Any place you think you might want them, you probably want something else - like data channel. I think that was part of the discussion that lead to "lets just add what we have a real need for".
fluffy commentedon Dec 1, 2015
@aboba - FWIW ... I don't think PR 402 fixes this. It leaves me not understanding if the browser is going to do A-D or not. It seems like it might. Or perhaps it might not. That is the worst of all possible worlds for the developer. I'd rather have it be clear that these were going to work or they were not allowed.
rshpount commentedon Dec 1, 2015
@fluffy I agree the use case for A-D is marginal. But one could argue the same thing about all DTMF tones and that data channel is better tool for practically anything which uses DTMF tones. The only reason DTMF tones are there is legacy interop. From that point of view, I think it makes more sense to have the complete functionality block (RFC 4733 section 3). In the very least removing features should be discussed on IETF list first and once agreement is reached propagated to this specification. If there was a decision reached there, I have surely missed it.
aboba commentedon Dec 2, 2015
Further discussion on the list:
https://lists.w3.org/Archives/Public/public-webrtc/2015Dec/0004.html
alvestrand commentedon Dec 13, 2015
Leaving this bug open despite merging fixes until IETF RTCWEB discussion of DTMF as part of the WG Last Call for draft-ietf-rtcweb-audio has concluded.
alvestrand commentedon Jan 20, 2016
There isn't an issue tracker for rtcweb-audio. @aboba will have to monitor the list on this.
aboba commentedon Feb 4, 2016
Cullen has posted a "Summary of DTMF Issues":
https://mailarchive.ietf.org/arch/search/?email_list=rtcweb&gbt=1&index=A56A533P48krInTfd2CHWXTctNM
In this note, Adam indicates advocates requiring support for tones A-D:
https://mailarchive.ietf.org/arch/msg/rtcweb/19mpSa9mNuFEYpzbXRxn9oM0-eM
aboba commentedon Feb 22, 2016
Latest draft of https://tools.ietf.org/html/draft-ietf-rtcweb-audio now requires support for tones A-D.
Support for DTMF Tones
[-]Remove DTMF tones A-D[/-][+]Support for DTMF tones A-D[/+]aboba commentedon Feb 25, 2016
I think this can be closed now.