Re: Issue 391: Remove DTMF tones A-D

_____________
Roman Shpount

On Wed, Dec 9, 2015 at 1:48 PM, Cullen Jennings <fluffy@iii.ca> wrote:

>
> > 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 19:01:00 UTC