Re: Issue 391: Remove DTMF tones A-D

[BA] I agree with Roman that this is primarily an issue with draft-ietf-rtcweb-audio Section 3, which says that "WebRTC endpoints are REQUIRED to be able to generate and consume the following events" (0-9, *, #).  Since there is no normative language about A-D, support for those characters is optional. 

In WebRTC 1.0 Section 6.2.2, it says that "The characters 0 through 9, A through D, #, and * generate the associated DTMF tones. The characters a to d are equivalent to A to D... All other characters MUST be considered unrecognized.".  Since there is no normative language, I don't read this as imposing a requirement to support A-D.  If an implementation chooses not to support A-D, it would consider those characters as "unrecognized" and throw an InvalidCharacterError exception for them. 

Draft tracker shows that draft-ietf-rtcweb-audio is in WG last call: 
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/history/

So if there is a desire to change the DTMF requirements in Section 3, that should be submitted as a WG last call comment. 

Roman Shpount said: 

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

Adam Roach opined: 

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

Received on Tuesday, 1 December 2015 20:26:12 UTC