Recently, we faced some issues with an on-premise telehealth platform related to connectivity. It reminded us how important it is to keep your eye on the many different types of networks a peer can be utilizing and the subsequent connection issues that can arise in some particular networks. In this blog post, we will review the signaling process and share some tips on how to alleviate ICE issues that can be caused by certain network restrictions. 

You can watch this and other tips from our engineering team as part of our WebRTC Tips by WebRTC.ventures YouTube video series. Or, read on. 

Some background on signaling

To connect peers in WebRTC, you use a process called signaling which synchronizes the participants that are going to connect. 

In the above image, User A and User B want to connect. They need to synchronize using signaling (the server at the bottom). Within this process, we need to know how they will connect directly. Networks today are often set up in ways which prohibit from in doing this. This is good, because it is secure and protects us. However, it makes the WebRTC connections harder to do. 

ICE 

The mechanism we then use to connect is called ICE, which stands for Interactive Connectivity Establishment. The ICE process provides us a list of candidate connections and paths that we can use to connect us with the other peer. This is done by a STUN and TURN server, as shown at the top of the image.

STUN

The STUN is the more basic type of server. It provides the public IP address. This is what User A is doing in this case. It comes as an import that can be shared with the other user. This is the first step and it usually works. The connection is complete and there is no need for further action. 

TURN

Sometimes however, there are issues that do not allow us to connect directly via a STUN server. These may include firewall restrictions or a symmetric NAT.

In this image, we show how the media would flow through the TURN server. This obviously has a cost and that is something that needs to be considered when architecting a WebRTC application. 

Problems can arise

When using a TURN server, problems can arise if it is not configured correctly. This is an issue we recently faced with a very restrictive firewall, as you might see in a telehealth use case, where security and privacy is very important. You can find firewalls that do not only block UDP but, like in this case, block everything except HTTPS. This means that HTTPS is the only protocol that you can use to communicate. 

In this case, User A was under the restrictive firewall and was trying to transmit media using the port 3478, which is the default for a TURN server. But, we were not able to receive media back because the firewall would not allow it. 

This seems like a very obvious case, but when you’re building a large application and there are many different dependencies, it’s easy to forget things like this. A developer sees it works on their machine and assumes it will work everywhere, not taking these kinds of issues into account. 

Tips to alleviate ICE problems:

• Limit your number of ICE servers
• Verify your STUN or TURN servers are working via: https://github.com/webrtc/samples/tree/gh-pages/src/content/peerconnection/trickle-ice
• Properly configure your STUN/TURN server to support the protocols you need and want (e.g: udp, tcp or tls)
• Add the “turns” schema:
  • If you require additional TLS encryption passing username and password to your TURN server
  • If your firewall imposes TLS over 443
• Authenticate using ephemeral (time-limited) credentials
• Geographically distribute your relay servers

If you are ready to integrate live video into your web or mobile application, that’s exactly what we specialize in here at WebRTC.ventures. We’d love to help. Contact us today!