RTSP协议（14）——标题字段定义
原文第十二章
HTTP/1.1[2]或其他未在此列出的非标准头字段目前没有明确定义的含义，收件人应忽略这些字段。
表3总结了RTSP使用的头字段。类型“g”表示在请求和响应中都可以找到的一般请求头，“R”表示请求头，“R”表示响应头，“e”表示实体头字段。在标有“支持”的列中标有“req.”的字段必须由特定方法的收件人实现，而标有“opt.”的字段是可选的。请注意，并不是所有标记为“req.”的字段都将在每个此类请求中发送。“req.”表示只有客户机（用于响应头）和服务器（用于请求头）必须实现这些字段。最后一列列出了此头字段对其有意义的方法；名称“entity”是指返回消息体的所有方法。在本规范中，描述和GET_PARAMETER属于此类参数。
RTSP头字段概述
1.接受
Accept request header字段可用于指定响应可接受的某些表示描述内容类型。
表示描述的“level”参数被正确地定义为MIME类型注册的一部分，而不是在这里。
语法见[H14.1]。
用法示例：
Accept: application/rtsl, application/sdp;level=2
2.接受编码
见[H14.3]
3.接受语言
见[H14.4]。请注意，指定的语言适用于演示说明和任何原因短语，而不是媒体内容。
4.允许
Allow response header字段列出由请求URI标识的资源支持的方法。此字段的目的是严格通知收件人与资源关联的有效方法。允许标头字段必须出现在405（不允许的方法）响应中。
用法示例：
Allow: SETUP, PLAY, RECORD, SET_PARAMETER
5.授权
见[H14.8]
6.带宽
带宽请求头字段描述客户端可用的估计带宽，表示为正整数，以比特/秒为单位。在RTSP会话期间，可用于客户端的带宽可以改变，例如，由于调制解调器重新训练。
Bandwidth = “Bandwidth” “:” 1*DIGIT
示例：
Bandwidth: 4000
7.块大小
此请求头字段从客户端发送到媒体服务器，请求服务器提供特定的媒体包大小。此数据包大小不包括较低层的标头，如IP、UDP或RTP。服务器可以自由使用小于请求的块大小的块。服务器可以将该分组大小截断为最小的、特定于媒体的块大小的最近倍数，或者在必要时用特定于媒体的块大小覆盖它。块大小必须是以八位字节为单位的正十进制数。如果值在语法上无效，服务器只返回错误（416）。
8.缓存控制
Cache Control general header字段用于指定请求/响应链上所有缓存机制必须遵守的指令。
缓存指令必须由代理或网关应用程序传递，而不管它们对该应用程序的重要性如何，因为这些指令可能适用于请求/响应链上的所有收件人。无法为特定缓存指定cache-directive。
只能在安装请求及其响应中指定缓存控制。注意：Cache Control不像HTTP那样控制响应的缓存，而是控制由安装请求标识的流的缓存。对RTSP请求的响应不可缓存，但要描述的响应除外。
- no-cache:指示媒体流不能缓存在任何位置。这允许源服务器甚至通过已配置为向客户端请求返回过时响应的缓存来阻止缓存。
- public:指示媒体流可由任何缓存缓存。
- private:指示媒体流用于单个用户，不能由共享缓存缓存。私有（非共享）缓存可以缓存媒体流。
- no-transform:中间缓存（代理）可能会发现转换某个流的媒体类型很有用。例如，代理可以在视频格式之间进行转换，以节省缓存空间或减少慢速链路上的通信量。然而，当这些转换应用于特定类型应用程序的流时，可能会出现严重的操作问题。例如，用于医学成像、科学数据分析和那些使用端到端认证的应用程序都依赖于接收与原始实体体一点一滴相同的流。因此，如果响应包含no transform指令，则中间缓存或代理不能更改流的编码。与HTTP不同，RTSP此时不提供部分转换，例如，允许翻译成不同的语言。
- only-if-cached:在某些情况下，例如网络连接非常差的时候，客户机可能希望缓存仅返回其当前存储的那些媒体流，而不从源服务器接收这些媒体流。为此，客户机可以在请求中包含only if cached指令。如果接收到该指令，缓存应该使用与请求的其他约束一致的缓存媒体流进行响应，或者使用504（网关超时）状态进行响应。然而，如果一组高速缓存作为具有良好内部连接性的统一系统来操作，则可以在该组高速缓存内转发这样的请求。
- max-stale:指示客户端愿意接受超过其过期时间的媒体流。如果为max stale分配了一个值，则客户机愿意接受超出其过期时间不超过指定秒数的响应。如果没有为max stale赋值，那么客户机愿意接受任何年龄的过时响应。
- min-fresh:表示客户端愿意接受新鲜度生存期不小于其当前时间加上以秒为单位的指定时间的媒体流。也就是说，客户机需要一个至少在指定的秒数内仍然是新的响应。
- must-revalidate:当缓存接收到的设置响应中存在must revalidate指令时，该缓存不能在条目过时后使用该条目来响应后续请求，而必须先与源服务器重新验证该条目。也就是说，如果仅基于源服务器的Expires，缓存响应过时，那么每次缓存都必须进行端到端的重新验证。）
9.会议
此请求头字段在预先建立的会议和RTSP流之间建立逻辑连接。不能为同一RTSP会话更改会议id。
Conference = “Conference” “:” conference-id
Example: Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
如果会议id无效，则返回响应代码452（452 Conference Not Found）。
10.连接
见[H14.10]
11.内容库
见[H14.11]
12.内容编码
见[H14.12]
13.内容语言
见[H14.13]
14.内容长度
此字段包含方法内容的长度（即，在最后一个标头后面的双CRLF之后）。与HTTP不同，它必须包含在所有包含消息头部分以外内容的消息中。如果缺少，则假定默认值为零。根据[H14.14]进行解释。
15.内容位置
见[H14.15]
16.内容类型
见[H14.18]。注意，适用于RTSP的内容类型在实践中可能仅限于表示描述和参数值类型。
17.CSeq
CSeq字段指定RTSP请求-响应对的序列号。此字段必须出现在所有请求和响应中。对于每个包含给定序列号的RTSP请求，都会有一个具有相同序列号的相应响应。任何重新传输的请求必须包含与原始请求相同的序列号（即，对于相同请求的重新传输，序列号不会递增）。
18.日期
见[H14.19]。
19.到期
Expires entity header字段提供一个日期和时间，在该日期和时间之后，说明或媒体流应被视为过时。解释取决于方法：
DESCRIBE response:Expires标头指示一个日期和时间，在该日期和时间之后，说明应被视为过时。
过时的缓存项通常不会由缓存（代理缓存或用户代理缓存）返回，除非首先使用源服务器（或具有实体新副本的中间缓存）对其进行验证。有关过期模型的进一步讨论，请参见第13节。
Expires字段的存在并不意味着原始资源将在该时间、之前或之后更改或不再存在。
格式为[H3.3]中HTTP date定义的绝对日期和时间；必须采用RFC1123日期格式：
Expires = “Expires” “:” HTTP-date
例如：
Expires: Thu, 01 Dec 1994 16:00:00 GMT
RTSP/1.0客户端和缓存必须将其他无效的日期格式，特别是包括值“0”在内的格式视为过去发生的格式（即“已过期”）。
要将响应标记为“已过期”，源服务器应使用与日期标头值相等的过期日期。要将响应标记为“永不过期”，源服务器应该使用从发送响应起大约一年的过期日期。RTSP/1.0服务器发送的过期日期不应超过一年。
如果媒体流上存在日期值为未来某个时间的Expires标头字段（默认情况下不可缓存），则表示媒体流可缓存，除非缓存控制标头字段另有指示（第12.8节）。
20.从
见[H14.22]。
21.主机
RTSP不需要此HTTP请求头字段。如果发送，则应忽略它。
22.If-Match
见[H14.25]。
该字段对于确保表示描述的完整性特别有用，无论是在通过RTSP外部的方式（例如HTTP）获取表示描述的情况下，还是在服务器实现在描述消息和设置消息之间保证描述的完整性的情况下。
标识符是不透明的标识符，因此不特定于任何特定的会话描述语言。
23.If-Modified-Since
If-Modified-Since-request头字段与descripe和SETUP方法一起使用，使它们成为有条件的。如果自此字段中指定的时间以来未修改请求的变量，则不会从服务器返回描述（descripe）或设置流（SETUP）。相反，将返回304（未修改）响应，而不返回任何消息体。
If-Modified-Since = “If-Modified-Since” “:” HTTP-date
该字段的一个示例是：
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
24.最后修改
The Last-Modified entity-header field indicates the date and time at which the origin server believes the presentation description or media stream was last modified. See [H14.29]. For the methods DESCRIBE or ANNOUNCE, the header field indicates the last modification date and time of the description, for SETUP that of the media stream.
25.位置
见[H14.30]。
26.代理验证
见[H14.33]。
27.代理要求
Proxy Require头用于指示代理必须支持的代理敏感功能。如果代理不支持任何代理要求标头功能，则代理必须向客户端否定地确认这些功能。服务器应将此字段与Require字段同等对待。
有关此消息的机制和用法示例的更多详细信息，请参见第12.32节。
28.公共
见[H14.35]。
29.范围
此请求和响应标头字段指定了一个时间范围。可以用若干单位指定范围。本规范定义了smpte（第3.5节）、npt（第3.6节）和时钟（第3.7节）量程单位。在RTSP中，字节范围[H14.36.1]没有意义，不能使用。标头还可以包含UTC中的时间参数，指定操作生效的时间。支持范围标头的服务器必须了解NPT范围格式，并应了解SMPTE范围格式。范围响应标头指示实际播放或录制的时间范围。如果范围标头以不理解的时间格式给出，则收件人应返回“501未实现”。
范围是半开间隔，包括较低的点，但不包括上限。换句话说，a-b的范围正好从时间a开始，但在b之前停止。仅与媒体单元（例如视频或音频帧）的开始时间相关。例如，假设每隔40毫秒生成一次视频帧。10.0-10.1的范围将包括从10.0或更高时间开始的视频帧，并且将包括从10.08开始的视频帧，即使它持续超过间隔。另一方面，10.0-10.08范围将排除在10.08时的框架。
该符号类似于用于HTTP/1.1[2]字节范围头的符号。它允许客户端从媒体对象中选择摘录，并从给定点播放到结尾，以及从当前位置播放到给定点。回放的开始可以安排在将来的任何时间，尽管服务器可能拒绝在长时间的空闲期间保留服务器资源。
30.参考
见[H14.37]。URL指的是表示描述的URL，通常通过HTTP检索。
31.Retry-After
见[H14.38]。
32.要求
客户机使用Require头来查询服务器可能支持或不支持的选项。服务器必须通过使用不受支持的标头来响应此标头，以否定地确认那些不受支持的选项。
这是为了确保当所有选项都被双方理解时，客户机-服务器交互将毫不延迟地进行，并且只有在选项不被理解的情况下才会减慢速度（如上所述）。对于匹配良好的客户机-服务器对，交互进行得很快，节省了协商机制经常需要的往返时间。此外，当客户端需要服务器无法理解的功能时，它还消除了状态模糊性。
在本例中，“funky feature”是一个feature标记，它向客户机指示虚构的funky参数字段是必需的。“funky feature”和funky参数之间的关系不通过RTSP交换进行通信，因为该关系是“funky feature”的一个不变属性，因此不应与每个交换一起传输。
代理和其他中间设备应该忽略本领域中不了解的特性。如果某个特定的扩展需要中间设备支持它，那么应该在Proxy Require字段中标记该扩展（参见第12.27节）。
33.RTP信息
此字段用于设置播放响应中的RTP特定参数。
- url：指示以下RTP参数对应的流URL。
- seq：指示流的第一个数据包的序列号。这允许客户端在查找时优雅地处理数据包。客户机使用此值区分在查找之前发出的数据包和在查找之后发出的数据包。
- rtptime：指示与范围响应标头中的时间值相对应的RTP时间戳(注意：对于聚合控制，特定流可能不会为返回或暗示的范围时间值实际生成数据包。因此，不能保证序列号由seq指示的数据包实际上具有rtptime指示的时间戳。）客户机使用此值来计算RTP时间到NPT的映射。
RTCP提供从RTP时间戳到NTP时间戳（挂钟）的映射。但是，这些信息不足以生成从RTP时间戳到NPT的映射。此外，为了确保该信息在必要的时间（启动时或寻道之后）可用，并且可靠地传递，将该映射放置在RTSP控制通道中。
为了补偿长时间不间断演示的漂移，RTSP客户机还应该将NPT映射到NTP，使用初始RTCP发送方报告来进行映射，然后使用稍后的报告来检查映射的漂移。
34.缩放
刻度值为1表示以正常的向前观看速率进行正常播放或录制。如果不是1，则该值对应于相对于正常观看速率的速率。例如，比率2表示正常观看率的两倍（“快进”），比率0.5表示正常观看率的一半。换句话说，比率为2时，正常的播放时间会以两倍于挂钟的速率增加。每经过一秒（挂钟）时间，就会传送2秒的内容。负值表示方向相反。
除非速度参数另有要求，否则不得更改数据速率。规模更改的实现取决于服务器和媒体类型。例如，对于视频，服务器可以仅传送关键帧或选定的关键帧。对于音频，它可以在保持音调的同时对音频进行时间缩放，或者，不太理想地，传送音频片段。
服务器应尝试近似查看速率，但可能会限制它支持的缩放值范围。响应必须包含服务器选择的实际缩放值。
如果请求包含范围参数，则新的缩放值将在那时生效。
35.速度
此request header fields参数请求服务器以特定的速度向客户机传递数据，这取决于服务器以给定的速度为媒体流提供服务的能力和愿望。由服务器实现是可选的。默认值是流的比特率。
参数值表示为十进制比率，例如，值为2.0表示数据的传递速度将是正常值的两倍。零的速度无效。如果请求包含范围参数，则新的速度值将在那时生效。
使用此字段可更改用于数据传输的带宽。它适用于需要以较高或较低速率预览演示文稿的特定情况。实现者应该记住，会话的带宽可以事先协商（通过RTSP以外的方式），因此可能需要重新协商。当数据通过UDP传输时，强烈建议使用RTCP等方法来跟踪数据包丢失率。
36.服务器
见[H14.39]
37.会话
此请求和响应标头字段标识由媒体服务器在设置响应中启动并在演示URL上通过拆卸结束的RTSP会话。会话标识符由媒体服务器选择（见第3.4节）。一旦客户机接收到会话标识符，它就必须为与该会话相关的任何请求返回该标识符。如果服务器有其他识别会话的方法（如动态生成的url），则不必设置会话标识符。
超时参数只允许在响应头中使用。服务器使用它向客户机指示，由于缺少活动，在关闭会话之前，服务器准备在两个RTSP命令之间等待多长时间（请参阅A节）。超时以秒为单位，默认值为60秒（1分钟）。
请注意，会话标识符标识跨传输会话或连接的RTSP会话。多个RTSP URL的控制消息可以在单个RTSP会话中发送。因此，只要所有流来自同一服务器，客户机就可以使用同一会话来控制构成表示的许多流(参见第14节中的示例）。但是，来自同一客户端的同一URL的多个“用户”会话必须使用不同的会话标识符。
需要会话标识符来区分来自同一客户端的同一URL的多个传递请求。
如果会话标识符无效，则返回响应454（未找到会话）。
38.时间戳
timestamp general头描述客户机何时向服务器发送请求。时间戳的值仅对客户端重要，并且可以使用任何时间刻度。服务器必须回显完全相同的值，如果它有关于此的准确信息，则可以添加一个浮点数，指示自收到请求以来经过的秒数。客户机使用时间戳来计算到服务器的往返时间，以便它可以调整重新传输的超时值。
39.运输
此请求头指示要使用的传输协议，并为单个流配置其参数，如目标地址、压缩、多播生存时间和目标端口。它设置那些尚未由表示描述确定的值。
传输以逗号分隔，按优先顺序列出。参数可以添加到每个传输中，用分号分隔。
传输报头还可用于更改某些传输参数。服务器可能拒绝更改现有流的参数。
服务器可以在响应中返回传输响应头，以指示实际选择的值。
传输请求头字段可以包含客户端可接受的传输选项列表。在这种情况下，服务器必须返回一个实际选择的选项。
传输说明符的语法为
transport/profile/lower-transport.
“较低传输”参数的默认值特定于配置文件。对于RTP/AVP，默认为UDP。
以下是与传输相关的配置参数：
一般参数：
- unicast | multicast:将尝试单播还是多播传递的互斥指示。默认值为多播。能够处理单播和多播传输的客户机必须通过包含两个完整传输规范（每个规范有单独的参数）来指示这种能力。
- destination:流将被发送到的地址。客户端可以使用destination参数指定多播地址。为了避免无意中成为远程控制拒绝服务攻击的实施者，服务器应该对客户端进行身份验证，并在允许客户端将媒体流定向到服务器未选择的地址之前记录这些尝试。如果RTSP命令是通过UDP发出的，这一点尤其重要，但是实现不能依靠TCP本身作为客户端标识的可靠手段。服务器不应允许客户机将媒体流定向到与来自的地址命令不同的地址。
- source:如果流的源地址不同于可以从RTSP端点地址（回放中的服务器或录制中的客户端）派生的源地址，则可以指定源地址。
这些信息也可以通过SDP获得。但是，由于这是传输的一个特性，而不是媒体初始化，因此此信息的权威来源应该在设置响应中。
- layers:要用于此媒体流的多播层数。层被发送到从目标地址开始的连续地址。
- mode:mode参数指示此会话支持的方法。有效值为播放和录制。如果未提供，则默认为播放。
- append:如果mode参数包含RECORD，则append参数指示媒体数据应附加到现有资源，而不是覆盖它。如果请求追加，而服务器不支持追加，则必须拒绝请求，而不是覆盖URI标识的资源。如果mode参数不包含RECORD，则忽略append参数。
- interleaved:交错参数意味着使用第10.12节中定义的机制，以控制流正在使用的任何协议将媒体流与控制流混合。参数提供要在$语句中使用的通道号。该参数可以被指定为范围，例如，在媒体流的传输选择需要它的情况下，交织＝4-5。
这使得RTP/RTCP的处理方式与UDP类似，即一个通道用于RTP，另一个通道用于RTCP。
特定于多播：
ttl: multicast time-to-live
RTP特定：
-
port：此参数为多播会话提供RTP/RTCP端口对。它被指定为一个范围，例如端口=3456-3457。
-
client_port：此参数提供客户端选择在其上接收媒体数据和控制信息的单播RTP/RTCP端口对。它被指定为一个范围，例如，client_port=3456-3457。
-
server_port：此参数提供服务器选择在其上接收媒体数据和控制信息的单播RTP/RTCP端口对。它被指定为一个范围，例如，服务器\端口=3456-3457。
-
ssrc：ssrc参数表示RTP ssrc[24，秒。3] 媒体服务器应使用（请求）或将使用（响应）的值。此参数仅对单播传输有效。它标识与媒体流关联的同步源。
40.不支持
不支持的响应标头列出了服务器不支持的功能。如果通过Proxy Require字段（第12.32节）指定了该功能，则如果在客户端和服务器之间的路径上有代理，则代理必须插入带有错误消息“551 Option Not Supported”的消息回复。
有关用法示例，请参见第12.32节。
41.用户代理
见[H14.42]
42.变更
见[H14.43]
43.通过
见[H14.44]。
44.WWW-认证
See [H14.46].
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
