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

Re: DTMF again

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Sat, 10 Dec 2011 08:07:09 +0100
Message-ID: <4EE3051D.7000105@ericsson.com>
To: Justin Uberti <juberti@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 12/09/2011 08:17 PM, Justin Uberti wrote:
> On Fri, Dec 9, 2011 at 2:07 PM, Stefan Hakansson LK 
> <stefan.lk.hakansson@ericsson.com 
> <mailto:stefan.lk.hakansson@ericsson.com>> 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>> 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.
I'm not that attached to "insert", any way (or perhaps just "DTMF") is 
fine with me.

>>         "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!
> OK, I get it. If a "null" AudioTrack could be created, this could also 
> be used to play out tones as a user dials from the keypad.

Exactly. And I think we've already identified the need for that "null" 
AudioTrack for situations when you want to send DTMF without access to 
the microphone (as Neil pointed out in 

>>     I agree we want to allow the tones to optionally be played out
>>     locally, but I think we need a different mechanism to control
>>     this (possibly a flag on the stream or API call).
>>         "insertDTMF" also, if the MediaStream in question is attached
>>         to an open PeerConnection, leads to RTP packets according to
>>         RFC4733 being inserted in the RTP stream corresponding to
>>         this AudioStreamTrack.
>>         (if reception of DTMF is also supported by the browser, I
>>         guess that in addition to inserting the tones in the
>>         AudioStreamTrack, events informing the application should be
>>         dispatched)
Received on Saturday, 10 December 2011 07:07:52 UTC

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