Subject: [rtcweb] Comments regarding draft-ietf-rtcweb-audio-09

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Nov 2015 11:14:00 -0500

On Thu, Nov 5, 2015 at 1:57 AM, Cullen Jennings <[email-masked]> wrote:

> We would like to start the working group last call of
> draft-ietf-rtcweb-audio-09. Please send any comments to the list by the end
> of Nov 30.
>

The comments I have submitted last year are still not addressed (
https://www.ietf.org/mail-archive/web/rtcweb/current/msg13268.html):

In section 3, draft states that: "WebRTC clients are REQUIRED to be able to
generate and consume the following events" followed by list of RFC4733
events. What does it mean by "consume"? Does it mean receive without
failure, while ignoring its contents or actually processing the events and
exposing them to the end point user in some way?

Supported RFC4733 event list does not match events listed in section 6.2.2
W3C TR (http://www.w3.org/TR/webrtc/#methods-4). W3C also lists support for
DTMF digits A through D.

Should the document state the duration and gap recommendations for RFC 4733
tones from section 6.2.2 of W3C document?

I did not know there is a consensus on must implement of CN. This
is certainly not need for legacy interop.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 18 Nov 2015 13:34:53 -0500

Can someone confirm that my comments were received?

Thank You,

_____________
Roman Shpount

On Thu, Nov 5, 2015 at 11:14 AM, Roman Shpount <[email-masked]> wrote:

> In section 3, draft states that: "WebRTC clients are REQUIRED to be able
> to generate and consume the following events" followed by list of RFC4733
> Supported RFC4733 event list does not match events listed in section
> 6.2.2 W3C TR (http://www.w3.org/TR/webrtc/#methods-4). W3C also lists
> support for DTMF digits A through D.
>
> Should the document state the duration and gap recommendations for RFC
> 4733 tones from section 6.2.2 of W3C document?
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Nov 2015 13:14:53 -0700

My recollection of what the various WGs decided was 

1) browsers JS needed to be able to send DTMF 0-9,#, and * 

2) we did not need to be able to propagate received DTMF up the the JS API 

3) we did not want A to D at the JS level 

4) if the SDP had negotiated reliving DTMF, the browser could receive and discard it 

Does that match others people recollection ? Regardless of what we decided in the past, does it seem reasonable way forward?

(and Roman, yes your email made it to the list) 

> On Nov 18, 2015, at 11:34 AM, Roman Shpount <[email-masked]> wrote:
> 
> We would like to start the working group last call of draft-ietf-rtcweb-audio-09. Please send any comments to the list by the end of Nov 30.
> 
> The comments I have submitted last year are still not addressed (https://www.ietf.org/mail-archive/web/rtcweb/current/msg13268.html):
> 
> In section 3, draft states that: "WebRTC clients are REQUIRED to be able to generate and consume the following events" followed by list of RFC4733 events. What does it mean by "consume"? Does it mean receive without failure, while ignoring its contents or actually processing the events and exposing them to the end point user in some way? 
> 
> Supported RFC4733 event list does not match events listed in section 6.2.2 W3C TR (http://www.w3.org/TR/webrtc/#methods-4). W3C also lists support for DTMF digits A through D.
> 
> Should the document state the duration and gap recommendations for RFC 4733 tones from section 6.2.2 of W3C document?
> 
> I did not know there is a consensus on must implement of CN. This is certainly not need for legacy interop.
> 
> Regards,
> _____________
> Roman Shpount
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 18 Nov 2015 15:39:49 -0500

> 1) browsers JS needed to be able to send DTMF 0-9,#, and *

Section 7.2.2 of WebRTC PeerConnection (
https://w3c.github.io/webrtc-pc/#methods-10) says:

The tones parameter is treated as a series of characters. The characters 0
through 9, A through D, #, and * generate the associated DTMF tones. The
characters a to d are equivalent to A to D. The character ',' indicates a
delay of 2 seconds before processing the next character in the tones
parameter. All other characters must be considered unrecognized.

This certainly reads like A-D DTMF digits are supported.

> 2) we did not need to be able to propagate received DTMF up the the JS API

This was my understanding as well. I think in section 3 of
draft-ietf-rtcweb-audio some language stating that any RFC 4733 event (not
just DTMF and not just the ones listed in the table) should be consumed by
the decoder but should not be propagated to the JS API. I think what we
want is to make sure that nothing bad happens to the browser if it receives
an unexpected RFC 4733 event.

 So far the peer connection specification disagrees (see above).

4) if the SDP had negotiated receiving DTMF, the browser could receive and
> discard it

I agree. I would extend this to cover any RFC 4733 event, not just DTMF and
not just the DTMF tones listed in the table.

Section 7.2.2 of WebRTC PeerConnection (
https://w3c.github.io/webrtc-pc/#methods-10) also states:

The duration parameter indicates the duration in ms to use for each
character passed in the tones parameters. The duration cannot be more than
6000 ms or less than 40 ms. The default duration is 100 ms for each tone.

The interToneGap parameter indicates the gap between tones. It must be at
least 30 ms. The default value is 70 ms.

The browser may increase the duration and interToneGap times to cause the
times that DTMF start and stop to align with the boundaries of RTP packets
but it must not increase either of them by more than the duration of a
single RTP audio packet.

I believe this should also be stated in draft-ietf-rtcweb-audio.

Finally, was it ever decided that receivers MUST support RFC3389 CN for
streams encoded with G.711 or any other supported codec that does not
provide its own CN? I think it does not require anything more then a SHOULD
and should only affect the browsers. If CN is not supported and not
negotiated nothing especially bad will happen. Certainly there are enough
G.711 only end point that will not support CN, so making CN must implement
will require transcoding when it is completely unnecessary.

Does that match others people recollection ? Regardless of what we decided
> in the past, does it seem reasonable way forward?
>
>
I think current decisions regarding DTMF are already reflected in the
WebRTC W3C document. The path of least resistance would be to make sure
draft-ietf-rtcweb-audio states the same thing.

Regards,
_____________
Roman Shpount

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 18 Nov 2015 15:43:32 -0500

Hi Roman,

> Can someone confirm that my comments were received?

Sorry, my bad. See below.

> In section 3, draft states that: "WebRTC clients are REQUIRED to
> be able to generate and consume the following events" followed by
> list of RFC4733 events. What does it mean by "consume"? Does it
> mean receive without failure, while ignoring its contents or
> actually processing the events and exposing them to the end point
> user in some way?
> 
> Supported RFC4733 event list does not match events listed in
> section 6.2.2 W3C TR (http://www.w3.org/TR/webrtc/#methods-4). W3C
> also lists support for DTMF digits A through D.
> 
> Should the document state the duration and gap recommendations for 
> RFC 4733 tones from section 6.2.2 of W3C document?

The part relating to RFC4733 predates my involvement in this draft and
I'm not familiar with that RFC at all. Any text you'd like to suggest?

> is certainly not need for legacy interop.

IIRC, I've been told it was discussed at some interim meeting which I
did not attend myself. That being said, I think it makes sense for CN
to be a must so that the sender knows it can always use it. Any reason
you do not want a must on CN?

Cheers,

	Jean-Marc

---

From: Roman Shpount <[email-masked]>
Date: Thu, 19 Nov 2015 12:14:16 -0500

Hi Jean-Marc,

> I'm not familiar with that RFC at all. Any text you'd like to suggest?

If there is a general agreement that text needs to be synchronized with the
webrtc peer specifications I can try to write some language for the draft.

> you do not want a must on CN?

My understanding was that G.711 and CN are primarily needed to legacy
interop. If browser is communicating with a legacy end point through some
sort of ICE/DTLS-SRTP gateway, then it needs to support the same codecs as
legacy endpoint. There are plenty of legacy endpoints that support G.711
but do not support CN. Also, if browser is communicating with some sort of
non-browser service, such as conference bridge, and if this bridge
implements Opus codec, there is no real reason to implement CN. So, what I
want is to see is that CN a MUST(or a SHOULD) for browsers only, with
gateways and non-browsers allowed to implement G.711 only, only G.711 + CN,
Opus + G.711, or all three codecs.

Finally, if CN is not supported and not negotiated during call setup,
nothing bad will happen. I am not aware of any scenario where audio call
will fail to setup if CN fails to get negotiated. So, this probably makes
CN a SHOULD, not a MUST even for browsers.

Regards,
_____________
Roman Shpount