词语解释
RTSP协议(Real Time Streaming Protocol)是一种应用层协议,它是基于TCP/IP协议的,主要用于媒体服务器上的流媒体数据(如视频和音频)的控制。它定义了客户端和服务器之间的通信,允许客户端控制服务器上的媒体流,例如播放,暂停,快进,快退等操作。 RTSP协议的主要作用是实现客户端和服务器之间的实时流媒体传输,包括视频和音频流。它可以实现客户端和服务器之间的双向通信,客户端可以发送命令,服务器可以响应客户端的请求,例如发送媒体流,暂停媒体流,快进媒体流等。 RTSP协议的应用非常广泛,主要用于实现实时媒体流的传输,如视频会议,网络电视,网络电影,在线音乐,网络游戏等,也可以用于实时视频监控,远程教育,虚拟现实,数字医疗等领域。 RTSP协议的另一个重要作用是实现媒体流的可靠性,它可以实现媒体流的可靠性,并允许客户端在收到媒体流之后,可以对媒体流进行控制,例如暂停,快进,快退等操作,以及可以在媒体流中插入广告,提供更好的用户体验。 总之,RTSP协议是一种应用层协议,主要用于实现实时媒体流的传输,它可以实现客户端和服务器之间的双向通信,允许客户端控制服务器上的媒体流,并可以实现媒体流的可靠性,提供更好的用户体验。 实时流协议RTSP是由RealNetworks和Netscape共同提出的,该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或RTP完成数据传输。 HTTP与RTSP相比,HTTP传送HTML,而RTP传送的 是多媒体数据。HTTP请求由客户机发出,服务器作出响应;使用RTSP时,客户机和服务器都可 以发出请求,即RTSP可以是双向的。 6.3 RTSP协议 实时流协议(RTSP)是应用级协议,控制实时数据的发送。RTSP提供了一个可扩展框架,使 实时数据,如音频与视频,的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据 。该协议目的在于控制多个数据发送连接,为选择发送通道,如UDP、组播UDP与TCP,提供途径 ,并为选择基于RTP上发送机制提供方法。 6.3.1 简介 6.3.1.1 目的 实时流协议(RTSP)建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制 流交*是可能的,通常它本身并不发送连续流。换言之,RTSP充当多媒体服务器的网络远程控 制。RTSP连接没有绑定到传输层连接,如TCP。在RTSP连接期间,RTSP用户可打开或关闭多个对 服务器的可*传输连接以发出RTSP 请求。此外,可使用无连接传输协议,如UDP。RTSP流控制 的流可能用到RTP,但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操 作上与HTTP/1.1类似,因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下: 从媒体服务器上检索媒体: 用户可通过HTTP或其它方法提交一个演示描述。如演示是组播,演示式就包含用于连续媒体 的的组播地址和端口。如演示仅通过单播发送给用户,用户为了安全应提供目的地址。 媒体服务器邀请进入会议: 媒体服务器可被邀请参加正进行的会议,或回放媒体,或记录其中一部分,或全部。这种模 式在分布式教育应用上很有用,会议中几方可轮流按远程控制按钮。 将媒体加到现成讲座中: 如服务器告诉用户可获得附加媒体内容,对现场讲座显得尤其有用。如HTTP/1.1中类似,RTSP 请求可由代理、通道与缓存处理。 6.3.1.2 协议特点 RTSP 特性如下: 可扩展性: 新方法和参数很容易加入RTSP。 易解析: RTSP可由标准 HTTP或MIME解吸器解析。 安全: RTSP使用网页安全机制。 独立于传输: RTSP可使用不可*数据报协议(UDP)、可*数据报协议(RDP),如要实现应用级可*,可 使用可*流协议。 多服务器支持: 每个流可放在不同服务器上,用户端自动同不同服务器建立几个并发控制连接,媒体同步在 传输层执行。 记录设备控制: 协议可控制记录和回放设备。 流控与会议开始分离: 仅要求会议初始化协议提供,或可用来创建唯一会议标识号。特殊情况下, SIP或H.323 可用来邀请服务器入会。 适合专业应用: 通过SMPTE 时标,RTSP支持帧级精度,允许远程数字编辑 演示描述中立: 协议没强加特殊演示或元文件,可传送所用格式类型;然而,演示描述至少必须包含一个RTSP URI。 代理与防火墙友好: 协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法,为UDP媒体流打开一个"缺 口"。 HTTP友好: 此处,RTSP明智的采用HTTP观念,使现在结构都可重用。结构包括Internet 内容选择平台 (PICS)。由于在大多数情况下控制连续媒体需要服务器状态, RTSP不仅仅向HTTP 添加方法 。 适当的服务器控制: 如用户启动一个流,他必须也可以停止一个流。 传输协调; 实际处理连续媒体流前,用户 可协调传输方法。 性能协调: 如基本特征无效,必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的 用户界面。 6.3.1.3扩展RTSP 由于不是所有媒体服务器有着相同的功能,媒体服务器有必要支持不同请求集。RTSP 可以 如下三种方式扩展,这里以改变大小排序: 以新参数扩展。如用户需要拒绝通知,而方法扩展不支持,相应标记就加入要求的段中。 加入新方法。如信息接收者不理解请求,返回501错误代码(还未实现),发送者不应再次 尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支 持的方法。 定义新版本协议,允许改变所有部分。(除了协议版本号位置) 6.3.1.4操作模式 每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义 。使用HTTP或其它途径用户可获得这个文件,它没有必要保存在媒体服务器上。 为了说明,假设演示描述描述了多个演示,其中每个演示维持了一个公共时间轴。为简化说 明,且不失一般性,假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参 数外,网络目标地址和端口也需要决定。下面区分几种操作模式: 单播: 以用户选择的端口号将媒体发送到RTSP请求源。 组播,服务器选择地址: 媒体服务器选择组播地址和端口,这是现场直播或准点播常用的方式。 组播,用户选择地址: 如服务器加入正在进行的组播会议,组播地址、端口和密匙由会议描述给出。 6.3.1.5 RTSP状态 RTSP控制通过单独协议发送的流,与控制通道无关。例如,RTSP控制可通过TCP连接,而数 据流通过UDP。因此,即使媒体服务器没有收到请求,数据也会继续发送。在连接生命期,单个 媒体流可通过不同TCP连接顺序发出请求来控制。所以,服务器需要维持能联系流与RTSP请求的 连接状态。RTSP中很多方法与状态无关,但下列方法在定义服务器流资源的分配与应用上起着 重要的作用: SETUP: 让服务器给流分配资源,启动RTSP连接。 PLAY与RECORD: 启动SETUP 分配流的数据传输。 PAUSE: 临时停止流,而不释放服务器资源。 TEARDOWN: 释放流的资源,RTSP连接停止。 标识状态的RTSP方法使用连接头段识别RTSP连接,为响应SETUP请求,服务器连 接产生连接标识。 6.3.1.6 与其他协议关系 RTSP在功能上与HTTP有重叠,与HTTP相互作用体现在与流内容的初始接触是通过网页的。目 前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如, 演示描述可通过HTTP和RTSP检索,这降低了浏览器的往返传递,也允许独立RTSP 服务器与用户 不全依*HTTP。 但是,RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议,用户发 出请求,服务器作出响应。RTSP中,媒体用户和服务器都可发出请求,且其请求都是无状态的 ;在请求确认后很长时间内,仍可设置参数,控制媒体流。重用HTTP功能至少在两个方面有好 处,即安全和代理。要求非常接近,在缓存、代理和授权上采用HTTP功能是有价值的。 当大多数实时媒体使用RTP作为传输协议时,RTSP没有绑定到RTP。RTSP假设存在演示描述格 式可表示包含几个媒体流的演示的静态与临时属性。 6.3.2 协议参数 6.3.3 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代码。 6.3.4 实体 如不受请求方法或响应状态编码限制,请求和响应信息可传输实体,实体由实体头文件和试 题体组成,有些响应仅包括实体头。在此,根据谁发送实体、谁接收实体,发送者和接收者可 分别指用户和服务器。 实体头定义实体体可选元信息,如没有实体体,指请求标识的资源。扩展头机制允许定义附 加实体头段,而不用改变协议,但这些段不能假定接收者能识别。不可识别头段应被接收者忽 略,而让代理转发。 6.3.5 连接 RTSP请求可以几种不同方式传送: 1、持久传输连接,用于多个请求/响应传输。 2、每个请求/响应传输一个连接。 3、无连接模式。 传输连接类型由RTSP URI来定义。对 "rtsp" 方案,需要持续连接;而"rtspu"方案,调用 RTSP 请求发送,而不用建立连接。 不象HTTP,RTSP允许媒体服务器给媒体用户发送请求。然而,这仅在持久连接时才支持,否 则媒体服务器没有可*途径到达用户,这也是请求通过防火墙从媒体服务器传到用户的唯一途 径。 6.3.6 方法定义 方法记号表示资源上执行的方法,它区分大小写。新方法可在将来定义,但不能以$开头。 某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和 服务器操作复杂,并强加附加开销,除非有必要,应避免这样做。插入二进制数据仅在RTSP通 过TCP传输时才可使用。流数据(如RTP包)用一个ASCII美圆符号封装,后跟一个一字节通道标 识,其后是封装二进制数据的长度,两字节整数。
实时流协议RTSP是由RealNetworks和Netscape共同提出的,该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或RTP完成数据传输。 HTTP与RTSP相比,HTTP传送HTML,而RTP传送的 是多媒体数据。HTTP请求由客户机发出,服务器作出响应;使用RTSP时,客户机和服务器都可 以发出请求,即RTSP可以是双向的。 6.3 RTSP协议 实时流协议(RTSP)是应用级协议,控制实时数据的发送。RTSP提供了一个可扩展框架,使 实时数据,如音频与视频,的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据 。该协议目的在于控制多个数据发送连接,为选择发送通道,如UDP、组播UDP与TCP,提供途径 ,并为选择基于RTP上发送机制提供方法。 6.3.1 简介 6.3.1.1 目的 实时流协议(RTSP)建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制 流交*是可能的,通常它本身并不发送连续流。换言之,RTSP充当多媒体服务器的网络远程控 制。RTSP连接没有绑定到传输层连接,如TCP。在RTSP连接期间,RTSP用户可打开或关闭多个对 服务器的可*传输连接以发出RTSP 请求。此外,可使用无连接传输协议,如UDP。RTSP流控制 的流可能用到RTP,但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操 作上与HTTP/1.1类似,因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下: 从媒体服务器上检索媒体: 用户可通过HTTP或其它方法提交一个演示描述。如演示是组播,演示式就包含用于连续媒体 的的组播地址和端口。如演示仅通过单播发送给用户,用户为了安全应提供目的地址。 媒体服务器邀请进入会议: 媒体服务器可被邀请参加正进行的会议,或回放媒体,或记录其中一部分,或全部。这种模 式在分布式教育应用上很有用,会议中几方可轮流按远程控制按钮。 将媒体加到现成讲座中: 如服务器告诉用户可获得附加媒体内容,对现场讲座显得尤其有用。如HTTP/1.1中类似,RTSP 请求可由代理、通道与缓存处理。 6.3.1.2 协议特点 RTSP 特性如下: 可扩展性: 新方法和参数很容易加入RTSP。 易解析: RTSP可由标准 HTTP或MIME解吸器解析。 安全: RTSP使用网页安全机制。 独立于传输: RTSP可使用不可*数据报协议(UDP)、可*数据报协议(RDP),如要实现应用级可*,可 使用可*流协议。 多服务器支持: 每个流可放在不同服务器上,用户端自动同不同服务器建立几个并发控制连接,媒体同步在 传输层执行。 记录设备控制: 协议可控制记录和回放设备。 流控与会议开始分离: 仅要求会议初始化协议提供,或可用来创建唯一会议标识号。特殊情况下, SIP或H.323 可用来邀请服务器入会。 适合专业应用: 通过SMPTE 时标,RTSP支持帧级精度,允许远程数字编辑 演示描述中立: 协议没强加特殊演示或元文件,可传送所用格式类型;然而,演示描述至少必须包含一个RTSP URI。 代理与防火墙友好: 协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法,为UDP媒体流打开一个"缺 口"。 HTTP友好: 此处,RTSP明智的采用HTTP观念,使现在结构都可重用。结构包括Internet 内容选择平台 (PICS)。由于在大多数情况下控制连续媒体需要服务器状态, RTSP不仅仅向HTTP 添加方法 。 适当的服务器控制: 如用户启动一个流,他必须也可以停止一个流。 传输协调; 实际处理连续媒体流前,用户 可协调传输方法。 性能协调: 如基本特征无效,必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的 用户界面。 6.3.1.3扩展RTSP 由于不是所有媒体服务器有着相同的功能,媒体服务器有必要支持不同请求集。RTSP 可以 如下三种方式扩展,这里以改变大小排序: 以新参数扩展。如用户需要拒绝通知,而方法扩展不支持,相应标记就加入要求的段中。 加入新方法。如信息接收者不理解请求,返回501错误代码(还未实现),发送者不应再次 尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支 持的方法。 定义新版本协议,允许改变所有部分。(除了协议版本号位置) 6.3.1.4操作模式 每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义 。使用HTTP或其它途径用户可获得这个文件,它没有必要保存在媒体服务器上。 为了说明,假设演示描述描述了多个演示,其中每个演示维持了一个公共时间轴。为简化说 明,且不失一般性,假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参 数外,网络目标地址和端口也需要决定。下面区分几种操作模式: 单播: 以用户选择的端口号将媒体发送到RTSP请求源。 组播,服务器选择地址: 媒体服务器选择组播地址和端口,这是现场直播或准点播常用的方式。 组播,用户选择地址: 如服务器加入正在进行的组播会议,组播地址、端口和密匙由会议描述给出。 6.3.1.5 RTSP状态 RTSP控制通过单独协议发送的流,与控制通道无关。例如,RTSP控制可通过TCP连接,而数 据流通过UDP。因此,即使媒体服务器没有收到请求,数据也会继续发送。在连接生命期,单个 媒体流可通过不同TCP连接顺序发出请求来控制。所以,服务器需要维持能联系流与RTSP请求的 连接状态。RTSP中很多方法与状态无关,但下列方法在定义服务器流资源的分配与应用上起着 重要的作用: SETUP: 让服务器给流分配资源,启动RTSP连接。 PLAY与RECORD: 启动SETUP 分配流的数据传输。 PAUSE: 临时停止流,而不释放服务器资源。 TEARDOWN: 释放流的资源,RTSP连接停止。 标识状态的RTSP方法使用连接头段识别RTSP连接,为响应SETUP请求,服务器连 接产生连接标识。 6.3.1.6 与其他协议关系 RTSP在功能上与HTTP有重叠,与HTTP相互作用体现在与流内容的初始接触是通过网页的。目 前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如, 演示描述可通过HTTP和RTSP检索,这降低了浏览器的往返传递,也允许独立RTSP 服务器与用户 不全依*HTTP。 但是,RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议,用户发 出请求,服务器作出响应。RTSP中,媒体用户和服务器都可发出请求,且其请求都是无状态的 ;在请求确认后很长时间内,仍可设置参数,控制媒体流。重用HTTP功能至少在两个方面有好 处,即安全和代理。要求非常接近,在缓存、代理和授权上采用HTTP功能是有价值的。 当大多数实时媒体使用RTP作为传输协议时,RTSP没有绑定到RTP。RTSP假设存在演示描述格 式可表示包含几个媒体流的演示的静态与临时属性。 6.3.2 协议参数 6.3.3 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代码。 6.3.4 实体 如不受请求方法或响应状态编码限制,请求和响应信息可传输实体,实体由实体头文件和试 题体组成,有些响应仅包括实体头。在此,根据谁发送实体、谁接收实体,发送者和接收者可 分别指用户和服务器。 实体头定义实体体可选元信息,如没有实体体,指请求标识的资源。扩展头机制允许定义附 加实体头段,而不用改变协议,但这些段不能假定接收者能识别。不可识别头段应被接收者忽 略,而让代理转发。 6.3.5 连接 RTSP请求可以几种不同方式传送: 1、持久传输连接,用于多个请求/响应传输。 2、每个请求/响应传输一个连接。 3、无连接模式。 传输连接类型由RTSP URI来定义。对 "rtsp" 方案,需要持续连接;而"rtspu"方案,调用 RTSP 请求发送,而不用建立连接。 不象HTTP,RTSP允许媒体服务器给媒体用户发送请求。然而,这仅在持久连接时才支持,否 则媒体服务器没有可*途径到达用户,这也是请求通过防火墙从媒体服务器传到用户的唯一途 径。 6.3.6 方法定义 方法记号表示资源上执行的方法,它区分大小写。新方法可在将来定义,但不能以$开头。 某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和 服务器操作复杂,并强加附加开销,除非有必要,应避免这样做。插入二进制数据仅在RTSP通 过TCP传输时才可使用。流数据(如RTP包)用一个ASCII美圆符号封装,后跟一个一字节通道标 识,其后是封装二进制数据的长度,两字节整数。
抱歉,此页面的内容受版权保护,复制需扣除次数,次数不足时需付费购买。
如需下载请点击:点击此处下载
扫码付费即可复制
RLMAC | RATI | PANID | ESCAM | EIB | Ec/Ior | GDPUP | 干扰带 | VAMOS | G.lite | DSU-R | 无线协议 |