- From: Roman Shpount <roman@telurix.com>
- Date: Tue, 1 Dec 2015 16:39:41 -0500
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAD5OKxsWqTiBKgcLfkzrRQQu2AZr+ZgBpAMx25dVkP9+9M2jgQ@mail.gmail.com>
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."
Received on Tuesday, 1 December 2015 21:40:13 UTC