Illustration générée par IA — visuel conceptuel.
NDI en environnement managé : pourquoi le « ça marche en démo » ne suffit pas
NDI est très attractif en entreprise et en hôtellerie parce qu’il permet de transporter de la vidéo sur IP avec une mise en service souvent rapide. C’est précisément ce qui crée un risque en rénovation ou en « déploiement événementiel interne » : on branche sur le LAN existant, on “voit” les sources, puis l’intégration se heurte à des sujets IT classiques (segmentation, filtrage, Wi‑Fi, redondance, politiques de sécurité).
Dans cet article, on se concentre sur trois points utiles au bureau d’études : (1) la découverte NDI (mDNS) et ses limites, (2) la résilience via NDI Discovery Service (et sa redondance), (3) les limites de sécurité à expliciter quand NDI est posé sur un réseau d’entreprise/hôtel.
Pour replacer NDI dans le panorama « audio/vidéo sur IP » (multicast, segmentation, recette réseau), vous pouvez aussi lire : AV-over-IP : comment distribuer audio et vidéo sur un réseau professionnel ?
Comprendre la découverte NDI : mDNS (par défaut) et sa portée réelle
Ce qui est établi par les sources NDI (NDI 5.6)
Le White Paper NDI 5.6 (2023) décrit la découverte NDI par défaut via mDNS (multicast DNS). L’intérêt est « zéro configuration » : les équipements annoncent leurs services et les applications découvrent les sources automatiquement.
Les paramètres mDNS explicitement documentés incluent notamment l’adresse multicast IPv4 224.0.0.251 et le port UDP 5353 (et la MAC multicast associée). Source : NDI — NDI 5.6 White Paper (PDF).
La limite structurante : « un seul LAN » (et ce que cela implique en VLAN)
Dans le même document, NDI rappelle que mDNS repose sur du multicast link-local : sa portée est limitée à un LAN physique/logique. Autrement dit : dès que vous segmentez (VLAN, sous-réseaux), la découverte « automatique » ne traverse pas naturellement ces frontières. Source : NDI — NDI 5.6 White Paper (PDF).
Conséquence BE : si l’architecture réseau impose une segmentation (ce qui est généralement souhaitable), la question n’est pas “NDI marche-t-il ?”, mais plutôt : quelle méthode de découverte est compatible avec notre segmentation et nos règles de filtrage ?
Point pratique (Linux) : mDNS dépend souvent d’Avahi
Pour les environnements Linux, la doc NDI indique que la pile mDNS dépend typiquement d’Avahi (publication et résolution des annonces .local), et précise que la découverte mDNS peut prendre quelques secondes. Source : NDI Docs — NDI-FIND.
NDI Discovery Service : découverte centralisée, unicast et redondance
Ce que fait réellement le Discovery Service
Le White Paper NDI 5.6 décrit le NDI Discovery service/server comme un registre centralisé (application en ligne de commande Windows/macOS/Linux) qui remplace la découverte automatique mDNS par un mécanisme de « registration » auprès d’un serveur. L’intérêt est notamment de permettre un fonctionnement entièrement en unicast (utile si le multicast n’est pas possible ou pas souhaité). Source : NDI — NDI 5.6 White Paper (PDF).
Comportement « Sender » vs « Receiver » : point clé à ne pas manquer
Les documents NDI (White Paper + docs) indiquent un point structurant :
- Côté Sender (émetteur) : si un Sender est configuré pour utiliser un Discovery Service, il n’utilise plus mDNS ; ses sources ne sont visibles que des clients configurés sur ce Discovery server. Sources : White Paper + NDI Docs — Discovery Server.
- Côté Receiver (récepteur) : les applications peuvent cumuler les sources trouvées via Discovery server et celles découvertes via mDNS (pour des machines non configurées « discovery »). Sources : NDI Docs — SDK configuration files + Discovery Server.
Traduction projet : on peut progressivement « assainir » un réseau en basculant les équipements critiques (senders) en Discovery Service, tout en tolérant temporairement de la découverte mDNS résiduelle côté réception (si c’est accepté).
Redondance : plusieurs Discovery Servers, en parallèle
La redondance du Discovery Service est documentée : NDI v5 permet de définir une liste de serveurs (séparés par des virgules), utilisés simultanément, afin de conserver la visibilité des sources si l’un des serveurs tombe. Sources : White Paper + SDK configuration files.
La doc « configuration files » précise aussi que la configuration networks.discovery peut inclure plusieurs Discovery Servers, que les ports peuvent être spécifiés, et que le port par défaut est 5959 si aucun port n’est indiqué. Source : NDI Docs — SDK configuration files.
Ports et flux : ce qu’il faut cadrer au CCTP (sans « ouvrir large »)
Le White Paper NDI 5.6 fournit une base de ports (dont 5959/TCP pour le Discovery Server, 5960/TCP pour des requêtes de découverte « remote sources », et des plages à partir de 5961+ pour des connexions de stream ; il mentionne aussi l’usage d’UDP dans la plage 5960+ en mode Reliable UDP v5+). Source : NDI — NDI 5.6 White Paper (PDF).
La documentation « SDK configuration files » indique par ailleurs : « Each local machine runs a service on port 5960 » pour permettre la découverte de sources sur des IPs spécifiées, sans dépendre de mDNS. Source : NDI Docs — SDK configuration files.
Recommandation BE : ne transformez pas ces informations en « règle firewall universelle » copiée-collée. Utilisez-les pour écrire un chapitre clair : (1) quels rôles existent sur votre site (senders, receivers, discovery servers), (2) quels flux sont autorisés entre quels VLAN, (3) comment on prouve en recette que c’est suffisant (tests).
Sécurité : ce qui est prouvé vs non prouvé (et comment compenser côté architecture)
Ce que les sources consultées ne permettent pas d’affirmer
Dans les sources primaires fournies et consultées ici (White Paper NDI 5.6 + docs Discovery/config/find), il n’y a pas de mention explicite établissant un chiffrement générique des flux NDI “LAN / High Bandwidth” (hors Bridge). Autrement dit : le niveau de chiffrement des flux NDI standard sur LAN n’est pas prouvé par ces documents.
Conséquence : en étude, il est prudent de traiter NDI sur LAN comme un flux qui doit être protégé par le réseau (segmentation + filtrage + contrôle d’accès), plutôt que de présumer une protection cryptographique intégrée.
Ce qui est établi sur le périmètre « NDI Bridge »
Pour NDI Bridge, les pages officielles NDI Tools / Embedded Bridge documentent une Encryption Key (et indiquent que les communications via Bridge sont chiffrées), sans détailler les algorithmes dans les extraits consultés. Sources : NDI Tools — Bridge et NDI Docs — Embedded Bridge.
Mesures compensatoires recommandées (LAN managé)
Dans un réseau d’entreprise/hôtel, la posture la plus robuste consiste à protéger NDI comme un service audiovisuel interne, avec une logique « allow‑list » :
- Segmentation : VLAN dédié « AV/NDI » (ou au minimum une zone dédiée), séparé des réseaux bureautiques et a fortiori du Wi‑Fi invités. Voir : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?
- Filtrage inter‑VLAN : n’autoriser que les flux nécessaires (par rôle : senders ↔ receivers, receivers ↔ discovery). Éviter l’exposition large à tout le site.
- Gouvernance des accès : limiter l’accès aux outils d’administration (switches, serveurs, stations NDI) depuis un périmètre « admin/tech » (poste(s) et comptes dédiés).
- Supervision : surveiller les points de concentration (cœur/distribution, uplinks, switches AV, serveurs Discovery) pour éviter que l’incident soit vu « côté événementiel » avant d’être vu « côté IT ». Voir : Supervision réseau : quels équipements et indicateurs faut-il réellement surveiller ?
Pour un besoin d’accompagnement (audit/architecture), voir notre page solution : Réseau d’entreprise.
Cas d’usage : salle événementielle en hôtel / entreprise (déploiement « vite » sur LAN existant)
Pattern recommandé : « îlot AV » contrôlé, raccordé au LAN
En rénovation, une salle événementielle (ballroom, salles modulaires, auditorium interne) est souvent un endroit où NDI apparaît « en dernier » : prestataire externe, parc de PC, caméras, régie temporaire. La stratégie BE la plus exploitable consiste à prévoir un périmètre réseau dédié :
- un VLAN (ou une baie/switch AV) pour les équipements NDI ;
- un chemin clair vers les destinations autorisées (mur d’écrans, salle de régie, streaming interne) ;
- un mode de découverte choisi (mDNS si un seul LAN et multicast accepté, ou Discovery Service si segmentation stricte / multicast non souhaité).
En hôtellerie, cette approche s’inscrit dans une architecture IP convergée (Wi‑Fi/VoIP/CCTV/GRMS), qui impose naturellement une discipline de segmentation. Voir : Architecture réseau IP d’un hôtel : comment faire cohabiter Wi-Fi, IPTV, VoIP, CCTV et GRMS ?
Wi‑Fi : éviter les contresens « NDI sur le Wi‑Fi invités »
En pratique, NDI est souvent plus stable quand les équipements fixes (encodeurs, décoders, stations de régie, serveurs Discovery) sont câblés, et que le Wi‑Fi est réservé aux terminaux réellement mobiles. Pour la conception Wi‑Fi en entreprise, voir : Réseau Wi-Fi professionnel : comment bien le concevoir en entreprise ?
Recette (tests) : comment valider découverte, résilience et sécurité sans “croire”
Une validation utile ne consiste pas à afficher une image une fois. Pour un site managé, la recette doit prouver :
- Découverte
- les sources NDI apparaissent en conditions nominales (mDNS ou Discovery Service selon design) ;
- le délai de découverte est acceptable pour l’usage (en tenant compte des secondes possibles en mDNS). Source : NDI-FIND.
- Résilience
- si Discovery Service est utilisé : test de bascule sur le serveur de redondance (liste multi-serveurs) et vérification de la visibilité des sources. Source : SDK configuration files.
- coupure contrôlée d’un switch d’accès / d’un uplink : observation de l’impact (et limites acceptées) ;
- si la continuité électrique est dans le périmètre : test de coupure secteur sur la baie AV (et reprise). Pour cadrer l’onduleur par services : UPS/onduleur : que peut-on réellement maintenir en cas de coupure ?
- Sécurité (réseau)
- les flux NDI ne sont pas visibles depuis des VLAN non autorisés (bureautique, invités) ;
- les interfaces d’administration ne sont accessibles que depuis les zones d’admin prévues ;
- les règles inter‑VLAN sont documentées (DOE) et reproductibles.
Pour cadrer la remise documentaire, voir : Documentation réseau : quels schémas et sauvegardes remettre au client ?
Sources et documentation (NDI)
- NDI — NDI 5.6 White Paper (2023, PDF)
- NDI Docs — SDK configuration files (Discovery, redondance, ports)
- NDI Docs — Discovery Server
- NDI Docs — NDI-FIND (mDNS, Avahi)
- NDI Tools — Bridge (Encryption Key)
- NDI Docs — Embedded Bridge (communications chiffrées, option secure)
Besoin d’un cadrage réseau (VLAN, filtrage, recette) pour un projet NDI en entreprise ou hôtellerie ? Nous pouvons vous aider à structurer une architecture exploitable (études + mise en service). Découvrir notre approche Réseau d’entreprise.
