Re: DTMF again

On Mon, Dec 12, 2011 at 10:01 AM, Stefan Hakansson LK <
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.

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.


>
> 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 <stefan.lk.hakansson@ericsson.com>
>>>> <mailto:stefan.lk.hakansson@**ericsson.com<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
>>
>>
>>
>
>