Analysis: The uber-protocol that the Real client and server use to communicate between themselves is a marvel of engineering, on par with the Pizza tower and Lenin's mausoleum. It works as follows:
1. The client tries to connect to the following ports: 80, 8080, 7070, 554.
For each port it works with, it tries to work in something called "single post"
2. It connects to the server (via proxy) on connection #1 and issues a GET
request for the media (containing a unique string called GUID)
3. It connects to the server (via proxy) on connection #2 and issues a POST
request of specific type (containing the same GUID as the GET request above).
The Content-Length of this request is 32767 (this way they hope to be able to
send lots of data over it without the proxy closing the connection).
4. If the server sees a POST request within one second from a GET request with
the same GUID, it starts to send the media over connection #1, while using
connection #2 as a control channel (receiving commands from the client there).
5. Otherwise, the GET response contains a code that tells the client that the
server did not receive a POST request within the specified time.
6. Theoretically, after #5 occurs, the client is supposed to switch to something
called "multi-post" mode, in which a separate POST request with a correct
Content-Length is issued for every command that a client wishes to send to the
server, but in practice I was unable to make the client switch into this mode. In fact, I've noticed the following disturbing fact: if the proxy port is one of the two (3128, 8080), then no multi-post mode is used. If, on the other hand, the port is any other port, it is used (even though it fails immediately).
Solution: Either make your proxy allow partial POST requests through, or just give up on tunneling RTSP.
P.S. Apparently, the same thing (POST requests with unimaginable Content-Length) is characteristic to the ActiveX by WebEx TM.