小编use*_*402的帖子

我正在尝试使用代理通过HTTP获取RTSP流.Real客户端的行为似乎有点忙碌:它会立即尝试所有可能的端口,方法和协议.唯一应该工作的是通过端口80的HTTP GET.确实发出了这样的请求,并在服务器上接收.以下是代理向服务器发送请求时的外观:

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

这是服务器的响应:

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

此时,还有4个字节从服务器到达(它们的值为48 02 02 00) - 就是这样,仅此而已.服务器此时是否期望来自客户端,如果是这样 - 什么？这种操作模式是否有效？

关于这个问题的更多信息:显然,在RealPlayer中内置的使用RTSP over HTTP的预期机制如下:

1. 尝试连接到以下端口:80,8080,554,7070.(尝试直接下载文件,只是为了它,通过在端口80上发出GET http:// hostname:port/mediafilename)
2. 对于上述每个端口,创建2个连接.
3. 向其中一个连接发送GET请求http:// hostname:port/SmpDsBhgRl<guid>？1 ="1",其中<guid>是,是新创建的GUID.在此请求中添加一个名为X-Actual-URL的标头,其中包含原始RTSP URL.
4. 在另一个连接上发送POST请求到URL http:// hostname:port/SmpDsBhgRl,上面的GUID作为请求正文的一部分.发送一个32767字节的Content-Length标头,以防止代理提前关闭连接.
5. 通过POST请求开始向服务器发出命令,并获取相应的RTSP流作为GET响应的一部分. …