Php文档 Php问答行业资讯 Php论坛 Php手册 Php博客

游戏榜单

软件榜单

关闭导航

热搜榜

热门下载

热门标签

关闭搜索

php爱好者> php文档>RTP&RTCP

RTP&RTCP

时间：2006-07-05 来源：lzhw_lucky

一. 概述

实时传输协议（RTP，Real Time Transport Protocol）由RFC 1889定义，主要用于网络上各种实时应用（Real-time applications）。现在实时应用非常热（图14-02-1）。

图14-02-1 网络实时应用例

为什么不采用TCP？

众所周知，Web网页传输是建立在HTTP协议的基础上的，但是HTTP有着自己的局限性：

1.HTTP是无连接协议，限制了每次连接只处理一个请求，服务器处理完客户的请求，收到应答后，即断开连接，虽然这种方式可以节省时间，但却无法实现广播。

2.HTTP是无状态协议，所谓的无状态协议是指协议对于事件处理无记忆能力，这就意味着如果后续处理需要前面的信息，则必须重传，如果采用HTTP则必须重传，从而导致传输数据量增大，带宽浪费。

存在4个问题：

o不需要100% 的可靠性

o重发延迟

o窗口后退

oN 参与者 -> N*N 连接

实时传输协议提供了支持这些要求的功能：

丢失，顺序混乱：序列号
丢失，不稳定：时间戳
数据源/有效载荷认定
速率控制: 服务质量反馈（QoS feedback）

RTP用于一对多传输情况下，提供时间信息和实现媒体同步。此外，实时传输控制协议（RTCP，Real Time Transport Control Protocol）与RTP一起提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包，RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此服务器可利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合网上的实时数据。

RTP和其他熟悉的协议如HTTP、 FTP等类似，但是根据实时流的特定要求作了剪裁。

和HTTP、FTP不同，RTP并不下载整个视频到客户计算机上，而是用固定的数据速率传输一个细的单向数据流，使其实时播放广播（在很短的初始化握手和数据缓冲之后）。一个流化了的一分钟电影就恰好播放一分钟。当连接具有足够的带宽来处理数据流的时候，电影就将播放。当数据播放完了就丢弃。观众只能通过再请求从流服务器来重放。

实时流是如何被处理的？

当你收听实时广播时，流客户软件（比如，QuickTime Player，或者QuickTime 插件) 发送一个请求到流服务器。服务器查找会话描述协议 (SDP，Session Description Protocol)文件, 如找到，就开始通过RTP发送流媒体到你的计算机。

一个SDP文件是一个文本文件，包含了将要发送什么和怎么收听的信息。SDP文件由计算机上的广播软件（比如Sorenson广播器）建立，它捕获实况媒体，但是SDP文件必须在媒体广播之前被拷贝到流服务器。QuickTime Player 和QuickTime 插件可以打开视频的SDP文件。

传送的问题

必须牢记实时流包含一些传送上的问题。

· 数据丢失。 RTP 使用低级的UDP进行传送。 UDP 比TCP/IP快，但是没有丢失报告机制，所以Internet上的流通常都会丢失。

· 网络地址转换。小型网络用路由器连接Internet接收流可能有问题。这些路由器通常使用网络地址转换(NAT， Network Address Translation), 但是RTP的流包含的端口地址会使一些老式NAT软件迷惑。你需要升级NAT软件。

· HTTP 管道。如其他失败，使用HTTP管道将RTP数据包打包进普通HTTP数据包。这常常使流能穿过防火墙或NAT路由器。要使用HTTP管道, 收看者必须配置自己的QuickTime 设置控制面板，通过检查使用HTTP并且设置端口为80（或者是流服务器用HTTP传输的端口），而且服务器必须支持HTTP管道。

RTP 与 RTSP的比较

分清楚RTP和实时流协议（RTSP）很重要, RTSP是另一个传送协议。RTSP 用在观众和Unicast 服务器通信的情况。RTSP 提供双向通信，即观众可以和流服务器通信并且进行如倒带、换章节观看等操作。

相反，RTP 是一个单向协议，只能从服务器发送实况或存储流到客户。

RTP一般和RTCP配合使用（图14-02-2）。两个密切链接的部分（相继的UDP端口）：

o 数据部分，传输RT数据

o 控制部分RTCP（Real Time Control Protocol) ，监视QoS和携带预期信息

（a）用途

（b）使用相邻的端口

图14-02-2 RTP和RTCP的使用

二．RTP数据传输协议

RTP提供端对端网络传输功能，适合通过多播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立于传输层和网络层。

1．RTP固定头

RTP头格式如图14-02-3所示。

图14-02-3 RTP头格式

开始12个八位组（字节）出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。各字段的含义如下：

① 版本(v)：2位，标识RTP版本。

② 填充标识(P)：1位，如设置填充位，在包尾将包含附加填充字，它不属有效载荷。填充的最后一个八位组包含应该忽略的八位组。某些加密算法需要固定大小的填充字，或为在低层协议数据单元中携带几个RTP包。

③ 扩展(x)：1位，如设置扩展位，固定头后跟一个头扩展。

④ CSRC计数(cc)：4位，CSRC计数包括紧接在固定头后CSRC标识符个数。

⑤ 标记(M)：1位，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标识位，或通过改变位数量来指定没有标记位。

⑥ 载荷类型(PT，Payload Type)：7位，标识RTP载荷格式并决定其解释。设置指定载荷类型代码对载荷格式的静态映射（audio, video, image, texte, html等）。其他载荷类型代码可通过非RTP途径动态定义。对音频和视频的缺省映射初集在相关设置中指出。将来可进一步扩展。

⑦ 序列号（Sequence Number）：16位，序列号随每个RTP数据包而增加1，由接收者用来探测包损失，而恢复包序列。序列号初值是随机的，使对加密的文本攻击更加困难。

⑧ 时间戳（timestamp）：32位，时间戳反映RTP数据包中第一个八位组的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时钟必须有足够分辨率，满足所需同步和测定包到达抖动精度。时钟频率依赖携带数据的格式，并在设置中静态指定。如RTP包周期产生，采用采样所用的时钟确定名义采样时刻，而不是从系统读出。如同序列号，时间戳的初始值是随机的。如几个连续RTP包在逻辑上一次产生它们就有着相同的时间戳，属于同一视频帧。如数据不是以采集顺序发送，像MPEG插入的视频帧，连续RTP包包含的时标可能不是单调的。

⑨ 同步源标识符（SSRC，Synchronization Source Identifier）：32位，SSRC段标识同步源。此标识不是随机选择的，目的在于使同一RTP包连接中设有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。

⑩ CSRC列表：0到15项，每项32位。CSRC列表表示包内包含的对载荷起作用的源。标识数量由CC段给出。如超过15个作用源，也仅标识15个。CSRC标识由混合器插入，用作源的SSRC标识。

2．复用RP连接

为使协议有效运行，复用点数目应减至最小。RTP中，复用由定义RTP连接的目的传输地址(网络地址与端口号)提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不再将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。

使用同一SSRC，而具有不同载荷类型的交叉包将带来几个问题：

(1) 如一种载荷类型在连接期间切换，没有办法识别新值将替换哪一个旧值。

(2) SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明哪种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。

(3) RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。

(4) RTP混合器不能将不兼容媒体流合并成一个流。

(5) 在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配，接受媒介子集。

对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。

3．对RTP头特定设置的修改

现用RTP数据包头对RTP支持的所有应用类共同需要的功能集可以认为是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位宇，故允许分配在固定头中。包含这些段的八位组可通过设置重新定义以适应不同的要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八位组中最重要的位。

其他特殊载荷格式(视频编码)所要求的信息应该携带在包的载荷部分。可出现在头部，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始的12个八位组处理RTP包。

三. RTP控制协议——RTCP

RTCP协议将控制包周期发送给所有连接者，应用与数据包相同的分发机制。低层协议提供数据与控制包的复用，如使用单独的UDP端口号。RTCP执行下列四大功能：

(1) 主要是提供数据发布的质量反馈。RTCP是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP多播经验表明，从发送者收到反馈对诊断发送错误是至关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。诸如IP多播等发布机制使网络服务提供商之类的团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。

(2) RTCP带有称作规范名字(CNAME)的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME与相关RTP连接中给定的几个数据流联系。

(3)前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。让每个参加者给其他参加者发送控制包，就加大独立观察参加者数量。该数量用于计算包发送的速率。

(4)第四个可选功能是传送最小连接控制信息，如辨识参加者。最可能用在“松散控制”连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。

在IP多播场合应用RTP时，前三个功能是必须的，推荐用于所有情形。RTP应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。

（一）RTCP包格式

下面定义几个携带不同控制信息的RTCP包类型：

SR（Sender Report）：发送者报告，当前活动发送者发送、接收统计。
RR（Receiver Report）：接收者报告，非活动发送者接收统计。
SDES（Source Description）：源描述项，包括CNAME, NAME, EMAIL, PHONE等。
BYE：表示结束。
APP（application）：应用特定函数。

类似于RTP数据包，每个RTCP包以固定部分开始，紧接着的是可变长结构元素，但以一个32位边界结束。包含安排要求和固定部分中长度段，使RTCP包可堆叠。不需要插入任何分隔符将多个RTCP包连接起来形成一个RTCP组合包，以低层协议用单一包发送出去。由于需要低层协议提供整体长度来决定组合包的结尾，在组合包中没有单个RTCP包显式计数。

组合包中每个RTCP包可独立处理，不需要根据包组合顺序。但为了执行协议功能，强加如下约束：

(1) 接收统计(在SR或RR中)应该经常发送，只要带宽允许，因此每个周期发送的组合RTCP包应包含报告包。

(2) 新接收者需要接收CNAME，并尽快识别源，开始联系媒介进行同步，因此每个包应该包含SDES CNAME。

(3) 出现在组合包前面的是包类型数量，其增长应该受到限制，以提高常数位数量，提高成功确认RTCP包对错误地址RTP数据包或其他无关包的概率。

因此，所有RTCP包至少必须以两个包组合形式发送，推荐格式如下：

①加密前辍(Encryption prefix)

仅当组合包被加密，才加上一个32位随机数用于每个组合包发送。

② SR或RR

组合包中第一个RTCP包必须总为一个报告包，方便头的确认。即使没有数据发送，也没有接收到数据，也要发送一个空RR，即避免组合包中RTCP包为BYE（终止标识）。

③ 附加RR

如报告统计源数目超过31，在初始报告包后应该有附加RR包。

④ SDES

包含CNAME项的SDES包必须包含在每个组合RTCP包中。如应用要求，其他源描述项可选，但受到带宽限制。

⑤ BYE或APP

其他RTCP包类型可以任意顺序排列，除了BYE应作为最后一个包发送，包类型出现可不止一次。

建议转换器或混合器从多个源组合单个RTCP包。如组合包整体长度超过网络路径量最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。注意，每个组合包必须以SR或RR包开始。附加RTCP包类型可在因特网分配号码机构（IANA，Internet Assighnedd Numbers Authority）处注册。

（二）RTCP传输间隔

RTP设计成允许应用自动扩展，连接数可从几个到上千个。例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对多播，给定连接数据率仍是常数，独立于连接数。但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。

对每个连接，假定数据流量受到“连接带宽”的总量限制。选择连接带宽是根据费用或网络带宽的先验知识，与媒体编码无关，但编码选择会受到连接带宽的限制。当调用一个媒体应用时，连接带宽参数由连接管理应用提供，但媒体应用也可根据单个发送者数据带宽设置缺省值。应用可根据多播范围规则或其他标准强制限制带宽。由于这是资源预订系统需要知道的，对控制与数据流量的带宽计算包括低层传输与网络协议。应用也需要知道在使用哪个协议。在传输途中，因为包将包含不同连接层的包头，所以连接层的包头不计算在内。控制流量应限制为连接带宽中已知的一小部分：小，传递数据的传输协议主要功能才不致受损；已知，控制流量才能包含在所给资源预订协议的带宽规范中，这样，每个参加者就可单独计算其共享量。建议分配给RTCP的连接带宽固定为5％，而这个数值与间隔计算中其他常量并不重要，连接中所有参加者必须使用相同数值，因此，使用相同间隔计算。

计算RTCP包间隔依赖连接中地址加入数量的估计。当新地址被监听到，就加到此计数，并在以SSRC或CSRC标识索引的表中为之建立一个条目，用来跟踪它们。直到收到带有多个新SSRC包，新条目才有效。当收到具有相应SSRC标识的RTCP的BYE包，条目可从表中删除。如果对少量RTCP报告间隔没有接收到RTP或RTCP包，参加者可能将另外一个地址标记成不活动，如还未生效就删除掉。这为防止包丢失提供强大支持。为了“超时”正常工作，所有地址必须对RTCP报告间隔记入大致相同的数值。

一旦确认地址有效，如后来标记成不活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。

这个规范定义了除必需的CNAME外的几个源描述项，如NAME(人名)和E-mail(电子邮件地址)。它也是定义新特定应用RTCP包类型的途径。给附加信息分配控制带宽应引起注意，因为它将降低接收报告和CNAME发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20％。而且并没有有意让所有SDES项包含在每个应用中。

（三）发送者与接收者报告

RTP接收者使用RTCP报告包提供接收质量反馈，报告包则根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收者报告间惟一的差别是发送者报告包含一个20个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR。SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。最大可有31个接收报告块嵌入在SR或RR包中，附加RR包可堆叠在初始SR或RR包之后。

发送者报告包由三部分组成，也可能还有第四个特定设置扩展部分（图14-02-4）。

图14-02-4 发送者报告包

1) 第一部分为头，8个八位组长，内容如下。

① 版本（V）：2位，标识RTP版本。

② 填充(P)：1位，如设置于此位，RTCP包结尾包含一些附加填充八位组，它们不属于控制信息。最后一个八位组填充表示应忽略多少个填充。有些加密算法需要填充，块大小固定。在组合RTCP包内，填充仅在最后一个包中需要，因为组合包加密成一个整体。

③ 接收报告计数(RC)：5位，包含在包内的接收报告块数目，0值为有效。

④ 包类型(PT)：8位，包含常数200标识此包为RTCP的SR包。

⑤ 长度：16位，32位字RTCP包长度的一半。

⑥ SSRC：32位，同步源标识。

2) 第二部分为发送者信息，20个八位组，出现在每个发送者报告包中。含义如下。

① NTP时标：64位，表示报告发送时的时钟时间，这样它就可用于合并从其他发送者到那些接收者的接收报告返回的时标。

② RTP时标：32位，与上述NTP时标同一时间有关，但与RTP时标有着相同的时间单位和同样的随机偏移。

③ 发送者包计数：32位，自开始发送来，直到SR包产生时刻，发送者发送RTP数据包总数。如改变SSRC标识符，此计数重置。

④ 发送者八位组计数：32位，发送者在RTP数据包中发送的载荷八位组总数。从发送开始，直到产生SR包，如发送者改变SSRC标识，重置此计数。这部分可用于估计载荷数据平均速率。

3) 第三部分包含接收报告块，大小不固定。每个接收报告块传送单个同步源接收RTP包的统计。发生冲突，当源改变SSRC标识时，接收者并不继续统计。这些统计包括：

① SSRC_n(源标识)：32位，接收报告块中信息所属源的SSRC标识。

② 丢失部分：8位，前一个SR或RR包发送以来所丢失的源SSRC_n的RTP数据包中一部分，定义成所丢失包的数目。

③ 丢失包累积数：24位，自接收以来所丢失的源SSRC_n的RTP数据包总数，定义成小于实际所接收包的数量，该数量包括迟到或复制的包。因此，迟到的包不计为丢失，如有复制，此数量可能为负数。

④ 收到已扩展的最高系列号：32位，低16位包含从SSRC_n源RTP数据包中收到的最高系列号，最重要的16位以系列号循环相应计数扩展系列号。如开始时间明显不同，同一连接内不同接收者将对系列号产生不同扩展。

⑤ 间隔抖动：32位，RTP数据包间隔时间的统计估计，以时标为单位，是一个无符号整数。

⑥ 最后SR时标(LSR)：32位，NIP时标的中间32位，如还没有收到SR，此段设为零。

⑦ 自最后一个SR来的延迟(DLSR)：32位，延迟以1／65536秒为单位，表示源SSRC_n收到的最后一个SR包与发送此接收块之间的时间，如还没有收到SR，此段设为零。

接收报告包格式与SR包类似（图14-02-5），但包类型包含常数201，并删除发送者信息的五个字。当没有数据传输或接收报告时，则将一个空RR包(RC=O)放在组合RTCP包的前头。

图14-02-5 接收报告包

如接收者或发送者有附加信息要有规律地报告，应对接收报告与接收者定义设置或应用扩展。如需要附加发送者信息，应首先包含在发送者报告的扩展中，但不出现在接收者报告内。如要包括接收者信息，数据结构应设块数组，与接收报告块数组类似，即块数量由RC段表征。

人们总是希望接收质量反馈不仅对发送者有用，而且对其他接收者和第三方监控都有用。发送者可根据反馈改变发送，接收者决定问题是出现在本地、区域还是全局。网络管理员可仅使用接收RTCP包、而不是RTP数据包的设置无关监控器来估计网络多播的性能。

累计计数用在发送信息与接收者报告块中，可考虑长期和短期测量与提供报告丢失恢复能力之间的差别。后两个接收到报告之间的差别可用来估计近来发送的质量。将NTP时标包含在内，从两个报告间隔的差别考虑速率。由于时标独立于数据编码时钟速率，很可能实现编码与设置无关的质量监控器。

丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别则给出间隔期间希望发送的包数量，两者之比等于间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失率可通过NTP时标差除以丢失部分得到。

根据发送者信息，第三方监控器可计算出载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。

（四）源描述RTCP包

源描述RTCP包（SDES）为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源（图14-02-6）。

图14-02-6 SDES包

1) 项描述如下：

（1）版本(V)、填充(P)、长度：如SR包中所描述。

（2）包类型(PT)：8位，包含常数202，标识RTCP SDES包。

（3）源计数(X)：1位，包含在SDES包中的SSRC／CSRC块数量，零值有效，但没有意义。

2) 源描述项

源描述项内容如图14-02-7所示。

图14-02-7 源描述项

① CNAME

规范终端标识SDES项。CNAME标识属性如下：

如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定。
像SSRC标识，CNAME标识在RTP连接的所有参加者中应是惟一的。
为了提供一套相关RTP连接中某个参加者所采用的跨多媒体工具间的绑定，CNAME应固定为那个参加者。
为方便第三方监控，CNAME应适合程序或人员定位源。

② NAME

用户名称SDES项，这是用于描述源的真正的名称，如"John Doe，Bit Recycler，Megacorp"，可以是用户想要的任意形式（图14-02-8）。对诸如会议应用，这种名称也许是参加者列表显示所最适宜的形式，它将是除CNAME外发送最频繁的项目。设置可建立这样的优先级别。NAME值至少在连接期间仍希望保持为常数。它不该成为连接的所有参加者中惟一依赖。

图14-02-8 NAME

③ E-mail

电子邮件地址SDES项。邮件地址格式由RFC822规定，如“[email protected]"。连接期间，电子邮件仍希望保持为常数。

图14-02-9 EMAIL

④ PHONE

电话号码SDES项。电话号码应带有加号，代替国际接入代码，如“+86 28 8541 1212"即为中国电话号码。

图14-02-10 PHONE

⑤ LOC

用户地理位置SDES项。根据不同应用，此项具有不同的详细程度。对会议应用，字符串如"Murray Hill，New Jersey"就足够了。然而，对活动标记系统，字符串如“Room 2A244，AT&T BL MH"也许就适用。细节留给实施或用户，但格式和内容可用设置指示。在连接期间，除移动主机外，LOC值期望仍保留为常数。

图14-02-11 LOC

⑥ TOOL

应用或工具名称SDES项，是一个字符串，表示产生流的应用的名称与版本，如“video tool 1.2”。这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。TOOL值在连接期间仍保持常数。

图14-02-12 TOOL

⑦ NOTE

通知／状态SDES项。推荐的该项语法如下所述，但这些或其他语法可在设置中显式定义。NOTE项旨在描述源当前状态的过渡信息，如"on the phone，can't talk"，或在讲座期间用于传送谈话的题目。它应该只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和CNAME发送的速度，因此损害协议的性能。特殊情况下，它不应作为用户设置文件的项目，也不是自动产生。

当其为活动时，由于NOTE项对显示很重要，其他非CNAME项(如NAME)传输速率将会降低，结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，但以一个串长为零的字符串通知接收者。然而，如对小倍数的重复或约20~30倍RTCP间隔也没有接收到，接收者也应该考虑NOTE项是不活跃的。

图14-02-13 NOTE

⑧ PRIV

专用扩展SDES项。该项用于定义实验或应用特定的SDES扩展，它包括由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值。前组长度段为8位。前缀字符中是定义PRIV项人员选择的名称，惟一对应应用接收到的其他PRIV项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其他人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。

注意，前缀消耗了总长为255个八位组项的一些空间，因此，前缀应尽可能的短。这个设备和受到约束的RTCP带宽不应过载，其目的不在于满足所有应用的全部控制通讯要求。SDES PRIV前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性，IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀。这简化了应用，并提高了传输的效率。

（五）断开RTCP包（BYE）

如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC／CSRC标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个八位组计数，后跟表示离开原因的很多八位组文本，如：“camera malfunction"或"RTP loop detected"。字符串具有同样的编码，如在SDES中所描述的。如字符串填充包至下32位边界，字符中就不以空结尾；否则，BYE包以空八位组填充。

图14-02-14 BYE

（六）定义应用的RTCP包（APP）

APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。

图14-02-15 APP

图14-02-16给出了一个速率控制例。在理想情况下，使用RTP/RTCP可以使源速率与传输能力达到匹配（最小丢失）。

图14-02-16 速率控制例

四. 基于网络和传输协议的RTP

这部分讲述特殊网络和传输协议内与携带RTP包相关的内容。如果没有规范外特定协议定义替代，下列规则可适用。

RTP依赖低层协议提供RTP数据和RTCP控制流的多路分解。对UDP和类似协议，RTP使用一个偶数端口号，而相应RTCP流使用下一个(奇数，递增)端口号。如应用使用一个奇数RTP端口，就应该用下一个小偶数端口代替。RTP数据包不包含长度段或其他描述，因此RTP依赖低层协议提供长度指示，RTP包最大长度仅受低层协议限制。如RTP包包含在提供连续八位组流的低层协议而不是信息(包)中，必须定义RTP包的封装以提供帧机制。如低层协议包含填充，也需要帧机制，否则结果无法决定RIP负载程度。这里没有定义帧机制。

当RTP包含在提供帧的协议中时，为了允许在一个低层协议数据单元(UDP包)包括几个RTP包，设置可指定所使用的帧方法。在网络或传输包中携带几个RTP包可减少头部，并可能简化不同流之间的同步。

RTP 参数