Internet Engineering Task Force (IETF) X. Duan
Request for Comments: 5993 S. Wang
Category: Standards Track China Mobile Communications Corporation
ISSN: 2070-1721 M. Westerlund
K. Hellwig
I. Johansson
Ericsson AB
October 2010
Internet Engineering Task Force (IETF) X. Duan
Request for Comments: 5993 S. Wang
Category: Standards Track China Mobile Communications Corporation
ISSN: 2070-1721 M. Westerlund
K. Hellwig
I. Johansson
Ericsson AB
October 2010
RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR)
全球移动通信系统半速率（GSM-HR）的RTP有效载荷格式
Abstract
摘要
This document specifies the payload format for packetization of Global System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy.
本文件规定了将全球移动通信系统半速率（GSM-HR）语音编解码器数据打包到实时传输协议（RTP）中的有效载荷格式。有效负载格式支持每个有效负载传输多个帧，并支持使用冗余的分组丢失鲁棒性方法。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5993.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5993.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Payload Format Capabilities . . . . . . . . . . . . . . . . . 4
4.1. Use of Forward Error Correction (FEC) . . . . . . . . . . 4
5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6
5.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 6
5.2.1. Encoding of Speech Frames . . . . . . . . . . . . . . 8
5.2.2. Encoding of Silence Description Frames . . . . . . . . 8
5.3. Implementation Considerations . . . . . . . . . . . . . . 8
5.3.1. Transmission of SID Frames . . . . . . . . . . . . . . 8
5.3.2. Receiving Redundant Frames . . . . . . . . . . . . . . 8
5.3.3. Decoding Validation . . . . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. 3 Frames . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. 3 Frames with Lost Frame in the Middle . . . . . . . . . . 11
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 11
7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 12
7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 13
7.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 14
7.2.2. Declarative SDP Considerations . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Payload Format Capabilities . . . . . . . . . . . . . . . . . 4
4.1. Use of Forward Error Correction (FEC) . . . . . . . . . . 4
5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6
5.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 6
5.2.1. Encoding of Speech Frames . . . . . . . . . . . . . . 8
5.2.2. Encoding of Silence Description Frames . . . . . . . . 8
5.3. Implementation Considerations . . . . . . . . . . . . . . 8
5.3.1. Transmission of SID Frames . . . . . . . . . . . . . . 8
5.3.2. Receiving Redundant Frames . . . . . . . . . . . . . . 8
5.3.3. Decoding Validation . . . . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. 3 Frames . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. 3 Frames with Lost Frame in the Middle . . . . . . . . . . 11
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 11
7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 12
7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 13
7.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 14
7.2.2. Declarative SDP Considerations . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
This document specifies the payload format for packetization of GSM Half Rate (GSM-HR) codec [TS46.002] encoded speech signals into the Real-time Transport Protocol (RTP) [RFC3550]. The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy.
本文件规定了将GSM半速率（GSM-HR）编解码器[TS46.002]编码的语音信号打包成实时传输协议（RTP）[RFC3550]的有效载荷格式。有效负载格式支持每个有效负载传输多个帧，并支持使用冗余的分组丢失鲁棒性方法。
This document starts with conventions, a brief description of the codec, and payload format capabilities. The payload format is specified in Section 5. Examples can be found in Section 6. The media type specification and its mappings to SDP, and considerations when using the Session Description Protocol (SDP) offer/answer procedures are then specified. The document ends with considerations related to congestion control and security.
本文档从约定、编解码器的简要说明和有效负载格式功能开始。第5节规定了有效载荷格式。示例见第6节。然后指定媒体类型规范及其到SDP的映射，以及使用会话描述协议（SDP）提供/应答过程时的注意事项。该文件以与拥塞控制和安全相关的考虑事项结尾。
This document registers a media type (audio/GSM-HR-08) for the Real-time Transport Protocol (RTP) payload format for the GSM-HR codec. Note: This format is not compatible with the one provided back in 1999 to 2000 in early draft versions of what was later published as RFC 3551. RFC 3551 was based on a later version of the Audio-Visual Profile (AVP) draft, which did not provide any specification of the GSM-HR payload format. To avoid a possible conflict with this older format, the media type of the payload format specified in this document has a media type name that is different from (audio/GSM-HR).
本文档为GSM-HR编解码器的实时传输协议（RTP）有效负载格式注册媒体类型（音频/GSM-HR-08）。注：此格式与1999年至2000年早期草案版本RFC 3551中提供的格式不兼容。RFC 3551基于视听配置文件（AVP）草案的更高版本，该草案未提供任何GSM-HR有效负载格式规范。为避免与此旧格式发生冲突，本文档中指定的有效负载格式的媒体类型名称与（音频/GSM-HR）不同。
This document uses the normal IETF bit-order representation. Bit fields in figures are read left to right and then down. The leftmost bit in each field is the most significant. The numbering starts from 0 and ascends, where bit 0 will be the most significant.
本文档使用标准IETF位顺序表示法。图中的位字段从左到右再向下读取。每个字段中最左边的位是最重要的。编号从0开始并递增，其中位0将是最重要的。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The Global System for Mobile Communications (GSM) network provides with mobile communication services for nearly 3 billion users (statistics as of 2008). The GSM Half Rate (GSM-HR) codec is one of the speech codecs used in GSM networks. GSM-HR denotes the Half Rate speech codec as specified in [TS46.002].
全球移动通信系统（GSM）网络为近30亿用户提供移动通信服务（截至2008年的统计数据）。GSM半速率（GSM-HR）编解码器是GSM网络中使用的语音编解码器之一。GSM-HR表示[TS46.002]中规定的半速率语音编解码器。
Note: For historical reasons, these 46-series specifications are internally referenced as 06-series. A simple mapping applies; for example, 46.020 is referenced as 06.20, and so on.
注：由于历史原因，这些46系列规范在内部被称为06系列。一个简单的映射适用；例如，46.020被引用为06.20，依此类推。
The GSM-HR codec has a frame length of 20 ms, with narrowband speech sampled at 8000 Hz, i.e., 160 samples per frame. Each speech frame is compressed into 112 bits of speech parameters, which is equivalent to a bit rate of 5.6 kbit/s. Speech pauses are detected by a standardized Voice Activity Detection (VAD). During speech pauses, the transmission of speech frames is inhibited. Silence Descriptor (SID) frames are transmitted at the end of a talkspurt and about every 480 ms during speech pauses to allow for a decent comfort noise (CN) quality on the receiver side.
GSM-HR编解码器的帧长为20 ms，窄带语音采样频率为8000 Hz，即每帧160个采样。每个语音帧被压缩成112位语音参数，相当于5.6 kbit/s的比特率。语音暂停由标准化语音活动检测（VAD）检测。在语音暂停期间，语音帧的传输被禁止。静音描述符（SID）帧在TalkSput结束时传输，在语音暂停期间大约每480毫秒传输一次，以便在接收端获得良好的舒适噪声（CN）质量。
The SID frame generation in the GSM radio network is determined by the GSM mobile station and the GSM radio subsystem. SID frames come during speech pauses in the uplink from the mobile station about every 480 ms. In the downlink to the mobile station, when they are generated by the encoder of the GSM radio subsystem, SID frames are sent every 20 ms to the GSM base station, which then picks only one every 480 ms for downlink radio transmission. For other applications, like transport over IP, it is more appropriate to send the SID frames less often than every 20 ms, but 480 ms may be too sparse. We recommend as a compromise that a GSM-HR encoder outside of the GSM radio network (i.e., not in the GSM mobile station and not in the GSM radio subsystem, but, for example, in the media gateway of the core network) should generate and send SID frames every 160 ms.
GSM无线网络中的SID帧生成由GSM移动台和GSM无线子系统确定。SID帧在来自移动台的上行链路的语音暂停期间大约每480 ms出现一次。在到移动台的下行链路中，当它们由GSM无线电子系统的编码器生成时，SID帧每20 ms发送到GSM基站，然后GSM基站每480 ms仅拾取一个用于下行链路无线电传输。对于其他应用程序，如IP传输，发送SID帧的频率比每20毫秒一次更合适，但480毫秒可能过于稀疏。作为一种折衷方案，我们建议GSM无线网络外部的GSM-HR编码器（即，不在GSM移动台中，也不在GSM无线子系统中，但例如在核心网络的媒体网关中）应每160 ms生成并发送SID帧。
This RTP payload format carries one or more GSM-HR encoded frames -- either full voice or silence descriptor (SID) -- representing a mono speech signal. To maintain synchronization or to indicate unsent or lost frames, it has the capability to indicate No_Data frames.
这种RTP有效载荷格式携带一个或多个GSM-HR编码帧——全语音或静音描述符（SID）——表示单声道语音信号。为了保持同步或指示未发送或丢失的帧，它能够指示无数据帧。
Generic forward error correction within RTP is defined, for example, in RFC 5109 [RFC5109]. Audio redundancy coding is defined in RFC 2198 [RFC2198]. Either scheme can be used to add redundant information to the RTP packet stream and make it more resilient to packet losses, at the expense of a higher bit rate. Please see either RFC for a discussion of the implications of the higher bit rate to network congestion.
例如，在RFC 5109[RFC5109]中定义了RTP内的通用前向纠错。音频冗余编码在RFC 2198[RFC2198]中定义。这两种方案均可用于向RTP数据包流中添加冗余信息，并使其在以更高比特率为代价的情况下对数据包丢失更具弹性。有关更高比特率对网络拥塞的影响的讨论，请参见RFC。
In addition to these media-unaware mechanisms, this memo specifies an optional-to-use GSM-HR-specific form of audio redundancy coding, which may be beneficial in terms of packetization overhead. Conceptually, previously transmitted transport frames are aggregated together with new ones. A sliding window can be used to group the frames to be sent in each payload. Figure 1 below shows an example.
除了这些媒体不知道的机制外，本备忘录还指定了一种可选的使用GSM HR特定形式的音频冗余编码的方法，这在分组开销方面可能是有益的。从概念上讲，先前传输的传输帧与新传输帧聚合在一起。滑动窗口可用于对每个有效载荷中要发送的帧进行分组。下面的图1显示了一个示例。
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
Figure 1: An Example of Redundant Transmission
图1：冗余传输示例
Here, each frame is retransmitted once in the following RTP payload packet. f(n-2)...f(n+4) denote a sequence of audio frames, and p(n-1)...p(n+4) a sequence of payload packets.
这里，每个帧在下面的RTP有效负载分组中重传一次。f（n-2）…f（n+4）表示音频帧序列，p（n-1）…p（n+4）表示有效负载分组序列。
The mechanism described does not really require signaling at the session setup. However, signaling has been defined to allow the sender to voluntarily bound the buffering and delay requirements. If nothing is signaled, the use of this mechanism is allowed and unbounded. For a certain timestamp, the receiver may acquire multiple copies of a frame containing encoded audio data. The cost of this scheme is bandwidth, and the receiver delay is necessary to allow the redundant copy to arrive.
所描述的机制实际上不需要在会话设置时发送信令。然而，信令已被定义为允许发送方自愿约束缓冲和延迟要求。如果未发出任何信号，则允许使用此机制，且不受限制。对于某个时间戳，接收器可以获取包含编码音频数据的帧的多个副本。该方案的成本是带宽，并且接收机延迟是允许冗余副本到达的必要条件。
This redundancy scheme provides a functionality similar to the one described in RFC 2198, but it works only if both original frames and redundant representations are GSM-HR frames. When the use of other media coding schemes is desirable, one has to resort to RFC 2198.
该冗余方案提供了与RFC 2198中描述的功能类似的功能，但仅当原始帧和冗余表示都是GSM-HR帧时，该方案才起作用。当需要使用其他媒体编码方案时，必须求助于RFC 2198。
The sender is responsible for selecting an appropriate amount of redundancy, based on feedback regarding the channel conditions, e.g., in the RTP Control Protocol (RTCP) [RFC3550] receiver reports. The sender is also responsible for avoiding congestion, which may be exacerbated by redundancy (see Section 9 for more details).
发送方负责根据有关信道条件的反馈选择适当数量的冗余，例如，在RTP控制协议（RTCP）[RFC3550]接收方报告中。发送方还负责避免因冗余而加剧的拥塞（更多详细信息，请参见第9节）。
The format of the RTP header is specified in [RFC3550]. The payload format described in this document uses the header fields in a manner consistent with that specification.
RTP标头的格式在[RFC3550]中指定。本文档中描述的有效负载格式以与该规范一致的方式使用标题字段。
The duration of one speech frame is 20 ms. The sampling frequency is 8000 Hz, corresponding to 160 speech samples per frame. An RTP packet may contain multiple frames of encoded speech or SID parameters. Each packet covers a period of one or more contiguous
一个语音帧的持续时间为20 ms。采样频率为8000 Hz，对应于每帧160个语音样本。RTP数据包可以包含多个编码语音帧或SID参数。每个数据包覆盖一个或多个连续时间段
20-ms frame intervals. During silence periods, no speech packets are sent; however, SID packets are transmitted every now and then.
20毫秒帧间隔。在静默期间，不发送语音包；然而，SID数据包时不时地被传输。
To allow for error resiliency through redundant transmission, the periods covered by multiple packets MAY overlap in time. A receiver MUST be prepared to receive any speech frame multiple times. A given frame MUST NOT be encoded as a speech frame in one packet and as a SID frame or as a No_Data frame in another packet. Furthermore, a given frame MUST NOT be encoded with different voicing modes in different packets.
为了允许通过冗余传输进行错误恢复，多个数据包覆盖的时间段可能在时间上重叠。接收机必须准备好多次接收任何语音帧。给定的帧不能在一个数据包中编码为语音帧，也不能在另一个数据包中编码为SID帧或No_数据帧。此外，给定帧不得在不同分组中使用不同的语音模式进行编码。
The rules regarding maximum payload size given in Section 3.2 of [RFC5405] SHOULD be followed.
应遵守[RFC5405]第3.2节中给出的关于最大有效负载大小的规则。
The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame in the packet. The timestamp clock frequency SHALL be 8000 Hz. The timestamp is also used to recover the correct decoding order of the frames.
RTP时间戳对应于为分组中的第一帧编码的第一样本的采样瞬间。时间戳时钟频率应为8000 Hz。时间戳还用于恢复帧的正确解码顺序。
The RTP header marker bit (M) SHALL be set to 1 whenever the first frame carried in the packet is the first frame in a talkspurt (see definition of the talkspurt in Section 4.1 of [RFC3551]). For all other packets, the marker bit SHALL be set to zero (M=0).
每当包中携带的第一帧是TalkSport中的第一帧时，RTP报头标记位（M）应设置为1（见[RFC3551]第4.1节中TalkSput的定义）。对于所有其他数据包，标记位应设置为零（M=0）。
The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profiles in use currently mandate binding the payload type dynamically for this payload format.
为本备忘录中定义的格式分配RTP有效负载类型超出了本文档的范围。当前使用的RTP配置文件强制为此有效负载格式动态绑定有效负载类型。
The remaining RTP header fields are used as specified in RFC 3550 [RFC3550].
剩余的RTP标头字段按照RFC 3550[RFC3550]中的规定使用。
The complete payload consists of a payload table of contents (ToC) section, followed by speech data representing one or more speech frames, SID frames, or No_Data frames. The following diagram shows the general payload format layout:
完整的有效负载由一个有效负载目录（ToC）部分组成，后面是表示一个或多个语音帧、SID帧或No_数据帧的语音数据。下图显示了一般有效负载格式布局：
+-------------+-------------------------
| ToC section | speech data section ...
+-------------+-------------------------
+-------------+-------------------------
| ToC section | speech data section ...
+-------------+-------------------------
Figure 2: General Payload Format Layout
图2：一般有效负载格式布局
Each ToC element is one octet and corresponds to one speech frame; the number of ToC elements is thus equal to the number of speech frames (including SID frames and No_Data frames). Each ToC entry represents a consecutive speech or SID or No_Data frame. The timestamp value for ToC element (and corresponding speech frame data) N within the payload is (RTP timestamp field + (N-1)*160) mod 2^32. The format of the ToC element is as follows.
每个ToC元素是一个八位组，对应于一个语音帧；因此，ToC元素的数量等于语音帧的数量（包括SID帧和No_数据帧）。每个ToC条目表示一个连续的语音或SID或No_数据帧。有效载荷内ToC元素（和相应的语音帧数据）N的时间戳值为（RTP时间戳字段+（N-1）*160）mod 2^32。ToC元素的格式如下所示。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |R R R R|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |R R R R|
+-+-+-+-+-+-+-+-+
Figure 3: The TOC Element
图3:TOC元素
F: Follow flag; 1 denotes that more ToC elements follow; 0 denotes the last ToC element.
F：跟随旗；1表示有更多ToC元素跟随；0表示最后一个ToC元素。
R: Reserved bits; MUST be set to zero, and MUST be ignored by receiver.
R：保留位；必须设置为零，并且必须被接收器忽略。
FT: Frame type 000 = Good Speech frame 001 = Reserved 010 = Good SID frame 011 = Reserved 100 = Reserved 101 = Reserved 110 = Reserved 111 = No_Data frame
FT:Frame type 000=良好语音帧001=保留010=良好SID帧011=保留100=保留101=保留110=保留111=无数据帧
The length of the payload data depends on the frame type:
有效负载数据的长度取决于帧类型：
Good Speech frame: The 112 speech data bits are put in 14 octets.
良好的语音帧：112个语音数据位放入14个八位字节。
Good SID frame: The 33 SID data bits are put in 14 octets, as in the case of Speech frames, with the unused 79 bits all set to "1".
良好的SID帧：33个SID数据位放在14个八位字节中，与语音帧一样，未使用的79位都设置为“1”。
No_Data frame: Length of payload data is zero octets.
无数据帧：有效负载数据的长度为0个八位字节。
Frames marked in the GSM radio subsystem as "Bad Speech frame", "Bad SID frame", or "No_Data frame" are not sent in RTP packets, in order to save bandwidth. They are marked as "No_Data frame", if they occur within an RTP packet that carries more than one speech frame, SID frame, or No_Data frame.
GSM无线电子系统中标记为“坏语音帧”、“坏SID帧”或“无数据帧”的帧不在RTP数据包中发送，以节省带宽。如果它们出现在承载多个语音帧、SID帧或无数据帧的RTP数据包中，则标记为“无数据帧”。
The 112 bits of GSM-HR-coded speech (b1...b112) are defined in TS 46.020, Annex B [TS46.020], in their order of occurrence. The first bit (b1) of the first parameter is placed in the most significant bit (MSB) (bit 0) of the first octet (octet 1) of the payload field; the second bit is placed in bit 1 of the first octet; and so on. The last bit (b112) is placed in the least significant bit (LSB) (bit 7) of octet 14.
TS 46.020附录B[TS46.020]中按照出现顺序定义了GSM HR编码语音（b1…b112）的112位。第一个参数的第一位（b1）位于有效载荷字段的第一个八位字节（八位字节1）的最高有效位（MSB）（位0）；第二位置于第一个八位组的第1位；等等最后一位（b112）位于八位字节14的最低有效位（LSB）（位7）中。
The GSM-HR codec applies a specific coding for silence periods in so-called SID frames. The coding of SID frames is based on the coding of speech frames by using only the first 33 bits for SID parameters and by setting all of the remaining 79 bits to "1".
GSM-HR编解码器对所谓的SID帧中的静默期应用特定编码。SID帧的编码基于语音帧的编码，仅使用SID参数的前33位，并将其余79位全部设置为“1”。
An application implementing this payload format MUST understand all the payload parameters that are defined in this specification. Any mapping of the parameters to a signaling protocol MUST support all parameters. So an implementation of this payload format in an application using SDP is required to understand all the payload parameters in their SDP-mapped form. This requirement ensures that an implementation always can decide whether it is capable of communicating when the communicating entities support this version of the specification.
实现此有效负载格式的应用程序必须了解本规范中定义的所有有效负载参数。参数到信令协议的任何映射都必须支持所有参数。因此，需要在使用SDP的应用程序中实现此有效负载格式，才能理解SDP映射形式中的所有有效负载参数。此要求确保了当通信实体支持此版本的规范时，实现始终可以决定是否能够通信。
When using this RTP payload format, the sender SHOULD generate and send SID frames every 160 ms, i.e., every 8th frame, during silent periods. Other SID transmission intervals may occur due to gateways to other systems that use other transmission intervals.
使用此RTP有效负载格式时，发送方应在静默期内每隔160毫秒（即每8帧）生成并发送SID帧。由于到使用其他传输间隔的其他系统的网关，可能会出现其他SID传输间隔。
The reception of redundant audio frames, i.e., more than one audio frame from the same source for the same time slot, MUST be supported by the implementation.
该实现必须支持接收冗余音频帧，即在同一时隙内从同一来源接收多个音频帧。
If the receiver finds a mismatch between the size of a received payload and the size indicated by the ToC of the payload, the receiver SHOULD discard the packet. This is recommended, because decoding a frame parsed from a payload based on erroneous ToC data could severely degrade the audio quality.
如果接收器发现接收到的有效载荷的大小与有效载荷的ToC指示的大小不匹配，则接收器应丢弃该数据包。建议这样做，因为根据错误的ToC数据对从有效负载解析的帧进行解码可能会严重降低音频质量。
A few examples below highlight the payload format.
下面的几个示例突出显示了有效负载格式。
Below is a basic example of the aggregation of 3 consecutive speech frames into a single packet.
下面是将3个连续语音帧聚合为单个数据包的基本示例。
The first 24 bits are ToC elements.
前24位是ToC元素。
Bit 0 is '1', as another ToC element follows. Bits 1..3 are 000 = Good speech frame Bits 4..7 are 0000 = Reserved Bit 8 is '1', as another ToC element follows. Bits 9..11 are 000 = Good speech frame Bits 12..15 are 0000 = Reserved Bit 16 is '0'; no more ToC elements follow. Bits 17..19 are 000 = Good speech frame Bits 20..23 are 0000 = Reserved
第0位为“1”，后面跟着另一个ToC元素。位1..3为000=良好语音帧位4..7为0000=保留位8为“1”，另一个ToC元素如下。位9..11为000=良好语音帧位12..15为0000=保留位16为“0”；没有更多的ToC元素跟随。位17..19为000=良好语音帧位20..23为0000=保留
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|0 0 0|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|b1 b24|
+-+-+-+-+-+-+-+-+ +
|b25 Frame 2 b56|
+ +
|b57 b88|
+ +-+-+-+-+-+-+-+-+
|b89 b112|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 3 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|0 0 0|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|b1 b24|
+-+-+-+-+-+-+-+-+ +
|b25 Frame 2 b56|
+ +
|b57 b88|
+ +-+-+-+-+-+-+-+-+
|b89 b112|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 3 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|
+-+-+-+-+-+-+-+-+
Below is an example of a payload carrying 3 frames, where the middle one is No_Data (for example, due to loss prior to transmission by the RTP source).
下面是承载3个帧的有效载荷的示例，其中中间一个是无_数据（例如，由于RTP源传输之前的丢失）。
The first 24 bits are ToC elements.
前24位是ToC元素。
Bit 0 is '1', as another ToC element follows. Bits 1..3 are 000 = Good speech frame Bits 4..7 are 0000 = Reserved Bit 8 is '1', as another ToC element follows. Bits 9..11 are 111 = No_Data frame Bits 12..15 are 0000 = Reserved Bit 16 is '0'; no more ToC elements follow. Bits 17..19 are 000 = Good speech frame Bits 20..23 are 0000 = Reserved
第0位为“1”，后面跟着另一个ToC元素。位1..3为000=良好语音帧位4..7为0000=保留位8为“1”，另一个ToC元素如下。位9..11为111=无数据帧位12..15为0000=保留位16为“0”；没有更多的ToC元素跟随。位17..19为000=良好语音帧位20..23为0000=保留
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|1 1 1|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|b1 b24|
+-+-+-+-+-+-+-+-+ +
|b25 Frame 3 b56|
+ +
|b57 b88|
+ +-+-+-+-+-+-+-+-+
|b89 b112|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|1 1 1|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|b1 b24|
+-+-+-+-+-+-+-+-+ +
|b25 Frame 3 b56|
+ +
|b57 b88|
+ +-+-+-+-+-+-+-+-+
|b89 b112|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This RTP payload format is identified using the media type "audio/ GSM-HR-08", which is registered in accordance with [RFC4855] and uses [RFC4288] as a template. Note: Media subtype names are case-insensitive.
该RTP有效载荷格式使用媒体类型“audio/GSM-HR-08”标识，该媒体类型根据[RFC4855]注册，并使用[RFC4288]作为模板。注意：媒体子类型名称不区分大小写。
The media type for the GSM-HR codec is allocated from the IETF tree, since GSM-HR is a well-known speech codec. This media type registration covers real-time transfer via RTP.
GSM-HR编解码器的媒体类型是从IETF树中分配的，因为GSM-HR是众所周知的语音编解码器。这种媒体类型注册包括通过RTP进行实时传输。
Note: Reception of any unspecified parameter MUST be ignored by the receiver to ensure that additional parameters can be added in the future.
注意：接收器必须忽略任何未指定参数的接收，以确保将来可以添加其他参数。
Type name: audio
类型名称：音频
Subtype name: GSM-HR-08
子类型名称：GSM-HR-08
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are integers between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present.
最大红色：帧的主要（第一次）传输和发送方将使用的任何冗余传输之间经过的最大持续时间（毫秒）。当使用冗余时，此参数允许接收器具有有界延迟。允许的值是介于0（不使用冗余）和65535之间的整数。如果省略该参数，则对冗余的使用没有限制。
ptime: See [RFC4566].
ptime：请参阅[RFC4566]。
maxptime: See [RFC4566].
maxptime:请参阅[RFC4566]。
Encoding considerations:
编码注意事项：
This media type is framed and binary; see Section 4.8 of RFC 4288 [RFC4288].
这种媒体类型是框架和二进制的；参见RFC 4288[RFC4288]第4.8节。
Security considerations:
安全考虑：
See Section 10 of RFC 5993.
见RFC 5993第10节。
Interoperability considerations:
互操作性注意事项：
The media subtype name contains "-08" to avoid potential conflict with any earlier drafts of GSM-HR RTP payload types that aren't bit-compatible.
媒体子类型名称包含“-08”，以避免与任何不兼容的GSM-HR RTP有效负载类型的早期草稿发生潜在冲突。
Published specifications:
公布的规格：
RFC 5993, 3GPP TS 46.002
RFC 5993，3GPP TS 46.002
Applications that use this media type:
使用此媒体类型的应用程序：
Real-time audio applications like voice over IP and teleconference.
实时音频应用，如IP语音和电话会议。
Additional information: none
其他信息：无
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Ingemar Johansson <ingemar.s.johansson@ericsson.com>
Ingemar Johansson <ingemar.s.johansson@ericsson.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Authors:
作者：
Xiaodong Duan <duanxiaodong@chinamobile.com>
Xiaodong Duan <duanxiaodong@chinamobile.com>
Shuaiyu Wang <wangshuaiyu@chinamobile.com>
Shuaiyu Wang <wangshuaiyu@chinamobile.com>
Magnus Westerlund <magnus.westerlund@ericsson.com>
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ingemar Johansson <ingemar.s.johansson@ericsson.com>
Ingemar Johansson <ingemar.s.johansson@ericsson.com>
Karl Hellwig <karl.hellwig@ericsson.com>
Karl Hellwig <karl.hellwig@ericsson.com>
Change controller:
更改控制器：
IETF Audio/Video Transport working group, delegated from the IESG.
IETF音频/视频传输工作组，由IESG授权。
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 employing the GSM-HR codec, the mapping is as follows:
媒体类型规范中包含的信息与会话描述协议（SDP）[RFC4566]中的字段具有特定映射，该协议通常用于描述RTP会话。当使用SDP指定使用GSM-HR编解码器的会话时，映射如下：
o The media type ("audio") goes in SDP "m=" as the media name.
o 媒体类型（“音频”）以SDP“m=”作为媒体名称。
o The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 8000, and the encoding parameters (number of channels) MUST either be explicitly set to 1 or omitted, implying a default value of 1.
o 媒体子类型（有效负载格式名称）以SDP“a=rtpmap”作为编码名称。“a=rtpmap”中的RTP时钟频率必须为8000，编码参数（通道数）必须显式设置为1或省略，这意味着默认值为1。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o 参数“ptime”和“maxptime”分别位于SDP“a=ptime”和“a=maxptime”属性中。
o Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the media type parameter string as a semicolon-separated list of parameter=value pairs.
o 通过直接从媒体类型参数字符串中以分号分隔的参数=值对列表形式复制其余参数，将其放入SDP“a=fmtp”属性中。
The following considerations apply when using SDP offer/answer procedures to negotiate the use of GSM-HR payload in RTP:
当使用SDP提供/应答程序协商RTP中GSM-HR有效载荷的使用时，以下注意事项适用：
o The SDP offerer and answerer MUST generate GSM-HR packets as described by the offered parameters.
o SDP提供方和应答方必须按照提供的参数生成GSM-HR数据包。
o In most cases, the parameters "maxptime" and "ptime" will not affect interoperability; however, the setting of the parameters can affect the performance of the application. The SDP offer/ answer handling of the "ptime" parameter is described in [RFC3264]. The "maxptime" parameter MUST be handled in the same way.
o 在大多数情况下，参数“maxptime”和“ptime”不会影响互操作性；但是，参数的设置可能会影响应用程序的性能。[RFC3264]中描述了“ptime”参数的SDP提供/应答处理。必须以相同的方式处理“maxptime”参数。
o The parameter "max-red" is a stream property parameter. For sendonly or sendrecv unicast media streams, the parameter declares the limitation on redundancy that the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but is RECOMMENDED to use the same limitation as the offer declares. In the case of multicast, the offerer MAY declare a limitation; this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always include the "max-red" parameter. This information is likely to simplify the media stream handling in the receiver. This is especially true if no redundancy will be used, in which case "max-red" is set to 0.
o 参数“最大红色”是一个流属性参数。对于sendonly或sendrecv单播媒体流，参数声明流发送方将使用的冗余限制。对于recvonly streams，它指示发送到接收器的流的所需值。回答者可以更改值，但建议使用与报价声明相同的限制。在多播的情况下，报价人可以声明限制；应使用相同的值对此进行回答。建议使用此有效负载格式的媒体发送器始终包含“max red”参数。该信息可能简化接收器中的媒体流处理。如果不使用冗余，尤其如此，在这种情况下，“最大红色”设置为0。
o Any unknown media type parameter in an offer SHALL be removed in the answer.
o 报价中的任何未知媒体类型参数应在答复中删除。
In declarative usage, like SDP in the Real Time Streaming Protocol (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) [RFC2974], the parameters SHALL be interpreted as follows:
在声明性使用中，如实时流协议（RTSP）[RFC2326]或会话公告协议（SAP）[RFC2974]中的SDP，参数应解释如下：
o The stream property parameter ("max-red") is declarative, and a participant MUST follow what is declared for the session. In this case, it means that the receiver MUST be prepared to allocate buffer memory for the given redundancy. Any transmissions MUST NOT use more redundancy than what has been declared. More than one configuration may be provided if necessary by declaring multiple RTP payload types; however, the number of types should be kept small.
o 流属性参数（“max red”）是声明性的，参与者必须遵循为会话声明的内容。在这种情况下，这意味着接收器必须准备为给定的冗余分配缓冲内存。任何传输不得使用超过已声明的冗余。如有必要，可通过声明多个RTP有效负载类型来提供多个配置；但是，类型的数量应保持在较小的范围内。
o Any "maxptime" and "ptime" values should be selected with care to ensure that the session's participants can achieve reasonable performance.
o 应谨慎选择任何“maxptime”和“ptime”值，以确保课程参与者能够实现合理的绩效。
One media type (audio/GSM-HR-08) has been defined, and it has been registered in the media types registry; see Section 7.1.
已定义一种媒体类型（音频/GSM-HR-08），并已在媒体类型注册表中注册；见第7.1节。
The general congestion control considerations for transporting RTP data apply; see RTP [RFC3550] and any applicable RTP profiles, e.g., "RTP/AVP" [RFC3551].
传输RTP数据的一般拥塞控制注意事项适用；参见RTP[RFC3550]和任何适用的RTP配置文件，例如“RTP/AVP”[RFC3551]。
The number of frames encapsulated in each RTP payload highly influences the overall bandwidth of the RTP stream due to header overhead constraints. Packetizing more frames in each RTP payload can reduce the number of packets sent and hence the header overhead, at the expense of increased delay and reduced error robustness. If forward error correction (FEC) is used, the amount of FEC-induced redundancy needs to be regulated such that the use of FEC itself does not cause a congestion problem.
由于报头开销限制，封装在每个RTP有效负载中的帧的数量高度影响RTP流的总体带宽。在每个RTP有效负载中打包更多帧可以减少发送的数据包数量，从而减少报头开销，但代价是增加延迟和降低错误鲁棒性。如果使用前向纠错（FEC），则需要调节FEC引起的冗余量，以便FEC本身的使用不会导致拥塞问题。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encryption of the RTP payload, and integrity of the RTP packets through a suitable cryptographic integrity protection mechanism. A cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining whether or not an RTP packet is from a member of the RTP session.
使用本规范中定义的有效负载格式的RTP数据包应遵守RTP规范[RFC3550]和任何适用RTP配置文件中讨论的安全注意事项。携带本备忘录中定义的RTP有效载荷格式的RTP数据包的主要安全注意事项是机密性、完整性和源真实性。保密性是通过对RTP有效负载进行加密，并通过适当的密码完整性保护机制实现RTP数据包的完整性来实现的。密码系统还可允许对有效载荷的源进行认证。该RTP有效载荷格式的合适安全机制应提供机密性、完整性保护，以及至少能够确定RTP分组是否来自RTP会话的成员的源认证。
Note that the appropriate mechanism to provide security to RTP and payloads following this may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, the usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (e.g., for RTP over TCP), but other alternatives may also exist.
请注意，为RTP和有效负载提供安全性的适当机制可能会有所不同。它取决于应用程序、传输和所采用的信令协议。因此，单一机制是不够的，尽管如果合适，建议使用安全实时传输协议（SRTP）[RFC3711]。可使用的其他机制包括IPsec[RFC4301]和传输层安全（TLS）[RFC5246]（例如，用于TCP上的RTP），但也可能存在其他替代方案。
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data; nor does the RTP payload format contain any active content.
该RTP有效载荷格式及其媒体解码器在用于分组处理的接收器侧计算复杂度方面不表现出任何显著的非均匀性，因此不太可能由于接收病理数据而造成拒绝服务威胁；RTP有效负载格式也不包含任何活动内容。
The authors would like to thank Xiaodong Duan, Shuaiyu Wang, Rocky Wang, and Ying Zhang for their initial work in this area. Many thanks also go to Tomas Frankkila for useful input and comments.
作者要感谢段晓东、王帅宇、王洛基和张颖在这方面的初步工作。非常感谢Tomas Frankkila提供有用的意见和评论。
[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月。
[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月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[TS46.002] 3GPP, "Half rate speech; Half rate speech processing functions", 3GPP TS 46.002, June 2007, <http:// www.3gpp.org/ftp/Specs/archive/46_series/46.002/ 46002-700.zip>.
[TS46.002]3GPP，“半速率语音；半速率语音处理功能”，3GPP TS 46.002，2007年6月，<http://www.3GPP.org/ftp/Specs/archive/46_series/46.002/46002-700.zip>。
[TS46.020] 3GPP, "Half rate speech; Half rate speech transcoding", 3GPP TS 46.020, June 2007, <http://www.3gpp.org/ftp/ Specs/archive/46_series/46.020/46020-700.zip>.
[TS46.020]3GPP，“半速率语音；半速率语音转码”，3GPP TS 46.020，2007年6月<http://www.3gpp.org/ftp/ Specs/archive/46_series/46.020/46020-700.zip>。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198]Perkins，C.，Kouvelas，I.，Hodson，O.，Hardman，V.，Handley，M.，Bolot，J.，Vega Garcia，A.，和S.Fosse Parisis，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855]Casner，S.，“RTP有效负载格式的媒体类型注册”，RFC 48552007年2月。
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109]Li，A.“通用前向纠错的RTP有效载荷格式”，RFC 5109，2007年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
Authors' Addresses
作者地址
Xiaodong Duan China Mobile Communications Corporation 53A, Xibianmennei Ave., Xuanwu District Beijing, 100053 P.R. China EMail: duanxiaodong@chinamobile.com
段晓东中国移动通信股份有限公司，地址：中国北京市宣武区西边门内大街53A，邮编：100053电子邮件：duanxiaodong@chinamobile.com
Shuaiyu Wang China Mobile Communications Corporation 53A, Xibianmennei Ave., Xuanwu District Beijing, 100053 P.R. China EMail: wangshuaiyu@chinamobile.com
王帅宇中国移动通信股份有限公司，地址：中国北京市宣武区西边门内大街53A，邮编：100053电子邮件：wangshuaiyu@chinamobile.com
Magnus Westerlund Ericsson AB Farogatan 6 Stockholm, SE-164 80 Sweden Phone: +46 8 719 0000 EMail: magnus.westerlund@ericsson.com
Magnus Westerlund Ericsson AB Farogatan 6斯德哥尔摩，SE-164 80瑞典电话：+46 8 719 0000电子邮件：Magnus。westerlund@ericsson.com
Karl Hellwig Ericsson AB Ericsson Allee 1 52134 Herzogenrath Germany Phone: +49 2407 575-2054 EMail: karl.hellwig@ericsson.com
卡尔·赫尔维格·爱立信公司爱立信Allee 1 52134 Herzogenrath德国电话：+49 2407 575-2054电子邮件：卡尔。hellwig@ericsson.com
Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea Sweden Phone: +46 73 0783289 EMail: ingemar.s.johansson@ericsson.com
英格玛·约翰逊·爱立信AB实验室和11 SE-971 28 Lulea瑞典电话：+46 73 0783289电子邮件：Ingemar.s。johansson@ericsson.com