With the rise in remote work, video conferencing and live streaming, the demand for real-time communication technologies has grown exponentially. WebRTC, or Web Real-Time Communication, is an incredibly powerful technology that facilitates real-time communications between devices across the internet. Over the years, it has been the go-to choice for real-time commutations applications.
However, establishing a reliable network connection between devices can be a significant challenge, especially when firewalls and other network barriers separate them.
Here, we are going to delve into two essential components of WebRTC technology – the ICE and SDP protocols, which enable efficient and seamless real-time communication across the Internet.
Table of Contents
The ICE protocol, or Interactive Connectivity Establishment protocol, is a technique used in WebRTC to establish connections between devices over the Internet. It helps overcome obstacles like NATs (Network Address Translators) and firewalls that can hinder direct peer-to-peer communication.
By utilising a process called "ICE gathering," devices exchange network addresses known as ICE candidates to determine the most efficient network path for establishing a reliable connection. This enables seamless real-time communication even when faced with network barriers.
NAT, short for Network Address Translator is simply a technique deployed by routers to conserve, hide and add an extra layer of security to the internal IP addresses of devices in its network. Routers achieve this by allowing multiple devices on their local network to share a single public IP address that they can use to communicate with other devices, this could be DNS servers or other devices.
Although NATs make networks safer, they also present a significant obstacle to establishing peer-2-peer communication between devices.
This is where ICE comes into play.
ICE helps WebRTC traverse NATs and firewalls by allowing devices to find and use the most efficient network path between them, regardless of how the network is configured.
ICE achieves this through a process called "ICE gathering." During this process, devices exchange ICE candidates, which are potential network addresses. These candidates describe the different paths that a device can take to establish a connection. The ICE protocol then evaluates these candidates and selects the most suitable one for establishing a connection, even when NATs and firewalls hinder Peer-to-peer communication.
In WebRTC, ICE candidates serve as addresses that devices use to connect with each other over the internet. A device can have multiple ICE candidates, each containing information such as IP addresses, port numbers, and transport protocols. These candidates are instrumental in establishing the most optimal connection between devices, regardless of their network setups.
When establishing a WebRTC connection, each device shares its list of ICE candidates with the other device. This information is utilised to determine the best available network path for the session, ensuring a successful connection.
ICE candidates use a process called connectivity checks to determine which network path to use. This process involves sending and receiving messages between the two devices to test the connection quality and latency.
Once the best network path is determined, the devices establish a direct peer-to-peer connection over the Internet. STUN and TURN servers, which we’ll discuss later, are often used to facilitate the exchange of ICE candidates and establish connections when direct peer-to-peer communication is not possible.
By using ICE candidates to find the best available network path, WebRTC is able to traverse NATs and firewalls and connect users, even when they are behind complex network configurations.
An ICE server is a crucial component to WebRTC technology, it works in conjunction with the ICE protocol to provide the infrastructure that allows devices that leverage WebRTC to establish a connection with each other over the Internet.
ICE servers are particularly crucial when devices are separated by NATs or firewalls.
There are two main types of ICE servers:
Devices across the internet communicate using IP addresses and port numbers. To make this communication faster and more efficient, each device needs to be aware of the IP address and port number of the device they want to connect with.
In WebRTC, devices leverage STUN servers to help them find out their own IP address and port number which they can use to communicate. They achieve this by sending and receiving data packets to the STUN server, which returns data packets containing their public address and port number.
In some cases, devices are behind firewalls and NATs that hide their real IP address, preventing peer-to-peer communication over the internet. This is where STUN servers come into play. So when a device tries to connect to another device over the internet, the STUN servers help it determine the device’s public IP address and port number even if it’s behind a firewall or NAT. It also determines whether it’s a full clone NAT or an address-restricted network.
The STUN servers then return the IP address and port number that a client can use to establish a peer-to-peer connection. This way, STUN reduces latency and bandwidth consumption since the data packets are now being sent directly between devices. This information also helps the ICE protocol determine the best channel to use for communication.
However, STUN servers cannot be used in more restrictive types of NAT called symmetric NAT. This is where TURN servers come in handy. A reverse proxy server acting as a Layer 4 proxy is often used to forward the raw data packets between the WebRTC clients and the TURN server, reducing the need for additional hardware.
A TURN server acts as a relay between WebRTC devices that cannot establish a direct peer-to-peer connection due to network restrictions. For instance, when both devices are behind NATs or firewalls, or when a device is behind a symmetric NAT that does not allow direct communication.
TURN servers incur higher costs compared to STUN servers, as they are more resource-intensive and require more bandwidth to relay the data packets.
To reduce the costs of TURN servers, address-restricted clone NAT can be used instead of full clone NAT. Address-restricted clone NAT allows multiple devices to share the same public IP address and port number, reducing the number of connections required for a TURN server to handle.
However, this may increase latency and reduce overall performance. Hardware acceleration is also another option that can be used to improve the performance of TURN servers and reduce latency, but it can also be expensive to implement.
ICE servers play a critical role in establishing a WebRTC connection by helping devices discover and connect to each other. When two devices attempt to establish a WebRTC connection, each device sends its list of ICE candidates to the other device. If a direct connection cannot be established between the two devices, they will use ICE servers to relay media streams and establish the connection.
Session Description Protocol (SDP) is a text-based protocol used to set up multimedia sessions between devices across the internet. It includes details of the media streams, such as the type of codec, transport protocol, and other related information.
SDP plays a critical role in WebRTC by enabling devices to negotiate media formats, transport protocols, and other details required for a successful connection. When two devices attempt to establish a WebRTC connection, they exchange SDP messages to negotiate the details of the media streams they want to send and receive.
When devices are establishing a connection over the internet, they need to let each other know the type of media streams they want to send and receive, the transport protocols that should be used, the type of codec and any additional information needed to establish a connection. All this information is sent and received as an SDP.
If the devices come to an agreement on the connection requirements, a peer-to-peer connection is established and the devices can send and receive media streams in a direct and standardised way. Additionally, this ensures compatibility between devices from different manufacturers.
ICE and SDP are two important protocols used in WebRTC, which is the backbone of our video conferencing API. As mentioned above, ICE is responsible for facilitating the connection between devices over the Internet, while SDP is responsible for negotiating the parameters of a multimedia session between the devices.
Overall, ICE and SDP play a crucial role in the success of Digital Samba as a real-time communication platform. By leveraging these technologies, Digital Samba is able to provide its users with seamless and reliable real-time communication independent of a user’s geographical location or communication channel.
When it comes to real-time communication between devices over the internet, WebRTC is one of the most powerful technologies. It leverages a combination of ICE and SDP protocols to not only establish secure connections but also ensure communication is stable and reliable throughout a session. ICE helps devices traverse NATs and firewalls while SDP helps devices negotiate and agree on the parameters of the multimedia session.
Our API leverages ICE, ICE servers and SDP to provide a robust real-time video conferencing platform. ICE and ICE servers help ensure that users can connect even when barriers like NATs and firewalls make it difficult to do so while SDP enables devices to negotiate the best possible parameters for each user, enabling high-quality audio, video and text communication.
Digital Samba’s GDPR-compliant video conferencing API uses of ICE and SDP makes it one of the most powerful and reliable real-time video conferencing platforms. So whether, you’re using it for work, education or socialising, you can trust Digital Samba to deliver an excellent user experience.