Network Working Group C. Perkins
Request for Comments: 3158 USC/ISI
Category: Informational J. Rosenberg
dynamicsoft
H. Schulzrinne
Columbia University
August 2001
Network Working Group C. Perkins
Request for Comments: 3158 USC/ISI
Category: Informational J. Rosenberg
dynamicsoft
H. Schulzrinne
Columbia University
August 2001
RTP Testing Strategies
RTP测试策略
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations.
本备忘录描述了RTP（实时传输协议）实现的可能测试策略。
Table of Contents
目录
1 Introduction. . . . . . . . . . . . . . . . . . . . . . 2
2 End systems . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Media transport . . . . . . . . . . . . . . . . . 3
2.2 RTP Header Extension . . . . . . . . . . . . . . . 4
2.3 Basic RTCP . . . . . . . . . . . . . . . . . . . 4
2.3.1 Sender and receiver reports . . . . . . . . 4
2.3.2 RTCP source description packets . . . . . . 6
2.3.3 RTCP BYE packets . . . . . . . . . . . . . . 7
2.3.4 Application defined RTCP packets . . . . . . 7
2.4 RTCP transmission interval . . . . . . . . . . . . 7
2.4.1 Basic Behavior . . . . . . . . . . . . . . 8
2.4.2 Step join backoff . . . . . . . . . . . . 9
2.4.3 Steady State Behavior . . . . . . . . . . 11
2.4.4 Reverse Reconsideration . . . . . . . . . 12
2.4.5 BYE Reconsideration . . . . . . . . . . . 13
2.4.6 Timing out members . . . . . . . . . . . . 14
2.4.7 Rapid SR's . . . . . . . . . . . . . . . . 15
3 RTP translators . . . . . . . . . . . . . . . . . . . . 15
4 RTP mixers. . . . . . . . . . . . . . . . . . . . . . . 17
5 SSRC collision detection. . . . . . . . . . . . . . . . 18
1 Introduction. . . . . . . . . . . . . . . . . . . . . . 2
2 End systems . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Media transport . . . . . . . . . . . . . . . . . 3
2.2 RTP Header Extension . . . . . . . . . . . . . . . 4
2.3 Basic RTCP . . . . . . . . . . . . . . . . . . . 4
2.3.1 Sender and receiver reports . . . . . . . . 4
2.3.2 RTCP source description packets . . . . . . 6
2.3.3 RTCP BYE packets . . . . . . . . . . . . . . 7
2.3.4 Application defined RTCP packets . . . . . . 7
2.4 RTCP transmission interval . . . . . . . . . . . . 7
2.4.1 Basic Behavior . . . . . . . . . . . . . . 8
2.4.2 Step join backoff . . . . . . . . . . . . 9
2.4.3 Steady State Behavior . . . . . . . . . . 11
2.4.4 Reverse Reconsideration . . . . . . . . . 12
2.4.5 BYE Reconsideration . . . . . . . . . . . 13
2.4.6 Timing out members . . . . . . . . . . . . 14
2.4.7 Rapid SR's . . . . . . . . . . . . . . . . 15
3 RTP translators . . . . . . . . . . . . . . . . . . . . 15
4 RTP mixers. . . . . . . . . . . . . . . . . . . . . . . 17
5 SSRC collision detection. . . . . . . . . . . . . . . . 18
6 SSRC Randomization. . . . . . . . . . . . . . . . . . . 19
7 Security Considerations . . . . . . . . . . . . . . . . 20
8 Authors' Addresses. . . . . . . . . . . . . . . . . . . 20
9 References. . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement. . . . . . . . . . . . . . . . . 22
6 SSRC Randomization. . . . . . . . . . . . . . . . . . . 19
7 Security Considerations . . . . . . . . . . . . . . . . 20
8 Authors' Addresses. . . . . . . . . . . . . . . . . . . 20
9 References. . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement. . . . . . . . . . . . . . . . . 22
1 Introduction
1导言
This memo describes a possible testing strategy for RTP [1] implementations. The tests are intended to help demonstrate interoperability of multiple implementations, and to illustrate common implementation errors. They are not intended to be an exhaustive set of tests and passing these tests does not necessarily imply conformance to the complete RTP specification.
本备忘录描述了RTP[1]实现的可能测试策略。这些测试旨在帮助演示多个实现的互操作性，并说明常见的实现错误。它们不是一组详尽的测试，通过这些测试并不一定意味着符合完整的RTP规范。
2 End systems
2端系统
The architecture for testing RTP end systems is shown in Figure 1.
测试RTP终端系统的体系结构如图1所示。
+-----------------+
+--------+ Test instrument +-----+
| +-----------------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Second RTP |
| implementation | | implementation |
+----------------+ +----------------+
+-----------------+
+--------+ Test instrument +-----+
| +-----------------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Second RTP |
| implementation | | implementation |
+----------------+ +----------------+
Figure 1: Testing architecture
图1：测试架构
Both RTP implementations send packets to the test instrument, which forwards packets from one implementation to the other. Unless otherwise specified, packets are forwarded with no additional delay and without loss. The test instrument is required to delay or discard packets in some of the tests. The test instrument is invisible to the RTP implementations - it merely simulates poor network conditions.
两个RTP实现都向测试仪器发送数据包，测试仪器将数据包从一个实现转发到另一个实现。除非另有规定，否则数据包转发时不会出现额外延迟和丢失。在某些测试中，测试仪器需要延迟或丢弃数据包。测试仪器对RTP实现是不可见的——它只是模拟恶劣的网络条件。
The test instrument is also capable of logging packet contents for inspection of their correctness.
测试仪器还能够记录数据包内容，以检查其正确性。
A typical test setup might comprise three machines on a single Ethernet segment. Two of these machines run the RTP implementations, the third runs the test instrument. The test instrument is an application level packet forwarder. Both RTP implementations are instructed to send unicast RTP packets to the test instrument, which forwards packets between them.
典型的测试设置可能包括单个以太网段上的三台机器。其中两台运行RTP实现，第三台运行测试仪器。测试仪器是一个应用级数据包转发器。两种RTP实现都被指示向测试仪器发送单播RTP数据包，测试仪器在它们之间转发数据包。
The aim of these tests is to show that basic media flows can be exchanged between the two RTP implementations. The initial test is for the first RTP implementation to transmit and the second to receive. If this succeeds, the process is reversed, with the second implementation sending and the first receiving.
这些测试的目的是显示基本媒体流可以在两个RTP实现之间交换。初始测试是第一个RTP实现发送，第二个实现接收。如果此操作成功，则该过程将反转，第二个实现发送，第一个接收。
The receiving application should be able to handle the following edge cases, in addition to normal operation:
除了正常操作外，接收应用程序还应能够处理以下边缘情况：
o Verify reception of packets which contain padding.
o 验证是否接收到包含填充的数据包。
o Verify reception of packets which have the marker bit set
o 验证已设置标记位的数据包的接收情况
o Verify correct operation during sequence number wrap-around.
o 验证序列号环绕期间的操作是否正确。
o Verify correct operation during timestamp wrap-around.
o 在时间戳环绕期间验证操作是否正确。
o Verify that the implementation correctly differentiates packets according to the payload type field.
o 验证实现是否根据有效负载类型字段正确区分数据包。
o Verify that the implementation ignores packets with unsupported payload types
o 验证该实现是否忽略负载类型不受支持的数据包
o Verify that the implementation can playout packets containing a CSRC list and non-zero CC field (see section 4).
o 验证实现是否可以播放包含CSC列表和非零CC字段的数据包（参见第4节）。
The sending application should be verified to correctly handle the following edge cases:
应验证发送应用程序，以正确处理以下边缘情况：
o If padding is used, verify that the padding length indicator (last octet of the packet) is correctly set and that the length of the data section of the packet corresponds to that of this particular payload plus the padding.
o 如果使用了填充，请验证填充长度指示器（数据包的最后一个八位字节）是否正确设置，以及数据包的数据部分的长度是否对应于此特定有效负载的长度加上填充。
o Verify correct handling of the M bit, as defined by the profile.
o 根据配置文件的定义，验证M位的正确处理。
o Verify that the SSRC is chosen randomly.
o 确认SSRC是随机选择的。
o Verify that the initial value of the sequence number is randomly selected.
o 确认序列号的初始值是随机选择的。
o Verify that the sequence number increments by one for each packet sent.
o 验证发送的每个数据包的序列号是否增加1。
o Verify correct operation during sequence number wrap-around.
o 验证序列号环绕期间的操作是否正确。
o Verify that the initial value of the timestamp is randomly selected.
o 确认时间戳的初始值是随机选择的。
o Verify correct increment of timestamp (dependent on the payload format).
o 验证时间戳增量是否正确（取决于有效负载格式）。
o Verify correct operation during timestamp wrap-around.
o 在时间戳环绕期间验证操作是否正确。
o Verify correct choice of payload type according to the chosen payload format, profile and any session level control protocol.
o 根据所选的有效负载格式、配置文件和任何会话级控制协议，验证有效负载类型的正确选择。
An RTP implementation which does not use an extended header should be able to process packets containing an extension header by ignoring the extension.
不使用扩展报头的RTP实现应该能够通过忽略扩展来处理包含扩展报头的数据包。
If an implementation makes use of the header extension, it should be verified that the profile specific field and the length field of the extension are set correctly, and that the length of the packet is consistent.
如果实现使用了报头扩展，则应验证扩展的配置文件特定字段和长度字段设置是否正确，以及数据包的长度是否一致。
An RTP implementation is required to send RTCP control packets in addition to data packets. The architecture for testing basic RTCP functions is that shown in Figure 1.
除了数据包外，还需要RTP实现来发送RTCP控制包。测试基本RTCP功能的架构如图1所示。
The first test requires both implementations to be run, but neither sends data. It should be verified that RTCP packets are generated by each implementation, and that those packets are correctly received by the other implementation. It should also be verified that:
第一个测试要求两个实现都运行，但都不发送数据。应验证每个实现是否生成RTCP数据包，以及其他实现是否正确接收这些数据包。还应核实：
o all RTCP packets sent are compound packets
o 发送的所有RTCP数据包都是复合数据包
o all RTCP compound packets start with an empty RR packet
o 所有RTCP复合数据包都以空RR数据包开始
o all RTCP compound packets contain an SDES CNAME packet
o 所有RTCP复合数据包都包含SDES CNAME数据包
The first implementation should then be made to transmit data packets. It should be verified that that implementation now generates SR packets in place of RR packets, and that the second application now generates RR packets containing a single report block. It should be verified that these SR and RR packets are correctly received. The following features of the SR packets should also be verified:
然后，应进行第一个实现以传输数据包。应该验证该实现现在生成SR包而不是RR包，并且第二个应用程序现在生成包含单个报告块的RR包。应验证这些SR和RR数据包是否正确接收。还应验证SR数据包的以下特征：
o that the length field is consistent with both the length of the packet and the RC field
o 长度字段与数据包的长度和RC字段一致
o that the SSRC in SR packets is consistent with that in the RTP data packets
o SR数据包中的SSRC与RTP数据包中的SSRC一致
o that the NTP timestamp in the SR packets is sensible (matches the wall clock time on the sending machine)
o SR数据包中的NTP时间戳是否合理（与发送机器上的挂钟时间相匹配）
o that the RTP timestamp in the SR packets is consistent with that in the RTP data packets
o SR数据包中的RTP时间戳与RTP数据包中的RTP时间戳一致
o that the packet and octet count fields in the SR packets are consistent with the number of RTP data packets transmitted
o SR分组中的分组和八位字节计数字段与传输的RTP数据分组的数量一致
In addition, the following features of the RR packets should also be verified:
此外，还应验证RR数据包的以下特征：
o that the SSRC in the report block is consistent with that in the data packets being received
o 报告块中的SSRC与正在接收的数据包中的SSRC一致
o that the fraction lost is zero
o 损失的分数是零
o that the cumulative number of packets lost is zero
o 数据包丢失的累计数量为零
o that the extended highest sequence number received is consistent with the data packets being received (provided the round trip time between test instrument and receiver is smaller than the packet inter-arrival time, this can be directly checked by the test instrument).
o 接收到的扩展最高序列号与接收到的数据包一致（如果测试仪器和接收器之间的往返时间小于数据包到达时间，则可由测试仪器直接检查）。
o that the interarrival jitter is small (a precise value cannot be given, since it depends on the test instrument and network conditions, but very little jitter should be present in this scenario).
o 到达间隔抖动很小（无法给出精确值，因为它取决于测试仪器和网络条件，但在这种情况下，抖动应该很小）。
o that the last sender report timestamp is consistent with that in the SR packets (i.e., each RR passing through the test instrument should contain the middle 32 bits from the 64 bit NTP timestamp of the last SR packet which passed through the test instrument in the opposite direction).
o 最后一个发送方报告时间戳与SR数据包中的时间戳一致（即，通过测试仪器的每个RR应包含来自以相反方向通过测试仪器的最后一个SR数据包的64位NTP时间戳的中间32位）。
o that the delay since last SR field is sensible (an estimate may be made by timing the passage of an SR and corresponding RR through the test instrument, this should closely agree with the DLSR field)
o 自最后一个SR场起的延迟是合理的（可通过对SR和相应RR通过试验仪器的时间进行估算，这应与DLSR场密切一致）
It should also be verified that the timestamps, packet count and octet count correctly wrap-around after the appropriate interval.
还应验证时间戳、数据包计数和八位字节计数在适当的间隔后是否正确环绕。
The next test is to show behavior in the presence of packet loss. The first implementation is made to transmit data packets, which are received by the second implementation. This time, however, the test instrument is made to randomly drop a small fraction (1% is suggested) of the data packets. The second implementation should be able to receive the data packets and process them in a normal manner (with, of course, some quality degradation). The RR packets should show a loss fraction corresponding to the drop rate of the test instrument and should show an increasing cumulative number of packets lost.
下一个测试是显示数据包丢失时的行为。第一个实现用于发送由第二个实现接收的数据包。然而，这一次，测试仪器随机丢弃一小部分数据包（建议为1%）。第二个实现应该能够接收数据包并以正常方式处理它们（当然，会有一些质量下降）。RR数据包应显示与测试仪器丢弃率相对应的丢失分数，并应显示丢失数据包的累积数量增加。
The loss rate in the test instrument is then returned to zero and it is made to delay each packet by some random amount (the exact amount depends on the media type, but a small fraction of the average interarrival time is reasonable). The effect of this should be to increase the reported interarrival jitter in the RR packets.
然后将测试仪器中的丢失率恢复为零，并使每个数据包延迟一些随机量（确切的延迟量取决于媒体类型，但平均到达间隔时间的一小部分是合理的）。这样做的效果应该是增加RR数据包中报告的到达间隔抖动。
If these tests succeed, the process should be repeated with the second implementation transmitting and the first receiving.
如果这些测试成功，则应在第二个实现发送和第一个接收时重复该过程。
Both implementations should be run, but neither is required to transmit data packets. The RTCP packets should be observed and it should be verified that each compound packet contains an SDES packet, that that packet contains a CNAME item and that the CNAME is chosen according to the rules in the RTP specification and profile (in many cases the CNAME should be of the form `example@10.0.0.1' but this may be overridden by a profile definition).
两种实现都应该运行，但传输数据包都不需要。应观察RTCP数据包，并应验证每个复合数据包是否包含SDES数据包，该数据包是否包含CNAME项目，以及CNAME是否根据RTP规范和配置文件中的规则选择（在许多情况下，CNAME的格式应为`example@10.0.0.1'但这可能会被配置文件定义覆盖）。
If an application supports additional SDES items then it should be verified that they are sent in addition to the CNAME with some SDES packets (the exact rate at which these additional items are included is dependent on the application and profile).
如果应用程序支持其他SDES项目，则应验证这些项目是否与CNAME一起发送，并带有一些SDES数据包（包含这些附加项目的确切速率取决于应用程序和配置文件）。
It should be verified that an implementation can correctly receive NAME, EMAIL, PHONE, LOC, NOTE, TOOL and PRIV items, even if it does not send them. This is because it may reasonably be expected to interwork with other implementations which support those items. Receiving and ignoring such packets is valid behavior.
应该验证实现是否能够正确接收姓名、电子邮件、电话、LOC、备注、工具和PRIV项，即使它没有发送它们。这是因为可以合理地预期它将与支持这些项的其他实现交互工作。接收和忽略这样的数据包是有效的行为。
It should be verified that an implementation correctly sets the length fields in the SDES items it sends, and that the source count and packet length fields are correct. It should be verified that SDES fields are not zero terminated.
应验证实现是否正确设置了其发送的SDES项中的长度字段，以及源计数和数据包长度字段是否正确。应验证SDES字段不是以零结尾的。
It should be verified that an implementation correctly receives SDES items which do not terminate in a zero byte.
应验证实现是否正确接收不以零字节结束的SDES项。
Both implementations should be run, but neither is required to transmit data packets. The first implementation is then made to exit and it should be verified that an RTCP BYE packet is sent. It should be verified that the second implementation reacts to this BYE packet and notes that the first implementation has left the session.
两种实现都应该运行，但传输数据包都不需要。然后退出第一个实现，并应验证是否发送了RTCP BYE数据包。应该验证第二个实现是否对此BYE数据包做出反应，并注意第一个实现已离开会话。
If the test succeeds, the implementations should be restarted and the process repeated with the second implementation leaving the session.
如果测试成功，则应重新启动实现，并在第二个实现离开会话时重复该过程。
It should be verified that implementations handle BYE packets containing the optional reason for leaving text (ignoring the text is acceptable).
应该验证实现是否处理包含保留文本的可选原因的BYE数据包（可以忽略文本）。
Tests for the correct response to application defined packets are difficult to specify, since the response is clearly implementation dependent. It should be verified that an implementation ignores APP packets where the 4 octet name field is unrecognized. Implementations which use APP packets should verify that they behave as expected.
很难指定对应用程序定义的数据包的正确响应的测试，因为响应显然依赖于实现。应该验证一个实现是否忽略了4个八位组名称字段无法识别的应用程序数据包。使用应用程序数据包的实现应验证其行为是否符合预期。
The basic architecture for performing tests of the RTCP transmission interval is shown in Figure 2.
执行RTCP传输间隔测试的基本架构如图2所示。
The test instrument is connected to the same LAN as the RTP implementation being tested. It is assumed that the test instrument is preconfigured with the addresses and ports used by the RTP implementation, and is also aware of the RTCP bandwidth and sender/receiver fractions. The tests can be conducted using either multicast or unicast.
测试仪器与正在测试的RTP实现连接到同一LAN。假设测试仪器预先配置了RTP实现所使用的地址和端口，并且还知道RTCP带宽和发送方/接收方部分。测试可以使用多播或单播进行。
The test instrument must be capable of sending arbitrarily crafted RTP and RTCP packets to the RTP implementation. The test instrument should also be capable of receiving packets sent by the RTP implementation, parsing them, and computing metrics based on those packets.
测试仪器必须能够向RTP实现发送任意编制的RTP和RTCP数据包。测试工具还应该能够接收RTP实现发送的数据包，解析它们，并基于这些数据包计算度量。
+--------------+
| test |
| instrument |
+-----+--------+
|
------+-----------+-------------- LAN
|
+-------+--------+
| RTP |
| implementation |
+----------------+
+--------------+
| test |
| instrument |
+-----+--------+
|
------+-----------+-------------- LAN
|
+-------+--------+
| RTP |
| implementation |
+----------------+
Figure 2: Testing architecture for RTCP
图2:RTCP的测试架构
It is furthermore assumed that a number of basic controls over the RTP implementation exist. These controls are:
此外，还假设存在对RTP实现的一些基本控制。这些控制措施包括：
o the ability to force the implementation to send or not send RTP packets at any desired point in time
o 强制实现在任何所需时间点发送或不发送RTP数据包的能力
o the ability to force the application to terminate its involvement in the RTP session, and for this termination to be known immediately to the test instrument
o 强制应用程序终止其参与RTP会话的能力，以及测试仪器立即知道该终止的能力
o the ability to set the session bandwidth and RTCP sender and receiver fractions
o 设置会话带宽和RTCP发送方和接收方分数的能力
The second of these is required only for the test of BYE reconsideration, and is the only aspect of these tests not easily implementable by pure automation. It will generally require manual intervention to terminate the session from the RTP implementation and to convey this to the test instrument through some non-RTP means.
第二个测试仅用于测试系统，并且是这些测试中唯一一个无法通过纯自动化轻松实现的方面。通常需要手动干预，以从RTP实现中终止会话，并通过一些非RTP方式将其传递给测试仪器。
The first test is to verify basic correctness of the implementation of the RTCP transmission rules. This basic behavior consists of:
第一个测试是验证RTCP传输规则实现的基本正确性。这一基本行为包括：
o periodic transmission of RTCP packets
o RTCP数据包的定期传输
o randomization of the interval for RTCP packet transmission
o RTCP数据包传输间隔的随机化
o correct implementation of the randomization interval computations, with unconditional reconsideration
o 正确执行随机区间计算，无条件重新考虑
The RTP implementation acts as a receiver, and never sends any RTP data packets. The implementation is configured with a large session bandwidth, say 1 Mbit/s. This will cause the implementation to use the minimal interval of 5s rather than the small interval based on the session bandwidth and membership size. The implementation will generate RTCP packets at this minimal interval, on average. The test instrument generates no packets, but receives the RTCP packets generated by the implementation. When an RTCP packet is received, the time is noted by the test instrument. The difference in time between each pair of subsequent packets (called the interval) is computed. These intervals are stored, so that statistics based on these intervals can be computed. It is recommended that this observation process operate for at least 20 minutes.
RTP实现充当接收器，从不发送任何RTP数据包。该实现配置了较大的会话带宽，例如1 Mbit/s。这将导致实现使用最小间隔5s，而不是基于会话带宽和成员大小的小间隔。平均而言，该实现将以该最小间隔生成RTCP数据包。测试仪器不生成数据包，但接收由实现生成的RTCP数据包。当接收到RTCP数据包时，测试仪器记录时间。计算每对后续数据包之间的时间差（称为间隔）。存储这些间隔，以便可以计算基于这些间隔的统计信息。建议该观察过程至少运行20分钟。
An implementation passes this test if the intervals have the following properties:
如果间隔具有以下属性，则实现通过此测试：
o the minimum interval is never less than 2 seconds or more than 2.5 seconds;
o 最小间隔不得小于2秒或大于2.5秒；
o the maximum interval is never more than 7 seconds or less than 5.5 seconds;
o 最大间隔不得超过7秒或小于5.5秒；
o the average interval is between 4.5 and 5.5 seconds;
o 平均间隔在4.5到5.5秒之间；
o the number of intervals between x and x+500ms is less than the number of intervals between x+500ms and x+1s, for any x.
o 对于任何x，x和x+500ms之间的间隔数小于x+500ms和x+1s之间的间隔数。
In particular, an implementation fails if the packets are sent with a constant interval.
特别是，如果以恒定间隔发送数据包，则实现将失败。
The main purpose of the reconsideration algorithm is to avoid a flood of packets that might occur when a large number of users simultaneously join an RTP session. Reconsideration therefore exhibits a backoff behavior in sending of RTCP packets when group sizes increase. This aspect of the algorithm can be tested in the following manner.
重新考虑算法的主要目的是避免大量用户同时加入RTP会话时可能出现的大量数据包。因此，当组大小增加时，重新考虑在发送RTCP数据包时表现出退避行为。该算法的这一方面可以通过以下方式进行测试。
The implementation begins operation. The test instrument waits for the arrival of the first RTCP packet. When it arrives, the test instrument notes the time and then immediately sends 100 RTCP RR packets to the implementation, each with a different SSRC and SDES CNAME. The test instrument should ensure that each RTCP packet is of the same length. The instrument should then wait until the next RTCP packet is received from the implementation, and the time of such reception is noted.
实现开始运行。测试仪器等待第一个RTCP数据包的到达。当它到达时，测试仪器记录时间，然后立即向实现发送100个RTCP RR数据包，每个数据包具有不同的SSRC和SDES CNAME。测试仪器应确保每个RTCP数据包的长度相同。然后，仪器应等待，直到接收到来自实施的下一个RTCP数据包，并记录接收时间。
Without reconsideration, the next RTCP packet will arrive within a short period of time. With reconsideration, transmission of this packet will be delayed. The earliest it can arrive depends on the RTCP session bandwidth, receiver fraction, and average RTCP packet size. The RTP implementation should be using the exponential averaging algorithm defined in the specification to compute the average RTCP packet size. Since this is dominated by the received packets (the implementation has only sent one itself), the average will be roughly equal to the length of the RTCP packets sent by the test instrument. Therefore, the minimum amount of time between the first and second RTCP packets from the implementation is:
无需重新考虑，下一个RTCP数据包将在短时间内到达。重新考虑后，此数据包的传输将延迟。它最早到达取决于RTCP会话带宽、接收器分数和平均RTCP数据包大小。RTP实现应使用规范中定义的指数平均算法来计算平均RTCP数据包大小。由于这主要由接收的数据包决定（实现本身只发送了一个数据包），因此平均值大致等于测试仪器发送的RTCP数据包的长度。因此，来自实施的第一和第二RTCP数据包之间的最小时间量为：
T > 101 * S / ( B * Fr * (e-1.5) * 2 )
T > 101 * S / ( B * Fr * (e-1.5) * 2 )
Where S is the size of the RTCP packets sent by the test instrument, B is the RTCP bandwidth (normally five percent of the session bandwidth), Fr is the fraction of RTCP bandwidth allocated to receivers (normally 75 percent), and e is the natural exponent. Without reconsideration, this minimum interval Te would be much smaller:
其中S是测试仪器发送的RTCP数据包的大小，B是RTCP带宽（通常为会话带宽的5%），Fr是分配给接收器的RTCP带宽的分数（通常为75%），e是自然指数。如果不重新考虑，该最小间隔Te将小得多：
Te > MAX( [ S / ( B * Fr * (e-1.5) * 2 ) ] , [ 2.5 / (e-1.5) ] )
Te > MAX( [ S / ( B * Fr * (e-1.5) * 2 ) ] , [ 2.5 / (e-1.5) ] )
B should be chosen sufficiently small so that T is around 60 seconds. Reasonable choices for these parameters are B = 950 bits per second, and S = 1024 bits. An implementation passes this test if the interval between packets is not less than T above, and not more than 3 times T.
应选择足够小的B，以使T约为60秒。这些参数的合理选择是B=950位/秒，S=1024位。如果数据包之间的间隔不小于T，且不超过T的3倍，则实现通过该测试。
Note: in all tests the value chosen for B, the RTCP bandwidth, is calculated including the lower layer UDP/IP headers. In a typical IPv4 based implementation, these comprise 28 octets per packet. A common mistake is to forget that these are included when choosing the size of packets to transmit.
注意：在所有测试中，为B（RTCP带宽）选择的值是计算出来的，包括较低层的UDP/IP报头。在典型的基于IPv4的实现中，每个数据包包含28个八位字节。一个常见的错误是，在选择要传输的数据包的大小时，忘记了这些数据包包括在内。
The test should be repeated for the case when the RTP implementation is a sender. This is accomplished by having the implementation send RTP packets at least once a second. In this case, the interval between the first and second RTCP packets should be no less than:
当RTP实现是发送方时，应该重复测试。这是通过让实现至少每秒发送一次RTP数据包来实现的。在这种情况下，第一个和第二个RTCP数据包之间的间隔应不小于：
T > S / ( B * Fs * (e-1.5) * 2 )
T > S / ( B * Fs * (e-1.5) * 2 )
Where Fs is the fraction of RTCP bandwidth allocated to senders, usually 25%. Note that this value of T is significantly smaller than the interval for receivers.
其中Fs是分配给发送方的RTCP带宽的分数，通常为25%。注意，T的这个值明显小于接收机的间隔。
In addition to the basic behavior in section 2.4.1, an implementation should correctly implement a number of other, slightly more advanced features:
除了第2.4.1节中的基本行为外，实现还应正确实现一些其他稍微高级的功能：
o scale the RTCP interval with the group size;
o 根据组大小调整RTCP间隔；
o correctly divide bandwidth between senders and receivers;
o 正确划分发送方和接收方之间的带宽；
o correctly compute the RTCP interval when the user is a sender
o 当用户是发送方时，正确计算RTCP间隔
The implementation begins operation as a receiver. The test instrument waits for the first RTCP packet from the implementation. When it arrives, the test instrument notes the time, and immediately sends 50 RTCP RR packets and 50 RTCP SR packets to the implementation, each with a different SSRC and SDES CNAME. The test instrument then sends 50 RTP packets, using the 50 SSRC from the RTCP SR packets. The test instrument should ensure that each RTCP packet is of the same length. The instrument should then wait until the next RTCP packet is received from the implementation, and the time of such reception is noted. The difference between the reception of the RTCP packet and the reception of the previous is computed and stored. In addition, after every RTCP packet reception, the 100 RTCP and 50 RTP packets are retransmitted by the test instrument. This ensures that the sender and member status of the 100 users does not time out. The test instrument should collect the interval measurements figures for at least 100 RTCP packets.
实现作为接收器开始操作。测试仪器等待来自实现的第一个RTCP数据包。当它到达时，测试仪器记录时间，并立即向实现发送50个RTCP RR数据包和50个RTCP SR数据包，每个数据包具有不同的SSRC和SDES CNAME。然后，测试仪器使用RTCP SR数据包中的50个SSRC发送50个RTP数据包。测试仪器应确保每个RTCP数据包的长度相同。然后，仪器应等待，直到接收到来自实施的下一个RTCP数据包，并记录接收时间。计算并存储RTCP数据包的接收与前一个数据包的接收之间的差异。此外，在每次接收RTCP数据包后，100个RTCP和50个RTP数据包由测试仪器重新传输。这可确保100个用户的发件人和成员状态不会超时。测试仪器应收集至少100个RTCP数据包的间隔测量值。
With 50 senders, the implementation should not try to divide the RTCP bandwidth between senders and receivers, but rather group all users together and divide the RTCP bandwidth equally. The test is deemed successful if the average RTCP interval is within 5% of:
对于50个发送方，实现不应尝试在发送方和接收方之间划分RTCP带宽，而是将所有用户分组在一起，平均分配RTCP带宽。如果平均RTCP间隔在以下值的5%以内，则认为测试成功：
T = 101* S/B
T = 101* S/B
Where S is the size of the RTCP packets sent by the test instrument, and B is the RTCP bandwidth. B should be chosen sufficiently small so that the value of T is on the order of tens of seconds or more. Reasonable values are S=1024 bits and B=3.4 kb/s.
其中S是测试仪器发送的RTCP数据包的大小，B是RTCP带宽。应选择足够小的B，以使T的值在数十秒或更长的数量级上。合理的值是S=1024位和B=3.4kb/S。
The previous test is repeated. However, the test instrument sends 10 RTP packets instead of 50, and 10 RTCP SR and 90 RTCP RR instead of 50 of each. In addition, the implementation is made to send at least one RTP packet between transmission of every one of its own RTCP packets.
重复前面的测试。但是，测试仪器发送10个RTP数据包而不是50个，发送10个RTCP SR和90个RTCP RR而不是50个。此外，实现使得在其自身的每一个RTCP分组的传输之间发送至少一个RTP分组。
In this case, the average RTCP interval should be within 5% of:
在这种情况下，平均RTCP间隔应在以下值的5%以内：
T = 11 * S / (B * Fs)
T = 11 * S / (B * Fs)
Where S is the size of the RTCP packets sent by the test instrument, B is the RTCP bandwidth, and Fs is the fraction of RTCP bandwidth allocated for senders (normally 25%). The values for B and S should be chosen small enough so that T is on the order of tens of seconds. Reasonable choices are S=1024 bits and B=1.5 kb/s.
其中S是测试仪器发送的RTCP数据包的大小，B是RTCP带宽，Fs是分配给发送方的RTCP带宽的分数（通常为25%）。B和S的值应选择足够小的值，以便T在数十秒的量级上。合理的选择是S=1024位和B=1.5 kb/S。
The reverse reconsideration algorithm is effectively the opposite of the normal reconsideration algorithm. It causes the RTCP interval to be reduced more rapidly in response to decreases in the group membership. This is advantageous in that it keeps the RTCP information as fresh as possible, and helps avoids some premature timeout problems.
反向重新考虑算法实际上与正常重新考虑算法相反。它会导致RTCP间隔更快地缩短，以响应组成员资格的减少。这是有利的，因为它使RTCP信息尽可能保持新鲜，并有助于避免一些过早超时的问题。
In the first test, the implementation joins the session as a receiver. As soon as the implementation sends its first RTCP packet, the test instrument sends 100 RTCP RR packets, each of the same length S, and a different SDES CNAME and SSRC in each. It then waits for the implementation to send another RTCP packet. Once it does, the test instrument sends 100 BYE packets, each one containing a different SSRC, but matching an SSRC from one of the initial RTCP packets. Each BYE should also be the same size as the RTCP packets sent by the test instrument. This is easily accomplished by using a BYE reason to pad out the length. The time of the next RTCP packet from the implementation is then noted. The delay T between this (the third RTCP packet) and the previous should be no more than:
在第一个测试中，实现作为接收器加入会话。一旦实施发送其第一个RTCP数据包，测试仪器将发送100个RTCP RR数据包，每个数据包的长度相同，每个数据包中的SDES CNAME和SSRC不同。然后，它等待实现发送另一个RTCP数据包。一旦完成，测试仪器将发送100个BYE数据包，每个数据包包含不同的SSRC，但与一个初始RTCP数据包中的SSRC相匹配。每个BYE也应与测试仪器发送的RTCP数据包大小相同。这很容易通过使用BYE REASURE填充长度来实现。然后记录来自实现的下一个RTCP数据包的时间。此（第三个RTCP数据包）与前一个数据包之间的延迟T应不超过：
T < 3 * S / (B * Fr * (e-1.5) * 2)
T < 3 * S / (B * Fr * (e-1.5) * 2)
Where S is the size of the RTCP and BYE packets sent by the test instrument, B is the RTCP bandwidth, Fr is the fraction of the RTCP bandwidth allocated to receivers, and e is the natural exponent. B should be chosen such that T is on the order of tens of seconds. A reasonable choice is S=1024 bits and B=168 bits per second.
其中S是测试仪器发送的RTCP和BYE数据包的大小，B是RTCP带宽，Fr是分配给接收机的RTCP带宽的分数，e是自然指数。B的选择应确保T的数量级为数十秒。合理的选择是S=1024位，B=168位/秒。
This test demonstrates basic correctness of implementation. An implementation without reverse reconsideration will not send its next RTCP packet for nearly 100 times as long as the above amount.
该测试证明了实现的基本正确性。没有反向重新考虑的实现将不会发送其下一个RTCP数据包，发送时间几乎是上述金额的100倍。
In the second test, the implementation joins the session as a receiver. As soon as it sends its first RTCP packet, the test instrument sends 100 RTCP RR packets, each of the same length S, followed by 100 BYE packets, also of length S. Each RTCP packet
在第二个测试中，实现作为接收器加入会话。一旦发送其第一个RTCP数据包，测试仪器将发送100个RTCP RR数据包，每个数据包的长度相同S，然后发送100个BYE数据包，同样长度为S。每个RTCP数据包
carries a different SDES CNAME and SSRC, and is matched with precisely one BYE packet with the same SSRC. This will cause the implementation to see a rapid increase and then rapid drop in group membership.
携带不同的SDES CNAME和SSRC，并与具有相同SSRC的一个BYE数据包精确匹配。这将导致实现中的组成员数快速增加，然后快速下降。
The test is deemed successful if the next RTCP packet shows up T seconds after the first, and T is within:
如果下一个RTCP数据包在第一个RTCP数据包后T秒显示，且T在以下范围内，则认为测试成功：
2.5 / (e-1.5) < T < 7.5 / (e-1.5)
2.5 / (e-1.5) < T < 7.5 / (e-1.5)
This tests correctness of the maintenance of the pmembers variable. An incorrect implementation might try to execute reverse reconsideration every time a BYE is received, as opposed to only when the group membership drops below pmembers. If an implementation did this, it would end up sending an RTCP packet immediately after receiving the stream of BYE's. For this test to work, B must be chosen to be a large value, around 1Mb/s.
这将测试pmembers变量维护的正确性。不正确的实现可能会在每次收到BYE时尝试执行反向重新考虑，而不是仅当组成员资格降至pmembers以下时。如果一个实现做到了这一点，它将在收到BYE流后立即发送一个RTCP数据包。要使此测试正常工作，必须选择B作为一个大值，大约为1Mb/s。
The BYE reconsideration algorithm works in much the same fashion as regular reconsideration, except applied to BYE packets. When a user leaves the group, instead of sending a BYE immediately, it may delay transmission of its BYE packet if others are sending BYE's.
BYE重新考虑算法的工作方式与常规重新考虑基本相同，只是适用于BYE数据包。当用户离开组时，如果其他用户正在发送BYE，它可能会延迟其BYE数据包的传输，而不是立即发送BYE。
The test for correctness of this algorithm is as follows. The RTP implementation joins the group as a receiver. The test instrument waits for the first RTCP packet. When the test instrument receives this packet, the test instrument immediately sends 100 RTCP RR packets, each of the same length S, and each containing a different SSRC and SDES CNAME. Once the test instrument receives the next RTCP packet from the implementation, the RTP implementation is made to leave the RTP session, and this information is conveyed to the test instrument through some non-RTP means. The test instrument then sends 100 BYE packets, each with a different SSRC, and each matching an SSRC from a previously transmitted RTCP packet. Each of these BYE packets is also of size S. Immediately following the BYE packets, the test instrument sends 100 RTCP RR packets, using the same SSRC/CNAMEs as the original 100 RTCP packets.
对该算法正确性的测试如下。RTP实现作为接收器加入组。测试仪器等待第一个RTCP数据包。当测试仪器收到该数据包时，测试仪器立即发送100个RTCP RR数据包，每个数据包的长度相同，并且每个数据包包含不同的SSRC和SDES CNAME。一旦测试仪器接收到来自实施的下一个RTCP数据包，RTP实施将离开RTP会话，并且该信息通过一些非RTP方式传送到测试仪器。然后，测试仪器发送100个BYE数据包，每个数据包具有不同的SSRC，并且每个数据包与先前传输的RTCP数据包中的SSRC相匹配。每个BYE数据包的大小也是S。紧接着BYE数据包，测试仪器发送100个RTCP RR数据包，使用与原始100个RTCP数据包相同的SSRC/CNAMEs。
The test is deemed successful if the implementation either never sends a BYE, or if it does, the BYE is received by the test instrument not earlier than T seconds, and not later than 3 * T seconds, after the implementation left the session, where T is:
如果实现从未发送BYE，或者如果发送BYE，则测试仪器在实现离开会话后不早于T秒且不晚于3*T秒收到BYE，则测试被视为成功，其中T为：
T = 100 * S / ( 2 * (e-1.5) * B )
T = 100 * S / ( 2 * (e-1.5) * B )
S is the size of the RTCP and BYE packets, e is the natural exponent, B is the RTCP bandwidth, and Fr is the RTCP bandwidth fraction for receivers. S and B should be chosen so that T is on the order of 50 seconds. A reasonable choice is S=1024 bits and B=1.1 kb/s.
S是RTCP和BYE数据包的大小，e是自然指数，B是RTCP带宽，Fr是接收机的RTCP带宽分数。应选择S和B，使T在50秒左右。一个合理的选择是S=1024位，B=1.1kb/S。
The transmission of the RTCP packets is meant to verify that the implementation is ignoring non-BYE RTCP packets once it decides to leave the group.
RTCP数据包的传输旨在验证一旦实现决定离开组，它是否会忽略非BYE RTCP数据包。
Active RTP participants are supposed to send periodic RTCP packets. When a participant leaves the session, they may send a BYE, however this is not required. Furthermore, BYE reconsideration may cause a BYE to never be sent. As a result, participants must time out other participants who have not sent an RTCP packet in a long time. According to the specification, participants who have not sent an RTCP packet in the last 5 intervals are timed out. This test verifies that these timeouts are being performed correctly.
活动RTP参与者应定期发送RTCP数据包。当参与者离开会议时，他们可以发送拜拜，但这不是必需的。此外，再见重新考虑可能导致永远不会发送再见。因此，参与者必须让长时间未发送RTCP数据包的其他参与者超时。根据规范，在过去5个时间间隔内未发送RTCP数据包的参与者将超时。此测试验证这些超时是否正确执行。
The RTP implementation joins a session as a receiver. The test instrument waits for the first RTCP packet from the implementation. Once it arrives, the test instrument sends 100 RTCP RR packets, each with a different SDES and SSRC, and notes the time. This will cause the implementation to believe that there are now 101 group participants, causing it to increase its RTCP interval. The test instrument continues to monitor the RTCP packets from the implementation. As each RTCP packet is received, the time of its reception is noted, and the interval between RTCP packets is stored. The 100 participants spoofed by the test instrument should eventually time out at the RTP implementation. This should cause the RTCP interval to be reduced to its minimum.
RTP实现作为接收器加入会话。测试仪器等待来自实现的第一个RTCP数据包。一旦到达，测试仪器发送100个RTCP RR数据包，每个数据包具有不同的SDE和SSRC，并记录时间。这将使实现相信现在有101个组参与者，从而增加其RTCP间隔。测试仪器继续监控来自实施的RTCP数据包。当接收到每个RTCP数据包时，记录其接收时间，并存储RTCP数据包之间的间隔。被测试仪器欺骗的100名参与者最终应该在RTP实现时超时。这将导致RTCP间隔减小到其最小值。
The test is deemed successful if the interval between RTCP packets after the first is no less than:
如果第一次测试后RTCP数据包之间的间隔不小于：
Ti > 101 * S / ( 2 * (e-1.5) * B * Fr)
Ti > 101 * S / ( 2 * (e-1.5) * B * Fr)
and this minimum interval is sustained no later than Td seconds after the transmission of the 100 RR's, where Td is:
且该最小间隔在传输100 RR后的Td秒内保持，其中Td为：
Td = 7 * 101 * S / ( B * Fr )
Td = 7 * 101 * S / ( B * Fr )
and the interval between RTCP packets after this point is no less than:
并且在此点之后RTCP数据包之间的间隔不小于：
Tf > 2.5 / (e-1.5)
Tf>2.5/（e-1.5）
For this test to work, B and S must be chosen so Ti is on the order of minutes. Recommended values are S = 1024 bits and B = 1.9 kbps.
为了使该测试有效，必须选择B和S，使Ti为分钟量级。建议值为S=1024位和B=1.9 kbps。
The minimum interval for RTCP packets can be reduced for large session bandwidths. The reduction applies to senders only. The recommended algorithm for computing this minimum interval is 360 divided by the RTP session bandwidth, in kbps. For bandwidths larger than 72 kbps, this interval is less than 5 seconds.
对于较大的会话带宽，可以缩短RTCP数据包的最小间隔。该降价仅适用于发件人。计算此最小间隔的推荐算法是360除以RTP会话带宽，单位为kbps。对于大于72 kbps的带宽，此间隔小于5秒。
This test verifies the ability of an implementation to use a lower RTCP minimum interval when it is a sender in a high bandwidth session. The test can only be run on implementations that support this reduction, since it is optional.
此测试验证在高带宽会话中作为发送方时，实现是否能够使用较低的RTCP最小间隔。该测试只能在支持这种缩减的实现上运行，因为它是可选的。
The RTP implementation is configured to join the session as a sender. The session is configured to use 360 kbps. If the recommended algorithm for computing the reduced minimum interval is used, the result is a 1 second interval. If the RTP implementation uses a different algorithm, the session bandwidth should be set in such a way to cause the reduced minimum interval to be 1 second.
RTP实现被配置为作为发送方加入会话。会话配置为使用360 kbps。如果使用了计算缩减最小间隔的推荐算法，则结果为1秒间隔。如果RTP实现使用不同的算法，则会话带宽的设置应使缩短的最小间隔为1秒。
Once joining the session, the RTP implementation should begin to send both RTP and RTCP packets. The interval between RTCP packets is measured and stored until 100 intervals have been collected.
一旦加入会话，RTP实现应开始发送RTP和RTCP数据包。测量并存储RTCP数据包之间的间隔，直到收集到100个间隔。
The test is deemed successful if the smallest interval is no less than 1/2 a second, and the largest interval is no more than 1.5 seconds. The average should be close to 1 second.
如果最小间隔不小于1/2秒，且最大间隔不超过1.5秒，则认为试验成功。平均值应该接近1秒。
3 RTP translators
3个RTP翻译器
RTP translators should be tested in the same manner as end systems, with the addition of the tests described in this section.
RTP转换器应以与终端系统相同的方式进行测试，并添加本节所述的测试。
The architecture for testing RTP translators is shown in Figure 3.
测试RTP转换器的体系结构如图3所示。
+-----------------+
+--------+ RTP Translator +-----+
| +-----------------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Second RTP |
| implementation | | implementation |
+----------------+ +----------------+
+-----------------+
+--------+ RTP Translator +-----+
| +-----------------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Second RTP |
| implementation | | implementation |
+----------------+ +----------------+
Figure 3: Testing architecture for translators
图3：翻译人员的测试架构
The first RTP implementation is instructed to send data to the translator, which forwards the packets to the other RTP implementation, after translating then as desired. It should be verified that the second implementation can playout the translated packets.
指示第一个RTP实现向转换器发送数据，转换器在根据需要进行翻译之后将数据包转发给另一个RTP实现。应该验证第二个实现是否可以播放已翻译的数据包。
It should be verified that the packets received by the second implementation have the same SSRC as those sent by the first implementation. The CC should be zero and CSRC fields should not be present in the translated packets. The other RTP header fields may be rewritten by the translator, depending on the translation being performed, for example
应该验证第二个实现接收的数据包与第一个实现发送的数据包具有相同的SSRC。CC应为零，翻译后的数据包中不应存在CSC字段。其他RTP报头字段可由翻译器重写，这取决于例如正在执行的翻译
o the payload type should change if the translator changes the encoding of the data
o 如果转换器更改数据的编码，则有效负载类型应该更改
o the timestamp may change if, for example, the encoding, packetisation interval or framerate is changed
o 例如，如果编码、打包间隔或帧率改变，则时间戳可以改变
o the sequence number may change if the translator merges or splits packets
o 如果转换器合并或拆分数据包，序列号可能会更改
o padding may be added or removed, in particular if the translator is adding or removing encryption
o 可以添加或删除填充，特别是在转换器添加或删除加密时
o the marker bit may be rewritten
o 标记位可以被重写
If the translator modifies the contents of the data packets it should be verified that the corresponding change is made to the RTCP packets, and that the receivers can correctly process the modified RTCP packets. In particular
如果翻译器修改数据包的内容，则应验证对RTCP包进行了相应的更改，并且接收方能够正确处理修改后的RTCP包。特别地
o the SSRC is unchanged by the translator
o SSRC由译者更改
o if the translator changes the data encoding it should also change the octet count field in the SR packets
o 如果转换器更改了数据编码，它还应该更改SR数据包中的八位字节计数字段
o if the translator combines multiple data packets into one it should also change the packet count field in SR packets
o 如果转换器将多个数据包合并为一个，则还应更改SR数据包中的数据包计数字段
o if the translator changes the sampling frequency of the data packets it should also change the RTP timestamp field in the SR packets
o 如果转换器更改数据包的采样频率，它还应更改SR包中的RTP时间戳字段
o if the translator combines multiple data packets into one it should also change the packet loss and extended highest sequence number fields of RR packets flowing back from the receiver (it is legal for the translator to strip the report
o 如果翻译器将多个数据包合并为一个数据包，则还应更改从接收器流回的RR数据包的丢包和扩展的最高序列号字段（翻译器剥离报告是合法的）
blocks and send empty SR/RR packets, but this should only be done if the transformation of the data is such that the reception reports cannot sensibly be translated)
阻塞并发送空的SR/RR数据包，但仅当数据转换导致接收报告无法合理转换时，才应执行此操作）
o the translator should forward SDES CNAME packets
o 转换器应转发SDES CNAME数据包
o the translator may forward other SDES packets
o 转换器可以转发其他SDES分组
o the translator should forward BYE packets unchanged
o 翻译器应转发未更改的BYE数据包
o the translator should forward APP packets unchanged
o 翻译器应转发应用程序包，不作更改
When the translator exits it should be verified to send a BYE packet to each receiver containing the SSRC of the other receiver. The receivers should be verified to correctly process this BYE packet (this is different to the BYE test in section 2.3.3 since multiple SSRCs may be included in each BYE if the translator also sends its own RTCP information).
当转换器退出时，应验证是否向每个接收器发送BYE数据包，其中包含另一个接收器的SSRC。应验证接收器是否正确处理该BYE数据包（这与第2.3.3节中的BYE测试不同，因为如果翻译器也发送其自己的RTCP信息，则每个BYE中可能包含多个SSRC）。
4 RTP mixers
4个RTP混合器
RTP mixers should be tested in the same manner as end systems, with the addition of the tests described in this section.
RTP混合器应按照与末端系统相同的方式进行测试，并添加本节所述的测试。
The architecture for testing RTP mixers is shown in Figure 4.
测试RTP混频器的体系结构如图4所示。
The first and second RTP implementations are instructed to send data packets to the RTP mixer. The mixer combines those packets and sends them to the third RTP implementation. The mixer should also process RTCP packets from the other implementations, and should generate its own RTCP reports.
指示第一和第二RTP实现向RTP混合器发送数据分组。混合器组合这些数据包并将它们发送到第三个RTP实现。混音器还应处理来自其他实现的RTCP数据包，并应生成自己的RTCP报告。
+----------------+
| Second RTP |
| implementation |
+-------+--------+
|
| +-----------+
+-------+ RTP Mixer +-----+
| +-----------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Third RTP |
| implementation | | implementation |
+----------------+ +----------------+
+----------------+
| Second RTP |
| implementation |
+-------+--------+
|
| +-----------+
+-------+ RTP Mixer +-----+
| +-----------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Third RTP |
| implementation | | implementation |
+----------------+ +----------------+
Figure 4: Testing architecture for mixers
图4：混频器的测试架构
It should be verified that the third RTP implementation can playout the mixed packets. It should also be verified that
应该验证第三个RTP实现是否可以播放混合数据包。还应核实：
o the CC field in the RTP packets received by the third implementation is set to 2
o 第三个实现接收的RTP数据包中的CC字段设置为2
o the RTP packets received by the third implementation contain 2 CSRCs corresponding to the first and second RTP implementations
o 由第三实现接收的RTP分组包含与第一和第二RTP实现相对应的2个csrc
o the RTP packets received by the third implementation contain an SSRC corresponding to that of the mixer
o 由第三实现接收的RTP分组包含与混频器的SSRC相对应的SSRC
It should next be verified that the mixer generates SR and RR packets for each cloud. The mixer should generate RR packets in the direction of the first and second implementations, and SR packets in the direction of the third implementation.
接下来应该验证混频器是否为每个云生成SR和RR数据包。混频器应在第一和第二实现的方向上生成RR分组，并在第三实现的方向上生成SR分组。
It should be verified that the SR packets sent to the third implementation do not reference the first or second implementations, and vice versa.
应当验证发送到第三实现的SR分组不引用第一或第二实现，反之亦然。
It should be verified that SDES CNAME information is forwarded across the mixer. Other SDES fields may optionally be forwarded.
应验证SDES CNAME信息是否通过混合器转发。可以选择转发其他SDES字段。
Finally, one of the implementations should be quit, and it should be verified that the other implementations see the BYE packet. This implementation should then be restarted and the mixer should be quit. It should be verified that the implementations see both the mixer and the implementations on the other side of the mixer quit (illustrating response to BYE packets containing multiple sources).
最后，应该退出其中一个实现，并且应该验证其他实现是否看到BYE数据包。然后应重新启动此实现，并退出混音器。应该验证实现是否同时看到混频器和混频器另一侧的实现退出（说明对包含多个源的BYE数据包的响应）。
5 SSRC collision detection
5 SSRC碰撞检测
RTP has provision for the resolution of SSRC collisions. These collisions occur when two different session participants choose the same SSRC. In this case, both participants are supposed to send a BYE, leave the session, and rejoin with a different SSRC, but the same CNAME. The purpose of this test is to verify that this function is present in the implementation.
RTP规定了SSRC碰撞的解决方案。当两个不同的会话参与者选择相同的SSRC时，会发生这些冲突。在这种情况下，两个参与者都应该发送再见，离开会话，然后使用不同的SSRC重新加入，但CNAME相同。此测试的目的是验证此功能是否存在于实现中。
The test is straightforward. The RTP implementation is made to join the multicast group as a receiver. A test instrument waits for the first RTCP packet. Once it arrives, the test instrument notes the CNAME and SSRC from the RTCP packet. The test instrument then generates an RTCP receiver report. This receiver report contains an SDES chunk with an SSRC matching that of the RTP implementation, but with a different CNAME. At this point, the implementation should
测试很简单。RTP实现是为了作为接收器加入多播组。测试仪器等待第一个RTCP数据包。一旦到达，测试仪器会记录RTCP数据包中的CNAME和SSRC。然后，测试仪器生成RTCP接收器报告。此接收方报告包含一个SDES区块，其SSRC与RTP实现的SSRC匹配，但CNAME不同。在这一点上，应该考虑实施
send a BYE RTCP packet (containing an SDES chunk with the old SSRC and CNAME), and then rejoin, causing it to send a receiver report containing an SDES chunk, but with a new SSRC and the same CNAME.
发送BYE RTCP数据包（包含具有旧SSRC和CNAME的SDES区块），然后重新加入，使其发送包含SDES区块但具有新SSRC和相同CNAME的接收方报告。
The test is deemed successful if the RTP implementation sends the RTCP BYE and RTCP RR as described above within one minute of receiving the colliding RR from the test instrument.
如果RTP实施在接收到来自测试仪器的碰撞RR后一分钟内发送上述RTCP BYE和RTCP RR，则认为测试成功。
6 SSRC Randomization
6 SSRC随机化
According to the RTP specification, SSRC's are supposed to be chosen randomly and uniformly over a 32 bit space. This randomization is beneficial for several reasons:
根据RTP规范，SSRC应该在32位空间上随机均匀地选择。这种随机化有几个好处：
o It reduces the probability of collisions in large groups.
o 它降低了大群体碰撞的概率。
o It simplifies the process of group sampling [3] which depends on the uniform distribution of SSRC's across the 32 bit space.
o 它简化了分组采样过程[3]，这取决于SSRC在32位空间上的均匀分布。
Unfortunately, verifying that a random number has 32 bits of uniform randomness requires a large number of samples. The procedure below gives only a rough validation to the randomness used for generating the SSRC.
不幸的是，验证一个随机数是否具有32位均匀随机性需要大量样本。以下程序仅对用于生成SSRC的随机性进行了粗略验证。
The test runs as follows. The RTP implementation joins the group as a receiver. The test instrument waits for the first RTCP packet. It notes the SSRC in this RTCP packet. The test is repeated 2500 times, resulting in a collection of 2500 SSRC.
测试运行如下。RTP实现作为接收器加入组。测试仪器等待第一个RTCP数据包。它注意到RTCP数据包中的SSRC。该测试重复2500次，得到2500个SSRC。
The are then placed into 25 bins. An SSRC with value X is placed into bin FLOOR(X/(2**32 / 25)). The idea is to break the 32 bit space into 25 regions, and compute the number of SSRC in each region. Ideally, there should be 40 SSRC in each bin. Of course, the actual number in each bin is a random variable whose expectation is 40. With 2500 SSRC, the coefficient of variation of the number of SSRC in a bin is 0.1, which means the number should be between 36 and 44. The test is thus deemed successful if each bin has no less than 30 and no more than 50 SSRC.
然后将这些垃圾放入25个垃圾箱中。将值为X的SSRC放入料仓底板（X/（2**32/25））。其思想是将32位空间分成25个区域，并计算每个区域中SSRC的数量。理想情况下，每个箱子中应有40个SSRC。当然，每个箱子中的实际数字是一个期望值为40的随机变量。对于2500 SSRC，垃圾箱中SSRC数量的变异系数为0.1，这意味着数量应在36到44之间。因此，如果每个料仓的SSRC不小于30且不大于50，则认为试验成功。
Running this test may require substantial amounts of time, particularly if there is no automated way to have the implementation join the session. In such a case, the test can be run fewer times. With 26 tests, half of the SSRC should be less than 2**31, and the other half higher. The coefficient of variation in this case is 0.2, so the test is successful if there are more than 8 SSRC less than 2**31, and less than 26.
运行此测试可能需要大量的时间，特别是在没有自动方式让实现加入会话的情况下。在这种情况下，测试可以运行更少的次数。在26次测试中，一半SSRC应小于2**31，另一半更高。这种情况下的变异系数为0.2，因此，如果超过8个SSRC小于2**31且小于26，则测试成功。
In general, if the SSRC is collected N times, and there are B bins, the coefficient of variation of the number of SSRC in each bin is given by:
一般来说，如果SSRC收集N次，且有B个箱子，则每个箱子中SSRC数量的变异系数如下所示：
coeff = SQRT( (B-1)/N )
coeff = SQRT( (B-1)/N )
7 Security Considerations
7安全考虑
Implementations of RTP are subject to the security considerations mentioned in the RTP specification [1] and any applicable RTP profile (e.g., [2]). There are no additional security considerations implied by the testing strategies described in this memo.
RTP的实现受RTP规范[1]和任何适用RTP概要文件（例如[2]）中提到的安全注意事项的约束。本备忘录中所述的测试策略不包含其他安全注意事项。
8 Authors' Addresses
8作者地址
Colin Perkins USC Information Sciences Institute 3811 North Fairfax Drive Suite 200 Arlington, VA 22203
科林·珀金斯南加州信息科学研究所3811北费尔法克斯大道200号套房，弗吉尼亚州阿灵顿22203
EMail: csp@isi.edu
EMail: csp@isi.edu
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave. First Floor East Hanover, NJ 07936
Jonathan Rosenberg dynamicsoft 72 Eagle Rock大道一楼东汉诺威，NJ 07936
EMail: jdrosen@dynamicsoft.com
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
亨宁·舒尔兹林内哥伦比亚大学M/S 0401 1214纽约州纽约市阿姆斯特丹大道10027-7003
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
9 References
9参考文献
[1] Schulzrinne, H., Casner, S., Frederick R. and V. Jacobson, "RTP: A Transport Protocol to Real-Time Applications", Work in Progress (update to RFC 1889), March 2001.
[1] Schulzrinne，H.，Casner，S.，Frederick R.和V.Jacobson，“RTP：实时应用的传输协议”，正在进行的工作（更新至RFC 1889），2001年3月。
[2] Schulzrinne H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", Work in Progress (update to RFC 1890), March 2001.
[2] Schulzrinne H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，正在进行的工作（更新至RFC 1890），2001年3月。
[3] Rosenberg, J. and Schulzrinne, H. "Sampling of the Group Membership in RTP", RFC 2762, February 2000.
[3] Rosenberg，J.和Schulzrinne，H.“RTP中群体成员的抽样”，RFC 2762，2000年2月。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。