W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2012

Re: DTMF - the "Object Oriented" approach

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Fri, 16 Nov 2012 08:08:09 +0100
Message-ID: <50A5E659.5090109@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2012-11-16 07:49, Harald Alvestrand wrote:
> On 11/16/2012 07:33 AM, Adam Bergkvist wrote:
>> On 2012-11-14 15:46, 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
>>> DTMFSendingMediaStreamTrack.
>>> Add the following text:
>>>
>>> A RTCDTMFSendingMediaStreamTrack is created by calling the
>>> createDTMFSender() method on a PeerConnection. This constructs an object
>>> that decorates a MediaStreamTrack with the functions required to send
>>> DTMF.
>>>
>>>
>>> - 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
>>> 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]
>>
>> The prefix (RTCDTMF) it's pretty nasty, but I guess consistency has
>> precedence in this case.
> :-)
> The way that I think this will be used, it will never appear in JS code,
> so the only people it will be a pain for are the ones who do the
> implementation. I considered RTCMediaStreamTrackWithDTMFExtensions
> briefly, but decided to suggest this one.

If anyone suggests a separate constructor, we'll point them to this 
thread. :)

>> Is the intention that the decorated track needs to be added back into
>> the MediaStream where the original track came from?
> No, it's my intention that the created object is only a handle that can
> be used for sending DTMF. The MediaStreamTrack that it was created from
> is already part of the MediaStream it belongs in.

That's my preference as well. In that case, could we skip the 
inheritance from a MediaSteamTrack (and the MediaStreamTrack-part of the 
name) to avoid confusion? For example, someone using it as a track 
argument to the MediaStream constructor. We could simply call it 
RTCDTMFSender? The corresponding track could be a read-only property on 
the dtmf sender object if you wanted to relate back to the track.

/Adam
Received on Friday, 16 November 2012 07:08:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 16 November 2012 07:08:33 GMT