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

Re: DTMF again

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Mon, 12 Dec 2011 16:01:43 +0100
Message-ID: <4EE61757.9080807@ericsson.com>
To: public-webrtc@w3.org
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.

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>> 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 Monday, 12 December 2011 16:54:29 UTC

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