Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio

[Roman Shpount <[e-mail]>]

Also, some might find interesting what ham radio receivers typically look
like:

http://img3.ph.126.net/snBYUz0aHL9x7Fy2mh85MA==/1133499731230960393.jpg

and here is the microphone at higher resolution:

http://i.ebayimg.com/images/i/371238765810-0-1/s-l1000.jpg

As you can see it is designed to send A-D tones.
_____________
Roman Shpount

On Fri, Dec 18, 2015 at 8:12 PM, Roman Shpount <[e-mail]> wrote:

> On Fri, Dec 18, 2015 at 7:10 PM, Cullen Jennings (fluffy) <
> [e-mail]> wrote:
>
>>
>> On Dec 18, 2015, at 3:24 PM, Roman Shpount <[e-mail]> wrote:
>>
>> This applies to all DTMF tones, not A-D specifically. What I am saying is
>> that WebRTC endpoints must be able to generate all DTMF tones including A-D
>> and send them to legacy PSTN (gateway).
>>
>>
>> The thing people keep asking is why? what is the use case ?
>>
>> I don’t feel like I have seen an answer to this.
>>
>>
> Because there are IVR systems that use them. They are much less common
> then IVR systems that use 0-9 * and # but they do exist. I have provided 4
> examples of real IVR systems that use these tones. How many do you need to
> keep the extra tones? All these systems can probably be re-engineered not
> to use A-D tones, but since this is all legacy no one will spend the time.
>
> Your argument that these tones should be removed since they are sometimes
> blocked (When exactly? The only places I see them blocked are some
> international carriers) and would not work. The same applies to all DTMF
> tones. We should remove all telephone-events based on this logic.
>
> Most importantly I do not want optional tones. So, if we decide to remove
> A-D, they should not be allowed in the WebRTC API. If these tones are
> allowed in WebRTC API, everyone must implement them.
> _____________
> Roman Shpount
>
>