Internet多媒体协议解析课件

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,*,第十章,Internet,多媒体协议,概述,本章主要介绍下列支持多媒体传输的协议：,IGMP,MBONE,RTP,RTCP,RSVP,9/16/2024,1,有关概念,RTP,会话：,利用,RTP,进行通信的各方之间的映射关系。对于参与通信的每台主机，会话由一对特定的目标传输地址(网络地址加上,RTP,端口和,RTCP,端口)定义。在多媒体会话中，每种媒体都由一个单独的,RTP,会话传输；使用单独的,RTCP,分组。这些,RTP,会话通过不同的端口对和或不同的组播地址加以区别。,同步源(,Synchronization Source，SSRC)：,RTP,分组流的源点，,SSRC,标识符包含在,RTP,首部中。从特定同步源发出的所有分组组成同一定时和序号空间的一部分，所以接收端可以根据同步源将收到的分组进行分类，从而在本地重放。,9/16/2024,2,参与源(,Contributing Source,CSRC)：,特定,RTP,分组流,的源点。该流将作为,RTP,混合器的输入之一。混合器将在形成,的分组的,RTP,首部中插入与该分组源点相应的一组,SSRC,标识。,混合器(,Mixer)：,从若干数据源接收,RTP,分组的中间系统，该系统可能修改数据格式，按特定方式组合分组，然后创建新的,RTP,分组。由于各输入源点的定时可能不同步，混和器将会调整各输人流的定时，然后为组合流创建自己的定时。所有由混合器创建的数据分组的同步源就是该混合器。,翻译器(,Translator)：,在转发,RTP,分组时保持分组的同步源标识不变的中间系统。翻译器的实例包括：在不进行混合操作的同时转换编码的设备，将组播转换为单播的中继器以及防火墙中的应用级过滤器。,监视器(,Monitor)：,接收,RTP,会话参与者发送的,RTP,分组的应用程序,，它以分布监视、故障侦测和长期统计为目标对当前服务质量进行估算。,9/16/2024,3,IP,组,播,IP,组播系统,：一对多，数据分组只创建一次，然后被组播服务器（,ROUTER）,复制多份，发往服务器的输出端口并分发给相连的所有接收端。,主要应用：,音频会议和视频会议。远程教育、会议和白板交谈等。,地址格式：,1110+组播地址（28）,从 224.0.0.0 到 239.255.255.255,组播,方式：,组播遂道。,组播数据封装在,IP,数据报字段中传输，在,INTERNET,中的转发过程依传统的,IP,首部。,路由器上运行组播软件。,9/16/2024,4,IGMP,操作,IGMP,支持组播操作。它允许一主机加入组。路由器知道组的信息，先向主机发送,IGMP,查询；,IGMP,报告操作允许主机通知,ROUTER,它是否希望加入特定的组播组。,当一台主机欲加入某个多播组时，会发出“主机成员报告”的,IGMP,消息通知多播路由器。当多播路由器接收到发给那个多播组的数据时，便会将其转发给所有的多播主机。多播路由器还会周期性地发出“主机成员查询”的,IGMP,消息，向子网查询多播主机，若发现某个多播组已没有任何成员，则停止转发该多播组的数据。此外，当支持,IGMP v2,的主机（如,Windows 98/2000,计算机）退出某个多播组时，还会向路由器发送一条“离开组”的,IGMP,消息，以通知路由器停止转发该多播组的数据。但只有当子网上所有主机都退出某个多播组时，路由器才会停止向该子网转发该多播组的数据。,9/16/2024,5,MBONE,Multicast Backbone,的 缩 写， 一 种 高 速 虚 拟 网 络， 它 可 以 将 信 息 包 同 时 发 送 到 多 个,Internet,站 点， 适 用 于 音 频、 视 频 的 传 输。1992年，,MBONE,在,IETF（Internet,工 程 工 作 组） 的,Audiocast,试 验 中， 把,IETF,的 会 议 内 容 通 过 声 音、 图 像 进 行 实 时 传 播。,MBONE,已 成 为,Internet,的 一 部 分， 是 支 持 广 播 式 传 输 的 关 键 部 件。,最初连入了,4,个国家的,40,个子网。截至,1996,年,4,月，,MBONE,的规模已经遍及,25,个国家的,2800,多个子网。在,MBONE,上的著名,Multicast,服务有,NASA space shuttle missions,、,U.S. House and Senate sessions,、,live satellite weather photos,等等。新的应用与服务的出现，使得,Internet Multicasting,技术得到了迅速的发展。,9/16/2024,6,实时协议(,RTP),用于支持实时数据流。典型的实时应用是语音和视频系统。,RTP,为具有实时特征的数据，提供了端到端的传输服务。服务包括负载类型标识、定序、时间戳和传输监视。应用通常在,UDP,协议之上运行,RTP，,如果底层网络支持组播，那么,RTP,还支持到组播地址的数据传输。它依靠底层服务提供保证及时传输或保证其他服务质量。,RTP,不能防止传输过程出现的丢包和乱序现象，而且它也不要求底层网络是可靠的或按顺序传输分组。,RTP,代表了一种新型的协议，,RTP,将提供特定应用所需的信息，而且通常与应用处理集成在一起，而不是作为单独的协议层实现。,RTP,是通过修改和或增加首部来实现新功能的。,实时,协议,RTP,9/16/2024,7,翻译器和混合器,RTP,翻译器将负载从一种语法转换(编码)为另一种语法。,翻译器的任务是接收工作站的数据流，将其转换(编码)为以,下格式:(1)符合传输网络的带宽限制，和/或(2)符合另一边的,用户工作站的带宽限制。,RTP,混合器将多个源组合为一个流。通常，混合器主要执,行音频操作，不会降低接收方收到的信号质量。它只是将各,信号组合为一种统一的格式。,RTP,混合器特别适用于音频会,议。一般来说它不太适合做视频会议，因为将多个视频源组,合成一种格式比较困难。,RTP,混合器并不是将每种源负载转,换为一种不同的格式。它在保留原来格式的基础上将不同源,负载组合为一个流。而另一方面，如果视频流是简单的脉冲,代码调制(,PCM),的流，则可以将各源负载的值加起来，从而,将它们组合为单一的流。,9/16/2024,8,RTP,报文都使用同一种格式。,RTP,支持应用层成帧。如,G.722，JPEG,视频标准。,RTP,协议数据单元（,PDU）,封装在,用户,UDP,和,IP（PDU）,中传输。,RTP,无默认的,UDP,端口。由于主机在各种不同的应用中,都要利用,RTP，,给一默认口不够。但是当应用没有其他可用,的端口时，,RTP,将5004端口作为指定端口。,RTP,规范要求不,管选取哪个端口其值必须是偶数。这是由于比,RTP,端口值只,大1的端口(对于指定端口为5005)被用于传送实时控制协议,RTCP,的业务量的缘故。,格式见图,P179。,RTP,报文,9/16/2024,9,RTP,报文,同步源,ID,是,RTP,报文的最初发送者的标识。该发送者负责计算报文的序列号和时间戳。,RTP,翻译器保留该标识，但,RTP,混合器将成为新的同步源，而其他(最初的)源将成为参与源，这些参与源记录在报文的参与源,ID,字段中。,通信双方利用序列号和时间戳达到下列目的：(1)确定数据按正确,j,顷序到达；(2)检查丢包现象；(3)同步数据流。,值得注意的是，,RTP,并没有定义应用数据字段的格式，而是交给应用完成。因此，,RTP,可以携带各种类型的应用数据。,P180,页列出了,RTPPDU,数据字段可以携带的各种载荷类型。该表公布以后，业界又定义了可由,RTP,承载的其他标准。例如，,H324、H263,和,C723,分别是压缩音频流和视频流的最新标准。,9/16/2024,10,RTP,复用,操作,RTP,复用功能由目标传输地址（,SOCKET）,提供。,复用分组格式,除了时间戳、标记位和,SSRC,之外，,RTP,首,部的其他字段都保持原有定义。复用分组的格式如图所示。,载荷类型：负载类型字段标识此,RTP,分组为复用分组。 时间戳：该协议要求分组中所有复用流必须具有相同的时钟频率(例如，音频的采样频率)，而且按照一定时间间隔产生媒体帧，该时间间隔是一个公共的帧持续时间的整数倍。,标记位：复用操作没有使用此字段，它的值设置为0。复用首部中为每个用户都包含一个标记位。,SSRC：,此字段用于标识特定的用户组(而不是单个用户)，这些用户的帧是同步的。,复用(,MUX),首部包含参与复用操作的所有用户的信息。它还包含载荷类型的信息以及用于每个用户载荷的标识值。,9/16/2024,11,负 责,管理发送应用和接收应用的实时会话。该协议支持发送,者向接收者通报后者应该接收到的,RTP,数据，它还支持接收者,直接向发送者报告。这种思想在,IP,组播中非常有效，因为它可,以检查分组分发中的故障。,发送者和接收者报告可能占用大量的带宽，,RTCP,提供了一种,定义这些报告发送频率的机制。其思想是无论多少用户参与会,话，会话的总体数据流保持恒定。,所有,RTCP,分组的源端都发送源说明，描述发送数据的那些,应用的特征。这些报文包含一些定义属性的源说明项，例如电,子邮件地址、地理位置、电话号码和邮箱地址。会议(视频或,音频)的参与者可以在任何时间通过发送一个称为“,bye”,的注销,报文而退出会议。,RTCP,报文可以针对特定应用进行编码。,RTCP,并不关心报文的内容，,RTCP,操作在应用间透明地传输,报文。,RTCP,9/16/2024,12,RTCP,分组,有五种分组类型：200204,会话的发送者每隔一段时间向接收者发送者报告。各字段内容见,P184RTCP,报文格式。,抖动方程：,到达时间间隔抖动是两个分组的相对传输时间的,差异。它是分组的,RTP,时间戳和分组到达时接收者时钟之间,的差。,如下面的方程所示，它等于两个分组的“相对传输时间”之,差：相对传输时间是分组的,RTP,时间戳和分组到达时接收者,的时钟之差，以相同单位计算。,如果,Si,是分组,i,的,RTP,时间戳，,Bi,是按照,RTP,时间戳单位计算的分组,i,的到达时间，则对于分组,i,和,i，D,的表示如下：,D(i，j)=(,Rj,Rj,)(,Sj,Si,）=(,Rj,Sj,)(,Rj,Si,）,每次从源,SSRCn,接收到数据分组,i，,就计算一次到达时间间隔抖动,J，,其中利用了该分组和按到达顺序计算的前一分组,i1(,不一定按序号顺序)之差,D，,计算公式如下：,J=J+(|D(i1，i)|-J)16,9/16/2024,13,源描述分组(,SDES),RTCP,支持数据源提供更多的关于自己的信息。此操作通过发送,RTP,源描述分组(,SDES)(,如图,P185),实现。该,PDU,包括源同步标识或参与源标识(,SSRC,或,CCRC),以及,SDES,项。,图,P186,列出了目前定义的源描述项。如表所示，,这些项只是提供了更多关于源的信息。它们的使用方法由具体实现确定，,RFCl889,和,RFCl996,对这个课题有更多的讨论。,9/16/2024,14,RSVP,协议简介：,资源预约协议(,RSVP),为实时多媒体会议定义了一种预约操作。,RSVP,与目前使用诸如,ATM、,帧中继以及,X25,等技术的系统不同，它是由数据的接收方进行预约。与此形成对照的是，其他技术支持数据发送方创建需求。,原理：数据接收方最了解自己的能力和限制。,例如，视频服务器正以很高的比特率向接收方发送数据，比如高质量视频的速率是100,Mbs。,但是，,各接收者(客户)接收高质量传输的能力不同,。因此，它们可以向服务器发送自己的资源预约请求，从而定义不同的,吞吐量要求,。,例如，一个通过,OC-3,线路卡与,ATM,网络相连的设备，连接在以太网上的个人电脑可能无法支持全部100,MB,的传输带宽。因此，这2个设备可以向服务器发送预约请求，注明自己的能力(可用带宽)。,9/16/2024,15,RSVP,使用流的概念表示预约的数据流量。,流与帧中继及,ATM,中的面向连接的虚拟电路有些相似。它们标识了从发送端应用到达接收端,应用的数据流。此概念与,IPv6,的流标识字段配合,得非常好。该字段(连同源地址)将惟一地确定每一个流。流和流标识的概念主要用于区分网络中不同类型的数据，然后根据各自的,定时,和,同步,要求区别对待。实际上，流标识最可能用于将数据放在中间交换机(位于服务器和客户之间)的不同队列上。,RSVP,9/16/2024,16,RSVP,路径操作：,RSVP,不提供路由功能，而是利用,IPv4,或,IPv6,的转发功能，这正如网际控制报文协议(,ICMP),和,Intemet,组管理协议(,IGMP),一样。,RSVP,支持单播和组播，而且可以支持当前和以后可能出现的组播协议。与,IP,类似，它根据路由表计算报文的路径。它利用,IGMP,加入组播组，然后为该组播组预约资源。,RSVP,要求数据接收方提出流的,Oos,要求。接收方应用必须计算,QOS,需求，然后传递给,RSVP。,在分析请求之后，,RSVP,向数据流经过的所有节点发送请求报文。如图,P187,所示，服务器(流发送者)利用路径报文为会话建立路径。,9/16/2024,17,预约操作：,由流的接收方发出的预约报文，支持发送方和中间路由器获得接收方的请求。,见,P187,预约报文：,见,P188,所有,RSVP,报文由,相同的首部和报文体组成。,RSVP,对象（报文中信息按对象编码）,RSVP,报文功能：,本节简要介绍,RSVP,报文的功能，算是对前面关于,RSVP,的讨论的总结。关于更详细的信,息可以参考,RFC2205。,路径报文,针对自己创建的每个数据流，发送方都定期地发送路径报文。该报文中包括一个定义数据分组格式的,SENDERTEMPLATE,对象和描述流特征的,SENDERTSPEC,对象。另外，它还可能包括一个存储该流的广播信息的,ADSPEC,对象。,9/16/2024,18,预约报文(,Resv,),预约报文携带预约请求，它沿着与此会话的数据流相反的方向从接收方逐跳传输到发送方。预约报文的,IP,目的地址是从路径状态中获得的前一跳的单播地址，而源地址是发送此报文的节点的地址。,此报文中的,RESV_CONFIRM,对象表示需要预约确认，而且其中携带了接收预约确认报文的,IP,地址。该报文还可以包含若干,POLICY_DATA,对象。,路径拆除报文,收到路径拆除报文后将会删除匹配的路径,状态。所谓匹配必须与,SES-SION、 SENDER_TEMPLATE,和,PHOP,对象匹配。另外，针对组播会话的路径拆除报文只,能与该报文到达的接收接口上路径信息匹配。如果不存在匹,配的路径状态，则应该将路径拆除报文丢弃并不再转发。,路径拆除报文由发送方或检测到路径状态超时的节点最先发出，然后沿下游向所有接收跳发送。路径拆除报文必须以与相应的路径报文相同的方式转发。因此，它的,IP,目标地址必须是会话的目标地址，而源,IP,地址必须是将被拆除的路径状态中的发送方地址。,9/16/2024,19,预约拆除报文,收到预约拆除报文的节点将会删除匹配的预约状态。所谓匹配的预约状态是指与,SESSION、STYLE,和,FILTER SPEC,对象匹配。如果不存在匹配的预,约状态，则该预约拆除报文将被丢弃。预约拆除报文可以拆,除,FF,类型或,SE,类型的预约状态中的过滤器描述的任何子集。,预约拆除报文最初由接收方或检测到预约状态超时的任何节点发出，然后它们沿上游向所有匹配的发送方传输。预约拆除报文必须采用与相应的预约报文相同的路由方式，而且它的,IP,目的地址是前一跳的单播地址。,路径错误报文,路径错误报文报告在路径报文处理过程中发生的错误。它们将被发往上游的所有发送方，而且利用路径状态逐跳传输。在每个节点，,IP,目的地址是前一跳的单播地址。路径错误报文不修改途经节点的任何状态信息；它们只向发送方提供应用报告。,预约错误报文,预约错误报文报告在预约报文处理过程中发生的错误，它们也可能报告预约的突然终止(比如由于管理因素)。 预约错误报文向下游的适当接收方传输，并利用预约状态逐跳传递。在每个节点中，,IP,目的地址是下跳节点的单播地址。,9/16/2024,20,确认报文,预约确认报文用于确认预约请求。某节点接收到包含,RESV_CONFIRM,对象的预约请求报文时将发送预约确认报文。,端口规则：,RSVP,会话通常由三元组定义：,DesAddress,Protocolid,和,DstPort,。,DstPort,是一个,UDPTCP,目标端口字段。如果,Protocolid,指示的协议在,UDP,和,TCP,格式中没有目标端口字段，则,DstPort,可以省略(设置为0)。,RSVP,支持,Protocolid,的任何值。但是，,RSVP,的端系统实现可以只支持某些值，特别是只,支持,UDP,和,TCP,的值(分别是17和6)。,Intemet,多媒体协议是一组相关协议。,RSVP,为多媒体会话建立资源。,RTP,传输用户数据并管理用户应用的重放。,RTCP,提供一种反馈机制，支持用户确认会话的质量。而,IGMP,在必要时可以提供组播支持。,9/16/2024,21,