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

On 11/19/2012 12:09 PM, Adam Bergkvist wrote:
> On 2012-11-16 14:30, Stefan Hakansson LK wrote:
>> I think this is starting to become baked enough to be incorporated in
>> the Editor's draft. A couple of minor comments in-line.
>>
>> Stefan
>>
>> On 11/16/2012 12:56 PM, Harald Alvestrand wrote:
>>> I realized that I'd forgotten about the callback / event aspect of the
>>> DTMFSender!
>>>
>>> Feedback so far:
>>> - No need to inherit from MediaStreamTrack
>>> - Name's ugly, but we can live with it
>>>
>>> If we don't need to inherit, name can be a little nicer. I like to keep
>>> the RTC prefix.
>>>
>>> Modified version:
>>>
>>> On 11/14/2012 03:46 PM, Harald Alvestrand wrote:
>>>> Takeaways from Lyon were that:
>>>>
>>>> - Executing DTMF needs reference to an audio track (to know where to
>>>> send the data) and to a PeerConnection (to know that we've
>>>> successfully negotiated use of the DTMF codec).
>>>> - The WG preferred an "object oriented" model: creating a DTMF handler
>>>> object, rather than the "fortran" approach of having all functions
>>>> directly on the PeerConnection.
>>>>
>>>> Suggested edits, delta from the October 19 version of the spec:
>>>>
>>>> - In section 8.4, rename AudioMediaStreamTrack to RTCDTMFSender.
>>>> Remove inheritance.
>>>> Add the following text:
>>>>
>>>> A RTCDTMFSender is created by calling the createDTMFSender() method on
>>>> a PeerConnection. This constructs an object that exposes the functions
>>>> required to send DTMF.
>>> NEW IN THIS VERSION:
>>>
>>> Add to RTCDTMFSender:
>>>
>>>     attribute EventHandler ontonechange;
>>>
>>> Add text under 8.4.2 "InsertDTMF":
>>>
>>>     When InsertDTMF is called, do the following:
>>>
>>>     1. If the associated MediaStreamTrack is not connected to the
>>> associated PeerConnection, return.
>>>     2. If canInsertDTMF is false, return.
>>>     3. Set the value of the tone buffer to the "tones" argument.
>>>         Return, but continue the following steps asynchronously.
>>>
>>>     The following steps take place asynchronously.
>>>     4. Start playout of the tone on the associated RTP media stream,
>>> using the appropriate codec.
>>>     5. Fire a "tonechange" event at the object, with an event parameter
>>> consisting of the first character
>>>     of the tone buffer. Remove the first character of the tone buffer.
>>>     6. If the tone buffer is empty, fire a "tonechange" event at the
>>> object, with an empty string as
>>>         its parameter, and stop.
>>>     7. Schedule a task for <duration> milliseconds later, which will
>>> repeat steps 4-7.
>>
>> Should not all the above be moved to some other section (it is not a
>> MediaStreamTrack any more)?
>
> I agree. We should take the same approach as for p2p data and stats. 
> The factory method is documented in the PeerConnection section since 
> it's a method on PeerConnection, but the separate interface of the 
> created object has it's own section.
that makes sense to me. Please make it so.

Received on Monday, 19 November 2012 12:56:33 UTC