RTP (Real-time Transport Protocol) is an IETF standard that carries timestamped audio and video packets over IP networks for live communication. RTP usually runs over UDP to keep delay low and pairs with RTCP for quality reporting and stream synchronisation. You meet RTP inside WebRTC, SIP-based VoIP and video conferencing stacks.
A telehealth session that drifts out of lip-sync loses patient confidence. A sales demo where audio lags video breaks the conversation. Both failures trace back to transport-layer decisions, and RTP sits at the centre of nearly every real-time media stack.
This article defines the RTP protocol, explains how packets move from encoder to playback, and walks through the header fields, ports and RTCP reports. It then compares RTP in SIP and WebRTC, separates RTP from RTMP and RTSP, and covers the production pitfalls overviews skip.
What is the RTP Protocol?
RTP is defined as a network protocol standardised in RFC 3550 that delivers timestamped audio and video over IP networks, for applications where playback timing matters more than receiving every packet.
RTP works by breaking encoded media into small UDP datagrams and attaching a 12-byte header with sequence numbers and timestamps. Receivers use those fields to reorder arrivals and rebuild smooth playback on a shared media clock.
RTP does not set up sessions, negotiate codecs or recover lost packets on its own. SIP, or a WebRTC app's own signalling channel, handles session setup. Applications add jitter buffers, forward error correction (FEC) and negative acknowledgements (NACK) on top of RTP when networks drop traffic.
RTP is the media transport inside WebRTC (RFC 8834) and SIP-based VoIP. VideoSDK meetings run over WebRTC, so their audio and video travel as RTP packets.
RTP differs from raw UDP in purpose. UDP moves datagrams with no timing meaning; RTP adds the metadata receivers need to synchronise media and detect loss, and its companion, RTCP, reports jitter and round-trip time.
Basics of RTP
RTP gives each media packet an order, a timing reference and a source label, and three features do that work.
Key features of RTP
- Packetisation: RTP carries encoded audio and video in packets small enough to cross the network, each with a payload type that names its format.
- Timestamping: each packet carries the sampling instant of its first byte, so the receiver can play media at the right pace and measure jitter.
- Sequence numbering: the sequence number rises by one per packet, so the receiver can spot loss and restore order.
RTP for audio and video
Audio and video usually travel as separate RTP streams, each with its own source identifier and clock rate. Opus audio timestamps at 48,000 Hz (RFC 7587), while video payload formats use 90,000 Hz (RFC 3551).
How Does RTP Work?
RTP transports media by packetising encoded frames, stamping each packet with timing metadata, and letting receivers rebuild playback through sequence tracking and jitter buffering.
Packetisation and payload types
An encoder outputs compressed audio (Opus, G.711) or video (H.264, VP8) frames. The RTP sender splits large frames into packets that fit the network's maximum transmission unit (MTU). It sets a payload type (PT) that tells the receiver which codec to apply, and a sequence number that lets the receiver detect gaps.
Timestamps and synchronisation
Receivers map timestamp differences to playback intervals. Because each stream's clock starts at a random offset, RTCP sender reports publish the mapping between RTP timestamps and wall-clock (NTP) time. That mapping is how endpoints keep audio and video aligned and correct drift during long calls.
The sender-receiver model
The sender emits RTP packets continuously without waiting for acknowledgements. The receiver holds packets briefly in a jitter buffer so playback stays smooth when network delay fluctuates. Packets that arrive too late are discarded rather than stalling the stream, which puts conversational delay ahead of perfect completeness.
Teams keep jitter buffers for interactive video as short as the network allows, because every held packet adds mouth-to-ear delay, the budget ITU-T Recommendation G.114 sets limits for.
RTP packet header: what each field does
Every RTP packet starts with a 12-byte fixed header, defined in RFC 3550 section 5.1, followed by optional contributing-source IDs and an optional extension.
| Field | Size | What it does |
|---|---|---|
| Version (V) | 2 bits | Always 2 for the RTP defined in RFC 3550 |
| Padding (P) | 1 bit | Signals padding bytes at the end, which some encryption algorithms need |
| Extension (X) | 1 bit | Signals that one header extension follows the fixed header |
| CSRC count (CC) | 4 bits | Number of CSRC identifiers that follow, up to 15 |
| Marker (M) | 1 bit | Flags an event such as a frame boundary, as the profile defines |
| Payload type (PT) | 7 bits | Identifies the media format, from a static table or a dynamic value set in signalling |
| Sequence number | 16 bits | Rises by one per packet, so receivers detect loss and restore order |
| Timestamp | 32 bits | Sampling instant of the first byte, on the media's own clock |
| SSRC | 32 bits | Random identifier for the stream's source, unique within the session |
| CSRC list | 0 to 15 items, 32 bits each | Sources a mixer combined into this packet |
Sequence numbers and timestamps start at random values, to make known-plaintext attacks on encryption harder. Payload types 96 to 127 are reserved for dynamic assignment (RFC 3551), so the same codec can carry a different PT number in each session. Static types remain for older codecs: PCMU (G.711 µ-law) is PT 0 and PCMA is PT 8.
RTP ports and RTCP
The RTP protocol port isn't fixed; RFC 3550 pairs an even UDP port for RTP with the next odd port for RTCP.
RFC 3551 registered 5004 and 5005 as an optional default pair, but applications usually pick ports per session and announce them in SDP. WebRTC goes further: RFC 8834 requires support for carrying RTP and RTCP on a single port (RFC 5761), which cuts the NAT bindings and firewall ports a call needs.
VideoSDK's media servers use UDP ports 40000 to 60000, falling back to TCP on the same range. TURN uses port 3478, falling back to TCP 443 (VideoSDK firewall setup guide).
What RTCP reports carry
RTCP, the RTP Control Protocol, sends periodic reports alongside the media, and RFC 3550 recommends limiting it to 5% of the session bandwidth. Sender reports pair an RTP timestamp with NTP wall-clock time and count the packets and bytes sent. Receiver reports carry, for each source:
- the fraction of packets lost since the last report, and the cumulative number lost
- interarrival jitter, measured in timestamp units
- the last sender report timestamp and the delay since it, which let the sender work out round-trip time
VideoSDK's getVideoStats() and getAudioStats() return jitter, packetsLost and rtt for each participant, the same measures an RTCP receiver report carries. See what jitter is for its effect on calls.
Real-time Transport Protocol in Video Streaming
RTP suits live video when delay matters more than perfect delivery, and it carries the media under RTSP camera feeds and WebRTC broadcasts.
RTP has no retransmission of its own, so a stream keeps moving when a packet goes missing. That's why RTSP sessions, which typically deliver media over RTP (RFC 7826), and WebRTC-based interactive streams both use it. Large-audience HLS and DASH streaming works differently, switching between pre-encoded HTTP segments; that adaptive bitrate streaming isn't an RTP feature.
RTP streams adapt another way. RTCP feedback tells the sender about loss and delay, and congestion control lowers or raises the encoder's bitrate. In WebRTC group calls, simulcast adds a second lever: each sender publishes several RTP streams at different resolutions, and a media server forwards each viewer the one their connection can take. The guide to bitrate in WebRTC covers those settings in VideoSDK.
Significance of RTP in Video Conferencing
In a video conference, RTP carries every participant's audio and video, and its sequence numbers and timestamps drive loss recovery and lip-sync.
Lip-sync depends on RTP and RTCP together: the RTP-to-NTP mapping in each RTCP sender report lets the receiver match a spoken word to the lip movement.
Packet loss and jitter are handled around RTP rather than inside it. Sequence numbers reveal what's missing, and the receiver chooses a response. It can ask for a retransmission with an RTCP NACK (RFC 4585), rebuild the data from forward error correction such as Opus in-band FEC, or conceal the gap. A jitter buffer absorbs uneven arrival times, and RTCP receiver reports tell the sender to slow down when loss climbs.
RTP in SIP calls vs RTP in WebRTC
SIP phones and WebRTC browsers both send media as RTP, but they differ in how sessions are negotiated, secured and routed through NATs.
| RTP in SIP calls | RTP in WebRTC | |
|---|---|---|
| Session setup | SDP offer/answer inside SIP messages (RFC 3261) | SDP offer/answer over the app's own signalling channel (RFC 8829) |
| Encryption | Optional: SIP (2002) predates SRTP (2004), so each deployment chooses RTP or SRTP | SRTP with DTLS-SRTP keying is mandatory; plain RTP is forbidden (RFC 8827) |
| NAT traversal | Not part of RFC 3261; added per deployment | ICE is required (RFC 8835) |
| RTP and RTCP ports | An even/odd port pair by default | One multiplexed port (RFC 8834) |
| Mandatory codecs | None in RFC 3261; each call negotiates | Opus and G.711 audio (RFC 7874), VP8 and H.264 video (RFC 7742) |
VideoSDK bridges the two. Its SIP connect integration and telephony gateways route calls from providers such as Twilio into WebRTC meetings, so phone callers and app users share a room.
SIP signalling to VideoSDK uses ports 5060 (TCP or UDP) and 5061 (TLS). Turning on a gateway's Media Encryption setting switches that signalling to TLS and the audio to SRTP, per the secure SIP docs.
RTP vs RTMP vs RTSP
RTP, RTMP and RTSP sound alike but do different jobs: RTP carries media, RTSP controls a media session, and RTMP pushes a stream over TCP.
| Protocol | What it does | Transport and default port | Where you meet it |
|---|---|---|---|
| RTP | Carries timestamped audio and video packets | Usually UDP; ports set per session | WebRTC, SIP calls, camera feeds |
| RTSP | Sets up and controls media delivery; the media usually flows over RTP | TCP port 554 (RFC 7826) | IP cameras and surveillance |
| RTMP | Adobe's protocol for multiplexing and packetising a stream over a persistent connection | TCP, usually port 1935 | Pushing live streams from an encoder to a platform |
The UDP versus TCP split explains most of the table. A late packet is worthless in a live call, so RTP usually rides on UDP, while TCP retransmits until every byte arrives, which suits RTMP's job of ingest. See WebRTC vs RTMP for more.
How VideoSDK uses RTP in video calls
VideoSDK meetings run over WebRTC, so every camera, microphone and screen-share track travels as RTP, encrypted as SRTP, between each participant and VideoSDK's media servers.
You don't build RTP packets yourself. The SDK's WebRTC layer handles packetisation, RTCP feedback and SRTP keying. You shape the media through track settings:
- Codec:
createCameraVideoTrack()encodes with VP8 by default, or with H264, VP9 or AV1, which sets the payload format each RTP stream carries. The video codecs guide compares them. - Simulcast: with
multiStreamon, a camera publishes several RTP streams at different resolutions so each participant receives one that fits their bandwidth. VP9 and AV1 don't supportmultiStream. - Monitoring:
getVideoStats()andgetAudioStats()report jitter, packet loss and round-trip time for each participant.
Phone callers joining through VideoSDK's SIP gateways send RTP too, so one room can mix both kinds of endpoint.
Best Practices for Implementing RTP
RTP works best when the codec, the network path and the loss-recovery tools are chosen together.
Ensuring optimal performance
- Network path: open UDP for media where you can. TCP fallbacks and TURN relays keep calls connecting on locked-down networks, but TCP adds delay under loss and a relay adds a hop.
- Codec selection: balance compression efficiency against CPU. Opus, VP8 and H.264 are safe defaults because every WebRTC endpoint must support them.
Mitigating latency issues
- Real-time monitoring: watch jitter, packet loss and round-trip time from RTCP-based stats, not just whether the connection is up.
- Packet loss recovery: combine NACK retransmission, FEC and concealment. A retransmission helps only if it arrives before the packet's playout time.
- Jitter buffer sizing: size the buffer to the jitter you measure, not to a fixed worst case.
Secure RTP (SRTP)
Plain RTP sends media unencrypted, so production calls use SRTP, the Secure Real-time Transport Protocol defined in RFC 3711 (March 2004).
SRTP adds confidentiality, message authentication and replay protection to RTP, and SRTCP does the same for RTCP. WebRTC makes it mandatory, with keys exchanged over DTLS-SRTP, while SIP systems turn it on per trunk or gateway. SRTP protects media in transit, hop by hop: a media server that forwards a stream decrypts it and re-encrypts it for each receiver. The SRTP guide covers key exchange and ciphers.
Future Trends in RTP and Video Communication
RTP itself changes slowly; the work now happens in the standards built around it.
- WebRTC: browser media runs on RTP through WebRTC, specified in the IETF's RFC 8825 series (January 2021) and a W3C Recommendation (current version 13 March 2025).
- RTP over QUIC: the IETF RTP over QUIC (RoQ) draft maps RTP and RTCP onto QUIC. As of September 2026 it's still an Internet-Draft in working group last call, not an RFC.
Definitions glossary
SSRC: The 32-bit synchronisation source identifier that labels one RTP stream within a session. With VideoSDK's multiStream on, each simulcast layer a camera publishes travels as its own RTP stream with its own SSRC.Payload type: The 7-bit header field that tells a receiver which media format a packet carries. VideoSDK video defaults to VP8, which WebRTC signals with a dynamic payload type between 96 and 127.
SRTP: The Secure Real-time Transport Protocol (RFC 3711), which encrypts and authenticates RTP and RTCP. VideoSDK's WebRTC meetings always use SRTP, and its SIP gateways use it when Media Encryption is enabled.
Key takeaways
- RTP carries timestamped, sequenced audio and video over IP, usually UDP, and leaves session setup to SIP or WebRTC signalling.
- Every RTP packet has a 12-byte fixed header with version, payload type, sequence number, timestamp and SSRC fields, defined in RFC 3550.
- RTCP reports loss, jitter and timing alongside RTP, and WebRTC multiplexes both on one port.
- WebRTC requires SRTP for all media, while SIP deployments choose between plain RTP and SRTP.
- VideoSDK meetings carry media as SRTP over WebRTC, and
getVideoStats()reports jitter, loss and round-trip time.
Conclusion
The RTP protocol is small by design: a 12-byte header, a companion control channel and profiles that SIP phones and WebRTC browsers both build on. Knowing the header fields, port rules and RTCP reports tells you where to look when a call stutters. To see RTP at work without building the stack, start with the VideoSDK JavaScript quickstart and sign up with $20 free credit.
What are you building with VideoSDK? Drop a comment and tell us where RTP shows up in your stack.
Frequently Asked Questions
Is RTP TCP or UDP?
RTP usually runs over UDP, because in a live call a late packet is worth less than a stream that keeps moving. WebRTC can fall back to TCP or a TURN relay when UDP is blocked.
What port does RTP use?
RTP uses no fixed port. RFC 3550 recommends an even UDP port for RTP and the next odd port for RTCP, with 5004 and 5005 registered as an optional default pair. WebRTC carries RTP and RTCP on one negotiated port.
What is the difference between RTP and RTCP?
The difference is that RTP carries the media, while RTCP carries reports about it. Sender reports map RTP timestamps to wall-clock time for synchronisation, and receiver reports carry packet loss, jitter and round-trip timing.
How do SIP and RTP work together?
SIP and RTP split a call into signalling and media. SIP sets up the call and exchanges SDP describing codecs and ports, then RTP carries the audio until a SIP BYE ends it.
Does WebRTC use RTP?
Yes, WebRTC uses RTP for all audio and video, always in its secure form, SRTP, with keys exchanged over DTLS. RFC 8834 also requires support for multiplexing RTP and RTCP on one port.
Does VideoSDK support RTP?
Yes, VideoSDK uses RTP for every audio and video track, because its meetings run over WebRTC. The SDKs handle packetisation, RTCP and SRTP, and SIP callers joining through its gateways send RTP too.
How does VideoSDK ensure security with RTP?
VideoSDK secures RTP with SRTP, which WebRTC requires, so media is encrypted in transit between each participant and VideoSDK's servers. For SIP calls, a gateway's Media Encryption setting switches signalling to TLS and audio to SRTP.