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:22:23 +0100
Message-ID: <50A989CF.8030604@alvestrand.no>
To: public-webrtc@w3.org
On 11/16/2012 05:38 PM, Jim Barnett wrote:
> 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?
The classic use case mentioned is tone-controlled pan/tilt cameras. I 
think the 50 ms inter-tone spacing won't hurt that use case much.

>
> - 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 Monday, 19 November 2012 01:22:51 GMT

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