2026-06-02

ONVIF funciona pero la URL RTSP falla: encontrar la ruta de transmisión de la cámara real

Por qué el descubrimiento ONVIF puede funcionar mientras falla la transmisión RTSP y cómo depurar perfiles de cámara, URL de medios, autenticación, transporte y evidencia SDP.

Es común que una cámara IP aparezca correctamente en el descubrimiento ONVIF mientras la URL RTSP aún falla. El dispositivo es visible en la red, se detecta el nombre y el modelo de la cámara, tal vez incluso se enumeran los perfiles, pero la transmisión de video real no se abre. Los usuarios buscan "ONVIF funciona pero RTSP falla", "cámara descubierta pero no hay video RTSP" o "cómo encontrar la URL RTSP desde ONVIF" porque el éxito del descubrimiento parece garantizar el éxito de la transmisión.

No es así.

ONVIF y RTSP están relacionados en muchos flujos de trabajo de cámaras, pero no son el mismo protocolo y no demuestran lo mismo. ONVIF puede indicarle que existe una cámara y puede proporcionarle un perfil multimedia. RTSP aún debe autenticarse, describir la transmisión, negociar el transporte, configurar pistas RTP y entregar paquetes de medios.

RTSP Inspector se centra en la segunda mitad: lo que realmente sucede cuando se utiliza una URL RTSP específica.

Lo que demuestra ONVIF

El descubrimiento ONVIF puede demostrar que:

La cámara responde a WS-Discovery.
La cámara expone un punto final del servicio ONVIF.
El cliente puede acceder a la interfaz de gestión de la cámara.
La cámara puede tener uno o más perfiles multimedia.
El dispositivo puede informar URI de transmisión a través de servicios de medios ONVIF.

Esto es útil, pero no es lo mismo que demostrar que la transmisión RTSP funciona. El descubrimiento ONVIF puede utilizar un puerto diferente, un comportamiento de autenticación diferente y una ruta de servicio diferente que RTSP.

Una cámara puede pasar el descubrimiento ONVIF y aun así fallar RTSP porque:

RTSP está deshabilitado en la configuración de la cámara.
La cuenta ONVIF no tiene permiso RTSP.
El URI de flujo devuelto está incompleto o es solo interno.
El puerto RTSP está bloqueado por un firewall.
La cámara requiere transporte entrelazado TCP pero el cliente intenta UDP.
El perfil apunta a H.265 pero el cliente espera H.264.
La ruta del canal NVR es incorrecta.
La cámara devuelve SDP pero no envía paquetes RTP.

Es posible que el URI de transmisión ONVIF no se pueda utilizar directamente

Algunas cámaras devuelven un URI RTSP a través de ONVIF que parece utilizable pero aún necesita modificaciones. Por ejemplo:

rtsp://192.168.1.50/Streaming/Channels/101

The real usable URL may need:

ONVIF profile does not guarantee codec support

The symptom may be:

RTSP Inspector helps by separating the layers:

RTSP transport can fail after ONVIF succeeds

This is common when:

Authentication can differ between ONVIF and RTSP

You may see:

RTSP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="IP Camera", nonce="..."

aunque el descubrimiento ONVIF funcionó. Eso significa que el servicio RTSP solicita credenciales. Si el cliente envía credenciales y la cámara continúa devolviendo "401", verifique los permisos de la cuenta, la autenticación implícita, la codificación de URL y los derechos del canal.

Los NVR hacen que esto sea más confuso porque el dispositivo ONVIF puede ser el NVR, mientras que la ruta de transmisión RTSP hace referencia a un canal de cámara detrás del NVR. Es posible que la cuenta pueda consultar el NVR pero no transmitir la transmisión principal del canal 1.

Confusión de la corriente principal y la corriente secundaria

Muchas cámaras exponen múltiples perfiles:

Transmisión principal: alta resolución, alta tasa de bits, a menudo H.265.
Subtransmisión: menor resolución, menor tasa de bits, a menudo H.264.
Transmisión móvil: tamaño de fotograma pequeño y velocidad de fotogramas más baja.

ONVIF puede devolver uno de estos perfiles de forma predeterminada. La URL RTSP copiada de un foro o PDF de proveedor puede apuntar a otro. Si la transmisión principal es H.265 pero el cliente solo admite H.264, la transmisión secundaria puede funcionar mientras que la transmisión principal falla.

Búsquedas como "La transmisión principal RTSP no funciona, la transmisión secundaria funciona" a menudo pertenecen a esta categoría. El problema no es el descubrimiento. Es la selección de perfil, la selección de códec, la tasa de bits o el comportamiento de transporte.

Cómo depurar ONVIF funciona pero RTSP falla

Utilice una lista de verificación en capas:

Confirme que el servicio RTSP de la cámara esté habilitado.
Confirme que el puerto RTSP, generalmente 554, sea accesible desde el cliente.
Obtenga el perfil multimedia ONVIF y transmita el URI.
Normalice la URL RTSP para la ruta de red que realmente está utilizando.
Agregue las credenciales con cuidado y codifique caracteres especiales en URL.
Ejecute RTSP OPCIONES y DESCRIBIR.
Inspeccionar los desafíos y respuestas de autenticación.
Inspeccione SDP en busca de códec, tipo de carga útil, velocidad de reloj y URL de control de seguimiento.
Compare el transporte entrelazado UDP y TCP.
Confirme que los paquetes RTP lleguen después de "PLAY".
Verifique la continuidad de la secuencia RTP, las marcas de tiempo y el tipo de carga útil.
Pruebe la transmisión principal y la transmisión secundaria por separado.

Esta lista de verificación evita un error común: tratar el éxito del descubrimiento de ONVIF como prueba de que la transmisión de medios debería funcionar automáticamente.

Lo que debería mostrar el seguimiento RTSP

Un flujo RTSP saludable suele tener el siguiente aspecto:

OPTIONS rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

DESCRIBE rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK
Content-Type: application/sdp

SETUP rtsp://camera/stream/trackID=1 RTSP/1.0
RTSP/1.0 200 OK
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

PLAY rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

Final diagnosis

Evidencia reproducible para «ONVIF funciona pero la URL RTSP falla: encontrar la ruta de transmisión de la cámara real»

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 «ONVIF funciona pero la URL RTSP falla: encontrar la ruta de transmisión de la cámara real», 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 «ONVIF funciona pero la URL RTSP falla: encontrar la ruta de transmisión de la cámara real» es: Por qué el descubrimiento ONVIF puede funcionar mientras falla la transmisión RTSP y cómo depurar perfiles de cámara, URL de medios, autenticación, transporte y evidencia SDP. 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: ONVIF funciona pero la URL RTSP falla: encontrar la ruta de transmisión de la cámara real

Cierre «ONVIF funciona pero la URL RTSP falla: encontrar la ruta de transmisión de la cámara real» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 2: Por qué el descubrimiento ONVIF puede funcionar mientras falla la transmisión RTSP y cómo

Para «Por qué el descubrimiento ONVIF puede funcionar mientras falla la transmisión RTSP y cómo depurar perfiles de cámara, URL de medios, autenticación, tr», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 3: Lo que demuestra ONVIF

Cierre «Lo que demuestra ONVIF» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 4: Es posible que el URI de transmisión ONVIF no se pueda utilizar directamente

Para «Es posible que el URI de transmisión ONVIF no se pueda utilizar directamente», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 5: ONVIF profile does not guarantee codec support

Cierre «ONVIF profile does not guarantee codec support» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 6: RTSP transport can fail after ONVIF succeeds

Para «RTSP transport can fail after ONVIF succeeds», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 7: Authentication can differ between ONVIF and RTSP

Cierre «Authentication can differ between ONVIF and RTSP» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 8: Confusión de la corriente principal y la corriente secundaria

Para «Confusión de la corriente principal y la corriente secundaria», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 9: Cómo depurar ONVIF funciona pero RTSP falla

Cierre «Cómo depurar ONVIF funciona pero RTSP falla» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 10: Lo que debería mostrar el seguimiento RTSP

Para «Lo que debería mostrar el seguimiento RTSP», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
ONVIF funciona pero la URL RTSP falla: encontrar la ruta de transmisión de la cámara real	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Por qué el descubrimiento ONVIF puede funcionar mientras falla la transmisión RTSP y cómo depurar perfiles de cámara, UR	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Lo que demuestra ONVIF	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Es posible que el URI de transmisión ONVIF no se pueda utilizar directamente	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
ONVIF profile does not guarantee codec support	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
RTSP transport can fail after ONVIF succeeds	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: