Estoy tratando de obtener una secuencia de RTSP a través de HTTP utilizando un proxy. El comportamiento del cliente Real parece ser un poco agitado: prueba todos los puertos, métodos y protocolos posibles a la vez. Lo único que debería funcionar es HTTP GET sobre el puerto 80. Dicha solicitud se emite y se recibe en el servidor. Así es como se ve la solicitud cuando es enviado por el proxy al servidor:rtsp en http sobre un proxy
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
aquí es la respuesta del servidor:
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
En este punto 4 bytes más llegan desde el servidor (sus valores son 48 02 02 00) - y eso es todo, nada más. ¿Espera el servidor algo del cliente en este momento y, de ser así, qué? ¿Funciona este modo de operación?
Algunos más información sobre este problema: al parecer, el mecanismo previsto de trabajar con RTSP a través de HTTP integrado en RealPlayer es el siguiente:
- intenta conectarse a los siguientes puertos: 80, 8080, 554, 7070 . (Pruebe también para descargar el archivo directamente, sólo por el gusto de hacerlo, mediante la emisión de GET http://hostname:port/mediafilename en el puerto 80)
- para cada uno de los puertos anteriores, crear 2 conexiones.
- Enviar una solicitud GET a una de las conexiones a la url http://hostname:port/SmpDsBhgRl
<guid>? 1 = "1", donde<guid>es, sí, un GUID recién creado. Agregue un encabezado a esta solicitud llamado X-Actual-URL que contiene la URL RTSP original. - Envíe una solicitud POST en la otra conexión a la URL http://hostname:port/SmpDsBhgRl con el GUID anterior como parte del cuerpo de la solicitud. Envíe un encabezado Content-Length de 32767 bytes para evitar que el proxy cierre la conexión prematuramente.
- Comience a emitir comandos al servidor a través de la solicitud POST, y obtenga la secuencia RTSP correspondiente como parte de la respuesta GET.
La materia extraña (si lo anterior no es lo suficientemente extraño) es que, por ejemplo, funciona con el calamar, pero no si se utiliza cualquiera de los puertos 3128 o 8080! De alguna manera, el cliente usa el puerto al que se conecta para decidir el orden de las solicitudes o cuando se debe cancelar una solicitud, pero de todos modos, por difícil de creer que sea, funciona con el puerto proxy 9090, 3129, 8081, pero no con 3128 o 8080.
Actualización n. ° 2: Here es la fuente del RealPlayer con la explicación del comportamiento anterior. Sin embargo, todavía no hay solución.
Actualización # 3: OK, a la luz de lo anterior, el valor mágico de 48 02 02 00 es claro: 48 == 'h' es para HTTP_RESPONSE, el próximo 02 es la longitud de los siguientes datos, el el próximo 02 se llama POST_NOT_RECEIVED (lo que significa que la solicitud POST no llegó al servidor en un segundo desde la solicitud GET correspondiente).
Actualización # 4: Este comportamiento (es decir, las solicitudes POST con gran contenido de longitud) también es característico de un ActiveX utilizado por WebEx (y, posiblemente, muchas otras aplicaciones web que necesitan un canal abierto en el servidor).
¿Es válida la respuesta OK 200 del servidor? Mi servidor solía responder como el suyo, pero RealPlayer dejó de responder después de abrir las conexiones GET y POST. Luego agregué al cuerpo de la respuesta 48 02 00 00 y Content-Length: 4 y funcionó ... Tal vez necesite modificar su respuesta HTTP OK y enviarla después de recibir la conexión POST, no antes de eso. – Cipi