Why This Matters

You are about to make four to seven configuration decisions — encoder, protocol, bitrate, audio config, buffer, retransmission budget, backup — that together determine whether your live stream can survive a one-second public-internet hiccup. If you pick the wrong combination, the only signal you will see is the QoE dashboard turning red five minutes into the event, and the only fix you can deploy in flight is "tell the operator to switch encoders". The cost of picking the right combination is one afternoon of reading; the cost of picking the wrong one is the whole event.

The article is also a map of the rest of Block 3. By the end you will know which protocol to read about next: RTMP (article 3.2) if your encoder is a software product like OBS pointed at YouTube or Twitch, SRT (3.3) if you contribute from a remote venue over the public internet, WHIP (3.5) if you ingest from a browser, RIST or ST 2110 (3.4 / 3.7) if you run a broadcast-grade facility, and the decision tree (3.8) if you are picking one for the first time.

What "Ingest" Actually Means

The word the broadcast industry uses is contribution. The word the cloud-streaming industry uses is ingest. They describe the same hop: the path from the camera or encoder (the source) to the first server you control (the ingest endpoint, contribution server, or origin). Everything past that server — transcoding, packaging, CDN distribution, player playback — is delivery, and is the subject of Block 4 of this section.

The ingest hop is short in geography (often a few hundred kilometres from a venue to a regional ingest server) but long in fragility. The encoder has one network interface card, one route to the public internet, and one ingest URL. If any link in that single path fails — the venue's uplink saturates, a transit provider deprioritises the encoder's traffic, the ingest server in Frankfurt is briefly unreachable — your live event has a hole in it that no CDN can paper over. The hole is upstream of every multiplication factor your distribution stack offers.

A useful frame is the asymmetry of redundancy. On the delivery side, one origin feeds two shield tiers feeds dozens of mid-tier caches feeds hundreds of edges feeds millions of viewers. On the ingest side, one encoder feeds one or two ingest endpoints, and almost every product runs only one encoder per camera. The numbers run in the opposite direction; the failure modes run in the opposite direction too.

Diagram showing the asymmetry between the ingest leg and the delivery leg of a streaming pipeline. Left side: a single camera and a single encoder send one stream over one public-internet path to one ingest endpoint, labelled the riskiest hop. Right side: the same stream fans out from the ingest server through one origin, two shield caches, four mid-tier caches, twelve edge caches, and out to millions of viewers, illustrating the multiplicative redundancy of delivery. A note below highlights that delivery has hundreds of redundant paths while ingest typically has one. Figure 1. The structural asymmetry that makes the ingest leg the highest-risk hop in a streaming pipeline. The delivery side fans out into hundreds of redundant paths; the ingest side typically lives on a single uplink and a single ingest endpoint.

Why Ingest Fails More Than Delivery

Four factors push the failure rate of the ingest leg above that of any other hop in the pipeline.

One uplink, one route, no fail-around. The encoder in a venue has one — sometimes two — uplinks to the public internet. If the primary uplink saturates, drops packets, or goes down, the encoder has no equivalent of the CDN's any-cast routing. The only fallback is a second encoder on a second uplink, which most products do not run.

One ingest endpoint per stream. RTMP is single-endpoint by design; SRT and WHIP also bind one session to one URL. Multi-region ingest is possible (push the same stream to two ingest endpoints in different regions and let the origin pick the better one) but it doubles the upload bitrate and is not the default in any common encoder. Until the second endpoint is configured, the single ingest URL is a single point of failure.

Public-internet path, no SLA. The bytes leave the venue and traverse a sequence of transit providers, peering points, and the ingest provider's network. Any one of them can experience a 200-ms latency spike or a 2% packet-loss event without warning. Inside a CDN the equivalent path is short and instrumented; on the ingest leg the equivalent path is long, unmeasured, and out of your control.

Encoder configuration is human. The encoder's bitrate, keyframe interval, audio codec, ingest URL, and stream key are typed in by an operator at the venue, sometimes minutes before the event. A typo, a stale stream key, a misconfigured audio sample rate, an output bitrate that exceeds the uplink — every one of these has caused a stream to fail in the first minute. Delivery has no equivalent human-in-the-loop step.

The math out loud. Assume your CDN edge has a 99.95% per-hour availability and your origin has 99.9%. Assume your venue's uplink has 99.5% (a generous number for non-redundant business broadband over a one-hour live window) and your ingest endpoint has 99.95%. The end-to-end availability is the product: 0.9995 × 0.999 × 0.995 × 0.9995 = 0.9933, or 99.33% — roughly 40 seconds of outage per hour of live time, almost all of it on the ingest leg. The CDN math is impressive; the ingest math is the math that actually shows up in your QoE dashboard.

The Four Protocol Families You Actually Encounter

Almost every live ingest in production in 2026 uses one of four protocol families. The differences between them are not academic — each makes a different trade between latency, reliability, encoder support, and operational complexity. The deep dives in 3.2–3.7 cover each in detail; this section is the orientation.

RTMP — Real-Time Messaging Protocol. Adobe's TCP-based protocol from 2002, formally published in 2012, and never standardised by an IETF working group. RTMP is the universal default of the encoder ecosystem: OBS Studio, vMix, Wirecast, Larix, every hardware encoder from Blackmagic to Teradek, and every consumer streaming platform from YouTube and Twitch to TikTok and Kick accept RTMP ingest. Its weakness is TCP under packet loss: a 2% loss event on the contribution path causes TCP's congestion control to halve the send rate, which on a 6 Mbps stream means the encoder cannot keep the buffer full and the stream stalls. RTMP is alive and well as the universal default for studio-grade or office-uplink contribution; it dies the moment the contribution path becomes lossy. (Full deep dive: article 3.2.)

SRT — Secure Reliable Transport. Haivision's open-source UDP-based protocol from 2017, now an IETF Internet-Draft (draft-sharabayko-srt-01 for SRT v1.5). SRT pairs UDP with selective retransmission inside a configurable latency budget: the receiver detects packet loss by sequence-number gaps and asks the sender for just the missing packets, all within a window typically set to 4× the path's round-trip time. SRT recovers from up to roughly 10–25% packet loss with no visible glitch as long as the missing data fits inside the latency budget, and it ships with AES-128/AES-256 encryption built in. SRT is the 2026 standard for field contribution over the public internet — sports rights-holders, news crews, live music venues, remote interviews. (Full deep dive: article 3.3.)

WHIP — WebRTC-HTTP Ingestion Protocol. IETF Standards Track RFC 9725, published March 2025 by the IETF WISH working group. WHIP wraps the WebRTC stack — UDP with congestion control, DTLS-SRTP encryption, the ICE NAT-traversal machinery — in a tiny HTTP signalling layer: an HTTP POST with an SDP offer creates a session, HTTP PATCH carries Trickle ICE candidates, HTTP DELETE tears it down. The result is browser-grade ingest with sub-500-millisecond glass-to-glass latency and no proprietary signalling. WHIP is the protocol that makes "click the browser button, you are now broadcasting" possible. (Full deep dive: article 3.5.)

The broadcast-grade family — RIST, Zixi, SMPTE ST 2110, NDI. Four protocols used inside professional facilities and on dedicated contribution links. RIST (Reliable Internet Stream Transport, SMPTE TR-06-1/2/3) is the SMPTE-standardised open alternative to SRT, with forward-error-correction and ARQ; Zixi is the proprietary equivalent with the broadest deployed footprint in tier-1 broadcasters; SMPTE ST 2110 carries uncompressed video over IP inside a studio LAN; NDI is the studio-LAN protocol for compressed video. These are the protocols you encounter when the source is a broadcast facility, not an OBS instance. (Full deep dives: articles 3.4 and 3.7.)

Bar diagram comparing the four ingest protocol families on five criteria: latency, packet-loss tolerance, encoder support, encryption, and operational complexity. RTMP has medium latency, low packet-loss tolerance, near-universal encoder support, optional encryption via RTMPS, and very simple operations. SRT has low latency, very high packet-loss tolerance, growing encoder support, mandatory built-in AES-128/256 encryption, and medium operational complexity. WHIP has very low latency, medium packet-loss tolerance, browser and growing native encoder support, mandatory DTLS-SRTP encryption, and medium operational complexity. RIST and Zixi have very low latency, very high packet-loss tolerance, broadcast-encoder support, mandatory encryption, and high operational complexity. Figure 2. The four ingest protocol families compared on the five criteria that actually drive the protocol choice. None of the four is universally better; each occupies a different operating point on the latency / reliability / encoder-support surface.

A Worked Example — Picking a Protocol for a Real Event

Imagine you are streaming a 90-minute conference panel from a hotel ballroom to 50,000 viewers worldwide. The contribution side runs on the hotel's 100 Mbps business uplink (shared, unmetered, with a typical evening packet-loss rate around 0.5% and an occasional 3% spike). The encoder is an OBS instance on a venue laptop. The viewers are mostly on Wi-Fi at home.

A naïve pipeline pushes RTMP from OBS to a YouTube ingest URL. It will work — most of the time. The 0.5% baseline packet loss is invisible to TCP; the occasional 3% spike will halve the RTMP send rate for one to three seconds, which an audience watching with a five-second player buffer never notices. This is the default for a reason: RTMP-over-business-uplink is the operational sweet spot for the conference-and-corporate-event vertical.

A more resilient pipeline pushes SRT from OBS to your own ingest endpoint in the same region as the venue, then transcodes and pushes HLS to your CDN. The SRT layer absorbs the 3% spikes with no visible degradation. The trade is operational: you now run an ingest endpoint, a transcoder, and a CDN, where the YouTube pipeline ran none of those. For a 50,000-viewer corporate event, the SRT pipeline is often overbuilt; for a 5,000-viewer paid event where a five-second stall costs you refunds, it is correctly built.

A low-latency pipeline pushes WHIP from a browser-based capture tool to a WebRTC ingest endpoint, then bridges to LL-HLS for the audience. The contribution latency drops to under 500 milliseconds, which matters for an interactive Q&A but not for a passive panel. The trade is encoder choice: you give up OBS for a browser-native tool, and you pay for the WebRTC ingest infrastructure.

Three viable pipelines for one event, each correct under different operational constraints. Block 3 articles 3.2–3.7 unpack the protocol-by-protocol details; article 3.8 packages the choice into a decision tree.

Common Pitfalls

Pitfall 1: testing the ingest leg on the office Wi-Fi. The office uplink is symmetric, low-latency, low-loss, and nothing like the venue Wi-Fi or the remote-correspondent's cellular tether. Always test on a path representative of the production contribution path — and prefer to test on a worse path so you size your retransmission budget conservatively.

Pitfall 2: running one encoder with no backup. A second encoder pushing to a second ingest endpoint is the cheapest redundancy in the entire pipeline, and almost no team runs it. For events where the stream is the product, the second encoder pays for itself the first time the primary fails.

Pitfall 3: setting the SRT latency window too low. SRT recovers lost packets within a configurable latency budget (default 120 ms; recommended 4× the path's round-trip time). A 200-ms window over a 90-ms-RTT path is too tight; the first 3% loss spike that arrives at the wrong moment cannot be recovered in time and the stream stutters. Configure the window to the path, not to the default.

Pitfall 4: ignoring the audio codec. RTMP carries AAC by default and chokes on Opus; some SRT pipelines pass-through whatever codec the encoder produces and break the downstream transcoder. Always confirm the audio codec at both the encoder and the ingest endpoint before showtime.

Pitfall 5: hard-coding the ingest URL inside the encoder. Stream keys rotate, ingest endpoints fail over to backups, and tokens expire. The encoder configuration should pull the ingest URL from a config endpoint that can be updated five minutes before the event without re-deploying the encoder.

Where Fora Soft Fits In

Fora Soft has shipped live-streaming software since 2005, across video conferencing, OTT, telemedicine, e-learning, surveillance, and broadcast workflows. The work the previous section describes — picking a protocol per contribution path, sizing the SRT latency window, building the backup-encoder failover, instrumenting the ingest endpoint for QoE — is the bread-and-butter of a contribution-side engagement. Our telemedicine clients run WHIP-over-WebRTC ingest from clinician laptops; our OTT and e-learning clients run RTMP and SRT contribution from venues; our broadcast clients run RIST or Zixi from contribution links. The protocol changes; the production discipline does not.

What to Read Next

Talk to Us / See Our Work / Download

  • Talk to a streaming engineer — book a 30-minute scoping call to audit your contribution path and pick the right protocol for your venue.
  • See our case studies — live-streaming, OTT, telemedicine, and conferencing projects that run on the ingest stacks described above.
  • Download: Ingest Protocol Selection Cheat Sheet (PDF) — one-page summary of the four protocol families, their operating points, and the configuration parameters that matter for each.

References

  1. IETF RFC 9725 — WebRTC-HTTP Ingestion Protocol (WHIP), S. Murillo, A. Gouaillard, March 2025. The IETF Standards Track specification for HTTP-based WebRTC ingest signalling: POST creates a session with an SDP offer, PATCH carries Trickle ICE candidates, DELETE terminates the session. Updates RFCs 8840 and 8842.
  2. IETF Internet-Draft draft-sharabayko-srt-01 — The SRT Protocol, M. Sharabayko et al., latest revision in the IETF datatracker. The SRT v1.5 protocol specification including handshake, ARQ retransmission, encryption with AES-128/256, and the live and file-transfer modes. Subject to revision before RFC publication.
  3. Adobe RTMP 1.0 Specification, Real-Time Messaging Protocol (RTMP) Specification, Adobe Systems, December 2012, last published revision. The original specification for RTMP including the chunk stream, message format, and handshake. Adobe has not actively maintained the specification since 2012; the protocol's behaviour in 2026 is defined by the Adobe document plus 14 years of FFmpeg, OBS, and CDN-side implementation consensus.
  4. SMPTE TR-06-1, TR-06-2, TR-06-3 — Reliable Internet Stream Transport (RIST), SMPTE. The SMPTE-standardised broadcast-grade ARQ + FEC protocol for contribution over the public internet, published as the RIST Main Profile (TR-06-1), Enhanced Profile (TR-06-2), and Simple Profile (TR-06-3).
  5. W3C WebRTC 1.0: Real-Time Communication Between Browsers, W3C Recommendation, last updated 2025. The W3C specification that defines the browser API surface WHIP builds on, including RTCPeerConnection, DTLS-SRTP transport, and the SDP offer/answer model.
  6. YouTube Live — Live Streaming Ingestion Protocol Comparison, Google for Developers. YouTube's published comparison of RTMP, RTMPS, HLS, DASH-over-CMAF, and WebRTC ingest, with the operational guidance YouTube gives to creators. Tier 4 in the source hierarchy — useful as a snapshot of the protocols a tier-1 platform currently accepts in 2026.
  7. Mux — Which Live Stream Ingest Protocol Is Right for You?, Mux engineering blog. A first-party deployer's comparison of RTMP, SRT, RTSP, and WHIP for ingest; useful for vendor-side guidance on which protocol pairs with which encoder. Tier 3 — Mux engineers are co-editors of LL-HLS and have direct production exposure to all four protocols.
  8. Haivision — SRT Open Source Specification and Reference Implementation, GitHub repository. The reference implementation of SRT, used as the canonical interoperability target; the readme also serves as a user-facing protocol overview while the IETF draft matures.
  9. Wowza — Contribution and Delivery Protocols in Video Streaming Workflows, Wowza engineering blog. Vendor-side framing of the contribution-vs-delivery distinction this article uses; useful as a sanity-check against the Mux framing in reference 7. Tier 4.
  10. Cloudflare — Behind the Scenes of Cloudflare Stream Live, Cloudflare blog, 2024. The Cloudflare-side architecture for RTMP, SRT, and WHIP ingest, including the regional ingest endpoint model and the multi-region origin. Tier 3 — Cloudflare engineers co-author parts of the WHIP work in the IETF WISH WG.

Per §4.3.2, the article follows the controlling IETF and SMPTE specifications on every protocol claim; where vendor descriptions (Mux, Cloudflare, Wowza, Haivision) describe deployment behaviours that differ from the specification, the article flags the divergence. WHIP entered IETF Standards Track as RFC 9725 in March 2025 — earlier articles describing it as a draft predate that publication.