Supplementary Protocols and Technologies

In the realm of digital communication, Network Address Translation (NAT) plays a crucial role in managing IP addresses within private networks. However, NAT presents challenges for peer-to-peer (P2P) communications, as it obscures the IP addresses and ports of devices, making direct communication between devices difficult. This necessitates the use of NAT traversal techniques, which include protocols like STUN, TURN, and ICE, to facilitate effective P2P connectivity across different network configurations. 

STUN (Session Traversal Utilities for NAT)

STUN is a protocol designed to allow an end host to discover its public IP address and the type of NAT it is behind. This is achieved by sending a request to a STUN server located outside the NAT. The server replies with the public IP and port that is visible to the outside world, which can then be used to inform other peers about how to establish a direct connection. However, STUN may not work effectively with symmetric NATs, where the port mapping changes with every request to different external destinations. You will find detailed information about STUN in RFC8489. 

TURN (Traversal Using Relays around NAT)

TURN is specified in RFC8656. When STUN is not an option due to the type of NAT or firewall restrictions, serves as a robust alternative for NAT traversal. Unlike STUN, which merely discovers the public IP address and port, TURN facilitates the relay of traffic through a server located in the public domain. This approach ensures connectivity even in the most restrictive NAT environments. 

The client first requests a TURN server to allocate a public IP address and port for its use. Once the allocation is set, the TURN server relays data between the client's private network and its peer (or peers) on the Internet. The client sends its data to the TURN server, which then forwards it to the intended recipient. The TURN server keeps the relay allocation active for the duration of the session, handling inbound and outbound data as a middleman.  

ICE (Interactive Connectivity Establishment)

ICE represents a holistic approach to NAT traversal, integrating the capabilities of both STUN and TURN to ensure the highest probability of successful P2P communication. ICE works by gathering all possible candidates (ways to connect) that could be used for communication between peers. These include host addresses (direct connections), STUN-discovered addresses, and TURN relay addresses. ICE then attempts to establish the connection starting with the most preferred candidate, based on a priority system that considers factors like direct connectivity and network performance. For more detailed information on ICE, please refer to RFC8863.

The RTP Protocol 

The Real Time Protocol (RTP), standardized in RFC3550, is crucial for the real-time transport of data such as audio and video over IP networks. Utilizing UDP for transport, RTP allows for the packetization of media, adhering to specific requirements for timing, sequence numbering, timestamps, and synchronization.  

Codecs and DTMF-Relay 

Codecs play a vital role in encoding the media content for RTP transport, with options ranging from uncompressed formats like G.711 to compressed formats like G.729 and GSM, catering to bandwidth efficiency and loss concealment. DTMF-Relay, as described in RFC2833, is essential for transmitting signaling information such as DTMF tones over RTP, ensuring interoperability between user agents in signaling events. 

Real Time Control Protocol (RTCP) 

RTCP complements RTP by providing feedback on the quality of reception, including statistics on jitter, latency, packet loss, and round-trip time (RTT). It is instrumental in voice quality reporting and in assessing the performance of the media flow. RTCP is defined in RFC3550.

Session Description Protocol (SDP) 

Defined in RFC8866, SDP is used for negotiating session parameters, including media types, transport addresses, and codec support, between user agents. The INVITE message typically contains the SDP offer, with the "200 OK" response carrying the answer, allowing for the effective establishment of media sessions and codec negotiation.