Re: DTMF - the "Object Oriented" approach

On 11/15/2012 12:07 PM, Stefan Hakansson LK wrote:
> On 11/14/2012 03:46 PM, 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, 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]
> This looks good to me. I think we also need to specify:
> * What happens if the MediaStream with the track that the 
> RTCDTMFSendingMediaStreamTrack is associated to is removed from the 
> PeerConnection? I assume there would be an error event next time the 
> app tries to send DTMF.
My thought:

I think that if it's removed from the PC, canSendDTMF should change to 
Any time canSendDTMF is false, sendDTMF should throw an exception.

Do we need to find a way to throw an event if it's removed from its PC 
while in the middle of sending tones, or can we just ignore that situation?

> Stefan

Received on Thursday, 15 November 2012 21:59:59 UTC