What you will learn on this page

For real-time media, that’s a problem.

What UDP is missing — and how RTP fixes it

 
• 1. Packet ordering
  UDP problem: Packets can arrive out of order.
  
  RTP solution: RTP adds a sequence number so the receiver can:
   • Reorder packets
   • Detect missing packets


• 2. Timing & playout control
  UDP problem: No timing info — packets arrive “whenever.”
  RTP solution - RTP adds:
  • Timestamp (media clock–based, not wall-clock)
  • Enables jitter buffers
  • Enables smooth playout
  This is critical for audio and video.


• 3. Loss detection
  UDP problem: You cannot tell what was lost.
  RTP solution: Sequence numbers make loss visible, even if retransmission is not used.
  
  
• 4. Media type identification
  UDP problem: UDP has no idea what the payload is.
  RTP solution: RTP Payload Type (PT) field identifies:
   Video format, Audio codec, Data essence
  
  In SMPTE-2110, PT distinguishes:
   Video (ST 2110-20), Audio (ST 2110-30/31), ANC (ST 2110-40)


• 5. Multiple streams on one port
  UDP problem: One UDP port = one ambiguous stream.
  
  RTP solution: RTP adds SSRC (Synchronization Source ID) so:
  Multiple RTP streams can share one UDP port
  Each stream is uniquely identified
  
  This is essential in:
  Multichannel audio, Multicast video, Conference systems


• 6. Synchronization between streams
  UDP problem: Audio and video drift apart.
  
  RTP solution: RTP works with RTCP:
   • RTCP Sender Reports map RTP timestamps to wall clock
   • Allows audio/video lip-sync
   • Enables monitoring (loss, jitter, RTT)
  
  In SMPTE-2110, RTP timestamps align with PTP (ST-2059).


• 7. Extensibility
  UDP problem: No standardized way to extend semantics.
  
  RTP solution: RTP supports:
   • Header extensions
   • Profile-specific extensions
   • Timecode carriage
   • Metadata signaling
  
  Used heavily in broadcast workflows.

Why not just “add this in the application”?
  Because:
 • Everyone would do it differently
 • Interoperability would collapse
 • Monitoring and tooling would be impossible

RTP is a standardized media contract on top of UDP.

UDP delivers packets; RTP delivers time-based media.

While RTP (Real-time Transport Protocol) is found at the OSI Layer 5 – Session layer, it is most accurately described as operating between the Transport layer (Layer 4) and the Application layer (Layer 7) in practice.

RTP resides in Layer 5 (Session)?
RTP provides session management features for real-time media streams:

• Synchronization of multiple streams (audio + video)
• Timing and sequencing (via RTP timestamps and sequence numbers)
• Play-out control (jitter buffer management)
• Identification of participants (SSRC – Synchronization Source Identifier)

These functions align with the OSI Session layer's responsibilities: establishing, managing, and terminating sessions/dialogues between applications.

  The actual ST2110 payload resides in layer 6 (Presentation), so, RTP is the “shim” ST 2110 uses to make UDP packets behave like real-time media.

Quick Summary
• OSI model (academic/theoretical) → Layer 5 (Session)
• TCP/IP model (real-world/practical) → Application layer (above UDP)
• Most precise modern answer → Layer 5, because RTP manages real-time media sessions rather than being a pure end-user application like HTTP or SMTP.

So if you're studying for networking certifications (CCNA, CompTIA Network+, etc.) or discussing OSI layers strictly, say: RTP operates at Layer 5 (Session layer).

RTP Packets

Packetization: Encapsulates media (like video frames or audio samples) into packets that fit within network MTUs.

Synchronization source (SSRC): A unique ID per stream, ensuring receivers can distinguish between multiple media sources.

Contributing source (CSRC): Used when a stream is mixed (e.g., multiple talkers in a conference).

Minimal control overhead: Only 12 bytes of base header — very efficient for high-rate video/audio.

SSRC (Synchronization Source) 32 bits
Unique ID chosen by the sender to identify the stream. Receivers use it to distinguish multiple concurrent RTP sources.

CSRC List (Optional) 0–15 entries, 32 bits each
Lists contributing sources if the payload is a mix (e.g., an audio mixer combining multiple microphones).

RTP Header Extension
Where it lives: Immediately after the fixed 12-byte RTP header — but only if the X bit (Extension) in the header is set to 1.

Purpose: Used to carry optional metadata that doesn’t fit into the standard header, Such as:

• Absolute timestamps (wall-clock time)
• Frame identifiers
• Color space or HDR metadata
• SMPTE ST 2110-21 traffic shaping data
• Telemetry or custom app data

Profile-specific ID: Identifies the meaning/format of the extension (e.g., SMPTE 2110-21 uses 0xABAC).
Length: Number of 32-bit words in the extension data.
Extension Data: The custom information itself.

In 2110 systems, the extension is often used for flow timing metadata or ancillary synchronization.

Structure:

Header end

Payload Variable length (up to MTU limit)
The actual media data — such as video frame segments, audio samples, or ancillary data. The type and interpretation are defined by the Payload Type (PT) field.

RTP Padding (P bit)
Where it lives: At the end of the packet (payload section).

Purpose: Used when the payload must be padded to a specific byte boundary. For example:

• Encryption block alignment (SRTP)
• Proprietary hardware requirements

How it works:

• The P (Padding) bit in the RTP header = 1 if padding is present.
• The last byte of the packet indicates how many padding bytes were added.

Example:
[Payload Data][xx][xx][xx][03]
The final byte (03) means there are 3 padding bytes in total.

RTP Control Protocol (RTCP)
RFC 3550 also defines a companion protocol: RTCP (RTP Control Protocol).

• Sent periodically along with RTP streams.
• Provides quality feedback — packet loss, jitter, round-trip delay.
• Reports are used to adjust encoding rates or diagnose network issues.
• Also carries canonical names (CNAMEs) to keep track of which RTP streams belong to the same sender.

How RTP Works in Real Time

1. Sender:
1. Captures video/audio samples.
2. Encodes them (e.g., H.264, PCM).
3. Splits them into RTP packets with sequence numbers and timestamps.
4. Sends over UDP to a multicast or unicast destination.
2. Network:
1. Switches forward packets based on multicast groups (e.g., 239.x.x.x).
2. Some may be duplicated for redundancy (ST 2022-7).
3. Receiver:
1. Receives RTP packets.
2. Uses sequence numbers to reorder, detect loss.
3. Uses timestamps to rebuild timing and clock synchronization.
4. Decodes the payload and plays it out.

RTP Is Transport, Not Reliability
RTP does not:

• Guarantee delivery
• Correct errors
• Handle congestion control (that’s up to the application or RTCP feedback)

This makes it perfect for live, real-time content, where a missing frame is better than a delayed one.

SMPTE ST 2110 uses RTP as the encapsulation layer for all essence types (video, audio, metadata).

ST 2022-7 can be used underneath for redundancy.

RTP (RFC 3550) is a lightweight, real-time transport protocol designed for synchronization, sequencing, and timing of audio/video data across IP networks, which are the backbone of modern IP broadcast and streaming systems.

Secure RTP

SRTP Master Key Identifier (MKI)
Where it lives: In Secure RTP (SRTP) packets, optionally appended after the encrypted payload but before the authentication tag.

Purpose: Identifies which cryptographic key was used to encrypt the RTP payload. This is important when multiple SRTP keys are in use, for example, during rekeying events or multi-party conferences.

Structure (optional, variable length):
[Encrypted Payload][MKI][Auth Tag]

MKI length is negotiated during session setup (via SDP). It tells the receiver which master key to use to decrypt the payload. Used mainly in environments where keys are rotated frequently for security compliance.

Authentication Fields (SRTP Auth Tag)
Where it lives: At the end of the SRTP packet — after the payload and optional MKI.

Purpose: Provides integrity and authenticity for the RTP packet. It ensures that the packet wasn’t tampered with and came from a trusted sender.

How it works: Calculated using an HMAC (Hash-based Message Authentication Code) algorithm like HMAC-SHA1.
Common tag lengths: 80 bits (10 bytes) or 32 bits (4 bytes).
The receiver recomputes the tag and compares it — mismatch means discard.

Example structure (end of packet):
[Encrypted Payload][MKI (optional)][Auth Tag]

Note: MTU (Maximum Transmission Unit) is the largest packet size, in bytes, that can be transmitted across a particular network link without needing to be fragmented. Think of it as the “box size limit” for the network: Every frame or packet you send must fit inside this box — otherwise, it gets split into smaller boxes (fragments), which slows things down and can cause problems for real-time streams.
Network Type	Common MTU (bytes)	Notes
Ethernet (standard)	1500	Default for most IP networks.
Ethernet Jumbo Frames	9000	Used in data centers and 2110 networks for higher efficiency.
Wi-Fi	2304 (max theoretical)	Often lower in practice due to overhead.
VPN / GRE tunnels	1400–1476	Smaller MTU because of encapsulation overhead.
In SMPTE ST 2110 and other uncompressed media systems, each video frame can be tens of megabytes. It must be split into many RTP packets, and each RTP packet must fit within the MTU (usually 1500 bytes).
If you use Jumbo Frames (9000 bytes), you can send more payload per packet → fewer packets per frame → lower CPU load and switch congestion.
If an RTP packet is larger than the MTU, IP will fragment it into multiple smaller packets. That’s bad for real-time streams because:
• If one fragment is lost, the entire packet is unusable.
• It increases latency and processing overhead.
Hence, in professional media networks, fragmentation is avoided by design. Packet sizes are kept under the MTU limit.
Every device in the path (switches, routers, NICs) must agree on the MTU. If not, packets might get dropped or fragmented midstream.
This is why IP video engineers often set: MTU = 9000 (Jumbo) across all NICs and switches in a 2110 plant.
The RTP packet includes: Ethernet + IP + UDP + RTP headers + payload
→ total size must not exceed MTU.
MTU never appears in an RTP packet; it is an external network limit that determines how large the RTP payload is allowed to be.
• MTU is path-specific
• Different links may have different MTUs
• Endpoints already know their local MTU
• IP fragmentation exists (but is avoided for real-time media)

Mapping MPEG Transport Streams to RTP