- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 07 Aug 2012 21:02:36 +0200
- To: public-webrtc@w3.org
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