RTC协议和RTCP协议4.doc

RTC协议和RTCP协议4 RTP（Real-timeTransportProtocol）是用于Inter上针对多媒体数据流的一种传输协议。 RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。 RTP通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。 当应用程序开始一个RTP会话时将使用两个端口一个给RTP，一个给RTCP。 RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。 实时传输控制协议RTCP。 RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和拥塞控制服务。 在RTP会话期间，各参与者周期性地传送RTCP包。 RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。 RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。 6.2.1RTP数据传输协议RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。 RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。 RTP与RTCP设计成独立传输和网络层。 2.1.1RTP固定头RTP头格式如下-|V=2|P|X|CC|M|PT|系列号|-|时标|-|同步源标识(SSRC)|-|作用标识(CSRC)|.|-开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。 2.1.2复用RTP连接为使协议有效运行，复用点数目应减至最小。 RTP中，复用由定义RTP连接的目的传输地址（网络地址与端口号）提供。 例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。 目标不在将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。 使用同一SSRC，而具有不同载荷类型的交叉包将带来几个问题如一种载荷类型在连接期间切换，没有办法识别新值将替换那一个旧值。 SSRC定义成用于标识单个计时和系列号空间。 如媒体时钟速率不同，而要求不同系列号空间以说明那种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。 RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。 RTP混合器不能将不兼容媒体流合并成一个流。 在一个RTP连接中携带多个媒介阻止几件事使用不同网络路径或网络资源分配；接受媒介子集。 对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。 2.1.3对RTP头特定设置的修改可以认为，现用RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。 然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。 标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位字，故允许分配在固定头中。 包含这些段的八进制可通过设置重新定义以适应不同要求，如采用更多或更少标记位。 如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八进制中最重要的位。 其它特殊载荷格式（视频编码）所要求的信息应该携带在包的载荷部分。 可出现在头，总是在载荷部分开始处，或在数据模式的保留值中指出。 如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。 这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制处理RTP包。 如证实附加功能是所有设置共同需要的，新版本RTP应该对固定头作出明确改变6.2.2RTP控制协议-RTCP RTCP协议将控制包周期发送给所有连接者，应用与数据包相同的分布机制。 低层协议提供数据与控制包的复用，如使用单独的UDP端口号。 RTCP执行下列四大功能主要是提供数据发布的质量反馈。 是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。 反馈对自适应编码控制直接起作用，但IP组播经验表明，从发送者收到反馈对诊断发送错误是致关重要的。 给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。 诸如IP组播等发布机制使网络服务提供商类团体可能接收反馈信息，充当第三方监控者来诊断网络问题。 反馈功能由RTCP发送者和接收者报告执行。 RTCP带有称作规范名字（AME）的RTP源持久传输层标识。 如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要AME跟踪参加者。 接收者也需要AME与相关RTP连接中给定的几个数据流联系前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。 让每个参加者给其它参加者发送控制包，就大独立观察参加者数量。 该数量用语计算包发送的速率。 第四个可选功能是传送最小连接控制信息，如参加者辨识。 最可能用在松散控制连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。 高级连接控制协议超出本书范围。 在IP组播场合应用RTP时，前3个功能是必须的，推荐用于所有情形。 RTP应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。 6.2.2.1RTCP包格式下面定义几个携带不同控制信息的RTCP包类型SR发送报告，当前活动发送者发送、接收统计。 RR接收报告，非活动发送者接收统计。 SDES源描述项，包括AME。 BYE表示结束。 APP应用特定函数。 类似于RTP数据包，每个RTCP包以固定部分开始，紧接着的是可变长结构元素，但以一个32位边界结束。 包含安排要求和固定部分中长度段，使RTCP包可堆叠。 不需要插入任何分隔符将多哥RTCP包连接起来形成一个RTCP组合包，以低层协议用单一包发送出去。 由于需要低层协议提供提供整体长度来决定组合包的结尾，在组合包中没有单个RTCP包显式计数。 组合包中每个RTCP包可独立处理，不需要根据包组合顺序。 但未了执行协议功能，强加如下约束接收统计（在SR或RR中）应该经常发送，只要带宽允许，因此每个周期发送的组合RTCP包应包含报告包。 新接收者需要接收AME，并尽快识别源，开始联系媒介进行同步，因此每个包应该包含SDES AME。 出现在组合包前面的是包类型数量，其增长应该受到限制，以提高常数位数量，提高成功确认RTCP包对错误地址RTP数据包或其他无关包的概率。 因此，所有RTCP包至少必须以两个包组合形式发送，推荐格式如下加密前缀（Encryption prefix）仅当组合包被加密，才加上一个32位随机数用于每个组合包发送。 SR或RR组合包中第一个RTCP包必须总为一个报告包，方便头的确认。 即使没有数据发送，也没有接收到数据，也要发送一个空RR，那怕组合包中RTCP包为BYE。 附加RR如报告统计源数目超过31，在初始报告包后应该有附加RR包。 SDES包含AME项的SDES包必须包含在每个组合RTCP包中。 如应用要求，其他源描述项可选，但受到带宽限制。 BYE或APP其它RTCP包类型可以任意顺序排列，除了BYE应作为最后一个包发送，包类型出现可不止一次。 建议转换器或混合器从多个源组合单个RTCP包。 如组合包整体长度超过网络路径最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。 注意，每个组合包必须以SR或RR包开始。 附加RTCP包类型可在Inter AssignedNumbers Authority(IANA)处注册。 6.2.2.2RTCP传输间隔RTP设计成允许应用自动扩展，连接数可从几个到上千个。 例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立于连接数，但控制流量不是内在限制的。 如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。 一旦确认地址有效，如后来标记成未活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。 注意，这仍大于RTCP报告间隔最大值的五倍。 这个规范定义了除必需的AME外的几个源描述项，如NAME（人名）和EMAIL（电子邮件地址）。 它也为定义新特定应用RTCP包类型的途径。 给附加信息分配控制带宽应引起注意，因为它将降低接收报告和AME发送的速率而损害协议的性能。 建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20%。 而且并没有有意让所有SDES项包含在每个应用中。 6.2.2.3发送者与接收者报告RTP接收者使用RTCP报告包提供接收质量反馈，报告包根据接收者是否是发送者而采用两种格式中的一种。 除包类型代码外，发送者报告与接收者报告间唯一的差别是发送者报告包含一个20个字节发送者信息段。 如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR；SR和RR都可没有或包括多个接收报告块。 发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。 既然最大可有31个接收报告块嵌入在SR或RR包中，丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。 如两报告连续，比值应该等于丢失段部分；否则，就不等。 每秒包丢失绿可通过NTP时标差除以丢失部分得到。 从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。 如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。 6.2.2.4SDES:源描述RTCP包SDES包为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源。 项描述如下版本（V）、填充（P）、长度如SR包中所描述。 包类型（PT）8位，包含常数202，识别RTCP SDES包。 源计数（SC）5位，包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。 源描述项内容如下AME:规范终端标识SDES项AME标识属性如下如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要AME项提供从SSRC标识到仍为常量的源标识的绑定。 象SSRC标识，AME标识在RTP连接的所有参加者中应是唯一的。 为了提供一套相关RTP连接中某个参加者所采用的跨多媒体工具间的绑定，AME应固定为那个参加者。 为方便第三方监控，AME应适合程序或人员定位源。 NAME用户名称SDES项这是用于描述源的真正的名称，如John Doe,Bit Recycler,Megacorp，可是用户想要的任意形式。 对诸如会议应用，这种名称也许是参加者列表显示最适宜的形式，它将是除AME外发送最频繁的项目。 设置可建立这样的优先级别。 NAME值至少在连接期间仍希望保持为常数。 它不该成为连接的所有参加者中唯一依赖。 EMAIL电子邮件地址SDES项邮件地址格式由RFC822规定，如John.Doemegacorp.。 连接期间，电子邮件仍希望保持为常数。 PHONE电话号码SDES项电话号码应带有加号，代替国际接入代码，如+19085551212即为美国电话号码。 LOC用户地理位置SDES项根据应用，此项具有不同程度的细节。 对会议应用，字符串如Murray Hill,New Jersey就足够了。 然而，对活动标记系统，字符串如Room2A244,AT&T BLMH也许就适用。 细节留给实施或用户，但格式和内容可用设置指示。 在连接期间，除移动主机外，LOC值期望仍保留为常数。 TOOL应用或工具名称SDES项是一个字符串，表示产生流的应用的名称与版本，如videotool1.2。 这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。 TOOL值在连接期间仍保持常数。 NOTE:通知/状态SDES项该项的推荐语法如下所述，但这些或其它语法可在设置中显式定义。 NOTE项旨在描述源当前状态的过渡信息，如on thephone,can?t talk，或在讲座期间用于传送谈话的题目。 它应该只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和AME发送的速度，因此损害协议的性能。 特殊情况下，它不应作为用户设置文件的项目，也不是自动产生。 当其为活动时，由于NOTE项对显示很重要，其它非AME项（如NAME）传输速率将会降低，结果使NOTE项占用RTCP部分带宽。 若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，但以一个串长为零的字符串通知接收者。 然而，如对小倍数的重复或约20-30RTCP间隔也没有接收到，接收者也应该考虑NOTE项是不活跃的。 PRIV:专用扩展SDES项该项用于定义实验或应用特定的SDES扩展，它包括由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值。 前缀长度段为8位。 前缀字符串是定义PRIV项人员选择的名称，唯一对应应用接收到的其它PRIV项。 应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。 另外，推荐其它人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。 注意，前缀消耗了总长为255个八进制项的一些空间，因此，前缀应尽可能的短。 这个设备和受到约束的RTCP带宽不应过载，其目的不在于满足所有应用的全部控制通讯要求。 SDES PRIV前缀没在IANA处注册。 如证实某些形式的PRIV项具有通用性，IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀。 这简化了应用，并提高了传输的效率。 6.2.2.5BYE断开RTCP包如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC标识。 如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。 作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如camera malfunction或RTP loopdetected。 字符串具有同样的编码，如在SDES中所描述的。 如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。 6.2.2.6APP定义应用的RTCP包APP包用于开发新应用和新特征的实验，不要求注册包类型值。 带有不可识别名称的APP包应被忽略掉。 测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。 实时流协议RTSP实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。 RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。 与RTSP相比，传送HTML，而RTP传送的是多媒体数据。 请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。 6.3RTSP协议实时流协议（RTSP）是应用级协议，控制实时数据的发送。 RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。 数据源包括现场数据与存储在剪辑中数据。 该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。 6.3.1简介6.3.1.1目的实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。 尽管连续媒体流与控制流交叉是可能的，通常它本身并不发送连续流。 换言之，RTSP充当多媒体服务器的网络远程控制。 RTSP连接没有绑定到传输层连接，如TCP。 在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出RTSP请求。 此外，可使用无连接传输协议，如UDP。 RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。 实时流协议在语法和操作上与/1.1类似，因此的扩展机制大都可加入RTSP。 协议支持的操作如下从媒体服务器上检索媒体用户可通过或其它方法提交一个演示描述。 如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。 如演示仅通过单播发送给用户，用户为了安全应提供目的地址。 媒体服务器邀请进入会议媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。 这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。 将媒体加到现成讲座中如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。 如/1.1中类似，RTSP请求可由代理、通道与缓存处理。 6.3.1.2协议特点RTSP特性如下可扩展性新方法和参数很容易加入RTSP。 易解析RTSP可由标准或MIME解吸器解析。 安全RTSP使用网页安全机制。 独立于传输RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。 多服务器支持每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。 记录设备控制协议可控制记录和回放设备。 流控与会议开始分离仅要求会议初始化协议提供，或可用来创建唯一会议标识号。 特殊情况下，SIP或H.323可用来邀请服务器入会。 适合专业应用通过SMPTE时标，RTSP支持帧级精度，允许远程数字演示描述中立协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个RTSP URI。 代理与防火墙友好协议可由应用和传输层防火墙处理。 防火墙需要理解SETUP方法，为UDP媒体流打开一个缺口。 友好此处，RTSP明智的采用观念，使现在结构都可重用。 结构包括Inter内容选择平台（PICS）。 由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向添加方法。 适当的服务器控制如用户启动一个流，他必须也可以停止一个流。 传输协调；实际处理连续媒体流前，用户可协调传输方法。 性能协调如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。 这允许用户提出适合的用户界面。 6.3.1.3扩展RTSP由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。 RTSP可以如下三种方式扩展，这里以改变大小排序以新参数扩展。 如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。 加入新方法。 如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。 用户可使用OPTIONS方法查询服务器支持的方法。 服务器使用公共响应头列出支持的方法。 定义新版本协议，允许改变所有部分。 （除了协议版本号位置）6.3.1.4操作模式每个演示和媒体流可用RTSP URL识别。 演示组成的整个演示与媒体属性由演示描述文件定义。 使用或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。 为了说明，假设演示描述描述了多个演示，其中每个演示维持了一个公共时间轴。 为简化说明，且不失一般性，假定演示描述的确包含这样一个演示。 演示可包含多个媒体流。 除媒体参数外，网络目标地址和端口也需要决定。 下面区分几种操作模式单播以用户选择的端口号将媒体发送到RTSP请求源。 组播，服务器选择地址媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。 组播，用户选择地址如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。 6.3.1.5RTSP状态RTSP控制通过单独协议发送的流，与控制通道无关。 例如，RTSP控制可通过TCP连接，而数据流通过UDP。 因此，即使媒体服务器没有收到请求，数据也会继续发送。 在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。 所以，服务器需要维持能联系流与RTSP请求的连接状态。 RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用SETUP让服务器给流分配资源，启动RTSP连接。 PLAY与RECORD启动SETUP分配流的数据传输。 PAUSE临时停止流，而不释放服务器资源。 TEARDOWN释放流的资源，RTSP连接停止。 标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连接产生连接标识。 6.3.1.6与其他协议关系RTSP在功能上与有重叠，与相互作用体现在与流内容的初始接触是通过网页的。 目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。 例如，演示描述可通过和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP服务器与用户不全依靠。 但是，RTSP与的本质差别在于数据发送以不同协议进行。 是不对称协议，用户发出请求，服务器作出响应。 RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。 重用功能至少在两个方面有好处，即安全和代理。 要求非常接近，在缓存、代理和授权上采用功能是有价值的。 当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。 RTSP假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。 6.3.2协议参数6.3.3RTSP信息RTSP是基于文本的协议，采用ISO10646字符集，使用UTF-8编码方案。 行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。 基于文本的协议使以自描述方式增加可选参