Stun Server: What is Session Traversal Utilities for NAT?
In this post we will learn about the STUN Server and TURN, NAT, ICE and UDP, let's get started.
STUN server: What is it? and how does it make the magic of WebRTC work.
In this article we will learn about Packets of data and how do they travel peer-to-peer between 2 devices through very difficult terrain of corporate firewalls, Multiple NATs, flaky connections and unknown network addresses ports.
Our Journey begins with the STUN server, and we will also learn about the following along the way:
- What are STUN Servers?
- What are TURN Servers? STUN server Vs TURN server
- What is NAT Traversal?
- What are ICE Candidates?
- What is the UDP Protocol?
If you need Global STUN and TURN server consider the Metered Global WebRTC STUN & TURN server
What is a STUN Server?
Simple Explanation
STUN servers allow a client device to discover its own Public IP address.
In situations where a client device is behind a NAT device usually a router, (devices behind a NAT have private IP address and all their data is routed through a single Public IP address by the NAT device usually a router)
Client devices do not know what their public IP address is, they only know their private IP address
These devices ping the STUN server and the STUN server replies back with the IP address and port number with which it is being pinged.
This is relayed back to the NAT device first which then forwards it to the client
the client device can then share the public IP and port with another device on the internet in order to establish P2P communication
Technical explanation
STUN is a protocol that allows the host application to discover the presence of NAT on the network, and if found get the public IP address and port for the current connection.
To achieve this the STUN protocol requires a well known third party server on the public network i.e the internet, called the STUN server.
The NAT Problem
In many networks especially in home, office as well as enterprise networks, there are multiple devices behind a single public IP address
NAT is the process of translating the private IP traffic into public IP and vice versa
that is internal devices have a private IP addresses and all their traffic is send through a single public IP address.
The traffic coming from the internet is distributed to the internal devices with private IP addresses using NAT
The Problem with p2p communication
To conduct p2p communication each device needs to know the other device's IP address. But due to NAT the IP address is hidden. The device itself does not know what it's public IP is. The public IP address is only known to the router.
This makes it difficult to communicate between devices.
Role of the STUN Server
- Discovery of Public IP and port A STUN server which is located on the internet, helps the client devices discover what their Public IP address and PORT number is.
This is achieved when the client sends a request to the STUN server and when then replies back with the devices Public IP and PORT number.
- Type of NAT Determination: STUN can be used to determine, client are behind what knd of NAT.
This kind of information can used to establish effective communication strategies behind different kinds of NAT
- Connection Establishment : One the external IP address and PORT number of the clients are known, the client then shares this information with its peer clinet and they can establish direct communication with each other using WebRTC or any other protocol.
this can be useful in VoIP, video calling, online gaming, and other real-time communications.
Limitations and Complimentory protocols
- Does not work everytime: STUN servers does not always work, many times there are firewall rules and symmetrical NATs and many other situations where the STUN server does not work.
In these cases there are alternative TURN servers which must be used.
- TURN servers alternative to STUN Servers In cases where STUN servers do not work then to establish the connection TURN servers are used.
TURN server relay encrypted traffic through the servers, ensuring connectivity.
Metered Global TURN servers
- Global Geo-Location targeting: Automatically directs traffic to the nearest servers, for lowest possible latency and highest quality performance.
- Low Latency: less than 50 ms latency, anywhere across the world.
- Cost-Effective: pay-as-you-go pricing with bandwidth and volume discounts available.
- Easy Administration: Get usage logs, emails when accounts reach threshold limits, billing records and email and phone support.
- Standards Compliant: Conforms to RFCs 5389, 5769, 5780, 5766, 6062, 6156, 5245, 5768, 6336, 6544, 5928 over UDP, TCP, TLS, and DTLS.
- Multi‑Tenancy: Create multiple credentials and separate the usage by customer, or different apps. Get Usage logs, billing records and threshold alerts.
- Reliability: 99.999% Uptime with SLA.
- Enterprise Scale: : With no limit on concurrent traffic or total traffic. Metered TURN Servers provide Enterprise Scalability
- 5 GB/mo Free: Get 5 GB every month free TURN server usage with the Free Plan
Practical Applications
- VoIP: STUN servers are widely used in VoIP servers like Skype
- Video Calling: STUN servers are also used in Video calling applications using WebRTC video calling
- File Sharing and Streaming: STUN servers can be used to share files and Stream video and audio and other files as well
IP addresses depletion Problem
So many devices are being born, there is a problem to assign an IP address to each of them.
During the 1990 there was a cambrian explosion of devices on the internet.
And as we know the IPV4 is a 32bit number, so there are only 4.29 billion unique IPV4 addresses in the world.
The people running the internet were worried, we cannot give every device its own IP address, something needs to be done about this.
They came up with a temporary solution called NAT which like most things in life became a permanent solution and we have NAT everywhere.
What is Network Address Translation (NAT):
NAT or Network address translation is a method of mapping an IP address space to allow the traffic to get to its destination when a device does not have a public IP address.
A NAT device at the edge of a network, which would be mapped to a public IP address and which will have a table of local IP addresses.
The devices behind the NAT will use the local IP addresses and the public IP address of the NAT will be used for all the devices behind the NAT.
So, any traffic that needs to go to any device behind the NAT will be sent to the public IP of the NAT and NAT will have a table of devices with mapped local address
NAT will send the traffic to the local device behind it.
To the world on internet all the devices behind the NAT look like a single device.
The local address shall remain unknown to the outside world, so some IP subnets were reserved for the local networks i.e
10.0.0.0 – 10.255.255.255172.16.0.0 – 172.31.255.255192.168.0.0 – 192.168.255.255
These addresses should not be routed in the internet and were reserved for local use and thus be reused, and in front of these private ip addresses there will be a NAT device that would have globally route-able public ip address and would do that translation from public to private addresses and vice versa for its network.
Hence using one public IP for many devices.
Usually in a home or office the internet service provider provides a single public IP address and all the devices are behind this IP address.
To reach a specific device from the outside world the outside servers sends the packets to the public IP address and then the NAT transfers the data to the device on the local IP address because the NAT know which device on the local network requested the data.
The problem arises if we want to establish a direct connection between two or more clients, because with NAT all the clients will be behind a NAT.
It only knows it s internal local IP address and the NAT devices rewrites the source port and address in every UDP packet as well as the originating IP addresses within the IP packet.
The client cannot communicate with outside peers with its internal IP address because connection will fail.
Hence, the application must discover its public IP address and then share it with a peer outside its network.
However, Just knowing about the public IP address does not solve the problem.
Any packet that arrives at the public IP of a NAT device must also have a destination port and an entry into the NAT table that can translate it to an internal IP to an internal destination host IP and port.
If this entry does not exists which is most likely the case if the client is directly communicating with its peers from the outside world then the NAT drops the packets because NAT has no way of knowing where to send this packet (that is to which device this packet needs to go).
TO work around this mismatch various Traversal techniques have been invented namely (STUN, TURN and ICE).
These are use to establish end-to-end connectivity between peers across the network.
The technique of bypassing the NAT to establish the connection with the device behind the NAT is called as NAT Traversal
Metered Global TURN servers
- Global Geo-Location targeting: Automatically directs traffic to the nearest servers, for lowest possible latency and highest quality performance.
- Low Latency: less than 50 ms latency, anywhere across the world.
- Cost-Effective: pay-as-you-go pricing with bandwidth and volume discounts available.
- Easy Administration: Get usage logs, emails when accounts reach threshold limits, billing records and email and phone support.
- Standards Compliant: Conforms to RFCs 5389, 5769, 5780, 5766, 6062, 6156, 5245, 5768, 6336, 6544, 5928 over UDP, TCP, TLS, and DTLS.
- Multi‑Tenancy: Create multiple credentials and separate the usage by customer, or different apps. Get Usage logs, billing records and threshold alerts.
- Reliability: 99.999% Uptime with SLA.
- Enterprise Scale: : With no limit on concurrent traffic or total traffic. Metered TURN Servers provide Enterprise Scalability
- 5 GB/mo Free: Get 5 GB every month free TURN server usage with the Free Plan
How does the STUN Server work?
detailed explanation:
Session Traversal Utilities for NAT (STUN) is a protocol that allows the host applications to discover the presence of NAT on a network.
When the NAT is found STUN also allows the public IP and the port of the local device connection to be discovered.
For this protocol to work there must be a well known stun server available on the public network
Assuming the IP address of the STUN server is known, because it is on the public network (through DNS stun for UDP or stuns for TCP/TLS server resource record. or manually writing the public address of the STUN server).
The client application sends a binding request to the STUN server and the server responds with the public IP address and host of the client as seen through the eyes of the public stun server.
The result is obfuscated through exclusive or (XOR) mapping to avoid translation of the packet content by application layer gateways that perform deep packet inspection in an attempt to perform alternate NAT traversal methods.
This solves many problems that we discover while sending data through NAT:
The client discover the public IP and port of its peers and is able to communicate with its peers.
The outbound request to the STUN server create an routing entry into the NAT table along the path.
such that the inbound packets can find their path to the host on the local network when they arrive at the public IP address.
The STUN protocol defines a simple mechanism for keep alive pings to keep the NAT routing entries from timing out.
With STUN servers in place when ever two peers want to connect with each other they will send their requests to their STUN servers and after a successful response from both sides they can establish a public IP and port to exchange data.
STUN messages are sent using the UDP protocol and since as we have discussed above the UDP is not a reliable protocol. reliability must be implement through application control retransmissions.
The STUN servers themselves do not implement any reliability methods inside them. If reliability is mandatory TCP can be used and for security STUN packets can be encrypted using the TLS security layer.
In practice, However STUN servers are not sufficient to deal with all NAT topologies and network conditions
Sometimes commonly in corporate environments UDP might be blocked in the firewall settings.
To deal with this issue, whenever STUN fails we can fallback on TURN (Traversal using Relay around NAT) the KEY word here is Relay.
Metered Video provides a free WebRTC TURN server to relay traffic across networks.
We will learn more about how TURN works in the section after this one.
STUN server Protocol details
STUN is a client server protocol. IT supports 2 types of transactions.
The first one is a client server request, where a client sends a request to the server and the server responds.
The second one is called a indication transaction, this can be send through with the client or the server but it generates no response.
Both the transactions include a transactionID, a randomly selected 96 bit number.
For the client server transaction the transactionID acts as a verification tool and for the indication transaction it can act as a debugging tool.
All stun messages start with a fixed header that contains the following:
- a method
- a class
- a transactionID
The only mandatory method is the binding method which indicates the various requests.
The binding method is used to determine the particular binding a NAT response has allocated to the client. the binding method can also be used to keep the bindings alive.
The class indicates whether this is a :
- request
- success response
- an error response
- an indication
In the Binding request/ response transactions a binding request is sent from the client to the server.
TO reach the server the binding request passes through a single NAT or multiple NATS that are between the client and the server As the Binding requests pass through NATs the NAT modifies the source transport address ( that is the source IP address and the source port) of the packet.
As a result when the server receive the packet from the NAt it will contain the public IP address and port of the NAt closest to the server.
This is called as reflexive transport addresses.
The stun server then copies this address in an COR mapped addresses and sends it back to the client in the STUN binding response.
As this packet passes through the NAT the NAt will modify the destination transport header in the IP header but the XOR MAPPED ADDRESS will remain untouched.
In this the client learns its XOR-MAPPED-HEADER
STUN Protocol Terms
STUN Agent: The entity that implements the STUN protocol. The entity could be a client or a server.
STUN client: The entity that sends the STUN requests and gets the stun responses is a STUN client.
STUN server: The entity that receives a STUN requests and sends the STUN responses is a STUN server.
Transport Address: Ip address and port number combination is called as a Transport address.
Reflexive Transport Address: The address as seen by the STUN server. Reflexive Transport address is the mapped address allocated to the client on the other side of the NAT.
Mapped Address: same meaning as reflective address.
Long-Term Credentials a username and password that is a shared Credential between a server and the class. Long term credentials are generally granted to the client by a service provider (a service provider that is offering the service. Example: a free service provider is the Open Relay Project by Metered Video they provide a free public turn server.)
Long-Term Password password is a long term Credential
Short-Term Credentials A temporary username and password that is used to establish a connection between the client and the server before the STUN exchange. They are exchanged with some kind of mechanism.
Short-Term Password A short term password
STUN indication: A STUN message that does not receive a response.
Attribute A Type length Value object that can be added to the STUN message. There are 2 types
1. comprehension required: *Message cannot be successfully processed if they are not understood*
2. comprehension-optional: *Can be ignored safely by STUN agents*RTO Retransmission Timeout: Time between initial transmission of request and another retransmit of that request
Detailed protocol workings of STUN server
In this section we will discuss the following
- How STUN messages are formed
- How STUN messages are sent
- Sending Request over the UDP protocol
- Sending Request over the TCP or TLS-over-IP protocol
- How STUN messages are processed when they are received
How STUN messages are formed
The STUN agent creates a STUN message. The STUN message class must be wither "Request" or "Indication" and the method must be either "binding" or some other methods For Binding method with no auth no attributes are required.
Sending a request
The STUN agent sends a request or indication. STUN messages can be sent over
1. UDP
2. TCP
3. TLS-over-TCP
The STUN message must specify the transport protocol that is being used and how the agent determines the IP address and port of the recipient.
STUN agent can also use DNS to determine the IP address and port number of the host.
A client can have multiple outstanding requests with the same TURN server.
Care must be taken given other considerations that new transactions are spaced to a server by RTO and should limit itself to 10 outstanding transactions to the same server.
Sending over UDP
When sending packets over UDP it is possible that the packets are dropped as the UDP offers No guarantees to reach the destination No failure notifications
reliability of STUN requests must be accomplished through retransmissions of the request message by the client itself.
The client can retransmit the request message starting with the RTO (retransmission Time out) interval and doubling after each retransmission. retransmissions can continue until a response is received or until the total Rc requests have be exhaused the default Rc requests is 7.
Sending over TCP /IP
For transmitting the STUN messages over the TCP the client opens are TCP connection to the server.
In some use cases the STUN is send as the only protocol over the TCP connection, in these cases the STUN can be sent with any additional framing or multiplexing.
In other use cases STUN is sent STUN is multiplexed with other data over the TCP connection.
When STUN is multiplexed with other data over the TCP connection some kind of framing protocol is required and STUN runs on top of that framing protocol.
That framing protocol allows the STUN messages to be received.
If you are running the STUN messages over TCP the RCA cipher must be implemented at a minimum but other cipher suites can also be used.
reliability of STUN messages being received is handled by TCP itself and there is no need for retransmissions at the STUN protocol level
For a request / response transaction if the client is unable to establish a connection over TCP or if the TCP connection is reset of fails then the request / response transaction is considered to have failed.
the client can send multiple requests over TCP and it can send multiple requests even before receiving a response.
The client should keep the connection open until
- all the STUN requests have been sent over the connection
- have no plans to use any other resources that were learned through STUN requests or relayed address (TURN)
The server should keep the communication open and let the client end the communication unless it is timed out.
Bindings learned by the client are valid only such time as the connection is open.
Receiving STUN messages
When a STUN server receives a message, it checks for the following criteria.
- Are the first 2 bits 0 ?
- Magic cookie field has the correct value?
- Does the message length makes sense?
- Is the message class allowed for the particular method?
- Is the message value a supported method?
- If it is a success response or a error response it checks whether the transactionID is the same as the transactionID of the current transaction in process.
- If errors are detected the message is silently discarded.
- If fingerprint attribute is used the agent checks if the fingerprint attribute is present and if it is correct.
- If there are any authentication mechanisms in place the STUN checks for the authentication.
Processing the request.
How does the STUN agent process the request once it is received. It does the following processes:
- Checks for one or more unknown comprehension-required attributes and if present sends the error response with the code 403 and includes an UNKNOWN-ATTRIBUTE response in the response listing the unknown attributes.
- Does any additional checking that is required by the method and formulates a success response.
Formulating a Success or ERROR response
The method of sending the success or error response is the same as that of receiving the request.
success response sends the data along with the success code of 200.
For the ERROR response the server adds an error code attribute to the response.
a phrase is also added to the error response that describes the type of error.
Setting Up STUN Server
In this section we will learn how to setup STUN server in your application in a step by step manner
Step 1 Prerequisites for setting up a STUN server
A Basic understanding of JavaScript and web development concepts and basic understading of NAT Traversal and how to establish a peer-2-peer connection
Step 2 Choosing a STUN server
There are many free and paid STUN server services. Some of the popular ones are
- Metered Global WebRTC STUN and TURN servers
- Google STUN servers
You can also setup your own STUN servers as well
Step 3 Setting up the WebRTC Configuration
You need to set up the configuration Object. This Object includes information about ICE (Interactive connectivity Establishment) servers. Which has both STUN and TURN servers
Example of a basic STUN server configuration
let configuration = {
'iceServers': [{
'urls': 'stun:stun.l.google.com:19302'
}]
};
Creating a Peer Connection
Now we will be creating a new RTCPeerConnection Object using the configuration. This object represents a WebRTC connection between the local computer and a remote peer
let peerConnection = new RTCPeerConnection(configuration);
Step 5 Creating and sending an Offer
To initiate a connection with a remote peer, we need to create an offer In this offer we will include the information regarding media tracks audio and video and any other data channels that we need to open
peerConnection.createOffer()
.then(offer => peerConnection.setLocalDescription(offer))
.then(() => {
// Send the offer to the remote peer using your signaling server
});
Step 6 The ICE candiates?
When the RTC Peer connection finds an ICE Candidate the 'icecandidate' event is triggered.
You can learn what are ICE candiates?
We need to handle this event on the client side and send the ICE candidate to the remote peer
peerConnection.onicecandidate = event => {
if (event.candidate) {
// Send the ICE candidate to the remote peer using your signaling server
}
};
Step 7 Incoming offers, Answers and ICE candidates
We need to listen to the messages from the signalling server, using functions like 'setRemoteDescription' and 'addIceCandidate' on the RTCPeerConnection
// Listen for messages from your signaling server
signalingServer.onmessage = message => {
if (message.offer) {
peerConnection.setRemoteDescription(new RTCSessionDescription(message.offer));
// Create an answer and send it back to the remote peer
peerConnection.createAnswer()
.then(answer => peerConnection.setLocalDescription(answer))
.then(() => {
// Send the answer back to the remote peer using your signaling server
});
} else if (message.answer) {
peerConnection.setRemoteDescription(new RTCSessionDescription(message.answer));
} else if (message.iceCandidate) {
peerConnection.addIceCandidate(new RTCIceCandidate(message.iceCandidate));
}
};
This is how you can set up the STUN server on the client side.
What is a TURN server? TURN Server Vs. STUN Server
Turn Server is a server that is required to relay traffic between 2 hosts/ peers that are in different networks.
Metered Global TURN servers
- Global Geo-Location targeting: Automatically directs traffic to the nearest servers, for lowest possible latency and highest quality performance.
- Low Latency: less than 50 ms latency, anywhere across the world.
- Cost-Effective: pay-as-you-go pricing with bandwidth and volume discounts available.
- Easy Administration: Get usage logs, emails when accounts reach threshold limits, billing records and email and phone support.
- Standards Compliant: Conforms to RFCs 5389, 5769, 5780, 5766, 6062, 6156, 5245, 5768, 6336, 6544, 5928 over UDP, TCP, TLS, and DTLS.
- Multi‑Tenancy: Create multiple credentials and separate the usage by customer, or different apps. Get Usage logs, billing records and threshold alerts.
- Reliability: 99.999% Uptime with SLA.
- Enterprise Scale: : With no limit on concurrent traffic or total traffic. Metered TURN Servers provide Enterprise Scalability
- 5 GB/mo Free: Get 5 GB every month free TURN server usage with the Free Plan
This is because a direct connection is not possible between 2 peers unless they are on the same network(This is because firewall blocks the traffic).
The Term TURN server stands for Traversal using NAT.
There are currently a few options for TURN servers online, one of them is the Open Relay Project by Metered Video they provide a public TURN server for Free.
This is how TURN server works in practice
- Multiple clients send their requests to the same TURN server following by authentication and permission negotiations
- Once the connection is establish and the negotiations are completed the clients communicate with the TURN server which in turn relays the data to the other clients.
Using TURN servers means that the communication is no longer peer-to-peer and must go through the server.
TURN is the most reliable method of communicating between peers but it carries a high cost in terms of network traffic as all traffic must go through the server and as much in many scenarios it is used as a last resort when connectivity fails.
TURN server configuration
You add add turn server configuration in 2 ways
Add the static urls on the front end or whereever you need them.
Use the API to fetch url everytime. Learn more on the Metered TURN server website
adding the urls on the front end or whereever you need them
Once you have a TURN server online, all you need is the correct RTCconfiguration for the client to use it.
If you are using the Free turn server provided by the Open Relay Project then here is a sample url (these are not real urls, you need to create a account for that.)
var myPeerConnection = new RTCPeerConnection({
iceServers: [
{
urls: "stun:openrelay.metered.ca:80",
},
{
urls: "turn:openrelay.metered.ca:80",
username: "openrelayproject",
credential: "openrelayproject",
},
{
urls: "turn:openrelay.metered.ca:443",
username: "openrelayproject",
credential: "openrelayproject",
},
{
urls: "turn:openrelay.metered.ca:443?transport=tcp",
username: "openrelayproject",
credential: "openrelayproject",
},
],
});
A demo configuration if you are using your own TURN server would be.
Turn server will have the host name and will be running on a port. the configuration object supports username and password fields
const iceConfiguration = {
iceServers: [
{
urls: 'turn:demo-turn-server.test.com:19403',
username: 'optional',
credentials: 'auth-token'
}
]
}
const peerConnection = new RTCPeerConnection(iceConfiguration);
- Using the API
You can also use the API to fetch the creds from the TURN server. learn more on the Metered TURN server website
Testing the TURN Server.
You can test the TURN server at: https://turndemo.metered.ca/
or
Go to the Trickle ICE website at
and enter the TURN server credentials
ICE Candidates
Building an effective NAT traversal solution is a very difficult given the layers upon layers of NAT and firewalls blocking ports and protocols. Thankfully ICE has been developed as an effective protocol to traverse the NAT ICE or Interactive Connectivity Establishment protocol is a set of methods that see to establish the most efficient tunnel between the participants
- Connecting peers directly when possible
- Using STUN negotiation when needed
- and fallback on TURN when needed.
The STUN server and the data transport is done on the UDP protocol. Let's learn more about the UDP protocol:
The UDP Protocol
Jon Postel added the UDP protocol or the User Datagram Protocol to the core network protocol suite on August of 1980, about the time TCP and IP specifications were being split into 2 different RFCs.
This timing is important, because the primary appeal of the UDP protocol is not in what it introduces but in what it chooses to omit.
The UDP is also called the null protocol or the unreliable datagram protocol indeed the RFC of the UDP could easily fit on a paper napkin:
A self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination nodes without reliance on earlier exchanges between the nodes and the transporting network.
While datagram and packets are terms that are used interchangeable there are some differences. While packet refers to a formatted block of code the datagram refers to a block of code transported via unreliable networks.
The defining feature of the UDP protocol is the unreliable nature of transportation of data. That is:
- No delivery guarantees
- No failure notifications
For this reason UDP is called Unreliable Datagram protocol instead of the official term User Datagram protocol and this is the reason UDP packets are called as DataGrams.
While you might be wondering if it is unreliable, what use can it be of when there are other reliable protocols available. Well people have built reliable systems off of unreliable protocols and what the UDP loses in reliability it gains in speed and throughput
The webRTC (Web real time communications) standards that enable video calling, voice calling, and data transfers of all kinds run on the UDP protocol.
Null Protocol Services
To understand UDP, lets look at the Internet Protocol (IP), which is located one layer below the both TCP and UDP protocols.
The primary task of the IP protocol is delivering datagrams or packets from source to the destination host based on their addresses.
Messages are encapsulated within the IP packet which identifies the source and destination of the address as well a number of routing parameters
The IP layer provides no guarantees of delivery or notification of failures hence exposes the unreliability of the underlying protocol to the layers above it.
If a routing node drops a packet due to congestion, high load or any other reason then it is the responsibility of the layers above it to recover, retransmit the data if that is the desired behavior.
| bit | +0.7 | +0.7 | +8.15 | +8.15 | +16.23 | +24.31 |
|---|---|---|---|---|---|---|
| 0 | Version | Header Length | DSCP | ECN | Total Length | Total Length |
| 32 | Identification | Identification | Identification | Identification | Flags | Fragment Offset |
| 64 | Time to Live | Time to Live | Protocol | Protocol | Header Checksum | Header Checksum |
| 96 | Source IP Address | Source IP Address | Source IP Address | Source IP Address | Source IP Address | Source IP Address |
| 128 | Destination IP Address | Destination IP Address | Destination IP Address | Destination IP Address | Destination IP Address | Destination IP Address |
| 160 | Options (if present) | Options (if present) | Options (if present) | Options (if present) | Options (if present) | Options (if present) |
| ... | payload | payload | payload | payload | payload | payload |
IPV4 header
| Bit | +0.7 | +0.7 | +8.15 | +8.15 | +16.23 | +24.31 |
|---|---|---|---|---|---|---|
| 0 | source port | source port | source port | source port | Destination Port | Destination Port |
| 32 | length | length | length | length | checksum | checksum |
| ... | payload | payload | payload | payload | payload | payload |
UDP header
UDP protocol encapsulates the User messages into its own package structure which adds 4 more fields to the IP layer
- source port
- destination port
- length of the packet
- checksum
When the IP delivers the packet to the destination host the host is able to identify the target application by the destination port and deliver the message.
At its code, UDP just provides application multiplexing above the IP protocol by embedding the source and target application ports of the communicating hosts. Let us summarize all the UDP non-services:
- No guarantees of message delivery: No acknowledgements, retransmissions or timeouts
- No guarantees of order of delivery: No packet sequence numbers, no reordering, no head-of-line blocking
- No connection state tracking No connection establishment or teardown state machines
- No congestion control No built in client or network feedback mechanisms
Conclusion:
In this article we have listed how the STUN protocol works and how its friends namely the TURN server, the ICE protocol and the UDP protocol help with the connection and transmission of data through webrtc.
Metered Global TURN servers
- Global Geo-Location targeting: Automatically directs traffic to the nearest servers, for lowest possible latency and highest quality performance.
- Low Latency: less than 50 ms latency, anywhere across the world.
- Cost-Effective: pay-as-you-go pricing with bandwidth and volume discounts available.
- Easy Administration: Get usage logs, emails when accounts reach threshold limits, billing records and email and phone support.
- Standards Compliant: Conforms to RFCs 5389, 5769, 5780, 5766, 6062, 6156, 5245, 5768, 6336, 6544, 5928 over UDP, TCP, TLS, and DTLS.
- Multi‑Tenancy: Create multiple credentials and separate the usage by customer, or different apps. Get Usage logs, billing records and threshold alerts.
- Reliability: 99.999% Uptime with SLA.
- Enterprise Scale: : With no limit on concurrent traffic or total traffic. Metered TURN Servers provide Enterprise Scalability
- 5 GB/mo Free: Get 5 GB every month free TURN server usage with the Free Plan