This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Presented in https://www.w3.org/2011/04/webrtc/wiki/images/6/6c/WebRTC_RTCSender-Receiver%2C_TPAC_2014.pdf slide 16. This would make RTPsender.track be a mutable attribute, leading to the ability to switch which video is sent with no signalling. Compatible tracks are required, and it means that one loses the ability to correlate sendertrack.id with receivertrack.id - this needs to be explicit in the proposal. More work needed, but there was interest in pursuing this.
Note that the mutable attribute was not popular. There was a general preference for a setter. The primary reason being that the replacement might fail. I think that the general sense was that failure was not a problem that browsers need concern themselves with: the track would simply go BYE-BYE (i.e., RTCP BYE) if media could not be provided in a compatible form from the new source. However, it was observed that replacement would not be atomic and that maybe a promise-bearing method was superior. That would allow for the time of replacement to be marked, as well as giving the application a way to learn about errors.
WebRTC API bugs have been moved to github issues: https://github.com/w3c/webrtc-pc/issues Please subscribe to the issues you want to keep watching.