RTP (Real-time Transport Protocol) carries audio and video across IP networks in WebRTC and VoIP. It defines a compact packet header with a sequence number, timestamp, payload type and SSRC identifier, and is almost always paired with RTCP for quality feedback.
What is the RTP protocol?
RTP is defined in IETF RFC 3550, with many additional RFCs layering extensions on top of it. It runs over UDP to keep delivery latency low, and accepts that some packets may be lost or arrive out of order in exchange for that speed.
The RTP packet header is 12 bytes at a minimum. The overhead is deliberately small so that most of each packet is media payload (an encoded audio frame, a slice of a video frame) rather than protocol metadata.
RTP packet header structure
Every RTP packet starts with a fixed 12-byte header. Optional extensions can follow before the media payload.
- V: Version (2 bits) – always
2in modern RTP. - P: Padding (1 bit) – padding marker, relevant when encryption is used
- X: Extension (1 bit) – extension bit marker, indicating if RTP header extensions are used or not
- CC: CSRC count (4 bits) – the number of CSRCs in this packet header
- M: Marker (1 bit) – payload-specific signal. For video it typically marks the last packet of a frame; for audio it marks the start of a talk spurt after silence suppression (DTX)
- PT: Payload type (7 bits) – tells the receiver which codec decodes this packet (e.g. Opus, VP8, H.264). The mapping between numbers and codecs is negotiated in SDP
- Sequence number (16 bits) – increments by 1 per packet. Used to detect packet loss and packet reordering
- Timestamp (32 bits) – the sampling instant of the first byte of payload. The receiver uses it to play media back at the correct rate and to compensate for jitter
- SSRC (32 bits) – a random identifier for the source of the stream. See SSRC for how WebRTC uses it to separate audio, video and simulcast layers
- CSRC list (0-15 × 32 bits) – contributing sources when a mixer combines streams. Rarely used in modern SFU-based WebRTC
Key RTP concepts in WebRTC
RTP plays a key role in VoIP, and as such in WebRTC as well.
The main difference is that for WebRTC, RTP is always encrypted, which means its SRTP variant is used.
Two other important differences are:
- WebRTC makes generous use of RTP header extensions in its implementation. Common ones include MID and RID (to identify media and simulcast layers),
abs-send-timeand Transport-Wide Congestion Control (TWCC) sequence numbers for bandwidth estimation - Since WebRTC runs inside a web browser, it needs to use mechanisms such as DTLS-SRTP instead of the simpler SDES approach popularized by SIP
RTP and RTCP work together
RTP carries media, RTCP carries control and quality feedback. The two protocols share the same port in WebRTC (via rtcp-mux) and the same SSRC identifies an endpoint across both. RTCP messages like NACK, PLI, REMB and Transport-CC are how the receiver tells the sender what it sees on the network.
RTP vs SRTP
WebRTC mandates encrypted media. It does that by using SRTP – the Secure variant of RTP – with keys negotiated over DTLS-SRTP. The packet format is essentially the same; SRTP adds payload encryption and an authentication tag on top of the RTP header.
| RTP | SRTP | |
|---|---|---|
| Defined in | RFC 3550 | RFC 3711 |
| Payload encryption | No | Yes (AES by default) |
| Message authentication | No | Yes (HMAC-SHA1 tag) |
| Used by WebRTC | No (mandated out) | Yes (mandatory) |
| Used by legacy VoIP / SIP | Common | Optional, often via SDES |
Because SRTP extends RTP rather than replacing it, everything above – header layout, sequence numbers, timestamps, SSRCs, RTCP pairing – applies to WebRTC media too. The only visible difference in a packet capture of a WebRTC session is the encrypted payload.
Where RTP is used outside WebRTC
RTP is the dominant real-time media transport across the industry. Most VoIP platforms, SIP infrastructure, and IP broadcast workflows use RTP, either in its plain form or wrapped in SRTP. Its popularity comes from broad codec support, its UDP-first design, and a header small enough to stay out of the way of the media itself.
