Re: Where to attach a DTMF API

On 11/30/2011 05:25 AM, Justin Uberti wrote:

>     Unlike Stefan, I think the API makes most sense if it's an API on a
>     MediaStreamTrack object. If it is an API on a PeerConnection, it
>     would have to be something like PeerConnection.DTMF(StreamID,
>     TrackID, "12345"), which seems somewhat bizarre. It could easily be
>     defined to generate failure if the other end of the MediaStreamTrack
>     is not a playout into a PeerConnection.
I had a simpler, but error prone, proposal which meant you would not 
have to supply Stream aor TrackID.
>
>
> This matches my viewpoint. We've created a nice object-oriented API, so
> I'd like to maintain that design as much as possible, even if means a
> bit more implementation work.
It seems that most people want to go this way (i.e. attach sendDTMF to a 
MediaStreamTrack), so this is probably what we should do.

A follow up question: if that track is recorded or played out locally or 
remotely, should there be any traces/signs of the DTMF inserted? You 
could imagine that the actual tones are played/recorded, but you could 
equally well imagine that there are no signs of the DTMF stuff when 
recording/playing out.

>
> Followup question: should we define a specific AudioMediaStreamTrack
> that inherits from MediaStreamTrack, and only expose this DTMF API on
> AudioMediaStreamTracks?
Without thinking very much about it, defining separate 
AudioMediaStreamTrack and VideoMediaStreamTrack makes sense to me.
> Or should we expose it from all tracks, and have
> it throw an exception on tracks that don't support DTMF? And how should
> apps know if DTMF is supported?
>
> My suggestion would be to introduce AudioMediaStreamTrack, and have the
> DTMF API fail if the other side doesn't support telephone-event. Support
> for telephone-event can be determined from parsing the incoming SDP
> (with ROAP), or the PeerConnection.remoteDescription method (with JSEP).
Sounds reasonable to me.
>

Received on Wednesday, 30 November 2011 07:46:15 UTC