Subject: [rtcweb] The DTMF API [Was: Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)]

From: Justin Uberti <[email-masked]>
Date: Tue, 15 Nov 2011 01:49:32 -0500

On Mon, Nov 14, 2011 at 10:58 AM, Randell Jesup <[email-masked]>wrote:

> On 11/14/2011 10:47 AM, Neil Stratford wrote:
>
>> On Mon, Nov 14, 2011 at 3:34 PM, Randell Jesup <[email-masked]:
>>    Note my other email I just sent - DTMF has a property not shared by
>>    the data streams - media synchronization.  I won't repeat all the
>>    arguments here, but there actually is a reason for delivering it in
>>    a media channel, totally regardless of legacy.  For a greenfield
>>    design, one *might* implement it as a separate media stream (m=
>>    line), but even there I'm not sure I would mandate it be separated.
>>
>>
>> How can we achieve the media synchronization in WebRTC? In a traditional
>> RTC endpoint the DTMF comes from the same source as the media, in many
>> cases it's actually taken from the media itself. However in WebRTC the
>> only way to trigger a DTMF event is through an asynchronous Javascript
>> function call, which is not synchonized to the media. Do we assume that
>> the function call happens 'at about the right time' and take that as the
>> current timestamp to use?
>>
>
> That speaks to the API needing tweaking - the JS app generally knows
> *when* (in realtime) the event occurred; it should pass that info in with
> the command to send it so the synchronized data can be correctly generated
> (along with the other timing info - duration or ongoing until told to
> stop).  ("When" could also include a special case for "now", defined as the
> current media clock position when the function call is processed.)

One simple option would be to say that the DTMF event occurs when the API
is called. If you need to generate DTMF tones in the future, you can pass
in a full dialstring, or use JS timers. Granted, this will sacrifice some
precision, but given that most DTMF is entered via manual button presses, I
don't see this as an issue.

This needs to be scoped on a per-track basis, since it needs to be sent
with a specific SSRC.

So I would propose an API of the form

[Local]MediaStreamTrack.sendDTMF(in DOMString tones)  // e.g. "1" or "123"

---

From: Randell Jesup <[email-masked]>
Date: Tue, 15 Nov 2011 11:01:57 -0500

On 11/15/2011 1:49 AM, Justin Uberti wrote:
> On Mon, Nov 14, 2011 at 10:58 AM, Randell Jesup <[email-masked]
>     *when* (in realtime) the event occurred; it should pass that info in
>     with the command to send it so the synchronized data can be
>     correctly generated (along with the other timing info - duration or
>     ongoing until told to stop).  ("When" could also include a special
>     case for "now", defined as the current media clock position when the
>     function call is processed.)
>
>
> One simple option would be to say that the DTMF event occurs when the
> API is called. If you need to generate DTMF tones in the future, you can
> pass in a full dialstring, or use JS timers. Granted, this will
> sacrifice some precision, but given that most DTMF is entered via manual
> button presses, I don't see this as an issue.
>

The problem is you need a bunch more timing info that when it starts. 
DTMF is not just "this was played", though many use it that way.  DTMF 
has length as well, and that length may even be indeterminate.  Many SIP 
ATAs and the like only support sending DTMF as X ms on, Y ms off, but 
you'll note that those are often configurable, and the protocol is much 
more expressive than that.

That said: we absolutely can decide that we only support only sending 
"now", and that the duration is fixed (or configurable).  For the uses 
we're talking about, that's probably sufficient.  Some odd PSTN-interop 
things have been known to use DTMF duration ("hold 4 to fast-forward" or 
"press and hold 5 to pan the security camera"), but they're rare IMHO, 
and PSTN interop isn't the prime usecase (and many/most other voip 
devices don't support press-and-hold anyways).  I'd be fine with this.

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Nov 2011 02:43:50 +0000

On Nov 15, 2011, at 11:01 AM, Randell Jesup wrote:

> The problem is you need a bunch more timing info that when it starts. DTMF is not just "this was played", though many use it that way.  DTMF has length as well, and that length may even be indeterminate.  Many SIP ATAs and the like only support sending DTMF as X ms on, Y ms off, but you'll note that those are often configurable, and the protocol is much more expressive than that.
> 
> That said: we absolutely can decide that we only support only sending "now", and that the duration is fixed (or configurable).  For the uses we're talking about, that's probably sufficient.  Some odd PSTN-interop things have been known to use DTMF duration ("hold 4 to fast-forward" or "press and hold 5 to pan the security camera"), but they're rare IMHO, and PSTN interop isn't the prime usecase (and many/most other voip devices don't support press-and-hold anyways).  I'd be fine with this.

You'd be surprised how many things use/need DTMF duration. :(

It caused a lot of issues for certain Mobile/Cellular networks a long time ago where the cell phones couldn't generate a duration for DTMF - I can't remember if it was a limitation of the phones or the cellular technology, but it caused lots of user complaints.
It also caused issues in H.323 because H.245 UII supported both indicating with/without duration and those sending without had problems talking to those needing it.

Regardless, as an FYI - I had put the following DTMF API requirements in draft-kaplan-rtcweb-sip-interworking-requirements-01:

      ----------------------------------------------------------------
      A2-13           WebRTC MUST provide a means for the
                      Browser to generate [RFC4733] DMTF RTP
                      Events for at least the events 0-15, in
                      an audio-type RTP packet stream.
      ----------------------------------------------------------------
      A2-14           WebRTC MAY provide a means for the
                      Browser to receive [RFC4733] DMTF RTP
                      Events for the events 0-15.
      ----------------------------------------------------------------
      A2-15           WebRTC MUST provide a means for the
                      Javascript application to invoke [RFC4733]
                      DTMF events to be generated, and their
                      duration, with a default duration of 50ms.
                      In other words, the Javascript should be
                      able to tell the Browser to generate event
                      "0" for 50ms based on a button click, for
                      example.
      ----------------------------------------------------------------
      A2-16           WebRTC MUST provide a means for the
                      Javascript application to enable or
                      disable [RFC4733] use, per session.
      ----------------------------------------------------------------

-hadriel

---

From: Justin Uberti <[email-masked]>
Date: Wed, 16 Nov 2011 01:13:06 -0500

On Tue, Nov 15, 2011 at 9:43 PM, Hadriel Kaplan <[email-masked]>wrote:

> DTMF is not just "this was played", though many use it that way.  DTMF has
> length as well, and that length may even be indeterminate.  Many SIP ATAs
> and the like only support sending DTMF as X ms on, Y ms off, but you'll
> note that those are often configurable, and the protocol is much more
> expressive than that.
> >
> "press and hold 5 to pan the security camera"), but they're rare IMHO, and
> PSTN interop isn't the prime usecase (and many/most other voip devices
> don't support press-and-hold anyways).  I'd be fine with this.
>
>
> It caused a lot of issues for certain Mobile/Cellular networks a long time
> ago where the cell phones couldn't generate a duration for DTMF - I can't
> remember if it was a limitation of the phones or the cellular technology,
> but it caused lots of user complaints.
> It also caused issues in H.323 because H.245 UII supported both indicating
> with/without duration and those sending without had problems talking to
> those needing it.
>
> Regardless, as an FYI - I had put the following DTMF API requirements in
> draft-kaplan-rtcweb-sip-interworking-requirements-01:
>
OK, how about

[Local]MediaStreamTrack.sendDTMF(in DOMString tones, in optional long
duration)

ex:
sendDTMF("1")  // plays tone 1 for 50 ms
sendDTMF("2", 200)  // plays tone 2 for 200 ms
sendDTMF("123")  // plays tones 1, 2, 3 in succession, each for 50 ms
sendDTMF("456", 200)  // plays tones 4, 5, 6 in succession, each for 200 ms

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Nov 2011 06:38:58 +0000

On Nov 16, 2011, at 1:13 AM, Justin Uberti wrote:

> [Local]MediaStreamTrack.sendDTMF(in DOMString tones, in optional long duration)
> 
> ex:

Sounds good to me, but supporting a multi-digit-string as you did above reminds me that I'll have to check with some experts if this is ok - it reminded me there have been issues with DTMFs being too close to each other in time, but I am not an expert in that and it may not be an issue at all.  (there were issues in PSTN when multiple DTMFs were generated back-to-back from a saved address-book contact-entry type thing, but it may have only been a problem for using in-band DTMF which won't be an issue here)
I'll ask.

-hadriel

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 16 Nov 2011 02:20:02 -0500

Justin Uberti writes:

ex:

For some UI models, you may need start-DTMF / stop-DTMF APIs, mapping to mousedown / mouseup on a button or similar.  You don’t know in advance how long the user will hold the key down.

--
Jonathan Lennox
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Wed, 16 Nov 2011 02:46:23 -0500

> Sounds good to me, but supporting a multi-digit-string as you did above reminds me that I'll have to check with some experts if this is ok - it reminded me there have been issues with DTMFs being t…

Typically you need an on-time and an off-time when sending a stream.  I 
think typical minimums are around 70ms on, 40ms off, but that's 
off-the-cuff from old neurons.  I think the minimum is around 45ms on, 
but that will see problems with decoders.

http://nemesis.lonestar.org/reference/telecom/signaling/dtmf.html
indicates 50ms min on, 45ms min off, 100ms min cycle duration. I 
wouldn't want to run too close to those numbers, though.

"It should be mentioned that Radio Shack, one of the worlds largest 
retailers of consumer telephone equipment, requires that all telephone 
devices it sells generate DTMF tones of no less than 70 msec of 
duration. Radio Shack developed this number based on real-life use of 
their equipment on telephone networks throughout North America and the 
finding that shorter tones are more likely to cause dialing troubles."

-- 
Randell Jesup
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 16 Nov 2011 15:52:48 +0800

> sendDTMF("1")  // plays tone 1 for 50 ms
If I call this twice in a row, are they serialized? Is there a gap?
> sendDTMF("2", 200)  // plays tone 2 for 200 ms
Same question as above.
> sendDTMF("123")  // plays tones 1, 2, 3 in succession, each for 50 ms
Does this put a gap of 0 ms, 50 ms, or something else between 1 2 and 3?
> sendDTMF("456", 200)  // plays tones 4, 5, 6 in succession, each for 
How about this?

Matthew Kaufman

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Nov 2011 23:54:17 -0800

> If I call this twice in a row, are they serialized? Is there a gap?

Also, does playout start right away or does it start after one
returns control to the JS VM?

-Ekr

---

From: Justin Uberti <[email-masked]>
Date: Wed, 16 Nov 2011 06:24:06 -0500

On Wed, Nov 16, 2011 at 2:20 AM, Jonathan Lennox <[email-masked]> wrote:

> Justin Uberti writes:****
>
> duration) ****
> ** **
> ex:****
> sendDTMF("1")  // plays tone 1 for 50 ms****
>
> sendDTMF("2", 200)  // plays tone 2 for 200 ms****
>
> sendDTMF("123")  // plays tones 1, 2, 3 in succession, each for 50 ms****
>
> ****
> ** **
> For some UI models, you may need start-DTMF / stop-DTMF APIs, mapping to
> mousedown / mouseup on a button or similar.  You don’t know in advance how
> long the user will hold the key down.
>

I've been trying to avoid that complexity. If it's really needed, we can
add it, but given that DTMF is kind of a wart I'd prefer to keep the
support as minimal as possible.

Of course we could let you cancel an existing press by passing in "", so
you could play a really long tone and cancel it through this API.

> ****
> ** **
> -- ****
> Jonathan Lennox****
> [email-masked]****
> ** **
> ** **

---

From: Justin Uberti <[email-masked]>
Date: Wed, 16 Nov 2011 06:26:27 -0500

On Wed, Nov 16, 2011 at 2:46 AM, Randell Jesup <[email-masked]>wrote:

>>  [Local]MediaStreamTrack.**sendDTMF(in DOMString tones, in optional long
>>> duration)
>>>
>>> ex:
>> Sounds good to me, but supporting a multi-digit-string as you did above
>> reminds me that I'll have to check with some experts if this is ok - it
>> reminded me there have been issues with DTMFs being too close to each other
>> in time, but I am not an expert in that and it may not be an issue at all.
>>  (there were issues in PSTN when multiple DTMFs were generated back-to-back
>> from a saved address-book contact-entry type thing, but it may have only
>> been a problem for using in-band DTMF which won't be an issue here)
>>
>
> off-the-cuff from old neurons.  I think the minimum is around 45ms on, but
> that will see problems with decoders.
>
> http://nemesis.lonestar.org/**reference/telecom/signaling/**dtmf.html<http://nemesis.lonestar.org/reference/telecom/signaling/dtmf.html>
> indicates 50ms min on, 45ms min off, 100ms min cycle duration. I wouldn't
> want to run too close to those numbers, though.
>
> devices it sells generate DTMF tones of no less than 70 msec of duration.
> Radio Shack developed this number based on real-life use of their equipment
> on telephone networks throughout North America and the finding that shorter
> tones are more likely to cause dialing troubles."

If I read this right, sounds like this means we enforce a minimum tone
length of 100 ms and a minimum gap of 50 ms.

>
>
> --
> Randell Jesup
> [email-masked]
>
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 16 Nov 2011 06:30:04 -0500

> If I call this twice in a row, are they serialized? Is there a gap?

Yes. Gap is the minimum allowed gap, which from Randell I gather is 50 ms.

> Does this put a gap of 0 ms, 50 ms, or something else between 1 2 and 3?

The gap is always 50 ms. We could have a meta-character to mean "play
silence for the specified duration" if there was a clear need.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 16 Nov 2011 06:31:25 -0500

> returns control to the JS VM?

I was thinking playout would start right away, but I could be convinced
otherwise if there was a clear need.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 16 Nov 2011 12:06:02 -0500

I think sendDTMF should take four parameters: digit string, digit duration
(default 70 ms), after digit pause duration (default 50ms), and volume
(default 0. Valid values are 0-63 with larger value specifying lower
volume). Default durations are based on ITU-T V.18.

This function should queue the DTMF digits and pauses and return control
immediately to JavaScript. If you call sendDTMF multiple times in rapid
succession their digit strings are queued one after the other and played
according to digit and pause durations specified.

We can also provide a call back to inform JavaScript that DTMF digit
started/stopped playing, but I am not sure it would get a lot of use.

For UI integration and complete RFC 4733  we would also need something like
startTone/stopTone function. I actually think startTone/endTone is more
appropriate then startDTMF/stopDTMF since RFC 4733 can be used to carry
other tones, such as ring back, in addition to DTMF. This function would
take a tone ID (based on IANA registration) and volume. We can also add
support for specifying custom tones by making this function accept
modulation frequency, volume, and a list of frequencies that are combined
to create a tone (I have not actually seen anybody using or supporting
this, so this is really optional). stopTone would take no parameters and
terminate the current tone. If there are queued DTMF digits from sendDTMF
when startTone is initiated, tone is not started until all the queued DTMF
digits are played. If sendDTMF is called when tone is played, and error is
returned (the app should know better).
_____________
Roman Shpount

On Wed, Nov 16, 2011 at 2:54 AM, Eric Rescorla <[email-masked]> wrote:

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

---

From: Roman Shpount <[email-masked]>
Date: Wed, 16 Nov 2011 12:23:11 -0500

One more thing that forgot: In digit string sendDTMF should take digits
0-9, letters A,B,C,D, #, *, and comma. Comma specifies pause between the
digits. This also means that sendDTMF should take the fifth parameter:
comma pause duration (different from inter digit pause).
_____________
Roman Shpount

On Wed, Nov 16, 2011 at 12:06 PM, Roman Shpount <[email-masked]> wrote:

> For UI integration and complete RFC 4733  we would also need something
> like startTone/stopTone function. I actually think startTone/endTone is
> more appropriate then startDTMF/stopDTMF since RFC 4733 can be used to
> carry other tones, such as ring back, in addition to DTMF. This function
> would take a tone ID (based on IANA registration) and volume. We can also
> add support for specifying custom tones by making this function accept

---

From: Michael Thornburgh <[email-masked]>
Date: Wed, 16 Nov 2011 11:29:30 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman Shpount
> Sent: Wednesday, November 16, 2011 9:06 AM
> Subject: Re: [rtcweb] The DTMF API [Was: Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)]

> I think sendDTMF should take four parameters: digit string, digit duration (default 70 ms), after digit pause duration (default 50ms), and volume (default 0. Valid values are 0-63 with larger value specifying lower volume). Default durations are based on ITU-T V.18.

without comment on any other part of this proposal, the volume parameter should be consistent with the volume attribute of media elements and should range from 0.0 to 1.0. a volume of 1.0 should be 0 dBm0 and a volume of 0 should be -63 dBm0 (for purposes of RFC 4733 encoding). the volume parameter should be linear and converted appropriately to dBm0 (RFC4733_volume_field = -10 * log10(JS_volume_parameter)).

[...]

---

From: Roman Shpount <[email-masked]>
Date: Wed, 16 Nov 2011 14:45:43 -0500

On Wed, Nov 16, 2011 at 2:29 PM, Michael Thornburgh <[email-masked]>wrote:

> > Subject: Re: [rtcweb] The DTMF API [Was: Traffic should be encrypted.
> (Re: Let's define the purpose of WebRTC)]
>
> > I think sendDTMF should take four parameters: digit string, digit
> duration (default 70 ms), after digit pause duration (default 50ms), and
> volume (default 0. Valid values are 0-63 with larger value specifying lower
> without comment on any other part of this proposal, the volume parameter
> should be consistent with the volume attribute of media elements and should
> range from 0.0 to 1.0. a volume of 1.0 should be 0 dBm0 and a volume of 0
> should be -63 dBm0 (for purposes of RFC 4733 encoding). the volume
> parameter should be linear and converted appropriately to dBm0
> (RFC4733_volume_field = -10 * log10(JS_volume_parameter)).
>
>
Agreed. I was just going through the RFC 4733, but it makes sense to make
this consistent with the rest of the JS API.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Thu, 17 Nov 2011 04:35:16 -0500

> this consistent with the rest of the JS API.
The API I have proposed currently satisfies all the DTMF requirements of
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-06,
namely F22: there should be a way to navigate IVRs.

Control of DTMF volume is not currently a requirement.

---

From: Neil Stratford <[email-masked]>
Date: Thu, 17 Nov 2011 09:47:41 +0000

> [Local]MediaStreamTrack.sendDTMF(in DOMString tones, in optional long

Do we support null MediaStreamTracks in the current API?

It should be possible to navigate an IVR using DTMF without having given
any local microphone access permission, or selected a local file for
playout on a track.

Neil

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 17 Nov 2011 10:18:11 +0000

FYI - I asked an expert and he said that for the default DTMF duration that although 50ms is the official minimum, in practice it's safer to use 100ms and people often do that (or even longer but we don't need to).  We also need to have a 50ms gap minimum.
So basically confirming what was already stated in other emails in this thread.

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Thu, 17 Nov 2011 10:13:34 -0500

On 11/17/2011 4:35 AM, Justin Uberti wrote:
> On Wed, Nov 16, 2011 at 2:45 PM, Roman Shpount <[email-masked]
> <mailto:[email-masked]>> wrote:
>          > I think sendDTMF should take four parameters: digit string,
>         digit duration (default 70 ms), after digit pause duration
>         (default 50ms), and volume (default 0. Valid values are 0-63
>         with larger value specifying lower volume). Default durations
>         are based on ITU-T V.18.
>
>         without comment on any other part of this proposal, the volume
>         parameter should be consistent with the volume attribute of
>         media elements and should range from 0.0 to 1.0. a volume of 1.0
>         should be 0 dBm0 and a volume of 0 should be -63 dBm0 (for
>         purposes of RFC 4733 encoding). the volume parameter should be
>         linear and converted appropriately to dBm0 (RFC4733_volume_field
>         = -10 * log10(JS_volume_parameter)).
>
>     Agreed. I was just going through the RFC 4733, but it makes sense to
>     make this consistent with the rest of the JS API.
>
>

This brings up a point I was going to make (or perhaps did), but needs 
to be expanded on here:

There's RFC 4733/2833 (and if you're worrying about legacy interop, you 
want 2833 included), with all the many variations that they can express. 
  As I've mentioned, this includes a lot of edge issues like press-and-hold.

And then there's what we need to support sending (and receiving!!!) in 
WebRTC.  These are not necessarily the same, which is what Justin is 
referring to.

The requirement is written the way it is in order to not require 
bringing in all of 2833/4733, and the API complexities it would engender 
that would be rarely, if ever used.  Most VoIP ATAs don't support all 
these options - if you're lucky there's a hidden configuration option 
for the service provider to adjust on/off times.  Most in my experience 
do not support volume or press-and-hold.

Personally, I think being able to send DTMF digits or string of DTMF 
digits with a pre-configured on-off time is sufficient for the API 
(though I'll note this is the W3C API we're talking here).  In the IETF 
land we could just say RFC 2833 & 4733 are supported and leave it at 
that, and let W3C decide what's exposed - but that does potentially 
require someone to implement things that would not be usable (or only 
through non-standard APIs).

For on-off times, 'hidden' configs (about:config in Firefox) would be 
fine by me.  I wouldn't mandate they be configurable.  We should choose 
a default on and off time based on surveying existing equipment. (I'll 
probably suggest something like 80/50 or 100/60.)  The default on/off 
time should be a SHOULD.

The remaining issue is *reception* of 2833/4733.  That is not covered by 
the existing requirement.  The use case would be (if we were to add it) 
to allow someone to contact a WebRTC-based client that has a built-in 
answering function and control it via DTMF from a phone/cellphone.  (Or 
control other things that the JS app (or non-browser webrtc-based 
device) has access to - think a webrtc-based security system.)

Note again this is NOT currently a use case, and DTMF playback and 
sending DTMF events to the JS app are NOT requirements; if someone makes 
the case we can consider it.  If no one wants it, or there isn't 
consensus on adopting it, I see no reason to require 2833/4733 
reception/playback.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Thu, 17 Nov 2011 10:19:29 -0500

On 11/17/2011 4:47 AM, Neil Stratford wrote:
> On Wed, Nov 16, 2011 at 6:13 AM, Justin Uberti <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     OK, how about
>

This is a good point to detail - thanks Neil.  It also brings up a 
related point - how an application that hasn't asked for microphone 
access, or has been denied microphone access should act and what it has 
access to.  I.e., in this case, it would be a one-way media stream, but 
for sending DTMF it must be two-way, even without mic access.  So we'd 
need to be able to set up a "silent"/null stream, as Neil refers to, in 
order to be able to send DTMF on top of it.

-- 
Randell Jesup
[email-masked]

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 18 Nov 2011 01:53:37 +0000

It will be great in case usecase are added before going into DTMF API. AFAIK, DTMF is not directly going to useful in browser-browser scenario and it is possible to pass DTMF in the signaling layer for H.323, SIP in the standard manner.

IMO, There are way to solve DTMF in WebRTC without including media level API.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Hadriel Kaplan
>Sent: Thursday, November 17, 2011 6:18 PM
>To: Justin Uberti
>Cc: Randell Jesup; <[email-masked]>
>FYI - I asked an expert and he said that for the default DTMF duration
>that although 50ms is the official minimum, in practice it's safer to
>use 100ms and people often do that (or even longer but we don't need
>to).  We also need to have a 50ms gap minimum.
>>> sendDTMF("1")  // plays tone 1 for 50 ms sendDTMF("2", 200)  // plays
>>> tone 2 for 200 ms
>> Sounds good to me, but supporting a multi-digit-string as you did
>> above reminds me that I'll have to check with some experts if this is
>ok - it reminded me there have been issues with DTMFs being too close to
>each other in time, but I am not an expert in that and it may not be an
>issue at all.  (there were issues in PSTN when multiple DTMFs were
>generated back-to-back from a saved address-book contact-entry type
>thing, but it may have only been a problem for using in-band DTMF which
>won't be an issue here) I'll ask.
>>
>> -hadriel
>>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 18 Nov 2011 10:46:19 +0800

On 11/18/2011 09:53 AM, Ravindran, Parthasarathi wrote:
> It will be great in case usecase are added before going into DTMF API.
4.3.2.  Fedex Call

4.3.2.1.  Description

    Alice uses her web browser with a service something like Skype to be
    able to phone PSTN numbers.  Alice calls 1-800-gofedex.  Alice should
    be able to hear the initial prompts from the fedex IVR and when the
    IVR says press 1, there should be a way for Alice to navigate the
    IVR.

4.3.2.2.  Derived Requirements

    F1, F2, F3, F4, F5, F6, F8, F9, F10, F21, F22

    A1, A2, A3, A4, A7, A8, A9, A10, A11, A12

>   AFAIK, DTMF is not directly going to useful in browser-browser scenario and it is possible to pass DTMF in the signaling layer for H.323, SIP in the standard manner.
What do you mean by "the standard manner"?

> IMO, There are way to solve DTMF in WebRTC without including media level API.
How do you propose to allow Alice in the use case to navigate the IVR 
without having some API that allows injecting DTMF?

Whether the API is media level or not, it seems clear to me that there 
needs to be an API. (The alternative would be to claim that the dialpad, 
too, is part of the browser chrome - that seems to me like the wrong 
solution in this case.)

(and - sounding like a broken record - the API aspects REALLY need to be 
in the W3C list.)
>> Cc: Randell Jesup;<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Nov 2011 02:55:20 +0000

As I said at the microphone: the use-case and explanation of why we need DTMF is noted in section 5.3 of draft-kaplan-rtcweb-sip-interworking-requirements-01.  Note that is not a WG draft, just an individual draft.  

The WG draft draft-ietf-rtcweb-use-cases-and-requirements-06 has the FedEx use-case in section 4.3.2.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Nov 2011 03:02:49 +0000

> What do you mean by "the standard manner"?

H.323 and SIP both offer a signaling-plane means of indicating DTMF, other than RFC 2833/4733.  For H.323 it's H.245 User Input Indications (UII) messages.  For SIP it's officially KPML (RFC 4730), but in practice it's not popular.  Two vendors I know of support it, but it's a drop in the bucket compared to rfc2833 or SIP INFO.

> How do you propose to allow Alice in the use case to navigate the IVR without having some API that allows injecting DTMF?

Well in theory the Javascript could send a message to the Web Server to generate a "dtmf event", which the server interworks to a SIP KPML NOTIFY in a KPML subscription.

-hadriel

---

From: Wolfgang Beck <[email-masked]>
Date: Fri, 18 Nov 2011 11:26:26 +0800

On Fri, Nov 18, 2011 at 10:46 AM, Harald Alvestrand
<[email-masked]> wrote:
[about DTMF in the signaling path]

> (and - sounding like a broken record - the API aspects REALLY need to be in
> the W3C list.)
Sounding like an Ogg player on 'repeat':

In a single server scenario, we don't need a standard way to ask for
DTMF generation between RTCWEB client and server. An RTCWEB server
that includes a PSTN gateway function could use H.248's DTMF
generation package to tell the media gateway that it should insert
tones.

A more disruptive way to do DTMF would be an API function wich lets
the JS application insert arbitrary sound bits into the media stream.
A JS client could locally generate DTMF samples and play them. But of
course this would need to be discussed on the W3C list.

Wolfgang Beck

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 18 Nov 2011 15:29:39 +0800

> H.323 and SIP both offer a signaling-plane means of indicating DTMF, other than RFC 2833/4733.  For H.323 it's H.245 User Input Indications (UII) messages.  For SIP it's officially KPML (RFC 4730),…
OK, thanks.

So the discussion that is really part of the IETF's task here is to pick 
one (and preferably one) way that WebRTC applications are recommended to 
do DTMF.

If we accept draft-cbran's codec recommendation, it follows that an API 
must be standardized in the W3C, and discussion of the form of that API 
should go to the W3C list.

But I agree that the discussion on what the recommendation should be 
needs to happen here.

                      Harald

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 18 Nov 2011 17:06:29 +0800

> H.323 and SIP both offer a signaling-plane means of indicating DTMF, other than RFC 2833/4733.  For H.323 it's H.245 User Input Indications (UII) messages.  For SIP it's officially KPML (RFC 4730),…

With no DTMF work in the browser, the browser could still send any 
signaling-plane version of DTMF it wants in cooperation with whatever 
server(s) it is talking to.

However this would preclude all cases where the DTMF must be transported 
in the media plane, as per 2833/4733.

Given that the latter cases are fairly common (and not just for PSTN 
interoperation) I believe it would be a mistake to not have this 
capability in the browser. Noting that if we do require it, we get the 
best of both worlds... the ability for the JavaScript to command the 
browser to insert RFC4733 DTMF in the media stream *and* the ability for 
the JavaScript to notify the server to send signaling-layer DTMF.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 18 Nov 2011 17:09:17 +0800

On 11/18/11 3:29 PM, Harald Alvestrand wrote:
>>>>   AFAIK, DTMF is not directly going to useful in browser-browser 
>>>> scenario and it is possible to pass DTMF in the signaling layer for 
>>>> H.323, SIP in the standard manner.
>> H.323 and SIP both offer a signaling-plane means of indicating DTMF, 
>> other than RFC 2833/4733.  For H.323 it's H.245 User Input 
>> Indications (UII) messages.  For SIP it's officially KPML (RFC 4730), 
>> but in practice it's not popular.  Two vendors I know of support it, 
>> but it's a drop in the bucket compared to rfc2833 or SIP INFO.
> OK, thanks.
>
> So the discussion that is really part of the IETF's task here is to 
> pick one (and preferably one) way that WebRTC applications are 
> recommended to do DTMF.

I think it is simpler than that. The IETF's task here is to note that 
in-media-plane DTMF signaling is required to meet the IETF's use cases, 
and that RFC 4733 tells how to send that over the wire. Whether or not 
there are additional non-media-plane ways of doing DTMF signaling turns 
out to be irrelevant, unless we go down the road of defining the entire 
JavaScript-to-Web Server signaling protocol, which I hope we can agree 
to not do.

>
> If we accept draft-cbran's codec recommendation, it follows that an 
> API must be standardized in the W3C, and discussion of the form of 
> that API should go to the W3C list.

Agree with this. It follows that if we agree that RFC 4733 messages are 
to be sent in the media plane directly from the browser, W3C must 
provide an API by which JavaScript may insert those messages.

Matthew Kaufman

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 18 Nov 2011 11:05:55 +0100

2011/11/18 Harald Alvestrand <[email-masked]>:
>> H.323 and SIP both offer a signaling-plane means of indicating DTMF, other
>> than RFC 2833/4733.  For H.323 it's H.245 User Input Indications (UII)
>> messages.  For SIP it's officially KPML (RFC 4730), but in practice it's not
>> popular.  Two vendors I know of support it, but it's a drop in the bucket
>> compared to rfc2833 or SIP INFO.
>
> OK, thanks.
>
> So the discussion that is really part of the IETF's task here is to pick one
> (and preferably one) way that WebRTC applications are recommended to do
> DTMF.

In case http://tools.ietf.org/html/draft-kaplan-dispatch-info-dtmf-package-00
becomes a standard, there is no need to send DTMF over the media
stream (when interoperating with SIP networks). Since this just
concerns the in-the-wire signaling it becomes up to the application
developer.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 18 Nov 2011 18:37:21 +0800

On 11/18/11 6:05 PM, Iñaki Baz Castillo wrote:
> 2011/11/18 Harald Alvestrand<[email-masked]>:
Are you advocating that we not put DTMF-in-media support in browsers (in 
which case I have a good argument against), or are you simply making an 
observation about an alternative that may also become available?

Matthew Kaufman

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 18 Nov 2011 11:48:45 +0100

> Are you advocating that we not put DTMF-in-media support in browsers (in which case I have a good argument against), or are you simply making an observation about an alternative that may also become available?
> 

Do you have any application for DTMF in mind other than PSTN interoperability? I'd like to hear that argument against not having DTMF-in-media support in the browser :-)

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 18 Nov 2011 12:53:28 +0100

2011/11/18 Matthew Kaufman <[email-masked]>:
>> In case
>> http://tools.ietf.org/html/draft-kaplan-dispatch-info-dtmf-package-00

I'd would like not to make the WebRTC API ugly just due to
interoperability with legacy networks, and DTMF is something that, for
sure, is so far from the concept of "Web innovation".

So if such DTMF can be emulated via the free in-the-wire signaling we
avoid adding it to the WebRTC API and also avoid browsers vendors
having to deal with DTMF duration, volume and other pure legacy
telephony stuff.

Even in modern SIP networks, sending DTMF's over RTP is undesired in
many cases and forces some non optimal architectural designs. For
example, it's very common the use case in which a SIP PBX system
brigdes a call between two phones/endpoints and offers "on-demand"
recording service. For this, the user (which just has a common/legacy
SIP phone) must enter some specific DTMF tones during the call. In
order the PBX to intercept these DTMF codes, the RTP must pass through
the PBX. If not, DTMF's must be sent over the signaling path so the
PBX is aware of them and can react.

So sending DTMF's over the signaling path is just better than sending
them over the media stream, IMHO for all the possible cases. This is
the reason of the use of INFO for carrying DTMFs (even if it has never
been standarized and its usage has real drawbacks).

Said that, I would strongly propose the above if
http://tools.ietf.org/html/draft-kaplan-dispatch-info-dtmf-package-00
was already a standard, unfortunatelly it's not the case.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 18 Nov 2011 19:55:52 +0800

> Do you have any application for DTMF in mind other than PSTN interoperability? I'd like to hear that argument against not having DTMF-in-media support in the browser :-)

Sure. Two-way radio systems using ROIP.

For example, from 
http://www.safecomprogram.gov/SiteCollectionDocuments/BSICoreImplementationProfile.pdf

"6.4 DTMF

A BSI complying with this implementation profile MUST support “RTP 
Payload for DTMF
Digits, Telephony Tones and Telephony Signals”, RFC 4733 [7] for the 
sending and
receiving of DTMF digits."

And of course, yes, *also* PSTN interoperability.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 18 Nov 2011 19:57:01 +0800

On 11/18/11 7:53 PM, Iñaki Baz Castillo wrote:
> them over the media stream, IMHO for all the possible cases.

Except for all use cases where the only way to send DTMF is over the 
media path, because (for instance) there is no signaling protocol which 
supports sending DTMF and/or the signaling service is no longer in-path 
when DTMF needs to be sent.

Matthew Kaufman

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 18 Nov 2011 13:05:54 +0100

2011/11/18 Matthew Kaufman <[email-masked]>:
>> So sending DTMF's over the signaling path is just better than sending them
>> over the media stream, IMHO for all the possible cases.
>
>
> Except for all use cases where the only way to send DTMF is over the media
> path, because (for instance) there is no signaling protocol which supports
> sending DTMF and/or the signaling service is no longer in-path when DTMF
> needs to be sent.

The question here is (assuming that
draft-kaplan-dispatch-info-dtmf-package becomes a standard soon):

1) Do we want to make a solution that *just* works with existing legacy devices?

2) Or do we want to make a solution that *can* interoperate with other
VoIP protocols since there are specifications for them (regardless
some devices do not implement them "yet")?

This should be clarified. But if the answer is 1), then we would also
accept any kind of insecure communication (plain RTP, no ICE, etc etc)
just to make happy old devices and vendors that don't want to invest
in making their devices modern and secure.

1) or 2) ?

IMHO 2).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Nov 2011 17:30:37 +0000

> draft-kaplan-dispatch-info-dtmf-package becomes a standard soon):

Unfortunately draft-kaplan-dispatch-info-dtmf-package will never become a standard.  I presented it a couple IETF meetings ago, and was basically told to go away and never bring it back to the IETF.  (despite the fact it was the main use-case and motivation for creating INFO packages to begin with)

> some devices do not implement them "yet")?

I'm not sure I understand #2 - we have "a solution that can interoperate with other devices and is a standard": RFC 4733.  It also works with legacy devices.

If you mean #2 is signaling-plane DTMF (a la SIP KPML), then your choices are false - it's not a choice between #1 or #2, because it's impossible *not* to have #2.  We can't choose whether to support DTMF in signaling or not, because it's possible to do it even right now today on any browser, without any changes whatsoever.  So we've already got #2.  Any javascript developer in the Web can do #2 already, today.  The question for RTCWEB is whether to also support RFC 4733 or not.  

So if it's not too hard to add, it would be great to support RFC 4733 as well, so we can let the web-app provider work with even more non-WebRTC devices.  And we've been told it shouldn't be too hard to add, so why do you care?  If you don't want to use it in your web-app, don't.

-hadriel

---

From: Justin Uberti <[email-masked]>
Date: Fri, 18 Nov 2011 12:34:29 -0500

On Fri, Nov 18, 2011 at 7:05 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> them
> media
We shouldn't use WebRTC as a lever to try to fix everything that might be
seen as suboptimal in unified communications.

To meet the requirements, we need to support DTMF, and life will be much
simpler if we support in-RTP DTMF in the API. (Applications of course are
free to communicate DTMF over signaling instead if they wish).

So I have proposed a simple API method that allows for in-RTP DTMF, in a
separate thread. If you disagree with the details of that API, please
comment in that thread.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 18 Nov 2011 19:57:47 +0100

> Unfortunately draft-kaplan-dispatch-info-dtmf-package will never become a standard.  I presented it a couple IETF meetings ago, and was basically told to go away and never bring it back to the IETF…

Opss... then, why do we need the "SIP INFO Method and Package
Framework"? just for having a generic "framework"? for nothing?
It's hard to believe :(

> We can't choose whether to support DTMF in signaling or not, because it's possible to do it even right now today on any browser, without any changes whatsoever

But what is the real DTMF alternative in the signaling plane? using
INFO as so many devices do? such usage has drawbacks, those DTMF's are
not negotiated and so.

Or do you mean SIP KPML (the most exotic and complex mechanism for
sending simple DTMF's)? I'm pretty sure that 99% of existing SIP
devices do not implement KPML (does it really mean that a PSTN GW
should subscribe to any peer fom which it receives an INVITE?? it
sounds really annoying IMHO.

> So if it's not too hard to add, it would be great to support RFC 4733 as well, so we can let the web-app provider work with even more non-WebRTC devices.  And we've been told it shouldn't be too ha…

I'm not 100% opposed to implementing RFC 4733 in WebRTC. But AFAIK,
instead of creating a cool API, the only worry is about implementing
all the requirements of SIP protocol (and others).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Nov 2011 14:33:02 -0500

On Fri, Nov 18, 2011 at 1:57 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> > Unfortunately draft-kaplan-dispatch-info-dtmf-package will never become
> a standard.  I presented it a couple IETF meetings ago, and was basically
> told to go away and never bring it back to the IETF.  (despite the fact it
> was the main use-case and motivation for creating INFO packages to begin
> with)
>
This whole framework was shut down because it was not usable for some
applications (record and press # type) due to luck of synchronization with
media stream. Since it did not work for some applications it was ruled to
be generally undesirable. Kind of similar to the SRTP discussion we were
having on this list. The result is interesting too: whoever needed DTMF
over INFO ignored that it is not a standard and used it anyway (since it
has applications were it is desirable, like calling cards).

Instead of DTMF specific API, I would prefer a mechanism for CODEC specific
extensions and implement DTMF this way.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Fri, 18 Nov 2011 15:02:17 -0500

On Fri, Nov 18, 2011 at 2:33 PM, Roman Shpount <[email-masked]> wrote:

> Instead of DTMF specific API, I would prefer a mechanism for CODEC
> specific extensions and implement DTMF this way.
>

Can you make a proposal for what you'd like to see here? My view is that
DTMF is a special case already, so the most pragmatic approach is a special
case DTMF API.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Nov 2011 15:56:04 -0500

> DTMF is a special case already, so the most pragmatic approach is a special

DTMF is somewhat a special case due to fast payload switching. So, it might
need its own specific API.

What I was thinking is something a long the line of
sendCodecCommand(payloadType, JSONObject). In case of DTMF the JSON object
should have digitString and digitDuration parameters (maybe more, but this
is up for the group to decide if we want to specify pause duration and
volume). Having a CODEC specific command is helpful, since this will allow
control of codec specific options that can be changed without offer/answer,
such as encoder complexity or enabling decoder post processing filters,
without polluting the API.
_____________
Roman Shpount

---

From: Mary Barnes <[email-masked]>
Date: Fri, 18 Nov 2011 20:29:40 -0600

> concerns the in-the-wire signaling it becomes up to the application
That document will not become a standard.  We already dispatched it
(scroll down to IETF-79):
http://trac.tools.ietf.org/wg/dispatch/trac/wiki

Mary.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Nov 2011 21:55:58 -0500

On Fri, Nov 18, 2011 at 3:56 PM, Roman Shpount <[email-masked]> wrote:

> DTMF is somewhat a special case due to fast payload switching. So, it
> might need its own specific API.
>

Since my proposal caused some confusion I wanted to clarify it a bit. I do
want WebRTC to support RFC 4733. What I meant in the previous email was
that it might be be better to implement payload specific type features
through some sort of generic codec control API. So, instead of using
sendDTMF command on peer connection, we could do
sendCodecCommand('telephone-event', 'digitstring: "1234"') to implement the
same thing. This will also be useful for other codecs like
sendCodecCommand('ilbc', 'enhancer: true') or sendCodecCommand('silk',
'red: true, redPercent:10') without defining a new ilbc or silk specific
API.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 19 Nov 2011 09:41:28 +0100

Hi,

3GPP has defined a simple DTMF Info Package, some time ago. 

I don't see it in the IANA Info Package registry, though, so I will look into that.

However, the Info Package defininion can be found in 3GPP TS 24.449, Annex P.

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
> Sent: 18. marraskuuta 2011 20:58
> To: Hadriel Kaplan
> Cc: <[email-masked]>
> Subject: Re: [rtcweb] Support DTMF "codec" or expose DTMF in 
> signaling? (Re: DTMF usecase before DTMF API)
> 
> > Unfortunately draft-kaplan-dispatch-info-dtmf-package will never 
> > become a standard.  I presented it a couple IETF meetings 
> ago, and was 
> > basically told to go away and never bring it back to the IETF.  
> > (despite the fact it was the main use-case and motivation 
> for creating 
> > INFO packages to begin with)
> 
> > We can't choose whether to support DTMF in signaling or 
> not, because 
> >it's possible to do it even right now today on any browser, 
> without any 
> >changes whatsoever
> 
> But what is the real DTMF alternative in the signaling plane? 
> using INFO as so many devices do? such usage has drawbacks, 
> those DTMF's are not negotiated and so.
> 
> Or do you mean SIP KPML (the most exotic and complex 
> mechanism for sending simple DTMF's)? I'm pretty sure that 
> 99% of existing SIP devices do not implement KPML (does it 
> really mean that a PSTN GW should subscribe to any peer fom 
> which it receives an INVITE?? it sounds really annoying IMHO.
> 
> 
> > So if it's not too hard to add, it would be great to 
> support RFC 4733 as well, so we can let the web-app provider 
> work with even more non-WebRTC devices.  And we've been told 
> it shouldn't be too hard to add, so why do you care?  If you 
> don't want to use it in your web-app, don't.
> 
> I'm not 100% opposed to implementing RFC 4733 in WebRTC. But 
> AFAIK, instead of creating a cool API, the only worry is 
> about implementing all the requirements of SIP protocol (and others).
> 
> --
> Iñaki Baz Castillo
> <[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Sat, 19 Nov 2011 09:32:23 +0000

On 17 Nov 2011, at 15:13, Randell Jesup wrote:

> 
> 
> For on-off times, 'hidden' configs (about:config in Firefox) would be fine by me.  I wouldn't mandate they be configurable.  We should choose a default on and off time based on surveying existing equipment. (I'll probably suggest something like 80/50 or 100/60.)  The default on/off time should be a SHOULD.

That 'hidden config' would impact _all_ usages of web RTC, not just the site that needed the change.
So changing them to make the  remote-webcam-steering work on one site would potentially
break a subsequent call to a banking IVR? 

If tweaks are needed they should to be per-site, and the cleanest way to do  that is offer a javascript API.
Otherwise you get into include/exclude lists as used in the proxy-bypass dialogs.

Tim.

---

From: Randell Jesup <[email-masked]>
Date: Sat, 19 Nov 2011 08:00:47 -0500

> break a subsequent call to a banking IVR?

Increasing them (within reason) never breaks things (decreasing can). 
I've never seen any ATA or other endpoint that needed per-destination 
DTMF on/off configs; they're occasionally available in case the defaults 
are too low.  (Lower == faster dialing, about the only advantage of 
smaller values.)

> Otherwise you get into include/exclude lists as used in the proxy-bypass

I disagree.  Way too complex, and it would never be used in practice.  I 
would not mandate configs, just a minimum, and if an implementation 
wants to include configs it can.

-- 
Randell Jesup
[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Sat, 19 Nov 2011 08:41:26 -0500

On Sat, Nov 19, 2011 at 4:32 AM, Tim Panton <[email-masked]> wrote:

> fine by me.  I wouldn't mandate they be configurable.  We should choose a
> default on and off time based on surveying existing equipment. (I'll
> probably suggest something like 80/50 or 100/60.)  The default on/off time
> should be a SHOULD.
>
>
One more thing to note is that there are certain IVR menus that distinguish
between long and short DTMF digits, for example a lot of calling cards use
long pound (pound DTMF digit of long duration) to initiate an IVR menu in
the middle of the call. This means that application must have at least the
control of the on DTMF digit duration. Off duration is much less frequently
changed, and if needed can be simulated by an external JS timer.

One other thing that we can do for on/off DTMF digit control is to enable
something like "6-" in DTMF digit string (note the trailing dash). This
will initiate a continuous playback of DTMF digit 6 until a new dtmf API
call (including an API call with empty string) is issued. If we implement
something like this, we can control on DTMF digit duration from JS,
including play DTMF while digit is pressed.
_____________
Roman Shpount