检查WebRTC连通性-可靠的方法 [英] Checking for WebRTC connectivity - reliable methods
问题描述
我有一个实时视频聊天应用程序，我使用TURN服务器，该服务器支持STUN/TURN和UPD/TCP传输.
I have a live video chat application and I use a TURN server which supports STUN/TURN and both UPD/TCP transmission.
有时用户可以连接到网络，该网络阻止 WebRTC连接无法发生的许多端口和协议(通常是公司网络).我想在用户尝试彼此连接之前检查是否可以进行WebRTC连接(实际上，请执行技术检查).
Sometimes users can be connected to the network which blocks that much ports and protocols that WebRTC connection just cannot happen (usually those are corporate networks). I would like to check if a WebRTC connection is possible before users try to connect to each other (actually, perform a technical check).
我该怎么办?我的想法:
How can I do it? Ideas I have in my head:
- 尝试通过WebRTC 下载托管的数据块(例如，音频文件)-是否有可能，并且这足以确保入站和出站连接均打开?
- 使用 TURN服务器作为主机以建立连接并查看其是否失败(不知道我是否可以这样做)
- 使用 Flash尝试通过特定的端口和协议下载/上传大量数据.甚至可以使用Cirrus.但是，从WebRTC的角度来看，我不确定此测试是否准确.
- 还有其他想法吗?
- Try to download a hosted chunk of data (audio file, for example) via WebRTC - is it possible and would this be enough to make sure both inbound and outbound connections are open?
- Use a TURN server as a host to make a connection to and see if it fails (have no idea if I can do it or not)
- Use Flash to try to download/upload a chunk of data over specific ports and protocols. May be even using Cirrus. However, I am not sure this test will be accurate from WebRTC prospective.
- Any other ideas?
其他要求:检查技术必须支持Chrome，Opera和Firefox.最好也是通过Temasys插件的IE/Safari.
版本1-收集ICE候选人是一个好主意，但是，它并不是100％可靠的.一旦我在应用程序中检查了日志，它实际上收集了ICE中继候选者，但是视频/音频传输失败.在Apprtc上也进行了测试，并获得了相同的结果.
推荐答案
典型的WebRTC方法是使用STUN和TURN服务器创建对等连接，调用createOffer和setLocalDescription并观察收集的候选对象.参见例如 http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
the typical WebRTC approach to this is to create a peerconnection with STUN and TURN servers, call createOffer and setLocalDescription and watch the candidates gathered. See e.g. http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
如果获得srflx候选者，则您的stun服务器可以正常工作(即UDP没有被阻止).更有趣的是您是否获得接力候选人.如果您这样做，可以使用TURN作为后备.如果使用TURN/TCP，则质量可能会受到影响.如果您没有接力人选，那么接听电话的可能性就很小.
If you get srflx candidates, your stun server works (i.e. UDP is not blocked). More interesting is whether you get relay candidates. If you do, using TURN as a fallback will work. Quality might suffer if TURN/TCP is used. If you don't get relay candidates... calls are very unlikely to work.
这篇关于检查WebRTC连通性-可靠的方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
