2026-06-02

Error interno del servidor RTSP 500: ruta de transmisión de la cámara, recurso del codificador, firmware y diagnóstico de sesión

Cómo solucionar el error interno del servidor RTSP 500 de cámaras IP y NVR, incluidas rutas de transmisión incorrectas, límites de recursos del codificador, errores de firmware, conexiones máximas y sesiones fallidas.

RTSP/1.0 500 Internal Server Error es una de las respuestas RTSP menos útiles porque le indica que la cámara o el NVR falló internamente, pero no dice por qué. Los usuarios buscan "Error interno del servidor RTSP 500", "Error del servidor interno RTSP de la cámara", "ffmpeg RTSP 500", "NVR RTSP 500" y "Error de flujo 500 de la cámara IP" cuando se puede acceder al servicio RTSP pero no se puede crear el flujo.

A diferencia de "401 no autorizado", "404 no encontrado", "454 sesión no encontrada" o "461 transporte no compatible", "500" a menudo apunta a una ruta de falla del lado del servidor: recurso de transmisión incorrecto, codificador no listo, demasiadas sesiones, error de firmware, estado de perfil no válido, canal NVR fuera de línea o un límite interno de búfer/recursos.

RTSP Inspector es útil porque el método RTSP exacto y el tiempo son importantes. 500 en DESCRIBE significa algo diferente de 500 en SETUP o PLAY.

Qué significa RTSP 500

500 Error interno del servidor significa que el servidor RTSP aceptó la solicitud lo suficiente como para procesarla, pero sufrió una falla interna. El servidor puede ser la propia cámara, un NVR, una puerta de enlace de medios o un servicio de retransmisión.

Ejemplos:

DESCRIBE rtsp://camera/stream RTSP/1.0
RTSP/1.0 500 Internal Server Error

or:

SETUP rtsp://camera/stream/trackID=1 RTSP/1.0
RTSP/1.0 500 Internal Server Error

El primero sugiere que el servidor no pudo describir ni crear el recurso de transmisión. El segundo sugiere que existía SDP pero que la configuración del transporte de medios falló internamente.

Ruta de transmisión incorrecta o incompleta

Algunas cámaras devuelven "404" por un mal camino. Otros devuelven "500" porque su servicio RTSP intenta resolver la ruta de la transmisión internamente y falla. Esto es común con las URL RTSP específicas del proveedor.

Verifique patrones de ruta como:

/stream1
/live
/h264
/cam/realmonitor?channel=1&subtype=0
/Streaming/Channels/101
/profile1/media.smp

If the URL has a channel number, profile name, or query parameter, verify it against the exact camera model. A path from a similar model may not work.

Encoder not ready or resource exhausted

IP cameras have limited encoding resources. A camera may fail internally when asked to create a stream profile it cannot currently provide.

Causes include:

Too many clients already connected.
Main stream already used by another profile.
H.265/H.264 encoder resource conflict.
Resolution/frame rate/bitrate combination too heavy.
NVR channel offline.
Camera is rebooting encoder after settings change.
Audio/video profile references disabled components.
Internal buffer space exhausted.

If rebooting the camera temporarily fixes 500, resource exhaustion or firmware state becomes more likely.

500 after authentication

Sometimes authentication succeeds and 500 appears only after the authenticated retry. That means credentials are probably not the main issue. The camera accepted the user enough to reach stream creation but failed internally.

Still check permissions:

User allowed to access live video?
User allowed to access that channel?
Main stream vs sub-stream permission?
NVR user allowed to view target channel?

Some NVRs return generic server errors instead of clean authorization errors.

Method-specific diagnosis

Use the failed method as a guide:

OPTIONS 500: RTSP service itself is unhealthy.
DESCRIBE 500: stream path, profile, encoder, or channel state.
SETUP 500: track control URL, transport setup, RTP resource allocation.
PLAY 500: session created but media start failed.
Keepalive 500: session state or firmware instability.

This is why the whole RTSP sequence must be preserved.

Debug checklist

Use this process:

Identify the exact method that receives 500.
Confirm authentication status before the error.
Validate the stream path for the exact model.
Test main stream and sub-stream.
Reduce resolution, bitrate, frame rate, or switch codec.
Disconnect other RTSP clients and VMS recorders.
Test direct camera URL vs NVR/restream URL.
Check camera/NVR logs for encoder or channel errors.
Reboot only after collecting the RTSP trace.
Record whether the failure is constant or intermittent.

Final diagnosis

RTSP 500 Internal Server Error is a server-side RTSP failure. The likely causes are wrong stream resource, unavailable encoder, resource exhaustion, NVR channel state, firmware bug, or failed media setup.

RTSP Inspector helps by showing exactly which RTSP method triggered the 500 and what happened before it, so troubleshooting can focus on the camera/NVR service state instead of guessing at playback or codec layers.

Evidencia reproducible para «Error interno del servidor RTSP 500: ruta de transmisión de la cámara, recurso del codificador, firmware y diagnóstico de sesión»

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 «Error interno del servidor RTSP 500: ruta de transmisión de la cámara, recurso del codificador, firmware y diagnóstico de sesión», 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.

De la observación a un veredicto por capas

En «Error interno del servidor RTSP 500: ruta de transmisión de la cámara, recurso del codificador, firmware y diagnóstico de sesión», escribe primero lo observado y después la interpretación. Una observación puede localizarse en la captura: estado RTSP asociado a CSeq, valor SDP, respuesta Transport, hueco entre secuencias, cambio de SSRC o diferencia entre RTP timestamp y RTCP sender report. «El servidor es lento» o «el codec es incompatible» sigue siendo una hipótesis hasta que una evidencia concreta la explique mejor que las alternativas.

Divide el flujo en fronteras. Primero se abre TCP. Después se aceptan OPTIONS o DESCRIBE. El SDP debe describir una pista utilizable, control URL, payload type y clock rate. SETUP necesita una respuesta Transport compatible y PLAY una Session válida. Solo entonces se evalúan llegada RTP, orden, tiempo y preparación del decoder. Detente en la primera frontera sin prueba de éxito; no permitas que datos posteriores oculten una ausencia anterior.

Mantén fuente e intervalo constantes en comparaciones. Para UDP frente a TCP interleaved usa la misma ruta y credenciales. Para main stream frente a sub stream conserva cliente y transporte. Al comparar VLC con un VMS, registra métodos, cabeceras y URL reales; una diferencia de control URL, Authorization, Session o keepalive puede explicar el resultado mejor que el nombre del programa.

Matriz de descarte

Empieza con dos hipótesis. Si no llega multimedia, UDP puede estar bloqueado o el servidor puede enviar a otros puertos. TCP interleaved prueba la primera; comparar oferta y respuesta Transport, IP y puertos prueba la segunda. Para imagen dañada, la secuencia RTP separa pérdida de paquetes de inicialización incompleta, mientras que SPS/PPS/VPS antes del primer frame prueba la hipótesis del codec.

Para cada hipótesis anota evidencia a favor y evidencia que podría refutarla. Una afirmación que ninguna captura puede negar es demasiado amplia. «NAT elimina UDP» queda refutado si RTP llega al puerto del cliente. «Faltan parámetros H.264» queda refutado al ver SPS y PPS válidos antes de IDR. Así el informe conserva prioridad y no se convierte en una lista desordenada.

Interpretar el tiempo sin excederse

RTSP CSeq ordena transacciones, RTP sequence ordena paquetes, RTP timestamp expresa tiempo de muestreo y el reloj de captura expresa llegada al punto observado. No son el mismo reloj. Variación de llegada no demuestra drift; un salto timestamp no demuestra pérdida sin secuencia. Para sincronizar audio y vídeo, los RTCP sender reports relacionan relojes RTP distintos con una referencia común.

Paquete final de aceptación

Cierra el caso cuando el arreglo se repita desde una conexión nueva con un solo cambio documentado. El informe debe indicar entradas, última frontera correcta, primera evidencia fallida, cambio, resultado y pruebas pendientes. Adjunta un fragmento pequeño del transcript o estadísticas relevantes. Oculta secretos, pero conserva CSeq, Session saneada, SSRC e intervalo.

Usa la solución de problemas RTSP para reconstruir el flujo y los informes de RTSP Inspector para entregar la frontera al equipo de cámara, red o VMS.