Advanced Search

Log In | Not a Member?

Contact ADC

< Previous PageNext Page > Hide TOC

Tunneling RTSP and RTP Over HTTP

Using standard RTSP/RTP, a single TCP connection can be used to stream a QuickTime presentation to a user. Such a connection is not sufficient to reach users on private IP networks behind firewalls where HTTP proxy servers provide clients with indirect access to the Internet. To reach such clients, QuickTime 4.1 supports the placement of RTSP and RTP data in HTTP requests and replies. As a result, viewers behind firewalls can access QuickTime presentations through HTTP proxy servers.

The QuickTime HTTP transport is built from two separate HTTP GET and POST method requests initiated by the client. The server then binds the connections to form a virtual full-duplex connection. The protocol that forms this type of connection is must meet the following requirements:

• Work with unmodified RTSP/RTP packets

• Be acceptable to HTTP proxy servers

• Indicate to proxy servers that requests and replies are not to be cached

• Work in an environment where the client originates all requests

• Provide a way to uniquely identify request pairs so that they can be bound together to form a full-duplex connection

• Ensure that related requests connect to the same RTSP server in spite of load-balancing algorithms such as round-robin DNS servers

• Identify any request as one that will eventually tunnel an RTSP conversation and RTP data

The QuickTime HTTP transport exploits the capability of HTTP’s 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 an HTTP GET request to the server to open the server-to-client connection. Then the client makes a HTTP POST request to the server to open the client-to-server connection. The resulting virtual full-duplex connection (shown in Figure 2-14) makes it possible to send unmodified RTSP and RTP data over the connection.

Figure 1-14  Required connections for tunneling

In this section:

HTTP Client Request Requirements
HTTP Server Reply Requirements
RTSP Request Encoding
Connection Maintenance
Support For Other HTTP Features

HTTP Client Request Requirements

To work with the QuickTime HTTP transport, client HTTP requests must

• Be made using HTTP version 1.0

• Include in the header an x-sessioncookie directive whose value is a globally unique identifier (GUID). The GUID makes it possible for the server to unambiguously bind the two connections by passing it as an opaque token to the C library strcmp function

• In POST requests, the application/x-rtsp-tunneled MIME type for both the Content-Type and Accept directives must be specified; this MIME type reflects the data type that is expected and delivered by the client and server

• Direct POST requests to the specified IP address if a server’s reply to an initial GET request includes the x-server-ip-address directive and an IP address

In addition to these requirements, client HTTP POST request headers may include other directives in order to help HTTP proxy servers handle RTSP streams optimally.

Sample Client GET Request

Here is an example of a client GET request:

GET /sw.mov HTTP/1.0

User-Agent: QTS (qtver=4.1;cpu=PPC;os=Mac8.6)

x-sessioncookie: tD9hKgAAfB8ABCftAAAAAw

Sample Client POST Request

Here is an example of a client POST request:

POST /sw.mov HTTP/1.0

User-Agent: QTS (qtver=4.1;cpu=PPC;os=Mac8.6)

Content-Type: application/x-rtsp-tunnelled

Pragma: no-cache

Cache-Control: no-cache

Content-Length: 32767

Expires: Sun, 9 Jan 1972 00:00:00 GMT

The sample client POST request includes three optional header directives that are present to control the behavior of HTTP proxy servers so that they handle RTSP streams optimally:

• The Pragma: no-cache directive tells many HTTP 1.0 proxy servers not to cache the transaction.

• The Cache-Control: no-cache directive tells many HTTP 1.1 proxy servers not to cache the transaction.

• The Expires directive specifies an arbitrary time in the past. This directive is intended to prevent proxy servers from caching the transaction.

HTTP requires that all POST requests have a content-length header. In the sample client POST request, the content length of 32767 is an arbitrary value. 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.

HTTP Server Reply Requirements

When the server receives an HTTP GET request from a client, it must respond with a reply whose header specifies the application/x-rtsp-tunneled MIME type for both the Content-Type and Accept directives.

Server reply headers may optionally include the Cache-Control: no-store and Pragma: no-cache directives to prevent HTTP proxy servers from caching the transaction. It is recommended that implementations honor these headers if they are present.

Server clusters are often allocated connections by a round-robin DNS or other load-balancing algorithm. To insure that client requests are directed to the same server among potentially several servers in a server farm, the server may optionally include the x-server-ip-address directive followed by an IP address in dotted decimal format in the header of its reply to a client’s initial GET request. When this directive is present, the client must direct its POST request to the specified IP address regardless of the IP address returned by a DNS lookup.

In the absence of an HTTP error, the server reply header contains “200 OK”. An HTTP error in a server reply reflects the inability of the server to form the virtual full-duplex connection; an HTTP error does not imply an RTSP error. When an HTTP error occurs, the server simply closes the connection.

Sample Server Reply to a GET Request

Here is an example of a server reply to a GET request:

HTTP/1.0 200 OK

Server: QTSS/2.0 [v101] MacOSX

Connection: close

Date: Thu, 19 Aug 1982 18:30:00 GMT

Cache-Control: no-store

Pragma: no-cache

Content-Type: application/x-rtsp-tunnelled

Including the following header directives in a reply is not required but is recommended because the directives they tell proxy servers to behave in a way that allows them to handle RTSP streams optimally:

• The Date directive specifies an arbitrary time in the past. This keeps proxy servers from caching the transaction.

• The Cache-Control: no-cache directive tells many HTTP 1.1 proxy servers not to cache the transaction.

• The Pragma: no-cache directive tells many HTTP 1.0 proxy servers not to cache the transaction.

RTSP Request Encoding

RTSP requests made by the client on the POST connection must be encoded using the base64 method. (See RFC 2045 “Internet Message Bodies”, section 6.8, Base64 Content-Transfer-Encoding, and RFC 1421 “Privacy Enhancements for Electronic Mail,” section 4.3.2.4, Printable Encoding.) The base64 encoding prevents HTTP proxy server from determining that an embodied RTSP request is a malformed HTTP requests.

Here is a sample RTSP request before it is encoded:

DESCRIBE rtsp://tuckru.apple.com/sw.movRTSP/1.0

CSeq: 1

Accept: application/sdp

Bandwidth: 1500000

Accept-Language: en-US

User-Agent: QTS (qtver=4.1;cpu=PPC;os=Mac8.6)

Here is the same request after encoding:

REVTQ1JJQkUgcnRzcDovL3R1Y2tydS5hcHBsZS5jb20vc3cubW92IFJUU1AvMS4w

DQpDU2VxOiAxDQpBY2N1cHQ6IGFwcGxpY2F0aW9uL3NkcA0KQmFuZHdpZHRo0iAx

NTAwMDAwDQpBY2N1cHQtTGFuZ3VhZ2U6IGVuLVVTDQpVc2VyLUFnZW50OiBRVFMg

KHF0dmVyPTQuMTtjcHU9UFBDO29zPU1hYyA4LjYpDQoNCg==

Connection Maintenance

The client may close the POST connection at any time. Doing so frees socket and memory resources at the server that might otherwise be unused for a long time. In QuickTime HTTP streaming, the best time to close the POST connection usually occurs after the PLAY request.

Support For Other HTTP Features

Support for HTTP features that are not documented here is not required in order to implement the tunneling of QuickTime RTSP and RTP over HTTP. The tunnel should mimic a normal TCP connection as closely as possible without adding unnecessary features.

< Previous PageNext Page > Hide TOC

Did this document help you? Yes: Tell us what works for you. It’s good, but: Report typos, inaccuracies, and so forth. It wasn’t helpful: Tell us what would have helped.

	Get information on Apple products. Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice