Rtsp over http through proxy

Question

I am trying to get an RTSP stream through HTTP using a proxy. The behavior of a real client seems a bit hectic: he is simultaneously trying to use all possible ports, methods and protocols. The only thing that should work is HTTP GET over port 80. Such a request is actually issued and received on the server. Here is what the request looks like when it is sent by the proxy server:

GET /SmpDsBhgRl83c52ef2-d0f4-41ac-bada-93e5350f67d1?1="1" HTTP/1.0\r\n Connection: Keep-Alive\r\n Host: 10.194.5.162:80\r\n Pragma: no-cache\r\n User-Agent: RealPlayer G2\r\n Expires: Mon, 18 May 1974 00:00:00 GMT\r\n Accept: application/x-rtsp-tunnelled, */*\r\n ClientID: WinNT_5.1_6.0.14.806_RealPlayer_R41UKD_en-GB_686\r\n X-Actual-URL: rtsp://10.194.5.162:554/01.mp3\r\n \r\n 

Here is the server response:

 HTTP/1.0 200 OK\r\n Server: RMServer 1.0\r\n Expires: Mon, 18 May 1974 00:00:00 GMT\r\n Pragma: no-cache\r\n x-server-ipaddress: 10.194.5.162\r\n Content-type: audio/x-pn-realaudio\r\n \r\n 

At this moment, 4 more bytes come to the server (their values ​​are 48 02 02 00) - and this is no more. Does the server expect a client at the moment, and if so, what? Does this mode of operation work at all?

Additional information about this problem: apparently, the alleged mechanism for working with RTSP via HTTP, built into RealPlayer, is as follows:

• Try connecting to the following ports: 80, 8080, 554, 7070. (Try also to download the file directly, just for this by issuing GET http: // hostname: port / mediafilename on port 80).
• For each of these ports, create 2 connections.
• Send a GET request to one of the connections with the address http: // hostname: port / SmpDsBhgRl <guid> ? 1 = "1", where <guid> , yes, the just created GUID. Add a header to this query with the name X-Actual-URL containing the RTSP source URL.
• Send a POST request to another connection, in the URL http: // hostname: port / SmpDsBhgRl with the specified GUID as part of the request body. Send a Content-Length header of 32767 bytes to prevent the connection from closing prematurely.
• Start issuing commands to the server through a POST request and receive the corresponding RTSP stream as part of the GET response.

The weird stuff (if the above is not weird enough) is that, for example, it works with Squid, but not if you use any of the ports 3128 or 8080! One way or another, the client uses the port to which it connects to decide on the order of requests or when the request should be canceled, but in any case, as it is hard to believe, it works with the proxy port 9090, 3129, 8081, but not from 3128 or 8080.

Update # 2: Here is the source of RealPlayer explaining the behavior described above. However, there is no solution.

Update No. 3: OK, in the light of the above, the magic value 48 02 02 00 is clear: 48 == 'h' for HTTP_RESPONSE , the next 02 is the length of the following data, the next 02 is called POST_NOT_RECEIVED (this means that the POST request did not reach the server within a second from the corresponding GET request).

Update # 4: This behavior (that is, POST requests with huge content) is also typical of the ActiveX used by WebEx (and possibly many other web applications that need an open channel for the server).

Answer 1

You can read this first:

http://developer.apple.com/quicktime/icefloe/dispatch028.html

Secondly, HTTP requests (both GET and POST) must be formatted so that they are correctly proxied. I have seen proxies that insist on caching too much POST request, preventing it from reaching the server. These proxies are wrong, but there is nothing you can do about it, and I could not get around this problem. Basically, I saw this with antivirus software that tries to transparently proxy POST requests coming from the browser in order to scan them for personal information, such as social security numbers. You may be facing the same problem.

Do you accidentally use McAfee antivirus?

In addition, it looks like Real came up with its own way to do the same, but the basic design is very similar - GET for downlink, POST for upstream, with some magic cookie (in this case GUID) to link them together on the server. In any case, POST should go to the server, and in your case it seems that this is not so.

By the way, since the problem is that the POST request does not go through the proxy, how about sending this request in addition to GET?

Answer 2

• See if the same request can be issued, but bypassing the proxy (for example, repeating the request that you posted above using Netcat) results in more than four bytes being transferred to the response body.
• See what TCP packets the proxy server receives, for example, by listening to TCP traffic on a machine running the proxy server, say, using Wireshark.