RE: DTMF - the "Object Oriented" approach

> -----Original Message-----
> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
> Sent: Friday, November 16, 2012 3:08 PM
> 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.
> 

Even though not so many people will use RTCDTMF.....Track to forge a stream, but I think it is a good idea, RTCDTMFSender is more simple and easy to understand as a handler.

> /Adam
> 
> 




Yang
Huawei

Received on Friday, 16 November 2012 08:38:17 UTC