Una fuente NDI puede no aparecer en la lista, verse pero no poder conectar, o estar conectada sin imagen ni sonido útiles. Empiece por el síntoma:
- Fuente ausente: compruebe emisor, interfaz y método de descubrimiento.
- Fuente listada, sin conexión: compruebe transporte de medios, puertos y ruta.
- Conectada, sin imagen ni audio: inspeccione el medio recibido y el decodificador.
Use el mismo emisor y receptor en todas las comprobaciones. Anote nombres de fuente, versiones NDI, interfaces de red y hora de cada prueba para comparar resultados.
Cuando falta una fuente NDI, demuestre primero el descubrimiento
Confirme que la aplicación o el dispositivo emisor esté en ejecución y tenga activada la salida NDI. Compruebe después que el receptor mira la interfaz prevista y que ambos extremos pertenecen al grupo NDI esperado. Una fuente ausente en una aplicación pero visible en una herramienta diagnóstica NDI puede ser un problema de aplicación, runtime o configuración, no un fallo de descubrimiento de toda la red.
De forma predeterminada, NDI usa mDNS para descubrimiento sin configuración. Su dirección multicast IPv4 es 224.0.0.251 en UDP 5353 y está limitado a una LAN física o lógica. En Windows, un perfil de red Pública puede impedir las respuestas mDNS que necesita NDI; en redes de dominio administradas, el administrador debe permitir ese tráfico. Consulte la referencia oficial de mDNS de NDI.
Para un entorno aislado, enrutado o en la nube, elija un diseño de descubrimiento documentado en vez de suponer que multicast lo atravesará. Una entrada manual de host puede consultar una máquina remota por TCP 5960, pero solo ayuda al receptor a encontrar las fuentes de esa máquina. No establece conectividad de medios ni crea capacidad de red.
Configure Discovery Server en emisor y receptor
NDI Discovery Server es un registro centralizado para instalaciones donde mDNS no es deseable o no está disponible. Su escucha predeterminada es TCP 5959, y el servicio puede enlazarse a una dirección elegida o configurarse en otro puerto. Los clientes deben usar la misma dirección y puerto del servidor previstos por el despliegue.
El detalle importante depende del rol. Un emisor configurado con Discovery Server no anuncia mediante mDNS; ese emisor es visible para finders y receptores configurados para ese servidor. Los finders y receptores también pueden usar mDNS para máquinas locales no configuradas con Discovery Server. Trátelo como una decisión de diseño, no como un interruptor que se aplica a un host y se olvida.
NDI 5 documenta direcciones de Discovery Server separadas por comas para clientes compatibles. Pruebe el emisor, receptor y versión NDI exactos ante una caída del servidor: las implementaciones recientes de receptor-listener pueden requerir lógica de cliente que detecte un servidor fallido y vuelva a conectar. La visión general de Discovery Server y su referencia de configuración son la fuente de verdad para la versión instalada.
Use la regla de puertos que corresponda al modo NDI
La siguiente es una tabla funcional, no permiso para abrir un rango sin restricciones entre todos los hosts. Aplique la regla en la dirección, zona y número de conexiones del emisor y receptor desplegados. Confirme la versión NDI instalada y el modo de recepción elegido antes de crear una regla de mínimo privilegio.
| Función | Regla oficial de puertos | Qué demuestra el resultado |
|---|---|---|
| Descubrimiento mDNS | UDP 5353; multicast IPv4 224.0.0.251 | Hay tráfico de descubrimiento en esa LAN, no que los medios sean utilizables. |
| Discovery Server | TCP 5959 predeterminado; configurable | Un cliente puede alcanzar el registro, no que tenga un stream. |
| Consulta manual de host | TCP 5960 | Puede consultarse un host remoto para hallar fuentes. |
| Medios TCP base | TCP 5961 y superiores; al menos un puerto por conexión | Úselo cuando el modo elegido use TCP base. |
| UDP fiable NDI 5+ | UDP 5960 y superiores; compartido con TCP, un puerto por proceso NDI | Compartir conexiones cambia el supuesto de cantidad. |
| Recepción Multi-TCP o UDP | TCP/UDP 6960 y superiores; al menos un puerto por conexión | Regla de medios del lado receptor para ese modo. |
| Envío Multi-TCP, UDP unicast o UDP multicast | TCP/UDP 7960 y superiores; al menos un puerto por conexión | Regla de medios del lado emisor para ese modo. |
La documentación actual de NDI dice que las versiones 4.6 y posteriores ya no usan puertos efímeros. La referencia completa de puertos NDI debe acompañar cualquier cambio de firewall.
Compruebe subredes e interfaces de red
mDNS tiene un límite de LAN; el enrutamiento, los relés multicast y el comportamiento de VPN no lo convierten en un servicio general de descubrimiento enrutado. Use Discovery Server o el método documentado de direccionamiento manual del producto participante si fuente y receptor están en redes controladas separadas.
En un host multitarjeta, registre qué interfaz posee el descubrimiento y cuál transporta los medios. Un adaptador de gestión, Wi-Fi o VPN puede hacer aparecer una fuente desde la red equivocada o hacer que las respuestas salgan por una ruta que el receptor no puede usar. Asigne direcciones estables a la interfaz de medios, evite nombres de máquina duplicados y haga determinista la preferencia de interfaz antes del evento.
Fuente listada pero sin imagen ni sonido
Una fuente listada significa que el receptor obtuvo un anuncio de fuente o una entrada de registro. No demuestra que pueda abrirse el transporte elegido, que esté permitida la ruta de retorno ni que el receptor pueda decodificar el vídeo. Inspeccione URL y puerto de fuente activos, estado de conexión, modo de recepción, presencia de vídeo, presencia de audio y salida renderizada.
La herramienta actual NDI Discovery puede mostrar emisores registrados, dirección/puerto de fuente y datos de monitorización del receptor, incluido estado de conexión, modo de recepción y presencia de vídeo o audio. Use esa evidencia para elegir la siguiente comprobación. Una prueba TCP al puerto 5959 solo demuestra alcance a Discovery Server; no demuestra una sesión de medios NDI.
Compruebe si mDNS alcanza esta interfaz Linux
sudo tcpdump -ni <media-interface> udp port 5353Resultado esperado: aparecen paquetes mDNS mientras el descubrimiento está activo en esa interfaz. Confirman tráfico de descubrimiento en ella, no acceso a los puertos de medios elegidos. Ejecute capturas y diagnósticos de firewall únicamente con la autorización requerida para esa red de producción.
Compruebe el alcance de Discovery Server desde Windows
Test-NetConnection <discovery-server> -Port 5959Resultado esperado: conexión TCP correcta a dirección y puerto configurados. Esto confirma un listener TCP accesible. Compruebe registro, pertenencia a grupos y entrega de medios en la aplicación NDI.
Compruebe fuentes descubiertas en Callaba
Callaba Cloud NDI ofrece al operador un lugar para configurar descubrimiento, interfaces y adaptadores, y su flujo de dispositivos descubiertos puede mostrar el inventario actual. Sirve para separar una entrada de dispositivo guardada de una fuente descubierta actualmente por la instancia seleccionada. Compruebe la fuente elegida en el receptor final además de en el inventario.
Una vez actualizada la fuente y verificada la ruta de medios, configure el adaptador NDI o la tarea posterior que realmente necesite la producción. Compruebe su salida por separado en el receptor objetivo; un resultado de descubrimiento es una entrada para esa decisión, no la prueba de aceptación.
Registre la configuración que funciona
- Fuente ausente: demuestre salida del emisor, grupo, NIC elegida y configuración de mDNS o Discovery Server.
- Fuente listada, sin sesión: registre dirección de fuente, modo de transporte y regla de medios activa; inspeccione firewall y enrutamiento de extremos en ambos sentidos.
- Sesión, sin fotogramas útiles: inspeccione modo de recepción, bitrate, presencia de vídeo/audio, compatibilidad de decodificación y salida realmente renderizada.
- Antes de aceptar: repita la ruta correcta en interfaces de producción y registre configuración, nombre de fuente y evidencia en el runbook.
Siguientes pasos
Use Cloud NDI para configurar la ruta de descubrimiento e interfaz prevista y lea después la referencia de dispositivos descubiertos cuando el flujo requiera comprobar inventario. Mantenga la prueba de aceptación de producción en el receptor final: imagen en avance, audio esperado y ruta de salida elegida.
