RE: DTMF - the "Object Oriented" approach

If the DTMF sender object is just a handle, what  happens when DTMF
sending is negotiated away/off?  Is there some way to invalidate the
handle?  Do we set its Track property to Null?  How does the app know
that the handle can't be used to send DTMF anymore?

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Friday, November 16, 2012 2:08 AM
To: Harald Alvestrand
Cc: public-webrtc@w3.org
Subject: Re: DTMF - the "Object Oriented" approach

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 13:58:53 UTC