Re: DTMF

Obviously, it is more important to be able to add DTMF than it is to
receive it.  In the MS API proposal, we opted not to include a
definition for DTMF because this feature is a MediaStream property
(consistent with the current draft).  Making this yet another
PeerConnection function is not the correct architectural choice, even
if it might be argued as being expedient.

I did draft up a proposal that had DTMF as a wrapper on a MediaStream.
 Looking the API as currently proposed, it is clear that it couldn't
be implemented as a keypad interface: the length of tones cannot be
accurately conveyed.

This is what the API looks like:

[Constructor(MediaStreamTrack audioTrack)]
interface DtmfAudioStreamTrack : MediaStreamTrack, EventTarget {
    void playTones (DOMString tones, optional unsigned long duration = 100);
    void startTone (DOMString tone);
    void endTone ();

    attribute DtmfCallback? ontone;
};

The idea was to create an audio track and then wrap that track using
this class if DTMF sending was required.  RealtimeMediaStream objects
that arrive from the network with the DTMF codec present are decorated
at creation time so that these methods (particularly the event
handler) are present.

Note that decorating an audio track with DTMF messes with the security
properties of a stream as it relates to any assertions that might be
made with respect to the authenticity of a stream.

--Martin

Received on Wednesday, 8 August 2012 22:10:24 UTC