Ingest is how a contribution feed reaches the platform before it is transcoded and packaged for viewers. The protocol you choose sets your startup latency, loss tolerance, firewall friendliness, and how easily you can run redundant paths. For adult live platforms, where a dropped cam session is lost revenue, ingest reliability matters as much as picture quality.
Protocol comparison
| Protocol | Transport | Latency | Loss handling | Typical use |
|---|---|---|---|---|
| RTMP | TCP | ~2–5s | Retransmits (head-of-line blocking) | Legacy encoders, broad support |
| RTMPS | TLS over TCP | ~2–5s | Same as RTMP, encrypted | Encoders that require TLS |
| SRT | UDP | sub-second to ~2s | ARQ retransmission, jitter buffer | Lossy networks, remote contributors |
| WHIP | HTTP/3 or HTTP/2 (WebRTC) | sub-second | WebRTC congestion control | Browser and modern encoders |
| HLS pull | HTTP | segment-sized | Player-side | Pulling an upstream that already packages |
RTMP/RTMPS remain the compatibility baseline: almost every hardware and software encoder speaks them, and TLS protects the stream key in transit. Their weakness is TCP head-of-line blocking — a single lost packet stalls everything behind it, which is painful on long-haul or congested last miles.
SRT runs over UDP with selective retransmission and a configurable jitter buffer, so it tolerates loss and jitter far better than RTMP. It is the workhorse for remote contributors and unpredictable networks, at the cost of more tuning and a UDP path through firewalls.
WHIP and its RFC 9725 constraints
WHIP (WebRTC-HTTP ingestion protocol) gives WebRTC ingest an HTTP handshake, so browsers and modern encoders can publish without custom signalling. RFC 9725 defines it tightly, and the constraints shape how you deploy it:
- A single POST carries the SDP offer and creates the session; the response carries the answer.
- No renegotiation — the session is fixed once established. Plan encoder settings before connecting.
- 307 redirect — the server may redirect the POST to the node that should terminate the media, letting you front WHIP with a load balancer without breaking the handshake.
- 503 with
Retry-After— when no capacity is available, the server returns 503 and the client retries after the indicated delay. Honour it; do not hammer. ice-serverlink — the response may advertise ICE servers via aLinkheader, so clients discover STUN/TURN without out-of-band configuration.
HLS pull ingest
When an upstream already packages HLS, you can pull its playlist rather than receive a contribution feed. This is simple and firewall-friendly, but it inherits the upstream’s segment latency and gives you no control over its encoding. Use it for restreaming partnerships, not for primary contribution.
Redundant ingest design
A single ingest path is a single point of failure. Build for it:
- Primary and backup ingest endpoints on separate networks or regions, so an encoder failover does not depend on the same path that just failed.
- Regional ingest close to contributors, so long-haul loss is not part of the contribution hop.
- Health-based failover with a defined trigger, and encoders configured to reconnect rather than stall.
- Session continuity so a brief reconnect does not end the stream or orphan viewers.
Stream-key hygiene
The stream key is a credential. Treat it like one:
- Never embed keys in public pages, logs, analytics, or support transcripts.
- Use per-session or short-lived keys where the protocol allows, and rotate on any suspicion of leak.
- Require TLS (RTMPS, HTTPS, WHIP over TLS) so keys are not sent in clear.
- Separate keys per contributor and per platform property so a leak is contained.
- Invalidate on session end, and audit who can read keys.
Where AdultInfra fits
AdultInfra designs redundant ingest for live-cam and adult live platforms — SRT or WHIP for low-latency contribution, RTMPS for compatibility, and primary/backup/regional paths that fail over without dropping the session. Start with Live cam CDN and Live cam site, or contact us to review your ingest topology.