Budget delivery and protect metadata deliberately
06Configured metadata is not promised in every packet. Repetition improves a modelled delivery chance; security requires explicit protection.
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 ↗
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.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
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).
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 ↗