Every RTP packet—whether carrying a voice sample from a phone call, a video frame from a conference, or game state from a cloud gaming server—begins with the same 12-byte structure. This compact header contains everything receivers need to properly sequence, time, and process real-time media.\n\nThe RTP header represents decades of protocol engineering wisdom, carefully balancing information density against overhead minimization. Every bit serves a purpose; nothing is wasted. Understanding this header is essential for anyone implementing, debugging, or optimizing real-time communication systems.\n\nThis page provides a field-by-field examination of the RTP header, explaining not just what each field contains but why it exists and how implementations use it in practice.

The RTP header consists of a fixed 12-byte portion present in every packet, plus an optional extension of variable length. The fixed header contains all essential information for basic real-time transport; extensions provide application-specific data when needed.\n\nThe header is designed for efficient parsing by both software and hardware implementations. Fields are aligned on byte or word boundaries where possible, and the most frequently accessed information appears first.

The first byte of the RTP header begins with three control fields that receivers check immediately upon packet arrival.\n\nVersion (V) - 2 bits\n\nThe version field identifies the RTP protocol version. The current version is 2, and no updates to this version number are anticipated. Receivers encountering version values other than 2 should discard the packet as malformed or belonging to a different protocol.\n\nVersion 0 was used for early RTP drafts, and version 1 was used in the first published RTP standard (RFC 1889, now obsolete). Version 2 (RFC 3550) has been the standard since 2003.",

Padding (P) - 1 bit\n\nWhen set, the padding bit indicates that the packet contains padding bytes at the end that are not part of the payload. The last byte of the padding indicates the total number of padding bytes (including itself).\n\nPadding is typically used when encryption algorithms require block-aligned data. For example, AES encryption operates on 16-byte blocks, so payloads not naturally aligned to 16 bytes require padding. RTP's padding mechanism standardizes how this is handled.

Extension (X) - 1 bit\n\nWhen set, the extension bit indicates that the fixed header is followed by exactly one header extension. Extensions allow profile-specific or application-specific information to be carried in RTP packets without modifying the base protocol.\n\nThe header extension structure begins with a 16-bit extension profile identifier and a 16-bit length field, followed by the extension data. Common extensions include:\n\n- Absolute capture time: Precise wall-clock timestamps for synchronization\n- Audio level: Volume information for voice activity detection\n- Video orientation: Rotation hints for mobile devices\n- Transport-wide sequence numbers: Enhanced loss detection for congestion control

CSRC Count (CC) - 4 bits\n\nThe CC field contains the number of Contributing Source (CSRC) identifiers that follow the fixed header. Valid values range from 0 to 15.\n\nThis field is primarily relevant when RTP mixers combine multiple input streams into a single output stream. The mixer creates new packets with its own SSRC as the source but includes the original SSRCs as CSRC entries, maintaining attribution to the original speakers.\n\nWhen CC > 0:\n\nThe fixed header is followed by CC × 4 bytes of CSRC identifiers before the payload begins. Each CSRC is a 32-bit value identifying one of the original sources whose data contributed to this packet.

Marker Bit (M) - 1 bit\n\nThe marker bit has profile-specific semantics—its meaning depends on the application and payload type. The RTP specification intentionally leaves this bit's interpretation to profile documents, allowing different applications to use it for their specific needs.\n\nCommon marker bit uses:

Payload Type (PT) - 7 bits\n\nThe payload type field identifies the format of the RTP payload and determines its interpretation by the receiver. Values range from 0 to 127.\n\nThe payload type serves as a shorthand reference to a complete codec definition negotiated during session setup. When two endpoints establish an RTP session (via SIP/SDP, WebRTC, or other signaling), they agree on which payload type numbers correspond to which codecs, sample rates, and parameters.\n\nStatic vs. Dynamic Payload Types:\n\nRTP defines two categories of payload type assignments:

Collision avoidance with RTCP:\n\nPayload type values 72-76 are avoided in RTP because RTCP packets use these values as their packet type field in the same position. When RTP and RTCP share the same port (common with BUNDLE), this range helps demultiplex RTP from RTCP traffic. RFC 5761 specifies this demultiplexing approach.

Sequence Number - 16 bits\n\nThe sequence number increments by one for each RTP packet sent and wraps around after 65535 back to 0. The initial sequence number is chosen randomly for security reasons (making stream injection attacks harder).\n\nPrimary purposes:\n\n1. Loss detection: Gaps in sequence numbers indicate lost packets\n2. Reordering detection: Out-of-order arrivals detected by sequence comparison\n3. Duplicate detection: Same sequence number appearing twice\n4. Packet counting: Enables statistics for jitter, loss rate calculation

Sequence number vs. timestamp:\n\nA common confusion is the difference between sequence numbers and timestamps. They serve different purposes:\n\n- Sequence number: Increments by 1 per packet. Used for loss/reordering detection.\n- Timestamp: Increments by samples per packet. Used for playback timing.\n\nFor audio at 48kHz with 20ms packets (960 samples per packet):\n- Sequence: 100, 101, 102, 103...\n- Timestamp: 0, 960, 1920, 2880...\n\nBoth are needed: sequence numbers tell you if packets arrived correctly; timestamps tell you when their content should play.

Timestamp - 32 bits\n\nThe RTP timestamp reflects the sampling instant of the first octet of the media data in that packet. This is not wall-clock time; it's a media-specific value that increments at a rate defined by the payload format.\n\nClock rates by media type:\n\nDifferent media types use different clock rates, reflecting their sampling characteristics:

Timestamp behavior and interpretation:\n\nFor audio:\nTimestamps typically increment linearly by the number of samples in each packet. If a sender transmits 20ms of 48kHz Opus audio, the timestamp increments by 960 (48000 × 0.020) per packet. During silence suppression (not transmitting silence), timestamps continue incrementing, creating gaps that receivers use to insert silence.

For video:\nAll packets belonging to the same video frame share the same timestamp. A single 720p H.264 frame might span 10 RTP packets—all with identical timestamps. The marker bit indicates the last packet of a frame, signaling that a complete frame is available for decoding.\n\nRandom initial timestamp:\nLike sequence numbers, timestamps start from a random value for security. Receivers calculate relative timing from timestamp differences rather than assuming they start at zero.

Synchronization Source (SSRC) - 32 bits\n\nThe SSRC identifier uniquely identifies the source of an RTP stream within a session. Each sender picks a random 32-bit value as their SSRC when joining a session.\n\nWhy random SSRC matters:\n\n- Collision resistance: Even without coordination, 32-bit random values have very low collision probability\n- Security: Attackers can't predict SSRCs to inject traffic\n- Mobility: Same device reconnecting from different IP gets same SSRC\n- Independence: No central allocation authority required

Contributing Source (CSRC) - 32 bits each\n\nWhen a mixer combines multiple streams, it uses CSRC identifiers to preserve information about the original sources. The CC field indicates how many CSRCs are present (0-15).\n\nSSRC collision handling:\n\nIf two participants randomly generate the same SSRC (probability ~1 in 4 billion), RTCP helps detect this. Participants monitor RTCP SDES packets; if they see their own SSRC reporting from a different CNAME (canonical name), a collision has occurred. The participant who joined later must pick a new SSRC.

We've examined every field of the RTP header, understanding how each contributes to enabling real-time communication over unreliable networks.

What's next:\n\nRTP provides the data transport, but real-time communication requires feedback about quality, synchronization across streams, and participant management. The next page explores RTCP (Real-time Transport Control Protocol), the companion protocol that provides these essential control functions.