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

Looks good.  A few comments.

s/ontonechange/ontone/
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
construction).

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