Network Working Group H. Schulzrinne
Request for Comments: 3550 Columbia University
Obsoletes: 1889 S. Casner
Category: Standards Track Packet Design
R. Frederick
Blue Coat Systems Inc.
V. Jacobson
Packet Design
July 2003
Network Working Group H. Schulzrinne
Request for Comments: 3550 Columbia University
Obsoletes: 1889 S. Casner
Category: Standards Track Packet Design
R. Frederick
Blue Coat Systems Inc.
V. Jacobson
Packet Design
July 2003
RTP: A Transport Protocol for Real-Time Applications
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.
本备忘录描述了实时传输协议RTP。RTP提供端到端网络传输功能，适用于通过多播或单播网络服务传输实时数据（如音频、视频或模拟数据）的应用程序。RTP不能解决资源预留问题，也不能保证实时服务的服务质量。数据传输通过控制协议（RTCP）进行扩展，以允许以可扩展到大型多播网络的方式监控数据传输，并提供最小的控制和识别功能。RTP和RTCP设计为独立于底层传输层和网络层。该协议支持使用RTP级转换器和混频器。
Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.
本备忘录中的大部分内容与RFC 1889相同，RFC 1889已被废弃。网络上的数据包格式没有变化，只是控制协议使用方式的规则和算法发生了变化。最大的变化是对用于计算何时发送RTCP数据包的可伸缩计时器算法的增强，以便在多个参与者同时加入会话时将超过预期速率的传输最小化。
Table of Contents
目录
1. Introduction ................................................ 4
1.1 Terminology ............................................ 5
2. RTP Use Scenarios ........................................... 5
2.1 Simple Multicast Audio Conference ...................... 6
2.2 Audio and Video Conference ............................. 7
2.3 Mixers and Translators ................................. 7
2.4 Layered Encodings ...................................... 8
3. Definitions ................................................. 8
4. Byte Order, Alignment, and Time Format ...................... 12
5. RTP Data Transfer Protocol .................................. 13
5.1 RTP Fixed Header Fields ................................ 13
5.2 Multiplexing RTP Sessions .............................. 16
5.3 Profile-Specific Modifications to the RTP Header ....... 18
5.3.1 RTP Header Extension ............................ 18
6. RTP Control Protocol -- RTCP ................................ 19
6.1 RTCP Packet Format ..................................... 21
6.2 RTCP Transmission Interval ............................. 24
6.2.1 Maintaining the Number of Session Members ....... 28
6.3 RTCP Packet Send and Receive Rules ..................... 28
6.3.1 Computing the RTCP Transmission Interval ........ 29
6.3.2 Initialization .................................. 30
6.3.3 Receiving an RTP or Non-BYE RTCP Packet ......... 31
6.3.4 Receiving an RTCP BYE Packet .................... 31
6.3.5 Timing Out an SSRC .............................. 32
6.3.6 Expiration of Transmission Timer ................ 32
6.3.7 Transmitting a BYE Packet ....................... 33
6.3.8 Updating we_sent ................................ 34
6.3.9 Allocation of Source Description Bandwidth ...... 34
6.4 Sender and Receiver Reports ............................ 35
6.4.1 SR: Sender Report RTCP Packet ................... 36
6.4.2 RR: Receiver Report RTCP Packet ................. 42
6.4.3 Extending the Sender and Receiver Reports ....... 42
6.4.4 Analyzing Sender and Receiver Reports ........... 43
6.5 SDES: Source Description RTCP Packet ................... 45
6.5.1 CNAME: Canonical End-Point Identifier SDES Item . 46
6.5.2 NAME: User Name SDES Item ....................... 48
6.5.3 EMAIL: Electronic Mail Address SDES Item ........ 48
6.5.4 PHONE: Phone Number SDES Item ................... 49
6.5.5 LOC: Geographic User Location SDES Item ......... 49
6.5.6 TOOL: Application or Tool Name SDES Item ........ 49
6.5.7 NOTE: Notice/Status SDES Item ................... 50
6.5.8 PRIV: Private Extensions SDES Item .............. 50
6.6 BYE: Goodbye RTCP Packet ............................... 51
6.7 APP: Application-Defined RTCP Packet ................... 52
7. RTP Translators and Mixers .................................. 53
7.1 General Description .................................... 53
1. Introduction ................................................ 4
1.1 Terminology ............................................ 5
2. RTP Use Scenarios ........................................... 5
2.1 Simple Multicast Audio Conference ...................... 6
2.2 Audio and Video Conference ............................. 7
2.3 Mixers and Translators ................................. 7
2.4 Layered Encodings ...................................... 8
3. Definitions ................................................. 8
4. Byte Order, Alignment, and Time Format ...................... 12
5. RTP Data Transfer Protocol .................................. 13
5.1 RTP Fixed Header Fields ................................ 13
5.2 Multiplexing RTP Sessions .............................. 16
5.3 Profile-Specific Modifications to the RTP Header ....... 18
5.3.1 RTP Header Extension ............................ 18
6. RTP Control Protocol -- RTCP ................................ 19
6.1 RTCP Packet Format ..................................... 21
6.2 RTCP Transmission Interval ............................. 24
6.2.1 Maintaining the Number of Session Members ....... 28
6.3 RTCP Packet Send and Receive Rules ..................... 28
6.3.1 Computing the RTCP Transmission Interval ........ 29
6.3.2 Initialization .................................. 30
6.3.3 Receiving an RTP or Non-BYE RTCP Packet ......... 31
6.3.4 Receiving an RTCP BYE Packet .................... 31
6.3.5 Timing Out an SSRC .............................. 32
6.3.6 Expiration of Transmission Timer ................ 32
6.3.7 Transmitting a BYE Packet ....................... 33
6.3.8 Updating we_sent ................................ 34
6.3.9 Allocation of Source Description Bandwidth ...... 34
6.4 Sender and Receiver Reports ............................ 35
6.4.1 SR: Sender Report RTCP Packet ................... 36
6.4.2 RR: Receiver Report RTCP Packet ................. 42
6.4.3 Extending the Sender and Receiver Reports ....... 42
6.4.4 Analyzing Sender and Receiver Reports ........... 43
6.5 SDES: Source Description RTCP Packet ................... 45
6.5.1 CNAME: Canonical End-Point Identifier SDES Item . 46
6.5.2 NAME: User Name SDES Item ....................... 48
6.5.3 EMAIL: Electronic Mail Address SDES Item ........ 48
6.5.4 PHONE: Phone Number SDES Item ................... 49
6.5.5 LOC: Geographic User Location SDES Item ......... 49
6.5.6 TOOL: Application or Tool Name SDES Item ........ 49
6.5.7 NOTE: Notice/Status SDES Item ................... 50
6.5.8 PRIV: Private Extensions SDES Item .............. 50
6.6 BYE: Goodbye RTCP Packet ............................... 51
6.7 APP: Application-Defined RTCP Packet ................... 52
7. RTP Translators and Mixers .................................. 53
7.1 General Description .................................... 53
7.2 RTCP Processing in Translators ......................... 55
7.3 RTCP Processing in Mixers .............................. 57
7.4 Cascaded Mixers ........................................ 58
8. SSRC Identifier Allocation and Use .......................... 59
8.1 Probability of Collision ............................... 59
8.2 Collision Resolution and Loop Detection ................ 60
8.3 Use with Layered Encodings ............................. 64
9. Security .................................................... 65
9.1 Confidentiality ........................................ 65
9.2 Authentication and Message Integrity ................... 67
10. Congestion Control .......................................... 67
11. RTP over Network and Transport Protocols .................... 68
12. Summary of Protocol Constants ............................... 69
12.1 RTCP Packet Types ...................................... 70
12.2 SDES Types ............................................. 70
13. RTP Profiles and Payload Format Specifications .............. 71
14. Security Considerations ..................................... 73
15. IANA Considerations ......................................... 73
16. Intellectual Property Rights Statement ...................... 74
17. Acknowledgments ............................................. 74
Appendix A. Algorithms ........................................ 75
Appendix A.1 RTP Data Header Validity Checks ................... 78
Appendix A.2 RTCP Header Validity Checks ....................... 82
Appendix A.3 Determining Number of Packets Expected and Lost ... 83
Appendix A.4 Generating RTCP SDES Packets ...................... 84
Appendix A.5 Parsing RTCP SDES Packets ......................... 85
Appendix A.6 Generating a Random 32-bit Identifier ............. 85
Appendix A.7 Computing the RTCP Transmission Interval .......... 87
Appendix A.8 Estimating the Interarrival Jitter ................ 94
Appendix B. Changes from RFC 1889 ............................. 95
References ...................................................... 100
Normative References ............................................ 100
Informative References .......................................... 100
Authors' Addresses .............................................. 103
Full Copyright Statement ........................................ 104
7.2 RTCP Processing in Translators ......................... 55
7.3 RTCP Processing in Mixers .............................. 57
7.4 Cascaded Mixers ........................................ 58
8. SSRC Identifier Allocation and Use .......................... 59
8.1 Probability of Collision ............................... 59
8.2 Collision Resolution and Loop Detection ................ 60
8.3 Use with Layered Encodings ............................. 64
9. Security .................................................... 65
9.1 Confidentiality ........................................ 65
9.2 Authentication and Message Integrity ................... 67
10. Congestion Control .......................................... 67
11. RTP over Network and Transport Protocols .................... 68
12. Summary of Protocol Constants ............................... 69
12.1 RTCP Packet Types ...................................... 70
12.2 SDES Types ............................................. 70
13. RTP Profiles and Payload Format Specifications .............. 71
14. Security Considerations ..................................... 73
15. IANA Considerations ......................................... 73
16. Intellectual Property Rights Statement ...................... 74
17. Acknowledgments ............................................. 74
Appendix A. Algorithms ........................................ 75
Appendix A.1 RTP Data Header Validity Checks ................... 78
Appendix A.2 RTCP Header Validity Checks ....................... 82
Appendix A.3 Determining Number of Packets Expected and Lost ... 83
Appendix A.4 Generating RTCP SDES Packets ...................... 84
Appendix A.5 Parsing RTCP SDES Packets ......................... 85
Appendix A.6 Generating a Random 32-bit Identifier ............. 85
Appendix A.7 Computing the RTCP Transmission Interval .......... 87
Appendix A.8 Estimating the Interarrival Jitter ................ 94
Appendix B. Changes from RFC 1889 ............................. 95
References ...................................................... 100
Normative References ............................................ 100
Informative References .......................................... 100
Authors' Addresses .............................................. 103
Full Copyright Statement ........................................ 104
This memorandum specifies the real-time transport protocol (RTP), which provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Those services include payload type identification, sequence numbering, timestamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the transport protocol functionality. However, RTP may be used with other suitable underlying network or transport protocols (see Section 11). RTP supports data transfer to multiple destinations using multicast distribution if provided by the underlying network.
本备忘录规定了实时传输协议（RTP），该协议为具有实时特性的数据（如交互式音频和视频）提供端到端交付服务。这些服务包括有效载荷类型识别、序列编号、时间戳和交付监控。应用程序通常在UDP之上运行RTP，以利用其多路复用和校验和服务；这两个协议都提供了传输协议功能的一部分。然而，RTP可与其他合适的底层网络或传输协议一起使用（见第11节）。如果底层网络提供，RTP支持使用多播分发将数据传输到多个目的地。
Note that RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender's packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence.
请注意，RTP本身并没有提供任何机制来确保及时交付或提供其他服务质量保证，而是依赖于较低层的服务来做到这一点。它不保证交付或防止无序交付，也不假设底层网络可靠并按顺序交付数据包。RTP中包括的序列号允许接收机重构发送方的分组序列，但是序列号也可以用于确定分组的适当位置，例如在视频解码中，而不必按顺序解码分组。
While RTP is primarily designed to satisfy the needs of multi-participant multimedia conferences, it is not limited to that particular application. Storage of continuous data, interactive distributed simulation, active badge, and control and measurement applications may also find RTP applicable.
虽然RTP主要是为了满足多参与者多媒体会议的需求而设计的，但它并不限于该特定应用。连续数据存储、交互式分布式仿真、主动徽章以及控制和测量应用程序也可能适用RTP。
This document defines RTP, consisting of two closely-linked parts:
本文件定义了RTP，由两个紧密相连的部分组成：
o the real-time transport protocol (RTP), to carry data that has real-time properties.
o 实时传输协议（RTP），用于传输具有实时属性的数据。
o the RTP control protocol (RTCP), to monitor the quality of service and to convey information about the participants in an on-going session. The latter aspect of RTCP may be sufficient for "loosely controlled" sessions, i.e., where there is no explicit membership control and set-up, but it is not necessarily intended to support all of an application's control communication requirements. This functionality may be fully or partially subsumed by a separate session control protocol, which is beyond the scope of this document.
o RTP控制协议（RTCP），用于监控服务质量并在正在进行的会话中传递有关参与者的信息。RTCP的后一个方面对于“松散控制”会话可能已经足够了，即，没有明确的成员控制和设置，但它不一定旨在支持应用程序的所有控制通信需求。此功能可以完全或部分包含在单独的会话控制协议中，这超出了本文档的范围。
RTP represents a new style of protocol following the principles of application level framing and integrated layer processing proposed by Clark and Tennenhouse [10]. That is, RTP is intended to be malleable
RTP代表了一种新型的协议，它遵循Clark和Tennenhouse[10]提出的应用层成帧和集成层处理原则。也就是说，RTP旨在具有延展性
to provide the information required by a particular application and will often be integrated into the application processing rather than being implemented as a separate layer. RTP is a protocol framework that is deliberately not complete. This document specifies those functions expected to be common across all the applications for which RTP would be appropriate. Unlike conventional protocols in which additional functions might be accommodated by making the protocol more general or by adding an option mechanism that would require parsing, RTP is intended to be tailored through modifications and/or additions to the headers as needed. Examples are given in Sections 5.3 and 6.4.3.
提供特定应用程序所需的信息，这些信息通常会集成到应用程序处理中，而不是作为单独的层实现。RTP是一个故意不完整的协议框架。本文档指定了RTP适用于的所有应用程序的通用功能。与传统协议不同，在传统协议中，可以通过使协议更通用或添加需要解析的选项机制来容纳附加功能，RTP旨在根据需要通过修改和/或添加报头来定制。第5.3节和第6.4.3节给出了示例。
Therefore, in addition to this document, a complete specification of RTP for a particular application will require one or more companion documents (see Section 13):
因此，除本文件外，特定应用的完整RTP规范还需要一份或多份配套文件（见第13节）：
o a profile specification document, which defines a set of payload type codes and their mapping to payload formats (e.g., media encodings). A profile may also define extensions or modifications to RTP that are specific to a particular class of applications. Typically an application will operate under only one profile. A profile for audio and video data may be found in the companion RFC 3551 [1].
o 配置文件规范文档，定义一组有效负载类型代码及其到有效负载格式的映射（例如，媒体编码）。概要文件还可以定义特定于特定应用程序类别的RTP扩展或修改。通常，应用程序将仅在一个配置文件下运行。音频和视频数据的配置文件可在配套的RFC 3551[1]中找到。
o payload format specification documents, which define how a particular payload, such as an audio or video encoding, is to be carried in RTP.
o 有效负载格式规范文档，定义了特定有效负载（如音频或视频编码）在RTP中的传输方式。
A discussion of real-time services and algorithms for their implementation as well as background discussion on some of the RTP design decisions can be found in [11].
关于实时服务及其实现算法的讨论，以及一些RTP设计决策的背景讨论，见[11]。
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, RFC 2119 [2] and indicate requirement levels for compliant RTP implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释，并指出符合RTP实施的要求级别。
The following sections describe some aspects of the use of RTP. The examples were chosen to illustrate the basic operation of applications using RTP, not to limit what RTP may be used for. In these examples, RTP is carried on top of IP and UDP, and follows the conventions established by the profile for audio and video specified in the companion RFC 3551.
以下各节描述了RTP使用的一些方面。选择这些示例是为了说明使用RTP的应用程序的基本操作，而不是限制RTP的用途。在这些示例中，RTP是在IP和UDP之上进行的，并遵循配套RFC 3551中指定的音频和视频配置文件建立的约定。
A working group of the IETF meets to discuss the latest protocol document, using the IP multicast services of the Internet for voice communications. Through some allocation mechanism the working group chair obtains a multicast group address and pair of ports. One port is used for audio data, and the other is used for control (RTCP) packets. This address and port information is distributed to the intended participants. If privacy is desired, the data and control packets may be encrypted as specified in Section 9.1, in which case an encryption key must also be generated and distributed. The exact details of these allocation and distribution mechanisms are beyond the scope of RTP.
IETF的一个工作组开会讨论最新的协议文件，使用互联网的IP多播服务进行语音通信。通过某种分配机制，工作组主席获得一个多播组地址和一对端口。一个端口用于音频数据，另一个用于控制（RTCP）数据包。此地址和端口信息将分发给预期的参与者。如果需要隐私，可按照第9.1节的规定对数据包和控制包进行加密，在这种情况下，还必须生成并分发加密密钥。这些分配和分配机制的具体细节超出了RTP的范围。
The audio conferencing application used by each conference participant sends audio data in small chunks of, say, 20 ms duration. Each chunk of audio data is preceded by an RTP header; RTP header and data are in turn contained in a UDP packet. The RTP header indicates what type of audio encoding (such as PCM, ADPCM or LPC) is contained in each packet so that senders can change the encoding during a conference, for example, to accommodate a new participant that is connected through a low-bandwidth link or react to indications of network congestion.
每个会议参与者所使用的音频会议应用程序发送的音频数据为小块，例如，持续时间为20毫秒。每个音频数据块前面都有一个RTP头；RTP报头和数据依次包含在UDP数据包中。RTP报头指示每个分组中包含何种类型的音频编码（例如PCM、ADPCM或LPC），以便发送者可以在会议期间更改编码，例如，容纳通过低带宽链路连接的新参与者或对网络拥塞指示作出反应。
The Internet, like other packet networks, occasionally loses and reorders packets and delays them by variable amounts of time. To cope with these impairments, the RTP header contains timing information and a sequence number that allow the receivers to reconstruct the timing produced by the source, so that in this example, chunks of audio are contiguously played out the speaker every 20 ms. This timing reconstruction is performed separately for each source of RTP packets in the conference. The sequence number can also be used by the receiver to estimate how many packets are being lost.
与其他分组网络一样，互联网偶尔会丢失和重新排序分组，并延迟不同的时间。为了应对这些损伤，RTP报头包含定时信息和序列号，该序列号允许接收机重构由源产生的定时，因此在本示例中，扬声器每隔20 ms连续播放音频块。会议中的每个RTP数据包源分别执行此定时重建。接收机还可以使用序列号来估计丢失了多少数据包。
Since members of the working group join and leave during the conference, it is useful to know who is participating at any moment and how well they are receiving the audio data. For that purpose, each instance of the audio application in the conference periodically multicasts a reception report plus the name of its user on the RTCP (control) port. The reception report indicates how well the current speaker is being received and may be used to control adaptive encodings. In addition to the user name, other identifying information may also be included subject to control bandwidth limits. A site sends the RTCP BYE packet (Section 6.6) when it leaves the conference.
由于工作组成员在会议期间加入和离开，因此了解谁随时参加会议以及他们接收音频数据的情况非常有用。为此，会议中音频应用程序的每个实例定期在RTCP（控制）端口上多播接收报告及其用户名称。接收报告指示当前扬声器的接收情况，并可用于控制自适应编码。除了用户名之外，根据控制带宽限制，还可以包括其他标识信息。站点在离开会议时发送RTCP BYE数据包（第6.6节）。
If both audio and video media are used in a conference, they are transmitted as separate RTP sessions. That is, separate RTP and RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. There is no direct coupling at the RTP level between the audio and video sessions, except that a user participating in both sessions should use the same distinguished (canonical) name in the RTCP packets for both so that the sessions can be associated.
如果在会议中同时使用音频和视频媒体，则它们将作为单独的RTP会话进行传输。也就是说，使用两个不同的UDP端口对和/或多播地址为每个媒体传输单独的RTP和RTCP数据包。音频和视频会话之间在RTP级别没有直接耦合，除了参与两个会话的用户应在RTCP数据包中为这两个会话使用相同的可分辨（规范）名称，以便可以关联会话。
One motivation for this separation is to allow some participants in the conference to receive only one medium if they choose. Further explanation is given in Section 5.2. Despite the separation, synchronized playback of a source's audio and video can be achieved using timing information carried in the RTCP packets for both sessions.
这种分离的一个动机是，如果会议的一些参与者愿意，他们只能接受一种媒介。第5.2节给出了进一步的解释。尽管分离，但是可以使用RTCP数据包中为两个会话携带的定时信息来实现源音频和视频的同步播放。
So far, we have assumed that all sites want to receive media data in the same format. However, this may not always be appropriate. Consider the case where participants in one area are connected through a low-speed link to the majority of the conference participants who enjoy high-speed network access. Instead of forcing everyone to use a lower-bandwidth, reduced-quality audio encoding, an RTP-level relay called a mixer may be placed near the low-bandwidth area. This mixer resynchronizes incoming audio packets to reconstruct the constant 20 ms spacing generated by the sender, mixes these reconstructed audio streams into a single stream, translates the audio encoding to a lower-bandwidth one and forwards the lower-bandwidth packet stream across the low-speed link. These packets might be unicast to a single recipient or multicast on a different address to multiple recipients. The RTP header includes a means for mixers to identify the sources that contributed to a mixed packet so that correct talker indication can be provided at the receivers.
到目前为止，我们假设所有站点都希望接收相同格式的媒体数据。然而，这可能并不总是合适的。考虑一个区域中的参与者通过低速链路连接到大多数享受高速网络接入的会议参与者的情况。与其强迫每个人使用较低带宽、较低质量的音频编码，不如在低带宽区域附近放置一个称为混音器的RTP级中继。该混频器重新同步传入的音频分组以重构发送器生成的恒定20ms间隔，将这些重构的音频流混合成单个流，将音频编码转换为较低带宽编码，并通过低速链路转发较低带宽分组流。这些数据包可以单播到单个收件人，也可以在不同地址上多播到多个收件人。RTP报头包括混频器用于识别对混合分组有贡献的源的装置，以便可以在接收机处提供正确的说话者指示。
Some of the intended participants in the audio conference may be connected with high bandwidth links but might not be directly reachable via IP multicast. For example, they might be behind an application-level firewall that will not let any IP packets pass. For these sites, mixing may not be necessary, in which case another type of RTP-level relay called a translator may be used. Two translators are installed, one on either side of the firewall, with the outside one funneling all multicast packets received through a secure connection to the translator inside the firewall. The translator inside the firewall sends them again as multicast packets to a multicast group restricted to the site's internal network.
音频会议的一些预期参与者可能通过高带宽链路连接，但可能无法通过IP多播直接到达。例如，它们可能位于不允许任何IP数据包通过的应用程序级防火墙后面。对于这些站点，可能不需要混合，在这种情况下，可以使用另一种称为转换器的RTP级中继。安装了两个转换器，一个位于防火墙的两侧，另一个位于防火墙的外侧，通过与防火墙内的转换器的安全连接将接收到的所有多播数据包汇集在一起。防火墙内的转换器将它们作为多播数据包再次发送到仅限于站点内部网络的多播组。
Mixers and translators may be designed for a variety of purposes. An example is a video mixer that scales the images of individual people in separate video streams and composites them into one video stream to simulate a group scene. Other examples of translation include the connection of a group of hosts speaking only IP/UDP to a group of hosts that understand only ST-II, or the packet-by-packet encoding translation of video streams from individual sources without resynchronization or mixing. Details of the operation of mixers and translators are given in Section 7.
混音器和翻译器可设计用于多种用途。一个例子是视频混合器，它在单独的视频流中缩放个人的图像，并将其合成到一个视频流中，以模拟群体场景。翻译的其他示例包括将只讲IP/UDP的一组主机连接到只懂ST-II的一组主机，或者对来自单个源的视频流进行逐包编码翻译，而无需重新同步或混合。混音器和翻译器的操作细节见第7节。
Multimedia applications should be able to adjust the transmission rate to match the capacity of the receiver or to adapt to network congestion. Many implementations place the responsibility of rate-adaptivity at the source. This does not work well with multicast transmission because of the conflicting bandwidth requirements of heterogeneous receivers. The result is often a least-common denominator scenario, where the smallest pipe in the network mesh dictates the quality and fidelity of the overall live multimedia "broadcast".
多媒体应用程序应该能够调整传输速率以匹配接收器的容量或适应网络拥塞。许多实现将速率自适应的责任放在源位置。由于异构接收器的带宽要求相互冲突，这在多播传输中不起作用。结果往往是一种最小公分母的情况，即网络网格中最小的管道决定了整个直播多媒体“广播”的质量和保真度。
Instead, responsibility for rate-adaptation can be placed at the receivers by combining a layered encoding with a layered transmission system. In the context of RTP over IP multicast, the source can stripe the progressive layers of a hierarchically represented signal across multiple RTP sessions each carried on its own multicast group. Receivers can then adapt to network heterogeneity and control their reception bandwidth by joining only the appropriate subset of the multicast groups.
相反，通过将分层编码与分层传输系统相结合，可以将速率自适应的责任放在接收机上。在RTP-over-IP多播的上下文中，源可以在多个RTP会话（每个会话在其自己的多播组上进行）上对分层表示的信号的渐进层进行条带化。然后，接收机可以适应网络异构性，并通过只加入适当的多播组子集来控制其接收带宽。
Details of the use of RTP with layered encodings are given in Sections 6.3.9, 8.3 and 11.
第6.3.9、8.3和11节给出了使用分层编码的RTP的详细信息。
RTP payload: The data transported by RTP in a packet, for example audio samples or compressed video data. The payload format and interpretation are beyond the scope of this document.
RTP有效载荷：RTP在数据包中传输的数据，例如音频样本或压缩视频数据。有效载荷格式和解释超出了本文件的范围。
RTP packet: A data packet consisting of the fixed RTP header, a possibly empty list of contributing sources (see below), and the payload data. Some underlying protocols may require an encapsulation of the RTP packet to be defined. Typically one packet of the underlying protocol contains a single RTP packet, but several RTP packets MAY be contained if permitted by the encapsulation method (see Section 11).
RTP数据包：由固定RTP报头、可能为空的贡献源列表（见下文）和有效负载数据组成的数据包。一些底层协议可能需要定义RTP数据包的封装。通常，基础协议的一个数据包包含一个RTP数据包，但是如果封装方法允许，可以包含多个RTP数据包（参见第11节）。
RTCP packet: A control packet consisting of a fixed header part similar to that of RTP data packets, followed by structured elements that vary depending upon the RTCP packet type. The formats are defined in Section 6. Typically, multiple RTCP packets are sent together as a compound RTCP packet in a single packet of the underlying protocol; this is enabled by the length field in the fixed header of each RTCP packet.
RTCP数据包：一种控制数据包，由一个与RTP数据包类似的固定报头部分组成，后面是根据RTCP数据包类型而变化的结构化元素。格式在第6节中定义。通常，多个RTCP数据包作为基础协议的单个数据包中的复合RTCP数据包一起发送；这由每个RTCP数据包的固定报头中的长度字段启用。
Port: The "abstraction that transport protocols use to distinguish among multiple destinations within a given host computer. TCP/IP protocols identify ports using small positive integers." [12] The transport selectors (TSEL) used by the OSI transport layer are equivalent to ports. RTP depends upon the lower-layer protocol to provide some mechanism such as ports to multiplex the RTP and RTCP packets of a session.
端口：“传输协议用于区分给定主机内多个目的地的抽象。TCP/IP协议使用小正整数识别端口。”[12]OSI传输层使用的传输选择器（TSEL）与端口等效。RTP依赖于较低层协议来提供一些机制，例如端口，以多路复用会话的RTP和RTCP数据包。
Transport address: The combination of a network address and port that identifies a transport-level endpoint, for example an IP address and a UDP port. Packets are transmitted from a source transport address to a destination transport address.
传输地址：标识传输级端点的网络地址和端口的组合，例如IP地址和UDP端口。数据包从源传输地址传输到目标传输地址。
RTP media type: An RTP media type is the collection of payload types which can be carried within a single RTP session. The RTP Profile assigns RTP media types to RTP payload types.
RTP媒体类型：RTP媒体类型是可在单个RTP会话中承载的有效负载类型的集合。RTP配置文件将RTP介质类型分配给RTP有效负载类型。
Multimedia session: A set of concurrent RTP sessions among a common group of participants. For example, a videoconference (which is a multimedia session) may contain an audio RTP session and a video RTP session.
多媒体会话：一组共同参与者之间的一组并发RTP会话。例如，视频会议（是多媒体会话）可以包含音频RTP会话和视频RTP会话。
RTP session: An association among a set of participants communicating with RTP. A participant may be involved in multiple RTP sessions at the same time. In a multimedia session, each medium is typically carried in a separate RTP session with its own RTCP packets unless the the encoding itself multiplexes multiple media into a single data stream. A participant distinguishes multiple RTP sessions by reception of different sessions using different pairs of destination transport addresses, where a pair of transport addresses comprises one network address plus a pair of ports for RTP and RTCP. All participants in an RTP session may share a common destination transport address pair, as in the case of IP multicast, or the pairs may be different for each participant, as in the case of individual unicast network addresses and port pairs. In the unicast case, a participant may receive from all other participants in the session using the same pair of ports, or may use a distinct pair of ports for each.
RTP会话：一组与RTP通信的参与者之间的关联。参与者可能同时参与多个RTP会话。在多媒体会话中，除非编码本身将多个媒体多路复用到单个数据流中，否则每个媒体通常在单独的RTP会话中携带其自己的RTCP数据包。参与者通过使用不同的目的地传输地址对接收不同会话来区分多个RTP会话，其中一对传输地址包括一个网络地址加上一对RTP和RTCP端口。RTP会话中的所有参与者可以共享一个公共目的地传输地址对，如在IP多播的情况下，或者对于每个参与者，该对可以不同，如在单个单播网络地址和端口对的情况下。在单播情况下，参与者可以使用相同的端口对从会话中的所有其他参与者接收，或者可以为每个端口使用不同的端口对。
The distinguishing feature of an RTP session is that each maintains a full, separate space of SSRC identifiers (defined next). The set of participants included in one RTP session consists of those that can receive an SSRC identifier transmitted by any one of the participants either in RTP as the SSRC or a CSRC (also defined below) or in RTCP. For example, consider a three-party conference implemented using unicast UDP with each participant receiving from the other two on separate port pairs. If each participant sends RTCP feedback about data received from one other participant only back to that participant, then the conference is composed of three separate point-to-point RTP sessions. If each participant provides RTCP feedback about its reception of one other participant to both of the other participants, then the conference is composed of one multi-party RTP session. The latter case simulates the behavior that would occur with IP multicast communication among the three participants.
RTP会话的显著特征是，每个会话都维护一个完整、独立的SSRC标识符空间（定义见下文）。一个RTP会话中包含的参与者集包括那些可以接收任何一个参与者在RTP中作为SSRC或CSC（定义见下文）或RTCP传输的SSRC标识符的参与者。例如，考虑使用单播UDP实现的三方会议，每个参与者在单独的端口对上从其他两个接收。如果每个参与者仅向该参与者发送关于从另一参与者收到的数据的RTCP反馈，则会议由三个独立的点对点RTP会话组成。如果每个参与者向其他两个参与者提供RTCP关于其接收另一个参与者的反馈，则会议由一个多方RTP会话组成。后一种情况模拟了三个参与者之间IP多播通信的行为。
The RTP framework allows the variations defined here, but a particular control protocol or application design will usually impose constraints on these variations.
RTP框架允许此处定义的变体，但特定的控制协议或应用程序设计通常会对这些变体施加约束。
Synchronization source (SSRC): The source of a stream of RTP packets, identified by a 32-bit numeric SSRC identifier carried in the RTP header so as not to be dependent upon the network address. All packets from a synchronization source form part of the same timing and sequence number space, so a receiver groups packets by synchronization source for playback. Examples of synchronization sources include the sender of a stream of packets derived from a signal source such as a microphone or a camera, or an RTP mixer (see below). A synchronization source may change its data format, e.g., audio encoding, over time. The SSRC identifier is a randomly chosen value meant to be globally unique within a particular RTP session (see Section 8). A participant need not use the same SSRC identifier for all the RTP sessions in a multimedia session; the binding of the SSRC identifiers is provided through RTCP (see Section 6.5.1). If a participant generates multiple streams in one RTP session, for example from separate video cameras, each MUST be identified as a different SSRC.
同步源（SSRC）：RTP数据包流的源，由RTP报头中携带的32位数字SSRC标识符标识，以便不依赖于网络地址。来自同步源的所有数据包构成相同定时和序列号空间的一部分，因此接收器按同步源对数据包进行分组以进行回放。同步源的示例包括从信号源（例如麦克风或照相机）或RTP混频器（参见下文）导出的数据包流的发送方。同步源可以随时间改变其数据格式，例如音频编码。SSRC标识符是随机选择的值，意味着在特定RTP会话中全局唯一（见第8节）。参与者不需要为多媒体会话中的所有RTP会话使用相同的SSRC标识符；SSRC标识符的绑定通过RTCP提供（见第6.5.1节）。如果参与者在一个RTP会话中生成多个流，例如从单独的摄像机生成多个流，则必须将每个流标识为不同的SSRC。
Contributing source (CSRC): A source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer (see below). The mixer inserts a list of the SSRC identifiers of the sources that contributed to the generation of a particular packet into the RTP header of that packet. This list is called the CSRC list. An example application is audio conferencing where a mixer indicates all the talkers whose speech
贡献源（CSC）：RTP数据包流的一个源，它对RTP混合器产生的组合流做出了贡献（见下文）。混合器将有助于生成特定分组的源的SSRC标识符的列表插入该分组的RTP报头中。该名单称为中国证监会名单。一个示例应用是音频会议，其中混音器指示所有讲话人的语音
was combined to produce the outgoing packet, allowing the receiver to indicate the current talker, even though all the audio packets contain the same SSRC identifier (that of the mixer).
合并后生成传出数据包，允许接收器指示当前说话者，即使所有音频数据包包含相同的SSRC标识符（混音器的标识符）。
End system: An application that generates the content to be sent in RTP packets and/or consumes the content of received RTP packets. An end system can act as one or more synchronization sources in a particular RTP session, but typically only one.
终端系统：生成RTP数据包中要发送的内容和/或使用接收到的RTP数据包内容的应用程序。终端系统可以在特定RTP会话中充当一个或多个同步源，但通常只有一个。
Mixer: An intermediate system that receives RTP packets from one or more sources, possibly changes the data format, combines the packets in some manner and then forwards a new RTP packet. Since the timing among multiple input sources will not generally be synchronized, the mixer will make timing adjustments among the streams and generate its own timing for the combined stream. Thus, all data packets originating from a mixer will be identified as having the mixer as their synchronization source.
混合器：从一个或多个源接收RTP数据包的中间系统，可能会更改数据格式，以某种方式组合数据包，然后转发新的RTP数据包。由于多个输入源之间的定时通常不会同步，因此混频器将在流之间进行定时调整，并为组合流生成其自己的定时。因此，来自混频器的所有数据分组将被标识为具有混频器作为其同步源。
Translator: An intermediate system that forwards RTP packets with their synchronization source identifier intact. Examples of translators include devices that convert encodings without mixing, replicators from multicast to unicast, and application-level filters in firewalls.
Translator：转发RTP数据包的中间系统，同步源标识符保持不变。转换器的示例包括在不混合的情况下转换编码的设备、从多播到单播的复制器以及防火墙中的应用程序级过滤器。
Monitor: An application that receives RTCP packets sent by participants in an RTP session, in particular the reception reports, and estimates the current quality of service for distribution monitoring, fault diagnosis and long-term statistics. The monitor function is likely to be built into the application(s) participating in the session, but may also be a separate application that does not otherwise participate and does not send or receive the RTP data packets (since they are on a separate port). These are called third-party monitors. It is also acceptable for a third-party monitor to receive the RTP data packets but not send RTCP packets or otherwise be counted in the session.
监视器：一种应用程序，用于接收RTP会话中参与者发送的RTCP数据包，尤其是接收报告，并估计当前的服务质量，以便进行分布监视、故障诊断和长期统计。监控功能可能内置于参与会话的应用程序中，但也可能是一个单独的应用程序，该应用程序不参与，也不发送或接收RTP数据包（因为它们位于单独的端口上）。这些被称为第三方监视器。第三方监视器也可以接收RTP数据包，但不发送RTCP数据包或在会话中计数。
Non-RTP means: Protocols and mechanisms that may be needed in addition to RTP to provide a usable service. In particular, for multimedia conferences, a control protocol may distribute multicast addresses and keys for encryption, negotiate the encryption algorithm to be used, and define dynamic mappings between RTP payload type values and the payload formats they represent for formats that do not have a predefined payload type value. Examples of such protocols include the Session Initiation Protocol (SIP) (RFC 3261 [13]), ITU Recommendation H.323 [14] and applications using SDP (RFC 2327 [15]), such as RTSP (RFC 2326 [16]). For simple
非RTP意味着：除了RTP之外，还可能需要协议和机制来提供可用的服务。具体地，对于多媒体会议，控制协议可以分发用于加密的多播地址和密钥，协商要使用的加密算法，并定义RTP有效负载类型值和它们所表示的有效负载格式之间的动态映射，用于不具有预定义有效负载类型值的格式。此类协议的示例包括会话发起协议（SIP）（RFC 3261[13]）、ITU建议H.323[14]和使用SDP的应用（RFC 2327[15]），例如RTSP（RFC 2326[16]）。简单地说
applications, electronic mail or a conference database may also be used. The specification of such protocols and mechanisms is outside the scope of this document.
也可以使用应用程序、电子邮件或会议数据库。此类协议和机制的规范不在本文件的范围内。
All integer fields are carried in network byte order, that is, most significant byte (octet) first. This byte order is commonly known as big-endian. The transmission order is described in detail in [3]. Unless otherwise noted, numeric constants are in decimal (base 10).
所有整数字段都是按网络字节顺序进行的，也就是说，最高有效字节（八位字节）排在第一位。这种字节顺序通常称为big-endian。[3]中详细描述了传输顺序。除非另有说明，否则数值常量为十进制（以10为基数）。
All header data is aligned to its natural length, i.e., 16-bit fields are aligned on even offsets, 32-bit fields are aligned at offsets divisible by four, etc. Octets designated as padding have the value zero.
所有报头数据都与其自然长度对齐，即16位字段按偶数偏移对齐，32位字段按可被4整除的偏移对齐，等等。指定为填充的八位字节的值为零。
Wallclock time (absolute date and time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900 [4]. The full resolution NTP timestamp is a 64-bit unsigned fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. In some fields where a more compact representation is appropriate, only the middle 32 bits are used; that is, the low 16 bits of the integer part and the high 16 bits of the fractional part. The high 16 bits of the integer part must be determined independently.
Wallclock时间（绝对日期和时间）使用网络时间协议（NTP）的时间戳格式表示，相对于1900年1月1日0h UTC，以秒为单位[4]。全分辨率NTP时间戳是一个64位无符号定点数字，整数部分在前32位，小数部分在后32位。在一些更紧凑的表示法适用的字段中，仅使用中间的32位；即，整数部分的低16位和小数部分的高16位。整数部分的高16位必须独立确定。
An implementation is not required to run the Network Time Protocol in order to use RTP. Other time sources, or none at all, may be used (see the description of the NTP timestamp field in Section 6.4.1). However, running NTP may be useful for synchronizing streams transmitted from separate hosts.
为了使用RTP，运行网络时间协议不需要实现。可使用其他时间源，或根本不使用（参见第6.4.1节中NTP时间戳字段的说明）。但是，运行NTP可能有助于同步从不同主机传输的流。
The NTP timestamp will wrap around to zero some time in the year 2036, but for RTP purposes, only differences between pairs of NTP timestamps are used. So long as the pairs of timestamps can be assumed to be within 68 years of each other, using modular arithmetic for subtractions and comparisons makes the wraparound irrelevant.
NTP时间戳将在2036年的某个时间变为零，但出于RTP目的，仅使用NTP时间戳对之间的差异。只要可以假设时间戳对彼此之间的间隔在68年之内，那么使用模块化算法进行减法和比较会使概括变得无关紧要。
The RTP header has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first twelve octets are present in every RTP packet, while the list of CSRC identifiers is present only when inserted by a mixer. The fields have the following meaning:
前12个八位字节存在于每个RTP数据包中，而CSC标识符列表仅在通过混频器插入时才存在。这些字段具有以下含义：
version (V): 2 bits This field identifies the version of RTP. The version defined by this specification is two (2). (The value 1 is used by the first draft version of RTP and the value 0 is used by the protocol initially implemented in the "vat" audio tool.)
版本（V）：2位此字段标识RTP的版本。本规范规定的版本为二（2）。（RTP初稿版本使用值1，最初在“vat”音频工具中实现的协议使用值0。）
padding (P): 1 bit If the padding bit is set, the packet contains one or more additional padding octets at the end which are not part of the payload. The last octet of the padding contains a count of how many padding octets should be ignored, including itself. Padding may be needed by some encryption algorithms with fixed block sizes or for carrying several RTP packets in a lower-layer protocol data unit.
padding（P）：1位如果设置了padding位，则数据包的末尾包含一个或多个额外的padding八位字节，它们不是有效负载的一部分。填充的最后一个八位字节包含应忽略的填充八位字节数，包括其本身。某些具有固定块大小的加密算法或在较低层协议数据单元中承载多个RTP数据包可能需要填充。
extension (X): 1 bit If the extension bit is set, the fixed header MUST be followed by exactly one header extension, with a format defined in Section 5.3.1.
扩展（X）：1位如果设置了扩展位，则固定标题后面必须紧跟一个标题扩展，格式见第5.3.1节。
CSRC count (CC): 4 bits The CSRC count contains the number of CSRC identifiers that follow the fixed header.
CSC计数（CC）：4位CSC计数包含固定标头后面的CSC标识符的数量。
marker (M): 1 bit The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. A profile MAY define additional marker bits or specify that there is no marker bit by changing the number of bits in the payload type field (see Section 5.3).
标记（M）：1位标记的解释由剖面定义。它旨在允许在分组流中标记诸如帧边界之类的重要事件。配置文件可以定义额外的标记位，或者通过更改有效负载类型字段中的位数来指定没有标记位（参见第5.3节）。
payload type (PT): 7 bits This field identifies the format of the RTP payload and determines its interpretation by the application. A profile MAY specify a default static mapping of payload type codes to payload formats. Additional payload type codes MAY be defined dynamically through non-RTP means (see Section 3). A set of default mappings for audio and video is specified in the companion RFC 3551 [1]. An RTP source MAY change the payload type during a session, but this field SHOULD NOT be used for multiplexing separate media streams (see Section 5.2).
有效负载类型（PT）：7位该字段标识RTP有效负载的格式，并确定应用程序对其的解释。配置文件可以指定有效负载类型代码到有效负载格式的默认静态映射。其他有效载荷类型代码可通过非RTP方式动态定义（见第3节）。配套RFC 3551[1]中指定了一组音频和视频的默认映射。RTP源可以在会话期间更改有效负载类型，但此字段不应用于多路复用单独的媒体流（参见第5.2节）。
A receiver MUST ignore packets with payload types that it does not understand.
接收器必须忽略其不了解的有效负载类型的数据包。
sequence number: 16 bits 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 packet sequence. The initial value of the sequence number SHOULD be random (unpredictable) to make known-plaintext attacks on encryption more difficult, even if the source itself does not encrypt according to the method in Section 9.1, because the packets may flow through a translator that does. Techniques for choosing unpredictable numbers are discussed in [17].
序列号：16位序列号对于发送的每个RTP数据包，序列号递增1，接收器可使用序列号检测数据包丢失并恢复数据包序列。序列号的初始值应该是随机的（不可预测的），以使对加密的已知明文攻击更加困难，即使源本身没有按照第9.1节中的方法进行加密，因为数据包可能会通过进行加密的转换器。[17]中讨论了选择不可预测数字的技术。
timestamp: 32 bits The timestamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant MUST be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations (see Section 6.4.1). The resolution of the clock MUST be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not sufficient). The clock frequency is dependent on the format of data carried as payload and is specified statically in the profile or payload format specification that defines the format, or MAY be specified dynamically for payload formats defined through non-RTP means. If RTP packets are generated periodically, the nominal sampling instant as determined from the sampling clock is to be used, not a reading of the system clock. As an example, for fixed-rate audio the timestamp clock would likely increment by one for each sampling period. If an audio application reads blocks covering
时间戳：32位时间戳反映RTP数据包中第一个八位字节的采样瞬间。采样瞬间必须从时间上单调线性递增的时钟中得出，以允许同步和抖动计算（见第6.4.1节）。时钟的分辨率必须足以达到所需的同步精度和测量数据包到达抖动（每个视频帧一个刻度通常是不够的）。时钟频率取决于作为有效载荷承载的数据的格式，并且在定义该格式的概要文件或有效载荷格式规范中静态地指定，或者可以针对通过非RTP方式定义的有效载荷格式动态地指定。如果定期生成RTP数据包，则将使用从采样时钟确定的标称采样瞬间，而不是系统时钟的读数。例如，对于固定速率音频，时间戳时钟对于每个采样周期可能增加一个。如果音频应用程序读取块覆盖
160 sampling periods from the input device, the timestamp would be increased by 160 for each such block, regardless of whether the block is transmitted in a packet or dropped as silent.
160从输入设备的采样周期，对于每个这样的块，时间戳将增加160，而不管该块是在分组中传输还是作为静默丢弃。
The initial value of the timestamp SHOULD be random, as for the sequence number. Several consecutive RTP packets will have equal timestamps if they are (logically) generated at once, e.g., belong to the same video frame. Consecutive RTP packets MAY contain timestamps that are not monotonic if the data is not transmitted in the order it was sampled, as in the case of MPEG interpolated video frames. (The sequence numbers of the packets as transmitted will still be monotonic.)
与序列号一样，时间戳的初始值应该是随机的。如果几个连续的RTP数据包（逻辑上）同时生成，例如，属于同一视频帧，则它们将具有相等的时间戳。如果数据没有按照采样顺序传输，则连续的RTP数据包可能包含非单调的时间戳，如在MPEG插值视频帧的情况下。（传输的数据包序列号仍然是单调的。）
RTP timestamps from different media streams may advance at different rates and usually have independent, random offsets. Therefore, although these timestamps are sufficient to reconstruct the timing of a single stream, directly comparing RTP timestamps from different media is not effective for synchronization. Instead, for each medium the RTP timestamp is related to the sampling instant by pairing it with a timestamp from a reference clock (wallclock) that represents the time when the data corresponding to the RTP timestamp was sampled. The reference clock is shared by all media to be synchronized. The timestamp pairs are not transmitted in every data packet, but at a lower rate in RTCP SR packets as described in Section 6.4.
来自不同媒体流的RTP时间戳可能以不同的速率前进，并且通常具有独立的随机偏移。因此，尽管这些时间戳足以重建单个流的定时，但是直接比较来自不同媒体的RTP时间戳对于同步来说是无效的。相反，对于每个介质，RTP时间戳通过与表示与RTP时间戳对应的数据被采样的时间的参考时钟（wallcock）的时间戳配对而与采样时刻相关。参考时钟由所有要同步的介质共享。时间戳对并非在每个数据包中传输，而是在RTCP SR包中以较低的速率传输，如第6.4节所述。
The sampling instant is chosen as the point of reference for the RTP timestamp because it is known to the transmitting endpoint and has a common definition for all media, independent of encoding delays or other processing. The purpose is to allow synchronized presentation of all media sampled at the same time.
选择采样瞬间作为RTP时间戳的参考点，因为传输端点知道它，并且对所有媒体都有一个共同的定义，与编码延迟或其他处理无关。其目的是允许同步显示同时采样的所有媒体。
Applications transmitting stored data rather than data sampled in real time typically use a virtual presentation timeline derived from wallclock time to determine when the next frame or other unit of each medium in the stored data should be presented. In this case, the RTP timestamp would reflect the presentation time for each unit. That is, the RTP timestamp for each unit would be related to the wallclock time at which the unit becomes current on the virtual presentation timeline. Actual presentation occurs some time later as determined by the receiver.
传输存储数据而非实时采样数据的应用程序通常使用从wallclock time派生的虚拟表示时间线来确定何时应显示存储数据中每个介质的下一帧或其他单元。在这种情况下，RTP时间戳将反映每个单元的呈现时间。也就是说，每个单元的RTP时间戳将与该单元在虚拟表示时间线上成为当前单元的墙时钟时间相关。根据接收者的判断，实际的呈现会在一段时间后发生。
An example describing live audio narration of prerecorded video illustrates the significance of choosing the sampling instant as the reference point. In this scenario, the video would be presented locally for the narrator to view and would be simultaneously transmitted using RTP. The "sampling instant" of a video frame transmitted in RTP would be established by referencing
一个描述预录视频的实时音频叙述的示例说明了选择采样瞬间作为参考点的重要性。在此场景中，视频将在本地呈现，供讲述人查看，并使用RTP同时传输。在RTP中传输的视频帧的“采样瞬间”将通过参考来建立
its timestamp to the wallclock time when that video frame was presented to the narrator. The sampling instant for the audio RTP packets containing the narrator's speech would be established by referencing the same wallclock time when the audio was sampled. The audio and video may even be transmitted by different hosts if the reference clocks on the two hosts are synchronized by some means such as NTP. A receiver can then synchronize presentation of the audio and video packets by relating their RTP timestamps using the timestamp pairs in RTCP SR packets.
它的时间戳是指视频帧呈现给讲述者时的挂钟时间。包含叙述者语音的音频RTP数据包的采样瞬间将通过引用音频采样时的相同挂钟时间来建立。如果两个主机上的参考时钟通过诸如NTP之类的某种方式同步，则音频和视频甚至可以由不同的主机传输。然后，接收机可以通过使用RTCP SR分组中的时间戳对关联其RTP时间戳来同步音频和视频分组的呈现。
SSRC: 32 bits The SSRC field identifies the synchronization source. This identifier SHOULD be chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier. An example algorithm for generating a random identifier is presented in Appendix A.6. Although the probability of multiple sources choosing the same identifier is low, all RTP implementations must be prepared to detect and resolve collisions. Section 8 describes the probability of collision along with a mechanism for resolving collisions and detecting RTP-level forwarding loops based on the uniqueness of the SSRC identifier. If a source changes its source transport address, it must also choose a new SSRC identifier to avoid being interpreted as a looped source (see Section 8.2).
SSRC:32位SSRC字段标识同步源。应随机选择该标识符，以确保同一RTP会话中的两个同步源不会具有相同的SSRC标识符。附录a.6中给出了生成随机标识符的示例算法。尽管多个源选择相同标识符的概率很低，但所有RTP实现都必须准备好检测和解决冲突。第8节描述了冲突的概率以及基于SSRC标识符的唯一性解决冲突和检测RTP级转发循环的机制。如果源更改其源传输地址，还必须选择新的SSRC标识符，以避免被解释为循环源（见第8.2节）。
CSRC list: 0 to 15 items, 32 bits each The CSRC list identifies the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 can be identified. CSRC identifiers are inserted by mixers (see Section 7.1), using the SSRC identifiers of contributing sources. For example, for audio packets the SSRC identifiers of all sources that were mixed together to create a packet are listed, allowing correct talker indication at the receiver.
CSC列表：0到15个项目，每个项目32位。CSC列表标识此数据包中包含的有效负载的贡献源。标识符的数量由CC字段给出。如果有15个以上的贡献来源，则只能确定15个。混合器使用贡献源的SSRC标识符插入CSC标识符（见第7.1节）。例如，对于音频分组，列出了混合在一起以创建分组的所有源的SSRC标识符，从而允许在接收机处正确指示说话者。
For efficient protocol processing, the number of multiplexing points should be minimized, as described in the integrated layer processing design principle [10]. In RTP, multiplexing is provided by the destination transport address (network address and port number) which is different for each RTP session. For example, in a teleconference composed of audio and video media encoded separately, each medium SHOULD be carried in a separate RTP session with its own destination transport address.
对于有效的协议处理，应尽量减少复用点的数量，如集成层处理设计原则[10]所述。在RTP中，多路复用由目标传输地址（网络地址和端口号）提供，该地址对于每个RTP会话是不同的。例如，在由单独编码的音频和视频媒体组成的电话会议中，每个媒体都应在单独的RTP会话中承载，并具有自己的目的地传输地址。
Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. Interleaving packets with different RTP media types but using the same SSRC would introduce several problems:
单独的音频和视频流不应在单个RTP会话中传输，并根据有效负载类型或SSRC字段进行解复用。交叉使用不同RTP媒体类型但使用相同SSRC的数据包会带来几个问题：
1. If, say, two audio streams shared the same RTP session and the same SSRC value, and one were to change encodings and thus acquire a different RTP payload type, there would be no general way of identifying which stream had changed encodings.
1. 例如，如果两个音频流共享相同的RTP会话和相同的SSRC值，而其中一个要更改编码并因此获得不同的RTP有效负载类型，则没有通用的方法来识别哪个流更改了编码。
2. An SSRC is defined to identify a single timing and sequence number space. Interleaving multiple payload types would require different timing spaces if the media clock rates differ and would require different sequence number spaces to tell which payload type suffered packet loss.
2. SSRC定义为识别单个定时和序列号空间。如果媒体时钟速率不同，则交错多个有效负载类型将需要不同的定时空间，并且将需要不同的序列号空间来告知哪种有效负载类型遭受了分组丢失。
3. The RTCP sender and receiver reports (see Section 6.4) can only describe one timing and sequence number space per SSRC and do not carry a payload type field.
3. RTCP发送方和接收方报告（见第6.4节）只能描述每个SSRC的一个定时和序列号空间，不包含有效负载类型字段。
4. An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream.
4. RTP混频器将无法将不兼容媒体的交错流组合成一个流。
5. Carrying multiple media in one RTP session precludes: the use of different network paths or network resource allocations if appropriate; reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth; and receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations.
5. 在一个RTP会话中承载多个媒体会排除：使用不同的网络路径或网络资源分配（如果合适）；如果需要，接收媒体的子集，例如，如果视频将超过可用带宽，则仅接收音频；以及对不同媒体使用单独进程的接收器实现，而使用单独的RTP会话允许单个或多个进程实现。
Using a different SSRC for each medium but sending them in the same RTP session would avoid the first three problems but not the last two.
对每种介质使用不同的SSRC，但在同一RTP会话中发送它们可以避免前三个问题，但不能避免后两个问题。
On the other hand, multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions. The problems listed above don't apply: an RTP mixer can combine multiple audio sources, for example, and the same treatment is applicable for all of them. It may also be appropriate to multiplex streams of the same medium using different SSRC values in other scenarios where the last two problems do not apply.
另一方面，在一个RTP会话中使用不同的SSRC值复用同一介质的多个相关源是多播会话的标准。上面列出的问题不适用：例如，RTP混音器可以组合多个音频源，并且相同的处理方法适用于所有音频源。在最后两个问题不适用的其他场景中，使用不同的SSRC值复用相同介质的流也可能是合适的。
The existing RTP data packet header is believed to be complete for the set of functions required in common across all the application classes that RTP might support. However, in keeping with the ALF design principle, the header MAY be tailored through modifications or additions defined in a profile specification while still allowing profile-independent monitoring and recording tools to function.
现有的RTP数据包报头被认为对于RTP可能支持的所有应用程序类通用所需的函数集是完整的。然而，根据ALF设计原则，可通过外形规范中定义的修改或添加来定制收割台，同时仍允许外形独立的监测和记录工具发挥作用。
o The marker bit and payload type field carry profile-specific information, but they are allocated in the fixed header since many applications are expected to need them and might otherwise have to add another 32-bit word just to hold them. The octet containing these fields MAY be redefined by a profile to suit different requirements, for example with more or fewer marker bits. If there are any marker bits, one SHOULD be located in the most significant bit of the octet since profile-independent monitors may be able to observe a correlation between packet loss patterns and the marker bit.
o 标记位和有效负载类型字段携带特定于配置文件的信息，但它们是在固定头中分配的，因为许多应用程序预计需要它们，否则可能不得不添加另一个32位字来保存它们。包含这些字段的八位字节可以通过配置文件重新定义，以适应不同的要求，例如使用更多或更少的标记位。如果存在任何标记位，则一个标记位应位于八位字节的最高有效位，因为与配置文件无关的监视器可能能够观察到丢包模式和标记位之间的相关性。
o Additional information that is required for a particular payload format, such as a video encoding, SHOULD be carried in the payload section of the packet. This might be in a header that is always present at the start of the payload section, or might be indicated by a reserved value in the data pattern.
o 特定有效载荷格式所需的附加信息，例如视频编码，应在分组的有效载荷部分中携带。这可能位于始终存在于有效负载部分开头的标头中，或者可能由数据模式中的保留值指示。
o If a particular class of applications needs additional functionality independent of payload format, the profile under which those applications operate SHOULD define additional fixed fields to follow immediately after the SSRC field of the existing fixed header. Those applications will be able to quickly and directly access the additional fields while profile-independent monitors or recorders can still process the RTP packets by interpreting only the first twelve octets.
o 如果特定类别的应用程序需要独立于有效负载格式的附加功能，则这些应用程序运行的配置文件应定义附加的固定字段，以紧跟在现有固定报头的SSRC字段之后。这些应用程序将能够快速直接地访问附加字段，而独立于配置文件的监视器或记录器仍然可以通过仅解释前12个八位字节来处理RTP数据包。
If it turns out that additional functionality is needed in common across all profiles, then a new version of RTP should be defined to make a permanent change to the fixed header.
如果所有概要文件都需要额外的功能，那么应该定义一个新版本的RTP，对固定头进行永久性更改。
An extension mechanism is provided to allow individual implementations to experiment with new payload-format-independent functions that require additional information to be carried in the RTP data packet header. This mechanism is designed so that the header extension may be ignored by other interoperating implementations that have not been extended.
提供了一种扩展机制，以允许单个实现试验新的有效负载格式独立的功能，这些功能需要在RTP数据包报头中携带附加信息。此机制的设计使得未扩展的其他互操作实现可以忽略标头扩展。
Note that this header extension is intended only for limited use. Most potential uses of this mechanism would be better done another way, using the methods described in the previous section. For example, a profile-specific extension to the fixed header is less expensive to process because it is not conditional nor in a variable location. Additional information required for a particular payload format SHOULD NOT use this header extension, but SHOULD be carried in the payload section of the packet.
请注意，此标题扩展仅用于有限的用途。这种机制的大多数潜在用途最好用另一种方法，即使用上一节中描述的方法。例如，固定标头的特定于概要文件的扩展处理成本较低，因为它既不是有条件的，也不在可变位置。特定有效负载格式所需的附加信息不应使用此报头扩展，而应在数据包的有效负载部分中携带。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |
If the X bit in the RTP header is one, a variable-length header extension MUST be appended to the RTP header, following the CSRC list if present. The header extension contains a 16-bit length field that counts the number of 32-bit words in the extension, excluding the four-octet extension header (therefore zero is a valid length). Only a single extension can be appended to the RTP data header. To allow multiple interoperating implementations to each experiment independently with different header extensions, or to allow a particular implementation to experiment with more than one type of header extension, the first 16 bits of the header extension are left open for distinguishing identifiers or parameters. The format of these 16 bits is to be defined by the profile specification under which the implementations are operating. This RTP specification does not define any header extensions itself.
如果RTP报头中的X位为1，则必须在RTP报头后附加可变长度报头扩展名，并遵循CSC列表（如果存在）。标头扩展包含一个16位长度字段，该字段统计扩展中32位的字数，不包括四个八位扩展标头（因此，零是有效长度）。RTP数据头只能附加一个扩展名。为了允许多个互操作实现分别使用不同的头扩展进行试验，或者为了允许特定实现使用多种类型的头扩展进行试验，头扩展的前16位保持打开状态，以便区分标识符或参数。这16位的格式将由配置文件规范定义，在该规范下实现操作。此RTP规范本身不定义任何头扩展。
The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol MUST provide multiplexing of the data and control packets, for example using separate port numbers with UDP. RTCP performs four functions:
RTP控制协议（RTCP）基于向会话中的所有参与者定期传输控制数据包，使用与数据包相同的分发机制。底层协议必须提供数据和控制数据包的多路复用，例如使用UDP的单独端口号。RTCP执行四项功能：
1. The primary function is to provide feedback on the quality of the data distribution. This is an integral part of the RTP's role as a transport protocol and is related to the flow and congestion control functions of other transport protocols (see Section 10 on the requirement for congestion control). The feedback may be directly useful for control of adaptive encodings [18,19], but experiments with IP multicasting have shown that it is also
1. 主要功能是提供有关数据分发质量的反馈。这是RTP作为传输协议的一个组成部分，与其他传输协议的流量和拥塞控制功能有关（参见第10节“拥塞控制要求”）。反馈可能直接用于自适应编码的控制[18,19]，但IP多播的实验表明，它也是有用的
critical to get feedback from the receivers to diagnose faults in the distribution. Sending reception feedback reports to all participants allows one who is observing problems to evaluate whether those problems are local or global. With a distribution mechanism like IP multicast, it is also possible for an entity such as a network service provider who is not otherwise involved in the session to receive the feedback information and act as a third-party monitor to diagnose network problems. This feedback function is performed by the RTCP sender and receiver reports, described below in Section 6.4.
从接收器获得反馈以诊断配电系统中的故障至关重要。通过向所有参与者发送接收反馈报告，观察问题的人可以评估这些问题是本地问题还是全球问题。利用诸如IP多播之类的分发机制，诸如网络服务提供商之类的实体也可以接收反馈信息，并充当第三方监视器来诊断网络问题，该实体不参与会话。该反馈功能由RTCP发送方和接收方报告执行，如下文第6.4节所述。
2. RTCP carries a persistent transport-level identifier for an RTP source called the canonical name or CNAME, Section 6.5.1. Since the SSRC identifier may change if a conflict is discovered or a program is restarted, receivers require the CNAME to keep track of each participant. Receivers may also require the CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, for example to synchronize audio and video. Inter-media synchronization also requires the NTP and RTP timestamps included in RTCP packets by data senders.
2. RTCP带有RTP源的持久传输级标识符，称为规范名称或CNAME，第6.5.1节。由于如果发现冲突或重新启动程序，SSRC标识符可能会更改，因此接收者需要CNAME跟踪每个参与者。接收机还可以要求CNAME在一组相关RTP会话中关联来自给定参与者的多个数据流，例如同步音频和视频。媒体间同步还需要数据发送方在RTCP数据包中包含NTP和RTP时间戳。
3. The first two functions require that all participants send RTCP packets, therefore the rate must be controlled in order for RTP to scale up to a large number of participants. By having each participant send its control packets to all the others, each can independently observe the number of participants. This number is used to calculate the rate at which the packets are sent, as explained in Section 6.2.
3. 前两个功能要求所有参与者发送RTCP数据包，因此必须控制速率，以便RTP扩展到大量参与者。通过让每个参与者向所有其他参与者发送其控制数据包，每个参与者都可以独立地观察参与者的数量。该数字用于计算数据包的发送速率，如第6.2节所述。
4. A fourth, OPTIONAL function is to convey minimal session control information, for example participant identification to be displayed in the user interface. This is most likely to be useful in "loosely controlled" sessions where participants enter and leave without membership control or parameter negotiation. RTCP serves as a convenient channel to reach all the participants, but it is not necessarily expected to support all the control communication requirements of an application. A higher-level session control protocol, which is beyond the scope of this document, may be needed.
4. 第四个可选功能是传递最小会话控制信息，例如要在用户界面中显示的参与者标识。这在“松散控制”的会话中非常有用，参与者在没有成员控制或参数协商的情况下进出。RTCP是联系所有参与者的便捷渠道，但并不一定支持应用程序的所有控制通信要求。可能需要更高级别的会话控制协议，这超出了本文档的范围。
Functions 1-3 SHOULD be used in all environments, but particularly in the IP multicast environment. RTP application designers SHOULD avoid mechanisms that can only work in unicast mode and will not scale to larger numbers. Transmission of RTCP MAY be controlled separately for senders and receivers, as described in Section 6.2, for cases such as unidirectional links where feedback from receivers is not possible.
功能1-3应在所有环境中使用，尤其是在IP多播环境中。RTP应用程序设计人员应该避免只能在单播模式下工作且不能扩展到更大数量的机制。如第6.2节所述，RTCP的传输可针对发送方和接收方分别进行控制，例如，在单向链路中，无法从接收方获得反馈。
Non-normative note: In the multicast routing approach called Source-Specific Multicast (SSM), there is only one sender per "channel" (a source address, group address pair), and receivers (except for the channel source) cannot use multicast to communicate directly with other channel members. The recommendations here accommodate SSM only through Section 6.2's option of turning off receivers' RTCP entirely. Future work will specify adaptation of RTCP for SSM so that feedback from receivers can be maintained.
非规范性说明：在称为源特定多播（SSM）的多播路由方法中，每个“通道”（源地址、组地址对）只有一个发送方，接收方（通道源除外）不能使用多播直接与其他通道成员通信。此处的建议仅通过第6.2节完全关闭接收机RTCP的选项来适应SSM。未来的工作将指定RTCP对SSM的自适应，以便能够保持来自接收器的反馈。
This specification defines several RTCP packet types to carry a variety of control information:
本规范定义了几种RTCP数据包类型，以承载各种控制信息：
SR: Sender report, for transmission and reception statistics from participants that are active senders
SR：发送者报告，用于从作为活动发送者的参与者发送和接收统计信息
RR: Receiver report, for reception statistics from participants that are not active senders and in combination with SR for active senders reporting on more than 31 sources
RR:Receiver report，用于非活动发件人参与者的接收统计信息，并与SR结合使用，用于报告31个以上来源的活动发件人
SDES: Source description items, including CNAME
SDES：源描述项，包括CNAME
BYE: Indicates end of participation
再见：表示参与结束
APP: Application-specific functions
应用程序：特定于应用程序的功能
Each RTCP packet begins with a fixed part similar to that of RTP data packets, followed by structured elements that MAY be of variable length according to the packet type but MUST end on a 32-bit boundary. The alignment requirement and a length field in the fixed part of each packet are included to make RTCP packets "stackable". Multiple RTCP packets can be concatenated without any intervening separators to form a compound RTCP packet that is sent in a single packet of the lower layer protocol, for example UDP. There is no explicit count of individual RTCP packets in the compound packet since the lower layer protocols are expected to provide an overall length to determine the end of the compound packet.
每个RTCP数据包以一个类似于RTP数据包的固定部分开始，然后是根据数据包类型具有可变长度但必须在32位边界上结束的结构化元素。每个数据包的固定部分包含对齐要求和长度字段，以使RTCP数据包“可堆叠”。多个RTCP数据包可以在没有任何中间分隔符的情况下连接起来，以形成复合RTCP数据包，该复合RTCP数据包在较低层协议（例如UDP）的单个数据包中发送。复合数据包中没有单个RTCP数据包的明确计数，因为较低层协议预期提供总长度以确定复合数据包的结束。
Each individual RTCP packet in the compound packet may be processed independently with no requirements upon the order or combination of packets. However, in order to perform the functions of the protocol, the following constraints are imposed:
复合分组中的每个单独RTCP分组可以独立处理，而不需要对分组的顺序或组合进行任何要求。然而，为了执行协议的功能，施加了以下约束：
o Reception statistics (in SR or RR) should be sent as often as bandwidth constraints will allow to maximize the resolution of the statistics, therefore each periodically transmitted compound RTCP packet MUST include a report packet.
o 接收统计数据（在SR或RR中）应尽可能频繁地发送，因为带宽限制将允许最大限度地提高统计数据的分辨率，因此每个周期性传输的复合RTCP数据包必须包括一个报告数据包。
o New receivers need to receive the CNAME for a source as soon as possible to identify the source and to begin associating media for purposes such as lip-sync, so each compound RTCP packet MUST also include the SDES CNAME except when the compound RTCP packet is split for partial encryption as described in Section 9.1.
o 新的接收者需要尽快接收某个源的CNAME，以识别该源，并开始关联媒体以实现唇形同步等目的，因此每个复合RTCP数据包还必须包括SDES CNAME，但如第9.1节所述，将复合RTCP数据包拆分为部分加密时除外。
o The number of packet types that may appear first in the compound packet needs to be limited to increase the number of constant bits in the first word and the probability of successfully validating RTCP packets against misaddressed RTP data packets or other unrelated packets.
o 需要限制可能首先出现在复合分组中的分组类型的数量，以增加第一字中恒定比特的数量以及针对错误寻址的RTP数据分组或其他不相关分组成功验证RTCP分组的概率。
Thus, all RTCP packets MUST be sent in a compound packet of at least two individual packets, with the following format:
因此，所有RTCP数据包必须以至少两个单独数据包的复合数据包的形式发送，格式如下：
Encryption prefix: If and only if the compound packet is to be encrypted according to the method in Section 9.1, it MUST be prefixed by a random 32-bit quantity redrawn for every compound packet transmitted. If padding is required for the encryption, it MUST be added to the last packet of the compound packet.
加密前缀：当且仅当根据第9.1节中的方法对复合数据包进行加密时，其前缀必须为每个传输的复合数据包重新绘制的随机32位数量。如果加密需要填充，则必须将其添加到复合数据包的最后一个数据包中。
SR or RR: The first RTCP packet in the compound packet MUST always be a report packet to facilitate header validation as described in Appendix A.2. This is true even if no data has been sent or received, in which case an empty RR MUST be sent, and even if the only other RTCP packet in the compound packet is a BYE.
SR或RR：复合数据包中的第一个RTCP数据包必须始终是报告数据包，以便于进行附录a.2中所述的报头验证。即使未发送或接收任何数据（在这种情况下，必须发送空RR），并且即使复合数据包中唯一的其他RTCP数据包是BYE，情况也是如此。
Additional RRs: If the number of sources for which reception statistics are being reported exceeds 31, the number that will fit into one SR or RR packet, then additional RR packets SHOULD follow the initial report packet.
附加RRs：如果正在报告接收统计信息的源的数量超过31个，将适合一个SR或RR数据包的数量，则附加RR数据包应跟随初始报告数据包。
SDES: An SDES packet containing a CNAME item MUST be included in each compound RTCP packet, except as noted in Section 9.1. Other source description items MAY optionally be included if required by a particular application, subject to bandwidth constraints (see Section 6.3.9).
SDES：包含CNAME项目的SDES数据包必须包含在每个复合RTCP数据包中，除非第9.1节另有说明。如果特定应用需要，根据带宽限制（见第6.3.9节），可以选择包括其他源描述项。
BYE or APP: Other RTCP packet types, including those yet to be defined, MAY follow in any order, except that BYE SHOULD be the last packet sent with a given SSRC/CSRC. Packet types MAY appear more than once.
BYE或APP：其他RTCP数据包类型，包括尚未定义的数据包类型，可按任何顺序跟随，但BYE应为使用给定SSRC/CSC发送的最后一个数据包除外。数据包类型可能出现多次。
An individual RTP participant SHOULD send only one compound RTCP packet per report interval in order for the RTCP bandwidth per participant to be estimated correctly (see Section 6.2), except when the compound RTCP packet is split for partial encryption as described in Section 9.1. If there are too many sources to fit all the necessary RR packets into one compound RTCP packet without exceeding the maximum transmission unit (MTU) of the network path, then only the subset that will fit into one MTU SHOULD be included in each interval. The subsets SHOULD be selected round-robin across multiple intervals so that all sources are reported.
单个RTP参与者应在每个报告间隔内仅发送一个复合RTCP数据包，以便正确估计每个参与者的RTCP带宽（参见第6.2节），但如第9.1节所述将复合RTCP数据包拆分为部分加密时除外。如果源太多，无法在不超过网络路径的最大传输单位（MTU）的情况下将所有必要的RR数据包装入一个复合RTCP数据包，则每个间隔中只应包括将装入一个MTU的子集。子集应在多个时间间隔内循环选择，以便报告所有来源。
It is RECOMMENDED that translators and mixers combine individual RTCP packets from the multiple sources they are forwarding into one compound packet whenever feasible in order to amortize the packet overhead (see Section 7). An example RTCP compound packet as might be produced by a mixer is shown in Fig. 1. If the overall length of a compound packet would exceed the MTU of the network path, it SHOULD be segmented into multiple shorter compound packets to be transmitted in separate packets of the underlying protocol. This does not impair the RTCP bandwidth estimation because each compound packet represents at least one distinct participant. Note that each of the compound packets MUST begin with an SR or RR packet.
建议翻译器和混频器在可行的情况下，将来自其转发的多个源的单个RTCP数据包合并为一个复合数据包，以分摊数据包开销（见第7节）。图1中示出了可能由混合器产生的示例RTCP复合分组。如果复合数据包的总长度将超过网络路径的MTU，则应将其分割为多个较短的复合数据包，以在基础协议的单独数据包中传输。这不会影响RTCP带宽估计，因为每个复合数据包至少代表一个不同的参与者。请注意，每个复合数据包必须以SR或RR数据包开头。
An implementation SHOULD ignore incoming RTCP packets with types unknown to it. Additional RTCP packet types may be registered with the Internet Assigned Numbers Authority (IANA) as described in Section 15.
实现应忽略类型未知的传入RTCP数据包。如第15节所述，其他RTCP数据包类型可向互联网分配号码管理局（IANA）注册。
if encrypted: random 32-bit integer
|
|[--------- packet --------][---------- packet ----------][-packet-]
|
| receiver chunk chunk
V reports item item item item
--------------------------------------------------------------------
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
--------------------------------------------------------------------
| |
|<----------------------- compound packet ----------------------->|
|<-------------------------- UDP packet ------------------------->|
if encrypted: random 32-bit integer
|
|[--------- packet --------][---------- packet ----------][-packet-]
|
| receiver chunk chunk
V reports item item item item
--------------------------------------------------------------------
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
--------------------------------------------------------------------
| |
|<----------------------- compound packet ----------------------->|
|<-------------------------- UDP packet ------------------------->|
#: SSRC/CSRC identifier
#: SSRC/CSRC identifier
Figure 1: Example of an RTCP compound packet
图1:RTCP复合数据包示例
RTP is designed to allow an application to scale automatically over session sizes ranging from a few participants to thousands. For example, in an audio conference the data traffic is inherently self-limiting because only one or two people will speak at a time, so with multicast distribution the data rate on any given link remains relatively constant independent of the number of participants. However, the control traffic is not self-limiting. If the reception reports from each participant were sent at a constant rate, the control traffic would grow linearly with the number of participants. Therefore, the rate must be scaled down by dynamically calculating the interval between RTCP packet transmissions.
RTP的设计允许应用程序自动扩展会话大小，从几个参与者到数千人不等。例如，在音频会议中，数据流量本质上是自我限制的，因为一次只有一到两个人发言，因此通过多播分发，任何给定链路上的数据速率保持相对恒定，与参与者的数量无关。但是，控制流量不是自限的。如果来自每个参与者的接收报告以恒定速率发送，则控制流量将随参与者数量线性增长。因此，必须通过动态计算RTCP数据包传输之间的间隔来降低速率。
For each session, it is assumed that the data traffic is subject to an aggregate limit called the "session bandwidth" to be divided among the participants. This bandwidth might be reserved and the limit enforced by the network. If there is no reservation, there may be other constraints, depending on the environment, that establish the "reasonable" maximum for the session to use, and that would be the session bandwidth. The session bandwidth may be chosen based on some cost or a priori knowledge of the available network bandwidth for the session. It is somewhat independent of the media encoding, but the encoding choice may be limited by the session bandwidth. Often, the session bandwidth is the sum of the nominal bandwidths of the senders expected to be concurrently active. For teleconference audio, this number would typically be one sender's bandwidth. For layered encodings, each layer is a separate RTP session with its own session bandwidth parameter.
对于每个会话，假设数据通信量受到称为“会话带宽”的聚合限制的约束，该聚合限制将在参与者之间分配。网络可能会保留此带宽并强制执行此限制。如果没有保留，则可能存在其他约束（取决于环境），这些约束确定会话要使用的“合理”最大值，即会话带宽。可以基于会话的可用网络带宽的一些成本或先验知识来选择会话带宽。它在某种程度上独立于媒体编码，但编码选择可能受到会话带宽的限制。通常，会话带宽是预期同时活动的发送方的标称带宽之和。对于电话会议音频，这个数字通常是一个发送者的带宽。对于分层编码，每个层都是一个单独的RTP会话，具有自己的会话带宽参数。
The session bandwidth parameter is expected to be supplied by a session management application when it invokes a media application, but media applications MAY set a default based on the single-sender data bandwidth for the encoding selected for the session. The application MAY also enforce bandwidth limits based on multicast scope rules or other criteria. All participants MUST use the same value for the session bandwidth so that the same RTCP interval will be calculated.
会话带宽参数预计将由会话管理应用程序在调用媒体应用程序时提供，但媒体应用程序可以基于为会话选择的编码的单个发送方数据带宽设置默认值。应用程序还可以基于多播作用域规则或其他标准强制实施带宽限制。所有参与者必须使用相同的会话带宽值，以便计算相同的RTCP间隔。
Bandwidth calculations for control and data traffic include lower-layer transport and network protocols (e.g., UDP and IP) since that is what the resource reservation system would need to know. The application can also be expected to know which of these protocols are in use. Link level headers are not included in the calculation since the packet will be encapsulated with different link level headers as it travels.
控制和数据流量的带宽计算包括较低层的传输和网络协议（如UDP和IP），因为这是资源预留系统需要知道的。应用程序还可以知道正在使用这些协议中的哪些。链路级报头不包括在计算中，因为数据包在传输时将使用不同的链路级报头进行封装。
The control traffic should be limited to a small and known fraction of the session bandwidth: small so that the primary function of the transport protocol to carry data is not impaired; known so that the control traffic can be included in the bandwidth specification given to a resource reservation protocol, and so that each participant can independently calculate its share. The control traffic bandwidth is in addition to the session bandwidth for the data traffic. It is RECOMMENDED that the fraction of the session bandwidth added for RTCP be fixed at 5%. It is also RECOMMENDED that 1/4 of the RTCP bandwidth be dedicated to participants that are sending data so that in sessions with a large number of receivers but a small number of senders, newly joining participants will more quickly receive the CNAME for the sending sites. When the proportion of senders is greater than 1/4 of the participants, the senders get their proportion of the full RTCP bandwidth. While the values of these and other constants in the interval calculation are not critical, all participants in the session MUST use the same values so the same interval will be calculated. Therefore, these constants SHOULD be fixed for a particular profile.
控制通信量应限制在会话带宽的一小部分：小到传输协议承载数据的主要功能不受损害；已知，因此控制流量可以包含在给定给资源预留协议的带宽规范中，并且每个参与者可以独立计算其份额。控制流量带宽是对数据流量的会话带宽的补充。建议将为RTCP添加的会话带宽部分固定为5%。还建议将RTCP带宽的1/4专用于发送数据的参与者，以便在有大量接收者但只有少量发送者的会话中，新加入的参与者将更快地接收发送站点的CNAME。当发送方的比例大于参与者的1/4时，发送方将获得其全部RTCP带宽的比例。虽然间隔计算中这些常数和其他常数的值并不重要，但会话中的所有参与者必须使用相同的值，以便计算相同的间隔。因此，对于特定的配置文件，这些常量应该是固定的。
A profile MAY specify that the control traffic bandwidth may be a separate parameter of the session rather than a strict percentage of the session bandwidth. Using a separate parameter allows rate-adaptive applications to set an RTCP bandwidth consistent with a "typical" data bandwidth that is lower than the maximum bandwidth specified by the session bandwidth parameter.
配置文件可以指定控制业务带宽可以是会话的单独参数，而不是会话带宽的严格百分比。使用单独的参数允许速率自适应应用程序设置RTCP带宽，该带宽与低于会话带宽参数指定的最大带宽的“典型”数据带宽一致。
The profile MAY further specify that the control traffic bandwidth may be divided into two separate session parameters for those participants which are active data senders and those which are not; let us call the parameters S and R. Following the recommendation that 1/4 of the RTCP bandwidth be dedicated to data senders, the RECOMMENDED default values for these two parameters would be 1.25% and 3.75%, respectively. When the proportion of senders is greater than S/(S+R) of the participants, the senders get their proportion of the sum of these parameters. Using two parameters allows RTCP reception reports to be turned off entirely for a particular session by setting the RTCP bandwidth for non-data-senders to zero while keeping the RTCP bandwidth for data senders non-zero so that sender reports can still be sent for inter-media synchronization. Turning off RTCP reception reports is NOT RECOMMENDED because they are needed for the functions listed at the beginning of Section 6, particularly reception quality feedback and congestion control. However, doing so may be appropriate for systems operating on unidirectional links or for sessions that don't require feedback on the quality of reception or liveness of receivers and that have other means to avoid congestion.
该简档可以进一步指定，对于那些是活动数据发送者和那些不是活动数据发送者的参与者，控制业务带宽可以被划分为两个单独的会话参数；让我们调用参数S和R。根据将RTCP带宽的1/4专用于数据发送方的建议，这两个参数的建议默认值分别为1.25%和3.75%。当发送者的比例大于参与者的S/（S+R）时，发送者将获得这些参数之和的比例。通过使用两个参数，可以将非数据发送方的RTCP带宽设置为零，同时将数据发送方的RTCP带宽保持为非零，从而完全关闭特定会话的RTCP接收报告，以便仍然可以发送发送方报告进行媒体间同步。不建议关闭RTCP接收报告，因为第6节开头列出的功能需要这些报告，特别是接收质量反馈和拥塞控制。然而，这样做可能适用于在单向链路上运行的系统，或者不需要对接收质量或接收器的活跃度进行反馈并且具有其他方法来避免拥塞的会话。
The calculated interval between transmissions of compound RTCP packets SHOULD also have a lower bound to avoid having bursts of packets exceed the allowed bandwidth when the number of participants is small and the traffic isn't smoothed according to the law of large numbers. It also keeps the report interval from becoming too small during transient outages like a network partition such that adaptation is delayed when the partition heals. At application startup, a delay SHOULD be imposed before the first compound RTCP packet is sent to allow time for RTCP packets to be received from other participants so the report interval will converge to the correct value more quickly. This delay MAY be set to half the minimum interval to allow quicker notification that the new participant is present. The RECOMMENDED value for a fixed minimum interval is 5 seconds.
复合RTCP数据包传输之间的计算间隔也应该有一个下限，以避免在参与者人数较少且流量未根据大数定律平滑时，数据包突发超过允许带宽。它还可以防止报告间隔在诸如网络分区之类的短暂中断期间变得太小，从而在分区恢复时延迟自适应。在应用程序启动时，应在发送第一个复合RTCP数据包之前施加延迟，以便有时间从其他参与者处接收RTCP数据包，以便报告间隔更快地收敛到正确的值。此延迟可设置为最小间隔的一半，以便更快地通知新参与者。固定最小间隔的建议值为5秒。
An implementation MAY scale the minimum RTCP interval to a smaller value inversely proportional to the session bandwidth parameter with the following limitations:
实现可将最小RTCP间隔缩放为与会话带宽参数成反比的较小值，但有以下限制：
o For multicast sessions, only active data senders MAY use the reduced minimum value to calculate the interval for transmission of compound RTCP packets.
o 对于多播会话，只有活动数据发送方可以使用减少的最小值来计算复合RTCP数据包的传输间隔。
o For unicast sessions, the reduced value MAY be used by participants that are not active data senders as well, and the delay before sending the initial compound RTCP packet MAY be zero.
o 对于单播会话，减少的值也可由非活动数据发送者的参与者使用，并且发送初始复合RTCP分组之前的延迟可为零。
o For all sessions, the fixed minimum SHOULD be used when calculating the participant timeout interval (see Section 6.3.5) so that implementations which do not use the reduced value for transmitting RTCP packets are not timed out by other participants prematurely.
o 对于所有会话，计算参与者超时时间间隔时应使用固定的最小值（见第6.3.5节），以便不使用缩减值传输RTCP数据包的实现不会被其他参与者过早超时。
o The RECOMMENDED value for the reduced minimum in seconds is 360 divided by the session bandwidth in kilobits/second. This minimum is smaller than 5 seconds for bandwidths greater than 72 kb/s.
o 减少的最小值（以秒为单位）的建议值是360除以会话带宽（以千位/秒为单位）。对于大于72 kb/s的带宽，此最小值小于5秒。
The algorithm described in Section 6.3 and Appendix A.7 was designed to meet the goals outlined in this section. It calculates the interval between sending compound RTCP packets to divide the allowed control traffic bandwidth among the participants. This allows an application to provide fast response for small sessions where, for example, identification of all participants is important, yet automatically adapt to large sessions. The algorithm incorporates the following characteristics:
第6.3节和附录A.7中描述的算法旨在满足本节中概述的目标。它计算发送复合RTCP数据包之间的间隔，以在参与者之间分配允许的控制流量带宽。这使得应用程序能够为小型会话提供快速响应，例如，在小型会话中，所有参与者的标识都很重要，但会自动适应大型会话。该算法包含以下特征：
o The calculated interval between RTCP packets scales linearly with the number of members in the group. It is this linear factor which allows for a constant amount of control traffic when summed across all members.
o RTCP数据包之间的计算间隔与组中的成员数成线性比例。正是这一线性因素允许在所有成员之间求和时，控制流量保持恒定。
o The interval between RTCP packets is varied randomly over the range [0.5,1.5] times the calculated interval to avoid unintended synchronization of all participants [20]. The first RTCP packet sent after joining a session is also delayed by a random variation of half the minimum RTCP interval.
o RTCP数据包之间的间隔在计算间隔的[0.5,1.5]倍范围内随机变化，以避免所有参与者的意外同步[20]。加入会话后发送的第一个RTCP数据包也会因最小RTCP间隔一半的随机变化而延迟。
o A dynamic estimate of the average compound RTCP packet size is calculated, including all those packets received and sent, to automatically adapt to changes in the amount of control information carried.
o 计算平均复合RTCP数据包大小的动态估计，包括所有接收和发送的数据包，以自动适应所携带控制信息量的变化。
o Since the calculated interval is dependent on the number of observed group members, there may be undesirable startup effects when a new user joins an existing session, or many users simultaneously join a new session. These new users will initially have incorrect estimates of the group membership, and thus their RTCP transmission interval will be too short. This problem can be significant if many users join the session simultaneously. To deal with this, an algorithm called "timer reconsideration" is employed. This algorithm implements a simple back-off mechanism which causes users to hold back RTCP packet transmission if the group sizes are increasing.
o 由于计算的间隔取决于观察到的组成员的数量，因此当新用户加入现有会话或多个用户同时加入新会话时，可能会出现不希望的启动效果。这些新用户最初对组成员的估计不正确，因此他们的RTCP传输间隔将太短。如果多个用户同时加入会话，则此问题可能非常严重。为了解决这个问题，采用了一种称为“计时器重新考虑”的算法。该算法实现了一种简单的退避机制，当组大小增加时，该机制会导致用户阻止RTCP数据包传输。
o When users leave a session, either with a BYE or by timeout, the group membership decreases, and thus the calculated interval should decrease. A "reverse reconsideration" algorithm is used to allow members to more quickly reduce their intervals in response to group membership decreases.
o 当用户通过BYE或超时退出会话时，组成员资格将减少，因此计算的间隔应减少。“反向重新考虑”算法用于允许成员更快地缩短间隔，以响应组成员减少。
o BYE packets are given different treatment than other RTCP packets. When a user leaves a group, and wishes to send a BYE packet, it may do so before its next scheduled RTCP packet. However, transmission of BYEs follows a back-off algorithm which avoids floods of BYE packets should a large number of members simultaneously leave the session.
o BYE数据包的处理方式与其他RTCP数据包不同。当用户离开组并希望发送BYE数据包时，可以在下一个预定RTCP数据包之前发送。然而，如果大量成员同时离开会话，则BYE的传输遵循退避算法，该算法可避免BYE数据包的泛滥。
This algorithm may be used for sessions in which all participants are allowed to send. In that case, the session bandwidth parameter is the product of the individual sender's bandwidth times the number of participants, and the RTCP bandwidth is 5% of that.
此算法可用于允许所有参与者发送消息的会话。在这种情况下，会话带宽参数是单个发送方的带宽乘以参与者数量的乘积，RTCP带宽是该值的5%。
Details of the algorithm's operation are given in the sections that follow. Appendix A.7 gives an example implementation.
算法操作的详细信息在下面的章节中给出。附录A.7给出了一个实施示例。
Calculation of the RTCP packet interval depends upon an estimate of the number of sites participating in the session. New sites are added to the count when they are heard, and an entry for each SHOULD be created in a table indexed by the SSRC or CSRC identifier (see Section 8.2) to keep track of them. New entries MAY be considered not valid until multiple packets carrying the new SSRC have been received (see Appendix A.1), or until an SDES RTCP packet containing a CNAME for that SSRC has been received. Entries MAY be deleted from the table when an RTCP BYE packet with the corresponding SSRC identifier is received, except that some straggler data packets might arrive after the BYE and cause the entry to be recreated. Instead, the entry SHOULD be marked as having received a BYE and then deleted after an appropriate delay.
RTCP数据包间隔的计算取决于参与会话的站点数量的估计。当听到新的站点时，会将其添加到计数中，并且应在由SSRC或CSC标识符索引的表中为每个站点创建一个条目（参见第8.2节），以跟踪它们。在收到携带新SSRC的多个数据包之前（见附录A.1），或在收到包含该SSRC CNAME的SDES RTCP数据包之前，新条目可能被视为无效。当接收到具有相应SSRC标识符的RTCP BYE数据包时，可以从表中删除条目，但某些散乱数据包可能在BYE之后到达并导致重新创建条目。相反，条目应标记为已收到BYE，并在适当延迟后删除。
A participant MAY mark another site inactive, or delete it if not yet valid, if no RTP or RTCP packet has been received for a small number of RTCP report intervals (5 is RECOMMENDED). This provides some robustness against packet loss. All sites must have the same value for this multiplier and must calculate roughly the same value for the RTCP report interval in order for this timeout to work properly. Therefore, this multiplier SHOULD be fixed for a particular profile.
如果在少量RTCP报告间隔内（建议5次）未收到RTP或RTCP数据包，参与者可将另一站点标记为非活动，或将其删除（如果尚未生效）。这提供了一些抗数据包丢失的健壮性。所有站点必须具有此乘数的相同值，并且必须为RTCP报告间隔计算大致相同的值，以便此超时正常工作。因此，对于特定的配置文件，该乘数应该是固定的。
For sessions with a very large number of participants, it may be impractical to maintain a table to store the SSRC identifier and state information for all of them. An implementation MAY use SSRC sampling, as described in [21], to reduce the storage requirements. An implementation MAY use any other algorithm with similar performance. A key requirement is that any algorithm considered SHOULD NOT substantially underestimate the group size, although it MAY overestimate.
对于参与者数量非常多的会话，维护一个表来存储所有参与者的SSRC标识符和状态信息可能是不切实际的。实现可以使用SSRC采样，如[21]中所述，以减少存储需求。实现可以使用具有类似性能的任何其他算法。一个关键要求是，所考虑的任何算法都不应严重低估组大小，尽管它可能会高估。
The rules for how to send, and what to do when receiving an RTCP packet are outlined here. An implementation that allows operation in a multicast environment or a multipoint unicast environment MUST meet the requirements in Section 6.2. Such an implementation MAY use the algorithm defined in this section to meet those requirements, or MAY use some other algorithm so long as it provides equivalent or better performance. An implementation which is constrained to two-party unicast operation SHOULD still use randomization of the RTCP transmission interval to avoid unintended synchronization of multiple instances operating in the same environment, but MAY omit the "timer reconsideration" and "reverse reconsideration" algorithms in Sections 6.3.3, 6.3.6 and 6.3.7.
此处概述了如何发送以及接收RTCP数据包时应执行的操作规则。允许在多播环境或多点单播环境中运行的实现必须满足第6.2节的要求。这种实现可以使用本节中定义的算法来满足这些要求，也可以使用其他算法，只要它提供同等或更好的性能。受限于两方单播操作的实现仍应使用RTCP传输间隔的随机化，以避免在同一环境中运行的多个实例的意外同步，但可省略第6.3.3、6.3.6和6.3.7节中的“计时器重新考虑”和“反向重新考虑”算法。
To execute these rules, a session participant must maintain several pieces of state:
要执行这些规则，会话参与者必须维护多个状态：
tp: the last time an RTCP packet was transmitted;
tp：上次传输RTCP数据包的时间；
tc: the current time;
tc：当前时间；
tn: the next scheduled transmission time of an RTCP packet;
tn：RTCP数据包的下一个预定传输时间；
pmembers: the estimated number of session members at the time tn was last recomputed;
pmembers：上次重新计算tn时估计的会话成员数；
members: the most current estimate for the number of session members;
成员：会议成员人数的最新估计数；
senders: the most current estimate for the number of senders in the session;
发件人：会话中发件人数量的最新估计值；
rtcp_bw: The target RTCP bandwidth, i.e., the total bandwidth that will be used for RTCP packets by all members of this session, in octets per second. This will be a specified fraction of the "session bandwidth" parameter supplied to the application at startup.
rtcp_bw：目标rtcp带宽，即此会话的所有成员将用于rtcp数据包的总带宽，以每秒八位字节为单位。这将是启动时提供给应用程序的“会话带宽”参数的指定部分。
we_sent: Flag that is true if the application has sent data since the 2nd previous RTCP report was transmitted.
we_sent：如果应用程序自上次第二次RTCP报告传输后已发送数据，则该标志为真。
avg_rtcp_size: The average compound RTCP packet size, in octets, over all RTCP packets sent and received by this participant. The size includes lower-layer transport and network protocol headers (e.g., UDP and IP) as explained in Section 6.2.
avg_rtcp_size：此参与者发送和接收的所有rtcp数据包的平均复合rtcp数据包大小（以八位字节为单位）。如第6.2节所述，大小包括较低层传输和网络协议头（如UDP和IP）。
initial: Flag that is true if the application has not yet sent an RTCP packet.
initial：如果应用程序尚未发送RTCP数据包，则为true的标志。
Many of these rules make use of the "calculated interval" between packet transmissions. This interval is described in the following section.
这些规则中的许多都利用了数据包传输之间的“计算间隔”。下一节将介绍此间隔。
To maintain scalability, the average interval between packets from a session participant should scale with the group size. This interval is called the calculated interval. It is obtained by combining a number of the pieces of state described above. The calculated interval T is then determined as follows:
为了保持可伸缩性，来自会话参与者的数据包之间的平均间隔应随组大小而伸缩。此间隔称为计算间隔。它是通过组合上述多个状态片段而获得的。然后，计算的间隔T确定如下：
1. If the number of senders is less than or equal to 25% of the membership (members), the interval depends on whether the participant is a sender or not (based on the value of we_sent). If the participant is a sender (we_sent true), the constant C is set to the average RTCP packet size (avg_rtcp_size) divided by 25% of the RTCP bandwidth (rtcp_bw), and the constant n is set to the number of senders. If we_sent is not true, the constant C is set to the average RTCP packet size divided by 75% of the RTCP bandwidth. The constant n is set to the number of receivers (members - senders). If the number of senders is greater than 25%, senders and receivers are treated together. The constant C is set to the average RTCP packet size divided by the total RTCP bandwidth and n is set to the total number of members. As stated in Section 6.2, an RTP profile MAY specify that the RTCP bandwidth may be explicitly defined by two separate parameters (call them S and R) for those participants which are senders and those which are not. In that case, the 25% fraction becomes S/(S+R) and the 75% fraction becomes R/(S+R). Note that if R is zero, the percentage of senders is never greater than S/(S+R), and the implementation must avoid division by zero.
1. 如果发件人数量小于或等于成员（成员）的25%，则间隔取决于参与者是否为发件人（基于we_sent的值）。如果参与者是发送方（we_sent true），则常数C设置为平均RTCP数据包大小（平均RTCP大小）除以RTCP带宽（RTCP_bw）的25%，常数n设置为发送方数量。如果we_sent不为true，则常数C设置为平均RTCP数据包大小除以RTCP带宽的75%。常数n被设置为接收者（成员-发送者）的数量。如果发送者数量大于25%，发送者和接收者将一起处理。常数C设置为平均RTCP数据包大小除以总RTCP带宽，n设置为成员总数。如第6.2节所述，RTP配置文件可规定RTCP带宽可由两个单独的参数（称为S和R）明确定义，用于发送方和非发送方的参与者。在这种情况下，25%的分数变为S/（S+R），75%的分数变为R/（S+R）。请注意，如果R为零，则发送者的百分比永远不会大于S/（S+R），并且实现必须避免被零除。
2. If the participant has not yet sent an RTCP packet (the variable initial is true), the constant Tmin is set to 2.5 seconds, else it is set to 5 seconds.
2. 如果参与者尚未发送RTCP数据包（变量initial为true），则常数Tmin设置为2.5秒，否则设置为5秒。
3. The deterministic calculated interval Td is set to max(Tmin, n*C).
3. 确定性计算间隔Td设置为最大值（Tmin，n*C）。
4. The calculated interval T is set to a number uniformly distributed between 0.5 and 1.5 times the deterministic calculated interval.
4. 将计算间隔T设置为均匀分布在确定性计算间隔0.5到1.5倍之间的数字。
5. The resulting value of T is divided by e-3/2=1.21828 to compensate for the fact that the timer reconsideration algorithm converges to a value of the RTCP bandwidth below the intended average.
5. T的结果值除以e-3/2=1.21828，以补偿计时器算法收敛到低于预期平均值的RTCP带宽值这一事实。
This procedure results in an interval which is random, but which, on average, gives at least 25% of the RTCP bandwidth to senders and the rest to receivers. If the senders constitute more than one quarter of the membership, this procedure splits the bandwidth equally among all participants, on average.
此过程产生的间隔是随机的，但平均而言，至少25%的RTCP带宽分配给发送方，其余的分配给接收方。如果发送者占成员的四分之一以上，则此过程平均在所有参与者之间平均分配带宽。
Upon joining the session, the participant initializes tp to 0, tc to 0, senders to 0, pmembers to 1, members to 1, we_sent to false, rtcp_bw to the specified fraction of the session bandwidth, initial to true, and avg_rtcp_size to the probable size of the first RTCP packet that the application will later construct. The calculated interval T is then computed, and the first packet is scheduled for
Upon joining the session, the participant initializes tp to 0, tc to 0, senders to 0, pmembers to 1, members to 1, we_sent to false, rtcp_bw to the specified fraction of the session bandwidth, initial to true, and avg_rtcp_size to the probable size of the first RTCP packet that the application will later construct. The calculated interval T is then computed, and the first packet is scheduled fortranslate error, please retry
time tn = T. This means that a transmission timer is set which expires at time T. Note that an application MAY use any desired approach for implementing this timer.
时间tn=T。这意味着设置了一个传输计时器，该计时器在时间T到期。请注意，应用程序可以使用任何期望的方法来实现该计时器。
The participant adds its own SSRC to the member table.
参与者将自己的SSRC添加到成员表中。
When an RTP or RTCP packet is received from a participant whose SSRC is not in the member table, the SSRC is added to the table, and the value for members is updated once the participant has been validated as described in Section 6.2.1. The same processing occurs for each CSRC in a validated RTP packet.
当从SSRC不在成员表中的参与者处收到RTP或RTCP数据包时，SSRC被添加到表中，并且一旦参与者按照第6.2.1节所述进行了验证，成员的值就会更新。对于已验证RTP数据包中的每个CSC，也会发生相同的处理。
When an RTP packet is received from a participant whose SSRC is not in the sender table, the SSRC is added to the table, and the value for senders is updated.
当从SSRC不在发送者表中的参与者接收RTP数据包时，SSRC将添加到表中，并且发送者的值将更新。
For each compound RTCP packet received, the value of avg_rtcp_size is updated:
对于接收到的每个复合RTCP数据包，将更新平均RTCP大小的值：
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
where packet_size is the size of the RTCP packet just received.
其中，packet_size是刚接收到的RTCP数据包的大小。
Except as described in Section 6.3.7 for the case when an RTCP BYE is to be transmitted, if the received packet is an RTCP BYE packet, the SSRC is checked against the member table. If present, the entry is removed from the table, and the value for members is updated. The SSRC is then checked against the sender table. If present, the entry is removed from the table, and the value for senders is updated.
除第6.3.7节所述的传输RTCP BYE的情况外，如果收到的数据包是RTCP BYE数据包，则根据成员表检查SSRC。如果存在，则从表中删除该条目，并更新成员的值。然后根据发送方表检查SSRC。如果存在，则从表中删除该条目，并更新发件人的值。
Furthermore, to make the transmission rate of RTCP packets more adaptive to changes in group membership, the following "reverse reconsideration" algorithm SHOULD be executed when a BYE packet is received that reduces members to a value less than pmembers:
此外，为了使RTCP数据包的传输速率更适应组成员资格的变化，当接收到将成员减少到小于pmembers的值的BYE数据包时，应执行以下“反向重新考虑”算法：
o The value for tn is updated according to the following formula:
o 根据以下公式更新tn值：
tn = tc + (members/pmembers) * (tn - tc)
tn = tc + (members/pmembers) * (tn - tc)
o The value for tp is updated according the following formula:
o tp的值根据以下公式更新：
tp = tc - (members/pmembers) * (tc - tp).
tp=tc-（成员/成员）*（tc-tp）。
o The next RTCP packet is rescheduled for transmission at time tn, which is now earlier.
o 下一个RTCP数据包被重新安排在时间tn传输，时间tn现在更早。
o The value of pmembers is set equal to members.
o pmembers的值设置为等于members。
This algorithm does not prevent the group size estimate from incorrectly dropping to zero for a short time due to premature timeouts when most participants of a large session leave at once but some remain. The algorithm does make the estimate return to the correct value more rapidly. This situation is unusual enough and the consequences are sufficiently harmless that this problem is deemed only a secondary concern.
当大型会话的大多数参与者立即离开，但一些参与者仍在时，由于过早超时，此算法无法防止组大小估计值在短时间内错误地降至零。该算法确实使估计值更快地返回到正确值。这种情况很不寻常，其后果也很无害，因此这个问题被认为只是次要问题。
At occasional intervals, the participant MUST check to see if any of the other participants time out. To do this, the participant computes the deterministic (without the randomization factor) calculated interval Td for a receiver, that is, with we_sent false. Any other session member who has not sent an RTP or RTCP packet since time tc - MTd (M is the timeout multiplier, and defaults to 5) is timed out. This means that its SSRC is removed from the member list, and members is updated. A similar check is performed on the sender list. Any member on the sender list who has not sent an RTP packet since time tc - 2T (within the last two RTCP report intervals) is removed from the sender list, and senders is updated.
偶尔，参与者必须检查其他参与者是否超时。为此，参与者计算接收机的确定性（不含随机化因子）计算间隔Td，即we_sent false。自时间tc-MTd（M是超时乘数，默认为5）超时后未发送RTP或RTCP数据包的任何其他会话成员。这意味着其SSRC将从成员列表中删除，并更新成员。对发件人列表执行类似的检查。自tc-2T（在最近两个RTCP报告间隔内）从发送者列表中删除并更新发送者后，发送者列表中未发送RTP数据包的任何成员。
If any members time out, the reverse reconsideration algorithm described in Section 6.3.4 SHOULD be performed.
如果任何成员超时，应执行第6.3.4节中描述的反向重新考虑算法。
The participant MUST perform this check at least once per RTCP transmission interval.
参与者必须在每个RTCP传输间隔内至少执行一次此检查。
When the packet transmission timer expires, the participant performs the following operations:
当数据包传输计时器到期时，参与者执行以下操作：
o The transmission interval T is computed as described in Section 6.3.1, including the randomization factor.
o 传输间隔T的计算如第6.3.1节所述，包括随机化因子。
o If tp + T is less than or equal to tc, an RTCP packet is transmitted. tp is set to tc, then another value for T is calculated as in the previous step and tn is set to tc + T. The transmission timer is set to expire again at time tn. If tp + T is greater than tc, tn is set to tp + T. No RTCP packet is transmitted. The transmission timer is set to expire at time tn.
o 如果tp+T小于或等于tc，则传输RTCP数据包。tp设置为tc，然后按照上一步计算T的另一个值，tn设置为tc+T。传输计时器设置为在tn时再次过期。如果tp+T大于tc，tn设置为tp+T。不传输RTCP数据包。传输计时器设置为在时间tn时过期。
o pmembers is set to members.
o pmembers设置为members。
If an RTCP packet is transmitted, the value of initial is set to FALSE. Furthermore, the value of avg_rtcp_size is updated:
如果传输RTCP数据包，则初始值设置为FALSE。此外，avg_rtcp_size的值更新为：
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
where packet_size is the size of the RTCP packet just transmitted.
其中，packet_size是刚刚传输的RTCP数据包的大小。
When a participant wishes to leave a session, a BYE packet is transmitted to inform the other participants of the event. In order to avoid a flood of BYE packets when many participants leave the system, a participant MUST execute the following algorithm if the number of members is more than 50 when the participant chooses to leave. This algorithm usurps the normal role of the members variable to count BYE packets instead:
当一个参与者希望离开一个会话时，会发送一个BYE数据包来通知其他参与者该事件。为了避免许多参与者离开系统时BYE数据包泛滥，如果参与者选择离开时成员数超过50，则参与者必须执行以下算法。此算法取代members变量的正常角色来计算BYE数据包：
o When the participant decides to leave the system, tp is reset to tc, the current time, members and pmembers are initialized to 1, initial is set to 1, we_sent is set to false, senders is set to 0, and avg_rtcp_size is set to the size of the compound BYE packet. The calculated interval T is computed. The BYE packet is then scheduled for time tn = tc + T.
o 当参与者决定离开系统时，tp重置为tc，当前时间、成员和成员初始化为1，initial设置为1，we_sent设置为false，senders设置为0，avg_rtcp_size设置为复合BYE数据包的大小。计算出的间隔T。然后将BYE分组调度为时间tn＝tc+T。
o Every time a BYE packet from another participant is received, members is incremented by 1 regardless of whether that participant exists in the member table or not, and when SSRC sampling is in use, regardless of whether or not the BYE SSRC would be included in the sample. members is NOT incremented when other RTCP packets or RTP packets are received, but only for BYE packets. Similarly, avg_rtcp_size is updated only for received BYE packets. senders is NOT updated when RTP packets arrive; it remains 0.
o 每次收到来自另一个参与者的BYE数据包时，无论该参与者是否存在于成员表中，以及SSRC采样正在使用时，无论BYE SSRC是否将包含在样本中，成员都将递增1。当接收到其他RTCP数据包或RTP数据包时，成员不会增加，但仅针对BYE数据包。同样，avg_rtcp_大小仅针对收到的BYE数据包进行更新。RTP数据包到达时，发送方未更新；它仍然是0。
o Transmission of the BYE packet then follows the rules for transmitting a regular RTCP packet, as above.
o 然后，BYE数据包的传输遵循传输常规RTCP数据包的规则，如上所述。
This allows BYE packets to be sent right away, yet controls their total bandwidth usage. In the worst case, this could cause RTCP control packets to use twice the bandwidth as normal (10%) -- 5% for non-BYE RTCP packets and 5% for BYE.
这允许立即发送BYE数据包，但控制其总带宽使用。在最坏的情况下，这可能会导致RTCP控制数据包使用正常带宽的两倍（10%）——非BYE RTCP数据包使用5%，BYE数据包使用5%。
A participant that does not want to wait for the above mechanism to allow transmission of a BYE packet MAY leave the group without sending a BYE at all. That participant will eventually be timed out by the other group members.
不希望等待上述机制来允许BYE分组的传输的参与者可以在根本不发送BYE的情况下离开组。该参与者最终将被其他组成员超时。
If the group size estimate members is less than 50 when the participant decides to leave, the participant MAY send a BYE packet immediately. Alternatively, the participant MAY choose to execute the above BYE backoff algorithm.
当参与者决定离开时，如果组大小估计成员小于50，则参与者可立即发送BYE数据包。或者，参与者可以选择执行上述BYE退避算法。
In either case, a participant which never sent an RTP or RTCP packet MUST NOT send a BYE packet when they leave the group.
在这两种情况下，从未发送RTP或RTCP数据包的参与者在离开组时不得发送BYE数据包。
The variable we_sent contains true if the participant has sent an RTP packet recently, false otherwise. This determination is made by using the same mechanisms as for managing the set of other participants listed in the senders table. If the participant sends an RTP packet when we_sent is false, it adds itself to the sender table and sets we_sent to true. The reverse reconsideration algorithm described in Section 6.3.4 SHOULD be performed to possibly reduce the delay before sending an SR packet. Every time another RTP packet is sent, the time of transmission of that packet is maintained in the table. The normal sender timeout algorithm is then applied to the participant -- if an RTP packet has not been transmitted since time tc - 2T, the participant removes itself from the sender table, decrements the sender count, and sets we_sent to false.
如果参与者最近发送了RTP数据包，则我们发送的变量包含true，否则为false。通过使用与管理senders表中列出的其他参与者集相同的机制进行确定。如果参与者在we_sent为false时发送RTP数据包，它会将自身添加到sender表中，并将we_sent设置为true。应执行第6.3.4节中描述的反向重新考虑算法，以尽可能减少发送SR数据包之前的延迟。每次发送另一个RTP数据包时，该数据包的传输时间保留在表中。然后将正常的发送方超时算法应用于参与者——如果自时间tc-2T以来没有发送RTP数据包，则参与者将自己从发送方表中移除，减少发送方计数，并将we_sent设置为false。
This specification defines several source description (SDES) items in addition to the mandatory CNAME item, such as NAME (personal name) and EMAIL (email address). It also provides a means to define new application-specific RTCP packet types. Applications should exercise caution in allocating control bandwidth to this additional information because it will slow down the rate at which reception reports and CNAME are sent, thus impairing the performance of the protocol. It is RECOMMENDED that no more than 20% of the RTCP bandwidth allocated to a single participant be used to carry the additional information. Furthermore, it is not intended that all SDES items will be included in every application. Those that are included SHOULD be assigned a fraction of the bandwidth according to their utility. Rather than estimate these fractions dynamically, it is recommended that the percentages be translated statically into report interval counts based on the typical length of an item.
除了强制的CNAME项目外，本规范还定义了几个源描述（SDES）项目，如姓名（个人姓名）和电子邮件（电子邮件地址）。它还提供了定义新的特定于应用程序的RTCP数据包类型的方法。应用程序在为这些附加信息分配控制带宽时应谨慎，因为这会降低接收报告和CNAME的发送速率，从而影响协议的性能。建议不超过分配给单个参与者的RTCP带宽的20%用于传输附加信息。此外，并非所有SDES项目都包含在每个应用程序中。根据它们的效用，应该为包含的那些分配一部分带宽。建议将百分比静态转换为基于项目典型长度的报告间隔计数，而不是动态估计这些分数。
For example, an application may be designed to send only CNAME, NAME and EMAIL and not any others. NAME might be given much higher priority than EMAIL because the NAME would be displayed continuously in the application's user interface, whereas EMAIL would be displayed only when requested. At every RTCP interval, an RR packet and an SDES packet with the CNAME item would be sent. For a small session
例如，应用程序可能被设计为只发送CNAME、姓名和电子邮件，而不发送任何其他信息。名称可能比电子邮件具有更高的优先级，因为名称将连续显示在应用程序的用户界面中，而电子邮件将仅在请求时显示。在每个RTCP间隔，将发送带有CNAME项的RR数据包和SDES数据包。开个小会
operating at the minimum interval, that would be every 5 seconds on the average. Every third interval (15 seconds), one extra item would be included in the SDES packet. Seven out of eight times this would be the NAME item, and every eighth time (2 minutes) it would be the EMAIL item.
以最小间隔运行，平均每5秒一次。每隔第三个间隔（15秒），SDES数据包中将包含一个额外的项目。八次中有七次是姓名项，每八次（2分钟）是电子邮件项。
When multiple applications operate in concert using cross-application binding through a common CNAME for each participant, for example in a multimedia conference composed of an RTP session for each medium, the additional SDES information MAY be sent in only one RTP session. The other sessions would carry only the CNAME item. In particular, this approach should be applied to the multiple sessions of a layered encoding scheme (see Section 2.4).
当多个应用程序通过每个参与者的公共CNAME使用跨应用程序绑定协同操作时，例如在由每个媒体的RTP会话组成的多媒体会议中，可以仅在一个RTP会话中发送附加SDES信息。其他会议将只进行CNAME项目。特别是，这种方法应适用于分层编码方案的多个会话（见第2.4节）。
RTP receivers provide reception quality feedback using RTCP report packets which may take one of two forms depending upon whether or not the receiver is also a sender. The only difference between the sender report (SR) and receiver report (RR) forms, besides the packet type code, is that the sender report includes a 20-byte sender information section for use by active senders. The SR is issued if a site has sent any data packets during the interval since issuing the last report or the previous one, otherwise the RR is issued.
RTP接收机使用RTCP报告包提供接收质量反馈，根据接收机是否也是发送方，RTCP报告包可能采用两种形式之一。除了数据包类型代码之外，发送方报告（SR）和接收方报告（RR）表单之间的唯一区别在于，发送方报告包含一个20字节的发送方信息部分，供活动发送方使用。如果站点在发布上次报告或上次报告后的间隔期间发送了任何数据包，则会发布SR，否则会发布RR。
Both the SR and RR forms include zero or more reception report blocks, one for each of the synchronization sources from which this receiver has received RTP data packets since the last report. Reports are not issued for contributing sources listed in the CSRC list. Each reception report block provides statistics about the data received from the particular source indicated in that block. Since a maximum of 31 reception report blocks will fit in an SR or RR packet, additional RR packets SHOULD be stacked after the initial SR or RR packet as needed to contain the reception reports for all sources heard during the interval since the last report. If there are too many sources to fit all the necessary RR packets into one compound RTCP packet without exceeding the MTU of the network path, then only the subset that will fit into one MTU SHOULD be included in each interval. The subsets SHOULD be selected round-robin across multiple intervals so that all sources are reported.
SR和RR形式都包括零个或多个接收报告块，一个用于自上次报告以来该接收机从中接收RTP数据分组的每个同步源。报告不针对中国证监会名单中列出的贡献来源发布。每个接收报告块提供关于从该块中指示的特定源接收的数据的统计信息。由于SR或RR数据包中最多可容纳31个接收报告块，因此应根据需要在初始SR或RR数据包之后堆叠额外的RR数据包，以包含自上次报告以来间隔期间听到的所有源的接收报告。如果源太多，无法在不超过网络路径MTU的情况下将所有必要的RR数据包装入一个复合RTCP数据包，则每个间隔中只应包括将装入一个MTU的子集。子集应在多个时间间隔内循环选择，以便报告所有来源。
The next sections define the formats of the two reports, how they may be extended in a profile-specific manner if an application requires additional feedback information, and how the reports may be used. Details of reception reporting by translators and mixers is given in Section 7.
下一节将定义两个报告的格式，如果应用程序需要额外的反馈信息，如何以特定于概要文件的方式扩展它们，以及如何使用报告。翻译和混音员的接待报告详情见第7节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sender report packet consists of three sections, possibly followed by a fourth profile-specific extension section if defined. The first section, the header, is 8 octets long. The fields have the following meaning:
发送者报告包由三个部分组成，如果定义的话，后面可能跟第四个配置文件特定的扩展部分。第一部分，标题，是8个八位字节长。这些字段具有以下含义：
version (V): 2 bits Identifies the version of RTP, which is the same in RTCP packets as in RTP data packets. The version defined by this specification is two (2).
版本（V）：2位标识RTP的版本，RTP数据包中的版本与RTP数据包中的版本相同。本规范规定的版本为二（2）。
padding (P): 1 bit If the padding bit is set, this individual RTCP packet contains some additional padding octets at the end which are not part of the control information but are included in the length field. The last octet of the padding is a count of how many padding octets should be ignored, including itself (it will be a multiple of four). Padding may be needed by some encryption algorithms with fixed block sizes. In a compound RTCP packet, padding is only required on one individual packet because the compound packet is encrypted as a whole for the method in Section 9.1. Thus, padding MUST only be added to the last individual packet, and if padding is added to that packet, the padding bit MUST be set only on that packet. This convention aids the header validity checks described in Appendix A.2 and allows detection of packets from some early implementations that incorrectly set the padding bit on the first individual packet and add padding to the last individual packet.
padding（P）：1位如果设置了padding位，则此单个RTCP数据包的末尾包含一些额外的padding八位字节，这些八位字节不属于控制信息的一部分，但包含在长度字段中。填充的最后一个八位字节是应该忽略多少填充八位字节的计数，包括它本身（它将是四的倍数）。某些具有固定块大小的加密算法可能需要填充。在复合RTCP数据包中，只需要对一个单独的数据包进行填充，因为复合数据包按照第9.1节中的方法作为一个整体进行加密。因此，只能将填充添加到最后一个单独的数据包，如果将填充添加到该数据包，则必须仅在该数据包上设置填充位。该约定有助于附录A.2中所述的报头有效性检查，并允许检测来自一些早期实现的数据包，这些数据包错误地在第一个单独的数据包上设置了填充位，并在最后一个单独的数据包上添加了填充。
reception report count (RC): 5 bits The number of reception report blocks contained in this packet. A value of zero is valid.
接收报告计数（RC）：5位此数据包中包含的接收报告块数。值为零是有效的。
packet type (PT): 8 bits Contains the constant 200 to identify this as an RTCP SR packet.
数据包类型（PT）：8位包含常数200，用于将其标识为RTCP SR数据包。
length: 16 bits The length of this RTCP packet in 32-bit words minus one, including the header and any padding. (The offset of one makes zero a valid length and avoids a possible infinite loop in scanning a compound RTCP packet, while counting 32-bit words avoids a validity check for a multiple of 4.)
长度：16位此RTCP数据包的长度（32位字减去1），包括标头和任何填充。（偏移量为1使零成为有效长度，并避免扫描复合RTCP数据包时可能出现的无限循环，而计数32位字可避免对4的倍数进行有效性检查。）
SSRC: 32 bits The synchronization source identifier for the originator of this SR packet.
SSRC:32位此SR数据包的发起方的同步源标识符。
The second section, the sender information, is 20 octets long and is present in every sender report packet. It summarizes the data transmissions from this sender. The fields have the following meaning:
第二部分是发送方信息，长度为20个八位字节，存在于每个发送方报告包中。它总结了来自此发送方的数据传输。这些字段具有以下含义：
NTP timestamp: 64 bits Indicates the wallclock time (see Section 4) when this report was sent so that it may be used in combination with timestamps returned in reception reports from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the timestamp may be limited to far less than the resolution of the NTP timestamp. The measurement uncertainty of the timestamp is not indicated as it
NTP timestamp：64位表示发送此报告时的挂钟时间（参见第4节），因此它可以与从其他接收器接收报告中返回的时间戳结合使用，以测量到这些接收器的往返传播。接收机应期望时间戳的测量精度可被限制为远小于NTP时间戳的分辨率。时间戳的测量不确定度未显示为
may not be known. On a system that has no notion of wallclock time but does have some system-specific clock such as "system uptime", a sender MAY use that clock as a reference to calculate relative NTP timestamps. It is important to choose a commonly used clock so that if separate implementations are used to produce the individual streams of a multimedia session, all implementations will use the same clock. Until the year 2036, relative and absolute timestamps will differ in the high bit so (invalid) comparisons will show a large difference; by then one hopes relative timestamps will no longer be needed. A sender that has no notion of wallclock or elapsed time MAY set the NTP timestamp to zero.
可能不知道。在没有wallclock时间概念但具有某些系统特定时钟（如“系统正常运行时间”）的系统上，发送方可以使用该时钟作为参考来计算相对NTP时间戳。选择一个常用的时钟非常重要，这样，如果使用单独的实现来生成多媒体会话的各个流，那么所有实现都将使用相同的时钟。直到2036年，相对时间戳和绝对时间戳将在高位上有所不同，因此（无效）比较将显示较大的差异；到那时，人们希望不再需要相对时间戳。没有挂钟或已用时间概念的发送方可以将NTP时间戳设置为零。
RTP timestamp: 32 bits Corresponds to the same time as the NTP timestamp (above), but in the same units and with the same random offset as the RTP timestamps in data packets. This correspondence may be used for intra- and inter-media synchronization for sources whose NTP timestamps are synchronized, and may be used by media-independent receivers to estimate the nominal RTP clock frequency. Note that in most cases this timestamp will not be equal to the RTP timestamp in any adjacent data packet. Rather, it MUST be calculated from the corresponding NTP timestamp using the relationship between the RTP timestamp counter and real time as maintained by periodically checking the wallclock time at a sampling instant.
RTP时间戳：32位对应于与NTP时间戳（如上）相同的时间，但单位相同，随机偏移量与数据包中的RTP时间戳相同。该对应可用于其NTP时间戳被同步的源的媒体内和媒体间同步，并且可由媒体独立接收机用于估计标称RTP时钟频率。注意，在大多数情况下，该时间戳将不等于任何相邻数据包中的RTP时间戳。相反，必须使用RTP时间戳计数器和实时之间的关系（通过在采样时刻定期检查wallclock时间来维护）从相应的NTP时间戳计算它。
sender's packet count: 32 bits The total number of RTP data packets transmitted by the sender since starting transmission up until the time this SR packet was generated. The count SHOULD be reset if the sender changes its SSRC identifier.
发送方数据包计数：32位自开始传输到生成此SR数据包为止，发送方传输的RTP数据包总数。如果发送方更改其SSRC标识符，则应重置计数。
sender's octet count: 32 bits The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since starting transmission up until the time this SR packet was generated. The count SHOULD be reset if the sender changes its SSRC identifier. This field can be used to estimate the average payload data rate.
发送方的八位字节计数：32位从开始传输到生成此SR数据包为止，发送方在RTP数据包中传输的有效负载八位字节总数（即，不包括报头或填充）。如果发送方更改其SSRC标识符，则应重置计数。此字段可用于估计平均有效负载数据速率。
The third section contains zero or more reception report blocks depending on the number of other sources heard by this sender since the last report. Each reception report block conveys statistics on the reception of RTP packets from a single synchronization source. Receivers SHOULD NOT carry over statistics when a source changes its SSRC identifier due to a collision. These statistics are:
第三部分包含零个或多个接收报告块，这取决于自上次报告以来该发送者听到的其他来源的数量。每个接收报告块传送关于从单个同步源接收RTP数据包的统计信息。当源因冲突而更改其SSRC标识符时，接收方不应进行统计。这些统计数字如下：
SSRC_n (source identifier): 32 bits The SSRC identifier of the source to which the information in this reception report block pertains.
SSRC_n（源标识符）：32位此接收报告块中的信息所属的源的SSRC标识符。
fraction lost: 8 bits The fraction of RTP data packets from source SSRC_n lost since the previous SR or RR packet was sent, expressed as a fixed point number with the binary point at the left edge of the field. (That is equivalent to taking the integer part after multiplying the loss fraction by 256.) This fraction is defined to be the number of packets lost divided by the number of packets expected, as defined in the next paragraph. An implementation is shown in Appendix A.3. If the loss is negative due to duplicates, the fraction lost is set to zero. Note that a receiver cannot tell whether any packets were lost after the last one received, and that there will be no reception report block issued for a source if all packets from that source sent during the last reporting interval have been lost.
分数丢失：8位自上一个SR或RR数据包发送以来，源SSRC_n的RTP数据包丢失的分数，表示为固定点数，二进制点位于字段左边缘。（这相当于将丢失分数乘以256后取整数部分。）该分数定义为丢失的数据包数除以预期数据包数，如下一段中所定义。附录A.3中给出了一个实施方案。如果由于重复而导致损失为负值，则损失的分数将设置为零。请注意，接收器无法判断在最后一个接收到的数据包之后是否有任何数据包丢失，并且如果在最后一个报告间隔期间从该数据源发送的所有数据包都丢失，则不会为该数据源发出接收报告块。
cumulative number of packets lost: 24 bits The total number of RTP data packets from source SSRC_n that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. Thus, packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. This may be calculated as shown in Appendix A.3.
累计丢失数据包数：24位自接收开始以来已丢失的来自源SSRC\n的RTP数据包总数。该数字被定义为预期的数据包数量减去实际接收的数据包数量，其中接收的数据包数量包括任何延迟或重复的数据包。因此，延迟到达的数据包不被视为丢失，如果存在重复数据包，则丢失可能为负。预期的数据包数定义为接收到的扩展的最后一个序列号，如下面定义的，减去接收到的初始序列号。可按照附录A.3所示进行计算。
extended highest sequence number received: 32 bits The low 16 bits contain the highest sequence number received in an RTP data packet from source SSRC_n, and the most significant 16 bits extend that sequence number with the corresponding count of sequence number cycles, which may be maintained according to the algorithm in Appendix A.1. Note that different receivers within the same session will generate different extensions to the sequence number if their start times differ significantly.
接收到的扩展最高序列号：32位低16位包含从源SSRC_n接收的RTP数据包中的最高序列号，最高有效16位使用相应的序列号周期计数扩展该序列号，可根据附录A.1中的算法进行维护。请注意，如果同一会话中的不同接收器的开始时间显著不同，则它们将生成序列号的不同扩展。
interarrival jitter: 32 bits An estimate of the statistical variance of the RTP data packet interarrival time, measured in timestamp units and expressed as an unsigned integer. The interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of packets. As shown in the equation below, this is equivalent to the difference in the "relative transit time" for the two packets;
到达间隔抖动：32位RTP数据包到达间隔时间的统计方差估计值，以时间戳单位测量，并表示为无符号整数。到达间抖动J被定义为一对分组的接收器处的分组间隔与发送器处的分组间隔之差D的平均偏差（平滑绝对值）。如下面的等式所示，这相当于两个数据包的“相对传输时间”之差；
the relative transit time is the difference between a packet's RTP timestamp and the receiver's clock at the time of arrival, measured in the same units.
相对传输时间是数据包的RTP时间戳和到达时接收器时钟之间的差值，以相同的单位测量。
If Si is the RTP timestamp from packet i, and Ri is the time of arrival in RTP timestamp units for packet i, then for two packets i and j, D may be expressed as
如果Si是来自分组i的RTP时间戳，Ri是分组i的以RTP时间戳为单位的到达时间，那么对于两个分组i和j，D可以表示为
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
The interarrival jitter SHOULD be calculated continuously as each data packet i is received from source SSRC_n, using this difference D for that packet and the previous packet i-1 in order of arrival (not necessarily in sequence), according to the formula
当从源SSRC_n接收到每个数据分组i时，应根据以下公式，使用该分组与前一分组i-1的差值D，按照到达顺序（不一定是顺序）连续计算到达间抖动
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
Whenever a reception report is issued, the current value of J is sampled.
每当发出接收报告时，对J的当前值进行采样。
The jitter calculation MUST conform to the formula specified here in order to allow profile-independent monitors to make valid interpretations of reports coming from different implementations. This algorithm is the optimal first-order estimator and the gain parameter 1/16 gives a good noise reduction ratio while maintaining a reasonable rate of convergence [22]. A sample implementation is shown in Appendix A.8. See Section 6.4.4 for a discussion of the effects of varying packet duration and delay before transmission.
抖动计算必须符合此处指定的公式，以便允许独立于配置文件的监控器对来自不同实现的报告进行有效解释。该算法是最优的一阶估计器，增益参数1/16在保持合理的收敛速度的同时提供了良好的降噪率[22]。附录A.8中显示了一个示例实现。有关传输前不同数据包持续时间和延迟的影响的讨论，请参见第6.4.4节。
last SR timestamp (LSR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in Section 4) received as part of the most recent RTCP sender report (SR) packet from source SSRC_n. If no SR has been received yet, the field is set to zero.
最后一个SR时间戳（LSR）：32位NTP时间戳中64位的中间32位（如第4节所述），作为来自源SSRC\n的最新RTCP发送方报告（SR）数据包的一部分接收。如果尚未收到SR，则该字段设置为零。
delay since last SR (DLSR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last SR packet from source SSRC_n and sending this reception report block. If no SR packet has been received yet from SSRC_n, the DLSR field is set to zero.
自上次SR以来的延迟（DLSR）：32位从源SSRC接收最后一个SR数据包到发送此接收报告块之间的延迟，以1/65536秒为单位。如果尚未从SSRC\n接收到SR数据包，则DLSR字段设置为零。
Let SSRC_r denote the receiver issuing this receiver report. Source SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this reception report block is received. It calculates the total round-trip time A-LSR using the last SR timestamp (LSR) field, and then subtracting this field to leave the round-trip propagation delay as (A - LSR - DLSR). This
让SSRC_r表示发出此接收方报告的接收方。源SSRC\n可以通过记录接收到该接收报告块的时间A来计算到SSRC\r的往返传播延迟。它使用最后一个SR时间戳（LSR）字段计算总往返时间A-LSR，然后减去该字段，将往返传播延迟保留为（A-LSR-DLSR）。这
is illustrated in Fig. 2. Times are shown in both a hexadecimal representation of the 32-bit fields and the equivalent floating-point decimal representation. Colons indicate a 32-bit field divided into a 16-bit integer part and 16-bit fraction part.
如图2所示。时间以32位字段的十六进制表示形式和等效的浮点十进制表示形式显示。冒号表示分为16位整数部分和16位小数部分的32位字段。
This may be used as an approximate measure of distance to cluster receivers, although some links have very asymmetric delays.
虽然有些链路具有非常不对称的延迟，但这可以用作到集群接收机距离的近似度量。
[10 Nov 1995 11:33:25.125 UTC] [10 Nov 1995 11:33:36.5 UTC]
n SR(n) A=b710:8000 (46864.500 s)
---------------------------------------------------------------->
v ^
ntp_sec =0xb44db705 v ^ dlsr=0x0005:4000 ( 5.250s)
ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
(3024992005.125 s) v ^
r v ^ RR(n)
---------------------------------------------------------------->
|<-DLSR->|
(5.250 s)
[10 Nov 1995 11:33:25.125 UTC] [10 Nov 1995 11:33:36.5 UTC]
n SR(n) A=b710:8000 (46864.500 s)
---------------------------------------------------------------->
v ^
ntp_sec =0xb44db705 v ^ dlsr=0x0005:4000 ( 5.250s)
ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
(3024992005.125 s) v ^
r v ^ RR(n)
---------------------------------------------------------------->
|<-DLSR->|
(5.250 s)
A 0xb710:8000 (46864.500 s)
DLSR -0x0005:4000 ( 5.250 s)
LSR -0xb705:2000 (46853.125 s)
-------------------------------
delay 0x0006:2000 ( 6.125 s)
A 0xb710:8000 (46864.500 s)
DLSR -0x0005:4000 ( 5.250 s)
LSR -0xb705:2000 (46853.125 s)
-------------------------------
delay 0x0006:2000 ( 6.125 s)
Figure 2: Example for round-trip time computation
图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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the receiver report (RR) packet is the same as that of the SR packet except that the packet type field contains the constant 201 and the five words of sender information are omitted (these are the NTP and RTP timestamps and sender's packet and octet counts). The remaining fields have the same meaning as for the SR packet.
接收机报告（RR）分组的格式与SR分组的格式相同，只是分组类型字段包含常数201，并且省略了发送方信息的五个字（它们是NTP和RTP时间戳以及发送方分组和八位字节计数）。其余字段的含义与SR数据包相同。
An empty RR packet (RC = 0) MUST be put at the head of a compound RTCP packet when there is no data transmission or reception to report.
当没有要报告的数据传输或接收时，必须将空RR数据包（RC=0）放在复合RTCP数据包的头部。
A profile SHOULD define profile-specific extensions to the sender report and receiver report if there is additional information that needs to be reported regularly about the sender or receivers. This method SHOULD be used in preference to defining another RTCP packet type because it requires less overhead:
如果需要定期报告有关发送方或接收方的其他信息，则概要文件应定义发送方报告和接收方报告的特定于概要文件的扩展。此方法应优先于定义另一种RTCP数据包类型，因为它需要较少的开销：
o fewer octets in the packet (no RTCP header or SSRC field);
o 数据包中的八位字节更少（没有RTCP报头或SSRC字段）；
o simpler and faster parsing because applications running under that profile would be programmed to always expect the extension fields in the directly accessible location after the reception reports.
o 更简单、更快的解析，因为在该配置文件下运行的应用程序将被编程为在接收报告之后始终希望扩展字段位于直接可访问的位置。
The extension is a fourth section in the sender- or receiver-report packet which comes at the end after the reception report blocks, if any. If additional sender information is required, then for sender reports it would be included first in the extension section, but for receiver reports it would not be present. If information about receivers is to be included, that data SHOULD be structured as an array of blocks parallel to the existing array of reception report blocks; that is, the number of blocks would be indicated by the RC field.
扩展是发送方或接收方报告包中的第四部分，位于接收报告块（如果有）之后的末尾。如果需要额外的发送方信息，则对于发送方报告，它将首先包含在扩展部分中，但对于接收方报告，它将不存在。如果要包括关于接收器的信息，则该数据应被构造为与现有接收报告块阵列平行的块阵列；也就是说，块的数量将由RC字段指示。
It is expected that reception quality feedback will be useful not only for the sender but also for other receivers and third-party monitors. The sender may modify its transmissions based on the feedback; receivers can determine whether problems are local, regional or global; network managers may use profile-independent monitors that receive only the RTCP packets and not the corresponding RTP data packets to evaluate the performance of their networks for multicast distribution.
预计接收质量反馈不仅对发送者有用，而且对其他接收器和第三方监视器也有用。发送方可以基于反馈修改其传输；接收者可以确定问题是局部的、区域性的还是全球性的；网络管理器可以使用仅接收RTCP数据包而不接收相应RTP数据包的与配置文件无关的监控器来评估其多播分发网络的性能。
Cumulative counts are used in both the sender information and receiver report blocks so that differences may be calculated between any two reports to make measurements over both short and long time periods, and to provide resilience against the loss of a report. The difference between the last two reports received can be used to estimate the recent quality of the distribution. The NTP timestamp is included so that rates may be calculated from these differences over the interval between two reports. Since that timestamp is independent of the clock rate for the data encoding, it is possible to implement encoding- and profile-independent quality monitors.
在发送方信息和接收方报告块中使用累积计数，以便计算任意两个报告之间的差异，以便在短时间和长时间内进行测量，并提供针对报告丢失的恢复能力。最近收到的两份报告之间的差异可用于估计最近的分发质量。包括NTP时间戳，以便根据两份报告之间的时间间隔内的这些差异计算费率。由于时间戳与数据编码的时钟频率无关，因此可以实现编码和配置文件无关的质量监视器。
An example calculation is the packet loss rate over the interval between two reception reports. The difference in the cumulative number of packets lost gives the number lost during that interval. The difference in the extended last sequence numbers received gives the number of packets expected during the interval. The ratio of these two is the packet loss fraction over the interval. This ratio should equal the fraction lost field if the two reports are consecutive, but otherwise it may not. The loss rate per second can be obtained by dividing the loss fraction by the difference in NTP timestamps, expressed in seconds. The number of packets received is the number of packets expected minus the number lost. The number of
示例计算是两个接收报告之间间隔内的分组丢失率。累计丢失的数据包数之差即为该间隔内丢失的数据包数。接收到的扩展最后序列号的差值给出了间隔期间预期的数据包数。这两者的比率是间隔内的数据包丢失分数。如果两个报告是连续的，则此比率应等于“丢失分数”字段，否则可能不相等。每秒的丢失率可以通过将丢失分数除以NTP时间戳的差值（以秒为单位）来获得。接收的数据包数是预期的数据包数减去丢失的数据包数。人数
packets expected may also be used to judge the statistical validity of any loss estimates. For example, 1 out of 5 packets lost has a lower significance than 200 out of 1000.
预期的分组也可用于判断任何损失估计的统计有效性。例如，丢失的5个数据包中有1个的重要性低于1000个数据包中的200个。
From the sender information, a third-party monitor can calculate the average payload data rate and the average packet rate over an interval without receiving the data. Taking the ratio of the two gives the average payload size. If it can be assumed that packet loss is independent of packet size, then the number of packets received by a particular receiver times the average payload size (or the corresponding packet size) gives the apparent throughput available to that receiver.
根据发送方信息，第三方监视器可以在不接收数据的情况下计算一段时间间隔内的平均有效负载数据速率和平均分组速率。取两者之比，得到平均有效载荷大小。如果可以假设分组丢失与分组大小无关，则特定接收机接收的分组数量乘以平均有效负载大小（或相应的分组大小）给出该接收机可用的明显吞吐量。
In addition to the cumulative counts which allow long-term packet loss measurements using differences between reports, the fraction lost field provides a short-term measurement from a single report. This becomes more important as the size of a session scales up enough that reception state information might not be kept for all receivers or the interval between reports becomes long enough that only one report might have been received from a particular receiver.
除了允许使用报告之间的差异进行长期数据包丢失测量的累积计数外，丢失分数字段还提供了单个报告的短期测量。当会话的大小扩展到可能无法为所有接收器保留接收状态信息，或者报告之间的间隔变长到可能仅从特定接收器接收到一个报告时，这变得更加重要。
The interarrival jitter field provides a second short-term measure of network congestion. Packet loss tracks persistent congestion while the jitter measure tracks transient congestion. The jitter measure may indicate congestion before it leads to packet loss. The interarrival jitter field is only a snapshot of the jitter at the time of a report and is not intended to be taken quantitatively. Rather, it is intended for comparison across a number of reports from one receiver over time or from multiple receivers, e.g., within a single network, at the same time. To allow comparison across receivers, it is important the the jitter be calculated according to the same formula by all receivers.
到达间隔抖动字段提供了网络拥塞的第二个短期度量。数据包丢失跟踪持续拥塞，而抖动度量跟踪瞬时拥塞。抖动度量可能在导致分组丢失之前指示拥塞。到达间隔抖动字段仅是报告时抖动的快照，不打算定量获取。相反，它是为了在一段时间内对来自一个接收器或来自多个接收器（例如，在单个网络内）的多个报告进行比较。为了允许在接收机之间进行比较，所有接收机必须根据相同的公式计算抖动。
Because the jitter calculation is based on the RTP timestamp which represents the instant when the first data in the packet was sampled, any variation in the delay between that sampling instant and the time the packet is transmitted will affect the resulting jitter that is calculated. Such a variation in delay would occur for audio packets of varying duration. It will also occur for video encodings because the timestamp is the same for all the packets of one frame but those packets are not all transmitted at the same time. The variation in delay until transmission does reduce the accuracy of the jitter calculation as a measure of the behavior of the network by itself, but it is appropriate to include considering that the receiver buffer must accommodate it. When the jitter calculation is used as a comparative measure, the (constant) component due to variation in delay until transmission subtracts out so that a change in the
由于抖动计算基于RTP时间戳，该RTP时间戳表示对分组中的第一个数据进行采样的时刻，因此该采样时刻与分组传输时间之间的延迟的任何变化都将影响所计算的结果抖动。对于不同持续时间的音频分组，将发生延迟的这种变化。对于视频编码也会发生这种情况，因为时间戳对于一帧的所有数据包都是相同的，但是这些数据包不是同时发送的。传输前延迟的变化确实降低了抖动计算的准确性，作为网络自身行为的度量，但考虑到接收器缓冲区必须容纳抖动计算是合适的。当抖动计算用作比较度量时，由于传输延迟的变化而产生的（常数）分量减去，因此
network jitter component can then be observed unless it is relatively small. If the change is small, then it is likely to be inconsequential.
然后可以观察到网络抖动分量，除非它相对较小。如果变化很小，那么很可能是无关紧要的。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| SC | PT=SDES=202 | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_1 |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_2 |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| SC | PT=SDES=202 | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_1 |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_2 |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
The SDES packet is a three-level structure composed of a header and zero or more chunks, each of which is composed of items describing the source identified in that chunk. The items are described individually in subsequent sections.
SDES数据包是一个三级结构，由一个头部和零个或多个数据块组成，每个数据块由描述该数据块中标识的源的项目组成。这些项目将在后续章节中单独描述。
version (V), padding (P), length: As described for the SR packet (see Section 6.4.1).
版本（V）、填充（P）、长度：如SR数据包所述（见第6.4.1节）。
packet type (PT): 8 bits Contains the constant 202 to identify this as an RTCP SDES packet.
数据包类型（PT）：8位包含常数202，用于将其标识为RTCP SDES数据包。
source count (SC): 5 bits The number of SSRC/CSRC chunks contained in this SDES packet. A value of zero is valid but useless.
源计数（SC）：5位此SDES数据包中包含的SSRC/CSC块数。值为零是有效的，但没有用处。
Each chunk consists of an SSRC/CSRC identifier followed by a list of zero or more items, which carry information about the SSRC/CSRC. Each chunk starts on a 32-bit boundary. Each item consists of an 8- bit type field, an 8-bit octet count describing the length of the text (thus, not including this two-octet header), and the text itself. Note that the text can be no longer than 255 octets, but this is consistent with the need to limit RTCP bandwidth consumption.
每个区块由一个SSRC/CSC标识符和一个包含零个或多个项目的列表组成，这些项目包含有关SSRC/CSC的信息。每个块从32位边界开始。每个项由一个8位类型字段、一个描述文本长度的8位八位组计数（因此，不包括这两个八位组标题）和文本本身组成。请注意，文本长度不能超过255个八位字节，但这与限制RTCP带宽消耗的需要一致。
The text is encoded according to the UTF-8 encoding specified in RFC 2279 [5]. US-ASCII is a subset of this encoding and requires no additional encoding. The presence of multi-octet encodings is indicated by setting the most significant bit of a character to a value of one.
文本根据RFC 2279[5]中规定的UTF-8编码进行编码。US-ASCII是该编码的子集，不需要额外编码。通过将字符的最高有效位设置为值1来指示是否存在多个八位编码。
Items are contiguous, i.e., items are not individually padded to a 32-bit boundary. Text is not null terminated because some multi-octet encodings include null octets. The list of items in each chunk MUST be terminated by one or more null octets, the first of which is interpreted as an item type of zero to denote the end of the list. No length octet follows the null item type octet, but additional null octets MUST be included if needed to pad until the next 32-bit boundary. Note that this padding is separate from that indicated by the P bit in the RTCP header. A chunk with zero items (four null octets) is valid but useless.
项目是连续的，即项目不单独填充到32位边界。文本不是以null结尾的，因为某些多八位字节编码包含null八位字节。每个区块中的项目列表必须由一个或多个空八位字节终止，其中第一个八位字节被解释为零的项目类型，以表示列表的结束。空项类型的八位字节后面没有长度八位字节，但如果需要填充到下一个32位边界，则必须包含额外的空八位字节。请注意，此填充与RTCP标头中的P位指示的填充是分开的。具有零项（四个空八位字节）的块是有效的，但没有用处。
End systems send one SDES packet containing their own source identifier (the same as the SSRC in the fixed RTP header). A mixer sends one SDES packet containing a chunk for each contributing source from which it is receiving SDES information, or multiple complete SDES packets in the format above if there are more than 31 such sources (see Section 7).
终端系统发送一个包含其自身源标识符的SDES数据包（与固定RTP报头中的SSRC相同）。混频器发送一个SDES数据包，该数据包包含从中接收SDES信息的每个贡献源的数据块，或者发送多个以上格式的完整SDES数据包（如果有超过31个这样的源）（参见第7节）。
The SDES items currently defined are described in the next sections. Only the CNAME item is mandatory. Some items shown here may be useful only for particular profiles, but the item types are all assigned from one common space to promote shared use and to simplify profile-independent applications. Additional items may be defined in a profile by registering the type numbers with IANA as described in Section 15.
下一节将介绍当前定义的SDES项目。只有CNAME项是必需的。此处显示的某些项目可能仅对特定概要文件有用，但项目类型都是从一个公共空间分配的，以促进共享使用并简化与概要文件无关的应用程序。如第15节所述，可通过向IANA注册型号，在配置文件中定义其他项目。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CNAME=1 | length | user and domain name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CNAME=1 | length | user and domain name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CNAME identifier has the following properties:
CNAME标识符具有以下属性：
o Because the randomly allocated SSRC identifier may change if a conflict is discovered or if a program is restarted, the CNAME item MUST be included to provide the binding from the SSRC identifier to an identifier for the source (sender or receiver) that remains constant.
o 由于如果发现冲突或程序重新启动，随机分配的SSRC标识符可能会更改，因此必须包含CNAME项，以提供从SSRC标识符到源（发送方或接收方）标识符的绑定，该绑定保持不变。
o Like the SSRC identifier, the CNAME identifier SHOULD also be unique among all participants within one RTP session.
o 与SSRC标识符一样，CNAME标识符在一个RTP会话中的所有参与者中也应该是唯一的。
o To provide a binding across multiple media tools used by one participant in a set of related RTP sessions, the CNAME SHOULD be fixed for that participant.
o 为了在一组相关RTP会话中一个参与者使用的多个媒体工具之间提供绑定，应该为该参与者固定CNAME。
o To facilitate third-party monitoring, the CNAME SHOULD be suitable for either a program or a person to locate the source.
o 为了便于第三方监控，CNAME应该适合程序或个人定位源。
Therefore, the CNAME SHOULD be derived algorithmically and not entered manually, when possible. To meet these requirements, the following format SHOULD be used unless a profile specifies an alternate syntax or semantics. The CNAME item SHOULD have the format "user@host", or "host" if a user name is not available as on single-user systems. For both formats, "host" is either the fully qualified domain name of the host from which the real-time data originates, formatted according to the rules specified in RFC 1034 [6], RFC 1035 [7] and Section 2.1 of RFC 1123 [8]; or the standard ASCII representation of the host's numeric address on the interface used for the RTP communication. For example, the standard ASCII representation of an IP Version 4 address is "dotted decimal", also known as dotted quad, and for IP Version 6, addresses are textually represented as groups of hexadecimal digits separated by colons (with variations as detailed in RFC 3513 [23]). Other address types are expected to have ASCII representations that are mutually unique. The fully qualified domain name is more convenient for a human observer and may avoid the need to send a NAME item in addition, but it may be difficult or impossible to obtain reliably in some operating environments. Applications that may be run in such environments SHOULD use the ASCII representation of the address instead.
因此，在可能的情况下，CNAME应该通过算法导出，而不是手动输入。为了满足这些要求，除非概要文件指定了替代语法或语义，否则应使用以下格式。CNAME项的格式应为“user@host，或“主机”，如果用户名在单用户系统上不可用。对于这两种格式，“主机”是实时数据来源主机的完全限定域名，按照RFC 1034[6]、RFC 1035[7]和RFC 1123[8]第2.1节规定的规则进行格式化；或用于RTP通信的接口上主机数字地址的标准ASCII表示形式。例如，IP版本4地址的标准ASCII表示为“点十进制”，也称为点四进制，而对于IP版本6，地址以文本形式表示为以冒号分隔的十六进制数字组（其变化如RFC 3513[23]所述）。其他地址类型应具有相互唯一的ASCII表示。完全限定的域名对于人类观察者来说更方便，并且可以避免另外发送名称项的需要，但是在某些操作环境中可能难以或不可能可靠地获得。可能在此类环境中运行的应用程序应改为使用地址的ASCII表示形式。
Examples are "doe@sleepy.example.com", "doe@192.0.2.89" or "doe@2201:056D::112E:144A:1E24" for a multi-user system. On a system with no user name, examples would be "sleepy.example.com", "192.0.2.89" or "2201:056D::112E:144A:1E24".
例如:doe@sleepy.example.com", "doe@192.0.2.89“或”doe@2201：056D:：112E:144A:1E24“用于多用户系统。在没有用户名的系统上，示例为“sleepy.example.com”、“192.0.2.89”或“2201:056D:：112E:144A:1E24”。
The user name SHOULD be in a form that a program such as "finger" or "talk" could use, i.e., it typically is the login name rather than the personal name. The host name is not necessarily identical to the one in the participant's electronic mail address.
用户名应采用“finger”或“talk”等程序可以使用的形式，即，它通常是登录名而不是个人名。主机名不一定与参与者电子邮件地址中的主机名相同。
This syntax will not provide unique identifiers for each source if an application permits a user to generate multiple sources from one host. Such an application would have to rely on the SSRC to further identify the source, or the profile for that application would have to specify additional syntax for the CNAME identifier.
如果应用程序允许用户从一台主机生成多个源，则此语法不会为每个源提供唯一标识符。这样的应用程序必须依赖SSRC来进一步识别源，或者该应用程序的概要文件必须为CNAME标识符指定额外的语法。
If each application creates its CNAME independently, the resulting CNAMEs may not be identical as would be required to provide a binding across multiple media tools belonging to one participant in a set of related RTP sessions. If cross-media binding is required, it may be necessary for the CNAME of each tool to be externally configured with the same value by a coordination tool.
如果每个应用程序独立创建其CNAME，则生成的CNAME可能与在一组相关RTP会话中为属于一个参与者的多个媒体工具提供绑定所需的CNAME不同。如果需要跨媒体绑定，则可能需要通过协调工具将每个工具的CNAME外部配置为相同的值。
Application writers should be aware that private network address assignments such as the Net-10 assignment proposed in RFC 1918 [24] may create network addresses that are not globally unique. This would lead to non-unique CNAMEs if hosts with private addresses and no direct IP connectivity to the public Internet have their RTP packets forwarded to the public Internet through an RTP-level translator. (See also RFC 1627 [25].) To handle this case, applications MAY provide a means to configure a unique CNAME, but the burden is on the translator to translate CNAMEs from private addresses to public addresses if necessary to keep private addresses from being exposed.
应用程序编写者应注意，专用网络地址分配（如RFC 1918[24]中提出的Net-10分配）可能会创建非全局唯一的网络地址。如果具有专用地址且与公共互联网没有直接IP连接的主机通过RTP级转换器将其RTP数据包转发到公共互联网，则这将导致非唯一CNAMEs。（另请参见RFC 1627[25]）为了处理这种情况，应用程序可以提供一种配置唯一CNAME的方法，但翻译人员的负担是在必要时将CNAME从专用地址翻译为公用地址，以防止专用地址被公开。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME=2 | length | common name of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME=2 | length | common name of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the real name used to describe the source, e.g., "John Doe, Bit Recycler". It may be in any form desired by the user. For applications such as conferencing, this form of name may be the most desirable for display in participant lists, and therefore might be sent most frequently of those items other than CNAME. Profiles MAY establish such priorities. The NAME value is expected to remain constant at least for the duration of a session. It SHOULD NOT be relied upon to be unique among all participants in the session.
这是用于描述来源的真实名称，例如，“John Doe，比特回收商”。它可以是用户想要的任何形式。对于会议等应用程序，这种形式的名称可能最适合显示在参与者列表中，因此可能是除CNAME之外最频繁发送的项目。档案可以确定这些优先事项。名称值至少在会话期间保持不变。它不应被认为是本届会议所有与会者中的独特之处。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EMAIL=3 | length | email address of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EMAIL=3 | length | email address of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The email address is formatted according to RFC 2822 [9], for example, "John.Doe@example.com". The EMAIL value is expected to remain constant for the duration of a session.
电子邮件地址的格式符合RFC 2822[9]，例如，“John。Doe@example.com". 电子邮件值应在会话期间保持不变。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHONE=4 | length | phone number of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHONE=4 | length | phone number of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The phone number SHOULD be formatted with the plus sign replacing the international access code. For example, "+1 908 555 1212" for a number in the United States.
电话号码的格式应为加号，以取代国际接入码。例如，在美国，“+1 908 555 1212”表示一个数字。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC=5 | length | geographic location of site ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC=5 | length | geographic location of site ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Depending on the application, different degrees of detail are appropriate for this item. For conference applications, a string like "Murray Hill, New Jersey" may be sufficient, while, for an active badge system, strings like "Room 2A244, AT&T BL MH" might be appropriate. The degree of detail is left to the implementation and/or user, but format and content MAY be prescribed by a profile. The LOC value is expected to remain constant for the duration of a session, except for mobile hosts.
根据应用情况，此项目适用不同的详细程度。对于会议应用程序，像“新泽西州默里山”这样的字符串可能就足够了，而对于活动徽章系统，像“AT&T BL MH 2A244室”这样的字符串可能就足够了。详细程度由实现和/或用户决定，但格式和内容可能由概要文件规定。LOC值预计在会话期间保持不变，移动主机除外。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOOL=6 | length |name/version of source appl. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOOL=6 | length |name/version of source appl. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A string giving the name and possibly version of the application generating the stream, e.g., "videotool 1.2". This information may be useful for debugging purposes and is similar to the Mailer or Mail-System-Version SMTP headers. The TOOL value is expected to remain constant for the duration of the session.
一个字符串，给出生成流的应用程序的名称和可能的版本，例如“videotool 1.2”。此信息可能有助于调试，并与邮件程序或邮件系统版本SMTP标头类似。预计刀具值在会话期间保持不变。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NOTE=7 | length | note about the source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NOTE=7 | length | note about the source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following semantics are suggested for this item, but these or other semantics MAY be explicitly defined by a profile. The NOTE item is intended for transient messages describing the current state of the source, e.g., "on the phone, can't talk". Or, during a seminar, this item might be used to convey the title of the talk. It should be used only to carry exceptional information and SHOULD NOT be included routinely by all participants because this would slow down the rate at which reception reports and CNAME are sent, thus impairing the performance of the protocol. In particular, it SHOULD NOT be included as an item in a user's configuration file nor automatically generated as in a quote-of-the-day.
建议对此项使用以下语义，但这些语义或其他语义可以由概要文件显式定义。注释项用于描述源当前状态的瞬态消息，例如“在电话上，无法通话”。或者，在研讨会期间，此项目可能用于传达演讲的标题。它应仅用于携带特殊信息，不应被所有参与者例行纳入，因为这会减慢接收报告和CNAME的发送速度，从而影响协议的性能。特别是，它不应作为项目包含在用户的配置文件中，也不应作为当日报价自动生成。
Since the NOTE item may be important to display while it is active, the rate at which other non-CNAME items such as NAME are transmitted might be reduced so that the NOTE item can take that part of the RTCP bandwidth. When the transient message becomes inactive, the NOTE item SHOULD continue to be transmitted a few times at the same repetition rate but with a string of length zero to signal the receivers. However, receivers SHOULD also consider the NOTE item inactive if it is not received for a small multiple of the repetition rate, or perhaps 20-30 RTCP intervals.
由于便笺项在活动时显示可能很重要，因此传输其他非CNAME项（如名称）的速率可能会降低，以便便笺项可以占用RTCP带宽的该部分。当瞬态信息变为非活动状态时，应继续以相同的重复率发送注释项几次，但字符串长度为零，以向接收器发送信号。然而，如果不接收重复频率的一小部分，或者可能20-30个RTCP间隔，接收器也应该考虑音符项不活动。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRIV=8 | length | prefix length |prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | value string ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRIV=8 | length | prefix length |prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | value string ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This item is used to define experimental or application-specific SDES extensions. The item contains a prefix consisting of a length-string pair, followed by the value string filling the remainder of the item and carrying the desired information. The prefix length field is 8 bits long. The prefix string is a name chosen by the person defining the PRIV item to be unique with respect to other PRIV items this application might receive. The application creator might choose to use the application name plus an additional subtype identification if
此项用于定义实验性或特定于应用程序的SDES扩展。该项包含由长度字符串对组成的前缀，后跟填充该项其余部分并携带所需信息的值字符串。前缀长度字段的长度为8位。前缀字符串是定义PRIV项的人员选择的名称，该PRIV项相对于此应用程序可能接收的其他PRIV项是唯一的。如果需要，应用程序创建者可以选择使用应用程序名称和附加的子类型标识
needed. Alternatively, it is RECOMMENDED that others choose a name based on the entity they represent, then coordinate the use of the name within that entity.
需要。或者，建议其他人根据他们所代表的实体选择名称，然后在该实体内协调名称的使用。
Note that the prefix consumes some space within the item's total length of 255 octets, so the prefix should be kept as short as possible. This facility and the constrained RTCP bandwidth SHOULD NOT be overloaded; it is not intended to satisfy all the control communication requirements of all applications.
请注意，前缀在条目的255个八位字节的总长度内会占用一些空间，因此前缀应尽可能短。该设施和受限RTCP带宽不应过载；并非旨在满足所有应用的所有控制通信要求。
SDES PRIV prefixes will not be registered by IANA. If some form of the PRIV item proves to be of general utility, it SHOULD instead be assigned a regular SDES item type registered with IANA so that no prefix is required. This simplifies use and increases transmission efficiency.
IANA不会注册SDES PRIV前缀。如果证明某种形式的PRIV项目具有通用性，则应为其分配一个向IANA注册的常规SDES项目类型，以便不需要前缀。这简化了使用并提高了传输效率。
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| SC | PT=BYE=203 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) | length | reason for leaving ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| SC | PT=BYE=203 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) | length | reason for leaving ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BYE packet indicates that one or more sources are no longer active.
BYE数据包表示一个或多个源不再处于活动状态。
version (V), padding (P), length: As described for the SR packet (see Section 6.4.1).
版本（V）、填充（P）、长度：如SR数据包所述（见第6.4.1节）。
packet type (PT): 8 bits Contains the constant 203 to identify this as an RTCP BYE packet.
数据包类型（PT）：8位包含常数203，用于将其标识为RTCP BYE数据包。
source count (SC): 5 bits The number of SSRC/CSRC identifiers included in this BYE packet. A count value of zero is valid, but useless.
源计数（SC）：5位此BYE数据包中包含的SSRC/CSC标识符的数量。计数值为零是有效的，但没有用处。
The rules for when a BYE packet should be sent are specified in Sections 6.3.7 and 8.2.
第6.3.7节和第8.2节规定了应发送BYE数据包的时间规则。
If a BYE packet is received by a mixer, the mixer SHOULD forward the BYE packet with the SSRC/CSRC identifier(s) unchanged. If a mixer shuts down, it SHOULD send a BYE packet listing all contributing sources it handles, as well as its own SSRC identifier. Optionally, the BYE packet MAY include an 8-bit octet count followed by that many octets of text indicating the reason for leaving, e.g., "camera malfunction" or "RTP loop detected". The string has the same encoding as that described for SDES. If the string fills the packet to the next 32-bit boundary, the string is not null terminated. If not, the BYE packet MUST be padded with null octets to the next 32- bit boundary. This padding is separate from that indicated by the P bit in the RTCP header.
如果混音器接收到BYE数据包，则混音器应在SSRC/CSC标识符不变的情况下转发BYE数据包。如果混音器关闭，它应该发送一个BYE数据包，列出它处理的所有贡献源，以及它自己的SSRC标识符。可选地，BYE分组可包括8位八位组计数，后跟指示离开原因的多个八位组文本，例如，“相机故障”或“检测到RTP循环”。该字符串具有与SDE相同的编码。如果字符串将数据包填充到下一个32位边界，则该字符串不会以null结尾。否则，BYE数据包必须用空八位字节填充到下一个32位边界。此填充与RTCP标头中的P位指示的填充是分开的。
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| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent 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| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The APP packet is intended for experimental use as new applications and new features are developed, without requiring packet type value registration. APP packets with unrecognized names SHOULD be ignored. After testing and if wider use is justified, it is RECOMMENDED that each APP packet be redefined without the subtype and name fields and registered with IANA using an RTCP packet type.
该应用程序包用于开发新应用程序和新功能时的实验性使用，无需包类型值注册。应忽略名称无法识别的应用程序包。测试后，如果有理由更广泛地使用，建议重新定义每个应用程序数据包，不使用子类型和名称字段，并使用RTCP数据包类型向IANA注册。
version (V), padding (P), length: As described for the SR packet (see Section 6.4.1).
版本（V）、填充（P）、长度：如SR数据包所述（见第6.4.1节）。
subtype: 5 bits May be used as a subtype to allow a set of APP packets to be defined under one unique name, or for any application-dependent data.
子类型：5位可用作子类型，以允许在一个唯一名称下定义一组应用程序数据包，或为任何依赖于应用程序的数据定义一组应用程序数据包。
packet type (PT): 8 bits Contains the constant 204 to identify this as an RTCP APP packet.
数据包类型（PT）：8位包含常数204，用于将其标识为RTCP APP数据包。
name: 4 octets A name chosen by the person defining the set of APP packets to be unique with respect to other APP packets this application might receive. The application creator might choose to use the application name, and then coordinate the allocation of subtype values to others who want to define new packet types for the application. Alternatively, it is RECOMMENDED that others choose a name based on the entity they represent, then coordinate the use of the name within that entity. The name is interpreted as a sequence of four ASCII characters, with uppercase and lowercase characters treated as distinct.
名称：4个八位字节定义应用程序数据包集合的人员选择的名称，该集合相对于此应用程序可能接收的其他应用程序数据包是唯一的。应用程序创建者可以选择使用应用程序名称，然后将子类型值分配给希望为应用程序定义新数据包类型的其他人。或者，建议其他人根据他们所代表的实体选择名称，然后在该实体内协调名称的使用。名称被解释为四个ASCII字符的序列，大写和小写字符被视为不同的字符。
application-dependent data: variable length Application-dependent data may or may not appear in an APP packet. It is interpreted by the application and not RTP itself. It MUST be a multiple of 32 bits long.
应用程序相关数据：可变长度的应用程序相关数据可能会出现在应用程序数据包中，也可能不会出现在应用程序数据包中。它由应用程序解释，而不是RTP本身。它必须是32位长的倍数。
In addition to end systems, RTP supports the notion of "translators" and "mixers", which could be considered as "intermediate systems" at the RTP level. Although this support adds some complexity to the protocol, the need for these functions has been clearly established by experiments with multicast audio and video applications in the Internet. Example uses of translators and mixers given in Section 2.3 stem from the presence of firewalls and low bandwidth connections, both of which are likely to remain.
除了终端系统外，RTP还支持“翻译器”和“混音器”的概念，在RTP级别可以将其视为“中间系统”。虽然这种支持增加了协议的复杂性，但通过在互联网上使用多播音频和视频应用程序的实验，已经清楚地确定了对这些功能的需求。第2.3节中给出的翻译器和混频器的示例使用源于防火墙和低带宽连接的存在，这两种情况都可能继续存在。
An RTP translator/mixer connects two or more transport-level "clouds". Typically, each cloud is defined by a common network and transport protocol (e.g., IP/UDP) plus a multicast address and transport level destination port or a pair of unicast addresses and ports. (Network-level protocol translators, such as IP version 4 to IP version 6, may be present within a cloud invisibly to RTP.) One system may serve as a translator or mixer for a number of RTP sessions, but each is considered a logically separate entity.
RTP转换器/混频器连接两个或多个传输级“云”。通常，每个云由一个公共网络和传输协议（如IP/UDP）加上一个多播地址和传输级目标端口或一对单播地址和端口定义。（网络级协议转换器，如IP版本4到IP版本6，可能存在于云中，对RTP来说是不可见的。）一个系统可以充当多个RTP会话的转换器或混合器，但每个系统都被视为逻辑上独立的实体。
In order to avoid creating a loop when a translator or mixer is installed, the following rules MUST be observed:
为了避免在安装转换器或混音器时创建循环，必须遵守以下规则：
o Each of the clouds connected by translators and mixers participating in one RTP session either MUST be distinct from all the others in at least one of these parameters (protocol, address, port), or MUST be isolated at the network level from the others.
o 由参与一个RTP会话的转换器和混频器连接的每个云必须至少在其中一个参数（协议、地址、端口）上与所有其他云不同，或者必须在网络级别与其他云隔离。
o A derivative of the first rule is that there MUST NOT be multiple translators or mixers connected in parallel unless by some arrangement they partition the set of sources to be forwarded.
o 第一条规则的一个衍生规则是，除非通过某种安排将要转发的源集分割开来，否则不能有多个并行连接的转换器或混频器。
Similarly, all RTP end systems that can communicate through one or more RTP translators or mixers share the same SSRC space, that is, the SSRC identifiers MUST be unique among all these end systems. Section 8.2 describes the collision resolution algorithm by which SSRC identifiers are kept unique and loops are detected.
类似地，可以通过一个或多个RTP转换器或混频器进行通信的所有RTP终端系统共享相同的SSRC空间，即SSRC标识符在所有这些终端系统中必须是唯一的。第8.2节描述了冲突解决算法，通过该算法，SSRC标识符保持唯一并检测循环。
There may be many varieties of translators and mixers designed for different purposes and applications. Some examples are to add or remove encryption, change the encoding of the data or the underlying protocols, or replicate between a multicast address and one or more unicast addresses. The distinction between translators and mixers is that a translator passes through the data streams from different sources separately, whereas a mixer combines them to form one new stream:
可能有多种翻译器和混音器，用于不同的目的和应用。一些示例包括添加或删除加密、更改数据或底层协议的编码，或在多播地址和一个或多个单播地址之间进行复制。翻译器和混频器之间的区别在于翻译器分别通过不同来源的数据流，而混频器将它们组合成一个新的流：
Translator: Forwards RTP packets with their SSRC identifier intact; this makes it possible for receivers to identify individual sources even though packets from all the sources pass through the same translator and carry the translator's network source address. Some kinds of translators will pass through the data untouched, but others MAY change the encoding of the data and thus the RTP data payload type and timestamp. If multiple data packets are re-encoded into one, or vice versa, a translator MUST assign new sequence numbers to the outgoing packets. Losses in the incoming packet stream may induce corresponding gaps in the outgoing sequence numbers. Receivers cannot detect the presence of a translator unless they know by some other means what payload type or transport address was used by the original source.
转换器：转发SSRC标识符完整的RTP数据包；这使得接收机能够识别单个源，即使来自所有源的数据包通过同一个转换器并携带转换器的网络源地址。某些类型的转换器将不受影响地传递数据，但其他类型的转换器可能会更改数据的编码，从而更改RTP数据有效负载类型和时间戳。如果将多个数据包重新编码为一个数据包，或者反之亦然，则转换器必须为传出的数据包分配新的序列号。传入分组流中的丢失可能导致传出序列号中的相应间隙。接收器无法检测到转换器的存在，除非他们通过其他方式知道原始源使用的有效负载类型或传输地址。
Mixer: Receives streams of RTP data packets from one or more sources, possibly changes the data format, combines the streams in some manner and then forwards the combined stream. Since the timing among multiple input sources will not generally be synchronized, the mixer will make timing adjustments among the streams and generate its own timing for the combined stream, so it is the synchronization source. Thus, all data packets forwarded by a mixer MUST be marked with the mixer's own SSRC identifier. In order to preserve the identity of the original sources contributing to the mixed packet, the mixer SHOULD insert their SSRC identifiers into the CSRC identifier list following the fixed RTP header of the packet. A mixer that is also itself a contributing source for some packet SHOULD explicitly include its own SSRC identifier in the CSRC list for that packet.
混合器：从一个或多个源接收RTP数据包流，可能更改数据格式，以某种方式组合流，然后转发组合流。由于多个输入源之间的定时通常不会同步，因此混频器将在流之间进行定时调整，并为组合流生成其自己的定时，因此它是同步源。因此，混频器转发的所有数据包必须用混频器自己的SSRC标识符进行标记。为了保留对混合数据包有贡献的原始源的身份，混合器应在数据包的固定RTP报头之后将其SSRC标识符插入CSC标识符列表。混频器本身也是某个数据包的贡献源，它应该在该数据包的CSC列表中明确包含自己的SSRC标识符。
For some applications, it MAY be acceptable for a mixer not to identify sources in the CSRC list. However, this introduces the danger that loops involving those sources could not be detected.
对于某些应用，混合器不识别CSC列表中的源是可以接受的。然而，这带来了无法检测到涉及这些源的回路的危险。
The advantage of a mixer over a translator for applications like audio is that the output bandwidth is limited to that of one source even when multiple sources are active on the input side. This may be important for low-bandwidth links. The disadvantage is that receivers on the output side don't have any control over which sources are passed through or muted, unless some mechanism is implemented for remote control of the mixer. The regeneration of synchronization information by mixers also means that receivers can't do inter-media synchronization of the original streams. A multi-media mixer could do it.
对于音频等应用，混频器优于转换器的优点是，即使在输入端有多个源处于活动状态时，输出带宽也仅限于一个源的带宽。这对于低带宽链路可能很重要。缺点是，输出端的接收器无法控制哪些信号源通过或静音，除非实现了某种机制来远程控制混频器。混频器对同步信息的再生还意味着接收机不能对原始流进行媒体间同步。多媒体混合器可以做到这一点。
[E1] [E6]
| |
E1:17 | E6:15 |
| | E6:15
V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17)
(M1)-------------><T1>-----------------><T2>-------------->[E7]
^ ^ E4:47 ^ E4:47
E2:1 | E4:47 | | M3:89 (64,45)
| | |
[E2] [E4] M3:89 (64,45) |
| legend:
[E3] --------->(M2)----------->(M3)------------| [End system]
E3:64 M2:12 (64) ^ (Mixer)
| E5:45 <Translator>
|
[E5] source: SSRC (CSRCs)
------------------->
[E1] [E6]
| |
E1:17 | E6:15 |
| | E6:15
V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17)
(M1)-------------><T1>-----------------><T2>-------------->[E7]
^ ^ E4:47 ^ E4:47
E2:1 | E4:47 | | M3:89 (64,45)
| | |
[E2] [E4] M3:89 (64,45) |
| legend:
[E3] --------->(M2)----------->(M3)------------| [End system]
E3:64 M2:12 (64) ^ (Mixer)
| E5:45 <Translator>
|
[E5] source: SSRC (CSRCs)
------------------->
Figure 3: Sample RTP network with end systems, mixers and translators
图3：带有终端系统、混频器和转换器的RTP网络示例
A collection of mixers and translators is shown in Fig. 3 to illustrate their effect on SSRC and CSRC identifiers. In the figure, end systems are shown as rectangles (named E), translators as triangles (named T) and mixers as ovals (named M). The notation "M1: 48(1,17)" designates a packet originating a mixer M1, identified by M1's (random) SSRC value of 48 and two CSRC identifiers, 1 and 17, copied from the SSRC identifiers of packets from E1 and E2.
图3显示了混频器和转换器的集合，以说明它们对SSRC和CSC标识符的影响。在图中，末端系统显示为矩形（命名为E），转换器显示为三角形（命名为T），混合器显示为椭圆形（命名为M）。符号“M1:48（1,17）”指定源自混合器M1的分组，由M1的（随机）SSRC值48和两个csc标识符1和17标识，从E1和E2的分组的SSRC标识符复制而来。
In addition to forwarding data packets, perhaps modified, translators and mixers MUST also process RTCP packets. In many cases, they will take apart the compound RTCP packets received from end systems to
除了转发可能已修改的数据包外，转换器和混频器还必须处理RTCP数据包。在许多情况下，它们会将从终端系统接收到的复合RTCP数据包拆分为
aggregate SDES information and to modify the SR or RR packets. Retransmission of this information may be triggered by the packet arrival or by the RTCP interval timer of the translator or mixer itself.
聚合SDES信息并修改SR或RR数据包。该信息的重新传输可由数据包到达或由转换器或混频器本身的RTCP间隔计时器触发。
A translator that does not modify the data packets, for example one that just replicates between a multicast address and a unicast address, MAY simply forward RTCP packets unmodified as well. A translator that transforms the payload in some way MUST make corresponding transformations in the SR and RR information so that it still reflects the characteristics of the data and the reception quality. These translators MUST NOT simply forward RTCP packets. In general, a translator SHOULD NOT aggregate SR and RR packets from different sources into one packet since that would reduce the accuracy of the propagation delay measurements based on the LSR and DLSR fields.
不修改数据包的转换器，例如仅在多播地址和单播地址之间复制的转换器，也可以简单地转发未修改的RTCP包。以某种方式变换有效载荷的转换器必须在SR和RR信息中进行相应的变换，以便它仍然反映数据的特征和接收质量。这些转换器不能简单地转发RTCP数据包。通常，转换器不应将来自不同来源的SR和RR分组聚合成一个分组，因为这将降低基于LSR和DLSR字段的传播延迟测量的准确性。
SR sender information: A translator does not generate its own sender information, but forwards the SR packets received from one cloud to the others. The SSRC is left intact but the sender information MUST be modified if required by the translation. If a translator changes the data encoding, it MUST change the "sender's byte count" field. If it also combines several data packets into one output packet, it MUST change the "sender's packet count" field. If it changes the timestamp frequency, it MUST change the "RTP timestamp" field in the SR packet.
SR发送方信息：转换器不生成自己的发送方信息，而是将从一个云接收到的SR数据包转发给其他云。SSRC保持不变，但如果翻译要求，则必须修改发件人信息。如果转换器更改了数据编码，则必须更改“发送方字节计数”字段。如果它还将多个数据包组合成一个输出包，则必须更改“发送方的数据包计数”字段。如果更改时间戳频率，则必须更改SR数据包中的“RTP timestamp”字段。
SR/RR reception report blocks: A translator forwards reception reports received from one cloud to the others. Note that these flow in the direction opposite to the data. The SSRC is left intact. If a translator combines several data packets into one output packet, and therefore changes the sequence numbers, it MUST make the inverse manipulation for the packet loss fields and the "extended last sequence number" field. This may be complex. In the extreme case, there may be no meaningful way to translate the reception reports, so the translator MAY pass on no reception report at all or a synthetic report based on its own reception. The general rule is to do what makes sense for a particular translation.
SR/RR接收报告块：转换器将从一个云接收到的接收报告转发给其他云。请注意，这些流的方向与数据的方向相反。SSRC完好无损。如果转换器将多个数据包组合成一个输出包，并因此更改序列号，则必须对数据包丢失字段和“扩展的最后序列号”字段进行反向操作。这可能很复杂。在极端情况下，可能没有翻译接收报告的有意义的方法，因此翻译人员可能根本不传递接收报告或基于自身接收的合成报告。一般规则是做对特定翻译有意义的事情。
A translator does not require an SSRC identifier of its own, but MAY choose to allocate one for the purpose of sending reports about what it has received. These would be sent to all the connected clouds, each corresponding to the translation of the data stream as sent to that cloud, since reception reports are normally multicast to all participants.
翻译人员不需要自己的SSRC标识符，但可以选择分配一个，以便发送有关其收到内容的报告。这些将被发送到所有连接的云，每个云对应于发送到该云的数据流的转换，因为接收报告通常多播到所有参与者。
SDES: Translators typically forward without change the SDES information they receive from one cloud to the others, but MAY, for example, decide to filter non-CNAME SDES information if bandwidth is limited. The CNAMEs MUST be forwarded to allow SSRC identifier collision detection to work. A translator that generates its own RR packets MUST send SDES CNAME information about itself to the same clouds that it sends those RR packets.
SDES：翻译人员通常在不更改从一个云接收到的SDES信息的情况下将其转发到其他云，但例如，如果带宽有限，翻译人员可能会决定过滤非CNAME SDES信息。必须转发CNAMEs以允许SSRC标识符冲突检测工作。生成其自己的RR数据包的转换器必须将其自身的SDES CNAME信息发送到其发送这些RR数据包的相同云中。
BYE: Translators forward BYE packets unchanged. A translator that is about to cease forwarding packets SHOULD send a BYE packet to each connected cloud containing all the SSRC identifiers that were previously being forwarded to that cloud, including the translator's own SSRC identifier if it sent reports of its own.
BYE：翻译人员转发的BYE数据包不变。即将停止转发数据包的翻译器应向每个连接的云发送BYE数据包，其中包含之前转发到该云的所有SSRC标识符，包括翻译器自己的SSRC标识符（如果翻译器发送了自己的报告）。
APP: Translators forward APP packets unchanged.
应用程序：翻译人员转发应用程序包，未更改。
Since a mixer generates a new data stream of its own, it does not pass through SR or RR packets at all and instead generates new information for both sides.
由于混频器生成自己的新数据流，因此它根本不通过SR或RR数据包，而是为双方生成新信息。
SR sender information: A mixer does not pass through sender information from the sources it mixes because the characteristics of the source streams are lost in the mix. As a synchronization source, the mixer SHOULD generate its own SR packets with sender information about the mixed data stream and send them in the same direction as the mixed stream.
SR发送方信息：由于源流的特征在混音中丢失，混音器不会通过来自其混音源的发送方信息。作为同步源，混频器应生成其自己的SR包，其中包含关于混合数据流的发送者信息，并以与混合流相同的方向发送它们。
SR/RR reception report blocks: A mixer generates its own reception reports for sources in each cloud and sends them out only to the same cloud. It MUST NOT send these reception reports to the other clouds and MUST NOT forward reception reports from one cloud to the others because the sources would not be SSRCs there (only CSRCs).
SR/RR接收报告块：混合器为每个云中的源生成自己的接收报告，并仅将它们发送到同一个云中。它不能将这些接收报告发送到其他云，也不能将接收报告从一个云转发到其他云，因为那里的源不是SSRC（只有CSRC）。
SDES: Mixers typically forward without change the SDES information they receive from one cloud to the others, but MAY, for example, decide to filter non-CNAME SDES information if bandwidth is limited. The CNAMEs MUST be forwarded to allow SSRC identifier collision detection to work. (An identifier in a CSRC list generated by a mixer might collide with an SSRC identifier generated by an end system.) A mixer MUST send SDES CNAME information about itself to the same clouds that it sends SR or RR packets.
SDE：混频器通常在不改变从一个云中接收到的SDE信息的情况下转发到其他云中，但例如，如果带宽有限，可能会决定过滤非CNAME SDE信息。必须转发CNAMEs以允许SSRC标识符冲突检测工作。（混合器生成的CSC列表中的标识符可能与终端系统生成的SSRC标识符冲突。）混合器必须向发送SR或RR数据包的相同云中发送关于自身的SDES CNAME信息。
Since mixers do not forward SR or RR packets, they will typically be extracting SDES packets from a compound RTCP packet. To minimize overhead, chunks from the SDES packets MAY be aggregated into a single SDES packet which is then stacked on an SR or RR packet originating from the mixer. A mixer which aggregates SDES packets will use more RTCP bandwidth than an individual source because the compound packets will be longer, but that is appropriate since the mixer represents multiple sources. Similarly, a mixer which passes through SDES packets as they are received will be transmitting RTCP packets at higher than the single source rate, but again that is correct since the packets come from multiple sources. The RTCP packet rate may be different on each side of the mixer.
由于混频器不转发SR或RR数据包，它们通常从复合RTCP数据包中提取SDES数据包。为了最小化开销，来自SDES分组的块可以聚合成单个SDES分组，该SDES分组随后堆叠在源自混合器的SR或RR分组上。聚合SDES数据包的混合器将使用比单个源更多的RTCP带宽，因为复合数据包将更长，但这是适当的，因为混合器代表多个源。类似地，在接收SDES数据包时通过SDES数据包的混频器将以高于单源速率的速率传输RTCP数据包，但这同样是正确的，因为数据包来自多个源。在混频器的每一侧，RTCP数据包速率可能不同。
A mixer that does not insert CSRC identifiers MAY also refrain from forwarding SDES CNAMEs. In this case, the SSRC identifier spaces in the two clouds are independent. As mentioned earlier, this mode of operation creates a danger that loops can't be detected.
未插入CSC标识符的混合器也可以避免转发SDE CNAMEs。在这种情况下，两个云中的SSRC标识符空间是独立的。如前所述，这种操作模式会产生无法检测到回路的危险。
BYE: Mixers MUST forward BYE packets. A mixer that is about to cease forwarding packets SHOULD send a BYE packet to each connected cloud containing all the SSRC identifiers that were previously being forwarded to that cloud, including the mixer's own SSRC identifier if it sent reports of its own.
BYE：混音器必须转发BYE数据包。即将停止转发数据包的混合器应向每个连接的云发送一个BYE数据包，其中包含之前转发到该云的所有SSRC标识符，如果混合器发送了自己的报告，则包括混合器自己的SSRC标识符。
APP: The treatment of APP packets by mixers is application-specific.
应用程序：混合器对应用程序包的处理是特定于应用程序的。
An RTP session may involve a collection of mixers and translators as shown in Fig. 3. If two mixers are cascaded, such as M2 and M3 in the figure, packets received by a mixer may already have been mixed and may include a CSRC list with multiple identifiers. The second mixer SHOULD build the CSRC list for the outgoing packet using the CSRC identifiers from already-mixed input packets and the SSRC identifiers from unmixed input packets. This is shown in the output arc from mixer M3 labeled M3:89(64,45) in the figure. As in the case of mixers that are not cascaded, if the resulting CSRC list has more than 15 identifiers, the remainder cannot be included.
RTP会话可涉及如图3所示的混频器和转换器的集合。如果两个混频器级联，例如图中的M2和M3，则混频器接收的分组可能已经混合，并且可能包括具有多个标识符的csc列表。第二个混合器应使用来自已混合输入数据包的CSC标识符和来自未混合输入数据包的SSRC标识符为传出数据包构建CSC列表。图中标记为M3:89（64,45）的混合器M3的输出弧显示了这一点。与未级联的混合器一样，如果生成的CSC列表具有超过15个标识符，则不能包括其余标识符。
The SSRC identifier carried in the RTP header and in various fields of RTCP packets is a random 32-bit number that is required to be globally unique within an RTP session. It is crucial that the number be chosen with care in order that participants on the same network or starting at the same time are not likely to choose the same number.
RTP报头和RTCP数据包的各个字段中携带的SSRC标识符是一个随机32位数字，要求在RTP会话中全局唯一。为避免同一网络上的参与者或同时开始的参与者选择相同的号码，谨慎选择号码至关重要。
It is not sufficient to use the local network address (such as an IPv4 address) for the identifier because the address may not be unique. Since RTP translators and mixers enable interoperation among multiple networks with different address spaces, the allocation patterns for addresses within two spaces might result in a much higher rate of collision than would occur with random allocation.
仅使用本地网络地址（例如IPv4地址）作为标识符是不够的，因为该地址可能不是唯一的。由于RTP转换器和混频器支持具有不同地址空间的多个网络之间的互操作，因此两个空间内的地址分配模式可能会导致比随机分配更高的冲突率。
Multiple sources running on one host would also conflict.
在一台主机上运行的多个源也会发生冲突。
It is also not sufficient to obtain an SSRC identifier simply by calling random() without carefully initializing the state. An example of how to generate a random identifier is presented in Appendix A.6.
仅通过调用random（）而不仔细初始化状态来获取SSRC标识符也是不够的。附录a.6中给出了如何生成随机标识符的示例。
Since the identifiers are chosen randomly, it is possible that two or more sources will choose the same number. Collision occurs with the highest probability when all sources are started simultaneously, for example when triggered automatically by some session management event. If N is the number of sources and L the length of the identifier (here, 32 bits), the probability that two sources independently pick the same value can be approximated for large N [26] as 1 - exp(-N**2 / 2**(L+1)). For N=1000, the probability is roughly 10**-4.
由于标识符是随机选择的，因此两个或多个源可能会选择相同的数字。当所有源同时启动时（例如，当某些会话管理事件自动触发时），冲突发生的概率最高。如果N是源的数量，L是标识符的长度（此处为32位），则两个源独立选取相同值的概率可近似为1-exp（-N**2/2**（L+1））。对于N=1000，概率大约为10**-4。
The typical collision probability is much lower than the worst-case above. When one new source joins an RTP session in which all the other sources already have unique identifiers, the probability of collision is just the fraction of numbers used out of the space. Again, if N is the number of sources and L the length of the identifier, the probability of collision is N / 2**L. For N=1000, the probability is roughly 2*10**-7.
典型碰撞概率远低于上述最坏情况。当一个新的源加入一个RTP会话，其中所有其他源都已经具有唯一标识符时，冲突的概率只是空间中使用的数字的分数。同样，如果N是源的数量，L是标识符的长度，则冲突概率为N/2**L。对于N=1000，概率大约为2*10**-7。
The probability of collision is further reduced by the opportunity for a new source to receive packets from other participants before sending its first packet (either data or control). If the new source keeps track of the other participants (by SSRC identifier), then
新的源在发送其第一个数据包（数据或控制）之前接收来自其他参与者的数据包的机会进一步降低了冲突的概率。如果新来源跟踪其他参与者（通过SSRC标识符），则
before transmitting its first packet the new source can verify that its identifier does not conflict with any that have been received, or else choose again.
在发送其第一个数据包之前，新源可以验证其标识符是否与已接收的任何数据包不冲突，或者再次选择。
Although the probability of SSRC identifier collision is low, all RTP implementations MUST be prepared to detect collisions and take the appropriate actions to resolve them. If a source discovers at any time that another source is using the same SSRC identifier as its own, it MUST send an RTCP BYE packet for the old identifier and choose another random one. (As explained below, this step is taken only once in case of a loop.) If a receiver discovers that two other sources are colliding, it MAY keep the packets from one and discard the packets from the other when this can be detected by different source transport addresses or CNAMEs. The two sources are expected to resolve the collision so that the situation doesn't last.
尽管SSRC标识符冲突的概率很低，但所有RTP实现都必须做好检测冲突的准备，并采取适当的措施来解决冲突。如果一个源在任何时候发现另一个源使用与自己相同的SSRC标识符，它必须为旧标识符发送RTCP BYE数据包，并选择另一个随机数据包。（如下所述，在循环的情况下，此步骤仅执行一次。）如果接收器发现两个其他源发生冲突，则当可由不同的源传输地址或CNAME检测到时，它可以保留来自一个源的数据包并丢弃来自另一个源的数据包。预计这两个来源将解决冲突，使情况不会持续下去。
Because the random SSRC identifiers are kept globally unique for each RTP session, they can also be used to detect loops that may be introduced by mixers or translators. A loop causes duplication of data and control information, either unmodified or possibly mixed, as in the following examples:
由于随机SSRC标识符对于每个RTP会话保持全局唯一性，因此它们还可用于检测混频器或转换器可能引入的循环。循环会导致数据和控制信息的重复（未修改或可能混合），如以下示例所示：
o A translator may incorrectly forward a packet to the same multicast group from which it has received the packet, either directly or through a chain of translators. In that case, the same packet appears several times, originating from different network sources.
o 翻译器可能会直接或通过翻译器链错误地将数据包转发到从中接收数据包的同一多播组。在这种情况下，来自不同网络源的同一数据包多次出现。
o Two translators incorrectly set up in parallel, i.e., with the same multicast groups on both sides, would both forward packets from one multicast group to the other. Unidirectional translators would produce two copies; bidirectional translators would form a loop.
o 两个并行设置错误的翻译器（即，两侧具有相同的多播组）都会将数据包从一个多播组转发到另一个多播组。单向翻译将产生两份副本；双向翻译器将形成一个循环。
o A mixer can close a loop by sending to the same transport destination upon which it receives packets, either directly or through another mixer or translator. In this case a source might show up both as an SSRC on a data packet and a CSRC in a mixed data packet.
o 混频器可以通过直接或通过另一个混频器或转换器发送到接收数据包的同一传输目的地来关闭循环。在这种情况下，源可能在数据包上显示为SSRC，在混合数据包中显示为CSC。
A source may discover that its own packets are being looped, or that packets from another source are being looped (a third-party loop). Both loops and collisions in the random selection of a source identifier result in packets arriving with the same SSRC identifier but a different source transport address, which may be that of the end system originating the packet or an intermediate system.
源可能会发现自己的数据包正在循环，或者来自另一个源的数据包正在循环（第三方循环）。源标识符随机选择中的循环和冲突都会导致到达的数据包具有相同的SSRC标识符，但具有不同的源传输地址，这可能是发起数据包的终端系统或中间系统的传输地址。
Therefore, if a source changes its source transport address, it MAY also choose a new SSRC identifier to avoid being interpreted as a looped source. (This is not MUST because in some applications of RTP sources may be expected to change addresses during a session.) Note that if a translator restarts and consequently changes the source transport address (e.g., changes the UDP source port number) on which it forwards packets, then all those packets will appear to receivers to be looped because the SSRC identifiers are applied by the original source and will not change. This problem can be avoided by keeping the source transport address fixed across restarts, but in any case will be resolved after a timeout at the receivers.
因此，如果源更改其源传输地址，它还可以选择新的SSRC标识符，以避免被解释为循环源。（这不是必须的，因为在某些RTP应用程序中，可能期望源在会话期间更改地址。）请注意，如果转换器重新启动并因此更改其转发数据包的源传输地址（例如，更改UDP源端口号），然后，所有这些数据包在接收器看来都是循环的，因为SSRC标识符是由原始源应用的，不会改变。通过在重启期间保持源传输地址固定，可以避免此问题，但在任何情况下，都将在接收器超时后解决。
Loops or collisions occurring on the far side of a translator or mixer cannot be detected using the source transport address if all copies of the packets go through the translator or mixer, however, collisions may still be detected when chunks from two RTCP SDES packets contain the same SSRC identifier but different CNAMEs.
如果数据包的所有副本都经过转换器或混频器，则无法使用源传输地址检测转换器或混频器远端发生的循环或冲突，但是，当来自两个RTCP SDES数据包的数据块包含相同的SSRC标识符但不同的CNAME时，仍可能检测到冲突。
To detect and resolve these conflicts, an RTP implementation MUST include an algorithm similar to the one described below, though the implementation MAY choose a different policy for which packets from colliding third-party sources are kept. The algorithm described below ignores packets from a new source or loop that collide with an established source. It resolves collisions with the participant's own SSRC identifier by sending an RTCP BYE for the old identifier and choosing a new one. However, when the collision was induced by a loop of the participant's own packets, the algorithm will choose a new identifier only once and thereafter ignore packets from the looping source transport address. This is required to avoid a flood of BYE packets.
为了检测和解决这些冲突，RTP实现必须包括与下面描述的算法类似的算法，尽管该实现可以选择不同的策略来保存来自冲突第三方源的数据包。下面描述的算法忽略来自新源或循环的与已建立源冲突的数据包。它通过为旧标识符发送RTCP BYE并选择新标识符来解决与参与者自己的SSRC标识符的冲突。然而，当冲突是由参与者自己的数据包的循环引起时，算法将只选择一次新标识符，然后忽略来自循环源传输地址的数据包。这是避免BYE数据包泛滥所必需的。
This algorithm requires keeping a table indexed by the source identifier and containing the source transport addresses from the first RTP packet and first RTCP packet received with that identifier, along with other state for that source. Two source transport addresses are required since, for example, the UDP source port numbers may be different on RTP and RTCP packets. However, it may be assumed that the network address is the same in both source transport addresses.
该算法需要保持一个由源标识符索引的表，并包含来自第一个RTP数据包和使用该标识符接收的第一个RTCP数据包的源传输地址，以及该源的其他状态。需要两个源传输地址，因为，例如，RTP和RTCP数据包上的UDP源端口号可能不同。然而，可以假设网络地址在两个源传输地址中相同。
Each SSRC or CSRC identifier received in an RTP or RTCP packet is looked up in the source identifier table in order to process that data or control information. The source transport address from the packet is compared to the corresponding source transport address in the table to detect a loop or collision if they don't match. For control packets, each element with its own SSRC identifier, for example an SDES chunk, requires a separate lookup. (The SSRC identifier in a reception report block is an exception because it
在源标识符表中查找RTP或RTCP数据包中接收的每个SSRC或CSC标识符，以便处理该数据或控制信息。数据包中的源传输地址与表中相应的源传输地址进行比较，以检测循环或冲突（如果它们不匹配）。对于控制数据包，每个具有自己的SSRC标识符的元素（例如SDES块）都需要单独的查找。（接收报告块中的SSRC标识符是一个例外，因为它
identifies a source heard by the reporter, and that SSRC identifier is unrelated to the source transport address of the RTCP packet sent by the reporter.) If the SSRC or CSRC is not found, a new entry is created. These table entries are removed when an RTCP BYE packet is received with the corresponding SSRC identifier and validated by a matching source transport address, or after no packets have arrived for a relatively long time (see Section 6.2.1).
标识报告者听到的源，且SSRC标识符与报告者发送的RTCP数据包的源传输地址无关。）如果未找到SSRC或CSC，则创建新条目。当接收到带有相应SSRC标识符的RTCP BYE数据包并通过匹配的源传输地址进行验证时，或在较长时间内没有数据包到达后，删除这些表项（见第6.2.1节）。
Note that if two sources on the same host are transmitting with the same source identifier at the time a receiver begins operation, it would be possible that the first RTP packet received came from one of the sources while the first RTCP packet received came from the other. This would cause the wrong RTCP information to be associated with the RTP data, but this situation should be sufficiently rare and harmless that it may be disregarded.
请注意，如果在接收器开始操作时，同一主机上的两个源使用相同的源标识符进行传输，则可能接收到的第一个RTP数据包来自其中一个源，而接收到的第一个RTCP数据包来自另一个源。这将导致错误的RTCP信息与RTP数据相关联，但这种情况应该非常罕见且无害，可以忽略。
In order to track loops of the participant's own data packets, the implementation MUST also keep a separate list of source transport addresses (not identifiers) that have been found to be conflicting. As in the source identifier table, two source transport addresses MUST be kept to separately track conflicting RTP and RTCP packets. Note that the conflicting address list should be short, usually empty. Each element in this list stores the source addresses plus the time when the most recent conflicting packet was received. An element MAY be removed from the list when no conflicting packet has arrived from that source for a time on the order of 10 RTCP report intervals (see Section 6.2).
为了跟踪参与者自己的数据包的循环，实现还必须保留一个单独的源传输地址列表（而不是标识符），这些地址被发现存在冲突。与源标识符表中一样，必须保留两个源传输地址，以分别跟踪冲突的RTP和RTCP数据包。请注意，冲突的地址列表应该很短，通常为空。此列表中的每个元素存储源地址加上接收到最新冲突数据包的时间。当某个元素在10个RTCP报告间隔的时间内没有来自该源的冲突数据包到达时，可以从列表中删除该元素（见第6.2节）。
For the algorithm as shown, it is assumed that the participant's own source identifier and state are included in the source identifier table. The algorithm could be restructured to first make a separate comparison against the participant's own source identifier.
对于如图所示的算法，假设参与者自己的源标识符和状态包含在源标识符表中。可以重新构造算法，首先与参与者自己的源标识符进行单独比较。
if (SSRC or CSRC identifier is not found in the source
identifier table) {
create a new entry storing the data or control source
transport address, the SSRC or CSRC and other state;
}
if (SSRC or CSRC identifier is not found in the source
identifier table) {
create a new entry storing the data or control source
transport address, the SSRC or CSRC and other state;
}
/* Identifier is found in the table */
/* Identifier is found in the table */
else if (table entry was created on receipt of a control packet
and this is the first data packet or vice versa) {
store the source transport address from this packet;
}
else if (source transport address from the packet does not match
the one saved in the table entry for this identifier) {
else if (table entry was created on receipt of a control packet
and this is the first data packet or vice versa) {
store the source transport address from this packet;
}
else if (source transport address from the packet does not match
the one saved in the table entry for this identifier) {
/* An identifier collision or a loop is indicated */
/* An identifier collision or a loop is indicated */
if (source identifier is not the participant's own) {
/* OPTIONAL error counter step */
if (source identifier is from an RTCP SDES chunk
containing a CNAME item that differs from the CNAME
in the table entry) {
count a third-party collision;
} else {
count a third-party loop;
}
abort processing of data packet or control element;
/* MAY choose a different policy to keep new source */
}
if (source identifier is not the participant's own) {
/* OPTIONAL error counter step */
if (source identifier is from an RTCP SDES chunk
containing a CNAME item that differs from the CNAME
in the table entry) {
count a third-party collision;
} else {
count a third-party loop;
}
abort processing of data packet or control element;
/* MAY choose a different policy to keep new source */
}
/* A collision or loop of the participant's own packets */
/* A collision or loop of the participant's own packets */
else if (source transport address is found in the list of
conflicting data or control source transport
addresses) {
/* OPTIONAL error counter step */
if (source identifier is not from an RTCP SDES chunk
containing a CNAME item or CNAME is the
participant's own) {
count occurrence of own traffic looped;
}
mark current time in conflicting address list entry;
abort processing of data packet or control element;
}
else if (source transport address is found in the list of
conflicting data or control source transport
addresses) {
/* OPTIONAL error counter step */
if (source identifier is not from an RTCP SDES chunk
containing a CNAME item or CNAME is the
participant's own) {
count occurrence of own traffic looped;
}
mark current time in conflicting address list entry;
abort processing of data packet or control element;
}
/* New collision, change SSRC identifier */
/* New collision, change SSRC identifier */
else {
log occurrence of a collision;
create a new entry in the conflicting data or control
source transport address list and mark current time;
send an RTCP BYE packet with the old SSRC identifier;
choose a new SSRC identifier;
create a new entry in the source identifier table with
the old SSRC plus the source transport address from
the data or control packet being processed;
}
}
else {
log occurrence of a collision;
create a new entry in the conflicting data or control
source transport address list and mark current time;
send an RTCP BYE packet with the old SSRC identifier;
choose a new SSRC identifier;
create a new entry in the source identifier table with
the old SSRC plus the source transport address from
the data or control packet being processed;
}
}
In this algorithm, packets from a newly conflicting source address will be ignored and packets from the original source address will be kept. If no packets arrive from the original source for an extended period, the table entry will be timed out and the new source will be
在该算法中，来自新冲突源地址的数据包将被忽略，而来自原始源地址的数据包将被保留。如果在一段较长的时间内没有来自原始源的数据包到达，表条目将超时，新源将被删除
able to take over. This might occur if the original source detects the collision and moves to a new source identifier, but in the usual case an RTCP BYE packet will be received from the original source to delete the state without having to wait for a timeout.
能够接管。如果原始源检测到冲突并移动到新的源标识符，则可能发生这种情况，但在通常情况下，将从原始源接收RTCP BYE数据包以删除状态，而无需等待超时。
If the original source address was received through a mixer (i.e., learned as a CSRC) and later the same source is received directly, the receiver may be well advised to switch to the new source address unless other sources in the mix would be lost. Furthermore, for applications such as telephony in which some sources such as mobile entities may change addresses during the course of an RTP session, the RTP implementation SHOULD modify the collision detection algorithm to accept packets from the new source transport address. To guard against flip-flopping between addresses if a genuine collision does occur, the algorithm SHOULD include some means to detect this case and avoid switching.
如果原始源地址是通过混音器接收的（即，学习为CSC），并且随后直接接收到相同的源，则最好建议接收器切换到新的源地址，除非混音中的其他源将丢失。此外，对于诸如电话之类的应用，其中诸如移动实体之类的一些源可以在RTP会话过程中改变地址，RTP实现应当修改冲突检测算法以接受来自新源传输地址的分组。为了防止在发生真正的冲突时地址之间发生翻转，算法应该包括一些方法来检测这种情况并避免切换。
When a new SSRC identifier is chosen due to a collision, the candidate identifier SHOULD first be looked up in the source identifier table to see if it was already in use by some other source. If so, another candidate MUST be generated and the process repeated.
由于冲突而选择新的SSRC标识符时，应首先在源标识符表中查找候选标识符，以查看它是否已被其他源使用。如果是这样，则必须生成另一个候选对象并重复该过程。
A loop of data packets to a multicast destination can cause severe network flooding. All mixers and translators MUST implement a loop detection algorithm like the one here so that they can break loops. This should limit the excess traffic to no more than one duplicate copy of the original traffic, which may allow the session to continue so that the cause of the loop can be found and fixed. However, in extreme cases where a mixer or translator does not properly break the loop and high traffic levels result, it may be necessary for end systems to cease transmitting data or control packets entirely. This decision may depend upon the application. An error condition SHOULD be indicated as appropriate. Transmission MAY be attempted again periodically after a long, random time (on the order of minutes).
将数据包循环到多播目的地可能会导致严重的网络洪泛。所有混音器和翻译器都必须实现一个类似于这里的循环检测算法，以便它们能够打破循环。这应该将多余的通信量限制为不超过原始通信量的一个副本，这可能允许会话继续，以便找到并修复循环的原因。然而，在混频器或转换器不能正确地中断环路并导致高通信量的极端情况下，终端系统可能需要完全停止传输数据或控制数据包。这一决定可能取决于申请。应酌情指出错误情况。在长时间的随机时间（以分钟为单位）后，可能会定期再次尝试传输。
For layered encodings transmitted on separate RTP sessions (see Section 2.4), a single SSRC identifier space SHOULD be used across the sessions of all layers and the core (base) layer SHOULD be used for SSRC identifier allocation and collision resolution. When a source discovers that it has collided, it transmits an RTCP BYE packet on only the base layer but changes the SSRC identifier to the new value in all layers.
对于在单独RTP会话上传输的分层编码（参见第2.4节），应在所有层的会话中使用单个SSRC标识符空间，核心（基础）层应用于SSRC标识符分配和冲突解决。当一个源发现它发生了冲突时，它只在基本层上传输RTCP BYE数据包，但在所有层中将SSRC标识符更改为新值。
Lower layer protocols may eventually provide all the security services that may be desired for applications of RTP, including authentication, integrity, and confidentiality. These services have been specified for IP in [27]. Since the initial audio and video applications using RTP needed a confidentiality service before such services were available for the IP layer, the confidentiality service described in the next section was defined for use with RTP and RTCP. That description is included here to codify existing practice. New applications of RTP MAY implement this RTP-specific confidentiality service for backward compatibility, and/or they MAY implement alternative security services. The overhead on the RTP protocol for this confidentiality service is low, so the penalty will be minimal if this service is obsoleted by other services in the future.
较低层协议最终可能提供RTP应用所需的所有安全服务，包括身份验证、完整性和机密性。[27]中已为IP指定了这些服务。由于使用RTP的初始音频和视频应用程序在IP层提供此类服务之前需要保密服务，因此下一节中描述的保密服务定义为与RTP和RTCP一起使用。此处包含该说明是为了编纂现有实践。RTP的新应用程序可以实现此RTP特定的保密服务以实现向后兼容性，和/或它们可以实现替代安全服务。此机密性服务的RTP协议开销很低，因此如果此服务在将来被其他服务淘汰，则惩罚将很小。
Alternatively, other services, other implementations of services and other algorithms may be defined for RTP in the future. In particular, an RTP profile called Secure Real-time Transport Protocol (SRTP) [28] is being developed to provide confidentiality of the RTP payload while leaving the RTP header in the clear so that link-level header compression algorithms can still operate. It is expected that SRTP will be the correct choice for many applications. SRTP is based on the Advanced Encryption Standard (AES) and provides stronger security than the service described here. No claim is made that the methods presented here are appropriate for a particular security need. A profile may specify which services and algorithms should be offered by applications, and may provide guidance as to their appropriate use.
或者，将来可以为RTP定义其他服务、服务的其他实现和其他算法。具体而言，正在开发称为安全实时传输协议（SRTP）[28]的RTP配置文件，以提供RTP有效载荷的机密性，同时保持RTP报头处于透明状态，以便链路级报头压缩算法仍然可以运行。预计SRTP将是许多应用程序的正确选择。SRTP基于高级加密标准（AES）并提供比此处描述的服务更强的安全性。没有人声称此处提供的方法适用于特定的安全需求。概要文件可以指定应用程序应该提供哪些服务和算法，并可以提供关于其适当使用的指导。
Key distribution and certificates are outside the scope of this document.
密钥分发和证书不在本文档的范围内。
Confidentiality means that only the intended receiver(s) can decode the received packets; for others, the packet contains no useful information. Confidentiality of the content is achieved by encryption.
保密性意味着只有预期的接收器可以解码接收到的数据包；对于其他人来说，数据包不包含任何有用的信息。内容的机密性是通过加密实现的。
When it is desired to encrypt RTP or RTCP according to the method specified in this section, all the octets that will be encapsulated for transmission in a single lower-layer packet are encrypted as a unit. For RTCP, a 32-bit random number redrawn for each unit MUST be prepended to the unit before encryption. For RTP, no prefix is prepended; instead, the sequence number and timestamp fields are initialized with random offsets. This is considered to be a weak
当需要根据本节规定的方法对RTP或RTCP进行加密时，将封装在一个较低层数据包中传输的所有八位字节作为一个单元进行加密。对于RTCP，在加密之前，必须为每个单元重新绘制一个32位随机数。对于RTP，没有前缀；相反，序列号和时间戳字段用随机偏移量初始化。这被认为是一个薄弱环节
initialization vector (IV) because of poor randomness properties. In addition, if the subsequent field, the SSRC, can be manipulated by an enemy, there is further weakness of the encryption method.
由于随机性差，初始化向量（IV）。此外，如果随后的领域，即SSRC，可以被敌人操纵，则加密方法还有进一步的弱点。
For RTCP, an implementation MAY segregate the individual RTCP packets in a compound RTCP packet into two separate compound RTCP packets, one to be encrypted and one to be sent in the clear. For example, SDES information might be encrypted while reception reports were sent in the clear to accommodate third-party monitors that are not privy to the encryption key. In this example, depicted in Fig. 4, the SDES information MUST be appended to an RR packet with no reports (and the random number) to satisfy the requirement that all compound RTCP packets begin with an SR or RR packet. The SDES CNAME item is required in either the encrypted or unencrypted packet, but not both. The same SDES information SHOULD NOT be carried in both packets as this may compromise the encryption.
对于RTCP，实现可将复合RTCP数据包中的各个RTCP数据包分离为两个单独的复合RTCP数据包，一个要加密，另一个要以明文形式发送。例如，SDES信息可能会被加密，而接收报告则以明文形式发送，以容纳不了解加密密钥的第三方监控器。在该示例中，如图4所示，必须将SDES信息附加到没有报告（和随机数）的RR分组，以满足所有复合RTCP分组以SR或RR分组开始的要求。加密或未加密的数据包中都需要SDES CNAME项，但不是两者都需要。两个数据包中不应携带相同的SDES信息，因为这可能会影响加密。
UDP packet UDP packet
----------------------------- ------------------------------
[random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]
----------------------------- ------------------------------
encrypted not encrypted
UDP packet UDP packet
----------------------------- ------------------------------
[random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]
----------------------------- ------------------------------
encrypted not encrypted
#: SSRC identifier
#：SSRC标识符
Figure 4: Encrypted and non-encrypted RTCP packets
图4：加密和非加密RTCP数据包
The presence of encryption and the use of the correct key are confirmed by the receiver through header or payload validity checks. Examples of such validity checks for RTP and RTCP headers are given in Appendices A.1 and A.2.
接收方通过报头或有效负载有效性检查确认加密的存在和正确密钥的使用。附录A.1和A.2给出了RTP和RTCP头的有效性检查示例。
To be consistent with existing implementations of the initial specification of RTP in RFC 1889, the default encryption algorithm is the Data Encryption Standard (DES) algorithm in cipher block chaining (CBC) mode, as described in Section 1.1 of RFC 1423 [29], except that padding to a multiple of 8 octets is indicated as described for the P bit in Section 5.1. The initialization vector is zero because random values are supplied in the RTP header or by the random prefix for compound RTCP packets. For details on the use of CBC initialization vectors, see [30].
为了与RFC 1889中RTP初始规范的现有实现保持一致，默认加密算法是密码块链接（CBC）模式下的数据加密标准（DES）算法，如RFC 1423[29]第1.1节所述，除了第5.1节中P位所述的填充到8个八位字节的倍数。初始化向量为零，因为随机值在RTP报头中提供，或由复合RTCP数据包的随机前缀提供。有关使用CBC初始化向量的详细信息，请参见[30]。
Implementations that support the encryption method specified here SHOULD always support the DES algorithm in CBC mode as the default cipher for this method to maximize interoperability. This method was chosen because it has been demonstrated to be easy and practical to use in experimental audio and video tools in operation on the Internet. However, DES has since been found to be too easily broken.
支持此处指定的加密方法的实现应始终支持CBC模式下的DES算法作为此方法的默认密码，以最大限度地提高互操作性。之所以选择这种方法，是因为它已被证明易于在互联网上运行的实验音频和视频工具中使用。然而，人们发现DES太容易损坏。
It is RECOMMENDED that stronger encryption algorithms such as Triple-DES be used in place of the default algorithm. Furthermore, secure CBC mode requires that the first block of each packet be XORed with a random, independent IV of the same size as the cipher's block size. For RTCP, this is (partially) achieved by prepending each packet with a 32-bit random number, independently chosen for each packet. For RTP, the timestamp and sequence number start from random values, but consecutive packets will not be independently randomized. It should be noted that the randomness in both cases (RTP and RTCP) is limited. High-security applications SHOULD consider other, more conventional, protection means. Other encryption algorithms MAY be specified dynamically for a session by non-RTP means. In particular, the SRTP profile [28] based on AES is being developed to take into account known plaintext and CBC plaintext manipulation concerns, and will be the correct choice in the future.
建议使用更强大的加密算法（如三重DES）代替默认算法。此外，安全CBC模式要求每个数据包的第一个数据块与随机、独立的IV进行异或运算，其大小与密码的数据块大小相同。对于RTCP，这是（部分）通过在每个数据包前面加上一个32位随机数来实现的，该随机数是为每个数据包独立选择的。对于RTP，时间戳和序列号从随机值开始，但连续数据包不会独立随机。应该注意的是，两种情况（RTP和RTCP）的随机性都是有限的。高安全性应用应该考虑其他更常规的保护手段。可以通过非RTP方式为会话动态指定其他加密算法。特别是，基于AES的SRTP配置文件[28]正在开发中，以考虑已知的明文和CBC明文操作问题，并将是未来的正确选择。
As an alternative to encryption at the IP level or at the RTP level as described above, profiles MAY define additional payload types for encrypted encodings. Those encodings MUST specify how padding and other aspects of the encryption are to be handled. This method allows encrypting only the data while leaving the headers in the clear for applications where that is desired. It may be particularly useful for hardware devices that will handle both decryption and decoding. It is also valuable for applications where link-level compression of RTP and lower-layer headers is desired and confidentiality of the payload (but not addresses) is sufficient since encryption of the headers precludes compression.
作为如上所述的IP级或RTP级加密的替代方案，概要文件可以为加密编码定义额外的有效负载类型。这些编码必须指定如何处理填充和加密的其他方面。此方法只允许加密数据，而对于需要加密的应用程序，将头保留在清除状态。它对于同时处理解密和解码的硬件设备可能特别有用。对于需要RTP和较低层报头的链路级压缩且有效负载（但不是地址）的机密性足够的应用程序来说，这也是很有价值的，因为报头的加密排除了压缩。
Authentication and message integrity services are not defined at the RTP level since these services would not be directly feasible without a key management infrastructure. It is expected that authentication and integrity services will be provided by lower layer protocols.
认证和消息完整性服务没有在RTP级别定义，因为如果没有密钥管理基础设施，这些服务将无法直接实现。预计认证和完整性服务将由较低层协议提供。
All transport protocols used on the Internet need to address congestion control in some way [31]. RTP is not an exception, but because the data transported over RTP is often inelastic (generated at a fixed or controlled rate), the means to control congestion in RTP may be quite different from those for other transport protocols such as TCP. In one sense, inelasticity reduces the risk of congestion because the RTP stream will not expand to consume all available bandwidth as a TCP stream can. However, inelasticity also means that the RTP stream cannot arbitrarily reduce its load on the network to eliminate congestion when it occurs.
互联网上使用的所有传输协议都需要以某种方式解决拥塞控制问题[31]。RTP也不例外，但由于通过RTP传输的数据通常是非弹性的（以固定或受控速率生成），因此RTP中控制拥塞的方法可能与其他传输协议（如TCP）的方法大不相同。在某种意义上，非弹性降低了拥塞风险，因为RTP流不会像TCP流那样扩展到消耗所有可用带宽。然而，非弹性也意味着RTP流不能任意减少其在网络上的负载以消除拥塞。
Since RTP may be used for a wide variety of applications in many different contexts, there is no single congestion control mechanism that will work for all. Therefore, congestion control SHOULD be defined in each RTP profile as appropriate. For some profiles, it may be sufficient to include an applicability statement restricting the use of that profile to environments where congestion is avoided by engineering. For other profiles, specific methods such as data rate adaptation based on RTCP feedback may be required.
由于RTP可以在许多不同的环境中用于各种各样的应用，因此没有一种单一的拥塞控制机制可以适用于所有情况。因此，拥塞控制应该在每个RTP配置文件中定义。对于某些配置文件，包括一个适用性声明可能就足够了，该声明将该配置文件的使用限制在通过工程避免拥塞的环境中。对于其他配置文件，可能需要特定方法，例如基于RTCP反馈的数据速率自适应。
This section describes issues specific to carrying RTP packets within particular network and transport protocols. The following rules apply unless superseded by protocol-specific definitions outside this specification.
本节描述特定于在特定网络和传输协议中承载RTP数据包的问题。以下规则适用，除非被本规范以外的协议特定定义取代。
RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number. For applications that take a single port number as a parameter and derive the RTP and RTCP port pair from that number, if an odd number is supplied then the application SHOULD replace that number with the next lower (even) number to use as the base of the port pair. For applications in which the RTP and RTCP destination port numbers are specified via explicit, separate parameters (using a signaling protocol or other means), the application MAY disregard the restrictions that the port numbers be even/odd and consecutive although the use of an even/odd port pair is still encouraged. The RTP and RTCP port numbers MUST NOT be the same since RTP relies on the port numbers to demultiplex the RTP data and RTCP control streams.
RTP依赖于底层协议来提供RTP数据和RTCP控制流的解复用。对于UDP和类似协议，RTP应使用偶数目标端口号，而相应的RTCP流应使用下一个更高（奇数）的目标端口号。对于采用单个端口号作为参数并从该端口号派生RTP和RTCP端口对的应用程序，如果提供奇数，则应用程序应使用下一个较低（偶数）的数字替换该数字，以用作端口对的基础。对于RTP和RTCP目的地端口号通过明确、单独的参数（使用信令协议或其他方式）指定的应用程序，尽管仍然鼓励使用偶数/奇数端口对，但应用程序可以忽略端口号为偶数/奇数和连续的限制。RTP和RTCP端口号不能相同，因为RTP依赖端口号来解复用RTP数据和RTCP控制流。
In a unicast session, both participants need to identify a port pair for receiving RTP and RTCP packets. Both participants MAY use the same port pair. A participant MUST NOT assume that the source port of the incoming RTP or RTCP packet can be used as the destination port for outgoing RTP or RTCP packets. When RTP data packets are being sent in both directions, each participant's RTCP SR packets MUST be sent to the port that the other participant has specified for reception of RTCP. The RTCP SR packets combine sender information for the outgoing data plus reception report information for the incoming data. If a side is not actively sending data (see Section 6.4), an RTCP RR packet is sent instead.
在单播会话中，两个参与者都需要标识用于接收RTP和RTCP数据包的端口对。两个参与者可以使用相同的端口对。参与者不得假设传入RTP或RTCP数据包的源端口可用作传出RTP或RTCP数据包的目标端口。当RTP数据包在两个方向上发送时，每个参与者的RTCP SR数据包必须发送到另一参与者指定用于接收RTCP的端口。RTCP SR数据包将传出数据的发送方信息与传入数据的接收报告信息相结合。如果一方未主动发送数据（见第6.4节），则发送RTCP RR数据包。
It is RECOMMENDED that layered encoding applications (see Section 2.4) use a set of contiguous port numbers. The port numbers MUST be distinct because of a widespread deficiency in existing operating
建议分层编码应用程序（参见第2.4节）使用一组连续端口号。由于现有操作系统普遍存在缺陷，端口号必须不同
systems that prevents use of the same port with multiple multicast addresses, and for unicast, there is only one permissible address. Thus for layer n, the data port is P + 2n, and the control port is P + 2n + 1. When IP multicast is used, the addresses MUST also be distinct because multicast routing and group membership are managed on an address granularity. However, allocation of contiguous IP multicast addresses cannot be assumed because some groups may require different scopes and may therefore be allocated from different address ranges.
防止使用具有多个多播地址的同一端口的系统，对于单播，只有一个允许的地址。因此，对于层n，数据端口为P+2n，控制端口为P+2n+1。使用IP多播时，地址也必须是不同的，因为多播路由和组成员资格是在地址粒度上管理的。但是，不能假设连续IP多播地址的分配，因为某些组可能需要不同的作用域，因此可能从不同的地址范围分配。
The previous paragraph conflicts with the SDP specification, RFC 2327 [15], which says that it is illegal for both multiple addresses and multiple ports to be specified in the same session description because the association of addresses with ports could be ambiguous. It is intended that this restriction will be relaxed in a revision of RFC 2327 to allow an equal number of addresses and ports to be specified with a one-to-one mapping implied.
上一段与SDP规范RFC 2327[15]相冲突，该规范指出，在同一会话描述中指定多个地址和多个端口是非法的，因为地址与端口的关联可能是不明确的。RFC 2327的修订版将放宽此限制，以允许使用一对一映射指定相同数量的地址和端口。
RTP data packets contain no length field or other delineation, therefore RTP relies on the underlying protocol(s) to provide a length indication. The maximum length of RTP packets is limited only by the underlying protocols.
RTP数据包不包含长度字段或其他描述，因此RTP依赖于底层协议来提供长度指示。RTP数据包的最大长度仅受底层协议的限制。
If RTP packets are to be carried in an underlying protocol that provides the abstraction of a continuous octet stream rather than messages (packets), an encapsulation of the RTP packets MUST be defined to provide a framing mechanism. Framing is also needed if the underlying protocol may contain padding so that the extent of the RTP payload cannot be determined. The framing mechanism is not defined here.
如果RTP数据包要在提供连续八位字节流而不是消息（数据包）抽象的基础协议中进行，则必须定义RTP数据包的封装以提供帧机制。如果基础协议可能包含填充，从而无法确定RTP有效负载的范围，则还需要帧。此处未定义框架机制。
A profile MAY specify a framing method to be used even when RTP is carried in protocols that do provide framing in order to allow carrying several RTP packets in one lower-layer protocol data unit, such as a UDP packet. Carrying several RTP packets in one network or transport packet reduces header overhead and may simplify synchronization between different streams.
配置文件可以指定要使用的成帧方法，即使在提供成帧的协议中承载RTP，以便允许在一个较低层协议数据单元（例如UDP分组）中承载多个RTP分组。在一个网络或传输数据包中承载多个RTP数据包可减少报头开销，并可简化不同流之间的同步。
This section contains a summary listing of the constants defined in this specification.
本节包含本规范中定义的常量的摘要列表。
The RTP payload type (PT) constants are defined in profiles rather than this document. However, the octet of the RTP header which contains the marker bit(s) and payload type MUST avoid the reserved values 200 and 201 (decimal) to distinguish RTP packets from the RTCP SR and RR packet types for the header validation procedure described
RTP有效负载类型（PT）常量在配置文件中定义，而不是在本文档中定义。然而，包含标记位和有效负载类型的RTP报头的八位字节必须避免保留值200和201（十进制），以区分RTP分组与所述报头验证过程的RTCP SR和RR分组类型
in Appendix A.1. For the standard definition of one marker bit and a 7-bit payload type field as shown in this specification, this restriction means that payload types 72 and 73 are reserved.
在附录A.1中。对于本规范中所示的一个标记位和7位有效负载类型字段的标准定义，该限制意味着保留有效负载类型72和73。
abbrev. name value SR sender report 200 RR receiver report 201 SDES source description 202 BYE goodbye 203 APP application-defined 204
阿巴雷夫。名称值SR发送方报告200 RR接收方报告201 SDES源描述202应用程序定义204
These type values were chosen in the range 200-204 for improved header validity checking of RTCP packets compared to RTP packets or other unrelated packets. When the RTCP packet type field is compared to the corresponding octet of the RTP header, this range corresponds to the marker bit being 1 (which it usually is not in data packets) and to the high bit of the standard payload type field being 1 (since the static payload types are typically defined in the low half). This range was also chosen to be some distance numerically from 0 and 255 since all-zeros and all-ones are common data patterns.
与RTP数据包或其他无关数据包相比，在200-204范围内选择这些类型值，以改进RTCP数据包的报头有效性检查。当将RTCP数据包类型字段与RTP报头的相应八位字节进行比较时，该范围对应于标记位为1（它通常不在数据包中）和标准有效负载类型字段的高位为1（因为静态有效负载类型通常在低位定义）。这个范围也被选择为从0到255的数字距离，因为所有的0和1都是公共数据模式。
Since all compound RTCP packets MUST begin with SR or RR, these codes were chosen as an even/odd pair to allow the RTCP validity check to test the maximum number of bits with mask and value.
由于所有复合RTCP数据包必须以SR或RR开头，因此选择这些代码作为偶数/奇数对，以允许RTCP有效性检查使用掩码和值测试最大位数。
Additional RTCP packet types may be registered through IANA (see Section 15).
其他RTCP数据包类型可通过IANA注册（见第15节）。
abbrev. name value END end of SDES list 0 CNAME canonical name 1 NAME user name 2 EMAIL user's electronic mail address 3 PHONE user's phone number 4 LOC geographic user location 5 TOOL name of application or tool 6 NOTE notice about the source 7 PRIV private extensions 8
阿巴雷夫。名称值SDES列表末尾0 CNAME规范名称1名称用户名2电子邮件用户的电子邮件地址3电话用户的电话号码4 LOC地理用户位置5应用程序或工具的工具名称6关于来源的注意事项7 PRIV private extensions 8
Additional SDES types may be registered through IANA (see Section 15).
其他SDE类型可通过IANA注册（见第15节）。
A complete specification of RTP for a particular application will require one or more companion documents of two types described here: profiles, and payload format specifications.
一个特定应用的完整RTP规范需要一个或多个本文描述的两种类型的配套文档：概要文件和有效负载格式规范。
RTP may be used for a variety of applications with somewhat differing requirements. The flexibility to adapt to those requirements is provided by allowing multiple choices in the main protocol specification, then selecting the appropriate choices or defining extensions for a particular environment and class of applications in a separate profile document. Typically an application will operate under only one profile in a particular RTP session, so there is no explicit indication within the RTP protocol itself as to which profile is in use. A profile for audio and video applications may be found in the companion RFC 3551. Profiles are typically titled "RTP Profile for ...".
RTP可用于各种不同要求的应用。通过在主协议规范中允许多种选择，然后在单独的概要文件中选择适当的选择或定义特定环境和应用程序类别的扩展，可以提供适应这些需求的灵活性。通常，在特定RTP会话中，应用程序将仅在一个配置文件下运行，因此RTP协议本身中没有关于使用哪个配置文件的明确指示。音频和视频应用的配置文件可在配套的RFC 3551中找到。配置文件的标题通常为“RTP配置文件…”。
The second type of companion document is a payload format specification, which defines how a particular kind of payload data, such as H.261 encoded video, should be carried in RTP. These documents are typically titled "RTP Payload Format for XYZ Audio/Video Encoding". Payload formats may be useful under multiple profiles and may therefore be defined independently of any particular profile. The profile documents are then responsible for assigning a default mapping of that format to a payload type value if needed.
第二类附带文档是有效负载格式规范，它定义了特定类型的有效负载数据（如H.261编码视频）应如何在RTP中传输。这些文档的标题通常为“XYZ音频/视频编码的RTP有效负载格式”。有效载荷格式在多个概要文件下可能有用，因此可以独立于任何特定概要文件进行定义。如果需要，概要文件文档负责将该格式的默认映射分配给有效负载类型值。
Within this specification, the following items have been identified for possible definition within a profile, but this list is not meant to be exhaustive:
在本规范中，已确定以下项目，以便在概要文件中进行可能的定义，但本列表并非详尽无遗：
RTP data header: The octet in the RTP data header that contains the marker bit and payload type field MAY be redefined by a profile to suit different requirements, for example with more or fewer marker bits (Section 5.3, p. 18).
RTP数据头：RTP数据头中包含标记位和有效负载类型字段的八位字节可由配置文件重新定义，以适应不同的要求，例如使用更多或更少的标记位（第5.3节，第18页）。
Payload types: Assuming that a payload type field is included, the profile will usually define a set of payload formats (e.g., media encodings) and a default static mapping of those formats to payload type values. Some of the payload formats may be defined by reference to separate payload format specifications. For each payload type defined, the profile MUST specify the RTP timestamp clock rate to be used (Section 5.1, p. 14).
有效负载类型：假设包含有效负载类型字段，配置文件通常会定义一组有效负载格式（例如，媒体编码）以及这些格式到有效负载类型值的默认静态映射。一些有效载荷格式可以通过参考单独的有效载荷格式规范来定义。对于定义的每个有效负载类型，配置文件必须指定要使用的RTP时间戳时钟速率（第5.1节，第14页）。
RTP data header additions: Additional fields MAY be appended to the fixed RTP data header if some additional functionality is required across the profile's class of applications independent of payload type (Section 5.3, p. 18).
RTP数据头添加：如果在配置文件的应用程序类别中需要一些独立于有效负载类型的附加功能，则可以在固定RTP数据头中添加附加字段（第5.3节，第18页）。
RTP data header extensions: The contents of the first 16 bits of the RTP data header extension structure MUST be defined if use of that mechanism is to be allowed under the profile for implementation-specific extensions (Section 5.3.1, p. 18).
RTP数据头扩展：如果在特定于实现的扩展配置文件（第5.3.1节，第18页）下允许使用RTP数据头扩展结构的前16位的内容，则必须定义该结构的内容。
RTCP packet types: New application-class-specific RTCP packet types MAY be defined and registered with IANA.
RTCP数据包类型：可在IANA中定义并注册新的应用程序类特定RTCP数据包类型。
RTCP report interval: A profile SHOULD specify that the values suggested in Section 6.2 for the constants employed in the calculation of the RTCP report interval will be used. Those are the RTCP fraction of session bandwidth, the minimum report interval, and the bandwidth split between senders and receivers. A profile MAY specify alternate values if they have been demonstrated to work in a scalable manner.
RTCP报告间隔：配置文件应规定将使用第6.2节中建议的用于计算RTCP报告间隔的常数值。这些是会话带宽的RTCP部分、最小报告间隔以及发送方和接收方之间的带宽分配。配置文件可以指定备用值，前提是它们已被证明以可伸缩的方式工作。
SR/RR extension: An extension section MAY be defined for the RTCP SR and RR packets if there is additional information that should be reported regularly about the sender or receivers (Section 6.4.3, p. 42 and 43).
SR/RR扩展：如果有关于发送方或接收方的额外信息应定期报告，则可为RTCP SR和RR数据包定义扩展部分（第6.4.3节，第42和43页）。
SDES use: The profile MAY specify the relative priorities for RTCP SDES items to be transmitted or excluded entirely (Section 6.3.9); an alternate syntax or semantics for the CNAME item (Section 6.5.1); the format of the LOC item (Section 6.5.5); the semantics and use of the NOTE item (Section 6.5.7); or new SDES item types to be registered with IANA.
SDE使用：档案可规定RTCP SDE项目的相对优先级，以便传输或完全排除（第6.3.9节）；CNAME项的替代语法或语义（第6.5.1节）；LOC项目的格式（第6.5.5节）；注释项的语义和使用（第6.5.7节）；或向IANA注册的新SDES项目类型。
Security: A profile MAY specify which security services and algorithms should be offered by applications, and MAY provide guidance as to their appropriate use (Section 9, p. 65).
安全性：概要文件可以指定应用程序应提供哪些安全服务和算法，并可以提供有关其适当使用的指导（第9节，第65页）。
String-to-key mapping: A profile MAY specify how a user-provided password or pass phrase is mapped into an encryption key.
字符串到密钥映射：配置文件可以指定如何将用户提供的密码或密码短语映射到加密密钥。
Congestion: A profile SHOULD specify the congestion control behavior appropriate for that profile.
拥塞：配置文件应指定适合该配置文件的拥塞控制行为。
Underlying protocol: Use of a particular underlying network or transport layer protocol to carry RTP packets MAY be required.
底层协议：可能需要使用特定的底层网络或传输层协议来承载RTP数据包。
Transport mapping: A mapping of RTP and RTCP to transport-level addresses, e.g., UDP ports, other than the standard mapping defined in Section 11, p. 68 may be specified.
传输映射：RTP和RTCP到传输级地址（例如UDP端口）的映射，而不是第11节，p中定义的标准映射。可规定第68条。
Encapsulation: An encapsulation of RTP packets may be defined to allow multiple RTP data packets to be carried in one lower-layer packet or to provide framing over underlying protocols that do not already do so (Section 11, p. 69).
封装：RTP数据包的封装可定义为允许在一个较低层数据包中承载多个RTP数据包，或在尚未这样做的底层协议上提供帧（第11节，第69页）。
It is not expected that a new profile will be required for every application. Within one application class, it would be better to extend an existing profile rather than make a new one in order to facilitate interoperation among the applications since each will typically run under only one profile. Simple extensions such as the definition of additional payload type values or RTCP packet types may be accomplished by registering them through IANA and publishing their descriptions in an addendum to the profile or in a payload format specification.
并非所有应用程序都需要新的配置文件。在一个应用程序类中，为了促进应用程序之间的互操作，最好扩展现有概要文件，而不是创建新概要文件，因为每个应用程序通常只在一个概要文件下运行。可以通过IANA注册其他有效负载类型值或RTCP数据包类型，并在概要文件附录或有效负载格式规范中发布其描述，从而实现简单扩展，如定义其他有效负载类型值或RTCP数据包类型。
RTP suffers from the same security liabilities as the underlying protocols. For example, an impostor can fake source or destination network addresses, or change the header or payload. Within RTCP, the CNAME and NAME information may be used to impersonate another participant. In addition, RTP may be sent via IP multicast, which provides no direct means for a sender to know all the receivers of the data sent and therefore no measure of privacy. Rightly or not, users may be more sensitive to privacy concerns with audio and video communication than they have been with more traditional forms of network communication [33]. Therefore, the use of security mechanisms with RTP is important. These mechanisms are discussed in Section 9.
RTP与底层协议具有相同的安全责任。例如，冒名顶替者可以伪造源或目标网络地址，或者更改报头或有效负载。在RTCP内，CNAME和姓名信息可用于模拟其他参与者。此外，RTP可以通过IP多播发送，这没有为发送者提供了解所发送数据的所有接收者的直接手段，因此没有隐私措施。不管正确与否，与传统的网络通信方式相比，用户可能对音频和视频通信的隐私问题更加敏感[33]。因此，在RTP中使用安全机制非常重要。第9节讨论了这些机制。
RTP-level translators or mixers may be used to allow RTP traffic to reach hosts behind firewalls. Appropriate firewall security principles and practices, which are beyond the scope of this document, should be followed in the design and installation of these devices and in the admission of RTP applications for use behind the firewall.
RTP级转换器或混频器可用于允许RTP通信到达防火墙后面的主机。在设计和安装这些设备以及允许RTP应用程序在防火墙后使用时，应遵循适当的防火墙安全原则和实践，这些原则和实践超出了本文件的范围。
Additional RTCP packet types and SDES item types may be registered through the Internet Assigned Numbers Authority (IANA). Since these number spaces are small, allowing unconstrained registration of new values would not be prudent. To facilitate review of requests and to promote shared use of new types among multiple applications, requests for registration of new values must be documented in an RFC or other permanent and readily available reference such as the product of another cooperative standards body (e.g., ITU-T). Other requests may also be accepted, under the advice of a "designated expert."
其他RTCP数据包类型和SDES项目类型可通过互联网分配号码管理局（IANA）注册。由于这些数字空间很小，因此允许无约束地注册新值是不明智的。为了便于审查请求并促进在多个应用程序之间共享新类型的使用，新值的注册请求必须记录在RFC或其他永久和现成的参考文件中，如另一个合作标准机构（如ITU-T）的产品。在“指定专家”的建议下，也可以接受其他请求
(Contact the IANA for the contact information of the current expert.)
（有关当前专家的联系信息，请联系IANA。）
RTP profile specifications SHOULD register with IANA a name for the profile in the form "RTP/xxx", where xxx is a short abbreviation of the profile title. These names are for use by higher-level control protocols, such as the Session Description Protocol (SDP), RFC 2327 [15], to refer to transport methods.
RTP概要文件规范应以“RTP/xxx”的形式向IANA注册概要文件的名称，其中xxx是概要文件标题的缩写。这些名称用于更高级别的控制协议，如会话描述协议（SDP），RFC 2327[15]，以引用传输方法。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
This memorandum is based on discussions within the IETF Audio/Video Transport working group chaired by Stephen Casner and Colin Perkins. The current protocol has its origins in the Network Voice Protocol and the Packet Video Protocol (Danny Cohen and Randy Cole) and the protocol implemented by the vat application (Van Jacobson and Steve McCanne). Christian Huitema provided ideas for the random identifier generator. Extensive analysis and simulation of the timer reconsideration algorithm was done by Jonathan Rosenberg. The additions for layered encodings were specified by Michael Speer and Steve McCanne.
本备忘录基于由Stephen Casner和Colin Perkins主持的IETF音频/视频传输工作组内的讨论。当前协议起源于网络语音协议和分组视频协议（Danny Cohen和Randy Cole）以及由vat应用程序实现的协议（Van Jacobson和Steve McCanne）。Christian Huitema为随机标识符生成器提供了一些想法。Jonathan Rosenberg对计时器重新考虑算法进行了广泛的分析和模拟。分层编码的添加由Michael Speer和Steve McCanne指定。
Appendix A - Algorithms
附录A-算法
We provide examples of C code for aspects of RTP sender and receiver algorithms. There may be other implementation methods that are faster in particular operating environments or have other advantages. These implementation notes are for informational purposes only and are meant to clarify the RTP specification.
我们提供了RTP发送方和接收方算法方面的C代码示例。在特定的操作环境中，可能有其他更快的实现方法，或者具有其他优势。这些实施说明仅供参考，旨在澄清RTP规范。
The following definitions are used for all examples; for clarity and brevity, the structure definitions are only valid for 32-bit big-endian (most significant octet first) architectures. Bit fields are assumed to be packed tightly in big-endian bit order, with no additional padding. Modifications would be required to construct a portable implementation.
以下定义适用于所有示例；为清晰和简洁起见，结构定义仅适用于32位big-endian（最重要的八位组优先）体系结构。假定位字段按大端位顺序紧密排列，没有额外的填充。构建一个可移植的实现需要修改。
/*
* rtp.h -- RTP header file
*/
#include <sys/types.h>
/*
* rtp.h -- RTP header file
*/
#include <sys/types.h>
/*
* The type definitions below are valid for 32-bit architectures and
* may have to be adjusted for 16- or 64-bit architectures.
*/
typedef unsigned char u_int8;
typedef unsigned short u_int16;
typedef unsigned int u_int32;
typedef short int16;
/*
* The type definitions below are valid for 32-bit architectures and
* may have to be adjusted for 16- or 64-bit architectures.
*/
typedef unsigned char u_int8;
typedef unsigned short u_int16;
typedef unsigned int u_int32;
typedef short int16;
/*
* Current protocol version.
*/
#define RTP_VERSION 2
/*
* Current protocol version.
*/
#define RTP_VERSION 2
#define RTP_SEQ_MOD (1<<16)
#define RTP_MAX_SDES 255 /* maximum text length for SDES */
#define RTP_SEQ_MOD (1<<16)
#define RTP_MAX_SDES 255 /* maximum text length for SDES */
typedef enum {
RTCP_SR = 200,
RTCP_RR = 201,
RTCP_SDES = 202,
RTCP_BYE = 203,
RTCP_APP = 204
} rtcp_type_t;
typedef enum {
RTCP_SR = 200,
RTCP_RR = 201,
RTCP_SDES = 202,
RTCP_BYE = 203,
RTCP_APP = 204
} rtcp_type_t;
typedef enum {
RTCP_SDES_END = 0,
RTCP_SDES_CNAME = 1,
typedef enum {
RTCP_SDES_END = 0,
RTCP_SDES_CNAME = 1,
RTCP_SDES_NAME = 2, RTCP_SDES_EMAIL = 3, RTCP_SDES_PHONE = 4, RTCP_SDES_LOC = 5, RTCP_SDES_TOOL = 6, RTCP_SDES_NOTE = 7, RTCP_SDES_PRIV = 8 } rtcp_sdes_type_t;
RTCP_SDES_NAME=2，RTCP_SDES_EMAIL=3，RTCP_SDES_PHONE=4，RTCP_SDES_LOC=5，RTCP_SDES_TOOL=6，RTCP_SDES_NOTE=7，RTCP_SDES_PRIV=8}；
/*
* RTP data header
*/
typedef struct {
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int x:1; /* header extension flag */
unsigned int cc:4; /* CSRC count */
unsigned int m:1; /* marker bit */
unsigned int pt:7; /* payload type */
unsigned int seq:16; /* sequence number */
u_int32 ts; /* timestamp */
u_int32 ssrc; /* synchronization source */
u_int32 csrc[1]; /* optional CSRC list */
} rtp_hdr_t;
/*
* RTP data header
*/
typedef struct {
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int x:1; /* header extension flag */
unsigned int cc:4; /* CSRC count */
unsigned int m:1; /* marker bit */
unsigned int pt:7; /* payload type */
unsigned int seq:16; /* sequence number */
u_int32 ts; /* timestamp */
u_int32 ssrc; /* synchronization source */
u_int32 csrc[1]; /* optional CSRC list */
} rtp_hdr_t;
/*
* RTCP common header word
*/
typedef struct {
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int count:5; /* varies by packet type */
unsigned int pt:8; /* RTCP packet type */
u_int16 length; /* pkt len in words, w/o this word */
} rtcp_common_t;
/*
* RTCP common header word
*/
typedef struct {
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int count:5; /* varies by packet type */
unsigned int pt:8; /* RTCP packet type */
u_int16 length; /* pkt len in words, w/o this word */
} rtcp_common_t;
/*
* Big-endian mask for version, padding bit and packet type pair
*/
#define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)
#define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)
/*
* Big-endian mask for version, padding bit and packet type pair
*/
#define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)
#define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)
/*
* Reception report block
*/
typedef struct {
u_int32 ssrc; /* data source being reported */
unsigned int fraction:8; /* fraction lost since last SR/RR */
/*
* Reception report block
*/
typedef struct {
u_int32 ssrc; /* data source being reported */
unsigned int fraction:8; /* fraction lost since last SR/RR */
int lost:24; /* cumul. no. pkts lost (signed!) */
u_int32 last_seq; /* extended last seq. no. received */
u_int32 jitter; /* interarrival jitter */
u_int32 lsr; /* last SR packet from this source */
u_int32 dlsr; /* delay since last SR packet */
} rtcp_rr_t;
int lost:24; /* cumul. no. pkts lost (signed!) */
u_int32 last_seq; /* extended last seq. no. received */
u_int32 jitter; /* interarrival jitter */
u_int32 lsr; /* last SR packet from this source */
u_int32 dlsr; /* delay since last SR packet */
} rtcp_rr_t;
/*
* SDES item
*/
typedef struct {
u_int8 type; /* type of item (rtcp_sdes_type_t) */
u_int8 length; /* length of item (in octets) */
char data[1]; /* text, not null-terminated */
} rtcp_sdes_item_t;
/*
* SDES item
*/
typedef struct {
u_int8 type; /* type of item (rtcp_sdes_type_t) */
u_int8 length; /* length of item (in octets) */
char data[1]; /* text, not null-terminated */
} rtcp_sdes_item_t;
/*
* One RTCP packet
*/
typedef struct {
rtcp_common_t common; /* common header */
union {
/* sender report (SR) */
struct {
u_int32 ssrc; /* sender generating this report */
u_int32 ntp_sec; /* NTP timestamp */
u_int32 ntp_frac;
u_int32 rtp_ts; /* RTP timestamp */
u_int32 psent; /* packets sent */
u_int32 osent; /* octets sent */
rtcp_rr_t rr[1]; /* variable-length list */
} sr;
/*
* One RTCP packet
*/
typedef struct {
rtcp_common_t common; /* common header */
union {
/* sender report (SR) */
struct {
u_int32 ssrc; /* sender generating this report */
u_int32 ntp_sec; /* NTP timestamp */
u_int32 ntp_frac;
u_int32 rtp_ts; /* RTP timestamp */
u_int32 psent; /* packets sent */
u_int32 osent; /* octets sent */
rtcp_rr_t rr[1]; /* variable-length list */
} sr;
/* reception report (RR) */
struct {
u_int32 ssrc; /* receiver generating this report */
rtcp_rr_t rr[1]; /* variable-length list */
} rr;
/* reception report (RR) */
struct {
u_int32 ssrc; /* receiver generating this report */
rtcp_rr_t rr[1]; /* variable-length list */
} rr;
/* source description (SDES) */
struct rtcp_sdes {
u_int32 src; /* first SSRC/CSRC */
rtcp_sdes_item_t item[1]; /* list of SDES items */
} sdes;
/* source description (SDES) */
struct rtcp_sdes {
u_int32 src; /* first SSRC/CSRC */
rtcp_sdes_item_t item[1]; /* list of SDES items */
} sdes;
/* BYE */
struct {
u_int32 src[1]; /* list of sources */
/* BYE */
struct {
u_int32 src[1]; /* list of sources */
/* can't express trailing text for reason */
} bye;
} r;
} rtcp_t;
/* can't express trailing text for reason */
} bye;
} r;
} rtcp_t;
typedef struct rtcp_sdes rtcp_sdes_t;
类型定义结构rtcp_sdes rtcp_sdes_t；
/*
* Per-source state information
*/
typedef struct {
u_int16 max_seq; /* highest seq. number seen */
u_int32 cycles; /* shifted count of seq. number cycles */
u_int32 base_seq; /* base seq number */
u_int32 bad_seq; /* last 'bad' seq number + 1 */
u_int32 probation; /* sequ. packets till source is valid */
u_int32 received; /* packets received */
u_int32 expected_prior; /* packet expected at last interval */
u_int32 received_prior; /* packet received at last interval */
u_int32 transit; /* relative trans time for prev pkt */
u_int32 jitter; /* estimated jitter */
/* ... */
} source;
/*
* Per-source state information
*/
typedef struct {
u_int16 max_seq; /* highest seq. number seen */
u_int32 cycles; /* shifted count of seq. number cycles */
u_int32 base_seq; /* base seq number */
u_int32 bad_seq; /* last 'bad' seq number + 1 */
u_int32 probation; /* sequ. packets till source is valid */
u_int32 received; /* packets received */
u_int32 expected_prior; /* packet expected at last interval */
u_int32 received_prior; /* packet received at last interval */
u_int32 transit; /* relative trans time for prev pkt */
u_int32 jitter; /* estimated jitter */
/* ... */
} source;
An RTP receiver should check the validity of the RTP header on incoming packets since they might be encrypted or might be from a different application that happens to be misaddressed. Similarly, if encryption according to the method described in Section 9 is enabled, the header validity check is needed to verify that incoming packets have been correctly decrypted, although a failure of the header validity check (e.g., unknown payload type) may not necessarily indicate decryption failure.
RTP接收器应检查传入数据包上RTP报头的有效性，因为这些数据包可能已加密，或者可能来自碰巧地址错误的不同应用程序。类似地，如果启用了根据第9节中描述的方法的加密，则需要进行报头有效性检查以验证传入分组是否已正确解密，尽管报头有效性检查的失败（例如，未知有效负载类型）不一定表示解密失败。
Only weak validity checks are possible on an RTP data packet from a source that has not been heard before:
对于来自以前从未听到过的源的RTP数据包，只能进行弱有效性检查：
o RTP version field must equal 2.
o RTP版本字段必须等于2。
o The payload type must be known, and in particular it must not be equal to SR or RR.
o 有效负载类型必须是已知的，尤其是它不能等于SR或RR。
o If the P bit is set, then the last octet of the packet must contain a valid octet count, in particular, less than the total packet length minus the header size.
o 如果设置了P位，则数据包的最后一个八位组必须包含有效的八位组计数，尤其是小于数据包总长度减去报头大小。
o The X bit must be zero if the profile does not specify that the header extension mechanism may be used. Otherwise, the extension length field must be less than the total packet size minus the fixed header length and padding.
o 如果配置文件未指定可以使用标头扩展机制，则X位必须为零。否则，扩展长度字段必须小于总数据包大小减去固定的报头长度和填充。
o The length of the packet must be consistent with CC and payload type (if payloads have a known length).
o 数据包的长度必须与CC和有效负载类型一致（如果有效负载具有已知长度）。
The last three checks are somewhat complex and not always possible, leaving only the first two which total just a few bits. If the SSRC identifier in the packet is one that has been received before, then the packet is probably valid and checking if the sequence number is in the expected range provides further validation. If the SSRC identifier has not been seen before, then data packets carrying that identifier may be considered invalid until a small number of them arrive with consecutive sequence numbers. Those invalid packets MAY be discarded or they MAY be stored and delivered once validation has been achieved if the resulting delay is acceptable.
最后三个检查有点复杂，并不总是可能的，只剩下前两个，总共只有几位。如果数据包中的SSRC标识符是以前收到过的标识符，那么数据包可能是有效的，检查序列号是否在预期范围内提供了进一步的验证。如果之前没有看到SSRC标识符，则携带该标识符的数据包可能被视为无效，直到其中一小部分带有连续序列号到达。如果产生的延迟是可接受的，则一旦实现验证，这些无效数据包可能会被丢弃，或者它们可能会被存储和交付。
The routine update_seq shown below ensures that a source is declared valid only after MIN_SEQUENTIAL packets have been received in sequence. It also validates the sequence number seq of a newly received packet and updates the sequence state for the packet's source in the structure to which s points.
下面显示的例行更新程序确保只有在按顺序接收到最小顺序数据包后，源才被声明为有效。它还验证新接收的数据包的序列号seq，并在s指向的结构中更新数据包源的序列状态。
When a new source is heard for the first time, that is, its SSRC identifier is not in the table (see Section 8.2), and the per-source state is allocated for it, s->probation is set to the number of sequential packets required before declaring a source valid (parameter MIN_SEQUENTIAL) and other variables are initialized:
当第一次听到新源时，即其SSRC标识符不在表中（见第8.2节），并且为其分配了每个源状态，s->Permission设置为声明源有效之前所需的连续数据包数（参数MIN_sequential），并初始化其他变量：
init_seq(s, seq);
s->max_seq = seq - 1;
s->probation = MIN_SEQUENTIAL;
init_seq(s, seq);
s->max_seq = seq - 1;
s->probation = MIN_SEQUENTIAL;
A non-zero s->probation marks the source as not yet valid so the state may be discarded after a short timeout rather than a long one, as discussed in Section 6.2.1.
如第6.2.1节所述，非零s->试用将源标记为无效，因此在短时间超时后，而不是长时间超时后，状态可能会被丢弃。
After a source is considered valid, the sequence number is considered valid if it is no more than MAX_DROPOUT ahead of s->max_seq nor more than MAX_MISORDER behind. If the new sequence number is ahead of max_seq modulo the RTP sequence number range (16 bits), but is smaller than max_seq, it has wrapped around and the (shifted) count of sequence number cycles is incremented. A value of one is returned to indicate a valid sequence number.
在源被视为有效后，如果序列号不超过s->MAX_seq前面的MAX_DROPOUT，也不超过s->MAX_seq后面的MAX_Misord，则序列号被视为有效。如果新序列号在RTP序列号范围（16位）的max_seq模之前，但小于max_seq，则新序列号已环绕，且序列号周期的（移位）计数递增。返回值1以指示有效的序列号。
Otherwise, the value zero is returned to indicate that the validation failed, and the bad sequence number plus 1 is stored. If the next packet received carries the next higher sequence number, it is considered the valid start of a new packet sequence presumably caused by an extended dropout or a source restart. Since multiple complete sequence number cycles may have been missed, the packet loss statistics are reset.
否则，返回值0表示验证失败，并存储错误序列号加1。如果接收到的下一个数据包带有下一个更高的序列号，则它被认为是新数据包序列的有效开始，可能是由扩展的丢失或源重新启动引起的。由于可能错过了多个完整的序列号周期，因此分组丢失统计被重置。
Typical values for the parameters are shown, based on a maximum misordering time of 2 seconds at 50 packets/second and a maximum dropout of 1 minute. The dropout parameter MAX_DROPOUT should be a small fraction of the 16-bit sequence number space to give a reasonable probability that new sequence numbers after a restart will not fall in the acceptable range for sequence numbers from before the restart.
所示参数的典型值基于50个数据包/秒的最大误序时间2秒和最大丢失时间1分钟。辍学参数MAX_dropout应该是16位序列号空间的一小部分，以提供一个合理的概率，即重新启动后的新序列号不会在重新启动前的序列号的可接受范围内。
void init_seq(source *s, u_int16 seq)
{
s->base_seq = seq;
s->max_seq = seq;
s->bad_seq = RTP_SEQ_MOD + 1; /* so seq == bad_seq is false */
s->cycles = 0;
s->received = 0;
s->received_prior = 0;
s->expected_prior = 0;
/* other initialization */
}
void init_seq(source *s, u_int16 seq)
{
s->base_seq = seq;
s->max_seq = seq;
s->bad_seq = RTP_SEQ_MOD + 1; /* so seq == bad_seq is false */
s->cycles = 0;
s->received = 0;
s->received_prior = 0;
s->expected_prior = 0;
/* other initialization */
}
int update_seq(source *s, u_int16 seq)
{
u_int16 udelta = seq - s->max_seq;
const int MAX_DROPOUT = 3000;
const int MAX_MISORDER = 100;
const int MIN_SEQUENTIAL = 2;
int update_seq(source *s, u_int16 seq)
{
u_int16 udelta = seq - s->max_seq;
const int MAX_DROPOUT = 3000;
const int MAX_MISORDER = 100;
const int MIN_SEQUENTIAL = 2;
/*
* Source is not valid until MIN_SEQUENTIAL packets with
* sequential sequence numbers have been received.
*/
if (s->probation) {
/* packet is in sequence */
if (seq == s->max_seq + 1) {
s->probation--;
s->max_seq = seq;
if (s->probation == 0) {
init_seq(s, seq);
s->received++;
return 1;
/*
* Source is not valid until MIN_SEQUENTIAL packets with
* sequential sequence numbers have been received.
*/
if (s->probation) {
/* packet is in sequence */
if (seq == s->max_seq + 1) {
s->probation--;
s->max_seq = seq;
if (s->probation == 0) {
init_seq(s, seq);
s->received++;
return 1;
}
} else {
s->probation = MIN_SEQUENTIAL - 1;
s->max_seq = seq;
}
return 0;
} else if (udelta < MAX_DROPOUT) {
/* in order, with permissible gap */
if (seq < s->max_seq) {
/*
* Sequence number wrapped - count another 64K cycle.
*/
s->cycles += RTP_SEQ_MOD;
}
s->max_seq = seq;
} else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) {
/* the sequence number made a very large jump */
if (seq == s->bad_seq) {
/*
* Two sequential packets -- assume that the other side
* restarted without telling us so just re-sync
* (i.e., pretend this was the first packet).
*/
init_seq(s, seq);
}
else {
s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1);
return 0;
}
} else {
/* duplicate or reordered packet */
}
s->received++;
return 1;
}
}
} else {
s->probation = MIN_SEQUENTIAL - 1;
s->max_seq = seq;
}
return 0;
} else if (udelta < MAX_DROPOUT) {
/* in order, with permissible gap */
if (seq < s->max_seq) {
/*
* Sequence number wrapped - count another 64K cycle.
*/
s->cycles += RTP_SEQ_MOD;
}
s->max_seq = seq;
} else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) {
/* the sequence number made a very large jump */
if (seq == s->bad_seq) {
/*
* Two sequential packets -- assume that the other side
* restarted without telling us so just re-sync
* (i.e., pretend this was the first packet).
*/
init_seq(s, seq);
}
else {
s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1);
return 0;
}
} else {
/* duplicate or reordered packet */
}
s->received++;
return 1;
}
The validity check can be made stronger requiring more than two packets in sequence. The disadvantages are that a larger number of initial packets will be discarded (or delayed in a queue) and that high packet loss rates could prevent validation. However, because the RTCP header validation is relatively strong, if an RTCP packet is received from a source before the data packets, the count could be adjusted so that only two packets are required in sequence. If initial data loss for a few seconds can be tolerated, an application MAY choose to discard all data packets from a source until a valid RTCP packet has been received from that source.
有效性检查需要两个以上的数据包按顺序进行。缺点是，大量初始数据包将被丢弃（或在队列中延迟），并且高数据包丢失率可能会阻止验证。但是，由于RTCP报头验证相对较强，如果在数据包之前从源接收到RTCP包，则可以调整计数，以便只需要按顺序接收两个包。如果可以容忍初始数据丢失几秒钟，则应用程序可以选择丢弃来自某个源的所有数据包，直到从该源接收到有效的RTCP数据包。
Depending on the application and encoding, algorithms may exploit additional knowledge about the payload format for further validation. For payload types where the timestamp increment is the same for all packets, the timestamp values can be predicted from the previous packet received from the same source using the sequence number difference (assuming no change in payload type).
根据应用程序和编码，算法可以利用有关有效负载格式的额外知识进行进一步验证。对于所有数据包的时间戳增量相同的有效负载类型，可以使用序列号差异（假设有效负载类型没有变化）从从同一源接收的前一个数据包预测时间戳值。
A strong "fast-path" check is possible since with high probability the first four octets in the header of a newly received RTP data packet will be just the same as that of the previous packet from the same SSRC except that the sequence number will have increased by one. Similarly, a single-entry cache may be used for faster SSRC lookups in applications where data is typically received from one source at a time.
强“快速路径”检查是可能的，因为新接收的RTP数据包报头中的前四个八位字节很有可能与来自同一SSRC的前一个数据包的头四个八位字节相同，只是序列号增加了一个。类似地，在通常一次从一个源接收数据的应用程序中，单条目缓存可用于更快的SSRC查找。
The following checks should be applied to RTCP packets.
以下检查应适用于RTCP数据包。
o RTP version field must equal 2.
o RTP版本字段必须等于2。
o The payload type field of the first RTCP packet in a compound packet must be equal to SR or RR.
o 复合数据包中第一个RTCP数据包的有效负载类型字段必须等于SR或RR。
o The padding bit (P) should be zero for the first packet of a compound RTCP packet because padding should only be applied, if it is needed, to the last packet.
o 对于复合RTCP数据包的第一个数据包，填充位（P）应为零，因为填充只应在需要时应用于最后一个数据包。
o The length fields of the individual RTCP packets must add up to the overall length of the compound RTCP packet as received. This is a fairly strong check.
o 单个RTCP数据包的长度字段必须与接收到的复合RTCP数据包的总长度相加。这是一张相当有力的支票。
The code fragment below performs all of these checks. The packet type is not checked for subsequent packets since unknown packet types may be present and should be ignored.
下面的代码片段执行所有这些检查。由于可能存在未知的数据包类型，因此不检查后续数据包的数据包类型，因此应忽略该数据包类型。
u_int32 len; /* length of compound RTCP packet in words */
rtcp_t *r; /* RTCP header */
rtcp_t *end; /* end of compound RTCP packet */
u_int32 len; /* length of compound RTCP packet in words */
rtcp_t *r; /* RTCP header */
rtcp_t *end; /* end of compound RTCP packet */
if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {
/* something wrong with packet format */
}
end = (rtcp_t *)((u_int32 *)r + len);
if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {
/* something wrong with packet format */
}
end = (rtcp_t *)((u_int32 *)r + len);
do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1);
while (r < end && r->common.version == 2);
do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1);
while (r < end && r->common.version == 2);
if (r != end) {
/* something wrong with packet format */
}
if (r != end) {
/* something wrong with packet format */
}
In order to compute packet loss rates, the number of RTP packets expected and actually received from each source needs to be known, using per-source state information defined in struct source referenced via pointer s in the code below. The number of packets received is simply the count of packets as they arrive, including any late or duplicate packets. The number of packets expected can be computed by the receiver as the difference between the highest sequence number received (s->max_seq) and the first sequence number received (s->base_seq). Since the sequence number is only 16 bits and will wrap around, it is necessary to extend the highest sequence number with the (shifted) count of sequence number wraparounds (s->cycles). Both the received packet count and the count of cycles are maintained the RTP header validity check routine in Appendix A.1.
为了计算数据包丢失率，需要使用下面代码中通过指针s引用的struct source中定义的每个源状态信息，知道从每个源预期和实际接收的RTP数据包的数量。接收的数据包数量只是数据包到达时的计数，包括任何延迟或重复的数据包。接收机可以将预期的数据包数计算为接收到的最高序列号（s->max_seq）和接收到的第一个序列号（s->base_seq）之间的差值。由于序列号仅为16位且将环绕，因此有必要使用序列号环绕（s->cycles）的（移位）计数扩展最高序列号。接收数据包计数和周期计数均由附录A.1中的RTP报头有效性检查例行程序进行维护。
extended_max = s->cycles + s->max_seq;
expected = extended_max - s->base_seq + 1;
extended_max = s->cycles + s->max_seq;
expected = extended_max - s->base_seq + 1;
The number of packets lost is defined to be the number of packets expected less the number of packets actually received:
丢失的数据包数定义为预期数据包数减去实际接收的数据包数：
lost = expected - s->received;
lost = expected - s->received;
Since this signed number is carried in 24 bits, it should be clamped at 0x7fffff for positive loss or 0x800000 for negative loss rather than wrapping around.
因为这个有符号的数字是以24位的形式携带的，所以对于正损耗，它应该被钳制在0x7fffff，对于负损耗，它应该被钳制在0x800000，而不是环绕。
The fraction of packets lost during the last reporting interval (since the previous SR or RR packet was sent) is calculated from differences in the expected and received packet counts across the interval, where expected_prior and received_prior are the values saved when the previous reception report was generated:
在上一个报告间隔期间（自上一个SR或RR数据包被发送以来）丢失的数据包分数是根据整个间隔内预期数据包计数和接收数据包计数的差异计算得出的，其中预期数据包计数和接收数据包计数是生成上一个接收报告时保存的值：
expected_interval = expected - s->expected_prior;
s->expected_prior = expected;
received_interval = s->received - s->received_prior;
s->received_prior = s->received;
lost_interval = expected_interval - received_interval;
if (expected_interval == 0 || lost_interval <= 0) fraction = 0;
else fraction = (lost_interval << 8) / expected_interval;
expected_interval = expected - s->expected_prior;
s->expected_prior = expected;
received_interval = s->received - s->received_prior;
s->received_prior = s->received;
lost_interval = expected_interval - received_interval;
if (expected_interval == 0 || lost_interval <= 0) fraction = 0;
else fraction = (lost_interval << 8) / expected_interval;
The resulting fraction is an 8-bit fixed point number with the binary point at the left edge.
得到的分数是一个8位固定点数，二进制点位于左边缘。
This function builds one SDES chunk into buffer b composed of argc items supplied in arrays type, value and length. It returns a pointer to the next available location within b.
此函数将一个SDES块构建到缓冲区b中，缓冲区b由以数组类型、值和长度提供的argc项组成。它返回指向b中下一个可用位置的指针。
char *rtp_write_sdes(char *b, u_int32 src, int argc,
rtcp_sdes_type_t type[], char *value[],
int length[])
{
rtcp_sdes_t *s = (rtcp_sdes_t *)b;
rtcp_sdes_item_t *rsp;
int i;
int len;
int pad;
char *rtp_write_sdes(char *b, u_int32 src, int argc,
rtcp_sdes_type_t type[], char *value[],
int length[])
{
rtcp_sdes_t *s = (rtcp_sdes_t *)b;
rtcp_sdes_item_t *rsp;
int i;
int len;
int pad;
/* SSRC header */
s->src = src;
rsp = &s->item[0];
/* SSRC header */
s->src = src;
rsp = &s->item[0];
/* SDES items */
for (i = 0; i < argc; i++) {
rsp->type = type[i];
len = length[i];
if (len > RTP_MAX_SDES) {
/* invalid length, may want to take other action */
len = RTP_MAX_SDES;
}
rsp->length = len;
memcpy(rsp->data, value[i], len);
rsp = (rtcp_sdes_item_t *)&rsp->data[len];
}
/* SDES items */
for (i = 0; i < argc; i++) {
rsp->type = type[i];
len = length[i];
if (len > RTP_MAX_SDES) {
/* invalid length, may want to take other action */
len = RTP_MAX_SDES;
}
rsp->length = len;
memcpy(rsp->data, value[i], len);
rsp = (rtcp_sdes_item_t *)&rsp->data[len];
}
/* terminate with end marker and pad to next 4-octet boundary */
len = ((char *) rsp) - b;
pad = 4 - (len & 0x3);
b = (char *) rsp;
while (pad--) *b++ = RTCP_SDES_END;
/* terminate with end marker and pad to next 4-octet boundary */
len = ((char *) rsp) - b;
pad = 4 - (len & 0x3);
b = (char *) rsp;
while (pad--) *b++ = RTCP_SDES_END;
return b;
}
return b;
}
This function parses an SDES packet, calling functions find_member() to find a pointer to the information for a session member given the SSRC identifier and member_sdes() to store the new SDES information for that member. This function expects a pointer to the header of the RTCP packet.
此函数解析SDES数据包，调用函数find_member（）查找指向给定SSRC标识符的会话成员信息的指针，并调用函数member_SDES（）存储该成员的新SDES信息。此函数需要指向RTCP数据包头的指针。
void rtp_read_sdes(rtcp_t *r)
{
int count = r->common.count;
rtcp_sdes_t *sd = &r->r.sdes;
rtcp_sdes_item_t *rsp, *rspn;
rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)
((u_int32 *)r + r->common.length + 1);
source *s;
void rtp_read_sdes(rtcp_t *r)
{
int count = r->common.count;
rtcp_sdes_t *sd = &r->r.sdes;
rtcp_sdes_item_t *rsp, *rspn;
rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)
((u_int32 *)r + r->common.length + 1);
source *s;
while (--count >= 0) {
rsp = &sd->item[0];
if (rsp >= end) break;
s = find_member(sd->src);
while (--count >= 0) {
rsp = &sd->item[0];
if (rsp >= end) break;
s = find_member(sd->src);
for (; rsp->type; rsp = rspn ) {
rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2);
if (rspn >= end) {
rsp = rspn;
break;
}
member_sdes(s, rsp->type, rsp->data, rsp->length);
}
sd = (rtcp_sdes_t *)
((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);
}
if (count >= 0) {
/* invalid packet format */
}
}
for (; rsp->type; rsp = rspn ) {
rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2);
if (rspn >= end) {
rsp = rspn;
break;
}
member_sdes(s, rsp->type, rsp->data, rsp->length);
}
sd = (rtcp_sdes_t *)
((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);
}
if (count >= 0) {
/* invalid packet format */
}
}
The following subroutine generates a random 32-bit identifier using the MD5 routines published in RFC 1321 [32]. The system routines may not be present on all operating systems, but they should serve as hints as to what kinds of information may be used. Other system calls that may be appropriate include
以下子例程使用RFC 1321[32]中发布的MD5例程生成随机32位标识符。系统例程可能不会出现在所有操作系统上，但它们应该作为提示，说明可以使用哪些类型的信息。其他合适的系统调用包括
o getdomainname(),
o getdomainname（），
o getwd(), or
o getwd（），或
o getrusage().
o getrusage（）。
"Live" video or audio samples are also a good source of random numbers, but care must be taken to avoid using a turned-off microphone or blinded camera as a source [17].
“现场”视频或音频样本也是一个很好的随机数来源，但必须注意避免使用关闭的麦克风或盲摄像头作为来源[17]。
Use of this or a similar routine is recommended to generate the initial seed for the random number generator producing the RTCP period (as shown in Appendix A.7), to generate the initial values for the sequence number and timestamp, and to generate SSRC values. Since this routine is likely to be CPU-intensive, its direct use to generate RTCP periods is inappropriate because predictability is not an issue. Note that this routine produces the same result on repeated calls until the value of the system clock changes unless different values are supplied for the type argument.
建议使用此程序或类似程序为产生RTCP周期的随机数生成器生成初始种子（如附录a.7所示），为序列号和时间戳生成初始值，并生成SSRC值。由于此例程可能是CPU密集型的，因此直接使用它生成RTCP周期是不合适的，因为可预测性不是问题。请注意，除非为类型参数提供不同的值，否则此例程在重复调用时会产生相同的结果，直到系统时钟的值发生变化。
/*
* Generate a random 32-bit quantity.
*/
#include <sys/types.h> /* u_long */
#include <sys/time.h> /* gettimeofday() */
#include <unistd.h> /* get..() */
#include <stdio.h> /* printf() */
#include <time.h> /* clock() */
#include <sys/utsname.h> /* uname() */
#include "global.h" /* from RFC 1321 */
#include "md5.h" /* from RFC 1321 */
/*
* Generate a random 32-bit quantity.
*/
#include <sys/types.h> /* u_long */
#include <sys/time.h> /* gettimeofday() */
#include <unistd.h> /* get..() */
#include <stdio.h> /* printf() */
#include <time.h> /* clock() */
#include <sys/utsname.h> /* uname() */
#include "global.h" /* from RFC 1321 */
#include "md5.h" /* from RFC 1321 */
#define MD_CTX MD5_CTX #define MDInit MD5Init #define MDUpdate MD5Update #define MDFinal MD5Final
#定义MD_CTX MD5_CTX#定义MDInit MD5Init#定义MDUpdate MD5Update#定义MDFinal MD5Final
static u_long md_32(char *string, int length)
{
MD_CTX context;
union {
char c[16];
u_long x[4];
} digest;
u_long r;
int i;
static u_long md_32(char *string, int length)
{
MD_CTX context;
union {
char c[16];
u_long x[4];
} digest;
u_long r;
int i;
MDInit (&context);
MDInit（&上下文）；
MDUpdate (&context, string, length);
MDFinal ((unsigned char *)&digest, &context);
r = 0;
for (i = 0; i < 3; i++) {
r ^= digest.x[i];
}
return r;
} /* md_32 */
MDUpdate (&context, string, length);
MDFinal ((unsigned char *)&digest, &context);
r = 0;
for (i = 0; i < 3; i++) {
r ^= digest.x[i];
}
return r;
} /* md_32 */
/*
* Return random unsigned 32-bit quantity. Use 'type' argument if
* you need to generate several different values in close succession.
*/
u_int32 random32(int type)
{
struct {
int type;
struct timeval tv;
clock_t cpu;
pid_t pid;
u_long hid;
uid_t uid;
gid_t gid;
struct utsname name;
} s;
/*
* Return random unsigned 32-bit quantity. Use 'type' argument if
* you need to generate several different values in close succession.
*/
u_int32 random32(int type)
{
struct {
int type;
struct timeval tv;
clock_t cpu;
pid_t pid;
u_long hid;
uid_t uid;
gid_t gid;
struct utsname name;
} s;
gettimeofday(&s.tv, 0);
uname(&s.name);
s.type = type;
s.cpu = clock();
s.pid = getpid();
s.hid = gethostid();
s.uid = getuid();
s.gid = getgid();
/* also: system uptime */
gettimeofday(&s.tv, 0);
uname(&s.name);
s.type = type;
s.cpu = clock();
s.pid = getpid();
s.hid = gethostid();
s.uid = getuid();
s.gid = getgid();
/* also: system uptime */
return md_32((char *)&s, sizeof(s));
} /* random32 */
return md_32((char *)&s, sizeof(s));
} /* random32 */
The following functions implement the RTCP transmission and reception rules described in Section 6.2. These rules are coded in several functions:
以下功能实现第6.2节所述的RTCP传输和接收规则。这些规则在几个功能中编码：
o rtcp_interval() computes the deterministic calculated interval, measured in seconds. The parameters are defined in Section 6.3.
o rtcp_interval（）计算确定的计算间隔，以秒为单位。参数在第6.3节中定义。
o OnExpire() is called when the RTCP transmission timer expires.
o 当RTCP传输计时器过期时调用OnExpire（）。
o OnReceive() is called whenever an RTCP packet is received.
o 每当接收到RTCP数据包时，都会调用OnReceive（）。
Both OnExpire() and OnReceive() have event e as an argument. This is the next scheduled event for that participant, either an RTCP report or a BYE packet. It is assumed that the following functions are available:
OnExpire（）和OnReceive（）都将事件e作为参数。这是该参与者的下一个计划事件，RTCP报告或BYE数据包。假设以下功能可用：
o Schedule(time t, event e) schedules an event e to occur at time t. When time t arrives, the function OnExpire is called with e as an argument.
o 计划（时间t，事件e）计划事件e在时间t发生。当t到达时，函数OnExpire将以e作为参数调用。
o Reschedule(time t, event e) reschedules a previously scheduled event e for time t.
o 重新调度（时间t，事件e）将先前调度的事件e重新调度到时间t。
o SendRTCPReport(event e) sends an RTCP report.
o SendRTCPReport（事件e）发送RTCP报告。
o SendBYEPacket(event e) sends a BYE packet.
o SendBYEPacket（事件e）发送一个BYE数据包。
o TypeOfEvent(event e) returns EVENT_BYE if the event being processed is for a BYE packet to be sent, else it returns EVENT_REPORT.
o 如果正在处理的事件是为了发送BYE数据包，则TypeOfEvent（event e）返回event_BYE，否则返回event_REPORT。
o PacketType(p) returns PACKET_RTCP_REPORT if packet p is an RTCP report (not BYE), PACKET_BYE if its a BYE RTCP packet, and PACKET_RTP if its a regular RTP data packet.
o 如果数据包p是RTCP报告（非BYE），则PacketType（p）返回数据包RTCP报告；如果是BYE RTCP数据包，则返回数据包BYE；如果是常规RTP数据包，则返回数据包RTP。
o ReceivedPacketSize() and SentPacketSize() return the size of the referenced packet in octets.
o ReceivedPacketSize（）和SentPacketSize（）返回引用数据包的大小（以八位字节为单位）。
o NewMember(p) returns a 1 if the participant who sent packet p is not currently in the member list, 0 otherwise. Note this function is not sufficient for a complete implementation because each CSRC identifier in an RTP packet and each SSRC in a BYE packet should be processed.
o 如果发送数据包p的参与者当前不在成员列表中，则NewMember（p）返回1，否则返回0。注意：此功能不足以实现完整的实现，因为RTP数据包中的每个CSC标识符和BYE数据包中的每个SSRC都应进行处理。
o NewSender(p) returns a 1 if the participant who sent packet p is not currently in the sender sublist of the member list, 0 otherwise.
o 如果发送数据包p的参与者当前不在成员列表的发件人子列表中，则NewSender（p）返回1，否则返回0。
o AddMember() and RemoveMember() to add and remove participants from the member list.
o AddMember（）和RemoveMember（）可在成员列表中添加和删除参与者。
o AddSender() and RemoveSender() to add and remove participants from the sender sublist of the member list.
o AddSender（）和RemoveSender（）可在成员列表的发件人子列表中添加和删除参与者。
These functions would have to be extended for an implementation that allows the RTCP bandwidth fractions for senders and non-senders to be specified as explicit parameters rather than fixed values of 25% and 75%. The extended implementation of rtcp_interval() would need to avoid division by zero if one of the parameters was zero.
必须扩展这些功能，以实现允许将发送方和非发送方的RTCP带宽分数指定为显式参数，而不是25%和75%的固定值。如果其中一个参数为零，则rtcp_interval（）的扩展实现需要避免被零除。
double rtcp_interval(int members,
int senders,
double rtcp_bw,
int we_sent,
double avg_rtcp_size,
int initial)
{
/*
* Minimum average time between RTCP packets from this site (in
* seconds). This time prevents the reports from `clumping' when
* sessions are small and the law of large numbers isn't helping
* to smooth out the traffic. It also keeps the report interval
* from becoming ridiculously small during transient outages like
* a network partition.
*/
double const RTCP_MIN_TIME = 5.;
/*
* Fraction of the RTCP bandwidth to be shared among active
* senders. (This fraction was chosen so that in a typical
* session with one or two active senders, the computed report
* time would be roughly equal to the minimum report time so that
* we don't unnecessarily slow down receiver reports.) The
* receiver fraction must be 1 - the sender fraction.
*/
double const RTCP_SENDER_BW_FRACTION = 0.25;
double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);
/*
/* To compensate for "timer reconsideration" converging to a
* value below the intended average.
*/
double const COMPENSATION = 2.71828 - 1.5;
double rtcp_interval(int members,
int senders,
double rtcp_bw,
int we_sent,
double avg_rtcp_size,
int initial)
{
/*
* Minimum average time between RTCP packets from this site (in
* seconds). This time prevents the reports from `clumping' when
* sessions are small and the law of large numbers isn't helping
* to smooth out the traffic. It also keeps the report interval
* from becoming ridiculously small during transient outages like
* a network partition.
*/
double const RTCP_MIN_TIME = 5.;
/*
* Fraction of the RTCP bandwidth to be shared among active
* senders. (This fraction was chosen so that in a typical
* session with one or two active senders, the computed report
* time would be roughly equal to the minimum report time so that
* we don't unnecessarily slow down receiver reports.) The
* receiver fraction must be 1 - the sender fraction.
*/
double const RTCP_SENDER_BW_FRACTION = 0.25;
double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);
/*
/* To compensate for "timer reconsideration" converging to a
* value below the intended average.
*/
double const COMPENSATION = 2.71828 - 1.5;
double t; /* interval */
double rtcp_min_time = RTCP_MIN_TIME;
int n; /* no. of members for computation */
double t; /* interval */
double rtcp_min_time = RTCP_MIN_TIME;
int n; /* no. of members for computation */
/*
* Very first call at application start-up uses half the min
* delay for quicker notification while still allowing some time
* before reporting for randomization and to learn about other
* sources so the report interval will converge to the correct
* interval more quickly.
/*
* Very first call at application start-up uses half the min
* delay for quicker notification while still allowing some time
* before reporting for randomization and to learn about other
* sources so the report interval will converge to the correct
* interval more quickly.
*/
if (initial) {
rtcp_min_time /= 2;
}
/*
* Dedicate a fraction of the RTCP bandwidth to senders unless
* the number of senders is large enough that their share is
* more than that fraction.
*/
n = members;
if (senders <= members * RTCP_SENDER_BW_FRACTION) {
if (we_sent) {
rtcp_bw *= RTCP_SENDER_BW_FRACTION;
n = senders;
} else {
rtcp_bw *= RTCP_RCVR_BW_FRACTION;
n -= senders;
}
}
*/
if (initial) {
rtcp_min_time /= 2;
}
/*
* Dedicate a fraction of the RTCP bandwidth to senders unless
* the number of senders is large enough that their share is
* more than that fraction.
*/
n = members;
if (senders <= members * RTCP_SENDER_BW_FRACTION) {
if (we_sent) {
rtcp_bw *= RTCP_SENDER_BW_FRACTION;
n = senders;
} else {
rtcp_bw *= RTCP_RCVR_BW_FRACTION;
n -= senders;
}
}
/*
* The effective number of sites times the average packet size is
* the total number of octets sent when each site sends a report.
* Dividing this by the effective bandwidth gives the time
* interval over which those packets must be sent in order to
* meet the bandwidth target, with a minimum enforced. In that
* time interval we send one report so this time is also our
* average time between reports.
*/
t = avg_rtcp_size * n / rtcp_bw;
if (t < rtcp_min_time) t = rtcp_min_time;
/*
* The effective number of sites times the average packet size is
* the total number of octets sent when each site sends a report.
* Dividing this by the effective bandwidth gives the time
* interval over which those packets must be sent in order to
* meet the bandwidth target, with a minimum enforced. In that
* time interval we send one report so this time is also our
* average time between reports.
*/
t = avg_rtcp_size * n / rtcp_bw;
if (t < rtcp_min_time) t = rtcp_min_time;
/*
* To avoid traffic bursts from unintended synchronization with
* other sites, we then pick our actual next report interval as a
* random number uniformly distributed between 0.5*t and 1.5*t.
*/
t = t * (drand48() + 0.5);
t = t / COMPENSATION;
return t;
}
/*
* To avoid traffic bursts from unintended synchronization with
* other sites, we then pick our actual next report interval as a
* random number uniformly distributed between 0.5*t and 1.5*t.
*/
t = t * (drand48() + 0.5);
t = t / COMPENSATION;
return t;
}
void OnExpire(event e, int members, int senders, double rtcp_bw, int we_sent, double *avg_rtcp_size,
void OnExpire（事件e，int成员，int发送者，双rtcp\u bw，我们发送的int，双*平均rtcp\u大小，
int *initial,
time_tp tc,
time_tp *tp,
int *pmembers)
{
/* This function is responsible for deciding whether to send an
* RTCP report or BYE packet now, or to reschedule transmission.
* It is also responsible for updating the pmembers, initial, tp,
* and avg_rtcp_size state variables. This function should be
* called upon expiration of the event timer used by Schedule().
*/
int *initial,
time_tp tc,
time_tp *tp,
int *pmembers)
{
/* This function is responsible for deciding whether to send an
* RTCP report or BYE packet now, or to reschedule transmission.
* It is also responsible for updating the pmembers, initial, tp,
* and avg_rtcp_size state variables. This function should be
* called upon expiration of the event timer used by Schedule().
*/
double t; /* Interval */
double tn; /* Next transmit time */
double t; /* Interval */
double tn; /* Next transmit time */
/* In the case of a BYE, we use "timer reconsideration" to
* reschedule the transmission of the BYE if necessary */
/* In the case of a BYE, we use "timer reconsideration" to
* reschedule the transmission of the BYE if necessary */
if (TypeOfEvent(e) == EVENT_BYE) {
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
tn = *tp + t;
if (tn <= tc) {
SendBYEPacket(e);
exit(1);
} else {
Schedule(tn, e);
}
if (TypeOfEvent(e) == EVENT_BYE) {
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
tn = *tp + t;
if (tn <= tc) {
SendBYEPacket(e);
exit(1);
} else {
Schedule(tn, e);
}
} else if (TypeOfEvent(e) == EVENT_REPORT) {
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
tn = *tp + t;
if (tn <= tc) {
SendRTCPReport(e);
*avg_rtcp_size = (1./16.)*SentPacketSize(e) +
(15./16.)*(*avg_rtcp_size);
*tp = tc;
} else if (TypeOfEvent(e) == EVENT_REPORT) {
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
tn = *tp + t;
if (tn <= tc) {
SendRTCPReport(e);
*avg_rtcp_size = (1./16.)*SentPacketSize(e) +
(15./16.)*(*avg_rtcp_size);
*tp = tc;
/* We must redraw the interval. Don't reuse the
/* We must redraw the interval. Don't reuse the
one computed above, since its not actually
distributed the same, as we are conditioned
on it being small enough to cause a packet to
be sent */
one computed above, since its not actually
distributed the same, as we are conditioned
on it being small enough to cause a packet to
be sent */
t = rtcp_interval(members, senders, rtcp_bw, we_sent, *avg_rtcp_size, *initial);
t=rtcp_间隔（成员、发送方、rtcp_bw、我们发送，*平均rtcp_大小，*初始值）；
Schedule(t+tc,e);
*initial = 0;
} else {
Schedule(tn, e);
}
*pmembers = members;
}
}
Schedule(t+tc,e);
*initial = 0;
} else {
Schedule(tn, e);
}
*pmembers = members;
}
}
void OnReceive(packet p,
event e,
int *members,
int *pmembers,
int *senders,
double *avg_rtcp_size,
double *tp,
double tc,
double tn)
{
/* What we do depends on whether we have left the group, and are
* waiting to send a BYE (TypeOfEvent(e) == EVENT_BYE) or an RTCP
* report. p represents the packet that was just received. */
void OnReceive(packet p,
event e,
int *members,
int *pmembers,
int *senders,
double *avg_rtcp_size,
double *tp,
double tc,
double tn)
{
/* What we do depends on whether we have left the group, and are
* waiting to send a BYE (TypeOfEvent(e) == EVENT_BYE) or an RTCP
* report. p represents the packet that was just received. */
if (PacketType(p) == PACKET_RTCP_REPORT) {
if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddMember(p);
*members += 1;
}
*avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
(15./16.)*(*avg_rtcp_size);
} else if (PacketType(p) == PACKET_RTP) {
if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddMember(p);
*members += 1;
}
if (NewSender(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
if (PacketType(p) == PACKET_RTCP_REPORT) {
if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddMember(p);
*members += 1;
}
*avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
(15./16.)*(*avg_rtcp_size);
} else if (PacketType(p) == PACKET_RTP) {
if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddMember(p);
*members += 1;
}
if (NewSender(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddSender(p);
*senders += 1;
}
} else if (PacketType(p) == PACKET_BYE) {
*avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
(15./16.)*(*avg_rtcp_size);
AddSender(p);
*senders += 1;
}
} else if (PacketType(p) == PACKET_BYE) {
*avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
(15./16.)*(*avg_rtcp_size);
if (TypeOfEvent(e) == EVENT_REPORT) {
if (NewSender(p) == FALSE) {
RemoveSender(p);
*senders -= 1;
}
if (TypeOfEvent(e) == EVENT_REPORT) {
if (NewSender(p) == FALSE) {
RemoveSender(p);
*senders -= 1;
}
if (NewMember(p) == FALSE) {
RemoveMember(p);
*members -= 1;
}
if (NewMember(p) == FALSE) {
RemoveMember(p);
*members -= 1;
}
if (*members < *pmembers) {
tn = tc +
(((double) *members)/(*pmembers))*(tn - tc);
*tp = tc -
(((double) *members)/(*pmembers))*(tc - *tp);
if (*members < *pmembers) {
tn = tc +
(((double) *members)/(*pmembers))*(tn - tc);
*tp = tc -
(((double) *members)/(*pmembers))*(tc - *tp);
/* Reschedule the next report for time tn */
/* Reschedule the next report for time tn */
Reschedule(tn, e);
*pmembers = *members;
}
Reschedule(tn, e);
*pmembers = *members;
}
} else if (TypeOfEvent(e) == EVENT_BYE) {
*members += 1;
}
}
}
} else if (TypeOfEvent(e) == EVENT_BYE) {
*members += 1;
}
}
}
The code fragments below implement the algorithm given in Section 6.4.1 for calculating an estimate of the statistical variance of the RTP data interarrival time to be inserted in the interarrival jitter field of reception reports. The inputs are r->ts, the timestamp from the incoming packet, and arrival, the current time in the same units. Here s points to state for the source; s->transit holds the relative transit time for the previous packet, and s->jitter holds the estimated jitter. The jitter field of the reception report is measured in timestamp units and expressed as an unsigned integer, but the jitter estimate is kept in a floating point. As each data packet arrives, the jitter estimate is updated:
下面的代码片段实现第6.4.1节中给出的算法，用于计算要插入接收报告的到达间抖动字段中的RTP数据到达间时间的统计方差估计值。输入是r->ts，来自传入数据包的时间戳，以及到达，以相同单位表示的当前时间。这里是指向源状态的点；s->transit保存前一个数据包的相对传输时间，s->jitter保存估计的抖动。接收报告的抖动字段以时间戳单位测量，并表示为无符号整数，但抖动估计值保留在浮点中。当每个数据包到达时，抖动估计值更新：
int transit = arrival - r->ts;
int d = transit - s->transit;
s->transit = transit;
if (d < 0) d = -d;
s->jitter += (1./16.) * ((double)d - s->jitter);
int transit = arrival - r->ts;
int d = transit - s->transit;
s->transit = transit;
if (d < 0) d = -d;
s->jitter += (1./16.) * ((double)d - s->jitter);
When a reception report block (to which rr points) is generated for this member, the current jitter estimate is returned:
当为该成员生成接收报告块（rr点）时，返回当前抖动估计值：
rr->jitter = (u_int32) s->jitter;
rr->jitter = (u_int32) s->jitter;
Alternatively, the jitter estimate can be kept as an integer, but scaled to reduce round-off error. The calculation is the same except for the last line:
或者，抖动估计可以保持为整数，但可以缩放以减少舍入误差。除最后一行外，计算结果相同：
s->jitter += d - ((s->jitter + 8) >> 4);
s->jitter += d - ((s->jitter + 8) >> 4);
In this case, the estimate is sampled for the reception report as:
在这种情况下，对接收报告的估计进行采样，如下所示：
rr->jitter = s->jitter >> 4;
rr->jitter = s->jitter >> 4;
Appendix B - Changes from RFC 1889
附录B-RFC 1889的变更
Most of this RFC is identical to RFC 1889. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets:
大多数RFC与RFC1889相同。网络上的数据包格式没有变化，只是控制协议使用方式的规则和算法发生了变化。最大的变化是对用于计算何时发送RTCP数据包的可伸缩计时器算法的增强：
o The algorithm for calculating the RTCP transmission interval specified in Sections 6.2 and 6.3 and illustrated in Appendix A.7 is augmented to include "reconsideration" to minimize transmission in excess of the intended rate when many participants join a session simultaneously, and "reverse reconsideration" to reduce the incidence and duration of false participant timeouts when the number of participants drops rapidly. Reverse reconsideration is also used to possibly shorten the delay before sending RTCP SR when transitioning from passive receiver to active sender mode.
o 第6.2节和第6.3节中规定并在附录A.7中说明的计算RTCP传输间隔的算法得到了扩展，包括“重新考虑”，以在多个参与者同时加入会话时，将超过预期速率的传输最小化，以及“反向重新考虑”当参与者人数迅速下降时，减少错误参与者超时的发生率和持续时间。当从被动接收器转换到主动发送器模式时，反向重新考虑也用于可能缩短发送RTCP SR之前的延迟。
o Section 6.3.7 specifies new rules controlling when an RTCP BYE packet should be sent in order to avoid a flood of packets when many participants leave a session simultaneously.
o 第6.3.7节规定了控制何时应发送RTCP BYE数据包的新规则，以避免当许多参与者同时离开会话时出现数据包泛滥。
o The requirement to retain state for inactive participants for a period long enough to span typical network partitions was removed from Section 6.2.1. In a session where many participants join for a brief time and fail to send BYE, this requirement would cause a significant overestimate of the number of participants. The reconsideration algorithm added in this revision compensates for the large number of new participants joining simultaneously when a partition heals.
o 第6.2.1节删除了将非活动参与者的状态保留足够长的时间以跨越典型网络分区的要求。在一个有许多参与者加入的会话中，如果有一段时间没有发送“再见”，那么这一要求将导致对参与者数量的高估。此修订中添加的重新考虑算法补偿了分区修复时同时加入的大量新参与者。
It should be noted that these enhancements only have a significant effect when the number of session participants is large (thousands) and most of the participants join or leave at the same time. This makes testing in a live network difficult. However, the algorithm was subjected to a thorough analysis and simulation to verify its performance. Furthermore, the enhanced algorithm was designed to interoperate with the algorithm in RFC 1889 such that the degree of reduction in excess RTCP bandwidth during a step join is proportional to the fraction of participants that implement the enhanced algorithm. Interoperation of the two algorithms has been verified experimentally on live networks.
应该注意的是，只有当会话参与者的数量很大（数千）且大多数参与者同时加入或离开时，这些增强才会产生显著效果。这使得在实时网络中进行测试变得困难。然而，对该算法进行了深入的分析和仿真，以验证其性能。此外，增强算法的设计目的是与RFC 1889中的算法进行互操作，从而使阶跃连接期间多余RTCP带宽的减少程度与实施增强算法的参与者比例成正比。两种算法的互操作性已经在实时网络上进行了实验验证。
Other functional changes were:
其他功能变化包括：
o Section 6.2.1 specifies that implementations may store only a sampling of the participants' SSRC identifiers to allow scaling to very large sessions. Algorithms are specified in RFC 2762 [21].
o 第6.2.1节规定，实现可能只存储参与者SSRC标识符的样本，以允许扩展到非常大的会话。RFC 2762[21]中规定了算法。
o In Section 6.2 it is specified that RTCP sender and non-sender bandwidths may be set as separate parameters of the session rather than a strict percentage of the session bandwidth, and may be set to zero. The requirement that RTCP was mandatory for RTP sessions using IP multicast was relaxed. However, a clarification was also added that turning off RTCP is NOT RECOMMENDED.
o 第6.2节规定，RTCP发送方和非发送方带宽可设置为会话的单独参数，而不是会话带宽的严格百分比，并可设置为零。对于使用IP多播的RTP会话，RTCP是强制性的要求已经放宽。然而，还补充了一项澄清，即不建议关闭RTCP。
o In Sections 6.2, 6.3.1 and Appendix A.7, it is specified that the fraction of participants below which senders get dedicated RTCP bandwidth changes from the fixed 1/4 to a ratio based on the RTCP sender and non-sender bandwidth parameters when those are given. The condition that no bandwidth is dedicated to senders when there are no senders was removed since that is expected to be a transitory state. It also keeps non-senders from using sender RTCP bandwidth when that is not intended.
o 在第6.2节、第6.3.1节和附录A.7中，规定发送方获得专用RTCP带宽的参与者比例从固定的1/4变为基于RTCP发送方和非发送方带宽参数的比例（如果给定）。当没有发送方时，没有带宽专用于发送方的情况被删除，因为这是一种过渡状态。它还防止非发送方在非预期情况下使用发送方RTCP带宽。
o Also in Section 6.2 it is specified that the minimum RTCP interval may be scaled to smaller values for high bandwidth sessions, and that the initial RTCP delay may be set to zero for unicast sessions.
o 第6.2节还规定，对于高带宽会话，最小RTCP间隔可缩放为较小值，对于单播会话，初始RTCP延迟可设置为零。
o Timing out a participant is to be based on inactivity for a number of RTCP report intervals calculated using the receiver RTCP bandwidth fraction even for active senders.
o 参与者的超时将基于使用接收器RTCP带宽分数计算的多个RTCP报告间隔的非活动性，即使对于活动发送者也是如此。
o Sections 7.2 and 7.3 specify that translators and mixers should send BYE packets for the sources they are no longer forwarding.
o 第7.2节和第7.3节规定，翻译器和混音器应为不再转发的源发送BYE数据包。
o Rule changes for layered encodings are defined in Sections 2.4, 6.3.9, 8.3 and 11. In the last of these, it is noted that the address and port assignment rule conflicts with the SDP specification, RFC 2327 [15], but it is intended that this restriction will be relaxed in a revision of RFC 2327.
o 第2.4节、第6.3.9节、第8.3节和第11节定义了分层编码的规则更改。在最后一部分中，需要注意的是，地址和端口分配规则与SDP规范RFC 2327[15]冲突，但在RFC 2327的修订版中，这一限制将被放宽。
o The convention for using even/odd port pairs for RTP and RTCP in Section 11 was clarified to refer to destination ports. The requirement to use an even/odd port pair was removed if the two ports are specified explicitly. For unicast RTP sessions, distinct port pairs may be used for the two ends (Sections 3, 7.1 and 11).
o 第11节对RTP和RTCP使用偶数/奇数端口对的约定进行了澄清，以参考目标端口。如果明确指定了两个端口，则取消了使用偶数/奇数端口对的要求。对于单播RTP会话，两端可以使用不同的端口对（第3、7.1和11节）。
o A new Section 10 was added to explain the requirement for congestion control in applications using RTP.
o 增加了新的第10节，以解释使用RTP的应用中的拥塞控制要求。
o In Section 8.2, the requirement that a new SSRC identifier MUST be chosen whenever the source transport address is changed has been relaxed to say that a new SSRC identifier MAY be chosen. Correspondingly, it was clarified that an implementation MAY
o 在第8.2节中，当源传输地址改变时，必须选择新的SSRC标识符的要求已经放宽，即可以选择新的SSRC标识符。相应地，有人澄清说，实施可能会
choose to keep packets from the new source address rather than the existing source address when an SSRC collision occurs between two other participants, and SHOULD do so for applications such as telephony in which some sources such as mobile entities may change addresses during the course of an RTP session.
当其他两个参与者之间发生SSRC冲突时，选择保留来自新源地址而不是现有源地址的数据包，并且对于某些源（如移动实体）可能在RTP会话过程中更改地址的应用程序（如电话）应这样做。
o An indentation bug in the RFC 1889 printing of the pseudo-code for the collision detection and resolution algorithm in Section 8.2 has been corrected by translating the syntax to pseudo C language, and the algorithm has been modified to remove the restriction that both RTP and RTCP must be sent from the same source port number.
o 通过将语法转换为伪C语言，纠正了RFC 1889打印第8.2节中冲突检测和解决算法伪代码时出现的缩进错误，并对算法进行了修改，以消除RTP和RTCP必须从同一源端口号发送的限制。
o The description of the padding mechanism for RTCP packets was clarified and it is specified that padding MUST only be applied to the last packet of a compound RTCP packet.
o 对RTCP数据包填充机制的描述进行了澄清，并规定填充只能应用于复合RTCP数据包的最后一个数据包。
o In Section A.1, initialization of base_seq was corrected to be seq rather than seq - 1, and the text was corrected to say the bad sequence number plus 1 is stored. The initialization of max_seq and other variables for the algorithm was separated from the text to make clear that this initialization must be done in addition to calling the init_seq() function (and a few words lost in RFC 1889 when processing the document from source to output form were restored).
o 在A.1节中，基本顺序的初始化被更正为seq而不是seq-1，并且文本被更正为表示存储了错误的序列号加1。算法的max_seq和其他变量的初始化从文本中分离出来，以明确除了调用init_seq（）函数外，还必须进行此初始化（并且恢复了RFC 1889从源到输出表单处理文档时丢失的一些单词）。
o Clamping of number of packets lost in Section A.3 was corrected to use both positive and negative limits.
o 第A.3节中丢失的数据包数的钳制已更正为使用正限值和负限值。
o The specification of "relative" NTP timestamp in the RTCP SR section now defines these timestamps to be based on the most common system-specific clock, such as system uptime, rather than on session elapsed time which would not be the same for multiple applications started on the same machine at different times.
o RTCP SR部分中的“相对”NTP时间戳规范现在将这些时间戳定义为基于最常见的系统特定时钟，如系统正常运行时间，而不是基于会话运行时间，这对于在不同时间在同一台机器上启动的多个应用程序来说是不同的。
Non-functional changes:
非功能性变化：
o It is specified that a receiver MUST ignore packets with payload types it does not understand.
o 指定接收器必须忽略其不了解的有效负载类型的数据包。
o In Fig. 2, the floating point NTP timestamp value was corrected, some missing leading zeros were added in a hex number, and the UTC timezone was specified.
o 在图2中，对浮点NTP时间戳值进行了校正，在十六进制数中添加了一些缺失的前导零，并指定了UTC时区。
o The inconsequence of NTP timestamps wrapping around in the year 2036 is explained.
o NTP时间戳在2036年前后的不一致性得到了解释。
o The policy for registration of RTCP packet types and SDES types was clarified in a new Section 15, IANA Considerations. The suggestion that experimenters register the numbers they need and then unregister those which prove to be unneeded has been removed in favor of using APP and PRIV. Registration of profile names was also specified.
o RTCP数据包类型和SDES类型的注册政策在新的第15节IANA注意事项中进行了澄清。建议实验者注册他们需要的号码，然后注销那些被证明不需要的号码，这一建议已被删除，取而代之的是使用APP和PRIV。还规定了档案名称的注册。
o The reference for the UTF-8 character set was changed from an X/Open Preliminary Specification to be RFC 2279.
o UTF-8字符集的参考从X/Open初步规范更改为RFC 2279。
o The reference for RFC 1597 was updated to RFC 1918 and the reference for RFC 2543 was updated to RFC 3261.
o RFC 1597的参考更新为RFC 1918，RFC 2543的参考更新为RFC 3261。
o The last paragraph of the introduction in RFC 1889, which cautioned implementors to limit deployment in the Internet, was removed because it was deemed no longer relevant.
o RFC1889中引言的最后一段警告实施者限制在互联网上的部署，因为它被认为不再相关而被删除。
o A non-normative note regarding the use of RTP with Source-Specific Multicast (SSM) was added in Section 6.
o 第6节增加了关于RTP与源特定多播（SSM）的使用的非规范性说明。
o The definition of "RTP session" in Section 3 was expanded to acknowledge that a single session may use multiple destination transport addresses (as was always the case for a translator or mixer) and to explain that the distinguishing feature of an RTP session is that each corresponds to a separate SSRC identifier space. A new definition of "multimedia session" was added to reduce confusion about the word "session".
o 第3节中“RTP会话”的定义进行了扩展，以确认单个会话可以使用多个目的地传输地址（对于转换器或混音器来说总是如此），并解释RTP会话的区别特征是每个会话对应一个单独的SSRC标识符空间。增加了“多媒体会话”的新定义，以减少对“会话”一词的混淆。
o The meaning of "sampling instant" was explained in more detail as part of the definition of the timestamp field of the RTP header in Section 5.1.
o 作为第5.1节RTP报头时间戳字段定义的一部分，对“采样瞬间”的含义进行了更详细的解释。
o Small clarifications of the text have been made in several places, some in response to questions from readers. In particular:
o 一些地方对文本作了一些小的澄清，有些地方是为了回答读者的问题。特别地：
- In RFC 1889, the first five words of the second sentence of Section 2.2 were lost in processing the document from source to output form, but are now restored.
- 在RFC 1889中，第2.2节第二句的前五个单词在从源到输出形式的文档处理过程中丢失，但现在已恢复。
- A definition for "RTP media type" was added in Section 3 to allow the explanation of multiplexing RTP sessions in Section 5.2 to be more clear regarding the multiplexing of multiple media. That section also now explains that multiplexing multiple sources of the same medium based on SSRC identifiers may be appropriate and is the norm for multicast sessions.
- 第3节中增加了“RTP介质类型”的定义，以便更清楚地解释第5.2节中关于多路复用RTP会话的内容。该部分现在还解释了基于SSRC标识符复用同一介质的多个源可能是合适的，并且是多播会话的标准。
- The definition for "non-RTP means" was expanded to include examples of other protocols constituting non-RTP means.
- 对“非RTP方式”的定义进行了扩展，以包括构成非RTP方式的其他协议的示例。
- The description of the session bandwidth parameter is expanded in Section 6.2, including a clarification that the control traffic bandwidth is in addition to the session bandwidth for the data traffic.
- 会话带宽参数的描述在第6.2节中进行了扩展，包括说明控制通信带宽是对数据通信的会话带宽的补充。
- The effect of varying packet duration on the jitter calculation was explained in Section 6.4.4.
- 第6.4.4节解释了不同数据包持续时间对抖动计算的影响。
- The method for terminating and padding a sequence of SDES items was clarified in Section 6.5.
- 第6.5节阐明了终止和填充SDES项目序列的方法。
- IPv6 address examples were added in the description of SDES CNAME in Section 6.5.1, and "example.com" was used in place of other example domain names.
- 第6.5.1节SDES CNAME的描述中添加了IPv6地址示例，并使用“example.com”代替其他示例域名。
- The Security section added a formal reference to IPSEC now that it is available, and says that the confidentiality method defined in this specification is primarily to codify existing practice. It is RECOMMENDED that stronger encryption algorithms such as Triple-DES be used in place of the default algorithm, and noted that the SRTP profile based on AES will be the correct choice in the future. A caution about the weakness of the RTP header as an initialization vector was added. It was also noted that payload-only encryption is necessary to allow for header compression.
- 安全部分添加了对IPSEC的正式引用，现在IPSEC已经可用，并表示本规范中定义的保密方法主要是对现有实践进行编码。建议使用更强大的加密算法（如三重DES）代替默认算法，并注意到基于AES的SRTP配置文件将是未来的正确选择。添加了关于RTP头作为初始化向量的弱点的警告。还有人指出，只有有效负载加密才有必要允许报头压缩。
- The method for partial encryption of RTCP was clarified; in particular, SDES CNAME is carried in only one part when the compound RTCP packet is split.
- 阐明了RTCP部分加密的方法；特别是，当复合RTCP数据包被拆分时，SDES CNAME仅在一个部分中携带。
- It is clarified that only one compound RTCP packet should be sent per reporting interval and that if there are too many active sources for the reports to fit in the MTU, then a subset of the sources should be selected round-robin over multiple intervals.
- 需要澄清的是，每个报告间隔只应发送一个复合RTCP数据包，并且如果有太多的活动源使报告不适合MTU，则应在多个间隔内循环选择源的子集。
- A note was added in Appendix A.1 that packets may be saved during RTP header validation and delivered upon success.
- 附录A.1中添加了一条注释，即在RTP报头验证期间可以保存数据包，并在成功后交付。
- Section 7.3 now explains that a mixer aggregating SDES packets uses more RTCP bandwidth due to longer packets, and a mixer passing through RTCP naturally sends packets at higher than the single source rate, but both behaviors are valid.
- 第7.3节现在解释，由于数据包较长，聚合SDES数据包的混频器使用更多RTCP带宽，并且通过RTCP的混频器自然以高于单一源速率发送数据包，但这两种行为都是有效的。
- Section 13 clarifies that an RTP application may use multiple profiles but typically only one in a given session.
- 第13节阐明了RTP应用程序可以使用多个配置文件，但通常在给定会话中仅使用一个配置文件。
- The terms MUST, SHOULD, MAY, etc. are used as defined in RFC 2119.
- 术语“必须”、“应该”、“可以”等按照RFC 2119中的定义使用。
- The bibliography was divided into normative and informative references.
- 参考文献分为规范性参考文献和信息性参考文献。
References
工具书类
Normative References
规范性引用文件
[1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[1] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 3551，2003年7月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[4] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[4] Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC13051992年3月。
[5] Yergeau, F., "UTF-8, a Transformation Format of ISO 10646", RFC 2279, January 1998.
[5] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[6] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[7] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[7] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[8] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[8] Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
Informative References
资料性引用
[10] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols," in SIGCOMM Symposium on Communications Architectures and Protocols , (Philadelphia, Pennsylvania), pp. 200--208, IEEE Computer Communications Review, Vol. 20(4), September 1990.
[10] Clark，D.和D.Tennenhouse，“新一代协议的架构考虑”，载于SIGCOMM通信架构和协议研讨会（宾夕法尼亚州费城），第200-208页，IEEE计算机通信评论，第20卷（4），1990年9月。
[11] Schulzrinne, H., "Issues in designing a transport protocol for audio and video conferences and other multiparticipant real-time applications." expired Internet Draft, October 1993.
[11] Schulzrinne，H.，“为音频和视频会议及其他多方实时应用程序设计传输协议的问题”，已过期的互联网草案，1993年10月。
[12] Comer, D., Internetworking with TCP/IP , vol. 1. Englewood Cliffs, New Jersey: Prentice Hall, 1991.
[12] Comer，D.，与TCP/IP的互联，第1卷。新泽西州恩格尔伍德悬崖：普伦蒂斯大厅，1991年。
[13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[13] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[14] International Telecommunication Union, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service", Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 2003.
[14] 国际电信联盟，“提供非保证服务质量的局域网可视电话系统和设备”，建议H.323，国际电联电信标准化部门，瑞士日内瓦，2003年7月。
[15] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[15] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[16] Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[17] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[17] Eastlake 3rd，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[18] Bolot, J.-C., Turletti, T. and I. Wakeman, "Scalable Feedback Control for Multicast Video Distribution in the Internet", in SIGCOMM Symposium on Communications Architectures and Protocols, (London, England), pp. 58--67, ACM, August 1994.
[18] Bolot，J.-C.，Turletti，T.和I.Wakeman，“互联网中多播视频分发的可伸缩反馈控制”，载于SIGCOMM通信体系结构和协议研讨会（英国伦敦），第58-67页，ACM，1994年8月。
[19] Busse, I., Deffner, B. and H. Schulzrinne, "Dynamic QoS Control of Multimedia Applications Based on RTP", Computer Communications , vol. 19, pp. 49--58, January 1996.
[19] Busse，I.，Deffner，B.和H.Schulzrinne，“基于RTP的多媒体应用的动态QoS控制”，计算机通信，第19卷，第49-58页，1996年1月。
[20] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", in SIGCOMM Symposium on Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp. 33--44, ACM, September 1993. Also in [34].
[20] Floyd，S.和V.Jacobson，“周期性路由消息的同步”，载于SIGCOMM通信体系结构和协议研讨会（D.P.Sidhu，ed.），（加利福尼亚州旧金山），第33-44页，ACM，1993年9月。同样在[34]中。
[21] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group Membership in RTP", RFC 2762, February 2000.
[21] Rosenberg，J.和H.Schulzrinne，“RTP中群体成员的抽样”，RFC 2762，2000年2月。
[22] Cadzow, J., Foundations of Digital Signal Processing and Data Analysis New York, New York: Macmillan, 1987.
[22] 《数字信号处理和数据分析基础》，纽约，纽约：麦克米伦，1987年。
[23] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[23] Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[24] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.
[24] Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.和E.Lear，“私人互联网地址分配”，RFC 1918，1996年2月。
[25] Lear, E., Fair, E., Crocker, D. and T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)", RFC 1627, July 1994.
[25] Lear，E.，Fair，E.，Crocker，D.和T.Kessler，“网络10被认为是有害的（有些做法不应该被编纂）”，RFC 1627，1994年7月。
[26] Feller, W., An Introduction to Probability Theory and its Applications, vol. 1. New York, New York: John Wiley and Sons, third ed., 1968.
[26] 费勒，W.，概率论及其应用导论，第1卷。纽约，纽约：约翰·威利父子，第三版，1968年。
[27] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[27] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[28] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K. and D. Oran, "Secure Real-time Transport Protocol", Work in Progress, April 2003.
[28] Baugher，M.，Blom，R.，Carrara，E.，McGrew，D.，Naslund，M.，Norrman，K.和D.Oran，“安全实时传输协议”，正在进行的工作，2003年4月。
[29] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III", RFC 1423, February 1993.
[29] Balenson，D.，“因特网电子邮件的隐私增强：第三部分”，RFC 1423，1993年2月。
[30] Voydock, V. and S. Kent, "Security Mechanisms in High-Level Network Protocols", ACM Computing Surveys, vol. 15, pp. 135-171, June 1983.
[30] Voydock，V.和S.Kent，“高级网络协议中的安全机制”，ACM计算调查，第15卷，第135-171页，1983年6月。
[31] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[31] Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[32] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[32] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[33] Stubblebine, S., "Security Services for Multimedia Conferencing", in 16th National Computer Security Conference, (Baltimore, Maryland), pp. 391--395, September 1993.
[33] Stubblebine，S.，“多媒体会议的安全服务”，第16届全国计算机安全会议，（马里兰州巴尔的摩），第391-395页，1993年9月。
[34] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, vol. 2, pp. 122--136, April 1994.
[34] Floyd，S.和V.Jacobson，“周期性路由消息的同步”，IEEE/ACM网络事务，第2卷，第122-136页，1994年4月。
Authors' Addresses
作者地址
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 United States
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
Stephen L.Casner Packet Design美国加利福尼亚州帕洛阿尔托市Hillview大道3400号3号楼，邮编94304
EMail: casner@acm.org
EMail: casner@acm.org
Ron Frederick Blue Coat Systems Inc. 650 Almanor Avenue Sunnyvale, CA 94085 United States
Ron Frederick Blue Coat Systems Inc.美国加利福尼亚州桑尼维尔阿尔马诺大道650号，邮编94085
EMail: ronf@bluecoat.com
EMail: ronf@bluecoat.com
Van Jacobson Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
美国加利福尼亚州帕洛阿尔托市Hillview大道3400号3号楼Van Jacobson Packet Design 94304
EMail: van@packetdesign.com
EMail: van@packetdesign.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。