问题标签 [rtcpeerconnection]

我的问题是关于 webrtc 协商。

许多在线教程和 MDN 中描述的内容存在矛盾。

在 MDN 中，它说链接

在每一代候选者结束时，以候选者属性为空字符串的 RTCIceCandidate 形式发送候选者结束通知。仍然应该像往常一样使用 addIceCandidate() 方法将此候选者添加到连接中，以便将该通知传递给远程对等方。

如果在当前协商交换期间根本没有更多候选者，则通过传递候选者属性为空的 RTCIceCandidate 来发送候选者结束通知。此消息不需要发送到远程对等方。这是一个状态的遗留通知，可以通过观察 iceGatheringState 更改为完成，通过观察 icegatheringstatechange 事件来检测。

但是，在这里的教程中，他们介绍了以下代码

如果 Candidate 是一个空字符串，它将被评估为 falsy 并且不会通过sendToServer.

更有趣的是，即使在同一篇文章中

他们有以下示例代码

但是在这个片段的正下方，他们说

当 ICE 谈判会话中没有候选人为给定的 RTCIceTransport 提出建议时，它已经完成了一代候选人的收集。这由一个候选字符串为空 ("")的 icecandidate 事件指示。

您应该像任何标准候选人一样将其交付给远程对等方，如上面共享新候选人中所述。这可确保远程对等方也收到候选结束通知。

实际上，我阅读了许多在线教程，但我从未见过他们处理空字符串候选者的任何地方。

我可以使用 socket.io 连接超过 1 个 RTCpeerconnection 吗？客户：

服务器：

在对我的 Web 应用程序进行故障排除时，我发现了 draft-mdns-ice-candidates，它是关于使用 mDNS 混淆主机候选者中的地址。

而且我发现当两个peer（agent L，agent R）处于如下图7的拓扑中时，WebRTC peer连接失败，因为agent R的主机地址被混淆了，agent R的srflx地址被丢弃，因为代理 R 不在 NAT 后面。rfc8445中关于丢弃agent R的srflx地址的相关表述如下。

5.1.3. 消除冗余候选人

接下来，ICE 代理（发起和响应）消除多余的候选人。两个候选者可以有相同的传输地址但不同的基数，这些不会被认为是多余的。通常，当代理不在 NAT 之后时，服务器自反候选和主机候选将是多余的。一个候选者是冗余的当且仅当它的传输地址和基址与另一个候选者的相同。代理应该消除具有较低优先级的冗余候选者。- RFC8445 第 5.1.3 节

（图 7 来自rfc8445 的第 15.1 节）

并且在draft-mdns-ice-candidates 的第 5 节中，我没有找到关于图 7 的情况的解释。当我测试最新版本的 Chrome、Firefox 和 Safari 时，WebRTC 对等连接在所有浏览器中都失败了。图 7 的情况，因为我上面写的原因——代理 R 的主机地址被混淆，代理 R 的 srflx 地址被丢弃。

通过更改浏览器设置关闭混淆本地地址时（默认情况下进行混淆），WebRTC对等连接成功建立。（我在 Chrome 和 FireFox 上测试了这个成功的连接。在 Chrome 中，通过Anonymize local IPs exposed by WebRTC在“about:flags”页面中禁用。在 Firefox 中，通过false media.peerconnection.ice.obfuscate_host_addresses在“about:config”页面中设置。）

这是 IETF 的 WebRTC 规范的问题吗？（可能是draft-mdns-ice-candidates和rfc8445之间的冲突？）还是现代浏览器的实现问题？有没有办法在不关闭混淆主机地址的情况下，在图 7 的情况下建立 WebRTC 对等连接？我想知道。

我愿意：

在 IP4 127.0.0.1 为什么是 127.0.0.1，而不是像 151.101.1.69 这样的外部 IP？

我们正在我们的应用程序中实现 Webrtc。库版本：implementation 'org.webrtc:google-webrtc:1.0.30039'. 在 Android 上，它只生成 UDP ICE 候选者，在 IOS 上生成 UDP 和 TCP，尽管 lib 版本在两者上都是最新的，并且设置大致相同。我们认为因为一些需要 TURN 的调用不会立即工作，而是在重新连接后，当 webrtc 库将其状态更改为失败时，我们重新发送一个报价，其中已经包含 ICE。这是我对 Peerconnection 的设置：

为了使 Webrtc 库也生成 TCP ICE，我应该设置什么样的设置？

我想在 HTML 中录制具有相同样式 CSS 的视频流，在远程视频左下角的本地视频中可以做到这一点？

我正在做一些跨浏览器测试，并且在使用 Chrome 到 Firefox 进行测试时（在接收端），我总是第一次遇到这个问题。刷新后它似乎工作正常。

我有一个绑定到我的 peerConnection 的事件处理程序，如下所示。

peerconnection.onicecandidate = handleIceCandidate;

第一次，我在候选人中得到空值。 event.candidate = null

任何线索可能发生在这里？如果您需要更多信息，请告诉我。

提前致谢！

我正在尝试通过考虑以下页面中的示例为我的小型视频会议应用程序实现完美的 WebRTC 协商：

https://blog.mozilla.org/webrtc/perfect-negotiation-in-webrtc/

不幸的是，我没有设法让它完全工作，特别是移动 safari 似乎以自己的方式处理回滚行为，这里是处理回滚行为的代码：

因此，当在移动 safariofferCollision === true上检测到报价冲突 () 并pc.setRemoteDescription({ type: 'rollback' })在我的代码中实现时调用它，它会引发类型错误InvalidStateError。仔细查看 MDN 中有关此类错误的文档（https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/setRemoteDescription#Browser_compatibility）显示：

“RTCPeerConnection 已关闭，或者处于与指定描述类型不兼容的状态。例如，如果类型为回滚且信令状态为稳定、具有本地-pranswer 或具有-远程- pranswer，抛出此异常，因为您无法回滚已完全建立或处于连接的最后阶段的连接。”

在回滚之前检查对等连接信号状态表明它处于“have-local-offer”状态，这应该没问题，因为 MDN 说InvalidStateError在状态稳定的状态下回滚是不可能的（抛出）， have-local-pranswer，或有-远程-pranswer。

对于另一种情况，当我的桌面 Chrome 浏览器在报价冲突中运行时，一切都在启动回滚之前以相同的信号状态按预期工作。

这里的人是否知道移动 Safari 可能存在什么问题或需要以不同方式处理。

我正在尝试使用 Angular 在 chrome 中播放 webRTC 视频。我有 IP 摄像机，我正在使用 Wowza 流引擎将他们的 RTSP 流转换为 webRTC。

Wowza 共享了一个示例，该示例index.html使用webrtc.js 这些文件的 github 链接来流式传输视频，我可以在其中提及我想要播放的相机流，并且它在 chrome 中工作。

我在角度代码中实现了相同的逻辑。我已经比较了 Wowza 代码和角度代码中的请求/响应，它是相同的，但视频不播放。我只看到带有视频加载标志的黑屏。

我对 webRTC 很陌生，所以不确定我应该在哪里调试它。

这是我的html代码

这是component.ts文件

我比较了 Wowza 代码和 Angular 代码的控制台日志，它看起来和我一模一样。

Wowza 示例控制台日志

Angular 代码控制台日志

任何人都可以提出一些关于如何调试的建议吗？

这是代码（Ubuntu上的浏览器Chrome）：

它显示：

实际上，这几乎是来自Mozilla 网站的确切代码

此外，符合 WebRTC 规范第 4.9 节