Re: [Bug 18485] Change DTMF API to be on PeerConnection

On 2012-08-10 18:03, Randell Jesup wrote:
> On 8/10/2012 11:49 AM, Martin Thomson wrote:
>> On 10 August 2012 05:49, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote:
>
>>> I don't see any reason why the DtmfAudioStreamTrack needs to be a
>>> MediaStreamTrack. We could simply have an object that's used as a remote to
>>> insert and receive DTMF on associated MediaStreamTrack objects.
>>>
>>> [Constructor(MediaStreamTrack outgoingAudioTrack,
>>>       optional MediaStreamTrack incomingAudioTrack)]
>>> interface DtmfTransceiver : EventTarget {
>>>       void playTones (DOMString tones,
>>>               optional unsigned long duration = 100);
>>>       void startTone (DOMString tone);
>>>       void endTone ();
>>>
>>>       attribute Function? ontone;
>>> };
>>
>> This also works.  The complication here is for the browser
>> implementation: audio tracks will all need to know about DTMF so that
>> they can carry it.  There would be browser-private interfaces for
>> sending and receiving tones that are only exposed once the descriptor
>> is added.  Sure, this would be hidden from users, but the core audio
>> track implementation would carry the burden of DTMF support.  That
>> negates the benefits of isolation for the browser implementation.
>>
>> I don't follow your reasoning for having two tracks attached to the
>> tranceiver.  Can you explain how that would be useful?
>
> The incoming track would be for local echo.  Using an audio element in
> the app for local echo invites the possibility of the local tone not
> being echo-cancelled and leaking into the outbound stream (especially if
> the developer guesses wrong at the length/start-time of the outgoing
> 'tone'), causing possible double-detection in an IVR. Everyone I've seen
> who puts a number pad in a phone or softphone does something in audio
> when you hit one (generic beep or DTMF tone normally), so one would
> expect anyone building an app which expects to access PSTN gateways to
> include that.  This makes it easier for them to not shoot themselves in
> the foot.   It's not mandatory, but likely would be a source of
> frustration and odd hard-to-reproduce bugs and possibly
> works-in-one-browser but fails 1-in-20-times in another browser.

That's one use. The idl also has an ontone event listener attribute 
which I interpret as a way for a browser to get events when DTMF tones 
are received. So the track for incoming tones needs to be specified. 
Again, I don't think that functionality is top priority but it was 
present in Martin's idl so I kept it.

/Adam

Received on Monday, 13 August 2012 08:33:41 UTC