RFC 5285

A General Mechanism for RTP Header Extensions

📅 published July 2008, from ietf

RFC 5285: A General Mechanism for RTP Header Extensions ✨

okay bestie, here's the header info 🎀 It's a Network Working Group doc from July 2008. The authors are D. Singer (Apple, Inc.) and H. Desineni (Qualcomm). It's a Standards Track document, and this title block doesn't list any Obsoletes or Updates. 🦋

Status of This Memo 📜

This one is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💖 For the standardization state and status of this protocol, check the current "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Abstract ✨

So this doc gives RTP (the Real-Time Transport Protocol) a general way to use its header extension feature 🧚 It lets each RTP packet carry a small number of small extensions. The pool of possible extensions is huge and registration is decentralized, so it's very much a no-gatekeeping situation 💅 Which extensions are actually in use in a session gets signaled in that session's setup info 🎀

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  2
3.  Design Goals . . . . . . . . . . . . . . . . . . . . . . . . .  2
4.  Packet Design  . . . . . . . . . . . . . . . . . . . . . . . .  3
  4.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  3
  4.2.  One-Byte Header  . . . . . . . . . . . . . . . . . . . . .  5
  4.3.  Two-Byte Header  . . . . . . . . . . . . . . . . . . . . .  6
5.  SDP Signaling Design . . . . . . . . . . . . . . . . . . . . .  7
6.  Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . .  9
7.  BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
  9.1.  Identifier Space for IANA to Manage  . . . . . . . . . . . 13
  9.2.  Registration of the SDP extmap Attribute . . . . . . . . . 14
10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15

1. Introduction 🌸

okay so the RTP spec [RFC3550] already gives you a way to extend the RTP header 🎀 The format and the rules for using it are defined in Section 5.3.1. The existing method allows at most one extension per RTP packet 🙈 That extension is identified by a 16-bit identifier, and a 16-bit length field tells you how long the header extension is, in 32-bit words.

This mechanism has two conspicuous drawbacks, and they're giving main character problems 💀 First, it only permits one header extension in a single RTP packet. Second, the spec gives no guidance on how those 16-bit header extension identifiers should be allocated so they don't collide 😭

This specification fixes the first drawback by defining a backward-compatible and extensible way to carry multiple header extension elements in a single RTP packet ✨ It fixes the second drawback by naming these extension elements with URIs. It also defines an IANA registry for extension elements defined in IETF specifications, plus a Session Description Protocol (SDP) method for mapping between the naming URIs and the identifier values carried in the RTP packets 👑

This header extension applies to RTP/AVP (the Audio/Visual Profile) and its extensions 🦋

2. Requirements Notation 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those caps words are the big rules, so read them carefully 🫶

3. Design Goals 🎯

The goal here is a simple mechanism so multiple identified extensions can be used in RTP packets. You don't need formal registration for each one, and it still avoids collisions 💖

This mechanism is an alternative to the practice of burying associated metadata into the media format bit stream. That has often been done with media sent over fixed-bandwidth channels, and honestly it's kind of messy 🙈 Once you do it, a decoder for that specific media format is required to extract the metadata. Also, depending on the media format, the metadata may need to be added at encoding time so the bit rate needed for it gets accounted for. But the metadata may not be known at that time. Inserting it later can require a decode and re-encode to meet bit-rate requirements, which is a whole ordeal 😭

In some cases a more appropriate, higher-level mechanism may be available, and if so, it should be used ✨ For cases where a higher-level mechanism isn't available, it's better to provide a mechanism at the RTP level than to tie the metadata to a specific form of media data 🌈

4. Packet Design 🧚

4.1. General 💅

The following design fits into the "header extension" of the RTP extension, as described above 🎀

The presence and format of this header extension, along with its contents, are negotiated or defined out-of-band, such as through signaling (see below for SDP signaling) 📡 The value defined for an RTP extension (defined below for the one-byte and two-byte header forms) is only an architectural constant (e.g., for use by network analyzers). It's the negotiation or definition (e.g., in SDP) that is the definitive indication that this header extension is present 🔥

This specification inherits the requirement from the RTP specification that the header extension "is designed so that the header extension may be ignored". To be specific, header extensions using this specification MUST only be used for data that can safely be ignored by the recipient without affecting interoperability. They MUST NOT be used when the presence of the extension has changed the form or nature of the rest of the packet in a way that isn't compatible with the way the stream is signaled (e.g., as defined by the payload type). Valid examples might include metadata that is additional to the usual RTP information 🍓

The RTP header extension is formed as a sequence of extension elements, with possible padding. Each extension element has a local identifier and a length. The local identifiers may be mapped to a larger namespace in the negotiation (e.g., session signaling) 🦋

As is good network practice, data should only be transmitted when needed 🫶 The RTP header extension should only be present in a packet if that packet also contains one or more extension elements, as defined here. An extension element should only be present in a packet when needed. The signaling setup of extension elements only indicates that those elements may be present in some packets, not that they're actually present in all (or indeed, any) packets 💜

Each extension element in a packet has a local identifier (ID) and a length. The local identifiers present in the stream MUST have been negotiated or defined out-of-band. There are no static allocations of local identifiers. Each distinct extension MUST have a unique ID. The value 0 is reserved for padding and MUST NOT be used as a local identifier 🔥

There are two variants of the extension: one-byte and two-byte headers. Since it's expected that (a) the number of extensions in any given RTP session is small and (b) the extensions themselves are small, the one-byte header form is preferred and MUST be supported by all receivers 👑 A stream MUST contain only one-byte or two-byte headers. They MUST NOT be mixed within a stream. Transmitters SHOULD NOT use the two-byte form when all extensions are small enough for the one-byte header form ✨

A sequence of extension elements, possibly with padding, forms the header extension defined in the RTP specification. There are as many extension elements as fit into the length indicated in the RTP header extension length. Since this length is signaled in full 32-bit words, padding bytes are used to pad to a 32-bit boundary. The entire extension is parsed byte-by-byte to find each extension element (no alignment is required). Parsing stops at the earlier of two things: the end of the entire header extension, or, in one-byte headers, encountering an identifier with the reserved value of 15 🧚

In both forms, padding bytes have the value of 0 (zero). They may be placed between extension elements if you want alignment, or after the last extension element if you need padding. A padding byte doesn't supply the ID of an element, nor the length field. When a padding byte is found, it's ignored and the parser moves on to interpret the next byte 🌸

Note carefully that the one-byte header form allows for data lengths between 1 and 16 bytes, by adding 1 to the signaled length value. So 0 in the length field means 1 byte of data follows 💖 This allows for the important case of 16-byte payloads. This addition is not performed for the two-byte headers, where the length field signals data lengths between 0 and 255 bytes 🎀

Using RTP header extensions will reduce the efficiency of RTP header compression, since the header extension gets sent uncompressed unless the RTP header compression module is updated to recognize the extension header 😭 If header extensions are present in some packets but not others, that can also reduce compression efficiency, because the fixed header needs an update whenever header extensions start or stop being sent 🙈 The interactions between the RTP header extension and header compression are explored further in [RFC2508] and [RFC3095] 🌈

4.2. One-Byte Header 💖

okay so the one-byte header form is giving main character energy 🎀. The 16-bit value that the RTP spec asks for (it's labeled "defined by profile" over there 🙈) is locked to the fixed pattern 0xBEDE. And yes, the first version of this spec was written on the feast day of the Venerable Bede, so the vibes are literally saint-core 🧚✨

Every extension element starts with one byte that holds an ID and a length 🍓:

    0
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |  ID   |  len  |
   +-+-+-+-+-+-+-+-+

The 4-bit ID is the local identifier of this element, and it has to be in the range 1-14 inclusive 🦋. In the signaling section, this is called the valid range.

The local identifier value 15 is reserved for future extension and MUST NOT be used as an identifier 🚫. If you ever run into ID value 15, you should ignore its length field, stop processing the whole extension right there, and only consider the extension elements that came before the element with ID 15. (ngl this is a very dramatic exit 💀)

The 4-bit length is the number of data bytes in this element after the one-byte header, minus one 🌈. So a value of zero means one byte of data follows, and a value of 15 (the max) means 16 bytes of element data. This lets you carry 16-byte values, which is a super common length for labels and identifiers, but you give up zero-length values. Honestly that's fine, since they'd usually get padded anyway ✨

Here's an example header extension with three extension elements, some padding, and the required RTP fields 👑:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0xBE    |    0xDE       |           length=3            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ID   | L=0   |     data      |  ID   |  L=1  |   data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         ...data   |    0 (pad)    |    0 (pad)    |  ID   | L=3   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          data                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.3. Two-Byte Header 🦋

in the two-byte header form, the 16-bit value that the RTP spec wants (again, "defined by profile") is defined like this 💅:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         0x100         |appbits|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The appbits field is 4 bits, and the application gets to decide what they mean 🔥. That stuff is outside the scope of this spec. For signaling purposes, this field is treated as a special extension value assigned to the local identifier 256. If no extension has been specified through configuration or signaling for this local identifier value 256, the sender SHOULD set the appbits field to all 0s, and the receiver MUST ignore it 🫶.

Each extension element starts with a byte for the ID and a byte for the length 🌸:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       ID      |     length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The 8-bit ID is the local identifier of this element, in the range 1-255 inclusive. In signaling, the range 1-256 is called the valid range. The values 1-255 point to extension elements, and the value 256 points to the 4-bit appbits field (see above) 🧚.

The 8-bit length field is the length of the extension data in bytes, not counting the ID and length fields. A value of zero means there's no data after it 🍓.

Here's another example header extension, with three extension elements, some padding, and the required RTP fields 💜:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0x10    |    0x00       |           length=3            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ID       |     L=0       |     ID        |     L=1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       data    |    0 (pad)    |       ID      |      L=4      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          data                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. SDP Signaling Design 📮

the way this works: the presence of this extension, and the mapping of the local identifiers used in the header extension to a larger namespace, MUST be done out-of-band 🙌. For example, that can happen as part of a SIP offer/answer exchange that uses SDP. This section defines that signaling in SDP.

A usable mapping MUST use IDs from the valid range, and each ID in that range MUST be used only once for each media (or only once if the mappings are at session level) 💅. Mappings that don't follow these rules MAY still be shown, for instance during offer/answer negotiation (more on that in the next section), but they have to be remapped to conformant values before they can be applied 😭.

Each extension is named by a URI 🔗. That URI MUST be absolute and precisely identifies the format and meaning of the extension. URIs that contain a domain name SHOULD also contain a month-date in the form mmyyyy. The definition of the element and the assignment of the URI MUST have been authorized by the owner of the domain name on or very close to that date. (This avoids problems when domain names change owners 🫠.) If the resource or document defines several extensions, the URI MUST identify the actual extension in use, e.g., using a fragment or query identifier (characters after a '#' or '?' in the URI) 🎯.

Rationale: URIs give us a huge, unallocated space, and they come with documentation about the extension 📚. The URIs are not required to be de-referencable, so that confidential or experimental use is allowed, and so extensions can keep working even after the organization that defined them is gone 🕊️.

An extension URI with the same attributes MUST NOT appear more than once for the same stream, meaning at session level or in the declarations for a single stream at media level. (The same extension can totally be used for several streams, and it can show up differently parameterized for the same stream 🧩.)

For extensions defined in RFCs, the URI used SHOULD be a URN that starts with "urn:ietf:params:rtp-hdrext:" and is followed by a registered, descriptive name 🌈.

The registration requirements are detailed in the IANA Considerations section, below ✨.

Here's an example (only an example!) where 'avt-example-metadata' is a hypothetical name for a header extension:

   urn:ietf:params:rtp-hdrext:avt-example-metadata

And an example name that isn't from the IETF (also only an example) might be:

   http://example.com/082005/ext.htm#example-metadata

The mapping can be provided per media stream (in the media-level section(s) of SDP, i.e., after an "m=" line) or globally for all streams (i.e., before the first "m=" line, at session level) 🎀. The definitions MUST be either all session level or all media level; mixing the two styles is not permitted 🙅. Also, as noted above, the IDs used MUST be unique for each stream type for a given media, or for the session for session-level declarations 🔐.

Each local identifier that might be used in the stream is mapped to a string using an attribute of this form:

   a=extmap:<value>["/"<direction>] <URI> <extensionattributes>

Where <URI> is a URI as described above, <value> is the local identifier (ID) of this extension and is an integer in the valid range inclusive (0 is reserved for padding in both forms, and 15 is reserved in the one-byte header form, as noted above), and <direction> is one of "sendonly", "recvonly", "sendrecv", or "inactive" (without the quotes) 💜.

The formal BNF syntax is presented in a later section of this specification 📖.

Example:

   a=extmap:1 http://example.com/082005/ext.htm#ttime

   a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short

When SDP signaling is used for the RTP session, it's the presence of the 'extmap' attribute(s) that tells you this style of header extension is in use, not the magic number mentioned above 🦋✨

6. Offer/Answer ✨

Okay so the simple signaling from earlier can level up in an offer/answer situation 💅 It lets you do three extra things:

  • asymmetric behavior, where extensions only go one way 🦋
  • offering mutually exclusive alternatives 🎀
  • offering more extensions than one session can hold 🌸

You MAY add a direction attribute to an extmap 💖 If you don't, it just inherits the stream direction (obviously 🙄), or it's "sendrecv" for session-level attributes or for extensions on "inactive" streams. The direction MUST be one of "sendonly", "recvonly", "sendrecv", or "inactive". "sendonly" means you're able to send, "recvonly" means you want to receive, and "sendrecv" means both. "inactive" means neither, but a later renegotiation might make the extension active again 🧚

Extensions, with their directions, can be signaled for an "inactive" stream. Using an extension direction that clashes with the stream direction is an error 💀 For example, a "sendonly" attribute on a "recvonly" stream is a no-go.

If an offer or answer has session-level mappings (so no media-level ones), and each stream needs different behavior, you can move the whole set of extension map declarations down into the media-level section(s) of the SDP 🌈 Just note that this spec doesn't let you mix global and local declarations, so identifier management stays easy 🫶

If an extension map is offered as "sendrecv", either explicitly or implicitly, and you want asymmetric behavior, the SDP may be modified to change or add direction qualifiers for that extension ✨ If an extension is marked "sendonly" and the answerer wants to receive it, the extension MUST be marked as "recvonly" in the SDP answer. An answerer that doesn't want to receive it, or doesn't understand it, SHOULD remove it from the SDP answer 😭

Same energy the other way: if an extension is marked "recvonly" and the answerer wants to send it, the extension MUST be marked as "sendonly" in the SDP answer. An answerer that doesn't want to send it, or can't, SHOULD remove it from the SDP answer 🍓

Local identifiers in the valid range, inclusive, in an offer or answer must not be used more than once per media section (session-level section included) 🙈 A session update MAY change the direction qualifiers of extensions in use. A session update MAY also add or remove extensions. Identifier values in the valid range MUST NOT be altered (remapped) 👑

Note that, under this rule, the same local identifier can't be used for two extensions on the same media, even if one is "sendonly" and the other is "recvonly". That's because neither could ever become sendrecv, since renumbering isn't allowed either 💜

If a party wants to offer mutually exclusive alternatives, it can offer multiple extensions with the same identifier in the (unusable) range 4096-4351 🦋 The answerer should pick at most one of the offered extensions with that identifier, and remap it to a free identifier in the valid range so it becomes usable.

Same idea if more extensions are offered than fit in the valid range: identifiers in the range 4096-4351 may be offered 🌸 The answerer should choose the ones it wants and remap them to free identifiers in the valid range.

It's always allowed to put the offered identifier value "as is" in the SDP answer, for example if there's no free identifier left in the valid range 🙌 Extensions with an identifier outside the valid range can't be used, of course. If needed, the offerer or answerer can update the session to make room for such an extension 🫧

Rationale: the range 4096-4351 for these negotiation identifiers is deliberately restricted so the range of valid identifiers can expand in the future. 🔮

Either party MAY include extensions in the stream other than the ones negotiated, or the ones negotiated as "inactive", for example for the benefit of intermediate nodes 🎀 But only extensions that appeared with an identifier in the valid range, in SDP originated by the sender, can be sent.

Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. all left out for brevity) 📝

The offer:

a=extmap:1 URI-toffset
a=extmap:14 URI-obscure
a=extmap:4096 URI-gps-string
a=extmap:4096 URI-gps-binary
a=extmap:4097 URI-frametype
m=video
a=sendrecv
m=audio
a=sendrecv

The answerer only wants GPS in string format, and only on video, but it can't send GPS at all 🥺 It doesn't care about transmission offsets on audio, and it doesn't understand URI-obscure. So it moves the extensions from session level to media level and tweaks the declarations:

m=video
a=sendrecv
a=extmap:1 URI-toffset
a=extmap:2/recvonly URI-gps-string
a=extmap:3 URI-frametype
m=audio
a=sendrecv
a=extmap:1/sendonly URI-toffset

7. BNF Syntax

The syntax below is written in ABNF, following [RFC5234] 🧠 The syntax element 'URI' comes from [RFC3986] (only absolute URIs are allowed here). The syntax element 'extmap' is an attribute from [RFC4566], so "a=" comes before the extmap definition. Each specific extension attribute is defined by the spec for that extension name, and there can be several of them 💅

        extmap = mapentry SP extensionname [SP extensionattributes]

        extensionname = URI

        direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"

        mapentry = "extmap:" 1*5DIGIT ["/" direction]

        extensionattributes = byte-string

        URI = <Defined in RFC 3986>

        byte-string = <Defined in RFC 4566>

        SP = <Defined in RFC 5234>

        DIGIT = <Defined in RFC 5234>

8. Security Considerations 🔐

This only defines a place to transmit information 🫣 The security implications of the extensions themselves have to be discussed in those extensions.

Care should be taken when defining extensions. They should be purely informative, but even when the information gets extracted, it should not cause security concerns 😰

Header extensions have the same security coverage as the RTP header itself 💀 When Secure Real-time Transport Protocol (SRTP) [RFC3711] is used to protect RTP sessions, the RTP payload may be both encrypted and integrity protected, while the RTP header is either unprotected or integrity protected. So it's inappropriate to put information in header extensions that would cause security problems if disclosed, unless the entire RTP packet is protected by a lower-layer security protocol that provides both confidentiality and integrity 🚨

9. IANA Considerations 📋

9.1. Identifier Space for IANA to Manage

The mapping from the naming URI form to a reference to a specification is managed by IANA 🗂️ Adding to this registry falls under "Expert Review" as defined in [RFC5226].

IANA will also keep a server with all of the registered elements in a publicly accessible space 🌐

Here's the formal declaration needed by the IETF URN Sub-namespace specification [RFC3553] ✨

  • Registry name: RTP Compact Header Extensions
  • Specification: RFC 5285 and RFCs updating RFC 5285.
  • Information required:
    • A. The desired extension naming URI
    • B. A formal reference to the publicly available specification
    • C. A short phrase describing the function of the extension
    • D. Contact information for the organization or person making the registration

For extensions defined in RFCs, the URI is recommended to be of the form urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC number of the RFC documenting the extension 🎀

  • Review process: Expert review is required. The expert review should check the following requirements:
    1. that the specification is publicly available;
    2. that the extension complies with the requirements of RTP and this specification, for extensions (notably, that the stream is still decodable if the extension is ignored or not recognized);
    3. that the extension specification is technically consistent (in itself and with RTP), complete, and comprehensible;
    4. that the extension does not duplicate functionality in existing IETF specifications (including RTP itself), or other extensions already registered;
    5. that the specification contains a security analysis regarding the content of the header extension;
    6. that the extension is generally applicable, for example point-to-multipoint safe, and the specification correctly describes limitations if they exist; and
    7. that the suggested naming URI form is appropriately chosen and unique.
  • Size and format of entries: a mapping from a naming URI string to a formal reference to a publicly available specification, with a descriptive phrase and contact information.
  • Initial assignments: none.

9.2. Registration of the SDP extmap Attribute

This section has the info [RFC4566] requires for an SDP attribute 📇

  • contact name, email address, and telephone number:
      D. Singer
      singer@apple.com
      +1 408-974-3162
  • attribute name (as it will appear in SDP): extmap
  • long-form attribute name in English: generic header extension map definition
  • type of attribute (session level, media level, or both): both
  • whether the attribute value is subject to the charset attribute: not subject to the charset attribute
  • a one-paragraph explanation of the purpose of the attribute: This attribute defines the mapping from the extension numbers used in packet headers into extension names as documented in specifications and appropriately registered.
  • a specification of appropriate attribute values for this attribute: see RFC 5285.

10. Acknowledgments 🫶

Huge thanks to Brian Link and John Lazzaro, who gave helpful comments on an early draft 💜 Colin Perkins helped review and sort out the details 🧚 Jonathan Lennox suggested using URNs for IETF-defined extensions, and Pete Cordell was key in improving the padding wording 🌷 Dave Oran gave feedback and text during review ✨ Mike Dolan contributed the two-byte header form 🦋 And Magnus Westerlund and Tom Taylor were instrumental in managing the registration text 👑

11. Normative References ✨

okay bestie, this is the reading list the whole spec leans on 📚 every one of these is pulled in to define terms, so they're kind of a big deal 💅

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑 this is the one that defines what all those capital words mean!!
  • [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. 🐢 header compression on slow links, iconic
  • [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. 🧩 sixteen authors?! that's a whole squad 🫶
  • [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 🎥 RTP, the real-time backbone, it's giving everything
  • [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003. 🏷️ the URN namespace for registered parameters, very organized of them
  • [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 🔐 SRTP! the encrypted version of RTP, security glow-up ✨
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. 🔗 the URI rulebook, everybody needs this one
  • [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 📝 SDP, the session description format that carries the signaling
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 🧾 how to write the IANA section properly, respect
  • [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 🔤 ABNF, the grammar language all those rules are written in 🧠

Authors' Addresses

okay so here are the people who wrote it, and where you can find them 🌸 these are copied exactly, so you can reach out if you ever need to 💌

David Singer
Apple, Inc.
1 Infinite Loop
Cupertino, CA  95014
USA

Phone: +1 408 996 1010
EMail: singer@apple.com
URI:   http://www.apple.com/quicktime


Harikishan Desineni
Qualcomm
5775 Morehouse Drive
San Diego, CA  92126
USA

Phone: +1 858 845 8996
EMail: hd@qualcomm.com
URI:   http://www.qualcomm.com

this part is the legal fine print, so I'm keeping it word for word 🎀 no vibes changed here, just the facts 🫶

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

the IP section is basically "we're not picking sides on patents, but here's where to look" 🦋 same facts, just in my words

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that might be claimed to apply to the technology in this document are valid or in scope, or whether any license under those rights might be available. It also doesn't claim to have independently searched for any such rights. You can find the procedures for rights in RFC documents in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, along with any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for implementers or users to use such proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org. 💜

📦 where this page comes from