- From: Cullen Jennings <fluffy@iii.ca>
- Date: Wed, 9 Dec 2015 11:48:59 -0700
- To: Roman Shpount <roman@telurix.com>
- Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
> On Dec 1, 2015, at 2:39 PM, Roman Shpount <roman@telurix.com> wrote: > > 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. I want to be clear I don't care that much one way or the other about this but I want to try again to explain the issue... A to D will often be blocked by the system that sends them from one side to the other. So if you write JS applications that use theses, they will work some times and not others. That is just inviting developers to shoot themselves in the foot and no one has identified any benefit of adding A to D yet. 100% agree that the IETF and W3C specs need to align on this and we should change the ietf audio draft if we are including A-D. Cullen PS - Yes there sort is a F, F0, I and P as well as A to D and sometimes A means # not A. Here is a link to a photo of a not that unusual DTMF keypad https://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signaling#/media/File:66a3aDTMFpad.jpg The whole complexity that comes out of DTMF tones from that keypad is one of the reasons I don't think it is worth opening the A to D can of worms - even when we are done specifying it, it still won't work much of the time.
Received on Wednesday, 9 December 2015 18:49:26 UTC