Re: DTMF

On 08/07/2012 05:32 PM, Adam Bergkvist wrote:
> 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, the proposal currently on the table is discussed with this subject:

CHANGE: Re: [Bug 18485] New: Change DTMF API to be on PeerConnection

So far, all the responses have been positive; if this continues for 
another day, we'll just tell the editors to make the change.

>
> /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 19:02:59 UTC