Real Time Transport Protocol — SRT vs RTP for Live Video

Search for real time transport protocol and you get two different answers wearing almost the same name — which is exactly why the phrase causes so much confusion. So let us settle it in one line before anything else. The Real-time Transport Protocol (RTP) is the protocol that actually carries live audio and video across a network: the packets your voice or your picture travel inside. It is not the same thing as the Real Time Streaming Protocol (RTSP), which is a control channel, not a media carrier. Two protocols, near-identical names, completely different jobs.

This article explains both accurately, clears up the RTP vs RTSP mix-up for good, and shows where each one still earns its keep — and where a protocol like SRT takes over once you leave the managed network behind.

What RTP actually does

RTP is defined in RFC 3550 and almost always runs on top of UDP. Its job is narrow and specific: take a stream of media and wrap each packet with the metadata a receiver needs to rebuild real-time audio or video correctly. Four fields do the heavy lifting.

• Sequence number — so the receiver can detect loss and put packets back in order.
• Timestamp — so playback timing is preserved and audio stays locked to video.
• Payload type — so the receiver knows which codec it is decoding.
• SSRC identifier — so multiple sources in the same session can be told apart.

What RTP deliberately does not do is just as important. It does not guarantee delivery, it does not guarantee in-order arrival, and it does not manage congestion. Because it rides on UDP, a lost packet stays lost unless something above RTP decides to ask for it again. That is a design choice, not an oversight: for a phone call or a video conference, a packet that shows up late is worse than one that never shows up at all. RTP handles media transport; reliability and congestion control are somebody else's problem, on purpose.

RTP travels with RTCP

RTP rarely works alone. It is paired with RTCP, the RTP Control Protocol, which runs on a companion port and carries the telemetry: sender reports, receiver reports, cumulative packet loss, inter-arrival jitter, round-trip estimates. RTCP is how endpoints know a connection is degrading and can react — dropping to a lower bitrate, for instance. Put simply: RTP moves the media, RTCP tells you how the move is going.

Where will you find RTP in the wild? VoIP and SIP telephony, WebRTC (via SRTP, its encrypted profile), video conferencing, and some IPTV. If you have ever been on a browser video call, your media rode RTP.

RTSP — the remote control, not the media

Now the protocol that gets mistaken for it. The Real Time Streaming Protocol (RTSP), defined in RFC 2326, is a control and signaling protocol. The cleanest analogy is a VCR remote, or the transport buttons on a media player: RTSP is how a client tells a streaming server DESCRIBE, SETUP, PLAY, PAUSE, and TEARDOWN. It negotiates the session and drives playback state.

What RTSP does not do is carry the video itself. That job it typically hands to RTP. RTSP is the remote control; RTP is the cable delivering the picture. The two are so often deployed together that people end up using the names interchangeably — which is where the trouble starts.

RTSP's natural home is IP cameras and surveillance. Point VLC or an ONVIF NVR at an rtsp:// URL and you are speaking RTSP to set up the session, then pulling RTP media across it, usually on port 554. Nearly every security camera on the planet works this way.

RTP vs RTSP, finally settled

If you remember nothing else, remember this: they sit on different planes.

• RTP is the data plane — it carries the actual media bits.
• RTSP is the control plane — it starts, stops, and steers the session.
• They frequently work together (RTSP sets up, RTP delivers), which is precisely why they get conflated.
• When someone says the camera streams RTSP, what they almost always mean is an RTSP-negotiated session delivering RTP media.

RTSP is the remote; RTP is the signal on the wire. One tells the stream what to do; the other is the stream.

Both were built for managed networks

Here is the context that explains everything. RTP and RTSP were designed for a particular world: LANs and managed IP networks where packet loss was low and you controlled the path end to end. RTP has no built-in reliability. RTSP assumes a cooperative, reachable server. Neither was built to fight its way across the open public internet, with its variable loss, wandering jitter, and NAT/firewalls sitting in the middle of every connection.

On a corporate LAN or a managed IPTV network, that is completely fine — excellent, even. And when the open internet is involved, systems layer extra machinery on top: WebRTC adds ICE for traversal, its own congestion control, SRTP for encryption, and selective retransmission, all wrapped around RTP, precisely because raw RTP over the internet needs help. The protocol was never meant to do that alone.

Leaving the managed network: SRT

When your media genuinely has to cross the public internet — a live contribution feed from a venue, or distribution to partners in other countries — you want the reliability and security that RTP and RTSP leave to other layers built directly into the transport. That is what SRT (Secure Reliable Transport) does.

SRT also runs over UDP, but it adds the pieces the older protocols delegate:

• ARQ error recovery — lost packets are re-requested and re-delivered inside a bounded latency window, so loss gets repaired before the decoder ever sees a glitch.
• AES encryption — negotiated during the handshake from a shared passphrase, end to end.
• Firewall and NAT traversal — caller, listener, and rendezvous connection modes so you can establish a session without opening inbound ports at every site.

Where RTP hands reliability upward and RTSP only controls the session, SRT bakes transport reliability and security into one protocol designed for lossy, uncontrolled links.

To be fair: this is not a story about RTP or RTSP being bad. They are excellent, and ubiquitous, in their domains. WebRTC's real-time magic rides on RTP. Nearly every IP camera speaks RTSP. Vendors like Wowza have published some of the clearest reference and educational material on all of these protocols, and it is worth reading before you commit to a design. Different tools, different jobs — the mistake is reaching for the LAN-era protocol when the problem is the open internet.

RTP vs RTSP vs SRT at a glance

How SRT Cloud fits in

Understanding the transport is one thing; running it for a wall of downstream partners is another. SRT Cloud operationalizes SRT for the distribution end of the chain, and the model is deliberately narrow.

You send one live SRT input. SRT Cloud produces unlimited bit-exact, 1:1 copies and delivers each one to a taker — a downstream destination such as a broadcaster, telco, affiliate, CDN, or satellite operator. There is no transcoding and no re-encoding: every output is frame-for-frame identical to your source. Real takers on the platform today include FreeSat, Pyur, Eutelsat, SES, Etisalat, Swisscom, UIG, and KiwiSat.

Because it is a managed cloud service, there is no hardware to rack, no media server to babysit, and no long-term commitment. Pricing is simply €99 per output per month — one license equals one SRT output — starting with a free trial, and you scale outputs up or down whenever a partner comes or goes.

If your world is phone calls, WebRTC, or cameras on a LAN, RTP and RTSP are the right protocols and always will be. The moment a feed has to leave the managed network and reach many destinations reliably, SRT is the transport — and SRT Cloud is the simplest way to turn one feed into unlimited exact copies.