RTCP概述

6.2.1RTCP概述

1.RTCP协议功能

RTCP协议的基本思想是采用和数据分组同样的配送机制向RTP会话中的所有与会者周期性地传送控制分组，从而提供数据传送QoS的监测手段，并获知与会者的身份信息。其功能包括：

(1)提供数据传送质量的反馈信息。

这是RTCP最基本的功能。它是RTP作为运输层协议的一项不可或缺的功能，也和其它运输层协议的流量控制和拥塞控制功能密切相关。反馈信息可直接用于控制自适应编码，在IP多播中对于诊断数据分配故障也十分有用。向所有与会者发送接收反馈报告有助于判断故障是局部性还是全面性的。这些信息还可通过多播方法发送给不参与会话的业务提供者，作为第三方对网络进行监视和故障诊断。完成这项反馈功能的就是RTCP发送者报告和接收者报告。

(2)传送RTP源运输层永久标识

该标识称为规范名(CNAME)。由于SSRC标识在发生冲突或程序重启动时是要改变的，因此接收方需要使用不变的CNAME来跟踪每个与会者。CNAME的另一作用是关联同一与会者由一组RTP会话发出的多个相关的数据流，例如可视电话中的话音流和视频流，

虽然分属两个不同的RTP会话，但是它们的RTCP分组中的CNAME相同，接收者据此可知需对它们进行同步处理。媒体间同步需要精确的定时关系，RTP分组中的时戳只是反映取样周期的信息，并不是指示绝对时间的系统时钟，因此不同媒体分组的时戳可能是不同步的。由数据发送者送出的RTCP分组中既包含了RTP时戳，又包含了绝对时间NTP时戳，接收者据此可以实现多种媒体间的同步。

(3)确定RTCP分组发送速率

由于RTCP分组需要定期发送，在大型会议情况下，网络上就会产生可观的控制话务量，因此必须根据可用带宽和会议规模确定RTCP分组的发送速率。由于每个与会者都向所有其他人发送控制分组，因此每人都知道参会者的数目，据此就可计算RTCP分组的发送速率。

(4)传送少量会话控制信息

例如与会者标识，可在用户界面上显示，对于与会者可以自由进出的松弛型控制会话最为有用。此是任选功能。

总的说来，RTCP对于1P多播环境尤为有用。

2.RTCP分组类型和组装

RTCP定义了如下几种分组类型：

•SR(SenderReport)：发送者报告。由数据发送者发出的发送和接收统计数据。

RR(ReceiverReport)：接收者报告。由非数据发送者发出的接收统计数据。

•SDES(SoureeDescription)：源描述项。包括CNAME。

•BYE：指示退出会话。

•APP：应用特定功能。

每个RTCP分组由固定头部和若干个可变长度的数据单元组成。分组长度必定是32比特字的整数倍，且头部有长度字段，因此多个RTCP分组可以组装成一个复合RTCP分组，各分组间无需分界指示。

复合RTCP分组的构成规则是：

．复合分组中的第1个RTCP分组必须是SR或RR。即使尚未发送或接收任何数据，也必须发送一个空的RR；即使除此以外仅有的RTCP分组是BYJ砂忖且，也必须包含SR或RR。其目的是在带宽允许的条件下，尽可能多地发送接收统计信息，以便提高统计精度。

．如果要向其发送接收统计信息的信源数超过31个(SR和RR允许的最大数），就应在第一个报告分组后再设置若干个后续报告。

．每个复合RTCP分组必须包含一个含有CNAME的SDES分组，其目的是使新加入的接收者尽快地识别信源，并确定相互间有关联的媒体，以便实现同步。是否包含其它源描述项则根据应用而定。

．只有当复合分组需要加密时，才在整个分组前面加一个32比特随机量，分组后面是否需加填充视加密算法而定。

．其它类型RTCP分组可以任意顺序装配于后，每种分组可以有多个。但BYE分组应置于复合分组的最后。

由上可知，所有RTCP分组必须组装成复合分组后才能发送，复合分组至少包含两个分组。

为了减少网络开销，混合器和翻译器应尽可能将来自多个信源的RTCP分组组合成一个复合分组送往各目的地。如果复合分组的长度超过网络允许的最大传输单元(MTV)，则应分段。但必须注意每段复合分组必须以SR或RR分组开始。

接收方可以任意顺序处理收到的每个RTCP分组。如果某个分组类塑不能识别．则予丢弃。

6.2.2发送者和接收者报告

RR和SR都可用来发送数据接收质量的反馈信息，其差别在于SR除了提供上述信息外，还可提供有关数据发送的信息。从分组结构上看，SR除了有接收报告数据块外，还有20个字节的发送者信息段。如果一个站点仅是会话的接收者，则只能发送RR分组；如果一个站点既是会话的接收者，又是会话的发送者，则可在发送SR时一起发送接收反馈信息，在没有SR需要发送时，就专门发送RR。报告分组定期发送，如果在上次发送SR或RR后又发送过数据，则本次应发送SR，否则就发送RR。

SR和RR都包含零个或多个接收报告数据块，每个数据块针对一个同步源，自上次发送报告后，本站点从该同步源又收到过数据，接收报告提供数据接收的统计信息。每个SR或RR最多可包含31个接收报告块。对分信源(CSRC)不发送接收报告。

I.SR分组结构

SR结构如图6.4所示。它由三个数据段组成：头部、发送方信息和接收报告块。

       (I)头部

长度为8个字节，包含以下字段：

· V:版本号，2比特。含义同RTP分组头部。

· p：填充指示位，1比特。含义同RTP分组头部。由于加密是对整个复合分组进行的，因此如果要加填充字节，只需要加在最后一个分组之后。也就是说，只有最后一个分组的P位可能置l。

· RC：接收报告计数，5比特。指示本分组包含的接收报告块个数，可以为零值。

· PT:净荷类型，8比特。SR的净荷类型值为200。

· 长度：16比特。其值加1为该RTCP分组的长度，长度单位为32比特字，包括头部和填充字节。

· 发送方SSRC:32比特。发送该SR分组的站点的同步源标识。

(2)发送方信息

长度为20个字节，每个SR分组的必备部分，包含以下字段：

• NTP时戳：64比特。指出该SR发出的绝对时间。NTP(Net­ work Time Protocol)称为网络时间协议，NTP时戳表示相对于1990.1.1协调世界时零点的时间差值，单位为秒。前32比特为整数部分，后32比特为小数部分。某些字段要求紧缩表示形式时，可只取用中间32比特，即整数部分的低16比特和小数部分的高16比特。根据此

图6.4  SR分组结构

值及由其它接收端回送的时戳，就能测出至这些接收端的往返传播时延。如果不能获得绝对时间，也可用系统时钟作为参照计算相对NTP时戳。在多媒体会话中，重要的是各媒体流都采用公共的时钟。

• RTP时戳：32比特。它所指示的就是上述NTP时戳指示的时间，但是时间单位和初始值和数据分组中的RTP时戳相同。根据这一对应关系就可控制来自不同源的相同媒体和不同媒体之间的同步，其条件是这些信源的NTP时戳是同步的。它还可供和媒体无关的接收者估算RTP时钟标称频率。需要注意的是，该时戳值必须利用RTP时戳计数值和实际时间的关系由相应的NfP时戳值计算得出，它和相邻数据分组中的RTP时戳并不相同。

• 发送方分组计数值：32比特。其值为该发送者自开始发送以来直至本SR分组生成时为止发送的RTP数据分组总数。如果发送者改变其SSRC值，该计数值需复位。

• 发送方字节计数值：32比特。其值为上述同一段时间内发送的RTP数据分组的净荷字节数（即，不含头部和填充字节）。该值可用来估算平均净荷数据速率。

(3)接收报告块

该数据段包含零个或多个接收报告块，每个报告块提供来自指定同步源的接收数据的统计信息。这些统计信息包括：

• SSRC-n:32比特。本报告块信息所属信源的SSRC标识。

• 丢失率：8比特。指示自上次SR或RR发送以来，由SSRC-n发来的RTP数据分组的丢失比率。用二进制小数表示，小数点位于该字段的最左面。该值定义为丢失分组数除以期望接收的分组数。需要注意的是该值计算不一定正确，因为在最后一个收到分组之后丢失的分组，接收端将无法检测。另外，如果在整个报告间隔周期内所有分组都丢失了，也就不会有接收报告发出。

• 累计丢失分组数：24比特。指示从开始接收以来丢失的来自SSRC-n的RTP数据分组总数。该值定义为期望收到的分组数减去实际收到的分组数。

• 扩展的已接收最高序号：32比特。其低16比特为接收来自SSRC-n的RTP数据分组的最高序号，高16比特为序号循环计数。该值减去收到的初始序号就是上两个字段需使用的期望收到的分组数。

• 到达时延抖动：32比特。用时戳单元测量的RTP数据分组到达时延统计方差估值，用无符号整数表示。时延抖动J定义为一对分组在接收端接收间隔和发送端发送间隔之差值D的平均偏差。

记S_i，为分组_i的发送RTP时戳值，R_i为分组i到达时间（以RTP时戳为计时单位），则分组i和j间的差值D为：

D(i,j)=(Rj-Sj)-(Ri-Si)

到达时延抖动在每个分组到达时更新计算，其公式为：

j_i=j_i-1+(ID(i-1,i)I-j_i-1)／16

其中，参数1/16为平滑因子，减小噪声影响。

．最末SR时戳(LSR):32比特。为最近收到的来自SSRC-n的SR分组中NTP时戳的中间32比持。

．最末SR后的时延(DLSR):32比特。自收到最近一个来自SS­RC-n的SR分组至发送本接收报告块的时延，单位为1/65536秒。如果尚未收到SR分组，则置DL5R=0。

记SSCR-n收到此报告的时间为A，则根据下述式子就可估算出至本站点的往返传播时延：

往返时延＝A-LSR-DLSR

由图6.5不难理解上述计算式的含义。其前提是收发链路双向对称。

图6.5   往返传播时延的计算

2.RR分组结构

RR分组格式和SR相同。差别仅在于没有20个字节的发送者信息，且PT=201。

如果没有数据发送或接收需要报告，也必须在复合RTCP分组首部置一空的RR分组(RC=O)。

3.QoS性能监测

SR和RR中有许多有用的信息可供信号发送者、接收者和第三方监测小S性能和诊断网络问题，并及时调整发送模式。

这些信息可分为三类：累计信息、即时信息和时间信息。通过计算两个接收报告累计信息之差可以监测长期性能指标；由即时信息可以测量短期性能；时间信息可以用来计算比率指标，且由于NTP时戳和编码时钟速率无关，可以获得独于编码和应用文档的测量结果。

例如，两个接收报告的累计丢失分组数之差给出了在这段时间中的丢失分组数；扩展最高序号之差为这段时间内的期望接收分组数；二者之比为这段时间内的分组丢失率。丢失分组数除以两个报告的N1P时戳之差为每秒分组丢失率。期望接收分组减去丢失分组数即为这段时间内收到的分组数。由期望接收分组数还可判断丢失统计指标的可信度，如总共5个分组中丢失1个，由于样本空间过小，此丢失率数据意义不大；如总共1000个分组中丢失200个，则此数据比较可信。由于上述测僵都是基于两个接收报告之差，因此即使曾发生报告丢失也不会影响监测结果。

第三方即使没有接收实际数据，通过收到的发送者信息也可算出这段时间内的平均净荷数据率和平均分组发送率。两者之比即给出平均净荷大小。假定分组丢失率和分组大小无关，则由某个接收站接收分组数乘以平均净荷大小就得出该接收站的吞吐量。

单个接收报告中的丢失率可以直接用作短期测量指标，该值在会话规模相当大时显得很重要，因为此时报告间隔时间很长，且不一定保存所有接收站的信息，所以基于两个报告之差的长期监测方法实现可能有困难。

另一个关于网络拥塞的短期监测指标是到达时延抖动。分组丢失反映网络长时间拥塞状况，而时延抖动跟踪的是网络瞬态拥塞状况，此时还没有出现分组丢失。作为网络管理者来说，有必要监视和分析许多报告和许多接收站的时延抖动数据，以便了解整个网络的负荷情况。

6.2.3其它RTCP分组

I.SDES分组

SDES分组结构如图6.6所示。它由头部和零个或多个描述数据块组成。头部各字段的含义和SR/RR相同，不再细述。每个数据块的起始字段是信源的SSRC或CSRC标识，其后是零个或多个该信源的描述项（零个合法但无意义）。

图6.6    SD区分组结构

描述项的一般结构如图6.7所示。8比特的类型字段指示该描述项的性质，其编码和描述示例如表6.3所示。其中，只有CNAME是必备描述项，其余都是任选描述项。8比特的长度字段指示描述项文本的字节数。其后是描述文本，给出信源的各种信息。文本由ASCII码字符组成，最大长度为255个字符。各个描述项依次连续排列，结束时设置l个或多个零字节。第1个零字节解释为描述项类型为零，即描述项列表结束，其后零字节为填充字节，使整个描述数据块为32比特字的整数倍。

图6.7      描述项般结构

表6.3    描述项类型编码

端系统发送一个SDES分组，源标识为自己的SSRC，即RTP头部的SSRC。混合器发送l个或多个SDES分组，内含各分信源的描述数据块，分信源用CSRC标识。

在所有描述项中，以CNAME为最重要，它的主要作用是绑定由同一源发生的多个RTP会话流。其描述名的格式为“user@host”或"host",hos（t主机）为规范域名或RTP通信接口的数字地址，它不一定是用户的E-mail地址。如果不能获得域名，也可以使用用户名的形式，但应使用登录名，而不是用户的个人姓名。

用户名描述项对于会议通信很有用，可以向用户显示与会者名单。应用或工具名指示生成数据流的应用程序名及其版本，对程序排错有用。状态通知描述可动态给出信源的当前状态，如“正在接电话，不能发言”等；或可指示讲话者的头衔。专用扩展描述供具体应用自行定义，或可供试验用。

2.BYE分组

BYE分组结构如图6.8所示。它指示一个或多个信源不再工作，退出会话。其中，SC字段指示分组中包含的SSRC/CSRC个数。分组还可给出这些信源退出会话的理由，例如“摄像机故障＂、＂检测到RTP环路”等。

图6.8    BYE分组结构

混合器收到BYE分组，应前转此分组，不改变SSRC/CSRC标识。如果混合器关机，应发送BYE分组，列出自己的SSRC及所有它处理的分信源的CSRC。

3.APP分组

该分组供新应用或新功能试验使用，在试验期间不必申请分组类型值。如果试验表明某分组确实需要，则向Internet号码分配署(LANA-InternetAssignedNumbersAuthority）申请正式的分组类型编码。

至此，我们已经知道各种RTCP控制分组的作用及其结构。如前所述，这些分组都是组装成复合分组后往外发送的，图6.9为复合分组的构成示例，该复合分组由混合器发出。表6.4汇总给出各RTCP分组的分组类型码。

表6.4RTCP分组类型码

图6.9复合分组结构示例

6.2.4RTCP分组发送问隔

RTP的设计使应用能自动适应从几个站点直至几千站点不同的会话规模。例如，在电话会议中，数据话务量具有自我限制特性，因为同时只有1至2个人讲话，所以在多播时每个链路的数据速率基本上是恒定的，与参与会话的站点数没有关系。但是，控制话务量不具备自我限制特性。如果每个站点以恒定速率发送接收报告，则控制话务鼠将随站点数线性增长。因此，必须根据会议规模动态计算RTCP分组发送间隔时间。

对于每个会话来说，总的数据话务量有一个上限，称为＂会话带宽＂，由各参会者分享。该带宽可能通过资源预留获得，或由网络环境限定。通常，会话带宽是同时激活的发送者标准带宽之和，对于电话会议来说，就是一个发送者的带宽。所有与会者必须使用同一个，会话带宽值，这样才能保证计算所得的RTCP间隔相同。带宽计算

应包括下层运输层和网络层（如UDP和IP)的开销，但不包括链路层开销。

计算时应将RTCP话务量限定为会话带宽的一个很小的固定比例，建议值为5%。另外还建议1/4的RTCP带宽分配给会话数据的发送者，这样，对于接收者很多而发送者较少的会话，新加入的与会者很快就能获知数据发送者的CNAME。也可以将控制话务带宽作为一个单独参数处理，或者将发话者和接收者带宽比例作为两个参数处理。无论采用何种方法，关键是所有参会者必须采用同样的参数值进行计算。

计算时还需规定复合分组发送间隔的下限值，以防止突发负荷超限，其建议值为5秒。

所计算的间隔值应随会话组成员数线性调节，以保证控制话务总量恒定。在实际运行时，应允许RTCP分组间隔在计算值的0.5~1.5倍之间变化，以避免不必要的与会站点之间的同步。新加入的会话者应延迟一段时间后才发送RTCP分组，以便首先接收其它站点来的控制分组，使计算间隔值能快速收敛到正确值。

RTCP协议根据上述原则给出了建议算法，算法细节不再在此讨论。

6.2.5 H.323系统的QoS

H.323系统的QoS主要取决于网络传送的QoS，其主要指标有3项：误码率、分组丢失率和时延。

时延增加源自网络拥塞。短时拥塞通过接收端的差错校正来维持i定的质量，长时拥塞需采用反馈机制降低媒体数据话务量。

分组丢失要求接收端能补偿丢失的分组，使差错效应降到最大程度。对于数据和控制信息可以采用重发方式补偿，对于视频和音频信号一般采用预测补偿。

误码一般由低层协议校正，它将造成分组丢失，不在运输层考虑范围之内。

H.323系统利用RTCP的SR和RR分组监测QoS。SR主要用于多RTP流，如音频和视频流之间的同步，和H.225.0密切相关。和流同步相关的字段是RTP时戳和NTP时戳。RR用于监测QoS指标，包括长时指标和短时指标。如果分组丢失率高于设定值，就应降低媒体速率。如果接收报告间隔超过设定值，则应根据RR分组中的丢失率字段判断网络是否严重拥塞，如是，应降低媒体速率。如果连续三个接收报告的到达时延抖动值增加，发送终端应采取措施。

需注意，在H.245中也有测量往返时延的消息：＂往返时延请求“和＂往返时延响应＂，该消息不含时间参数，请求发送端根据两个消息的收发时间差即得往返时延，该时延为传播时延、接收端排队时延和处理时延之总和。而RTCP中根据SR和RR消息计算得出的是单纯的传播时延，直接反映网络传送的QoS。因此，二者监测的是不同的物理量，相互间并不冲突。

为了维持一定的服务质量，当监测到QoS指标下降时，H.323终端和网关应采取一定措施。实际上这些措施并不是保持原有的QoS，而是按照一定的顺序依次降低各种媒体的质款，使得在给定的带宽和负荷条件下仍然能向用户提供可接受的服务。首先考虑降低质量的是视频信号，然后依次为数据、音频和拧制信号。采取的措施可分为两类：短时响应和长时响应，前者旨在解决分组短时丢失和时延增加的短期问题，后者用于网络拥塞日益严重的情况。

      H.323系统中的QoS机制通常包括以下几个方面：

      1.呼叫准入控制（Call Admission Control, CAC）

     CAC用于管理网络中的呼叫数量，防止过多的呼叫导致网络拥塞。它可以基于网络的当前状态和资源预留协议（Resource Reservation Protocol, RSVP）来决定是否接受新的呼叫请求。

      2.流量整形（Traffic Shaping）

     流量整形技术通过调整数据包的发送速率来匹配网络的承载能力，避免突发流量造成网络拥堵。

     3.优先级队列（Priority Queuing）

     在网络设备中设置优先级队列可以确保关键的实时数据流（如语音和视频）获得更高的传输优先级，减少延迟和丢包。

     4.资源预留协议（RSVP）

      RSVP允许应用程序在网络中预留必要的带宽和缓冲区资源，以保证通信质量。

      5.区分服务（Differentiated Services, DiffServ）

      DiffServ是一种网络流量管理框架，通过在网络设备上标记数据包来提供不同等级的服务质量。

短时响应措施包括：

．在短期内降低图像的帧速率。

．将音频和视频信号混合成一个分组，以降低分组速率。

．视频流采用宏块分割(H.261)降低分组速率。长时响应措施包括：

．降低媒体比特率。要求终端改变编码方式，或网关使用速率变换功能。这些改变要用到H.245流量控制命令或逻辑信道信令。

．关闭不太重要的媒体，如关闭视频。

．向接收方发送“适应性忙“信号，同时伴随媒体的关闭，向其指示网络发生拥塞。适应性忙由Q.931ReleaseComplete消息的原因数据单元给出。此外，H.323网关应具有2/4线变换回波控制功能，H.323终端也应具有一定的回波控制功能。