16,472
社区成员
发帖
与我相关
我的任务
分享rtsp://xxxx/xx/xx.rm
我先获得rtsp://xxxx/xx/xx.rm该文件的信息，包括：有效性、大小、最后一次修改的时间。
该怎么办呐？哪有rtsp协议的文档？Real Player是咋弄地？？
这个问题我问了好多遍了
该怎么办呐？哪有rtsp协议的文档？Real Player是咋弄地？？
这个问题我问了好多遍了
...全文
请发表友善的回复…
发表回复
RED_spring 2002-09-30
- 打赏
- 举报
学习。
devil97518 2002-09-30
- 打赏
- 举报
gz
up
up
masterlee 2002-09-30
- 打赏
- 举报
1.5 RTSP扩展
全部媒体服务器都没有相同的功能性之后，媒体服务器将有必要支持要求的不同的一套。例如：
* 这样服务器也许仅仅能作重放地能力，而不必有支持记录要求的必要。
* 如果它仅仅支持现场的事件，服务器也可以不要查找地能力（绝对定位）。
* 一些服务器可以不支持播放流参数和不GET_PARAMETER和SET_PARAMETER。
服务器应该实现全部在第12节所描述的功能。
不询问服务器不可能是播放描述的创造者最高层次。这与在http/1.1 [ 2 ]中类似，这时，在里边[ H19.6 ]被阐述的方法不有可能被全部服务器支持。RTSP能以3方法被扩展，在这里按被支持的变化的大小的顺序编成表。
* 要这些模式能被新参数被扩展，只要这些参数能够被容器忽略。（这和把新参数加到HTML签条上相等。）如果当模式扩展不被支持时，客户端需要否定地能力。一个对扩展地相应标签也要加到请求里面：失败（见12.32章）。
* 新方法能够被加进去。如果信息的接受方不理解要求，它用错误代码501应答（实现），并且，发件人应该不试图再一次使用这方法。另外，客户端可以用任意选择方法来询问用服务器支持的方法。服务器应该把它支持使用的方法编成表作为应答公共的回答标题。
* 协议书的新版本允许几乎所有方面（除了协议书版本编号的位置）地改变，而且能被定义。
1.6 总体操作
每个陈述都和媒体流在RTSP URL附近识别。全部的陈述和组成媒体描述的属性是通过陈述描述文件定义的，格式是说明书的范围。播放描述文件通过客户端使用HTTP或者象EMAIL一样的东西得到，可以不必放在媒体服务器上。
为这说明的目的，有人假设陈述描述一个以上的——每个都包含相同的时间轴。因为说明简单，并且丧失普遍性，一个陈述描述确切地说包括这样的陈述。陈述可以包括几个媒体流。
陈述描述文件包含组成陈述的媒体流的定义描述，包括他们的编码，语言和能使客户端选择媒体的最适当的结合的其他的参数。
在这陈述描述中，每个个别通过RTSP 控制的媒体流都是被RTSP URL识别，在那里特殊媒体流指向媒体服务器和命名存在服务器上的流。几个媒体流能被置于不同的服务器；
例如，声音和录像流为了能通过服务器而被切割。描述也列举服务器能作那些传输方法。
除媒体参数之外，网络目的地址和端口也需要被决定。几个操作的方式也能被识别：
Unicast ：
媒体用客户端选的端口号被传送到RTSP要求的源。作为选择，媒体在和RTSP同样的可靠的溪流上传送。
多点选择，服务器选择地址：
媒体服务器挑选地址和端口。这是现场或者VOD的传输的典型的情况。
多点选择，客户端选择地址:
如果服务器参与已经存在的多点传送会议，多点传送端口，地址和密码化钥匙会议描述，在这个说明的范围外面。
1.7 RTSP 规定
RTSP可以经由一个分开的协议，一个独立的控制通道控制被送的流。例如,RTSP当数据经由UDP流动时，控制在一个TCP连接。这样,数据就算媒体没有收到RTSP求被，任可以继续传递。另外,在它的周期里面，一条单个的媒介流可以是RTSP在不同的TCP连接上连续发出的请求控制的。因此，服务器需要维护会议形态能把RTSP要求与流结合起来。这形态转换在A部分描述。
不过，以下在服务器上定义流资源的分配和使用中扮演核心的角色：
建立，播放，录像，暂停和关闭。
建立：
使服务器把资源分配给流，开始RTSP会议。
播放和录像;
经过分配的流经过建立开始传送了。
暂停：
临时挂起服务器上的流。
关闭：
获得自由与溪流有关联的资源。RTSP会议在服务器上停止。
RTSP模式归功于使用会议标识（第12.37节）来识别正在操作的RTSP会议。服务器作为对于准备要求的反应产生会议标识符（第10.4节）。
1.8 与其它协议的联系
RTSP在功能中于http有一些重复。它也可以用流的内容的最初连接与HTTP联系，它时通过网页完成工作的。现在的协议书说明想允许在实现RTSP的网络服务器和媒体服务器之间的不同的传递点。例如，陈述表达用HTTP或RTSP取得，这样可以减少基于WEB浏览器的工作量，也允许独立的RTSP服务器和不依赖于HTTP的客户端。
但是，RTSP在不同的协议中，数据传输上与HTTP根本上不同的。HTTP是客户端发出要求的不对称的协议书，并且，服务器作应答。在RTSP中，媒体客户端和媒体服务器能出来
进行应答。另外，RTSP要求是没有界限的：在要求被接受之后，他们可以设置参数，继续长期控制媒体流。
把HTTP功能性重复使用至少有两个地方，安全和代理。它们必要条件非常类似，所以，它们有在缓冲，代理和证明适应HTTP工作的能力是有价值。
当大部分的实时媒体将象运输议定书那样使用RTP的时候，RTSP不被捆绑到RTP上。
RTSP设想陈述表达的存在格式能够是静态或者动态的，包含几个服务器流的属性。
2 国际协定
既然定义和语法与HTTP/1.1在很多地方相似，这说明仅仅是指他们是被定义而不是拷贝它的一部分。为了简洁，[ HX.Y ]在的HTTP/说明1.1（RFC [ 2 ] 2068）的X.Y部分提到过。
在这文件中所有被指定的机制都可以在散文和扩大的Backus-Naur方式的类似于[ H2.1 ]中的方法来描述。这将在RFC 2234 [17]中详细的描述，它是不同于RTSP说明书主张的“1#”区分标志。
在这记录中，我们用交替的和小型段落来提供背景和动机。这打算给那些没有在表达一种理解为什么他们在RTSP的方法的公式化表述的读者。
3 协议参数
3.1协议版本
[H3.1]应用，用RTSP代替HTTP。
3.2 RTSP URL
“RTSP”和“RTSPU”计划被用来经RTSP协议来访问网络资源。这部分为RTSP URL定义特有的句法和语句。
rtsp_URL = ( "rtsp:" | "rtspu:" )
"//" host [ ":" port ] [ abs_path ]
host = <A legal Internet host domain name of IP address
(in dotted decimal form), as defined by Section 2.1 of RFC 1123 \cite{rfc1123}>
port = *DIGIT
ABS_PATH 在 [H3.2.1]中定义
片断和疑问标识符在这一时间没有用，要到RTSP服务器上解释。
配置RTSP需要指令经可靠的协议发出（在因特网，TCP范围内），另一方面，配置RTSPU识别协议是不可信赖的（在因特网，UDP范围内）。
如果端口是空的，或者没有给，端口554就被假设。语法计划被识别的资源能够通过RTSP在服务器上监听TCP连接或者是在主机端口的UDP包的控制。这些资源的请求连接是RTSP-URL。
在URL的中IP地址无论什么时候只要可能，应避免被打开。
陈述或流通过原文的媒体标识符识别来使用URL的（RFC [ 20 ] 1738）字符集和逃跑规则[ H3.2 ]。URL可以提到流或者流的集合，比如描述。因此，在第10节所描述的要求能在陈述的范围内适用于全部陈述和个人流。一些要求方法只能到流，不能到陈述，反之也然。
例如：RTSP URL
rtsp://media.example.com:554/twister/audiotrack
在陈述内部，不同的音频流缠绕在一起，经过RTSP请求发出控制信号，经过一个TCP连接到media.example.com的554端口。
也可以是这样的连接：
rtsp://media.example.com:554/twister
不同的东西缠绕在一起，可以是音频或者视频组成的。
这不意味着在URL中有通往参照流的标准的路。表达描述在表达和URL中为个别的流定义阶层性的关系。表达描述可以给流“a.mov”和全部陈述“b.mov”命名。对客户端来说，RTSP URL的路组成部分是不透明的。服务器不暗示着任何特别的文件系统结构。
这种减弱措施也允许表达陈述用非RTSP媒体控制协议简单地在URL代替协议书。
3.3 会议标识符
会议标识符是对RTSP不透明的并且用标准URI编码方法（i.e.,lws是以％来进行扩展的）来编码。它能包含任何的八位值。会议标识符必须在全局中是唯一的。对H.323，会议标识符的值是被用的。
conference-id = 1*xchar
会议标识符被用于允许RTSP会议获得媒体服务器参与的多媒体会议参数。那些会议被在这说明的范围之外的协议创建，例如，H.323或SIP[12]。代替RTSP客户明确的提供的传输信息，例如，它请求媒体服务器用会议报告中的数值代替。
3.4 话路标识符
话路标识符是对任意长度的字符串不透明的。线性的空白必定是URI扩展。一个话路标识符必须是随意的和至少八位长来使其难以被猜出。（见16节）
session-id = 1*( ALPHA | DIGIT | safe )
3.5 SMPTE 相对时间标记
一个SMPTE相对时间标记表达了相对于剪辑开始的时间。相对时间标记是作为SMPTE 帧数通道精确度的时间代码来表达的。时间代码的格式为：时：分：秒；帧.分帧，在剪辑开始的原点。默认的SMPTE格式时“SMPTE 30 点”格式，与帧速是29.97帧每秒。其他SMPTE代码可能被支持（例如“SMPTE 25”）通过用可选择的“SMPTE 时间”的使用。对在时间值的“帧”域能被定义在0到29之间。在30和29.97帧每秒之间的不同每分钟的头两个帧的失去，除了每第十分钟。如果帧值是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 ]
比如：
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）表示流的绝对的和表演的开始有关系的位置。数的左边可以是秒或者是小时，分，秒。数的右边可以测定一秒的一部分。节目的开始应对应于0.0秒开始。
否定的值不能定义。现在特殊的数被定义为现场的事件的现在的瞬息。它也许仅仅为现场的事件而使用。
NPT是在DSM-CC中被定义：直观地讲，NPT是联系观众和程序的钟。它在VCR上经常被数字化的展示。NPT正常接近时，当快速向前时以正常播放模式（模拟1）以较快的输率运行，当反向时消耗以及在停止时固定。
npt-range = ( npt-time "-" [ npt-time ] ) | ( "-" npt-ti
全部媒体服务器都没有相同的功能性之后，媒体服务器将有必要支持要求的不同的一套。例如：
* 这样服务器也许仅仅能作重放地能力，而不必有支持记录要求的必要。
* 如果它仅仅支持现场的事件，服务器也可以不要查找地能力（绝对定位）。
* 一些服务器可以不支持播放流参数和不GET_PARAMETER和SET_PARAMETER。
服务器应该实现全部在第12节所描述的功能。
不询问服务器不可能是播放描述的创造者最高层次。这与在http/1.1 [ 2 ]中类似，这时，在里边[ H19.6 ]被阐述的方法不有可能被全部服务器支持。RTSP能以3方法被扩展，在这里按被支持的变化的大小的顺序编成表。
* 要这些模式能被新参数被扩展，只要这些参数能够被容器忽略。（这和把新参数加到HTML签条上相等。）如果当模式扩展不被支持时，客户端需要否定地能力。一个对扩展地相应标签也要加到请求里面：失败（见12.32章）。
* 新方法能够被加进去。如果信息的接受方不理解要求，它用错误代码501应答（实现），并且，发件人应该不试图再一次使用这方法。另外，客户端可以用任意选择方法来询问用服务器支持的方法。服务器应该把它支持使用的方法编成表作为应答公共的回答标题。
* 协议书的新版本允许几乎所有方面（除了协议书版本编号的位置）地改变，而且能被定义。
1.6 总体操作
每个陈述都和媒体流在RTSP URL附近识别。全部的陈述和组成媒体描述的属性是通过陈述描述文件定义的，格式是说明书的范围。播放描述文件通过客户端使用HTTP或者象EMAIL一样的东西得到，可以不必放在媒体服务器上。
为这说明的目的，有人假设陈述描述一个以上的——每个都包含相同的时间轴。因为说明简单，并且丧失普遍性，一个陈述描述确切地说包括这样的陈述。陈述可以包括几个媒体流。
陈述描述文件包含组成陈述的媒体流的定义描述，包括他们的编码，语言和能使客户端选择媒体的最适当的结合的其他的参数。
在这陈述描述中，每个个别通过RTSP 控制的媒体流都是被RTSP URL识别，在那里特殊媒体流指向媒体服务器和命名存在服务器上的流。几个媒体流能被置于不同的服务器；
例如，声音和录像流为了能通过服务器而被切割。描述也列举服务器能作那些传输方法。
除媒体参数之外，网络目的地址和端口也需要被决定。几个操作的方式也能被识别：
Unicast ：
媒体用客户端选的端口号被传送到RTSP要求的源。作为选择，媒体在和RTSP同样的可靠的溪流上传送。
多点选择，服务器选择地址：
媒体服务器挑选地址和端口。这是现场或者VOD的传输的典型的情况。
多点选择，客户端选择地址:
如果服务器参与已经存在的多点传送会议，多点传送端口，地址和密码化钥匙会议描述，在这个说明的范围外面。
1.7 RTSP 规定
RTSP可以经由一个分开的协议，一个独立的控制通道控制被送的流。例如,RTSP当数据经由UDP流动时，控制在一个TCP连接。这样,数据就算媒体没有收到RTSP求被，任可以继续传递。另外,在它的周期里面，一条单个的媒介流可以是RTSP在不同的TCP连接上连续发出的请求控制的。因此，服务器需要维护会议形态能把RTSP要求与流结合起来。这形态转换在A部分描述。
不过，以下在服务器上定义流资源的分配和使用中扮演核心的角色：
建立，播放，录像，暂停和关闭。
建立：
使服务器把资源分配给流，开始RTSP会议。
播放和录像;
经过分配的流经过建立开始传送了。
暂停：
临时挂起服务器上的流。
关闭：
获得自由与溪流有关联的资源。RTSP会议在服务器上停止。
RTSP模式归功于使用会议标识（第12.37节）来识别正在操作的RTSP会议。服务器作为对于准备要求的反应产生会议标识符（第10.4节）。
1.8 与其它协议的联系
RTSP在功能中于http有一些重复。它也可以用流的内容的最初连接与HTTP联系，它时通过网页完成工作的。现在的协议书说明想允许在实现RTSP的网络服务器和媒体服务器之间的不同的传递点。例如，陈述表达用HTTP或RTSP取得，这样可以减少基于WEB浏览器的工作量，也允许独立的RTSP服务器和不依赖于HTTP的客户端。
但是，RTSP在不同的协议中，数据传输上与HTTP根本上不同的。HTTP是客户端发出要求的不对称的协议书，并且，服务器作应答。在RTSP中，媒体客户端和媒体服务器能出来
进行应答。另外，RTSP要求是没有界限的：在要求被接受之后，他们可以设置参数，继续长期控制媒体流。
把HTTP功能性重复使用至少有两个地方，安全和代理。它们必要条件非常类似，所以，它们有在缓冲，代理和证明适应HTTP工作的能力是有价值。
当大部分的实时媒体将象运输议定书那样使用RTP的时候，RTSP不被捆绑到RTP上。
RTSP设想陈述表达的存在格式能够是静态或者动态的，包含几个服务器流的属性。
2 国际协定
既然定义和语法与HTTP/1.1在很多地方相似，这说明仅仅是指他们是被定义而不是拷贝它的一部分。为了简洁，[ HX.Y ]在的HTTP/说明1.1（RFC [ 2 ] 2068）的X.Y部分提到过。
在这文件中所有被指定的机制都可以在散文和扩大的Backus-Naur方式的类似于[ H2.1 ]中的方法来描述。这将在RFC 2234 [17]中详细的描述，它是不同于RTSP说明书主张的“1#”区分标志。
在这记录中，我们用交替的和小型段落来提供背景和动机。这打算给那些没有在表达一种理解为什么他们在RTSP的方法的公式化表述的读者。
3 协议参数
3.1协议版本
[H3.1]应用，用RTSP代替HTTP。
3.2 RTSP URL
“RTSP”和“RTSPU”计划被用来经RTSP协议来访问网络资源。这部分为RTSP URL定义特有的句法和语句。
rtsp_URL = ( "rtsp:" | "rtspu:" )
"//" host [ ":" port ] [ abs_path ]
host = <A legal Internet host domain name of IP address
(in dotted decimal form), as defined by Section 2.1 of RFC 1123 \cite{rfc1123}>
port = *DIGIT
ABS_PATH 在 [H3.2.1]中定义
片断和疑问标识符在这一时间没有用，要到RTSP服务器上解释。
配置RTSP需要指令经可靠的协议发出（在因特网，TCP范围内），另一方面，配置RTSPU识别协议是不可信赖的（在因特网，UDP范围内）。
如果端口是空的，或者没有给，端口554就被假设。语法计划被识别的资源能够通过RTSP在服务器上监听TCP连接或者是在主机端口的UDP包的控制。这些资源的请求连接是RTSP-URL。
在URL的中IP地址无论什么时候只要可能，应避免被打开。
陈述或流通过原文的媒体标识符识别来使用URL的（RFC [ 20 ] 1738）字符集和逃跑规则[ H3.2 ]。URL可以提到流或者流的集合，比如描述。因此，在第10节所描述的要求能在陈述的范围内适用于全部陈述和个人流。一些要求方法只能到流，不能到陈述，反之也然。
例如：RTSP URL
rtsp://media.example.com:554/twister/audiotrack
在陈述内部，不同的音频流缠绕在一起，经过RTSP请求发出控制信号，经过一个TCP连接到media.example.com的554端口。
也可以是这样的连接：
rtsp://media.example.com:554/twister
不同的东西缠绕在一起，可以是音频或者视频组成的。
这不意味着在URL中有通往参照流的标准的路。表达描述在表达和URL中为个别的流定义阶层性的关系。表达描述可以给流“a.mov”和全部陈述“b.mov”命名。对客户端来说，RTSP URL的路组成部分是不透明的。服务器不暗示着任何特别的文件系统结构。
这种减弱措施也允许表达陈述用非RTSP媒体控制协议简单地在URL代替协议书。
3.3 会议标识符
会议标识符是对RTSP不透明的并且用标准URI编码方法（i.e.,lws是以％来进行扩展的）来编码。它能包含任何的八位值。会议标识符必须在全局中是唯一的。对H.323，会议标识符的值是被用的。
conference-id = 1*xchar
会议标识符被用于允许RTSP会议获得媒体服务器参与的多媒体会议参数。那些会议被在这说明的范围之外的协议创建，例如，H.323或SIP[12]。代替RTSP客户明确的提供的传输信息，例如，它请求媒体服务器用会议报告中的数值代替。
3.4 话路标识符
话路标识符是对任意长度的字符串不透明的。线性的空白必定是URI扩展。一个话路标识符必须是随意的和至少八位长来使其难以被猜出。（见16节）
session-id = 1*( ALPHA | DIGIT | safe )
3.5 SMPTE 相对时间标记
一个SMPTE相对时间标记表达了相对于剪辑开始的时间。相对时间标记是作为SMPTE 帧数通道精确度的时间代码来表达的。时间代码的格式为：时：分：秒；帧.分帧，在剪辑开始的原点。默认的SMPTE格式时“SMPTE 30 点”格式，与帧速是29.97帧每秒。其他SMPTE代码可能被支持（例如“SMPTE 25”）通过用可选择的“SMPTE 时间”的使用。对在时间值的“帧”域能被定义在0到29之间。在30和29.97帧每秒之间的不同每分钟的头两个帧的失去，除了每第十分钟。如果帧值是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 ]
比如：
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）表示流的绝对的和表演的开始有关系的位置。数的左边可以是秒或者是小时，分，秒。数的右边可以测定一秒的一部分。节目的开始应对应于0.0秒开始。
否定的值不能定义。现在特殊的数被定义为现场的事件的现在的瞬息。它也许仅仅为现场的事件而使用。
NPT是在DSM-CC中被定义：直观地讲，NPT是联系观众和程序的钟。它在VCR上经常被数字化的展示。NPT正常接近时，当快速向前时以正常播放模式（模拟1）以较快的输率运行，当反向时消耗以及在停止时固定。
npt-range = ( npt-time "-" [ npt-time ] ) | ( "-" npt-ti
masterlee 2002-09-30
- 打赏
- 举报
RFC2326
Real Time流媒体协议（RTSP）
这个备忘录的地位：
这个文档详细说明了因特网传输协议中的一种因特网标准路径协议，而且为了提高需要不断讨论和建议。请查阅正确的,与这协议相关的标准化的声明和情况的因特网官方协议标准协议.分发这备忘录是没有限制的.
摘要：
Real Time流媒体协议或者RTSP，是一种在应用层上控制实时传输数据的工具。RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据的反馈和存贮的文件。这协议有意识的控制多重数据,传递会议,提供一种选择传递通道,比如UDP,多点传递UDP,
和TCP,以及一种基于RTP(RFC1889)选择传递机制.
目录内容:(略).
1. 介绍
1.1 目的
实时流媒体传输协议建立和控制一种简单的,或者几种时间同步,连续的媒体流,比如音频和视频.他不是代表性的传递连续流,尽管交错受到控制的连续媒体流是可能的(看10.12章).另一点,RTSP担当着为多媒体服务提供网络遥控控制.
被控制的流的设置是被一个介绍描写定义的.这个备忘录不是为介绍图象定义的格式.
这里没有RTSP连接的概念：作为代替，一个服务器的维护，一个被验证人标签的会议。一个RTSP会议是绝不会连到传输层连接的，比如，TCP连接。在一个RTSP会议中，一个 RTSP会议客户端可以开和关许多可靠的传送器，连接到发送RTSP请求的服务器上，作为选择，它可以使用无连接传输协议，比如UDP。
用RTSP控制流可以使用RTP，但是RTSP的操作不依靠通常传输连续媒体的传输机制。这个协议有意地在运作在上与HTTP/1.1相似。所以HTTP地扩展机制能够最大程度上被加到RTSP。但是RTSP与HTTP地许多重要不同在于：
* RTSP介绍许多新模式，并且有一个不同地协议标识符。
* 一个RTSP服务器需要默认地几乎所有地情况来维持正常运行。
* RTSP服务端和客户端都要能发出请求。
* 数据通过不同地协议传送。
* RTSP是用比ISO 8859-1要好地ISO 10646定义的，使它与当前的HTML的国际化努力相一致。
* 要求URI总使包括绝对URI.因为向后兼容性在历史上范过大错，HTTP/1.1只能传递要求的绝对路径，把主机名放入没有联系的标题栏上。
这使“虚拟主机”更简单，这时，带1 IP地址的单一的主机可以服务几个文件树。
本协议支持一下操作：
从媒体服务器端取回媒体资料：
客户端能够要求一个图象描述通过HTTP或者其它模式。如果图象使被多点传输的，图象描述包含了多点传输的地址和端口，用来传输连续媒体。如果图像只能经过UNICAST，那客户端就要因为安全而提供给目的文件。
对会议的媒体服务器的邀请：
一个媒体服务器端能够被邀请参加一个存在的会议，可以向后播放图像，记录媒体文件的全部或者一部分。这种模式对分布式教学软件是有用的。查看会议中的几个部分可以按遥控控制按钮。
对存在图像的媒体追加：
尤其为存在的图像，如果服务器能告诉客户端可以利用的补充性的媒体，那它是有用的。
在http/1.1 [ 2 ]中RTSP要求可以是通过代理，通道和缓存。
1.2 要求
在这些文档中的关键字“必需”，“一定不能”，“必需的”，“会”，“不会”，“应该”，“不应该”，“被推荐的”，“可以”，和“可选择的”都在RFC2119中解释描述。
1.3 术语
一些术语采用于HTTP/1.1.在这里就不列举了。
总体控制：
多重流的控制通过服务器使用一种简单的时间线。为了音频/视频的反馈，可以通过客户端发送一个简单的开始或暂停的指令去控制视频/音频的反馈。
讨论：
一个多部件的，多媒体的图像，这里的多表示大于或者等于一。
客户端：
客户端从服务器端请求连续的媒体数据。
连接：
为了通讯的目的在两个程序之间确定的传输层虚拟线路。
容器文件：
可以包含多媒体，包含图像的文件被打开的时候。RTSP服务器可以在这些文件上提供总体控制，尽管容器文件的观念没有被植入协议中。
连续媒体：
数据是数据源和连接之间的实时关系，也就是说，接受器和数据源之间要不断产生关系联接。最普通的连续媒体的例子是音频和动画视频。连接媒体可以交互式的工作，它们在源和接受器之间是一种紧密的实时关系。或者是流的形式，这种关系就没有那么严格了。
实体：
是作为一个请求或者回应的有效负荷的信息传递。一个实体包含在头部的信息形式和在实体中的内容。这些在第八张中介绍。
媒体的初始化：
多媒体数字编解码特殊的初始化，这些包括时钟输率，颜色表等。任何独立传输器信息的请求，是通过客户端在媒体初始化设置阶段当中媒体流发生的重放来实现的。
媒体参数:
一个媒体类型的特定参数可以在流重放前或者重放时改变。
媒体服务器：
服务器倘若在重放一个或者多个媒体流，不同的媒体流内部的图像可以来源于不同的媒体服务器。一个媒体服务器可以放在相同或者不同的主机上作为的调用网络服务器。
媒体服务器迂回：
重新定向一个媒体客户端到不同的媒体服务器。
流：
一个简单的媒体实例，比如一个音频流或者也是一个简单白班或者共享应用程序组，当用到RTP时，一个流在RTP周期内由创建的RTP和RTCP组成的，这是和DSM-CC流的定义相同的。
消息：
RTSP通讯的基本单元。由15章里面定义的八位匹配语法的结构化序列组成，并且经过一个连接或者无连接协议转移。
参与者：
一个会议成员。一个参与者可以是机器，比如是一个媒体记录或者重放服务器。
陈述：
一套由一条或者几条流作为完全的媒体反馈，使用下面的表达陈述送到客户端。在RTSP上下文中的多数场合，这表示这些流的主体控制，但是不是一定要的。
陈述描写：
一个陈述描写包括关于一个陈述里面的一个或者多个媒体流的信息。比如，一套关于连接编码，网络地址和信息。另外，象SDP的TETF协议，使用现场陈述作为会议。这个陈述可以采用不同的格式，不仅仅限制于会议描述对SDP的安排。
回应：
一个RTSP回应。如果一个HTTP回应能够接受，那就能被清楚的表示。
请求；
一个RTSP请求。如果一个HTTP请求能够接受，那就能被清楚的表示。
RTSP会议：
一个完整的RTSO处理。比如，一个电影的观看过程。一个会议通常由客户端为连续媒体流建立一个传输机制，用播放或者录像开始一个流，用停止来关闭流。
传输器初始化：
在客户端和服务器端之间的传输器信息（端口号，传输协议等）的商议。
1.4 协议属性
RTSP有以下属性：
可扩展性：
新的模式和参数可以很容易的加到RTSP当中。
易于解析：
RTSP能够被标准的HTTP或者MIME解析。
安全性：
RTSP也使用网络的安全机制。所有的HTTP验证机制比如基本的（RFC 2068[2,11章]）和分类坚定可以直接使用，也可以重新使用传输器或者网络层安全机制。
传输独立性：
RTSP即可以使用用户数据报协议（RFC 768）,可靠传输协议（RDP,RFC 1151,没有被广泛使用）或者可靠的流协议，比如TCP，作为可靠的执行应用层。
多服务器能力：
每一个媒体流在其播放时能够从不同的服务器传来，客户端不同的媒体服务器自动的建立几个并发控制会议，媒体同步是在传输层执行的。
记录装置的控制：
这个协议能够同时控制录像和播放，也可以选择其中的一种模式。
流控制的分离和会议开始:
流控制是从为一个会议媒体服务器分离出来的。唯一的要求是会议开始协议即可以提供，也能被创建新的会议标识符。在特殊情况下，STP或H.233可以建立会议的服务器。
适合专业人员应用：
RTSP支持框架层的精度。通过SMPTE时间来标记，允许细微的数据编辑。
播放种类的中立性：
本协议没有加强一种特别的播放描述或者图文件格式，以及能够使传递用过的类型。但是播放描述必须包含至少一个RTSP连接。
代理和防火墙的友好性：
本协议应该同时通过应用层和传输层防火墙容易地掌握。一个防火墙对于理解为UDP媒体流开地“洞”建立模式是需要地。
HTTP友好性：
在明确RTSP重新使用HTTP观念后。这样，目前地基础设施就能够再使用了。这个基础设施包含了为了标签联系起来和内容地PICS在内。不过，控制连续的媒体在大部分的例子需要服务器状态之后，RTSP不能加到HTTP上。
分配服务器控制：
如果客户端能开始一个流，它必须能停止流。服务器不应该给客户端开始流，这样客户端就不能停止流的流动。
传输协商：
客户端能在需要办理连续的媒体流之前实际上协商传输方法。
能力协商：
如果基本的特点不能使用，客户端为了决定哪个方法不去被实现必须有一些清理的机制。这允许客户端出示适当的用户界面。例如，如果寻找不被允许，用户界面必须能拒绝承认移动滑行的位置指示器。
RTSP里的早期的要求是多客户端的能力。不过，它决心已一种更好地方法去使得本协议能很容易地扩展多客户端地想定。流标识符能被几个控制流使用，这样，“远程通过”将成为可能。本协议将不谈到几个客户端协商接近的方法。这被委托给“社会协议书”和一些其他的层控制机制。
Real Time流媒体协议（RTSP）
这个备忘录的地位：
这个文档详细说明了因特网传输协议中的一种因特网标准路径协议，而且为了提高需要不断讨论和建议。请查阅正确的,与这协议相关的标准化的声明和情况的因特网官方协议标准协议.分发这备忘录是没有限制的.
摘要：
Real Time流媒体协议或者RTSP，是一种在应用层上控制实时传输数据的工具。RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据的反馈和存贮的文件。这协议有意识的控制多重数据,传递会议,提供一种选择传递通道,比如UDP,多点传递UDP,
和TCP,以及一种基于RTP(RFC1889)选择传递机制.
目录内容:(略).
1. 介绍
1.1 目的
实时流媒体传输协议建立和控制一种简单的,或者几种时间同步,连续的媒体流,比如音频和视频.他不是代表性的传递连续流,尽管交错受到控制的连续媒体流是可能的(看10.12章).另一点,RTSP担当着为多媒体服务提供网络遥控控制.
被控制的流的设置是被一个介绍描写定义的.这个备忘录不是为介绍图象定义的格式.
这里没有RTSP连接的概念：作为代替，一个服务器的维护，一个被验证人标签的会议。一个RTSP会议是绝不会连到传输层连接的，比如，TCP连接。在一个RTSP会议中，一个 RTSP会议客户端可以开和关许多可靠的传送器，连接到发送RTSP请求的服务器上，作为选择，它可以使用无连接传输协议，比如UDP。
用RTSP控制流可以使用RTP，但是RTSP的操作不依靠通常传输连续媒体的传输机制。这个协议有意地在运作在上与HTTP/1.1相似。所以HTTP地扩展机制能够最大程度上被加到RTSP。但是RTSP与HTTP地许多重要不同在于：
* RTSP介绍许多新模式，并且有一个不同地协议标识符。
* 一个RTSP服务器需要默认地几乎所有地情况来维持正常运行。
* RTSP服务端和客户端都要能发出请求。
* 数据通过不同地协议传送。
* RTSP是用比ISO 8859-1要好地ISO 10646定义的，使它与当前的HTML的国际化努力相一致。
* 要求URI总使包括绝对URI.因为向后兼容性在历史上范过大错，HTTP/1.1只能传递要求的绝对路径，把主机名放入没有联系的标题栏上。
这使“虚拟主机”更简单，这时，带1 IP地址的单一的主机可以服务几个文件树。
本协议支持一下操作：
从媒体服务器端取回媒体资料：
客户端能够要求一个图象描述通过HTTP或者其它模式。如果图象使被多点传输的，图象描述包含了多点传输的地址和端口，用来传输连续媒体。如果图像只能经过UNICAST，那客户端就要因为安全而提供给目的文件。
对会议的媒体服务器的邀请：
一个媒体服务器端能够被邀请参加一个存在的会议，可以向后播放图像，记录媒体文件的全部或者一部分。这种模式对分布式教学软件是有用的。查看会议中的几个部分可以按遥控控制按钮。
对存在图像的媒体追加：
尤其为存在的图像，如果服务器能告诉客户端可以利用的补充性的媒体，那它是有用的。
在http/1.1 [ 2 ]中RTSP要求可以是通过代理，通道和缓存。
1.2 要求
在这些文档中的关键字“必需”，“一定不能”，“必需的”，“会”，“不会”，“应该”，“不应该”，“被推荐的”，“可以”，和“可选择的”都在RFC2119中解释描述。
1.3 术语
一些术语采用于HTTP/1.1.在这里就不列举了。
总体控制：
多重流的控制通过服务器使用一种简单的时间线。为了音频/视频的反馈，可以通过客户端发送一个简单的开始或暂停的指令去控制视频/音频的反馈。
讨论：
一个多部件的，多媒体的图像，这里的多表示大于或者等于一。
客户端：
客户端从服务器端请求连续的媒体数据。
连接：
为了通讯的目的在两个程序之间确定的传输层虚拟线路。
容器文件：
可以包含多媒体，包含图像的文件被打开的时候。RTSP服务器可以在这些文件上提供总体控制，尽管容器文件的观念没有被植入协议中。
连续媒体：
数据是数据源和连接之间的实时关系，也就是说，接受器和数据源之间要不断产生关系联接。最普通的连续媒体的例子是音频和动画视频。连接媒体可以交互式的工作，它们在源和接受器之间是一种紧密的实时关系。或者是流的形式，这种关系就没有那么严格了。
实体：
是作为一个请求或者回应的有效负荷的信息传递。一个实体包含在头部的信息形式和在实体中的内容。这些在第八张中介绍。
媒体的初始化：
多媒体数字编解码特殊的初始化，这些包括时钟输率，颜色表等。任何独立传输器信息的请求，是通过客户端在媒体初始化设置阶段当中媒体流发生的重放来实现的。
媒体参数:
一个媒体类型的特定参数可以在流重放前或者重放时改变。
媒体服务器：
服务器倘若在重放一个或者多个媒体流，不同的媒体流内部的图像可以来源于不同的媒体服务器。一个媒体服务器可以放在相同或者不同的主机上作为的调用网络服务器。
媒体服务器迂回：
重新定向一个媒体客户端到不同的媒体服务器。
流：
一个简单的媒体实例，比如一个音频流或者也是一个简单白班或者共享应用程序组，当用到RTP时，一个流在RTP周期内由创建的RTP和RTCP组成的，这是和DSM-CC流的定义相同的。
消息：
RTSP通讯的基本单元。由15章里面定义的八位匹配语法的结构化序列组成，并且经过一个连接或者无连接协议转移。
参与者：
一个会议成员。一个参与者可以是机器，比如是一个媒体记录或者重放服务器。
陈述：
一套由一条或者几条流作为完全的媒体反馈，使用下面的表达陈述送到客户端。在RTSP上下文中的多数场合，这表示这些流的主体控制，但是不是一定要的。
陈述描写：
一个陈述描写包括关于一个陈述里面的一个或者多个媒体流的信息。比如，一套关于连接编码，网络地址和信息。另外，象SDP的TETF协议，使用现场陈述作为会议。这个陈述可以采用不同的格式，不仅仅限制于会议描述对SDP的安排。
回应：
一个RTSP回应。如果一个HTTP回应能够接受，那就能被清楚的表示。
请求；
一个RTSP请求。如果一个HTTP请求能够接受，那就能被清楚的表示。
RTSP会议：
一个完整的RTSO处理。比如，一个电影的观看过程。一个会议通常由客户端为连续媒体流建立一个传输机制，用播放或者录像开始一个流，用停止来关闭流。
传输器初始化：
在客户端和服务器端之间的传输器信息（端口号，传输协议等）的商议。
1.4 协议属性
RTSP有以下属性：
可扩展性：
新的模式和参数可以很容易的加到RTSP当中。
易于解析：
RTSP能够被标准的HTTP或者MIME解析。
安全性：
RTSP也使用网络的安全机制。所有的HTTP验证机制比如基本的（RFC 2068[2,11章]）和分类坚定可以直接使用，也可以重新使用传输器或者网络层安全机制。
传输独立性：
RTSP即可以使用用户数据报协议（RFC 768）,可靠传输协议（RDP,RFC 1151,没有被广泛使用）或者可靠的流协议，比如TCP，作为可靠的执行应用层。
多服务器能力：
每一个媒体流在其播放时能够从不同的服务器传来，客户端不同的媒体服务器自动的建立几个并发控制会议，媒体同步是在传输层执行的。
记录装置的控制：
这个协议能够同时控制录像和播放，也可以选择其中的一种模式。
流控制的分离和会议开始:
流控制是从为一个会议媒体服务器分离出来的。唯一的要求是会议开始协议即可以提供，也能被创建新的会议标识符。在特殊情况下，STP或H.233可以建立会议的服务器。
适合专业人员应用：
RTSP支持框架层的精度。通过SMPTE时间来标记，允许细微的数据编辑。
播放种类的中立性：
本协议没有加强一种特别的播放描述或者图文件格式，以及能够使传递用过的类型。但是播放描述必须包含至少一个RTSP连接。
代理和防火墙的友好性：
本协议应该同时通过应用层和传输层防火墙容易地掌握。一个防火墙对于理解为UDP媒体流开地“洞”建立模式是需要地。
HTTP友好性：
在明确RTSP重新使用HTTP观念后。这样，目前地基础设施就能够再使用了。这个基础设施包含了为了标签联系起来和内容地PICS在内。不过，控制连续的媒体在大部分的例子需要服务器状态之后，RTSP不能加到HTTP上。
分配服务器控制：
如果客户端能开始一个流，它必须能停止流。服务器不应该给客户端开始流，这样客户端就不能停止流的流动。
传输协商：
客户端能在需要办理连续的媒体流之前实际上协商传输方法。
能力协商：
如果基本的特点不能使用，客户端为了决定哪个方法不去被实现必须有一些清理的机制。这允许客户端出示适当的用户界面。例如，如果寻找不被允许，用户界面必须能拒绝承认移动滑行的位置指示器。
RTSP里的早期的要求是多客户端的能力。不过，它决心已一种更好地方法去使得本协议能很容易地扩展多客户端地想定。流标识符能被几个控制流使用，这样，“远程通过”将成为可能。本协议将不谈到几个客户端协商接近的方法。这被委托给“社会协议书”和一些其他的层控制机制。
