- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jul 2017 00:09:22 +0000
- To: public-webrtc-logs@w3.org
This is how Chrome has always behaved, and given that Chrome doesn't support `addTrack`/`removeTrack` (until very soon!), this is the only way people have had to modify a stream (besides removing it and re-adding it, which has consequences). I can imagine there's a lot of code that looks like this:
```
stream.addTrack(track);
if (pc.addTrack) {
pc.addTrack(track, stream);
}
```
Or some variant thereof.
Also, this behavior *was* in the standard (or at least was heavily implied) at one point:
> If something in the browser changes that causes the RTCPeerConnection object to need to initiate a new session description negotiation, a negotiationneeded event is fired at the RTCPeerConnection object.
>
> In particular, if an RTCPeerConnection object is consuming a MediaStream on which a track is added, by, e.g., the addTrack() method being invoked, the RTCPeerConnection object must fire the "negotiationneeded" event. Removal of media components must also trigger "negotiationneeded".
--
GitHub Notification of comment by taylor-b
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1451#issuecomment-314932563 using your GitHub account
Received on Thursday, 13 July 2017 00:09:29 UTC