A TCP 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 makes it possible to send unmodified RTSP and RTP data over the connection.
Tunneling RTSP and RTP Over HTTP, the HTTP server pass the client socket fd to the RTSP server through UNIX domain socket. Then the RTSP server takes over the management of replying RTP/RTCP packets.
A quite simple diagram for the overall process :
