Support for DTMF tones A-D

[adamroach]

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.

[aboba]

I believe that this issue was addressed in PR 402.

[rshpount]

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]

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]

@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]

@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]

Further discussion on the list:
https://lists.w3.org/Archives/Public/public-webrtc/2015Dec/0004.html

[alvestrand]

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]

There isn't an issue tracker for rtcweb-audio. @aboba will have to monitor the list on this.

[aboba]

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]

Latest draft of https://tools.ietf.org/html/draft-ietf-rtcweb-audio now requires support for tones A-D.

[aboba]

I think this can be closed now.