2026-06-02

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

Cómo depurar errores de transporte RTSP que no coinciden cuando la cámara responde con un modo de transporte RTP diferente, canales entrelazados incorrectos, puertos faltantes o respuesta de CONFIGURACIÓN incompatible.

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:

Capture la solicitud SETUP.
Capture la respuesta SETUP.
Comparar protocolo de transporte: UDP, TCP intercalado, multidifusión.
Comparar unidifusión/multidifusión.
Compare puertos de cliente, puertos de servidor y canales entrelazados.
Compruebe si hay un proxy/restreamer en la ruta.
Compruebe si los paquetes RTP posteriores siguen la asignación de respuesta.
Compare un jugador tolerante y un cliente estricto utilizando evidencia de paquetes.
Pruebe la URL directa de la cámara si es posible.
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.

Evidencia reproducible para «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»

La respuesta directa es que una avería de vídeo no se demuestra con una ventana negra ni con un solo código de estado. Un diagnóstico fiable conecta la petición y la respuesta RTSP, el transporte negociado, una sesión válida y después los números de secuencia RTP, las marcas de tiempo y las señales RTCP. Para «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», empieza por la capa más cercana al síntoma visible, pero conserva una cronología común para no mezclar un fallo de control con uno de red o decodificación.

Antes de cambiar la cámara, el firewall o el VMS, crea una prueba base pequeña. Anota la URL RTSP sin contraseña, la hora, la ruta, el transporte solicitado, la respuesta del servidor y el instante del primer paquete multimedia. Prueba UDP y TCP interleaved por separado cuando el equipo ofrezca ambos. No cambies ruta, credenciales y transporte a la vez; si el segundo intento funciona, necesitas saber qué variable produjo la diferencia.

Capa	Evidencia que se debe guardar	Pregunta de decisión
RTSP	método, estado, cabeceras, CSeq y Session	¿El servidor aceptó exactamente la operación?
SDP	control, payload type, clock rate y codec	¿El servidor describió la pista esperada?
Transport	client_port, server_port o interleaved	¿Ambos extremos usan el mismo canal?
RTP	SSRC, secuencia, timestamp y marker	¿Las unidades llegan en un orden explicable?
RTCP	sender report, CNAME y BYE	¿Se pueden relacionar reloj, identidad y final?
Decoder	SPS/PPS/VPS y packetization mode	¿El payload recibido permite iniciar el decoder?

Separa «no llega multimedia» de «llega multimedia que no se puede decodificar». Si no aparece RTP después de SETUP y PLAY correctos, revisa UDP, NAT, firewall y una respuesta Transport distinta de la oferta. RTP con huecos de secuencia prueba pérdida o reordenación. Una secuencia continua sin imagen desplaza la investigación hacia payload type, clock rate, límites de cuadro y parámetros H.264 o H.265. Esta frontera es más útil que el mensaje general del reproductor.

¿Cómo se redacta una respuesta que pueda citarse?

Usa tres frases: última operación correcta, primera evidencia que falla y siguiente prueba que separa dos causas. Ejemplo: «DESCRIBE, SETUP y PLAY terminan correctamente; no llega RTP a los puertos anunciados por el cliente; repetir por TCP interleaved separará el bloqueo UDP de una ruta multimedia incorrecta». No atribuyas el fallo a la cámara o a la red sin una respuesta o un paquete que marque ese límite.

¿Qué hace reproducible el caso?

Guarda OPTIONS, DESCRIBE, SETUP y PLAY, el SDP, la respuesta Transport y el identificador Session saneado. Para RTP registra SSRC, primer y último número de secuencia, clock rate, huecos y duración. Indica si VLC u otro VMS funciona, pero úsalo como comparación controlada, no como prueba de que el cliente exitoso interpreta todas las reglas de forma correcta.

¿Cuándo se investiga el servidor y cuándo el cliente?

Mira el servidor si rechaza un método, entrega un control URL inexistente, responde con un transporte incompatible o cambia SSRC o reloj sin transición. Mira el cliente si reutiliza un nonce caducado, pierde Session, solicita UDP sin abrir los puertos o interpreta cada final NAL como final de access unit. Si el límite está entre ambos, conserva paquete y hora en cada afirmación.

¿Cómo se revisa el informe?

Repite desde una conexión nueva y compara las dos cronologías solo hasta la primera diferencia. Elimina contraseñas y valores Authorization completos. Relaciona cada conclusión con CSeq, secuencia o timestamp. Continúa con la guía RTSP relacionada y usa RTSP Inspector para probar un stream RTSP y recoger evidencia de forma local, sin subir el vídeo de la cámara a un servicio público.

Respuesta directa y límite de aceptación

La respuesta breve a «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» es: Cómo depurar errores de transporte RTSP que no coinciden cuando la cámara responde con un modo de transporte RTP diferente, canales entrelazados incorrectos, puertos faltantes o respuesta de CONFIGURACIÓN incompatible. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en RTSP Inspector.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: Transporte RTSP no coincidente en la respuesta del servidor: depuración de respuestas de C

Compruebe «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» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 2: Cómo depurar errores de transporte RTSP que no coinciden cuando la cámara responde con un

Si «Cómo depurar errores de transporte RTSP que no coinciden cuando la cámara responde con un modo de transporte RTP diferente, canales entrelazados incor» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 3: Cómo se ve un intercambio SETUP coincidente

Compruebe «Cómo se ve un intercambio SETUP coincidente» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 4: Casos comunes de discrepancia

Si «Casos comunes de discrepancia» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 5: Por qué un jugador funciona y otro falla

Compruebe «Por qué un jugador funciona y otro falla» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 6: Reescritura de proxy y retransmisión

Si «Reescritura de proxy y retransmisión» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 7: Lista de verificación de depuración

Compruebe «Lista de verificación de depuración» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 8: Diagnóstico final

Si «Diagnóstico final» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 9: Evidencia reproducible para «Transporte RTSP no coincidente en la respuesta del servidor:

Compruebe «Evidencia reproducible para «Transporte RTSP no coincidente en la respuesta del servidor: depuración de respuestas de CONFIGURACIÓN de la cámara y dis» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 10: ¿Cómo se redacta una respuesta que pueda citarse?

Si «¿Cómo se redacta una respuesta que pueda citarse?» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Transporte RTSP no coincidente en la respuesta del servidor: depuración de respuestas de CONFIGURACIÓN de la cámara y di	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo depurar errores de transporte RTSP que no coinciden cuando la cámara responde con un modo de transporte RTP diferen	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo se ve un intercambio SETUP coincidente	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Casos comunes de discrepancia	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Por qué un jugador funciona y otro falla	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Reescritura de proxy y retransmisión	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: