- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 19 Nov 2012 02:22:23 +0100
- 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 UTC