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

[Ted Hardie <[e-mail]>]

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

> On Fri, Dec 18, 2015 at 2:34 PM, Ted Hardie <[e-mail]> wrote:
>
>> On Fri, Dec 18, 2015 at 10:32 AM, Roman Shpount <[e-mail]>
>> wrote:
>>
>>> Hi All,
>>>
>>> Since the decision not to support A-D DTMF digits was never made on the
>>> IETF list (I have looked through the archive and cannot find it), I do not
>>> think they should be removed.
>>>
>>>
>> ​Can you say more about what use there would be in supporting them?
>>
>
> First of all, DTMF support is there for legacy support.
> ​  ​​​I generally dislike when features are removed from an established
> capability set without a good reason.
>

​We have stretched very far in many directions to be reasonable in our
support of WebRTC to legacy use cases, but ​I don't think we can argue that
WebRTC has an established capability set that includes these, nor has
anyone given flows where a legacy system would reasonably emit them toward
a WebRTC client.


>
> ​Can anyone name me a single commercial PSTN VoIP gateway which does not
> support A-D DTMF tones? I cannot think of one. I believe it would generally
> make sense to implement whole set defined in
> https://tools.ietf.org/html/rfc4733#section-3.2 instead of just 3/4. From
> what I know there is no extra implementation to support A-D DTMF tone. It
> looks like these tones are removed for aesthetic reasons only.
>

​No, the point Cullen made was that they were sufficiently hit-or-miss in
terms of system blocking that they were effectively unreliable *in the
contexts where WebRTC and legacy might interact*.​



> As far as more specific examples are concerned:
>
> DTMF tones A-D are used to provide a way to access hidden flows in IVR
> systems. For instance, when inbound call center is integrated with an
> external auto-dialer, auto-dialer places a call to call center IVR and uses
> a hidden flow accessible via one of those tones to connect directly to a
> waiting agent.
>
> ​Given that they likely would block the receipt of those tones from
external clients in order to avoid this access from outside, this seems
like one of the cases that Cullen alluded to; it is permitted only part of
the time and the access it provides is not standard.​



> DTMF tones A-D are also commonly used by ham radio operators to integrate
> with PSTN, such as http://www.echolink.org/Help/dtmf_functions.htm
>
>
​This seems far outside our remit.​


> DTMF tone A-D are used to provide prioritized call handling service in ITU
> Q.955.3 specification which is still used by some PBX and phone systems.
>
>
​Again, not at all clear that a WebRTC client would ever expect to use
these features of a PBX.

Finally, some calling card like systems allow remote control of functions
> such as flash by mapping them to extended DTMF tones.
>
>
​If there is a calling card system using WebRTC, I have not heard of it.
Can you provide a pointer?​

​The main point here is that we need a consistent set.  I take it you do
agree with that point, and disagree only on whether the set should include
A-D.  Do I have that right?

Ted


Regards,
> _____________
> Roman Shpount
>
>