iOS WebRTC 连接卡在 Ice Connection State Gathering答案

【问题标题】：iOS WebRTC connection stuck at Ice Connection State GatheringiOS WebRTC 连接卡在 Ice Connection State Gathering
【发布时间】：2019-05-16 03:11:02
【问题描述】：

我正在做一个 iOS 原生 WebRTC 实现，我正在尝试与 Wowza 流引擎进行对等连接。

我已经构建了自己的实现，交换 SDP 提议/答案，没有错误，但是交换在 Ice State Checking 中停止。

这也可以从 Chrome 通过 WebRTC 到 Wowza 引擎按预期工作，因此问题似乎并不存在。

我遇到的日志错误

[019:110] [51467] (stunport.cc:282): Port[801a400:0:1:0:local:Net[en2:169.254.0.x/16:Wifi:id=1]]: UDP send of 100 bytes failed with error 65
[009:190] [52483] (port.cc:1731): Conn[7058e00:0:Net[en2:169.254.0.x/16:Wifi:id=3]:K1VeXnEm:1:0:local:udp:169.254.31.x:63068->u76s55ya:1:50:local:udp:52.7.176.x:6970|C--W|-|0|0|218992623103|-]: Sent STUN ping, id=66706566354b77567a55706a, use_candidate=0, nomination=0
[009:241] [52483] (port.cc:1731): Conn[503dc00:0:Net[pdp_ip0:10.233.207.x/32:Cellular:id=8]:Usd6n9/m:1:0:local:udp:10.233.207.x:61703->u76s55ya:1:50:local:udp:52.7.176.x:6970|C--W|-|0|0|218992229887|-]: Sent STUN ping, id=6431755a4674675155333050, use_candidate=0, nomination=0
[009:292] [52483] (port.cc:1731): Conn[7060e00:0:Net[en0:192.168.0.x/24:Wifi:id=1]:s9SLzrT3:1:0:local:udp:192.168.0.x:53334->u76s55ya:1:50:local:udp:52.7.176.x:6970|C--I|-|0|0|218992754175|-]: Sent STUN ping, id=496e57507237574d52324b50, use_candidate=0, nomination=0

任何帮助都会很棒！

编辑：更详细的流程。

我正在尝试在 iOS 上的 Wowza Streaming Engine 实例和 WebRTC 之间创建对等连接。连接只是一个发布，没有接收到任何流。

我的步骤如下

出厂时已创建对等连接。
媒体流添加到对等连接。
在对等连接上创建优惠。
报价设置为本地描述并发送到 Wowza。优惠有当地的冰候选人
Wowza 响应与 Answer SDP 和 ice 候选（Wowza 只给出一个）
答案设置为远程描述
将单个 Ice Candidate 添加到对等连接中

最终状态始终是 RTCIceConnectionStateChecking 然后失败。

【问题讨论】：

标签： ios objective-c xcode webrtc wowza

【解决方案1】：

您需要交换（涓流）ICE 候选人，或在交换 SDP 提议/答案之前等待几秒钟，以便让当地 ICE 代理有时间用候选人填充提议/答案（可通过获取当地描述获得）。

【讨论】：

感谢您的回复！这只是从 iOS 到 Wowza 流媒体引擎的发布（如果这会有所不同）即使其他状态看起来不错，我仍然卡在同一个 RTCIceConnectionStateChecking 上，然后过了一会儿，RTCIceConnectionStateFailed。一些奇怪的日志 [VideoSendStream::Stop] 一堆失败的 PING 发送，并丢弃了样本缓冲区。最终 [连接已删除，发送的 ping 数：96]
@JohnLanzivision 没有区别。您仍然必须交换主持人候选人。几秒钟后检查本地 SDP，它们应该会出现在那里。
我可能有点困惑，我向 Wowza 发送了 offer SDP，它会回复 Answer SDP 和 Ice Candidate（只有一个），仅此而已。适用于我们的 Chrome POC，但不适用于原生 iOS。
抱歉不可用，我不确定我会不会有很大帮助。如果它在 Chrome 中工作，那么我不知道。请注意，报价还需要包含一个冰候选（或滴流冰候选，如果您正在滴流候选人 - 从您的问题中不清楚您是否是）。
没有问题，感谢您的考虑！我已经更详细地更新了这个问题。 iOS 上的原生 webRTC 似乎开始与 Wowza 流引擎不兼容......

【解决方案2】：

也许有人在 iOS 上也会遇到这个问题。我也想知道如何使涓涓细流工作，因为在我的情况下，即使是 iOS 到 iOS，它似乎也不起作用。但有可能的是，作为呼叫者，此时您的连接转到checking 以再次发送报价。在第二个报价中，您还将找到所有候选人。因此，当您发送所有候选人和未在第二个提议中连接的候选人时，这可以让对等点进行连接。

尝试将您立即生成的报价与您转到checking 后生成的报价进行比较以查看差异。

func webRTCClient(_ client: WebRTCClient, didChangeConnectionState
state: RTCIceConnectionState)

如果您收到状态“检查”电话：-

-(void)offerForConstraints:(RTCMediaConstraints *)constraints
completionHandler:(nullable void (^)(RTCSessionDescription *_Nullable sdp,
NSError *_Nullable error))completionHandler;

【讨论】：

见func webRTCClient(_ client: WebRTCClient, didChangeConnectionState state: RTCIceConnectionState)。如果您再次收到“检查”状态，请致电- (void)offerForConstraints:(RTCMediaConstraints *)constraints completionHandler:(nullable void (^)(RTCSessionDescription *_Nullable sdp, NSError *_Nullable error))completionHandler;
嗨，我在服务器中检查状态，发现我的发布者卡在收集状态，订阅者卡在连接状态，我可以再次调用 offerForConstraint 吗？
不确定。您是否使用收到的答案/报价设置远程描述？如果您在实际失败之前等待几秒钟（使用计时器）并再次生成答案/提议，您是否第二次获得候选人？
是的，我有很多候选人，但有时只有订阅者工作，只有发布者失败，现在我专注于检查转服务器
这也取决于谁坚持聚会。我认为发出初始报价的一方总是需要采取主动。但是如果你做错了什么，你很快就会注意到，因为如果你在不正确的状态下尝试设置提议或答案，WebRTC 将会崩溃。但就我而言，如果 ICE 涓涓细流失败，我总是去checking，所以它坚如磐石。