精华内容
下载资源
问答
  • rtcp:RTCP的Go实现-源码

    2021-03-17 14:39:17
    介子RTCP RTCP的Go实现 有关功能和未来目标的概述,请参见 。 路线图 该库用作我们的WebRTC实施的一部分。 请参考该以跟踪我们的主要里程碑。 社区 在上有一个活跃的社区。 注册并加入#pion频道以进行讨论和支持...
  • 用于收集RTCP-XR(RFC 3611)SIP质量数据包的python库 前任 非常感谢位于的项目。核心概念和处理核心是从那里获得的。 大多数代码已被重构并精简。 基本用法 这应该是更大项目(因此有一个库)的一部分。我强烈建议...
  • rtcp nack 重传抓包

    2020-07-10 17:33:52
    rtcp nack 重传抓包
  • rtp-rtcp rtp-rtcp协议的node模块,这个项目还在建设中。 如何安装 npm install rtp-rtcp 快速开始 var RtpSession=require("rtp-rtcp").RtpSession; var RtpPacket=require("rtp-rtcp").RtpPacket; //server var...
  • The standards for RTP and the RTP Control Protocol (RTCP)are RFCs 1889 and 1890. Also contained in the directory ``main'' is an application that uses the library to play real-time audio streams in ...
  • jrtplib用于rtp/rtcp数据传输的c++开源库, jrtplib用于rtp/rtcp数据传输的c++开源库
  • 简单实现RTSP, RTP, RTCP收发功能,可用于基础入门的学习研究。由于只是闲时兴趣随意花2星期凑出实现,代码及功能并非完善,只是能够多路VLC及MPLAYER作为客户端同时播放。
  • RTCP

    2019-10-15 20:25:10
    RTCP协议介绍 RTCP概要 实时传输控制协议(Real-time ControlProtocol,RTCP)与RTP共同定义在1996年提出的RFC 1889中,是和 RTP一起工作的控制协议。RTCP单独运行在低层协议上,由低层协议提供数据与控制包的...

    RTCP协议介绍

    RTCP概要

    实时传输控制协议(Real-time ControlProtocol,RTCP)与RTP共同定义在1996年提出的RFC 1889中,是和 RTP一起工作的控制协议。RTCP单独运行在低层协议上,由低层协议提供数据与控制包的复用。在RTP会话期间,每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包,如下图所示。对于RTP会话或者广播,通常使用单个多目标广播地址,属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址,通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。


    图  每个参与者周期性地发送RTCP控制信息包

    RTCP功能

    1、为应用程序提供会话质量或者广播性能质量的信息 

    RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据,而是封装发送端(和 / 或者)接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况,这些反馈信息反映了当前的网络状况,对发送端、接收端或者网络管理员都非常有用。RTCP规格没有指定应用程序应该使用这些反馈信息做什么,这完全取决于应用程序开发人员。例如,发送端可以根据反馈信息来调整传输速率,接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的,网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。

    2、确定 RTP用户源 

    RTCP为每个RTP用户提供了一个全局唯一的规范名称 (Canonical Name)标志符 CNAME接收者使用它来追踪一个RTP进程的参加者。当发现冲突或程序重新启动时,RTP中的同步源标识符SSRC可能发生改变,接收者可利用CNAME来跟踪参加者。同时,接收者也需要利用CNAME在相关RTP连接中的几个数据流之间建立联系。当 RTP需要进行音视频同步的时候,接受者就需要使用 CNAME来使得同一发送者的音视频数据相关联,然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。

    3、控制 RTCP传输间隔

    由于每个对话成员定期发送RTCP信息包,随着参加者不断增加,RTCP信息包频繁发送将占用过多的网络资源,为了防止拥塞,必须限制RTCP信息包的流量,控制信息所占带宽一般不超过可用带宽的 5%,因此就需要调整 RTCP包的发送速率。由于任意两个RTP终端之间都互发 RTCP包,因此终端的总数很容易估计出来,应用程序根据参加者总数就可以调整RTCP包的发送速率。

    4、传输最小进程控制信息 

    这项功能对于参加者可以任意进入和离开的松散会话进程十分有用,参加者可以自由进入或离开,没有成员控制或参数协调。

    RTCP信息包

    RTCP也是用UDP来传送的,但RTCP封装的仅仅是一些控制信息,因而分组很短,所以可以将多个RTCP分组封装在一个UDP包中。

    类似于RTP信息包,每个RTCP信息包以固定部分开始,紧接着的是可变长结构单元,最后以一个32位边界结束。

    根据所携带的控制信息不同RTCP信息包可分为RR(接收者报告包)、SR(源报告包)、SEDS(源描述包)、BYE(离开申明)和APP(特殊应用包)五类5类:

    类型

    缩写表示

    用途

    200

    SR(Sender Report)

    发送端报告

    201

    RR(Receiver Report)

    接收端报告

    202

    SDES(Source Description Items)

    源点描述

    203

    BYE

    结束传输

    204

    APP

    特定应用


    TypeDescriptionReferences
    0
    -
    191
      
    192FIR, full INTRA-frame request.RFC 2032
    193NACK, negative acknowledgement.RFC 2032
    194SMPTETC, SMPTE time-code mapping.RFC5484
    195IJ, extended inter-arrival jitter report.RFC 5450
    196
    -
    199
      
    200SR, sender report.RFC 3550
    201RR, receiver report.RFC 3550
    202SDES, source description.RFC 3550
    203BYE, goodbye.RFC 3550
    204APP, application defined.RFC 3550
    205RTPFB, Generic RTP Feedback. 
    206PSFB, Payload-specific Feedback. 
    207XR, RTCP extension.RFC 3611
    208AVB, AVB RTCP packet.IEEE 1733
    209RSI, Receiver Summary Information.RFC 5760
    210
    -
    255
      

    1、SR:

    发送端报告包,用于发送和接收活动源的统计信息;

    发送端报告分组SR(Sender Report)用来使发送端以多播方式向所有接收端报告发送情况。SR分组的主要内容有:相应的RTP流的SSRC,RTP流中最新产生的RTP分组的时间戳和NTP,RTP流包含的分组数,RTP流包含的字节数。SR包的封装如下图所示:


    版本(V):同RTP包头域。

    填充(P):同RTP包头域。

    接收报告计数器(RC):5比特,该SR包中的接收报告块的数目,可以为零。

    包类型(PT):8比特,SR包是200。

    长度域(Length):16比特,其中存放的是该SR包以32比特为单位的总长度减一。

    同步源(SSRC of sender):SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。

    NTP Timestamp(Network time protocol)SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。

    RTP Timestamp:与NTP时间戳对应,与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。

    Sender’s packet count:从开始发送包到产生这个SR包这段时间里,发送者发送的RTP数据包的总数. SSRC改变时,这个域清零。

    Sender`s octet count:从开始发送包到产生这个SR包这段时间里,发送者发送的净荷数据的总字节数(不包括头部和填充)。发送者改变其SSRC时,这个域要清零。

    同步源n的SSRC标识符:该报告块中包含的是从该源接收到的包的统计信息。

    丢失率(Fraction Lost):表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率。

    累计的包丢失数目:从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数。

    收到的扩展最大序列号:从SSRC_n收到的RTP数据包中最大的序列号,

    接收抖动(Interarrival jitter):RTP数据包接受时间的统计方差估计

    上次SR时间戳(Last SR,LSR):取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包,则该域清零。

    上次SR以来的延时(Delay since last SR,DLSR):上次从SSRC_n收到SR包到发送本报告的延时。


    2、RR:

    接收者报告包,用于接收非活动站的统计信息;

    3、SDES:

    源描述包,用于报告和站点相关的信息,包括CNAME;

    4、BYE:

    断开RTCP包,是站点离开系统的报告,表示结束;

    5、APP:

    应用特定函数。



    不同类型的RTCP信息包可堆叠,不需要插入任何分隔符就可以将多个RTCP包连接起来形成一个RTCP组合包,然后由低层协议用单一包发送出去。由于需要低层协议提供整体长度来决定组合包的结尾,在组合包中没有单个RTCP包的显式计数。

    组合包中每个RTCP包可独立处理,而不需要按照包组合的先后顺序处理。在组合包中有以下几条强制约束:

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

    2、每个组合包中都应该包含SDES CNAME,因为新接收者需要通过接收CNAME来识别源,并与媒体联系进行同步。

    3、组合包前面是包类型数量,其增长应该受到限制。


    所有RTCP包至少必须以两个包组合形式发送,推荐格式如下:

    加密前缀(Encryption prefix):

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

    SR或RR:

    组合包中第一个RTCP包必须是一个报告包,以帮助分组头的确认。即使没有数据发送,也没有接收到数据,也要发送一个空RR,那怕组合包中RTCP包为BYE。

    附加RR:

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

    SDES:

    包含CNAME 项的SDES包必须包含在每个组合RTCP包中。SDES包可能包括其他源描述项,这要根据特别的应用需要,并同时考虑带宽限制。

    BYE或APP:

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

    混合器从多个源组合单个RTCP包,如组合包整体长度超过网络路径最大传输单元,可分成多个较短组合包用低层协议以单个包形式发送。注意,每个组合包必须以SR或RR包开始。附加RTCP包类型可在Internet Assigned NumbersAuthority (IANA)处注册,以获得合法的类型号。

    RTCP传输间隔

    由于RTP设计成允许应用自动扩展,可从几个人的小规模系统扩展成上千人的大规模系统。而每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包,如每个参与者以固定速率发送接收报告,控制流量将随参与者数量线性增长。由于网络资源有限,相应的数据包就要减少,直接影响用户关心的数据传输。为了限制控制信息的流量,RTCP控制信息包速率必须按比例下降。

    一旦确认加入到RTP会话中,即使后来被标记成非活动站,地址的状态仍会被保留,地址应继续计入共享RTCP带宽地址的总数中,时间要保证能扫描典型网络分区,建议为30分钟。注意,这仍大于RTCP报告间隔最大值的五倍。

    SR源报告包和RR接收者报告包

    SR源报告包和RR接收者报告包用于提供接收质量反馈,除包类型代码外,SR与RR间唯一的差别是源报告包含有一个20字节发送者信息段。RR针对每个信源都提供信息包丢失数、已收信息包最大序列号、到达时间抖动、接收最后一个SR的时间、接收最后一个SR的延迟等信息。SR不仅提供接收质量反馈信息(与RR相同),而且提供SSRC标识符、NTP时间戳、RTP时间戳、发送包数以及发送字节数等。根据接收者是否为发送者来决定使用SR还是RR包,活动源在发出最后一个数据包之后或前一个数据包与下一个数据包间隔期间发送SR;否则,就发送RR;SR和RR包都可没有接收报告块也可以包括多个接收报告块,其发布报告表示的源不一定是在CSRC列表上的起作用的源,每个接收报告块提供从特殊源接收数据的统计。最大可有31个接收报告块嵌入在SR 或 RR包中,丢失包累计数差别给出间隔期间丢包的数量,而系列号的差别给出间隔期间希望发送的包数量,两者之比等于经过间隔期间包丢失百分比。从发送者信息,第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率,两者比值给出平均载荷大小。如假设包丢失与包大小无关,那么特殊接收者收到的包数量给出此接收者收到的表观流量。

    SDES源描述包

    SDES源描述包提供了直观的文本信息来描述会话的参加者,包括CNAME、NAME、EMAIL、PHONE、LOC等源描述项,这些为接收方获取发送方的有关信息提供了方便。SDES 包由包头与数据块组成,数据块可以没有,也可有多个。包头由版本(V)、填充(P)、长度指示、包类型(PT)和源计数(SC)组成。PT占8位,用于识别RTCP的SDES包,SC占5位,指示包含在SDES包中的SSRC/CSRC块数量,零值有效,但没有意义。数据块由源描述项组成,源描述项的内容如下:

    CNAME: 规范终端标识SDES项

    类似SSRC标识,RTCP为RTP连接中每一个参加者赋予唯一一个CNAME标识。在发生冲突或重启程序时,由于随机分配的SSRC标识可能发生变化,CNAME项可以提供从SSRC标识到仍为常量的源标识的绑定。

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

    NAME:用户名称SDES项

    这是用于描述源的真正的名称,如"John Doe, Bit Recycler, Megacorp",可以是用户想要的任意形式。由于采用文本信息来描述,对诸如会议应用,可以对参加者直接列表显示,NAME项是除CNAME项以外发送最频繁的项目。NAME值在一次RTP会话期间应该保持为常数,但它不该成为连接的所有参加者中唯一依赖。

    EMAIL:电子邮件地址SDES项

    邮件地址格式由RFC822规定,如"John.Doe@megacorp.com"。一次RTP会话期间,EMAIL项的内容希望保持不变。

    PHONE:电话号码SDES项

    电话号码应带有加号,代替国际接入代码,如"+1 908 555 1212"即为美国电话号码。 

    LOC:用户地理位置SDES项

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

    TOOL:应用或工具名称SDES项

    TOOL项包含一个字符串,表示产生流的应用的名称与版本,如"videotool 1.2"。这部分信息对调试很有用,类似于邮件或邮件系统版本SMTP头。TOOL值在一次RTP会话期间保持不变。

    NOTE: 通知/状态SDES项

    NOTE 项旨在描述源当前状态的过渡信息,如"on the phone, can't talk",或在讲座期间用于传送谈话的题目,它的语法可在设置中显式定义。NOTE项一般只用于携带例外信息,而不应包含在全部参加者中,因为这将降低接收报告和CNAME发送的速度,损害协议的性能。一般NOTE 项不作为用户设置文件的项目,也不会自动产生。

    由于NOTE项对显示很重要,当会话的参加者处于活动状态时,其它非CNAME项(如NAME)传输速率将会降低,结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃,NOTE项继续以同样的速度重复发送几次,并以一个串长为零的字符串通知接收者。

    PRIV: 专用扩展SDES项

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

    注意,前缀应尽可能的短。SDES的PRIV项前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性, IANA应给它分配一个正式的SDES项类型,这样就不再需要前缀,从而简化应用,并提高传输的效率。

    BYE断开RTCP包

    如混合器接收到一个BYE包,混合器转发BYE包,而不改变SSRC/CSRC 标识。如混合器关闭,在关闭之前它应该发出一个BYE包,列出混合器处理的所有源,而不只是自己的SSRC标识。作为可选项,BYE包可包括一个8位八进制计数,后跟文本信息,表示离开原因,如:"cameramalfunction"或"RTPloop detected"。字符串的编码与在SDES 项中所描述的相同。如字符串信息至BYE包下32位边界结束处,字符串就不以空结尾;否则,BYE包以空八进制填充。

    APP特殊应用包

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

    RTP/ RTCP的不足之处

    RTP与RTCP相结合虽然保证了实时数据的传输,但也有自己的缺点。最显著的是当有许多用户一起加入会话进程的时候,由于每个参与者都周期发送RTCP信息包,导致RTCP包泛滥(flooding)。

     

    展开全文
  • BECKHOFF CNC 中的RTCP功能的使用
  • 提供如何使用wireshark进行抓包RTSP, RTP调试,了解RTSP, RTP的协议及客户端与服务端的交互过程,方便大家debug。
  • RTCP概要 实时传输控制协议(Real-timeControlProtocol,RTCP)与RTP共同定义在1996年提出的RFC 1889中,是和 RTP一起工作的控制协议。RTCP单独运行在低层协议上,由低层协议提供数据与控制包的复用。在RTP会话期间...

    一、概要

    RTCP(Real-time ControlProtocol,RTCP-译:实时传输控制协议)与RTP是 由RFC 3550定义(1996年提出的RFC 1889已经作废)。RTCP与RTP联合工作,RTP用于音视频媒体流数据的传输,RTCP则负责在发送端与接收端之间传输一些控制信息。最主要的用途是RTP接收端向发送端提供服务质量反馈。RTCP单独运行在传输层协议上,由低层协议提供数据与控制包的复用。在RTP会话期间,每个会话的RTP数据接收端周期性地向其发送端发送RTCP控制信息包,如下图所示。对于RTP会话或者广播,通常使用单个多目标广播地址,属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址,RTP 使用一个 偶数 UDP port ;而RTCP 则使用 RTP 的 port + 1,也就是一个奇数 port,例如如果发送RTP数据用3618,则此会话发送RTCP的端口是3619。


    图  每个接收端周期性地向发送端反馈RTCP控制信息包

    二、用途说明

    1、为应用程序提供会话质量或者广播性能质量的信息 

    RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据,而是封装发送端(和 / 或者)接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况,这些反馈信息反映了当前的网络状况,对发送端、接收端或者网络管理员都非常有用。RTCP规格没有指定应用程序应该使用这些反馈信息做什么,这完全取决于应用程序开发人员。例如,发送端可以根据反馈信息来调整传输速率,接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的,网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。

    2、确定 RTP用户源 

    RTCP为每个RTP用户提供了一个全局唯一的规范名称 (Canonical Name)标志符 CNAME接收者使用它来追踪一个RTP进程的参加者。当发现冲突或程序重新启动时,RTP中的同步源标识符SSRC可能发生改变,接收者可利用CNAME来跟踪参加者。同时,接收者也需要利用CNAME在相关RTP连接中的几个数据流之间建立联系。当 RTP需要进行音视频同步的时候,接受者就需要使用 CNAME来使得同一发送者的音视频数据相关联,然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。

    3、控制 RTCP传输间隔

    由于每个对话成员定期发送RTCP信息包,随着参加者不断增加,RTCP信息包频繁发送将占用过多的网络资源,为了防止拥塞,必须限制RTCP信息包的流量,控制信息所占带宽一般不超过可用带宽的 5%,因此就需要调整 RTCP包的发送速率。由于任意两个RTP终端之间都互发 RTCP包,因此终端的总数很容易估计出来,应用程序根据参加者总数就可以调整RTCP包的发送速率。

    4、传输最小进程控制信息 

    这项功能对于参加者可以任意进入和离开的松散会话进程十分有用,参加者可以自由进入或离开,没有成员控制或参数协调。

    三、RTCP数据包定义

    RTCP也是用UDP来传送的,但RTCP封装的仅仅是一些控制信息,因而分组很短,所以可以将多个RTCP分组封装在一个UDP包中。

    类似于RTP信息包,每个RTCP信息包以固定部分开始,紧接着的是可变长结构单元,最后以一个32位边界结束。

    根据所携带的控制信息不同RTCP信息包可分为RR(接收者报告包)、SR(源报告包)、SEDS(源描述包)、BYE(离开申明)和APP(特殊应用包)五类5类:

     

    类型

    缩写表示

    用途

    200

    SR(Sender Report)

    发送端报告

    201

    RR(Receiver Report)

    接收端报告

    202

    SDES(Source Description Items)

    源点描述

    203

    BYE

    结束传输

    204

    APP

    特定应用

    在相关RFC中定义如下:

    类型说明引用
    0
    -
    191
      
    192FIR, full INTRA-frame request.RFC 2032
    193NACK, negative acknowledgement.RFC 2032
    194SMPTETC, SMPTE time-code mapping.RFC5484
    195IJ, extended inter-arrival jitter report.RFC 5450
    196
    -
    199
      
    200SR, sender report.RFC 3550
    201RR, receiver report.RFC 3550
    202SDES, source description.RFC 3550
    203BYE, goodbye.RFC 3550
    204APP, application defined.RFC 3550
    205RTPFB, Generic RTP Feedback. 
    206PSFB, Payload-specific Feedback. 
    207XR, RTCP extension.RFC 3611
    208AVB, AVB RTCP packet.IEEE 1733
    209RSI, Receiver Summary Information.RFC 5760
    210
    -
    255
      

    详细的数据包格式

    1、SR:

    发送端报告包,用于发送和接收活动源的统计信息;

    发送端报告分组SR(Sender Report)用来使发送端以多播方式向所有接收端报告发送情况。SR分组的主要内容有:相应的RTP流的SSRC,RTP流中最新产生的RTP分组的时间戳和NTP,RTP流包含的分组数,RTP流包含的字节数。SR包的封装如下图所示:

    版本(V):同RTP包头域。

    填充(P):同RTP包头域。

    接收报告计数器(RC):5比特,该SR包中的接收报告块的数目,可以为零。

    包类型(PT):8比特,SR包是200。

    长度域(Length):16比特,其中存放的是该SR包以32比特为单位的总长度减一。

    同步源(SSRC of sender):SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。

    NTP Timestamp(Network time protocol)SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。

    RTP Timestamp:与NTP时间戳对应,与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。

    Sender’s packet count:从开始发送包到产生这个SR包这段时间里,发送者发送的RTP数据包的总数. SSRC改变时,这个域清零。

    Sender`s octet count:从开始发送包到产生这个SR包这段时间里,发送者发送的净荷数据的总字节数(不包括头部和填充)。发送者改变其SSRC时,这个域要清零。

    同步源n的SSRC标识符:该报告块中包含的是从该源接收到的包的统计信息。

    丢失率(Fraction Lost):表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率。

    累计的包丢失数目:从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数。

    收到的扩展最大序列号:从SSRC_n收到的RTP数据包中最大的序列号,

    接收抖动(Interarrival jitter):RTP数据包接受时间的统计方差估计

    上次SR时间戳(Last SR,LSR):取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包,则该域清零。

    上次SR以来的延时(Delay since last SR,DLSR):上次从SSRC_n收到SR包到发送本报告的延时。

     

    2、RR:

    用来使接收端周期性的向发送端进行报告。内容包括

    所接收到的RTP流的SSRC;该RTP流的分组丢失率;在该RTP流中的最后一个RTP分组的序号;分组到达时间间隔的抖动等。

    发送RR分组有两个目的。第一,可以使所有的接收端和发送端了解当前网络的状态。

    第二,可以使所有发送RTCP分组的站点自适应的调整自己发送RTCP分组的速率,RTCP分组的通信量不超过网络中的数据分组的通信量的5%,而接收端分组报告分组的通信量又应小于所有RTCP分组的通信量的75%。

    3、SDES:

    源描述包,给出会话中参加者的描述,包括参加者的规范名(CNAME);

    4、BYE:

    断开RTCP包,是站点离开系统的报告,表示结束;

    5、APP:

    应用特定的分组类型。

    不同类型的RTCP信息包可堆叠,不需要插入任何分隔符就可以将多个RTCP包连接起来形成一个RTCP组合包,然后由低层协议用单一包发送出去。由于需要低层协议提供整体长度来决定组合包的结尾,在组合包中没有单个RTCP包的显式计数。

    组合包中每个RTCP包可独立处理,而不需要按照包组合的先后顺序处理。在组合包中有以下几条强制约束:

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

    2、每个组合包中都应该包含SDES CNAME,因为新接收者需要通过接收CNAME来识别源,并与媒体联系进行同步。

    3、组合包前面是包类型数量,其增长应该受到限制。

     

    所有RTCP包至少必须以两个包组合形式发送,推荐格式如下:

    加密前缀(Encryption prefix):

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

    SR或RR:

    组合包中第一个RTCP包必须是一个报告包,以帮助分组头的确认。即使没有数据发送,也没有接收到数据,也要发送一个空RR,那怕组合包中RTCP包为BYE。

    附加RR:

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

    SDES:

    包含CNAME 项的SDES包必须包含在每个组合RTCP包中。SDES包可能包括其他源描述项,这要根据特别的应用需要,并同时考虑带宽限制。

    BYE或APP:

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

    混合器从多个源组合单个RTCP包,如组合包整体长度超过网络路径最大传输单元,可分成多个较短组合包用低层协议以单个包形式发送。注意,每个组合包必须以SR或RR包开始。附加RTCP包类型可在Internet Assigned NumbersAuthority (IANA)处注册,以获得合法的类型号。

    四、RTCP传输间隔

    由于RTP设计成允许应用自动扩展,可从几个人的小规模系统扩展成上千人的大规模系统。而每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包,如每个参与者以固定速率发送接收报告,控制流量将随参与者数量线性增长。由于网络资源有限,相应的数据包就要减少,直接影响用户关心的数据传输。为了限制控制信息的流量,RTCP控制信息包速率必须按比例下降。

    一旦确认加入到RTP会话中,即使后来被标记成非活动站,地址的状态仍会被保留,地址应继续计入共享RTCP带宽地址的总数中,时间要保证能扫描典型网络分区,建议为30分钟。注意,这仍大于RTCP报告间隔最大值的五倍。

    SR源报告包和RR接收者报告包

    SR源报告包和RR接收者报告包用于提供接收质量反馈,除包类型代码外,SR与RR间唯一的差别是源报告包含有一个20字节发送者信息段。RR针对每个信源都提供信息包丢失数、已收信息包最大序列号、到达时间抖动、接收最后一个SR的时间、接收最后一个SR的延迟等信息。SR不仅提供接收质量反馈信息(与RR相同),而且提供SSRC标识符、NTP时间戳、RTP时间戳、发送包数以及发送字节数等。根据接收者是否为发送者来决定使用SR还是RR包,活动源在发出最后一个数据包之后或前一个数据包与下一个数据包间隔期间发送SR;否则,就发送RR;SR和RR包都可没有接收报告块也可以包括多个接收报告块,其发布报告表示的源不一定是在CSRC列表上的起作用的源,每个接收报告块提供从特殊源接收数据的统计。最大可有31个接收报告块嵌入在SR 或 RR包中,丢失包累计数差别给出间隔期间丢包的数量,而系列号的差别给出间隔期间希望发送的包数量,两者之比等于经过间隔期间包丢失百分比。从发送者信息,第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率,两者比值给出平均载荷大小。如假设包丢失与包大小无关,那么特殊接收者收到的包数量给出此接收者收到的表观流量。

    SDES源描述包

    SDES源描述包提供了直观的文本信息来描述会话的参加者,包括CNAME、NAME、EMAIL、PHONE、LOC等源描述项,这些为接收方获取发送方的有关信息提供了方便。SDES 包由包头与数据块组成,数据块可以没有,也可有多个。包头由版本(V)、填充(P)、长度指示、包类型(PT)和源计数(SC)组成。PT占8位,用于识别RTCP的SDES包,SC占5位,指示包含在SDES包中的SSRC/CSRC块数量,零值有效,但没有意义。数据块由源描述项组成,源描述项的内容如下:

    CNAME: 规范终端标识SDES项

    类似SSRC标识,RTCP为RTP连接中每一个参加者赋予唯一一个CNAME标识。在发生冲突或重启程序时,由于随机分配的SSRC标识可能发生变化,CNAME项可以提供从SSRC标识到仍为常量的源标识的绑定。

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

    NAME:用户名称SDES项

    这是用于描述源的真正的名称,如"John Doe, Bit Recycler, Megacorp",可以是用户想要的任意形式。由于采用文本信息来描述,对诸如会议应用,可以对参加者直接列表显示,NAME项是除CNAME项以外发送最频繁的项目。NAME值在一次RTP会话期间应该保持为常数,但它不该成为连接的所有参加者中唯一依赖。

    EMAIL:电子邮件地址SDES项

    邮件地址格式由RFC822规定,如"John.Doe@megacorp.com"。一次RTP会话期间,EMAIL项的内容希望保持不变。

    PHONE:电话号码SDES项

    电话号码应带有加号,代替国际接入代码,如"+1 908 555 1212"即为美国电话号码。 

    LOC:用户地理位置SDES项

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

    TOOL:应用或工具名称SDES项

    TOOL项包含一个字符串,表示产生流的应用的名称与版本,如"videotool 1.2"。这部分信息对调试很有用,类似于邮件或邮件系统版本SMTP头。TOOL值在一次RTP会话期间保持不变。

    NOTE: 通知/状态SDES项

    NOTE 项旨在描述源当前状态的过渡信息,如"on the phone, can't talk",或在讲座期间用于传送谈话的题目,它的语法可在设置中显式定义。NOTE项一般只用于携带例外信息,而不应包含在全部参加者中,因为这将降低接收报告和CNAME发送的速度,损害协议的性能。一般NOTE 项不作为用户设置文件的项目,也不会自动产生。

    由于NOTE项对显示很重要,当会话的参加者处于活动状态时,其它非CNAME项(如NAME)传输速率将会降低,结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃,NOTE项继续以同样的速度重复发送几次,并以一个串长为零的字符串通知接收者。

    PRIV: 专用扩展SDES项

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

    注意,前缀应尽可能的短。SDES的PRIV项前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性, IANA应给它分配一个正式的SDES项类型,这样就不再需要前缀,从而简化应用,并提高传输的效率。

    BYE断开RTCP包

    如混合器接收到一个BYE包,混合器转发BYE包,而不改变SSRC/CSRC 标识。如混合器关闭,在关闭之前它应该发出一个BYE包,列出混合器处理的所有源,而不只是自己的SSRC标识。作为可选项,BYE包可包括一个8位八进制计数,后跟文本信息,表示离开原因,如:"cameramalfunction"或"RTPloop detected"。字符串的编码与在SDES 项中所描述的相同。如字符串信息至BYE包下32位边界结束处,字符串就不以空结尾;否则,BYE包以空八进制填充。

    APP特殊应用包

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

    展开全文
  • RTP/RTCP协议的解析
  • rtp和rtcp

    2021-08-16 19:42:17
    RTP协议和RTP控制协议RTCP一起使用,而且它是建立在用户数据报协议上的(UDP)。 RTP标准定义了两个子协议 ,RTP和RTCP 数据传输协议RTP,用于实时传输数据。该协议提供的信息包括:时间戳(用于同步)、序列号...

    1、RTP 

    1.1、RTP 简介

    实时传输协议RTP(Real-time Transport Protocol)是一个网络传输协议。RTP协议和RTP控制协议RTCP一起使用,而且它是建立在用户数据报协议上的(UDP)。

    RTP标准定义了两个子协议 ,RTP和RTCP

    数据传输协议RTP,用于实时传输数据。该协议提供的信息包括:时间戳(用于同步)、序列号(用于丢包和重排序检测)、以及负载格式(用于说明数据的编码格式)。

    控制协议RTCP,用于QoS反馈和同步媒体流。相对于RTP来说,RTCP所占的带宽非常小,通常只有5%。
     

    1.2、RTP的协议层次

    这里写图片描述

     从图中可以看出,RTP被划分在传输层,它建立在UDP上。同UDP协议一样,为了实现其实时传输功能,RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步,但并不保证服务质量。服务质量由RTCP来提供。

    1.3、RTP的工作机制为


            当应用程序建立一个RTP会话时,应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成,有两个端口:一个给RTP包,一个给RTCP包,使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口,而对应的控制信号RTCP数据发向相邻的奇数UDP端口(偶数的UDP端口+1),这样就构成一个UDP端口对。 

    1.4、RTP Header解析

    以上为RTP头,可以看到其固定前三行,为12个字节,后面的CSRC(....)表示视情况加入。

    1)        V:RTP协议的版本号,占2位,当前协议版本号为2

    2)        P:填充标志,占1位,如果P=1,则在该报文的尾部填充一个或多个额外的八位组,它们不是有效载荷的一部分。(就是下面的6)表示的)

    3)        X:扩展标志,占1位,如果X=1,则在RTP报头后跟有一个扩展报头

    4)        CC:CSRC计数器,占4位,指示CSRC 标识符的个数

    5)        M: 标记,占1位,不同的有效载荷有不同的含义,对于视频,标记一帧的结束;对于音频,标记会话的开始。

    6)        PT: 有效荷载类型,占7位,用于说明RTP报文中有效载荷的类型,如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的,这样便于客户端进行解析,常用荷载类型如下。

    Payload TypeCodec
    0PCM μ -Law
    8PCM-A Law
    9G..722 audio codec
    4G..723 audio codec
    15G..728 audio codec
    18G..729 audio codec
    34G..763 audio codec
    31G..761 audio codec

    7)        序列号:占16位,用于标识发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。这个字段当下层的承载协议用UDP的时候,网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序,序列号的初始值是随机的,同时音频包和视频包的sequence是分别记数的。

    8)        时戳(Timestamp):占32位,必须使用90 kHz 时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。

    9)        同步信源(SSRC)标识符:占32位,用于标识同步信源。该标识符是随机选择的,参加同一视频会议的两个同步信源不能有相同的SSRC。

    10)    特约信源(CSRC)标识符:0~15项,每项32比特,用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来,以便接收端能正确指出交谈双方的身份。

    如果上面3)的字段为1,表示有个扩展头,其跟在CSRC后面,其扩展头格式如下

    这里写图片描述

     头扩展包含 16 比特的长度域,及length,指示扩展项中 32 比特字的个数,但不包括 4 个字节扩展头(及不包括图片上的   defined by profile 和 length字段)

    example:

    取一段码流如下:

    80 e0 00 1e 00 00 d2 f0 00 00 00 00 41 9b 6b 49 €?....??....A?kI

    e1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P.

    cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f'|?

    f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9 ??)????>.??l?Q??

    cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ????

    其中,
    80               是V_P_X_CC
    e0               是M_PT
    00 1e          是SequenceNum
    00 00 d2 f0 是Timestamp
    00 00 00 00是SSRC
    把前两字节换成二进制如下
    1000 0000 1110 0000
    按顺序解释如下:
    10               是V;
    0                 是P;
    0                 是X;
    0000           是CC;
    1                 是M;
    110 0000    是PT;

    1.5、RTP荷载H264码流

    上面1.7)说了RTP可以荷载很多类型,这里我们说下荷载H264码流。

    我们知道,在H.264/AVC视频编码标准中,整个系统框架被分为了两个层面:视频编码层面(VCL)和网络抽象层面(NAL)。其中,前者负责有效表示视频数据的内容,而后者则负责格式化数据并提供头信息,以保证数据适合各种信道和存储介质上的传输。因此我们平时的每帧数据就是一个NAL单元(SPS与PPS除外)。在实际的H264数据帧中,往往帧前面带有00 00 00 01 或 00 00 01分隔符,一般来说编码器编出的首帧数据为PPS与SPS,接着为I帧……

    NAL单元由NALU头和NALU主体构成。NALU头的定义如下

    对应字段解释如下

    1)       F:   1个比特.
      forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0.

    2)       NRI: 2个比特.
      nal_ref_idc. 取00~11,似乎指示这个NALU的重要性,如00的NALU解码器可以丢弃它而不影响图像的回放,0~3,取值越大,表示当前NAL越重要,需要优先受到保护。如果当前NAL是属于参考帧的片,或是序列参数集,或是图像参数集这些重要的单位时,本句法元素必需大于0。

    3)       Type: 5个比特.
      nal_unit_type. 这个NALU单元的类型,1~12由H.264使用,24~31由H.264以外的应用使用,简述如下:

    技术分享

    在荷载H264码流时,定义了三个不同的基本荷载结构,通过NALU头的后五位3)Type区分

    1)   单个NAL单元包:荷载中只包含一个NAL单元。NAL头类型域等于原始 NAL单元类型,即在范围1到23之间

    2)   聚合包:本类型用于聚合多个NAL单元到单个RTP荷载中。本包有四种版本,单时间聚合包类型A (STAP-A),单时间聚合包类型B (STAP-B),多时间聚合包类型(MTAP)16位位移(MTAP16), 多时间聚合包类型(MTAP)24位位移(MTAP24)。赋予STAP-A, STAP-B, MTAP16, MTAP24的NAL单元类型号分别是 24,25, 26, 27

    3)   分片单元:用于分片单个NAL单元到多个RTP包。现存两个版本FU-A,FU-B,用NAL单元类型 28,29标识

    常用的打包时的分包规则是:如果小于MTU采用单个NAL单元包,如果大于MTU就采用FUs分片方式。

    因为常用的打包方式就是单个NAL包和FU-A方式,所以我们只解析这两种。

    1.5.1、单个NAL单元包

    定义在此的NAL单元包必须只包含一个。这意味聚合包和分片单元不可以用在单个NAL 单元包中。并且RTP序号必须符合NAL单元的解码顺序。如下图

     1.5.2、分片单元(FU-A)

    下图表示FU-A的RTP荷载格式。

     分片只定义于单个NAL单元不用于任何聚合包。NAL单元的一个分片由整数个连续NAL单元字节组成。每个NAL单元字节必须正好是该NAL单元一个分片的一部分。相同NAL单元的分片必须使用递增的RTP序号连续顺序发送(第一和最后分片之间没有其他的RTP包)。相似,NAL单元必须按照RTP顺序号的顺序装配。
     

     当一个NAL单元被分片运送在分片单元(FUs)中时,被引用为分片NAL单元。STAPs,MTAPs不可以被分片。 FUs不可以嵌套。 即, 一个FU 不可以包含另一个FU。运送FU的RTP时戳被设置成分片NAL单元的NALU时刻。

    FU-A由1字节的分片单元指示(如下图左),1字节的分片单元头(如下图右),和分片单元荷载组成。

    分片单元指示:

    字段F、NRI、Type在上面说过,这里不再说明。 Type这里由上面说的,因为是FU-A,所以值为28。

    分片单元荷载:

    1)       S: 1 bit 当设置成1,开始位指示分片NAL单元的开始。当跟随的FU荷载不是分片NAL单元荷载的开始,开始位设为0。

    2)       E: 1 bit 当设置成1, 结束位指示分片NAL单元的结束,即, 荷载的最后字节也是分片NAL单元的最后一个字节。当跟随的 FU荷载不是分片NAL单元的最后分片,结束位设置为0。

    3)       R: 1 bit 保留位必须设置为0,接收者必须忽略该位

    取一段码流分析如下:
    80 60 01 0f 00 0e 10 00 00 0000 00 7c 85 88 82 €`..........|???

    00 0a 7f ca 94 05 3b7f 3e 7f fe 14 2b 27 26 f8 ...??.;.>.?.+'&?

    89 88 dd 85 62 e1 6dfc 33 01 38 1a 10 35 f2 14 ????b?m?3.8..5?.

    84 6e 21 24 8f 72 62f0 51 7e 10 5f 0d 42 71 12 ?n!$?rb?Q~._.Bq.

    17 65 62 a1 f1 44 dc df 4b 4a 38 aa 96 b7 dd 24 .eb??D??KJ8????$
     
    前12字节是RTP Header
    7c是FU indicator
    85是FU Header
    FU indicator(0x7C)和FU Header(0x85)换成二进制如下
    0111 1100 1000 0101
    按顺序解析如下:
    0                            是F
    11                          是NRI
    11100                    是FU Type,这里是28,即FU-A
    1                            是S,Start,说明是分片的第一包
    0                            是E,End,如果是分片的最后一包,设置为1,这里不是
    0                            是R,Remain,保留位,总是0
    00101                    是NAl Type,这里是5,说明是关键帧(不知道为什么是关键帧请自行谷歌)
     
    打包时,FUindicator的F、NRI是NAL Header中的F、NRI,Type是28;FU Header的S、E、R分别按照分片起始位置设置,Type是NAL Header中的Type。

    解包时,取FU indicator的前三位和FU Header的后五位,即0110 0101(0x65)为NAL类型。
    打包时,原始的NAL头的前三位为FU indicator的前三位,原始的NAL头的后五位为FU header的后五位。

    2 rtcp

    2.1 rtcp简介

    实时传输控制协议(Real-time ControlProtocol,RTCP)与RTP共同定义在1996年提出的RFC 1889中,是和 RTP一起工作的控制协议。RTCP单独运行在低层协议上,由低层协议提供数据与控制包的复用。在RTP会话期间,每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包,如下图所示。对于RTP会话或者广播,通常使用单个多目标广播地址,属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址,通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。

     2.2 rtcp功能

    1、为应用程序提供会话质量或者广播性能质量的信息

    RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据,而是封装发送端(和 / 或者)接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况,这些反馈信息反映了当前的网络状况,对发送端、接收端或者网络管理员都非常有用。RTCP规格没有指定应用程序应该使用这些反馈信息做什么,这完全取决于应用程序开发人员。例如,发送端可以根据反馈信息来调整传输速率,接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的,网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。

    2、确定 RTP用户源

    RTCP为每个RTP用户提供了一个全局唯一的规范名称 (Canonical Name)标志符 CNAME,接收者使用它来追踪一个RTP进程的参加者。当发现冲突或程序重新启动时,RTP中的同步源标识符SSRC可能发生改变,接收者可利用CNAME来跟踪参加者。同时,接收者也需要利用CNAME在相关RTP连接中的几个数据流之间建立联系。当 RTP需要进行音视频同步的时候,接受者就需要使用 CNAME来使得同一发送者的音视频数据相关联,然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。
     

    3、控制 RTCP传输间隔

    由于每个对话成员定期发送RTCP信息包,随着参加者不断增加,RTCP信息包频繁发送将占用过多的网络资源,为了防止拥塞,必须限制RTCP信息包的流量,控制信息所占带宽一般不超过可用带宽的 5%,因此就需要调整 RTCP包的发送速率。由于任意两个RTP终端之间都互发 RTCP包,因此终端的总数很容易估计出来,应用程序根据参加者总数就可以调整RTCP包的发送速率。
     

    4、传输最小进程控制信息 

    这项功能对于参加者可以任意进入和离开的松散会话进程十分有用,参加者可以自由进入或离开,没有成员控制或参数协调。

    2.3 rtcp信息包

    RTCP也是用UDP来传送的,但RTCP封装的仅仅是一些控制信息,因而分组很短,所以可以将多个RTCP分组封装在一个UDP包中。
    类似于RTP信息包,每个RTCP信息包以固定部分开始,紧接着的是可变长结构单元,最后以一个32位边界结束。

    根据所携带的控制信息不同RTCP信息包可分为RR(接收者报告包)、SR(源报告包)、SEDS(源描述包)、BYE(离开申明)和APP(特殊应用包)五类5类:

    类型缩写表示用途
    200SR(Sender Report)发送端报告
    201RR(Receiver Report)接收端报告
    202SDES(Source Description Items)源点描述
    203BYE结束传输
    204APP特定应用

    2.3.1五类信息包介绍

    1、SR:
    发送端报告包,用于发送和接收活动源的统计信息;

    发送端报告分组SR(Sender Report)用来使发送端以多播方式向所有接收端报告发送情况。SR分组的主要内容有:相应的RTP流的SSRC,RTP流中最新产生的RTP分组的时间戳和NTP,RTP流包含的分组数,RTP流包含的字节数。SR包的封装如下图所示:

    版本(V):同RTP包头域。

    填充(P):同RTP包头域。

    接收报告计数器(RC):5比特,该SR包中的接收报告块的数目,可以为零。

    包类型(PT):8比特,SR包是200。

    长度域(Length):16比特,其中存放的是该SR包以32比特为单位的总长度减一。该字段中大小的表示比较有意思,使用4个字节为1组,长度共有几个4个字节的组,然后用该长度减去1,即为RTCP包中的长度!举个栗子:假设RTCP数据包的长度为32个字节,32/4=8,总共有8组4个字节,8-1=7,此时RTCP数据包中length的值为7。

    同步源(SSRC of sender):SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。

    NTP Timestamp(Network time protocol)SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。

    RTP Timestamp:与NTP时间戳对应,与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。

    Sender’s packet count:从开始发送包到产生这个SR包这段时间里,发送者发送的RTP数据包的总数. SSRC改变时,这个域清零。

    Sender`s octet count:从开始发送包到产生这个SR包这段时间里,发送者发送的净荷数据的总字节数(不包括头部和填充)。发送者改变其SSRC时,这个域要清零。

    同步源n的SSRC标识符:该报告块中包含的是从该源接收到的包的统计信息。

    丢失率(Fraction Lost):表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率。

    累计的包丢失数目:从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数。

    收到的扩展最大序列号:从SSRC_n收到的RTP数据包中最大的序列号,

    接收抖动(Interarrival jitter):RTP数据包接受时间的统计方差估计

    上次SR时间戳(Last SR,LSR):取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包,则该域清零。如上一个SR数据包的NTP时间戳为“0x 00 01 7d 6e 3b 64 5a 1c ”,则LSR为0x  7d 6e 3b 64! 

    上次SR以来的延时(Delay since last SR,DLSR):上次从SSRC_n收到SR包到发送本报告的延时。以1/65536为单位,如,本次RR包与上一次SR的时间间隔为264ms,则本字段的值为0.264*65536=17301.54。

    2、RR:

    接收者报告包,用于接收非活动站的统计信息;

    3、SDES

    源描述包,用于报告和站点相关的信息,包括CNAME;

    SDES源描述包提供了直观的文本信息来描述会话的参加者,包括CNAME、NAME、EMAIL、PHONE、LOC等源描述项,这些为接收方获取发送方的有关信息提供了方便。SDES 包由包头与数据块组成,数据块可以没有,也可有多个。包头由版本(V)、填充(P)、长度指示、包类型(PT)和源计数(SC)组成。PT占8位,用于识别RTCP的SDES包,SC占5位,指示包含在SDES包中的SSRC/CSRC块数量,零值有效,但没有意义。SDES的组织结构是按照KLV的格式组织的,key表示具体的类型,length为长度,value为具体的值, key占用1个字节, length占用1个字节!value数据块由源描述项组成,源描述项的内容如下:

    a) CNAME: 规范终端标识SDES项

            类似SSRC标识,RTCP为RTP连接中每一个参加者赋予唯一一个CNAME标识。在发生冲突或重启程序时,由于随机分配的SSRC标识可能发生变化,CNAME项可以提供从SSRC标识到仍为常量的源标识的绑定。

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

    b) NAME:用户名称SDES项

            这是用于描述源的真正的名称,如"John Doe, Bit Recycler, Megacorp",可以是用户想要的任意形式。由于采用文本信息来描述,对诸如会议应用,可以对参加者直接列表显示,NAME项是除CNAME项以外发送最频繁的项目。NAME值在一次RTP会话期间应该保持为常数,但它不该成为连接的所有参加者中唯一依赖。

    c) EMAIL:电子邮件地址SDES项

            邮件地址格式由RFC822规定,如"John.Doe@megacorp.com"。一次RTP会话期间,EMAIL项的内容希望保持不变。

    d) PHONE:电话号码SDES项

            电话号码应带有加号,代替国际接入代码,如"+1 908 555 1212"即为美国电话号码。 

    e) LOC:用户地理位置SDES项

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

    f) TOOL:应用或工具名称SDES项

            TOOL项包含一个字符串,表示产生流的应用的名称与版本,如"videotool 1.2"。这部分信息对调试很有用,类似于邮件或邮件系统版本SMTP头。TOOL值在一次RTP会话期间保持不变。

    g) NOTE: 通知/状态SDES项

            NOTE 项旨在描述源当前状态的过渡信息,如"on the phone, can't talk",或在讲座期间用于传送谈话的题目,它的语法可在设置中显式定义。NOTE项一般只用于携带例外信息,而不应包含在全部参加者中,因为这将降低接收报告和CNAME发送的速度,损害协议的性能。一般NOTE 项不作为用户设置文件的项目,也不会自动产生。

            由于NOTE项对显示很重要,当会话的参加者处于活动状态时,其它非CNAME项(如NAME)传输速率将会降低,结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃,NOTE项继续以同样的速度重复发送几次,并以一个串长为零的字符串通知接收者。

    h) PRIV: 专用扩展SDES项

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

            注意,前缀应尽可能的短。SDES的PRIV项前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性, IANA应给它分配一个正式的SDES项类型,这样就不再需要前缀,从而简化应用,并提高传输的效率。

    4、BYE

            断开RTCP包,是站点离开系统的报告,表示结束;

            如混合器接收到一个BYE包,混合器转发BYE包,而不改变SSRC/CSRC 标识。如混合器关闭,在关闭之前它应该发出一个BYE包,列出混合器处理的所有源,而不只是自己的SSRC标识。作为可选项,BYE包可包括一个8位八进制计数,后跟文本信息,表示离开原因,如:"cameramalfunction"或"RTPloop detected"。字符串的编码与在SDES 项中所描述的相同。如字符串信息至BYE包下32位边界结束处,字符串就不以空结尾;否则,BYE包以空八进制填充。

    5、APP

    应用特定函数。

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

    2.3.2 RTCP组合包规则

    不同类型的RTCP信息包可堆叠,不需要插入任何分隔符就可以将多个RTCP包连接起来形成一个RTCP组合包,然后由低层协议用单一包发送出去。由于需要低层协议提供整体长度来决定组合包的结尾,在组合包中没有单个RTCP包的显式计数。

    组合包中每个RTCP包可独立处理,而不需要按照包组合的先后顺序处理。在组合包中有以下几条强制约束:

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

    2、每个组合包中都应该包含SDES CNAME,因为新接收者需要通过接收CNAME来识别源,并与媒体联系进行同步。

    3、组合包前面是包类型数量,其增长应该受到限制。

    4、所有RTCP包至少必须以两个包组合形式发送,推荐格式如下:

            a. 加密前缀(Encryption prefix):

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

            b. SR或RR:

            组合包中第一个RTCP包必须是一个报告包,以帮助分组头的确认。即使没有数据发送,也没有接收到数据,也要发送一个空RR,那怕组合包中RTCP包为BYE。

            c. 附加RR:

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

            d. SDES:

            包含CNAME 项的SDES包必须包含在每个组合RTCP包中。SDES包可能包括其他源描述项,这要根据特别的应用需要,并同时考虑带宽限制。

            e. BYE或APP:

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

    注意:混合器从多个源组合单个RTCP包,如组合包整体长度超过网络路径最大传输单元,可分成多个较短组合包用低层协议以单个包形式发送。注意,每个组合包必须以SR或RR包开始。附加RTCP包类型可在Internet Assigned NumbersAuthority (IANA)处注册,以获得合法的类型号。
     

    原文参考1链接:https://blog.csdn.net/chen495810242/article/details/39207305

    原文参考2链接:https://blog.csdn.net/special00/article/details/82533768

    原文参考3链接:https://blog.csdn.net/davidsguo008/article/details/73658422

    原文参考4链接:https://blog.csdn.net/bytxl/article/details/50400987

    原文参考5链接:https://blog.csdn.net/lipku/article/details/50183405

    展开全文
  • RTCP-XR 收集器 使用 RTCP-XR 的语音质量报告收集器。
  • RTP和RTCP

    2020-07-29 16:28:24
    一、RTP 1、RTP简介 实时传输协议(Real-time Transport Protocol或简写RTP)是一个网络传输协议,它...RTP协议和RTP控制协议(RTCP)一起使用,而且它是创建在UDP协议上的。 2、特征 RTP 本身并没有提供按时...

    一、RTP

    1、RTP简介

           实时传输协议(Real-time Transport Protocol或简写RTP)是一个网络传输协议,它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。RTP协议常用于流媒体系统(配合RTSP协议),视频会议和一键通(Push to Talk)系统(配合H.323或SIP),使它成为IP电话产业的技术基础。RTP协议和RTP控制协议(RTCP)一起使用,而且它是创建在UDP协议上的。

    2、特征

           RTP 本身并没有提供按时发送机制或其它服务质量(QoS)保证,它依赖于底层服务去实现这一过程。RTP 并不保证传送或防止无序传送,也不确定底层网络的可靠性。 RTP 为了实行有序传送, RTP 中的序列号允许接收方重组发送方的包序列,同时序列号也能用于决定适当的包位置,例如:在视频解码中,就不需要顺序解码。

    3、组成

           RTP标准定义了两个子协议,RTP和RTCP。

    (1)数据传输协议RTP:

           用于实时传输数据。该协议提供的信息包括:时间戳(用于同步)、序列号(用于丢包和重排序检测)、以及负载格式(用于说明数据的编码格式)。

    (2)控制协议RTCP:

           用于QoS反馈和同步媒体流。相对于RTP来说,RTCP所占的带宽非常小,通常只有5%。

           RTP 使用偶数端口号接收发送数据,相应的RTCP则使用相邻的下一位奇数端口号。RTP和RTCP使用UDP端口1024 - 65535。

    4、RTP的协议层次

           RTP(实时传输协议),顾名思义它是用来提供实时传输的,因而可以看成是传输层的一个子层。下图给出了流媒体应用中的一个典型的协议体系结构。

           从图中可以看出,RTP被划分在传输层,它建立在UDP上。同UDP协议一样,为了实现其实时传输功能,RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步,但并不保证服务质量。服务质量由RTCP来提供。

           RTP实现者在发送RTP数据时,需先将数据封装成RTP包,而在接收到RTP数据包,需要将数据从RTP包中提取出来。

           RTP协议的目的是提供实时数据(如交互式的音频和视频)的端到端传输服务,因此在RTP中没有连接的概念,它可以建立在底层的面向连接(TCP)或面向非连接(UDP)的传输协议之上;RTP也不依赖于特别的网络地址格式,而仅仅只需要底层传输协议支持组帧(Framing)和分段(Segmentation)就足够了;

    5、RTP的封装

           RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输,每一个RTP数据报都由头部(Header)和负载(Payload)两个部分组成,其中头部前12个字节的含义是固定的,而负载则可以是音频或者视频数据。

    下面是 RFC 3550 中规定的 RTP 头的结构:

           0             1             2               3               4

           0 1 2 3 4 5 6 7 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |V=2|P|X|  CC   |M|     PT    |       sequence number         |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |                           timestamp                         |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |           synchronization source (SSRC) identifier          |

          +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

          |            contributing source (CSRC) identifiers           |

          |                             ....                            |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    • 负载类型 Payload type (PT): 7 bits
    • 序列号 Sequence number (SN): 16 bits
    • 时间戳 Timestamp: 32 bits

    • 版本号(V):RTP协议的版本号,占2位,当前协议版本号为2
    • 填充位(P):填充标志,占1位,如果P=1,则在该报文的尾部填充一个或多个额外的八位组,它们不是有效载荷的一部分。
    • 扩展位(X):扩展标志,占1位,如果X=1,则在RTP报头后跟有一个扩展报头
    • CSRC计数器(CC):CSRC计数器,占4位,指示CSRC 标识符的个数(作用信源CSRC计数器)
    • 标志位(M): 标记,占1位,不同的有效载荷有不同的含义,对于视频,标记一帧的结束;对于音频,标记会话的开始。(对于分组中的重要事件可用该位标识)
    • 载荷类型(PT): 有效荷载类型,占7位,用于说明RTP报文中有效载荷的类型,如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的,这样便于客户端进行解析。
    • 序列号(SN):占16位,用于标识发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。这个字段当下层的承载协议用UDP的时候,网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序,序列号的初始值是随机的,同时音频包和视频包的sequence是分别记数的。
    • 时戳(Timestamp)占32位,必须使用90 kHz 时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。
    • 同步信源(SSRC)标识符:占32位,用于标识同步信源。该标识符是随机选择的,参加同一视频会议的两个同步信源不能有相同的SSRC。同步信源是指产生媒体流的信源,例如麦克风、摄像机、RTP混合器等;它通过RTP报头中的一个32位数字SSRC标识符来标识,而不依赖于网络地址,接收者将根据SSRC标识符来区分不同的信源,进行RTP报文的分组。
    • 特约信源(CSRC)标识符:每个CSRC标识符占32位,可以有0~15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。特约信源是指当混合器接收到一个或多个同步信源的RTP报文后,经过混合处理产生一个新的组合RTP报文,并把混合器作为组合RTP报文的 SSRC,而将原来所有的SSRC都作为CSRC传送给接收者,使接收者知道组成组合报文的各个SSRC。

    RTP扩展头:

           很多时候,在传输H264数据的时候,也需要传输其他的协议数据信息,这个时候,就可以放在RTP的扩展头部分传输。根据上面RTP协议格式,第一个字节的bit2(X),这个字段如果是1的话,就表示当前RTP协议带着扩展头。

           这个扩展头就跟在RTP确定的头部后面。如果有CSRC,就跟在CSRC后面,CSRC的个数,可以看第一个字节的bit4~bit7(CC),每一个CSRC 4个字节。这样就可以确定扩展头的位置了。

    扩展头的内部格式:

           0             1             2               3               4

           0 1 2 3 4 5 6 7 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |       defined by profile    |            length             |

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          |                           header extension                  |

                                      ......  ......

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    • defined by profile :按照私有的协议文档自己定义就行了,相当于一个标识。
    • length:扩展头长度,更确切地说,是扩展头个数,比如length == 2,标识有两个,每个扩展头4字节,则共 2 * 4 = 8字节。即扩展头内容长度为 4 * length(字节)。

    6、RTP的会话过程

           当应用程序建立一个RTP会话时,应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成,有两个端口:一个给RTP包,一个给RTCP包,使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口,而对应的控制信号RTCP数据发向相邻的奇数UDP端口(偶数的UDP端口+1),这样就构成一个UDP端口对。 RTP的发送过程如下,接收过程则相反。

    (1)RTP协议从上层接收流媒体信息码流(如H.263),封装成RTP数据包;RTCP从上层接收控制信息,封装成RTCP控制包。

    (2) RTP将RTP 数据包发往UDP端口对中偶数端口;RTCP将RTCP控制包发往UDP端口对中的接收端口。

    7、h264的rtp打包

    (1)单NALU:   P帧或者B帧比较小的包,直接将NALU打包成RTP包进行传输    RTP header(12bytes) + NALU header (1byte) + NALU payload

    (2)多NALU:   特别小的包几个NALU放在一个RTP包中 

    (3)FUs(Fragment Units):   I帧长度超过MTU的,就必须要拆包组成RTP包了,有FU-A,FU-B

    问答:

    (a)NALU头不见了,如何判断类型?实际上NALU头被分散填充到FU indicator和FU header里面了。bit位按照从左到右编号0-7来算,nalu头中0-2前三个bit放在FU indicator的0-2前三个bit中,后3-7五个bit放入FU header的后3-7五个中     

    //NALU header = (FU indicator & 0xe0) | (FU header & 0x1F)   取FU indicator前三和FU header后五 

    headerStart[1] = (headerStart[0]&0xE0)|(headerStart[1]&0x1F); 

    (b)多个RTP包如何还原组合成回一个完整的I帧? 在FU header中有标记为判断。

    照旧从左到右,Fu header前两个bit表示start和end标记,start为1表示一个i帧分片开始,end为1表示一个i帧分片结束

    (c)如何查看是一个I帧分片开始?  

    看第一个字节FU Indicator,照旧从左到右,Fu Indicator前三个bit是NALU头的前三个bit,后五位为类型FU-A:28(11100),FU-B:29(11101)。

    RTP抓包看下来整个字节是0x7c开头。

    如果不是分片,第一字节就是NALU头,如:0x67,0x68,0x41等

     

     

    二、RTCP

    1、RTCP功能

           服务质量的监视与反馈、媒体间的同步,以及多播组中成员的标识。在RTP会话期间,各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料,因此,各参与者可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTP和RTCP配合使用,它们能以有效的反馈和最小的开销使传输效率最佳化,因而特别适合传送网上的实时数据。

    2、RTCP分组类型

           RTCP也是用UDP来传送的,但RTCP封装的仅仅是一些控制信息,因而分组很短,所以可以将多个RTCP分组封装在一个UDP包中。RTCP有如下五种分组类型。

    类型

    缩写表示

    用途

    200

    SRSender Report

    发送端报告

    201

    RRReceiver Report

    接收端报告

    202

    SDESSource Description Items

    源点描述

    203

    BYE

    结束传输

    204

    APP

    特定应用

    • SR:发送端报告,所谓发送端是指发出RTP数据报的应用程序或者终端,发送端同时也可以是接收端。
    • RR:接收端报告,所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
    • SDES:源描述,主要功能是作为会话成员有关标识信息的载体,如用户名、邮件地址、电话号码等,此外还具有向会话成员传达会话控制信息的功能。
    • BYE:通知离开,主要功能是指示某一个或者几个源不再有效,即通知会话中的其他成员自己将退出会话。
    • APP:由应用程序自己定义,解决了RTCP的扩展性问题,并且为协议的实现者提供了很大的灵活性。

           所有RTCP包至少必须以两个包组合形式发送,推荐格式如下:

    • 加密前缀(Encryption prefix):

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

    • SR或RR

           组合包中第一个RTCP包必须是一个报告包,以帮助分组头的确认。即使没有数据发送,也没有接收到数据,也要发送一个空RR,那怕组合包中RTCP包为BYE。

    • 附加RR

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

    • SDES

            包含CNAME 项的SDES包必须包含在每个组合RTCP包中。SDES包可能包括其他源描述项,这要根据特别的应用需要,并同时考虑带宽限制。

    • BYE或APP

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

           混合器从多个源组合单个RTCP包,如组合包整体长度超过网络路径最大传输单元,可分成多个较短组合包用低层协议以单个包形式发送。注意,每个组合包必须以SR或RR包开始。附加RTCP包类型可在Internet Assigned NumbersAuthority (IANA)处注册,以获得合法的类型号。

    2、SR类型

           上述五种分组的封装大同小异,下面只讲述SR类型,而其它类型请参考RFC3550。

    • 版本(V):同RTP包头域。
    • 填充(P):同RTP包头域。
    • 接收报告计数器(RC):5比特,该SR包中的接收报告块的数目,可以为零。
    • 包类型(PT):8比特,SR包是200。
    • 长度域(Length):16比特,其中存放的是该SR包以32比特为单位的总长度减一。
    • 同步源(SSRC):SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。
    • NTP Timestamp(Network time protocol):SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。
    • RTP Timestamp与NTP时间戳对应,与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。
    • Sender’s packet count从开始发送包到产生这个SR包这段时间里,发送者发送的RTP数据包的总数. SSRC改变时,这个域清零。
    • Sender`s octet count从开始发送包到产生这个SR包这段时间里,发送者发送的净荷数据的总字节数(不包括头部和填充)。发送者改变其SSRC时,这个域要清零。
    • 同步源n的SSRC标识符:该报告块中包含的是从该源接收到的包的统计信息。
    • 丢失率(Fraction Lost):表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率。
    • 累计的包丢失数目:从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数。
    • 收到的扩展最大序列号:从SSRC_n收到的RTP数据包中最大的序列号,
    • 接收抖动(Interarrival jitter):RTP数据包接受时间的统计方差估计
    • 上次SR时间戳(Last SR,LSR):取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包,则该域清零。
    • 上次SR以来的延时(Delay since last SR,DLSR):上次从SSRC_n收到SR包到发送本报告的延时。

    3、RTCP组合包的约束

           不同类型的RTCP信息包可堆叠,不需要插入任何分隔符就可以将多个RTCP包连接起来形成一个RTCP组合包,然后由低层协议用单一包发送出去。由于需要低层协议提供整体长度来决定组合包的结尾,在组合包中没有单个RTCP包的显式计数。

    组合包中每个RTCP包可独立处理,而不需要按照包组合的先后顺序处理。在组合包中有以下几条强制约束:

    • 只要带宽允许,在SR包或RR包中的接收统计应该经常发送,因此每个周期发送的组合RTCP 包中应包含报告包。
    • 每个组合包中都应该包含SDES CNAME,因为新接收者需要通过接收CNAME来识别源,并与媒体联系进行同步。
    • 组合包前面是包类型数量,其增长应该受到限制。

    4、相关协议

    (1)实时流协议RTSP

           实时流协议RTSP(Real-Time Streaming Protocol)是IETF提出的协议,对应的RFC文档为RFC2362。

    从上图可以看出,RTSP是一个应用层协议(TCP/IP网络体系中)。它以C/S模式工作,它是一个多媒体播放控制协议,主要用来使用户在播放流媒体时可以像操作本地的影碟机一样进行控制,即可以对流媒体进行暂停/继续、后退和前进等控制。

    (2)资源预定协议RSVP

           资源预定协议RSVP(Resource Reservation Protocol)是IETF提出的协议,对应的RFC文档为RFC2208。

    从上可以看出,RSVP工作在网络层是一个网络控制协议。RSVP通过在路由器上预留一定的带宽,能在一定程度上为流媒体的传输提供服务质量。在某些试验性的系统如网络视频会议工具vic中就集成了RSVP。

     

    展开全文
  • RTSP/RTP/RTCP之间的区别

    2018-05-17 16:41:48
    RTSP/RTP/RTCP的概念以及区别。摘抄别人的,自我感觉该资料讲的比较通俗易懂
  • 只传有用的,鄙视上传垃圾。...live555 RTSP RTCP RTP。包括live555类关系结构图,客户端/服务器传输流程,RTSP学习笔记,及RFC中文规范,H264流传输等。 还有项目之后的代码在我的上传空间中,支持移植
  • 文档详细解释了RTP和RTCP协议的内容和实现算法,对开发类似流媒体服务有一定的参考性。
  • RTP和RTCP协议

    2021-07-18 08:05:29
    tn=T(这意味着,一个计时器将经T时间后被唤醒) Receiving an RTP or Non-BYE RTCP Packet 更新如下的变量: avg rtcp size = (1/16) * packet size + (15/16) * avg rtcp size Receiving an RTCP BYE Packet • ...
  • 1. RTP/RTCP协议 协议详解可见文档: https://download.csdn.net/download/fireroll/15308144 2. 抓包与代码分析 2.1 RTP报文 RTP报文头格式(见RFC3550 Page12): PT(Payload Type 负载类型)的值...
  • rtp rtcp协议实现

    2018-03-30 11:09:38
    RTCP协议实现c语言RTCP协议实现c语言RTCP协议实现c语言RTCP协议实现c语言
  • WebRTC RTCP 分析

    2020-08-15 10:59:27
    RTP 已经定义的几种 Profile (AVP/SAVP/AVPF/SAVPF) 中最复杂的 SAVPF,这些机制里面最复杂的部分要数 Feedback,而 RTCP 是整个 Feedback 机制实现的重要组成部分(还有一部分可以通过 RTP Header Extention 实现)...
  • RTP/RTCP协议

    2021-01-21 20:27:34
    目的传输地址由一个网络地址和一对端口组成,有两个端口:一个给RTP包,一个给RTCP包,使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口,而对应的控制信号RTCP数据发向相邻的奇数UDP端口(偶数的UDP端口+1...
  • RTCP发送时间间隔分析 一设计RTCP的原因 2 二RTCP发送需要考虑的问题 2 三对问题进行进一步的细化 3 四问题的解决 4 五算法验证 8 六总结 8 七参考 9 一 设计RTCP的原因 使用网络传输数据没有什么问题,...
  • RTCP协议规范中定义了五种类型的RTCP包:接收⽅报告(RR)、发送⽅报告(SR)、源 描述(SDES)、成员管理(BYE)和应⽤程序定义(APP)。 SR: payload type=201 RR:payload type=202 SEDS:payload type=203 ...
  • RTP_RTCP基础

    2017-04-25 15:39:29
    RTP_RTCP基础
  • RTP 控制协议 RTCP,就是用于监控服务质量和传达关于在一个正在进行的会议中的参与者的信息,包括对抗卡顿、网络拥塞控制扩展功能的实现,均利用RTCP报文实现,有名的是Google的GCC(拥塞控制算法(Google Congestion...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 14,333
精华内容 5,733
关键字:

rtcp