RTP协议校对翻译（三）

陶朱子

3.定义（definitions)

RTP载荷（RTP payload）：通过RTP传输的包中的数据，例如，音频采样值或压缩视频数据。载荷格式与解释不在本文讨论范围。
RTP包（RTP packet）：一种数据包，其组成部分有：一个固定RTP包头部，一个可能为空的作用源（contributing sources）列表（见后文），以及载荷数据。一些下层协议可能要求对RTP包的封装进行定义。一般地，下层协议的一个包包含一个RTP包，但若封装方法允许，也可包含数个RTP包（见第11节）。
RTCP包（RTCP packet）：一种控制包，其组成部分有：一个类似RTP包头部的固定头部，后跟一个结构化的部分，该部分具体元素依不同RTCP包的类型而定。格式的定义见第６节。一般地，多个RTCP包将在下层协议的一个包中以RTCP复合包的形式传输；这依靠每个RTCP包的固定头部中的长度字段来实现。
端口（Port）：“传输协议用来在同一主机中区分不同目的地的一种抽象。TCP/IP协议使用较小的正整数来标识不同端口。[12]”OSI传输层使用的传输选择器（TSEL, the transport selectors）等同于这里的端口。RTP需依靠低层协议提供的多种机制，如“端口”，用以多路复用会话中的RTP和RTCP包。
传输地址(Transport address)：是网络地址与端口的结合，用来标识一个传输层次的终端，例如一个IP地址与一个UDP端口。包是从源传输地址发送到目的传输地址。
RTP媒体类型（RTP media type）：一个RTP媒体类型是一个单独RTP会话所载有的负载类型的集合。RTP描述文件（profile）把RTP媒体类型指派给RTP载荷类型。
多媒体会话（Multimedia session）：在一个参与者公共组中，并发的RTP会话的集合。例如，一个视频会议（为多媒体会话）可能包含一个音频RTP会话和一个视频RTP会话。
RTP会话（RTP session）：一群参与者通过RTP进行通信时所产生的关联。一个参与者 可能同时参与多个RTP会话。在一个多媒体会话中，除非编码方式把多种媒体多路复用到一个单一数据流中，否则每种媒体都将使用各自的RTCP包，通过单独的RTP会话来传送 。通过使用不同的目的传输地址对（一个网络地址加上一对分别用于RTP和RTCP的端口，构成了一个传输地址对）来接收不同的会话，参与者能把多个RTP会话区隔开来。单个RTP会话中的所有参与者，可能共享一个公用目的传输地址对，比如IP多播的情况；也可能各自使用不同的目标传输地址对，比如个体单播网络地址加上一个端口对。对于单播的情况，参与者可能使用相同端口对来收听其他所有参与者 ，也可能对其他每个参与者使用不同的端口对来收听。
RTP会话间相互区别的特征，在于每个RTP会话都维护一个用于SSRC标识符的独立完整的空间。RTP会话所包含的参与者组，由能接收SSRC标识符的参与者组成，这些SSRC标识符由任意参与者传递，在RTP以同步源或作用源的形式，或在RTCP中。例如，考虑下述情况，用单播UDP实现的三方会议，每方都用不同的端口对来收听其他两方。如果收到一方的数据，就只把RTCP反馈发送给那一方，则会议就相当于由三个单独的点到点RTP会话构成。如果收到一方的数据，却把RTCP反馈发送另两方，则会议就是由一个多方（multi-party）RTP会话构成。后者模拟了三方间进行IP多播通信时的行为。
RTP框架允许上述规定发生变化，但一个特定的控制协议或者应用在设计时常常对变化作出约束。
同步源（SSRC，Synchronization source）：RTP包流的源，用RTP包头部中32位的SSRC标识符进行标识，使其不依赖于网络地址。一个同步源的所有包构成了相同计时和序列号空间的一部分，这样接收方就可以把一个同步源的包放在一起，来进行重放。举些同步源的例子，像来自同一信号源的包流的发送方，如麦克风、摄影机、RTP混频器（见后文）等，就是同步源。一个同步源可能随着时间变化而改变其数据格式，如音频编码。SSRC标识符是一个随机选取的值，它在特定的RTP会话中是全局唯一（globally unique）的（见第8节）。参与者并不需要在一个多媒体会议的所有RTP会话中，使用相同的SSRC标识符；SSRC标识符的绑定通过RTCP（见6.5.1节）。如果参与者在一个RTP会话中生成了多个流，例如来自多个摄影机，则每个摄影机都必须标识成单独的同步源 。
作用源（CSRC，Contributing source）：若一个RTP包流的源，对由RTP混频器生成的组合流起了作用，则它就是一个组合流的作用源。对特定包的生成起作用的源，其SSRC标识符组成的列表，被混频器插入到组合流包的RTP头部中。这个列表叫做CSRC表。相关应用的例子如，在音频会议中，即使所有的音频包都包含同一个（混频器的）SSRC标识符，混频器也将向所有的说话人（talker)指出，谁的话语（speech）将被组合到即将发出的包中，以使听者（接收者）可以清楚谁是当前说话人。
终端系统（End system）：一种应用，它产生发送出的RTP包中内容，或者使用接收到的RTP包中内容。在一个特定的RTP会话中，一个终端系统可以扮演一个或多个同步源角色，但通常是一个。
混频器（Mixer）：一种中间系统，它从一个或多个源中接收RTP包，可能改变其数据格式，再按某种方式把这些包组合成一个新的包，然后转发出去。由于多个输入源的计时一般不会同步，所以混频器会对各个流的计时作出调整，并为组合流生成一个新的计时。因此，混频器将被标识成它所产生所有数据包的同步源。
转换器（Translator)：一种中间系统，它转发RTP包而不改变各包的同步源标识符。转换器的例子如下：不作混频地转变编码的设备，把多播复制到单播的重复装置，以及防火墙里应用层次的过滤器。
监视器（Monitor）：一种应用，它接收RTP会话参与者所发送的RTCP包，特别是接收报告（reception report)，而且对当前服务质量进行评估，评估结果用于分配监视任务，故障诊断和长期统计。监视器的功能常常被内建到参与会话的应用中，但也可以是一个的独立的应用——不参加会话、也不发送或接收RTP数据包（因为它们在不同的端口上）。这些被称作第三方监视器。还有一种情况也是可以接受的，第三方监视器只接收RTP数据包，但不发送RTCP数据包，或者另外地算入到会话中。
非RTP途径（Non-RTP means)：为提供一个可用的服务，除了RTP可能还需要其他的协议和机制。特别地，对多媒体会议来说，一个控制协议可以发布多播地址，发布加密密钥，协商所用的加密算法，以及为没有预定义载荷类型值的格式，建立载荷类型值与其所代表的载荷格式之间的动态映射。其他协议的例子如下：会话初始化协议（SIP）(RFC3261[13]），ITU推荐的H.323[14]，还有使用SDP（RFC2327[15]）的应用，如RTSP（RFC 2326[16]）。对于简单的应用，电子邮件或者会议数据库也可能用到。对这些协议和机制的详细说明已经超出了本文档的讨论范围。


4.字节序、对齐和时间格式
所有整数都是以网络字节序传送的，即先发最重要字节（octet），也就是通常说的Big-Endian。传输的次序在[3,Appendix A]当中描述。除非其他的通知，数值常数都是十进制的（以10为基）。
所有头部数据都是以其自然长度对齐的，即16位字段都是在偶数偏移上对齐的，32位字段都是在被4除尽的偏移上对齐的，等等。分配为填充的字节是0值的。
挂钟时间(Wallclock Time，即绝对日期时间)是使用网络时间协议（NTP，Network Time Protocol）的时间戳格式来表现的，即相对于1900年1月1日0时（UTC，Coordinated Universal Time，协调世界时、世界标准时）的秒为单位。完全分辨率的NTP时间戳是64位的无符号定位数，其整数部分在第一个32位，小数部分在后32位当中。在一些更紧凑的表示更合适的地方，只使用中间的32位，即整数部分的低16位和小数部分的高16位。整数部分的高16位必须独立决定。
并不要求协议实现为使用RTP而运行NTP。其它时间源也可使用（见6.4.1节当中的NTP时间戳字节描述）。然而，运行NTP对于不同主机间的流同步是有用的。
NTP时间戳将会在2036年的某个时候回转（wrap around）到0，但对RTP来说只是使用了NTP时间戳对间的差值。只要这个时间戳对可假定相互在68年当中，使用取模算法来减（modular arithmetic for subtractions）和对比，都是使用回转是一样的。