RTSP协议详解中文版
E-mail：bryanj@https://www.sodocs.net/doc/5d10888530.html,
译者：Bryan.Wong（王晶，宁夏固原）
译文版本：alpha 0.80
译文发布时间：2007-7-25
版权：本中文翻译文档之版权归王晶所有。可于非商业用途前提下自由转载，但必须保留此翻译及版权信息。
https://www.sodocs.net/doc/5d10888530.html,/filedownload?user=bryanj&id=611206
网络工作组 H. Schulzrinne
请求注释: 2326 哥伦比亚大学.
类别: 标准跟踪 A. Rao
Netscape
R. Lanphier
RealNetworks
1998年4月
实时流协议(RTSP)
本备忘录状态
本文为Internet社区描述了一种Internet标准跟踪协议，还需要讨论和建议以便进行改善。请查看最新版本的"Internet正式协议标准"（STD 1）了解本协议的标准化进程和状态。本备忘录的传播不受限制。
版权声明：
版权为The Internet Society 所有。所有权利保留。
摘要：
实时流协议（RTSP）是应用层协议，控制实时数据的传送。RTSP提供了一个可扩展框架，使受控、按需传输实时数据（如音频与视频）成为可能。数据源包括现场数据与存储在剪辑中的数据。本协议旨在于控制多个数据发送会话，提供了一种选择传送途径（如UDP、组播UDP与TCP）的方法，并提供了一种选择基于RTP (RFC1889)的传送机制的方法。
目录：
1 介绍
1.1 目的
1.2 要求
1.3 术语
1.4 协议特性
1.5 RTSP扩展
1.6 整体运作
1.7 RTSP状态
1.8 与其他协议的关系
2 符号协定
3 协议参数
3.1 RTSP版本
3.2 RTSP URL
3.3 会议标识
3.4 会话标识
3.5 SMPTE 相对时间戳
3.6正常播放时间
3.7 绝对时间
3.8 选项标签
3.8.1 用IANA注册新的选项标签*4 RTSP消息
4.1 消息类型
4.2 消息头
4.3 消息主体
4.4 消息长度
*5 普通头部段
*6 请求
6.1 请求行
6.2 请求消息头段
*7 响应
7.1 状态行
7.1.1 状态码和原因短语
7.1.2 响应头部段
*8 实体
8.1 实体头部域
8.2 实体主体24
*9 连接
9.1 流水线化25
9.2 可靠性及确认25
*10 方法定义25
10.1 可选项26
10.2 描述26
10.3 通知26
10.4 建立26
10.5 播放27
10.6 暂停27
10.7 断开27
10.8 获取参数28
10.9 设置参数28
10.10 重定向28
10.11 录制29
10.12 嵌入（交织）的二进制数据29 *11状态码定义29
11.1成功2xx 30
11.1.1 存储空间低250 30
11.2 重定向3xx 31
11.3 客户端错误4xx 31
11.3.1方法不允许32
11.3.2无法理解参数32
11.3.3会议未找到33
11.3.4 带宽不足33
11.3.5 会话未找到34
11.3.6 本状态下该方法无效34
11.3.7 头部域与资源不匹配34
11.3.8 无效范围35
11.3.9 参数为只读35
11.3.10 不允许合操作36
11.3.11 只允许合操作36
11.3.12 不支持的传输36
11.3.13 目标不可达37
11.3.14 不支持的选项37
12 头部段定义（Header Field Definitions）38 12.1 接受38
12.2 接受-编码38
12.3 接受-语言39
12.4 允许（Allow）39
12.5 授权（Authorization）40
12.6 带宽40
12.7 块大小 40
12.8 缓存控制41
12.9 会议41
12.10 连接41
12.11 内容-基础42
12.12 内容-编码（Content-Encoding）42
12.13 内容-语言43
12.14 内容-长度（Content-Length）43
12.15 内容-位置43
12.16 内容-类型（Content-Type）44
12.17 命令序列题头（CSeq）44
12.18 日期（Date）44
12.19 过期（Expires）45
12.20 来自（From）45
12.21 主机45
12.22 如果匹配45
12.23如果-被修改-自从（If-Modified-Since）46 12.24 最后修改（Last-Modified）46
12.25 位置（Location）46
12.26 代理认证47
12.27 代理要求47
12.28 公布 47
12.29 范围49
12.30 提交方（Referer）49
12.31 稍后重试49
12.32 要求49
12.33 RTP信息49
12.34 倍速（Scale）
12.35 速度49
12.36 服务器（Server）49
12.37 会话49
12.38 时间戳49
12.39 传输49
12.40 不支持49
12.41 用户代理（User-Agent）49
12.42 变化49
12.43 通过49
12.44 WWW-认证（WWW-Authenticate）50 *13 缓存50
*14 例子50
14.1 按需点播（单播）50
14.2 容器文件的流化51
14.3 单个流容器文件51
14.4 实况媒体表示的组播51
14.5 在存在的会话中播放媒体51
14.6 录制52
*15 语法52
15.1 基本语法52
16 安全考虑（Security Considerations）52
*附录A RTSP协议状态机53
*A.1 客户端状态机53
*A.2 服务器端状态机53
*附录B 与RTP协议的交互53
*附录C 使用SDP进行RTSP会话描述54 +C.1 定义54
o C.1.1 控制URL 55
o C.1.2 媒体流55
o C.1.3 有效载荷类型55
o C.1.4 详细格式参数55
o C.1.5 表示的范围56
o C.1.6 有效时间56
o C.1.7 连接信息56
o C.1.8 实体标签57
+C.2 合控制不可用57
+C.3 合控制可用57
*附录D 最小RTSP实现58
+D.1 客户端58
D.1.1基本回放58
D.1.2 认证enabled 58
+D.2 服务器59
D.2.1基本回放 59
D.2.2认证enabled 59
*附录E 作者地址60
*附录F 致谢60
*参考书目60
*版权申明61
1 介绍
1.1 目的
实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，比如音频或视频。尽管在连续媒体流中有可能插入控制流（见10.12节），但RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的"网络遥控器"。
表示描述定义了流的控制操作的集合，但本文并没有规定表示描述的格式。
RTSP没有"连接"这个概念，而由RTSP会话(session)代替（服务器端保持一个由识别符标记的会话）。RTSP会话没有绑定传输层连接（如TCP连接）。在RTSP会话期间，RTSP 客户端可以打开或关闭多个到服务器端的可靠传输连接以发出RTSP请求。但也可以使用无连接传输协议，比如UDP，来发送RTSP请求。
RTSP所控制的流可能用到RTP，但RTSP的操作并不依赖用来传送连续媒体的传输机制。实时流协议在语法和操作上有意地类似于HTTP/1.1，使得HTTP的扩展机制大都可加入RTSP。尽管如此，RTSP在很多重要方面与HTTP有所不同：
*RTSP引入了很多新方法并且有不同的协议标识符。
*RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。
*RTSP客户机和服务器都可以发出请求。
*数据由信带外的另一个协议传送（但有一个特例）。
*RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。
*RTSP的URI请求时总是包含绝对URI。而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。
当只有一个IP的主机要提供多个文档树时，可使"虚拟主机"的实现更简单。
协议支持以下操作：
从媒体服务器上获得媒体：
用户可通过HTTP或其它途径请求一个表示描述。如果该表示是组播，表示描述就包含用于该连续媒体的的多播地址和端口。如表示仅通过单播发送给用户，用户为了安全应起见要提供目的地址。
邀请媒体服务器进入会议：
媒体服务器可被"邀请"加入已存在的的会议，包括向该表示内回放媒体，或记录此表示中的一部分或全部媒体。这种模式在分布式教学应用上很有用。会议中的各方可轮流"按网络遥控器的按钮"。
将媒体加到已存在的表示中：
现场表示的专用概念。当服务器可以告诉客户端"可以附加媒体"时有用。
和HTTP/1.1类似，RTSP的请求可由代理、通道与缓存处理。
1.2 要求
在本文档中的关键字"必须"，"必须不"、"需要"、"必须"、"必须不"、"应该"、"不应该"、"推荐"、"可能"、和"可选的"，都和RFC2119 [4]中的解释一致。
1.3 术语
一些HTTP/1.1的术语被采用。这里没有举出的术语，其定义与HTTP/1.1相同。
合控制：
服务器使用一条时间线对多个流进行控制。对音频/视频的回放来讲，这意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回放。
会议：
多方参与的多媒体表示，这里的多方意味着大于或等于一方。
客户端：
指请求媒体服务器上连续流媒体数据的客户端。
连接：
以通讯为目的，在传输层建立的两个程序间的虚拟信道。
可以容纳多个媒体流的文件，而这些媒体流共同播放时通常还包含一个表示。RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不包含在本协议中。
连续媒体：
接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重放原来存在于源数据中的时序关系。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流（回放）的形式，时序关系没那么严格。
实体：
请求或者响应的载荷部分中所传输的信息。实体由信息元组成，而每个信息元由由实体头部域和实体主体组成。实体头部域内是信息格式，实体主体内是信息内容，如第8章所述。
媒体初始化：
数据类型/编码的具体初始化。这包括时钟频率，颜色空间等。客户端请求一个媒体流回放时所需的任何独立于传输的信息，都是在流创建时媒体初始化阶段产生的。
媒体参数:
对于某种特定的媒体类型来说，回放前或者回放中有可能会发生改变的一些参数。
媒体服务器：
提供一个或多个媒体流之回放或录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不同的媒体服务器。媒体服务器可以建在激活该表示(presentation)的Web服务器上，也可以建立在不同的主机上。
媒体服务器重定向：
重新把媒体客户端定向到另外一个媒体服务器。
(媒体)流：
单个媒体实例，比如，一个音频流或者一个视频流，连同一个白板或者共享程序组。当使用RTP时，流包括由RTP会话(session)中同一个源所创建的所有RTP和RTCP包。这和DSM-CC流([5])的定义相同。
消息：
RTSP通讯的基本单元。由15章语法定义的结构化八位位组序列组成，并通过有连接或者无连接协议传送。
一个会议的成员。参与者可以是机器，比如是媒体记录或回放服务器。
表示(presentation)：
作为一个完整的媒体信息，回馈性地表述给客户端的一个或多个流的集合。表示使用下面的表示描述进行表述。大部分情况下，在RTSP中的文字部分中，这暗示集合中的流的合控制，但并非必须。
表示描述(presentation description)：
表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息，的集合。另外，其他IETF协议，如SDP协议使用术语"会话(session)"代替"现场表示"。表示描述可以采用包括会话描述(session description)SDP在内的多种格式。
响应：
RTSP响应。如果能理解HTTP响应，就能清楚地理解RTSP响应。
请求：
RTSP请求。如果能理解HTTP请求，就能清楚地理解RTSP请求。
RTSP会话(session)：
包括一次RTSP"事务"（transaction）的全过程。比如，一个电影的观看过程。会话(session)一般包括由客户端为连续媒体建立传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。
传输初始化：
客户端和服务器端之间关于传输所需的相关信息（端口号，传输协议等）的协商。
1.4 协议特点
RTSP有以下特性：
易于扩展：
可以很容易地向RTSP加入新方法和参数。
易解析：
RTSP可由标准HTTP或MIME解析器解析。
RTSP重用了网页安全机制。所有HTTP授权机构如basic (RFC 2068 [2, Section 11.1])和digest (RFC 2069 [8])授权都可直接使用。也可以重用传输层或网络层安全机制。
独立于传输：
RTSP即可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，也可使用可靠流协议如TCP。
多服务器支持：
表示(presentation)中的每个流可放在不同服务器上，客户端自动同不同服务器建立几个并发控制的会话，媒体同步在传输层执行。
录制设备控制：
协议可控制记录和回放设备，以及可在两种模式之间切换的设备（VCR）。
流控制与会议初始化分离：
流控制与邀请媒体服务器入会相分离；仅要求会议初始化协议可提供，或可用来创建具有唯一性的会议标识号。具体地说，SIP或H.323 可用来邀请服务器入会。
适合专业应用：
通过SMPTE 时标，RTSP支持帧级别精度，以支持远程数字编辑。
适合专业应用：
RTSP依赖SMPTE时间戳支持帧级精度，使得可以进行远程数字编辑。
表示描述中立：
协议没强行指定特定的表示或元文件格式，可传达所用的格式类型；然而，表示描述必须至少包含一个RTSP URI。
代理与防火墙友好：
协议需由应用层协同传输层(SOCKS [14])防火墙友好地进行处理。防火墙需要理解SETUP方法，以为UDP媒体流打开一个"洞口"。
HTTP友好：
此处，RTSP明智地重用了HTTP概念，使现有的基础结构可被重用。这些基础结构包括Internet 内容选择平台（PICS：Platform for Internet Content Selection [15,16]），以便通过相关
标签访问内容。但由于在大多数情况下，控制连续媒体需要服务器状态，RTSP不仅仅向HTTP 添加方法。
合适的服务器控制：
若客户端能启动一个流，它必须也能停止一个流。服务器不能启动一个用户不能停止的流。
传输协商：
实际处理连续媒体流前，客户端可协商传输方法。
性能协商：
若基础特性被禁用，必须有某种明确的机制让用户决定哪种方法将不不被实现。这允许用户提出适合的用户界面。例如，如果不允许寻找，用户界面必须能禁止位置条滑动。
早期曾要求RTSP支持多用户，但现在有了更好的方案，就是保证RTSP能很容易扩展成支持多用户即可。因为流的标志可以被多个控制流使用，因此可以"轮换持有控制器"。协议不涉及到多个客户端如何协调入口--这项任务被留给"社会协议"或其他层。
1.5 扩展RTSP
由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同的请求集。例如：
服务器可能只能回放，因此不必支持录制请求。
用于提供现场直播的服务器可能不支持寻找（绝对位置）功能。
一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER 请求。
但服务器应该实现所有12章中要求的标题域。
表示描述(presentation description)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1 [2]中，[H19.6]所描述的方法不太可能被所有服务器都支持的情形一致。
RTSP 可以如下三种方式扩展，按所支持的改变多少排序：
*已有的方法可以扩展加入新参数，只要这些参数可以被接收方安全地忽略。（这和给一种HTML tag增加新标签是一样的）如果客户端在请求失败时需要一个拒绝确认，需要在请求：字段(见Section 12.32)中加入一个对应于该扩展的标签。
*可以加入新方法。如果接收方不理解请求，它就返回一个501错误码（意指未实现），发送方就不应再尝试这种方法。客户端可以用OPTIONS方法去询问服务器支持的方法。服务器应该在公共回应头里列出它所支持的所有方法。
*可以定义新版本的协议，以支持几乎所有方面的改变（除了版本协议号的位置）。
1.6 整体运作
每个表示和媒体流可用RTSP URL识别。表示组成的整个表示与媒体属性由表示描述(presentation description)文件定义，其格式不在本协议中定义。客户端可以通过HTTP或其它途径（如email）获得此表示描述文件，它没有必要保存在媒体服务器上。
根据此规范的目标，我们假想一个表示描述(presentation description)描述了多个表示(presentation)，每个表示(presentation)维持一个统一的时间轴。为简明但不失一般性，假定表示描述(presentation description)正好包含一个这样的表示(presentation)。表示(presentation)可包含多个媒体流。
表示描述(presentation description)包含组成表示的流的描述，包括它们的编码，语言和使用户可以选择最符合要求媒体的其他参数。在表示描述中，各个由RTSP分别控制的媒体流各有一个RTSP URL。RTSP URL指出了处理具体媒体流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别放到不同服务器而实现均分负载。描述（description)还列出了服务器可使用的传输方法。
除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：
单播：
以用户选择的端口号将媒体发送到RTSP请求的来源处。另一种选择是，用和RTSP相同的可靠流传输媒体。
多播，服务器选择地址：
媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。
多播，用户选择地址：
若服务器要加入正在进行的多播会议，多播地址、端口和密匙由会议描述给出。会议描述的建立不在此规范中讨论。
1.7 RTSP状态
RTSP控制通过与控制通道无关的独立协议发送的流。例如，RTSP控制可能是使用TCP 连接，而数据流使用UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接按顺序发出的请求来控制。所以，服务器需要维护"会话状态"以便使RTSP请求和流相互关联。状态之间的转换在附录A中描述。
RTSP中很多方法与状态无关，但下列方法在服务器流资源的定位和应用上起着重要的作用：SETUP, PLAY, RECORD, PAUSE, 和TEARDOWN.
SETUP：
让服务器给流分配资源，启动RTSP会话。
PLAY与RECORD：
启动SETUP所分配的流的数据传输。
PAUSE：
临时暂停流，而不释放服务器资源。
TEARDOWN：
释放流占用的资源，RTSP会话停止，从服务器端退出。
与状态相关的RTSP方法使用会话头部域（Session header field (Section 12.37)）来识别哪个RTSP会话的状态需要处理，在SETUP请求(章节10.4)的响应中，服务器生成会话标识。
1.8 与其他协议关系
RTSP在功能上与HTTP有重叠。它也可能与HTTP相互作用，体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许网页服务器与RTSP媒体服务器之间有多种接力点。例如，表示描述(presentation description)可通过HTTP和RTSP得到，这降低了基于浏览器的应用模式的往返传递，也允许完全不依赖HTTP的独立RTSP 服务器与客户端。
但是，RTSP与HTTP 的本质差别在于数据发送以信带外的不同协议进行。HTTP是不对称协议，用户发送请求，服务器作出响应。RTSP中，媒体用户和服务器都可发送请求。RTSP请求也不是无状态的；在请求确认后很长时间后，仍可设置参数，继续控制媒体流。
重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。
虽然大多数实时媒体使用RTP作为传输层协议，RTSP并没有绑定到RTP。
RTSP假设存在可表示包含几个媒体流的表示的静态与临时属性的表示描述格式。
2 符号约定
既然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档。为简便起见，本文档中[ HX.Y ]表示对应HTTP/1.1（RFC 2068 [2]）中的X.Y部分。（[译者注：]为更方便学习RTSP，本翻译文档将相关段落完全译出）
与[H2.1]类似，本文对所有机制的说明都是以增广BNF的形式来描述的。此形式在RFC 2234中有详细的描述，唯一的不同是RTSP中以"1#"代替","为分隔符。
********************
简单说明增广BNF如下：
增广BNF（augmented BNF）包括下面的结构：
要解释的名词＝名词解释（name = definition）
规则的名字（name）就是它本身（不带任何尖括号，"<"，">"），后面跟个等号＝，然后就是该规则的定义。如果规则需要用多个行来描述，利用空格进行缩进格式排版。某些基本的规则使用大写，如SP, LWS, HT, CRLF, DIGIT, ALPHA,等等。定义中还可以使用尖括号来帮助理解规则名的使用。
字面意思（"literal"）
文字的字面意思放在引号中间，若无特别指定，则该段文字是大小写敏感的。
规则1｜规则2（rule1 | rule2）
"｜"表示其分隔的元素是可选的，比如，"是｜否"要选择‘是’或‘否’。
（规则1 规则2）（(rule1 rule2)）
在圆括号中的元素表明必然出现。如（元素1（元素2｜元素3）元素4）可表明两种意思，即"元素1 元素2 元素4"和"元素1 元素3 元素4"
*规则（*rule）
在元素前加星号"*"表示循环，其完整形式是"
［规则］（[rule]）
方括号内是可选元素。如"［元素1 元素2］"与"*1（元素1 元素2）"是一回事。
N 规则（N rule）
表明循环的次数："
＃规则（#rule）
"#"与"*"类似，用于定义元素列表。
完整形式是"
空元素在结构中可被任意使用，但不参与元素个数的计数。也就是说，"（元素1），，（元素2）"仅表示2个元素。但在结构中，应至少有一个非空的元素存在。缺省值是0到无限，即"#（元素）"表示可取任何数值，包括0；而"1#元素"表示至少有1个；而"1#2元素"表示有1个或2个。
；注释（; comment）
分号后面是注释，仅在单行使用。
隐含*LWS（implied *LWS）
本文的语法描述是基于单词的。除非另有指定，否则线性空格（LWS）可以在两个邻近符号或分隔符（tspecials）之间任意使用，而不会对整句的意思造成影响。在两个符号之间必须有至少一个分隔符，因为它们也要做为单独的符号来解释。实际上，应用程序在产生HTTP 结构时，应当试图遵照"通常方式"，因为现在的确有些实现方式在通常方式下无法正常工作。
********************
在本备忘录中，我们用缩进的小型段落来提供背景和动机。这将使没有参与制定RTSP 规范的读者更容易理解RTSP中各部分为什么要以该方式来实现。
3 协议参数
3.1 RTSP版本
同[H3.1]定义，仅用RTSP代替HTTP即可。
********************
[H3.1]：
RTSP采用主从（
RTSP消息的版本由消息第一行中的RTSP版本域来表示。
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
注意，主从版本应当被看作单独的整数，因为它们都有可能增加，从而超过一位整
数。因而，RTSP/2.4比RTSP/2.13版本低，而RTSP/2.13又比RTSP/12.3版本低。
版本号前面的0将被接收方忽略，而在发送方处也不应产生。
本文档定义了RTSP协议的1.0版本。发送本规范定义的请求（Request）或响应（Response）消息的应用必须指明RTSP的版本为"RTSP/1.0"。使用该版本号意味着发送消息的应用至少有条件的遵循本规范。
应用的RTSP版本即为应用至少能有条件遵循的RTSP版本中的最高版本。
当代理及网关收到与其自身版本不同的RTSP请求时，必须小心处理请求的推送，因为协议版本表明发送方的能力，代理或网关不应发出高于自身版本的消息。如果收到高版本的请求，代理或网关必须降低该请求的版本，并响应一个错误。而低版本的请求也应在被推送前升级。代理或网关响应请求时必须和请求的版本相同。
********************
3.2 RTSP URL
"rtsp"和"rtspu"前缀表示要通过RTSP协议来定位网络资源。本节详细定义了RTSP URL的语法和语义。
rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ]
host = <合法的Internet主机域名或IP地址(用十进制数及点组成), 见RFC1123，2.1节定义>
port = *DIGIT
abs_path 在[H3.2.1]中定义。
********************
[H3.2.1]：
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]
path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
params = param *( ";" param )
param = *( pchar | "/" )
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = reserved, extra, safe, and unsafe> 权威的URL语法及语义信息请参见RFC1738[4]和RFC1808[9]。 ******************** 注意：fragment和query标识符在这时没有明确的定义，需要到RTSP服务器上解释。 rtsp前缀要求使用可靠协议（在Internet上指TCP协议）发出命令，而rtspu前缀则说明使用不可靠协议（在Internet指UDP协议）。 如是端口为空或没指定，则缺省为554端口。语义如下：拥有被请求的资源的服务器主机通过监听TCP连接(rtsp方案)或主机上相应端口的UDP包(rtspu方案)，来控制所标记的资源。资源的请求URI是rtsp_URL。 应尽可能避免在URL中直接使用IP地址。（请参考RFC1924） 一个表示或者流是通过基于文本的媒体标记来标识的，此媒体标记使用URLs (RFC 1738 [20])中的字符集和转义规则[H3.2]。URLs可以指向一个流或者一个流的集合，即是说，一个表示。请求视情况可以指向一个完整的表示或者表示中的单个流，见第十章。注意，某些 rtsp简介(ZT) Real Time Streaming Protocol或者RTSP（实时流媒体协议），是由Real network 和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据的反馈和存贮的文件。rtsp对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，rtsp作用相当于流媒体服务器的远程控制。传输数据可以通过传输层的tcp，udp协议，rtsp也提供了基于rtp传输机制的一些有效的方法。RTSP消息格式: RTSP的消息有两大类,一是请求消息(request),一是回应消息(response),两种 消息的格式不同. 请求消息: 方法URI RTSP版本CR LF 消息头CR LF CR LF 消息体CR LF 其中方法包括OPTION回应中所有的命令,URI是接受方的地址,例如 :rtsp://192.168.20.136 RTSP版本一般都是RTSP/1.0.每行后面的CR LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF 回应消息: RTSP版本状态码解释CR LF 消息头CR LF CR LF 消息体CR LF 其中RTSP版本一般都是RTSP/1.0,状态码是一个数值,200表示成功,解释是与状态码对应的文本解释. 简单的rtsp交互过程: C表示rtsp客户端,S表示rtsp服务端 1.C->S:OPTION request //询问S有哪些方法可用 1.S->C:OPTION response //S回应信息中包括提供的所有可用方法 2.C->S:DESCRIBE request //要求得到S提供的媒体初始化描述信息 2.S->C:DESCRIBE response //S回应媒体初始化描述信息，主要是sdp 3.C->S:SETUP request //设置会话的属性，以及传输模式，提醒S建立会 话 3.S->C:SETUP response //S建立会话，返回会话标识符，以及会话相关信息 4.C->S:PLAY request //C请求播放 4.S->C:PLAY response //S回应该请求的信息 S->C:发送流媒体数据 5.C->S:TEARDOWN request //C请求关闭会话 5.S->C:TEARDOWN response //S回应该请求 RTSP协议学习笔记 目录 RTSP协议学习笔记 (1) 第一部分:RTSP协议 (2) 一、RTSP协议概述 (2) 二、RTSP协议与HTTP协议区别 (2) 三、RTSP重要术语 (3) 1.集合控制(Aggregate control ): (3) 2.实体(Entity)： (3) 3.容器文件（Container file）： (3) 4.RTSP会话(RTSP session )： (3) 四、RTSP请求消息 (3) 1.消息格式： (3) 五、RTSP回应消息 (4) 1.消息格式： (4) 六、RTSP 重要方法 (4) 1. OPTIONS: (4) 2. DESCRIBE： (5) 3. SETUP： (6) 4. PLAY： (7) 5. PAUSE： (8) 6. TEARDOWN： (8) 七、RTSP重要头字段参数 (9) 1.Accept: (9) 2.Bandwidth: (9) 3. CSeq： (9) 4. Rang： (9) 5.Session: (9) 6.Transport: (9) 八、简单的RTSP消息交互过程 (10) 1.第一步：查询服务器端可用方法 (10) 2.第二步：得到媒体描述信息 (10) 3.第三步：建立RTSP会话 (10) 4.第四步：请求开始传送数据 (10) 5.第五步：数据传送播放中 (10) 6.第六步：关闭会话，退出 (10) 第二部分:SDP协议 (11) 一、SDP协议概述 (11) 二、SDP格式 (11) 三、SDP示例 (12) 第三部分:MMS协议 (13) 一、MMS协议概述 (13) 一、 RTP : （Real-time Transport Protocol，实时传输协议）是一个网络传输协议 RTP报文格式 RTP报文由两部分组成：报头和有效载荷。RTP报头格式如图所示，其中： 1.V：RTP协议的版本号，占2位，当前协议版本号为2。 2.P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 3.X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。 https://www.sodocs.net/doc/5d10888530.html,：CSRC计数器，占4位，指示CSRC 标识符的个数。 5.M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。 6.同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。 7.特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。 8.PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM 图像等。 9.序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。 10.时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。 图 RTP报头格式 二、RTCP：RTP 控制协议（RTCP：RTP Control Protocol） RTSP协议学习笔记 目录 RTSP协议学习笔记 (1) 第一部分:RTSP协议 (3) 一、RTSP协议概述 (3) 二、RTSP协议与HTTP协议区别 (3) 三、RTSP重要术语 (4) 1.集合控制(Aggregate control): (4) 2.实体(Entity)： (4) 3.容器文件（Container file）： (4) 4.RTSP会话(RTSP session)： (4) 四、RTSP请求消息 (4) 1.消息格式： (4) 五、RTSP回应消息 (5) 1.消息格式： (5) 六、RTSP重要方法 (5) 1.OPTIONS: (6) 2.DESCRIBE： (6) 3.SETUP： (7) 4.PLAY： (8) 5.PAUSE： (9) 6.TEARDOWN： (10) 七、RTSP重要头字段参数 (10) 1.Accept: (10) 2.Bandwidth: (10) 3.CSeq： (11) 4.Rang： (11) 5.Session: (11) 6.Transport: (11) 八、简单的RTSP消息交互过程 (11) 1.第一步：查询服务器端可用方法 (11) 2.第二步：得到媒体描述信息 (11) 3.第三步：建立RTSP会话 (12) 4.第四步：请求开始传送数据 (12) 5.第五步：数据传送播放中 (12) 6.第六步：关闭会话，退出 (12) 第二部分:SDP协议 (12) 一、SDP协议概述 (12) 二、SDP格式 (13) 三、SDP示例 (14) 第三部分:MMS协议 (14) 一、MMS协议概述 (14) E-mail：bryanj@https://www.sodocs.net/doc/5d10888530.html, 译者：Bryan.Wong（王晶，宁夏固原） 译文版本：alpha 0.80 译文发布时间：2007-7-25 版权：本中文翻译文档之版权归王晶所有。可于非商业用途前提下自由转载，但必须保留此翻译及版权信息。 https://www.sodocs.net/doc/5d10888530.html,/filedownload?user=bryanj&id=611206 网络工作组 H. Schulzrinne 请求注释: 2326 哥伦比亚大学. 类别: 标准跟踪 A. Rao Netscape R. Lanphier RealNetworks 1998年4月 实时流协议(RTSP) 本备忘录状态 本文为Internet社区描述了一种Internet标准跟踪协议，还需要讨论和建议以便进行改善。请查看最新版本的"Internet正式协议标准"（STD 1）了解本协议的标准化进程和状态。本备忘录的传播不受限制。 版权声明： 版权为The Internet Society 所有。所有权利保留。 摘要： 实时流协议（RTSP）是应用层协议，控制实时数据的传送。RTSP提供了一个可扩展框架，使受控、按需传输实时数据（如音频与视频）成为可能。数据源包括现场数据与存储在剪辑中的数据。本协议旨在于控制多个数据发送会话，提供了一种选择传送途径（如UDP、组播UDP与TCP）的方法，并提供了一种选择基于RTP (RFC1889)的传送机制的方法。 目录： 1 介绍 1.1 目的 1.2 要求 1.3 术语 1.4 协议特性 1.5 RTSP扩展 1.6 整体运作 1.7 RTSP状态 1.8 与其他协议的关系 2 符号协定 3 协议参数 3.1 RTSP版本 3.2 RTSP URL 3.3 会议标识 3.4 会话标识 3.5 SMPTE 相对时间戳 3.6正常播放时间 3.7 绝对时间 3.8 选项标签 3.8.1 用IANA注册新的选项标签*4 RTSP消息 4.1 消息类型 4.2 消息头 编号：_______________本资料为word版本，可以直接编辑和打印，感谢您的下载 rtsp协议摄像头 甲方：___________________ 乙方：___________________ 日期：___________________ rtsp协议摄像头 篇一：使用海康摄像头实现实时监控 使用海康摄像头实现实时监控 1. 基于Rtsp协议的windows平台监控。 1.1选取海康网络摄像头（支持Rtsp，标准h.264Rtp 封装的设备）。 1.2. 按照摄像头的使用说明书部署。假设访问ip地址是：http://192.168.0.64 ，登录后设置输出端口为：81, 则完整的取流地址为：主码流 rtsp://admin:12345@192.0.0.64:81/h264/ch1/main/av_s tream rtsp://admin:12345@192.0.0.64:81/mpeg-4/ch1/main/av _stream 子码流： rtsp://admin:12345@192.0.0.64/mpeg4/ch1/sub/av_stre am rtsp://admin:12345@192.0.0.64/h264/ch1/sub/av_strea m 1.3. 使用Vlc (支持标准的Rtsp流媒体)的播放器可以实时播放。 2. 基于active 控件的网页监控。 2.1. 选取海康网络摄像头并进行部署，假设访问地址为：http://192.168.0.64:6666 。 2.2. 访问http://192.168.0.64:6666 , ie 浏览器会提 示需要安装active 控件，将active控件存储到本地(ipcameraactivex.cab.cab )。 2.3. 解压ipcameraactivex.cab ,用记事本打开ipcameraactivex.inf 文件，查看代码段： [netVideoactivex23.ocx] file-win32-x86=thiscab Registerserver=yes clsid={caFcF48d-8e34-4490-8154-026191d73924} destdir=11 FileVersion=2,3,21,1 2.4. 记录上面的“ clsid ”。 2.5. 在网页中注册上述ocx控件，使用js调用控件的 中的方法进行登录，查看等操作(查看其他操作可查找：海 RTSP协议 RTSP协议 RTSP（Real Time Stream Protocol，实时流协议）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据 源包括现插数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、多播UDP 与TCP等提供途径，并为选择基于RTP 上发送机制提供方法。 一．简介 1．目的 实时流协议建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交叉是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒 体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出 RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP 流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协 议在语法和操作上与HTTP 1.1类似，因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下： (1)从媒体服务器上检索媒体 用户可通过HTTP或其他方法提交一个演示描述。如演示是多播，演示时就包含用于连续媒体的多播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。 (2)媒体服务器邀请进入会议 媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。 (3)将媒体加到现成讲座中 例如，服务器告诉用户可获得附加媒体内容。这对现场讲座显得尤其有用。如HTTP 1.1中类似，RTSP请求可由代理、通道与缓存处理。 2．协议特点 RTSP有如下特性。 (1) 可扩展性：新方法和参数很容易加入RTSP。 (2) 易解析：RTSP可由标准HTTP或MIME解析器解析。 (3) 安全：RTSP使用网页安全机制。 (4) 独立于传输：RTSP可使用不可靠数据报协议(EDP)、可靠数据报协议(RDP)；如要实现应用级可靠，可使用可靠流协议。 一．RTSP协议概述 RTSP(Real-Time Stream Protocol )是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。 RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。 二．一次基本的RTSP协议连接过程 1.客户端与服务器建立TCP三次握手连接。 2.客户端连接到流服务器并发送一个RTSP描述命令（OPTIONS），询问S有哪些方法可用 （包括DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、OPTIONS、ANNOUNCE、RECORD等）。 3.客户端继续发送一个RTSP描述命令（DESCRIBE），要求得到S提供的媒体描述信息，流服务器 通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。 4.客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建 立命令告诉服务器客户端用于接收媒体数据的端口。 5.流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流 （RTP包）到客户端。 6.在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发 送一个终止命令(TERADOWN)来结束流媒体会话。 三、简单的RTSP消息交互过程 C表示RTSP客户端,S表示RTSP服务端 1.第一步：查询服务器端可用方法 1.C->S:OPTION request //询问S有哪些方法可用 1.S->C:OPTION response //S回应信息的public头字段中包括提供的所有可用方法 RTSP协议介绍 RTSP协议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停/继续、后退、前进等。因此 RTSP 又称为“因特网录像机遥控协议”。 1.1. RTSP协议简介 要实现 RTSP 的控制功能，不仅要有协议，而且要有专门的媒体播放器(media player)和媒体服务器(media server)。媒体服务器与媒体播放器的关系是服务器与客户的关系。 媒体服务器与普通的万维网服务器的最大区别就是媒体服务器支持流式音频和视频的传送，因而在客户端的媒体播放器可以边下载边播放（需要先缓存一小段时间的节目）。但从普通万维网服务器下载多媒体节目时，是先将整个文件下载完毕，然后再进行播放。 图1 RTSP与RTP和RTCP的关系 RTSP 仅仅是使媒体播放器能控制多媒体流的传送。因此，RTSP 又称为带外协议，而多媒体流是使用 RTP 在带内传送的。 1.2. RTSP的报文结构 RTSP有两类报文：请求报文和响应报文。请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。 由于 RTSP 是面向正文的(text-oriented)，因此在报文中的每一个字段都是一些 ASC II 码串，因而每个字段的长度都是不确定的。 RTSP报文由三部分组成，即开始行、首部行和实体主体。在请求报文中，开始行就是请求行，RTSP请求报文的结构如图2所示。 图2 RTSP请求报文的结构 RTSP请求报文的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、G ET_PARAMETER和SET_PARAMETER。RTSP请求报文的常用方法及作用如表1所示。 表1 RTSP请求报文的常用方法及作用 RTSP协议与HTTP协议 一。RTSP协议简介 流媒体技术是一系列的网络协议的集合，包括： 1. 实时传输协议RTP(Real-time Transport protocol) 2. 实时传输控制协议RTCP(Real-time Transport Control protocol) 3. 实时流协议RTSP(Real Time Streaming protocol) 4. 资源预留协议RSVP(Resource Reserve Protocol)。 实时流协议RTSP是一个应用层协议，用于控制具有实时特性的数据（例如多媒体流）的传送。为多媒体数据流提供远程控制功能，如播放、停止、快进等。该协议支持以下操作： 1. 从媒体服务器上获取媒体； 2. 邀请媒体服务器加入会议（Conference）； 3. 在一个已存在的演示（Presentation）中加入新的媒体流。 RTSP协议一般与RTP/RTCP和RSVP等底层协议一起协同工作，提供基于Internet的整套的流服务。它可以选择发送通道（例如：UDP、组播UDP和TCP）和基于RTP的发送机制。它可以应用于组播和点播。 二。HTTP协议简介 HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。 HTTP协议的主要特点可概括如下： 1.支持客户/服务器模式。 2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。 RTSP协议转换RTMP直播协议 RTSP协议转换RTMP直播协议 RTSP协议也是广泛使用的直播/点播流媒体协议，最近实现了一个RTSP协议转换RTMP直播协议的程序，为的是可以接收远端设备或服务器的多路RTSP 直播数据，实时转换为RTMP直播协议，推送到FMS、Red5、wowza server等RTMP 服务器，以实现flash观看RTSP直播源的需求。程序同时也具备从FLV文件获取输入数据并转换RTMP直播。实现的思路分享如下。 要点分析 首先，程序的主要目的，是从多路RTSP输入源中提取AAC编码的音频和H.264编码视频数据，并生成RTMP数据包，然后组装RTMP推送协议，并发往RTMP服务器。在发送的过程中，要求可以从RTSP数据源切换到具有相同h.264和aac 编码的FLV文件中，并不影响RTMP直播。因此，本程序的关键点有以下部分： 1.RTSP直播流的读取 2.H.264和AAC编码数据的分析、处理 3.FLV文件数据的提取及与RTSP直接的切换和衔接 4.RTMP数据包封装 5.RTMP推送协议 有了关键点，就可以一项一项的去分析。 设计思路 根据上面分析的要点，首先要选择RTSP直播协议的读取。我们不需要从零做起，网络上有很多和RTSP相关的开源项目可以使用或借鉴，我选择了Live555。 Live555是一个跨平台的流媒体解决方案，主要支持RTSP协议，好像也支持SIP（这个也是我马上研究的重点，之后会写文章研究SIP相关的技术实现）。Live555实现了RTSP包括服务器-客户端的整套结构，是很知名的一个开源项目。 网上有很多关于Live555学习和使用的文章，我就不具体介绍了。 H.264和AAC数据的分析处理，这个对于从没做过相关项目开发的人来说，应该是一个难点，主要是相关概念的理解。好在我一直在做这块，也比较好弄。 第4和第5点，可以参照文章“RTMP协议发送H.264编码及AAC编码的音视频（https://www.sodocs.net/doc/5d10888530.html,/haibindev/archive/2011/12/29/2305712.html），实现摄像头直播”的技术方法，来加以实现。因此，主要需要处理的就是RTSP 直播流数据的获取，以及对其中H.264和AAC编码数据的处理。 于是可以画出大体结构如下： RtmpThread的主要工作就是发送音频数据流的解码信息头和视频数据流的解码信息头，并不断从DataBufferQueue中取出数据，封装为RTMP Packet，发送出去。流程如下列代码所示：（process_buf_queue_，即是上图中的DataBufferQueue） rtsp摘要认证协议(Response计算方法) 1. rtsp摘要认证协议流程 RTSP协议，全称Real Time Streaming Protocol，是应用层的协议，它主要实现的功能是传输并控制具有实时特性的媒体流，如音频（Audio）和视频（Video）。Rtsp认证主要分为两种：基本认证（basic authentication）和摘要认证（digest authentication）。基本认证是http 1.0提出的认证方案，其消息传输不经过加密转换因此存在严重的安全隐患。摘要认证是http 1.1提出的基本认证的替代方案，其消息经过MD5哈希转换因此具有更高的安全性。下面将以一次与网络摄像机握手的全过程来详细介绍RTSP摘要认证的应用： 摘要认证Digest authentication [plain] view plaincopyprint? 客户端第一次发起连接请求：OPTIONS rtsp://192.168.123.158:554/11 RTSP/1.0 CSeq: 1 User-Agent: LibVLC/2.0.5(LIVE555 Streaming Media v2012.09.13) 服务器端返回服务端信息及public方法：RTSP/1.0 200 OK Server: HiIpcam/V100R003 V odServer/1.0.0 Cseq: 1 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY,GET_PARAMETER 客户端再次发起连接：DESCRIBE rtsp://192.168.123.158:554/11 RTSP/1.0 CSeq: 2 音视频—RTSP协议简介 RTSP简介 RTSP协议以客户端/服务器方式工作，如：暂停/继续、后退、前进等。它是一个多媒体播放控制协议，用来控制用户在播放从因特网下载的实时数据,因此RTSP又称为“因特网录像机遥控协议”。 RTSP(Real-Time Stream Protocol)是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学,网景和RealNetworks公司提交的IETF RFC 标准.对应的RFC编号是2326，可以在这里搜索 https://https://www.sodocs.net/doc/5d10888530.html,/search/rfc_search_detail.php RTSP协议定义了一对多的应用程序如何有效地通过IP网络传送多媒体数据.。RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或UDP完成数据传输。 RTSP被用于去控制已建立的媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于传送媒体流数据。媒体数据的传送可通过 RTP/RTCP等协议来完成。 该协议基于C/S模型,是一个基于文本的协议,用于在客户端和服务器端建立和协商实时流会话。. RTSP是类似http的应用层协议，一个典型的流媒体框架网络体系可参考下图： RTSP协议特点 ●可扩展性:新方法和参数很容易加入RTSP。 ●易解析:RTSP可由标准HTTP或MIME解析器解析。 ●安全:RTSP使用网页安全机制。 ●独立于传输:RTSP可使用不可靠数据报协议(EDP),可靠数据报协议(RDP); 如要实现应用级可靠,可使用可靠流协议。 ●多服务器支持:每个流可放在不同服务器上,用户端自动与不同服务器建立 几个并发控制连接,在传输层执行媒体同步。 ●记录设备控制:协议可控制记录和回放设备。 ●流控与会议开始分离:仅要求会议初始化协议提供,或可用来创建唯一会议 标识号.特殊情况下,可用SIP或H.323来邀请服务器入会。 ●适合专业应用:通过SMPTE时标,RTSP支持帧级精度,允许远程数字编 辑。 ●演示描述中立:协议没强加特殊演示或元文件,可传送所用格式类型;然而, 演示描述至少必须包括一个RTSP URL。 ●代理与防火墙友好:协议可由应用和传输层防火墙处理.防火墙需要理解 SETUP方法,为UDP媒体流打开一个“缺口”。 ●HTTP友好:此处,RTSP明智地采用HTTP观念,使现在结构都可重用.结 构包括Internet内容选择平台(PICS).由于在大多数情况下控制连续媒体需要服务器状态,RTSP不仅仅向HTFP添加方法。 ●适当的服务器控制:如用户启动一个流,必须也可以停止一个流。 ●传输协调:实际处理连续媒体流前,用户可协调传输方法。 ●性能协调:如基本特征无效,必须有一些清理机制让用户决定哪种方法没生 效.这允许用户提出适合的用户界面。 一次基本的RTSP操作过程: ●首先，客户端连接到流服务器并发送一个RTSP描述命令(DESCRIBE)。 ●流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型 等信息。 ●客户端然后分析该SDP描述，并为会话中的每一个流发送一个RTSP建立 命令(SETUP)，RTSP建立命令(SETUP)告诉服务器当前客户端用于接收媒体数据的端口号。 ●流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始使 用UDP或者TCP传送媒体流(RTP包)到客户端。 ●在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。 ●最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话。RTSP协议与HTTP协议区别 实时流协议(RTSP) 本文为Internet社区描述了一种Internet标准跟踪协议，还需要讨论和建议以便进行改善。请查看最新版本的"Internet正式协议标准"（STD 1）了解本协议的标准化进程和状态。本备忘录的传播不受限制。 版权声明： 摘要： 实时流协议（RTSP）是应用层协议，控制实时数据的传送。RTSP提供了一个可扩展框架，使受控、按需传输实时数据（如音频与视频）成为可能。数据源包括现场数据与存储在剪辑中的数据。本协议旨在于控制多个数据发送会话，提供了一种选择传送途径（如UDP、组播UDP与TCP）的方法，并提供了一种选择基于RTP (RFC1889)的传送机制的方法。 目录： 1 介绍 1.1 目的 1.2 要求 1.3 术语 1.4 协议特性 1.5 RTSP扩展 1.6 整体运作 1.7 RTSP状态 1.8 与其他协议的关系 2 符号协定 3 协议参数 3.1 RTSP版本 3.2 RTSP URL 3.3 会议标识 3.4 会话标识 3.5 SMPTE 相对时间戳 3.6正常播放时间 3.7 绝对时间 3.8 选项标签 3.8.1 用IANA注册新的选项标签*4 RTSP消息 4.1 消息类型 4.2 消息头 4.3 消息主体 4.4 消息长度 *5 普通头部段 *6 请求 6.1 请求行 6.2 请求消息头段 *7 响应 7.1 状态行 7.1.1 状态码和原因短语 7.1.2 响应头部段 *8 实体 8.1 实体头部域 8.2 实体主体24 *9 连接 9.1 流水线化25 9.2 可靠性及确认25 *10 方法定义25 10.1 可选项26 10.2 描述26 10.3 通知26 10.4 建立26 10.5 播放27 10.6 暂停27 10.7 断开27 10.8 获取参数28 RTP、RTCP、RTSP协议详解 一、RTP协议 实时传输协议（RTP）为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在UDP 上运行RTP以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是RTP可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么RTP可以使用该组播表传输数据到多个目的地。 RTP本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。RTP协议并不保证传送或防止无序传送，也不确定底层网络的可靠性。RTP 实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。 RTP协议由两个紧密链接部分组成： RTP―传送具有实时属性的数据； RTP控制协议（RTCP）―监控服务质量并传送正在进行的会话参与者的相关信息。RTCP 第二方面的功能对于“松散受控”会话是足够的，也就是说，在没有明确的成员控制和组织的情况下，它并不非得用来支持一个应用程序的所有控制通信请求。 协议结构 1238916bitVPXCSRC CountMPayload TypeSequence numberTimestampSSRCCSRC (variable 0 –15 items 32bits each)V ―版本。识别RTP版本。 P ―间隙（Padding）。设置时，数据包包含一个或多个附加间隙位组，其中这部分不属于有效载荷。 X ―扩展位。设置时，在固定头后面，根据指定格式设置一个扩展头。 CSRC Count ―包含CSRC 标识符（在固定头后）的编号。 M ―标记。标记由Profile 文件定义。允许重要事件如帧边界在数据包流中进行标记。 Payload Type ―识别RTP有效载荷的格式，并通过应用程序决定其解释。Profile 文件规定了从Payload 编码到Payload 格式的缺省静态映射。另外的Payload Type 编码可能通过非RTP方法实现动态定义。 Sequence Number ―每发送一个RTP数据包，序列号增加1。接收方可以依次检测数据包的丢失并恢复数据包序列。 Timestamp ―反映RTP数据包中的第一个八位组的采样时间。采样时间必须通过时钟及时提供线性无变化增量获取，以支持同步和抖动计算。 SSRC ―同步源。该标识符随机选择，旨在确保在同一个RTP协议会话中不存在两个同步源具有相同的SSRC 标识符。 CSRC ―贡献源标识符。识别该数据包中的有效载荷的贡献源。 二、RTCP：RTP 控制协议 RTP 控制协议（RTCP）采用与数据包相同的分发机制，将控制包周期性传输到所有会话参与者中。底层协议必须提供数据和控制包的多路发送，例如使用不同的UDP 端口号。RTCP 主要完成四个功能服务： RTCP 提供数据分发质量反馈信息。这是RTP 作为传输协议的部分功能并且它涉及到了其它传输协议的流控制和拥塞控制。 RTCP 为RTP 源携带一个持久性传输层标识符，称为规范名或CNAME 。由于一旦发现冲突或程序重启时，SSRC 标识符会随之改变，所以接收方需要CNAME 来跟踪每一个 竭诚为您提供优质文档/双击可除 rtsp协议摄像头 篇一：使用海康摄像头实现实时监控 使用海康摄像头实现实时监控 1.基于Rtsp协议的windows平台监控。 1.1选取海康网络摄像头（支持Rtsp，标准h.264Rtp 封装的设备）。 1.2.按照摄像头的使用说明书部署。假设访问ip地址是：http://192.168.0.64，登录后设置输出端口为：81，则完整的取流地址为：主码流 rtsp://admin:12345@192.0.0.64:81/h264/ch1/main/av_s tream rtsp://admin:12345@192.0.0.64:81/mpeg-4/ch1/main/av _stream 子码流： rtsp://admin:12345@192.0.0.64/mpeg4/ch1/sub/av_stre am rtsp://admin:12345@192.0.0.64/h264/ch1/sub/av_strea m 1.3.使用Vlc（支持标准的Rtsp流媒体）的播放器可以实时播放。 2.基于active控件的网页监控。 2.1.选取海康网络摄像头并进行部署，假设访问地址为：http://192.168.0.64:6666。 2.2.访问http://192.168.0.64:6666，ie浏览器会提 示需要安装active控件，将active控件存储到本地（ipcameraactivex.cab.cab）。 2.3.解压ipcameraactivex.cab，用记事本打开ipcameraactivex.inf文件，查看代码段： [netVideoactivex23.ocx] file-win32-x86=thiscab Registerserver=yes clsid={caFcF48d-8e34-4490-8154-026191d73924} destdir=11 FileVersion=2,3,21,1 2.4.记录上面的“clsid”。 2.5.在网页中注册上述ocx控件，使用js调用控件的 Network Working Group H. Schulzrinne Request for Comments: 2326 Columbia U. Category: Standards Track A. Rao Netscape R. Lanphier RealNetworks April 1998 翻译： radium 2005.1 实时流协议(RTSP) ( Real Time Streaming Protocol (RTSP) ) 备忘录的状态： 本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。本备忘录的发布不受任何限制。 版权声明： 版权为The Internet Society 所有。所有权利保留。 摘要： 实时流协议（RTSP）是应用层协议，控制实时数据的传送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于 RTP(RFC1889)上传送机制提供方法。 目录： 1 绪论 5 1.1 目的 5 1.2 要求 6 1.3 术语 6 1.4 协议特点 7 1.5 RTSP扩展 8 1.6 操作模式 9 1.7 RTSP状态 9 1.8 与其他协议关系 10 2 符号协定 10 3 协议参数 10 3.1 RTSP版本 10 3.2 RTSP URL 11 3.3 会议标识 13 3.4 会话标识 13 3.5 SMPTE 相对时间戳 13 3.6正常播放时间 14 3.7 绝对时间 15 3.8 选择标签 15 3.8.1 用IANA注册新的选择标签 15 4 RTSP消息 15 4.1 消息类型 16 4.2 消息标题 17 4.3 消息主体 17 4.4 消息长度 18 5 普通标题域 18 6 请求 19 6.1 请求队列 19 6.2 请求标题域 19 7 回应 20 7.1 状态行 20 7.1.1 状态代码和原因分析 20 7.1.2 回应标题域 23 8 实体 23 8.1 实体标题域 24 8.2 实体主体 24 9 连接 25 9.1 流水线操作 25 9.2 可靠性及确认 25 10 方法定义 25 10.1 选择 26 10.2 描述 26 10.3 通告 26 10.4 建立 26RTSP(实时流媒体协议)
RTSP协议学习笔记(学习流媒体的时候自己总结的)
RTC PRTP RTSP协议简介
RTSP协议学习笔记
RTSP中文版(实时流媒体协议)
rtsp协议摄像头
RTSP协议
防火墙RTSP协议处理流程及RTSP ALG应用
RTSP协议介绍
RTSP协议与HTTP协议
RTSP协议转换RTMP直播协议
rtsp摘要认证协议(Response计算方法)
音视频—RTSP协议简介
RTSP中文版(实时流媒体协议)资料
RTPRTCPRTSP协议详解
rtsp协议摄像头
实时流协议(RTSP)