恋风的鱼☆°『奇幻世界』°★
恋风的鱼☆°『奇幻世界』°★
我是一条快乐的鱼， 自由自在 生活在蓝色的海洋里。 直到有一天， 我遇到了风...
文章
基于ARM-Linux和CDMA的远程视频监控系统
CDMA（码分多址）无线网络具有覆盖面广，高效、低成本 的特点，CDMA网络的数据传输速率可达200kb/s，这里开发的嵌入式远程视频监控系统就是充分利用CDMA无线网络技术和嵌入式系统的特点而搭建的 数据传输系统，特别适合边远偏僻或不具备常规网络传输条件的地方使用，例如车载视频监控系统、交通路口（车牌实时监视）及城市路灯的监控等。
1 嵌入式Linux系统
嵌入式系统是以应用为中心、以计算机技术为基础、软件硬件可裁剪、适应对功能、可靠性、成本、体积、功耗要求严格的专用计算机系统，目前嵌入式系统已经 无处不在，从汽车、家用微波炉、PDA（个人数字助理）、电视机、到工控生产现场、通信、仪器、仪表、汽车、船舶、航空、航天、军事装备、消费类产品方 面，都能发现嵌入式系统的踪影。
Linux本身作为一个桌面系统，其最大的特点是操作系统源代码公开并且遵循GPL协议，其内核采用模块化的设计，易于裁减，特别适合嵌入式系统的小型化要求，在嵌入式系统中占据了半壁江山。
本监控系统选用的处理器是SAMSUNG公司的一款中高端ARM9内核的CPU-S3C2410，其内建有MMU（内存管理单元），主频可达到 203MHz，运行嵌入式Linux2.4系统正好如鱼得水，不但保持了嵌入式系统小型化、低功耗、易携带的特点，又充分利用了Linux系统的内存、文 件、线程管理功能，大大方便了程序的开发和程序中多任务功能的实现。
2 监控系统结构
监控系统一般可分为实时监控和触发模式监控两种，可以根据具体的情况设计合适的监控方式，如果采用实时监控，将占用较多网络资源，成本相对较高，采用触发模式的运行成本较低，这里采用触发模式，监控系统结构见图1。
当遇异常情况后，触发监控终端拍摄图片，同时其内部的嵌入式控制模块和CDMA模块协同运作，完成Internet的接入（包括拨号、
PPP和CTP/IP协议的处理等），并把拍摄到的图片数据经打包后发送给控制中心主机，或发送给指定的E-mail地址，控制中心主机登录到
Internet上后运行服务器端软件就可以浏览由监控点发来的图片。
要能够正确运行一个操作系统，硬件方面至少应该包括CPU、内存和固态存储器、系统内部总线以及外设接口，具体硬件系统结构见图2。
SAMSUNG公司的S3C2410 CPU具有3个UART、1个RTC和触摸屏接口，还具有I2C总线、USB Host、USB Device等接口，充分满足了系统的需要，而且性价比极高，是一个很不错的选择。
由于剪裁后的Linux系统所占得存储空间非常小（只有几MB），我们选择Nor
Flash作为固体存储器，型号是E28F128J3A150，容量为16MB，通过16位数据总线与CPU交换数据，并利用其上端8MB空间
（00800000H-00ffffffH）开辟了一个jffs2文件存储系统，存储系统的配置文件。
64MB的SDRAM为2片K4S561632C，通过32位数据总线与CPU交换数据。
通过MAX3232C电平转换芯片和RTL8019网络芯片转换成一个RS-232接口和一个以太网接口，用串口线和以太网网线与PC机相连，组成可以交叉编译的开发环境。
通过CPU上集成的USB Host接口直接与USB摄像头连接，考虑到监控与控制模块接口的要求，选用USB1.1接口的红外线摄像头。
通过CPU上集成的UART接口直接与CDMA Modem模块相连接，选用价格适中的AnyData公司的DTGS-800 CDMA模块。
4 软件系统设计
4.1 控制终端程序设计
控制终端软件的核心是嵌入式Linux操作系统，一切功能的实现都基于Linux操作系统完成，Linux本身作为一个桌面系统，进入嵌入式操作系统领
域时，需要解决的问题主要包括硬件支持、提供二次开发的环境以及小型化（裁减内核）等，小型化的目的是在满足操作系统基本功能和用户特定需要的情况下，使
内核尽可能小，作为一个操作系统，Linux内核主要负责程序的管理与调度、内存的管理及对外设的驱动和管理等，由于Linux内核采用模块化的设计，很
多模块可以独立地加载或卸载，所以小型化就是对Linux内核重新编译，在编译时仔细地选择嵌入式设备所需要的功能模块，同时删除不需要的功能，这里只需
要串口驱动、USB摄像头接口驱动（包含USB Host，USB Core和USB
Device）还有拨号网络应用，还要支持PPP、TCP/IP网络协议，其他都可以删除掉，使系统运行所需要的内核显著减小至1Mb以内。
具体程序设计包括Bootloader启动代码、设备驱动程序（USB摄像头接口驱动程序、串口驱动程序）、拨号、PPP及TCP/IP协议处理，监控接收转发控制程序等。控制流程如图3所示。
a）系统加电后复位。
b）Bootloader初始化CPU、SDRAM、分配地址空间等。
c）Bootloader把Linux内核的压缩文件解压到SDRAM中，同时把控制权从Bootloader移交到Linux。Linux的内核有两种
运行方式可供选择。可以在Flash存储器上直接运行，也可以加载到内存中运行。Flash存储器运行方式就是把内核的可执行映像烧写到Flash存储器
上，系统启动时从Flash存储器的某个地址开始运行内核，进入SDRAM继续运行，这种做法能减少内存需要，实际上很多嵌入式系统都采用这种方法，内存
加载方式把内核的压缩文件存放在Flash存储器上，系统启动时自动读取压缩文件并在内存中解压，然后开始执行，这种方式相对较复杂，但运行速度更快，我
们采用的就是这种方式。
d）开始执行SDRAM中的代码，Linux内核初始化，完成堆栈，中断的分配等。
e）加载串口驱动模块和USB摄像头驱动模块，完成串口和USB口的初始化。
f）运行PPP拨号程序，通过CDMA网络与Internet进行连接，在Linux下的PPP包是专门为解决Modem拨号上网问题而编写的，并且是
公开源代码的，PPP拨号脚本程序主要是通过调用pppd和chat这两个应用程序，并通过AT指令实现对Modem的操作。
至此，已经建立了从图像采集到图像传输的完整的嵌入式监控系统，但是，作为一个嵌入式操作系统，他是为某一专门的用途而设计的。运行不同的用户应用程序，就可以实现用户要求的不同功能，生动地体现了嵌入式系统的灵活性。
我们运行的用户程序是一个无限循环的过程，控制终端在不断等待拍照请求，通过比较识别认为有请求后，CPU通过USB摄像头驱动控制摄像头拍照，同时接收图片并发送控制中心，或通过SMTP协议，发送到指定的Email地址，完成一次请求。
4.2 控制中心服务器程序设计
服务器端软件实现的主要功能是接收、保存和重由嵌入式终端发送过来的监控图片，控制中心主机通过拨号、带宽上网等方式登录到Internet上，注意
必须申请一个静态IP地址，使主机每次登录到Internet所获得的IP地址（互联网IP地址）不变，主机登录Internet后，即可运行服务器端软
件，服务器端程序设计主要包括网络通信、接收图片、保存图片、即时重显图片和察看图片，用户通过此软件可以方便地浏览由控制终端发来的图片。
另一种方案是不设置控制中心服务器，控制终端抓怕到的图片直接发送到指定的Email地址，这种方案容易管理，只需定期查收Email，清除Email存储空间即可，运行成本很低，但可靠性差。
5 结束语
利用无线网络与IT技术对传统监控领域进行革新，是市场的需要，在这个过程中，嵌入式系统因其体积小、处理能力强、支持网络服务等功能，无疑扮演了重要角色。
RTP/RTCP流媒体服务器技术研究
1 引言
随着互联网的飞速发展,流媒体技术的应用越来越广泛,从网上广播、电影播放到远程教学以及在线的新闻网站等都用到了流媒体技术。但现有公开文献 所报道的大多是利用现有的流媒体服务器来搭建一个流媒体服务系统，或者是针对流媒体数据的编码方式所进行的研究。本文对流媒体服务器技术的研究重点在于如 何建立一个服务器，并且在实现流媒体传输的两个基本协议RTP/RTCP的基础上构建一个基本的流媒体服务器。
2 流媒体技术简介
2.1 “流”的定义
现在网上传输视频、音频主要有下载（Download）和流式传输（Streaming）两种方式。流式传输是连续传送视/音频信号，当流媒体 在客户机播放时其余部分在后台继续下载。流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差,以 减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系。
在Internet中使用流式传输技术的连续时基媒体就称为流媒体，通常也将其视频与音频称为视频流和音频流。实现流式传输一般都需要专用服务器和播放器。
2.2 流媒体系统组件
流媒体是由各种不同软件构成的，这些软件在各个不同层面上互相通信，基本的流媒体系统包含以下3个组件：
播放器（Player），用来播放流媒体的软件。
服务器（Server），用来向用户发送流媒体的软件。
编码器（Encode），用来将原始的音频视频转化为流媒体格式的软件。
这些组件之间通过特定的协议互相通信，按照特定的格式互相交换文件数据。有些文件中包含了由特定编解码器解码的数据，这种编解码器通过特定算法压缩文件的数据量。
3 流媒体服务器的基本功能和服务方式
3.1 流媒体服务器的主要功能
（1）响应客户的请求，把媒体数据传送给客户。流媒体服务器在流媒体传送期间必须与客户的播放器保持双向通信（这种通信是必需的，因为客户可能随时暂停或快放一个文件）。
（2）响应广播的同时能够及时处理新接收的实时广播数据，并将其编码。
（3）可提供其他额外功能，如：数字权限管理（DRM），插播广告，分割或镜像其他服务器的流，还有组播。
3.2 流媒体服务器的服务方式
（1）单播。在客户端与媒体服务器之间建立一个单独的数据通道，从1台服务器送出的每个数据包只能传送给1个客户机。
（2）组播。在以组播技术构建的网络上，允许路由器一次将数据包复制到多个通道上。
（3）点播与广播。点播连接是客户端与服务器之间的主动的连接，在点播连接中，用户通过选择内容项目来初始化客户端连接，用户可以开始、停止、 后退、快进或暂停流。广播指的是用户被动地接收流，在广播过程中，数据包的单独一个拷贝将发送给网络上的所有用户，客户端接收流，但不能控制流。
4 构建流媒体服务器
4.1 RTP/RTCP协议简介
实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同 步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠 的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。
实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数 量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈 和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。
RTCP主要有4个功能:
（1）用反馈信息的方法来提供分配数据的传送质量，这种反馈可以用来进行流量的拥塞控制，也可以用来监视网络和用来诊断网络中的问题；
（2）为RTP源提供一个永久性的CNAME（规范性名字）的传送层标志，因为在发现冲突或者程序更新重启时SSRC(同步源标识)会变，需要一个运作痕迹，在一组相关的会话中接收方也要用CNAME来从一个指定的与会者得到相联系的数据流（如音频和视频）；
（3）根据与会者的数量来调整RTCP包的发送率；
（4）传送会话控制信息，如可在用户接口显示与会者的标识，这是可选功能。
4.2 RTP/RTCP工作过程
工作时，RTP协议从上层接收流媒体信息码流（如H.263），装配成RTP数据包发送给下层，下层协议提供RTP和RTCP的分流。如在 UDP中，RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制，它的最大包长只受下层协议的限制。
4.3 服务器的算法
服务器软件模型主要有两种，即并发服务器和循环服务器。循环服务器(Iterative Server)是指在一个时刻只处理一个请求的服务器。并发服务器(Concurrent Server)是指在一个时刻可以处理多个请求的服务器。事实上，多数服务器没有用于同时处理多个请求的冗余设备，而是提供一种表面上的并发性，方法是依 靠执行多个线程，每个线程处理一个请求，从客户的角度看，服务器就像在并发地与多个客户通信。
由于流媒体服务时间的不定性和数据交互实时性的请求，流媒体服务器一般采用并发服务器算法。本文构建了一个基本的流媒体服务器，能够同时响应多 个用户的请求，把本地硬盘流媒体文件或实时数据流（H.263格式）发送给用户。在应用中，把客户分为请求实时数据的实时客户和请求文件数据的文件客户两 类。主要算法为：
（1）打开设备，分配资源。当设备准备好时，创建一个RTP实时服务线程和一个RTCP实时服务线程。
（2）创建一个UDP套接字并将其绑定到所提供服务的地址之上。
（3）反复调用接收模块，接收来自客户的RTCP报告，根据其类型做出响应。对新实时客户的请求，把客户地址添加到实时服务的客户列表中，对新 文件客户的请求，则创建一个新RTP文件服务线程和一个新RTCP文件服务线程；对已经在服务中的客户则根据RTCP报告的内容调整服务。
RTP实时服务线程1：初始化客户列表和RTP首部。
RTP实时服务线程2：从设备读取媒体数据，把数据发送给实时服务列表中的客户。
RTP实时服务线程3：更新RTP首部和统计数据。
RTP实时服务线程4：计算延时，重复第二步。
RTCP实时服务线程1：初始化RTCP首部。
RTCP实时服务线程2：发送发送方报告给实时服务列表中的客户。
RTCP实时服务线程3：计算延时，重复第二步。
RTP文件服务线程1：初始化RTP首部。
RTP文件服务线程2.：从文件读取媒体数据，把数据发送给客户。
RTP文件服务线程3：更新已发送数据的统计信息，为生成发送方报告做准备。
RTP文件服务线程4：计算延时，调整发送速度，正常情况下开始重复第二步。
RTCP文件服务线程1：初始化RTCP首部，发送一个源描述(SDES)报文给客户。
RTCP文件服务线程2：根据已发送数据的统计信息生成发送方报告，发送给客户。
RTCP文件服务线程3：计算延时，正常情况下开始重复第一步。
5 流媒体服务器实现中应注意的问题
5.1 会话和流的两级分用
一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个 RTP分组在服务器端发送出去的时候总是要指定属于哪个会话和流，在接收时也需要进行两级分用，即会话分用和流分用。只有当RTP使用同步源标识 (SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来，才能够使用序列号(Sequence Number)和时间戳(Timestamp)对分组进行排序和正确回放。
5.2 多线程的管理
并发服务器模式要求用多线程来提供服务，所以多线程的管理十分重要。在本文构建的服务器中，不同客户的请求和反馈都由服务器的主线程处理，由于 实时数据的独有性，不同实时客户可以共用一个RTP实时服务线程和一个RTCP实时服务线程，这样可以大大减小服务器的负担，而每个文件客户由于请求的文 件不同，相应地对速度和开始时间的要求都可能不同，所以需要有自己独有的RTP文件服务线程和RTCP文件服务线程。
RTP服务线程负责把实时数据流发送给客户，RTCP服务线程根据RTP线程的统计数据，产生发送方报告给客户。RTP线程和RTCP线程之间 通过一段共享内存交互统计数据，对共享内存必须设置互斥体进行保护，防止出现错误读写。在这种方式下，服务器可以根据每个用户的不同请求和具体情况方便地 提供不同的服务。
5.3 时间戳的处理
时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间 (Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增 长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。
RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。
在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值。
5.4 媒体数据发送速度的控制
由于RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送媒体数据的速度。对来自设备的实时数据可以采 取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的设置相对容易。对已经录制好的本地硬盘上的媒体文件，以H.263格式的文件为 例，由于文件本身不包含帧率信息，所以需要知道录制时的帧率或者设置一个初始值，在发送数据的时候找出发送数据中的帧数目，根据帧率和预置值来计算时延， 以适当的速度发送数据并设置时间戳信息。
5.5 多种流同步
RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输， 这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据 源的规范名(Canonical Name），尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪些流是有关联的。而发送方报告报 文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那 个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中的时间戳 值映射为另一个流中的时间戳值。
6 结论
流媒体技术的应用日益广泛，对流媒体技术的研究具有很大的实际意义,本文通过对RTP/RTCP协议的研究，分析流媒体服务器的一般功能和结 构，给出构建一个基本的流媒体服务器的实现方案，实验证明可以同时满足多个实时和文件客户的要求,并已经应用于一个远程监控系统中。
RFC3550(RTP) 5.3.1-6.3.4(主要是RTCP)翻译
5.3.1 RTP头部扩展
下面给出了一个扩展机制以允许某些实现要求能够试验在RTP数据包头中承载额外信息新的负载格式无关的功能。这个机制被设计为其他未扩展的实现能够忽略这些头部扩展。
注 意，这个头部扩展只是打算用作某些受限用途。此机制的大多潜在使用最好以前面章节描述的方式来做。例如，对固定头部的一个策略相关的扩展处理起来更廉价， 因为这并不是有条件的或可变的位置。一特定负载要求的额外信息“应当不”使用这个头部扩展，而是“应当”放在包的负载部分。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |
如 果RTP头的X比特为1，“必须”在RTP头部可能的CSRC列表之后追加一变长的头部扩展。头部扩展包含16比特长度域给出了除扩展头部前4字节之外扩 展头部的32比特字的数目（因而0是合法的）。最多允许一个扩展头部追加到RTP头部。为了允许多个互操作实现独立试验不同的头部扩展，或者允许某特定实 现试验多余一种的头部扩展，头部扩展的头16比特被留作区分标识符或者参数。这16比特的格式将被特定实现采用的策略规范所定义。RTP规范自身并没有定 义任何头部扩展。
6. RTP控制协议--RTCP
RTP控制协议(RTCP)向会话中所有参与者周期性发送控制包，利用与数据包相同的分发机制。下层协议必须提供数据包和控制包的多工，例如用不同的UDP端口。RTCP完成四个功能：
（1） 基本功能是提供数据传输质量的反馈。这是RTP作为一种传输协议整体的一部分，且与其他传输协议（见第10节关于拥塞控制的要求）的流量和阻塞控制相关。 反馈可以直接用于自适应编码[18,19]。IP多播的实验还表明它是从接收机得到反馈信息以诊断传输故障的关键。向所有成员发送接收反馈可以使"观察员 "评估相关问题是局部的还是全局的。类似IP多播的分发机制，使某些实体，诸如没有加入会话的网络业务提供者，接收到反馈信息并扮演诊断网络故障的第三方 监视器。反馈功能通过 RTCP发射机和接收机报告提供，在第6.4节描述。
（2）RTCP为每个RTP源携带一个持久性传输层识别 符，称为正规名字或CNAME，见第6.5.1节。由于当发生冲突或程序重启时SSRC可能改变，所以接收机要求CNAME以跟踪每个成员。接收机还可能 用CNAME来关联一系列相关RTP会话期中来自同一个成的多个数据流,例如同步语音和图像。媒体间同步还要求数据发送机在其RTCP包中包含NTP和 RTP时间戳。
（3）头两个功能要求所有成员都发送RTCP包，因此必须控制速率以使RTP会话成员数目可扩展到大的数量。通过让每个成员向所有成员发送控制包，各个成员都可以独立地观察会话中成员数目。此数目用来计算发包速率，见第6.2节。
（4） 第四个可选的功能是传递少量的会话控制信息，例如在用户界面上显示的成员标识。这最可能在"松散控制"的会话中起作用。在"松散控制"会话里，成员可以不 经过资格控制和参数协商而加入或退出会话。RTCP是一个联系所有成员的方便通路，但不要期望它支持具体应用所需的所有控制信息传递要求。这可能需要本文 档范围之外的一个高层的会话控制协议。
在所有环境中，尤其是IP多播环境，都“应当”使用功能1-3。RTP应用设计者“应当”避免仅使用单播模式，这将使得成员数目不具有扩展性。在类似接收机反馈不可行的单向链路这样情形下，发送机和接收机“可能”独立控制RTCP的传输（如6.2节所述）。
非 正规注解：在称作源相关多播（Source-Specific Multicast, 简称SSM）这个多播路由方式下，每个“通道”（源地址、组地址对）只有一个发送机，并且接收机（除了通道源）不能用多播来和通道其他成员联系。本处建议 只是通过6.2节的完全关闭接收机RTCP来适应SSM。将来要针对SSM调整RTCP以维护接收机反馈。
6.1 RTCP报文格式
本规格定义了多个RTCP报文格式以承载不同的控制信息：
SR：发送机报告，描述作为活跃发送机成员的发送和接收统计数字
RR：接收机报告，描述非活跃发射机成员，或是与SR联合使用以描述活跃发射机的接收统计数字
SDES：源描述，包括CNAME
BYE：表示结束参与
APP：应用相关的功能
每 个RTCP报文开始于与RTP数据包类似的固定头部，随后是一块结构化单元,它随报文类型不同而长度“可能”不同，但是总以32比特边界处终止。对齐要求 和长度域使RTCP包可“堆栈”。可以将多个RTCP包不加任何间隔地拼接成一个复合RTCP包在一个下层协议(如UDP)中发送。复合包中没有明确给出 独立的RTCP包的数目，因为下层协议有会提供一个总体长度以指出复合包的结束之处。
复合包中的每个RTCP单包可以单独处理，而无需考虑包或包组合的顺序。然而,为了实现某些协议功能，添加以下限制:
- 接收统计数字(SR或RR)只要带宽限制允许就应当发送，以最大化统计信息的分辨率。因此每个周期性发送的复合RTCP包必须包含一个报告包。
- 新的接收机需要尽可能迅速地接收一个源的CNAME以标识此源并且为嘴唇同步（lip-sync）之类目的启动相关的媒体。所以每个复合RTCP包必须还包括SDES CNAME除非这个复合RTCP包按照第9.1节描述的那样分割并部分加密。
- 必须限制在复合包第一个包可能类型的数目，以增加在第一个字中常数比特的数目，还可以增加成功校验RTCP包的有效性的可能性以区分误传的RTP包或其他无关包。
因此，所有RTCP包必须在至少包含两个单包的复合包中传输，具有以下推荐格式：
加密前缀：当且仅当复合包按照9.1节被加密时，对每个RTCP复合包“必须”加随机32比特的前缀。如果加密要求填充，则填充“必须”增加到复合包的最后一个包。
SR或RR：复合包中的第一个RTCP包必须是一个报告包，以方便附录A.2所述的头部校验。即使没有数据发送和接收数据，此时“必须”发送空的RR包；或者复合包中其他的唯一包是BYE包。
附加的RR：若被报告的接收统计源数目超过一个SR/RR包最大允许的31个，附加的RR包“应当”跟在最初的报告包后面。
SDES：每个复合RTCP包“必须”包括一个含有CNAME项的SDES包，除非9.1节特别说明的情形。如果特定应用要求的话，在带宽限制前提下（见6.3.9节），“可以”可选地报刊其他源描述项。
BYE或APP：其他RTCP包类型，包括将来定义的，“可以”按照任何顺序，除了BYE“应当”是一个给定SSRC/CSRC的最后一个包。同一包类型“可以”出现不止一次。
为 了能正确估计（见6.2节）每个参数者的RTCP带宽，一个RTP参与者“应当”在每个报告间隔仅发送一个复合RTCP包，除非复合RTCP包按照9.1 节分割以部分加密。如果源数目过多以至于不能将所有需要的RR放入单个RTCP包而不超出网络路径的最大传输单元（MTU），则每个间隔“应当”只把不超 过MTU的一部分放入复合包。这个子集“应当”在多个间隔时循环选择以使得报告所有的源。
“建议”转换器和混合器在任何可能的时候，把其转发的从 多个源来的独立的RTCP包组合经一个复合包以分摊报文过载（见第7节）。图1给出了一个混合器可能产生的RTCP复合包的例子。如果一个复合包总长度将 操作网络MTU，“应当”将其分片成多个更短的复合包在下层协议独立的包中传输。这不会损害RTCP带宽估计，因为每个复合包代表至少一个不同的参与者。 注意，每个复合包“必须”开始与一个SR或RR包。
一个实现“应当”忽略它不能识别类型的RTCP包。其他RTCP包类型可能按照第15节描述注册到IANA。
if encrypted: random 32-bit integer
|
|[--------- packet --------][---------- packet ----------][-packet-]
|
| receiver chunk chunk
V reports item item item item
--------------------------------------------------------------------
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
--------------------------------------------------------------------
| |
|<----------------------- compound packet ----------------------->|
|<-------------------------- UDP packet ------------------------->|
#: SSRC/CSRC identifier
Figure 1: Example of an RTCP compound packet
6.2 RTP传输间隔
RTP 被设计为允许一个应用涉及的会话尺寸从少量参与者到上千数目自动地扩展。例如，音频会议中的数据流量是自限制的，因为同时只有一到两个人同时说话，所以在 任何给定链路上的多播数据速率相对于参与者数目而言是不变的。然而控制信息流量并不是自限制的。如果每个参与者以一个恒定速率发送接收报告，控制信息流量 将随着参与者数目线性增长。因而，必须通过动态计算RTCP包传输间隔降低发送速率。
对每个会话，假设数据流量取决于参与者分享的一个称为“会话 带宽”的总计限制。此带宽可能被网络保留。如果没有保留，可能有取决于环境的其他约束来设置此会话使用带宽的“合理的”最大值，这就是会话带宽。会话带宽 可能基于本会话的价格或可用网络带宽的预先知识来选择。这在某种程度上与媒体编码无关，但是会话带宽可能限制了编码的选择。会话带宽常常就是同时活跃的发 送机名义上的（nominal）带宽之和。对电话会议音频，这个数字一般是一个发送机的带宽。对分层编码（layered encodings），每一层是一个独立的RTP会话，具有自己的会话带宽参数。
会话带宽参数期望在一个会话管理应用被一个媒体应用调用时提供。但是媒体应用“可以”基于单个发送机数据带宽设置一个默认值。应用还“可以”基于多播范围规则或其他标准强制带宽限制。所有参与者都“必须”使用相同的会话带宽值，这样就能计算出相同的RTCP间隔。
控制和数据流量的带宽计算包括了低层传输和网络协议（例如UDP和IP），因为资源预留系统需要知道它们。应用还期望知道使用了这些协议中的那些。链路层头部排除在计算之外，因为报文在传输过程中将被用不同的链路层头部封装。
控 制流量应当被限制到整个会话带宽的一个已知的小的比例：小是为了不至于损害传递数据这一主要功能；已知是为了给资源预留协议带宽规格时能考虑进控制流量， 并且每个参与者能独自计算自己分享的那部分带宽。控制流量带宽是会话带宽中除数据流量外的那部分。由RTCP占用的会话带宽比例“建议”固定为5%。“建 议”1/4的RTCP带宽给发送数据的的参与者，这样在一个包含大量接收机但少量发送机的会话中，新加入的参与者能更快的收到来自发送机的CNAME。当 发送机在所有参与者所占比例超过1/4时，发送机应获得相应比例的RTCP带宽。虽然在间隔计算中这些值以及其他常量并不重要，但会话中所有的参与者“必 须”使用相同的值以计算出相同的间隔。因而，在特定策略中这些常量“应当”是固定的。
一个策略“可以”规定控制流量带宽是会话的一个独立参数而不是会话带宽的一个严格的比例。使用独立参数使得速率自适应应用能设置RTCP带宽以与比会话带宽参数规定的最大带宽小的一个“典型的”数据带宽保持一致。
策 略还“可以”进一步规定控制流量带宽分解成两个独立的会话参数分别针对活跃数据发射机和其他参与者：我们称这两个参数为S和R。按照“1/4 RTCP带宽分配给数据发射机”的建议，这两个参数的默认值“建议”分别为1.25%和3.75%。当发射机比例超过S/(S+R)，发送机获得(S+ R)中相应比例。使用两个参数使得如下成为可能：对特定会话通过设置非数据发射机RTCP带宽为0，同时保持数据发射机RTCP带宽非0，RTCP接收报 告完全关闭，而发送机报告仍然被发送以使能媒体间同步。“不建议”不关闭RTCP接收报告，因为第6节开始的功能列表需要它们。然而，这样做在一下情形下 可能是合适的：单向链路上的系统，或者不需要接收质量或存在性反馈的反馈的会话，或是有其他办法避免拥塞的会话。
计算出来的符合RTCP包的传输 间隔还“应当”有一个下界以避免在参与者数目较少而流量不平滑时报文突发而超过了允许的带宽。这还防止了在网络部分瞬变时报告间隔变得过小而延误了网络恢 复时后的调节。在应用启动和发送第一个符合RTCP包之间“应当”强制一个延迟，这样就有时间受到从其他参与者来的俄RTCP包，从而报告间隔能更快地趋 向正确值。此延迟“可以”设置为最小间隔的一半以更快地通告新参与者的键入。固定的最小间隔的“推荐”值是5秒。
一个实现“以”把最小RTCP间隔变得更小以适合会话带宽参数，有以下限制：
- 对多播会话，仅活跃数据发射机“可以”使用更小的最小值来计算符合RTCP包传输间隔。
- 对单播会话，非活跃数据发射机也“可以”使用更小的值，发送第一个复合RTCP包之前的延迟“可以”是0。
- 对所有会话，计算参与者超时间隔（见6.3.5节）时“应当”使用上述固定的最小值，这样那些不使用更小值的实现就不会被其他参与者过早地认为超时。
- 更小值（以秒计）“推荐”采用360除以会话带宽（单位kb/s）。这个值在带宽超过72kb/s时小于5秒。
在6.3节和附录A.7中描述的算法符合本节提出的目标。此算法计算出发送RTCP复合包的间隔，并在所有参与者间分配允许的控制流量带宽。这允许应用在如标识所有参与者是重要的这样的小会话能快速响应，并且能自动调节到更大会话。此算法具有如下特征：
- 计算出的RTCP包间隔随组内成员数目线性增涨。正是这个线性使得所有成员的控制流量总和为常量。
- 实际RTCP包间隔在计算值[0.5,1.5]倍范围内随即选取，以避免不期望的所有参与者同步[20]。加入会话后的第一个RTCP包延迟是最小RTCP间隔[0,0.5]倍范围内随机值。
- 计算出复合RTCP包的平均尺寸的估计值，包括所有发送和接收的，以自动适应承载的控制信息量的变化。
- 既然计算出的间隔依赖于观察到的组成员数目，可能存在不希望的启动效应：在一新用户加入一正退出的会话，或多个用户同时加入一新会话。这些新用户刚开始对 组规模估计不正确，这样它们的RTCP传输间隔非常短。这个问题在多个用户同时加入会话时比较明显。为处理这种情况，应用了一个被称为“timer reconsideration”的算法。此算法实现了一个简单的补偿(back-off)机制使得用户在组规模增长时阻止发送RTCP包。
- 当用户离开会话，以BYE或超时，组规模减小，这样计算出的间隔应当减小。“reverse reconsideration”算法能够使得成员更快地减小其间隔以对组规模减小作出反应。
- BYE包与其他RTCP包处理不同。当用户离开组时并希望发送BYE包时，它可以在其安排的下一个RTCP包之前发送。但是，BYE包发送遵循一个补偿算法以避免大量成员同时离开会话时BYE包的泛滥。
这个算法可以用于那些允许所有参与者发送数据的会话。在此情形下，会话带宽参数是单个发送机带宽乘以参与者总数，并且RTCP带宽占其中5%。
此算法的细节在接下来给出。附录A.7给出了一个示范实现。
6.2.1 会话成员数目的维护
RTCP 包间隔的计算依赖于对参与会话的站点数目的估计。新站点被计入当它们被听到时，并且“应当”为每个新站点在以SSRC或CSRC标识符索引的表（见8.2 节）中创建相应条目以跟踪它们。新条目“可以”被认为无效，直到收到多个包含新SSRC的报文被（见附录A.1），或者收到一个包含对应SSRC的 CNAME的SEDS RTCP包。当收到RTCP BYE包时，相应SSRC的条目“可以”被删除，除非此后一些散乱的数据包到达并导致重新创建此条目。替代地，“应当”标记此条目收到BYE并在适当延迟 之后删除它。
一参与者“可以”标记另一站点非活跃，或如果条目无效则删除它，如果几个RTCP报告间隔（“推荐”5s）内没有收到RTP或 RTCP包。这为丢包提供了某种健壮性。所有站点必须使用相同的乘数且必须计算出大指向等的RTCP报告间隔，这个超时才能正常工作。因而，特定策略“应 当”固定此乘数。
对大量成员参与的会话，维护一个存储着SSRC标识符和相应状态信息的表可能并不可行。一个实现“可以”按照[21]所述那样使 用SSRC抽样（sampling）以减小存储需求。一个实现“可以”使用其他类似的算法。一个关键要求就是这样的算法“应当不”大体上低估组规模，然而 “可以”高估。
6.3 RTCP包发送和接收的规则
这儿概述了怎样发送和接收后如何处理RTCP包的规则。一个允许多播环境或多 点单播（multipoint unicast）环境的实现“必须”符合6.2节的要求。这样的实现“可以”使用本节定义的算法以符合那些要求，或者“可以”使用其他相同性能或更高效的 算法。一个限制为两方单播的实现“应当”仍然使用RTCP传输间隔随机值以避免不期望的多实例操作的同步，但是“可以”忽略6.3.3，6.3.6和 6.3.7节中的“timer reconsideration”和“reverse reconsideration”算法。
为实施这些规则，一个会话参与者必须维护如下几个状态信息：
tp：最近一次发送RTCP包的时间；
tc：当前时间；
tn：下一个计划发送RTCP包的时间；
pmembers：最经一次计算tn时估计的会话成员总数；
members：会话成员总数的最新估计；
senders：会话中发射机总数的最新估计；
trcp_bw：目标RTCP带宽，即本会话中所有成员的RTCP包使用的总带宽，单位字节每秒。这是应用启动时提供给应用的“会话带宽”的一个指定的比例。
we_sent：一个标记，如果应用从上2个RTCP报告依赖发送过数据则为真。
avg_rtpc_size：本参与者发送和接收的所有RTCP复合包的平均尺寸，单位字节。此尺寸包含了低层传输和网络层协议头部（例如UDP和IP），如6.2节所述。
initial：一个标记，如果一个应用还没有发送第一个RTCP包则为真。
这些规则大多利用了在包传输期间“计算出的间隔”。此间隔在下面章节中描述。
6.3.1 计算RTCP传输间隔
为了保持可扩展性，会话参与者的包间平均间隔应当随组规模扩展。此间隔被成为计算出的间隔（calcutated interval）。它有以上描述的状态的某些部分来导出。计算出的间隔T按照如下方式决定：
1. 如果发送机数目少于或等于总数的25%，间隔T依赖于参与者是否为发射机（基于变量we_sent）。如果是发射机（we_sent为真），常量C被设置 为平均RTCP包尺寸（avg_rtcp_size）除以25%的RTCP带宽（rtcp_bw），常量n被设置为发送机数目。如果we_sent为假， 常量C被设置为平均RTCP包尺寸除以75%的RTCP带宽。常量n被设置为接收机数目（成员总数减去接收机数目）。如果发送机数目超过25%，发送机和 接收机一起处理：常量C被设置为平均RTCP包尺寸除以总的RTCP带宽，n被设置为成员总数。如6.2节所述，一个RTP策略“可以”规定RTCP带宽 被两个独立的参数（称为S和R）分别针对发射机和接收机。在此情形下，25%比例变为S/(S+R)，75%比例变为R/(S+R)。注意如果R为0，则 发送机比例不过超过S/(S+R)，实现必须避免被0除。
2. 如果参与者还没有发送第一个RTCP包（变量initial为真），常量Tmin设置为2.5秒，否则设置为5秒。
3. 决定性的计算出的间隔Td设置为max(Tmin, n*C)。
4. 计算出的间隔T设置为[0.5,1.5]倍Td之间均匀分布的一个随机值。
5. T除以e-3/2=1.21828以补偿，因为timer reconsideration算法计算出的RTCP带宽的均值低于期望的平均值。
上述过程产生的间隔T是随机的，但平均意义上将至少25%的RTCP带宽给了发射机。如果发射机占总数的1/4多，在平均意义上，上述过程在所有参与者间分配相等的带宽。
6.3.2 初始化
一 旦加入会话，参与者这样初始化以下值：tp为0，tc为0，senders为0，pmembers为1，members为1，we_send为假， rtcp_bw为会话带宽中指定的比例，initial为真，avg_rtcp_size为本应用稍后将构造的第一个RTCP包的可能尺寸。接下来计算 T，并且第一个包设置计划在时间点tn=T处。这意味着一个传输定时器设置为在时间点T超时。注意，一个应用“可以”用任何它希望的方式实现这个定时器。
参与者增加自己的SSRC到成员表。
6.3.3 收到一个RTP或者非BYE RTCP包
当收到来自一个在成员表中不存在其SSRC的参与者的一个RTP或RTCP包，SSRC增加到此表，并且一旦按照6.2.1节所述那样校验此参与者通过就更新参数members。对校验过的RTP包中的每个CSRC执行同样的过程。
当收到来自一个在发送机表中不存在其SSRC的参与者的一个RTP包，SSRC增加到此表，并且更新senders的值。
对收到的每个复合RTCP包，avg_rtcp_size这样更新：
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
上式中packet_size是刚收到的RTCP包的尺寸。
6.3.4 收到一个RTCP BYE包
除了6.3.7描述的情形之外，如果收到一个RTCP BYE包，按照成员表检查包的SSRC。如果存在，则从表中删除此条目并且更新members值。再按照发射机表检查。如果存在，则从表中删除此条目并且更新senders值。
进一步，为了使得RTCP包发送速率更适应组规模的变化，当收到一个将导致members减少到小于pmembers的BYE包时，“应当”执行下面的“reverse reconsideration”算法：
- tn的值按照如下公式更新：
tn = tc + (members/pmembers) * (tn - tc)
- tp的值按照如下公式更新：
tp = tc - (members/pmembers) * (tc - tp).
- 下一个RTCP包发送时间点被重新安排到tn，这之前的计划时间点更早。
- pmembers的值设置为等于members
本算法并没有防止如下情形：大多数而不是全部参与者同时离开一个大会话时，计算出的过早的超时就会使得估计出的组规模不正确地短暂性地降为0。本算法并没有使得估计值更快地回归到正确值。这种情形很少见，并且导致的后果也没什么害处，所以这个问题被认为不需要关注。
RTP协议/RTP控制协议RTCP （补充）
RTP协议
实时传输协议RTP提供了实时信息的端对端传输业务,如交互的语音和图象;这些业务包括负载类型识别,序列编号,加入时间标志,传输监视.典型的应用是在UDP层上传输RTP包,以利用它的复用和总和检测业务.
RTP包括两个紧密相关的部分:
- 实时传输协议(RTP),传输有实时特性的信息;
- RTP控制协议(RTCP),监视业务质量和传输对话中成员的信息.
RTP包头
RTP头有以下格式:
0 1 2 3
0 1 23 4 5 6 7 89 0 1 2 3 45 6 7 8 90 1 2 34 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 序列号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 时间标志 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 同步源(SSRC)识别符 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 有贡献源(CSRC)识别符 |
| ... ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTP包头格式
前12个字节出现在每个RTP包中,仅仅在被混合器插入时,才出现CSRC识别符列表.这些域有以下意义:
版本(V):2比特 此域定义了RTP的版本.此协议定义的版本是2.(值1被RTP草案版本使用,值0用在最初"vat"语音工具使用的协议中.)
填料(P):1比特 若填料比特被设置,此包包含一到多个附加在末端的填充比特,不是负载的一部分.填料的最后一个字节包含可以忽略多少个填充比特.填料可能用于某些具有固定长度的加密算法,或者在底层数据单元中传输多个RTP包.
扩展(X):1比特 若设置扩展比特,固定头(仅)后面跟随一个头扩展.
CSRC计数(CC):4比特 CSRC计数包含了跟在固定头后面CSRC识别符的数目.
标志(M):1比特 标志的解释由具体协议规定.它用来允许在比特流中标记重要的事件,如帧范围.规定该标志在静音后的第一个语音包时置位.
负载类型(PT):7比特 此域定义了负载的格式,由具体应用决定其解释.协议可以规定负载类型码和负载格式之间一个默认的匹配.其他的负载类型码可以通过非RTP方法动态定义. RTP发射机在任意给定时间发出一个单独的RTP负载类型;此域不用来复用不同的媒体流.
序列号:16比特 每发送一个RTP数据包,序列号加一,接收机可以据此检测包损和重建包序列.序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难.
时间标志:32比特 时间标志反映了RTP数据包中第一个比特的抽样瞬间.抽样瞬间必须由随时间单调和线形增长的时钟得到,以进行同步和抖动计算.时钟的分辨率必须满足要求的 同步准确度,足以进行包到达抖动测量.时钟频率与作为负载传输的数据格式独立,在协议中或定义此格式的负载类型说明中静态定义,也可以在通过非RTP方法 定义的负载格式中动态说明.若RTP包周期性生成,可以使用由抽样时钟确定的额定抽样瞬间,而不是读系统时钟.例如,对于固定速率语音,时间标志钟可以每 个抽样周期加1.若语音设备从输入设备读取覆盖160个抽样周期的数据块,对于每个这样的数据块,时间标志增加160,无论此块被发送还是被静音压缩.
时间标志的起始值是随机的,如同序列号.多个连续的RTP包可能由同样的时间标志,若他们在逻辑上同时产生.如属于同一个图象帧.若数据没有按照抽样的
顺序发送,连续的RTP包可以包含不单调的时间标志,如MPEG交织图象帧.
SSRC:32比特 SSRC域用以识别同步源.标识符被随机生成,以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符.尽管多个源选择同一个SSRC识别 符的概率很低,所有RTP实现工具都必须准备检测和解决冲突.若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源.
CSRC列表:0到15项,每项32比特 CSRC列表识别在此包中负载的有贡献源.识别符的数目在CC域中给定.若有贡献源多于15个,仅识别15个.CSRC识别符由混合器插入,用有贡献源的 SSRC识别符.例如语音包,混合产生新包的所有源的SSRC标识符都被陈列,以期在接收机处正确指示交谈者.
RTP头扩展
RTP提供扩展机制以允许实现个性化:某些新的与负载格式独立的功能要求的附加信息在RTP数据数据包头中传输.设计此方法可以使其它没有扩展的交互运行忽略此头扩展.RTP头扩展的格式如下图所示.
0 1 2 3
0 1 2 34 5 6 78 9 0 1 2 3 4 56 7 8 90 1 23 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 由协议定义 | 长度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 头扩展 |
| ... ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
若RTP头中的扩展比特位置1,则一个长度可变的头扩展部分被加到RTP固定头之后,.头扩展包含16比特的长度域,指示扩展项中32比特字的个数,不包 括4个字节扩展头(因此零是有效值).RTP固定头之后只允许有一个头扩展.为允许多个互操作实现独立生成不同的头扩展,或某种特定实现有多种不同的头扩 展,扩展项的前16比特用以识别标识符或参数.这16比特的格式由具体实现的上层协议定义.基本的RTP说明并不定义任何头扩展本身.
RTP控制协议RTCP
RTP控制协议(RTCP)向会议中所有成员周期性发送控制包,利用与数据包相同的传输机制.底层协议必须提供数据包和控制包的复用,例如用不同的UDP端口.RTCP执行四个功能.
- 基本功能是提供数据传输质量的反馈.这是RTP作为一种传输协议的主要作用,它与其他协议的流量和阻塞控制相关.反馈可能对自适应编码有直接作用,但是 IP组播的实验表明它对于从接收机得到反馈信息以诊断传输故障也有决定性作用.向所有成员发送接收反馈可以使"观察员"评估这些问题是局部的还是全局的. 利用类似多点广播的传机制,可以使某些实体,诸如没有加入会议的网络网络业务观察员,接收到反馈信息并作为第三类监视员来诊断网络故障.反馈功能通过 RTCP发射机和接收机报告实现.
- RTCP为每个RTP源传输一个固定的识别符,称为标称名或CNAME.由于当发生冲突或程序重启时SSRC可能改变,接收机要用CNAME来跟踪每个成 员.接收机还要用CNAME来关联一系列相关RTP会话期中来自同一个成员的多个数据流,例如同步语音和图象.
- 头两个功能要求所有成员都发送RTCP包,因此必须控制速率以使RTP成员数可以逐级增长.通过让每个成员向所有成员发送控制包,各个成员都可以独立地观察会议中所有成员的数目.此数目可以用来估计发包数率.
- 第四个可选的功能是传输最少的会议控制信息,例如在用户接口中显示的成员识别.这最可能在"松散控制"的会议中起作用,在"松散控制"会议里,成员可以不 经过资格控制和参数协商而加入或退出会议.RTCP作为一个延伸到所有成员的方便通路,必须要支持具体应用所需的所有控制信息通信.
- 在RTP用于IP多点广播时,功能1-3是强制的,在所有情况下都推荐使用.建议RTP应用开发商避免使用只能用于单向广播而不能递增到多用户的方法.
RTCP包格式
这部分定义了几个RTCP包类型,可以传送不同的控制信息:
- SR:发射机报告,描述作为活跃发射机成员的发送和接收统计数字;
- RR:接收机报告,描述非活跃发射机成员的接收统计数字;
在本文中详细介绍SR和RR.
每个RTCP包的开始部分是与RTP数据包相类似的固定部分,随后是一块结构化单元,它随负载类型不同长度发生变化,但是总以32比特终止.对齐要求和长 度域使RTCP包可"堆栈",既可以将多个RTCP包形成一个复合RTCP包,在底层协议(如UDP)中,通常都是将复合包作为一个包传输的.
复合包中的每个RTCP单包可以单独处理,而无需考虑包复合的顺序.然而,为了实现某些协议功能,添加以下限制:
- 接收统计数字(SR或RR),经常作为带宽限制值,尽可能达到统计数字的最大分辨率,因此每个周期发送的RTCP包必须包含一个报告包.
- 必须限制首次在复合包中出现的包类型数目,以增加在第一个字中常数比特的数目,这样可以增加RTCP包的有效性,以区分误传的RTP包和其他无关包.
因此,所有RTCP包必须在至少包含两个单包的复合包中传输,具有以下推荐格式:
- 加密前缀:当且仅当复合包被加密时,对每个RTCP复合包加32比特的前缀.
- SR或RR:复合包中的第一个RTCP包必须是一个报告包.即使没有数据发送和接收,此时发送空的RR包,或者复合包中其他的唯一包是BYE包,也必须发送报告包.
- 附加的RR:若被报告的接收统计源数目超过SR/RR包中最大允许的31个,附加的RR必须跟在最初的报告包后面.
RTCP发送机制
RTCP包发送机制:在两次RTCP报文之间,若端点没有发出任何RTP报文,则端点此次发送RR(接收报文),否则,端点发送SR(发送报文),RTCP包每秒发送一次.
发射机和接收机报告
RTP接收机利用RTCP报告包提供接收质量反馈,根据接收机是否同时还是发射机RTCP包采取两种不同的形式.发射机报告(SR)和接收机报告(RR)格式中唯一的不同,包括包类型码,在于发射机报告包括20字节活跃发射机专有的发射机信息部分.
SR包和RR包都包括零到多个接收报告块,针对该接收机发出上一个报告块后接收到RTP包的起始同步源,每个源一个块.在CSRC列表中陈列的有贡献源不 发送报告块.每个接收报告块提供从此块中指示的特定源接收到数据的统计数字.由于在SR/RR包中最多允许31接收报告块,可以在最初的SR或RR包之后 堆栈附加的RR包,包含在上一个报告以来的间隔内收听到的所有源的接收报告.
以下部分定义了两种报告的格式.
SR:发射机报告RTCP包
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=SR=200 | 长度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 发送者的SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| NTP 时戳, 高字节 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP 时戳, 低字节 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP 时戳 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 发送的报文数 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 发送的字节数 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (第一个源的SSRC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 丢包率 | 累计包丢失数 |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 接收到的扩展的最高序列号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 到达间隔抖动 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 上一SR报文 (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 自上一SR的时间(DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (第二个源的SSRC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 特定协议扩展 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
发射机报告包由3部分组成,若定义,可能跟随第4个面向协议的扩展部分.
第一部分,8字节长.该域有以下意义:
版本(V):2比特 RTP版本识别符,在RTCP包内的意义与RTP包中的相同.此协议中定义的版本号为2.
填料(P):1比特 若设置填料比特,该RTCP包在末端包含一些附加填料比特,并不是控制信息的基本部分.填料的最后一个比特统计了多少个字节必须被忽略.某些有固定块大小 的加密算法可能需要填料比特.在复合RTCP包中,复合包作为一个整体加密,填料比特只能加在最后一个单包的后面.
接收报告块计数(RC):5比特 该包中所含接收报告块的数目.零值有效.
包类型(PT):8比特 包含常数200,用以识别这个为RTCP SR包.
长度:16比特 以32比特字为单位,该RTCP包的长度减一,包括头和任何填料.(偏移量1保证零值有效,避免了在扫描RTCP包长度时可能发生的无限循环,同时以32比特为单位避免了对以4为倍数的有效性检测.)
SSRC:32比特 SR包发起者的同步源标识符.
第二部分,发射机信息,20比特长,在每个发射机报告包中出现.它概括了从此发射机发出的数据传输情况.此域有以下意义:
NTP时间标志:64比特 指示了此报告发送时的壁钟时刻,它可以与从其它接收机返回的接收报告块中的时间标志结合起来,测量到这些接收机的环路时沿.接收机必须期望此时间标志的准 确度远低于NTP时间标志的分辨率.测量的不确定度不可知,因此也无需指示.某个发射机,能够跟踪逝去时间但是无法跟踪壁钟时间,可以用加入会议后的逝去 时间代替.假定该值小于68年,则最高比特为零.允许用抽样时钟估计逝去壁钟时间.无法用壁钟时间或逝去时间的可以设置此项为零.
RTP时间标志:32比特 与以上的NTP时间标志对应同一时刻,但是与数据包中的RTP时间标志具有相同的单位和偏移量.这个一致性可以用来让NTP时间标志已经同步的源间进行媒 体内/间同步,还可以让与媒体无关的接收机估计标称RTP时钟频率.注意在大多数情况下此时间标志不等于任何临近的RTP包中的时间标志.然而,通过 "RTP时间标志计数器"和"由在抽样点上周期性检测壁钟时间得到的实际时间"两者之间的关系,可以通过相应的NTP时间标志计算得到此RTP时间标志.
发送的报文数:32比特 从开始传输到此SR包产生时该发射机发送的RTP数据包总数.若发射机改变SSRC识别符,该计数器重设.
发送的字节文数:32比特 从开始传输到此SR包产生时该发射机在RTP数据包发送的字节总数(不包括头和填料).若发射机改变SSRC识别符,该计数器重设.此域可以用来估计平均负载类型数据速率.
第三部分零到多个接收报告块,块数等于从上一个报告以来该发射机收听到的其它源的数目.每个接收报告块传输关于从某个同步源来的数据包的接收统计信息.若某个源因冲突而改变其SSRC识别符,接收机并不延续统计数字.这些统计数字是:
SSRC_n(源识别符):32比特 在此接收报告块中信息所属源的SSRC识别符.
丢包率:8比特 自从前一SR包或RR包发射以来,从SSRC_n传来的RTP数据包的损失比例,以固定点小数的形式表示,小数点在此域的左侧,等于将损失比例乘256后 取整数部分.该值定义为损失包数被期望接收的包数除,在下一段中定义.若由于复制而导致包损为值,损失比例值设为零.注意在收到上一个包后,接收机无法 告之以后的包是否丢失,若在上一个接收报告间隔内从某个源发出的所有数据包都丢失,那么将不为此源发送接收报告块.
累计包丢失数:24比特 从开始接收到现在,从源SSRC_n发到本源的RTP数据包的丢包总数.该值定义为期望接收的包数减去实际接收的包数,接收的包括复制的或迟到的.由于迟 到的包不算作损失,在发生复制时包损可能为负值.期望接收的包数定义为扩展的上一接收序号(随后定义)减去最初接收序号.
接收到的扩展的最高序列号:32比特 低16比特包含从源SSRC_n来的最高接收序列号,高16比特用相应的序列号周期计数器扩展该序列号.注意在同一会议中的不同接收机,若启动时间明显不同,将产生不同的扩展项.
到达间隔抖动:32比特 RTP数据包到达时刻统计方差的估计值,以时间标志为单位测量,用无符号整数表达.到达时刻抖动J定义为一对包中接收机相对发射机的时间跨度差值的平均偏 差(平滑后的绝对值).如以下等式所示,该值等于两个包相对传输时间的差值,相对传输时间是指包的RTP时间标志和到达时刻接收机时钟,以同一单位的差 值.若Si是包i的RTP时间标志,Ri是包i以RTP时间标志单位的到达时刻值,对于两个包i和j,D可以表达为
D(i,j)=(Rj-Sj)-(Ri-Si);
到达时刻抖动可以在收到从源SSRC_n来的每个数据包i后连续计算,利用该包和前一包i-1的偏差D(按到达顺序,而非序号顺序),根据公式J=J+(|D(i-1,i)|-J)/16计算.无论何时发送接收报告,都用当前的J值.
此处描述的抖动计算允许与协议独立的监视器对来自不同实现的报告进行有效的解释.
上一SR报文 (LSR):32比特 接收到的来自源SSRC_n的最新RTCP发射机报告(SR)的64位NTP时间标志的中间32位.若还没有接收到SR,该域值为零.
自上一SR的时间(DLSR):32比特 是从收到来自SSRC_n的SR包到发送此接收报告块之间的延时,以1/65536秒为单位.若还未收到来自SSRC_n的SR包,该域值为零.
假设SSRC_r为发出此接收报告块的接收机.源SSRC_n可以通过记录收到此接收报告块的时刻A来计算到SSRC_r的环路传输时延.可以利用最新的SR时间标志(LSR)域计算整个环路时间A-LSR,然后减去此DLSR域得到环路传播时延.
可以用此来近似测量到一族接收机的距离,尽管有些连接可能有非常不对称的时延.
接收机报告RTCP包
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=RR=201 | 长度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 报文发送者的SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (第一个源的SSRC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 丢包率 | 累计包丢失数 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 接收到的扩展的最高序列号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 到达间隔抖动 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 上一SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 自上一SR的时间 (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (第二个源的SSRC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 特定协议扩展 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
接收机报告包(RR)与发射机报告包基本相同,除了包类型域包含常数201和没有发射机信息的5个字(NTP和RTP时间标志和发射机包和字节计数).余 下区域与SR包意义相同.若没有发送和接收据报告,在RTCP复合包头部加入空的RR包(RC=0).
分析发射机和接收机报告
接收质量反馈不仅对发射机有用,而且对于其它接收机和第三派监视器也有作用.发射机可以基于反馈修正发送信息量;接收机可以判断问题是本地的,区域内的还 是全球的;网络管理者可以利用与协议无关的监视器(只接收RTCP包但是不接收相应的RTP包)去评估多点传送网络的性能.
在发射机信息和接收机报告块中都连续统计丢包数,因此可以计算任何两个报告块中的差别,在短时间和长时间内都可以进行测算,最近收到的两个包之间差值可以 评估当前传输质量.包中有NTP时间标志,可以用两个报告间隔的差值计算传输速率.由于此时间间隔与数据编码始终速率独立,可以实现与编码及协议独立的质 量监视.
从发射机信息中,第三派监视器可以在一个时间间隔内计算平均负载数据速率和平均发包速率,而无需考虑数据接收.两个值的比就是平均负载大小.若能假定包损 与包的大小无关,那么某个特定接收机收到的包数乘以平均负载大小(或相应的包大小)就得出接收机可得到的外在吞吐量.
除了累计计数允许利用报告间差值进行长期包损测量外,单个报告的包损比例域提供一个短时测量数据.当会议规模递增到无法为所有接收机保存接收状态信息,或者报告间隔变得足够长以至于从一个特定接收机只能收到一个报告时,短时测量数据变得更重要.
到达间隔抖动域提供另一个有关网络阻塞的短时测量量.包损追踪长期阻塞,抖动测量追踪短时阻塞.抖动测量可以在导致包损前指示阻塞.由于到达间隔抖动
域仅仅是发送报告时刻抖动的一个快照,因此需要在一个网络内在一段时间内分析来自某个接收机的报告,或者分析来自多个接收机的报告.
负载类型
注意并非所有RTP所用的编码方式都分配了静态负载类型号.可以建立在96-127间的负载类型值与编码方式间的动态匹配.可用的负载类型空间比较小.仅在满足以下条件时分配新的静态负载类型:
- 很多因特网社团都对此编码感兴趣;
- 与现存编码方式比较有好处和/或要求与现有广泛使用会议及多媒体系统互通;
- 描述足以建立一个译码器.
下表 为RTP数据头的PT域定义了静态负载类型.此外,96-127之间的负载类型值可以通过会议控制协议动态定义.例如,一个会话期可以在一个给定会话期 内,指定负载类型96指示PCMU编码,8,000抽样率,双通道.负载类型值表的"保留"项用以使RTP和RTCP包可以被可靠识别.
一个RTP源在任何给定时刻,只能发射一个RTP负载类型;不允许在一个RTP对话期中交织多个RTP负载类型,但是可以并行存在多个RTP对话期以发送多媒体.此协议中定义的负载类型传输或者语音,或者图象,但是不允许两者同传.
PT 编码 语音/图象 时钟速率 通道
(A/V) (Hz) (语音)
0 PCMU A 8000 1
8 PCMA A 8000 1
9 G722 A 8000 1
4 G723 A 8000 1
15 G728 A 8000 1
18 G729 A 8000 1
31 H261 V 90000
34 H263 V 90000
96-127 动态
注意:负载类型1-7,10-14,16-30保留.
端口分配
同RTP协议定义所述,RTP数据在偶数UDP端口传输,相应的RTCP包在下一个高(奇)端口传输.
依据此协议的应用程序可以用任意这样的UDP端口对.例如,可以用对话期管理程序随机分配.由于在同一台主机上可以运行多个利用本协议的应用程序,而有些操作系统不允许同一个UDP端口与不同的多点传送地址结合进行多重处理,因此不能要求固定的端口对.
端口对在5000以上选择,以适应UNIX操作系统端口号分配惯例:1024以下用来进行特权处理,1024到5000之间被操作系统动态分配.
4 RTP协议
4．IRTP报头格式
各Field值确定
V（版本）： 2 bit版本号置 2
P（填充）： l bit填充位置 0
X（扩展）： l bit扩展位置0
CC（CSRC数）： 4 bit CSRC标识的数量，此字段填充为 0，本体制不使用 CSRC。
M（标志）：l bit标志位，该标志在静音后的第一个语音包时置位。静音包仅发送一个，不连续发送。
pT（净荷类型） 7 bit G．723.1 4
G．729 18
Sequence number（序列号）：16bit序列号，初始值为一随机数，此后以1递增，收端以此判定包丢失及恢复包顺序。
Time stamP（时戳）：32bit时戳。用于标识RTP数据包中第一个字节来样时的时刻，其起始值为一随机值，以8000次/s的速率递增。
Synchronization Source（SSRC） identifiers（同步源标志）： 32 bit，用来标识 RTP包的数据源。
Contributing Source（CSRC）identifiers（贡献源标志）：每个 CSRC 32 bit， 0～ 15个 CSRC序列，本体制不包含该字段。
4．2 RTCP 协议
RTCP报文共有5类：RR SR SDES BYE APP。本标准只对SR和RR报文提出要求。
SR（发送报文）的格式如下：
其中的各项内容定义如下：
版本（V）： 2 bit协议鉴别，在本体制中规定为 2
填充（P）： 1 bit在本体制中规定为 0
接收报告数（RC)：5bit
在SR中包含的RR的数目，在本体制中规定不得大于1。
净荷类型(pt)：8 bit
报文类型，以二进制表示。其中十进制的200代表SR。
长度（length)：16 bit
报文长度，指在其后的报文长度，所以有可能为0。
发送者的同步源标志（SSRC of sender）：32 bit
源同步码，用以标识此次通话。
NTP时戳（NTP timestmp）： 64 bit
绝对时戳。在测量环路时延时可在对方的RR报文中带回；如果发送方不具有绝对时钟的能力，则可以用通话开始时间作为时钟0点或将此域置0。（在NTP格式 中，64位的前32位是从1900年1月1日0时开始到现在的以秒为单位的整数部分，后32位是此时间的小数部分）
RTP时戳（RTP timestamp）： 32 bit
以RTP的时戳为基推。
发送的报文数（ sender\'s packet count）： 32 bit
从通话开始后发送方总共发送的RTP报文的数目。
发送的字节数（ sender\'s octet count）： 32 bit
从通话开始后发送方总共发送的有效载荷的数目（以字节记）。
随后描述的是一个或多个RR报文块，在本体制中规定在SR报文中最多只能有一个RR报文块。
源标志一n（SSRC_n）： 32 bit
源同步码，用以标识此RR块所从属的通话。
丢包率（ fraction LOSt）： 8 bit
从上一个SR或RR报文发送后的丢包率，表现为接收方在此段时间内期待的RTP报文与所收到的
RTP包数目的差值和它所期待的RTP报文的数目的比值，若为负值，置为0。详见RFC1889。
累计的包丢失数（ Cumulative numberof packets LoSt）： 24 bit
累计的包丢失数。
接收到的扩展的最高序列号（extended highest sequence number received）： 32 bit
其低16位是其收到的RTP包中的sequence number的最新值。其高16位标识其收到的RTP报文的 sequence number的循环的次数。
到达间隔抖动（interarrival jitter) 32bit
时延抖动。每两个RTP包的抖动可以用其RTP包中的RTP时戳和接收的时刻进行计算，计算公式如下：设
Rj代表第j个包的到达时刻， Sj代表第j个包的RTP时戳值，则第 i个 RTP报文与第j个 RTP报文间的科动为D（i,j） ：
D（i，j）＝（Rj－Ri）-（Sj－ Si） =（Rj－ Sj）- （Ri- Si）
在生成RTCP报文时，其应当传送的时延抖动的值可用如下公式进行递 推计算：
J＝J＋（ 1D（I－1，I)1-J)/16
其中，J为要传送的时延抖动值。对后一项除以16是为了消除连带噪声。
上一SR报文时戳（LSR）： 32 bit
收到的最近一个SR报文的NTP时戳的中间32位。
自上一SR的时间（DLSR）：32bit
在收到上SR报文与此次以送报文之间的时间。以1/65536s记。如果还没有收到任何SR报文，此值置0。
RR报文的格式如下：
其中各项的功能与形式如 SR中的说明。若未收到任何RTP报文，则可发送一个空的RR，即RC=0。
RTCP包发送机制：在两次RTCP报文之音，若端点没有发出任何RTP报文，则端点此次发送RR（接收报文），否则，端点发送SR（发送报文），RTCP包每秒发送一次。