【精品】RTC协议和RTCP协议4

1、rtp (real-timetransportprotocol)是用于internet上针对多媒体数据流的一种传输协议。rtp 被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步°rtp 通常使用udp來传送数据，但rtp也可以在tcp或atm等其他i办议之上工作。当应用程 序开始一个rtp会话时将使川两个端口：一个给rtp, 一个给rtcpo rtp本身并不能为按顺 序传送数据包提供可靠的传送机制，也不提供流竝控制或拥塞控制，它依靠rtcp提供这些 服务。通常rtp算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。 实时传输控制协议rtcpo

2、 rtcp(real-timetransportcontrolprotocol)和rtp -起提供流量控制 和拥塞控制服务。在rtp会话期间，各参与者周期性地传送rtcp包。rtcp包中含有已发 送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利川这些信息动态 地改变传输速率，共至改变有效载荷类型。rtp和rtcp配合使用，它们能以有效的反馈和 最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。6.2.1 rtp数据传输协议rtp提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数 据。rtp没有涉及资源预订和质量保证等实吋服务，rtcp扩充数

3、据传输以允许监控数据传 送，提供最小的控制和识別功能。rtp -u rtcp设计成独立传输和网络层。2.1.1 rtp固定头rtp头格式如下： |v=2|p|x| cc |m| pt | 系列号 |i同步源标识(ssrc) |i作用标识(csrc) |开始12个八进制出现在每个rtp包中，而csrc标识列表仅出现在混合器插入吋。2.1.2复用rtp连接为使协议有效运行，复用点数目应减至最小。rtp屮，复川由定义rtp连接的目的传输地址 (网络地址与端口号)提供。例如，对音频和视频单独编码的远程会 议，每个媒介被携带 在单独rtp连接中，具有各自的目的传输地址。目标不在将音频和视频放在单一 rt

4、p连接 中，而根据ssrc段载荷类型进行多路分解。使用同一 ssrc，而具有不同载荷类型的交叉 包将带来几个问题：如一种载荷类型在连接期间切换，没有办法识别新值将替换那一个旧值。ssrc定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空 间以说明那种载荷类型有丢包，交义复用载荷类型将需要不同计吋空间。rtcp发送和接收报告可能仅描述每个ssrc的计时和系列号空i'可，而不携带载荷类型段。 rtp混合器不能将不兼容媒体流合并成一个流。在一个rtp连接屮携带多个媒介阻止儿件事：使川不同网络路径或网络资源分配；接受媒介 子集。对每种媒介使用不同ssrc,但以相同rtp

5、连接发送可避免前三个问题，但不能避免后两个 问题。2.1.3对rtp头特定设置的修改可以认为，现用rtp数据包头对rtp支持的所冇应用类共同需要的功能集是完整的。然而, 为维持alf设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工 具起作用。标记位与载荷类型段携带特定设置信息，但山于很多应用需要它们，否则要容纳 它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制nj通过设置重 新定义以适m不同要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观 察包丢失模式和标记位间关系，我们就可以定位八进制中最重要的位。其它特殊载荷格式(视频编码)所要求的信

6、息应该携带在包的载荷部分。可出现在头，总是 在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附 加功能，应用运行的设置应该定义附加固定段跟随在现存固定头ssrcz后。这些应川将能 迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进 制处理rtp包。如证实附加功能是所有设置共同需要的，新版木rtp应该对|古|定头作岀明 确改变6.2.2 rtp 控制协议- rtcprtcp协议将控制包周期发送给所冇连接者，应川与数据包相同的分布机制。低层协议捉供 数据与控制包的复用，如使用单独的udp端口号。rtcp执行下列四大功能：主要是提供数据发布的

7、质量反馈。是作为rtp传输协议的一部分，与其他传输协议的流和阻 塞控制有关。反馈对h适应编码控制直接起作用，但ip组播经验表明，从发送者收到反馈 对诊断发送错谋是致关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问 题是局部的，还是全局的。诸如ip组播等发布机制使网络服务提供商类团体可能接收反馈 信息，充当第三方监控者来诊断网络问题。反馈功能由rtcp发送者和接收者报告执行。rtcp带有称作规范名字(cname)的rtp源持久传输层标识。如发现冲突，或程序重新启 动，既然ssrc标识可改变，接收者需要cname跟踪参加者。接收者也需要cname与相关 rtp连接中给定的几个数据流联

8、系前两种功能要求所有参加者发送rtcp包，因此，为了 rtp扩展到人规模数量，速率必须受 到控制。让每个参加者给其它参加者发送控制包，就人独立观察参加者数量。该数最用语计 算包发送的速率。笫四个可选功能是传送最小连接控制信息，如参加者辨识。最可能用在”松散控制连接， 那里参加者自山进入或离开，没有成员控制或参数协调，rtcp充当通往所有参加者的方便 通道，但不必支持应用的所有控制通讯要求。高级连接控制协议超出本书范围。在ip纟r播场合应用rtp时，前3个功能是必须的，推荐用于所有情形。rtp应用设计人员 必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。 rtcp 包格

9、式卜-面定义儿个携带不同控制信息的rtcp包类型：sr：发送报告，当前活动发送者发送、接收统计。rr：接收报告，非活动发送者接收统计。sdes：源描述项，包括cnameobye：表示结束。app：应用特定函数。类似于rtp数据包，每个rtcp包以固定部分开始，紧接着的是可变长结构元索，但以一个 32位边界结束。包含安排要求和固定部分中长度段，使rtcp包可堆叠。不需要插入任何 分隔符将多哥rtcp包连接起來形成一个rtcp组合包，以低层协议用单一包发送出去。由 于需要低层协议捉供捉供整体长度來决定组合包的结尾,在组合包中没有单个rtcp包显式 计数。组合包中每个rtcp包可独立处理，不需要根据

10、包组合顺序。但未了执行协议功能，强加如 下约束：接收统计(在sr或rr中)应该经常发送，只要带宽允许，因此每个周期发送的组合rtcp包 应包含报告包。新接收者需要接收cname,并尽快识别源，开始联系媒介进行同步，因此每个包应该包含sdes cnameo出现在组合包前面的是包类型数量，其增长应该受到限制，以提高常数位数量，提高成功确 认rtcp包对错谋地址rtp数据包或其他无关包的概率。因此，所冇rtcp包至少必须以两个包组合形式发送，推荐格式如下：加密前缀(encryption prefix)：仅当组合包被加密，才加上一个32位随机数用于每个组合包发送。sr 或 rr：组合包屮第一个rtcp

11、包必须总为一个报告包，方便头的确认。即使没有数据发送，也没有 接收到数据，也要发送一个空rr,那怕组合包中rtcp包为bye。附加rr：如报告统计源数目超过31,在初始报告包后应该有附加rr包。sdes：包含cname项的sdes包必须包含在每个组合rtcp包屮。如应用要求，其他源描述项町选, 但受到带宽限制。bye 或 app：其它rtcp包类型可以任意顺序排列，除了 bye应作为最后一个包发送，包类型出现可不止 一次。建议转换器或混合器从多个源组合单个rtcp包。如组合包整体长度超过网络路径最人传输 单元，可分成多个较短纟r合包用低层协议以单个包形式发送。注意，每个组合包必须以sr 或 r

12、r 包开始。附加 rtcp 包类型 口j 在 internet assigned numbers authority (iana)处注册。 rtcp传输间隔rtp设计成允许应用白动扩展，连接数可从儿个到上千个。例如，音频会议屮，数据流量是 内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立 于连接数，但控制流屋不是内在限制的。如每个参加者以固定速率发送接收报告，控制流虽 将随参加者数量线性增长，因此，速率必须按比例下 降。一旦确认地址有效，如后來标记成未活动，地址的状态应仍保留，地址应继续计入共享rtcp 带宽地址的总数中，时间要保证能扫描典型网络分区

13、，建议为30分钟。注意，这仍大于rtcp 报告间隔最大值的五倍。这个规范定义了除必需的cname外的几个源描述项，如name （人名）和email （电子邮 件地址）。它也为定义新特定应用rtcp包类型的途径。给附加信息分配控制带宽应引起注 意，因为它将降低接收报告和cname发送的速率而损害协议的性能。建议分配给单个参加 者用于携带附加信息的rtcp带宽不要超过20%。而且外没有有意让所有sdes项包含在每 个应用中。6.2.23发送者与接收者报告rtp接收者使用rtcp报告包提供接收质量反馈，报告包根据接收者是否是发送者而采用两 种格式中的一种。除包类型代码外，发送者报告与接收者报告间唯一

14、的差别是发送者报告 包含一个20个字节发送者信息段。如某地址在发岀最示或前一个报告间隔期间发送数据包, 就发布sr；否则，就发出rr； sr和rr都可没有或包括多个接收报告块。发布报告不是为 列在csrc列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大 可有31个接收报告块嵌入在sr或rr包中，丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间 隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。如两报告连续，比值 应该等于丢失段部分；否则，就不等。每秒包丢失绿可通过ntp吋标差除以丢失部分得到。 从发送者信息，第三方监控器可计算载

15、荷平均数据速率与没收到数据间隔的平均包速率，两 者比值给出平均载荷人小。如假设包丢失与包人小无关，那么特殊接收者收到的包数量给出 此接收者收到的表观流量。 sdes:源描述 rtcp 包sdes包为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所 表明的源。项描述如下：版本（v）、填充（p）、长度：如sr包中所描述。包类型（pt）：8位，包含常数202,识别rtcp sdes包。源计数（sc）：5位,包含在sdes包中的ssrc/csrc块数量，零值有效,但没有意义。源描述项内容如下：cname:规范终端标识sdes项cname标识属性如下：如发生冲突或重启

16、程序，由于随机分配的ssrc标识可能发生变化，需要cname项提供从 ssrc标识到仍为常量的源标识的绑定。象ssrc标识，cname标识在rtp连接的所有参加者中应是唯一的。为了提供一套相关rtp连接中某个参加者所采用的跨多媒体工具间的绑定，cname应固定 为那个参加者。为方便第三方监控，cname应适合程序或人员定位源。name：用户名称sdes项这是用于描述源的真正的名称，如”john doe, bit recycler, megacorpv，可是用户想要的任意 形式。对诸如会议应用，这种名称也许是参加者列表显示最适宜的形式，它将是除cname 外发送最频繁的项目。设置可建立这样的优先

17、级别。name值至少在连接期间仍希望保持 为常数。它不该成为连接的所有参加者中唯一依赖。email：电了邮件地址sdes项邮件地址格式由rfc822规定，如"john.doe"o连接期间，电了邮件仍希望 保持为常数。phone：电话号码sdes项电话号码应带有加号，代替国际接入代码，如”+1 908 555 1212、”即为美国电话号码。loc：用户地理位置sdes项根据应用，此项具有不同程度的细节。对会议应用，字符帝如'“murray hill, new jersey、”就 足够了。然而,对活动标记系统,字符串如腺00口 2a244, at&t bl mh

18、“也许就适用。细节 留给实施或用户，但格式和内容町川设置指示。在连接期间，除移动主机外，loc值期望仍 保留为常数。tool：应用或工具名称sdes项是一个字符串，表示产生流的应用的名称版本，m"videotool 1.2"0这部分信息对调试很 有用，类似于邮件或邮件系统版本smtp头。tool值在连接期间仍保持常数。note:通知/状态sdes项该项的推荐语法如下所述，但这些或其它语法可在设置屮显式定义。note项旨在描述源当 前状态的过渡信息,如”on the phone, can't talk、”，或在讲座期间用于传送谈话的题目。它 应该只用于携帯例外信息，而

19、不应包含在全部参加者中，因为这将降低接收报告和cname 发送的速度，因此损害协议的性能。特殊情况下，它不应作为用户设置文件的项目，也不 是自动产生。当其为活动时，由于note项对显示很重要，其它非cname项（如name）传输速率将会 降低，结果使note项占用rtcp部分带宽。若过渡信息不活跃，note项继续以同样的速 度重复发送几次，但以一个串长为零的字符串通知接收者。然而，如对小倍数的重复或约 20-30 rtcp间隔也没有接收到，接收者也应该考虑note项是不活跃的。priv:专用扩展sdes项该项用于定义实验或m用特定的sdes扩展，它包括由长字符串对组成的前缀，示跟填充该 项其他

20、部分和携带所需信息的字符串值。前缀长度段为8位。前缀字符串是定义priv项人 员选择的名称，唯-对应应用接收到的其它priv项。应用实现者可选择便用应用名称，如 有必要，外加附加子类型标识。另外，推荐其它人根据其代表的实体选择名称，然后，在 实体内部协调名称的使用。注意，前缀消耗了总长为255个八进制项的一些空间，因此，前缀应尽可能的短。这个设备 和受到约束的rtcp带宽不应过载，其目的不在于满足所有应用的全部控制通讯要求。sdes priv前缀没在iana处注册。如证实某些形式的priv项具有通用性，iana应给它分配一个 正式的sdes项类型，这样就不再需要前缀。这简化了应用，并提高了传输

21、的效率。 bye：断开 rtcp 包如混合器接收到一个bye包，混合器转发bye包，而不改变ssrc/csrc标识。如混合器关 闭，它也应该发出一个bye包，列出它所处理的所有源，而不只是自己的ssrc标识。作为 可选项，bye包町包括一个8位八进制计数，后 跟很多八进制文本，表示离开原因，如： v'camera malfunction"或”盯卩loop detected、"。字符串具有同样的编码,如在sdes中所描 述的。如字符串填充包至卜 32位边界，字符串就不以空结尾；否则，bye包以空八进制填 充。 app：定义应用的rtcp包a

22、pp包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识別名称的app 包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个app包，而不用向iana注册 了类型和名称段。实时流协议rtsp 实时流协议 rtsp（realtimestreamingprotocol）是ill realnetworks 和 netscape 共同提出的,该 协议定义了一对多应川程序如何有效地通过ip网络传送多媒体数据。rtsp在体系结构上位 于rtp和rtcp之上，它使用tcp或rtp完成数据传输。http与rtsp相比,http传送html, 而rtp传送的是多媒体数据。http请求由客户机发出，服

23、务器作出响应；使用rtsp时，客 户机和服务器都町以发出请求，即rtsp可以是双向的。6.3 rtsp 协议实吋流协议（rtsp）是应用级协议，控制实时数据的发送。rtsp提供了一个可扩展框架， 使实吋数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑 中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如udp、组播udp与 tcp,提供途径，并为选择基于rtp上发送机制提供方法。&3.1简介 目的实时流协议（rtsp）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制 流交叉是可能的，通常它本身并不发送连续流。换言之，rtsp

24、充当多媒体服务器的网络远 程控制。rtsp连接没冇绑定到传输层连接，如tcp。在rtsp连接期间，rtsp川户可打开或 关闭多个对服务器的可靠传输连接以发出rtsp请求。此外，可使用无连接传输协议，如 udpo rtsp流控制的流可能用到rtp,但rtsp操作并不依赖用于携带连续媒体的传输机制。 实时流协议在语法和操作-上与http/1.1类似，因此http的扩展机制大都可加入rtsp。协 议支持的操作如下： 从媒休服务器上检索媒休：用户可通过http或其它方法提交一个演示描述。如演示是纽播，演示式就包含用于连续媒 体的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供忖的地址。

25、 媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模 式在分布式教育应用上很有用，会议中几方口j轮流按远程控制按钮。将媒体加到现成讲朋屮：如服务器告诉用八可获得附加媒体内容，对现场讲座显得尤其有用。如http/"中类似， rtsp请求町由代理、通道少缓存处理。协议特点rtsp特性如下：可扩展性：新方法和参数很容易加入rtspo易解析：rtsp 口jrfl标准http或mime解吸器解析。安全：rtsp使用网页安全机制。独立于传输：rtsp可使用不可靠数据报协议（udp）、可靠数据报协议（rdp）,如要实现应用级可靠，

26、可 使用可靠流协议。多服务器支持：每个流可放在不同服务器上，用户端白动同不同服务器建立几个并发控制连接，媒体同步在 传输层执行。记录设备控制：协议可控制记录和冋放设备。流控与会议开始分离：仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下，sip或h.323 可用來邀请服务器入会。适合专业应用:通过smpte时标，rtsp支持帧级精度，允许远程数字编辑演示描述中立：协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个rtsp url代理与防火墙友好：协议可由丿应用和传输层防火墙处理。防火墙需要理解setup方法，为udp媒体流打开一个 “缺口 丫'

27、;。http友好：此处，rtsp明智的采用http观念，使现在结构都可重用。结构包括internet内容选择平台 （pics）o由于在大多数情况下控制连续媒体碍要服务器状态，rtsp不仅仅向http添加方 法。适当的服务器控制：如用户启动一个流，他必须也可以停止一个流。传输协调；实际处理连续媒体流前，用八可协调传输方法。性能协调：如基木特征无效，必须有一些清理机制让用八决定那种方法没牛:效。这允许用八捉出适合的 用户界面。 扩展 rtsp山于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。rtsp可以 如下三种方式扩展，这里以改变大小排序：以新参数扩展。如用户需

28、要拒绝通知，而方法扩展不支持，相应标记就加入要求的段屮。 加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次 尝试这种方法。用户可使用options方法查询服务器支持的方法。服务器使用公共响应头 列出支持的方法。定义新版本协议，允许改变所有部分。（除了协议版本号位置）操作模式每个演示和媒体流可用rtsp url识別。演示组成的整个演示与媒体加性由演示描述文件定 义。使用http或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。为了说明，假设演示描述描述了多个演示，其小每个演示维持了一个公共时间轴。为简化说 明，且不失一般性，假定演不描述的

29、确包含这样一个演示。演示可包含多个媒体流。除媒体 参数外，网络目标地址和端口也需要决定。下面区分儿种操作模式：单播：以用八选择的端口号将媒体发送到rtsp请求源。组播，服务器选择地址：媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。组播，用户选择地址：如服务器加入正在进行的组播会议，组播地址、端口和密匙山会议描述给岀。 rtsp 状态rtsp控制通过单独协议发送的流，与控制通道无关。例如，rtsp控制可通过tcp连接，而 数据流通过udp。因此，即使媒体服务器没冇收到请求，数据也会继续发送。在连接生命 期，单个媒体流可通过不同tcp连接顺序发出请求来控制。所以，服务

30、器需耍维持能联系流 与rtsp请求的连接状态。rtsp中很多方法与状态无关，但下列方法在定义服务器流资源 的分配与应用上起着垂要的作用：setup：讣服务器给流分配资源，启动rtsp连接。play 与 record：启动setup分配流的数据传输。pause：临时停止流，而不解放服务器资源。teardown：释放流的资源，rtsp连接停止。标识状态的rtsp方法使用连接头段识别rtsp连接，为响应setup请求，服务器连接产生连接标识。与其他协议关系rtsp在功能上与http有重叠，与http相互作用体现在与流内容的初始接触是通过网页的。 目前的协议规范目的在于允许在网页服务器与

31、实现rtsp媒体服务器之间存在不同传递点。 例如，演示描述可通过http和rtsp检索，这降低了浏览器的往返传递，也允许独立rtsp服 务器与用户不全依靠http。但是，rtsp与http的本质差别在于数据发送以不同协议进行。http是不对称协议，用户 发出请求，服务器作出响应。rtsp中,媒体用户和服务器都可发出请求,且其请求都是无 状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用http功能至少在两 个方面有好处，即安全和代理。耍求非常接近，在缓存、代理和授权上釆川http功能是 有价值的。当大多数实时媒体使用rtp作为传输协议时，rtsp没冇绑定到rtp0 rtsp假设存在演示描 述格式可表示包含几个媒体流的演示的静态临吋属性。6.3.2协议参数6.3.3 rtsp 信息rtsp是基于文本的协议,采用iso 10646字符集,使用utf-8编码方案。行以crlf中断， 但接收者木身可将cr和lf解释成行终止符。