Internet多媒体协议

2019/10/121第十章Internet多媒体协议概述本章主要介绍下列支持多媒体传输的协议：IGMPMBONERTPRTCPRSVP2019/10/122有关概念RTP会话：利用RTP进行通信的各方之间的映射关系。对于参与通信的每台主机，会话由一对特定的目标传输地址(网络地址加上RTP端口和RTCP端口)定义。在多媒体会话中，每种媒体都由一个单独的RTP会话传输；使用单独的RTCP分组。这些RTP会话通过不同的端口对和／或不同的组播地址加以区别。同步源(SynchronizationSource，SSRC)：RTP分组流的源点，SSRC标识符包含在RTP首部中。从特定同步源发出的所有分组组成同一定时和序号空间的一部分，所以接收端可以根据同步源将收到的分组进行分类，从而在本地重放。2019/10/123参与源(ContributingSource,CSRC)：特定RTP分组流的源点。该流将作为RTP混合器的输入之一。混合器将在形成的分组的RTP首部中插入与该分组源点相应的一组SSRC标识。混合器(Mixer)：从若干数据源接收RTP分组的中间系统，该系统可能修改数据格式，按特定方式组合分组，然后创建新的RTP分组。由于各输入源点的定时可能不同步，混和器将会调整各输人流的定时，然后为组合流创建自己的定时。所有由混合器创建的数据分组的同步源就是该混合器。翻译器(Translator)：在转发RTP分组时保持分组的同步源标识不变的中间系统。翻译器的实例包括：在不进行混合操作的同时转换编码的设备，将组播转换为单播的中继器以及防火墙中的应用级过滤器。监视器(Monitor)：接收RTP会话参与者发送的RTP分组的应用程序，它以分布监视、故障侦测和长期统计为目标对当前服务质量进行估算。2019/10/124IP组播IP组播系统：一对多，数据分组只创建一次，然后被组播服务器（ROUTER）复制多份，发往服务器的输出端口并分发给相连的所有接收端。主要应用：音频会议和视频会议。远程教育、会议和白板交谈等。地址格式：1110+组播地址（28）从224.0.0.0到239.255.255.255组播方式：组播遂道。组播数据封装在IP数据报字段中传输，在INTERNET中的转发过程依传统的IP首部。路由器上运行组播软件。2019/10/125IGMP操作IGMP支持组播操作。它允许一主机加入组。路由器知道组的信息，先向主机发送IGMP查询；IGMP报告操作允许主机通知ROUTER它是否希望加入特定的组播组。当一台主机欲加入某个多播组时，会发出“主机成员报告”的IGMP消息通知多播路由器。当多播路由器接收到发给那个多播组的数据时，便会将其转发给所有的多播主机。多播路由器还会周期性地发出“主机成员查询”的IGMP消息，向子网查询多播主机，若发现某个多播组已没有任何成员，则停止转发该多播组的数据。此外，当支持IGMPv2的主机（如Windows98/2000计算机）退出某个多播组时，还会向路由器发送一条“离开组”的IGMP消息，以通知路由器停止转发该多播组的数据。但只有当子网上所有主机都退出某个多播组时，路由器才会停止向该子网转发该多播组的数据。2019/10/126MBONEMulticastBackbone的缩写，一种高速虚拟网络，它可以将信息包同时发送到多个Internet站点，适用于音频、视频的传输。1992年，MBONE在IETF（Internet工程工作组）的Audiocast试验中，把IETF的会议内容通过声音、图像进行实时传播。MBONE已成为Internet的一部分，是支持广播式传输的关键部件。最初连入了4个国家的40个子网。截至1996年4月，MBONE的规模已经遍及25个国家的2800多个子网。在MBONE上的著名Multicast服务有NASAspaceshuttlemissions、U.S.HouseandSenatesessions、livesatelliteweatherphotos等等。新的应用与服务的出现，使得InternetMulticasting技术得到了迅速的发展。2019/10/127实时协议(RTP)用于支持实时数据流。典型的实时应用是语音和视频系统。RTP为具有实时特征的数据，提供了端到端的传输服务。服务包括负载类型标识、定序、时间戳和传输监视。应用通常在UDP协议之上运行RTP，如果底层网络支持组播，那么RTP还支持到组播地址的数据传输。它依靠底层服务提供保证及时传输或保证其他服务质量。RTP不能防止传输过程出现的丢包和乱序现象，而且它也不要求底层网络是可靠的或按顺序传输分组。RTP代表了一种新型的协议，RTP将提供特定应用所需的信息，而且通常与应用处理集成在一起，而不是作为单独的协议层实现。RTP是通过修改和／或增加首部来实现新功能的。实时协议RTP2019/10/128翻译器和混合器RTP翻译器将负载从一种语法转换(编码)为另一种语法。翻译器的任务是接收工作站的数据流，将其转换(编码)为以下格式:(1)符合传输网络的带宽限制，和/或(2)符合另一边的用户工作站的带宽限制。RTP混合器将多个源组合为一个流。通常，混合器主要执行音频操作，不会降低接收方收到的信号质量。它只是将各信号组合为一种统一的格式。RTP混合器特别适用于音频会议。一般来说它不太适合做视频会议，因为将多个视频源组合成一种格式比较困难。RTP混合器并不是将每种源负载转换为一种不同的格式。它在保留原来格式的基础上将不同源负载组合为一个流。而另一方面，如果视频流是简单的脉冲代码调制(PCM)的流，则可以将各源负载的值加起来，从而将它们组合为单一的流。2019/10/129RTP报文都使用同一种格式。RTP支持应用层成帧。如G.722，JPEG视频标准。RTP协议数据单元（PDU）封装在用户UDP和IP（PDU）中传输。RTP无默认的UDP端口。由于主机在各种不同的应用中都要利用RTP，给一默认口不够。但是当应用没有其他可用的端口时，RTP将5004端口作为指定端口。RTP规范要求不管选取哪个端口其值必须是偶数。这是由于比RTP端口值只大1的端口(对于指定端口为5005)被用于传送实时控制协议RTCP的业务量的缘故。格式见图P179。RTP报文2019/10/1210RTP报文同步源ID是RTP报文的最初发送者的标识。该发送者负责计算报文的序列号和时间戳。RTP翻译器保留该标识，但RTP混合器将成为新的同步源，而其他(最初的)源将成为参与源，这些参与源记录在报文的参与源ID字段中。通信双方利用序列号和时间戳达到下列目的：(1)确定数据按正确j顷序到达；(2)检查丢包现象；(3)同步数据流。值得注意的是，RTP并没有定义应用数据字段的格式，而是交给应用完成。因此，RTP可以携带各种类型的应用数据。P180页列出了RTPPDU数据字段可以携带的各种载荷类型。该表公布以后，业界又定义了可由RTP承载的其他标准。例如，H·324、H．263和C．723分别是压缩音频流和视频流的最新标准。2019/10/1211RTP复用操作RTP复用功能由目标传输地址（SOCKET）提供。复用分组格式除了时间戳、标记位和SSRC之外，RTP首部的其他字段都保持原有定义。复用分组的格式如图所示。●载荷类型：负载类型字段标识此RTP分组为复用分组。●时间戳：该协议要求分组中所有复用流必须具有相同的时钟频率(例如，音频的采样频率)，而且按照一定时间间隔产生媒体帧，该时间间隔是一个公共的帧持续时间的整数倍。●标记位：复用操作没有使用此字段，它的值设置为0。复用首部中为每个用户都包含一个标记位。●SSRC：此字段用于标识特定的用户组(而不是单个用户)，这些用户的帧是同步的。复用(MUX)首部包含参与复用操作的所有用户的信息。它还包含载荷类型的信息以及用于每个用户载荷的标识值。2019/10/1212负责管理发送应用和接收应用的实时会话。该协议支持发送者向接收者通报后者应该接收到的RTP数据，它还支持接收者直接向发送者报告。这种思想在IP组播中非常有效，因为它可以检查分组分发中的故障。发送者和接收者报告可能占用大量的带宽，RTCP提供了一种定义这些报告发送频率的机制。其思想是无论多少用户参与会话，会话的总体数据流保持恒定。所有RTCP分组的源端都发送源说明，描述发送数据的那些应用的特征。这些报文包含一些定义属性的源说明项，例如电子邮件地址、地理位置、电话号码和邮箱地址。会议(视频或音频)的参与者可以在任何时间通过发送一个称为“bye”的注销报文而退出会议。RTCP报文可以针对特定应用进行编码。RTCP并不关心报文的内容，RTCP操作在应用间透明地传输报文。RTCP2019/10/1213RTCP分组有五种分组类型：200~204会话的发送者每隔一段时间向接收者发送者报告。各字段内容见P184RTCP报文格式。抖动方程：到达时间间隔抖动是两个分组的相对传输时间的差异。它是分组的RTP时间戳和分组到达时接收者时钟之间的差。如下面的方程所示，它等于两个分组的“相对传输时间”之差：相对传输时间是分组的RTP时间戳和分组到达时接收者的时钟之差，以相同单位计算。如果Si是分组i的RTP时间戳，Bi是按照RTP时间戳单位计算的分组i的到达时间，则对于分组i和i，D的表示如下：D(i，j)=(Rj—Rj)—(Sj—Si）=(Rj—Sj)—(Rj—Si）每次从源SSRC—n接收到数据分组i，就计算一次到达时间间隔抖动J，其中利用了该分组和按到达顺序计算的前一分组i—1(不一定按序号顺序)之差D，计算公式如下：J=J+(|D(i—1，i)|-J)／162019/10/1214源描述分组(SDES)RTCP支持数据源提供更多的关于自己的信息。此操作通过发送RTP源描述分组(SDES)(如图P185)实现。该PDU包括源同步标识或参与源标识(SSRC或CCRC)以及SDES项。图P186列出了目前定义的源描述项。如表所示，这些项只是提供了更多关于源的信息。它们的使用方法由具体实现确定，RFCl889和RFCl996对这个课题有更多的讨论。2019/10/1215RSVP协议简介：资源预约协议(RSVP)为实时多媒体会议定义了一种预约操作。RSVP与目前使用诸如ATM、帧中继以及X．25等技术的系统不同，它是由数据的接收方进行预约。与此形成对照的是，其他技术支持数据发送方创建需求。原理：数据接收方最了解自己的能力和限制。例如，视频服务器正以很高的比特率向接收方发送数据，比如高质量视频的速率是100Mb／s。但是，各接收者(客户)接收高质量传输的能力不同。因此，它们可以向服务器发送自己的资源预约请求，从而定义不同的吞吐量要求。例如，一个通过OC-3线路卡与ATM网络相连的设备，连接在以太网上的个人电脑可能无法支持全部100MB的传输带宽。因此，这2个设备可以向服务器发送预约请求，注明自己的能力(可用带宽)。2019/10/1216RSVP使用流的概念表示预约的数据流量。流与帧中继及ATM中的面向连接的虚拟电路有些相似。它们标识了从发送端应用到达接收端应用的数据流。此概念与IPv6的流标识字段配合得非常好。该字段(连同源地址)将惟一地确定每一个流。流和流标识的概念主要用于区分网络中不同类型的数据，然后根据各自的定时和同步要求区别对待。实际上，流标识最可能用于将数据放在中间交换机(位于服务器和客户之间)的不同队列上。RSVP2019/10/1217RSVP路径操作：RSVP不提供路由功能，而是利用IPv4或IPv6的转发功能，这正如网际控制报文协议(ICMP)和Intemet组管理协议(IGMP)一样。RSVP支持单播和组播，而且可以支持当前和以后可能出现的组播协议。与IP类似，它根据路由表计算报文的路径。它利用IGMP加入组播组，然后为该组播组预约资源。RSVP要求数据接收方提出流的Oos要求。接收方应用必须计算QOS需求，然后传递给RSVP。在分析请求之后，RSVP向数据流经过的所有节点发送