RTSP

RTSP

求助编辑百科名片

RTSP（Real Time Streaming Protocol），实时流传输协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTSP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。

目录

概念

简介

协议特点

协议结构

协议参数

RTSP信息

RTSP实体

展开

概念

简介

协议特点

协议结构

协议参数

RTSP信息

RTSP实体

展开

编辑本段概念

　　RTSP是用来控制声音或影像的多媒体串流 协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内， 服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调 时间同步，所以比较能容忍网

  RTSP

络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低 服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。因为与 HTTP1.1的运作方式相似，所以 代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

编辑本段简介

　　该 协议用于 C/S模型，是一个基于 文本的 协议，用于在 客户端和 服务器端建立和协商实时流会话。

　　实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该 协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、 组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。

　　实时流 协议（RTSP）建立并控制一个或几个 时间同步的连续 流媒体。尽管连续媒体流与 控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多 媒体服务器的网络 远程控制。RTSP连接没有绑定到 传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对 服务器的可传输连接以发出RTSP请求。此外，可使用无连接 传输协议，如UDP。RTSP 流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。

　　 协议支持的操作如下：

　　(1）从 媒体服务器上检索媒体：用户可通过HTTP或其它方法提交一个演示描述。如演示是 组播，演示式就包含用于连续媒体的的 组播地址和 端口。如演示仅通过 单播发送给用户，用户为了安全应提供目的地址。

　　(2） 媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按 远程控制按钮。

　　(3）将媒体加到现成讲座中：如 服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与 缓存处理。

编辑本段协议特点

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

　　(2) 易解析：RTSP可由标准HTTP或MIME解析器解析。

　　(3) 安全：RTSP使用网页安全机制。

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

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

　　(6) 记录设备控制： 协议可控制记录和回放设备。

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

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

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

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

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

　　(12) 适当的 服务器控制：如用户启动一个流，必须也可以停止一个流。

　　(13) 传输协调：实际处理连续媒体流前，用户可协调传输方法。

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

编辑本段协议结构

　　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”针对于返回一个信息主体的所有方法。

编辑本段协议参数

　　1．RTSP版本

　　H.321采用，用RTSP代替HTTP。

　　2．RTSPURL

　　“rksp"和“rtspu"方案用于指RTSP 协议使用的网络资源，为RTSP URL定义方案特定的语法和语义。

　　3．会议标识

　　会议标识对RTSP来说是模糊的，采用标准URI编码方法编码，可包含任何八位组数值。会议标识必须全局惟一。

　　4．连接标识

　　连接标识是长度不确定的字符串，必须随机选择，至少要8个八位组长，使其很难被猜出。

　　5．SMPTE相关时标

　　SMPTE相关时标表示相对剪辑开始的时间，相关时标表示成SMPTE时间代码，精确到帧级。时间代码格式为小时：分钟：秒：帧。缺省smpte格式是"SMPTE 30"，帧速率为每秒29.97帧。其他SMPTE代码可选择使用smpte时间获得支持（如"SMPIE 25")。时间数值中帧段值可从0到29。每秒30与29.97帧的差别可将每分钟的头两帧丢掉来实现。如帧值为零，就可删除。

　　6．正常播放时间

　　正常播放时间（NPT）表示相对演示开始的流绝对位置。时标由十进制分数组成。左边部分用秒或小时、分钟、秒表示；小数点右边部分表示秒的部分。演示的开始对应0.0秒，负数没有定义。特殊常数定义成现场事件的当前时刻，这也许只用于现场事件。直观上，NPT是联系观看者与程序的时钟，通常以数字式显示在VCR上。

　　7．绝对时间

　　绝对时间表示成ISO 8601时标，采用UTC(GMT）。

　　8．可选标签

　　可选标签是用于指定RTSP新可选项的惟一标记。这些标记用在请求和代理-请求头段。当登记新RTSP选项时，需提供下列信息：

　　（1）名称和描述选项。名称长度不限，但不应该多于20个字符。名称不能包括空格、 控制字符。

　　（2）表明谁改变选项的控制。如IETF，ISO，ITU-T，或其他国际标准团体、联盟或公司。

　　（3）深入描述的参考，如RFC、论文、专利、技术报告、文档源码和计算机手册。

　　（4）对专用选项，附上联系方式。

编辑本段RTSP信息

　　RTSP是基于 文本的 协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于 文本的 协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。文本 协议很容易以 脚本语言（如：Tcl，Visual Basic与Perl）实现研究原型。

　　ISO 10646 字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10x x x x x x。RTSP信息可通过任何低层 传输协议携带。

　　请求包括方法、方法作用于其上的对象以及进一步描述方法的参数。方法也可设计为在 服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度由如下因素决定：

　　(1）不管实体头段是否出现在信息中，不包括信息体的响应，信息总以头段后第一个空行结束。

　　(2）如出现内容长度头段，其值以 字节计，表示信息体长度。如未出现头段，其值为零。

　　(3） 服务器关闭连接。

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

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

编辑本段RTSP实体

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

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

编辑本段连接

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

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

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

　　·　无连接模式。

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

　　不像HTTP，RTSP允许 媒体服务器给媒体用户发送请求。然而，这仅在 持久连接时才支持，否则 媒体服务器没有可靠途径到达用户，这也是请求通过 防火墙从媒体服务器传到用户的惟一途径。

编辑本段方法定义

　　方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。已定义方法如下表所示。

　　RTSP方法

　　

方法	方向	对象	要求	含义
DESCRIBE	C->S	P,S	推荐	检查演示或媒体对象的描述，也允许使用接收头指定用户理解的描述格式。DESCRIBE的答复-响应组成媒体RTSP初始阶段
ANNOUNCE	C->S  S->C	P,S	可选	当从用户发往服务器时，ANNOUNCE将请求URL识别的演示或媒体对象描述发送给服务器；反之，ANNOUNCE实时更新连接描述。如新媒体流加入演示，整个演示描述再次发送，而不仅仅是附加组件，使组件能被删除
GET_PARAMETER	C->S  S->C	P,S	可选	GET_PARAMETER请求检查RUL指定的演示与媒体的参数值。没有实体体时，GET_PARAMETER也许能用来测试用户与服务器的连通情况
OPTIONS	C->S  S->C	P,S	要求	可在任意时刻发出OPTIONS请求，如用户打算尝试非标准请求，并不影响服务器状态
PAUSE	C->S	P,S	推荐	PAUSE请求引起流发送临时中断。如请求URL命名一个流，仅回放和记录被停止；如请求URL命名一个演示或流组，演示或组中所有当前活动的流发送都停止。恢复回放或记录后，必须维持同步。在SETUP消息中连接头超时参数所指定时段期间被暂停后，尽管服务器可能关闭连接并释放资源，但服务器资源会被预订
PLAY	C->S	P,S	要求	PLAY告诉服务器以SETUP指定的机制开始发送数据；直到一些SETUP请求被成功响应，客户端才可发布PLAY请求。PLAY请求将正常播放时间设置在所指定范围的起始处，发送流数据直到范围的结束处。PLAY请求可排成队列，服务器将PLAY请求排成队列，顺序执行
RECORD	C->S	P,S	可选	该方法根据演示描述初始化媒体数据记录范围，时标反映开始和结束时间；如没有给出时间范围，使用演示描述提供的开始和结束时间。如连接已经启动，立即开始记录，服务器数据请求URL或其他URL决定是否存储记录的数据；如服务器没有使用URL请求，响应应为201（创建），并包含描述请求状态和参考新资源的实体与位置头。支持现场演示记录的媒体服务器必须支持时钟范围格式，smpte格式没有意义
REDIRECT	S->C	P,S	可选	重定向请求通知客户端连接到另一服务器地址。它包含强制头地址，指示客户端发布URL请求；也可能包括参数范围，以指明重定向何时生效。若客户端要继续发送或接收URL媒体，客户端必须对当前连接发送TEARDOWN请求，而对指定主执新连接发送SETUP请求
SETUP	C->S	S	要求	对URL的SETUP请求指定用于流媒体的传输机制。客户端对正播放的流发布一个SETUP请求，以改变服务器允许的传输参数。如不允许这样做，响应错误为"455 Method Not Valid In This State”。为了透过防火墙，客户端必须指明传输参数，即使对这些参数没有影响
SET_PARAMETER	C->S  S->C	P,S	可选	这个方法请求设置演示或URL指定流的参数值。请求仅应包含单个参数，允许客户端决定某个特殊请求为何失败。如请求包含多个参数，所有参数可成功设置，服务器必须只对该请求起作用。服务器必须允许参数可重复设置成同一值，但不让改变参数值。注意：媒体流传输参数必须用SETUP命令设置。将设置传输参数限制为SETUP有利于防火墙。将参数划分成规则排列形式，结果有更多有意义的错误指示
TEARDOWN	C->S	P,S	要求	TEARDOWN请求停止给定URL流发送，释放相关资源。如URL是此演示URL，任何RTSP连接标识不再有效。除非全部传输参数是连接描述定义的，SETUP请求必须在连接可再次播放前发布

注：P----演示，S----流，C----用户端，S---- 服务器端

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

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

编辑本段流水线操作

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

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

　　实现RTSP的系统必须支持通过TCP传输RTSP，并支持UDP。对UDP和TCP，RTSP 服务器的缺省 端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与RTP和RTCP包交叉。不像HTTP，RTSP信息必须包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头。

编辑本段扩展RTSP

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

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

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

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

编辑本段操作模式

　　每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用HTTP或其他途径用户可获得这个文件，它没有必要保存在 媒体服务器上。为了说明这个问题，假设演示描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说明，且不失一般性，假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参数外，网络目标地址和 端口也需要决定。

　　下面区分几种操作模式。

　　(1） 单播：用户选择的 端口号将媒体发送到RTSP请求源。

　　(2） 服务器选择地址 多播： 媒体服务器选择 多播地址和 端口，这是现场直播或准点播常用的方式。

　　(3）用户选择地址 多播：如 服务器加入正在进行的多播会议， 多播地址、 端口和密钥由会议描述给出。

编辑本段RTSP状态

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

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

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

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

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

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

编辑本段与其他协议的关系

　　实时流 协议在语法和操作上与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只在请求过程中传送 绝对路径并将 主机名置于另外的头字段。

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

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

　　当大多数实时媒体使用RTP作为 传输协议时，RTSP没有绑定到RTP。RTSP假设存在演示描述格式可表示包含几个媒体流的演示的 静态与临时属性。

编辑本段微软与RTSP

简述

　　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协议有一些轻微的改动。我们网站上有本文档（还有后续版本）和一个简单的研究，它们可以帮助你了解这些信息。

区别

　　 微软的rtsp规范与标准 rtsp协议相比最主要的改动是发送包payloads到 客户端的方式，另外还有一些请求命令有一些改动。传输单个媒体包的机制并没有文档（就我目前所知），这可能是 微软要保留的信息。　就像MMS和HTTP 1.0流 协议使用一个媒体数据 包头一样，RTSP也有。但是 微软的数据 包头格式没有在任何的rtsp文档中注明。在企图连接 微软的rtsp 服务器时，这是主要的问题。

　　 微软RTSP 协议的命令采用的语法和标准 rtsp协议的命令语法一样，只有一些小的修改和添加，可以通过阅读网上的一些文档，就可以知道怎么去组成这些命令。微软rtsp命令部分已经有文档了。