Subject: [rtcweb] DTMF resolution proposal

From: Ted Hardie <[email-masked]>
Date: Mon, 7 Mar 2016 12:35:50 -0800

We've had about 60 or so messages on this topic, and the rough consensus
seems to be align this document with the limits set out in the W3C work
here:

https://www.w3.org/TR/webrtc/#rtcdtmfsender

However, there was also a proposal to slightly modify those limits.  They
are currently:

"The duration cannot be more than 6000 ms or less than 40 ms. The default
duration is 100 ms for each tone."

Based on Roman's note, a minimum of 40ms and a maximum 8000 ms to align
with the ITU and RFC2833.

To resolve this, I propose that we ask the WebRTC group to raise their max
to 8000 and, on receiving a positive response, publish this document with
40/8000 as the min and max.  If they give a negative response, we retain
40/6000.  This values alignment between the two documents higher than the
reference 2833, but that seems sensible in this context.

If you have an objection to this way forward, please send your reasoning to
the list by March 14th.

thanks,

Ted

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 7 Mar 2016 16:23:11 -0500

As proposed by Roman, I think we should also include the "minimum gap
of 30 ms". Otherwise, I support the proposal.

	Jean-Marc

On 03/07/2016 03:35 PM, Ted Hardie wrote:
> We've had about 60 or so messages on this topic, and the rough
> consensus seems to be align this document with the limits set out
> in the W3C work here:
> 
> However, there was also a proposal to slightly modify those limits.
>  They are currently:
> 
> "The duration cannot be more than 6000 ms or less than 40 ms. The 
> default duration is 100 ms for each tone."
> 
> Based on Roman's note, a minimum of 40ms and a maximum 8000 ms to
> align with the ITU and RFC2833.
> 
> To resolve this, I propose that we ask the WebRTC group to raise
> their max to 8000 and, on receiving a positive response, publish
> this document with 40/8000 as the min and max.  If they give a
> negative response, we retain 40/6000.  This values alignment
> between the two documents higher than the reference 2833, but that
> seems sensible in this context.
> 
> If you have an objection to this way forward, please send your
> reasoning to the list by March 14th.
> 
> thanks,
> 
> Ted
> 
> 
> 
> _______________________________________________ rtcweb mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 7 Mar 2016 14:19:00 -0800

On Mon, Mar 7, 2016 at 1:23 PM, Jean-Marc Valin <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
Thank you Jean-Marc; I had not thought to include that in my note, but I
agree.

regards,

Ted

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJW3fE5AAoJEJ6/8sItn9q9KDgH/j4bSutkSjUmvt6aTtt26qF6
> FKF2JMkrZc8pjSg6IDTq9MJradJr8WSzr27VSpedWOHHPFf5z4jDn6IpVVMyTUtP
> Jj6MvAPTyf9uB7UGq8rfA9y6az9OjChsJZ3j2/yPk7i/bnVYObg0OXOItyPA2+kA
> 7KCJAIWUiIBdfifKV8W1qre5DbUVi4iXnGIzbQ5KJIpxrO3Cxrq+vlPy7Gznc1a1
> o4B50DU6p3nBILGgCXpFwAMW5PBfco/oAOzCH90gqcM8hzEROW50LTJED/OP0K/b
> S3LMG3M+BriuAaslwW/Tj0qm3VUqtFpKaE3I0zjlxUbvfsxg/JYju2ebGSslZ7I=
> =dpJA
> -----END PGP SIGNATURE-----
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 8 Mar 2016 07:24:48 +0000

Would the text be crafted so that it pertains *only* to the RFC4733 digit packets emitted by a browser?

Information about gap between retransmission of the final packet could be useful as well and I suggest 20ms for that one.

Thanks,
Tolga

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Monday, March 07, 2016 5:19 PM
To: Jean-Marc Valin <[email-masked]>
Cc: Cullen Jennings <[email-masked]>; [email-masked]
Subject: Re: [rtcweb] DTMF resolution proposal

On Mon, Mar 7, 2016 at 1:23 PM, Jean-Marc Valin <[email-masked]<mailto:[email-masked]>> wrote:

Thank you Jean-Marc; I had not thought to include that in my note, but I agree.
regards,
Ted

        Jean-Marc

On 03/07/2016 03:35 PM, Ted Hardie wrote:
> list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 8 Mar 2016 19:57:02 -0500

Unless someone objects, I think the language would be:

WebRTC endpoints generated events MUST have duration of no more than 8000
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.

WebRTC endpoints limits this language to browsers and removes this
requirements from the gateways.

I do not think we should add any language about retransmission of the final
packets since this will cause another unnecessary debate (for instance I
think the value of 20 ms is wrong and it should be much shorter). If you
want to change this please write an update draft for RFC 4733 and we can
discuss it there.

Regards,
_____________
Roman Shpount

On Tue, Mar 8, 2016 at 2:24 AM, Asveren, Tolga <[email-masked]>
wrote:

> Would the text be crafted so that it pertains **only** to the RFC4733
> digit packets emitted by a browser?
>
>
>
> Information about gap between retransmission of the final packet could be
> useful as well and I suggest 20ms for that one.
>
>
>
> Thanks,
>
> Tolga
>
>
>
> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Ted Hardie
> *Sent:* Monday, March 07, 2016 5:19 PM
> *To:* Jean-Marc Valin <[email-masked]>
> *Cc:* Cullen Jennings <[email-masked]>; [email-masked]
> *Subject:* Re: [rtcweb] DTMF resolution proposal
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 8 Mar 2016 20:29:15 -0500

I'm not going to make a big deal out of this, but it feels to me like
the default duration should be in the W3C doc rather than in the IETF
doc since it describes browser behaviour rather than something can can
be observed on the wire. Of course, it doesn't hurt either, so I won't
object if people disagree with me.

Cheers,

	Jean-Marc

On 03/08/2016 07:57 PM, Roman Shpount wrote:
> WebRTC endpoints generated events MUST have duration of no more
> than 8000 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.
> 
> I do not think we should add any language about retransmission of
> the final packets since this will cause another unnecessary debate
> (for instance I think the value of 20 ms is wrong and it should be
> much shorter). If you want to change this please write an update
> draft for RFC 4733 and we can discuss it there.
> 
> Regards, _____________ Roman Shpount
> 
> On Tue, Mar 8, 2016 at 2:24 AM, Asveren, Tolga
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Would the text be crafted so that it pertains **only** to the 
> RFC4733 digit packets emitted by a browser? ____
> 
> __ __
> 
> Information about gap between retransmission of the final packet 
> could be useful as well and I suggest 20ms for that one.____
> 
> __ __
> 
> Thanks,____
> 
> Tolga____
> 
> __ __
> 
> *From:*rtcweb [mailto:[email-masked] 
> <mailto:[email-masked]>] *On Behalf Of *Ted Hardie *Sent:*
> Monday, March 07, 2016 5:19 PM *To:* Jean-Marc Valin
> <[email-masked] <mailto:[email-masked]>> *Cc:* Cullen
> Jennings <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]> *Subject:* Re: [rtcweb]
> DTMF resolution proposal____
> 
> __ __
> 
> On Mon, Mar 7, 2016 at 1:23 PM, Jean-Marc Valin
> <[email-masked] <mailto:[email-masked]>> wrote:____
> 
> As proposed by Roman, I think we should also include the "minimum
> gap of 30 ms". Otherwise, I support the proposal.____
> 
>> __ __
> 
>> Thank you Jean-Marc; I had not thought to include that in my
>> note, but I agree.____
> 
>> regards,____
> 
>> Ted____
> 
> 
>> ____
> 
> Jean-Marc____
> 
> 
>> consensus seems to be align this document with the limits set
>> out in the W3C work here:
> 
>> "The duration cannot be more than 6000 ms or less than 40 ms.
>> The default duration is 100 ms for each tone."
> 
>> Based on Roman's note, a minimum of 40ms and a maximum 8000 ms
>> to align with the ITU and RFC2833.
> 
>> between the two documents higher than the reference 2833, but
>> that seems sensible in this context.
> 
>> ____
>> list [email-masked] <mailto:[email-masked]>
> __ __
> list [email-masked] <mailto:[email-masked]>

---

From: Mark Harris <[email-masked]>
Date: Tue, 8 Mar 2016 20:44:21 -0800

Agreed.  Also I assume the intention is only to restrict DTMF events,
not any other audio/telephone-event events that an implementation
might wish to support, and that (like the duration) the minimum gap is
intended to apply to WebRTC-endpoint-generated DTMF events.  How about
this:

Each DTMF event generated by a WebRTC endpoint MUST have a duration no
less than 40 ms and no more than 8000 ms, and MUST begin no sooner
than 30 ms after the end of the last generated DTMF event if any.

 - Mark

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 9 Mar 2016 07:25:54 +0000

I agree with this Jean-Marc's position. If the goal is to aid applications/limit the range in the browser (this has been presented as the raison d'etre so far), it better is defined in W3C specification rather than being a factor for all WebRTC elements. This both makes logically more sense and also practically does not introduce restrictions, which are not needed to satisfy the requirement.

Thanks,
Tolga

> -----Original Message-----
> From: Jean-Marc Valin [mailto:[email-masked]]
> Sent: Tuesday, March 08, 2016 8:29 PM
> To: Roman Shpount <[email-masked]>; Asveren, Tolga
> <[email-masked]>
> Cc: Ted Hardie <[email-masked]>; Cullen Jennings <[email-masked]>;
> [email-masked]
> I'm not going to make a big deal out of this, but it feels to me like the default
> duration should be in the W3C doc rather than in the IETF doc since it
> describes browser behaviour rather than something can can be observed on
> the wire. Of course, it doesn't hurt either, so I won't object if people disagree
> with me.
> 
> Cheers,
> 
> 	Jean-Marc
> 
> > WebRTC endpoints generated events MUST have duration of no more than
> > 8000 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.
> >
> > I do not think we should add any language about retransmission of the
> > final packets since this will cause another unnecessary debate (for
> > instance I think the value of 20 ms is wrong and it should be much
> > shorter). If you want to change this please write an update draft for
> > RFC 4733 and we can discuss it there.
> >
> > On Tue, Mar 8, 2016 at 2:24 AM, Asveren, Tolga <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >
> > Information about gap between retransmission of the final packet could
> > be useful as well and I suggest 20ms for that one.____
> >
> > __ __
> >
> > Thanks,____
> >
> > Tolga____
> >
> > __ __
> >
> > Jennings <[email-masked] <mailto:[email-masked]>>; [email-masked]
> > <mailto:[email-masked]> *Subject:* Re: [rtcweb] DTMF resolution
> > proposal____
> >
> > __ __
> >
> > On Mon, Mar 7, 2016 at 1:23 PM, Jean-Marc Valin <[email-masked]
> > <mailto:[email-masked]>> wrote:____
> >
> > of 30 ms". Otherwise, I support the proposal.____
> >
> >> __ __
> >
> >> Thank you Jean-Marc; I had not thought to include that in my note,
> >> but I agree.____
> >
> >> regards,____
> >
> >> Ted____
> >
> >
> >> ____
> >
> > Jean-Marc____
> >
> >
> >> consensus seems to be align this document with the limits set out in
> >> the W3C work here:
> >
> >> their max to 8000 and, on receiving a positive response, publish this
> >> document with 40/8000 as the min and max.  If they give a negative
> >> response, we retain 40/6000.  This values alignment between the two
> >> documents higher than the reference 2833, but that seems sensible in
> >> this context.
> >
> >> _______________________________________________ rtcweb
> mailing list
> >> [email-masked] <mailto:[email-masked]>
> > _______________________________________________ rtcweb
> mailing list
> > [email-masked] <mailto:[email-masked]>
> iQEcBAEBCAAGBQJW33xoAAoJEJ6/8sItn9q9agEIAIDvDjcyiWb1jrDPRiPmY2z0
> uOtzfmdg7FurvbEM4uIn5S30DrbB1i5ncl2xTmM24/jIHKAVtr/pXbMt5jH5a/F8
> XMQs5zkgK7w1tP/EykJ3f2ti5pWc18Lia8rYMzKdm0GEwcUQMemUCZ+7WrqT
> 0N3p
> BHYPZY8B4qR/7TK+AquxcWUUZsQdPi3LaGcJwJF9+KwRKuXAQcEphUVs2SnF
> 48+F
> IMFlhRyT097gaz5lOFS36AeyS8SO1So8W1Y2hwGMIjmuHJAMJm4vN4E8JO4R4
> 9MF
> gsvqeYimx8YZtxJww02aBN/gauUwdecol5N6xXk3haWTgdgvBJjfWzRIOsSluVo
> =
> =WJ2n

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 9 Mar 2016 09:46:10 +0000

i- I personally would prefer not to leave a grey area (after all, the gap between retransmitted end-packets is another value, which needs to be known/determined/provided).

ii- I wouldn’t mind if the min-value for retransmission gap is 10ms, or even 0ms, and actually would prefer 0ms as it does not impose any restrictions (this all assuming –which IMHO is not the right choice- that the limits will be specified in rtcweb-audio draft rather than in W3C specification)

iii- It is not clear to me whether the use of the word “WebRTC endpoint” by default covers gateways as well. draft-ietf-rtcweb-gateways-02 has the following:
   A WebRTC gateway appears as a WebRTC-compatible endpoint, and will
   thus not be conformant with all requirements for a WebRTC endpoint
   (it does not do everything a WebRTC endpoint does), but is able to
   interoperate with WebRTC endpoints.
I interpret this as “Anything, which is mandated for webrtc-endpoints and not explicitly specified as not applicable for gateways in  rtcweb-gateway document is applicable for gateways too”, in which case I would suggest adding a statement to rtcweb-gateway document that RFC4733 limits do not apply to it (just trying to prevent the possibility of interworking).

iv- I don’t understand why retransmission gap limit would require RFC4733 update whereas the other limits under consideration don’t.

Thanks,
Tolga

From: Roman Shpount [mailto:[email-masked]]
Sent: Tuesday, March 08, 2016 7:57 PM
To: Asveren, Tolga <[email-masked]>
Cc: Ted Hardie <[email-masked]>; Jean-Marc Valin <[email-masked]>; Cullen Jennings <[email-masked]>; [email-masked]
Subject: Re: [rtcweb] DTMF resolution proposal

WebRTC endpoints generated events MUST have duration of no more than 8000 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.

WebRTC endpoints limits this language to browsers and removes this requirements from the gateways.

I do not think we should add any language about retransmission of the final packets since this will cause another unnecessary debate (for instance I think the value of 20 ms is wrong and it should be much shorter). If you want to change this please write an update draft for RFC 4733 and we can discuss it there.

Regards,
_____________
Roman Shpount

On Tue, Mar 8, 2016 at 2:24 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
Would the text be crafted so that it pertains *only* to the RFC4733 digit packets emitted by a browser?

Thanks,
Tolga

From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ted Hardie
Sent: Monday, March 07, 2016 5:19 PM
To: Jean-Marc Valin <[email-masked]<mailto:[email-masked]>>
Cc: Cullen Jennings <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] DTMF resolution proposal

        Jean-Marc

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Roman Shpount <[email-masked]>
Date: Wed, 9 Mar 2016 10:31:03 -0500

> object if people disagree with me.

I would prefer the recommended values to stay in audio draft.

This draft already specifies preferences, such as not using CN with OPUS,
so it would make sense to include DTMF tone and gap duration preferences as
well.

The recommendations are there to improve interoperability of WebRTC end
points with traditional PSTN, so it is not something that should be defined
by W3C document.

This data useful in providing guidance for interop tests for gateways,
SBCs. or any other equipment which is designed to work with WebRTC. I do
not think gateway implementer should go through the API document to find
the typical tone and gap duration for WebRTC.

Finally, I have proposed to include this data as non-normative, information
only value, so there is very little harm in it being there.

Regards,
_____________
Roman Shpount

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 9 Mar 2016 10:35:46 -0500

On 03/09/2016 10:31 AM, Roman Shpount wrote:

OK, I can live with that and include the text you proposed:

"WebRTC endpoints generated events MUST have duration of no more than
8000 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."

Cheers,

	Jean-Marc

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 9 Mar 2016 10:35:46 -0500

Cheers,

	Jean-Marc

> This draft already specifies preferences, such as not using CN with
> OPUS, so it would make sense to include DTMF tone and gap duration
> preferences as well.
> 
> The recommendations are there to improve interoperability of
> WebRTC end points with traditional PSTN, so it is not something
> that should be defined by W3C document.
> 
> This data useful in providing guidance for interop tests for 
> gateways, SBCs. or any other equipment which is designed to work 
> with WebRTC. I do not think gateway implementer should go through 
> the API document to find the typical tone and gap duration for 
> WebRTC.
> 
> Finally, I have proposed to include this data as non-normative, 
> information only value, so there is very little harm in it being 
> there.
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 9 Mar 2016 10:52:17 -0500

On Wed, Mar 9, 2016 at 4:46 AM, Asveren, Tolga <[email-masked]>
wrote:

> i- I personally would prefer not to leave a grey area (after all, the gap
> between retransmitted end-packets is another value, which needs to be
> known/determined/provided).
>

There are a lot of grey areas in how RFC 4733 tones are generated,
including how often tone update packets should be sent when tone is being
played, should audio signal be sent during tone generation, should audio
packets be sent during the tone generation, should tone duration and start
be extended to a regular, non-tone packet boundary, what interval should be
used for the end of tone packet. This group indicated that it is not
interested in defining any of these things and I would prefer to keep these
things out rtcweb-audio draft.

If you think (I definitely think so), that RFC 4733 can be improved with
the set of recommendations on how tones should be generated, this should be
discussed in a different group (avtcore or avtext) as either RFC 4733
update or an independent information draft. This information would not be
rtcweb specific and most likely benefit other VoIP implementations.

ii- I wouldn’t mind if the min-value for retransmission gap is 10ms, or
> even 0ms, and actually would prefer 0ms as it does not impose any
> restrictions (this all assuming –which IMHO is not the right choice- that
> the limits will be specified in rtcweb-audio draft rather than in W3C
> specification)
>

I believe anything network protocol related should be specified in one of
the IETF groups. If it is rtcweb specific it should go into one of the
rtcweb drafts. If it generic (like a general RFC 4733 update) it should be
done by the group responsible for this specification.

iii- It is not clear to me whether the use of the word “WebRTC endpoint” by
> default covers gateways as well. draft-ietf-rtcweb-gateways-02 has the
> following:
>
> I interpret this as “Anything, which is mandated for webrtc-endpoints and
> not explicitly specified as not applicable for gateways in  rtcweb-gateway
> document is applicable for gateways too”, in which case I would suggest
> adding a statement to rtcweb-gateway document that RFC4733 limits do not
> apply to it (just trying to prevent the possibility of interworking).
>

WebRTC endpoint is specifically different from WebRTC-compatible endpoint.
WebRTC-compatible endpoints do not have to implement OPUS or CN. They just
need to interop with full WebRTC endpoints.

iv- I don’t understand why retransmission gap limit would require RFC4733
> update whereas the other limits under consideration don’t.
>
>
>
As I have mentioned above, there is a lot more then just final packet
retransmission gap which is left to be implementation specific in RFC4733.
I have a feeling this group is tired of DTMF so if you want to discuss
this, we should discuss this elsewhere (avtcore or avtext). Whatever is
decided there will affect rtcweb as well as other RFC 4733 implementations.

Regards,
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 9 Mar 2016 16:09:52 +0000

“WebRTC endpoint is specifically different from WebRTC-compatible endpoint. WebRTC-compatible endpoints do not have to implement OPUS or CN. They just need to interop with full WebRTC endpoints.”
As the bottom line, would a gateway need to comply with the range restrictions for the RFC4733 it is sending toward the WebRTC leg or not? I *think* what you say is that it does not. I strongly would prefer that the text is clear on this issue.

Thanks,
Tolga

Sent: Wednesday, March 09, 2016 10:52 AM

On Wed, Mar 9, 2016 at 4:46 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
i- I personally would prefer not to leave a grey area (after all, the gap between retransmitted end-packets is another value, which needs to be known/determined/provided).

There are a lot of grey areas in how RFC 4733 tones are generated, including how often tone update packets should be sent when tone is being played, should audio signal be sent during tone generation, should audio packets be sent during the tone generation, should tone duration and start be extended to a regular, non-tone packet boundary, what interval should be used for the end of tone packet. This group indicated that it is not interested in defining any of these things and I would prefer to keep these things out rtcweb-audio draft.

If you think (I definitely think so), that RFC 4733 can be improved with the set of recommendations on how tones should be generated, this should be discussed in a different group (avtcore or avtext) as either RFC 4733 update or an independent information draft. This information would not be rtcweb specific and most likely benefit other VoIP implementations.

I believe anything network protocol related should be specified in one of the IETF groups. If it is rtcweb specific it should go into one of the rtcweb drafts. If it generic (like a general RFC 4733 update) it should be done by the group responsible for this specification.

WebRTC endpoint is specifically different from WebRTC-compatible endpoint. WebRTC-compatible endpoints do not have to implement OPUS or CN. They just need to interop with full WebRTC endpoints.

As I have mentioned above, there is a lot more then just final packet retransmission gap which is left to be implementation specific in RFC4733. I have a feeling this group is tired of DTMF so if you want to discuss this, we should discuss this elsewhere (avtcore or avtext). Whatever is decided there will affect rtcweb as well as other RFC 4733 implementations.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 9 Mar 2016 11:21:21 -0500

On Wed, Mar 9, 2016 at 11:09 AM, Asveren, Tolga <[email-masked]>
wrote:

>  “WebRTC endpoint is specifically different from WebRTC-compatible
> endpoint. WebRTC-compatible endpoints do not have to implement OPUS or CN.
> They just need to interop with full WebRTC endpoints.”
>
> As the bottom line, would a gateway need to comply with the range
> restrictions for the RFC4733 it is sending toward the WebRTC leg or not? I *
> *think** what you say is that it does not. I strongly would prefer that
> the text is clear on this issue.
>
>
>
WebRTC endpoints, such as browsers, will not do anything with RFC 4733
tones sent from the gateway, except gracefully drop them. There is
currently no API to inform JavaScript about the received DTMF or other RFC
4733 tones.

Do you want the language added to the specification that WebRTC endpoint
should be able to receive any RFC 4733 tones and process them in a graceful
manner?

I think I have previously proposed the following:

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.

This language was dropped as obvious, but can be included if you think is
necessary and no one objects.

Regards,
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 9 Mar 2016 16:52:00 +0000

“WebRTC endpoints, such as browsers, will not do anything with RFC 4733 tones sent from the gateway, except gracefully drop them. There is currently no API to inform JavaScript about the received DTMF or other RFC 4733 tones.

Do you want the language added to the specification that WebRTC endpoint should be able to receive any RFC 4733 tones and process them in a graceful manner?”

This sounds strange to me (using digits unidirectionally) but I would think that browser vendors should weigh in on this one. For me, the practically important point is that gateway can send RFC4733 digits toward the browser/native WebRTC app without being restricted by the defined range. There wouldn’t be any issue from my perspective if browsers are anyhow going to drop the digits (I assume this would be the same for native WebRTC application) but *if* things change so that they may process them, then I would prefer the text to be clear that the range restriction does not apply for digits from a gateway toward the browser/native app.

Thanks,
Tolga

Sent: Wednesday, March 09, 2016 11:21 AM

On Wed, Mar 9, 2016 at 11:09 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
 “WebRTC endpoint is specifically different from WebRTC-compatible endpoint. WebRTC-compatible endpoints do not have to implement OPUS or CN. They just need to interop with full WebRTC endpoints.”
As the bottom line, would a gateway need to comply with the range restrictions for the RFC4733 it is sending toward the WebRTC leg or not? I *think* what you say is that it does not. I strongly would prefer that the text is clear on this issue.

WebRTC endpoints, such as browsers, will not do anything with RFC 4733 tones sent from the gateway, except gracefully drop them. There is currently no API to inform JavaScript about the received DTMF or other RFC 4733 tones.

Do you want the language added to the specification that WebRTC endpoint should be able to receive any RFC 4733 tones and process them in a graceful manner?

This language was dropped as obvious, but can be included if you think is necessary and no one objects.

Regards,
_____________
Roman Shpount

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 Mar 2016 09:47:44 -0800

On Tue, Mar 8, 2016 at 5:29 PM, Jean-Marc Valin <[email-masked]> wrote:

> They should definitely be aligned, if included.  (Insert your favorite
"Why not both?" meme here).

Ted

> XMQs5zkgK7w1tP/EykJ3f2ti5pWc18Lia8rYMzKdm0GEwcUQMemUCZ+7WrqT0N3p
> BHYPZY8B4qR/7TK+AquxcWUUZsQdPi3LaGcJwJF9+KwRKuXAQcEphUVs2SnF48+F
> IMFlhRyT097gaz5lOFS36AeyS8SO1So8W1Y2hwGMIjmuHJAMJm4vN4E8JO4R49MF
> gsvqeYimx8YZtxJww02aBN/gauUwdecol5N6xXk3haWTgdgvBJjfWzRIOsSluVo=
> =WJ2n

---

From: Roman Shpount <[email-masked]>
Date: Wed, 9 Mar 2016 12:57:52 -0500

On Wed, Mar 9, 2016 at 11:52 AM, Asveren, Tolga <[email-masked]>
wrote:

> “WebRTC endpoints, such as browsers, will not do anything with RFC 4733
> manner?”
> This sounds strange to me (using digits unidirectionally) but I would
> think that browser vendors should weigh in on this one. For me, the
> practically important point is that gateway can send RFC4733 digits toward
> the browser/native WebRTC app without being restricted by the defined
> range. There wouldn’t be any issue from my perspective if browsers are
> anyhow going to drop the digits (I assume this would be the same for native
> WebRTC application) but **if** things change so that they may process
> them, then I would prefer the text to be clear that the range restriction
> does not apply for digits from a gateway toward the browser/native app.
>
>
>
>
> WebRTC enabled browsers are clients, so they do not normally need to
process digits. This is similar VoIP Phones, which will send RFC 4733 DTMF
tones but have no reason to process them.

Native applications can do whatever they want with the digits that they
receive.

So, does anybody needs the language that gateways can generate any RFC 4733
digits they like and WebRTC end point can ignore them?

Regards,
_____________
Roman Shpount