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

[Jean-Marc Valin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Roman,

On 01/26/2016 02:59 PM, Roman Shpount wrote:
> 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:

The text below is what you propose for the rtcweb-audio draft? I
personally have no opinion on these events (see comment inline for
clarification though) so I'm happy to include that text if everyone
else is OK with it.

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

I think this would require a bit of clarification. What does "no
audio" mean here? Silence or no codec packets at all (in that case
what about PLC)? Also, keep in mind that any silence may not be
perfectly aligned with theoretical frame boundaries, due to look-ahead.

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

Cheers,

	Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWp9aBAAoJEJ6/8sItn9q9rMkH/1a1vSiUD48mxA2MN7WeHYV9
qGZl1Or69xJnOaG/67oyiwMg6E46BaxFi55Wqd5RAIqC9uNkKosk5HgbPbc+NM2Y
xaJxfDPXKnCPNiS7HxtUOTzGMysXOpOEkDKAF2EYCMyh6fQKhKJQxaRWFGgmctgj
0lOZnyk1NbQBhq8pWW3dFO0BiRCph/JLi3CH3HYA1YjMCi2n0JH6kmVSV57j1qQc
eTFdkuJIMF05f0I9224sAMYBhCMvw/r5tKM34b2SPwFMDZRixVsMfZT6oJfHorhg
jz8MIUcaiTezdGfUJ8OEFCRD3Qn3SrkWy1NEC+qUDpVwNZiUwE8uNRBu+PqSISw=
=1UJ7
-----END PGP SIGNATURE-----