RTCP「建议收藏」

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺

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（SenderReport）：发送者报告，当前活动发送者发送、接收统计。

• RR（ReceiverReport）：接收者报告，非活动发送者接收统计。

• SDES（SourceDescription）：源描述项，包括CNAME, NAME, EMAIL,PHONE等。

• BYE：表示结束。

• APP（application）：应用特定函数。

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

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

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

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

   (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，InternetAssighnedd 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包之后。

   发送者报告包由三部分组成，也可能还有第四个特定设置扩展部分

 

图1 发送者报告包

   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包的前头。

 

图2 接收报告包

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

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

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

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

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

 

源描述RTCP包

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

 

图3 SDES包

   1) 项描述如下：

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

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

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

   2) 源描述项

      源描述项内容如图4所示。

 

 

图4 源描述项

    ①CNAME

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

• 如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定。

• 像SSRC标识，CNAME标识在RTP连接的所有参加者中应是惟一的。

• 为了提供一套相关RTP连接中某个参加者所采用的跨多媒体工具间的绑定，CNAME应固定为那个参加者。

• 为方便第三方监控，CNAME应适合程序或人员定位源。

    ② NAME

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

 

图5 NAME

    ③ E-mail

         电子邮件地址SDES项。邮件地址格式由RFC822规定，如“John.Doe@megacorp.com“。连接期间，电子邮件仍希望保持为常数。

 

 

图6 EMAIL

    ④ PHONE

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

 

 

图7 PHONE

    ⑤LOC

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

 

 

图8 LOC

    ⑥TOOL

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

 

 

图9 TOOL

    ⑦ NOTE

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

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

 

 

图10 NOTE

    ⑧PRIV

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

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

 

断开RTCP包（BYE）

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

 

 

图11 BYE

定义应用的RTCP包（APP）

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

 

 

图12 APP

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

 

图13 速率控制例

基于网络和传输协议的RTP

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

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

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