Re: Issue 391: Remove DTMF tones A-D

On Thu, Dec 3, 2015 at 4:29 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

>
> This is a matter of conformance.
> If A-F get thrown away by the lower layers, because they conform to the
> IETF spec, and the API spec requires them to be handled, the client as a
> whole is not conformant to the API spec.
>
> So the only thing that makes sense is for our requirement to track
> what's in rtcweb-audio.
>

I agree that specifications should match. Why would anybody reply to my
comments regarding rtcweb-audio draft in the IETF list?

As it stands the DTMF specifications in peer connection specification were
discussed in detail and define which DTMF tones should be supported, tone
and pause duration, and how DTMF tones should be generated. DTMF section in
rtcweb-audio was not discussed. It was inherited from somewhere and author
did not have any incentive to update it.  It is under-specified and
confusing. Are we correcting this specification only because no one wants
to spend any time on fixing the rtcweb-audio draft?



> WRT clients' ease of handling: Next time you see a virtual keypad on
> your screen, look for the A-F keys. That's where the real difficulty of
> support comes in.
>
>
I am not quite sure what you mean here. Why should I care about virtual
keypads or applications that draw a telephone on the screen? DTMF tone
support is for generating DTMF tones needed for the specific application,
so someone can design the interface with a single DTMF button if this is
the only button needed for this IVR application. In fact it is quite common
for application like record a message and press pound. Alternatively
application can design an IVR interface that uses all 16 DTMF digits, as
quite a few automation systems remotely controlled over phones do. DTMF
support is for legacy interop. The problem with legacy is that if you
remove features in random something always breaks.

P.S. We are talking about support for DTMF tones A, B, C, and D. There is
no DTMF tone F.
_____________
Roman Shpount

Received on Thursday, 3 December 2015 10:11:29 UTC