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.

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.

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.

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.

As opposed to HTTP, where only the client can send a request to the server; WebSocket enables each side in the connection to send messages without any need to wait for past responses.

WebSocket starts its life as a specialized HTTP request that validates if the server is capable of supporting WebSocket or not. If the response is positive, then the WebSocket “hijacks” the HTTP connection and turns it into a WebSocket connection.

Since WebSocket isn’t supported by all web servers and web proxies, it is sometimes used in parallel to other messaging mechanisms such as XHR and SSE.

WebSocket can also be used on top of TLS, creating a secured WebSocket connection.

Due to the nature of WebRTC, which requires both ends to be capable of receiving and sending messages at all times, many of the WebRTC services opt for the use of WebSocket as the transport of their signaling protocol.

The post WebSocket appeared first on BlogGeek.me.

QUIC is an experimental protocol by Google that is based on UDP and targeted at improving situations when you need multiple parallel sessions between two entities. This is the situation for virtually every web page on the internet, which usually requires more than a single resource file to be transmitted from the web server to the browser.

QUIC finds WebRTC in Google’s latest roadmap where it announced its intentions to experiment with the use of QUIC as a replacement for SCTP for the data channel transport.

The post QUIC appeared first on BlogGeek.me.

HTTPS uses TLS instead of TCP as its transport mechanism.

Most WebRTC services end up using HTTPS and not HTTP because of the way permissions are handled by web browsers: When a service asks for access to the camera or microphone of the user with WebRTC, the web browser asks the user for permission. This request will occur each time the service is loaded (or the page is refreshed) if the page was loaded using HTTP, but will happen only once and the user’s permissions will be remembered by the web browser if the page was loaded using HTTPS.

The post HTTPS appeared first on BlogGeek.me.