计算机]rtsp中文版实时流媒体协议

计算机]rtsp中文版实时流媒体协议内容摘要：

RTSP / 1*DIGIT . 1*DIGIT 注意，主从版本应当被看作单独的整数，因为它们都有可能增加，从而超过一位整 数。 因而， RTSP/ RTSP/，而 RTSP/ RTSP/。 版本号前面的 0将被接收方忽略，而在发送方处也不应产生。 本文档定义了 RTSP 协议的 版本。 发送本规范定义的请求（ Request）或响应（ Respnse）消息的应用必须指明 RTSP的版本为 RTSP/。 使用该版本号意味着发送消息的应用至少有条件的遵循本规范。 应用的 RTSP版本即为应用至少能有条件遵循的 RTSP版本中的最高版本。 当代理及网关收到与其自身版本不同的 RTSP请求时，必须小心处理请求的推送，因为协议版本表明发送方的能力，代理或网关不应发出高于自身版本的消息。 如果收到高版本的请求，代理或网关必须降低该请求的版本，并响应一个错误。 而低版本的请求也应在被推送前升级。 代理或网关响应请求时必须和请求的版本相同。 ******************** RTSP URL rtsp和 rtspu前缀表示要通过 RTSP协议来定位网络资源。 本节详细定义了 RTSP URL的语法和语义。 合法的 Inter 主机域名或 IP 地址 (用十进制数及点组成 ), 见RFC1123， abs_path 在 []中定义。 ******************** []： 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 | + | | . ) _lc = *( pchar |。 | ? ) query = *( uchar | reserved ) fragment = *( uchar | reserved ) pchar = uchar | : | @ | amp。 | = | + uchar = unreserved | escape unreserved = ALPHA | DIGIT | safe | extra | natinal escape = % HEX HEX reserved =。 | / | ? | : | @ | amp。 | = | + extra = ! | * | 39。 | ( | ) | , safe = $ | | _ | . unsafe = CTL | SP | | | % | | natinal = any CTET excluding ALPHA, DIGIT, reserved, extra, safe, and unsafe 权威的 URL语法及语义信息请参见 RFC1738[4]和 RFC1808[9]。 ******************** 注意： fragment和 query标识符在这时没有明确的定义，需要到 RTSP 服务器上解释。 rtsp 前缀要求使用可靠协议（在 Inter上指 TCP 协议）发出命令，而 rtspu前缀则说明使用不可靠协议（在 Inter指 UDP协议）。 如是端口为空或 没指定，则缺省为 554 端口。 语义如下：拥有被请求的资源的服务器主机通过监听 TCP 连接 (rtsp 方案 )或主机上相应端口的 UDP 包 (rtspu 方案 )，来控制所标记的资源。 资源的请求 URI是 rtsp_URL。 应尽可能避免在 URL中直接使用 IP地址。 （请参考 RFC1924） 一个表示或者流是通过基于文本的媒体标记来标识的，此媒体标记使用 URLs (RFC 1738 [20])中的字符集和转义规则 []。 URLs可以指向一个流或者一个流的集合，即是说，一个表示。 请求视情况可以指向一个完整的表示或者表示 中的单个流，见第十章。 注意，某些请求方法只能用于流，而不能用于表示，反之亦然。 例如： RTSP URL: 标识了表示 twister中的音频流，它可以通过发送基于 TCP连接的 RTSP请求至主机 554端口进行控制。 也可以是这样 RTSP URL： 标识了表示 twister，它可能是由音频和 视频流组成的。 这里并没有暗示相关流 URL 的标准。 表示的结构关系和各个流的 URL 在表示描述中定义。 如一个表示描述可能将一个流命名为 ，而将整个表示命名为。 RTSP URL的路径组成对客户端是不透明的，也不暗含任何服务器的具体文件系统结构。 简单替换 URL中的前缀后，表示描述同样可以用于非 RTSP 媒体控制协议。 会议标识 会议标识采用 URI 标准编码方法（即是说， LWS 被转义为 %）编码，并对 RTSP不透明。 它们能包含任意字节值。 【必须】保证会议标识在全局中的唯一性。 在 ，将用到会议的标识值。 ference 会议标识用以允许 RTSP 会话从媒体服务器参与的多媒体会议中获取参数。 这些会议是用该规范之外的协议创建的，例如 [13] 或 SIP [12]协议。 这样就不用 RTSP 客户端显式地提供传输信息，而改用其他方式代替，例如，客户端要求媒体服务器使用会议描述中的值。 会话标识 会话标识符是非直读 的任意长度的字符串。 线性空格必须是 URL转义的。 会话标识符【必须】随机产生并且【必须】至少由 8个字节组成，以保证 其难以被猜出。 （详见 16章） sessin SMPTE 相对时间戳 SMPTE 相对时间戳表示相对于开始剪辑的时间。 相对时间戳以 SMPTE时间编码形式表示以保证帧级的访问精度。 时间编码的格式为：时：分：秒：帧 .子帧，并以 剪辑开始为起点。 缺省的 SMPTE格式为 SMPTE 30 drp格式，其帧率是。 也可能可通过选择使用不同 SMPTE time来选择其他 SMPTE 编码格式（如 SMPTE 25）。 帧域（ frames field）的时间值在 0到 29 之间。 30帧每秒和 除了整十分钟外的每分钟都要丢掉头两个帧（ 00和 01）。 忽略帧值为 0的帧，子帧以百分之一帧为单位。 smpterange = smptetype = smptetime [ smptetime ] smptetype = smpte | smpte30drp | smpte25。 ther timecdes may be added smptetime = 1*2DIGIT : 1*2DIGIT : 1*2DIGIT [ : 1*2DIGIT ] [ . 1*2DIGIT ] 例如： 10:07:33: 25=10:07:0010:07:33: 正常播放时间 (NPT)指示流相对于表示 (presentatin)开始的位置。 时间戳由一个十进制小数组成，以秒为单位，小数点左边可以是秒或者以小时：分：秒的形式表示。 小数点右边表示秒的小数部分。 表示开始时对应。 负值没有意义。 特殊的常数 nw定义为现场事件当前瞬间。 它只能用于现场事件。 在 DSM CC 中，正常播放时间（ NPT）是这样定义的： 直观地讲， NPT 是用户和程序联系的时钟。 它经常在 VCR 上数字显示出来。 当处于普通播放模式 (倍速 = 1)时，NPT 正常前进。 当处于快进扫描模式时 (倍速为大于 1的正数 )， NPT 快速前进。 当处于反向扫描模式 (倍速小于 1)时， NPT快速后退。 当处于 暂停模式时， NPT停止。 NPT（逻辑上）等同于 SMPTE时间编码。 npt time [ npttime ] ) | ( npttime ) npt sec | npthhmmss npt npt hh : nptmm : nptss [ . *DIGIT ] npt npt 59 npt 59 例如： 125 语法遵循 IS 8601规则。 nptsec标志法便于自动生成， ntphhmmss 标志法便于人阅读。 nw常数允许客户端请求接收实时反馈而不是存储或者延时的版本。 因为对于这种情况而言，绝对时间和 0时间都不 适用。 绝对时间 绝对时间表示为 IS 8601时间戳，使用 UTC(GMT)时间。 秒的小数部分也可能会出现。 utc time [ utctime ] utc date T utctime Z utc utc tin 比如， 1996年 11 月 8日 14点 37分 UTC时间为： 选择标签 选项标签是用来指示 RTSP新选项的唯一标识符。 这些标签用于要求 (Require)(节 )和代理要求 (Prxy Require)( )头部域中。 语法： 要建立新的 RTSP 选项，可以在选项前加入反转域名的前缀（如：对于能访问到 则 是个合适的名 字），或者在英特网权威数字分派委员会注册（ IANA）新的选项。 用 IANA注册新的选项标签 当注册新 RTSP选项标签的时候，应该提供以下信息： *选项的名字和描述。 名字长度不限，但是应该不多于 20字符。 名字【必须不】包含任何空格，控制符或句点。 *指出谁拥有选项的改变控制权（例如， IETF，国际标准化组织，国际电信联盟 T，其他的国际标准化体，一个团体，一个公司，或者一组公司）。 *描述更为详细的参考文档（如果有），比如（按推荐程度排序）， RFC，公开发表的论文，专利文档，技 术报告，源代码，或者计算机手册。 *对于私有的选项，需要给出联系地址（邮政地址及电子邮箱）。 4 RTSP 消息 RTSP是基于文本的协议，采用 IS 10646 字符集和 UTF8编码方案。 每行结束处行以 CRLF标记，但接收方需有能力将 CR 和 LF自行解释成行终止符。 基于文本的协议使得易于以自描述方式增加可选参数。 由于参数的数量和命令出现的频率较低，处理效率不予考虑。 如定义得较仔细，文本协议很容易以脚本语言（如： Tcl、Visual Basic与 Perl）实现研究原型。 10646字符 集避免了繁琐的字符集切换，但若应用程序使用 USASCII字符集，它将不可见。 RTCP也采用这种编码方案。 IS 88591通过在高位填充 0，直接转成 Unicde。 标志位不为 0的 IS 88591字符被表示如 100001x 10xxxxxx.。 (见 RFC 2279 [21]) RTSP 信息可通过任何 8bit clean 的低层传输协议传送。 请求包括方法、方法作用于其上的对象和进一步描述方法的参数。 除非另外说明，否则方法是幂等 的。 方法还被设计为在服务器端只需要少量或不需要状态维护。 消息类型 见 [] ******************** []： RTSP 消息由客户端到服务器的请求和由服务器到客户端的响应组成。 RTSP message = Request | Respnse。 RTSP / messages 请求（ Request）和响应（ Respnse）消息都使用 RFC822中实体传输部分规定（作为消息中的有效载荷）的消息格式。 两者的消息都可能包括一起始行，一个或多个头部域（ headers）、一行表示头部域结束的空行（即 CRLF 前没有内容的行），和一个消息主体（ messagebdy, 可选）。 genericmessage = startline *messageheader CRLF [ messagebdy ] startline = RequestLine | StatusLine 为了健壮性考虑，服务器应该忽略任何在期望收到请求行时收到的空行。 换句话说，如果服务器正在读协议流，在一个消息开始时如果首先收到了 CRLF，这个 CRLF符应被忽略。 ******************** 消息头部 见 []。 ******************** []： RTSP头部域，包括主头部（ GeneralHeader,）、请求头部（ RequestHeader ,节）、响应头部（ RespnseHeader ,）及实体头部（ En。