Session Traversal Utilities for NAT is a standard method of NAT traversal used in WebRTC. The definition is in IETF RFC 5389.

It is one of two NAT traversal servers that are used in WebRTC (the other one is TURN).

At its core, it’s purpose is to answer the question “what is my IP address?” It does that by using a STUN server.

What is a STUN server?

It is a client-server protocol.

A STUN server is a server that runs on the public network and replies to incoming requests. The responses sent out include the public IP address the request was sent to him from. This effectively answers the question “what is my IP address?”

In most cases, the STUN servers aren’t installed and managed as separate entities but are rather installed together with TURN servers.

While there are free public servers that can be used (such as the one Google operates), it isn’t advisable to use them in commercial services as your main NAT traversal mechanism.

Using a STUN server

A WebRTC client has to know its public IP address in order to get more sessions connected successfully. For that purpose, WebRTC sends a request to a STUN server asking for its public IP address. The server replies back to the WebRTC client with the public IP address the request came from. This way, the WebRTC client learns what its public IP address is.

The WebRTC client then shares the public IP address it received from the server with its peer.

It might not always work. With some network architecture and NAT device types, the public IP address obtained via STUN will not work. This is why we use it in conjunction with TURN and ICE.

As a protocol, it is lightweight and simple, making the availability of public, free and open servers possible.

Free and public Session Traversal Utilities for NAT server

There are various free STUN servers available out there.

It is lightweight and carry no real authentication mechanism to it. This makes it simple for developers to connect to freeservers without any technical hurdles. It is not advisable to do so.

• These free STUN servers might not be there for you tomorrow, and there is no one that offers support for them or even guarantees that they will be there
• You will usually also need TURN servers and these aren’t free. As a result TURN servers also double as STUN servers and you will need to deploy or pay for those, just use them for STUN as well
• Using too many STUN and TURN servers in the iceServers list is counterproductive, often causing delays in connectivity and increasing network congestion instead of improving your chances to connect

Best practices

• STUN doesn’t cost much to operate, which is why there are various free servers you can connect to. Accordingly if you are using a free or a public server (like the famous stun.l.google.com:19302 server), expect it to go down from time to time as you have no control or an SLA for it
• STUN is usually deployed with TURN servers. Focus on a TURN server solution and STUN “will follow”
• Basically configuring TURN/UDP implicitly also implements the STUN protocol. As a result if you use a TURN/UDP server, you can do away with explicitly stating the server in the iceServers configuration of a peer connection

See also the episode of “WebRTC Insights”:

The post STUN: Definition and explanation appeared first on BlogGeek.me.

MQTT is a common protocol used in Internet of Things use cases.

At times, MQTT is used with WebRTC applications. The biggest example is Facebook Messenger, which makes use of MQTT and its voice and video calling features are built using WebRTC.

The post MQTT appeared first on BlogGeek.me.

It is a 32 bit random value that is generated in RTP to denote a specific source used to send media in an RTP connection.

The post SSRC appeared first on BlogGeek.me.

Signaling multiple media sources is needed to be able to send a video along with screen sharing, multiple camera sources or routing multiple streams from an SFU to the users.

In Unified Plan, there is an m= line per each media source.

The mechanism chosen for the official WebRTC specification is Unified Plan. The competing approach is known as Plan B.

Today, all browsers support it by default.

Signaling Multiple Media Sources

In multiparty real-time communication setup (most group calling solutions), the ability to handle multiple media sources is important.

This includes the capability to send a video alongside screen sharing, managing multiple camera sources, or routing multiple streams from a Selective Forwarding Unit (SFU) to the users.

The necessity for a standardized plan arose from the need to ensure seamless interaction among these media elements, and thus, the Unified Plan was conceived.

Structure

The core structure is defined by the presence of an m= line for each media source within the SDP.

This m= line is a fundamental aspect as it delineates each media source, thereby facilitating the organized signaling of multiple media streams.

The structuring is what sets Unified Plan apart and aligns it with the official WebRTC specification.

Adoption and Browser Support

Unified Plan, over time, has garnered widespread adoption and has become the mechanism of choice as per the official WebRTC specification, superseding the competing (and not deprecated or unimplemented) approach known as Plan B.

The transition was driven by its robust structure and the ease it introduced in managing multiple media sources.

The post Unified Plan appeared first on BlogGeek.me.

Signaling multiple media sources is needed to be able to send a video along with screen sharing, multiple camera sources or routing multiple streams from an SFU to the users.

In Plan B, an m= line is an “envelope” that includes multiple media sources per one defined transport.

The mechanism chosen for the official WebRTC specification isn’t Plan B but rather Unified Plan.

Plan B has been deprecated and removed from browsers.

The post Plan B appeared first on BlogGeek.me.

WebRTC stands for Web Real Time Communications. It is at the intersection between the internet and telecommunications.

WebRTC’s main driver is bringing real time communications into the browser, and to the hands of many more developers – enabling a considerable reduction in the barrier of entry for those who need to add communication capabilities to their applications; and a reduction in the level of friction end users face when dealing with communication services.

WebRTC enables sending voice, video and any arbitrary data across browsers in a peer to peer fashion.

WebRTC the specification

WebRTC is a specification that is being defined by two separate standardization organizations – the IETF and W3C.

W3C is “in charge” of the JavaScript API layer for WebRTC as part of HTML5. The latest working draft is available online.

IETF has an active working group with the name Rtcweb which handles the network part of WebRTC – defining what gets communicated over the network.

WebRTC is a “work in progress”. Version 1.0 of the specification hasn’t been released yet, although it is already implemented by Chrome, Firefox and Opera browsers.

WebRTC the project

WebRTC is an open source project released and maintained by Google.

It is an implementation of the WebRTC specification that fits into Google’s Chrome browser. It can be ported to other operating systems and uses as well.

The project is licensed under the permissive BSD license, enabling its commercial use by any organization and individual.

The project is found at webrtc.org.

The post WebRTC appeared first on BlogGeek.me.

This is typically used to send audio and video over the same connection, and allows reducing the number of opened sockets and pinholes that need to be managed and reduces the resources required to get a session work through a firewall or NAT device.

See also rtcp-mux.

The post BUNDLE appeared first on BlogGeek.me.

It is a process whereas RTP and RTCP share the same socket and connection, instead of using two separate connections.

This allows reducing the number of opened sockets and pinholes that need to be managed and reduces the resources required to get a session work through a firewall or NAT device.

While rtcp-mux is common in WebRTC, it is in less common use by other VoIP services and protocols that make use of RTP and RTCP.

See also BUNDLE.

Understanding the basics

In a simplistic, “old fashioned”, video call scenario, multiple ports are necessitated to facilitate the sending and receiving of media. To break it down, a total of four distinct connections are established – two for audio (RTP and RTCP) and two for video (RTP and RTCP). Here’s how it works:

• RTP: This is the channel over which audio and video data are transmitted
• RTCP: Acting as a control channel, RTCP is used alongside RTP to provide feedback on the quality of service being provided

Each media type (audio and video) requires separate RTP and RTCP connections, which are then synchronized using SSRC (Synchronization Source) identifiers and timestamps. The SSRC indicates the originating source of the media, while the timestamps denote when the data is sent from the local device.

The challenge at hand

The requirement of four separate ports for a single video call presents several challenges:

1. Resource Consumption: More connections equate to higher resource utilization, especially on the server-side when dealing with hundreds or thousands of simultaneous connections
2. Setup Time: The setup time increases as each port necessitates its own separate connection setup (full trickle ICE procedure), slowing down the overall process
3. Success Rate: With more connections, the likelihood of a successful setup decreases. If any one of the connections fails, the entire call fails

Transitioning to WebRTC

Before the advent of WebRTC, the default setup involved four connections as described above. However, WebRTC introduced two key mechanisms to optimize this setup:

1. Bundling: This mechanism allows bundling of audio and video over a single RTP connection, with RTCP also being bundled together for both media types. This is signaled over SDP by stating group: BUNDLE
2. RTCP-MUX: Taking it a step further, RTCP-MUX enables the multiplexing of RTCP over RTP. This means using the same connection and port for both RTP and RTCP data of audio and video.

By employing both bundling and RTCP-MUX, it’s possible to have a single connection where all RTP and RTCP data for audio and video are multiplexed, significantly optimizing server resources and setup time.

Embracing RTCP-MUX

RTCP-MUX is not just a theoretical concept but a practical solution to enhance the efficiency of WebRTC connections. By reducing the number of ports and connections required for a video call, RTCP-MUX plays a pivotal role in speeding up the setup time, improving the success rate, and optimizing server resources.

The post rtcp-mux appeared first on BlogGeek.me.

NACK is a way for the receiving end to indicate it hasn’t received a specific packet.

A NACK message is sent over RTCP to the sender of the media, which in turn needs to decide if it will retransmit the lost packet based on its availability in its cache and its estimate to the usefulness of the retransmission (will it be possible to use it once received).

Mechanism of NACK

The mechanism of NACK is straightforward yet crucial for maintaining the quality of the communication link. When a receiver detects the absence of a specific packet, it triggers a NACK message.

This message is then transmitted over RTCP to the sender of the media. The responsibility now lies on the sender to evaluate the request for retransmission.

Decision on Retransmission

Upon receiving a NACK message, the sender has to make a calculated decision regarding the retransmission of the lost packet.

This decision hinges on two primary factors:

1. The availability of the packet in its cache
2. The estimated usefulness of the retransmission

The sender evaluates whether the retransmitted packet, once received, will still hold value for the ongoing communication. If it doesn’t, he won’t retransmit it.

Importance in WebRTC

The implementation of NACK in WebRTC directly impacts the quality and reliability of the real-time communication. It is focused on video streams and a lot less on audio streams.

By providing a mechanism to request for lost packet retransmission, NACK plays a vital role in mitigating the effects of packet loss, thereby enhancing the overall user experience in a WebRTC environment.

The post NACK (Negative Acknowledgement) appeared first on BlogGeek.me.

For voice, the MTI codecs are G.711 and Opus.

For video, the MTI codecs are H.264 and VP8 (web browsers and devices must implement them both, while applications and services can decide which ones to use).

Web browsers are actively adding VP9 support as well, even though it is an optional video codec in WebRTC.

The post MTI (Mandatory To Implement) appeared first on BlogGeek.me.