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

[Roman Shpount <[e-mail]>]

On Fri, Dec 18, 2015 at 4:44 PM, Ted Hardie <[e-mail]> wrote:

> 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.
>

There is no additional implementation burden to support DTMF tones A-D, so
there is no stretching as far as any additional work is concerned.

I can guarantee you that legacy systems will generate DTMF tones towards
WebRTC client. Offer/answer telephone event negotiation is normally by
directional. This normally enabled DTMF detection in PSTN gateways. So, if
you have any system that connects WebRTC client to PSTN network, and if the
person on PSTN network will press a keypad digit, this digit will be sent
to WebRTC client. Furthermore, it is common for DTMF digit detection to be
caused by talk off, i.e. some voice periodically triggers DTMF detection.
Finally, some gateways will also send ANS tones if the call hits a fax
machine, so WebRTC end point will get not only DTMF events, but events for
tone that someone just happened to enable on the gateway. Unless we want to
transcode media coming from PSTN, WebRTC client will need to deal with any
incoming telephone-events. All of this being said, it is up to WebRTC
client to decide what to do with the received events. I am fine with these
tones being discard as long as they are being discarded in a manner which
does not disrupt normal audio processing. This means no unexpected jitter
buffer adjustments, packet loss correction for the audio segment covered by
telephone-event, treating these packets as lost, or payload mismatch.


> ​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*.​
>

All DTMF are often unreliable. There are also enough cases when they are
absolutely reliable. In places where they have been used, they can continue
to be used for legacy interop. In cases where they were unreliable they
will continue to be unreliable. It is not our job to fix or change this.


> 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.​
>

This is absolutely incorrect. In this particular example auto-dialer is
running on a hosted platform and accesses the inbound call center over
public PSTN.


> 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.​
>

Why? I have already seen a few virtual ham radio stations with WebRTC
interface

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.
>

There are intranet WebRTC applications that access in-company legacy PBX
via a private gateway.

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?​
>

Once again, this would be a private WebRTC application used to place calls
through a gateway which is under control of the person who developer the
app.

​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?
>

I agree that we need a consistent set. I would also like that this set
would be defined once and will have no optional components. I do not want
to spent any more time discussion they API to discover which DTMF tones are
supported by a particular implementation. Including tones A-D removes any
excuses for such options.

Regards,
_____________
Roman Shpount