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

On 10 August 2012 05:49, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote:
> I like this approach since it doesn't pollute the general part of the
> MediaStream API with DTMF functionality at same time as it doesn't add more
> functions to the PeerConnection API.

That was the reasoning behind the design.  DTMF is an artifact of our
desire to interoperate with some legacy stuff, but it has no real
place on the web.  Isolation is a good way to minimize the
(architectural) harm that it causes.

> One thing that might be confusing for developers is how the original
> MediaStreamTrack and the new DtmfAudioStreamTrack relate to each other since
> they are both MediaStreamTrack objects. Do I need to add the
> DtmfAudioStreamTrack to the same stream that provided the MediaStreamTrack
> (passed to the constructor) and send that stream with PeerConnection. Should
> it go into a MediaStream on it's own? If the tracks are in the same stream
> and transmitted with PeerConnection, what happens if I remove the
> MediaStreamTrack that was used to create the DtmfAudioStreamTrack? The
> DtmfAudioStreamTrack could also be added to another stream that is sent
> somewhere else than the MediaStreamTrack used to create the
> DtmfAudioStreamTrack. Should the DtmfAudioStreamTrack be in the
> MediaStream.audioTracks list? It doesn't really behave as a normal
> MediaStreamTrack.

I see your point, though I don't think that it is as complicated as
you make out.

A DtmfTrack is a Track (shorthand used here because I'm lazy).  If you
add a Track you get the track; if you add a DtmfTrack, then you get
the track plus DTMF.  Adding DTMF means creating a DtmfTrack and
reassembling the MediaStream with the replaced track.  If you add both
Track and DtmfTrack, then you get two tracks from the same source, one
with DTMF decoration.

The linkage might be a concern.  Ending a Track will end the matched
DtmfTrack, and vice versa.  Again, that event is something that can
happen on any stream for a number of reasons, another reason doesn't
bother me greatly.

> 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?

> We could initially skip the ontone stuff and add it back if we decide that
> we need to be able to receive DTMF as well.

Right. Though specification is cheap, I don't have enough information
about the implementation cost to make a good determination about this.

--Martin

Received on Friday, 10 August 2012 15:49:33 UTC