- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Fri, 16 Nov 2012 07:33:16 +0100
- To: Harald Alvestrand <harald@alvestrand.no>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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. Is the intention that the decorated track needs to be added back into the MediaStream where the original track came from? /Adam
Received on Friday, 16 November 2012 06:33:42 UTC