W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2012

Re: V2 of DTMF - the "Object Oriented" approach

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 16 Nov 2012 08:28:43 -0800
Message-ID: <CABkgnnXxW=D3rfrefnGj4Yio3NNxJ9pVvtKOvsAp1Wf9U49-BA@mail.gmail.com>
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Looks good.  A few comments.

s/ InsertDTMF/ insertDTMF/

RTCDTMFSender is a [NoInterfaceObject], so it's name doesn't matter
(it has a factory method on RTCPeerConnection, no need for independent

I think that we agreed that all tones would be of a known length, so
there is no need to event on tone end.

Steps 4+ might be better as:

4. Remove the first tone from the tone queue/buffer.
5. If the queue was empty, fire a 'tone' event with an empty tone and
undefined duration, end processing.
6. Fire a 'tone' event with the selected tone and duration.
7. Add the tone to the outgoing stream.
8. Schedule a task to re-run these steps after (tone duration +
inter-tone spacing).

This ensures that the 'end tone' event doesn't fire immediately after
the last tone was sent.  It also allows for a programming model where
each new tone is inserted by the application upon receipt of the event
for the last tone.

Do we permit the insertion of tones with varying durations?  I forget
what the conclusion was there.  If varying duration is possible, then
we need to store tuples of tone + duration in the queue/buffer.

On 16 November 2012 05:30, Stefan Hakansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
Received on Friday, 16 November 2012 16:29:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:35 UTC