Locate extensions without changing RTP meaning

An extension adds metadata; it must not redefine the core RTP header or RTCP.

• RTP means Real-time Transport Protocol. Its extension bit X indicates a header extension after the fixed header and any contributing-source (CSRC) list, before the media payload. RFC 8285 puts multiple local-ID/length/data elements inside the single outer RTP extension block; it does not add several competing outer blocks (§§1,4.1; RFC 3550§§5.1,5.3.1).
• The fixed RTP header is 12 bytes and each CSRC is 4 bytes. In the chosen example CC=2 and X=1, the first byte is 0x92: V=2, P=0, X=1, CC=2. The extension starts at offset 20. Its four-byte outer header carries a 16-bit defined-by-profile value and a 16-bit length counted in 32-bit words, excluding that outer header.
• A one-byte-form block with body 10 aa 00 00 has four body octets, so its outer header is be de 00 01. The entire block is 8 bytes and the chosen RTP payload starts at offset 28. The two zero bytes pad the extension block; they are not media bytes or an RTP payload-padding count (§§4.1.2,4.2).
• Presence, format and contents are negotiated or defined out of band. Profile constants help identify the layout, but are not the definitive setup signal; with SDP, extmap attributes establish this mechanism. A receiver must not invent the meaning of local ID 1 from the magic number alone (§§4.1,4.1.2,5). The figure withholds metadata interpretation while the core RTP payload path remains separate.
• RTP Control Protocol (RTCP) supplies companion control reports. Header extensions MUST NOT change RTP/RTCP meaning in a way that breaks interoperability with unextended RTP. Metadata can be necessary for full higher-layer application functionality, provided the RTP layer still works without it (§4.1). RFC 8285 is an October 2017 Proposed Standard, obsoletes 5285, and allows negotiated mixing between packets; it never permits mixing element formats within one packet (§11).