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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 19 Nov 2012 02:21:24 +0100
Message-ID: <50A98994.1030900@alvestrand.no>
To: public-webrtc@w3.org
On 11/16/2012 05:28 PM, Martin Thomson wrote:
> Looks good.  A few comments.
>
> s/ontonechange/ontone/
The reason for calling it "ontonechange" was that I'm also proposing to 
call it at tone end.
> 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.
I don't remember such an agreement.
The length is part of the parameters. If the tone insertion and JS 
timers were both completely predictable, there would be no need for a 
callback at all.

Having the callback has the advantage that the feedback signal and the 
tone playout can't get out of sync; this applies as much at the end of 
the tone sequene as at intermediate steps.

>
> 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.
Are you proposing that the buffer is a FIFO? I'd thought that the buffer 
would be a string that was reset on a new tone. FIFO's fine with me (but 
then we need an "abort" call too).

>
> 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.
The insertDTMF call has only a single "duration" parameter, which I 
think is the duration of each tone in the string. If the buffer is a 
FIFO, we need tuples.
>
> On 16 November 2012 05:30, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>>
Received on Monday, 19 November 2012 01:21:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 19 November 2012 01:21:55 GMT