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.
<!-- rtsp-localized-evidence-foundation-v1:end -->