RTP (Real-time Transport Protocol, RFC 3550) carries the actual voice or video after SIP negotiates the session, running over UDP with a compact header (sequence number, timestamp, SSRC). RTCP reports quality alongside it. SRTP (RFC 3711) adds encryption and authentication to RTP, keyed via SDES in SDP or DTLS-SRTP.
RTP: carrying the media
Once SIP and SDP have agreed the session, the media itself flows over RTP — almost always over UDP, because real-time audio prefers timely delivery to guaranteed delivery. Each RTP packet carries a chunk of encoded audio (a codec frame such as 20 ms of G.711) behind a 12-byte header. RTP is a separate stream from the SIP signalling, on the ports the SDP negotiated, and typically flows directly between the endpoints or through a media relay rather than following the signalling path.
The RTP header
The 12-byte RTP header gives the receiver everything it needs to reconstruct a real-time stream. The sequence number detects loss and reordering. The timestamp reflects the sampling instant so the receiver can play out audio at the right cadence and remove jitter with a jitter buffer. The SSRC uniquely identifies the media source within the session. The payload type echoes the codec agreed in SDP. The marker bit flags events such as the first packet after a silence period.
| Field | Size | Purpose |
|---|---|---|
| V / P / X / CC | 1 byte | Version, padding, extension, CSRC count flags |
| M (marker) + PT | 1 byte | Marker bit + payload type (codec from SDP) |
| Sequence number | 2 bytes | Detect packet loss and reordering |
| Timestamp | 4 bytes | Sampling instant; drives playout / jitter buffer |
| SSRC | 4 bytes | Synchronisation source — identifies the stream |
| CSRC (0–15) | 0–60 bytes | Contributing sources (from mixers) |
RTCP: quality feedback
RTP travels with a companion control protocol, RTCP, on the adjacent (odd) port. RTCP carries no media; instead each side periodically sends Sender Reports and Receiver Reports describing the stream's health — packets sent and lost, cumulative loss, interarrival jitter, and the round-trip time derived from report timestamps. These metrics are the raw material for MOS estimates and for diagnosing one-way audio, jitter and loss on a VoIP call. RTCP also carries source description (CNAME) and BYE for stream teardown.
| Metric | What it tells you |
|---|---|
| Packet loss (fraction + cumulative) | How much audio is being dropped |
| Interarrival jitter | Variation in packet timing — playout difficulty |
| Round-trip time | Path latency (from SR/RR timestamps) |
| Highest sequence received | Progress and loss detection per source |
SRTP: encrypting the media
Plain RTP is unencrypted, so anyone on the path can capture and replay the audio. SRTP (RFC 3711) secures it: it encrypts the RTP payload (default AES in counter mode) and appends an authentication tag (default HMAC-SHA1) that protects integrity and provides replay protection, while leaving the RTP header readable so routers and jitter buffers still work. The transport shows up in SDP as RTP/SAVP instead of RTP/AVP. SRTP protects confidentiality and integrity but depends entirely on how its keys are exchanged.
Keying SRTP: SDES vs DTLS-SRTP
SRTP needs a master key at each end, and the two common ways to deliver it differ sharply in security. SDES (RFC 4568) puts the key in an a=crypto line in the SDP — simple, but only as safe as the SIP signalling, so it must be carried over TLS or the key is exposed. DTLS-SRTP (RFC 5763/5764) instead runs a DTLS handshake in the media path to derive keys, so the key never appears in the signalling; it is the model WebRTC mandates. Choose DTLS-SRTP where endpoints support it, and always protect SDES with SIP over TLS.
| Method | RFC | Where the key lives | Note |
|---|---|---|---|
| SDES | RFC 4568 | a=crypto line in the SDP | Requires SIP over TLS to be safe |
| DTLS-SRTP | RFC 5763/5764 | Derived by a DTLS handshake in the media path | Key never in signalling; used by WebRTC |
| MIKEY | RFC 3830 | Key-management payload | Used in some IMS deployments |
Frequently asked
What is the difference between SIP and RTP?
SIP is the signalling that sets up, modifies and ends a call; RTP is the media transport that carries the actual voice or video once the call is established. They run as separate streams on separate ports — SIP negotiates the session, RTP delivers it.
Why does RTP run over UDP instead of TCP?
Real-time audio values timeliness over reliability. TCP's retransmission and head-of-line blocking would add latency and jitter that hurt a live call more than an occasional lost packet does. RTP over UDP lets the receiver conceal small losses while keeping the stream on time.
What does RTCP do?
RTCP is RTP's companion control channel. It carries no media; it periodically reports stream quality — packet loss, jitter and round-trip time via Sender and Receiver Reports — which is used to estimate call quality (MOS) and diagnose problems like one-way audio.
What is SRTP?
SRTP (RFC 3711) is the secure profile of RTP. It encrypts the media payload (typically AES counter mode) and authenticates each packet (typically HMAC-SHA1) with replay protection, while keeping the RTP header in the clear. In SDP it appears as the RTP/SAVP transport.
What is the difference between SDES and DTLS-SRTP?
Both key SRTP. SDES carries the key in an a=crypto SDP line, so it is only secure if the SIP signalling itself is protected with TLS. DTLS-SRTP derives keys through a DTLS handshake in the media path, so the key never touches the signalling — the approach WebRTC requires.
Source specifications
The published standards this page is grounded in. Opens in a new tab.