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

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.

/Adam

>>
>>
>> Wordsmithing is of course needed.
>>
>>>
>>>
>>> - In section 4.3.2, add the function
>>>
>>> RTCDTMFSendingMediaStreamTrack createDTMFSender(MediaStreamTrack track);
>>>
>>> - In section 4.3.2.2, add the paragraph
>>>
>>> createDTMFSender
>>>
>>> The createDTMFSender() creates an RTCDTMFSendingMediaStreamTrack that
>
> s/RTCDTMFSendingMediaStreamTrack/RTCDTMFSender/
>
>>> references the given MediaStreamTrack. The MediaStreamTrack MUST be an
>>> element of a MediaStream that's currently in the PC's localStreams
>>> attribute; if not, throw an Illegal Argument Exception. [NOTE - get
>>> correct name for exception before inserting]
>>>
>>
>>
>
>

Received on Monday, 19 November 2012 11:09:29 UTC