rtsp_transport reconnect_delay_max http networking proxy streaming rtsp

http - reconnect_delay_max - rtmp buffer ffmpeg



rtsp en http sobre un proxy (2)

  1. Vea si emitir la misma solicitud pero pasar el proxy (por ejemplo, reproducir la solicitud que publicó anteriormente mediante Netcat) genera más de cuatro bytes transmitidos en el cuerpo de la respuesta.
  2. Vea qué paquetes TCP está recibiendo el proxy, por ejemplo, interceptando el tráfico TCP en la máquina que ejecuta el proxy, por ejemplo, usando Wireshark.

Estoy tratando de buscar una secuencia 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 el proxy la envía al servidor:

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í está 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, llegan 4 bytes más del 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?

Más información sobre este problema: aparentemente, el mecanismo previsto para trabajar con RTSP sobre HTTP integrado en RealPlayer es el siguiente:

  1. Intente conectarse a los siguientes puertos: 80, 8080, 554, 7070. (Intente también descargar el archivo directamente, solo por el simple hecho de hacerlo, emitiendo GET http: // nombrehost: puerto / nombrearchivomedia en el puerto 80)
  2. Para cada uno de los puertos anteriores, crea 2 conexiones.
  3. Envíe 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.
  4. Envíe una solicitud POST en la otra conexión a la URL http: // nombrehost: puerto / 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.
  5. 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.

Lo extraño (si lo anterior no es lo suficientemente extraño) es que, por ejemplo, funciona con Squid, pero no si usas 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 # 2: Aquí está 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 siguiente 02 es la longitud de los siguientes datos, se llama el siguiente 02 POST_NOT_RECEIVED (lo que significa que la solicitud POST no llegó al servidor en un segundo desde la solicitud GET correspondiente).

Actualización n. ° 4: este comportamiento (es decir, solicitudes POST con gran longitud de contenido) también es característico de un ActiveX utilizado por WebEx (y, posiblemente, muchas otras aplicaciones web que necesitan un canal abierto para el servidor).

En primer lugar, es posible que desee leer esto:

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

En segundo lugar, las solicitudes HTTP (tanto GET como POST) deben formatearse para que se aprovisionen correctamente. He visto proxys que insisten en almacenar demasiado de la solicitud POST, evitando que llegue al servidor. Esos proxies tienen errores, pero no hay nada que puedas hacer al respecto, y no pude evitar ese problema. En su mayoría, he visto esto con un software antivirus que intenta hacer un proxy transparente de las solicitudes POST provenientes del navegador para escanearlas en busca de información privada, como números de seguridad social. Es posible que se encuentre con el mismo problema.

¿Estás usando el antivirus de McAfee por casualidad?

Además, parece que Real inventó su propia forma de hacer lo mismo, pero el diseño básico es muy similar: GET para el enlace descendente, POST para el ascendente, con alguna cookie mágica (en este caso, el GUID) para vincular el dos juntos en el servidor. De cualquier manera, el POST debe llegar al servidor, y en su caso parece que no.

Por cierto, dado que el problema parece ser que la solicitud POST no pasa por el proxy, ¿qué hay de publicar esa solicitud, además del GET?