Re: DTMF again

On Sat, Dec 10, 2011 at 2:07 AM, Stefan Hakansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

>  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> 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> 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.
>
Given the usage below "insert" is fine by 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
> http://lists.w3.org/Archives/Public/public-webrtc/2011Nov/0098.html).
>
>
>
>>  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)
>>>
>>>
>>>
>>
>>
>
>
I think at this point the only open topic on DTMF is how we indicate that
DTMF can be inserted into a stream (i.e. in a stream attached to a
peerconnection, whether the remote side supports telephone-event). Harald
had suggested that the DTMF API only be present on a stream if that stream
supports DTMF, but I'd like to get more feedback from others (especially
folks with WebIDL experience) on that approach.