Network Working Group L. Barbato
Request for Comments: 5215 Xiph
Category: Standards Track August 2008
Network Working Group L. Barbato
Request for Comments: 5215 Xiph
Category: Standards Track August 2008
RTP Payload Format for Vorbis Encoded Audio
Vorbis编码音频的RTP有效负载格式
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.
本文档描述了用于传输Vorbis编码音频的RTP有效负载格式。它详细介绍了原始Vorbis数据的RTP封装机制和解码器概率模型（称为码本）的交付机制，以及其他设置信息。
Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session Description Protocol (SDP).
本备忘录还包括媒体类型注册和Vorbis与会话描述协议（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 . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . 25
Vorbis is a general purpose perceptual audio codec intended to allow maximum encoder flexibility, thus allowing it to scale competitively over an exceptionally wide range of bit rates. At the high quality/ bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is in the same league as MPEG-4 AAC. Vorbis is also intended for lower and higher sample rates (from 8kHz telephony to 192kHz digital masters) and a range of channel representations (monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 discrete channels).
Vorbis是一种通用感知音频编解码器，旨在实现编码器的最大灵活性，从而使其能够在极宽的比特率范围内进行竞争性扩展。在音阶的高质量/比特率端（CD或DAT速率立体声，16/24位），它与MPEG-4 AAC处于同一级别。Vorbis还适用于更低和更高的采样率（从8kHz电话到192kHz数字主控）和一系列通道表示（单声道、复调、立体声、四声道、5.1声道、双声道或最多255个离散通道）。
Vorbis encoded audio is generally encapsulated within an Ogg format bitstream [RFC3533], which provides framing and synchronization. For the purposes of RTP transport, this layer is unnecessary, and so raw Vorbis packets are used in the payload.
Vorbis编码音频通常封装在Ogg格式的比特流[RFC3533]中，该比特流提供帧和同步。为了RTP传输的目的，该层是不必要的，因此在有效载荷中使用原始Vorbis数据包。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、[RFC2119]中的描述进行解释，并指出合规实施的要求级别。除非另有说明，否则要求适用于所有实现。
An implementation is a software module that supports one of the media types defined in this document. Software modules may support multiple media types, but conformance is considered 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". All other implementations are "unconditionally compliant".
未能满足一个或多个“必须”要求的实现被视为不符合要求。满足所有“必须”要求，但未能满足一个或多个“应该”要求的实现称为“有条件兼容”。所有其他实现都是“无条件兼容的”。
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 headers are used to associate the Vorbis data with its associated decoding codebooks as well as indicate if the following packet contains fragmented Vorbis data and/or the number of whole Vorbis data frames. The payload data contains the raw Vorbis bitstream information. There are 3 types of Vorbis data; an RTP payload MUST contain just one of them at a time.
对于基于RTP的Vorbis编码音频传输，标准RTP报头后面跟着一个4-octet有效负载报头，然后是有效负载数据。有效载荷报头用于将Vorbis数据与其相关联的解码码本相关联，以及指示以下分组是否包含分段的Vorbis数据和/或整个Vorbis数据帧的数目。有效负载数据包含原始Vorbis比特流信息。Vorbis数据有3种类型；RTP有效负载一次只能包含其中一个。
The format of the RTP header is specified in [RFC3550] and shown in Figure 1. This payload format uses the fields of the header in a manner consistent with that specification.
RTP头的格式在[RFC3550]中指定，如图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 | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图1:RTP报头
The RTP header begins with an octet of fields (V, P, X, and CC) to support specialized RTP uses (see [RFC3550] and [RFC3551] for details). For Vorbis RTP, the following values are used.
RTP报头以八位字段（V、P、X和CC）开头，以支持专门的RTP使用（有关详细信息，请参阅[RFC3550]和[RFC3551]）。对于Vorbis RTP，使用以下值。
Version (V): 2 bits
版本（V）：2位
This field identifies the version of RTP. The version used by this specification is two (2).
此字段标识RTP的版本。本规范使用的版本为二（2）。
Padding (P): 1 bit
填充（P）：1位
Padding MAY be used with this payload format according to Section 5.1 of [RFC3550].
根据[RFC3550]第5.1节，填充可与该有效载荷格式一起使用。
Extension (X): 1 bit
扩展（X）：1位
The Extension bit is used in accordance with [RFC3550].
根据[RFC3550]使用扩展位。
CSRC count (CC): 4 bits
CSC计数（CC）：4位
The CSRC count is used in accordance with [RFC3550].
根据[RFC3550]使用中国证监会计数。
Marker (M): 1 bit
标记（M）：1位
Set to zero. Audio silence suppression is not used. This conforms to Section 4.1 of [VORBIS-SPEC-REF].
设置为零。不使用音频静音抑制。这符合[VORBIS-SPEC-REF]第4.1节的规定。
Payload Type (PT): 7 bits
有效负载类型（PT）：7位
An RTP profile for a class of applications is expected to assign a payload type for this format, or a dynamically allocated payload type SHOULD be chosen that designates the payload as Vorbis.
一类应用程序的RTP配置文件预计将为此格式分配有效负载类型，或者应选择动态分配的有效负载类型，将有效负载指定为Vorbis。
Sequence number: 16 bits
序列号：16位
The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore the packet sequence. This field is detailed further in [RFC3550].
对于发送的每个RTP数据分组，序列号增加1，并且可由接收器用于检测分组丢失和恢复分组序列。该字段在[RFC3550]中有详细说明。
Timestamp: 32 bits
时间戳：32位
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 is conveyed out-of-band (e.g., as an SDP parameter).
表示RTP有效载荷中第一Vorbis分组的第一样本的采样时间的时间戳。时钟频率必须设置为编码音频数据的采样率，并在带外传输（例如，作为SDP参数）。
SSRC/CSRC identifiers:
SSRC/CSRC标识符：
These two fields, 32 bits each with one SSRC field and a maximum of 16 CSRC fields, are as defined in [RFC3550].
这两个字段为32位，每个字段有一个SSRC字段，最多16个CSC字段，如[RFC3550]中所定义。
The 4 octets following the RTP Header section are the Payload Header. This header is split into a number of bit fields detailing the format of the following payload data packets.
RTP报头部分后面的4个八位字节是有效负载报头。该报头分为多个位字段，详细说明以下有效负载数据包的格式。
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.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图2：有效载荷头
Ident: 24 bits
标识：24位
This 24-bit field is used to associate the Vorbis data to a decoding Configuration. It is stored as a network byte order integer.
该24位字段用于将Vorbis数据与解码配置相关联。它存储为网络字节顺序整数。
Fragment type (F): 2 bits
片段类型（F）：2位
This field is set according to the following list:
根据以下列表设置此字段：
0 = Not Fragmented
0 = Not Fragmented
1 = Start Fragment
1 = Start Fragment
2 = Continuation Fragment
2 = Continuation Fragment
3 = End Fragment
3 = End Fragment
Vorbis Data Type (VDT): 2 bits
Vorbis数据类型（VDT）：2位
This field specifies the kind of Vorbis data 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).
此字段指定存储在此RTP数据包中的Vorbis数据类型。目前有三种不同类型的Vorbis有效载荷。每个数据包必须仅包含单一类型的Vorbis数据包（例如，您不得在同一RTP有效负载中聚合配置和注释数据包）。
0 = Raw Vorbis payload
0 = Raw Vorbis payload
1 = Vorbis Packed Configuration payload
1 = Vorbis Packed Configuration payload
2 = Legacy Vorbis Comment payload
2 = Legacy Vorbis Comment payload
3 = Reserved
3 = Reserved
The packets with a VDT of value 3 MUST be ignored.
VDT值为3的数据包必须忽略。
The last 4 bits represent the number of complete packets in this payload. This provides for a maximum number of 15 Vorbis packets in the payload. If the payload contains fragmented data, the number of packets MUST be set to 0.
最后4位表示此有效负载中完整数据包的数量。这在有效负载中提供了最多15个Vorbis数据包。如果有效负载包含碎片数据，则数据包数必须设置为0。
Raw Vorbis packets are currently unbounded in length; application profiles will likely define a practical limit. Typical Vorbis packet sizes range from very small (2-3 bytes) to quite large (8-12 kilobytes). The reference implementation [LIBVORBIS] typically produces packets less than ~800 bytes, except for the setup header packets, which are ~4-12 kilobytes. Within an RTP context, to avoid fragmentation, the Vorbis data packet size SHOULD be kept sufficiently small so that after adding the RTP and payload headers, the complete RTP packet is smaller than the path MTU.
原始Vorbis数据包当前长度无限制；应用程序配置文件可能会定义一个实际限制。典型的Vorbis数据包大小从非常小（2-3字节）到非常大（8-12千字节）。参考实现[LIBVORBIS]通常产生小于约800字节的数据包，但设置头数据包除外，这些数据包约为4-12千字节。在RTP上下文中，为了避免碎片，Vorbis数据包大小应保持足够小，以便在添加RTP和有效负载报头后，完整的RTP包小于路径MTU。
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 ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图3：有效载荷数据头
Each Vorbis payload packet starts with a two octet length header, which is used to represent the size in bytes of the following data payload, and is followed by the raw Vorbis data padded to the nearest byte boundary, as explained by the Vorbis I Specification [VORBIS-SPEC-REF]. The length value is stored as a network byte order integer.
每个Vorbis有效载荷数据包以两个八位组长度的报头开始，该报头用于表示以下数据有效载荷的字节大小，然后是填充到最近字节边界的原始Vorbis数据，如Vorbis I规范[Vorbis-SPEC-REF]所述。长度值存储为网络字节顺序整数。
For payloads that consist of multiple Vorbis packets, the payload data consists of the packet length followed by the packet data for each of the Vorbis packets in the payload.
对于由多个Vorbis数据包组成的有效载荷，有效载荷数据由数据包长度和有效载荷中每个Vorbis数据包的数据包数据组成。
The Vorbis packet length header is the length of the Vorbis data block only and does not include the length field.
Vorbis数据包长度报头仅为Vorbis数据块的长度，不包括长度字段。
The payload packing of the Vorbis data packets MUST follow the guidelines set out in [RFC3551], where the oldest Vorbis packet occurs immediately after the RTP packet header. Subsequent Vorbis packets, if any, MUST follow in temporal order.
Vorbis数据包的有效载荷包装必须遵循[RFC3551]中规定的指南，其中最早的Vorbis数据包出现在RTP数据包头之后。后续Vorbis数据包（如果有）必须按照时间顺序进行。
Audio channel mapping is in accordance with the Vorbis I Specification [VORBIS-SPEC-REF].
音频通道映射符合Vorbis I规范[Vorbis-SPEC-REF]。
Here is an example RTP payload containing two Vorbis packets.
下面是一个包含两个Vorbis数据包的示例RTP有效负载。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图4：示例原始Vorbis数据包
The payload data section of the RTP packet begins with the 24-bit Ident field followed by the one octet bit field header, which has the number of Vorbis frames set to 2. Each of the Vorbis data frames is prefixed by the two octets length field. The Packet Type and Fragment Type are set to 0. The Configuration that will be used to decode the packets is the one indexed by the ident value.
RTP数据包的有效负载数据部分以24位Ident字段开始，然后是一个八位字段头，其Vorbis帧数设置为2。每个Vorbis数据帧的前缀是两个八位字节长度字段。数据包类型和片段类型设置为0。用于解码数据包的配置是由ident值索引的配置。
Unlike other mainstream audio codecs, Vorbis has no statically configured probability model. Instead, it packs all entropy decoding configuration, Vector Quantization and Huffman models into a data block that must be transmitted to the decoder with the compressed data. A decoder also requires information detailing the number of audio channels, bitrates, and similar information to configure itself for a particular compressed data stream. These two blocks of
与其他主流音频编解码器不同，Vorbis没有静态配置的概率模型。相反，它将所有熵解码配置、矢量量化和哈夫曼模型打包到一个数据块中，该数据块必须与压缩数据一起传输到解码器。解码器还需要详细说明音频通道数、比特率和类似信息的信息，以便为特定压缩数据流配置自身。这两块
information are often referred to collectively as the "codebooks" for a Vorbis stream, and are included as special "header" packets at the start of the compressed data. In addition, the Vorbis I specification [VORBIS-SPEC-REF] requires the presence of a comment header packet that gives simple metadata about the stream, but this information is not required for decoding the frame sequence.
信息通常被统称为Vorbis流的“码本”，并且在压缩数据的开始处被包括为特殊的“报头”分组。此外，Vorbis I规范[Vorbis-SPEC-REF]要求存在注释报头分组，该分组给出关于流的简单元数据，但是解码帧序列不需要该信息。
Thus, these two codebook header packets must be received by the decoder before any audio data can be interpreted. These requirements pose problems in RTP, which is often used over unreliable transports.
因此，解码器必须先接收这两个码本头数据包，然后才能解释任何音频数据。这些需求在RTP中带来了问题，RTP通常用于不可靠的传输。
Since this information must be transmitted reliably and, as the RTP stream may change certain configuration data mid-session, there are different methods for delivering this configuration data to a client, both in-band and out-of-band, which are detailed below. In order to set up an initial state for the client application, the configuration MUST be conveyed via the signalling channel used to set up the session. One example of such signalling is SDP [RFC4566] with the Offer/Answer Model [RFC3264]. Changes to the configuration MAY be communicated via a re-invite, conveying a new SDP, or sent in-band in the RTP channel. Implementations MUST support an in-band delivery of updated codebooks, and SHOULD support out-of-band codebook update using a new SDP file. The changes may be due to different codebooks as well as different bitrates of the RTP stream.
由于必须可靠地传输该信息，并且由于RTP流可能在会话中改变某些配置数据，因此存在用于将该配置数据传送到客户端的不同方法，包括带内和带外，下面详细说明。为了为客户机应用程序设置初始状态，必须通过用于设置会话的信令信道传输配置。这种信令的一个示例是具有提供/应答模型[RFC3264]的SDP[RFC4566]。对配置的更改可以通过重新邀请、传送新的SDP或在RTP信道中带内发送来进行通信。实现必须支持带内交付更新的代码本，并应支持使用新SDP文件进行带外代码本更新。这些变化可能是由于不同的码本以及RTP流的不同比特率造成的。
For non-chained streams, the recommended Configuration delivery method is inside the Packed Configuration (Section 3.1.1) in the SDP as explained the Mapping Media Type Parameters into SDP (Section 7.1).
对于非链式流，推荐的配置交付方法位于SDP中的打包配置（第3.1.1节）内，如将介质类型参数映射到SDP（第7.1节）中所述。
The 24-bit Ident field is used to map which Configuration will be used to decode a packet. When the Ident field changes, it indicates that a change in the stream has taken place. The client application MUST have in advance the correct configuration. If the client detects a change in the Ident value and does not have this information, it MUST NOT decode the raw associated Vorbis data until it fetches the correct Configuration.
24位标识字段用于映射将用于解码数据包的配置。当Ident字段更改时，表示流中发生了更改。客户端应用程序必须事先具有正确的配置。如果客户机检测到Ident值发生变化且没有此信息，则在获取正确配置之前，不得解码原始关联的Vorbis数据。
The Packed Configuration (Section 3.1.1) Payload is sent in-band with the packet type bits set to match the Vorbis Data Type. Clients MUST be capable of dealing with fragmentation and periodic re-transmission of [RFC4588] the configuration headers. The RTP timestamp value MUST reflect the transmission time of the first data packet for which this configuration applies.
打包配置（第3.1.1节）有效载荷在带内发送，分组类型位设置为与Vorbis数据类型匹配。客户端必须能够处理[RFC4588]配置头的碎片和定期重新传输。RTP时间戳值必须反映此配置适用的第一个数据包的传输时间。
A Vorbis Packed Configuration is indicated with the Vorbis Data Type field set to 1. Of the three headers defined in the Vorbis I specification [VORBIS-SPEC-REF], the Identification and the Setup MUST be packed as they are, while the Comment header MAY be replaced with a dummy one.
Vorbis压缩配置显示为Vorbis数据类型字段设置为1。在Vorbis I规范[Vorbis-SPEC-REF]中定义的三个标题中，标识和设置必须按原样打包，而注释标题可以替换为虚拟标题。
The packed configuration stores Xiph codec configurations in a generic way: the first field stores the number of the following packets minus one (count field), the next ones represent the size of the headers (length fields), and the headers immediately follow the list of length fields. The size of the last header is implicit.
打包配置以通用方式存储Xiph编解码器配置：第一个字段存储以下数据包的数量减去一（计数字段），下一个字段表示头的大小（长度字段），头紧跟在长度字段列表之后。最后一个标头的大小是隐式的。
The count and the length fields are encoded using the following logic: the data is in network byte order; every byte has the most significant bit used as a flag, and the following 7 bits are used to store the value. The first 7 most significant bits are stored in the first byte. If there are remaining bits, the flag bit is set to 1 and the subsequent 7 bits are stored in the following byte. If there are remaining bits, set the flag to 1 and the same procedure is repeated. The ending byte has the flag bit set to 0. To decode, simply iterate over the bytes until the flag bit is set to 0. For every byte, the data is added to the accumulated value multiplied by 128.
计数和长度字段使用以下逻辑进行编码：数据按网络字节顺序；每个字节都有最高有效位用作标志，下面7位用于存储值。前7个最高有效位存储在第一个字节中。如果有剩余位，则标志位设置为1，随后的7位存储在以下字节中。如果还有剩余的位，则将标志设置为1，然后重复相同的过程。结束字节的标志位设置为0。要解码，只需在字节上迭代，直到标志位设置为0。对于每个字节，将数据添加到累积值乘以128。
The headers are packed in the same order as they are present in Ogg [VORBIS-SPEC-REF]: Identification, Comment, Setup.
标题的包装顺序与Ogg[VORBIS-SPEC-REF]：标识、注释、设置中的顺序相同。
The 2 byte length tag defines the length of the packed headers as the sum of the Configuration, Comment, and Setup lengths.
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 | 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 ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图5：打包配置图
The Ident field is set with the value that will be used by the Raw Payload Packets to address this Configuration. The Fragment type is set to 0 because the packet bears the full Packed configuration. The number of the packet is set to 1.
Ident字段设置为原始有效负载数据包将用于寻址此配置的值。片段类型设置为0，因为数据包具有完全打包的配置。数据包的编号设置为1。
The following packet definition MUST be used when Configuration is inside in the SDP.
当配置位于SDP中时，必须使用以下数据包定义。
As mentioned above, the RECOMMENDED delivery vector for Vorbis configuration data is via a retrieval method that can be performed using a reliable transport protocol. As the RTP headers are not required for this method of delivery, the structure of the configuration data is slightly different. The packed header starts with a 32-bit (network-byte ordered) count field, which details the number of packed headers that are contained in the bundle. The following shows the Packed header payload for each chained Vorbis stream.
如上所述，Vorbis配置数据的推荐交付向量是通过可使用可靠传输协议执行的检索方法。由于这种交付方法不需要RTP头，因此配置数据的结构略有不同。压缩头以32位（网络字节顺序）计数字段开始，该字段详细说明包中包含的压缩头的数量。下面显示了每个链接Vorbis流的压缩头有效负载。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of packed headers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packed header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packed header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of packed headers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packed header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packed header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Packed Headers Overview
图6：打包标题概述
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图7：打包标题详细信息
The key difference between the in-band format and this one is that there is no need for the payload header octet. In this figure, the comment has a size bigger than 127 bytes.
带内格式与此格式之间的关键区别在于不需要有效负载头八位字节。在此图中，注释的大小大于127字节。
Unlike the loss of raw Vorbis payload data, loss of a configuration header leads to a situation where it will not be possible to successfully decode the stream. Implementations MAY try to recover from an error by requesting again the missing Configuration or, if the delivery method is in-band, by buffering the payloads waiting for the Configuration needed to decode them. The baseline reaction SHOULD either be reset or end the RTP session.
与原始Vorbis有效负载数据的丢失不同，配置头的丢失会导致无法成功解码流的情况。实现可以通过再次请求丢失的配置来尝试从错误中恢复，或者，如果交付方法在频带内，则通过缓冲有效负载来等待解码它们所需的配置。基线反应应重置或结束RTP会话。
Vorbis Data Type flag set to 2 indicates that the packet contains the comment metadata, such as artist name, track title, and so on. These metadata messages are not intended to be fully descriptive but rather to offer basic track/song information. Clients MAY ignore it completely. The details on the format of the comments can be found in the Vorbis I Specification [VORBIS-SPEC-REF].
设置为2的Vorbis数据类型标志表示数据包包含注释元数据，如艺术家姓名、曲目标题等。这些元数据消息不是为了完全描述，而是为了提供基本的曲目/歌曲信息。客户可能会完全忽略它。有关注释格式的详细信息，请参见Vorbis I规范[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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图8：注释包
The 2-byte length field is necessary since this packet could be fragmented.
2字节长度字段是必需的，因为此数据包可能会被分段。
Each RTP payload contains either one Vorbis packet fragment or an integer number of complete Vorbis packets (up to a maximum of 15 packets, since the number of packets is defined by a 4-bit value).
每个RTP有效负载包含一个Vorbis数据包片段或完整Vorbis数据包的整数（最多15个数据包，因为数据包的数量由4位值定义）。
Any Vorbis data packet that is less than path MTU SHOULD be bundled in the RTP payload with as many Vorbis packets as will fit, up to a maximum of 15, except when such bundling would exceed an application's desired transmission latency. Path MTU is detailed in [RFC1191] and [RFC1981].
小于路径MTU的任何Vorbis数据包都应在RTP有效载荷中捆绑，捆绑的Vorbis数据包数量应尽可能多，最多15个，除非此类捆绑将超过应用程序所需的传输延迟。路径MTU详见[RFC1191]和[RFC1981]。
A fragmented packet has a zero in the last four bits of the payload header. The first fragment will set the Fragment type to 1. Each fragment after the first will set the Fragment type to 2 in the payload header. The consecutive fragments MUST be sent without any other payload being sent between the first and the last fragment. The RTP payload containing the last fragment of the Vorbis packet will have the Fragment type set to 3. To maintain the correct sequence for fragmented packet reception, the timestamp field of fragmented packets MUST be the same as the first packet sent, with
碎片数据包在有效负载报头的最后四位中有一个零。第一个片段将片段类型设置为1。第一个之后的每个片段将在有效负载头中将片段类型设置为2。连续的片段必须在第一个片段和最后一个片段之间不发送任何其他有效负载的情况下发送。包含Vorbis数据包最后一个片段的RTP有效负载的片段类型将设置为3。要保持碎片数据包接收的正确顺序，碎片数据包的时间戳字段必须与发送的第一个数据包相同，包括
the sequence number incremented as normal for the subsequent RTP payloads; this will affect the RTCP jitter measurement. The length field shows the fragment length.
对于后续RTP有效载荷，序列号正常增加；这将影响RTCP抖动测量。长度字段显示片段长度。
Here is an example of a fragmented Vorbis packet split over three RTP payloads. Each of them contains the standard RTP headers as well as the 4-octet Vorbis headers.
下面是一个在三个RTP有效负载上分割Vorbis数据包的示例。它们中的每一个都包含标准RTP报头以及4-octet-Vorbis报头。
Packet 1:
第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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
图9：示例碎片数据包（数据包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 as the payload is raw Vorbis data, the VDT field is set to 0.
在此有效载荷中，初始序列号为1000，时间戳为12345。片段类型设置为1，数据包数字段设置为0，有效负载为原始Vorbis数据时，VDT字段设置为0。
Packet 2:
第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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
图10：示例碎片数据包（数据包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. The maximum packet size SHOULD be no greater than the path MTU, including all RTP and payload headers. The sequence number has been incremented by one, but the timestamp field remains the same as the initial payload.
片段类型字段设置为2，数据包数字段设置为0。对于大型Vorbis碎片，可以有几种类型的有效载荷。最大数据包大小不应大于路径MTU，包括所有RTP和有效负载头。序列号已增加1，但时间戳字段与初始有效负载保持相同。
Packet 3:
第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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
图11：示例碎片数据包（数据包3）
This is the last Vorbis fragment payload. The Fragment type is set to 3 and the packet count remains set to 0. As in the previous payloads, the timestamp remains set to the first payload timestamp in the sequence and the sequence number has been incremented.
这是最后一个Vorbis碎片有效载荷。片段类型设置为3，数据包计数保持设置为0。与前面的有效负载一样，时间戳保持设置为序列中的第一个有效负载时间戳，并且序列号已递增。
As there is no error correction within the Vorbis stream, packet loss will result in a loss of signal. Packet loss is more of an issue for fragmented Vorbis packets as the client will have to cope with the handling of the Fragment Type. In case of loss of fragments, the client MUST discard all the remaining Vorbis fragments and decode the incomplete packet. If we use the fragmented Vorbis packet 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 fragmented packet, MUST be dropped in the same manner. If the missing RTP payload is the last, the two fragments received will be kept and the incomplete Vorbis packet decoded.
由于Vorbis流中没有纠错，分组丢失将导致信号丢失。对于碎片化的Vorbis数据包来说，数据包丢失是一个更大的问题，因为客户端必须处理碎片类型。在片段丢失的情况下，客户端必须丢弃所有剩余的Vorbis片段并解码不完整的数据包。如果我们使用上面的片段Vorbis数据包示例，并且第一个RTP有效负载丢失，那么客户端必须检测到下一个RTP有效负载的数据包计数字段设置为0，片段类型为2，并且必须丢弃它。必须以相同的方式丢弃下一个RTP有效负载，即最后的碎片数据包。如果丢失的RTP有效载荷是最后一个，则接收到的两个片段将被保留，不完整的Vorbis数据包将被解码。
Loss of any of the Configuration fragment will result in the loss of the full Configuration packet with the result detailed in the Loss of Configuration Headers (Section 3.3) section.
任何配置片段的丢失都将导致完整配置数据包的丢失，详细结果见配置头丢失（第3.3节）一节。
Type name: audio
类型名称：音频
Subtype name: vorbis
子类型名称：vorbis
Required parameters:
所需参数：
rate: indicates the RTP timestamp clock rate as described in RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551].
速率：表示具有最小控制的音频和视频会议的RTP配置文件中所述的RTP时间戳时钟速率[RFC3551]。
channels: indicates the number of audio channels as described in RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551].
频道：表示RTP配置文件中描述的音频和视频会议的音频频道数量，具有最小控制[RFC3551]。
configuration: the base64 [RFC4648] representation of the Packed Headers (Section 3.2.1).
配置：压缩头的base64[RFC4648]表示（第3.2.1节）。
Encoding considerations:
编码注意事项：
This media type is framed and contains binary data.
此媒体类型是框架式的，包含二进制数据。
Security considerations:
安全考虑：
See Section 10 of RFC 5215.
见RFC 5215第10节。
Interoperability considerations:
互操作性注意事项：
None
没有一个
Published specification:
已发布的规范：
RFC 5215
RFC 5215
Ogg Vorbis I specification: Codec setup and packet decode.
Available from the Xiph website, http://xiph.org/
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
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, hence is only defined for transfer via RTP [RFC3550].
此媒体类型取决于RTP帧，因此仅定义为通过RTP[RFC3550]传输。
Author:
作者：
Luca Barbato
卢卡·巴巴托
Change controller:
更改控制器：
IETF AVT Working Group delegated from the IESG
IESG授权的IETF AVT工作组
The following IANA considerations refers to the split configuration Packed Headers (Section 3.2.1) used within RFC 5215.
以下IANA注意事项涉及RFC 5215中使用的拆分配置压缩头（第3.2.1节）。
Type name: audio
类型名称：音频
Subtype name: vorbis-config
子类型名称：vorbis config
Required parameters:
所需参数：
None
没有一个
Optional parameters:
可选参数：
None
没有一个
Encoding considerations:
编码注意事项：
This media type contains binary data.
此媒体类型包含二进制数据。
Security considerations:
安全考虑：
See Section 10 of RFC 5215.
见RFC 5215第10节。
Interoperability considerations:
互操作性注意事项：
None
没有一个
Published specification:
已发布的规范：
RFC 5215
RFC 5215
Applications which use this media type:
使用此媒体类型的应用程序：
Vorbis encoded audio, configuration data
Vorbis编码音频、配置数据
Additional information:
其他信息：
None
没有一个
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Luca Barbato: <lu_zero@gentoo.org>
IETF Audio/Video Transport Working Group
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
IESG授权的IETF AVT工作组
The following paragraphs define the mapping of the parameters described in the IANA considerations section and their usage in the Offer/Answer Model [RFC3264]. In order to be forward compatible, the implementation MUST ignore unknown parameters.
以下段落定义了IANA注意事项部分中描述的参数映射及其在报价/应答模型[RFC3264]中的使用。为了向前兼容，实现必须忽略未知参数。
The information carried in the Media Type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions, the mapping are as follows:
媒体类型规范中包含的信息与会话描述协议（SDP）[RFC4566]中的字段具有特定映射，该协议通常用于描述RTP会话。使用SDP指定会话时，映射如下所示：
o The type name ("audio") goes in SDP "m=" as the media name.
o 类型名称（“音频”）以SDP“m=”作为媒体名称。
o The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding name.
o 子类型名称（“vorbis”）以SDP“a=rtpmap”作为编码名称。
o The parameter "rate" also goes in "a=rtpmap" as the clock rate.
o 参数“rate”也作为时钟速率进入“a=rtpmap”。
o The parameter "channels" also goes in "a=rtpmap" as the channel count.
o 参数“channels”也作为通道计数进入“a=rtpmap”。
o The mandated parameters "configuration" MUST be included in the SDP "a=fmtp" attribute.
o 强制参数“配置”必须包含在SDP“a=fmtp”属性中。
If the stream comprises chained Vorbis files and all of them are known in advance, the Configuration Packet for each file SHOULD be passed to the client using the configuration attribute.
如果流包含链接的Vorbis文件，并且所有这些文件都是预先知道的，那么每个文件的配置包都应该使用Configuration属性传递给客户机。
The port value is specified by the server application bound to the address specified in the c= line. The channel count value specified in the rtpmap attribute SHOULD match the current Vorbis stream or should be considered the maximum number of channels to be expected. The timestamp clock rate MUST be a multiple of the sample rate; a different payload number MUST be used if the clock rate changes. The Configuration payload delivers the exact information, thus the SDP information SHOULD be considered a hint. An example is found below.
端口值由绑定到c=行中指定的地址的服务器应用程序指定。rtpmap属性中指定的通道计数值应与当前Vorbis流匹配，或应视为预期的最大通道数。时间戳时钟速率必须是采样速率的倍数；如果时钟频率发生变化，则必须使用不同的有效负载编号。配置负载提供准确的信息，因此SDP信息应被视为提示。下面是一个例子。
The following example shows a basic SDP single stream. The first configuration packet is inside the SDP; other configurations could be fetched at any time from the URIs provided. The following base64 [RFC4648] configuration string is folded in this example due to RFC line length limitations.
下面的示例显示了一个基本的SDP单流。第一配置分组在SDP内；可以随时从提供的URI获取其他配置。在本例中，由于RFC行长度限制，以下base64[RFC4648]配置字符串被折叠。
c=IN IP4 192.0.2.1
c=在IP4 192.0.2.1中
m=audio RTP/AVP 98
m=音频RTP/AVP 98
a=rtpmap:98 vorbis/44100/2
a=rtpmap:98 vorbis/44100/2
a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...;
a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...;
Note that the payload format (encoding) names are commonly shown in uppercase. Media Type subtypes are commonly shown in lowercase. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in Media Type types and in the default mapping to the SDP a=fmtp attribute. The a=fmtp line is
请注意，有效负载格式（编码）名称通常以大写形式显示。媒体类型子类型通常以小写字母显示。这些名称在两个位置都不区分大小写。类似地，参数名称在媒体类型和SDP a=fmtp属性的默认映射中都不区分大小写。a=fmtp线为
a single line, even if it is shown as multiple lines in this document for clarity.
一行，即使为了清晰起见，在本文档中显示为多行。
There are no negotiable parameters. All of them are declarative.
没有可协商的参数。它们都是声明性的。
The general congestion control considerations for transporting RTP data apply to Vorbis audio over RTP as well. See the RTP specification [RFC3550] and any applicable RTP profile (e.g., [RFC3551]). Audio data can be encoded using a range of different bit rates, so it is possible to adapt network bandwidth by adjusting the encoder bit rate in real time or by having multiple copies of content encoded at different bit rates.
传输RTP数据的一般拥塞控制考虑也适用于RTP上的Vorbis音频。请参阅RTP规范[RFC3550]和任何适用的RTP配置文件（例如[RFC3551]）。音频数据可以使用一系列不同的比特率进行编码，因此可以通过实时调整编码器比特率或通过以不同比特率编码内容的多个副本来调整网络带宽。
The following example shows a common usage pattern that MAY be applied in such a situation. The main scope of this section is to explain better usage of the transmission vectors.
下面的示例显示了在这种情况下可以应用的常见使用模式。本节的主要内容是解释如何更好地使用传输向量。
This is one of the most common situations: there is 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 (as the webjockey's voice) and stored streams (as 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 that the decoding will start immediately after.
加入后，客户端将接收对SDP内的当前流进行解码所需的当前配置，以便解码之后立即开始。
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.
当流式内容更改时，新配置在实际流之前在频带内发送，并且必须在SDP内发送的配置将更新。由于带内方法不可靠，因此提供带外回退。
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.
一旦发现带内丢失的配置数据包，客户机可以选择从备用源获取配置，或者如果服务器支持此功能，则使用选择性重传[RFC3611]。
A server-side optimization would be to keep a hash list of the Configurations per session, which avoids packing all of them and sending the same Configuration with different Ident tags.
服务器端优化将是为每个会话保留一个配置的哈希列表，这样可以避免打包所有配置，并使用不同的Ident标记发送相同的配置。
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.
客户端优化将保留每个会话的配置标记列表，而不是处理已知的配置包。
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.
使用此有效负载格式的RTP数据包受RTP规范[RFC3550]、base64规范[RFC4648]和URI通用语法规范[RFC3986]中讨论的安全注意事项的约束。在其他考虑因素中，这意味着通过使用加密来实现媒体流的机密性。由于与此有效负载格式一起使用的数据压缩是端到端应用的，因此可以对压缩数据执行加密。
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, provided that, unless separate permission is granted, redistributed modified works do not contain misleading author, version, name of work, or endorsement information.
作者同意授予第三方不可撤销的权利，在任何媒体上复制、使用和分发作品，无论是否修改，无需版税，前提是，除非授予单独许可，否则重新分发的修改作品不包含误导作者、版本、作品名称或背书信息。
This document is a continuation of the following documents:
本文件是以下文件的延续：
Moffitt, J., "RTP Payload Format for Vorbis Encoded Audio", February 2001.
Moffitt，J.，“Vorbis编码音频的RTP有效载荷格式”，2001年2月。
Kerr, R., "RTP Payload Format for Vorbis Encoded Audio", December 2004.
Kerr，R.，“Vorbis编码音频的RTP有效载荷格式”，2004年12月。
The Media Type declaration is a continuation of the following document:
介质类型声明是以下文档的延续：
Short, B., "The audio/rtp-vorbis MIME Type", January 2008.
Short，B.，“音频/rtp vorbis MIME类型”，2008年1月。
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
得益于AVT、VorbIS社区/XIPH.org基金会，包括Steve Casner、Aaron Colwell、Ross Finlayson、Fluendo、Ramon Garcia、Pascal Hennequin、Ralph Giles、Tor Einar Jarnbjo、So、Y、Y、Y、Y、Y、Y、Y、Y、Y、Y、Y、S.David Barrett、Silvia Pfeiffer、Stefan Ehmann、Gianni Ceccarelli和
Alessandro Salvatori. Thanks to the LScube Group, in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Dario Gallucci, and Juan Carlos De Martin.
亚历山德罗·萨尔瓦托里。感谢LScube集团，特别是费德里科·里多尔福、弗朗切斯科·瓦拉诺、詹帕罗·曼奇尼、达里奥·加卢奇和胡安·卡洛斯·德·马丁。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[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".
[VORBIS-SPEC-REF]“Ogg VORBIS I规范：编解码器设置和数据包解码。可从Xiph网站获得，http://xiph.org/vorbis/doc/Vorbis_I_spec.html".
[LIBVORBIS] "libvorbis: Available from the dedicated website, http://vorbis.com/".
[LIBVORBIS]“LIBVORBIS：可从专用网站获得，http://vorbis.com/".
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", RFC 3533, May 2003.
[RFC3533]Pfeiffer，S.，“Ogg封装格式版本0”，RFC 3533，2003年5月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，2006年7月。
Author's Address
作者地址
Luca Barbato Xiph.Org Foundation
Luca Barbato Xiph基金会基金会
EMail: lu_zero@gentoo.org
URI: http://xiph.org/
EMail: lu_zero@gentoo.org
URI: http://xiph.org/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.