Have you ever had to deal with SIP and NAT issues? How many times you or your customers were frustrated by one way audio? How much time have you spent debugging such cases?
It is not a simple problem, and there were many attempts to deal with NAT in SIP and other media signalling protocols that are using offer/answer model. Some of them are server centric, others are implemented on the client side and a few of them use mix of server and client implementation. Lets review some of them.
Universal Plug-and-Play. UPnP allows client to control router/firewall. This is something that not widely supported by SIP phones. Besides, there are security risks, plus UPnP requires strict and clean network conditions, which are typically rare.
SIP ALG. Application-Level Gateway was developed to be used in routers to inspect VoIP traffic, and help in passing it back and forth. Unfortunately many ALG implementations are broken by default.
SBC. Session Border Controllers have many different approaches for handling NAT. While very useful in general, they offer little help for users that are outside of company network and behind some public not controlled NAT's and firewalls.
STUN. Session Traversal Utilities for NAT is a network protocol which in a nutshell is like "What's my IP" service. STUN server sits somewhere in public internet, waits for incoming requests, examines packet source IP and port, packs this information as STUN response, and replies to the request with the information it discovered. This way clients behind NAT are able to find out about their public ipaddress/port pair and use that when they need to pass this to remote peer in order to receive audio on that IP/port pair. While this works in the majority of cases, STUN can't deal with Symmetric NAT.
Symmetric NAT has a limitation "Only an external host that receives a packet from an internal host can send a packet back.". Once the request is sent and received from the STUN server, STUN server becomes that "Only one external host that received a packet from an internal host ". This makes it impossible for a remote peer to send audio to the discovered ipaddress/port pair, since Symmetric NAT only allows to receive packets from the STUN server.
TURN. Traversal Using Relays around NAT is a network protocol, that aims to allow NAT traversal for Symmetric NAT scenarios. Instead of just replying with source's public ipaddress / port pair of the request, TURN server creates bindings on its own public interface, and replies with that information to the requester. Requester then sends this information to the remote peer. Once TURN server receives any media on that ipaddress/port pair it relays that information to the binding requester.
TURN servers can also be used to increase voice quality for users with poor network connections. For example, users in the US and Europe, which may have satisfactory network connection when traffic doesn't need to cross the ocean, may have too much latency and high packet loss when US and European users will try to establish media session. It's a common practice to install TURN servers with powerful network connection near the customers all over the world.
We will further focus on STUN and TURN - here is the summary:
STUN
Pros:
- Helps with NAT traversal in 90-95% of cases
- Does not require much extra bandwidth
- Lightweight in terms of CPU
- There are over 9000 public free STUN servers, including servers provided by Google
- Required only during call negotiation phase
Cons:
- Can't handle Symmetric NAT
TURN
Pros:
- Handles Symmetric NAT, passes almost any firewall or router as can be even run on 443 TCP port.
- Can be used as media repeater.
Cons:
- Requires CPU horsepower
- Requires extra network bandwidth
- Used during the entire call duration
Knowing the pros and cons of both protocols, we might think: "Wouldn't that be cool, if we can somehow combine STUN and TURN servers, so we could establish media sessions inside of local network when it' is possible, penetrate NAT using STUN, and use TURN for cases where both previous options have failed?" This is what ICE is all about.
Interactive Connectivity Establishment (ICE) is a technique for NAT traversal that allows to intelligently define the most feasible media path between two media endpoints. An ICE agent is any ICE capable endpoint. ICE agent gathers information of all possible network connections (ipaddress/port pairs) it can discover on local interfaces, as well as by using available STUN and/or TURN servers. Each such pair is called a "candidate". Once endpoint gathered all available candidates, it will send this information to remote peer in SDP body within INVITE request or response. When each peer has the local and remote candidates they create local and remote candidate pairs and order them by priority (lower number means higher priority)
- Candidates that were gathered on local network interfaces, of peer
- Candidates that were discovered using STUN server
- Candidates that were discovered using TURN server
After candidates are paired and ordered, ICE agent starts procedure called "connectivity checks". This procedure sends special requests to each remote candidate, in order described above until a response is received for one of these requests. Once a response is received that candidate pair is nominated to be used for media stream. This is very simplified explanation of the ICE process with many technical details skipped. You can learn more about ICE in RFC 5245
Thirdlane Connect and Thirdlane media core are both ICE agents. Thirdlane Connect uses WebRTC as the basis for media communications. ICE is the only available technique in WebRTC to establish media streams, so in order for Thirdlane Connect to establish media streams properly you have to configure and specify ICE servers for each Thirdlane Connect enabled user extension. You don't have to worry about Thirdlane Connect SIP signalling in terms of NAT traversal, as Thirdlane Connect uses Websockets (you can think of it as TCP-TLS connection) so that general SIP signalling problems do not apply. It will just work everywhere where HTTPS (443) is allowed.
Configure Thirdlane Connect with STUN/TURN servers
To add new ICE server you need to select System Management -> ICE Servers and click on appropriate button within Thirdlane Communications Manager.
After this, you need to enable your ICE server(-s) on ICE settings tab of Edit User Extension window.
In order to apply ICE server settings, all active Thirdlane Connect clients have to be be restarted by logging out and back in.
Note that Thirdlane Connect will use publicly available Google’s STUN servers if you don't specify any.
Options for ICE support - where to get your STUN and TURN servers:
- Use free public STUN servers with no TURN support
- Purchase commercial STUN and TURN service from a third party like Twilio
- Build and configure your own STUN and TURN server
In the follow up post we will explain how to build and configure your own STUN and TURN server - check back soon!