Transporte RTSP no coincidente en la respuesta del servidor: depuración de respuestas de CONFIGURACIÓN de la cámara y discrepancia del modo RTP

Algunas fallas de RTSP no devuelven un 461 Unsupported Transport limpio. En su lugar, el cliente informa "transporte no coincidente en la respuesta del servidor", "encabezado de transporte no válido", "el servidor respondió con un transporte diferente" o "no coincide el transporte RTP". Esto sucede a menudo cuando una cámara acepta "CONFIGURACIÓN" pero responde con un encabezado "Transporte" que no coincide con lo que el cliente solicitó o con lo que el cliente puede analizar.

Los usuarios buscan "transporte RTSP no coincidente en la respuesta del servidor", "transporte no coincidente ffmpeg", "no coincide el transporte RTSP SETUP" y "encabezado de transporte de cámara no válido" porque la transmisión puede funcionar en un reproductor y fallar en otro. La cámara no es simplemente inalcanzable. La negociación de transporte RTSP es inconsistente.

RTSP Inspector es útil porque los encabezados de solicitud y respuesta deben compararse directamente.

Cómo se ve un intercambio SETUP coincidente

El cliente solicita TCP entrelazado:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1

Server replies with compatible TCP interleaved transport:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=12345678

El cliente solicita UDP:

Transport: RTP/AVP;unicast;client_port=50000-50001

Server replies with UDP ports:

Transport: RTP/AVP;unicast;client_port=50000-50001;server_port=6970-6971

Si el servidor cambia el modo de transporte, omite campos obligatorios o devuelve valores con formato incorrecto, los clientes estrictos pueden fallar.

Casos comunes de discrepancia

Los ejemplos comunes incluyen:

• El cliente solicita TCP, el servidor responde UDP.
• El cliente solicita UDP, el servidor responde TCP.
• El servidor omite interleaved=.
• El servidor devuelve números de canal incorrectos.
• El servidor devuelve valores de client_port diferentes a los de la solicitud.
• El servidor omite server_port para UDP.
• El servidor devuelve multidifusión cuando el cliente solicita unidifusión.
• El servidor devuelve múltiples alternativas de transporte en un formato no compatible.
• El proxy reescribe la solicitud pero no la respuesta.

Algunos clientes toleran estas peculiaridades. Otros los rechazan.

Por qué un jugador funciona y otro falla

Las implementaciones de RTSP varían. Un jugador tolerante puede aceptar una respuesta de transporte incorrecta o inesperada y continuar. Una herramienta más estricta puede fallar porque la respuesta viola sus expectativas.

Eso no significa automáticamente que el cliente estricto esté equivocado. Significa que se debe inspeccionar el comportamiento de la cámara o del proxy.

Para diagnóstico profesional, conserve:

• El encabezado de transporte solicitado.
• La respuesta de transporte del servidor.
• URL de seguimiento.
• ID de sesión.
• Si los paquetes RTP llegan después.

Reescritura de proxy y retransmisión

Los relés compatibles con RTSP pueden reescribir los encabezados de transporte para unir las rutas UDP y TCP. Si la reescritura está incompleta, el cliente intermedio ve una respuesta que no coincide con su solicitud.

Ejemplos:

• El cliente solicita TCP del relé.
• La retransmisión solicita UDP desde la cámara.
• El relé reenvía accidentalmente la respuesta de transporte UDP de la cámara en sentido descendente.

El cliente informa que el transporte no coincide a pesar de que la cámara y el relé hicieron algo parcialmente válido.

Lista de verificación de depuración

Utilice este proceso:

1. Capture la solicitud SETUP.
2. Capture la respuesta SETUP.
3. Comparar protocolo de transporte: UDP, TCP intercalado, multidifusión.
4. Comparar unidifusión/multidifusión.
5. Compare puertos de cliente, puertos de servidor y canales entrelazados.
6. Compruebe si hay un proxy/restreamer en la ruta.
7. Compruebe si los paquetes RTP posteriores siguen la asignación de respuesta.
8. Compare un jugador tolerante y un cliente estricto utilizando evidencia de paquetes.
9. Pruebe la URL directa de la cámara si es posible.
10. Informe el par de transporte exacto al proveedor.

Diagnóstico final

"Transporte no coincidente en la respuesta del servidor" significa que la negociación SETUP produjo una respuesta de transporte incompatible o con formato incorrecto. La cámara o el relé pueden estar cambiando el modo RTP, omitiendo campos o devolviendo valores que el cliente no puede usar de forma segura.

RTSP Inspector ayuda a hacer visible el par de solicitud/respuesta de transporte, que es la única forma confiable de diagnosticar esta clase de falla RTSP.