锐英源软件
第一信赖

精通

英语

开源

擅长

开发

培训

胸怀四海 

第一信赖

当前位置:锐英源 / 英语翻译 / 基于HTTP协议对QuickTime RTSP和RTP协议进行通道支持
服务方向
人工智能数据处理
人工智能培训
kaldi数据准备
小语种语音识别
语音识别标注
语音识别系统
语音识别转文字
kaldi开发技术服务
软件开发
运动控制卡上位机
机械加工软件
软件开发培训
Java 安卓移动开发
VC++
C#软件
汇编和破解
驱动开发
联系方式
固话:0371-63888850
手机:138-0381-0136
Q Q:396806883
微信:ryysoft

锐英源精品开源心得,转载请注明:“锐英源www.wisestudy.cn,孙老师作品,电话13803810136。”需要全文内容也请联系孙老师。

基于HTTP协议对QuickTime RTSP和RTP协议进行通道支持

QuickTime 4.1 adds HTTP to its’ Streaming Transport capabilities. The addition of HTTP streaming allows QuickTime to utilize HTTP (RFC 1945 Hypertext Transfer Protocol 1.0 and RFC 2068 1945 Hypertext Transfer Protocol 1.1) proxies so viewers behind a firewall can access QuickTime presentations.

QuickTime 4.1增加了HTTP的流媒体传输能力。添加HTTP流允许QuickTime使用RFC 1945 HTTP(超文本传输协议1.0和RFC 2068 1945 1.1超文本传输协议)代理,所以浏览器在防火墙后面可以访问QuickTime演示。

The HTTP transport is built from two separate HTTP GET and POST requests initiated by the client. The server then binds the connections to form a virtual full-duplex connection. HTTP传输由客户端发起的两个单独的HTTP GET和POST请求建立。然后,服务器结合的连接,以形成一个虚拟全双工连接。

This paper documents the protocol used forming this type of connection, and notes implementation details associated with its use. 本文记录了协议,用于形成这种类型的连接,并指出与其使用相关的实施细则。

Protocol Requirements 协议要求

· It must support use of unmodified RTSP/RTP. 它必须支持使用未修改的RTSP和RTP。
· It must be acceptable to HTTP proxies. 它必须接受HTTP代理。
· It must identify the requests and replies as non-cacheable by a proxy. 必须识别请求和回复停机的代理。
· All requests must originate from the client. 所有请求都必须从客户端发起。
· It must uniquely identify the request pairs so that they may be successfully bound by the server. 必须惟一地标识请求配对,以便它们可以由服务器成功绑定。
· All requests must be made in such a way that they connect to the same RTSP server. This can be a challenge when the server is behind a DNS round robin for example. 所有请求必须连接到相同的RTSP服务器。例如当服务器在DNS后面循环,这可能是一个挑战,。
· Any request must be identifiable as one that will eventually tunnel an RTSP conversation and RTP data. 任何请求必须最终将RTSP谈话和RTP数据识别为一体。

Relationship to RTSP/RTP RTSP和RTP的关系

Using standard RTSP/RTP it is possible to stream a presentation to a user via a single TCP connection. (See RFC 2036 “Real Time Streaming Protocol (RTSP)”, section 10.12) 使用标准的RTSP和RTP可能是通过单一TCP连接向用户演示。RFC 2036(请参见“实时流协议(RTSP)”,10.12节)

Unfortunately, that is not sufficient to reach a significant population of Internet users.These users are typically on private IP networks where the client machines have indirectaccess to the public Internet via email and HTTP Proxies. 不幸的是,这并不足以达到一个重要的互联网用户的人口的要求。这些用户通常是私有IP网络环境中,客户端计算机已通过电子邮件和HTTP代理服务器直接接入公共互联网。

The QuickTime HTTP transport exploits the capability of HTTP GET and POST methods to carry an indefinite amount of data in their reply, and message body
respectively. In the most simple case, the client makes a HTTP GET request to the streaming server to open the server to client channel. Then the client makes a POST
request to the server to open the client to server channel.

QuickTime HTTP传输利用HTTP GET和POST的能力方法,在他们的回复中传递无限的数据量,并且和消息体分别。在最简单的情况下,客户端发出HTTP GET请求流媒体服务器打开服务器到客户端的通道。然后,客户端发出一个POST 请求发送到服务器以打开客户机到服务器的频道。

(HTTP GET)
|----<<<< data <<<<< ----| | - - - - - < < < < < < < < < - - - - - |数据
client -----| |---- server 客户端- - - - - - | | - - - - -服务器
|-- >>>> data >>>>-------| | - - - > > > > > > > >数据- - - - - - - |
(HTTP POST)
The virtual connection makes it possible to use unmodified RTSP over the connection. 虚拟连接使得能够通过该连接使用未修改的RTSP。

HTTP Requirements HTTP要求

Version – All requests are made using HTTP version 1.0. Binding the Channels – Each client HTTP request must include a “x-sessioncookie” header with a Globally Unique Identifier (GUID) as it’s value. This makes it possible for the server to unambiguously bind the 2 channels. This protocol uses the value as a simple opaque token passed to the Clib 'strcmp' function.

版本—所有的请求都是使用HTTP 1.0版。渠道——每个客户端的HTTP请求必须包含一个“x-会话cookie”头有一个全局唯一标识符(GUID)作为它的值。这可能使服务器明确绑定2通道。这协议使用值作为一个简单的不透明的令牌传递给Clib'strcmp'函数。

Caching - Server replies include "Cache-Control: no-store", and client requests include the "Pragma: no-cache" as directives in the headers. These are not required by the protocol. It is recommended that implementations x-server-ip-address Header - The server may optionally include a "x-server-ip-address" followed by an IP address in dotted quad format in it's reply to the client's initial GET request. When this header is present, the client must direct its’ POST request to the stated IP address, regardless of the IP address returned via DNS lookup.

缓存——服务器回复包括“cache - control:no-store”,和客户端请求包括“Pragma:no - cache”开头指令。这些都不是所要求的协议。建议实现x-server-ip-address——服务器可以选择包括一个“x-server-ip-address”后跟一个IP地址在虚线四格式回复客户的最初GET请求。这个开头存在时,客户端必须直接“POST请求的IP地址,不用管DNS查询返回的IP地址。

This insures that both requests will connect to the same server among potentially several servers in a server farm. Many times these server clusters will be allocated connections via a round robin DNS or other load balancing algorithms. 这确保请求将连接到相同的服务器中潜在的多个服务器之间的服务器群。很多时候这些服务器群将通过一个循环DNS或其它负载平衡算法分配连接。

Meaning of HTTP errors in replies - HTTP errors reflect the unwillingness or inability of the server to form the virtual full duplex connection. They do not imply RTSP errors. In general, the server will always reply with “200 OK”, and simply close the connection if problems occur. The POST request is never replied to by the server Request Identification QuickTime Streaming uses the 'application/x-rtsp-tunnelled' MIME type in both the Content-Type and Accept headers. This reflects the data type that is expected and delivered by the client and server.

HTTP错误回复- HTTP错误反映服务器不愿或不能形成虚拟全双工连接。他们并不意味着RTSP错误。在一般情况下,服务器将总是用“200 OK”答复,并在发生问题时简单地关闭连接。POST请求永远不会被请求鉴定QuickTime Streaming服务器答复,这类POST请求使用'application/x-rtsp-tunnelled“MIME类型,在两个Content-Type和Accept标头成员里都用了此类型。这反映了预期,由客户端和服务器下发的数据类型。

RTSP Request Encoding RTSP请求编码

The RTSP requests made by the client on the POST channel must be encoded using the base64 method. (See RFC 2045 “Internet Message Bodies”, section 6.8 Base64 Content-Transfer-Encoding; and RFC 1421 “Privacy Enhancement for Electronic Mail,” section 4.3.2.4, Printable Encoding) 在POST通道上的RTSP客户请求必须使用base64编码的方法。RFC 2045(请参阅“互联网消息体”,6.8节内容——Base64传输编码,RFC 1421“隐私增强电子邮件,”部分4.3.2.4打印编码)

The base64 encoding prevents HTTP proxies from mistaking the embodied RTSP requests as malformed HTTP requests. Our testing revealed that some HTTP proxies did in fact fail to pass the raw RTSP data properly. base64编码可以防止HTTP代理把RTSP请求体现为畸形的HTTP请求。我们的测试显示,一些HTTP代理在事实上无法正常通过原始数据RTSP。

Encoding a DESCRIBE 编码请求描述。

Original request:原始请求:

DESCRIBE rtsp:描述rtsp//tuckru.apple.com/sw.mov RTSP/1.0
CSeq: 1
Accept: application/sdp 接受:应用程序/ sdp
Bandwidth: 1500000 带宽:1500000
Accept-Language: en-US 接收语言:en - us
User-Agent: QTS (qtver=4.1;cpu=PPC;os=Mac 8.6) 用户代理:规定性(qtver = 4.1;cpu = PPC;Mac os = 8.6)

Encoded format:编码格式:

REVTQ1JJQkUgcnRzcDovL3R1Y2tydS5hcHBsZS5jb20vc3cubW92IFJUU1AvMS4wDQpDU2VxOiAxDQpBY2NlcHQ6IGFwcGxpY2F0aW9uL3NkcA0KQmFuZHdpZHRoOiAx
NTAwMDAwDQpBY2NlcHQtTGFuZ3VhZ2U6IGVuLVVTDQpVc2VyLUFnZW50OiBRVFMgKHF0dmVyPTQuMTtjcHU9UFBDO29zPU1hYyA4LjYpDQoNCg==

Sample HTTP Requests 样本的HTTP请求

Sample GET transaction.样品GET交易。

Client ‡ Server 客户端‡服务器
GET /sw.mov HTTP/1.0
User-Agent: QTS (qtver=4.1;cpu=PPC;os=Mac 8.6) 用户代理:规定性(qtver = 4.1;cpu = PPC;Mac os = 8.6)
x-sessioncookie: tD9hKgAAfB8ABCftAAAAAw
Accept: application/x-rtsp-tunnelled 接受:应用程序/ x-rtsp-tunnelled
Pragma: no-cache 编译指示:no - cache
Cache-Control: no-cache
Server ‡ Client 服务器‡客户端
HTTP/1.0 200 OK
Server: QTSS/2.0 [v101] MacOSX 服务器:规定性/ 2.0 v101 MacOSX
Connection: close 连接:关闭
Date: Thu, 19 Aug 1982 18:30:00 GMT 日期:1982年8月19日,星期四18:30:00格林尼治时间
Cache-Control: no-store
Pragma: no-cache 编译指示:no - cache
Content-Type: application/x-rtsp-tunnelled 内容类型:应用程序/ x-rtsp-tunnelled
Sample POST request 样本POST请求

Client ‡ Server 客户端‡服务器
POST /sw.mov HTTP/1.0
User-Agent: QTS (qtver=4.1;cpu=PPC;os=Mac 8.6) 用户代理:规定性(qtver = 4.1;cpu = PPC;Mac os = 8.6)
x-sessioncookie: tD9hKgAAfB8ABCftAAAAAw
Content-Type: application/x-rtsp-tunnelled

内容类型:应用程序/ x-rtsp-tunnelled Pragma: no-cache 编译指示:no - cache
Cache-Control: no-cache
Content-Length: 32767 内容长度:32767
Expires: Sun, 9 Jan 1972 00:00:00 GMT
Server ‡ Client 服务器‡客户端

There is no reponse from the server! The client will continue to send RTSP as the message body of this POST request. The chosen Content-Length of 32767 is an arbitrarily large value. All POST requests are required to have a contentlength header by HTTP. In practice the actual value seems to be ignored by proxy servers, so it is possible to send more than this amount of data in the form of RTSP requests. The QuickTime Server ignores the content-length header.

服务器没有响应!客户机将POST作为一个消息体继续发送RTSP请求。所选的内容长度为32767,一个无限大的值。所有POST请求都必须通过HTTP有一个内容长度。在实践中似乎忽视了实际的代理服务器价值,所以它可以发送比RTSP的请求更多数量的数据形式。QuickTime服务器忽略了内容长度。

Connection Maintenance 联系维修

The client may at its’ option close the POST connection at any given time. Doing so frees socket and memory resources at the server that might otherwise be unused for a long time. In QuickTime Streaming the best time for this usually occurs after the PLAY request.

客户端可以在其“选项关闭在任何给定时间内的POST连接。闲置很长一段时间后,服务器可以释放插座和内存资源。这通常在QuickTime播放请求后最佳的时间发生,。

Implementation Best Practices 实现最佳实践

This section covers details that are not required by the protocol, but communicate important information to proxies so that they handle the streams better. 本节讨论协议不需要的细节,但传达给代理的重要信息,以便他们更好地处理流。

Date Header – In QuickTime streaming, the GET reply includes a “Date” headers with a value at an arbitrary point in the past. This keeps proxies from caching the transaction. 日期标题——在QuickTime播放,GET回复包括在过去的任意点的值的“日期”的标题。这可以防止代理缓存事务。

Expires Header – Same as the Date header. Expires标题,—同日期标题。

Pragma “No cache” - Tells many HTTP 1.0 proxies not to cache. 编译“不缓存” - 告诉很多HTTP 1.0代理服务器不缓存。

Cache-Control “no-cache” – Tells HTTP 1.1 proxies not to cache. 告诉HTTP 1.1代理不要缓存。

Unsupported HTTP 不支持HTTP

Support for HTTP features not documented here is not required for RTSP tunneling. HTTP tunnel should mimic a normal TCP connection as closely as possible without adding unnecessary features.

不需要RTSP对此处未记录的HTTP功能的支持。 HTTP应尽可能地模仿正常的TCP连接而不会增加不必要的功能。

友情链接
版权所有 Copyright(c)2004-2021 锐英源软件
公司注册号:410105000449586 豫ICP备08007559号 最佳分辨率 1024*768
地址:郑州大学北校区院(文化路97号院)内