- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 May 2017 05:17:38 +0000
- To: public-webrtc-logs@w3.org
I still think this is plain wrong. So we have moved away from events firing on the track to explicitly surfacing an event on the peerconnection in case of an audio-only call upgrading to an audio-video one. What used to be this ``` pc.setRemoteDescription(type=offer, audio-sdp) addStream with a stream that has only only ... pc.setRemoteDescription(type=offer, audiovideo-sdp) stream.onaddtrack fires ``` is now surfacing addtrack ``` pc.setRemoteDescription(type=offer, audio-sdp) pc.ontrack(audiotrack) ... pc.setRemoteDescription(type=offer, audiovideo-sdp) pc.ontrack(videotrack) stream.onaddtrack fires ``` This is great because it increases transparancy of what happens on the peerconnection. Note that we have not removed the stream.onaddtrack. More on that later. Now if we were to remove the requirement that ended fires when the track is removed remotely there is a different area where we use the same pattern: datachannels. you only get a signal for adding one (ondatachannel) and then need to listen for its onclose method. If you remove this design pattern from MediaStreamTrack it should also be removed from the datachannel and I think we agree that nobody wants that (hopefully) -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1168#issuecomment-300063649 using your GitHub account
Received on Tuesday, 9 May 2017 05:17:46 UTC