- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Tue, 7 Aug 2012 17:32:46 +0200
- To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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