This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Spec should specify when the DTMFSender.canInsertDTMF values can be changed. The following are some scenarios when that value can be changed. It can change, when 1. When the track is stopped, through MediaStreamTrack API or the tracks state transits to "ended" state because of any other reason. 2. The track is changed from enabled to disabled or unmuted to muted states and vice-versa.
Not sure stopping the track should change this state. You can still send DTMF until the track is actually removed from the PeerConnection.
The canInsertDTMF should change when the codecs available change (the DTMF codec is added or removed). It will be false before negotiation is completed, may be true after that, and may change later in response to negotiation. I think enabled, disabled and ended are irrelevant; they no more change the ability to send DTMF than muting the track prevent you from whistling into the microphone - they just change whether or not the signal you're generating gets there, and you have existing APIs to check that.
(In reply to Harald Alvestrand from comment #2) > The canInsertDTMF should change when the codecs available change (the DTMF > codec is added or removed). It will be false before negotiation is > completed, may be true after that, and may change later in response to > negotiation. Agreed. > > I think enabled, disabled and ended are irrelevant; they no more change the > ability to send DTMF than muting the track prevent you from whistling into > the microphone - they just change whether or not the signal you're > generating gets there, and you have existing APIs to check that. This is a bit confusing. According to Media Capture spec, MediaStreamTrack.stop() or any other event that makes a track to stop should detach the source. In case of DTMF, "tones" of insertDTMF is the source for track. So, I felt we should stop inserting DTMF tones into the track that was stopped through tracks stop.
The value of canInsertDTMF Should also be changed, when the RTCPeerConnection is closed, due to user invoking stop method or because of any other reason.
WG discussion: There seems no value in changing the state of the track when it's ended. When it's paused, the data is discarded in the same way that audio data is. No change needed.