Subject: [rtcweb] Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 24 Feb 2016 13:31:21 -0800

The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document:
- 'WebRTC Audio Codec and Processing Requirements'
  <draft-ietf-rtcweb-audio-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2016-03-09. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document outlines the audio codec and processing requirements
   for WebRTC endpoints.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Feb 2016 16:42:35 -0500

Hi All,

There is still my comment which is not addressed. I was asking to add DTMF
tone duration normative information to this document to align it with  to
https://www.w3.org/TR/webrtc/#rtcdtmfsender.

In particular I proposed to add the following text to section 3:

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.

Regards,
_____________
Roman Shpount

On Wed, Feb 24, 2016 at 4:31 PM, The IESG <[email-masked]> wrote:

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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 25 Feb 2016 10:07:43 -0800

Mailman claims this was auto-discarded and it doesn't show in the archives,
so I'm forwarding.  I will separately check on why it got chucked.

regards,

Ted
---------- Forwarded message ----------
From: Jean-Marc Valin <[email-masked]>
Date: Wed, Feb 24, 2016 at 2:21 PM
Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC
Audio Codec and Processing Requirements) to Proposed Standard
To: Roman Shpount <[email-masked]>, [email-masked],
[email-masked], "[email-masked]" <[email-masked]>,
[email-masked]

> recommended default duration of 70 ms.

OK, I missed that part, but I'm fine with it. Unless anyone objects, I
can add it to the draft.

        Jean-Marc

> Regards,
> _____________
> Roman Shpount
>
> On Wed, Feb 24, 2016 at 4:31 PM, The IESG <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     [email-masked] <mailto:[email-masked]> mailing lists by 2016-03-09.
>     Exceptionally, comments may be
>     sent to [email-masked] <mailto:[email-masked]> instead. In either
>     case, please retain the
>     [email-masked] <mailto:[email-masked]>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 25 Feb 2016 19:44:42 +0000

Roman,

What is the rationale of having this "MUST" strength mandate?

Thanks,

Tolga

________________________________
From: rtcweb <[email-masked]> on behalf of Ted Hardie <[email-masked]>
Sent: Thursday, February 25, 2016 1:07 PM
To: [email-masked]
Subject: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

Mailman claims this was auto-discarded and it doesn't show in the archives, so I'm forwarding.  I will separately check on why it got chucked.

regards,

Ted
---------- Forwarded message ----------
From: Jean-Marc Valin <[email-masked]<mailto:[email-masked]>>
Date: Wed, Feb 24, 2016 at 2:21 PM
Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>

        Jean-Marc

> Regards,
> _____________
> Roman Shpount
>
> On Wed, Feb 24, 2016 at 4:31 PM, The IESG <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> mailing lists by 2016-03-09.
>     sent to [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> instead. In either
>     case, please retain the
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Feb 2016 15:58:28 -0500

Tolga,

In the proposed text I have copied the requirements from
https://www.w3.org/TR/webrtc/#rtcdtmfsender to make sure specifications are
consistent with each other. Here is the text present in WebRTC TR:

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.

I believe the limits in WebRTC TR are based on ITU-T Q.24, which are, in
turn, based on physical limitation imposed by transmitting DTMF tones using
8Khz audio. It is physically impossible to design an inband DTMF detector
which can detect DTMF digits of duration less then 40 ms with gaps less
then 30 ms and still be capable of handling talk off. This requirement is
the MUST level to provide minimal support necessary for PSTN interop.

Regards,
_____________
Roman Shpount

On Thu, Feb 25, 2016 at 2:44 PM, Asveren, Tolga <[email-masked]>
wrote:

> ------------------------------
> *From:* rtcweb <[email-masked]> on behalf of Ted Hardie <
> [email-masked]>
> *Sent:* Thursday, February 25, 2016 1:07 PM
> *To:* [email-masked]
> *Subject:* [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt>
> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard
>
> Mailman claims this was auto-discarded and it doesn't show in the
> archives, so I'm forwarding.  I will separately check on why it got chucked.
>
> regards,
>
> Ted

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 26 Feb 2016 08:38:23 +0100

Roman, you're the expert here - googling for the text unearthed this
message from you in 2013:

https://lists.w3.org/Archives/Public/public-webrtc/2013Apr/0030.html

Reviewiing that archive might save you the effort of repeating the
arguments again; at the moment, I have no idea where the upper limit
came from.

On 02/25/2016 09:58 PM, Roman Shpount wrote:
>  https://www.w3.org/TR/webrtc/#rtcdtmfsender to make sure
> specifications are consistent with each other. Here is the text
> present in WebRTC TR:
>
>     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.
>
>
> I believe the limits in WebRTC TR are based on ITU-T Q.24, which are,
> in turn, based on physical limitation imposed by transmitting DTMF
> tones using 8Khz audio. It is physically impossible to design an
> inband DTMF detector which can detect DTMF digits of duration less
> then 40 ms with gaps less then 30 ms and still be capable of handling
> talk off. This requirement is the MUST level to provide minimal
> support necessary for PSTN interop.
>
> Regards,
> _____________
> Roman Shpount
>
> On Thu, Feb 25, 2016 at 2:44 PM, Asveren, Tolga <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Roman,
>
>
>     ------------------------------------------------------------------------
>     *From:* rtcweb <[email-masked]
>     <mailto:[email-masked]>> on behalf of Ted Hardie
>     <[email-masked] <mailto:[email-masked]>>
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Subject:* [rtcweb] Fwd: Last Call:
>     <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and
>     Processing Requirements) to Proposed Standard
>      
>     From: *Jean-Marc Valin* <[email-masked]
>     <mailto:[email-masked]>>
>     Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-audio-10.txt>
>     To: Roman Shpount <[email-masked] <mailto:[email-masked]>>,
>     [email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, [email-masked]
>     <mailto:[email-masked]>
>
>
>     > On Wed, Feb 24, 2016 at 4:31 PM, The IESG
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> mailing lists by 2016-03-09.
>     >     sent to [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> instead. In either
>     >     case, please retain the
>     <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 26 Feb 2016 03:14:53 -0500

Hi Roman,

Just as a clarification, are we talking about the duration of RFC4733
tone events or the duration of audio tones (or both)? I agree that
going below 40 ms is just not possible. As for the upper bound, more
than 6000 ms is definitely insane, but I have no precise opinion on
the exact threshold that should be used, or why anyone would want such
long tones in the first place.

Cheers,

	Jean-Marc

On 02/25/2016 03:58 PM, Roman Shpount wrote:
> I believe the limits in WebRTC TR are based on ITU-T Q.24, which
> are, in turn, based on physical limitation imposed by transmitting
> DTMF tones using 8Khz audio. It is physically impossible to design
> an inband DTMF detector which can detect DTMF digits of duration
> less then 40 ms with gaps less then 30 ms and still be capable of
> handling talk off. This requirement is the MUST level to provide
> minimal support necessary for PSTN interop.
> 
> Regards, _____________ Roman Shpount
> 
> On Thu, Feb 25, 2016 at 2:44 PM, Asveren, Tolga
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Roman,
> 
> 
> ----------------------------------------------------------------------
- --
> <[email-masked] <mailto:[email-masked]>> *Sent:* Thursday,
> February 25, 2016 1:07 PM *To:* [email-masked]
> <mailto:[email-masked]> *Subject:* [rtcweb] Fwd: Last Call:
> <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing
> Requirements) to Proposed Standard
> 
> Ted ---------- Forwarded message ---------- From: *Jean-Marc Valin*
> <[email-masked] <mailto:[email-masked]>> Date: Wed, Feb 24,
> 2016 at 2:21 PM Subject: Re: [rtcweb] Last Call:
> <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing
> Requirements) to Proposed Standard To: Roman Shpount
> <[email-masked] <mailto:[email-masked]>>, 
>> 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.
> 
> OK, I missed that part, but I'm fine with it. Unless anyone
> objects, I can add it to the draft.
> 
> Jean-Marc
> 
> 
>> Regards, _____________ Roman Shpount
>> 
>> <mailto:[email-masked]
>> <mailto:[email-masked]>>> wrote:
>> 
>> 
>> The IESG has received a request from the Real-Time Communication
>> in WEB-browsers WG (rtcweb) to consider the following document: -
>> 'WebRTC Audio Codec and Processing Requirements' 
>> The IESG plans to make a decision in the next few weeks, and
>> solicits final comments on this action. Please send substantive
>> comments to the [email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked]
>> Exceptionally, comments may be sent to [email-masked]
>> <mailto:[email-masked]>
>> case, please retain the beginning of the Subject line to allow
>> automated sorting.
>> 
>> Abstract
>> 
>> 
>> This document outlines the audio codec and processing
>> requirements for WebRTC endpoints.
>> 
>> 
>> 
>> 
>> _______________________________________________ rtcweb mailing
>> list [email-masked] <mailto:[email-masked]>
> _______________________________________________ rtcweb mailing
> list [email-masked] <mailto:[email-masked]> 
> _______________________________________________ rtcweb mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 26 Feb 2016 11:19:55 +0000

i- I think w3org should have followed the lead of IETF in this issue rather than the other way around, i.e. the values recommended by the IETF specification should have been cited in the w3org document IMHO.

ii- The reasonable value range could depend on the negotiated codec and that would be known at the time of interesting the digits; so anything with MUST strength is too restrictive IMHO.

iii- The presence of transcoding/interworking (between different forms of digit transfer) devices (they will be there, whether we like it or not, for certain scenarios) makes it even less desirable to have MUST strength mandates.

iv- I think adding some text regarding gap/duration of digit packets could be fine but I rather would prefer it with "recommend" (even not RECOMMEND) (and providing some values only as examples).

Thanks,
Tolga

From: Harald Alvestrand [mailto:[email-masked]]
Sent: Friday, February 26, 2016 2:38 AM
To: Roman Shpount <[email-masked]>; Asveren, Tolga <[email-masked]>
Cc: [email-masked]
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

Roman, you're the expert here - googling for the text unearthed this message from you in 2013:

Reviewiing that archive might save you the effort of repeating the arguments again; at the moment, I have no idea where the upper limit came from.

In the proposed text I have copied the requirements from  https://www.w3.org/TR/webrtc/#rtcdtmfsender to make sure specifications are consistent with each other. Here is the text present in WebRTC TR:

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.

I believe the limits in WebRTC TR are based on ITU-T Q.24, which are, in turn, based on physical limitation imposed by transmitting DTMF tones using 8Khz audio. It is physically impossible to design an inband DTMF detector which can detect DTMF digits of duration less then 40 ms with gaps less then 30 ms and still be capable of handling talk off. This requirement is the MUST level to provide minimal support necessary for PSTN interop.

Regards,
_____________
Roman Shpount

On Thu, Feb 25, 2016 at 2:44 PM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

Roman,

Thanks,

Tolga

________________________________
From: rtcweb <[email-masked]<mailto:[email-masked]>> on behalf of Ted Hardie <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 25, 2016 1:07 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

---------- Forwarded message ----------
From: Jean-Marc Valin <[email-masked]<mailto:[email-masked]>>
Date: Wed, Feb 24, 2016 at 2:21 PM
Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>

        Jean-Marc

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

rtcweb mailing list

[email-masked]<mailto:[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Feb 2016 16:36:32 -0500

On Fri, Feb 26, 2016 at 2:38 AM, Harald Alvestrand <[email-masked]>
wrote:

> arguments again; at the moment, I have no idea where the upper limit came
> from.
>
>
Harald,

All I am trying to achieve is getting both WebRTC TR and
draft-ietf-rtcweb-audio say the same thing. The current tone duration
limitats are present in the W3C document. I do not necessarily agree with
these limitations, but I do know where they come from. I do think these
limitations should be reviewed by this group since they clearly define the
network related aspects of DTMF tone generation. Whatever is decided by
this group needs to be then replicated to W3C WebRTC document.

The minimum duration for tone and the gap in the W3C document comes from
ITU Q.24 specification.

The maximum duration of 6 seconds is something Cullen put in when he wrote
the document. Maximum duration of RFC 2833 tone or single segment RFC 4733
tone with 8 KHz RTP timestamps is about 8 seconds. If 48 KHz clock used,
max single segment tone duration would be about 1.3 sec. I have not seen
any implementations of RFC 4733 long duration events (
https://tools.ietf.org/html/rfc4733#section-2.5.1.3) in the wild since DTMF
tones are mostly used with 8 KHz clocks and no one really cares about DTMF
events longer then 8 sec. Support for multi-segment long duration DTMF
events would be necessary if someone will decide to use DTMF with Opus
since DTMF digits with duration longer then 1 sec are used by some IVR.

My personal preference (as expressed in the quoted message) not to specify
min and max duration for DTMF tones or gaps. I think having reasonable
default values is enough. If developer cares enough to adjust the duration
values, I assume he or she would know what they are doing. If they set
something silly, they will have to deal with the consequences.

Other people on the list wanted to limit the number of foot guns in the API
and decided to put reasonable min and max limits on tone and gap duration.
This is not my first preference, but I do not think these limits are
unreasonable, so I did not object too much.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Feb 2016 16:38:26 -0500

> long tones in the first place.

I think Cullen put the 6000 ms max limit in the specification. RFC 2833
tones have a limit of maximum duration of 8191 ms before the duration
counter overflows when 8 KHz clock is used.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Feb 2016 16:56:25 -0500

On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga <[email-masked]>
wrote:

> i- I think w3org should have followed the lead of IETF in this issue
> rather than the other way around, i.e. the values recommended by the IETF
> specification should have been cited in the w3org document IMHO.
>

I agree completely. I am not aware of any IETF document that defines DTMF
or RFC 4733 tone duration limits, so I proposed to add these limits to
draft-ietf-rtcweb-audio. Most importantly I wanted the text from W3C
reviewed in IETF since it was clearly a network related. Furthermore,
anybody implementing WebRTC compatible RTP audio interface should not need
to read the API document to find the network specific limits.

ii- The reasonable value range could depend on the negotiated codec and
> that would be known at the time of interesting the digits; so anything with
> MUST strength is too restrictive IMHO.
>

We know that RFC 4733 would be used to transmit DTMF tones from WebRTC
endpoints. RFC 4733 has no upper or lower limits on tone duration, so
technically these can be set to anything or not set at all. Some people
argue that we should limit number of foot guns for future API users, so
they wanted to have reasonable tone duration limits.

iii- The presence of transcoding/interworking (between different forms of
> digit transfer) devices (they will be there, whether we like it or not, for
> certain scenarios) makes it even less desirable to have MUST strength
> mandates.
>

Unfortunately I spend a significant amount of my time dealing with
transcoding elements (SBCs) dealing with RFC 4733 tones. Sending tones
which are too short or sent at high rates make such transcoding elements
generate unexpected or broken DTMF sequences. Reordered or interleaved
tones are commonly generated in response to such sequences. Extremely long
duration DTMF digits typically break into several digits. There is danger
in not having reasonable limits. The decision if API users should be
protected from this danger is up to this group.

iv- I think adding some text regarding gap/duration of digit packets could
> be fine but I rather would prefer it with “recommend” (even not RECOMMEND)
> (and providing some values only as examples).
>

I agree that having reasonable recommended values should be sufficient for
most cases. The group has to decide if it wants to protect the developers
from themselves and set MUST level limits on tone and gap duration.
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 27 Feb 2016 10:45:46 +0000

If I don’t mis/over-interpret Roman’s answer, it seems like at least some people who really care/have practical experience about this issue, e.g. Roman and myself, are in favor of not mandating any values and suggesting that w3org specification is updated accordingly. I personally would prefer nothing more than a (or two) sentence as a warning without using any keywords in rtcweb-audio. Does this sound a reasonable choice to other folks?

Thanks,
Tolga

From: Roman Shpount [mailto:[email-masked]]
Sent: Friday, February 26, 2016 4:56 PM
To: Asveren, Tolga <[email-masked]>
Cc: Harald Alvestrand <[email-masked]>; [email-masked]
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
i- I think w3org should have followed the lead of IETF in this issue rather than the other way around, i.e. the values recommended by the IETF specification should have been cited in the w3org document IMHO.

I agree completely. I am not aware of any IETF document that defines DTMF or RFC 4733 tone duration limits, so I proposed to add these limits to draft-ietf-rtcweb-audio. Most importantly I wanted the text from W3C reviewed in IETF since it was clearly a network related. Furthermore, anybody implementing WebRTC compatible RTP audio interface should not need to read the API document to find the network specific limits.

We know that RFC 4733 would be used to transmit DTMF tones from WebRTC endpoints. RFC 4733 has no upper or lower limits on tone duration, so technically these can be set to anything or not set at all. Some people argue that we should limit number of foot guns for future API users, so they wanted to have reasonable tone duration limits.

Unfortunately I spend a significant amount of my time dealing with transcoding elements (SBCs) dealing with RFC 4733 tones. Sending tones which are too short or sent at high rates make such transcoding elements generate unexpected or broken DTMF sequences. Reordered or interleaved tones are commonly generated in response to such sequences. Extremely long duration DTMF digits typically break into several digits. There is danger in not having reasonable limits. The decision if API users should be protected from this danger is up to this group.

iv- I think adding some text regarding gap/duration of digit packets could be fine but I rather would prefer it with “recommend” (even not RECOMMEND) (and providing some values only as examples).

I agree that having reasonable recommended values should be sufficient for most cases. The group has to decide if it wants to protect the developers from themselves and set MUST level limits on tone and gap duration.
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 27 Feb 2016 14:11:28 +0100

Den 27. feb. 2016 11:45, skrev Asveren, Tolga:
> If I don’t mis/over-interpret Roman’s answer, it seems like at least
> some people who really care/have practical experience about this issue,
> e.g. Roman and myself, are in favor of not mandating any values and
> suggesting that w3org specification is updated accordingly. I personally
> would prefer nothing more than a (or two) sentence as a warning without
> using any keywords in rtcweb-audio. Does this sound a reasonable choice
> to other folks?

At the WEBRTC API, this *will* lead to noninteroperable implementations,
since some browsers will enforce different limits from other browsers.

It's all coming back now - we decided to go with fixed limits in the
spec because it was inconcievable that implementations wouldn't impose
*some* limits, and the idea of adding API surface for probing what the
limits were was just too gross for such a low-value (relatively
speaking) feature.

> 
>  
> 
> Thanks,
> 
> Tolga
> 
>  
> 
> *From:*Roman Shpount [mailto:[email-masked]]
> *Sent:* Friday, February 26, 2016 4:56 PM
> *To:* Asveren, Tolga <[email-masked]>
> *Cc:* Harald Alvestrand <[email-masked]>; [email-masked]
> *Subject:* Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt>
>     rather than the other way around, i.e. the values recommended by the
>     IETF specification should have been cited in the w3org document IMHO.
> 
>  
> 
> I agree completely. I am not aware of any IETF document that defines
> DTMF or RFC 4733 tone duration limits, so I proposed to add these limits
> to draft-ietf-rtcweb-audio. Most importantly I wanted the text from W3C
> anybody implementing WebRTC compatible RTP audio interface should not
> need to read the API document to find the network specific limits.
> 
>  
> 
>     ii- The reasonable value range could depend on the negotiated codec
>     and that would be known at the time of interesting the digits; so
>     anything with MUST strength is too restrictive IMHO.
> 
>  
> 
>     iii- The presence of transcoding/interworking (between different
>     forms of digit transfer) devices (they will be there, whether we
>     like it or not, for certain scenarios) makes it even less desirable
>     to have MUST strength mandates.
> 
>  
> 
> tones are commonly generated in response to such sequences. Extremely
> long duration DTMF digits typically break into several digits. There is
> danger in not having reasonable limits. The decision if API users should
> be protected from this danger is up to this group.
> 
>  
> 
>     iv- I think adding some text regarding gap/duration of digit packets
>     could be fine but I rather would prefer it with “recommend” (even
>     not RECOMMEND) (and providing some values only as examples).
> 
>  
> 
> I agree that having reasonable recommended values should be sufficient
> for most cases. The group has to decide if it wants to protect the
> developers from themselves and set MUST level limits on tone and gap
> duration.
> 
> _____________
> Roman Shpount
> 
>  
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 27 Feb 2016 16:32:42 +0000

I don’t think browsers should be enforcing *any* limitations. It should be up to the application developer to decide what values to use. This would solve the problem and is the right approach anyhow IMHO.

Thanks,
Tolga

> -----Original Message-----
> Sent: Saturday, February 27, 2016 8:11 AM
> To: Asveren, Tolga <[email-masked]>; Roman Shpount
> <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt>
> > some people who really care/have practical experience about this
> > issue, e.g. Roman and myself, are in favor of not mandating any values
> > and suggesting that w3org specification is updated accordingly. I
> > personally would prefer nothing more than a (or two) sentence as a
> > warning without using any keywords in rtcweb-audio. Does this sound a
> > reasonable choice to other folks?
> 
> It's all coming back now - we decided to go with fixed limits in the spec
> because it was inconcievable that implementations wouldn't impose
> *some* limits, and the idea of adding API surface for probing what the limits
> were was just too gross for such a low-value (relatively
> speaking) feature.
> 
> 
> >
> >
> >
> > Thanks,
> >
> > Tolga
> >
> >
> >
> > *Subject:* Re: [rtcweb] Fwd: Last Call:
> > DTMF or RFC 4733 tone duration limits, so I proposed to add these
> > limits to draft-ietf-rtcweb-audio. Most importantly I wanted the text
> > from W3C reviewed in IETF since it was clearly a network related.
> > Furthermore, anybody implementing WebRTC compatible RTP audio
> > interface should not need to read the API document to find the network
> specific limits.
> >
> >
> >
> > technically these can be set to anything or not set at all. Some
> > people argue that we should limit number of foot guns for future API
> > users, so they wanted to have reasonable tone duration limits.
> >
> >
> >
> > which are too short or sent at high rates make such transcoding
> > elements generate unexpected or broken DTMF sequences. Reordered or
> > interleaved tones are commonly generated in response to such
> > sequences. Extremely long duration DTMF digits typically break into
> > several digits. There is danger in not having reasonable limits. The
> > decision if API users should be protected from this danger is up to this
> group.
> >
> >
> >

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Feb 2016 09:22:11 -0800

On Sat, Feb 27, 2016 at 8:32 AM, Asveren, Tolga <[email-masked]>
wrote:

> I don’t think browsers should be enforcing *any* limitations. It should be
> up to the application developer to decide what values to use.

So a tone of 2 hours duration is okay?  That seems pretty likely to trigger
the "multiple digits" issue that Roman pointed out for SBCs, for one thing.

Harald's point is that there are some clearly silly possibilities out
there, so some limitation will be there (1 hour, 3 minutes, 6000ms) and
that probing for what an implementation has chosen is much more complicated
here than makes sense.

> This would solve the problem and is the right approach anyhow IMHO.
>
>  Without any hats on, I think this is pretty unlikely work out well.

Ted

Thanks,
> limits

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 29 Feb 2016 18:29:09 +0000

There obviously are some values which are unreasonable but using sane values should be driven by the application. Browsers still can support some default values –to be used if application does not supply any value-, better based on the negotiated codec, for application developers, who are not savvy enough to pick a value. OTOH, what I am arguing against is browsers *enforcing* certain limits and rtcweb-audio specification mandating limits.

Thanks,
Tolga

From: Ted Hardie [mailto:[email-masked]]
Sent: Monday, February 29, 2016 12:22 PM
To: Asveren, Tolga <[email-masked]>
Cc: Harald Alvestrand <[email-masked]>; Roman Shpount <[email-masked]>; [email-masked]
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

On Sat, Feb 27, 2016 at 8:32 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
I don’t think browsers should be enforcing *any* limitations. It should be up to the application developer to decide what values to use.

So a tone of 2 hours duration is okay?  That seems pretty likely to trigger the "multiple digits" issue that Roman pointed out for SBCs, for one thing.

Harald's point is that there are some clearly silly possibilities out there, so some limitation will be there (1 hour, 3 minutes, 6000ms) and that probing for what an implementation has chosen is much more complicated here than makes sense.

> From: Harald Alvestrand [mailto:[email-masked]<mailto:[email-masked]>]
> To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; Roman Shpount
> <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> > *From:*Roman Shpount [mailto:[email-masked]<mailto:[email-masked]>]
> > *To:* Asveren, Tolga <[email-masked]<mailto:[email-masked]>>
> > *Cc:* Harald Alvestrand <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>
> > <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Feb 2016 10:35:33 -0800

On Mon, Feb 29, 2016 at 10:29 AM, Asveren, Tolga <[email-masked]>
wrote:

> There obviously are some values which are unreasonable but using sane
> values should be driven by the application
>

Okay, but the point of the max (6000ms) and min (40ms) is exactly that--to
make a common statement about what range is sane in this context.  Without
that, there would have to be API surface for discovering what was
considered sane; as Harald pointed out, that's going to get little use for
the complication it adds.

Do you disagree that these are sane values for a bound to the range?

regards,

Ted

> . Browsers still can support some default values –to be used if
> application does not supply any value-, better based on the negotiated
> codec, for application developers, who are not savvy enough to pick a
> value. OTOH, what I am arguing against is browsers **enforcing** certain
> limits and rtcweb-audio specification mandating limits.
>
>
>
> Thanks,
>
> Tolga
>
>
>
> *From:* Ted Hardie [mailto:[email-masked]]
> *Sent:* Monday, February 29, 2016 12:22 PM
> *Cc:* Harald Alvestrand <[email-masked]>; Roman Shpount <
> [email-masked]>; [email-masked]
>
> So a tone of 2 hours duration is okay?  That seems pretty likely to
> trigger the "multiple digits" issue that Roman pointed out for SBCs, for
> one thing.
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 29 Feb 2016 18:42:14 +0000

I am not sure whether 40ms should be absolute minimum for all codecs. Even for 6000ms, who am I to argue that somebody can’t come up with a use case/application, which requires something longer. So, overall, enforcing does not seem to be the right thing IMGO (default value is fine as already indicated) (and I don’t fully agree with your statement that “the point of min/max is promoting sane values” as the model you are describing is  “enforcing” a range rather than a default value in browser/recommendation in the specification).

Thanks,
Tolga

Sent: Monday, February 29, 2016 1:36 PM

On Mon, Feb 29, 2016 at 10:29 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
There obviously are some values which are unreasonable but using sane values should be driven by the application

Okay, but the point of the max (6000ms) and min (40ms) is exactly that--to make a common statement about what range is sane in this context.  Without that, there would have to be API surface for discovering what was considered sane; as Harald pointed out, that's going to get little use for the complication it adds.
Do you disagree that these are sane values for a bound to the range?
regards,
Ted

. Browsers still can support some default values –to be used if application does not supply any value-, better based on the negotiated codec, for application developers, who are not savvy enough to pick a value. OTOH, what I am arguing against is browsers *enforcing* certain limits and rtcweb-audio specification mandating limits.

Thanks,
Tolga

From: Ted Hardie [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, February 29, 2016 12:22 PM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>
Cc: Harald Alvestrand <[email-masked]<mailto:[email-masked]>>; Roman Shpount <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Feb 2016 11:07:08 -0800

On Mon, Feb 29, 2016 at 10:42 AM, Asveren, Tolga <[email-masked]>
wrote:

> I am not sure whether 40ms should be absolute minimum for all codecs. Even
> for 6000ms, who am I to argue that somebody can’t come up with a use
> case/application, which requires something longer. So, overall, enforcing
> does not seem to be the right thing IMGO (default value is fine as already
> indicated) (and I don’t fully agree with your statement that “the point of
> min/max is promoting sane values” as the model you are describing is
>  “enforcing” a range rather than a default value in browser/recommendation
> in the specification).
>
>
>
So, to put this in RFC 2119 terms, you believe these values should be at
SHOULD strength rather than MUST?  If that were the case but there were no
API surface to determine whether an implementation supported other values,
what, exactly would happen.

Ted

> *Sent:* Monday, February 29, 2016 1:36 PM
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 29 Feb 2016 20:08:25 +0100

Den 29. feb. 2016 19:42, skrev Asveren, Tolga:
> I am not sure whether 40ms should be absolute minimum for all codecs.
> Even for 6000ms, who am I to argue that somebody can’t come up with a
> use case/application, which requires something longer. So, overall,
> enforcing does not seem to be the right thing IMGO (default value is
> fine as already indicated) (and I don’t fully agree with your statement
> that “the point of min/max is promoting sane values” as the model you
> are describing is  “enforcing” a range rather than a default value in
> browser/recommendation in the specification).

The point of browswers enforcing min/max is to encourage (forcefully)
application writers to write applications that run in all browsers.

The point of mandating support up to min/max is to encourage browsers to
implement something that works with all conformant applications.

There's logic to this.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 29 Feb 2016 14:30:53 -0500

Hi All,

Just to be absolutely clear, there are no interconnected PSTN systems which
accept DTMF tones shorter then 40 ms with less then 30 ms gaps. RFC 4733
does not impose the minimum DTMF tone duration limit, so VoIP only systems
will take shorter tones. We routinely test SBCs and provider gateways on
how they handle extremely short DTMF tones. Quite a few of them break,
since tones and gaps need to be extended to generate valid PCMU/PCMA audio.

RFC 2833 had a maximum DTMF tone duration of 8191 ms after which the tone
duration counter overflowed (unsigned short int used to measure duration in
RTP units with 8 KHz clock). I am not aware of anyone who run into this
limit for any practical application.

So, as far as I can see we have two options for min duration:

a. Set the min tone duration limit to 40 ms and min gap limit to 30 ms.
These are minimum values accepted by national phone networks according to
ITU
b. Set the min tone duration and min gap to 0. These are the minimum values
possible with RFC 4733

I would prefer option b here, but this is mostly for testing. I would
understand if no one else would want this and go with PSTN based limits
(option a).

And we have two options for max duration:

a. Set max tone duration to 8000 ms (I would increase it from 6000ms to at
least have some reason for it).
b. Make max tone duration unlimited.

I would go with option a. No one needs tones longer then 8 s even for
testing.

I assume no one is against the default values of 100 ms tone and 70 ms gap.
I believe these values to be safe and reasonable.
>From interop experience I would also enforce starting and ending the tone
on the non tone packet boundary, but this can be an implementation specific.

This was all discussed to death in the webrtc group. Unfortunately it was
the wrong group to discuss this topic.

Regards,
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 29 Feb 2016 20:10:49 +0000

i- I don't know why we are trying to restrict the solution to PSTN/ITU recommendations. t certainly is possible that interworking is to be done to some other form of VoIP network.

ii- I think the core requirement is that we don't want application developers to use "wrong" values. There are two possibilities here:

- App developer knows what he is doing

In this scenario, he can supply the values to be used.

- App developer does not know much about DTMF digits

In this scenario, browser default values can be used. An application written by such a person still would run on all browsers as long as browsers supports *some* default value -not necessarily the same-.

IMHO, recommending some guidelines for app.developers and default values to be used by browsers (without any keywords) would provide a satisfactory solution for both scenarios.

Thanks,

Tolga

________________________________
From: Roman Shpount <[email-masked]>
Sent: Monday, February 29, 2016 2:30 PM
To: Asveren, Tolga
Cc: Ted Hardie; Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

On Mon, Feb 29, 2016 at 1:42 PM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
I am not sure whether 40ms should be absolute minimum for all codecs. Even for 6000ms, who am I to argue that somebody can't come up with a use case/application, which requires something longer. So, overall, enforcing does not seem to be the right thing IMGO (default value is fine as already indicated) (and I don't fully agree with your statement that "the point of min/max is promoting sane values" as the model you are describing is  "enforcing" a range rather than a default value in browser/recommendation in the specification).

Hi All,

Just to be absolutely clear, there are no interconnected PSTN systems which accept DTMF tones shorter then 40 ms with less then 30 ms gaps. RFC 4733 does not impose the minimum DTMF tone duration limit, so VoIP only systems will take shorter tones. We routinely test SBCs and provider gateways on how they handle extremely short DTMF tones. Quite a few of them break, since tones and gaps need to be extended to generate valid PCMU/PCMA audio.

RFC 2833 had a maximum DTMF tone duration of 8191 ms after which the tone duration counter overflowed (unsigned short int used to measure duration in RTP units with 8 KHz clock). I am not aware of anyone who run into this limit for any practical application.

a. Set the min tone duration limit to 40 ms and min gap limit to 30 ms. These are minimum values accepted by national phone networks according to ITU
b. Set the min tone duration and min gap to 0. These are the minimum values possible with RFC 4733

I would prefer option b here, but this is mostly for testing. I would understand if no one else would want this and go with PSTN based limits (option a).

a. Set max tone duration to 8000 ms (I would increase it from 6000ms to at least have some reason for it).
b. Make max tone duration unlimited.

I would go with option a. No one needs tones longer then 8 s even for testing.

I assume no one is against the default values of 100 ms tone and 70 ms gap. I believe these values to be safe and reasonable.
>From interop experience I would also enforce starting and ending the tone on the non tone packet boundary, but this can be an implementation specific.

This was all discussed to death in the webrtc group. Unfortunately it was the wrong group to discuss this topic.

Regards,
_____________
Roman Shpount

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Feb 2016 12:52:59 -0800

Howdy,
On Mon, Feb 29, 2016 at 12:10 PM, Asveren, Tolga <[email-masked]>

> - App developer knows what he is doing

You still have not answered the question of how the application discerns
what the bounds are for a browser, if they are not specified.

Also, assuming either 40/6000 (or even 40/8000, to follow Roman's recent
suggestion) are used in conformance with PSTN requirements, what is the
likelihood that the developer who knows what she's doing is going to select
something outside that range?

regards,

Ted

> *From:* Roman Shpount <[email-masked]>
> *Sent:* Monday, February 29, 2016 2:30 PM
> *To:* Asveren, Tolga
> *Cc:* Ted Hardie; Harald Alvestrand; [email-masked]
>> Even for 6000ms, who am I to argue that somebody can’t come up with a use
> Just to be absolutely clear, there are no interconnected PSTN systems
> which accept DTMF tones shorter then 40 ms with less then 30 ms gaps. RFC
> 4733 does not impose the minimum DTMF tone duration limit, so VoIP only
> systems will take shorter tones. We routinely test SBCs and provider
> gateways on how they handle extremely short DTMF tones. Quite a few of them
> break, since tones and gaps need to be extended to generate valid PCMU/PCMA
> audio.
>
> I assume no one is against the default values of 100 ms tone and 70 ms
> gap. I believe these values to be safe and reasonable.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 Feb 2016 17:15:53 -0700

> On Feb 26, 2016, at 2:38 PM, Roman Shpount <[email-masked]> wrote:
> 
> I think Cullen put the 6000 ms max limit in the specification. RFC 2833 tones have a limit of maximum duration of 8191 ms before the duration counter overflows when 8 KHz clock is used.

At the time we wanted a number that was less than 8 seconds (due to the limit above) and more than 4 seconds because some call centers use a "long pound" detection with times up to 4 seconds. So I made up a random number that was between 4 and 8 seconds that I hoped most people could live with. There was nothing special about 6 other than >4 and <8. 

For maximal interoperability, I still think we want to be between 4 and 8 seconds for the max.

Given that pretty much the only place these values are limits not really implemented is in the range of parameters values for the WebRTC insertDTMF function, I think the WebRTC spec is a fine place to specify them but don't think it will make any real world difference to interoperability if we move them from spec to another. I'm not of fan of putting two places as that makes it harder to update them and keep them in sync - the issue on sync is that the two standards organization approve revisions to specs on different time lines. 

As FYI ... the w3c spec for the function is at 

http://w3c.github.io/webrtc-pc/#widl-RTCDTMFSender-insertDTMF-void-DOMString-tones-unsigned-long-duration-unsigned-long-interToneGap