RTSP协议分析
来源：互联网 发布：炉石毕游侠知乎 编辑：程序博客网 时间：2024/06/01 19:38
RTSP协议分析-1
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 建立 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状态代码定义（Status Code Definitions） 29
11.1成功2xx（Success 2xx） 30
11.1.1 存储空间低 250 30
11.2 重定向（Redirection 3xx） 31
11.3 客户端错误（Client Error ）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 序列号 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 比例 49
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
C.1.1 控制URL 55
C.1.2 媒体流 55
C.1.3 有效载荷类型 55
C.1.4 详细格式参数 55
C.1.5 表示的范围 56
C.1.6 有效时间 56
C.1.7 连接信息 56
C.1.8 实体标签 57
C.2 合控制不可用 57
C.3 合控制可用 57
附录D 最简单的RTSP实现 58
D.1 客户端 58
D.1.1回放 58
D.1.2 授权 58
D.2 服务器 59
D.2.1回放 59
D.2.2授权 59
附录E 作者地址 60
附录F 致谢 60
参考书目 60
版权申明 61
1 绪论
1.1 目的
实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流有可能交叉，但
RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的网络远程控制。
表示描述(presentation description)定义了被控流，但本文并没有定义表示描述的格式。
这里没有使用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中解释。
1.3 术语
一些术语原由HTTP/1.1采用。在HTTP/1.1中定义的术语这里不再列举。
合控制：
服务器使用单条时间线对多个流的控制。对音频/视频回馈来讲，这就意味着客户端仅需发送一条播放或者暂停
消息就可同时控制音频和视频的回馈。
会议：
多方参与的多媒体表示，这里的多方意味着大于或者等于一方。
客户端：
指请求媒体服务器上连续流媒体数据的客户端。
连接：
两个应用程序以通讯为目的在传输层建立虚拟电路。
容器文件：
可以容纳多个共同播放时包含表示(presentation)的媒体流的文件。RTSP服务器可以为这些容器文件提供合控制
，但容器文件的概念本身并不是本协议内容。
连续媒体：
接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重新产生存在于源数据中的时序关系。最普通
的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（但是不交互的），它们在源和接受器之间是一种
紧密的时序关系；或者是流的形式，这种关系就没有那么严格了。
实体：
作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-header field）形式存在的元信息和以实
体主体（entity body）形式存在的内容组成，如第八章所述。
媒体的初始化：
数据类型/编码的具体初始化，这些包括时钟输率，颜色表等。用户请求媒体回放的任何独立传输信息，是在创
建流时初始化媒体流相位时产生的。
媒体参数:
针对回放前或回放过程中有可能改变的媒体类型而专门设定的参数。
媒宸衿鳎?BR>可对一个或多个媒体流提供回放和录制服务的服务器。同一个表示(presentation)中不同的媒体流
可能来自于不同的媒体服务器。媒体服务器可以建立在作为传送请求表示(presentation)的Web服务器的主机上
，也可以建立在不同的主机上。
媒体服务器重定向：
重新定向媒体客户端到另外一个媒体服务器。
(媒体)流：
单个媒体实例，比如，在应用中共用音频流或视频流。当使用RTP时，流包括由RTP 会话(session)中源所创建的
所有RTP和RTCP包。这和定义DSM-CC流时相同。
消息：
RTSP通讯的基本单元。由15章语法定义的一串八位位组组成，并通过连接或者无连接协议传送。
参与者：
一个会议成员。参与者可以是机器，比如是媒体记录或回放服务器。
表示(presentation)：
对用户请求所回馈的一组流，其使用下面的表示描述(presentation description)形式。在本文中的多数情况下
，其意味着对流进行总体控制，但这并不是必须的。
表示描述(presentation description)：
表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息。另外
，其他IETF协议，如SDP协议使用会话(session)代替现场presentation。表示描述可以采用包括会话描述
(session description)SDP在内的多种格式。
回应：
RTSP回应。如果能理解HTTP回应，就能清楚的理解RTSP回应。
请求；
RTSP请求。如果能理解HTTP请求，就能清楚的理解RTSP请求。
RTSP会话(session)：
RTSP交互的全过程。比如，一个电影的观看过程。会话(session)包括由客户端建立连续媒体流传输机制(SETUP)
，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。
传输初始化：
客户端和服务器端之间传输信息（端口号，传输协议等）的交互。
1.4 协议特点
RTSP 特性如下：
可扩展性：
RTSP中很容易加入新方法和参数。
易解析：
RTSP可由标准 HTTP或MIME解析器解析。
安全：
RTSP使用网页安全机制。所有HTTP授权机制如basic和digest授权都可直接使用。也可以传输层或网络层安全机
制。
独立于传输：
RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。
多服务器支持：
表示(presentation)中的每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同
步在传输层执行。
记录设备控制：
协议可控制记录和回放设备，也可控制可在记录和回放切换的设备。
流控与会议开始分离：
流控与邀请媒体服务器入会分离；仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下，
SIP或H.323 可用来邀请服务器入会。
适合专业应用：
通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。
表示描述中立：
协议没强加特殊表示或元文件，可传达所用格式类型；然而，表示描述至少必须包含一个RTSP URI。
代理与防火墙友好：
协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个\"缺口\"。
HTTP友好：
此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台（PICS）。由于在大
多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法。
适当的服务器控制：
如用户能启动一个流，它必须也能停止一个流。 服务器不能启动一个用户不能停止的流。
传输协调：
实际处理连续媒体流前，用户可协调传输方法。
性能协调：
如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。 例如，
如果不允许寻找，用户界面必定能禁止位置条滑动。
以前要求RTSP必须能支持多用户，但现在得出一个更好的方法就是保证RTSP能很容易扩展成支持多用户即可。因
为流的标志可以被多个控制流使用，因此”远程通过”成为可能。协议不涉及到多个客户端如何协调入口，其由
下层“社会协议”或其他下层控制机制提供。
1.5 RTSP扩展
由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。例如：
? 服务器可能只须支持回放，因此不必不支持录制功能。
? 对于支持现场播放的服务器可能不支持寻找功能。
? 一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER。
但服务器应该实现所有12章中要求的标题域。
表示描述(presentation description)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1中[H19.6]描
述方法不支持across server的情形一致。
RTSP 可以如下三种方式扩展，这里以改变大小排序：
? 以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。
? 加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。用
户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共回应标题列出支持的方法。
? 定义新版本协议，允许改变所有部分。（除了协议版本号位置）
1.6 操作模式
每个表示和媒体流可用RTSP URL识别。表示组成的整个表示与媒体属性由表示描述(presentation
description)文件定义，表示描述格式不在本协议中定义。使用HTTP或其它途径用户可获得这个文件，它没有必
要保存在媒体服务器上。
为了说明，假设表示描述(presentation description)描述了多个表示(presentation)，其中每个表示
(presentation)维持了一个公共时间轴。为简化说明，且不失一般性，假定表示描述(presentation
description)的确包含这样一个表示(presentation)。表示(presentation)可包含多个媒体流。
表示描述(presentation description)即组成表示的流的描述，包括它们的编码，语言和使用户可以选择最符合
要求媒体的其他参数。在表示描述中，被RTSP分别控制的媒体流由RTSP URL表示。RTSP URL指出了处理具体媒体
流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可以分别
放到不同服务器而负载共享。描述（description)还列出了服务器传输可使用的方法。
除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：
单播：
以用户选择的端口号将媒体发送到RTSP请求源。
组播，服务器选择地址：
媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。
组播，用户选择地址：
如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。
1.7 RTSP状态
RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因
此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接顺序发
出请求来控制。所以，服务器需要维持能联系流与RTSP请求的会话状态。
RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：
SETUP：
让服务器给流分配资源，启动RTSP会话。
PLAY与RECORD：
启动SETUP 分配流的数据传输。
PAUSE：
临时停止流，而不释放服务器资源。
TEARDOWN：
释放流的资源，RTSP会话停止。
标识状态的RTSP方法使用会话(session)标题域识别RTSP会话，为回应SETUP请求，服务器生成会话标识。
1.8 与其他协议关系
RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目
的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，表示描述(presentation
description)可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户不全依靠
HTTP。
但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作
出回应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设
置参数，控制媒体流。
重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有
价值的。
当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。
RTSP假设存在表示描述格式可表示包含几个媒体流的表示的静态与临时属性。
2 符号协定
既 然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档
。为简便起见，本文档中[ HX.Y ]表示对应HTTP/1.1（RFC 2068）中的X.Y部分。（[译者注：]为更方便学习
RTSP，本翻译文档将相关段落完全译出）
与[H2.1]类似，本文对所有机制的说明都是以散文和补充反馈的方式来描述的。除RTSP中以”1#”代替”,”为
分隔符不同外，其余在RFC 2234中有详细的描述。简单说明补充反馈方式如下：
补充反馈方式（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）
在元素前加星号“*”表示循环，其完整形式是“<n>*<m>元素”，表明元素最少产
生<n>次，最多<m>次。缺省值是0到无限，例如，“1*元素”意思是至少有一个，
而“1*2元素”表明允许有1个或2个。
［规则］（[rule]）
方括号内是可选元素。如“［元素1 元素2］”与“*1（元素1 元素2）”是一回
事。
N 规则（N rule）
表明循环的次数：“<n>（元素）”就是“<n>*<n>（元素）”，也就是精确指出<n>
取值。因而，2DIGIT 就是2位数字, 3ALPHA 就是由三个字母组成字符串。
＃规则（#rule）
“#”与“*”类似，用于定义元素列表。
完整形式是“<n>#<m>元素”表示至少有<n>个至多有<m>个元素，中间用“,”或
任意数量的空格（LWS-linear whitespace）来分隔，这将使列表非常方便，如“（*LWS
元素 *（ *LWS "," *LWS 元素 ））”就等同于“1#元素”。
空元素在结构中可被任意使用，但不参与元素个数的计数。也就是说，“（元素1），，
（元素2）”仅表示2个元素。但在结构中，应至少有一个非空的元素存在。缺省
值是0到无限，即“#（元素）”表示可取任何数值，包括0；而“1#元素”表示至
少有1个；而“1#2元素”表示有1个或2个。
；注释（; comment）
分号后面是注释，仅在单行使用。
隐含*LWS（implied *LWS）
本文的语法描述是基于单词的。除非另有指定，线性空格（LWS）可以两个邻近符
号或分隔符（tspecials）之间任意使用，而不会对整句的意思造成影响。在两个符号之
间必须有至少一个分隔符，因为它们也要做为单独的符号来解释。实际上，应用程序在
产生HTTP结构时，应当试图遵照“通常方式”，因为现在的确有些实现方式在通常方
式下无法正常工作。
在本备忘录中，我们用缩进的小型段落来提供动机和背景资料。这将使没有参与制定RTSP规范的读者更容易理解
RTSP中各部分为什么要以该方式来实现。
RTP/RTCP流媒体服务器技术研究
2007-08-11 00:00
1 引言
随着互联网的飞速发展,流媒体技术的应用越来越广泛,从网上广播、电影播放到远程教学以及在线的新闻网
站等都用到了流媒体技术。但现有公开文献所报道的大多是利用现有的流媒体服务器来搭建一个流媒体服务系统
，或者是针对流媒体数据的编码方式所进行的研究。本文对流媒体服务器技术的研究重点在于如何建立一个服务
器，并且在实现流媒体传输的两个基本协议RTP/RTCP的基础上构建一个基本的流媒体服务器。
2 流媒体技术简介
2.1 “流”的定义
现在网上传输视频、音频主要有下载（Download）和流式传输（Streaming）两种方式。流式传输是连续传
送视/音频信号，当流媒体在客户机播放时其余部分在后台继续下载。流式传输有顺序流式传输(Progressive
Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实
时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差,以减少对传输带宽的需求。“实时
”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系。
在Internet中使用流式传输技术的连续时基媒体就称为流媒体，通常也将其视频与音频称为视频流和音频流
。实现流式传输一般都需要专用服务器和播放器。
2.2 流媒体系统组件
流媒体是由各种不同软件构成的，这些软件在各个不同层面上互相通信，基本的流媒体系统包含以下3个组
件：
播放器（Player），用来播放流媒体的软件。
服务器（Server），用来向用户发送流媒体的软件。
编码器（Encode），用来将原始的音频视频转化为流媒体格式的软件。
这些组件之间通过特定的协议互相通信，按照特定的格式互相交换文件数据。有些文件中包含了由特定编解
码器解码的数据，这种编解码器通过特定算法压缩文件的数据量。
3 流媒体服务器的基本功能和服务方式
3.1 流媒体服务器的主要功能
（1）响应客户的请求，把媒体数据传送给客户。流媒体服务器在流媒体传送期间必须与客户的播放器保持
双向通信（这种通信是必需的，因为客户可能随时暂停或快放一个文件）。
（2）响应广播的同时能够及时处理新接收的实时广播数据，并将其编码。
（3）可提供其他额外功能，如：数字权限管理（DRM），插播广告，分割或镜像其他服务器的流，还有组播
。
3.2 流媒体服务器的服务方式
（1）单播。在客户端与媒体服务器之间建立一个单独的数据通道，从1台服务器送出的每个数据包只能传送
给1个客户机。
（2）组播。在以组播技术构建的网络上，允许路由器一次将数据包复制到多个通道上。
（3）点播与广播。点播连接是客户端与服务器之间的主动的连接，在点播连接中，用户通过选择内容项目
来初始化客户端连接，用户可以开始、停止、后退、快进或暂停流。广播指的是用户被动地接收流，在广播过程
中，数据包的单独一个拷贝将发送给网络上的所有用户，客户端接收流，但不能控制流。
4 构建流媒体服务器
4.1 RTP/RTCP协议简介
实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由
IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供
时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保
证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠
RTCP提供这些服务。
实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量在当前应用进程之
间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数
据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和
RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。
RTCP主要有4个功能:
（1）用反馈信息的方法来提供分配数据的传送质量，这种反馈可以用来进行流量的拥塞控制，也可以用来
监视网络和用来诊断网络中的问题；
（2）为RTP源提供一个永久性的CNAME（规范性名字）的传送层标志，因为在发现冲突或者程序更新重启时
SSRC(同步源标识)会变，需要一个运作痕迹，在一组相关的会话中接收方也要用CNAME来从一个指定的与会者得
到相联系的数据流（如音频和视频）；
（3）根据与会者的数量来调整RTCP包的发送率；
（4）传送会话控制信息，如可在用户接口显示与会者的标识，这是可选功能。
4.2 RTP/RTCP工作过程
工作时，RTP协议从上层接收流媒体信息码流（如H.263），装配成RTP数据包发送给下层，下层协议提供RTP
和RTCP的分流。如在UDP中，RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长
度限制，它的最大包长只受下层协议的限制。
4.3 服务器的算法
服务器软件模型主要有两种，即并发服务器和循环服务器。循环服务器(Iterative Server)是指在一个时刻
只处理一个请求的服务器。并发服务器(Concurrent Server)是指在一个时刻可以处理多个请求的服务器。事实
上，多数服务器没有用于同时处理多个请求的冗余设备，而是提供一种表面上的并发性，方法是依靠执行多个线
程，每个线程处理一个请求，从客户的角度看，服务器就像在并发地与多个客户通信。
由于流媒体服务时间的不定性和数据交互实时性的请求，流媒体服务器一般采用并发服务器算法。本文构建
了一个基本的流媒体服务器，能够同时响应多个用户的请求，把本地硬盘流媒体文件或实时数据流（H.263格式
）发送给用户。在应用中，把客户分为请求实时数据的实时客户和请求文件数据的文件客户两类。主要算法为：
（1）打开设备，分配资源。当设备准备好时，创建一个RTP实时服务线程和一个RTCP实时服务线程。
（2）创建一个UDP套接字并将其绑定到所提供服务的地址之上。
（3）反复调用接收模块，接收来自客户的RTCP报告，根据其类型做出响应。对新实时客户的请求，把客户
地址添加到实时服务的客户列表中，对新文件客户的请求，则创建一个新RTP文件服务线程和一个新RTCP文件服
务线程；对已经在服务中的客户则根据RTCP报告的内容调整服务。
RTP实时服务线程1：初始化客户列表和RTP首部。
RTP实时服务线程2：从设备读取媒体数据，把数据发送给实时服务列表中的客户。
RTP实时服务线程3：更新RTP首部和统计数据。
RTP实时服务线程4：计算延时，重复第二步。
RTCP实时服务线程1：初始化RTCP首部。
RTCP实时服务线程2：发送发送方报告给实时服务列表中的客户。
RTCP实时服务线程3：计算延时，重复第二步。
RTP文件服务线程1：初始化RTP首部。
RTP文件服务线程2.：从文件读取媒体数据，把数据发送给客户。
RTP文件服务线程3：更新已发送数据的统计信息，为生成发送方报告做准备。
RTP文件服务线程4：计算延时，调整发送速度，正常情况下开始重复第二步。
RTCP文件服务线程1：初始化RTCP首部，发送一个源描述(SDES)报文给客户。
RTCP文件服务线程2：根据已发送数据的统计信息生成发送方报告，发送给客户。
RTCP文件服务线程3：计算延时，正常情况下开始重复第一步。
5 流媒体服务器实现中应注意的问题
5.1 会话和流的两级分用
一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个
。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个RTP分组在服务
器端发送出去的时候总是要指定属于哪个会话和流，在接收时也需要进行两级分用，即会话分用和流分用。只有
当RTP使用同步源标识(SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来，才能够使用序列号(Sequence
Number)和时间戳(Timestamp)对分组进行排序和正确回放。
5.2 多线程的管理
并发服务器模式要求用多线程来提供服务，所以多线程的管理十分重要。在本文构建的服务器中，不同客户
的请求和反馈都由服务器的主线程处理，由于实时数据的独有性，不同实时客户可以共用一个RTP实时服务线程
和一个RTCP实时服务线程，这样可以大大减小服务器的负担，而每个文件客户由于请求的文件不同，相应地对速
度和开始时间的要求都可能不同，所以需要有自己独有的RTP文件服务线程和RTCP文件服务线程。
RTP服务线程负责把实时数据流发送给客户，RTCP服务线程根据RTP线程的统计数据，产生发送方报告给客户
。RTP线程和RTCP线程之间通过一段共享内存交互统计数据，对共享内存必须设置互斥体进行保护，防止出现错
误读写。在这种方式下，服务器可以根据每个用户的不同请求和具体情况方便地提供不同的服务。
5.3 时间戳的处理
时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值
给出了分组中数据的第一个字节的采样时间(Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的
，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端
，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，
就可以确定输出的时间间隔。
RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释
，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。
在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳
速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值。
5.4 媒体数据发送速度的控制
由于RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送媒体数据
的速度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间
戳的设置相对容易。对已经录制好的本地硬盘上的媒体文件，以H.263格式的文件为例，由于文件本身不包含帧
率信息，所以需要知道录制时的帧率或者设置一个初始值，在发送数据的时候找出发送数据中的帧数目，根据帧
率和预置值来计算时延，以适当的速度发送数据并设置时间戳信息。
5.5 多种流同步
RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不
同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声
音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical
Name），尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就
知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告
中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP
时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方
报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中
的时间戳值映射为另一个流中的时间戳值。
6 结论
流媒体技术的应用日益广泛，对流媒体技术的研究具有很大的实际意义,本文通过对RTP/RTCP协议的研究，
分析流媒体服务器的一般功能和结构，给出构建一个基本的流媒体服务器的实现方案，实验证明可以同时满足多
个实时和文件客户的要求,并已经应用于一个远程监控系统中。
RTP/RTCP流媒体服务器技术
您正在看的电脑技巧教程是:RTP/RTCP流媒体服务器技术。1 引言
随着互联网的飞速发展,流媒体技术的应用越来越广泛,从网上广播、电影播放到远程教学以及在线的新闻网站等
都用到了流媒体技术。但现有公开文献所报道的大多是利用现有的流媒体服务器来搭建一个流媒体服务系统，或
者是针对流媒体数据的编码方式所进行的研究。本文对流媒体服务器技术的研究重点在于如何建立一个服务器，
并且在实现流媒体传输的两个基本协议RTP/RTCP的基础上构建一个基本的流媒体服务器。
2 流媒体技术简介
2.1 “流”的定义
现在网上传输视频、音频主要有下载（Download）和流式传输（Streaming）两种方式。流式传输是连续传送视/
音频信号，当流媒体在客户机播放时其余部分在后台继续下载。流式传输有顺序流式传输(Progressive
Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实
时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差,以减少对传输带宽的需求。“实时
”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系。
在Internet中使用流式传输技术的连续时基媒体就称为流媒体，通常也将其视频与音频称为视频流和音频流。实
现流式传输一般都需要专用服务器和播放器。
2.2 流媒体系统组件
流媒体是由各种不同软件构成的，这些软件在各个不同层面上互相通信，基本的流媒体系统包含以下3个组件：
播放器（Player），用来播放流媒体的软件。
服务器（Server），用来向用户发送流媒体的软件。
编码器（Encode），用来将原始的音频视频转化为流媒体格式的软件。
这些组件之间通过特定的协议互相通信，按照特定的格式互相交换文件数据。有些文件中包含了由特定编解码器
解码的数据，这种编解码器通过特定算法压缩文件的数据量。
3 流媒体服务器的基本功能和服务方式
3.1 流媒体服务器的主要功能
（1）响应客户的请求，把媒体数据传送给客户。流媒体服务器在流媒体传送期间必须与客户的播放器保持双向
通信（这种通信是必需的，因为客户可能随时暂停或快放一个文件）。
（2）响应广播的同时能够及时处理新接收的实时广播数据，并将其编码。
（3）可提供其他额外功能，如：数字权限管理（DRM），插播广告，分割或镜像其他服务器的流，还有组播。
3.2 流媒体服务器的服务方式
（1）单播。在客户端与媒体服务器之间建立一个单独的数据通道，从1台服务器送出的每个数据包只能传送给1
个客户机。
（2）组播。在以组播技术构建的网络上，允许路由器一次将数据包复制到多个通道上。
（3）点播与广播。点播连接是客户端与服务器之间的主动的连接，在点播连接中，用户通过选择内容项目来初
始化客户端连接，用户可以开始、停止、后退、快进或暂停流。广播指的是用户被动地接收流，在广播过程中，
数据包的单独一个拷贝将发送给网络上的所有用户，客户端接收流，但不能控制流。
4 构建流媒体服务器
4.1 RTP/RTCP协议简介
实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由
IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供
时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保
证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠
RTCP提供这些服务。
实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量在当前应用进程之间交
换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包
的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP
配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。
RTCP主要有4个功能:
（1）用反馈信息的方法来提供分配数据的传送质量，这种反馈可以用来进行流量的拥塞控制，也可以用来监视
网络和用来诊断网络中的问题；
（2）为RTP源提供一个永久性的CNAME（规范性名字）的传送层标志，因为在发现冲突或者程序更新重启时SSRC(
同步源标识)会变，需要一个运作痕迹，在一组相关的会话中接收方也要用CNAME来从一个指定的与会者得到相联
系的数据流（如音频和视频）；
（3）根据与会者的数量来调整RTCP包的发送率；
（4）传送会话控制信息，如可在用户接口显示与会者的标识，这是可选功能。
4.2 RTP/RTCP工作过程
工作时，RTP协议从上层接收流媒体信息码流（如H.263），装配成RTP数据包发送给下层，下层协议提供RTP和
RTCP的分流。如在UDP中， RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度
限制，它的最大包长只受下层协议的限制。
4.3 服务器的算法
服务器软件模型主要有两种，即并发服务器和循环服务器。循环服务器(Iterative Server)是指在一个时刻只处
理一个请求的服务器。并发服务器(Concurrent Server)是指在一个时刻可以处理多个请求的服务器。事实上，
多数服务器没有用于同时处理多个请求的冗余设备，而是提供一种表面上的并发性，方法是依靠执行多个线程，
每个线程处理一个请求，从客户的角度看，服务器就像在并发地与多个客户通信。
由于流媒体服务时间的不定性和数据交互实时性的请求，流媒体服务器一般采用并发服务器算法。本文构建了一
个基本的流媒体服务器，能够同时响应多个用户的请求，把本地硬盘流媒体文件或实时数据流（H.263格式）发
送给用户。在应用中，把客户分为请求实时数据的实时客户和请求文件数据的文件客户两类。主要算法为：
（1）打开设备，分配资源。当设备准备好时，创建一个RTP实时服务线程和一个RTCP实时服务线程。
（2）创建一个UDP套接字并将其绑定到所提供服务的地址之上。
（3）反复调用接收模块，接收来自客户的RTCP报告，根据其类型做出响应。对新实时客户的请求，把客户地址
添加到实时服务的客户列表中，对新文件客户的请求，则创建一个新RTP文件服务线程和一个新RTCP文件服务线
程；对已经在服务中的客户则根据RTCP报告的内容调整服务。
RTP实时服务线程1：初始化客户列表和RTP首部。
RTP实时服务线程2：从设备读取媒体数据，把数据发送给实时服务列表中的客户。
RTP实时服务线程3：更新RTP首部和统计数据。
RTP实时服务线程4：计算延时，重复第二步。
RTCP实时服务线程1：初始化RTCP首部。
RTCP实时服务线程2：发送发送方报告给实时服务列表中的客户。
RTCP实时服务线程3：计算延时，重复第二步。
RTP文件服务线程1：初始化RTP首部。
RTP文件服务线程2.：从文件读取媒体数据，把数据发送给客户。
RTP文件服务线程3：更新已发送数据的统计信息，为生成发送方报告做准备。
RTP文件服务线程4：计算延时，调整发送速度，正常情况下开始重复第二步。
RTCP文件服务线程1：初始化RTCP首部，发送一个源描述(SDES)报文给客户。
RTCP文件服务线程2：根据已发送数据的统计信息生成发送方报告，发送给客户。
RTCP文件服务线程3：计算延时，正常情况下开始重复第一步。
5 流媒体服务器实现中应注意的问题
5.1 会话和流的两级分用
一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个。而
从同一个同步源发出的RTP分组序列称为流(Stream),一个RT您正在看的电脑技巧教程是:RTP/RTCP流媒体服务器
技术。P会话可能包含多个RTP流。一个 RTP分组在服务器端发送出去的时候总是要指定属于哪个会话和流，在接
收时也需要进行两级分用，即会话分用和流分用。只有当RTP使用同步源标识 (SSRC)和分组类型(PTYPE)把同一
个流中的分组组合起来，才能够使用序列号(Sequence Number)和时间戳(Timestamp)对分组进行排序和正确回放
。
5.2 多线程的管理
并发服务器模式要求用多线程来提供服务，所以多线程的管理十分重要。在本文构建的服务器中，不同客户的请
求和反馈都由服务器的主线程处理，由于实时数据的独有性，不同实时客户可以共用一个RTP实时服务线程和一
个RTCP实时服务线程，这样可以大大减小服务器的负担，而每个文件客户由于请求的文件不同，相应地对速度和
开始时间的要求都可能不同，所以需要有自己独有的RTP文件服务线程和RTCP文件服务线程。
RTP服务线程负责把实时数据流发送给客户， RTCP服务线程根据RTP线程的统计数据，产生发送方报告给客户。
RTP线程和RTCP线程之间通过一段共享内存交互统计数据，对共享内存必须设置互斥体进行保护，防止出现错误
读写。在这种方式下，服务器可以根据每个用户的不同请求和具体情况方便地提供不同的服务。
5.3 时间戳的处理
时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出
了分组中数据的第一个字节的采样时间 (Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，
即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端，
由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就
可以确定输出的时间间隔。
RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而
是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。
在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率
大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值。
5.4 媒体数据发送速度的控制
由于RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送媒体数据的速
度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的
设置相对容易。对已经录制好的本地硬盘上的媒体文件，以H.263格式的文件为例，由于文件本身不包含帧率信
息，所以需要知道录制时的帧率或者设置一个初始值，在发送数据的时候找出发送数据中的帧数目，根据帧率和
预置值来计算时延，以适当的速度发送数据并设置时间戳信息。
5.5 多种流同步
RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，
RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与
影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name）
，尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪
些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有
一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳
值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都
使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对
时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。
6 结论
流媒体技术的应用日益广泛，对流媒体技术的研究具有很大的实际意义,本文通过对RTP/RTCP协议的研究，分析
流媒体服务器的一般功能和结构，给出构建一个基本的流媒体服务器的实现方案，实验证明可以同时满足多个实
时和文件客户的要求,并已经应用于一个远程监控系统中。
原帖地址：
http://www.pcppc.cn/jichu/diannaojiqiao/jichu_47700_2.html
RFC2326(中文版)－实时流协议(RTSP)
这段时间学习RTSP，发现中文版资料实在太少，因此翻译了部分RFC2326文档，希望对学习实时流协议的读者有
所裨益。鉴于本人对RTSP的熟悉程度和翻译水平，如有不当之处请多多指教。E-mail:fra_2000@163.com
Network Working Group H. Schulzrinne
Request for Comments: 2326 Columbia U.
Category: Standards Track A. Rao
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 建立 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状态代码定义（Status Code Definitions） 29
11.1成功2xx（Success 2xx） 30
11.1.1 存储空间低 250 30
11.2 重定向（Redirection 3xx） 31
11.3 客户端错误（Client Error ）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 序列号 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 比例 49
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
C.1.1 控制URL 55
C.1.2 媒体流 55
C.1.3 有效载荷类型 55
C.1.4 详细格式参数 55
C.1.5 表示的范围 56
C.1.6 有效时间 56
C.1.7 连接信息 56
C.1.8 实体标签 57
C.2 合控制不可用 57
C.3 合控制可用 57
附录D 最简单的RTSP实现 58
D.1 客户端 58
D.1.1回放 58
D.1.2 授权 58
D.2 服务器 59
D.2.1回放 59
D.2.2授权 59
附录E 作者地址 60
附录F 致谢 60
参考书目 60
版权申明 61
1 绪论
1.1 目的
实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流有可能交叉，但
RTSP本身通常并不发送连续媒体流。换言之，RTSP充当多媒体服务器的网络远程控制。
表示描述(presentation description)定义了被控流，但本文并没有定义表示描述的格式。
这里没有使用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中解释。
1.3 术语
一些术语原由HTTP/1.1采用。在HTTP/1.1中定义的术语这里不再列举。
合控制：
服务器使用单条时间线对多个流的控制。对音频/视频回馈来讲，这就意味着客户端仅需发送一条播放或者暂停
消息就可同时控制音频和视频的回馈。
会议：
多方参与的多媒体表示，这里的多方意味着大于或者等于一方。
客户端：
指请求媒体服务器上连续流媒体数据的客户端。
连接：
两个应用程序以通讯为目的在传输层建立虚拟电路。
容器文件：
可以容纳多个共同播放时包含表示(presentation)的媒体流的文件。RTSP服务器可以为这些容器文件提
供合控制，但容器文件的概念本身并不是本协议内容。
连续媒体：
接受器和数据源之间存在时序关系的数据。也就是说，接受器需要重新产生存在于源数据中的时序关系
。最普通的连续媒体的例子是音频和动画视频。连续媒体可以是实时的（但是不交互的），它们在源和接受器之
间是一种紧密的时序关系；或者是流的形式，这种关系就没有那么严格了。
实体：
作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-header field）形式存在的元信息和以实
体主体（entity body）形式存在的内容组成，如第八章所述。
媒体的初始化：
数据类型/编码的具体初始化，这些包括时钟输率，颜色表等。用户请求媒体回放的任何独立传输信息，是在创
建流时初始化媒体流相位时产生的。
媒体参数:
针对回放前或回放过程中有可能改变的媒体类型而专门设定的参数。
媒体服务器：
可对一个或多个媒体流提供回放和录制服务的服务器。同一个表示(presentation)中不同的媒体流可能来自于不
同的媒体服务器。媒体服务器可以建立在作为传送请求表示(presentation)的Web服务器的主机上，也可以建立
在不同的主机上。
媒体服务器重定向：
重新定向媒体客户端到另外一个媒体服务器。
(媒体)流：
单个媒体实例，比如，在应用中共用音频流或视频流。当使用RTP时，流包括由RTP 会话(session)中源
所创建的所有RTP和RTCP包。这和定义DSM-CC流时相同。
消息：
RTSP通讯的基本单元。由15章语法定义的一串八位位组组成，并通过连接或者无连接协议传送。
参与者：
一个会议成员。参与者可以是机器，比如是媒体记录或回放服务器。
表示(presentation)：
对用户请求所回馈的一组流，其使用下面的表示描述(presentation description)形式。在本文中的多数情况下
，其意味着对流进行总体控制，但这并不是必须的。
表示描述(presentation description)：
表示描述包含在表示(presentation)中一个或者多个媒体流的信息。比如，编码，网络地址和内容的信息。另外
，其他IETF协议，如SDP协议使用会话(session)代替现场presentation。表示描述可以采用包括会话描述
(session description)SDP在内的多种格式。
回应：
RTSP回应。如果能理解HTTP回应，就能清楚的理解RTSP回应。
请求；
RTSP请求。如果能理解HTTP请求，就能清楚的理解RTSP请求。
RTSP会话(session)：
RTSP交互的全过程。比如，一个电影的观看过程。会话(session)包括由客户端建立连续媒体流传输机制(SETUP)
，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。
传输初始化：
客户端和服务器端之间传输信息（端口号，传输协议等）的交互。
1.4 协议特点
RTSP 特性如下：
可扩展性：
RTSP中很容易加入新方法和参数。
易解析：
RTSP可由标准 HTTP或MIME解析器解析。
安全：
RTSP使用网页安全机制。所有HTTP授权机制如basic和digest授权都可直接使用。也可以传输层或网络层安全机
制。
独立于传输：
RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。
多服务器支持：
表示(presentation)中的每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同
步在传输层执行。
记录设备控制：
协议可控制记录和回放设备，也可控制可在记录和回放切换的设备。
流控与会议开始分离：
流控与邀请媒体服务器入会分离；仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下，
SIP或H.323 可用来邀请服务器入会。
适合专业应用：
通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。
表示描述中立：
协议没强加特殊表示或元文件，可传达所用格式类型；然而，表示描述至少必须包含一个RTSP URI。
代理与防火墙友好：
协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个\"缺口\"。
HTTP友好：
此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台（PICS）。由于在大
多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法。
适当的服务器控制：
如用户能启动一个流，它必须也能停止一个流。 服务器不能启动一个用户不能停止的流。
传输协调：
实际处理连续媒体流前，用户可协调传输方法。
性能协调：
如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。 例如，
如果不允许寻找，用户界面必定能禁止位置条滑动。
以前要求RTSP必须能支持多用户，但现在得出一个更好的方法就是保证RTSP能很容易扩展成支持多用户即可。因
为流的标志可以被多个控制流使用，因此”远程通过”成为可能。协议不涉及到多个客户端如何协调入口，其由
下层“社会协议”或其他下层控制机制提供。
1.5 RTSP扩展
由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。例如：
Ø 服务器可能只须支持回放，因此不必不支持录制功能。
Ø 对于支持现场播放的服务器可能不支持寻找功能。
Ø 一些服务器可能不支持设置流参数，因此不支持GET_PARAMETER和SET_PARAMETER。
但服务器应该实现所有12章中要求的标题域。
表示描述(presentation description)应当保证不提出服务器不支持的功能，这种情形和HTTP/1.1中[H19.6]描
述方法不支持across server的情形一致。
RTSP 可以如下三种方式扩展，这里以改变大小排序：
Ø 以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。
Ø 加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法
。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共回应标题列出支持的方法。
Ø 定义新版本协议，允许改变所有部分。（除了协议版本号位置）
1.6 操作模式
每个表示和媒体流可用RTSP URL识别。表示组成的整个表示与媒体属性由表示描述(presentation
description)文件定义，表示描述格式不在本协议中定义。使用HTTP或其它途径用户可获得这个文件，它没有必
要保存在媒体服务器上。
为了说明，假设表示描述(presentation description)描述了多个表示(presentation)，其中每个表示
(presentation)维持了一个公共时间轴。为简化说明，且不失一般性，假定表示描述(presentation
description)的确包含这样一个表示(presentation)。表示(presentation)可包含多个媒体流。
最符合要求媒体的其他参数。在表示描述中，被RTSP分别控制的媒体流由RTSP URL表示。RTSP URL指出了处理具
体媒体流的服务器以及存在于该服务器上流的名字。多个媒体流可以放到不同的服务器上，比如音频和视频流可
以分别放到不同服务器而负载共享。描述（description)还列出了服务器传输可使用的方法。
除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：
单播：
以用户选择的端口号将媒体发送到RTSP请求源。
组播，服务器选择地址：
媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。
组播，用户选择地址：
如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。
1.7 RTSP状态
RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因
此，即使媒体服务器没有收到请求，数据也会继续发送。在会话生命期，单个媒体流可通过不同TCP连接顺序发
出请求来控制。所以，服务器需要维持能联系流与RTSP请求的会话状态。
RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：
SETUP：
让服务器给流分配资源，启动RTSP会话。
PLAY与RECORD：
启动SETUP 分配流的数据传输。
PAUSE：
临时停止流，而不释放服务器资源。
TEARDOWN：
释放流的资源，RTSP会话停止。
标识状态的RTSP方法使用会话(session)标题域识别RTSP会话，为回应SETUP请求，服务器生成会话标识。
1.8 与其他协议关系
RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目
的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，表示描述(presentation
description)可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户不全依靠
HTTP。
但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作
出回应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设
置参数，控制媒体流。
重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有
价值的。
当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。
RTSP假设存在表示描述格式可表示包含几个媒体流的表示的静态与临时属性。
2 符号协定
既然很多定义和语法与HTTP/1.1中相同，这里仅指出它们在HTTP/1.1中定义的位置而并没有拷贝它们到本文档。
为简便起见，本文档中[ HX.Y ]表示对应HTTP/1.1（RFC 2068）中的X.Y部分。（[译者注：]为更方便学习RTSP
，本翻译文档将相关段落完全译出）
与[H2.1]类似，本文对所有机制的说明都是以散文和补充反馈的方式来描述的。除RTSP中以”1#”代替”,”为
分隔符不同外，其余在RFC 2234中有详细的描述。简单说明补充反馈方式如下：
补充反馈方式（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）
在元素前加星号“*”表示循环，其完整形式是“<n>*<m>元素”，表明元素最少产
生<n>次，最多<m>次。缺省值是0到无限，例如，“1*元素”意思是至少有一个，
而“1*2元素”表明允许有1个或2个。
［规则］（[rule]）
方括号内是可选元素。如“［元素1 元素2］”与“*1（元素1 元素2）”是一回
事。
N 规则（N rule）
表明循环的次数：“<n>（元素）”就是“<n>*<n>（元素）”，也就是精确指出<n>
取值。因而，2DIGIT 就是2位数字, 3ALPHA 就是由三个字母组成字符串。
＃规则（#rule）
“#”与“*”类似，用于定义元素列表。
完整形式是“<n>#<m>元素”表示至少有<n>个至多有<m>个元素，中间用“,”或
任意数量的空格（LWS-linear whitespace）来分隔，这将使列表非常方便，如“（*LWS
元素 *（ *LWS "," *LWS 元素 ））”就等同于“1#元素”。
空元素在结构中可被任意使用，但不参与元素个数的计数。也就是说，“（元素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即可。
如下：
送方表明其消息的格式及功能，而不仅仅为了获得通讯的特性，这样做的目的是为了与更高
版本的RTSP实现通讯。只增加扩展域的值或增加了不影响通讯行为的消息组件都不会导致
版本数据的变化。当协议消息的主要解析算法没变，而消息语法及发送方的隐含功能增加了，
将会导致从版本号（<minor>）增加；当协议中消息的格式变化了，主版本号（<major>）也
将发生改变。
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版本中的最高版本。
协议版本表明发送方的能力，代理或网关不应发出高于自身版本的消息。如果收到高版本的
请求，代理或网关必须降低该请求的版本，并回应一个错误。而低版本的请求也应在被推送
前升级。代理或网关回应请求时必须和请求的版本相同。
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]中定义如下：
[注意]：段(fragment)和询问(query)标识符在这时没有明确的定义，需要到RTSP服务器上解释。
rtsp要求使用可靠协议（Internet的TCP协议）发出命令，而rtspu则使用不可靠协议（Internet的UDP协议）。
如是端口为空或没指定，则缺省为80端口。对于rtsp_URI来说，拥有被请求的
资源的服务器主机通过侦听该端口的TCP连接(rtsp)或UDP包(rtspu)来接收该URI请求。
只要可能，应尽量避免的在URL中直接使用IP地址。（请参考RFC1924）
文本媒体标识符使用URL中的字符集及转义规则（参考RFC1738）来标识一个表示(presentation)与单个流
(stream)。URL可以用于单个流或者多个流的集合，比如表示(presentation)。因此，在第十章所描述的请求
(request)可以用于整个表示(presentation)或表示中的单个流。注意，有些请求方法仅能用于流而不能用于表
示，反之亦然。
例如：RTSP URL:
rtsp://media.example.com:554/twister/audiotrack
标识了twister表示(presentation)中，可以通过media.example.com554端口的TCP连接发送RTSP请求来控制的音
频流。
也可以是这样RTSP URL：
rtsp://media.example.com:554/twister
标识了由音频和视频流组成的twister表示(presentation)。
这并没有给出URL中相关流的标准方法。表示描述定义了表示中的层次关系以及单独流的URL。如一个表示描述可
能将一个流命名为a.mov，而将整个表示命名为b.mov。
RTSP URL的路径组成对客户端来说不可见并且也并没有给出服务器的具体文件系统结构。
只需进行简单替换后，表示描述同样可以用于非RTSP媒体控制协议。
3.3 会议标识
会议标识采用URI标准编码方法编码，并对RTSP来说是不可见的。它们能包含任一八位位组值。必须保证会议标
识在全局中的唯一性。在H.323中，将用到会议的标识值。
conference-id = 1*xchar
会议标识允许RTSP会话从媒体服务器参与的多媒体会议中获取参数。比如，可以要求媒体服务器用会议描述中的
标识值来代替RTSP客户端以提供详细的传输信息。多媒体会议的建立不属于本协议内容，具体请参见H.323或SIP
协议。
3.4 会话标识
会话标识符是不可见的任意长度的字符串。线性空格必须是URL-escaped。会话标识符必须随机产生并且至少应
有8个八位位组长以保证其难以被猜出。（详见16章）
session-id = 1*( ALPHA | DIGIT | safe )
3.5 SMPTE 相对时间戳
SMPTE相对时间戳表示相对于开始剪辑的时间。相对时间戳以SMPTE时间编码形式表示而可以达到帧级量级的精度
。时间编码的格式为：时：分：秒；帧.子帧，并以剪辑开始为起点。缺省的SMPTE格式为“SMPTE 30 drop”格
式，其帧速是29.97帧每秒。可通过选择使用不同“SMPTE time”来选择其他SMPTE编码格式（如“SMPTE 25”格
式）。帧域的时间值在0到29之间。30帧每秒和29.97帧每秒的不同之处在于后者除每第十分钟外的每分钟都要丢
掉头两个帧（00和01）。忽略帧值为0的帧，子帧以百分之一帧为单位。
smpte-range= smpte-type "=" smpte-time "-" [ smpte-time ]
smpte-type = "smpte" | "smpte-30-drop" | "smpte-25"
; 还可以加入其他时间编码
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ]
[ "." 1*2DIGIT ]
比如：
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正常播放时间
正常播放时间(NPT)指出了流相对于表示(presentation)开始时的绝对位置。时间戳由一个十进制小数组成，以
秒为单位，小数点左边可以直接以秒表示或者以小时：分：秒的形式表示。
表示开始时对应0.0秒。负值没有意义。特殊的常数now定义为现场事件当前瞬间。它只能用于现场事件。
在DSM-CC中，正常播放时间（NPT）是这样定义的：“直观地讲，NPT是用户和程序联系的时钟。它经常作为数字
显示在VCR上。当处于普通播放模式(scale = 1)时，NPT正常前进。当处于快进扫描模式时(scale率为大于1的正
数)，NPT快速前进。当处于反向扫描模式(scale率小于-1)时，NPT快速后退。当处于暂停模式时，NPT停止。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-59
比如：
npt=123.45-125
npt=12:05:35.3-
npt=now-
语法遵循ISO 8601规则。npt-sec标志法便于自动产生， ntp-hhmmss标志法便于人工使用。“now”常数允许
客户端请求接收实时反馈而不是存储或者延时的版本。因为对于这种情况而言，既没有绝对时间，也没有0时间
，所以需要该参数。
3.7 绝对时间
绝对时间表示为ISO 8601时间戳，使用UTC(GMT)小数法表示。
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 >
比如，1996年11月8日14点37分20.25秒UTC时间为：
19961108T143720.25Z
3.8 选择标签
选择标签是用来指定RTSP新选择的唯一标识符。这些标签用于要求(Require)(12.32节)和代理要求(Proxy
Require)(12.27节)标题域中。
语法：
option-tag = 1*xchar
建立新的RTSP选择可以通过在选择前加入相反域名的前缀（如：对于能访问到foo.com则com.foo.mynewfeature"
是个合适的名字）或者在英特网权威数字分派委员会注册（IANA）新的选择。
3.8.1 用IANA注册新的选择标签
当注册新RTSP选择标签的时候，应该提供以下信息：
Ø 选择的名字和描述。名字长度不限，但是应该不少于20字符。名字不得包含任何空格，控制符或句点。
Ø 指出谁拥有选择的改变控制权（例如，IETF，国际标准化组织，国际电信联盟-T，其他的国际标准化体
，一个团体，一个公司，或者一组公司）。
Ø 描述更为详细的参考文档（如果有），比如，RFC，发表论文，专利文档，技术报告，源代码，或者计算
机手册。
Ø 选择的所有权，以及联系地址（邮编及电子信件地址）。
4 RTSP消息
RTSP是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR
和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现
较低，处理效率没引起注意。如仔细研究，文本协议很容易以脚本语言（如：Tcl、Visual Basic与Perl）实现
研究原型。
10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO
8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通过任何低层传输协议携带。
请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或
不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：
不管实体标题域是否出现在信息中，不包括信息体的的回应信息总以标题域后第一和空行结束。
如出现内容长度标题域，其值以字节计，表示信息体长度。如未出现标题域，其值为零。
服务器关闭连接。
注意：RTSP目前并不支持HTTP/1.1\"块\"传输编码，需要有内容长度头。假如返回适度表示描述长度，即使
动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显
式给出，规则可确保行为合理。
从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态
代码，而没有定义任何HTTP代码。
4.1 消息类型
见[H4.1]。如下：
RTSP消息由客户端到服务器的请求和由服务器到客户端的回应组成。
RTSP -message = Request | Response ; RTSP /1.0 messages
消息格式。两者的消息都可能包括一起始行，一个或多个标题域（headers）、一行表示标题域结束的空行（即
CRLF前没有内容的行），和一个消息主体（message-body,可选）。
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
为了健壮性考虑，服务器应该忽略任何在期望收到请求行时收到的空行。换句话说，如果服务器正在读协议流，
在一个消息开始时如果首先收到了CRLF，这个CRLF符应被忽略。
4.2 消息标题
见[H4.2]。
回应标题（Response-Header ,6.2节）及实体标题（Entity-Header,7.1节），都遵照RFC822-3.1
节[7]给出的通用格式定义。每个标题域由后紧跟冒号的名字，单空格（SP），字符及域值组
成。域名是大小写敏感的。虽然不提倡，标题域还是可以扩展成多行使用，只要这些行以一
个以上的SP或HT开头就行。
RTSP-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs make up the field-value
标题域接收的顺序并不重要，但良好的习惯是，先发送主标题，然后是请求标题或回应
标题，最后是实体标题。
的RTSP标题域才可以表示在一个消息里。而且必须能在不改变消息语法的前提下，将并发
的域值加到第一个值后面，之间用逗号分隔，最终能将多个标题域结合成“域名：域值”对。
4.3 消息主体
见[H4.3]。
RTSP消息的消息主体（如果有）用来携带请求或回应的主体。仅在使用传输编码(Transfer-Encoding)时消息主
体和实体主体才有所不同，这种情况在传输编码标题域中有详细说明。（见[H14.40]）
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
传输编码必须能解释所有保证传输安全和正确的应用程序的传输编码。传输编码是消息而不是实体的一个属性，
因此可以由任一应用程序随着请求/回应链添加或者删除。
什么时候允许消息带消息体的规则在请求和回应两种情况下有所不同。
在请求中有无消息主体的标志是是否包含内容长度或请求消息标题域中的传输编码标题域。只有当请求方法允许
有实体主体的时候才能在请求中包含消息主体。
而对于回应消息来说，无论消息中是否存在消息主体都与请求方法和回应状态编码无关。所有回应标题请求方法
的消息都不能包含消息主体，尽管有时会因为存在实体标题域而使人产生误解。所有1××（信息），204（无内
容），304（未修改）回应都不包含消息主体。而其他回应则都包含主体，尽管其长度有可能长度为零。
4.4 消息长度
当消息包含消息主体时，消息主体的长度由以下规则来决定（按优先级高低顺序排列）：
1. 任何回应消息都不包含消息主体（如1××，204和304回应），并且不管消息中是否存在实体标题域都
以消息标题域后的第一行空行表示结束。
2. 如果内容长度标题域存在，它在字节中的值就是消息主体的长度。如果内容标题域不存在，则假设值为
零。
3. 服务器关闭连接时。（关闭连接没有用来表明请求主体结束，否则可能导致服务器不能回应。
注意，RTSP不支持（至少现在）HTTP/1.1的块传输编码（详见[H3.6]）并且要求有内容长度标题域。
不需使用块传输编码方式。只要有实体主体就必须有内容长度项，这些规则保证了即使没有给出明确长度也能做
出合理的操作。
5 普通标题域
传输的消息。
General-Header = Date ; Section 10.6
新的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将
被视为实体域。
6 请求
从客户端到服务器端的请求消息包括，消息首行中，对资源的请求方法、资源的标识符
及使用的协议。
Request = Request-Line ; 6.1节
*( general-header ; 5章
| request-header ; 6.2节
| entity-header ) ; 8.1节
CRLF
[ message-body ] ; 4.3节
6.1 请求队列
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Method = "DESCRIBE" ; Section 10.2
| "ANNOUNCE" ; Section 10.3
| "GET_PARAMETER" ; Section 10.8
| "OPTIONS" ; Section 10.1
| "PAUSE" ; Section 10.6
| "PLAY" ; Section 10.5
| "RECORD" ; Section 10.11
| "REDIRECT" ; Section 10.10
| "SETUP" ; Section 10.4
| "SET_PARAMETER" ; Section 10.9
| "TEARDOWN" ; Section 10.7
| extension-method
extension-method = token
Request-URI = "*" | absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
6.2 请求标题域
request-header = Accept ; Section 12.1
| Accept-Encoding ; Section 12.2
| Accept-Language ; Section 12.3
| Authorization ; Section 12.5
| From ; Section 12.20
| If-Modified-Since ; Section 12.23
| Range ; Section 12.29
| Referer ; Section 12.30
| User-Agent ; Section 12.41
注意：相对于HTTP/1.1而言，RTSP请求要求绝对路径（并包括rtsp或rtspu方案，主机，端口号）。
HTTP/1.1 要求服务器理解绝对URL, 但是客户端需要假设为主机请求标题域。这样做完全是为了HTTP/1.0服务器
端向后兼容性，因此RTSP并不需要这样做。
在请求URI中星号“*”表示此请求不用于其他资源，只用于服务器本身，并且它只能在使用的方法不要求应用于
资源时才能使用。
比如：OPTIONS * RTSP/1.0。
7 回应
7.1 状态行
完整回应消息的第一行就是状态行，它依次由协议版本、数字形式的状态代码、及相应
的词语文本组成，各元素间以空格（SP）分隔，除了结尾的CRLF外，不允许出现单独的
CR或LF符。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
7.1.1 状态代码和原因分析
状态代码（Status-Code）由3位数字组成，表示请求是否被理解或被满足。原因分析是
用简短的文字来描述状态代码产生的原因。状态代码用来支持自动操作，原因分析是为人类
用户准备的。客户端不需要检查或显示原因分析。
状态代码的第一位数字定义了回应的类别，后面两位数字没有具体分类。首位数字有5
种取值可能：
o 1xx:：保留，将来使用。
o 2xx：成功 － 操作被接收、理解、接受（received, understood, accepted）。
o 3xx：重定向（Redirection）－ 要完成请求必须进行进一步操作。
o 4xx：客户端出错 － 请求有语法错误或无法实现。
o 5xx：服务器端出错 － 服务器无法实现合法的请求。
HTTP/1.0的状态代码、原因解释在下面给出。下面的原因解释只是建议采用，可任意
更改，而不会对协议造成影响。完整的代码定义在第9节。
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 Enough 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>
应用不要求了解全部注册的状态代码，当然，如果了解了更好。实际上，应用程序必须理解
任何一种状态代码，如果碰到不识别的情况，可根据其首位数字来判断其类型并处理。另外，
不要缓存无法识别的回应。
可认为回应的状态码就是400。在这种情况下，用户代理应当在回应消息的实体中通知用户，
因为实体中可以包括一些人类可以识别的非正常状态的描述信息。
Code reason
100 Continue all
200 OK all
201 Created RECORD
250 Low on Storage Space RECORD
300 Multiple Choices all
301 Moved Permanently all
302 Moved Temporarily all
303 See Other all
305 Use Proxy all
400 Bad Request all
401 Unauthorized all
402 Payment Required all
403 Forbidden all
404 Not Found all
405 Method Not Allowed all
406 Not Acceptable all
407 Proxy Authentication Required all
408 Request Timeout all
410 Gone all
411 Length Required all
412 Precondition Failed DESCRIBE, SETUP
413 Request Entity Too Large all
414 Request-URI Too Long all
415 Unsupported Media Type all
451 Invalid parameter SETUP
452 Illegal Conference Identifier SETUP
453 Not Enough Bandwidth SETUP
454 Session Not Found all
455 Method Not Valid In This State all
456 Header Field Not Valid all
457 Invalid Range PLAY
458 Parameter Is Read-Only SET_PARAMETER
459 Aggregate Operation Not Allowed all
460 Only Aggregate Operation Allowed all
461 Unsupported Transport all
462 Destination Unreachable all
500 Internal Server Error all
501 Not Implemented all
502 Bad Gateway all
503 Service Unavailable all
504 Gateway Timeout all
505 RTSP Version Not Supported all
551 Option not support all
Table 1: Status codes and their usage with RTSP methods
7.1.2 回应标题域
回应标题域中包括不能放在状态行中的附加回应信息。该域还可以存放与服务器相关的
信息，以及在对请求URI所指定资源进行访问的下一步信息。
response-header = Location ; Section 12.25
| Proxy-Authenticate ; Section 12.26
| Public ; Section 12.28
| Retry-After ; Section 12.31
| Server ; Section 12.36
| Vary ; Section 12.42
| WWW-Authenticate ; Section 12.44
的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将被
视为实体域。
8 实体
如不受请求方法或回应状态编码限制，请求和回应消息可传输实体，实体由实体标题域和实体主体组成，有些回
应仅包括实体头。
在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
8.1 实体标题域
实体标题定义实体主体可选元信息，如没有实体主体，指请求标识的资源。
entity-header = Allow ; Section 12.4
| Content-Base ; Section 12.11
| Content-Encoding ; Section 12.12
| Content-Language ; Section 12.13
| Content-Length ; Section 12.14
| Content-Location ; Section 12.15
| Content-Type ; Section 12.16
| Expires ; Section 12.19
| Last-Modified ; Section 12.24
| extension-header
extension-header = message-header
扩展头机制允许定义附加实体标题域，而不用改变协议，但这些段不能假定接收者能识别。不可识别标题域应被
接收者忽略，而让代理转发。
8.2 实体主体
见[H7.2]
（Entity-Header）中定义。
Entity-Body = *OCTET
标题域（Content-Length header field）的标志将指明请求中的实体主体是否存在。包含实体
主体的RTSP/1.0请求必须包含合法的内容长度标题域。
请求方法的回应都不应包括主体，即便是实体标题域中指明有主体也一样。在主体中不应包
括这些回应信息，全部1xx（信息）、204（无内容）和304（未修改）。而其它的回应必须包
括实体主体或其内容长度标题（Content-Length header）域的定义值为0。
9 连接
RTSP请求可以几种不同方式传送：
1、持久传输连接，用于多个请求/回应传输。
2、每个请求/回应传输一个连接。
3、无连接模式。
传输连接类型由RTSP URI来定义。对 \"rtsp\" 方案，需要持续连接；而\"rtspu\"方案，调用RTSP 请求发
送，而不用建立连接。
不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没
有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。
9.1 流水线操作
支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出回应。
9.2 可靠性及确认
如果请求不是发送给组播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间（RTT）后重
发同一信息。 RTT在TCP中估计，初始值为500 ms。应用缓存最后所测量的RTT，作为将来连接的初始值。
如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。
如两个低层可靠传输（如TCP 和RTSP）应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝
试到达接收着者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重
发将使阻塞进一步恶化。
时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。
每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加一。如由于没有确认而重发请求，请求必须
携带初始系列号。
实现RTSP的系统必须支持通过TCP传输RTSP ，并支持UDP。对UDP和TCP，RTSP服务器的缺省端口都是554。许
多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与RTP和RTCP包交叉。不象HTTP，RTSP信息必须
包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头。
RTP/ RTSP/ RTCP/SIP
RTP
(Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一
或一对多的传输情况下工作。其目的是提供时间信息和 实现流同步。但RTP通常使用UDP来传送数据。但RTP也可
以在TCP或ATM等其他协议之上工作。当应用程序开始一个RTP会话时将使用两个端口:一 个给RTP一个给 RTCP。
RTP本身并不能为接顺序传送数据包提供可靠的传送机制。也不提供流量控制或拥塞控制。它依靠RTCP提供这些
服务。通常RTP算法并不作为一 个独立的网络层来实现。而是作为应用程序代码的一部分。实时传送控制协议
RTCP.RTCP(Real-time Transport Control Protocol)和RTP提供流量控制和拥塞控制。在RTP会话期间,各参与者
周期性地传送RTCP包.RTCP包中含有已发送的数据包的数量、丢失的 数据包的数量等统计资料.因此,服务器可以
利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小
的开销使传输效率最佳化。因而特别适合传送网上的实时数据。
RTSP
实时流协议RTSP(Real-time Streaming Protocol)是由Real Networks和Netscape共同中提出的。该协议定义了
一对多应用程序如何有效地通过lP网络传送多媒体数据。RTSP在体系结构上位于RTP和 RTCP之上。它使用TCP或
RTP完成数据传输。HTTP与RTSP相比。HTTP传送HTML。而RTP传送是多媒体数据。HTTP请求由客户机发 出，服务
器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。
Description: Real-Time Streaming Protocol is a client-server protocol to enable controlled
delivery of streaming audio and video over an IP network. It provides "VCR-style"
RTCP
(Real-time Transport Control Protocol)和RTP提供流量控制和拥塞控制。在RTP会话期间,各参与者周期性地
传送RTCP包.RTCP包中含有已发送的数据包的数量、丢失的 数据包的数量等统计资料.因此,服务器可以利用这些
信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小 的开销使
传输效率最佳化。因而特别适合传送网上的实时数据
SIP
（Session Initiation Protocol）是由IETF定义，基于IP的一个应用层控制协议。由于SIP是基于纯文本的信令
协议，可以管理不同接入网络上的会晤等。会晤可以是终 端设备之间任何类型的通信，如视频会晤、既时信息
处理或协作会晤。该协议不会定义或限制可使用的业务，传输、服务质量、计费、安全性等问题都由基本核心网
络和其它协议处理。SIP得到了微软、AOL、等厂商及IETF和3GPP等标准制定机构的大力支持。支持SIP的网络将
提供一个网桥，以扩展向互联网和 无线网络的各种设备提供融合业务能力。这将允许运营商为其移动用户提供
大量的信息处理业务，通过SMS互通能力与固定用户和2G无线用户交互。SIP也是 在UMTS3GPP R5/R6版本中使用
的信令协议，因此可以保护运营商目前的投资而及具技术优势和商业价值。
SIP的技术优势
*独立于接入：SIP可用于建立与任何类型的接入网络的会晤，同时还使运营商能够使用其它协议。
*会晤和业务独立：SIP不限制或定义可以建立的会晤类型，使多种媒体类型的多个会晤可以在终端设备之间进行
交换。
*协议融合：SIP可以在无线分组交换域中提供所有业务的融合协议。
SIP的商业价值
*收入商机：新的融合多媒体业务可以部署在GORS，UMTS，XDSL，WLAN等与接入独立的域中，因此运营商可以在
3GPP R5推出之前就开始创收。
*经济高效：由于SIP是与接入独立的协议，无线运营商无需构建适用于多种接入网络的基础设施
RTP/RTCP
因为IP互联网不是等时系统，所以在发送实时数字数据时需要额外的协议支持。除了允许检测复制或重新排序的
分组的基本次序信息之外，每个分组还必须传送单独的时间戳，告诉接收方应该播放分组中的数据的准确时间。
如果网络中有抖动，接收方需要实现回放缓冲区来准确地重建信号。 - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - 在IP互联网上传输数字音频或视频信号所使用的协议是实时传输协议 (Real-Time Transport Protocol,
RTP)。RTP不包含确保及时交付的机制，必须由底层系统来保证。 RTP提供两个关键的特性：每个分组中的序号
以及时间戳。序号允许接收方检测不按顺序的交付或数据丢失，时间戳允许接收方控制回放。设计RTP是为了传
送包括音频和视频等广泛的实时数据，所以RTP不强制统一的语义解释，而是每个分组以固定的首部开头，首部
中的字段指定如何解释其余的首部字段以及如何解释有效载荷。
******************************************************************************** The RTP header
has the following format: 0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X| CC |M| PT | sequence
number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| timestamp |+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| synchronization source (SSRC) identifier
|+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| contributing source (CSRC)
identifiers || .... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| payload
(audio, video....) || +-+-+-+-+-+-+-+-+-+-+-+-+| ....| padding | count |+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混
合器插入时。各段含义如下： ①版本（V） 2位，标识RTP版本。 ②填充标识（P） 1位，如设置填充位，在包
尾将包含附加填充字，它不属于有效载荷。填充的最后一个八进制包含应该忽略的八进制计数。某些加密算法需
要固定大小的填充字，或为在底层协议数据单元中携带几个RTP包。 ③扩展（X） 1位，如设置扩展位，固定头
后跟一个头扩展。 ④CSRC计数（CC） 4位，CSRC计数包括紧接在固定头后CSRC标识符个数。 ⑤标记（M） 1位
，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标示位，或通过改变位数量
来指定没有标记位。 ⑥载荷类型（PT） 7位，记录后面资料使用哪种 Codec ， receiver 端找出相应的
decoder 解碼出來。 常用 types： Payload Type Codec 0 PCM μ -Law 8 PCM-A Law 9 G..722 audio codec
4 G..723 audio codec 15 G..728 audio codec 18 G..729 audio codec 34 G..763 audio codec 31 G..761
audio codec ⑦系列号 16位，系列号随每个RTP数据包而增加1，由接收者用来探测包损失。系列号初值是随机
的，使对加密的文本攻击更加困难。 ⑧时标 32位，时标反映RTP数据包中第一个八进制数的采样时刻，采样时
刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料
播放出来。由上图可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是
没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将data正确播放出来，如此我们才能播
放出正确无误的信息。 ⑨SSRC 32位，SSRC段标识同步源。此标识不是随机选择的，目的在于使同一RTP包连接
中没有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决
冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。 ⑩CSRC列表 0到15项，每项32
位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源，也仅标识15个。CSRC标
识由混合器插入，采用作用源的SSRC标识。
******************************************************************************** RTP的关键部分是对
变换 (也就是在中间位置改变数据流的编码)或混合 (也就是从多个源接收数据流，把它们组合成一个数据流，
然后发送结果)的支持。混合和组播技术的结合能使交付给每个参与主机的数据报减少。 RTP首部中的字段标识
发送方，指示是否发生混合。同步源标识符字段指定数据流的源站。每个源站必须选择一个惟一的32位标识符，
如果发生冲突，则协议包括解决冲突的机制。当混合器组合多个数据流时，混合器就变成新的数据流的同步源。
但是有关初始源的信息没有丢失，这是因为混合器使用大小可变的参与源ID字段提供正在混合的数据流的同步ID
。4位CC字段给出参与源的数目，最多可以列出15个源。传统的TCP 协议是一个面向连接的协议,它的重传机制和
拥塞控制机制都是不适用于实时多媒体传输的。RTP 是一个应用型的传输层协议,它并不提供任何传输可靠性的
保证和流量的拥塞控制机制。RTP不像传输协议那样发挥作用，在实际应用中不会在IP中直接封装，而是RTP在
UDP上运行，这意味着把每条RTP报文封装到UDP数据报中。使用UDP的主要优点是并发性 -- 单个计算机可以有多
个使用RTP的应用程序，而不会互相干扰。RTP不使用保留的UDP端口号，而是为每个会话分配一个端口，因此必
须把端口号通知给远程的应用程序。通常情况下RTP选择偶数UDP端口号。 - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - RTP控制协议 (RTCP)，是RTP的一个完整部分，提供需要的控制功能。RTCP允许发送方和接收方相互传
输一系列报告，这些报告包含有关正在传输的数据以及网络性能的额外信息。在RTP会话期间，各参与者周期性
地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些
信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输
效率最佳化，故特别适合传送网上的实时数据。当应用程序开始一个rtp会话时将使用两个端口：一个给rtp，一
个给rtcp。rtp本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠
rtcp提供这些服务。RTCP报文封装在UDP中，以便进行传输，发送时使用比它们所属的RTP流的端口号大1的协议
号。 RTCP使用5个基本报文类型允许发送方和接收方交换有关会话的信息。 类型 含义 --------------------
----------------------------------------- 200 发送方报告 (SR) 201 接收方报告 (RR) 202 源描述报文
(SDES) 203 结束报文 (BYE) 204 应用程序特定报文 (APP) 1. 发送方在停止发送数据流时传输一条结束报文。
2. 应用程序特定报文提供了基本功能的扩展，以允许应用程序定义报文类型。 3. 接收方周期性地传输接收方
报告报文，向源通知接收的条件。 4. 发送方周期性地传输发送方报告报文，提供绝对的时间戳。而绝对时间戳
为接收方提供了使多个数据流同步的机制。 5. 发送方还传输源站描述报文，提供有关拥有对源站控制权的用户
的常规信息。 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - H.323不是单个协议，而是制定如何把多个协议组
合起来，形成一个实用的IP电话技术系统。 H.323为IP电话技术使用的协议：协议目的 --------------------
--------------------------- H.225.0 建立通话所使用的信令 H.245 在通话中控制和返回 RTP 实时数据传输
（序列和时限） T.120 交换和通话有关的数据 SIP只涵盖信令，不推荐特殊的编码，也不要求对实时传输使用
RTP。SIP使用C/S交互方式。为了提供有关通话的信息，SIP要依靠一个伴生的协议，即会话说明协议 (SDP)。 -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - IETF提供的在IP环境中的QoS方案：资源预留协议 (Resource
Reservation Protocol, RSVP) 通用开放策略服务 (Common Open Policy Services, COPS) RSVP处理预留请求
并进行应答，它不是路由协议，也不强制在建立数据流时就启用策略，而是在发送任何数据之前运转。每个RSVP
流是单工的 (simplex)，也就是单向传输的。端点使用RSVP在指定了QoS界限的IP互联网上请求单工数据流。如
果路径上的路由器同意请求，则认可数据流，否则拒绝数据流。如果应用程序需要两个方向上的QoS，则每个端
点必须使用RSVP请求单独的数据流。当RSVP请求抵达时，路由器必须对两个方面进行评估：可行性（也就是路由
器是否具有满足请求的资源）和策略（也就是请求是否符合策略约束）。可行性是本地决策，而策略强制要求全
局合作。要实现全局策略，IETF使用两级模型，用C/S模式在两级之间交互作用。当路由器接收到RSVP请求时，
它就变成客户，与服务器协商以确定请求是否符合策略约束，该服务器称为策略确定点（Policy Decision
Point, PDP）。PDP不处理通信量，只对请求进行评估，检查它是否符合全局策略。如果PDP认可请求，则路由器
必须作为策略执行点（Policy Enforcement Point, PEP）进行操作，确保通信量不会超过认可的策略。 COPS协
议定义在路由器和PDP之间的C/S交互作用，或者如果组织有多级策略服务器，就定义路由器和本地PDP之间的C/S
交互作用。虽然COPS定义它自己的报文首部，但是底层格式和RSVP共享许多具体字段。而且，对于请求报文中的
单个数据项，COPS使用和RSVP一样的格式。这样，当路由器接收到RSVP请求时，它可以提取和策略相关的数据项
，把它们放在COPS报文中，把结果发送给PDP。
RTP/RTCP
RTP/RTCP协议简介
实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由
IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供
时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保
证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠
RTCP提供这些服务。
实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量在当前应用进程之
间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数
据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和
RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。
RTCP主要有4个功能:
（1）用反馈信息的方法来提供分配数据的传送质量，这种反馈可以用来进行流量的拥塞控制，也可以用来
监视网络和用来诊断网络中的问题；
（2）为RTP源提供一个永久性的CNAME（规范性名字）的传送层标志，因为在发现冲突或者程序更新重启时
SSRC(同步源标识)会变，需要一个运作痕迹，在一组相关的会话中接收方也要用CNAME来从一个指定的与会者得
到相联系的数据流（如音频和视频）；
（3）根据与会者的数量来调整RTCP包的发送率；
（4）传送会话控制信息，如可在用户接口显示与会者的标识，这是可选功能。
RTP/RTCP工作过程
工作时，RTP协议从上层接收流媒体信息码流（如H.263），装配成RTP数据包发送给下层，下层协议提供RTP
和RTCP的分流。如在UDP中，RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长
度限制，它的最大包长只受下层协议的限制。
RTP会话和流的两级分用
一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个
。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个RTP分组在服务
器端发送出去的时候总是要指定属于哪个会话和流，在接收时也需要进行两级分用，即会话分用和流分用。只有
当RTP使用同步源标识(SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来，才能够使用序列号(Sequence
Number)和时间戳(Timestamp)对分组进行排序和正确回放。
由于实时数据的独有性，不同实时客户可以共用一个RTP实时服务线程和一个RTCP实时服务线程，这样可以
大大减小服务器的负担，而每个文件客户由于请求的文件不同，相应地对速度和开始时间的要求都可能不同，所
以需要有自己独有的RTP文件服务线程和RTCP文件服务线程。
RTP服务线程负责把实时数据流发送给客户，RTCP服务线程根据RTP线程的统计数据，产生发送方报告给客户
。RTP线程和RTCP线程之间通过一段共享内存交互统计数据，对共享内存必须设置互斥体进行保护，防止出现错
误读写。在这种方式下，服务器可以根据每个用户的不同请求和具体情况方便地提供不同的服务。
RTP 时间戳的处理
时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值
给出了分组中数据的第一个字节的采样时间(Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的
，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端
，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，
就可以确定输出的时间间隔。
RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释
，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。
在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳
速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值。
RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送媒体数据的速
度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的
设置相对容易。对已经录制好的本地硬盘上的媒体文件，以H.263格式的文件为例，由于文件本身不包含帧率信
息，所以需要知道录制时的帧率或者设置一个初始值，在发送数据的时候找出发送数据中的帧数目，根据帧率和
预置值来计算时延，以适当的速度发送数据并设置时间戳信息。
RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不
同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声
音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical
Name），尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就
知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告
中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP
时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方
报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中
的时间戳值映射为另一个流中的时间戳值。
基于RTSP协议流媒体服务器的实现[转载]
RTSP，实时流协议，是一个C/S多媒体节目协议，它可以控制流媒体数据在IP网络上的发送，同时提供用于音频
和视频流的“VCR模式”远程控制功能，如停止、快进、快退和定位。同时RTSP又是一个应用层协议
，用来与诸如RTP、RSVP等更低层的协议一起，提供基于Internet的整套流化服务。基于RTSP协议流媒体服务器
的实现方案可以让流媒体在IP上自由翱翔。
RTSP协议
1．协议特点
RTSP协议具有如下的特点：
● 可扩展性：新方法和参数很容易加入RTSP。
● 易解析：RTSP可由标准 HTTP或MIME解析器解析。
● 安全：RTSP使用网页安全机制。
● 独立于传输：RTSP传输通道，可使用不可靠数据包协议（UDP）或可靠数据包协议（RDP），如要实现应用级
可靠，可使用诸如TCP的可靠流协议。
● 记录设备控制：协议可控制记录和回放设备。
● 适合专业应用：通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。
● 演示描述中立：协议未强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少需包含一个RTSP
URI。
● 代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个
“缺口”。
● 适当的服务器控制：如用户启动一个流，则也可以停止一个流。
● 传输协调：实际处理连续媒体流前，用户可协调传输方法。
● 性能协调：如基本特征无效，则必须有一些清理机制让用户决定那种方法不生效。这允许用户提出适合自己
的界面。
2．同其他协议的关系
RTSP在功能上与HTTP有重叠，最明显的交叉是在流媒体内容的发布上——大多是通过网页进行的。目前的协议规
范同时允许网页服务器和流媒体服务器支持RTSP实现。例如，演示描述可通过HTTP或RTSP获取，这样减少了基于
浏览器情况下的往返传递时间，同时也支持独立的RTSP 服务器与不依赖HTTP的客户端通信。
但是，RTSP与HTTP 的本质差别在于以下五个方面
● RTSP和HTTP是两个不同的协议，它们采用不同的方法和协议标志符。
● RTSP协议的数据发送不占用协议带宽，并且以不同的协议发送。
● HTTP是一个不对称协议，客户端发出请求，服务器应答。在RTSP中，客户端和服务器都可发出请求，且请求
是有状态的。
● HTTP是一个无状态协议，而RTSP在任何情况下，必须保持一定状态，以便在请求确认后的很长时间内，仍可
设置参数，控制媒体流。
● RTSP使用ISO 10646（UTF-8）定义，而不使用ISO 8859-1定义，保持与当前的HTML一致。
虽然大多数实时媒体采用RTP作为传输协议，但RTSP并不绑定RTP。
重用HTTP的功能至少在两个方面有好处:安全和代理。由于要求非常接近，因此在缓存、代理和授权上采用HTTP
功能是有价值的。
RTSP的实现
RTSP功能实现结构如下图所示。
RTSP在流媒体传输过程中，仅仅为双方建立连接，并不具备任何智能，也就不能很好地应付难以预料的网络状态
。因此，必须在它原有功能的基础上，进行改进。
1、初始化
在建立连接之前，客户端应向服务器提出测试请求，即要求服务器向客户端发送相应的测试数据包。初始化的目
的，是为了获取客户端和服务器之间的一些网络参数，估测基本网络状况，并以此选择相应的网络传输协议，使
客户端获得最佳观看效果。
接到这个请求之后，服务器将根据自身情况进行如下测试：
● 利用同客户端建立的RTSP通道，采用TCP协议，下发测试数据包。
● 采用UDP协议，向客户端下发测试数据包。
测试数据包仅做测试用，上面带有相应的时间和顺序信息，其内部数据并无任何意义。
需要向RTSP增加一个新的方法TEST，以支持这种传输前的测试工作。
2、TCP传输
如果在TCP测试中，客户端反馈良好，即丢包率在可承受范围之内，并且在规定时间内到达，那么就认为客户端
同服务器之间的网络状况良好， 可以采用RTP over TCP的方式发送数据。由于TCP没有丢包（其自身具有重传机
制），网络状况又属于良好，因此客户端将有较高的视听享受。
当子网内存在防火墙时，就需要采用RTSP附加数据传输方式。即把音视频数据直接打包，在RTSP通信信道内传输
。这种传输方式也存在一定的问题：
● 传输过程中，只是把音视频文件当成一个普通文件来处理，而没有考虑到它的音视频特性，不利于以后的扩
展。
● 音频与视频文件没有分离，不利于某些特殊需求的场合。例如，客户端需要对音、视频做不同的处理。
● 客户端的反馈和RTSP的控制信息也是通过同一条RTSP信道传送，因此控制效率不高。
因此，一般情况下，都默认使用RTP over TCP的方式发送数据。
3、UDP传输
如果在TCP测试中，客户端的反馈存在比较大的问题，即网络情况不理想，就应该考虑进行UDP测试。
目前初步采取的措施，在服务器端准备了两种码率的视频文件——高码率和低码率。
收到客户端的TEST方法后，将采用UDP协议下发测试包。采取的策略是每间隔2秒，下发一个1500字节的UDP数据
包。当丢包率处于一定范围（75％～85％）之内，就认为客户端的网络状况基本良好，可以下发高码率的电影文
件;否则，认为测试不成功，由于网络状况的限制，仅对客户端下发低码率的电影文件。
在基于UDP的播放过程中，可能会出现轻微的马赛克，这是完全可以接受的。这些马赛克出现的主要原因是：
● 不可靠连接造成的网络丢包，为客户端被动丢包。
● 高质量文件（DVD－>MP4）的高数据量，使得客户端解码线程和显示线程出现拥塞，从而出现客户端主动丢包
。
但从整体而言，UDP传输消耗的带宽，要比TCP小许多。在一般的视频点播要求下，使用基于UDP的传输线路，是
完全可以满足要求的。
4、传输反馈
在传输过程中，主要采取的方式是RTP over TCP或RTP over UDP，因此，在RTP端口之外，还存在一个回传端口
RTCP。
在服务器收到客户端的RTCP回传信息后，需要对其进行判断。如果客户端的丢包率、解码率等指标在一定限度之
下，就认为目前传送的视频文件可令客户端获得最大程度的音视频享受;否则，考虑改为传输更低码率的视频文
件或放弃这次RTSP会话，以避免更大范围的拥塞。
5、实际效果
采取如上方法设计的系统，可以满足视频点播的基本要求，避免了服务器视频文件下发的盲目性，同时使客户端
应用效果最好。
引入智能流技术
随着针对流媒体技术研究的不断深入，简单的流媒体实现已经不能满足人们日益增长的网络文化需求。即使在宽
带条件下，当网络用户达到一定限额时，简单的流媒体技术将面临着网络拥塞、丢包等常见的网络问题。因此，
如何在网络出现异常的情况下，依然保证客户端音视频享受的最大化，就成为现在研究的热点。
一种解决方法是服务器减少发送给客户端的数据而阻止再缓冲，在RealSystem 5.0中，这种方法称为“视频流瘦
化”。这种方法的限制是RealVideo文件必须是一种数据速率设计，结果可通过抽取内部帧扩展到更低速率，导
致质量较低，离原始数据速率越远，质量越差。
另一种解决方法是根据不同连接速率创建多个文件，根据用户连接，服务器发送相应文件，这种方法带来制作和
管理上的困难，而且，用户连接是动态变化的，服务器也无法实时协调。
智能流技术通过两种途径克服带宽协调和流瘦化:首先，确立一个编码框架，允许不同速率的多个流同时编码，
合并到同一个文件中；第二，采用一种复杂客户/服务器机制探测带宽变化。
针对软件、设备和数据传输速度上的差别，用户以不同带宽浏览音视频内容。为满足客户要求，Real Networks
公司编码、记录不同速率下媒体数据，并保存在单一文件中，此文件被称为智能流文件，即创建可扩展流式文件
。当客户端发出请求时，它将其带宽容量传给服务器，媒体服务器根据客户带宽将智能流文件相应部分传送给用
户。以此方式，用户可使用最优质的传输，制作人员只需要压缩一次，管理员也只需要维护单一文件，而媒体服
务器根据所得带宽自动切换。智能流通过描述Internet上变化的带宽特点来发送高质量媒体并保证其可靠性，并
对混合连接环境的内容授权提供了解决方法。这样流媒体实现方式如下：对所有连接速率环境创建一个文件。在
混合环境下以不同速率传送媒体。根据网络的变化情况，无缝切换到其他速率。关键帧优先，音频比部分视频帧
数据更重要，向后兼容老版本RealPlayer。
端口说明：554端口默认情况下用于“Real Time Streaming Protocol”（实时流协议，简称RTSP），该协
议是由RealNetworks和Netscape共同提出的，通过RTSP协议可以借助于Internet将流媒体文件传送到RealPlayer
中播放，并能有效地、最大限度地利用有限的网络带宽，传输的流媒体文件一般是Real服务器发布的，包括
有.rm、.ram。如今，很多的下载软件都支持RTSP协议，比如FlashGet、影音传送带等等。
端口漏洞：目前，RTSP协议所发现的漏洞主要就是RealNetworks早期发布的Helix Universal Server存在缓
冲区溢出漏洞，相对来说，使用的554端口是安全的。
操作建议：为了能欣赏并下载到RTSP协议的流媒体文件，建议开启554端口。
1024端口
端口说明：1024端口一般不固定分配给某个服务，在英文中的解释是“Reserved”（保留）。之前，我们曾
经提到过动态端口的范围是从1024～65535，而1024正是动态端口的开始。该端口一般分配给第一个向系统发出
申请的服务，在关闭服务的时候，就会释放1024端口，等待其他服务的调用。
端口漏洞：著名的YAI木马病毒默认使用的就是1024端口，通过该木马可以远程控制目标计算机，获取计算
机的屏幕图像、记录键盘事件、获取密码等，后果是比较严重的。
操作建议：一般的杀毒软件都可以方便地进行YAI病毒的查杀，所以在确认无YAI病毒的情况下建议开启该端
口。
1080端口
端口说明：1080端口是Socks代理服务使用的端口，大家平时上网使用的WWW服务使用的是HTTP协议的代理服
务。而Socks代理服务不同于HTTP代理服务，它是以通道方式穿越防火墙，可以让防火墙后面的用户通过一个IP
地址访问Internet。Socks代理服务经常被使用在局域网中，比如限制了QQ，那么就可以打开QQ参数设置窗口，
选择“网络设置”，在其中设置Socks代理服务（如图1）。另外，还可以通过安装Socks代理软件来使用QQ，比
如Socks2HTTP、SocksCap32等。
端口漏洞：著名的代理服务器软件WinGate默认的端口就是1080，通过该端口来实现局域网内计算机的共享
上网。不过，如Worm.Bugbear.B（怪物II）、Worm.Novarg.B（SCO炸弹变种B）等蠕虫病毒也会在本地系统监听
1080端口，给计算机的安全带来不利。
操作建议：除了经常使用WinGate来共享上网外，那么其他的建议关闭该端口。
1755端口
端口说明：1755端口默认情况下用于“Microsoft Media Server”（微软媒体服务器，简称MMS），该协议
是由微软发布的流媒体协议，通过MMS协议可以在Internet上实现Windows Media服务器中流媒体文件的传送与播
放。这些文件包括.asf、.wmv等，可以使用Windows Media Player等媒体播放软件来实时播放。其中，具体来讲
，1755端口又可以分为TCP和UDP的MMS协议，分别是MMST和MMSU，一般采用TCP的MMS协议，即MMST。目前，流媒
体和普通下载软件大部分都支持MMS协议。
端口漏洞：目前从微软官方和用户使用MMS协议传输、播放流媒体文件来看，并没有什么特别明显的漏洞，
主要一个就是MMS协议与防火墙和NAT（网络地址转换）之间存在的兼容性问题。
操作建议：为了能实时播放、下载到MMS协议的流媒体文件，建议开启该端口。
文章来源:http://computer.mblogger.cn/wucountry/posts/18995.aspx
阅读全文
0 0
- RTSP协议分析(1)
- RTSP协议分析
- RTSP协议分析
- RTSP协议分析-3
- RTSP协议分析-1
- RTSP协议分析-2
- rtsp协议简单分析
- RTSP协议分析
- RTSP 协议分析
- RTSP 协议分析
- RTSP 协议分析
- RTSP协议分析
- RTSP协议分析
- RTSP 协议分析
- RTSP 协议分析
- RTSP协议分析
- RTSP协议分析
- RTSP 协议分析
- NOIP 冲刺 模板：树的直径
- 基于 Anaconda3 5.0.0 JupyterLab 0.27.0 使用 ftplib 演示 IPv4 和 IPv6 上传文件和下载文件
- 1011 最大公约数GCD——51Nod(__gcd() )
- 数据结构笔记之树与二叉树
- 机器学习（周志华）习题3.3
- RTSP协议分析
- java中HashMap排序中实现Comparator接口
- 数据库存储过程
- python下载及安装
- 怎样连接Redis数据库
- HashMap从源码角度分析遍历过程
- 项目拆分
- java多线程-基础概念
- 左神算法课-找出数组中出现次数超过一半的数及其进阶
