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

[Roman Shpount <[e-mail]>]

On Tue, Jan 26, 2016 at 7:15 AM, Tim Panton <[e-mail]> wrote:

>
> More specifically - Under what circumstances will we need them where
> the same result couldn’t be achieved by injecting the correct notes into
> the stream using webAudio?
> It has been suggested that webaudio tone generation might not work with
> certain sets of codecs.
> But surely the (few) legacy systems (coal mines for example) that use A-D
> will be using G711
> for which tone generation should work well.
>
> (I might add that tone _detection_ can also be done in webaudio so
> developers have a symmetrical solution).
>

Any tone generated using inband audio will be less reliable then
telephone-events tone. For telephone-events 3 or more packets in a row need
to be lost for the tone to be lost or interrupted. For inband loosing a
single packet can break tone in two distinct tones. I am not even talking
about all the extra work and interop required to properly implement tone
generation. To generate all DTMF tone telephone-events you need no extra
code in the browser you need no additional code.

Finally, if you want WebRTC to be backwards compatible with RFC 2833 (which
is the most common implementation of telephone-events in PSTN universe),
then you will need to deal with this
https://tools.ietf.org/html/rfc2833#section-3.3:

   A compliant implementation MUST support the events listed in Table 1
   with the exception of "flash". If it uses some other, out-of-band
   mechanism for signaling line conditions, it does not have to
   implement the other events.


Here is table 1 (https://tools.ietf.org/html/rfc2833#section-3.10):

   Table 1 summarizes the DTMF-related named events within the
   telephone-event payload format.

                     Event  encoding (decimal)
                     _________________________
                     0--9                0--9
                     *                     10
                     #                     11
                     A--D              12--15
                     Flash                 16

                     Table 1: DTMF named events


So, all DTMF digits 0-9, *, #, A-D are required by RFC 2833.

So, if you want to break backwards compatibility please explain your
motivation. These tones (as well as all the other telephone-events) are
only needed for backwards compatibility. Implemented all or some of them
requires the same amount of effort. Not implementing all of them will make
life harder for the few people who use them.

Finally, I have wrote several other things regarding DTMF tone generation
which are considerably more important. Does everyone agree with the
following or no one cares:

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 and event and gap duration SHOULD be rounded up to the next regular
audio packet border.

During the time events are generated no audio SHOULD 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 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, 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.

Regards,
_____________
Roman Shpount