基于 TCP 的 Chrome WebRTC答案

【问题标题】：Chrome WebRTC over TCP基于 TCP 的 Chrome WebRTC
【发布时间】：2016-11-09 16:06:03
【问题描述】：

我正在尝试通过 TCP 使用 WebRTC 媒体，中间有一个网关，但我在 ICE 连接阶段遇到了一些有趣的问题。在进一步推进之前，重要的是要知道我有相同的 UDP 设置并且一切正常。

在网关中，我们修改远程应答 SDP 以包含单个 TCP 候选（媒体端口也被修改为包含相同的端口）：

a=candidate:1 1 tcp 1 <gw_ip> <gw_port> typ host tcptype passive generation 0

我还将属性设置作为被动发送：

a=setup:passive

在 Chrome 上应用远程描述后的几秒钟内，我在网关上收到一个 STUN BIND 请求，我用绑定成功响应来回答（我已经检查了事务 ID 和消息完整性，它们看起来很好）。

在这个 chrome simple 之后，不会继续 ICE 检查（DTLS 消息也不会）。我启用了 chrome 日志以查看是否发生了一些错误，并且我发现了一个有趣的输出：

“忽略共享套接字上的 STUN 绑定响应消息”

我查看了 chromium 源代码，似乎这是因为 chrome 使用共享套接字，但我不明白这是为什么。

有什么想法吗？谢谢！

【问题讨论】：

在 webrtc 中是否可以通过 TCP 数据包传输媒体？
@sureshkumar 是的，这是可能的，只需确保在将媒体发送到 webrtc 端之前实现了长度框架机制，请参阅更多 @tools.ietf.org/html/rfc5389

【解决方案1】：

经过深入调查，我发现在网关端没有正确解析 TCP 流。

具体来说，此流使用了未应用于入站/出站数据的长度框架机制，因此在流程管道上引发了几个问题。

有关框架机制的更多信息，请参阅 rfc5389： https://www.rfc-editor.org/rfc/rfc5389

【讨论】：