WebRTC：Firefox 中的重新协商答案

【问题标题】：WebRTC: Renegotiation in firefoxWebRTC：Firefox 中的重新协商
【发布时间】：2015-09-29 01:16:46
【问题描述】：

根据this article，重新协商是在 Firefox v38 中实现的，我们可以从相同的对等连接中添加删除流而不创建新的流，但是我找不到任何工作演示来支持该声明，当我尝试它时，两个用户在视频模式下聊天，我将其中一个流更改为 audio，我收到错误消息：

NotSupportedError: removeStream 尚未实现

this 表示相同，但this 表示支持重新协商事件，但removeStream 不是重新协商的关键部分吗？我在 Windows 7 中使用的是 Firefox 版本 39。我很困惑，Firefox 还不支持重新协商，对吧？

【问题讨论】：

标签： firefox webrtc

【解决方案1】：

Firefox 支持重新协商。

Firefox 只是从未实现过removeStream，因为在实现重新协商时the spec 已更改为addTrack 和removeTrack（有些人认为它的删除太仓促了，所以它可能会回来）。 addStream 仍然适用于向后兼容，因为 Firefox 已经支持它。

请注意，removeTrack 会混淆地采用从 addTrack 返回的 RTCRtpSender，因此 API 不是插件。

polyfill 看起来像这样：

mozRTCPeerConnection.prototype.removeStream = function(stream) {
  this.getSenders().forEach(sender =>
      stream.getTracks().includes(sender.track) && this.removeTrack(sender));
}

移动到轨道是为了给用户更多的灵活性，因为轨道可能属于多个流，并且不是流中的所有轨道都需要通过 PeerConnection（或同一个 PeerConnection）发送。

请参阅answer to a different question，了解适用于 Firefox 的重新协商示例。

【讨论】：

【解决方案2】：

尝试对单个轨道使用replaceTrack，而不是替换整个流。这个例子假设你有一个对等连接pc1 和一个新的流newStream 来替换它。获取发件人，并用新流中的适当曲目替换曲目。工作样本here。

Promise.all(pc1.getSenders().map(sender =>
  sender.replaceTrack((sender.track.kind == "audio")?
                      newStream.getAudioTracks()[0] :
                      newStream.getVideoTracks()[0])))
.then(() => log("Flip!"))
.catch(failed);

还要注意这一点，来自您的第一个链接：

function screenShare() {
    let screenConstraints = {video: {mediaSource: "screen"}};

    navigator.mediaDevices.getUserMedia(screenConstraints)
    .then(stream) {
        stream.getTracks().forEach(track) {
            screenStream = stream;
            screenSenders.push(pc1.addTrack(track, stream));
        });
    });
}

请注意，此示例调用 pc1.addTrack 而不是 pc1.addStream

反之亦然，用于删除 - pc1.removeTrack：

function stopScreenShare() {
    screenStream.stop();
    screenSenders.forEach(sender) {
        pc1.removeTrack(sender);
    });
}

【讨论】：