We all know that our WebRTC development has reached a new stage, the current EasyGBS gb video cloud service has supported the output of WebRTC protocol video stream, welcome to experience.
In weBRTC, when two devices cannot be directly connected, a TURN server is needed for transfer. Meanwhile, in the point-to-point service, a TURN server also needs to be installed and run.
But if you connect a device to a media server (whether SFU for group calls or some other type of server), you still need a TURN server. Why? In fact, this is mainly because certain firewalls block certain types of traffic. Most will only block UDP, but some may even block TCP so that WebrTC does not establish a communication connection.
Turn servers are an important part of the WEbrTC infrastructure because they help with NAT network penetration.
There is a mechanism called ICE-TCP that can be used in WEbrTC, which essentially enables the media server to provide ICE candidates in the SDP using TCP transport. This causes the media server to actively wait on the TCP port for incoming connections from the device. It is a Chrome feature, but is now available in all Web browsers that support WebrTC. Does this make TURN/TCP unnecessary? Obviously not, but we still need the TURN/TLS service.
The reason is: first try UDP directly to the server, then ICE-TCP directly to the server, and finally TURN/TLS server. If TURN/TLS is not connected, it indicates that the webrTC device has failed to connect directly to the device. If you are using a local network connection, this means that there is no need to use the TURN server to relay in this case.
If you are interested in our webrTC compilation, please continue to pay attention to our updates.