重新发送对等连接提议答案

【问题标题】：resending peerconnection offer重新发送对等连接提议
【发布时间】：2014-05-08 16:49:12
【问题描述】：

我目前正在尝试将我的本地流重新广播到我的所有对等连接。我尝试过的选项：

1) 循环遍历我的所有对等连接并使用新的本地流重新创建它们。我在这里遇到的问题是 createOffer 是异步的。

2) 创建 1 个 sdp 并将其发送给所有对等点。问题：没有视频

有没有人可以将报价重新发送给同行列表？

【问题讨论】：

您可以在所有连接中使用相同的 mediaStream，但每个连接都需要自己的 SDP（这是因为连接中选择了 ICE 候选者）。您是否也在处理另一方的重新谈判？
报价在接收端得到正确处理。（接收方重新创建与新流的对等连接）答案也是如此。问题确实是我需要为每个对等连接一个新的 SDP。因此，如果我能够在循环中调用 createOffer() ，可能会解决我的问题。但是由于这是异步的，所有 sdp 都被发送到列表中的最后一个连接。
您可以等待每个 createOffer 完成，一旦完成，它就会调用下一个连接开始。

标签： javascript html p2p webrtc

【解决方案1】：

每台 PC 都需要重新创建报价（如 bwrent 所说）。
显然您正在使用 p2p 多方（多个对等连接），您可能希望每次都将 peerID 传递给 createOffer 成功回调，那么您不必担心它是异步的。您需要使完整的握手（提议、回答、候选人）peerID 相关。
（简化）来自我们 SDK 的示例


    Skyway.prototype._doCall = function (targetMid) {
        var pc = this._peerConnections[targetMid]; // this is thread / asynchronous safe
        pc.createOffer(
            function (offer) {
                self._setLocalAndSendMessage(targetMid, offer); // pass the targetID down the callback chain
            },
            function (error) {this._onOfferOrAnswerError(targetMid, error);},
            constraints
        );
    }; 

    Skyway.prototype._setLocalAndSendMessage = function (targetMid, sessionDescription) {
        var pc = this._peerConnections[targetMid]; // this is thread / asynchronous safe
        pc.setLocalDescription(
            sessionDescription,
            self._sendMessage({ target: targetMid, ... }), // success callback
            function () {}                                 // error   callback
        );
    };

【讨论】：

【解决方案2】：

如果您的意思是异步的方式是当回调触发时，它有错误的变量，即循环结束时将其发送给谁，并且该变量包含最后一个“人”？您可以将其限定为解决异步问题：

For(var i=0;i<peerConnections.length;i++){
    (function(id){
        //inside here you have the right id. Even if the loop ended and the i variable has changed to something else, the I'd variable still is the same.
    })(i);
}

这有点像 Alex 的回答，因为他的回答还描述了一个在执行 .createOffer 的函数内确定变量范围的示例

另一种正确处理此问题的方法是使用重新协商。每当您更改流时，onnegotiation 事件处理程序都会自动触发。在此函数中，您创建一个新报价并将其发送给其他人。正如您所提到的，您有多个对等连接正在侦听流，您需要知道将 sdp 发送给谁。如果您要将人员 ID 添加到 rtc 对象，则可以通过调用 this.id 将其返回到 onnegotioation 事件中。

【讨论】：

我目前选择了 Alex 提出的解决方案。但是，我稍后会研究 onrenegotiation。从长远来看，这可能是一个更好的解决方案。感谢您的提示。
@user3428043 这确实是一个“发达”的 rtc 系统使用的东西。这会在流更改时自动处理重新发送 SDP，而无需在更改流时考虑处理 SDP。我不太确定，但也许它也会在其他情况发生变化时触发（并防止连接失败）。但是，在使用它时，您应该在成功建立连接后添加事件处理程序，否则您可能会得到双倍的 SDP。
重新协商和回滚确实是做到这一点的正确方法。它应该从应用程序中隐藏。不幸的是，好的 webRTC sdk 为您实现了它，即使规范定义了 onrenegotiationneeded 事件，FF 也没有实现它，并且回滚部分还没有在规范中并且可能不会达到 1.0。干杯。