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

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 1 Mar 2016 08:04:31 +0000

i- I thought I answered that aspect but here it goes again with an example:

App Developer, who knows what he is doing:
API call:
Send_DTMF_Digit(“5”, duration=2000ms, interval=60ms)
Browser uses the values supplied in the API call. It does not enforce any checks.
App. Developer may use different values based on the negotiated codec.

App Developer, who is not savvy about DTMF digits:
API call:
Send_DTMF_Digit(“5”)
Browser uses its default values for duration and interval.
Browser default values may be different based on the negotiated codec.
Different browsers may use different default values but this does not cause any problem from App. Dev. perspective.

Overall, browser never enforces a range. IT either uses what has been supplied by the API call directly or its default values.

ii- I think any enforced range is always guesswork and we may be limiting some use cases (people can be imaginative ;-) ). Especially a min of 40ms is too high IMHO. But as said, I don’t see a reason for the browser enforcing a range anyhow.

Thanks,
Tolga

From: Ted Hardie [mailto:[email-masked]]
Sent: Monday, February 29, 2016 3:53 PM
To: Asveren, Tolga <[email-masked]>
Cc: Roman Shpount <[email-masked]>; 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

Howdy,
On Mon, Feb 29, 2016 at 12:10 PM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
- 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

Thanks,

Tolga

________________________________
From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 29, 2016 2:30 PM
To: Asveren, Tolga
Cc: Ted Hardie; Harald Alvestrand; [email-masked]<mailto:[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.

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: Harald Alvestrand <[email-masked]>
Date: Tue, 1 Mar 2016 10:24:57 +0100

Den 01. mars 2016 09:04, skrev Asveren, Tolga:
> Different browsers may use different default values but this does not
> cause any problem from App. Dev. perspective.
> 

The other way to look at it:

App developer who doesn't know what he's doing:

Send_Dtmf_Digit("5", duration=10)

Runs on Chrome. It works on his test system. Deploys to a thousand users.

Someone runs it on Firefox.

"Illegal value".

Files a bug against Firefox. Wastes a lot of people's time.
In the meantime, the Chrome users discover that the DTMF-sending app
only works part of the time, and files bugs against Chrome for not
sending reliable DTMF.

Lots of time wasted for all. People's distrust of DTMF ever working
reliably goes up.

What's the benefit of NOT having a hard limit?

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 1 Mar 2016 10:17:43 +0000

Well, in your case, it is obviously app. developers fault to supply duration/interval without knowing what they mean/what he is doing (assuming those values are breaking something for whatever reason for that particular deployment). This would be a bug on the application/unintelligent behavior by the app. developer. I am for convenience and accommodating people who are not savvy about DMTF aspects but enforcing limits to guard against stupidity would sacrifice flexibility, which IMHO is another important aspect. And enforcing min/max would do exactly that, limiting flexibility.

Thanks,
Tolga 

> -----Original Message-----
> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Tuesday, March 01, 2016 4:25 AM
> To: Asveren, Tolga <[email-masked]>; Ted Hardie
> <[email-masked]>
> Cc: 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
> 
> only works part of the time, and files bugs against Chrome for not sending
> reliable DTMF.
> 
> Lots of time wasted for all. People's distrust of DTMF ever working reliably
> goes up.
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 1 Mar 2016 11:17:32 +0000

On 01/03/16 11:18, Asveren, Tolga wrote:
> Well, in your case, it is obviously app. developers fault to supply
> duration/interval without knowing what they mean/what he is doing
> (assuming those values are breaking something for whatever reason for
> that particular deployment). This would be a bug on the
> application/unintelligent behavior by the app. developer. I am for
> convenience and accommodating people who are not savvy about DMTF
> aspects but enforcing limits to guard against stupidity would
> sacrifice flexibility, which IMHO is another important aspect. And
> enforcing min/max would do exactly that, limiting flexibility.

I don't think increasing flexibility is a good reason per se. If that 
was the guiding principle all browser APIs would be on a very low level.

Is there a use case that can't be supported with the current spec?

Stefan

>
> Thanks, Tolga
>
>> -----Original Message----- From: Harald Alvestrand
>> [mailto:[email-masked]] Sent: Tuesday, March 01, 2016 4:25
>> AM To: Asveren, Tolga <[email-masked]>; Ted Hardie
>> <[email-masked]> Cc: 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
>>
>>> Different browsers may use different default values but this does
>>> not cause any problem from App. Dev. perspective.
>>>
>>
>> Files a bug against Firefox. Wastes a lot of people's time. In the
>> meantime, the Chrome users discover that the DTMF-sending app only
>> works part of the time, and files bugs against Chrome for not
>> sending reliable DTMF.
>>
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 1 Mar 2016 11:27:50 +0000

There are obviously different levels of flexibility. I am not arguing for changing the "level of abstraction" for the API. I just argue that enforcing limits *in the browser* is not a good idea.

When it comes to use cases setting limits based our imagination/agenda does not seem right to me. I think the high level principle should be the opposite: Do not add restrictions until absolutely necessary. One could have an application where pushing a digit for 10seconds triggers some special service/treatment. And 40ms is definitely too low of a value, I am aware of VoIP systems where lower values are used (but I definitely think that no enforced limit is the right thing to do rather than merely decreasing min).

Thanks,
Tolga

> From: Stefan Håkansson LK [mailto:[email-masked]]
> Sent: Tuesday, March 01, 2016 6:18 AM
> To: Asveren, Tolga <[email-masked]>; Harald Alvestrand
> <[email-masked]>; Ted Hardie <[email-masked]>
> Cc: [email-masked]
> I don't think increasing flexibility is a good reason per se. If that was the
> guiding principle all browser APIs would be on a very low level.
> 
> >> [mailto:[email-masked]] Sent: Tuesday, March 01, 2016 4:25 AM
> >>> Send_DTMF_Digit("5", duration=2000ms, interval=60ms)
> >>>
> >>> Send_DTMF_Digit("5")
> >> works part of the time, and files bugs against Chrome for not sending
> >> reliable DTMF.
> >>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 1 Mar 2016 11:35:57 +0000

On 01/03/16 12:27, Asveren, Tolga wrote:
> There are obviously different levels of flexibility. I am not arguing
> for changing the "level of abstraction" for the API. I just argue
> that enforcing limits *in the browser* is not a good idea.

I think differently. Having limits (based on real world 
experience/implementations and that allow agreed use cases to be 
supported) makes life easier for the app developer, the browser 
implementer and everyone involved in testing.

>
> When it comes to use cases setting limits based our
> imagination/agenda does not seem right to me. I think the high level
> principle should be the opposite: Do not add restrictions until
> absolutely necessary. One could have an application where pushing a
> digit for 10seconds triggers some special service/treatment. And 40ms
> is definitely too low of a value, I am aware of VoIP systems where
> lower values are used (but I definitely think that no enforced limit
> is the right thing to do rather than merely decreasing min).
>
> Thanks, Tolga
>
>> -----Original Message----- From: Stefan Håkansson LK
>> [mailto:[email-masked]] Sent: Tuesday, March 01,
>> 2016 6:18 AM To: Asveren, Tolga <[email-masked]>; Harald
>> Alvestrand <[email-masked]>; Ted Hardie <[email-masked]>
>> Cc: [email-masked] Subject: Re: [rtcweb] Fwd: Last Call:
>>> Well, in your case, it is obviously app. developers fault to
>>> supply duration/interval without knowing what they mean/what he
>>> is doing (assuming those values are breaking something for
>>> whatever reason for that particular deployment). This would be a
>>> bug on the application/unintelligent behavior by the app.
>>> developer. I am for convenience and accommodating people who are
>>> not savvy about DMTF aspects but enforcing limits to guard
>>> against stupidity would sacrifice flexibility, which IMHO is
>>> another important aspect. And enforcing min/max would do exactly
>>> that, limiting flexibility.
>>
>> I don't think increasing flexibility is a good reason per se. If
>> that was the guiding principle all browser APIs would be on a very
>> low level.
>>
>>>> [mailto:[email-masked]] Sent: Tuesday, March 01, 2016
>>>> 4:25 AM To: Asveren, Tolga <[email-masked]>; Ted Hardie
>>>> <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and
>>>> Processing Requirements) to Proposed Standard
>>>>
>>>>> Different browsers may use different default values but this
>>>>> does not cause any problem from App. Dev. perspective.
>>>>>
>>>>
>>>> Files a bug against Firefox. Wastes a lot of people's time. In
>>>> the meantime, the Chrome users discover that the DTMF-sending
>>>> app only works part of the time, and files bugs against Chrome
>>>> for not sending reliable DTMF.
>>>>
>>>> Lots of time wasted for all. People's distrust of DTMF ever
>>>> working reliably goes up.
>>>>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 1 Mar 2016 12:46:27 +0100

Den 01. mars 2016 11:17, skrev Asveren, Tolga:
> Well, in your case, it is obviously app. developers fault to supply duration/interval without knowing what they mean/what he is doing (assuming those values are breaking something for whatever reason for that particular deployment). This would be a bug on the application/unintelligent behavior by the app. developer. 

That's the part that I don't get.
I pointed out how the choice *not* to have hard limits imposes cost on a
lot of people - most of which are *not* the people doing the
unintelligent behavior.

And there's *no* mechanism for asking the app developer to pay for their
wasted time.

> I am for convenience and accommodating people who are not savvy about DMTF aspects but enforcing limits to guard against stupidity would sacrifice flexibility, which IMHO is another important aspect. And enforcing min/max would do exactly that, limiting flexibility.

Again - is there any *realistic* use case that is impossible when a
consistent min/max is enforced, and impossible when some other limits
are enforced?

Remember that *all* browsers *will* impose *some* limit.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 1 Mar 2016 17:00:14 +0000

So, you think that we shouldn’t expect that an App. Dev., who doesn’t know much about DTMF, can’t call the right API, which would use the browser defaults(despite explanations in relevant specifications)? I respectfully disagree. What about some other App. Dev., who calls APIs in a nilly-willy way, in the wrong order, with wrong values... Maybe we should have a single API: Make_Call(phone number)?!?

Thanks,
Tolga

> Sent: Tuesday, March 01, 2016 6:46 AM
> (assuming those values are breaking something for whatever reason for that
> particular deployment). This would be a bug on the application/unintelligent
> behavior by the app. developer.
> 
> I pointed out how the choice *not* to have hard limits imposes cost on a lot
> of people - most of which are *not* the people doing the unintelligent
> behavior.
> 
> > I am for convenience and accommodating people who are not savvy about
> DMTF aspects but enforcing limits to guard against stupidity would sacrifice
> flexibility, which IMHO is another important aspect. And enforcing min/max
> would do exactly that, limiting flexibility.
> 
> Again - is there any *realistic* use case that is impossible when a consistent
> min/max is enforced, and impossible when some other limits are enforced?
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 1 Mar 2016 13:26:48 -0500

> App. Developer may use different values based on the negotiated codec.
Can you please explain how negotiated codec will affect DTMF tone
generation? WebRTC end points will only send DTMF tones using RFC 4733
telephone events, so codec negotiation will not affect DTMF tone duration.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 1 Mar 2016 13:31:34 -0500

On Tue, Mar 1, 2016 at 6:27 AM, Asveren, Tolga <[email-masked]>
wrote:

>  And 40ms is definitely too low of a value, I am aware of VoIP systems
> where lower values are used (but I definitely think that no enforced limit

I assume you meant 40 ms is too high of the value. If you have an example
of an application (except testing apps) which is using a lower value,
please provide it to the list.
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 1 Mar 2016 18:40:08 +0000

Negotiated codec may reveal information about whether transcoding will happen (and it may be known a priori that all transcoded scenarios use a certain codec on the “legacy” side” etc…) or not depending on application/deployment model, e.g. AMR negotiated => no transcoding. It really depends on the use case/deployment model. I am not arguing this would be a generic/universal capability but may play a role. And if not, again nothing is really changing in my main argument: App. Developer can either supply the values or use the browser defaults.

Thanks,
Tolga

From: Roman Shpount [mailto:[email-masked]]
Sent: Tuesday, March 01, 2016 1:27 PM
To: Asveren, Tolga <[email-masked]>
Cc: Ted Hardie <[email-masked]>; 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 Tue, Mar 1, 2016 at 3:04 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
App. Developer may use different values based on the negotiated codec.

Can you please explain how negotiated codec will affect DTMF tone generation? WebRTC end points will only send DTMF tones using RFC 4733 telephone events, so codec negotiation will not affect DTMF tone duration.
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 1 Mar 2016 18:47:02 +0000

Ah yes, I meant too high…

i- As a general principle “Absence of proof does not mean proof of absence”. That you/I/x has not seen an application in their lifetime using a value lower than 40ms does not mean a use case does not exist/can’t exist in the future.

ii- As another general principle, introducing a restriction without a good reason is a bad idea IMHO. So far, I yet have to see a good argument in favor of an enforced range (other than that we should assume that intelligence level of app. developer’s is equal to a chimpanzee)

iii- I saw logs using values less than 40ms (and am aware of SBCs supporting lower than 40ms values) but I am not sure right now what was the emitting node (but again, this really shouldn’t be the determining factor in this debate; ii- is the main point IMHO for a clean solution).

Thanks,
Tolga

From: Roman Shpount [mailto:[email-masked]]
Sent: Tuesday, March 01, 2016 1:32 PM
To: Asveren, Tolga <[email-masked]>
Cc: Stefan Håkansson LK <[email-masked]>; Harald Alvestrand <[email-masked]>; Ted Hardie <[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 Tue, Mar 1, 2016 at 6:27 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
 And 40ms is definitely too low of a value, I am aware of VoIP systems where lower values are used (but I definitely think that no enforced limit is the right thing to do rather than merely decreasing min).

I assume you meant 40 ms is too high of the value. If you have an example of an application (except testing apps) which is using a lower value, please provide it to the list.
_____________
Roman Shpount

---

From: Ted Hardie <[email-masked]>
Date: Tue, 1 Mar 2016 10:58:20 -0800

Hi Tolga,

On Tue, Mar 1, 2016 at 10:47 AM, Asveren, Tolga <[email-masked]>
wrote:

>
>
> ii- As another general principle, introducing a restriction without a good
> reason is a bad idea IMHO. So far, I yet have to see a good argument in
> favor of an enforced range (other than that we should assume that
> intelligence level of app. developer’s is equal to a chimpanzee)
>
>
> This is not a fair characterization of the point that has been made, and
I'd appreciate your being careful with your wording.  The point that has
been made is that there will be a range imposed by browsers and that
standardizing that range avoids the complexity of discovery and/or random
failure modes.  If you are arguing that there will be no enforced range at
all, then the browser makers' assertion to the contrary seems to be
problematic for accepting your argument.

regards,

Ted

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 1 Mar 2016 19:02:24 +0000

“that there will be a range imposed by browsers”
Why are we assuming this? There should be some justification for this statement (and this is what I fail to see/understand but am really open to good explanation for the need for this). The model I presented has a “default value” for browsers not an “enforced range”. Those two are different things.

Thanks,
Tolga

From: Ted Hardie [mailto:[email-masked]]
Sent: Tuesday, March 01, 2016 1:58 PM
To: Asveren, Tolga <[email-masked]>
Cc: Roman Shpount <[email-masked]>; Stefan Håkansson LK <[email-masked]>; 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

Hi Tolga,

On Tue, Mar 1, 2016 at 10:47 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

This is not a fair characterization of the point that has been made, and I'd appreciate your being careful with your wording.  The point that has been made is that there will be a range imposed by browsers and that standardizing that range avoids the complexity of discovery and/or random failure modes.  If you are arguing that there will be no enforced range at all, then the browser makers' assertion to the contrary seems to be problematic for accepting your argument.
regards,
Ted

---

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

On Tue, Mar 1, 2016 at 11:02 AM, Asveren, Tolga <[email-masked]>
wrote:

> Why are we assuming this? There should be some justification for this
> statement (and this is what I fail to see/understand but am really open to
> good explanation for the need for this). The model I presented has a
> “default value” for browsers not an “enforced range”. Those two are
> different things.
>
>
>
We are assuming it because some of the browser vendors participating have
said so. Other data would be, of course, welcome.

Ted

Thanks,
>
> Tolga
>
>
>
> *From:* Ted Hardie [mailto:[email-masked]]
> *Sent:* Tuesday, March 01, 2016 1:58 PM
> *To:* Asveren, Tolga <[email-masked]>
> *Cc:* Roman Shpount <[email-masked]>; Stefan Håkansson LK <
> [email-masked]>; Harald Alvestrand <[email-masked]>;
> [email-masked]
> *Subject:* Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 3 Mar 2016 10:47:33 +0000

i- But is “X told so” really a technical argument and shouldn’t we base our decisions on technical aspects? What I am suggesting (browsers supporting “default” values instead of “enforced ranges”) has the technical merits that it both provides flexibility for application, which know what they are doing and need the flexibility, and at the same time covers the case of non-savvy users.

ii- RTCWeb is not only about browsers. There are gateways and native applications as well. RTCWeb specifications should cover use by all these types of entities IMHO.

Thanks,
Tolga

Sent: Wednesday, March 02, 2016 6:10 PM

On Tue, Mar 1, 2016 at 11:02 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
“that there will be a range imposed by browsers”
Why are we assuming this? There should be some justification for this statement (and this is what I fail to see/understand but am really open to good explanation for the need for this). The model I presented has a “default value” for browsers not an “enforced range”. Those two are different things.

We are assuming it because some of the browser vendors participating have said so. Other data would be, of course, welcome.
Ted

Thanks,
Tolga

From: Ted Hardie [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 01, 2016 1:58 PM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>
Cc: Roman Shpount <[email-masked]<mailto:[email-masked]>>; Stefan Håkansson LK <[email-masked]<mailto:[email-masked]>>; Harald Alvestrand <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

Hi Tolga,

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 3 Mar 2016 12:49:17 +0100

Den 03. mars 2016 11:47, skrev Asveren, Tolga:
> i- But is “X told so” really a technical argument and shouldn’t we base
> our decisions on technical aspects? What I am suggesting (browsers
> supporting “default” values instead of “enforced ranges”) has the
> technical merits that it both provides flexibility for application,
> which know what they are doing and need the flexibility, and at the same
> time covers the case of non-savvy users.

You've made this argument before. I cannot see that anything new has
been brought to the table that is likely to alter the WEBRTC WG
consensus to have these enforced limits.

> ii- RTCWeb is not only about browsers. There are gateways and native
> applications as well. RTCWeb specifications should cover use by all
> these types of entities IMHO.

The API is about a Javascript interface, and it is the remit of the W3C
WEBRTC WG. You're on the wrong list.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 3 Mar 2016 11:06:05 -0500

> consensus to have these enforced limits.

Am I correct to understand that WEBRTC WG decided that there should be
limits on DTMF tone generation and it is up to this group (IETF rtcweb) to
decide the exact values of these limits?

In this case, as I have stated before, the maximum tone duration should be
8000 ms to match possible tone duration for RFC 2833 DTMF tone. RFC 2833
was in use for the past 15 years and no one reported any issues with this
limit.

Minimum tone duration of 40 ms and minimum gap duration of 30 ms are
minimum physically required to transmit DTMF tone as 8 KHz audio signal and
still satisfy the talk-off specifications. These limitations have not
caused any practical issues for the past 50 years. I would like to mention
that shorter tones are used during call setup since it can be guaranteed
that no audio signal is present and talk-off requirements are relaxed.
Furthermore VoIP only networks, which use RFC 2833/RFC 4733 tones, can
support tones and gaps of anything from 0 ms and up. This is why I
initially advocated for 0 ms min duration. On the other hand if the group
decides that removing one more potential foot gun is more important, I will
not be too upset.

If anybody can come up with the practical example where tones longer then 8
sec or shorter then 40 ms with less then 30 ms gaps are used, please report
them to the list. Otherwise, let's document what is in W3C TR and move on.

Regards,
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 3 Mar 2016 17:45:57 +0100

Den 03. mars 2016 17:06, skrev Roman Shpount:
> On Thu, Mar 3, 2016 at 6:49 AM, Harald Alvestrand <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> limits on DTMF tone generation and it is up to this group (IETF rtcweb)
> to decide the exact values of these limits?

Formally, the RTCWEB group can advise the WEBRTC group about appropriate
values, but in practice, the result is indistinguishable from your
formulation :-)

> In this case, as I have stated before, the maximum tone duration should
> be 8000 ms to match possible tone duration for RFC 2833 DTMF tone. RFC
> 2833 was in use for the past 15 years and no one reported any issues
> with this limit.
> 
> minimum physically required to transmit DTMF tone as 8 KHz audio signal
> and still satisfy the talk-off specifications. These limitations have
> not caused any practical issues for the past 50 years. I would like to
> mention that shorter tones are used during call setup since it can be
> guaranteed that no audio signal is present and talk-off requirements are
> relaxed. Furthermore VoIP only networks, which use RFC 2833/RFC 4733
> tones, can support tones and gaps of anything from 0 ms and up. This is
> why I initially advocated for 0 ms min duration. On the other hand if
> the group decides that removing one more potential foot gun is more
> important, I will not be too upset.
> 
> If anybody can come up with the practical example where tones longer
> then 8 sec or shorter then 40 ms with less then 30 ms gaps are used,
> please report them to the list. Otherwise, let's document what is in W3C
> TR and move on.

Sounds good.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 4 Mar 2016 10:34:10 +0000

i- I don't think satisfactory technical explanation is provided why "enforcing a range" is superior to a "default range". I will leave this here and obviously this is just my personal -but honest- opinion.

ii- I got confused about what WEBRTC WG refers to, maybe to W3C? If so, is rtcweb-audio specification only about browsers? I wouldn’t think so. There are other types of entities playing in the RTCWeb domain, e.g. gateways. The limits we are talking about, are they applicable only for digits sent by browsers? What about digits emitted by a native application or a gateway? Will a browser be able to accept them if they are out of the range (assuming that the final outcome is to use enforced ranges)?

iii- Just as an example, I am aware of systems, which can detect digits <40ms.

iv- What about the gap between the final packet (with E-bit set) retransmissions? 

v- As use cases for the need for longer duration (all these are based on the same deployment model: A "legacy" application controlled by phone needs to be extended so that it can be accessed by Internet connected devices, e.g. a web-book. DataChannel is not used, e.g. not supported by gateway, by application etc..., hence digits are used for control.

- TV gaming show
User registers for the game and is selected for that day's show.
The user sees what is happening on the game on his TV and controls it by digits
The game (balloon escape) requires that at the beginning the user pumps air into the balloon. This is done by continuously pressing "5"

- Remote valve/door/lock control
Authorized person makes a call and then continuously presses "6" to keep the valve/door/lock open for that period.

- Panic button
An application for women who are mistreated by their husbands. Police/Social service workers rush to the registered address if she presses "7" continuously for longer than 10 seconds.

I am just trying to show that there are many different/imaginative ways using the "digit UI".

Thanks,
Tolga

> Sent: Thursday, March 03, 2016 11:46 AM
> To: Roman Shpount <[email-masked]>
> Cc: Asveren, Tolga <[email-masked]>; Ted Hardie
> <[email-masked]>; Stefan Håkansson LK
> <[email-masked]>; [email-masked]
> > On Thu, Mar 3, 2016 at 6:49 AM, Harald Alvestrand
> > <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > limits on DTMF tone generation and it is up to this group (IETF
> > rtcweb) to decide the exact values of these limits?
> 
> values, but in practice, the result is indistinguishable from your formulation :-
> )
> 
> > In this case, as I have stated before, the maximum tone duration
> > should be 8000 ms to match possible tone duration for RFC 2833 DTMF
> > tone. RFC
> > minimum physically required to transmit DTMF tone as 8 KHz audio
> > signal and still satisfy the talk-off specifications. These
> > limitations have not caused any practical issues for the past 50
> > years. I would like to mention that shorter tones are used during call
> > setup since it can be guaranteed that no audio signal is present and
> > talk-off requirements are relaxed. Furthermore VoIP only networks,
> > which use RFC 2833/RFC 4733 tones, can support tones and gaps of
> > anything from 0 ms and up. This is why I initially advocated for 0 ms
> > min duration. On the other hand if the group decides that removing one
> > more potential foot gun is more important, I will not be too upset.
> >
> > please report them to the list. Otherwise, let's document what is in
> > W3C TR and move on.
> 
> Sounds good.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 4 Mar 2016 11:46:36 +0100

> i- I don't think satisfactory technical explanation is provided why "enforcing a range" is superior to a "default range". I will leave this here and obviously this is just my personal -but honest-…

I interpret this as "the explanations that have been given do not
convince me".
Sorry about that.

> ii- I got confused about what WEBRTC WG refers to, maybe to W3C? If so, is rtcweb-audio specification only about browsers?

Again, for the umpteenth time:
The hard limits are *not* in rtcweb-audio. They're in the WEBRTC WG
(which is a WG of the W3C, not the IETF) API specification.

> I wouldn’t think so. There are other types of entities playing in the RTCWeb domain, e.g. gateways. The limits we are talking about, are they applicable only for digits sent by browsers? What about digits emitted by a native application or a gateway? Will a browser be able to accept them if they are out of the range (assuming that the final outcome is to use enforced ranges)?

If you don't understand which parts of the spec are done by the IETF and
which by the W3C, some more reading might be in order.
And if you don't have any experience in designing Javascript APIs, you
might want to talk to someone who has that experience.

> The game (balloon escape) requires that at the beginning the user pumps air into the balloon. This is done by continuously pressing "5"

Reference? To a game that actually works on current (mobile) phones?

> I am just trying to show that there are many different/imaginative ways using the "digit UI".

If you want to assert an use case, please assert one that is seen in the
real world.

The whole DTMF stuff is a wart that was added to the specification to
address use cases with real, existing, deployed hardware. It was not a
goal to stimulate people to imagine new ways in which DTMF could be used.

It remains a wart. It's a design goal to keep the cost of supporting the
wart low.
Removing the limits in the API would raise the support cost.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 4 Mar 2016 11:22:56 +0000

(I feel some "unfriendliness" in the reply I received but that is probably just my misinterpretation ;-) )

i- I understand very well what is defined by W3C and what by IETF RTCWEB WG. The point I am trying to make is that in this issue, the order of events seem to be upside-down to me as what is specified in the rtcweb-audio is not only applicable for browsers. And, what prevents W3C to enforce limits in the API even if such limits are not cited in rtcweb-audio?

ii- As far as use cases are concerned, your point seems to be "If it is not done until done, it does not need to be covered". I disagree but will leave this one here as well as I don’t have anything to add.

iii- Just so that they are not lost; would appreciate answers about systems detecting digits with <40ms duration and about the gap between the final packet retransmissions.

Thanks,
Tolga

> Sent: Friday, March 04, 2016 5:47 AM
> To: Asveren, Tolga <[email-masked]>; Roman Shpount
> <[email-masked]>
> Cc: Ted Hardie <[email-masked]>; Stefan Håkansson LK
> > i- I don't think satisfactory technical explanation is provided why "enforcing
> a range" is superior to a "default range". I will leave this here and obviously
> this is just my personal -but honest- opinion.
> 
> I interpret this as "the explanations that have been given do not convince
> me".
> Sorry about that.
> 
> > ii- I got confused about what WEBRTC WG refers to, maybe to W3C? If so, is
> rtcweb-audio specification only about browsers?
> 
> The hard limits are *not* in rtcweb-audio. They're in the WEBRTC WG (which
> is a WG of the W3C, not the IETF) API specification.
> 
> > I wouldn’t think so. There are other types of entities playing in the RTCWeb
> domain, e.g. gateways. The limits we are talking about, are they applicable
> only for digits sent by browsers? What about digits emitted by a native
> application or a gateway? Will a browser be able to accept them if they are
> out of the range (assuming that the final outcome is to use enforced
> ranges)?
> 
> 
> And if you don't have any experience in designing Javascript APIs, you might
> want to talk to someone who has that experience.
> 
> >
> > v- As use cases for the need for longer duration (all these are based on the
> same deployment model: A "legacy" application controlled by phone needs
> to be extended so that it can be accessed by Internet connected devices,
> e.g. a web-book. DataChannel is not used, e.g. not supported by gateway, by
> application etc..., hence digits are used for control.
> >
> > - TV gaming show
> > The user sees what is happening on the game on his TV and controls it
> > by digits The game (balloon escape) requires that at the beginning the user
> pumps air into the balloon. This is done by continuously pressing "5"
> 
> 
> > Authorized person makes a call and then continuously presses "6" to keep
> the valve/door/lock open for that period.
> >
> > - Panic button
> > An application for women who are mistreated by their husbands.
> Police/Social service workers rush to the registered address if she presses "7"
> continuously for longer than 10 seconds.
> >
> If you want to assert an use case, please assert one that is seen in the real
> world.
> 
> address use cases with real, existing, deployed hardware. It was not a goal to
> stimulate people to imagine new ways in which DTMF could be used.
> 
> It remains a wart. It's a design goal to keep the cost of supporting the wart
> low.
> >> Subject: Re: [rtcweb] Fwd: Last Call:
> >>> Am I correct to understand that WEBRTC WG decided that there should
> >>> be limits on DTMF tone generation and it is up to this group (IETF
> >> Formally, the RTCWEB group can advise the WEBRTC group about
> >> appropriate values, but in practice, the result is indistinguishable
> >> from your formulation :-
> >> )
> >>
> >>> years. I would like to mention that shorter tones are used during
> >>> call setup since it can be guaranteed that no audio signal is
> >>> present and talk-off requirements are relaxed. Furthermore VoIP only
> >>> networks, which use RFC 2833/RFC 4733 tones, can support tones and
> >>> gaps of anything from 0 ms and up. This is why I initially advocated
> >>> for 0 ms min duration. On the other hand if the group decides that
> >>> removing one more potential foot gun is more important, I will not be
> too upset.
> >>>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Mar 2016 22:33:28 +1100

This thread has gone on too long.

On 4 March 2016 at 22:22, Asveren, Tolga <[email-masked]> wrote:
> I understand very well what is defined by W3C and what by IETF RTCWEB WG.

Let's do away with that nonsense and address the issue squarely.  Both
Roman and Harald have provided you with solid technical arguments.
You have chosen to be un-swayed by those arguments, which is fine,
that's your prerogative.  However, it is clear that you have not
convinced anyone else to support your position either.

Thus, from my observer position, *this* working group has consensus to
impose limits.  Maybe one of the chairs is able to make a similar
assessment and, please, close this thread.

--Martin (who is for some reason unable to mute this thread)

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 4 Mar 2016 13:07:38 +0100

> (I feel some "unfriendliness" in the reply I received but that is probably just my misinterpretation ;-) )

I see why it could be interpreted as such.
I will endeavor to maintain a neutral tone.

> i- I understand very well what is defined by W3C and what by IETF RTCWEB WG.

Thank you. I was a bit confused about your knowledge given that you said
"I got confused about what WEBRTC WG refers to, maybe to W3C?"

> The point I am trying to make is that in this issue, the order of
events seem to be upside-down to me as what is specified in the
rtcweb-audio is not only applicable for browsers. And, what prevents W3C
to enforce limits in the API even if such limits are not cited in
rtcweb-audio?

Nothing. I thought your argument was against there being limits at all.

> ii- As far as use cases are concerned, your point seems to be "If it is not done until done, it does not need to be covered". I disagree but will leave this one here as well as I don’t have anythin…

If it's not done until now, there's a chance that there are genuine
problems with doing it at all. We're not here to solve those problems;
not part of our requirement set.

> iii- Just so that they are not lost; would appreciate answers about systems detecting digits with <40ms duration and about the gap between the final packet retransmissions.

I will leave that argument to others.

---

From: Barry Dingle <[email-masked]>
Date: Fri, 4 Mar 2016 23:09:48 +1100

I endorse Martin's comments.

DTMF is >50 yo technology. We are supporting it in WebRTC/rtcweb to enable
interworking with legacy real-time communications.

If you want to add App-specific user signalling in WebRTC/rtcweb, I suggest
you look at using the *WebRTC/rtcweb Data Channel*. Really simple to set up
- and there are no analog-telephony type limitations.

Cheers,
/Barry

Barry Dingle
University of Melbourne, Australia

On Fri, Mar 4, 2016 at 10:33 PM, Martin Thomson <[email-masked]>
wrote:

> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 4 Mar 2016 13:52:38 +0000

>And, what prevents W3C to enforce
> limits in the API even if such limits are not cited in rtcweb-audio?
> 
Yes, I was advocating not to enforce any limits on the browser (but won’t harp on it anymore, nothing to add). OTOH, enforcing limits in the browser v.s. in the rtcweb-audio specification are not exactly the same thing AFAICS. Would leaving RFC4733 -indirectly- untouched cause any problems? If what W3C needs is a recommendation from RTCWeb WG, can’t this be conveyed just by other means (and those limits can be imposed by the browser vendors as they see fit). Limits in rtcweb-audio will open the door for the need for yet another type of interworking (to make sure that RTCWeb leg complies with the limits) and wouldn’t it be preferable to eliminate such a need unless doing otherwise is absolutely needed?

Thanks,
Tolga

> Sent: Friday, March 04, 2016 7:08 AM
> Thank you. I was a bit confused about your knowledge given that you said "I
> got confused about what WEBRTC WG refers to, maybe to W3C?"
> 
> events seem to be upside-down to me as what is specified in the rtcweb-
> audio is not only applicable for browsers. And, what prevents W3C to enforce
> limits in the API even if such limits are not cited in rtcweb-audio?
> 
> > ii- As far as use cases are concerned, your point seems to be "If it is not
> done until done, it does not need to be covered". I disagree but will leave
> this one here as well as I don’t have anything to add.
> 
> If it's not done until now, there's a chance that there are genuine problems
> with doing it at all. We're not here to solve those problems; not part of our
> requirement set.
> 
> >
> > iii- Just so that they are not lost; would appreciate answers about systems
> detecting digits with <40ms duration and about the gap between the final
> packet retransmissions.
> 
> >> a range" is superior to a "default range". I will leave this here and
> >> obviously this is just my personal -but honest- opinion.
> >>
> >> domain, e.g. gateways. The limits we are talking about, are they
> >> applicable only for digits sent by browsers? What about digits
> >> emitted by a native application or a gateway? Will a browser be able
> >> to accept them if they are out of the range (assuming that the final
> >> outcome is to use enforced ranges)?
> >>
> >>
> >> If you don't understand which parts of the spec are done by the IETF
> >> and which by the W3C, some more reading might be in order.
> >> And if you don't have any experience in designing Javascript APIs,
> >> you might want to talk to someone who has that experience.
> >>
> >>>
> >>> iii- Just as an example, I am aware of systems, which can detect
> >>> digits
> >> <40ms.
> >>>
> >> same deployment model: A "legacy" application controlled by phone
> >> needs to be extended so that it can be accessed by Internet connected
> >> devices, e.g. a web-book. DataChannel is not used, e.g. not supported
> >> by gateway, by application etc..., hence digits are used for control.
> >>>
> >>> - TV gaming show
> >>> The user sees what is happening on the game on his TV and controls
> >>> it by digits The game (balloon escape) requires that at the
> >>> beginning the user
> >>> I am just trying to show that there are many different/imaginative
> >>> ways
> >> using the "digit UI".
> >>
> >> If you want to assert an use case, please assert one that is seen in
> >> the real world.
> >>
> >> address use cases with real, existing, deployed hardware. It was not
> >> a goal to stimulate people to imagine new ways in which DTMF could be
> used.
> >>
> >> It remains a wart. It's a design goal to keep the cost of supporting
> >> the wart low.
> >>>>> Am I correct to understand that WEBRTC WG decided that there
> >>>>> should be limits on DTMF tone generation and it is up to this
> >>>>> group (IETF
> >>>> appropriate values, but in practice, the result is
> >>>> indistinguishable from your formulation :-
> >>>> )
> >>>>
> >>>>> should be 8000 ms to match possible tone duration for RFC 2833
> >>>>> DTMF tone. RFC
> >>>>> 2833 was in use for the past 15 years and no one reported any
> >>>>> issues with this limit.
> >>>>>
> >>>>> present and talk-off requirements are relaxed. Furthermore VoIP
> >>>>> only networks, which use RFC 2833/RFC 4733 tones, can support
> >>>>> tones and gaps of anything from 0 ms and up. This is why I
> >>>>> initially advocated for 0 ms min duration. On the other hand if
> >>>>> the group decides that removing one more potential foot gun is
> >>>>> more important, I will not be
> >> too upset.
> >>>>>
> >>>>> If anybody can come up with the practical example where tones
> >>>>> longer then 8 sec or shorter then 40 ms with less then 30 ms gaps
> >>>>> are used, please report them to the list. Otherwise, let's
> >>>>> document what is in W3C TR and move on.
> >>>>
> >>>> Sounds good.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 4 Mar 2016 14:39:03 -0500

> (which is a WG of the W3C, not the IETF) API specification.

We are discussing adding tone and gap duration limits in rtcweb-audio. I
would argue that these limits should come from rtcweb-audio draft and
referenced in WEBRTC TR document. Not the other way around.

Do you disagree with this and do you think tone and gap duration limits
should only stay in WEBRTC TR?

Regards,
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 4 Mar 2016 19:47:59 +0000

That they stay only in WEBRTC TC would address my practical concerns. And *if* the main argument for the limits is making appellations less error prone, i.e. browsers enforcing limits, wouldn't this approach address the problem to be solved?

Thanks,

Tolga

________________________________
From: Roman Shpount <[email-masked]>
Sent: Friday, March 4, 2016 2:39 PM
To: Harald Alvestrand
Cc: Asveren, Tolga; Ted Hardie; Stefan Håkansson LK; [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, Mar 4, 2016 at 5:46 AM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
The hard limits are *not* in rtcweb-audio. They're in the WEBRTC WG
(which is a WG of the W3C, not the IETF) API specification.

We are discussing adding tone and gap duration limits in rtcweb-audio. I would argue that these limits should come from rtcweb-audio draft and referenced in WEBRTC TR document. Not the other way around.

Do you disagree with this and do you think tone and gap duration limits should only stay in WEBRTC TR?

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 4 Mar 2016 14:50:27 -0500

On Fri, Mar 4, 2016 at 2:47 PM, Asveren, Tolga <[email-masked]>
wrote:

> That they stay only in WEBRTC TC would address my practical concerns. And
> *if* the main argument for the limits is making appellations less error
> prone, i.e. browsers enforcing limits,
>
W3C WEBRTC working group is not the right to group define the acceptable
limits for DTMF tone duration. They can determine that API needs to have a
valid parameter range but defining the range should be in IETF.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 4 Mar 2016 14:55:38 -0500

On Fri, Mar 4, 2016 at 5:34 AM, Asveren, Tolga <[email-masked]>
wrote:

> i- I don't think satisfactory technical explanation is provided why
> "enforcing a range" is superior to a "default range". I will leave this
> here and obviously this is just my personal -but honest- opinion.
>

Having well defined limits simplifies interop. Most of existing systems
break down with tones below or above certain length. This way you can
validate that tones from 40 ms to 8 sec are correctly delivered by the
network.

> iii- Just as an example, I am aware of systems, which can detect digits

What systems? It is physically impossible to detect DTMF tone of duration
less then 40 ms in 8KHz tone and satisfy the original bellcore talk-off
specification. There are some PSTN gateways that detect shorter tones, but
they usually have a higher then acceptable talk-off error rate on general
speech.

iv- What about the gap between the final packet (with E-bit set)
> retransmissions?

The gap between final packets is not even discussed here. We are not
discussing the duration values or re-transmit intervals for RFC 4733
packets. We are only discussing overall duration of the DTMF tones and gaps
between them. It is up to an application to pick the interval for
transmitting RFC 4733 tone updates or final packets.

Furthermore, web browsers will not process RFC 4733 packets (except
processing necessary to safely discard them). This specification only
limits the tone and gap duration for tones generated by web browsers.

> v- As use cases for the need for longer duration (all these are based on
> the same deployment model: A "legacy" application controlled by phone needs
> The game (balloon escape) requires that at the beginning the user pumps
> air into the balloon. This is done by continuously pressing "5"
>

All long duration DTMF digits break into several tones. The application you
described typically considers several identical DTMF tones separated by
less then predefined gap duration a single tone.

It probably makes sense to note, that support for such application is
impossible from the current WebRTC API which only allows to play DTMF tone
of predefined length. To implement this application you need start play
tone/stop play tone API which is not provided.

> the valve/door/lock open for that period.

Same not as above applies here.

- Panic button
> Police/Social service workers rush to the registered address if she presses
> "7" continuously for longer than 10 seconds.
>

The "long press" for DTMF one is typically 1-4 sec. Most of current PSTN
networks will not pass a tone longer then 8 sec as a single tone due to RFC
2833 tone duration limitation.

> I am just trying to show that there are many different/imaginative ways

Unfortunately application you are referring to are unimplementable using
WebRTC.

Regards,
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 4 Mar 2016 20:14:10 +0000

Considering different points in your replies (please keep me honest if I misread/misinterpreted anything) that you think limit should be defined in RTCWeb WG but should be applicable only for digits generated by browsers. That sounds good to me (defining the limit only on API level in W3C is fine from my perspective too).

Thanks,

Tolga

________________________________
From: Roman Shpount <[email-masked]>
Sent: Friday, March 4, 2016 2:50 PM
To: Asveren, Tolga
Cc: Harald Alvestrand; Ted Hardie; Stefan Håkansson LK; [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, Mar 4, 2016 at 2:47 PM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

That they stay only in WEBRTC TC would address my practical concerns. And *if* the main argument for the limits is making appellations less error prone, i.e. browsers enforcing limits,

W3C WEBRTC working group is not the right to group define the acceptable limits for DTMF tone duration. They can determine that API needs to have a valid parameter range but defining the range should be in IETF.
_____________
Roman Shpount

---

From: Tim Panton <[email-masked]>
Date: Mon, 7 Mar 2016 10:47:41 +0000

> On 4 Mar 2016, at 19:55, Roman Shpount <[email-masked]> wrote:
> 
> On Fri, Mar 4, 2016 at 5:34 AM, Asveren, Tolga <[email-masked]> wrote:
…. snip…. 
> It probably makes sense to note, that support for such application is impossible from the current WebRTC API which only allows to play DTMF tone of predefined length. To implement this application you need start play tone/stop play tone API which is not provided.
> 
> The "long press" for DTMF one is typically 1-4 sec. Most of current PSTN networks will not pass a tone longer then 8 sec as a single tone due to RFC 2833 tone duration limitation.
>  
> Unfortunately application you are referring to are unimplementable using WebRTC.

Actually they are all implementable with webRTC - if combined with webAudio.
You just generate the DTMF tones with webAudio, mix (as appropriate)  with the mic signal and then
inject the result into the outgoing using 
AudioContext.createMediaStreamDestination()
and friends.

We could add a caveat that all the DTMF apis are optional if the browser also implements
webAudio. As it is possible to write a a javascript polyfill that implements the current api in 
terms of webaudio, which should be adequate for the legacy compatibility needs.

Also we should add a note that _all_ these sorts of usages would be better served by
carrying the data over the DataChannel, DTMF is for legacy interop only.

Tim.

---

From: Tim Panton <[email-masked]>
Date: Mon, 7 Mar 2016 10:48:20 +0000

> On 4 Mar 2016, at 11:33, Martin Thomson <[email-masked]> wrote:
> 

Since it is so hard to reach agreement on DTMF perhaps we could shelve 
all support for it ‘till after 1.0, then we can gain experience of actual requirements (if any).

T.

---

From: Tim Panton <[email-masked]>
Date: Mon, 7 Mar 2016 11:10:37 +0000

> On 7 Mar 2016, at 10:47, Tim Panton <[email-masked]> wrote:
> 
> 

And as proof by example : https://hacks.mozilla.org/2015/11/webrtc-sending-dtmf-in-firefox/
(thanks to Adam Roach for the code and Philipp Hancke for pointing it out)- 
I’d done a simpler version some years ago in phonoSDK - 
https://github.com/phono/PhonoSDK/commit/d6bb7ca54402aba3c0dd34dbd1912731f5af111b

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Mar 2016 13:35:52 -0500

> carrying the data over the DataChannel, DTMF is for legacy interop only.
This would be really unwise. DTMF generated as inband media is not
delivered by all codecs. Inband DTMF has much higher error rate then RFC
4733 in case of packet loss. Not supporting RFC 4733 will negatively affect
interop.

P.S. We already spent more time discussing DTMF then it would take to
implement it.
_____________
Roman Shpount

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 7 Mar 2016 13:57:29 -0500

On 03/07/2016 05:48 AM, Tim Panton wrote:
> Since it is so hard to reach agreement on DTMF perhaps we could
> shelve all support for it ‘till after 1.0, then we can gain
> experience of actual requirements (if any).

Let's not throw the baby out with the bath water. So far there's
agreement on most of the content. I think everyone agrees with the
lower bound on the DTMF duration and gap (without it bad things will
happen), so it's all down to whether there should be an upper bound.
My personal opinion is that a 6-8 second limit is reasonable and would
avoid problems, but it's not worth giving up on DTMF just for this issue
.

Cheers,

	Jean-Marc