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

If the main point of DTMF is legacy interoperability, I doubt that we need variable-length tones.  Traditional touch-tone IVR systems certainly don't use them.  Is there some other strange kind of legacy device that relies on them?

- Jim

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Friday, November 16, 2012 11:29 AM
To: Stefan Hakansson LK
Cc: public-webrtc@w3.org
Subject: 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:
>
>

Received on Friday, 16 November 2012 16:40:36 UTC