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

Re: DTMF v4

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 17 Dec 2012 20:27:27 +0100
Message-ID: <50CF721F.3020202@alvestrand.no>
To: Martin Thomson <martin.thomson@gmail.com>
CC: "Pastro, Rodrigo" <rodrigo.pastro@siemens-enterprise.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 12/17/2012 05:31 PM, Martin Thomson wrote:
> On 17 December 2012 04:28, Harald Alvestrand <harald@alvestrand.no> wrote:
>>> According to the current spec, if insertDTMF is called on the same object
>>> while an existing task for this object to generate DTMF is still running,
>>> the previous task is canceled. Is there a "tonechange" event indicating that
>>> the previous sequence has been canceled? The same question also applies to
>>> the case insertDTMF is called with an empty string to cancel the tones being
>>> sent.
>> Text change. See if you like the new one.
> I have a different view on this.  If there is a sequence playing out,
> the task should not be cancelled, the pending tones should be replaced
> with the new tone string.  Since we can't "recall" a tone, this allows
> the tone duration and spacing to be respected.  It also enables code
> like:
>
>      sender.insertDTMF('');
>      sender.ontonechange = function(e) {
>          var next = tones.shift();
>          e.target.insertDTMF(next.tone, next.duration);
>      };
>
> Without proper spacing, the tones would all run into each other, as
> fast as the event loop can spit them out.
>
> But that assumes that we fire the empty string tonechange event when
> an empty string is provided.  That is what the pseudocode says, but I
> can imagine some zealous programmer deciding to prevent this.
I think that's exactly what the current text says, so I've problems 
seeing the "different view".
Specifically, the async part of the algorithm says (from the 
not-yet-published editor's copy):

 1. If the tone buffer is empty, fire a "tonechange" event at the
    object, with an empty string as its parameter, and stop.
 2. Start playout of the tone corresponding to the first character in
    the tone buffer on the associated RTP media stream, using the
    appropriate codec.
 3. Fire a "tonechange" event at the object, with an event parameter
    consisting of the first character of the tone buffer.
 4. Remove the first character of the tone buffer.
 5. Wait for the number of milliseconds specified by the value of the
    duration parameter.
 6. Stop playout of the tone.
 7. Wait for the value of the required interĀ­tone gap.
 8. Go back to step 1.

(numbering is different)

Would it be clearer if we add a sentence saying "Note that it's 
important that the tone process waits for the inter-tone period before 
terminating, as this is essential to preserving the inter-tone gap in 
all cases"?
Received on Monday, 17 December 2012 19:28:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 December 2012 19:28:02 GMT