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.

A media frame can be considerably smaller or larger than the MTU size which means we will either be underutilizing the network or fragmenting these frames over multiple network packets.

To properly receive such frames, construct them back and play them, RTP packetizes the media frames, splitting them into multiple packets in a way that makes dealing with packet loss, reordering and other network artifacts manageable.

Packetization is especially important in video codecs, where the frames are usually larger than a single network packet size. Different video codecs have different payload headers to them which indicate how to packetize and depacketize the codec in a specific manner, based on the capabilities and characteristics of the codec.

The post Packetization appeared first on BlogGeek.me.

When data is sent over a network, it must adhere to the maximum transmission unit available. This means that if we are trying to send a chunk of data bigger than the MTU size, it will be fragmented into smaller chunks and sent in multiple packets over the network (or not sent at all).

To efficiently send media over the network in real time, our goal would be not to have the packets we send fragmented by the network or dropped due to too small MTU size, which is why we end up packetizing the media frames prior to sending them.

Different routers and switches in the network may have different MTU size configured in them, so figuring out what is the effective MTU size of a given network communication path can be tricky.

In most networks, it is usually assumed that the MTU size is around the 1,500 bytes mark. The approach WebRTC took here is to set an MTU size of around 1,200 bytes and use it for its packetization calculations (give or take a few bytes). Using this lower value makes sure WebRTC will work well on most network configurations (including scenarios where packets are further wrapped by VPN tunneling bytes or additional layers of encryption).

The post MTU size appeared first on BlogGeek.me.

Probing is one of the techniques used for bandwidth estimation.

Traditional bandwidth estimation mechanisms rely on packet loss and inter-frame delay. When using these techniques for increasing bandwidth, the level of confidence as to how much the bandwidth estimation can grow is low, leading to slow increase in bandwidth estimation even when more capacity is available.

Probing, on the other hand, is used to try and aggressively increase bandwidth estimation while keeping the estimate accurate. It is done by sending dedicated probing packets that can be disregarded without any degradation to media quality.

WebRTC uses this mechanism at the beginning of a session in order to reach bitrates of 2mbps or more within a second or two of starting the session. It also uses this technique throughout the session as needed.

The post Probing appeared first on BlogGeek.me.

You can find the definition and example for it in RFC 4888 section 8.7.

The post FID (Flow Identification) appeared first on BlogGeek.me.

It is defined and used as a header extension in RFC 8852 section 3.2.

RRID, along with MID and RID, are used to associate between low-level RTP concepts like synchronization source (SSRC) and higher-level WebRTC objects such as RtpSender and RtpReceiver.

These identifiers are important to be able to demultiplex RTP bundling, a common mechanism used in WebRTC sessions.

RRID is used specifically to indicate retransmitted packets.

When RTP packets are received, WebRTC needs to decide to which object/stream to associate the incoming packet. This is done using roughly the following decision diagram:

All header extensions used by MID, RID and RRID have the same basic structure and contain an ASCII string with the MID/RID/RRID value in it.

The post RRID (Repaired RTP Stream ID) appeared first on BlogGeek.me.

It is defined and used as a header extension in RFC 8852 section 3.1.

RID, along with MID and RRID, are used to associate between low-level RTP concepts like synchronization source (SSRC) and higher-level WebRTC objects such as RtpSender and RtpReceiver.

These identifiers are important to be able to demultiplex RTP bundling, a common mechanism used in WebRTC sessions.

RID is used specifically to distinguish between different simulcast streams of the same video source.

When RTP packets are received, WebRTC needs to decide to which object/stream to associate the incoming packet. This is done using roughly the following decision diagram:

All header extensions used by MID, RID and RRID have the same basic structure and contain an ASCII string with the MID/RID/RRID value in it.

The post RID (RTP Stream ID) appeared first on BlogGeek.me.

It is defined and used as a header extension in RFC 8843 section 16.2.

MID, along with RID and RRID, are used to associate between low-level RTP concepts like synchronization source (SSRC) and higher-level WebRTC objects such as RtpSender and RtpReceiver.

These identifiers are important to be able to demultiplex RTP bundling, a common mechanism used in WebRTC sessions.

When RTP packets are received, WebRTC needs to decide to which object/stream to associate the incoming packet. This is done using roughly the following decision diagram:

All header extensions used by MID, RID and RRID have the same basic structure and contain an ASCII string with the MID/RID/RRID value in it.

The post MID (Media Identification) appeared first on BlogGeek.me.

It denotes the number of video frames that are either sent or received per second.

We usually refer to FPS also as frame rate.

The post FPS (Frames Per Second) appeared first on BlogGeek.me.

RRTR is supported by WebRTC and can be enabled on a media server for the purpose of providing accurate incoming round trip time values.

The post RRTR appeared first on BlogGeek.me.