流媒体传输技术
完成流媒体的压缩编码以后，流媒体如何在网络上有效传输是另一个需要考虑的重要问题。
网络的环境是复杂的，Internet一直都是以“尽力而为”为目的的，在网络拥挤的情况下，没有办法保证流媒体文件的及时有效传输。虽然数据缓冲技术可以缓解数据实时传输的压力，但是单纯依靠数据缓冲技术依然无法满足顺畅欣赏网络媒体的要求。确保流媒体文件高效快速传输的技术成为迫切的需求，RTP/RTCP.RTSP和RSVP这三种协议都是为在Internet中保证流媒体高效、实时传输的技术体制。当然，网络传输技术的应用也可以大大缓解带宽的压力，特别是对于高清晰度直播电视的需求。因为大家看直播电视的时间往往会比较长，持续的带宽要求比较高，同时电视的观看具有高峰性，高峰期对于带宽的压力会更大，组播技术的应用刚好可以很好地解决这个问题。
一、RTP/RTCP简介
RTP是一种传输协议，主要针对Internet上的多媒体数据流，它不涉及资源预留和质量保证等实时服务，RTCP扩充数据传输已允许监控数据传送，提供最小的控制和识别功能。因此，RTCP和RTP一起提供流量控制和拥塞控制服务。
RTP工作模式是一对一或一对多的传输，其目的是提供时间信息，实现流同步。当应用程序开始一个RTP会话时，将使用两个端口，一个给RTP,一个给RTCPoRTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。在RTP会话期间，各参与者周期RTCP包中含有已发送的数据包的流量和丢失的数据包的数量服务器可以利用这些信息动态地改变传输速率，甚至改变有RTP算法并不作为一个独立的网络层来实现，而是作为应用它与RTCP一起设计成独立传输和网络层，配合使用，能以有效的反馈和最小的开销使传输效率最佳化，因而，特别适合传送网上的实时数据。
1.RTP数据传输协议
RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。RTP通常使用UDP（User Datagram Protocol,用户数据包协议）来传送数据，但也可以在TCP（Transfer Control Protocol,传输控制协议）或ATM（Asynchronous Transfer Mode.异步传输模式）等其他协议之上工作。RTP包包含一个载荷、一个RTP包头和一个IP包头。RTP具体内容在RFC1889中有详细的描述。下面介绍一下RTP协议的一些简单信息。
（1）RTP包头
RTP包头格式如图2-1所示，其描述如下。
每个RTP包都包含前面12字节，而CSRC（Contributing Source,贡献源）标识列表仅出现在混合器插入时。
图2-1RTP包头
(2)复用RTP连接
为使协议有效运行，复用点数冃应减至最小。在RTP中，复用由定义RTP连接的目的传输地址，即网络地址与端口号提供。例如，在远程会议中，对音频和视频单独编码，每个媒介根据各自的地址，在不同的RTP连接中传输，而且音频和视频也不是在单一RTP连接中，而是根据SSRC(SynchronizationSource.同步源)段载荷类型进行多路分解。具有不同载荷类型，但却使用同一SSRC的交叉包将可能存在以下几个问题：
①如果一种载荷类型在连接期间切换，将没有办法识别新值将替换哪一个旧值。
②SSRC被定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，则要求不同系列号空间以说明哪种载荷类型有丢包：交叉复用载荷类型将需要不同计时空间。
③RTCP发送和接收报告可能仅描述美国SSRC的计时和系列号空间，而不携带载荷类型段。
④RTP混合器不能将不兼容媒体流合并成一个流。
⑤在一个RTP连接中，携带多个媒介阻止几件事，使用不同网络路径或网络资源分配，接受媒介子集。
对每种媒介，使用不同SSRC,但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。
(3)对RTP头特定设置的修改
可以认为，现用的RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制数可通过设置重新定义以适应不同要求，如釆用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间的关系，我们就可以定位八进制数中最重要的位。
其他特殊载荷格式（视频编码）所要求的信息应该携带在包的载荷部分。可出现在包头，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定包头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制数处理RTP包完成。如证实附加功能是所有设置共同需要的，新版本RTP应该对固定包头进行明确改变。
2.控制协议——RTCP
RTCP协议将控制包周期发送给所有连接者，应用与数据包相同的分布机制。低层协议提供数据与控制包的复用，如使用单独的UDP端口号。
（1）RTCP功能
RTCP执行以下四大功能。
①提供数据发布的质量反馈。
这是RTCP最基本的功能，它是RTP传输协议的重要部分，同时也与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP组播经验表明，发送者收到反馈对诊断发送中的错误是至关重要的。通过给所有参加者发送接收反馈报告，问题观察者可以判断问题是局部的，还是全局的。诸如IP组播等发布机制使网络服务提供商类似的团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。
②带有称作规范名字的RTP源永久性传输层标识。
该功能是RTCP带有称作规范名字（CNAME）的RTP源永久性传输层标识。如发现冲突，或程序重新启动，SSRC标识可能改变，接收者需要利用CNAME跟踪每个参与者。接收者也需要CNAME与相关RTP连接中给定的一系列数据流联系，例如，同步音频和视频。
③控制RTP的速率。
前两种功能要求所有参加者发送RTCP包，因此，当参与者的数量增加到一定规模时，RTP的速率必须受到控制。让每个参加者给其他参与者发送控制包，每个参与者就可独立观察参与者数目，该数量用于计算包发送的速率。
④传送最小连接控制信息（可选）。
该可选功能是传送最小连接控制信息，如在用户接口显示参与者标识，这种方式最可能用在"松散控制”连接，参加者自由进出，不需要成员控制或参数协调，RTCP充当通往所有参与者的方便通道，但不必支持每一个申请者的所有的控制通信要求。
在IP组播场合应用RTP时，前3个功能是必须的。推荐用于所有情形。RTP应用设计人员必须避免使用仅支持单播模式下工作的机制，那将导致无法扩展规模。
(2)RTCP包格式
下面定义了几种携带不同控制信息的RTCP包类型。
• SR：发送报告，当前活动发送者发送和接收统计报告；
• RR：接收报告，非活动发送者接收统计报告；
• SDES：源描述项，包括CNAME；
• BYE：表示结束；
• APP：应用特定函数。
和RTP数据包类似，每个RTCP包以固定部分开始，紧接的是可变长度结构元素，但以32位边界结束。在固定部分中的校正请求和长度字段使RTCP包可堆叠。不需要插入任何分隔符将多个RTCP包连接起来形成一个RTCP组合包，以低层协议的单一包发送出去。由于低层协议需要提供整体长度来决定组合包的结尾，在组合包中，没有单个RTCP包的清楚计数。
组合包中每个RTCP包可独立处理，并不需要按照包的组合顺序进行。但为了执行协议功能，强加约束如下所述。
• 只要带宽允许，接收统计(在SR或RR中)应该经常发送，因此，每次周期发送应包含报告包；
• 新接收者应该尽快接收CNAME,以识别源，并开始联系媒介进行同步，因此，每个RTCP组合包应该包含SDESCNAME；
• 每一次可能出现在组合包里的包类型数量，其增长应该受到限制，以提高常数位数量和成功确认RTCP包对错误地址RTP数据包或其他无关包的概率。
所有RTCP包必须以至少两个组合包形式发送，推荐格式如下所述。
• 加密前缀(EncryptionPrefix)：当且仅当组合包被加密，才加上一个32位随机数用于每个组合包发送；
• SR或RR：组合包中每一个RTCP包必须为一个报告包，以方便包头的确认，即使没有数据发送或接收，也要发送一个空RR,哪怕组合包中RTCP包为BYE：
• 附加RR：如果报告统计源数目超过31,在初始报告包后应该有附加RR包；
• SDES：包含CNAME项的SDES包必须包含在每个RTCP组合包中，如应用要求，其他源描述项可选，但受到带宽限制；
• BYE或APP：其他RTCP包类型可以任意顺序排列，而BYE应与给定的SSRC/CSRC一起作为最后一个包发送，包类型出现可不止一次。
为了减少分组头可能带来的影响，只要条件允许，转换器和混合器最好能够从多个源(这些源都将转发给同一路信号)来产生单个RTCP包。如混合后的分组包的总长度超过网络路径最大传输单元(Maximum Transition Unit,MTU),可按照低层协议的规则分成多个较短分组包，用低层协议以单个包形式逐个发送。注意：每混合后的分组包必须以SR或RR包开始，特殊的RTCP包类型可在Internet号码分配机构(Internet Assigned Numbers Authority,IANA)处注册。
(3)RTCP传输间隔
RTP设计成允许应用自动扩展，连接数可从几个到上千个。例如，在音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立于连接数，但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。
一旦确认地址有效，如后来标记成未活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意：这仍大于RTCP报告最大值的五倍。
除了强制要求的CNAME项外，这个规范还定义了其他的几个源描述项，如NAME(人名)和EMAIL(电子邮件地址)，同时，它还提供方法定义新的特定应用的RTCP包的类型。在给附加信息分配控制带宽时应引起注意，因为它将降低接收报告和CNAME发送的速率从而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20%,而且不要让所有SDES项包含在每个应用中。
(4)发送者与接收者报告
RTP接收者使用RTCP报告包提供接收质量反馈，报告包根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收者报告之间唯一的差别是发送者报告包含一个20字节发送者信息段。如果某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR：否则，就发出RR。SR和RR都可没有或包括多个接收报告块。发布报告不是为了列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR或RR包中，像最后一个报告那样，在开始的间隙里，所有的源需要包含接收报告，在最初的SR或RR包里将加入附加的RR包。
丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失率可通过NTP（NetworkTimeProtocol,网络时间协议）时标差除以丢失部分得到。
从发送者信息中，第三方监控器可以计算出载荷平均数据速率和没有收到数据间隔里的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么，特殊接收者收到的包数量给出此接收者收到的表观流量。
（5）SDES:源描述RTCP包
SDES包为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源。RTCP包结构如图2-2所示。
图2-2 RTCP包结构
1）项描述
• 版本（V）、填充（P）和长度：如SR包中所描述；
• 包类型（PT）：8位，包含常数202,识别RTCPSDES包；
• 源计数（SC）：5位,包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。
2）源描述项内容
①CNAME：规范终端标识SDES项。CNAME标识属性如下所述。
• 如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定；
• 像SSRC标识一样，CNAME标识在RTP连接的所有参与者中应是唯一的；
• 为了提供一套相关RTP连接中某个参与者所釆用的跨多媒体工具间的绑定，参与者的CNAME应该是固定的；
• 为方便第三方监控，CNAME应适合程序或人员定位源。
②NAME：用户名称SDES项。这是用于描述源的真正的名称，如“JohnDoe,BitRecycler.Megacorp”,可以是用户想要的任何形式。对诸如会议应用，这种名称也许是参加者列表显示最适宜的形式，它将是除CNAME外发送最频繁的项，设置可建立这样的优先级别。NAME值至少在连接期间仍希望保持为常数，它不是连接过程中所有参与者的唯一依赖。
③EMAIL：电子邮件地址SDES项。邮件地址格式由RFC822规定，如“John.Doe@Megacorp.com”。连接期间，电子邮件仍希望保持为常数。
④PHONE：电话号码SDES项。电话号码应带有加号，代替国际接入代码，如“+19085551212”即为美国的一个电话号码。
⑤LOC：用户地理位置SDES项。根据应用对于该项的要求不同，此项具有不同程度的细节。对会议应用而言，字符串如"MurrayHill,NewJersey"就足够了。然而，对活动标记系统而言，字符串如“Room2A244,AT&TBLMH”可能才适用。细节留给实施或用户，但格式和内容可在设置指示中预先定义。在连接期间，除移动主机外，LOC值期望仍保留为常数。
⑥TOOL：应用或工具名称SDES项。是一个字符串，表示产生流的应用的名称与版本，如"Videotool1.2”。这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。TOOL值在连接期间仍保持常数。
⑦NOTE：通知/状态SDES项。该项的推荐语法如下所述，但这些或其他语法可在设置中显式定义。NOTE项旨在描述源当前状态的过渡信息，如“OnThePhone,Can'tTa汰”，或在讲座期间用于传送谈话题H。它应该只用于携带异常信息，而不应包含在全部参与者中，因为这将降低接收报告和CNAME发送的速度，损害协议的性能。特殊情况下，它不应作为用户设置文件的项目，也不是自动产生的。当其为活动时，由于NOTE项对显示很重要，其他非CNAME项（如NAME）,传输速率将会降低，结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，但以一个串长为零的字符串通知接收者。然而，如对小倍数的重复或约20〜30RTCP间隔也没有接收到，接收者也应该考虑NOTE项是不活跃的。
⑧PRIV：专用扩展SDES项。该项用于定义实验或应用特定的SDES扩展，它包括由长字符串对组成的前缀，后跟填充该项其他部分和携带所需要信息的字符串值。前缀长度段为8位。前缀字符串是定义PR1V项人员选择的名称，唯一对应应用接收到的其他PRIV项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其他人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。
注意：前缀消耗了总长为255个八进制数项的一些空间，因此，前缀应尽可能地短。这个设备和受到约束的RTCP带宽不应过载，其目的不在于满足所有应用的全部控制通信要求。SDESPRIV前缀没在IANA处注册，如证实某些形式的PRIV项具有通用性，IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀，这也简化了应用，提高了传输的效率。
(6)BYE:断开RTCP包
如果混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC标识。如果混合器关闭，它也应该发出一个BYE包，列出它所处理的所有起作用的源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制数文本，表示离开原因，如“Camera Malfunction或“RTP Loop Detected”。字符串具有同样的编码，如在SDES中所描述的。如字符串信息至BYE包下32位边界结束处，字符串就不以NULL结尾；否则，BYE包以空八进制数填充。
(7)APP:定义应用的RTCP包
APP包用于开发新应用和新特征的实验，不要求注册包类型值：带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
二、RTSP协议
实时流协议RTSP是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据，是应用级协议，控制实时数据的发送。
RTSP协议的目的在于控制多个数据发送连接，它使用TCP或RTP完成数据传输，它在体系结构上位于RTP和RTCP之上。HTTP与RTSP相比，HTTP传送HTML,而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；在使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控和点播成为可能。数据源包括现场数据与存储在剪辑中的数据。
1.协议简介
(1)协议目的
实时流协议RTSP建立并控制一个或几个时间同步的连续流媒体，尽管连续媒体流与控制流可能是交叉的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCPo在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP,但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操作上与HTTP1.1类似，因此，HTTP的扩展机制大都可加入RTSP。但是，在很多重要方面，RTSP仍不同于HTTPo
实时流协议支持的操作如下所述。
• 从媒体服务器上检索媒体：用户可通过HTTP或其他方法提交一个演示描述请求，如果演示是组播，演示描述包含用于连续媒体的组播地址和端口；如果演示仅通过单播发送给用户，用户为了安全应提供目的地址。
• 媒体服务器邀请进入会议：媒体服务器可被邀请参加正在进行的会议，或回放媒体，或记录部分或全部演示，这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
• 将新媒体加到现在演示中：如果服务器能告诉客户端接下来可用的媒体内容，对现场直播显得尤其有用。
与HTTP1.1类似，RTSP请求可由代理、通道与缓存处理。
(2)协议特点
RTSP具有如下一些特点。
• 可扩展性：新方法和参数很容易加入RTSPo
• 易解析：RTSP可由标准HTTP或MIME解析器解析。
• 安全：RTSP使用网页安全机制。
• 独立于传输：RTSP可使用不可靠数据协议(UDP)和可靠数据报协议(RDP),如要实现应用级可靠，可使用TCP等可靠流协议。
• 多服务器支持：每个媒体流可放在不同服务器上，用户端自动与不同服务器建立几个并发控制连接，在传输层执行媒体同步。
• 记录设备控制：协议可控制记录和回放设备。
• 流控与会议初始化分离：流控与邀请媒体服务器参加会议分离，仅要求会议初始化协议提供或用来创建唯一会议标识号，特殊情况下，SIP(SessionInitiationProtocol,会话初始化协议)或H.323可用来邀请服务器参加会议。
• 适合专业应用：通过SMPTE时标，RTSP支持帧级精度，允许远程数字编辑。
• 演示描述中立：协议没强加特殊演示描述或元文件，并且可以转换成可用
的格式类型，然而，演示描述必须至少包含一个RTSPURL
• 友好的代理与防火墙：协议可由应用和传输层防火墙处理，防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。
• 友好的HTTP：此处RTSP明智地采用HTTP观念，使现在结构都可重用，其结构包括Internet内容选择平台(Platformfor Internet Content Selection,PICS),由于在大多数情况下，控制连续媒体需要服务器状态，RTSP不仅仅向HTTP添加方法。
• 适当的服务器控制：如果用户可以启动流，就必须可以停止流。
• 传输协调：实际处理连续媒体流前，用户可协调传输方法。
• 性能协调：如基本特征无效，必须有一些清理机制让用户决定哪种方法没生效，允许用户提出适合的用户界面。
(3)扩展RTSP
由于媒体服务器并不都有相同的功能，媒体服务器有必要支持不同请求集。RTSP可以采用三种扩展方式，以改变大小排序，具体内容如下所述。
• 以新参数扩展：如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。
• 加入新方法：如信息接收者不理解请求，返回501错误代码，发送者不应再次尝试这种方法，用户可使用OPTIONS方法查询服务器支持的方法，服务器使用公共响应头列出支持的方法。
• 定义新版本协议：允许改变所有部分(除了协义版本号位置)。
(4)操作模式
每个演示和媒体流可用RTSPURL(UniformResourceLocator,统一资源定位符)识别。演示组的整个演示与媒体属性由演示描述文件定义，用户可通过HTTP或其他途径获得这个文件，没有必要保存在媒体服务器上。
为了说明，假设演示描述描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说明，且不失一般性，假定演示描述的确包含这样一个演示，演示可包含多个媒体流。
除媒体参数外，网络目标地址和端口也需要决定，有如下几种操作模式。
• 单播：以用户选择的端口号将媒体发送到RTSP请求源。
• 组播，服务器选择地址：媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。
• 组播，用户选择地址：如果服务器加入正在进行的组播会议，将按照范围定义的会议描述给出组播地址、端口和密匙。
(5)RTSP状态
RTSP控制与控制通道无关，由单独协议发送的流。例如，RTSP控制可通过TCP连接，而数据流通过UDP连接。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持会话状态使RTSP请求和流联系。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用。
• SETUP：让服务器给流分配资源，启动RTSP连接。
• PLAY与RECORD：启动SETUP分配流的数据传输。
• PAUSE：临时停止流，而不释放服务器资源。
• TEARDOWN：释放流的资源，RTSP连接停止。
标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连接产生连接标识。
(6)与其他协议关系
RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页进行的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递速率，也允许独立RTSP服务器与用户不全依靠HTTP。
但是，RTSP与HTTP的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出响应。在RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。
当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTPoRTSP假设存在演示描述格式可表示包含几个媒体流演示的静态与临时属性。
2.协议参数
(1)RTSP信息
RTSP是基于文本的协议，釆用ISO10646字符集，使用UTF-8编码方案。每行是以CRLF(换行回车符)中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使得以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容易以脚本语言(如Tel、VisualBasic与Perl)实现研究原型。
ISO10646字符集避免敏感字符集切换，但对应用来说不可见。RTSP也釆用这种编码方案。带有重要意义位的ISO8859-1字符表示为lOOOOlxlOxxxxxx.。RTSP信息可通过任何低层传输协议携带。
请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中时，信息体长度由如下因素决定。
• 不管实体头段是否出现在信息中，不包括信息体的响应信息总以头段后第一空行结束。
• 如岀现内容长度头段，其值以字节计，表示信息体长度，如未出现头段，其值为零。
• 服务器关闭连接。
注意：RTSP目前并不支持HTTP/1.1——“块”传输编码，需要有内容长度头。假如返回适度演示描述长度，即使动态产生，不需要块传输编码，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。
从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，而没有定义任何HTTP代码。
(2)实体
如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和实体体组成，有些响应仅包括实体头。在此，根据谁发送实体，谁接收实体的原则，发送者和接收者可分别指定用户和服务器。
实体头定义实体体可选元信息：如没有实体体，则定义请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。
(3)连接
RTSP请求可以有以下几种不同方式传送。
①持久传输连接，用于多个请求/响应传输。
②每个请求/响应传输一个连接。
③无连接模式。
传输连接类型由RTSPURI来定义，对“rtsp”方案，需要持久连接；而对于“rtspu”方案，调用RTSP请求发送，而不用建立连接。
不像HTTP,RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙，从媒体服务器传到用户的唯一途径，支持持久连接或无连接的客户端可用管道传输它的请求，服务器必须按照收到请求顺序发岀响应。
如果请求不是发送给组播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间(RoundTripTime,RTT)后重发同一信息。RTT在TCP中估计，初始值为500mso应用缓存最后所测量的RTT作为将来连接的初始值。如使用一个可靠传输协议传输RTSP,请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。如两个低层可靠传输(如TCP和RTSP)应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收者前不会发送应用层重传，接收者也不能充分利用应用层重传。如果包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加-O如由于没有确认而重发请求，请求必须携带初始系列号。
实现RTSP的系统必须支持通过TCP传输RTSP,并支持UDPo对UDP和TCP,RTSP服务器的默认端口都是554o许多冃的-致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与RTP和RTCP包交叉。不像HTTP,RTSP信息必须包含一个内容长度头，无论信息何时包含负载，否则，RTSP包以空行结束，后跟最后一个信息头。
(4)方法定义
方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头，且必须是一个记号。
某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和服务器操作复杂，并强加附加开销，除非有必要，否则，应避免这样做。插入二进制数据仅在RTSP通过TCP传输时才可使用。流数据(如RTP包)用一个ASCII符号封装，后跟一字节通道标识，其后是封装二进制数据的长度，两字节整数。流数据紧跟其后没有CRLF,但包括高层协议头。每个$块包含一个高层协议数据单元。
当传输选择RTP时，RTCP信息也被服务器通过TCP连接插入。在默认情况下，RTCP包在比RTP通道高的第一个可用通道上发送。客户端信息可能在另一个通道显式请求RTCP包中，这可通过指定传输头插入参数中的两个通道来做到。当两个或更多流交叉时，为取得同步，需要RTCPo而且，这为当网络设置需要通过TCP控制连接时，透过RTP/RTCP提供了一条方便的途径，如果可能，在UDP上进行传输。
三、 TS和ISMA比较
2000年12月，国际上的一些视频产业的重要成员成立了一个组织，叫Internet流媒体联盟，简称ISMA(Internet Streaming Media Alliance)。在这个组织里，有许多人们比较熟悉的公司，如Cisco、IBM、Sony、Sun、NEC、苹果、飞利浦、日立、杜比和以色列的阿贝斯公司(Optibase)和SIGMA等。该组织成立的目的是为了将当时已经产生的视/音频标准MPEG-4尽快转化成产品，以协调这些国际视/音频产业公司之间的利益冲突。
该组织规范了Internet±流媒体的一些标准，主要内容如下所述。
• 视频压缩采用MPEG-4的第2章(ISO14496-2)。
• —般音频压缩采用AAC(AdvancedAudioCodec,先进音频编码)格式。
• 语音编码：CELP(CodeExcitedLinearPrediction,码激励线性预测)。
• 媒体传输流协议：RTP和RTCP(详见RFC1889ATransportProtocolforReal-TimeApplications)□
• 媒体控制：RTSP,详见RFC2326RealTimeStreamingProtocol(RTSP)o
• 媒体公告(MediaAnnouncement)：SAP(详见RFC2974SessionAnnouncementProtocol,会话通告协议)和SDP(详见RFC2327SessionDescriptionProtocol,会话描述协议)。
• 内容交换格式(MediaDistribution)：采用苹果公司的MP4文件格式。
这一系列的规定，形成了ISMA流媒体规范。通常，我们将符合这些标准的Internet媒体流称为ISMA流。
在ISMA成立之前，活动图像专家组在制定MPEG-2系统标准时定义了复用一个或多个音频、视频和数据元素流的方法。数据流被打包，加上时间标识，形成一个被包装的元素流(PackedElementaryStream,PES)。音频、视频和数据(任选)的PES被复用在一起，形成可存储和传输应用的单一输出流。MPEG-2系统标准的目的是提供必要的句法，用以同步音频和视频声明信息。MPEG-2系统标准有节目流(ProgarmStream,PS)和传输流(Transmission Stream,TS)两种数据流。
• PS用可变长度包，TS用短固定尺寸包。
• PS通常用于DVD类的存储应用中，TS通常用于错误发生较多的场合。
• TS复用那些并没有共同时间基准的数据流，固定长度为188字节，在这188字节的包中，至少有4字节用为包头，其余字节用作传输存储数据、音频和视频信息。
• TS包头命令包含的信息有同步、包私有、节目标识和错误状态，TS可包含附带头领域，提供时间信息。
和ISMA一样，MPEG-2TS定义的就是一个在Internet环境下传输视/音频信号的数据流格式，也是媒体流的一种形式。
目前，这两种流格式，是不同厂家在IPTV系统中广泛采用的格式，下面我们从多方面来对这两种流格式进行比较。
ISMA历史相对较短，仅是为了Internet上的流媒体服务而制定的标准，在PCVOD应用中较多，但在基于宽带网络和电视终端的数字视频广播领域应用较少，因此，其目标是Internet上的低码率点播节目和低并发率。
TS则是广播行业通用的标准，已经有十多年实际的大规模普遍性应用历史，目标是基于宽带的数字视频广播，并且支持多种基本媒体流和多种媒体编码标准，得到全球广播行业和Internet行业的一致认同。目前，中国联通IPTV规范中已经明确要求支持TS流格式。
图2-3和图2-4是两种流格式的包结构图。
图2-3TS/PS流格式
图2-4ISMA流格式
ISMA流由于标准本身指定的目的是为了推广MPEG-4的应用，所以，其整个系统的设计是围绕MPEG-4进行的，它的流格式是和媒体文件相关的，它的目的是优化MPEG-4文件在网络中的传输。因此，除了编码器（Encoder）和终端的解码器（Decoder）需要了解AN编解码的细节信息（如视频格式等）夕卜，流媒体服务器也需要了解编解码的细节（如视频格式等），相比而言，加重了流媒体服务器的负荷。从处理方法上面来看，从编码端到解码端的所有环节，均需建立多个音/视频和其他数据流的RTPSession,因此，当作为流媒体服务器的I/O时，需要管理多个输入输出，多个Buffer的管理以及它们之间的同步，将极大地增加流媒体服务器的处理能力，也带来了较大的算法复杂性，同时降低了系统的稳定性和可靠性。图2-5为ISMA的MP4文件头格式。采用ISMA标准需要管理更多的RTPSession,要管理更多的I/O和Buffer,将极大地消耗流媒体服务器和STB的CPU性能和内存，从而严重地影响了系统的性能。根据Darwin系统及其实验，我们在一台高性能机器上，也只能跑较少的Stream并且会有掉线情况发生。ISMA的视/音频同步是依靠RTP中的TimeStamp来实现的，因此，在同步时，需要等到音/视频的RTP都到达后才能实现视/音频同步，带来的结果是，采用ISMA,在网络不稳定的时候，同步的时间可能会增加，导致频道切换以及快进快退等操作时响应不够快。除了需要编解码器外，同时还需要流媒体服务器参与AV同步的处理，消耗了流媒体服务器的资源，增加了算法复杂度和性能代价，降低了系统的可靠性和稳定性。在解码时，当用ISMA时，由于需要建立多个RTPSession连接，因此，需要有多个Buffer,并对其管理。所以在釆用ISMA时，使用的解码器的Memory和CPU资源也更多，其对硬件的要求也比较高。
MPEG-2TS流格式与媒体本身不相关，也就是说，TS流只负责媒体文件的传递，只有编码器（Encoder）和终端的解码器（Ecoder）需要了解A/V编解码的细节信息（如视频格式等），其他服务器（如流媒体服务器）无须了解。所以，虽然TS流格式是在MPEG-2中定义的，但是它同样可以用来传递MPEG-4的媒体文件，只是因为它在MPEG-2中定义，所以通常称为MPEG-2TS流。正是由于TS流和媒体格式不相关，所以，无论采用什么样的新媒体格式，对流媒体服务器都没有影响，而由于TS流本身复用的是没有共同时间基准的音/视频流，其同步是由TS的头部来提供的，所以，音/视频同步也无须流媒体服务器参与，从而简化了流媒体服务器的设计。从处理方法上来看，将多个音/视频和其他数据流复用在一起，仅需建立一个RTP Session,因此，在进行I/O、Buffer管理和音/视频同步等方面将会简单和容易得多。当采用TS流时，在相同的试验条件下，流媒体服务器会支持几百个2Mbps以上的Stream并且不会掉线。在视/音频同步问题上，TS不存在ISMA同样的问题，因此其时间信息都在一个流中，TS的视/音频同步只需在编码和解码端实现，中间的其他环节，如流服务器等，不需要参与，可以降低流媒体服务器的算法和处理复杂度。在解码方面，TS流的主要工作是在解复用上，即解复用器需要分析PSI信息，然后根据PSI信息获取音/视频的PID,再通过PID滤波，得到视/音频流，输出到各自的Buffer中。由于TS是固定的188字节包结构，因此，PID在包中的位置固定，滤波很容易实现，经过测试，釆用软件TS流解复用的方法，在EquatorBSP-15平台上，占用的CPU资源不足5%,其对机顶盒硬件的要求相应也比ISMA格式的机顶盒低。
ISMA流中的MP4文件头如图2-5所示。
图2-5 ISMA流中的MP4文件头
在对直播业务的支持方面，频道切换是一个关键指标，当采用ISMA方式时，进行LiveTV频道切换。由于STB解码时所需的很多信息在ISMA文件头中，因此STB需要从系统中重新获取ISMA的文件头。所以，系统还必须有一整套ISMA的文件头的生成和管理。这样会造成解码频道切换的延退。另外，当采用ISMA方式时，在LIVETV进行频道切换时，STB还需要重新获取SDP,并重新建立音/视频的Session；这两个方面均会造成频道切换时间较长，不能满足电信标准规定的2s,这两个因素导致了采用ISMA频道切换速度比较慢。在做LiveTV时，如果编码器的参数被修改，需要STB与编码器或流媒体服务器之间重新建立RTSPSession,以获取新的SDP,然后才能从SDP中得到解码所需要的一些具体参数。而在TS流中，没有所谓文件头，而且音/视频也在同一个流中，因此，可以进行快速地频道切换，能满足2s的切换时间要求。同样在进行频道参数改变时，所有的解码参数均是伴随着码流一起下来的，因此，不需要建立另外的Session,解码器反应速度会更快。
由于网络技术和计算机技术发展非常迅速，所以，系统的升级是必须的，支持不同的编码格式需要升级；增加新的功能需要升级；增加加新的服务也需要升级。ISMA1.0视频基于MPEG-4Part2,以SP(SimpleProfile,简装版)和ASP(AdvancedSimpleProfile,高级简装版)为基础，并没有涉及H.264,而ISMA2.0则基于H.264,ISMA2.0不兼容ISMA1.0,即ISMA1.0服务器和客户端不能平滑升级到ISMA2.0系统，具体原因在于：
①视频RTP包的封装模式不兼容。
②DP消息格式不兼容。
③文件的存储方式不一致，ISMA1.0基于MPEG-4Part14(*.MP4),而ISMA2.0的文件格式基于MPEG-4Part15(*.avcl)。
目前，支持H.264的ISMA2.0刚发布，还没有得到很多专业编码器的支持。
TS的存储则与媒体编码格式无关，MPEG-2TS可以封装任何格式的内容。在对TS流进行存储时，只需将其进行分段处理，然后加上Index信息，并与TS流共同存储即可。因此，釆用TS流的文件格式具有更好的兼容性，方便平台的平滑升级。在对H.264的支持方面，目前有众多H.264专业级编码器支持，如Tandberg和Harmonic。
新媒体业务要提供商业运营，对于数字版权管理非常关注。ISMA中虽然定义DRM采用AES的加密方法，但其DRM不具有扩展性。表现在不支持多种DRM方法和加密标准，不支持对Key的管理。而TS中正好解决了上述这一点，可以在RTP的Extension中定义Key的管理方法和映射关系，以及不同的DRM方法和标准，使得系统在DRM方面具有广泛的兼容性。
新媒体业务成功的关键在于内容，从这方面看，TS比较具有优势，目前，大部分CP都是电视台、电影公司和广电公司的，其主要的片源都釆用MPEG-2TS流封装格式。因此TS能更好地适应CP的主要现状和需求。从和DVB的兼容方面来看，目前在广电领域，DVB全部釆用TS流封装格式。因此，若采用TS,日后可以与广电领域DVB节目完全兼容。而ISMA流，则需要采用转码的方式，以实现这些内容的导入。
从设备厂家的支持来看，目前所有的专业级的编码器厂商均只支持TS,而不支持ISMA,如Harmonic、 Tandberg和Scientific Atlanta等，所有的MPEG-4和H.264的解码芯片均支持TS格式，所以，选择TS可以为STB提供更多的选择方案，利于降低STB的成本。目前，在已经规模运营的IPTV系统中，大部分均采用了MPEG-2TS格式，包括法国电信、中国香港电讯盈科和日本Yahoo!BB等主流运营商。
表2-1是对上述内容的概括整理，通过它，读者可以更清楚地了解TS和ISMA的不同之处。
表2-1TS和ISMA对比表
