The promise of WebRTC extends far beyond simple one-on-one video chat. In modern cloud applications, WebRTC powers massive multi-party video conferences (with hundreds of interactive participants), real-time peer-to-peer multiplayer gaming, remote desktop rendering, live interactive auctions, and decentralized data mesh networks.
Achieving these capabilities requires mastering three advanced pillars of WebRTC engineering:
- Media Capture & Processing: Fine-grained hardware camera and microphone ingestion via the
MediaStreamAPI and Web Audio processing graphs. - Arbitrary Low-Latency Data Channels: High-throughput, bi-directional binary data pipelines via
RTCDataChannelover SCTP/DTLS. - Multi-Party Scalability (SFU Architecture): Scaling beyond peer-to-peer limits through Selective Forwarding Units (SFUs), Transport-Wide Congestion Control (TWCC), and End-to-End Encrypted (E2EE) insertable streams.
This guide provides an exhaustive, university-grade examination of these core WebRTC technologies, establishing mathematical bandwidth scaling laws, protocol buffer management, and production media server micro-architectures.
Media Acquisition & Audio Processing Pipelines#
WebRTC interacts with client hardware sensors (webcams, studio microphones, screen displays) through the W3C Media Capture and Streams API.
+---------------------------------------------------------------------------------------+
| WebRTC Media Processing Pipeline |
+---------------------------------------------------------------------------------------+
| Microphone Hardware Capture |
| | |
| v |
| [ Acoustic Echo Cancellation (AEC) ] <--- Subtraction of speaker output playback |
| | |
| v |
| [ Noise Suppression (NS) ] <--- Removal of stationary background hiss |
| | |
| v |
| [ Automatic Gain Control (AGC) ] <--- Dynamic normalization of vocal volume |
| | |
| v |
| [ Voice Activity Detection (VAD) ] <--- Gates transmission during silence |
| | |
| v |
| [ Opus Audio Encoder ] <--- Emits compressed SRTP packets |
+---------------------------------------------------------------------------------------+Media Constraints & Hardware Negotiation#
When invoking navigator.mediaDevices.getUserMedia(constraints), developers declare explicit constraints:
const constraints = {
audio: {
echoCancellation: true,
noiseSuppression: true,
autoGainControl: true,
sampleRate: 48000,
channelCount: 2
},
video: {
width: { min: 640, ideal: 1280, max: 1920 },
height: { min: 480, ideal: 720, max: 1080 },
frameRate: { ideal: 30, max: 60 },
facingMode: "user"
}
};
const stream = await navigator.mediaDevices.getUserMedia(constraints);- `ideal` vs. `exact`: The
idealkeyword expresses a soft preference; the browser negotiates with OS hardware drivers to select the nearest supported resolution. Theexactkeyword enforces a strict invariant, throwing anOverconstrainedErrorif the camera hardware cannot satisfy the exact specification. - `MediaStream` & `MediaStreamTrack`: A
MediaStreamis a container synchronization object holding one or moreMediaStreamTrackobjects (e.g., one audio track, one video track). Tracks can be individually muted (track.enabled = false), stopped to release hardware indicators (track.stop()), or cloned.
Real-Time Arbitrary Data Transport: `RTCDataChannel`#
While audio and video flow over SRTP, WebRTC provides the RTCDataChannel interface for bidirectional transport of arbitrary text, JSON, binary ArrayBuffers, and Blobs.
The Protocol Foundation: SCTP over DTLS#
RTCDataChannel does not run over raw UDP or TCP; it runs on the Stream Control Transmission Protocol (SCTP, RFC 4960 and RFC 8831) encapsulated inside a DTLS tunnel over UDP:
[ Application Data: JSON / ArrayBuffer ]
|
v
[ SCTP (Stream Control Transmission Protocol) ] <-- Multi-streaming, configurable reliability
|
v
[ DTLS (Datagram Transport Layer Security) ] <-- TLS 1.3 cryptographic encryption
|
v
[ ICE / UDP / IP ] <-- Hole-punched network datagramsConfigurable Reliability & Ordering Semantics#
In traditional networking, developers are forced to choose between strict reliability with head-of-line blocking (TCP) or raw unreliability with zero ordering guarantees (UDP). SCTP gives developers granular, per-channel control over reliability and ordering:
// Reliable & Ordered (TCP-like behavior: file transfer, chat)
const chatChannel = pc.createDataChannel("chat", {
ordered: true
});
// Unreliable & Unordered (UDP-like behavior: FPS gaming coordinates)
const positionChannel = pc.createDataChannel("player_coordinates", {
ordered: false,
maxRetransmits: 0
});
// Partially Reliable with Time Ceiling (Sensor telemetry)
const sensorChannel = pc.createDataChannel("telemetry", {
ordered: false,
maxPacketLifeTime: 150 // Discard if unacknowledged after 150 milliseconds
});Buffer Backpressure Management#
When transmitting large files over an RTCDataChannel, calling channel.send(chunk) in a tight loop without flow control will exhaust browser process memory. The browser buffers outgoing data in an internal operating system queue.
Developers must monitor buffer backpressure:
async function sendLargeBinaryFile(channel, arrayBuffer) {
const CHUNK_SIZE = 16384; // 16 KB optimal chunk size
const BUFFER_CEILING = 1048576; // 1 MB high-water mark
channel.bufferedAmountLowThreshold = 262144; // 256 KB low-water mark
let offset = 0;
while (offset < arrayBuffer.byteLength) {
if (channel.bufferedAmount > BUFFER_CEILING) {
// Pause sending and wait for OS queue to drain
await new Promise(resolve => {
channel.onbufferedamountlow = () => {
channel.onbufferedamountlow = null;
resolve();
};
});
}
const chunk = arrayBuffer.slice(offset, offset + CHUNK_SIZE);
channel.send(chunk);
offset += CHUNK_SIZE;
}
}Multi-Party Conference Topologies: Mesh, MCU, and SFU#
When transitioning from 2-party calls to multi-party conferences (N ≥ 3 participants), the system architecture must choose between three distinct network topologies:
+---------------------------------------------------------------------------------------------------+
| Multi-Party Architecture Taxonomy |
+-----------------------------------+-----------------------------------+---------------------------+
| Topology 1: Full Mesh (P2P) | Topology 2: MCU (Mixing Server) | Topology 3: SFU (Routing) |
+-----------------------------------+-----------------------------------+---------------------------+
| - N(N - 1) / 2 P2P direct links | - Central transcoding server | - Central routing server |
| - Zero server infrastructure cost | - High server CPU/GPU cost | - Low server CPU cost |
| - Client upload: O(N) | - Client upload: O(1) | - Client upload: O(1) |
| - Client download: O(N) | - Client download: O(1) | - Client download: O(N) |
| - Max participants: ~4 to 5 | - Max participants: ~50 | - Max participants: 1000+ |
+-----------------------------------+-----------------------------------+---------------------------+1. Full Mesh (P2P): 2. MCU (Mixing Gateway): 3. SFU (Routing Gateway):
[A] <=====> [B] [A] [B] [A] [B]
\\ \ / // \ / \ /
\\ X // v v v v
[C] <-> [D] [ MCU Mixer ] [ SFU Router ]
(Decodes & Encodes) (Zero Transcoding)
/ \ / \
v v v v
[C] [D] [C] [D]1. Full Mesh (P2P)#
Every participant connects directly to every other participant.
- Failure Mode: At N = 6, each participant must encode and upload 5 separate video streams. A typical home upstream broadband link (e.g., 5 Mbps upload) collapses under the load.
2. Multipoint Control Unit (MCU / Composite Mixing)#
The MCU receives all N video streams, decodes them to uncompressed raw pixel buffers (YUV), arranges them into a composite video grid (e.g., a 2x2 or 3x3 Hollywood grid), re-encodes a single output video stream, and transmits it to participants.
- Advantages: Client upload is 1 stream; client download is 1 stream. Even low-powered mobile phones can participate.
- Fatal Flaws: Massive server CPU and GPU infrastructure costs; heavy transcoding latency (~200 ms added); rigid layout (users cannot rearrange or pin individual cameras locally).
3. Selective Forwarding Unit (SFU / Intelligent Routing)#
The SFU represents the modern standard for video conferencing (powering Zoom, Google Meet, Microsoft Teams, Discord, and LiveKit).
- Zero Transcoding: The SFU acts as a high-throughput, application-layer packet router. It does not decode or re-encode video.
- Selective Forwarding: It receives 1 upstream from each publisher, inspects packet headers, and forwards copies of the packets to receivers.
- Combined with Simulcast or SVC, the SFU forwards low-resolution layers to bandwidth-constrained mobile clients and high-resolution layers to desktop participants.
Congestion Control & RTCP Feedback Loops#
Real-world Internet bandwidth fluctuates wildly due to Wi-Fi interference, cellular fading, and competing home downloads. WebRTC engines continuously dynamically adapt video bitrate, framerate, and resolution to prevent packet loss.
Key RTCP Feedback Messages#
- NACK (Negative Acknowledgement, RFC 4585): The receiver detects a gap in RTP sequence numbers (e.g., received packets 101, 102, 104) and transmits an immediate NACK requesting retransmission of packet 103 from the sender's jitter buffer.
- PLI (Picture Loss Indication): When packet loss corrupts a key video reference frame, rendering subsequent delta frames undecodable, the receiver sends a PLI requesting the encoder to generate an immediate I-frame (keyframe).
- FIR (Full Intra Request): Similar to PLI, used when a new participant joins an SFU room and needs an immediate keyframe to start decoding.
Transport-Wide Congestion Control (TWCC, RFC 8888)#
Legacy congestion control (REMB) relied on the receiver estimating bandwidth and reporting a recommended bitrate. Modern WebRTC implements Transport-Wide Congestion Control (TWCC):
+---------------------------------------------------------------------------------------+
| Transport-Wide Congestion Control Flow |
+---------------------------------------------------------------------------------------+
| Sender (Publisher) Receiver (SFU / Peer) |
| | | |
| | 1. Transmit RTP packets with Transport Sequence Number | |
| | (Header Extension: seq=4821, seq=4822, ...) | |
| +------------------------------------------------------------->| |
| | |
| 2. Record exact arrival time |
| T_arrive for every packet |
| | |
| |<--- 3. Periodic TWCC RTCP Feedback Packet -------------------+ |
| | (Maps: seq -> arrival timestamp delta) |
| v |
| 4. Google Congestion Control (GCC) Engine computes Delay Gradient |
| - Inter-arrival delta > Inter-departure delta ===> Queues building (Back off!) |
| - Dynamically throttles video encoder bitrate! |
| |
+---------------------------------------------------------------------------------------+By analyzing whether the inter-packet arrival delta exceeds the departure delta, the sender detects queue buildup in intermediate network routers before packet loss occurs, seamlessly throttling encoder bitrate to match physical pipe capacity.
End-to-End Encryption (E2EE) in SFUs: Insertable Streams & SFrame#
Because an SFU inspects RTP headers to route packets, standard WebRTC terminates DTLS-SRTP at the SFU. Consequently, the SFU server operator technically has access to decrypt raw media payloads.
To guarantee zero-trust privacy in cloud-hosted SFUs, the IETF standardized SFrame (Secure Frame) implemented in browsers via WebRTC Insertable Streams (Encoded Transform API).
+---------------------------------------------------------------------------------------+
| SFrame E2EE Transform Pipeline |
+---------------------------------------------------------------------------------------+
| Publisher Browser: |
| Camera ---> [ Video Encoder ] ---> Raw Encoded Frame |
| | |
| v |
| [ SFrame TransformStream ]: Encrypts frame payload with End-to-End Shared Key |
| | |
| v |
| [ Standard WebRTC DTLS/SRTP ]: Encrypts packet for Hop-by-Hop transport to SFU |
| | |
| v |
| SFU Cloud Server: |
| Decrypts Hop-by-Hop DTLS/SRTP ---> Reads RTP Headers (Route to Receiver) |
| Payload remains 100% SFrame Encrypted (SFU CANNOT READ MEDIA!) |
| | |
| v |
| Receiver Browser: |
| Decrypts Hop-by-Hop DTLS/SRTP ---> [ SFrame Decryptor ] ---> Video Decoder ---> Display
+---------------------------------------------------------------------------------------+Insertable Streams insert a Web Streams TransformStream pipeline directly between the video encoder and the packetizer:
- The publisher encrypts raw encoded H.264/VP8 frames using an E2EE room key.
- The SFU routes packets based on plaintext RTP headers, but the frame payload remains cryptographically opaque.
- The receiver decrypts the SFrame payload using the E2EE key prior to passing frames to the hardware decoder.
In-Browser AI & Custom Processing: WebAssembly & WebGL#
In modern telecommunications applications, users expect advanced real-time computational video and audio augmentations:
- Real-Time Virtual Backgrounds & Segmentation: Segmenting human silhouettes and replacing background pixels with 1080p images or blurs.
- AI Noise Suppression: Neural network models (e.g., DeepFilterNet, RNNoise) removing barking dogs, vacuum cleaners, and mechanical keyboard clicks in real-time.
- Real-Time Facial Landmark Tracking: AR filters, avatar animation, and eye-contact correction.
The MediaStream Processing Architecture#
WebRTC integrates with WebAssembly (Wasm) and Web Workers via MediaStreamTrackProcessor and MediaStreamTrackGenerator (Insertable Streams for Media):
+---------------------------------------------------------------------------------------+
| WebAssembly In-Flight Frame Processing |
+---------------------------------------------------------------------------------------+
| Camera Feed ---> [ MediaStreamTrackProcessor ] |
| | |
| v Emits VideoFrame Objects |
| [ Dedicated Web Worker ] |
| | |
| v Zero-Copy Transfer |
| [ Wasm Neural Network / WebGPU ] |
| (Inferences Segmentation Mask @ 30 FPS) |
| | |
| v Emits Modified VideoFrame |
| [ MediaStreamTrackGenerator ] ---> Ingested by RTCPeerConnection |
+---------------------------------------------------------------------------------------+By offloading tensor execution to WebGPU and WebAssembly SIMD inside background Web Workers, the browser executes real-time AI transformations with sub-10 millisecond latency without blocking the primary UI rendering thread.
Open-Source SFU Engine Architectures: LiveKit vs. Mediasoup vs. Pion#
Building production-grade video infrastructure requires selecting an open-source Selective Forwarding Unit (SFU) architecture that matches organizational scalability requirements:
+----------------------------------------------------------------------------------------------------+
| Production SFU Architecture Comparison |
+-------------------+----------------------------+------------------------+--------------------------+
| Engine | Language Core | Concurrency Paradigm | Architectural Strength |
+-------------------+----------------------------+------------------------+--------------------------+
| Mediasoup | Node.js control, C++ media | Worker Thread Pool | Minimal latency, microVM |
| LiveKit | Go (Pion WebRTC) | Goroutine per peer | Complete ecosystem, E2EE |
| Janus Gateway | C (Glib) | POSIX Threads / Plugins| Telco SIP/PSTN legacy |
| Pion | Pure Go | Native Go runtime | Embeddable library |
+-------------------+----------------------------+------------------------+--------------------------+Mediasoup: The Worker Multi-Process Model#
Mediasoup separates high-level room orchestration logic from the low-level media packet routing engine:
- Node.js Orchestration Layer: Manages rooms, users, signaling state, and permissions.
- C++ Worker Processes: Spawns multiple single-threaded C++ worker daemons (one per CPU core) communicating over Unix Domain Sockets. Each C++ worker executes epoll packet loops, achieving line-rate UDP packet forwarding (> 500,000 packets per second per core) with zero garbage collection pauses.
LiveKit: Distributed Cloud-Native Infrastructure#
LiveKit builds upon the pure-Go Pion WebRTC stack:
- Distributed Room Mesh: Seamlessly clusters across multiple Kubernetes nodes using Redis pub/sub. If a room has 500 participants, publisher streams are bridged across nodes over internal high-speed gRPC meshes.
- Integrated Telemetry & Ingress: Includes native support for RTMP/WHIP ingestion (streaming from OBS Studio into WebRTC rooms) and automated cloud egress recording to MP4/HLS.
The Future of Real-Time Web: WebTransport & WebCodecs#
While WebRTC remains the undisputed sovereign standard for interactive peer-to-peer audio and video communication, the W3C and IETF are standardizing WebTransport and WebCodecs to provide lower-level, modular networking primitives:
- WebCodecs API: Grants JavaScript direct low-level access to the browser's underlying hardware video encoders and decoders (
VideoEncoder,VideoDecoder,AudioEncoder), bypassing the rigidRTCPeerConnectionencapsulation. - WebTransport API: A client-server protocol built natively on HTTP/3 and QUIC:
* Supports multiplexed bidirectional reliable streams.
Supports ultra-fast unreliable datagrams* with native TLS 1.3 encryption and built-in congestion control.
* Eliminates the complexity of SDP Offer/Answer negotiation and ICE candidate harvesting for pure client-server real-time gaming and cloud graphics streaming.
Multi-Region SFU Cascading & Active Speaker Detection#
In global enterprise town halls (e.g., an all-hands meeting with 1,000 attendees scattered across London, New York, Tokyo, and Sydney), hosting all participants on a single central SFU in one region causes massive transatlantic latency and bandwidth bottlenecks.
1. Geo-Distributed SFU Cascading#
Modern architectures deploy Cascaded SFU Clusters:
- Edge Ingestion: A speaker in London connects to an edge SFU in Frankfurt (
eu-central-1). - Inter-Region Backbone Mesh: The Frankfurt SFU forwards a single high-speed copy of the publisher's stream across a dedicated cloud fiber backbone (e.g., AWS Direct Connect or Google Cloud Interconnect) to regional SFUs in Virginia, Tokyo, and Sydney.
- Regional Local Fan-Out: The Tokyo SFU duplicates the stream locally to 300 Asian attendees, eliminating 299 redundant trans-Pacific streams.
+---------------------------------------------------------------------------------------+
| Cascaded Global SFU Mesh |
+---------------------------------------------------------------------------------------+
| Publisher (London) ---> [ Frankfurt SFU Edge Node ] |
| | |
| Dedicated Cloud Backbone Link |
| | |
| v |
| [ Tokyo SFU Regional Node ] |
| / | \ \ |
| v v v v |
| [Peer 1] [Peer 2] [Peer 3] ... [Peer 300] |
| |
+---------------------------------------------------------------------------------------+2. Active Speaker Detection & Dynamic Subscription#
In a 100-person video meeting, users only look at the person actively speaking and a handful of recent speakers.
- Audio-Level RTP Header Extensions (RFC 6464): Publishers embed client-side audio volume levels directly in RTP packet headers:
```
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
```
- Instantaneous Energy Detection: The SFU inspects audio levels without decrypting Opus audio payloads, updating an exponential moving average (EMA) energy score for each participant.
- Dynamic Video Tiering: The SFU automatically upgrades the active speaker's video to 1080p, while simultaneously throttling non-speaking participants to 180p thumbnails or pausing their video transmission entirely (
sendrecv -> inactive), reducing total room bandwidth consumption by up to 85%.
Checkpoint Practice Problems#
Problem 1 (Multi-Party Architecture Scaling Comparison): A video conference has N = 10 participants. Each user publishes an HD video stream at B = 2.5 Mbps and consumes video from all other participants.
- Under Architecture 1 (Full P2P Mesh): Each user connects to all N - 1 peers.
- Under Architecture 2 (MCU Mixing Gateway): Server decodes all 10 streams, composites a single grid, and sends 1 mixed stream (3.0 Mbps) to each user.
- Under Architecture 3 (Selective Forwarding Unit - SFU): Each user sends 1 stream to the SFU, and downloads N - 1 independent streams from the SFU.
Calculate:
- The upload bandwidth requirement on a single client's home internet connection under Mesh, MCU, and SFU.
- The download bandwidth requirement on a single client's connection under Mesh, MCU, and SFU.
- The total server egress network bandwidth consumed across the entire cloud cluster under Mesh, MCU, and SFU.
Solution:
- Client Upload Bandwidth:
* Full Mesh: Upload = (N - 1) · B = 9 · 2.5 Mbps = 22.5 Mbps. (Exceeds typical home cable upload!).
* MCU: Upload = 1 · B = 2.5 Mbps.
* SFU: Upload = 1 · B = 2.5 Mbps.
- Client Download Bandwidth:
* Full Mesh: Download = (N - 1) · B = 9 · 2.5 Mbps = 22.5 Mbps.
* MCU: Download = 1 · Mixed_Stream = 3.0 Mbps.
* SFU: Download = (N - 1) · B = 9 · 2.5 Mbps = 22.5 Mbps.
- Total Server Egress Bandwidth:
* Full Mesh: Server Egress = 0 Mbps (P2P direct; zero server bandwidth).
* MCU: Transmits 1 mixed stream (3.0 Mbps) to all N = 10 users:
Server Egress = 10 · 3.0 Mbps = 30.0 Mbps.
* SFU: Re-transmits each of the 10 streams to N - 1 = 9 receivers:
Server Egress = 10 publishers · 9 receivers · 2.5 Mbps = 225.0 Mbps.
Problem 2 (RTCDataChannel Buffer Flow Control Calculation): A developer is streaming an uncompressed sensor log file of total size S = 64 Megabytes (67,108,864 bytes) over an RTCDataChannel.
- Chunk size:
CHUNK_SIZE = 16,384 bytes (16 KB). - Underlying network uplink throughput:
Uplink = 8.0 Mbps = 1,000,000 bytes/sec (1.0 MB/s). - Channel buffer threshold:
bufferedAmountLowThreshold = 256 KB (262,144 bytes). - Buffer ceiling limit:
BUFFER_CEILING = 1,048,576 bytes (1 MB).
- Compute the total count of 16 KB chunks required to transmit the entire file.
- How many chunks can be sent before the buffer reaches the 1 MB ceiling from an empty state?
- How long does the operating system take to drain 1 MB of queued buffer data over the 1.0 MB/s uplink?
- Compute the minimum total transmission duration for the entire 64 MB file.
Solution:
- Compute chunk count:
```
Total Chunks = 67,108,864 bytes / 16,384 bytes/chunk = 4,096 chunks
```
- Chunks to reach ceiling:
```
Chunks to Ceiling = 1,048,576 bytes / 16,384 bytes/chunk = 64 chunks
```
- Drain time for 1 MB buffer:
```
T_drain = 1,048,576 bytes / 1,000,000 bytes/sec ≈ 1.0486 seconds
```
- Total transmission duration:
```
T_total = Total_Bytes / Uplink_Speed
T_total = 67,108,864 bytes / 1,000,000 bytes/sec ≈ 67.11 seconds (~1 minute 7.1 seconds)
```
Problem 3 (TWCC Delay Gradient & Queuing Detection): In Transport-Wide Congestion Control (TWCC), a sender transmits two consecutive packets:
- Packet 1: Departure timestamp
D_1 = 10.0 ms, Arrival timestamp at receiverA_1 = 45.0 ms. - Packet 2: Departure timestamp
D_2 = 25.0 ms, Arrival timestamp at receiverA_2 = 72.0 ms.
The inter-departure time is ΔD = D_2 - D_1.
The inter-arrival time is ΔA = A_2 - A_1.
The Delay Gradient is G = ΔA - ΔD.
- Compute the inter-departure time ΔD.
- Compute the inter-arrival time ΔA.
- Compute the Delay Gradient G.
- Based on the sign of G, determine whether intermediate router queues are building up or draining, and state what action the Google Congestion Control (GCC) engine executes.
Solution:
- Inter-departure delta:
```
ΔD = D_2 - D_1 = 25.0 ms - 10.0 ms = 15.0 ms
```
- Inter-arrival delta:
```
ΔA = A_2 - A_1 = 72.0 ms - 45.0 ms = 27.0 ms
```
- Compute Delay Gradient G:
```
G = ΔA - ΔD = 27.0 ms - 15.0 ms = +12.0 ms
```
- Congestion interpretation:
Since G = +12.0 ms > 0, Packet 2 arrived 12 milliseconds later than expected relative to its departure spacing. This positive delay gradient proves that packets are buffering inside an intermediate router queue.
To prevent impending packet loss and jitter buffer blowout, the Google Congestion Control engine enters the Overuse state and executes an immediate decrease in target video encoder bitrate.
Problem 4 (SFrame E2EE Cryptographic Overhead & MTU Fragmentation): An enterprise WebRTC video client implements SFrame End-to-End Encryption over an SFU architecture:
- Standard network Maximum Transmission Unit (MTU):
1,500 bytes. - Lower-layer protocol headers:
* IPv4: 20 bytes
* UDP: 8 bytes
* SRTP Header & Extensions: 24 bytes
* SRTP Authentication Tag: 10 bytes
- SFrame Header Overhead:
* SFrame Key ID & Counter Header: 6 bytes
* SFrame HMAC / GCM Authentication Tag: 16 bytes
- Compute the total combined byte overhead of all headers (network, SRTP, and SFrame) per packet.
- Compute the maximum usable payload byte size remaining per packet before encountering IP packet fragmentation.
- If an encoded video intra-frame has a compressed size of
42,000 bytes, compute the minimum number of MTU packets required to transmit this single frame.
Solution:
- Combined header overhead:
```
Header_total = 20 (IPv4) + 8 (UDP) + 24 (SRTP) + 10 (SRTP Tag) + 6 (SFrame Hdr) + 16 (SFrame Tag)
Header_total = 84 bytes per packet
```
- Maximum usable payload:
```
Payload_max = MTU - Header_total = 1,500 bytes - 84 bytes = 1,416 bytes
```
Each packet can carry at most 1,416 bytes of encrypted video frame data without exceeding the 1,500-byte MTU.
- Packets required for 42,000-byte frame:
```
Packets = ceil( 42,000 / 1,416 ) = ceil( 29.661 ) = 30 packets
```
The video packetizer will slice the 42 KB intra-frame into 30 discrete MTU packets.