在 iOS 11（iPhone 5s 和 iPhone 7）或桌面上使用 Safari 11 时，我的 Web 应用程序无法通过 CoTURN 服务器收集 WebRTC 中继 ICE 候选项。 Web 应用程序（建立单向音频 WebRTC 对等连接）在真实浏览器（Chrome 和 Firefox）之间直接或通过 CoTURN 中继运行良好，我通常在这些浏览器上获得 6-15 个 ICE 候选者。
我在接收端对 getUserMedia 进行了（坦率地说，不必要的）调用，这允许 Safari 生成主机 ICE 候选者。 （注意...用户must在 Safari 提供主机 Ice Candidates 之前批准音频和/或视频访问，即使在仅接收端也是如此。我已经克服了这个障碍，但只是为了让你不会遇到它......这是出于“隐私”问题。）。在添加允许 getUserMedia 之前，我没有收到 ICE。现在我收到了两位候选人。一个具有专用 IPv4，另一个具有 IPv6。这足以让应用程序在同一台计算机或本地网络上正常工作。所以我对应用程序代码的其他部分非常有信心。我不确定我的问题是应用程序代码还是 CoTURN 服务器。
收到的 ICE 候选人示例：
{"candidate":{"candidate":"candidate:622522263 1 udp 2113937151 172.27.0.65 56182 typ host generation 0 ufrag r23H network-cost 50","sdpMid":"audio","sdpMLineIndex":0,"usernameFragment":"r23H"}}
我非常确定我的 RTCPeerConnection 的 RTCIceServer 字典符合以下标准：
- https://w3c.github.io/webrtc-pc/webrtc.html https://w3c.github.io/webrtc-pc/webrtc.html
- https://www.rfc-editor.org/rfc/rfc7064 https://www.rfc-editor.org/rfc/rfc7064
- https://www.rfc-editor.org/rfc/rfc7065 https://www.rfc-editor.org/rfc/rfc7065
我尝试了多种参数变化：
// For Example:
var RPCconfig = {
iceServers: [{
urls: "turn:Example.live",
username: "un",
credential: "pw"
}]
};
// Or:
var RPCconfig = {
iceServers: [{
urls: "turns:Example.live",
username: "un",
credential: "pw",
credentialType: "password"
}, {
urls: "stun:Example.live"
}]
};
// And even more desperate attempts...
var RPCconfig = {
iceServers: [{
urls: "turn:Example.live?transport=tcp",
username: "un",
credential: "pw",
credentialType: "password"
}]
};
以下是信令进程日志的示例，可让您了解正在发生的情况。这是来自接收方，即 Safari 11。另一个浏览器是 Chrome（比较 6 与 2 个 ICE 候选者）。状态变化是指oniceconnectionstatechange.
SDP Offer received.
Sending signal SDP
Sending signal IceCandidate
Sending signal IceCandidate
ICE Candidate Received
4:08:25 AM State Change -> checking
ICE Candidate Received
ICE Candidate Received
ICE Candidate Received
ICE Candidate Received
ICE Candidate Received
4:08:40 AM State Change -> failed
据我所知，CoTURN 在接受每种可能的传输方法方面配置相当自由。它非常适合提供 ICE 候选者并作为其他浏览器的中继。
任何方向将不胜感激。即使它只是一个可以运行的 RTCIceServer 字典示例代码或可供尝试的经过验证的 TURN 服务器。
