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

[Ted Hardie <[e-mail]>]

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

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

​Sorry that this was not clear; I meant specifically A-D.​

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 seems to result in exactly the case Cullen was concerned about; if
they may be discarded their functionality remains completely unreliable.​
But more to the point, you are not pointing to uses of A-D, but number
detection and events which would still be covered.

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

​While this is no doubt not your intent, I must say your message reads as
"Sure it's broken now, but we must make sure it remains broken to be
backwards compatible."​



>
>
>> 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
>
>
​The only A-D tone in the one example you gave (echolink) was to pull up a
different stored configuration.



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

​And they are using the A-D set?
​


>
> 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.
>
>
​So this is theoretical.​



> ​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.
>
>
​Removing them from the set does as well, at least as far as I can tell.
No one has suggested that they be the subject of discovery or negotiation.​


​Ted
​

> Regards,
> _____________
> Roman Shpount
>
>