- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 16 Nov 2012 08:28:43 -0800
- To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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:29:14 UTC