RFC 5215
RTP Payload Format for Vorbis Encoded Audio
RFC 5215: RTP Payload Format for Vorbis Encoded Audio 🎀 (part 1 of 5)
okay bestie, this one is RFC 5215, and it's all about how to send Vorbis audio over RTP 🎧💖 It's a Standards Track document, written by L. Barbato from Xiph, and it's dated August 2008. The title block doesn't list any RFCs that it obsoletes or updates, so there's no drama there ✨
Status of This Memo 📜
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions so it can get even better 🌸 If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) document. Distribution of this memo is unlimited, so share it with everyone 💅
Abstract ✨
So this doc describes an RTP payload format for carrying Vorbis encoded audio 🦋 It covers the RTP encapsulation for raw Vorbis data, plus how the decoder probability model (called a codebook) and other setup info get delivered. It also includes media type registrations and the details you need to use Vorbis with the Session Description Protocol (SDP) 🎶
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conformance and Document Conventions . . . . . . . . . . . 3
2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 8
3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 10
3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 12
3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 12
3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13
4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13
5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 14
5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15
5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 19
7. SDP Related Considerations . . . . . . . . . . . . . . . . . . 20
7.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 20
7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21
7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 22
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 251. Introduction 🌈
Vorbis is a general purpose perceptual audio codec 🎵 It's built to give encoders maximum flexibility, so it can scale competitively across an exceptionally wide range of bit rates. At the high quality/bitrate end (CD or DAT rate stereo, 16/24 bits), it's in the same league as MPEG-4 AAC. Honestly, that's iconic 👑 It's also meant for lower and higher sample rates, from 8kHz telephony all the way up to 192kHz digital masters, and it handles a bunch of channel layouts: monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 discrete channels 🔥
Vorbis encoded audio normally lives inside an Ogg format bitstream [RFC3533], which handles framing and synchronization. For RTP transport, though, that layer isn't needed, so raw Vorbis packets go straight into the payload 💅
1.1. Conformance and Document Conventions 📏
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 BCP 14, [RFC2119] and indicate requirement levels for compliant implementations. Requirements apply to all implementations unless otherwise stated 🫶
An implementation is a software module that supports one of the media types defined in this document. A software module can support multiple media types, but conformance is judged individually for each type 🧚
Implementations that fail to satisfy one or more "MUST" requirements are considered non-compliant 😭 Implementations that satisfy all "MUST" requirements but fail to satisfy one or more "SHOULD" requirements are said to be "conditionally compliant". Everything else is "unconditionally compliant" ✨
2. Payload Format 🎁
For RTP-based transport of Vorbis-encoded audio, the standard RTP header is followed by a 4-octet payload header, and then the payload data. The payload header is what links the Vorbis data to its decoding codebooks, and it also says whether the packet holds fragmented Vorbis data and/or how many whole Vorbis data frames are in there 🧠 The payload data is the raw Vorbis bitstream information. There are 3 types of Vorbis data, and an RTP payload MUST contain just one of them at a time 🍓
2.1. RTP Header 💌
The format of the RTP header is specified in [RFC3550] and shown in Figure 1. This payload format uses the header fields in a way that's consistent with that spec 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: RTP Header
The RTP header starts with an octet of fields (V, P, X, and CC) that support specialized RTP uses (see [RFC3550] and [RFC3551] for details). For Vorbis RTP, these values are used 📦
Version (V): 2 bits
This field identifies the version of RTP. The version used by this specification is two (2). Two, always and forever 💖
Padding (P): 1 bit
Padding MAY be used with this payload format according to Section 5.1 of [RFC3550] 🫧
Extension (X): 1 bit
The Extension bit is used in accordance with [RFC3550] 🧩
CSRC count (CC): 4 bits
The CSRC count is used in accordance with [RFC3550] 🔢
Marker (M): 1 bit
Set to zero. Audio silence suppression is not used. This conforms to Section 4.1 of [VORBIS-SPEC-REF] 🤫
Payload Type (PT): 7 bits
An RTP profile for a class of applications is expected to assign a payload type for this format. Otherwise, a dynamically allocated payload type SHOULD be chosen that designates the payload as Vorbis 🏷️
Sequence number: 16 bits
The sequence number goes up by one for each RTP data packet sent. The receiver may use it to detect packet loss and to restore the packet sequence. This field is detailed further in [RFC3550] 🔁
Timestamp: 32 bits
A timestamp representing the sampling time of the first sample of the first Vorbis packet in the RTP payload. The clock frequency MUST be set to the sample rate of the encoded audio data, and it's conveyed out-of-band (e.g., as an SDP parameter) ⏰
SSRC/CSRC identifiers:
These two fields are 32 bits each. There's one SSRC field and a maximum of 16 CSRC fields, and they're defined in [RFC3550] 🪪
2.2. Payload Header 🧾
The 4 octets right after the RTP Header section are the Payload Header. This header is split into a number of bit fields that describe the format of the payload data packets that follow ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | F |VDT|# pkts.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: Payload Header
Ident: 24 bits
This 24-bit field links the Vorbis data to a decoding Configuration. It's stored as a network byte order integer 🔑
Fragment type (F): 2 bits
This field is set according to the following list:
0 = Not Fragmented1 = Start Fragment2 = Continuation Fragment3 = End Fragment
Vorbis Data Type (VDT): 2 bits
This field says what kind of Vorbis data is stored in this RTP packet. There are currently three different types of Vorbis payloads. Each packet MUST contain only a single type of Vorbis packet (e.g., you must not aggregate configuration and comment packets in the same RTP payload) 🚫
0 = Raw Vorbis payload1 = Vorbis Packed Configuration payload2 = Legacy Vorbis Comment payload3 = Reserved
The packets with a VDT of value 3 MUST be ignored. Reserved means reserved, bestie, so skip them 🙈
The last 4 bits represent the number of complete packets in this payload. That gives a maximum of 15 Vorbis packets per payload 🧁 If the payload contains fragmented data, the number of packets MUST be set to 0.
Part 1 ends here, but the story keeps going in part 2 💜
2.3. Payload Data
okay bestie, raw Vorbis packets have no set length limit rn, so application profiles will probably be the ones to set a practical cap 🎀 Typical packets are tiny (2-3 bytes) or chonky (8-12 kilobytes). The reference implementation [LIBVORBIS] usually makes packets under ~800 bytes, except the setup header packets, which land around ~4-12 kilobytes 📦 For RTP, you SHOULD keep each Vorbis data packet small enough that once you add the RTP and payload headers, the whole RTP packet is smaller than the path MTU. That's how you dodge fragmentation, and it's giving "pack your bags before the trip" energy 🧳✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis packet data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Payload Data Header 🌸
Every Vorbis payload packet kicks off with a two octet length header 💖 That number tells you how many bytes of raw Vorbis data come next, and the data gets padded out to the nearest byte boundary, as the Vorbis I Specification [VORBIS-SPEC-REF] explains. The length is stored as a network byte order integer, so read it in network order, bestie 🤓
When a payload has multiple Vorbis packets, it's just the packet length followed by the packet data, over and over, for each packet in there 🍓 And the Vorbis packet length header covers only the Vorbis data block. It does NOT count the length field itself. Lowkey a very important detail 👀
Now the packing rules: the payload packing of the Vorbis data packets MUST follow the guidelines in [RFC3551], with the oldest Vorbis packet sitting right after the RTP packet header. Any later Vorbis packets MUST follow in temporal order 🕰️💜 No shuffling!
Audio channel mapping follows the Vorbis I Specification [VORBIS-SPEC-REF], so that's where you go for those details 🎧
2.4. Example RTP Packet
Here's a sample RTP payload with two Vorbis packets in it, so you can see the whole vibe 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0|0| 0 |0| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (in sample rate units) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronisation source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 0 | 2 pks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | next vorbis packet data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Example Raw Vorbis Packet 💅
So the payload data section starts with the 24-bit Ident field, then a one octet bit field header 🎀 In this example, that header says the number of Vorbis frames is 2. Each Vorbis data frame gets its own two octet length field in front of it. The Packet Type and Fragment Type are both set to 0. And the Configuration used to decode these packets is the one indexed by the ident value 🗝️✨
3. Configuration Headers
Okay, this part is the main character moment 👑 Vorbis is different from the other mainstream audio codecs, because it has no statically configured probability model. Instead, it bundles all the entropy decoding configuration, Vector Quantization and Huffman models into one data block that has to get sent to the decoder alongside the compressed data 📚 The decoder also needs stuff like the number of audio channels, bitrates, and similar info so it can set itself up for that particular stream 🎧 People often call these two blocks together the "codebooks" for a Vorbis stream. They show up as special "header" packets right at the start of the compressed data. The Vorbis I specification [VORBIS-SPEC-REF] also requires a comment header packet with simple metadata about the stream, but that info isn't needed to decode the frame sequence, so it's not a dealbreaker 🌈
So, the two codebook header packets must be received by the decoder before any audio data can be interpreted. Here's the tea: RTP is often used over unreliable transports 💀 That's a real problem, because these headers have to get there reliably, and you can't just hope they arrive.
Since this info must be sent reliably, and the RTP stream might change some configuration data mid-session, there are different ways to deliver it to a client. Some are in-band, some are out-of-band, and we'll go through them below 🦋 To set up the client's initial state, the configuration MUST be conveyed through the signalling channel used to set up the session. One example is SDP [RFC4566] with the Offer/Answer Model [RFC3264]. Changes to the configuration MAY be communicated with a re-invite that carries a new SDP, or they can be sent in-band in the RTP channel. Implementations MUST support in-band delivery of updated codebooks, and they SHOULD support out-of-band codebook updates using a new SDP file 💜 The changes might come from different codebooks, or from different bitrates of the RTP stream.
For non-chained streams, the recommended way to deliver the Configuration is inside the Packed Configuration (Section 3.1.1) in the SDP, as explained in Mapping Media Type Parameters into SDP (Section 7.1) 🍓
The 24-bit Ident field tells the decoder which Configuration to use for a packet. When the Ident field changes, that means something in the stream has changed 🔥 The client application MUST already have the correct configuration on hand. If the client notices the Ident value changed and doesn't have that info, it MUST NOT decode the raw Vorbis data tied to it until it fetches the correct Configuration. No decoding with vibes alone 🙅♀️
3.1. In-band Header Transmission
The Packed Configuration (Section 3.1.1) Payload gets sent in-band, with the packet type bits set to match the Vorbis Data Type 🧚 Clients MUST be able to handle fragmentation and periodic re-transmission of the configuration headers [RFC4588]. And the RTP timestamp value MUST reflect the transmission time of the first data packet this configuration applies to ⏰✨
3.1.1. Packed Configuration 🎀
okay so a Vorbis Packed Configuration gets flagged by setting the Vorbis Data Type field to 1 💅. Of the three headers in the Vorbis I spec [VORBIS-SPEC-REF] (the big official doc, iykyk), the Identification and the Setup MUST be packed as they are, while the Comment header MAY be swapped out for a dummy one 🧚
The packed configuration is basically a generic way to store Xiph codec configs 💖 The first field is a count of how many packets follow, minus one (that's the count field). Then come the sizes of the headers (the length fields), and the actual headers show up right after that list. The size of the last header isn't stored at all because it can be figured out from the rest ✨
Now the count and length fields use a little encoding trick, and it's kind of genius 🦋 Everything is in network byte order, and every byte uses its most significant bit as a flag. The other 7 bits hold the actual value. The first 7 most significant bits go in the first byte. If there are bits left over, the flag bit gets set to 1 and the next 7 bits go in the following byte. If there are still bits left, you set the flag to 1 again and repeat the whole thing. The last byte has its flag set to 0, which is how you know you're done 🙈 To decode, you just keep reading bytes until you hit a flag of 0. For each byte, you add its data to the running total after multiplying that total by 128 💜
The headers are packed in the same order they show up in Ogg [VORBIS-SPEC-REF]: Identification, Comment, Setup 🌸
The 2 byte length tag holds the length of the packed headers, and that length is the sum of the Configuration, Comment, and Setup lengths 🍓
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | xxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| xxxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 1 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | n. of headers | length1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length2 | Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification | Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment | Setup ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Setup ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Setup ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Packed Configuration Figure
The Ident field gets set to the value the Raw Payload Packets will use to refer to this Configuration 🔥 The Fragment type is set to 0 because this packet carries the full Packed configuration. The number of the packet is set to 1 👑
3.2. Out of Band Transmission 🌈
The following packet definition MUST be used when the Configuration is inside the SDP 💜
3.2.1. Packed Headers 🧚
As mentioned above, the RECOMMENDED delivery vector for Vorbis configuration data is a retrieval method that runs over a reliable transport protocol 🫶 Since RTP headers aren't needed for this method of delivery, the structure of the configuration data is a bit different. The packed header starts with a 32-bit (network-byte ordered) count field, which tells you how many packed headers are in the bundle. Here's the Packed header payload for each chained Vorbis stream ✨
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of packed headers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packed header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packed header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Packed Headers Overview
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | length ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. | n. of headers | length1 | length2 ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. | Identification Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................................................................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. | Comment Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................................................................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................................................................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Setup Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Packed Headers Detail
The big difference between the in-band format and this one is that there's no payload header octet 🙈 In this figure, the comment is bigger than 127 bytes, so it's giving long comment energy 💅
3.3. Loss of Configuration Headers 💀
Unlike losing raw Vorbis payload data, losing a configuration header is a whole different vibe. It means the stream can't be decoded successfully anymore 😭 Implementations MAY try to recover by requesting the missing Configuration again or, if the delivery method is in-band, by buffering the payloads while they wait for the Configuration needed to decode them. The baseline reaction SHOULD either be a reset or ending the RTP session 🥀
4. Comment Headers 💬
A Vorbis Data Type flag set to 2 means the packet holds comment metadata, like artist name, track title, and so on 🎵 These metadata messages aren't meant to be fully descriptive. They're more like basic track or song info. Clients MAY ignore it completely 🫠 The details on the format of the comments can be found in the Vorbis I Specification [VORBIS-SPEC-REF] 📖
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | xxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| xxxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 2 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: Comment Packet
The 2-byte length field is necessary since this packet could be fragmented 🧩
5. Frame Packetization 🌸
Each RTP payload holds either one Vorbis packet fragment or a whole number of complete Vorbis packets. The max is 15 packets, since the number of packets is a 4-bit value 🔢
Any Vorbis data packet smaller than the path MTU SHOULD be bundled in the RTP payload with as many Vorbis packets as will fit, up to a max of 15 📦 The exception is when that bundling would go over an application's desired transmission latency ⏱️ Path MTU is detailed in [RFC1191] and [RFC1981] 🦋
A fragmented packet has zeros in the last four bits of the payload header 🙌 The first fragment sets the Fragment type to 1. Every fragment after the first sets the Fragment type to 2 in the payload header. The consecutive fragments MUST be sent without any other payload in between the first and the last fragment, no exceptions 🚫 The RTP payload with the last fragment of the Vorbis packet has its Fragment type set to 3. To keep the sequence right for reception of fragmented packets, the timestamp field of fragmented packets MUST be the same as the first packet sent, while the sequence number increments as normal for the later RTP payloads. This will affect the RTCP jitter measurement 📊 The length field shows the fragment length 💖
5.1. Example Fragmented Vorbis Packet ✨
okay so here's a fragmented Vorbis packet getting split across three RTP payloads 🎀 Every single one has the standard RTP headers AND the 4-octet Vorbis headers, so nothing gets left out, bestie 💅
Packet 1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 1 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Example Fragmented Packet (Packet 1)in this payload the initial sequence number is 1000 and the timestamp is 12345 🌸 the Fragment type is set to 1, the number of packets field is set to 0, and since the payload is raw Vorbis data, the VDT field is set to 0 🧚
Packet 2:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 2 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Example Fragmented Packet (Packet 2)the Fragment type field is set to 2, and the number of packets field is set to 0 💜 for large Vorbis fragments there can be several of these types of payloads, so it's giving multi-part energy 🦋 the maximum packet size SHOULD be no greater than the path MTU, including all RTP and payload headers ✨ also the sequence number has been incremented by one, but the timestamp field stays the same as the initial payload ⭐
Packet 3:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 1002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 3 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Example Fragmented Packet (Packet 3)and this is the last Vorbis fragment payload 🫶 the Fragment type is set to 3 and the packet count stays at 0 🌈 same as before, the timestamp stays on the first payload's timestamp and the sequence number gets bumped up 🔥
5.2. Packet Loss
no error correction in the Vorbis stream, bestie, so if packets go missing you get a loss of signal 😭 fragmented Vorbis is even more of a mess, because the client has to handle the Fragment Type stuff too 💀
if fragments get lost, the client MUST discard all the remaining Vorbis fragments and decode the incomplete packet 🙈 so say we use the fragmented example above and the first RTP payload is lost. the client MUST detect that the next RTP payload has the packet count field set to 0 and the Fragment type 2, and MUST drop it 🥺 the next RTP payload, which is the final fragment, MUST be dropped in the same manner 💅 and if the missing RTP payload is the last one, the two fragments that came through are kept and the incomplete Vorbis packet gets decoded ✨
losing any Configuration fragment means losing the whole Configuration packet, and the result is detailed in the Loss of Configuration Headers (Section 3.3) section 👑
6. IANA Considerations 🎀
Type name: audio
Subtype name: vorbis
Required parameters:
rate: indicates the RTP timestamp clock rate as described in RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551].channels: indicates the number of audio channels as described in RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551].configuration: the base64 [RFC4648] representation of the Packed Headers (Section 3.2.1).
Encoding considerations: this media type is framed and contains binary data 🍓
Security considerations: see Section 10 of RFC 5215.
Interoperability considerations: None
Published specification:
- RFC 5215
- Ogg Vorbis I specification: Codec setup and packet decode. Available from the Xiph website,
http://xiph.org/
Applications which use this media type: audio streaming and conferencing tools 🎧
Additional information: None
Person & email address to contact for further information:
- Luca Barbato:
<lu_zero@gentoo.org> - IETF Audio/Video Transport Working Group
Intended usage: COMMON
Restriction on usage: this media type depends on RTP framing, so it's only defined for transfer via RTP [RFC3550] 🦋
Author: Luca Barbato
Change controller: IETF AVT Working Group delegated from the IESG
6.1. Packed Headers IANA Considerations
okay so this bit covers the split configuration Packed Headers (Section 3.2.1) used within RFC 5215 🌸
Type name: audio
Subtype name: vorbis-config
Required parameters: None
Optional parameters: None
Encoding considerations: this media type contains binary data.
Security considerations: see Section 10 of RFC 5215.
Interoperability considerations: None
Published specification: RFC 5215
Applications which use this media type: Vorbis encoded audio, configuration data 🎶
Additional information: None
Person & email address to contact for further information:
- Luca Barbato:
<lu_zero@gentoo.org> - IETF Audio/Video Transport Working Group
Intended usage: COMMON
Restriction on usage: this media type doesn't depend on the transport 🧚
Author: Luca Barbato
Change controller: IETF AVT Working Group delegated from the IESG
7. SDP Related Considerations 💖
these paragraphs define how the parameters from the IANA section get mapped into SDP and how they're used in the Offer/Answer Model [RFC3264] 🫶 the implementation MUST ignore unknown parameters so it stays forward compatible, periodt 💅
7.1. Mapping Media Type Parameters into SDP
the info in the Media Type spec has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is what people usually use to describe RTP sessions 🌈 when SDP is used to specify sessions, the mapping goes like this:
- the type name ("audio") goes in SDP "m=" as the media name.
- the subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding name.
- the parameter "rate" also goes in "a=rtpmap" as the clock rate.
- the parameter "channels" also goes in "a=rtpmap" as the channel count.
- the mandated parameter "configuration" MUST be included in the SDP "a=fmtp" attribute.
if the stream is made of chained Vorbis files and you know all of them ahead of time, the Configuration Packet for each file SHOULD be passed to the client using the configuration attribute 🍓
the port value is set by the server application bound to the address in the c= line ✨ the channel count in the rtpmap attribute SHOULD match the current Vorbis stream, or it should be treated as the max number of channels to expect 🌸 the timestamp clock rate MUST be a multiple of the sample rate, and a different payload number MUST be used if the clock rate changes 🔥 the Configuration payload gives the exact info, so the SDP info SHOULD be considered a hint 🧚 here's an example:
7.1.1. SDP Example
this is a basic SDP single stream 💅 the first configuration packet is inside the SDP, and other configurations can be fetched any time from the URIs provided 🦋 the base64 [RFC4648] configuration string below is folded in this example because of RFC line length limits 🙈
c=IN IP4 192.0.2.1
m=audio RTP/AVP 98
a=rtpmap:98 vorbis/44100/2
a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...;quick note, the payload format (encoding) names are usually written in uppercase, and Media Type subtypes are usually lowercase 💜 they're case-insensitive in both places, and parameter names are case-insensitive too, both in Media Type types and in the default mapping to the SDP a=fmtp attribute 🎀 the a=fmtp line is a single line, even though it's shown across multiple lines in this document for clarity 🌈
7.2. Usage with the SDP Offer/Answer Model
no negotiable parameters here 🫶 they're all declarative, so what you see is what you get 👑
8. Congestion Control 🌊
Okay so the general congestion control stuff for sending RTP data totally applies to Vorbis audio over RTP too, bestie. Check out the RTP specification [RFC3550] and any RTP profile that applies to you (like [RFC3551]). Audio can be encoded at a whole range of bit rates, so it's possible to adapt your network bandwidth by adjusting the encoder bit rate in real time, or by having multiple copies of the same content encoded at different bit rates. Adaptive queen behavior 👑
9. Example 🎀
The following example shows a common usage pattern that MAY be applied in such a situation. Like, the main point of this section is to explain better usage of the transmission vectors 💅
9.1. Stream Radio 📻
This is one of the most common situations, no cap 🫶 There's one single server streaming content in multicast, and the clients may start a session at a random time. The content itself could be a mix of a live stream (the webjockey's voice) and stored streams (the music she plays) 🎧
In this situation, we don't know in advance how many codebooks we will use. The clients can join anytime, and users expect to start listening to the content in a short time ⏱️
Upon joining, the client will receive the current Configuration necessary to decode the current stream inside the SDP, so the decoding will start immediately after ✨
When the streamed content changes, the new Configuration is sent in-band before the actual stream, and the Configuration that has to be sent inside the SDP is updated. Since the in-band method is unreliable, an out-of-band fallback is provided 🦋
The client may choose to fetch the Configuration from the alternate source as soon as it discovers a Configuration packet got lost in-band, or use selective retransmission [RFC3611] if the server supports this feature. It's giving backup plan energy 🧚
A server-side optimization would be to keep a hash list of the Configurations per session. That way it avoids packing all of them and sending the same Configuration with different Ident tags 🍓
A client-side optimization would be to keep a tag list of the Configurations per session and not process configuration packets that are already known. Iconic, lowkey genius 🌸
10. Security Considerations 🔐
Okay, this section is serious, so pay attention 😭 RTP packets using this payload format are subject to the security considerations discussed in the RTP specification [RFC3550], the base64 specification [RFC4648], and the URI Generic syntax specification [RFC3986].
Among other considerations, this implies that the confidentiality of the media stream is achieved by using encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed on the compressed data 🔒
11. Copying Conditions 📜
The authors agree to grant third parties the irrevocable right to copy, use, and distribute the work, with or without modification, in any medium, without royalty. This is provided that, unless separate permission is granted, redistributed modified works do not contain misleading author, version, name of work, or endorsement information 💖
12. Acknowledgments 🫶
This document is a continuation of the following documents:
Moffitt, J., "RTP Payload Format for Vorbis Encoded Audio", February 2001.
Kerr, R., "RTP Payload Format for Vorbis Encoded Audio", December 2004.
The Media Type declaration is a continuation of the following document:
Short, B., "The audio/rtp-vorbis MIME Type", January 2008.
Thanks to the AVT, Vorbis Communities / Xiph.Org Foundation including Steve Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro, Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short, Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David Barrett, Silvia Pfeiffer, Stefan Ehmann, Gianni Ceccarelli, and Alessandro Salvatori. Thanks to the LScube Group, in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Dario Gallucci, and Juan Carlos De Martin. Y'all are the real ones 🌈
13. References 📚
13.1. Normative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[VORBIS-SPEC-REF] "Ogg Vorbis I specification: Codec setup and packet decode. Available from the Xiph website, http://xiph.org/vorbis/doc/Vorbis_I_spec.html".
13.2. Informative References
[LIBVORBIS] "libvorbis: Available from the dedicated website, http://vorbis.com/".
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", RFC 3533, May 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
Author's Address 🖋️
Luca Barbato Xiph.Org Foundation
EMail: lu_zero@gentoo.org URI: http://xiph.org/
Full Copyright Statement ⚖️
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 IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. ✨
📦 where this page comes from
- ietf: rfc5215 2008-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms