RTSP 401 no autorizado y 404 no encontrado: diagnóstico de la URL de la cámara y errores de autenticación

Cómo solucionar los errores de cámara RTSP 401 no autorizado y 404 no encontrado separando credenciales, rutas URL, descubrimiento ONVIF y evidencia de perfil de transmisión.

RTSP, autenticación, cámara, ONVIF, solución de problemas

Dos errores RTSP aparecen una y otra vez en los tickets de soporte: "401 no autorizado" y "404 no encontrado". Suenan simples. Uno parece un problema de inicio de sesión, el otro parece una URL incorrecta. En despliegues de cámara reales, ambos pueden ser más sutiles." Una cámara puede aceptar las mismas credenciales en la interfaz de usuario web pero rechazar RTSP. Una grabadora puede exponer diferentes rutas para la transmisión principal y la transmisión secundaria. Un escaneo ONVIF puede descubrir una URL que luego cambia. Un proveedor puede requerir un número de canal, un sufijo de transmisión o un token de perfil. Algunas cámaras también devuelven códigos de estado engañosos cuando la ruta es demasiado larga, la transmisión está deshabilitada o un modo de autenticación es incompatible con el cliente.

Para las búsquedas en Google, la consulta del usuario suele ser directa: "cámara no autorizada RTSP 401", "RTSP 404 no encontrada", "VLC funciona pero NVR dice que no hay señal" o "la URL RTSP de la cámara ONVIF no funciona". Un artículo útil no debe pretender que existe una URL mágica. Debería mostrar cómo recopilar pruebas.

Comience con el método RTSP que falló

No registre sólo el error final. Registre qué método RTSP lo devolvió:

  • OPCIONES
  • DESCRIBIR
  • CONFIGURACIÓN
  • REPRODUCIR

Si OPCIONES falla con 401, la autenticación o la política del servidor están bloqueando la sesión antes de que se soliciten los metadatos. Si DESCRIBE falla con 401, la cámara puede aceptar la conexión pero rechazar el acceso a esa ruta de transmisión. Si DESCRIBE devuelve 404, la ruta generalmente no se asigna a un perfil de transmisión. Si SETUP falla después de DESCRIBE exitoso, la URL puede ser válida pero la ruta de control de pista, el modo de transporte o el perfil de medios tienen un problema.

Esta distinción es importante porque la siguiente acción cambia. Las correcciones de credenciales no repararán una ruta de transmisión faltante. Cambiar el sufijo de la URL no solucionará una discrepancia en la autenticación de resumen.

Separe las credenciales de la ruta de transmisión

Una matriz de solución de problemas limpia se ve así:

  • El mismo nombre de usuario/contraseña funciona en la interfaz de usuario web de la cámara.
  • El servicio RTSP está habilitado
  • El puerto RTSP está abierto desde la red del cliente.
  • La ruta URL coincide con el patrón de transmisión principal o secundaria del proveedor.
  • El perfil de transmisión está habilitado en la cámara.
  • el modo de autenticación es compatible con el cliente
  • Los caracteres especiales en la contraseña están codificados correctamente.

Password characters are a frequent source of false failures. A password that contains @, :, /, ?, #, or spaces may need URL encoding when embedded in an RTSP URL. A better test is to use a client that sends credentials separately rather than relying on an inline URL.

Por qué 404 a menudo significa perfil o ruta, no red

404 No encontrado significa que se contactó al servidor y entendió la solicitud lo suficiente como para rechazar el recurso. Para las transmisiones de cámara, esto suele apuntar a uno de estos:

  • número de canal incorrecto
  • sufijo de transmisión incorrecto
  • transmisión principal deshabilitada
  • subtransmisión deshabilitada
  • la ruta de la grabadora difiere de la ruta de la cámara
  • Token de perfil ONVIF cambiado
  • Se requiere un nombre de acceso específico del proveedor
  • la transmisión existe solo después de habilitar RTSP en la configuración

La evidencia más útil es el URI de solicitud "DESCRIBE" y el estado de la respuesta. Si la cámara devuelve 404 antes del SDP, todavía no hay sesión multimedia. No salte a la pérdida de RTP o a la depuración de códecs antes de confirmar que la URL se asigna a una transmisión real.

ONVIF Discovery ayuda, pero no es lo mismo que una prueba

El descubrimiento ONVIF puede proporcionar URI de transmisión e información de perfil, pero el URI RTSP descubierto aún debe probarse. Algunos sistemas exponen ONVIF correctamente, mientras que la autenticación RTSP o el comportamiento de la ruta son diferentes. Otros devuelven un URI que es válido sólo para un perfil que luego se desactiva o se modifica.

La secuencia diagnóstica debe ser:

  1. descubrir o ingresar la URL RTSP
  2. ejecute OPCIONES y DESCRIBIR
  3. capturar códigos de estado y encabezados
  4. inspeccionar si se devuelve SDP
  5. solo entonces inspeccione SETUP, PLAY, RTP y evidencia de códec

Ese orden impide que un ingeniero trate cada falla como un problema de "cámara fuera de línea".

Cómo se debe utilizar el inspector RTSP

RTSP Inspector no es un reproductor, un administrador ONVIF ni un producto de descubrimiento de cámaras. Su función es hacer que la transacción RTSP sea lo suficientemente visible como para explicar lo sucedido. Para los casos 401 y 404, el resultado útil es:

  • solicitar URI
  • método fallido
  • código de estado
  • límite de autenticación
  • si el SDP fue devuelto
  • si el fracaso ocurrió antes de la negociación con los medios
  • Siguiente propietario recomendado: credenciales, perfil de cámara, formato de URL del proveedor, puerto de red o habilitación de transmisión

Esa es exactamente la evidencia que un integrador de campo o un ingeniero de plataformas de video necesita antes de recurrir al proveedor de la cámara o cambiar la configuración de la grabadora a ciegas.

Cuando un ticket de soporte diga "RTSP no funciona", solicite el método, el código de estado y el límite del SDP. Eso convierte una queja genérica en un caso solucionable.