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

[Roman Shpount <[e-mail]>]

Sorry,due to a finger slip the email went out too early. Here is the
proposed change:

OLD TEXT:
The audio/telephone-event media format as specified in [RFC4733].
WebRTC endpoints are REQUIRED to be able to generate and consume
the following events:

     +------------+--------------------------------+-----------+
     |Event Code  | Event Name                     | Reference |
     +------------+--------------------------------+-----------+
     | 0          | DTMF digit "0"                 |  RFC4733  |
     | 1          | DTMF digit "1"                 |  RFC4733  |
     | 2          | DTMF digit "2"                 |  RFC4733  |
     | 3          | DTMF digit "3"                 |  RFC4733  |
     | 4          | DTMF digit "4"                 |  RFC4733  |
     | 5          | DTMF digit "5"                 |  RFC4733  |
     | 6          | DTMF digit "6"                 |  RFC4733  |
     | 7          | DTMF digit "7"                 |  RFC4733  |
     | 8          | DTMF digit "8"                 |  RFC4733  |
     | 9          | DTMF digit "9"                 |  RFC4733  |
     | 10         | DTMF digit "*"                 |  RFC4733  |
     | 11         | DTMF digit "#"                 |  RFC4733  |
     +------------+--------------------------------+-----------+

NEW TEXT:

The audio/telephone-event media format as specified in [RFC4733].
WebRTC endpoints are REQUIRED to be able to generate the following
events:

     +------------+--------------------------------+-----------+
     |Event Code  | Event Name                     | Reference |
     +------------+--------------------------------+-----------+
     | 0          | DTMF digit "0"                 |  RFC4733  |
     | 1          | DTMF digit "1"                 |  RFC4733  |
     | 2          | DTMF digit "2"                 |  RFC4733  |
     | 3          | DTMF digit "3"                 |  RFC4733  |
     | 4          | DTMF digit "4"                 |  RFC4733  |
     | 5          | DTMF digit "5"                 |  RFC4733  |
     | 6          | DTMF digit "6"                 |  RFC4733  |
     | 7          | DTMF digit "7"                 |  RFC4733  |
     | 8          | DTMF digit "8"                 |  RFC4733  |
     | 9          | DTMF digit "9"                 |  RFC4733  |
     | 10         | DTMF digit "*"                 |  RFC4733  |
     | 11         | DTMF digit "#"                 |  RFC4733  |
     | 12         | DTMF digit "A"                 |  RFC4733  |
     | 13         | DTMF digit "B"                 |  RFC4733  |
     | 14         | DTMF digit "C"                 |  RFC4733  |
     | 15         | DTMF digit "D"                 |  RFC4733  |
     +------------+--------------------------------+-----------+

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

_____________
Roman Shpount

On Fri, Dec 18, 2015 at 1:32 PM, 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.
>
> Minimal DTMF tone duration and gap duration should be added to the
> document.
>
> The meaning of "consuming" RFC 4733 events by WebRTC endpoints is unclear.
>
> I suggest to change the following section of the document:
>
> OLD TEXT:
> The audio/telephone-event media format as specified in [RFC4733].
>       WebRTC endpoints are REQUIRED to be able to generate and consume
>       the following events:
>
>          +------------+--------------------------------+-----------+
>          |Event Code  | Event Name                     | Reference |
>          +------------+--------------------------------+-----------+
>          | 0          | DTMF digit "0"                 |  RFC4733  |
>          | 1          | DTMF digit "1"                 |  RFC4733  |
>          | 2          | DTMF digit "2"                 |  RFC4733  |
>          | 3          | DTMF digit "3"                 |  RFC4733  |
>          | 4          | DTMF digit "4"                 |  RFC4733  |
>          | 5          | DTMF digit "5"                 |  RFC4733  |
>          | 6          | DTMF digit "6"                 |  RFC4733  |
>          | 7          | DTMF digit "7"                 |  RFC4733  |
>          | 8          | DTMF digit "8"                 |  RFC4733  |
>          | 9          | DTMF digit "9"                 |  RFC4733  |
>          | 10         | DTMF digit "*"                 |  RFC4733  |
>          | 11         | DTMF digit "#"                 |  RFC4733  |
>          +------------+--------------------------------+-----------+
>
>
> _____________
> Roman Shpount
>
> On Fri, Dec 18, 2015 at 1:13 PM, Ted Hardie <[e-mail]> wrote:
>
>> The two issues that surfaced during this last call that needed resolution
>> were DTMF and comfort noise.  Based on the discussion, we believe that the
>> comfort noise requirement will be shifted to "WebRTC endpoints". The DTMF
>> language will aligned with the W3C specification and clarified that A-D are
>> not supported (as they will not be supported in the JavaScript).
>>
>> After the document is updated, the chairs plan to submit it to IETF last
>> call.
>>
>> regards,
>>
>> Ted, Cullen, Sean
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>