2

我目前正在使用 opentok WebRTC javascript API 开发视频聊天应用程序。该应用程序在一对一视频聊天中链接用户 A 和 B。A 和 B 都有自己的会话，他们是主持人（sessionId 在登录时生成并存储在数据库中）。起初，用户 A 和 B 只发布到他们自己的会话，并没有订阅任何其他会话。然后向两个用户发送“开始”命令（使用 socket.io），触发用户 A 订阅用户 B 的会话，反之亦然。然后，不再显示彼此的流（几周前效果很好），订阅视频窗口现在保持黑色（在 5 种情况下的 3-4 种情况下），最终触发 1013 peerconnection 错误。有没有人看到过同样的行为（自 WebRTC 2.0.0.13 发布以来，情况变得非常糟糕，大约 2 周前）？我很确定它与任何防火墙设置都无关，因为它之前运行良好，并且 opentok 诊断工具没有显示任何问题。

我注意到一些奇怪的事情：例如，如果一个或两个用户在订阅彼此的会话后才开始发布（通过访问他们的网络摄像头）到他们自己的会话，我永远不会收到 1013 错误并且一切运行顺利（使用完全相同sessionID)。

如果这是无法避免的事情，是否有适当的方法可以从这些错误中恢复？我尝试取消订阅 - 重新订阅，但这不起作用。有任何想法吗？

弗雷德里克

4

1 回答 1

0

这听起来确实是一个奇怪的问题。当你生成一个 sessionId 时，你能确保 p2p 没有启用吗？不通过我们服务器的 p2p 流容易受到 1013 连接错误的影响。

确保您的 javascript/iOS 库都使用 webrtc SDK。如果为我们的闪存服务器分配了会话 ID，则尝试通过 webrtc 连接的人将收到 1013 错误。

有时，如果您尝试多次调用 session.subscribe 到同一个流，它可能会使订阅者处于奇怪的状态，从而导致 1013 错误。

这些是我能想到的可能原因。您是否有可以分享的现场演示，以便我们重现问题？

于 2013-09-16T23:12:41.003 回答