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

Re: DTMF

From: Tim Panton <thp@westhawk.co.uk>
Date: Thu, 19 Jul 2012 13:03:37 +0100
Cc: public-webrtc@w3.org
Message-Id: <18B15500-948A-4F19-AB85-0482B34012E3@westhawk.co.uk>
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>

On 19 Jul 2012, at 12: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?
> 
> 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.
> 


All legacy signalling protocols I can think of have the ability to carry DTMF. Why do we want to make this a media issue ?
Can't we just say it is out of scope an let the application's selected signalling deal with it?

Tim.

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk
Received on Thursday, 19 July 2012 12:04:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC