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

[Roman Shpount <[e-mail]>]

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

>
> ​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 is completely unrelated. 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). Legacy PSTN will receive and handle them. If legacy PSTN
(gateway) sends DTMF tones to WebRTC end point (and it will, even though
they are not expected there), WebRTC endpoint can discard them, as long as
it does it nicely.



> ​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."​
>>
>
My intent is that there is an existing well understood functionality set
with its benefits (wide support) and faults (unreliability). This
functionality set is called DTMF. Why WebRTC needs to redefine this set is
beyond my understanding.


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

So, one out of four tones is used in this example.

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

Yes, they are using A-D set to provide priority dialing.


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

This is real with existing SIP interface being replaced by WebRTC.


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

And then they will be added back by some vendor who got a critical customer
who is using these tones for something.

Despite many words exchanged, I think our entire argument can be boiled
down to "let's remove these tones since they sometimes do not work and they
are ugly" vs "let's keep these tones since they are sometimes used and do
work on occasion."

P.S. I have proposed several other things in addition to tones A-D. Are
there any comments regarding adding the following:

Generated events MUST have duration of no more than 6000 ms and no
less than 40 ms with the recommended default duration of 100 ms for each
tone. The gap between events MUST be no less then 30 ms with the
recommended default duration of 70 ms. Event SHOULD start on a regular
audio packet border. Event and gap duration SHOULD be rounded up to the
next regular audio packet border.

During the time events are generated audio SHOULD NOT be sent for the
same audio stream. When gaps between events are generated, silence and not
the background audio SHOULD be sent using regular audio encoding.

If multiple audio sampling rates are supported, audio/telephone-event
payload SHOULD be present for each supported sampling rate. Endpoints
SHOULD use audio/telephone-event format parameters during the offer/answer
exchange to indicate which events are supported.

Receivers MUST be able to consume any audio/telephone-event events in such
a way that it will not generate audio artifacts, unexpected packet loss
concealment, jitter buffer adjustments, payload mismatches, or invalid RTCP
statistics calculation. Receivers MAY generate audio corresponding to the
received events but are also allowed to discard them in a manner that does
not affect regular audio processing.
_____________
Roman Shpount