|Log In | Not a Member?||Contact ADC|
Tunnelling RTSP and RTP through HTTP
This dispatch describes the methods used in QuickTime to tunnel RTSP and RTP through HTTP. The addition of RTSP and RTP tunnelled through HTTP allows QuickTime to utilize HTTP (RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0" and RFC 2068 "Hypertext Transfer Protocol -- HTTP/1.1") proxies so viewers behind a firewall can access RTSP streams.
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. This dispatch documents the protocol.
Relationship to RTSP and RTP
Using standard RTSP/RTP it is possible to stream a presentation to a user via a single TCP connection. (See RFC 2326 "Real Time Streaming Protocol (RTSP)", section 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 indirect access to the public Internet via email and HTTP proxies.
The QuickTime tunnelling method exploints the capability of HTTP GET and POST methods to carry large amounts 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. The virtual connection makes it possible to use unmodified RTSP over the connection.
(HTTP GET) |----<<<< data <<<<< ---- client -----| |---- server |-- >>>> data >>>>-------| (HTTP POST)
Version All requests are made using HTTP version 1.0. This is to get through as many firewalls as possible.
Binding the Channels Each client HTTP request must include a x-sessioncookie header with an ID as its value. This makes it possible for the server to unambiguously bind the 2 channels. This protocol uses the value as a simple opaque token. Tokens must be unique to the server, but do not need to be globally unique.
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 use the headers since some proxies will behave incorrectly without the headers.
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 its 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. This insures that both the GET and POST 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.
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.
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.
RTSP Request Encoding
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 188.8.131.52, Printable Encoding.) 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.
The RTSP traffic sent by the server to the client on the GET channel is not encoded using base64.
Encoding a DESCRIBE request
Sample HTTP Requests
Sample GET request
Client to Server:
Server to Client:
Sample POST request
Client to Server:
Server to 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 header value of 32767 is an arbitrarily large value that is accepted by most proxies. (Some proxies do not behave correctly when the value in the header is larger than 32767.) All POST requests are required to have a Content-Length header by HTTP. In practice the actual value seems to be ignored by most 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.
In order to get through some proxies, a POST connection per RTSP request must be made instead of one POST connection per session.
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. The best time for this usually occurs after the PLAY request. When the client needs to communicate to the server again, it opens up another POST connection.
Clients should be prepared to open POST connections as necessary. Servers should be prepared to handle a series of POST connections.
If the GET channel is disconnection, clients should do something reasonable. This might include trying to reconnect the GET connection.
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.
Expires Header Same as the Date header.
Pragma: No cache - Tells many HTTP 1.0 proxies not to cache.
Cache-Control: no-cache Tells HTTP 1.1 proxies not to cache.
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.
RFC 2045 "Multipurpose internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", section 6.8 Base64 Content-Transfer-Encoding
RFC 1421 Privacy Enhancement for Electronic Mail, section 184.108.40.206, Printable Encoding.
07//01 - aj - Added some clarifications.