《流媒体技术B》课程教学大纲

课程编号：0806602028

课程名称：流媒体技术B

英文名称：Streaming Media Technology

课程类型：专业必修课

总 学 时：32 讲课学时：22 上机学时：10

学 分：2

适用对象：计算机科学与技术专业本科生

先修课程：图象处理、多媒体技术、程序设计

一、课程性质、目的和任务

本课程是计算机专业的一门重要的专业课。本课程的教学目的是通过本课程的教学，使 学生掌握流媒体技术的基本概念、常见流媒体文件的格式、编码和压缩标准、网络传输协议、流媒体对计算机硬件和软件的需求等，并通过具体的软件工具和硬件，展现流媒体技术在不同层次和环境下的应用方案，并使学生在了解流媒体技术以及相关原理的基础上，掌握多种工具软件的使用方法和基本技巧，了解流媒体产品的市场发展方向，设计和制作过程，并具备独立设计流媒体技术初级应用方案的基本能力。

二、教学基本要求

本课程以流媒体的网络传输与控制协议,流媒体编码解码技术和流媒体的管理服务为研究对象，以流媒体的管理服务为重点。学完本课程应达到以下基本要求：了解流媒体技术的基础知识。掌握市场主流的三种流媒体技术的使用方法、文件格式和技术特点。了解数据压缩原理与相关的压缩算法。掌握流媒体数据组播传输方式的特点及技术规范。了解RTP/RTCP协议族、RSVP协议、RTSP协议的基本概念。了解同步多媒体集成语言(SMIL)的基本语法和应用。掌握流媒体服务器安装和运行的方法。掌握Windows Media Encoder的使用方法及网页嵌入式播放器的制作方法。

三、教学内容及要求

1、流媒体技术概述

了解流媒体技术的基础知识，包括相关概念、基本特征、发展历程和应用前景等。 ① 流媒体技术的起源、发展现状及面临的挑战

② 流媒体的基本概念

③ 流媒体技术的应用

2、流媒体技术的主流产品

了解已成为市场主流的三种流媒体技术，RealNetwork公司的RealMedia，Microsft的Windows Media和Apple公司的QuickTime；掌握它们的使用方法、文件格式和技术特点。 ① RealNetwork公司系列产品使用方法

② Microsoft Windows Media使用方法

③ QuickTime使用方法

3、适应流式应用的多媒体编码解码技术

掌握流媒体（声音、动态图像、视频）的数据描述格式；了解数据压缩原理与相关的压缩算法，以及常用流媒体编码解码器的工作原理及特点。

① 流媒体数据描述与压缩技术

② 流媒体编码解码器的工作原理

③ 适合网络传输的编码方案

④ 常用流媒体编码解码器介绍

4、流式文本文件的制作

了解用于处理流格式的文本标记语言——RealText；掌握流式文本的语法结构及规则。 ① RealText概述

② 流式文本文件语法规则

③ 制作流式文本文件

5、同步多媒体集成语言SMIL

了解同步多媒体集成语言（SMIL）的基本语法和应用；掌握在SMIL文件中创建链接。 ① SMIL语法规则

② 在SMIL标签中设置定时控制

③ 设置SMIL文档的窗口布局

④ 在SMIL文件中创建链接

6、流媒体的网络传输与控制协议

掌握流媒体网络传输的特征；了解RTP/RTCP协议族、RSVP协议、RTSP协议的基本概念。 ① 流媒体的网络传输特征

② RTP/RTCP协议族

③ RSVP

④ RTSP协议

7、流媒体的平台搭建

了解流媒体服务器性能特点和技术要求；掌握流媒体服务器安装和运行的方法。 ① 流媒体平台概述

② 流媒体服务器的安装和运行

8、流媒体的制作和发布

了解流媒体制作和发布的过程；掌握流媒体转换技术及网页嵌入式播放器的制作方法。 ①转换流媒体文件

②制作流媒体文件

③流媒体的多种表现方式

9、移动流媒体技术概述

了解移动通信技术；掌握移动流媒体关键技术及3G网络的视频应用；了解移动流媒体平台的实现。

① 移动通信技术概述

② 移动流媒体的关键技术

③ 3G网络的视频应用

④ 实现基于RealSystem的移动流媒体平台

四、实践环节

本课程安排的上机实验学时为10学时，课内开设5个实验，说明如下

五、课外习题及课程讨论

为达到本课程的教学基本要求，课外习题（包括自测题）不应少于100题。

六、教学方法与手段

本课程采用板书与多媒体课件结合的方式进行课堂教学。

八、考核方式

本课程为考试课程，期末考试为闭卷笔试。学生的课程总评成绩由平时成绩（占30%）和期末考试成绩两部分构成，平时成绩中实验成绩占10%，出勤、作业、课堂测验、学习主动性等占20%。

九、推荐教材和教学参考书

教 材：《流媒体技术入门与提高》，廖勇 等 编，国防工业出版社，20xx年

参考书：《流媒体和视频服务器》，钟玉琢、向哲、沈洪 编，清华大学出版社，20xx年

《流媒体宝典》，Steve Mack 编著 刑栩嘉 等 译，电子工业出版社，20xx年

十、说明

无。

大纲制订人：徐梦溪 大纲审定人：沈晨鸣

制订日期：20xx年 5月

《流媒体技术B》实验教学大纲

一、实验教学目标与基本要求

实验教学的目的是帮助学生加深对理论课内容的了解，在理解流媒体技术基本原理的基础上，掌握相关工具软件的使用方法，了解流媒体技术的实际应用方案。

要求学生能够独立运用相关技术进行流媒体的制作和发布。

二、本实验课程的基本理论与实验技术知识

随着互联网的发展，流媒体技术也趋于成熟化、商业化、它的应用也越加广泛。 本实验属技术实验课，在实验过程中，注意掌握流媒体技术的基本理论、基本知识和基本技能。为将来工作打下基础。

三、实验方法、特点与基本要求

1．基本操作技能

正确使用常见的计算机，耳机，麦克，摄像机等多媒体工具，训练学生基本的实验技能，掌握基本的流媒体应用技术、试验方法及数据分析处理。验证所学的科学知识、加深和巩固对所学知识的认识和了解。

2．设计性实验

在已具备实验技能的前提下，根据搭建好的流媒体服务器的情况，完成一个使用JavaScript控制Windows Media或RealMedia播放器的设计。由学生自己根据实验室现有设备确定实验方案，设计实验路线，选择实验方法和步骤，提出实验预案，经指导老师同意后，独立操作完成设计性实验，写出实验报告。

设计性实验主要培养学生查阅文献、确定实验方法、配置设备运行环境等方面的能力。

四、实验主要仪器设备

计算机，耳机，麦克，摄像机。

五、实验项目的设置与内容提要

注：总实验学时为 10 学时

六、实验报告要求

每次实验提交实验报告。实验报告由实验原理、实验内容及数据的记录及处理组成，并附有实验原始记录。

七、考核方式与成绩评定标准

实验成绩：预习10%、操作40%、报告40%、原始记录10%

八、教材及主要参考资料

教 材：《流媒体技术入门与提高》，廖勇编，国防工业出版社，2005

参考书：《流媒体和视频服务器》，钟玉琢编，清华大学出版社，2003

《流媒体技术与应用完全手册》，肖磊 等编著，清华大学出版社，2003

《流媒体宝典》，Steve Mack 编著 刑栩嘉 等译，电子工业出版社，2003

九、其他说明

无

大纲制订人：徐梦溪

大纲审定人：沈晨鸣

制订日期：20xx年5月

 

第二篇：流媒体传输协议

实时多媒体数据流的传输协议

10180001 常明贤   10180018 屈宏伟

随着Internet的迅速发展，通过网络传输多媒体信息的条件已经成熟，海量多媒体数据传输成为亟待解决的问题之一。流媒体(即实时多媒体数据流)在海量多媒体数据传输中脱颖而出，已成为研究的热点。而流媒体实现的关键技术就是流式传输。

　　流式传输是与下载相对应的在网络上传A/V（audio/video）等多媒体信息方案。A/V（audio/video）文件一般都较大，所以需要的存储容量也较大；同时由于网络带宽的限制，下载需要很长的时间开消，并有很大延迟。采用流式传输时，声音、影像或动画等时基媒体由音视频服务器向用户计算机的连续、 实时传送，用户不必等到整个文件全部下载完毕，而只需经过几秒或十数秒的启动延时即可进行观看，避免了用户必须等待整个文件全部从Internet上下载才能观看的缺点。当声音等时基媒体在客户机上播放时，文件的剩余部分将在后台从服务器内继续下载。

实现流式传输有两种方法：顺序流式传输（progressive streaming）和实时流式传输（Real Time Streaming）。而这两种传输方法所应用的协议不同。

1.顺序流式传输

顺序流式传输就是在下载文件的同时可观看在线媒体，在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的前头部分。如使用HTTP服务器，文件即通过顺序流发送。由于标准的HTTP服务器可发送这种形式的文件，也不需要其他特殊协议，它经常被称作HTTP流式传输。顺序流式文件是放在标准HTTP 或 FTP服务器上，易于管理，基本上与防火墙无关。

2.实时流式传输

实时流式传输指保证媒体信号带宽与网络连接匹配，使媒体可被实时观看到。实时流与HTTP流式传输不同，他需要专用的流媒体服务器、传输协议和特殊网络协议。这些协议在有防火墙时有时会出现问题，导致用户不能看到一些地点的实时内容。

支持流媒体传输有如下网络协议：

实时传输协议RTP（Real-Time Transport Protocol）

RTP是在Internet上针对多媒体数据流在一对一或一对多的传输情况下工作时的一种传输协议。其目的是提供时间信息和实现流同步。RTP通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。

1.RTP数据传输协议

　RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立传输和网络层。

RTP 头格式如下：

开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。

2.复用 RTP 连接

　 为使协议有效运行，复用点数应减至最小。RTP中，复用由定义RTP连接的目的传输地址（网络地址与端口号）提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不在将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。使用同一SSRC ，而具有不同载荷类型的交叉包将带来几个问题：

　 如一种载荷类型在连接期间切换，没有办法识别新值将替换哪个旧值。

SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明那种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。RTP混合器不能将不兼容媒体流合并成一个流。

　 在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配；接受媒介子集。对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。

3.对RTP头特定设置的修改

　可以认为，现用RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位之间的关系，我们就可以定位八进制中最重要的位。

　其它特殊载荷格式（视频编码）所要求的信息应该携带在包的载荷部分。可出现在头，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制处理RTP包。如证实附加功能是所有设置共同需要的，新版本RTP应该对固定头做出明确改变。

实时传输控制协议RTCP(Real－Time Transport Control Protocol)

RTCP和RTP一起提供流量控制和拥塞控制服务。在RTP会话期间，RTCP应用与数据包相同的分布机制，将控制包周期发送给所有连接者。低层协议提供数据与控制包的复用，如使用单独的UDP端口号。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。

1.RTCP执行下列四大功能：

　  提供数据发布的质量反馈。是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP组播经验表明，从发送者收到反馈对诊断发送错误是至关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。诸如IP组播等发布机制使网络服务提供商团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。

　  RTCP带有称作规范名字（CNAME）的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME 与相关RTP连接中给定的几个数据流联系

　  前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。让每个参加者给其它参加者发送控制包，就大独立观察参加者数量。该数量用语计算包发送的速率。

　  第四个可选功能是传送最小连接控制信息，如参加者辨识。最可能用在"松散控制"连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。高级连接控制协议超出本书范围。

2.RTCP 包类型及其工作方式

　RTCP包主要有如下类型，每种包携带不同的控制信息：

（1）SR：发送报告，当前活动发送者发送、接收统计。

（2）RR：接收报告，非活动发送者接收统计。

（3）SDES：源描述RTCP包，包括CNAME。

（4）BYE：断开RTCP包，表示结束。

　 如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如："camera malfunction"或"RTP loop detected"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。

（5）APP：应用特定函数。定义应用的RTCP包。

　 APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。

　 类似于RTP数据包，每个RTCP包以固定部分开始，紧接着的是可变长结构元素，但以一个32位边界结束。包含安排要求和固定部分中长度段，使RTCP包可堆叠。不需要插入任何分隔符将多个RTCP包连接起来形成一个RTCP组合包，以低层协议用单一包发送出去。由于需要低层协议提供整体长度来决定组合包的结尾，在组合包中没有单个RTCP包显式地计数。

　 组合包中每个RTCP包可独立处理，不需要根据包组合顺序。但未了执行协议功能，强加如下约束：

　 接收统计（在SR或RR中）应该经常发送，只要带宽允许，因此每个周期发送的组合RTCP 包应包含报告包。

　 新接收者需要接收CNAME，并尽快识别源，开始联系媒介进行同步，因此每个包应该包含SDES CNAME。

　 出现在组合包前面的是包类型数量，其增长应该受到限制，以提高常数位数量，提高成功确认RTCP包对错误地址RTP数据包或其他无关包的概率。

　 因此，所有RTCP包至少必须以两个包组合形式发送，推荐格式如下：

　 加密前缀（Encryption prefix）：仅当组合包被加密时，才加上一个32位随机数用于每个组合包发送。

　 SR或RR：组合包中第一个RTCP包必须总为一个报告包，方便了头的确认。即使没有数据发送，也没有接收到数据，也要发送一个空RR，那怕组合包中RTCP包为BYE。

　 附加RR：如报告统计源数目超过31，在初始报告包后应该有附加RR 包。

　 SDES：包含CNAME 项的SDES包必须包含在每个组合RTCP包中。如应用要求，其它源描述项可选，但受到带宽限制。

　 BYE或APP：其它RTCP包类型可以任意顺序排列，除了BYE应作为最后一个包发送，包类型出现可不止一次。

建议转换器或混合器从多个源组合单个RTCP包。如组合包整体长度超过网络路径最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。注意，每个组合包必须以SR或RR包开始。附加RTCP包类型可在Internet Assigned Numbers Authority (IANA)处注册。

3.RTCP传输间隔

　 RTP设计成允许应用自动扩展，连接数可从几个到上千个。例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立于连接数，但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。

　 一旦确认地址有效，如后来标记成未活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。

　 这个规范定义了除必需的CNAME外的几个源描述项，如NAME（人名）和EMAIL（电子邮件地址）。这也是定义新地特定应用RTCP包类型的途径。给附加信息分配控制带宽应引起注意，因为它将降低接收报告和CNAME发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20%。而且并没有有意让所有SDES项包含在每个应用中。

4.RTP与RTCP协同工作

　 RTP接收者使用RTCP报告包提供接收质量反馈，报告包根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收者报告间唯一的差别是发送者报告包含一个20个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR；SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR 或 RR包中，丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失绿可通过NTP时标差除以丢失部分得到。

　从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。

实时流协议RTSP(Real Time Streaming Protocol)

　实时流协议RTSP(Real Time Streaming Protocol)是由Real Networks和Netscape共同提出，定义了一对多应用程序如何有效地通过IP网络传送多媒体数据，控制实时数据的发送的应用级协议。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。

RTSP建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交叉是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出RTSP 请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。RTSP没有绑定到RTP，而是假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。

1.RTSP状态

　 RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：

　 SETUP：让服务器给流分配资源，启动RTSP连接。

　 PLAY与RECORD：启动SETUP 分配流的数据传输。

　 PAUSE：临时停止流，而不释放服务器资源。

　 TEARDOWN：释放流的资源，RTSP连接停止。

　 标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连接产生连接标识。

2.与HTTP协议的关系

　 RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户不全依靠HTTP。

　 但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器做出响应，传送HTML。RTSP中，媒体用户和服务器都可发出请求，即RTSP可以是双向的，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流，传送的是多媒体数据。重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。RTSP在语法和操作上与HTTP/1.1类似，HTTP的扩展机制大都可加入RTSP。

3.RTSP 信息

　 RTSP是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。10646字符集避免敏感字符集切换，但对应用来说不可见。RTSP信息可通过任何低层传输协议携带。

　 请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：　 不管实体头段是否出现在信息中，不包括信息体的的响应信息总以头段后第一和空行结束。　 如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。服务器关闭连接。

　 注意：RTSP目前并不支持HTTP/1.1"块"传输编码，需要有内容长度头。假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。

4.RTSP发送请求

从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，而没有定义任何HTTP代码。

如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和试题体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。

实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。

RTSP请求可以几种不同方式传送：

1、  持久传输连接，用于多个请求/响应传输。

2、  每个请求/响应传输一个连接。

3、  无连接模式。

　 传输连接类型由RTSP URI来定义。对 "rtsp" 方案，需要持续连接；而"rtspu"方案，调用RTSP 请求发送，而不用建立连接。

支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出响应。如果请求不是发送给组播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间（RTT）后重发同一信息。

　 RTT在TCP中估计，初始值为500 ms。应用缓存最后所测量的RTT，作为将来连接的初始值。如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。如两个低层可靠传输（如TCP 和RTSP）应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收着者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加一。如由于没有确认而重发请求，请求必须携带初始系列号。

　 实现RTSP的系统必须支持通过TCP传输RTSP ，并支持UDP。对UDP和TCP，RTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与RTP和RTCP包交叉。不象HTTP，RTSP信息必须包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头。RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。

5.方法定义

 方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。　 某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和服务器操作复杂，并强加附加开销，除非有必要，应避免这样做。插入二进制数据仅在RTSP通过TCP传输时才可使用。流数据（如RTP包）用一个ASCII的$封装，后跟一个一字节通道标识，其后是封装二进制数据的长度，两字节整数。流数据紧跟其后，没有CRLF，但包括高层协议头。每个块包含一个高层协议数据单元。

  当传输选择为RTP，RTCP信息也被服务器通过TCP连接插入。缺省情况下，RTCP包在比RTP通道高的第一个可用通道上发送。客户端可能在另一通道显式请求RTCP包 ，这可通过指定传输头插入参数中的两个通道来做到。当两个或更多流交叉时，为取得同步，需要RTCP。而且，这为当网络设置需要通过TCP控制连接透过RTP/RTCP提供了一条方便的途径，可能时在UDP上进行传输。

6.协议特点

（1）可扩展性：新方法和参数很容易加入RTSP。

由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP 可以如下三种方式扩展，这里以改变大小排序：

以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。

加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支持的方法。

定义新版本协议，允许改变所有部分。（除了协议版本号位置）

（2）易解析：RTSP可由标准 HTTP或MIME解吸器解析。

（3）安全：RTSP使用网页安全机制。

（4）独立于传输：RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。

多服务器支持：每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。

（5）记录设备控制：协议可控制记录和回放设备。

（6）流控与会议开始分离： 仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下， SIP或H.323 可用来邀请服务器入会。

（7）适合专业应用：通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。

演示描述中立：协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个RTSP URI。

（8）代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个"缺口"。

（9）HTTP友好：此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法。

（10）适当的服务器控制：如用户启动一个流，他必须也可以停止一个流。

（11）传输协调：实际处理连续媒体流前，用户可协调传输方法。

（12）性能协调：如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。

资源预订协议RSVP (Resource Reserve Protocol)

RSVP是正在开发的网络控制协议，它使Internet应用传输数据流时预留一部分网络资源（即带宽），能在一定程度上获得特殊服务质量（QoSs）；RSVP是非路由协议，它同路由协议协同工作。RSVP的组成元素有发送者、接收者和主机或路由器。发送者负责让接收者知道数据将要发送，以及需要什么样的QoS；接收者负责发送一个通知到主机或路由器，这样他们就可以准备接收即将到来的数据；主机或路由器负责留出所有合适的资源，建立与路由协议计算出路由等价的动态访问列表。RSVP运行在OSI 七层协议中传输层。

RSVP协议的两个重要概念是流与预定。流是从发送者到一个或多个接收者的连接特征，通过IP包中"流标记"来认证。发送一个流前，发送者传输一个路径信息到目的接收方，这个信息包括源IP地址、目的IP地址和一个流规格。这个流规格是由流的速率和延迟组成的，这是流的QoS需要的。接收者实现预定后，基于接收者的模式能够实现一种分布式解决方案。　

　

　 图 RSVP中主机信息通过数据流发送给接收者示意图

1.       RSVP数据流

　 在RSVP中，数据流是一系列信息，有着相同的源、目的（可有多个）和QoS，要求通过网络以流说明形式通讯。流说明是互连网主机用来请求特殊服务的数据结构，保证互连网处理主机传输。RSVP支持三种传输类型：最好性能（best-effort），速率敏感（rate-sensitive）与延迟敏感（delay-sensitive）。用来支持这些传输类型的数据流服务依赖QoS实施，以下部分陈述传输类型与相关服务。

　 最好性能传输为传统IP传输。应用包括文件传输（如邮件传输）、磁盘映像、交互登录和事务传输。支持最好性能传输的服务称为最好性能服务。速率敏感传输放弃及时性，而确保速率。例如：速率敏感传输请求100 kbps带宽，如在扩展期实际发送200 kbps，路由器可能延迟传输。速率敏感传输目的不在通过电路交换网络传输，但它通常与电路交换网络（ISDN）应用有联系，现在正运行在数据报网络（IP）上。这类应用如H.323视频会议，设计运行在ISDN （H.320）或ATM（H.310）上，但发现在Internet上也有应用。H.323编码是常数速率或准常数速率，它需要常数传输速率。RSVP服务支持速率敏感传输，称为位速率保证服务。延迟敏感传输要求传输及时，并因而改变其速率。例如：MPEG-II视频根据图象改变量大小平均流量为3 到7 Mbps，3 Mbps可能对应一堵上色的墙，而7 Mbps 可能是海洋的波浪。MPEG-II视频源发送关键和增量帧。典型的，每秒一个或两个关键帧，描述整个图象，而每秒13或28帧描述关键帧之间的变化，增量帧通常比关键帧小。因此，帧与帧之间速率变化较大。但由于单个帧要求在一帧时间内发送出去，或解码器速度跟不上，必须对增量帧传输进行特定优先级别协调。RSVP服务支持延迟敏感传输，被看作控制延迟服务（非实时服务）与预报服务（实时服务）。

2.RSVP 数据流处理

　 RSVP数据流基本特征是连接，数据包在其上流通。连接是具有相同单播或组播目的数据流，RSVP分别处理每个连接。RSVP支持单播和组播连接（这里连接是一些发送者与另一些接收者的会话），而流总是从发送者开始的。特定连接的数据包被导向同一个IP目的地址或公开的目的端口。IP目的地址可能是组播发送的组地址，也可能是单个接收者的单播地址。公开目的端口可用UDP/TCP目的端口段、另外传输协议等价段或某些应用特定信息定义。

　 RSVP数据发布是通过组播或单播实现的。组播传输将某个发送者的每个数据包拷贝转发给多个目的。单播传输特征是只有一个接收者。即使目的地址是单播，也可能有多个接收者，以公开端口区分。多个发送者也可能存在单播地址，在这种情况下，RSVP可建立多对一传输的资源预订。每个RSVP发送者和接收者对应唯一的Internet主机。然而，单个主机可包括多个发送者和接收者，以公开端口区分。

3.RSVP服务质量(QoS)

　 在RSVP中，服务质量（QoS）是流规范指定的属性，流规范用于决定参加实体（路由器、接收者和发送者）进行数据交换的方式。主机和路由器使用RSVP指定QoS；其中主机代表应用数据流使用RSVP从网络申请QoS级别，而路由器使用RSVP发送QoS请求给数据流路经的其它路由器。这样做，RSVP就可维持路由器和主机状态来提供所请求的服务。

4.RSVP连接启动

　 为了初始化RSVP组播连接，接收者首先使用Internet组成员协议（IGMP）加入IP目的地址指定的组播组。对单播连接，单播路由就象IGMP结合协议无关组播（PIM）在组播时的作用。接收者加入组后，潜在的发送者就开始发送RSVP路径信息给IP目的地址。接收者应用收到路径信息，开始发送相应资源预订请求信息，使用RSVP指定欲点播的流描述。发送者应用接收到资源预订请求信息后，发送者开始发送数据包。

5.RSVP资源预订类型

　 资源预订类型指一套指定所支持参数的控制选项。RSVP支持两种主要资源预订：独占资源预订和共享资源预订。独占资源预订为每个连接中每个相关发送者安装一个流；而共享资源预订由互不相关的发送者使用。表3.10说明这两种资源预订协议的应用范围及所支持的范围与类型的组合情况。

6.RSVP软状态实现

　 对RSVP，软状态指可被某些RSVP信息更新的路由器和终端结点的状态。软状态特征允许RSVP网络支持动态组成员变化，并适应路由变化。一般说来，软状态由基于RSVP网络维护，使网络可在没有查询终端结点的情况下改变状态。对比电路交换结构，终端结点进行依次呼叫，如失败，进行依次新呼叫。

　 RSVP协议为创建和维护组播和单播混合发送路径的分布式资源预订状态提供了一个通用功能。为维护资源预订状态，RSVP跟踪路由器和主机结点的软状态。路径与资源预订请求信息创建并周期更新RSVP软状态。如在清除时间间隔到期前没有收到相应更新信息，就删除该状态，显式teardown 信息也可删除软状态。RSVP周期扫描欲建立的软状态，并转发路径与预订请求更新信息给下一条。

　 当路由改变，下一个路径信息初始化新路由的路径状态，将来资源预订请求信息建立资源预订状态。现在未使用的网段状态标记为超时。（RSVP规范要求在拓扑改变后两秒通过网络初始化新资源预订）。当发生状态变化，RSVP无延迟的将变化从RSVP网络的一个终端传到另一个终端。如接收到的状态与存储状态不同，就更新存储状态。如结果改变了欲产生的更新信息，更新信息立即生成并转发出去。

7.RSVP 操作模型

　 在RSVP下，资源为简单数据流（单向数据流）预订起来。每个发送者逻辑上与接收者不同，但任何应用都可充当发送者和接收者，接收者负责请求资源预订。图3.5说明了其基本操作环境，紧接部分将提供特定事件序列的框架。

　 　 图 RSVP 操作环境：为单向数据流预订资源

8.基本RSVP协议操作

　 RSVP资源预订处理初始化开始于RSVP 后台服务查询本地路由协议以获得路由。主机发送IGMP消息加入组播组，而发送RSVP消息预订沿组路径的资源。每个能加入资源预订的路由器将收到的数据包传递给包分类器，然后将它们在包调度器中排队。RSVP包分类器决定每个包的路由和QoS类；RSVP调度器给每个接口所使用的特殊数据链路层媒介上传输分配资源。如数据链路层媒介有自身的QoS管理能力，包调度器负责协调数据链路层，获得RSVP所请求的QoS。调度器本身分配无源QoS媒介上包传输能力，如双铰线；也可分配其它系统资源，如CPU时间与缓存。QoS请求一般发源于接收者主机应用，而被传递到本地RSVP应用，如RSVP 后台服务。RSVP协议接着将对所有结点（路又器与主机）的请求沿逆向数据路径传到到数据源。在每个结点处，RSVP程序应用一个称为进入允许控制的本地决定程序决定是否能提供所请求的QoS。如进入允许控制成功，RSVP程序设置包分类和调度器的参数，以获得所申请的QoS。如进入允许控制在某结点处失败，RSVP程序给产生此请求的应用返回一个错误指示。

9.RSVP 隧道

　 在整个Internet上同时配置RSVP或任意其他协议都是不可能的。实际上，RSVP决不可能在每个地方都被配置。因此，RSVP必须提供正确协议操作，即使只有两个支持RSVP的路由器与一群不支持RSVP的路由器相连。一个中等规模不支持RSVP的网络不能执行资源预订，因而服务保证也就不能实现。然而，如该网络有充足额外容量，也可以提供可接受的实时服务。

　 为了支持RSVP网络连接通过不支持RSVP的网络，RSVP支持隧道技术。隧道技术要求RSVP和非RSVP路由器用本地路由表转发到目的地址的路径信息。当路径信息通过非RSVP 网络时，路径信息拷贝携带最后一个支持RSVP的路由器的IP地址。预订请求信息转发给下一个上游支持RSVP的路由器

　 加权平均排队方案　

用技术来加强出现瓶颈处的有效资源预订（如Cisco的加权平均排队方案）有着正面影响。隧道技术仅在瓶颈出在非RSVP 域且不可避免时才有风险。图3.6表示基于RSVP网络间采用隧道技术的RSVP环境

　

　 图 ：应用隧道技术的RSVP环境

10.RSVP 消息

　 RSVP支持四种基本消息类型：资源预订请求消息、路径消息、错误与确认消息和断开消息。

11. RSVP 包格式

（1）RSVP 消息头段

　 RSVP 消息头段组成：

Bit 0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  16    

　其中更多片段标志有一个字节的最低位，其它7位预订，除消息的最后一个片段外，都将设置MF。

（2）RSVP 对象段

RSVP 对象段组成如下：

Bit 0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  16

虽然目前RSVP还没有在任何一种网络上得到证实，它的应用还只是局限在测试的小Intranet网络上。RSVP还存在诸如当一个服务请求被申请控制否决时网络应该怎样通知用户以及用户怎样应答这样的通知等问题。但是，它的应用领域的发展是非常迅速的。

结语

本人上半年参加了信息中心语音组承接的属于“九七·三”工程的远程教育项目，又幸运的参与了关于流媒体实现这一方面的工作，所以，对流媒体有着很深的感情，所以选题的时候，我一眼就看准了这个题目。

在这里我想着重说明的一点就是，在流媒体的实现中采用RTP协议，根据流媒体系统存在连续性和实时性的特点，所以在功能实现上，虽然也强调对数据对象的共享使用和追求最大化的数据吞吐率，但是更强调对高速、稳定和连续的访问流支持。所以大多数目前的大多数流媒体服务系统中服务器与客户端的双向联接都存在双通道，一个通道采用HTTP/TCP 来传输控制信息，提高信息传输的可靠性；另一个通道采用RTP/UDP来传输实时声音数据，减少系统开销，增强对同步的支持，从而确保媒体数据的按时到达。所以是流媒体传输的基础，也是其它协议的开发基础。但由于很多书籍论文中关于TCP和UDP协议的介绍都非常常见并且内容相当丰富，所以在这里，我没有详细介绍。

上述协议之间的层次关系如下图所示：

参考文献：

《网络视频流媒体技术与应用》吴国勇，邱学刚万燕子编著，北邮出版社2001－7第一版

《 流媒体技术大全》作者：张丽  中国青年出版社 20##年11月第一版

JMF 2-0  sun公司产品

《完整的Internet 多媒体解决方案》互联网影音源动力网