Visual RFC.
ALL RFCs / RFC 8285
Read the RFC ↗
RFC 8285 / RTP header extensions

Budget delivery and protect metadata deliberately

06

Configured metadata is not promised in every packet. Repetition improves a modelled delivery chance; security requires explicit protection.

RFC 8285 · § 4.1.1EXAMPLE
4 / 4
Budget delivery and protect metadata deliberatelySRTP payload encryption does not automatically encrypt header metadata. RFC6904 selective header-extension encryption requires separate use and configuration, and each actual extension needs security analysis.Plan delivery and protectionSRTP-encrypted media payloadHeader metadata can remain visiblePayload encryption is not header secrecyRFC6904: separate selective-encryption optionEach extension needs its own security analysisNo cryptography is implemented by this figureRFC8285 · chapter 6 · state 4 · fictional values
04
Do not infer metadata secrecy

Without a separate selective-encryption configuration, the drawn header metadata remains visible. RFC 6904 is a separate protection mechanism, not automatically applied.

Source for this drawing: RFC 8285 · Read RFC section 4.1.1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

Finding a route and sending media are separate jobs.

Some messages set up a conversation or discover a reachable address. Other packets carry the audio or video. Follow those jobs separately.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Neither negotiation, repetition nor encrypted media makes extension data automatically reliable or secret.

  • A header extension SHOULD be present only when the packet contains one or more elements, and an element SHOULD be included only when needed. Setup says it can appear, not that it appears in every packet—or any packet. Loss, decode dependencies, when information is needed and RTP robustness mechanisms influence repetition choices (§4.1.1). Header extensions can also reduce RTP header-compression efficiency (§4.1.2).
  • For a simple independent-loss model, repeating in N packets gives delivery probability 1−P^N, where P is each packet’s loss probability. Chosen P=1/4,N=3 yields 63/64. The 64 cells represent equally weighted model outcomes, not 64 sent packets. Burst loss can correlate all copies; the calculation is not a delivery guarantee (§4.1.1).
  • Feedback such as RTCP reports can inform whether information arrived, but a lost RTCP report does not imply loss of the original extension-bearing packets. Sending one copy per independently decodable set may be more efficient than putting it in every dependent packet. No universal repetition count or retry schedule is prescribed (§4.1.1).
  • Extension-usage negotiation requires integrity protection and end-to-end authentication to be implemented (MUST), following RFC 3264 security considerations. RTP-extension integrity protection itself SHOULD be used to resist alteration/DoS; lower-layer protection such as DTLS MAY be used. These are distinct requirement strengths, not permission to trust an unprotected mapping (§9).
  • Secure Real-time Transport Protocol (SRTP) can encrypt/protect the RTP payload while the RTP header, including extensions, is unprotected or only integrity protected. Confidential extension data needs an explicit solution; RFC 6904 provides selective header-extension encryption. This guide does not implement it or promise header confidentiality from an encrypted payload alone. Each actual extension must analyze its own content/security implications (§§9,10.1).
DETAILS

Fictional metadata values, URI names and bounded packet/signaling models. Not an RTP stack, complete SDP negotiation, live loss measurement or cryptographic implementation.

Read the RFC section ↗

All chapters in RFC 8285

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗