W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2011

Re: DTMF again

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 13 Dec 2011 10:51:50 +0100
Message-ID: <4EE72036.3080209@ericsson.com>
To: Justin Uberti <juberti@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 12/12/2011 06:59 PM, Justin Uberti wrote:
>
>
> On Mon, Dec 12, 2011 at 10:01 AM, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     Top posting (sorry):
>
>     is there a problem suporting long tones? With the proposal further
>     below, it is fine to specify different duration, but for a situation
>     where the user enters DTMF by use of some kind of (virtual) dial
>     pad, and clicks on say "2" but does not release the mouse for a long
>     time, then you could imagine that there is a need to start inserting
>     DTMF before you know the length.
>
>     This would call for something like
>
>     beginDTMF("1"); //e.g. called on mousedown
>     endDTMF();      //e.g. called on mouseup
>
>     I think RFC 4733 has support for this kind of unknown length DTMF.
>
>
> This was discussed a couple weeks back, but the consensus at the time
> was that this wasn't needed by our current set of use cases.
OK, I missed that.

>
> However, I'd be open to adding a cancelDTMF() method to stop playing any
> current or queued DTMF. This could allow for mouseup/down handling
> without complicating the simple case that just needs a single function call.
Well, my view then would be to just do what is proposed below for the 
time being, and add more in a second release if there is need/interest.

>
>
>
>     Stefan
>
>
>
>     On 12/12/2011 03:48 PM, Harald Alvestrand wrote:
>
>         On 12/09/2011 11:07 AM, Stefan Hakansson LK wrote:
>
>             On 12/09/2011 07:59 PM, Justin Uberti wrote:
>
>
>
>                 On Thu, Dec 1, 2011 at 8:20 AM, Stefan HÃ¥kansson LK
>                 <stefan.lk.hakansson@ericsson.__com
>                 <mailto:stefan.lk.hakansson@ericsson.com>
>                 <mailto:stefan.lk.hakansson@__ericsson.com
>                 <mailto:stefan.lk.hakansson@ericsson.com>>> wrote:
>
>                     So, a concrete proposal:
>
>                     we define the operation "insertDTMF" that is
>                 available on
>                     AudioMediaStreamTrack's (or should that be named
>                 AudioStreamTrack?):
>
>                     insertDTMF("1")  // plays tone 1 for 50 ms
>                     insertDTMF("2", 200)  // plays tone 2 for 200 ms
>                     insertDTMF("123")  // plays tones 1, 2, 3 in
>                 succession, each for
>                     50 ms
>                     insertDTMF("456", 200)  // plays tones 4, 5, 6 in
>                 succession,
>                     each for 200 ms
>
>                     (I prefer "insert" over "send" as nothing is sent
>                 unless the
>                     MediaStream that the AudioStreamTrack belongs to is
>                 added to a
>                     PeerConnection)
>
>
>                 I think the name "sendDTMF" is slightly more intuitive,
>                 but I can see
>                 your point too. If others prefer sendDTMF I'm fine with
>                 that.
>
>
>                 "insertDTMF" leads to the insertion of the actual tones
>                 in the
>                     audio, so if the MediaStream in question is attached
>                 to an audio
>                     element, those tones would be played out. This has
>                 the advantage
>                     that it is much simpler to locally give audio
>                 feedback to the
>                     user that dtmf is sent - when I use DTMF on my phone
>                 I hear the
>                     tones.
>
>
>                 Not sure what you mean here. Do you mean if the local
>                 media stream
>                 was hooked up to an <audio/>, the tones would be played
>                 out? If so,
>                 wouldn't that mean that your own voice is being fed back
>                 to the audio
>                 output (which I'm sure we don't want)?
>
>             I meant like this:
>
>             Imagine you do "insertDTMF()" on an audio track of an
>             outgoing stream
>             (to send DTMF to the other end), if you now want an audio
>             feedback to
>             the person sending the DTMF, you could simultaneously do
>             "insertDTMF"
>             on the audio track of the incoming MediaStream (assuming a
>             bidirectional session). That would lead to that you hear the
>             tones
>             locally as you push the dial pad to generate them.
>
>             So, you would not hear yourself!
>
>         This (application uses insertDTMF on the stream heading towards the
>         speakers) seems right to me. Whether or not tones are played back
>         locally should be the application's decision, not the API's.
>
>                         Harald
>
>
>
>
>
Received on Tuesday, 13 December 2011 10:10:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:26 UTC