2026-06-18

Solución de problemas de transmisiones RTSP: la guía de diagnóstico completa para transmisiones de cámaras

Flujo de trabajo de diagnóstico RTSP completo: capa de conexión, errores del plano de control (400/401/404/454/461/500/503), fallas del plano de medios (H.264/H.265/RTP/RTCP), administración de sesiones y comparación con Wireshark/VLC. Cada problema RTSP asignado a una página de diagnóstico.

Esta es la página central para el diagnóstico de transmisiones de cámaras RTSP. Cada problema RTSP sigue un patrón: "falla en la capa de conexión, el plano de control o el plano de medios. Esta guía asigna cada falla común a una página de diagnóstico específica y le indica qué evidencia recopilar."

Triaje rápido: "¿dónde está el fracaso?"

Antes de leer cualquier página específica, determine qué capa está fallando: ""

¿Puede el cliente llegar a la cámara? → Problemas en la capa de conexión
¿DESCRIBE devuelve un SDP válido? → Problemas en el plano de control
¿Los paquetes RTP llegan y se decodifican correctamente? → Problemas en el plano de medios

Si no sabe qué capa está fallando, comience con el flujo de trabajo de diagnóstico sistemático.

Connection layer: reaching the camera

These problems happen before any RTSP command is sent. TCP handshake fails, TLS negotiation fails, or the network path is blocked.

RTSP connects but no video — The most common symptom. Camera appears online but no media stream.
RTSP over TLS (RTSPS) debugging — TLS certificate errors, handshake failures, cipher suite negotiation.

Plano de control: errores de comando RTSP

Estos son errores a nivel de protocolo que devuelve la cámara en respuesta a DESCRIBIR, CONFIGURAR o REPRODUCIR. El código de error le indica exactamente qué salió mal.

400 Solicitud incorrecta

Solicitud incorrecta de RTSP 400: DESCRIBE falló: URL con formato incorrecto, encabezados no admitidos, interferencia de proxy. Cubre los formatos de URL de Axis, Dahua y Hikvision.

401 No autorizado

Bucle de autenticación RTSP 401 — Digest vs autenticación básica, parámetros nonce/realm, por qué la autenticación tiene éxito en VLC pero falla en su aplicación.
Análisis profundo de autenticación de resumen RTSP — Caducidad nonce, coincidencia de dominio, manejo obsoleto=verdadero.
Diagnóstico de URL de cámara 401/404: cuando la URL funciona en un cliente pero no en otro.

404 no encontrado

Diagnóstico de URL de cámara 401/404 — Ruta de transmisión incorrecta, formatos de URL específicos de la cámara.
URL de control agregado y CONFIGURACIÓN DE SDP 404: cuando la URL de control en SDP no coincide con la URL DESCRIBE.

454 Sesión no encontrada

Sesión RTSP 454 no encontrada — El ID de la sesión no coincide, sesiones caducadas, REPRODUCCIÓN antes de la CONFIGURACIÓN.

461 Transporte no compatible

Transporte no admitido RTSP 461: Error en la CONFIGURACIÓN — Negociación de transporte UDP vs TCP, ffmpeg "error en la CONFIGURACIÓN del método: 461", errores de integración de Fragata/Scrypted/NVR.

Errores del servidor 500/503

Error del servidor interno RTSP 500 — Fallo en el lado de la cámara. Cuándo concluir que el firmware de la cámara tiene la culpa.
Servicio RTSP 503 no disponible — Agotamiento de los recursos de la cámara, demasiadas transmisiones simultáneas, límites de ancho de banda.

Transporte y networking

UDP RTP bloqueado por firewall/NAT — El control RTSP funciona pero el medio UDP RTP está bloqueado. Reglas de firewall, cruce de NAT, configuración de puerto de protocolo RTSP, respaldo entrelazado de TCP.
No coinciden los canales entrelazados TCP: cuando los canales RTP/RTCP entrelazados no coinciden entre el cliente y el servidor.
Respuesta del servidor de transporte no coincidente: el servidor responde con parámetros de transporte diferentes a los solicitados.
Depuración de multidifusión UDP — Configuración de multidifusión RTSP/RTP, IGMP, TTL e infraestructura de red.
Tiempo de espera de RTSP: UDP vs TCP intercalado — Por qué el tiempo de espera del flujo de transmisión es diferente en UDP que en TCP.

Media plane: RTP, codec, and payload problems

Control plane works perfectly — DESCRIBE returns SDP, SETUP succeeds, PLAY returns 200 OK — but video is broken. These are media plane problems.

RTP packet analysis

RTP dynamic payload type mismatch — "Unknown write" RTP/NDPI errors. How to map dynamic payload IDs to SDP rtpmap lines.
RTP packet loss diagnosis — RTP error in primary stream. Freezes, macroblocks, decoder errors. Read sequence numbers and RTCP reports to find the loss.
RTP timestamp drift — Audio/video sync loss, frame timing errors, clock rate mismatch.
RTP marker bit and frame boundaries — How the RTP marker bit signals H.264 access unit boundaries.
RTP sequence number wraparound — 16-bit sequence number rollover and how to detect actual loss vs wraparound.
RTP SSRC change mid-stream — When the camera changes SSRC mid-stream and the client loses sync.

H.264 and H.265 codec issues

H.264 FU-A fragmentation and reassembly — Missing fragments, start/end bit bugs, NAL unit reassembly failures, "invalid NAL unit" errors.
H.264 packetization mode 0 vs 1 — Single NAL vs non-interleaved mode. SDP parameter configuration.
H.264 SPS/PPS missing — Decoder errors when parameter sets are missing from SDP or RTP stream.
H.265 stream not working — H.265/HEVC failures and H.264 fallback behavior.
SDP H.264/H.265 diagnostics — Reading SDP for H.264/H.265: profile-level-id, sprop-parameter-sets, packetization-mode.

Audio and metadata tracks

Audio track AAC unknown track SDP — AAC audio tracks appearing as "unknown" in clients.

ONVIF and camera-specific

ONVIF works but RTSP URL fails — ONVIF discovery succeeds but direct RTSP connection fails.
Main stream vs sub stream — When the main stream works but the sub stream doesn't, or vice versa.

RTCP y gestión de sesiones

Informes del remitente RTCP: fluctuación y pérdida — Lectura de paquetes RTCP SR para comprender la calidad de la red desde la perspectiva de la cámara.
RTCP BYE: la transmisión finaliza inesperadamente — Cuando la cámara envía RTCP BYE y finaliza la transmisión.
RTCP CNAME y sincronización de audio/video — Uso de RTCP CNAME para sincronizar pistas de audio y video.
RTSP TEARDOWN y limpieza de sesión: fugas de recursos de la cámara, fallas de reconexión, estado de transmisión ocupada.
Tiempo de espera de sesión RTSP y keepalive — Por qué las transmisiones se detienen después de ~30 segundos y cómo mantenerlas vivas.
Encabezado de rango RTSP y NPT — Controlar la posición de reproducción con los parámetros Rango y NPT.
Encabezado de escala RTSP y reproducción con truco — Avance rápido, rebobinado y control de velocidad a través del encabezado de escala.

Comparison and alternatives

RTSP Inspector vs Wireshark/VLC/ONVIF Device Manager — When to use a dedicated RTSP diagnostic tool vs a general network analyzer.
Wireshark RTSP alternative — Why RTSP diagnostics need more than packet capture.

Empezando

¿Nuevo en el diagnóstico RTSP? Comience aquí:

Flujo de trabajo de diagnóstico sistemático — El modelo de tres capas y la recopilación de evidencia.
Conectarse a una transmisión — Configurando su primera conexión RTSP.
Guía de solución de problemas: fallas comunes y sus soluciones.

Evidencia reproducible para «Solución de problemas de transmisiones RTSP: la guía de diagnóstico completa para transmisiones de cámaras»

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 «Solución de problemas de transmisiones RTSP: la guía de diagnóstico completa para transmisiones de cámaras», 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 «Solución de problemas de transmisiones RTSP: la guía de diagnóstico completa para transmisiones de cámaras» es: Flujo de trabajo de diagnóstico RTSP completo: capa de conexión, errores del plano de control (400/401/404/454/461/500/503), fallas del plano de medios (H.264/H.265/RTP/RTCP), administración de sesiones y comparación con Wireshark/VLC. Cada problema RTSP asignado a una página de diagnóstico. 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: Solución de problemas de transmisiones RTSP: la guía de diagnóstico completa para transmis

Compruebe «Solución de problemas de transmisiones RTSP: la guía de diagnóstico completa para transmisiones de cámaras» 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: Flujo de trabajo de diagnóstico RTSP completo: capa de conexión, errores del plano de cont

Si «Flujo de trabajo de diagnóstico RTSP completo: capa de conexión, errores del plano de control (400/401/404/454/461/500/503), fallas del plano de medio» 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: Triaje rápido: "¿dónde está el fracaso?"

Compruebe «Triaje rápido: "¿dónde está el fracaso?"» 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: Connection layer: reaching the camera

Si «Connection layer: reaching the camera» 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: Plano de control: errores de comando RTSP

Compruebe «Plano de control: errores de comando RTSP» 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: 400 Solicitud incorrecta

Si «400 Solicitud incorrecta» 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: 401 No autorizado

Compruebe «401 No autorizado» 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: 404 no encontrado

Si «404 no encontrado» 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: 454 Sesión no encontrada

Compruebe «454 Sesión no encontrada» 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: 461 Transporte no compatible

Si «461 Transporte no compatible» 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
Solución de problemas de transmisiones RTSP: la guía de diagnóstico completa para transmisiones de cámaras	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Flujo de trabajo de diagnóstico RTSP completo: capa de conexión, errores del plano de control (400/401/404/454/461/500/5	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Triaje rápido: "¿dónde está el fracaso?"	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Connection layer: reaching the camera	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Plano de control: errores de comando RTSP	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
400 Solicitud incorrecta	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: