- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 13 Dec 2011 10:51:50 +0100
- 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