)RTSP
RTSP哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。
该协议用于C/S模型，是一个基于文本的协议，用于在客户端和服务器端建立和协商实时流会话。
实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
实时流协议（RTSP）建立并控制一个或几个时间同步的连续流a媒体。尽管连续媒体流与控制流交*是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可*传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。然而，在很多重要方面RTSP仍不同于HTTP：
RTSP引入了大量新方法并具有一个不同的协议标识符；
在大多数情况下，RTSP服务器需要保持缺省状态，与HTTP的无状态相对；
RTSP中客户端和服务器都可以发出请求；
在多数情况下，数据由不同的协议传输；
RTSP使用ISO 10646（UTF-8）而并非ISO 8859-1，与当前的国际标准HTML相一致；
URI请求总是包含绝对URI。为了与过去的错误相互兼容，HTTP/1.1只在请求过程中传送绝对路径并将主机名置于另外的头字段。
协议支持的操作如下：
从媒体服务器上检索媒体：用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。
媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
将媒体加到现成讲座中：如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
可扩展性：
新方法和参数很容易加入RTSP。
易解析：
RTSP可由标准 HTTP或MIME解吸器解析。
安全：
RTSP使用网页安全机制。
独立于传输：
RTSP可使用不可*数据报协议（UDP）、可*数据报协议（RDP），如要实现应用级可*，可
使用可*流协议。
多服务器支持：
每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在
传输层执行。
记录设备控制：
协议可控制记录和回放设备。
流控与会议开始分离：
仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下， SIP或H.323
可用来邀请服务器入会。
适合专业应用：
通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑
RTSP是一种文本协议，采用UTF-8编码中的ISO 10646字符集。一行可通过CRLF终止，但接收端需要做好解释CR和LF作为一行终止符的准备。关于头字段概述如下：
Header Type Support Methods
Accept R opt. entity
Accept-Encoding R opt. entity
Accept-Language R opt. all
Allow R opt. all
Authorization R opt. all
Bandwidth R opt. all
Blocksize R opt. All but OPTIONS, TEARDOWN
Cache-Control G opt. SETUP
Conference R opt. SETUP
Connection G req. all
Content-Base E opt. entity
Content-Encoding E req. SET_PARAMETER
Content-Encoding E req. DESCRIBE, ANNOUNCE
Content-Language E req. DESCRIBE, ANNOUNCE
Content-Length E req. SET_PARAMETER, ANNOUNCE
Content-Length E req. entity
Content-Location E opt. entity
Content-Type E req. SET_PARAMETER, ANNOUNCE
Content-Type R req. entity
CSeq G req. all
Date G opt. all
Expires E opt. DESCRIBE, ANNOUNCE
From R opt. all
If-Modified-Since R opt. DESCRIBE, SETUP
Last-Modified E opt. entity
Proxy-Authenticate
Proxy-Require R req. all
Public R opt. all
Range R opt. PLAY, PAUSE, RECORD
Range R opt. PLAY, PAUSE, RECORD
Referer R opt. all
Require R req. all
Retry-After R opt. all
RTP-Info R req. PLAY
Scale Rr opt. PLAY, RECORD
Session Rr req. All but SETUP, OPTIONS
Server R opt. all
Speed Rr opt. PLAY
Transport Rr req. SETUP
Unsupported R req. all
User-Agent R opt. all
Via G opt. all
WWW-Authenticate R opt. all
类型"g"表示请求和响应中的通用请求头；类型“R”表示请求头；类型“r”表示响应头；类型"e"表示实体头字段。在“support”一栏中标有“req.”的字段必须由接收者以特殊的方法实现；而“opt.”的字段是可选的。注意，不是所有“req.”字段在该类型的每个请求中都会被发送。“req.”只表示客户机（支持响应头）和服务器（支持请求头）必须执行该字段。最后一栏列出了关于头字段产生作用的方法；其中“entity”针对于返回一个信息主体的所有方法。
RTSP并非只是微软在用！
这是一个公开的规范，在这个规范上开发了很多的流服务器。甚至Linux服务提供者和苹果的程序员也使用rtsp协议以及Real Networks流媒体。似乎整个世界的网络流传输都用这个协议。然而，微软并不只在rtsp上有所作为。
微软和RTSP
在写这个文档的时候，微软正处于从首选MMS协议转换到首选采用RTSP协议的过程中。这个说明在Media Player 9.0版本和流媒体服务器2003版本之后，我们会看到微软将rtsp协议作为流媒体传输的主要协议。
随着时间慢慢的流逝，我们会发现mms协议正逐步走出人们的视野。It is only assumed that this is so MS can say they are being open with their protocols (rtsp is an open standard) while at the same time disregarding the need to publicise their own MMS protocol once its gone from media player. 然而，mms还没有真的死亡，至少在接下来的几年中我们依然可以看到它在流媒体传输中的身影。
是否微软的RTSP协议和标准的开放式RTSP不同？
是的。跟在RFC2326（1998年四月）中定义的原始RTSP协议相比，微软的rtsp协议有一些轻微的改动。我们网站上有本文档（还有后续版本）和一个简单的研究，它们可以帮助你了解这些信息。
区别在哪儿？
微软的rstp规范与标准rtsp协议相比最主要的改动是发送包payloads到客户端的方式，另外还有一些请求命令有一些改动。传输单个媒体包的机制并没有文档（就我目前所知），这可能是微软要保留的信息。
就像MMS和HTTP 1.0流协议使用一个媒体数据包头一样，RTSP也有。但是微软的数据包头格式没有在任何的rtsp文档中注明。在企图连接微软的rtsp服务器时，这是主要的问题。
微软RTSP协议的命令采用的语法和标准rtsp协议的命令语法一样，只有一些小的修改和添加，可以通过阅读网上的一些文档，就可以知道怎么去组成这些命令。微软rtsp命令部分已经有文档了。
[1] http://dslab.ee.ncku.edu.tw/~lily/learning/learning_ch2-1.html
