《精编》Internet多媒体协议培训资料

《《精编》Internet多媒体协议培训资料》由会员分享，可在线阅读，更多相关《《精编》Internet多媒体协议培训资料（21页珍藏版）》请在金锄头文库上搜索。

1、第十章Internet多媒体协议 概述本章主要介绍下列支持多媒体传输的协议 IGMPMBONERTPRTCPRSVP 有关概念RTP会话 利用RTP进行通信的各方之间的映射关系 对于参与通信的每台主机 会话由一对特定的目标传输地址 网络地址加上RTP端口和RTCP端口 定义 在多媒体会话中 每种媒体都由一个单独的RTP会话传输 使用单独的RTCP分组 这些RTP会话通过不同的端口对和 或不同的组播地址加以区别 同步源 SynchronizationSource SSRC RTP分组流的源点 SSRC标识符包含在RTP首部中 从特定同步源发出的所有分组组成同一定时和序号空间的一部分 所以接收端可

2、以根据同步源将收到的分组进行分类 从而在本地重放 参与源 ContributingSource CSRC 特定RTP分组流的源点 该流将作为RTP混合器的输入之一 混合器将在形成的分组的RTP首部中插入与该分组源点相应的一组SSRC标识 混合器 Mixer 从若干数据源接收RTP分组的中间系统 该系统可能修改数据格式 按特定方式组合分组 然后创建新的RTP分组 由于各输入源点的定时可能不同步 混和器将会调整各输人流的定时 然后为组合流创建自己的定时 所有由混合器创建的数据分组的同步源就是该混合器 翻译器 Translator 在转发RTP分组时保持分组的同步源标识不变的中间系统 翻译器的实例包

3、括 在不进行混合操作的同时转换编码的设备 将组播转换为单播的中继器以及防火墙中的应用级过滤器 监视器 Monitor 接收RTP会话参与者发送的RTP分组的应用程序 它以分布监视 故障侦测和长期统计为目标对当前服务质量进行估算 IP组播IP组播系统 一对多 数据分组只创建一次 然后被组播服务器 ROUTER 复制多份 发往服务器的输出端口并分发给相连的所有接收端 主要应用 音频会议和视频会议 远程教育 会议和白板交谈等 地址格式 1110 组播地址 28 从224 0 0 0到239 255 255 255组播方式 组播遂道 组播数据封装在IP数据报字段中传输 在INTERNET中的转发过程依

4、传统的IP首部 路由器上运行组播软件 IGMP操作IGMP支持组播操作 它允许一主机加入组 路由器知道组的信息 先向主机发送IGMP查询 IGMP报告操作允许主机通知ROUTER它是否希望加入特定的组播组 当一台主机欲加入某个多播组时 会发出 主机成员报告 的IGMP消息通知多播路由器 当多播路由器接收到发给那个多播组的数据时 便会将其转发给所有的多播主机 多播路由器还会周期性地发出 主机成员查询 的IGMP消息 向子网查询多播主机 若发现某个多播组已没有任何成员 则停止转发该多播组的数据 此外 当支持IGMPv2的主机 如Windows98 2000计算机 退出某个多播组时 还会向路由器发送

5、一条 离开组 的IGMP消息 以通知路由器停止转发该多播组的数据 但只有当子网上所有主机都退出某个多播组时 路由器才会停止向该子网转发该多播组的数据 MBONE MulticastBackbone的缩写 一种高速虚拟网络 它可以将信息包同时发送到多个Internet站点 适用于音频 视频的传输 1992年 MBONE在IETF Internet工程工作组 的Audiocast试验中 把IETF的会议内容通过声音 图像进行实时传播 MBONE已成为Internet的一部分 是支持广播式传输的关键部件 最初连入了4个国家的40个子网 截至1996年4月 MBONE的规模已经遍及25个国家的2800

6、多个子网 在MBONE上的著名Multicast服务有NASAspaceshuttlemissions U S HouseandSenatesessions livesatelliteweatherphotos等等 新的应用与服务的出现 使得InternetMulticasting技术得到了迅速的发展 实时协议 RTP 用于支持实时数据流 典型的实时应用是语音和视频系统 RTP为具有实时特征的数据 提供了端到端的传输服务 服务包括负载类型标识 定序 时间戳和传输监视 应用通常在UDP协议之上运行RTP 如果底层网络支持组播 那么RTP还支持到组播地址的数据传输 它依靠底层服务提供保证及时传输或

7、保证其他服务质量 RTP不能防止传输过程出现的丢包和乱序现象 而且它也不要求底层网络是可靠的或按顺序传输分组 RTP代表了一种新型的协议 RTP将提供特定应用所需的信息 而且通常与应用处理集成在一起 而不是作为单独的协议层实现 RTP是通过修改和 或增加首部来实现新功能的 实时协议RTP 翻译器和混合器RTP翻译器将负载从一种语法转换 编码 为另一种语法 翻译器的任务是接收工作站的数据流 将其转换 编码 为以下格式 1 符合传输网络的带宽限制 和 或 2 符合另一边的用户工作站的带宽限制 RTP混合器将多个源组合为一个流 通常 混合器主要执行音频操作 不会降低接收方收到的信号质量 它只是将各信

8、号组合为一种统一的格式 RTP混合器特别适用于音频会议 一般来说它不太适合做视频会议 因为将多个视频源组合成一种格式比较困难 RTP混合器并不是将每种源负载转换为一种不同的格式 它在保留原来格式的基础上将不同源负载组合为一个流 而另一方面 如果视频流是简单的脉冲代码调制 PCM 的流 则可以将各源负载的值加起来 从而将它们组合为单一的流 RTP报文都使用同一种格式 RTP支持应用层成帧 如G 722 JPEG视频标准 RTP协议数据单元 PDU 封装在用户UDP和IP PDU 中传输 RTP无默认的UDP端口 由于主机在各种不同的应用中都要利用RTP 给一默认口不够 但是当应用没有其他可用的端

9、口时 RTP将5004端口作为指定端口 RTP规范要求不管选取哪个端口其值必须是偶数 这是由于比RTP端口值只大1的端口 对于指定端口为5005 被用于传送实时控制协议RTCP的业务量的缘故 格式见图P179 RTP报文 RTP报文同步源ID是RTP报文的最初发送者的标识 该发送者负责计算报文的序列号和时间戳 RTP翻译器保留该标识 但RTP混合器将成为新的同步源 而其他 最初的 源将成为参与源 这些参与源记录在报文的参与源ID字段中 通信双方利用序列号和时间戳达到下列目的 1 确定数据按正确j顷序到达 2 检查丢包现象 3 同步数据流 值得注意的是 RTP并没有定义应用数据字段的格式 而是交

10、给应用完成 因此 RTP可以携带各种类型的应用数据 P180页列出了RTPPDU数据字段可以携带的各种载荷类型 该表公布以后 业界又定义了可由RTP承载的其他标准 例如 H 324 H 263和C 723分别是压缩音频流和视频流的最新标准 RTP复用操作RTP复用功能由目标传输地址 SOCKET 提供 复用分组格式除了时间戳 标记位和SSRC之外 RTP首部的其他字段都保持原有定义 复用分组的格式如图所示 载荷类型 负载类型字段标识此RTP分组为复用分组 时间戳 该协议要求分组中所有复用流必须具有相同的时钟频率 例如 音频的采样频率 而且按照一定时间间隔产生媒体帧 该时间间隔是一个公共的帧持续

11、时间的整数倍 标记位 复用操作没有使用此字段 它的值设置为0 复用首部中为每个用户都包含一个标记位 SSRC 此字段用于标识特定的用户组 而不是单个用户 这些用户的帧是同步的 复用 MUX 首部包含参与复用操作的所有用户的信息 它还包含载荷类型的信息以及用于每个用户载荷的标识值 负责管理发送应用和接收应用的实时会话 该协议支持发送者向接收者通报后者应该接收到的RTP数据 它还支持接收者直接向发送者报告 这种思想在IP组播中非常有效 因为它可以检查分组分发中的故障 发送者和接收者报告可能占用大量的带宽 RTCP提供了一种定义这些报告发送频率的机制 其思想是无论多少用户参与会话 会话的总体数据流保

12、持恒定 所有RTCP分组的源端都发送源说明 描述发送数据的那些应用的特征 这些报文包含一些定义属性的源说明项 例如电子邮件地址 地理位置 电话号码和邮箱地址 会议 视频或音频 的参与者可以在任何时间通过发送一个称为 bye 的注销报文而退出会议 RTCP报文可以针对特定应用进行编码 RTCP并不关心报文的内容 RTCP操作在应用间透明地传输报文 RTCP RTCP分组有五种分组类型 200 204会话的发送者每隔一段时间向接收者发送者报告 各字段内容见P184RTCP报文格式 抖动方程 到达时间间隔抖动是两个分组的相对传输时间的差异 它是分组的RTP时间戳和分组到达时接收者时钟之间的差 如下面

13、的方程所示 它等于两个分组的 相对传输时间 之差 相对传输时间是分组的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 16 源描述分组 SDES RTCP支持数据源提供更多的关于自己的信息 此操作通过发送RTP源描述分组 SDES

14、 如图P185 实现 该PDU包括源同步标识或参与源标识 SSRC或CCRC 以及SDES项 图P186列出了目前定义的源描述项 如表所示 这些项只是提供了更多关于源的信息 它们的使用方法由具体实现确定 RFCl889和RFCl996对这个课题有更多的讨论 RSVP 协议简介 资源预约协议 RSVP 为实时多媒体会议定义了一种预约操作 RSVP与目前使用诸如ATM 帧中继以及X 25等技术的系统不同 它是由数据的接收方进行预约 与此形成对照的是 其他技术支持数据发送方创建需求 原理 数据接收方最了解自己的能力和限制 例如 视频服务器正以很高的比特率向接收方发送数据 比如高质量视频的速率是100

15、Mb s 但是 各接收者 客户 接收高质量传输的能力不同 因此 它们可以向服务器发送自己的资源预约请求 从而定义不同的吞吐量要求 例如 一个通过OC 3线路卡与ATM网络相连的设备 连接在以太网上的个人电脑可能无法支持全部100MB的传输带宽 因此 这2个设备可以向服务器发送预约请求 注明自己的能力 可用带宽 RSVP使用流的概念表示预约的数据流量 流与帧中继及ATM中的面向连接的虚拟电路有些相似 它们标识了从发送端应用到达接收端应用的数据流 此概念与IPv6的流标识字段配合得非常好 该字段 连同源地址 将惟一地确定每一个流 流和流标识的概念主要用于区分网络中不同类型的数据 然后根据各自的定时

16、和同步要求区别对待 实际上 流标识最可能用于将数据放在中间交换机 位于服务器和客户之间 的不同队列上 RSVP RSVP 路径操作 RSVP不提供路由功能 而是利用IPv4或IPv6的转发功能 这正如网际控制报文协议 ICMP 和Intemet组管理协议 IGMP 一样 RSVP支持单播和组播 而且可以支持当前和以后可能出现的组播协议 与IP类似 它根据路由表计算报文的路径 它利用IGMP加入组播组 然后为该组播组预约资源 RSVP要求数据接收方提出流的Oos要求 接收方应用必须计算QOS需求 然后传递给RSVP 在分析请求之后 RSVP向数据流经过的所有节点发送请求报文 如图P187所示 服务器 流发送者 利用路径报文为会话建立路径 预约操作 由流的接收方发出的预约报文 支持发送方和中间路由器获得接收方的请求 见P187预约报文 见P188所有RSVP报文由相同的首部和报文体组成 RSVP对象 报文中信息按对象编码 RSVP报文功能 本节简要介绍RSVP报文的功能 算是对前面关于RSVP的讨论的总结 关于更详细的信息可以参考RFC2205 路径报文针对自己创建的每个数据流 发送方都定