RE: DTMF - the "Object Oriented" approach

Yang
Huawei


> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: Friday, November 16, 2012 2:49 PM
> To: Adam Bergkvist
> Cc: public-webrtc@w3.org
> Subject: Re: DTMF - the "Object Oriented" approach
> 
> 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.
> 

It is right, but if we may have a simple name, it is more easy to understand and remember the DTMF track when we implement it in webkit or learning to write JS code.

> >
> > 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.
> 
> (I think it would be entirely reasonable to create the
> RTCDTMFSendingMediaStreamTrack every time you need to send a DTMF
> tone,
> and throw it away after use. I see no reason to make it a heavy-weight
> object.)

Support a  light-weight object, but each time we send a DTMF we need to create it, it seems not optimized, why not hold the DTMF track in pc for some time, when the page is close or pc is removed, or original mediastream is removed, the DTMF track can be removed.

Received on Friday, 16 November 2012 08:30:16 UTC