I have already submitted the WG last call comment:
https://www.ietf.org/mail-archive/web/rtcweb/current/msg15356.html
If there is a general agreement regarding what needs to be implemented, I
can propose the text for the draft. Most likely we will need a section
regarding RFC 4733 DTMF tones.
>From the WebRTC client implementation point of view it would be easier to
support DTMF tones A through D then to block them, so I would suggest going
that route. If all the people who used to write modem scripts managed to
deal with this issue, I am sure JavaScript programmers would be able to
successfully deal with 4 extra tones.
_____________
Roman Shpount
On Tue, Dec 1, 2015 at 3:25 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:
> [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."