Internet多媒体协议课件

Internet多媒体协议2024/4/17Internet多媒体协议有关概念RTP会话：利用RTP进行通信的各方之间的映射关系。对于参与通信的每台主机，会话由一对特定的目标传输地址(网络地址加上RTP端口和RTCP端口)定义。在多媒体会话中，每种媒体都由一个单独的RTP会话传输；使用单独的RTCP分组。这些RTP会话通过不同的端口对和／或不同的组播地址加以区别。同步源(SynchronizationSource，SSRC)：RTP分组流的源点，SSRC标识符包含在RTP首部中。从特定同步源发出的所有分组组成同一定时和序号空间的一部分，所以接收端可以根据同步源将收到的分组进行分类，从而在本地重放。

2024/4/172Internet多媒体协议参与源(ContributingSource,CSRC)：特定RTP分组流的源点。该流将作为RTP混合器的输入之一。混合器将在形成的分组的RTP首部中插入与该分组源点相应的一组SSRC标识。混合器(Mixer)：从若干数据源接收RTP分组的中间系统，该系统可能修改数据格式，按特定方式组合分组，然后创建新的RTP分组。由于各输入源点的定时可能不同步，混和器将会调整各输人流的定时，然后为组合流创建自己的定时。所有由混合器创建的数据分组的同步源就是该混合器。翻译器(Translator)：在转发RTP分组时保持分组的同步源标识不变的中间系统。翻译器的实例包括：在不进行混合操作的同时转换编码的设备，将组播转换为单播的中继器以及防火墙中的应用级过滤器。监视器(Monitor)：接收RTP会话参与者发送的RTP分组的应用程序，它以分布监视、故障侦测和长期统计为目标对当前服务质量进行估算。2024/4/173Internet多媒体协议IP组播

IP组播系统：一对多，数据分组只创建一次，然后被组播服务器（ROUTER）复制多份，发往服务器的输出端口并分发给相连的所有接收端。

主要应用：音频会议和视频会议。远程教育、会议和白板交谈等。地址格式：1110+组播地址（28）从224.0.0.0到239.255.255.255组播方式：组播遂道。组播数据封装在IP数据报字段中传输，在INTERNET中的转发过程依传统的IP首部。路由器上运行组播软件。2024/4/174Internet多媒体协议IGMP操作IGMP支持组播操作。它允许一主机加入组。路由器知道组的信息，先向主机发送IGMP查询；IGMP报告操作允许主机通知ROUTER它是否希望加入特定的组播组。当一台主机欲加入某个多播组时，会发出“主机成员报告”的IGMP消息通知多播路由器。当多播路由器接收到发给那个多播组的数据时，便会将其转发给所有的多播主机。多播路由器还会周期性地发出“主机成员查询”的IGMP消息，向子网查询多播主机，若发现某个多播组已没有任何成员，则停止转发该多播组的数据。此外，当支持IGMPv2的主机（如Windows98/2000计算机）退出某个多播组时，还会向路由器发送一条“离开组”的IGMP消息，以通知路由器停止转发该多播组的数据。但只有当子网上所有主机都退出某个多播组时，路由器才会停止向该子网转发该多播组的数据。2024/4/175Internet多媒体协议MBONEMulticastBackbone的缩写，一种高速虚拟网络，它可以将信息包同时发送到多个Internet站点，适用于音频、视频的传输。1992年，MBONE在IETF（Internet工程工作组）的Audiocast试验中，把IETF的会议内容通过声音、图像进行实时传播。MBONE已成为Internet的一部分，是支持广播式传输的关键部件。最初连入了4个国家的40个子网。截至1996年4月，MBONE的规模已经遍及25个国家的2800多个子网。在MBONE上的著名Multicast服务有NASAspaceshuttlemissions、U.S.HouseandSenatesessions、livesatelliteweatherphotos等等。新的应用与服务的出现，使得InternetMulticasting技术得到了迅速的发展。

2024/4/176Internet多媒体协议实时协议(RTP)用于支持实时数据流。典型的实时应用是语音和视频系统。RTP为具有实时特征的数据，提供了端到端的传输服务。服务包括负载类型标识、定序、时间戳和传输监视。应用通常在UDP协议之上运行RTP，如果底层网络支持组播，那么RTP还支持到组播地址的数据传输。它依靠底层服务提供保证及时传输或保证其他服务质量。RTP不能防止传输过程出现的丢包和乱序现象，而且它也不要求底层网络是可靠的或按顺序传输分组。RTP代表了一种新型的协议，RTP将提供特定应用所需的信息，而且通常与应用处理集成在一起，而不是作为单独的协议层实现。RTP是通过修改和／或增加首部来实现新功能的。实时协议RTP2024/4/177Internet多媒体协议翻译器和混合器

RTP翻译器将负载从一种语法转换(编码)为另一种语法。翻译器的任务是接收工作站的数据流，将其转换(编码)为以下格式:(1)符合传输网络的带宽限制，和/或(2)符合另一边的用户工作站的带宽限制。RTP混合器将多个源组合为一个流。通常，混合器主要执行音频操作，不会降低接收方收到的信号质量。它只是将各信号组合为一种统一的格式。RTP混合器特别适用于音频会议。一般来说它不太适合做视频会议，因为将多个视频源组合成一种格式比较困难。RTP混合器并不是将每种源负载转换为一种不同的格式。它在保留原来格式的基础上将不同源负载组合为一个流。而另一方面，如果视频流是简单的脉冲代码调制(PCM)的流，则可以将各源负载的值加起来，从而将它们组合为单一的流。2024/4/178Internet多媒体协议

RTP报文都使用同一种格式。RTP支持应用层成帧。如G.722，JPEG视频标准。RTP协议数据单元（PDU）封装在用户UDP和IP（PDU）中传输。RTP无默认的UDP端口。由于主机在各种不同的应用中都要利用RTP，给一默认口不够。但是当应用没有其他可用的端口时，RTP将5004端口作为指定端口。RTP规范要求不管选取哪个端口其值必须是偶数。这是由于比RTP端口值只大1的端口(对于指定端口为5005)被用于传送实时控制协议RTCP的业务量的缘故。格式见图P179。RTP报文2024/4/179Internet多媒体协议RTP报文

同步源ID是RTP报文的最初发送者的标识。该发送者负责计算报文的序列号和时间戳。RTP翻译器保留该标识，但RTP混合器将成为新的同步源，而其他(最初的)源将成为参与源，这些参与源记录在报文的参与源ID字段中。通信双方利用序列号和时间戳达到下列目的：(1)确定数据按正确j顷序到达；(2)检查丢包现象；(3)同步数据流。值得注意的是，RTP并没有定义应用数据字段的格式，而是交给应用完成。因此，RTP可以携带各种类型的应用数据。P180页列出了RTPPDU数据字段可以携带的各种载荷类型。该表公布以后，业界又定义了可由RTP承载的其他标准。例如，H·324、H．263和C．723分别是压缩音频流和视频流的最新标准。2024/4/1710Internet多媒体协议RTP复用操作

RTP复用功能由目标传输地址（SOCKET）提供。复用分组格式除了时间戳、标记位和SSRC之外，RTP首部的其他字段都保持原有定义。复用分组的格式如图所示。●载荷类型：负载类型字段标识此RTP分组为复用分组。●时间戳：该协议要求分组中所有复用流必须具有相同的时钟频率(例如，音频的采样频率)，而且按照一定时间间隔产生媒体帧，该时间间隔是一个公共的帧持续时间的整数倍。●标记位：复用操作没有使用此字段，它的值设置为0。复用首部中为每个用户都包含一个标记位。●SSRC：此字段用于标识特定的用户组(而不是单个用户)，这些用户的帧是同步的。复用(MUX)首部包含参与复用操作的所有用户的信息。它还包含载荷类型的信息以及用于每个用户载荷的标识值。2024/4/1711Internet多媒体协议负责管理发送应用和接收应用的实时会话。该协议支持发送者向接收者通报后者应该接收到的RTP数据，它还支持接收者直接向发送者报告。这种思想在IP组播中非常有效，因为它可以检查分组分发中的故障。发送者和接收者报告可能占用大量的带宽，RTCP提供了一种定义这些报告发送频率的机制。其思想是无论多少用户参与会话，会话的总体数据流保持恒定。所有RTCP分组的源端都发送源说明，描述发送数据的那些应用的特征。这些报文包含一些定义属性的源说明项，例如电子邮件地址、地理位置、电话号码和邮箱地址。会议(视频或音频)的参与者可以在任何时间通过发送一个称为“bye”的注销报文而退出会议。RTCP报文可以针对特定应用进行编码。RTCP并不关心报文的内容，RTCP操作在应用间透明地传输报文。RTCP2024/4/1712Internet多媒体协议RTCP分组有五种分组类型：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)／162024/4/1713Internet多媒体协议源描述分组(SDES)RTCP支持数据源提供更多的关于自己的信息。此操作通过发送RTP源描述分组(SDES)(如图P185)实现。该PDU包括源同步标识或参与源标识(SSRC或CCRC)以及SDES项。图P186列出了目前定义的源描述项。如表所示，这些项只是提供了更多关于源的信息。它们的使用方法由具体实现确定，RFCl889和RFCl996对这个课题有更多的讨论。2024/4/1714Internet多媒体协议RSVP协议简介：资源预约协议(RSVP)为实时多媒体会议定义了一种预约操作。RSVP与目前使用诸如ATM、帧中继以及X．25等技术的系统不同，它是由数据的接收方进行预约。与此形成对照的是，其他技术支持数据发送方创建需求。原理：数据接收方最了解自己的能力和限制。例如，视频服务器正以很高的比特率向接收方发送数据，比如高质量视频的速率是100Mb／s。但是，各接收者(客户)接收高质量传输的能力不同。因此，它们可以向服务器发送自己的资源预约请求，从而定义不同的吞吐量要求。例如，一个通过OC-3线路卡与ATM网络相连的设备，连接在以太网上的个人电脑可能无法支持全部100MB的传输带宽。因此，这2个设备可以向服务器发送预约请求，注明自己的能力(可用带宽)。2024/4/1715Internet多媒体协议RSVP使用流的概念表示预约的数据流量。流与帧中继及ATM中的面向连接的虚拟电路有些相似。它们标识了从发送端应用到达接收端应用的数据流。此概念与IPv6的流标识字段配合得非常好。该字段(连同源地址)将惟一地确定每一个流。流和流标识的概念主要用于区分网络中不同类型的数据，然后根据各自的定时和同步要求区别对待。实际上，流标识最可能用于将数据放在中间交换机(位于服务器和客户之间)的不同队列上。RSVP2024/4/1716Internet多媒体协议RSVP路径操作：RSVP不提供路由功能，而是利用IPv4或IPv6的转发功能，这正如网际控制报文协议(ICMP)和Intemet组管理协议(IGMP)一样。RSVP支持单播和组播，而且可以支持当前和以后可能出现的组播协议。与IP类似，它根据路由表计算报文的路径。它利用IGMP加入组播组，然后为该组播组预约资源。RSVP要求数据接收方提出流的Oos要求。接收方应用必须计算QOS需求，然后传递给RSVP。在分析请求之后，RSVP向数据流经过的所有节点发送请求报文。如图P187所示，服务器(流发送者)利用路径报文为会话建立路径。2024/4/1717Internet多媒体协议预约操作：由流的接收方发出的预约报文，支持发送方和中间路由器获得接收方的请求。见P187预约报文：见P188所有RSVP报文由相同的首部和报文体组成。RSVP对象（报文中信息按对象编码）RSVP报文功能：

本节简要介绍RSVP报文的功能，算是对前面关于RSVP的讨论的总结。关于更详细的信息可以参考RFC2205。路径报文针对自己创建的每个数据流，发送方都定期地发送路径报文。该报文中包括一个定义数据分组格式的SENDER—TEMPLATE对象和描述流特征的SENDER—TSPEC对象。另外，它还可能包括一个存储该流的广播信息的ADSPEC对象。2024/4/1718Internet多媒体协议预约报文(Resv)预约报文携带预约请求，它沿着与此会话的数据流相反的方向从接收方逐跳传输到发送方。预约报文的IP目的地址是从路径状态中获得的前一跳的单播地址，而源地址是发送此报文的节点的地址。此报文中的RESV_CONFIRM对象表示需要预约确认，而且其中携带了接收预约确认报文的IP地址。该报文还可以包含若干POLICY_DATA对象。

路径拆除报文收到路径拆除报文后将会删除匹配的路径状态。所谓匹配必须与SES-SION、SENDER_TEMPLATE和PHOP对象匹配。另外，针对组播会话的路径拆除报文只能与该报文到达的接收接口上路径信息匹配。如果不存在匹配的路径状态，则应该将路径拆除报文丢弃并不再转发。

路