Re: DTMF

On 2012-07-19 13:42, Stefan Hakansson LK wrote:
> On 07/18/2012 10:05 PM, Randell Jesup wrote:
>> On 7/18/2012 2:10 PM, Justin Uberti wrote:
>>>
>>>
>>>
>>> On Wed, Jul 18, 2012 at 6:19 AM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ)
>>> <tommyw@google.com <mailto:tommyw@google.com>> wrote:
>>>
>>>      I found two things that I would like clarification on while trying
>>>      to implement this.
>>>
>>>      Firstly, can someone clarify how the DTMF information should flow
>>>      from one PeerConnection to another? The current editors draft
>>>      implies that the data should go as a string since the other side
>>>      will have a notification somehow that DTMF data has arrived but it
>>>      isn't written out explicitly.
>>>
>>>          Editor Note: It seems we would want a callback or event for
>>>          incoming tones. The proposal sent to the list had them played
>>>          as audio to the speaker but I don’t see how that is useful.
>>>
>>>
>>>      If the data should flow as a string, and not mixed into the
>>>      outgoing audio track, then I argue that this API should be
>>>      scrapped and the data channel should be used for this kind of
>>>      functionality. If the DTMF should be mixed into the outgoing audio
>>>      then no notification should pop up on the other side.
>>>
>>>
>>> The data is mixed into the outgoing audio track as DTMF events.
>>> Handling of incoming tones isn't important right now, apps that need
>>> to receive data can use better mechanisms, as you point out.
>>
>> An app that wants to accept incoming calls originating in the PSTN
>> network and interact with the user (think answering machine, or home
>> automation control, etc) needs to be notified of incoming DTMF events.
>> They don't need to be echoed into the audio stream, though that's a
>> minor nice-to-have.
> I think I proposed at one time that DTMF should be echoed into the audio
> stream. I did that for two purposes:
> 1. It seems very strange to me to have an operation on an audio stream
> track that has no meaning outside the RTP transmission of a
> PeerConnection. What should happen if you have a MediaStream locally
> only, and do "insertDTMF"?
> 2. It would make local feedback simpler. At least on my phone, when I
> use DTMF (which may be sent over the network using DTMF events - I don't
> know really and don't care), tones are played locally as a feedback. I
> assume that many app developers would like the behavior, and if
> "insertDTMF", for a MediaStreamTrack that is connected to an audio
> element, did play out as tones you would have that feedback for free.
> (There are other ways to do it for sure, it is more nice-to-have).
>
> That were my reasoning. But if "insertDTMF" should only mean "transmit
> DTMF events", perhaps is should be an operation on PeerConnection
> instead. Could we do something like Harald proposed for stats: have
> something you can do on what is in localStreams?

I think this is worth looking into. DTMF doesn't make sense in a local 
only case so it would be nice to avoid having the DTMF API in the 
MediaStream API and instead attach it to PeerConnection (e.g. 
peerConn.sendDTFM(targetAudioTrack, dtmfData ...);).

/Adam

> That said, I agree to Tommy. I think for browser-to-borwser use, DTMF is
> pointless, and for browser-to-legacy DTMF could be signaled as data of
> some sort to a GW that translates to DTMF events.
>
>
>
>>
>> --
>> Randell Jesup
>> randell-ietf@jesup.org
>>
>
>

Received on Tuesday, 7 August 2012 15:33:14 UTC