什么时候可以考虑断开 RTCPeerConnection？答案

【问题标题】：When can I consider a RTCPeerConnection to be disconnected?什么时候可以考虑断开 RTCPeerConnection？
【发布时间】：2020-02-14 16:06:27
【问题描述】：

我正在尝试检测 RTCPeerConnection 的另一端何时断开连接。目前我正在使用我的 RTCPeerConnection 对象执行以下操作：

rtcPeerConnection.oniceconnectionstatechange = () => {
        const state = rtcPeerConnection.iceConnectionState;

        if (state === "failed" || state === "closed") {
            // connection to the peer is lost and unsalvageable, run cleanup code
        } else if (state === "disconnected") {
            // do nothing in the "disconnected" state as it appears to be a transient 
            // state that can easily return to "connected" - I've seen this with Firefox
        }
    };

这似乎适用于我在非常简单的网络条件下进行的有限测试，但来自MDN 的以下内容让我停下来，它可能不会在生产中支持：

当然，“断开”和“关闭”不一定表示错误；这些可能是正常 ICE 协商的结果，因此请务必妥善处理（如果有的话）。

如果RTCPeerConnection.connectionState 是"closed"、"failed" 或"disconnected"，我是否应该改用RTCPeerConnection.onconnectionstatechange 并考虑永久关闭连接？

【问题讨论】：

标签： javascript webrtc rtcpeerconnection

【解决方案1】：

该规范针对该主题提供了精心设计的建议：

建议在 iceConnectionState 转换为 "failed" 时执行 ICE 重启。应用程序还可以选择侦听iceConnectionState 到"disconnected" 的转换，然后使用其他信息源（例如使用getStats 来测量在接下来的几秒钟内发送或接收的字节数是否增加）确定是否建议重新启动 ICE。

见the spec和the PR that added this

请注意，由于错误，Chrome 在统一计划中不再“失败”。 “关闭”只有在您的代码调用 pc.close() 时才会发生，因此从 Chrome 80 开始，iceconnectionstatechange 不再触发。

【讨论】：