W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2012

Re: DTMF

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 19 Jul 2012 13:42:02 +0200
Message-ID: <5007F28A.20602@ericsson.com>
To: public-webrtc@w3.org
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?

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 Thursday, 19 July 2012 11:42:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:35:46 UTC