- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Wed, 18 Jul 2012 16:05:16 -0400
- To: public-webrtc@w3.org
- Message-ID: <500716FC.8050607@jesup.org>
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. -- Randell Jesup randell-ietf@jesup.org
Received on Wednesday, 18 July 2012 20:05:39 UTC