2026-06-02

Transmisiones de cámara RTSP multidifusión y UDP: por qué Discovery funciona pero los medios no llegan

Cómo diagnosticar transmisiones de cámara RTSP donde el descubrimiento ONVIF, el control del tráfico o la configuración de multidifusión funcionan pero los medios RTP nunca llegan.

Las redes de cámaras a menudo combinan RTSP de unidifusión, RTP de multidifusión, descubrimiento ONVIF, VLAN, conmutadores PoE, firewalls y NVR. El síntoma puede resultar confuso: "se descubre la cámara, la URL RTSP es válida, DESCRIBE devuelve SDP, pero los paquetes multimedia nunca llegan." Este es un límite de protocolo clásico. El descubrimiento no son medios. El control RTSP no es entrega RTP. La accesibilidad de multidifusión no es lo mismo que la accesibilidad de unidifusión.

ONVIF Discovery es una conversación UDP diferente

El descubrimiento ONVIF normalmente utiliza multidifusión UDP en una dirección y puerto de descubrimiento. Si el descubrimiento tiene éxito, demuestra que al menos una ruta de control de estilo multidifusión funcionó para el descubrimiento. No prueba que los grupos de multidifusión RTP estén permitidos, unidos, enrutados o reenviados.

Errores comunes:

suponiendo que el descubrimiento de ONVIF demuestra la ruta de medios RTP
prueba desde una VLAN diferente a la del NVR
permitiendo TCP 554 pero bloqueando los puertos de medios UDP
bloquear el tráfico del grupo de multidifusión en el conmutador
olvidar el espionaje IGMP o el comportamiento de consulta
probando la URL directa de la cámara mientras NVR usa una ruta diferente

El informe debe nombrar el tipo de tráfico: descubrimiento, control RTSP, medios RTP o retroalimentación RTCP.

La multidifusión requiere membresía en un grupo

Para RTP de multidifusión, el receptor debe unirse al grupo de multidifusión. Es posible que los conmutadores y enrutadores necesiten un comportamiento IGMP para reenviar el tráfico correctamente. Si la multidifusión está deshabilitada, filtrada o mal configurada, es posible que el control RTSP aún funcione aunque los medios nunca lleguen.

Evidencias útiles:

SDP declara dirección de multidifusión o transporte de unidifusión
El encabezado de transporte SETUP confirma el modo solicitado
interfaz del receptor y VLAN
dirección de grupo de multidifusión
si los paquetes RTP llegan al punto de captura
si aparece RTCP
si el modo unidifusión se comporta de manera diferente

Si RTP de unidifusión funciona y la multidifusión no, el problema probablemente sea la configuración de multidifusión de la red, no H.264.

Los medios UDP se pueden bloquear mientras funciona el control TCP

Los firewalls suelen permitir TCP 554 u 8554 pero bloquean los puertos UDP. NAT también puede dañar los medios UDP. Esto crea un patrón común:

La conexión TCP se realiza correctamente
DESCRIBIR tiene éxito
SETUP tiene éxito
PLAY tiene éxito
no llega ningún RTP

Cambiar a TCP intercalado es una comparación útil. Si TCP intercalado funciona, es probable que el servidor RTSP y el códec funcionen. La ruta de los medios UDP necesita atención.

Qué capturar

Para casos de multidifusión y UDP, capture:

Encabezados de solicitud y respuesta RTSP
Dirección de medios SDP e información de seguimiento
encabezado de transporte desde SETUP
Puertos de cliente y servidor.
grupo de multidifusión
Llegada o ausencia del paquete RTP
Llegada o ausencia de paquetes RTCP
misma prueba sobre TCP intercalado

Esta evidencia ayuda al equipo de red a corregir el enrutamiento, el firewall o el reenvío de multidifusión en lugar de pedirle al proveedor de la cámara que cambie la configuración del códec.

Dónde encaja el inspector RTSP

RTSP Inspector está diseñado para evidencia de protocolo, no para conjeturas visuales. En casos de multidifusión y UDP, su valor muestra dónde se detuvo la transmisión:

el descubrimiento funcionó pero RTSP falló
RTSP funcionó pero RTP nunca llegó
UDP falló pero el entrelazado TCP funcionó
Se declaró un grupo de multidifusión pero ningún paquete llegó al cliente.
Llegó RTP pero falló la preparación del códec

Esos son fracasos diferentes. Una ventana de reproductor no puede distinguirlos de manera confiable. Un informe de protocolo puede hacerlo.

Evidencia reproducible para «Transmisiones de cámara RTSP multidifusión y UDP: por qué Discovery funciona pero los medios no llegan»

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 «Transmisiones de cámara RTSP multidifusión y UDP: por qué Discovery funciona pero los medios no llegan», 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 «Transmisiones de cámara RTSP multidifusión y UDP: por qué Discovery funciona pero los medios no llegan» es: Cómo diagnosticar transmisiones de cámara RTSP donde el descubrimiento ONVIF, el control del tráfico o la configuración de multidifusión funcionan pero los medios RTP nunca llegan. 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: Transmisiones de cámara RTSP multidifusión y UDP: por qué Discovery funciona pero los medi

Si «Transmisiones de cámara RTSP multidifusión y UDP: por qué Discovery funciona pero los medios no llegan» 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 2: Cómo diagnosticar transmisiones de cámara RTSP donde el descubrimiento ONVIF, el control d

Compruebe «Cómo diagnosticar transmisiones de cámara RTSP donde el descubrimiento ONVIF, el control del tráfico o la configuración de multidifusión funcionan per» 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 3: ONVIF Discovery es una conversación UDP diferente

Si «ONVIF Discovery es una conversación UDP diferente» 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 4: La multidifusión requiere membresía en un grupo

Compruebe «La multidifusión requiere membresía en un grupo» 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 5: Los medios UDP se pueden bloquear mientras funciona el control TCP

Si «Los medios UDP se pueden bloquear mientras funciona el control TCP» 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 6: Qué capturar

Compruebe «Qué capturar» 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 7: Dónde encaja el inspector RTSP

Si «Dónde encaja el inspector RTSP» 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 8: Evidencia reproducible para «Transmisiones de cámara RTSP multidifusión y UDP: por qué Dis

Compruebe «Evidencia reproducible para «Transmisiones de cámara RTSP multidifusión y UDP: por qué Discovery funciona pero los medios no llegan»» 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 9: ¿Cómo se redacta una respuesta que pueda citarse?

Si «¿Cómo se redacta una respuesta que pueda citarse?» 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 10: ¿Qué hace reproducible el caso?

Compruebe «¿Qué hace reproducible el caso?» 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.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Transmisiones de cámara RTSP multidifusión y UDP: por qué Discovery funciona pero los medios no llegan	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo diagnosticar transmisiones de cámara RTSP donde el descubrimiento ONVIF, el control del tráfico o la configuración	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
ONVIF Discovery es una conversación UDP diferente	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
La multidifusión requiere membresía en un grupo	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Los medios UDP se pueden bloquear mientras funciona el control TCP	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Qué capturar	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: