RFC3550-RTP/RTCP中英文对照第5章和第6章部分

说明

本文为RFC3550第5章和第6章的翻译部分，其中有自己的理解部分，可能不正确

5 .RTP Data Transfer Protocol RTP 数据传输协议

5.1 RTP Fixed Header Fields RTP 固定头中的各字段

The RTP header has the following format: RTP头格式: （10进制为单位）

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 包中，仅仅在被混频器插入时，才会有CSRC识别符列表。这些字段有以下意
义：
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。(值 1 被 RTP 草案版本使用，值 0 用在最初"vat"语音工具使用的协议中。)

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.
填充( P )：1 比特
若填充比特被设置，则此包包含一到多个附加在末端的填充字节，填充字节不算作有效负载的一部分。填充的最后一个字节指明可以忽略多少个填充字节(包括自己)。某些具有固定块大小的加密算法或在较低层协议数据单元中承载多个RTP分组可能需要填充。
笔录：填充的字节是位于RTP包的末尾，而不是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.
CSRC 计数(CC)：4 比特
CSRC计数包含了跟在头后面 CSRC 识别符的数目(最多16个，混频器需要)。

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节）。
笔录：可以参考live555,h264的传输部分的实现知道这个标志位的作用

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方式动态定义（参见第3节）。在配套的RFC3551[1]中指定了音频和视频的一组默认映射（需要看每种类型代表的是什么意思）。RTP源可以在会话期间更改有效负载类型，但此字段不应用于多路复用单独的媒体流（参见第5.2节）。（笔录：类型为0-127，最大类型不应超过数值128，大于等于96是动态负载类型，由应用程序决定，具体的负载类型如下图所示）

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].
序列号（sequence number）：16 比特
每发送一个 RTP 数据包，序列号加 1，接收端可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测的，一般不要设置为0)，以使即便在源本身不加密时也不容易被攻击，这些问题将在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 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.
时间戳：32位
时间戳反映了RTP数据包中第一个字节的采样瞬间。采样瞬间必须从时间上单调线性递增的时钟中导出，以允许同步和抖动计算（见第6.4.1节）。时钟的分辨率必须足以达到所需的同步精度和测量数据包到达抖动（每个视频帧一个刻度通常是不够的）。-(笔录：时钟的分辨率要足够快，以反映视频帧的连续性)。时钟频率取决于作为有效载荷携带的数据格式，并在定义格式的配置文件或有效载荷格式规范中静态指定，或者可以为通过非RTP手段定义的有效负载格式动态指定。如果周期性地生成RTP数据包，则将使用从采样时钟确定的标称采样瞬间，而不是对系统时钟的读取。例如，对于固定速率的音频，时间戳时钟很可能会为每个采样周期增加一个。如果音频应用程序从输入设备读取覆盖160个采样周期的块，那么每个块的时间戳将增加160，而不管块是在分组中传输还是作为无声地被丢弃。

笔录：在RTP协议中并没有规定时间戳的粒度，这取决于有效载荷的类型。因此RTP的时间戳又称为媒体时间戳，以强调这种时间戳的粒度取决于信号的类型。例如， 对于8kHz采样的话音信号，若每隔20ms构成一个数据块，则一个数据块中包含有160个样本（0.02×8000=160）。因此每发送一个RTP分组，其时间戳的值就增加160。时间戳是去除抖动和实现同步不可缺少的，比如我们网络中某个时间由延时，可能后发送的数据还先到达了接收端，这时候我们可以根据时间戳的大小来得到发送数据的先后顺序。）。
扩展几个基本概念：
时间戳单位：时间戳计算的单位不是秒之类的单位，而是由采样频率所代替的单位，这样做的目的就是 为了是时间戳单位更为精准。比如说一个音频的采样频率为8000Hz，那么我们可以把时间戳单位设为1 / 8000。（这样就能准确的表达每一个一个音频的每一次震动）
时间戳增量：相邻两个RTP包之间的时间差（以时间戳单位为基准）。
采样频率：每秒钟抽取样本的次数，例如音频的采样率一般为8000Hz
帧率： 每秒传输或者显示帧数，例如25f/s。一帧可能包含一个或者多个数据包（具有相同的时间戳）
如果采样频率为90000Hz，时间戳单位为1/90000，我们就假设1s钟被划分了90000个时间块，那么，如果每秒发送25 帧，那么，每一个帧的发送占多少个时间块呢？当然是 90000/25 = 3600。因此，我们根据定义“时间戳增量是发送第二个RTP包相距发送第一个RTP包时的时间间隔”，故时间戳增量应该为3600。）。

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数据包具有相同的时间戳和时间戳不是单调的情况）

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时间戳可以以不同的速率前进，通常具有独立的随机偏移（笔录：时间戳增加值随类型不同而每次增加不同，这个是由类型的时钟频率来决定的，一般频率越高的，每次时间戳增量就越高）。因此，尽管这些时间戳足以重建单个流的定时同步（timing），但是直接比较来自不同媒体的RTP时间戳对于同步是无效的。相反，对于每种媒体，RTP时间戳通过与表示与RTP时间戳对应的数据被采样时的时间的参考时钟（wallclock-NTP）的时间戳配对而与采样时刻相关。参考时钟由所有要同步的媒体共享。时间戳对不是在每个数据包中传输，而是在第6.4节所述的RTCP SR包中以较低的速率传输。(笔录：不同的媒体流不能根据不同的时间戳来比较，只能通过某一共同的参考物来比较，比如共同的时钟（Wallclock-NTP），NTP是绝对时间，可以用来同步不同的媒体)

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时间戳的参考点，因为发送端知道它，并且对于所有媒体具有公共定义，与编码延时（encoding delays：我们在模拟数据发送时可能有意的延时或者在一些编码中也会这么做）或其他处理无关。其目的是允许同步呈现同时采样的所有媒体。

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.
传输存储数据而不是实时采样的数据的应用程序（比如点播应用程序）通常使用从时钟时间导出的虚拟呈现的时间线（a virtual presentation timeline）来确定何时应显示存储数据中每个媒体的下一帧或其他单元。在这种情况下，RTP时间戳将反映每个单元的呈现时间。也就是说，每个单元的RTP时间戳将与单元在虚拟表示时间线上变为当前的时钟时间相关（即是说每个时间戳单元都代表一个精确地时间，以此我们可以知道我们回放的数据是哪个时刻的）。根据接收者的判断，实际的呈现会在一段时间后发生。（笔录：如果传输的数据是存贮好的，而不是实时采样得到的，那么会使用从参考时钟得到的虚的表示时间线（virtual presentation timeline）。以确定存贮数据中的每个媒体下一帧或下一个单元应该呈现的时间。此种情况下RTP时间戳反映了每一个单元应当回放的时间。真正的回放将由接收者决定。比如视频开始时间是0点开始，我们拖动到1分钟，那么时间戳就增加60s。也就是说找到绝对时间和相对时间的映射关系）。

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 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同时传输。在RTP中传输的视频帧的“采样时刻”将通过将其时间戳引用到当该视频帧呈现给叙述者时的时钟时间来建立（笔录:RTP头的时间戳是通过当前讲述人的音频时钟时刻来建立，而不是视频的发生时间,每一个采样瞬间同时同时代表了音频和视频，虽然视频和音频不是同时产生的，但是我们却可以找到一个对应点，但是不能使用类似时间戳的那种增量，因为音频和视频每次的时间戳增量不一样，这样会很难做到同步）。包含叙述者演讲的音频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 bits
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.
CSRC列表：0到15项，每个32位
CSRC列表标识此数据包中包含的有效负载的贡献源。标识符的数目由CC字段给出。如果有15个以上的贡献来源，则只能确定15个。混频器使用贡献源的SSRC标识符插入CSRC标识符（见第7.1节）。例如，对于音频分组，列出混合在一起以创建分组的所有源的SSRC标识符，从而允许在接收方处正确地指示说话者。

5.2 Multiplexing RTP Sessions 多路复用的RTP会话

For efficient protocol processing, the number of multiplexing points should be minimized, as de- scribed 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的混合包（Interleaving packets）会导致几个问题（笔录：每种媒体都应该有一个单独的RTP会话和拥有唯一的SSRC，通常 RTP 应用中具有不同的媒体时，每种媒体都具有一个RTP端口和RTCP端口。比如 一种媒体的RTP 发送到5004，RTCP 发送到5005。另一个媒体的RTP发送到5006，RTP发送到5007）

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值，如果其中一个要改变编码，这就导致了 payload 类型的改变，但是协议中没有提供方法来让接收者知道具体是哪个音频流改变了编码。

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节）仅仅只描述了一个时序（timing）和序列号。

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 implementa- tions that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations.
5.如果一个 RTP Session 中包含了多个媒体流后就会失去如下优势：使用不同的网络路径或网络资源分配（如果合适）；如果需要，接收媒体的子集，例如如果视频将超过可用带宽，则仅接收音频；以及对不同媒体使用单独处理的接收方实现，而使用单独的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值来复用相同介质的流也是合适的。

扩展：
单播：单播地址是IP网络中最常见的。包含单播目标地址的分组发送给特定主机。要发送和接收单播分组，IP分组报头中必须有一个目标IP地址，而以太网帧报头中必须有相应的目标MAC地址。IP地址和MAC地址一起将数据传输到特定的目标主机。
提示：在网络传输的过程中，如果目标IP地址属于另一个网络，则在帧中使用的目标MAC地址将为与源IP地址位于同一个网络中的路由器接口的MAC地址。

广播：广播分组的目标IP地址的主机部分全为1，这意味着本地网络（广播域）中的所有主机都将接收并查看该分组。诸如ARP和DHCP等很多网络协议都使用广播。
C类网络192.168.1.0的默认子网掩码为255.255.255.0，其广播地址为192.168.1.255，其主机部分为十进制数255或二进制数11111111（全为1）；
B类网络172.16.0.0的默认子网掩码为255.255.0.0，其广播地址为172.16.255.255；
A类网络10.0.0.0的默认子网掩码为255.0.0.0，其广播地址为10.255.255.255。
在以太网帧中，必须包含与广播IP地址对应的广播MAC地址。在以太网中，广播MAC地址长48位，其十六进制表示为FF-FF-FF-FF-FF-FF。

多播：多播地址让源设备能够将分组发送给一组设备。属于多播组的设备将被分配一个多播组IP地址，多播地址范围为224.0.0.0～239.255.255.255。由于多播地址表示一组设备（有时被称为主机组），因此只能用作分组的目标地址。源地址总是为单播地址。
同单播地址和广播地址一样，多播IP地址也需要相应的多播MAC地址在本地网络中实际传送帧。源主机只需要发送一份数据，而网络中的路由器在转发该数据时需要将它复制多份，分别发给在该个多播组内的所有主机。也就是说，IP多播必须依赖于多播路由器，这些路由器具有识别多播包的功能，当然，多播路由器也能转发单播包。那如何让一个多播数据包到达该多播组内的多台主机呢？肯定不能将这么多主机的ip地址都写入该多播数据包的目的ip包头域（长度限制），而是在该多播数据包的目的ip地址域中写入D类地址（224.0.0.0—239.225.225.225 前4bit固定为1110），每个D类地址对应一个多播组，则D类地址可以标志2^28个多播组。因此，多播数据包与一般的单播广播数据包的区别是它的目的ip地址为D类地址，并且ip首部中的协议字段为2，表明采用的是IGMP网际组管理协议。（需要注意的是多播数据包的目的ip地址实际上不可能对应某一台真实存在的主机的ip地址，也就是说该目的ip地址永远不可能作为源地址，即多播ip地址只能用于目的ip地址，不能用于源ip地址）

ip多播可以分为两种，一种是在本地局域网上进行硬件多播，第二种是在互联网的范围内进行多播。第二种最后还是需要依赖于把多播数据包在局域网上用硬件多播交付给多播组的所有成员。

IP多播需要两种协议：IGMP网际组管理协议以及多播路由选择协议。

5.3 Profile-Specific Modifications to the RTP Header RTP标头的配置文件特定的修改

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设计原则，可以通过在配置文件规范中定义的修改或添加来定制报头，同时仍然允许独立于配置文件的监视和记录工具来发挥作用。

.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.
.标记位和有效负载类型字段携带特定于配置文件的信息，但它们在固定头中分配，因为许多应用程序应该需要它们，否则可能需要添加另一个32位字来保存它们。包含这些字段的字节可以通过配置文件重新定义以适应不同的要求，例如使用或多或少的标记位。如果存在任何标记 位，则一个标记位应位于字节的最高有效位中，因为与配置文件无关的监视器可以观察分组丢失模式和标记位之间的相关性。(笔录：标记位和有效负载类型需要通过配置文件来获取)

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.
对于特定的有效负载格式所需的附加信息，例如视频编码，应在数据包的有效负载部分中携带。这可能位于数据头的有效负载类型节的开头部分，也可能是由数据模式中的保留值表示**（这个在什么位置？？）。**

If a particular class of applications needs additional functionality independent of payload for- mat, 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.
如果某类应用程序需要独立于有效负载格式的附加功能，则这些应用程序运行的配置文件应定义附加的固定字段，紧跟在现有固定报头的SSRC字段之后（如果存在CSRC list，则放在CSRC list之后）。这些应用程序将能够快速和直接访问附加字段，而独立于配置文件的监视器或记录器仍然只能通过解释前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版本以对固定头进行永久更改。

5.3.1RTP Header Extension 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数据包头中携带附加信息。该机制的设计是为了使其他尚未扩展的互操作实现可以忽略头扩展（笔录：RTP 提供了一个拓展机制，让上层应用可以将自定义的信息存储在 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.
请注意，此头扩展仅限于有限的用途。该机制的大多数潜在用途最好用另一种方法来完成，使用上一节中描述的方法。例如，特定于固定头的配置文件扩展的处理成本较低，因为它不是有条件的，位置是固定的（笔录:根据标志位或者有效负载位来定义配置文件）。特定有效负载格式所需的其他信息不应使用此标头扩展，而应在数据包的有效负载部分中进行携带。

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头附加一个可变长度的标头扩展，放在CSRC列表 的后面（如果存在）。头扩展包含一个16位长度字段，计算扩展中32位字的数量，不包括扩展头的前面4个字节（因此零是有效长度）。只能向RTP数据头附加一个扩展。为了允许使用不同的头扩展独立地进行多个互操作实现，或者允许特定实现实验多个类型的头扩展，头扩展的前16位被开放用于区分标识符或参数。这16位的格式由实现在其下运行的配置文件规范定义。此RTP规范本身没有定义任何标头扩展（笔录：因为 RTP 头部后面只能连接一个拓展块，考虑到有些应用可能会有多种类型的拓展块，所以拓展块的头 16-bit 留给开发者去自定义一些参数）。

6.RTP Control Protocol — RTCP RTP控制协议—RTCP

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 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.
1.最主要的功能是反馈数据分发的质量。这也是 RTP 作为一个传输协议来说最关键的功能，而且它和流量控制，拥塞控制息息相关。（参见关于拥塞控制要求的第10节）。反馈信息可能会直接影响自适应编码的控制。[18,19]，但IP多播的实验表明，从接收方那里获得反馈来诊断分布中的故障也至关重要。发送反馈报告给所有的参与者可以让它们评估遇到的数据分发问题是局部问题还是全局问题。利用诸如IP多播之类的分发机制，像网络提供商这样的机构即便不加入到这个 RTP Session 中也能收到反馈信息，它们会扮演一个第三方监测者的角色去确认数据分发问题。这个反馈的功能由 RTCP 的发送者报告（SR）或者接收者报告(RR)来执行（performed），如第6.4节中所述。

扩展：自适应调制与编码简称为AMC（Adaptive Modulation and Coding），是一种基于物理层的链路自适应技术。AMC技术的基本原理是在发送功率恒定的情况下，通过调整无线链路传输的调制方式与编码速率，确保链路的传输质量。当信道条件较差时，选择较小的调制方式与编码速率；当信道条件较好时，选择较大的调制方式，从而最大化了传输速率。在AMC的调整过程中，系统总是希望传输的数据速率与信道变化的趋势一致，从而最大化地利用无线信道的传输能力。

2.RTCP carries a persistent transport-level identifier for an RTP source called the canoni- cal 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节.由于如果发现冲突（笔录：一个session中包含一个数据源列表，某一时刻可能存在2个相同的SSRC,可以通过判断同一SSRC是否来自同一个地址来确定是否冲突）或程序重新启动程序，SSRC标识符可能会更改，所以接收者需要这个 CNAME 来持续追踪每个与会者。而且，接收者可以通过 CNAME 来将同一个参与者的所有数据流联系在一起，比如同步音频和视频。单个媒体内部的数据同步也需要 NTP 和 RTP 时间戳，这些数据都在数据发送者发送的 RTCP 报文中（笔录：SR 类型头 send info 里面有有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.
第四个可选功能是传达最小的Session控制信息，例如要在用户界面中显示的参与者标识。这在参与者没有成员资格控制或参数协商的情况下进入和离开的“松散控制”Session中很有用（笔录：个人理解是参与者可以随时加入和退出会话，而不需要跟其他参与者协商，比如记录参与者的姓名，电话，邮件等信息）。RTCP是接触所有参与者的方便通道，但它不一定需要支持应用程序的所有控制通信需求,可能需要一个更高层的Session控制协议，这不在本文的讨论范围。

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.
这四个功能中，前三个应该会被所有应用场景使用（IP 组播机制下）。RTP 应用的设计者应该避免自己的应用只能工作在单播模式，RTP 应用应该设计成可拓展的，要考虑大量使用者并发时的情况。此外，RTCP 的传输应该根据发送者和接收者角色的不同而分别进行控制，例如一些单项连接，接收者的反馈信息就发不出来，如6.2所示。(笔录：控制类型分为3种，一种是发送方，一种是接收方，另一种是发送方和接收方同时控制)

Non-normative note: In the multicast routing approach called Source-Specific Mul- ticast (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 communi- cate 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的适应性，以便能够保持来自接收器的反馈。

6.1RTCP Packet Format RTCP包格式

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:接收方报告，用于接收来自非活动发送方的接收统计信息，并与SR结合使用，以报告31个以上来源的活动发送方

SDES: Source description items, including CNAME
SDES：源描述项，包括CNAME

BYE: Indicates end of participation
BYE：表示参与者的结束

APP: Application-specific functions
APP：应用程序专用的功能包（上层应用自定义。）

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 类似的固定格式的头，后面跟着长度不定的结构化数据，在不同 RTCP 类型时，这些结构化数据各不一样，但是它们必须都要 32-bit 对齐(32字节的倍数)。在每个包的固定部分包含对齐要求和长度字段，以使RTCP包“可堆叠”。因此 RTCP 可以被复合成一组一同发送，还不需要任何分隔符来分割出单个的 RTCP 包，该复合RTCP包以较低层协议（例如UDP）的单个包发送。下层协议可能会根据自己的情况决定(主要是协议支持的字节大小)将多少个 RTCP 报文复合在一起组成一个复合包。（笔录：没有RTCP分组个数的长度，底层协议的长度就是所有分组的长度之和，每个RTCP类型都有一个字段来表明属于什么类型的RTCP包,这就需要根据长度来决定是否能够将所有的包复合成一个复合包，如果不能则需要将其复合到下一个复合包，构造规则还是有一定难度，可以参考jrtplib的构造包规则）

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 报文都是无序的，而且可能会被随意复合。为了让协议的功能正常运作，会有如下限制：（笔录：不同的RTCP包发送频率不一样）：

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.
接收统计（SR|RR）的发送频率需要达到带宽的最大限制，因此每个周期发送的 RTCP 复合包都需要包含一个这类报文。

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.
新的接收者需要尽快接收源的CNAME，以识别源，并开始为lip-sync（唇音同步）等目的关联媒体，因此每个复合RTCP包还必须包括SDES CNAME，除非复合RTCP包按照第9.1节所述进行部分加密拆分（笔录：复合包被拆成两半一半加密，一半明文）。

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.
复合包中包类型的数量需要限制，这可以减少其他发错的包或者不相关的包被识别成 RTCP 包的可能性，还能增加第一个字中固定比特的数量。（笔录：开始复合包的类型不能太多，以此来计算复合包的数据位和减少出差的可能性）

Thus, all RTCP packets must be sent in a compound packet of at least two individual packets, with the following format:
因此，所有RTCP包必须以复合包的形式发送。复合包中至少有2 种类型的的 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-bit 数。如果加密算法需要填充数据的话，需要填充到复合包中的最后一个 RTCP 包后。

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 or RR: 复合包中的第一个RTCP包必须是一个报告包，这可以加速报文头部数据的校验（如附录A.2的facilitate header validation）。即便没有RTP数据的发送和接收也要有一个报告报文，这种情况下必须发送一个空的RR报文，并且即便是这个复合包中的其他 RTCP 报文只有BYE也要这么做。（笔录：复合包必须以SR或者RR开头，如果没有数据要发送，也必须发送一个空的RR包，即使后面一个包是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.
Additional RRs:：如果接收的RTP数据来自超过31个不同的源,前31个接收报告会写进 SR 或者 RR 报文中，多出来的接收报告应该紧跟着默认的RR报告报文。(笔录：如果一个接收报告超过31个不同的源，应该使用一个额外的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 Sec- tion 6.3.9).
SDES:除非第9.1节所述，否则必须在每个复合RTCP包中包含CNAME项的SDES包。如果上层应用有需要，也可以加入一些别的 SDES 报文，这视带宽限制而定。（如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/CSRC发送的最后一个数据包。数据包类型可能出现多次。

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 参与者在一个报告周期（report interval）内应只发送一个 RTCP 复合包，以便正确估计每个参与者的 RTCP 带宽(section 6.2)。除非像 9.1 节描述的情况——把一个 RTCP 复合包分割以进行加密。如果数据发送者的数量太多，以至于除了增加 MTU 这个方法之外，没办法将所有 RR 报文塞进一个复合包时，那么一次只会将部分 RR 数据塞进这个复合包，其他的数据就不发送了。在多个发送周期中，所有的包应该被等概率的选中。这样就可以报告所有数据源的接收数据的情况.(笔录：当然，为了让所有源的接收情况都得到报告，会在多个周期内以环的形式循环共享所有源的接收情况。)

扩展：
MTU:MTU是数据链路层的概念，MTU限制的是数据链路层的payload，也就是上层协议的大小，例如IP，ICMP等，其实一个标准的以太网数据帧大小是：1518，头信息有14字节，尾部校验和FCS占了4字节，所以真正留给上层协议传输数据的大小就是：1518 - 14 - 4 = 1500。

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节）（笔录：为了减少数据包的开销，一般建议 Translator 和 Mixer 无论何时都能将多个源的 RTCP 报文复合成一个复合包。）。图1示出了可能由混频器产生的示例RTCP复合分组。如果复合包的总长度超过网络路径的MTU，则应将其分割成多个较短的复合包，以在基础协议的单独包中传输。这并不影响（ impair ）RTCP带宽估算，因为每个复合分组表示至少一个不同的参与者。注意，每个复合包必须以SR或RR包开始。（不是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）注册。

剩下的章节可以到我的百度网盘去查看：RFC3550翻译，链接码：rfic