Re: DTMF

On 08/09/2012 12:09 AM, Martin Thomson wrote:
> 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 see it a bit differently. I see DTMF as an artifact, and would like to 
hide it as much as possible. Putting it as an something (obscure) on 
PeerConnection in that sense feels better to me than making it part of 
MediaStreams. But that is just my personal view.

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

That is absolutely correct. I thought that was OK (there would be a way 
to send DTMF, you could have a keypad to enter, but you can't reflect 
the length). But I think having something like "startDTMF" and "endDTMF" 
is quite simple even if operating on PeerConnection.

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

This is definitely a good alternative to do things if we make DTMF part 
of MediaStream's (and not PeerConnection, which seems better to me 
personally).

>
> 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 Thursday, 9 August 2012 19:47:58 UTC