W3C home > Mailing lists > Public > public-orca@w3.org > September 2013

RE: DTMF API completed

From: Martin Thomson <martin.thomson@skype.net>
Date: Tue, 3 Sep 2013 16:34:23 +0000
To: Iñaki Baz Castillo <ibc@aliax.net>, public-orca <public-orca@w3.org>
Message-ID: <88EA7D224AA4F24F9D7628368F7572A91A673790@TK5EX14MBXC296.redmond.corp.microsoft.com>
Unfortunately, this will be unable to produce DTMF that is compatible with any existing DTMF sender or receiver.  The problem is that the DTMFTrack is a standalone entity that does not associate with an existing audio track.

I made a proposal to the W3C working group that looks similar to this API in many respects, but the DTMFTrack was a wrapper around AudioMediaStreamTrack.  It could equally be a wrapper around RTCTrack.  Inbound audio tracks are automatically wrapped, if they contain the DTMF codec description.

This has another properties that I believe to be important: the DTMF interfaces are completely standalone.  The rest of the API has no direct, visible knowledge of DTMF.

> -----Original Message-----
> From: Iñaki Baz Castillo [mailto:ibc@aliax.net]
> Sent: Monday, 2 September, 2013 9:15
> To: public-orca
> Subject: DTMF API completed
> Hi, I've added full DTMF API to ORTC as the existing one was incomplete (and
> buggy):
> https://github.com/openpeer/ortc/commit/a817775a28cadae4e7c279ad69b

> 0f96b17d13fd9
> The proposal is to use a new RTCDTMFTrack class for sending, and another
> one for receiving. Such a RTCDTMFTrack is added into the RTCConnection and
> has its associated RTCTrack (as any MediaCapture MediaStreamTrack).
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>

Received on Tuesday, 3 September 2013 16:40:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:21 UTC