RFC 2326
RTSP Spec中文版(1-11)
RTSP Spec中文版(12-16)
RTSP Spec中文版(附录)

1 Introduction

1.1 Purpose

RTSP（Real-Time Straeming Protocol，实时流协议）建立并控制一至多个连接的时间同步流，尽管交错（interleaving）媒体流和控制流是可行的，但通常RTSP并不直接参与数据传送。换言之，RTSP实际上只为多媒体服务器中“网络远程控制”功能。

可被控制的一系列流整体定义为呈现描述（presentation description）。本篇并未定义呈现描述的具体格式。

RTSP中并没有连接（connection）的概念，服务器（Server）只管理通过标识符进行标记的会话（session）。RTSP会话也从并未绑定至任何传输层连接（如TCP）。在一个RTSP会话生命周期中，RTSP客户端（Client）可能打开、关闭许多可靠传输层连接以向服务器发出RTSP请求（request）。此外，RTSP也有可能使用如UDP的无连接传输协议。

RTSP控制的流可能通过RTP传输，但并不意味着RTSP依赖于某一种具体传输机制。RTSP在语法和操作上域HTTP/1.1比较类似，因此HTTP的大部分扩展机制均可以生效于RTSP。但RTSP在如下重要方面依然与HTTP有所不同：

• RTSP引入了一些新方法，并有了新的协议标识
• RTSP服务器默认情况下均需维护状态，这一点与默认无状态的HTTP截然相反
• RTSP中服务器和客户端年均可以发出请求
• RTSP中数据通过其他协议以带外方式传输
• RTSP使用ISO 10646（UTF-8）而不是ISO 8859-1标准，有效利用了许多HTML国际化成果
• RTSP-URI只能使用绝对URI，而HTTP/1.1为了兼容旧版本，将字段分成了两部分

RTSP支持如下操作：

• 从媒体服务器获取媒体数据
  客户端可通过HTTP或其他方式获取呈现描述，如果呈现描述是多播的，那么描述中将会包含多播地址和端口；如果呈现描述是单播的，则处于安全性考虑，客户端需提供地址和端口。
• 邀请服务器参与会议
  服务器可被邀请至一个已存在的会议，或是向呈现中播放媒体文件，或是负责呈现的录制。该模式在分布式教学应用中特别有效。同一会议中的不同参与者可能轮流掌握控制权。
• 动态插入媒体至已存在呈现中
  尤其在直播场景下，服务器如能通知客户端可用的新增媒体将会十分有用

RTSP请求可能和HTTP/1.1一样，被代理（proxy）、隧道（tunnel）以及缓存（cache）处理。

1.2 Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].

1.3 术语（Terminology）

部分术语采自HTTP/1.1，不再赘述。此处仅列出其余字段：

• 聚合控制（Aggregate control）
  服务器对遵循同一时间线的多个流的控制。对于音视频而言，这代表着客户端可通过一条play/pause消息来控制所有音视频流。
• 会议（Conference）
  一个以上参与者的多媒体呈现。
• 客户端（Client）
  客户端从媒体服务器请求连续媒体数据。
• 连接（Connection）
  为了通讯而在两个进程间建立的传输层虚拟回路。
• 容器文件（Container file）
  容器文件用于包含组成一个呈现的一至多个媒体流。尽管容器文件的概念并不属于协议，当RTSP服务器仍可以为这些文件提供聚合控制。
• 连续媒体数据（Continuous media）
  source和sink间有时序关系的数据，即sink必须重现出source中数据间的时序关系。最普通的例子是音视频动画。连续媒体可能是交互式的严格实时流，也可以是宽松的点播流。
• Entity（实体）
  request/response中负载部分传递的信息，Entity由包含元信息的header域和包含内容的body域构成。
• 媒体初始化（Media initialization）
  Dattype/codec特定初始化，包括了时钟频率、颜色表等信息。任何客户端所需的用于媒体流播放的（传输层以外的信息）均在流初始化中的媒体初始化阶段发生。
• 媒体参数（Media Parameter）
  媒体类型的特定参数可在流播放期间动态调整。
• 媒体服务器（Media Server）
  服务器为一至多个流提供点播或录制服务，同一呈现中的不同媒体流可能源自不同媒体服务器。媒体服务器既可以和Web服务器处于同一主机，也可位于不同主机上。
• 媒体服务器重定向（Media Server indirection）
  将媒体客户端重定向至不同媒体服务器。
• 媒体流（Media Stream）
  媒体实例，如声音流、视频流等。使用RTP协议时，RTP会话中的Source可以创建一个包含所有RTP和RTCP分组的流。
• 消息（Message）
  RTSP通讯的基本单位，由[15节]中定义的结构化的八进制位组构成，并通过有连接和无连接协议进行传输。
• 参与者（Participant）
  会议参与者，有可能是机器。如媒体录制、点播服务器。
• 呈现（Presentation）
  呈现使用呈现描述来表示一系列展示给客户端的流，在大多数RTSP场景下，这表示对所有流的聚合操作，但并非强制。
• 呈现描述（Presentation description）
  呈现描述包含了呈现中所有流的信息，如编码、网络地址以及内容信息。其他IETF协议如SDP(RFC 2327[6])使用名词“会话”来表示运行中呈现。呈现描述有多种格式，包含但不限于SDP格式。
• 回复（Response）
  RTSP回复，与HTTP回复类似
• 请求（Request）
  RTSP请求，与HTTP请求类似
• RTSP会话（session）
  RTSP完整交互过程，如影片播放。典型交互过程包括：
  • SETUP 客户端建立用于传输连续媒体的机制
  • PLAY/RECORD 开始串流
  • TEARDOWN 关闭串流
• 传输初始化（Transport initialization）
  客户端和服务器间传输信息初始化

1.4 协议特性（Protocol Properties）

RTSP具有如下特性：

• 可扩展（Extendable）
  新方法和参数可方便地添加至RTSP
• 易解析（Easy to parse）
  RTSP可被标准HTTP或MIME解析器解析
• 安全性（Secure）
  RTSP重用了Web安全机制，所有的HTTP授权机制如basic、digest授权均可直接使用。甚至RTSP还可以重用传输层和网络层的安全机制。
• 传输层独立性（Transport-independent）
  RTSP可能会使用不可靠数据报协议UDP、可靠数据报协议RDP（RFC 1151，不常用）、或保证了应用层可靠性的可靠流协议如TCP。
• 多服务器兼容（Multi-server capable）
  呈现中的各个媒体流可分布在不同服务器上，客户端会与不同服务器自动建立多个并行的控制会话，而同步功能则在传输层完成即可
• 录制设备控制（Control of recording devices）
  RTSP可控制录制和点播设备，当然也能控制可在两种模式切换的设备（VCR）
• 媒体控制和会议初始化相独立（Separation of stream control and conference initiation）
  媒体控制在邀请一个媒体服务器进入会议时分割，唯一的前提是会议初始化协议需要提供或可被用于创建一个单独的会议标识符。实践中，通常会使用SIP和H.323协议来邀请某个服务器进入会议。
• 适用于专业应用（Suitable for professional applications）
  RTSP可通过SMPTE时间戳来提供帧精度的远程数字化编辑
• 中立的呈现描述（Presentation description neutral）
  RTSP并没有将呈现描述具体化，并且可携带当前使用的描述格式。但至少，呈现描述中要包含一个RTSP URI.
• 代理和防火墙亲和性（Proxy and firewall friendly）
  RTSP协议可被应用和传输层防火墙处理，防火墙可能需要识别SETUP方法，以为特定UDP媒体流开辟通道。
• HTTP亲和性（HTTP-friendly）
  由于RTSP明智地重用了HTTP的概念，所以现有的框架都可以被重用，如用于关联内容和标签的PICS(Platform for Internet Content Selection)。除此之外，RTSP也不仅仅只是在HTTP基础上添加方法而已，多数时候，RTSP还需要维护服务器状态来实现连续媒体的控制。
• 恰当的服务器控制（Appropriate server control）
  如果一个客户端可以开启一个流，那么理论上它应关闭该流的能力，这种情况下，服务器决不能向客户端传输客户端本身不能关闭的流。
• 传输协商（Transport negotiation）
  客户端可根据实际需要协商连续媒体流的传输方法
• 能力协商（Capability negotiation）
  如某些基础特性已禁用，则应该要有一些明确的机制告知客户端不去实现哪些方法，这使得客户端可以提供合适的用户接口。例如，当seeking不支持时。用户界面应禁止移动滚动条。

1.5 扩展RTSP(Extending RTSP)

由于并非所有媒体服务器都提供相同功能，媒体服务器也自然会支持不同的请求集。例如：

• 一个服务器可能只支持点播，也就不用支持RECORD请求
• 如果一个服务器只支持直播，那么它可能不支持seeking
• 有些服务器并不支持流参数的设置，也自然不需要支持GET_PARAMETER和SET_PARAMETER

*当然服务器必须实现[12小节]中提及的所有header域，而[H19.6]中所有方法都不用做支持。 *

RTSP可通过三种方式进行扩展，根据变化大小排列如下：

• 已存在方法可添加新参数，接收者也可以安全地选择忽略新增参数。如果客户端需要在某个方法扩展部分不支持时得到否定确认，需要在Require: 域中添加标签（见12.32小节）
• 可添加新方法，如果接收者不理解该请求，可回复错误代码501（未实现），之后发送者不应再尝试使用该方法。客户端可以使用OPTIONS方法来查询服务器所支持的方法，服务器则应在公共回复头（Public response header）中列出所支持的方法
• 可定义新版本协议，几乎允许变动所有元素

1.6 全局操作（Overall Operations）

每个呈现和流都使用RTSP URL进行标识，整体呈现及媒体其他属性均定义于呈现描述文件中，用户可通过HTTP或其他方式（如email）进行获取，因此呈现描述文件不一定非要存放在媒体服务器上。

对于本篇而言，呈现描述用于描述一至多个呈现，每个呈现维护正常时间轴。为了便于解释以及保持通用性，这里假设呈现描述中只包含一个这样的呈现，而每个呈现可能进一步包含多个媒体流。

呈现描述文件包含了组成呈现的所有媒体流的描述，包括编码、语言及其他供客户端正确选择最合适媒体组合的信息。媒体呈现中每个被RTSP独立控制的媒体流都有一个RTSP URL作为标识，该URL指向媒体流被存放的服务器。不同媒体流可源自不同服务器，例如，音频和视频流可能因为负载均衡而被分割至不同服务器。媒体呈现中同样还枚举了所有支持的传输方式。

除媒体参数外，网络目标地址和端口必须确认下来，具体需区分为如下几类：

• 单播（Unicast）
  媒体传送至RTSP请求的发起者，端口由客户端选择。
• 多播，服务器选择地址和端口
  服务器选择多播地址和端口，典型应用时直播和点播传输。
• 多播，客户端选择地址和端口
  如果服务器被中途邀请至一个已存在的多播会议，会议描述中会包含地址和端口，具体建立过程不在本篇讨论范围之内。

1.7 RTSP 状态

RTSP可能控制一个通过单独协议、独立于控制频道传输的流。例如，RTSP可能使用TCP连接来控制通过UDP传输的数据流，这样一来，即使服务器中间没有收到任何RTSO请求，数据依然可以保持连续传送。整个生命周期内，同一个流可能依次被通过不同TCP连接传输而来的RTSP请求控制。因此，服务器需要维护会话状态以便能够正确关联同一个流的RTSP请求。状态转换在[附录A]中有详细描述。

RTSP中许多方法并不会改变状态，会修改状态的方法有如下几个：

• SETUP
  使服务器为流分配资源并开启RTSP会话
• PLAY和RECORD
  在SETUP中分配的流上开始数据传送
• PAUSE
  临时冻结流，并不会释放服务器资源
• TEARDOWN
  释放流相关的资源，服务器上RTSP会话会被停止

会修改会话状态的方法会在header域中指明会话标识符以明确方法作用对象，该会话标识符在SETUP步骤中生成。

1.8 与其他协议的关系（Relationship with Other Protocols）

RTSP和HTTP在功能上有重叠的部分，甚至流内容可能会通过网页形式与HTTP交互获得。当前协议规格目标是允许网络服务器和实现了RTSP的媒体服务器有不同的切换点。如描述实现可通过HTTP或RTSP获取，这减少了网络浏览场景下的响应时间，当然只通过RTSP服务器和客户端而不依赖HTTP也是可行的。

然而，RTSP在数据传输上与HTTP有本质区别，因为RTSP是用不同协议以带外方式传输。HTTP是一个不对称协议，只允许客户端发出请求，然后服务器负责回复。而在RTSP中，客户端和媒体服务器均可以发出请求。进一步有，RTSP请求是有状态的，他们可能需要在请求得到确认应答后才会进一步设置参数和后续控制。

重用HTTP功能至少带来了两个好处，即安全性和代理。所需基础十分类似，因此拥有在HTTP缓存、代理和认证的能力是十分有益的。

尽管大多数实时媒体均会选择RTP作为传输协议，但RTSP并没有绑定使用RTP。

RTSP假设呈现描述格式可以表达呈现中媒体流的静态和临时特性。

2. 标志性公约（Notational Conventions）

由于很多定义和语法都与HTTP/1.1相同，因此本规格只是给出了对应章节的位置而不是重复拷贝。为了简短说明，[HX.Y]表示HTTP/1.1当前规格（RFC 2068）中对应的这章节 X.Y。

文中提到的所有机制都以[H2.1]中使用的ABNF（augmented Backus-Naur form）格式给出，ABNF在RFC 2234中有详细说明，with the
difference that this RTSP specification maintains the "1#" notation
for comma-separated lists.

3. 协议参数

3.1 RTSP版本

RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT

3.2 RTSP URL

"rtsp"和"rtspu"用于在RTSP协议中关联网络资源。

rtsp_URL = ("rtsp:" | “rtspu:") "//" host [":" port] [abs_path]

注意：上述字段均无严格定义，最终解释权归RTSP服务器所有

rtsp表示使用可靠协议传输（如TCP），而rtspu表示使用不可靠协议传输（如Internet, UDP）。
如port未给出，则默认使用554端口。字段中尽量避免直接使用IP地址，而应该使用域名代替。

描述或流均通过文本形式的媒体标识符进行表示，URL可能指向某一个流，也可能指向一系列聚合流。注意有的方法只能针对流或只能针对呈现，不能混用。

rtsp://media.example.com:554/twist/audiotrack   只操作audio
rtsp://media.example.com:554/twist              聚合操作

注意上述各字段暂无公认定义，最终解释权仍旧归属于RTSP服务器，应尽量避免在URL中直接使用IP地址。

3.3 会议标识符（Conference Identifiers）

会议标识符使用标准URI编码方式编码，对RTSP是不透明的。标识符中可包含任意八进制值，但标识符必须是全局唯一的。

conference-id = 1*xchar

RTSP会话可使用会议标识符来获取媒体服务器要加入的多媒体会议参数，这些会议由本篇外协议创建，如H.323或SIP。与通常由RTSP客户端提供传输信息相反，这种情况下通常媒体服务器直接使用直接会议描述值。

3.4 会话标识符（Session Identifiers）

会话标识符以变长字符串形式存在，中间如有空格，则以URL转义。会话标识符必须随机选择且至少八位八进制值以上，以避免与现有标识符发生冲突。

session-id = 1*(ALPHA | DIGTI | safe)

3.5 SMPTE相对时间戳（SMPTE Relative Timestamps）

SMPTE表示当前相对于起始位置（start）的时间，使用SMPTE时间格式（hours:minutes:seconds:frames.subframes）的相对时间戳可以达到帧级别精度。SMPTE格式默认值为“SMPTE 30 drop”格式，对应到帧率为29.97fps。其他SMPTE码值（如SMPTE 25）可能通过使用替代的"smpte time"进行支持。帧率30和帧率29.97的主要区别是29.97会丢掉每分钟的前两帧，但每第十分钟跳过丢弃操作。如smpte-time值为0，则忽略该选项。

smpte-range = smpte-type "=" smpte-time “-" [smpte-time]
smpte-type = "smpte" | "smpte-30-drop" | "smpte-25"     ; other timecodes may be added
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [":" 1*2DIGIT] ["." 1*2DIGIT]

Examples:
    smpte=10:12:33:20-
    smpte=10:07:33-
    smpte=10:07:00-10:07:33:05.01
    smpte-25=10:07:00-10:07:33:05.01

3.6 正常播放时间（Normal Play Time）

NPT表示从开始呈现到现在流的绝对位置，该时间戳包含一个十进制小数，小数点左侧的可能是小时、分钟和秒，右侧部分则为秒的小数部分。

呈现开始位置NPT值为0.0秒，不能去负值。特殊常量now定义于直播场景下表示当前实例，它可能仅在直播情境下被支持。

直观地讲，NPT是联系用户和程序的时钟，它经常以数字形式显示在VCR上，当播放速率为1时，它正常递增；当大于1时，加速递增；当小于-1时，加速递减，直到经过pause状态时恢复为1。逻辑上讲，NPT和SMPTE时间码是一致的。

npt-range = (npt-time "-" [ npt-time ]) | ("-" npt-time)
npt-time = "now" | npt-sec | npt-hhmmss
npt-sec = 1*DIGIT ["." *DIGIT]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss ["." *DIGIT]
npt-hh = 1*DIGIT    ; any positive number
npt-mm = 1*2DIGIT   ; 0-59
npt-ss = 1*2DIGIT   ; 0-69

Examples:
    npt=123.45-125
    npt=12:05:35.3-
    npt=now-

其语法符合ISO 8601. npt-sec概念主要用于自动化生成，npt-hhmmss概念则是为了便于用户阅读。
常量"now"则用于在直播情境下实时获取当前时间戳而非存储或有延迟的版本。

3.7 绝对时间（Absolute Time）

绝对时间使用UTC标准，遵循ISO 8601时间戳格式。

utc-range = "clock" "=" utc-time "-" [utc-time]
utc-time = utc-date "T" utc-time "Z"
utc-date = 8DIGIT                   ; <YYYYMMDD>
utc-time = 6DIGIT["." fraction]     ; <HHMMSS.fraction>

Example:
    19961108T143720.25Z

3.8 选项标签（Option Tags）

选项标签是RTSP中用于指派新选项的唯一标识符，这些标签在Require[12.32小节]和Proxy-Require[12.27小节]header域中使用。

option-tag = 1*xchar

RTSP选项的创建者可以选择以倒置的域名作为前缀，或在IANA上注册新的选项。

3.8.1 IANA注册新选项标签（Registering New Option Tags with IANA）

在注册新RTSP选项时，需提供如下信息：

• 选项名称及描述，名称长度可变，但建议小于20字符长度。同样，名称不建议包含空格等特殊字符
• 指明选项修改控制权归属，如IETF，ISO，ITU-T及其他国际化标准组织
• 尽可能提供详述连接，如RFC
• 联系方式，如email

4. RTSP消息（RTSP Message）

RTSP是文本协议，使用ISO 10646字符集，并采用UTF-8编码。文本行通常以CRLF结尾，但接收者应做好以CR/LF为行尾标志的准备。

文本协议使得以自我描述的方式添加新参数成为可能，基于参数个数以及命令使用频率较低，效率部分可不必过分在意。如果谨慎处理文本协议，还可以更好地与脚本语言如Tcl，Visual Basic及Perl进行对接。  

RTSP消息可通过任何8-bit clean(每个字符使用8位传输)的传输层协议传输。

RTSP包含方法、作用对象及进一步调整方法的参数。方法可设计为需要少量或完全不需要服务器配合维护状态。

4.1 消息类型（Message Types）

RTSP-message = Request | Response   

考虑到健壮性，服务器应忽略任何在期望收到请求行时收到的空白行CRLF。

4.2 消息头（Message Headers）

RTSP-header = field-name ":" [field-name] CRLF

4.3 消息体（Message Body）

仅在使用传输编码时消息体和实体主体才有所不同

message-body = entity-body | <entity-body encoded as per Transfer-Encoding>

4.4 消息长度（Message Length）

当消息中包含消息体时，body长度按如下次序进行确认：

• 回复消息中不允许包含消息体，通常会在header域后的空行终止
• Content-Length 默认值为0，如不为0则其值为消息体字节数
• 服务器关闭连接时

注意RTSP并不支持HTTP/1.1中块传输编码，它要求必须要有Content-Length字段。

5. 通用头域（General Header Fields）

general-header = Cache-Control | Connection | Date | Via

6. 请求（Request）

Request = Request-Line 
        *( general-header | request-header | entity-header )
        CRLF
        [ message-body ]

6.1 Request Line

Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Method = "DESCRIBE" 
        | "ANNOUNCE" 
        | "GET_PARAMETER" 
        | "OPTIONS" 
        | "PAUSE" 
        | "PLAY"
        | "RECORD" 
        | "REDIRECT" 
        | "SETUP" 
        | "SET_PARAMETER" 
        | "TEARDOWN"
        | extension-method
extension-method = token
Request-URI = "*" | absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT

6.2 Request Header Fields

request-header = Accept
                | Accept-Encoding
                | Accept-Language
                | Authorization
                | From
                | If-Modified-Since
                | Range
                | Referer
                | User-Agent

注意：与HTTP/1.1不同，RTSP请求中始终使用绝对URL，而非只是用绝对路径。

RTSP-URI中'*'表示请求并非针对某一特定资源，而是针对服务器本身，且该方式只能在不针对特定资源时使用。举例如下：

OPTIONS * RTSP/1.0

7 回复（Response）

回复除了HTTP-Version字段替换为RTSP-version外，基本沿用了HTTP中内容。当然，RTSP还选择性实现了一些HTTP状态码，并增加了部分特定状态码。

Response = Status-Line
        *(general-header
        | response-header
        | entity-header)
        CRLF
        [meassage-body]

7.1 状态行（Status-Line）

Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF

结尾处必须以CRLF标志结尾，不允许以CR或LF形式单独存在

7.1.1 状态码和原因词组（Status Code and Reason Phrase）

状态码是一个3位十进制数，表示对端对于之前请求的理解和执行状态。这些状态码在11小节会完整列出，便于机器识别。
原因词组意在给出状态码的简略文本描述，便于用户读取。客户端并不要求去检查或显示状态词组。

状态码首位用于定义不同类型的回复，其余两位暂未定义：

• 1xx: 提示信息（Informational）- 请求已收到，处理中
• 2xx：成功（Success）- 操作已被成功接收、理解并执行
• 3xx：重定向（Redirection）- 需进一步操作以完成整个请求
• 4xx：客户端错误（Client Error）- 请求中包含错误语法或不完整
• 5xx：服务器错误（Server Error）- 服务器无法正确执行请求

下面列出RTSP/1.0中特有的状态码及原因词组：

Status-Code = "100"     ; Continue
            | "200"     ; OK
            | "201"     ; Created
            | "250"     ; Low on Storage Space
            | "300"     ; Multiple Choices
            | "301"     ; Moved Permanently
            | "302"     ; Moved Temporarily
            | ”303“     ; See Other
            | "304"     ; Not Modified
            | "305"     ; Use Proxy
            | "400"     ; Bad Request
            | "401"     ; Unauthorized
            | "402"     ; Payment Required
            | "403"     ; Forbidden
            | "404"     ; Not Found
            | "405"     ; Method Not Allowed
            | "406"     ; Not Acceptable
            | "407"     ; Proxy Authentication Required
            | "408"     ; Request Time-out
            | "410"     ; Gone
            | "411"     ; Length Required
            | "412"     ; Precondition Failed
            | "413"     ; Request Entity Too Large
            | "414"     ; Request-URI Too Large
            | "415"     ; Unsupported Media Type
            | "451"     ; Parameter Not Understood
            | "452"     ; Conference Not Found
            | "453"     ; Not Enougn Bandwidth
            | "454"     ; Session Not Found
            | "455"     ; Method Not Valid in This State
            | "456"     ; Header Field Not Valid for Resource
            | "457"     ; Invalid Range
            | "458"     ; Parameter Is Read-Only
            | "459"     ; Aggregate operation not allowed
            | "460"     ; Only aggregate operation allowed
            | "461"     ; Unsupported transport
            | "462"     ; Destination unreachable
            | "500"     ; Internal Server Error
            | "501"     ; Not Implemented
            | "502"     ; Bad Gateway
            | "503"     ; Service Unavailable
            | "504"     ; Gateway Time-out
            | "505"     ; RTSP Version not supported
            | "551"     ; Option not supported
            | extension-code
            
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>

RTSP状态码是可扩展的，RTSP应用并不要求支持所有已注册状态码，当然能够支持则更好。但是，应用必须了解状态码的分类，在碰到不能识别的状态码时应将其等同于x00，并将不能识别的回复进行缓存。

举个例子，客户端收到一个不能识别的状态码431，它完全可以将其等同于400，并认定是自己发出的请求出现了问题。在这种情况下，由于实体（entity）中通常会包含关于异常的可读信息，因此客户端应该要将的实体部分呈献给用户。

7.1.2 回复头域（Response Header Fields）

回复头域中传递了状态行不能表达的额外信息，这些头域中给出了服务器和通过Request-URI标识的资源的其他信息。

response-header = Location
                | Proxy-Authenticate
                | Public 
                | Retry-After
                | Server
                | Vary
                | WWW-Authenticate

回复头域名称只有和协议版本一块修改时才能保证可靠性，也就是说，只有当通讯的所有参与者都能正确识别某一字段为回复头域时，才会将其新增至头域中。不能识别的头域则会统一视为实体头域（entity-header fields）。

8 实体（Entity）

如请求方法和回复状态码未限制，可在请求或回复中传输实体。一个实体由实体头和实体主体（entity-body）组成，虽然有些回复中只有实体头部分。

本节中客户端和服务器均可能成为发送端和接收端，身份依具体情况而定。

8.1 实体头域（Entity Header Fields）

实体头域定义了关于实体主体的可选元信息，或当主体不存在时用于描述请求中的资源描述符。

entity-header   = Allow
                | Content-Base
                | Content-Encoding
                | Content-Language
                | Content-Length
                | Content-Location
                | Content-Type
                | Expires
                | Last-Modified
                | extension-header
extension-header = message-header

可扩展头机制使得不修改协议的情况下也可以增加头域成为可能，但这些域接收端不一定能够识别，对于不能识别的域，接收端可直接忽略并传递给代理。

8.2 实体主体（Entity Body）

实体主体只在请求方法有要求时才会被放到请求消息中，且会再Content-Length中指明是否存在主体部分。

9 连接（Connections）

RTSP请求可通过如下三种方式传送：

• 永久性连接，贯穿数个交互（请求/回复） -> rtsp
• 易失性连接，每次交互单独建立 -> rtsp
• 无连接方式，如UDP -> rtspu

传输连接的类型由RTSP URI定义。与HTTP不同的是，RTSP允许服务器向客户端发送请求，但这只能在使用永久性连接时才行，因为除此之外媒体服务器没有其他可靠方法能够与客户端联系。同时，这也是媒体服务器可穿透防火墙和客户端通讯的唯一方式。

9.1 流水操作（Pipelining）

支持永久性连接或无连接模式的客户端可将其请求流水线化后发出，对应的有，服务器也必须按接收到的请求次序进行回复。

9.2 可靠性和确认应答（Reliability and Acknowledgements）

除非请求是发送给广播组的，否则接收者收到请求后必须被确认应答。如果没有确认应答，那么发送者会在触发往返时间RTT(round-trip time)延时后，重新发送同一条消息。往返时间RTT是由TCP进行动态评估的，其初始值为500ms。部分RTSP实现可能会选择缓存最后一个RTT内所有操作，以作为后续连接的初始状态。

但如果传输层协议是TCP时，则不应手动重传，而是依赖TCP所提供的可靠性机制。

如果TCP和RTSP同时重传请求，那么有可能每个分组（packet）丢失都会引起两次重传，接收者也无法真正从应用层重传中获益，因为只有当传输层重传抵达接收端后，才会开始传递应用层的重传分组。更糟糕的是，如果丢失是由与带宽饥荒（congestion）引起，那么多次重传反而会加重饥荒程度。

头中时间戳字段用于配合重传机制，同时也为Kam的算法提供支持。

每个请求头中都有一个单调递增的序号CSeq，需要重传时，将使用原始CSeq。

实现RTSP系统时必须支持通过TCP传输RTSP，然后可选择实现基于UDP的RTSP。RTSP服务器（TCP或UDP）默认端口为554。

一些发给相同控制终端的RTSP分组可能被打包入PUD或封装进TCP流，RTSP数据可与RTP或RTCP分组交错。与HTTP不同的是，RTSP消息中必须含有Content-Length头，即使消息中并无负载。此外，RTSP分组通过最后一个消息头后的空行直接终止。

10 方法定义（Method Definitions）

方法符标识作用于Request-URI指代资源的方法，它是大小写敏感的，且命名时不应以‘$’开头。未来可添加新方法。

P: 呈现（Presentation），S:流（Stream）

PAUSE推荐实现，但也不是必须的，如直播情境。如果一个服务器不支持某一方法，它必须返回“501未实现”错误，且之后客户端不应再尝试请求该方法。

10.1 OPTIONS

OPTIONS请求可能在任意时刻发出，如客户端尝试非标准化请求，并不会影响服务器状态。

示例：
    C->S:   OPTIONS * RTSP/1.0
            CSeq: 1
            Require: implicit-play
            Proxy-Require: gzipped-messages

    S->C:   RTSP/1.0 200 OK
            CSeq: 1
            Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

10.2 DESCRIBE

DESCRIBE用于从服务器中获取URL指定的呈现或媒体对象的描述信息，它可在'Accept'头中指定客户端可以理解的描述信息的格式。服务器则返回请求资源所对应的描述信息。DESCRIBE请求-回复对构成了整个RTSP初始化过程。

示例：
    C->S:   DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
            CSeq: 1
            Accept: application/sdp, application/rtsl, application/mheg
        
    S->C:   RTSP/1.0 200 OK
            CSeq: 312
            Date: 23 Jan 1997 15:25:06 GMT
            Content-Type: applicaiton/sdp
            Content-Length: 376
            
            v=0
            o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
            s=SDP Seminar
            i=A Seminar on the session description protocol
            u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
            e=mjh@isi.edu(Mark Handley)
            c=IN IP4 224.2.17.12/127
            t=2873397496 2873404696
            a=recvonly
            m=audio 3456 RTP/AVP 0
            m=video 2232 RTP/AVP 31
            m=whiteboard 32416 UDP WB
            a=orient:portrait

DESCRIBE回复中必须包含所描述的资源初始化相关所有媒体信息，如果客户端从别处获取了内含完整媒体初始化参数的呈现描述pd，那么客户端应该直接使用那些参数而不用通过RTSP重复请求描述信息。

此外，服务器不能将DESCRIBE回复作为媒体重定向的方法。

无规矩不成方圆，客户端应当明确DESCRIBE方法仅用于获取媒体初始化信息，而不能用来实现媒体重定向。我们也通过其他方法来避免循环问题（looping problems）。

对基于RTSP的系统而言，媒体初始化是必不可少的部分，但RTSP规格中并没有严格指出初始化必须通过DESCRIBE方法。事实上，RTSP客户端通常有如下3种方法来获取初始化信息：

• 通过DESCRIBE方法
• 通过其他协议，如HTTP，email附件等
• 命令行或其他标准输入（类似网络帮助文件，内容sdp或其他媒体格式文件）

实践中，十分推荐精简版服务器去支持DESCRIBE方法，而精简版服务器则十分推荐持根据使用环境从标准输入、命令行或其他方式中获取媒体初始化文件。

10.3 ANNOUNCE

ANNOUNCE方法有两个用途：

• 从服务器发送给客户端时：用于更新实时会话描述
• 从客户端发送给服务器时：推送URL指定的呈现或媒体对象的描述

如果呈现途中插入新流，应重发完整描述，而不仅仅是增量。这样一来，也就支持了动态移除组件。

示例：
    C->S:   ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
            CSeq: 312
            Date: 23 Jan 1997 15:35:06 GMT
            Session: 47112344
            Content-Type: application/sdp
            Content-Length: 332
            
            v=0
            o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
            s=SDP Seminar
            i=A Seminar on the session description protocol
            u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
            e=mjh@isi.edu (Mark Handley)
            c=IN IP4 224.2.17.12/127
            t=2873397496 2873404696
            a=recvonly
            m=audio 3456 RTP/AVP 0
            m=video 2232 RTP/AVP 31

    S->C:   RTSP/1.0 200 OK
            CSeq: 312

10.4 SETUP

SETUP请求用于为URI指定传输机制，客户端可以发出SETUP请求来改变运行中流的传输参数（如服务端不支持，需返回“455 当前状态不支持该方法”），为了尽可能利用交错的防火墙，客户端必须指明其传输参数，即使并无实际影响（如服务器通知一个广播组地址）。

示例：
    C->S:   SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
            CSeq: 302
            Transport: RTP/AVP;unicast;client_port=4588-4589
            
    S->C:   RTSP/1.0 200 OK
            CSeq: 302
            Date: 23 Jan 1997 15:35:06 GMT
            Session: 47112344
            Tranport: RTP/AVP;unicast;client_port=4588-4589;server_port=6256-6257

服务器在SETUP回复中生成了会话标识符（Session），如SETUP请求中已有会话标识符，则服务器应当要么绑定至该会话，要么回复“459聚合操作被禁止”。

10.5 PLAY

PLAY方法通知服务器使用SETUP中确定的机制开始传输数据，客户端不应在SETUP请求未被确认应答成功前发出PLAY请求。

PLAY请求将正常播放时间（Normal Play Time）置为指定范围的开始端，并传输数据直到抵达范围的末端。PLAY请求可能被队列化，即需要排队；服务器必须依次处理队列中的PLAY请求。也就是说，后到的PLAY请求必须等待前一个请求处理完成后才能进行处理。

这使得精细编辑成为可能。

举例来说，无论两个PLAY请求到达服务器时有多接近，服务器依然会先播放10s_{15s内容，然后20s}25s，并最终从30s到结束。

C->S:   PLAY rtsp://audio.example.com/audio RTSP/1.0
        CSeq: 835
        Session: 12345678
        
C->S:   PLAY rtsp://audio.example.com/audio RTSP/1.0
        CSeq:836
        Session: 12345678
        Range: npt=20-25
        
C->S:   PLAY rtsp://audio.example.com/audio RTSP/1.0
        CSeq: 837
        Session: 12345678
        Range: npt=30-

没有Range头的PLAY请求是合法的，它会从头开始播放流（除非流已被暂停PAUSE），而如果流已处于暂停状态，则从暂停点开始播放。如果一个流正处于播放状态，那么新的PLAY请求不会有任何作用，因此可被用于测试服务器是否在线（liveness）。

Range头中也可能存在时间参数，该参数使用UTC标准时间，它指定了开始播放的时间点。如请求到达时已经过了指定时间点，则立即开始播放。时间参数还可用于同步从不同源获得的流。

对于一个点播流而言，服务器回复将播放的准确Range，该值可能与请求的Range有所不同，因为需根据实际的帧边界来重新对齐。如请求中未指定range，回复中返回当前位置。请求和回复将使用同一单位。

当播放完指定Range后，呈现将自动暂停，就像有收到PAUSE请求一样。

示例：
    C->S:   PLAY rtsp://audio.example.com/twister.en RTSP/1.0
            CSeq: 833
            Session: 12345678
            Range: smpte=0:10:20-;time=19970123T153600Z

    S->C:   RTSP/1.0 200 OK
            CSeq: 833
            Date: 23 Jan 1997 15:35:06 GMT
            Range: smpte=0:10:22-;time=19970123T153600Z

播放一个直播中录制的流，可能需要使用clock单位：

    C->S:   PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
            CSeq: 835
            Session: 12345678
            Range: clock=19961108T142300Z-19961108T143520Z
            
    S->C:   RTSP/1.0 200 OK
            CSeq: 835
            Date: 23 Jan 1997 15:35:06 GMT

如媒体服务器只支持点播，则必须支持npt时间格式，而clock和smpte格式则是可选的。

10.6 PAUSE

PAUSE请求会临时终端流传输，如果URL指定的是某一个流，则该流的播放和录制会被暂停。例如，对于音频而言，相当于静音操作。如果URL指定的是一组流，则呈现或组中所有活动流将会被暂停。当恢复播放或录制时，所有轨道的流必须进行同步。
此过程中，所有服务器资源均会保留，除非SETUP时，头中有参数指定延时，那么服务器可能在触发延时后关闭会话并释放资源。

示例：
    C->S:   PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
            CSeq: 834
            Session: 12345678
            
    S->C:   RTSP/1.0 200 OK
            CSeq: 834
            Date: 23 Jan 1997 15:35:06 GMT

PAUSE请求中可能包含Range头以指定何时暂停流或呈现，我们将这个点成为暂停点（pause point），该头中必须指定某一个点而不是时间范围。正常播放时间会设置给暂停点，当服务器第一次碰到暂停点时，暂停请求生效。如果设置的暂停点不在播放段中，则返回“457无效Range”错误。如媒体单元（如音视频帧）正好从暂停点开始播放，那么将不会有任何效果。如不存在Range头，则立即暂停现有状态。

PAUSE请求会忽略所有队列中的PLAY请求，无论如何，媒体流中的暂停点都是需要被维护的。当然后续PLAY不带Range参数时，将从暂停点开始恢复。

举个例子，假如一个服务器收到两个PLAY请求，范围分别是10_15s，2029s，然后紧接着收到NPT21s为暂停点。那么服务器会再播放完第一段后停在NPT21。而如果当服务器在已经播放到13s时收到一个NPT12暂停点的请求，那么将会立即暂停。再假设暂停点为NPT16，那么服务器将在完整播放完第一段后忽略第二段播放请求，进入暂停状态。

如果收到请求时，服务器已发出Range外数据，那么PLAY操作仍然会从指定点开始恢复，因为它假设客户端会忽略暂停点后的数据。这样一来，才能够保证连续的PAUSE/PLAY循环。

10.7 TEARDOWN

TEARDOWN请求将会停止URI指定的流传输，并释放关联资源。如果URI关联的是一个呈现，那么RTSP会话标识符将不再有效。停止后，除非所有传输参数都通过绘画描述来定义，否则重新播放前必须发出SETUP请求。

示例：
    C->S:   TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
            CSeq: 892
            Session: 12345678
            
    S->C:   RTSP/1.0 200 OK
            CSeq: 892

10.8 GET_PARAMETER

GET_PARAMETER请求用于获取URI指定呈现或流的参数值。回复的内容有待实现，不带任何实体主体的GET_PARAMETER可用于测试客户端或服务器是否在线（类似“ping”程序）。

示例：
    S->C:   GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
            CSeq: 431
            Content-Type: text/parameters
            Session: 12345678
            Content-Length: 15
            
            packets_received
            jitter
            
    C->S:   RTSP/1.0 200 OK
            CSeq: 431
            Content-Length: 46
            Content-Type: text/parameters
            
            packets_received: 10
            jitter: 0.3838

10.9 SET_PARAMETER

SET_PARAMETER请求用于设置URI指定呈现或流的参数值。

每条请求应当只包含一个参数以允许客户端确定失败原因，如果请求中包含多个参数，服务器必须只在所有参数都能成功设置情况下生效。服务器应当允许同一参数多次设置同一值，但可拒绝设置为不同值。

注意：媒体流传输参数必须通过SETUP请求来设置

示例：
    C->S:   SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
            CSeq: 421
            Content-Length: 20
            Content-type: text/parameters
            
            barparam: barstuff
            
    S->C:   RTSP/1.0 451 Invalid Parameter
            CSeq: 421
            Content-Length: 10
            Content-type: text/parameters
            
            barparam

10.10 REDIRECT

REDIRECT请求用于提示客户端它必须连接至另一个服务器，其中强制包含了Location头，以指明新的服务器URL。其中还可能包含Range参数，指明何时重定向将生效。如果客户端希望向该URI发送和接收媒体，则客户端必须先对当前会话发出TEARDOWN请求，然后向目标主机发出SETUP请求新的会话。

示例：
    S->C:   REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
            CSeq: 732
            Location: rtsp://bigserver.com:8001
            Range: clock=19960213T143205Z-

10.11 RECORD

RECORD方法用于开始录制当前呈现描述中的一段媒体数据，UTC格式时间戳包含开始点和结尾点。如未给出时间范围，则使用呈现描述中的开始点和结尾点。如会话已处于运行中，则立即开始录制。

服务器决定将录制数据保存在请求URI或其他URI，如使用其他URI，需回复“201（Created）”并包含实体以描述请求状态和新资源位置信息。

一个支持直播情境下录制的服务器必须支持clock格式，这里smpte格式并没有意义。

示例：
    C->S:   RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
            CSeq: 954
            Session: 12345678
            Conference: 128.16.64.19/32492374

10.12 嵌入式二进制数据（Embedded(Interleaved) Binary Data）

某些防火墙设计或其他环境因素可能迫使服务器将RTSP方法交错进流数据中。该种交错操作应尽可能避免，因为它提高了客户端和服务器操作的复杂度，也增加了额外的开销。嵌入式二进制数据应当只在RTSP通过TCP传输时使用。

示例：
    C->S:   SETUP rtsp://foo.com/bar.file RTSP/1.0
            CSeq: 2
            Transport: RTP/AVP/TCP;interleaved=0-1

    S->C:   RTSP/1.0 200 OK
            CSeq: 2
            Date: 05 Jun 1997 18:57:18 GMT
            Transport: RTP/AVP/TCP;interleaved=0-1
            Session: 12345678
    
    C->S:   PLAY rtsp://foo.com/bar.file RTSP/1.0
            CSeq: 3
            Session: 12345678
    
    S->C:   RTSP/1.0 200 OK
            CSeq: 3
            Session: 12345678
            Date: 05 Jun 1997 18:59:15 GMT
            RTP-Info: url=rtsp://foo.com/bar.file;seq=232433；rtptime=972948234
            
    S->C:   $\000{2 byte length}{"length" bytes data, w/RTP header}
    S->C:   $\000{2 byte length}{"length" bytes data, w/RTP header}
    S->C:   $\001{2 byte length}{"length" bytes RTCP packet}

11 状态码定义（Status Code Definitions）

RTSP尽可能重用HTTP状态码，这里不再重复相同部分。

11.1 Success 2xx

11.1.1 250 Low on Storage Space

当服务器收到RECORD请求后发现由于没有足够磁盘空间来存放录制内容时，将会返回该警告信息。如有可能，服务器应当使用Range头指明哪一段可被录制。由于服务器其他进程可能同时消耗磁盘空间，因此该警告信息仅供参考。

11.2 Redirection 3xx

RTSP中，重定向可能用于负载均衡或将请求交给拓扑上更靠近客户端的服务器。确认拓扑上是否更接近的机制不在本规格中讨论。

11.3 Client Error 4xx

11.3.1 405 Method Not Allowed

请求的方法并不允许作用于URI所指定资源，回复中需列出所支持的方法列表。该状态码还可用于回复SETUP申请外的方法。

11.3.2 451 Parameter Not Understood

请求接收者不支持其中一个或多个参数。

11.3.3 452 Conference Not Found

媒体服务器无法识别会议头域中的会议。

11.3.4 453 Not Enough Bandwidth

因为带宽不足而拒绝请求，如预留资源失败

11.3.5 454 Session Not Found

会话头中的RTSP会话标识符未找到、无效或已过期

11.3.6 455 Method Not Valid in This State

客户端或服务器在当前状态下不能处理请求，回复中应包含Allow头以便于错误恢复

11.3.5 456 Header Field Not Valid for Resource

服务器不能使某一必需的请求头生效，如PLAY请求中包含Range头域，但服务器不允许seeking。

11.3.8 457 Invalid Range

给定的Range越界，如超出呈现的结尾点

11.3.9 458 Parameter Is Read-Only

SET_PARAMETER设置的参数只读，不能被修改

11.3.10 459 Aggregate Operation Not Allowed

请求的方法不能作用于聚合URL，该方法可能只支持作用于流URL。

11.3.11 460 Only Aggregate Operation Allowed

请求的方法不能作用于非聚合URL，该方法可能只支持作用于聚合URL。

11.3.12 461 Unsupported Transport

传输域中未包含支持的传输规格

11.3.13 462 Destination Unreachable

因为客户端地址不可达而不能建立数据传输通道。该错误也可能由客户端在传输域中存放了无效的目标地址造成。

11.3.14 551 Option not supported

不支持Require或Proxy-Require域中给定选项，回复中必须指明不支持哪个选项