What You Need to Know About NMOS (IS04/05) When Building an AV System

When you build a modern IP-based AV system—especially one using SMPTE ST 2110 or IPMX—you’re inevitably facing the need for automated discovery and connection of streams across devices from multiple vendors. NMOS—Networked Media Open Specifications—forms the critical control layer enabling interoperability, scalability and streamlined operations. In this guide, we draw on the latest web-published NMOS documentation to explain how IS-04 and IS-05 work together, why they matter in real deployments, and what best practices you should follow as an integrator.

This guide is based on authoritative AMWA sources including the IS-04, IS-05 and controller guide documents. We include real examples (e.g. Elemental Live, Vizrt), reference scalability testing studies, and answer long-tail questions integrators commonly ask.

IS-04: Discovery and Registration

IS-04 defines how NMOS Nodes register their presence, capabilities and API endpoints with a central registry or via peer-to-peer discovery. A Node represents a host on the network, containing one or more Devices, each in turn hosting Senders, Receivers, Sources and Flows. When a Device boots up it discovers the registry—typically via DNS-SD or mDNS—and registers itself and all its resources via the IS-04 Registration API, sending regular heartbeat messages to maintain presence. IS-04 also exposes a Query API which controllers subscribe to for updates on the available resources and changes over time.

Why this matters: Automates discovery across large infrastructures, eliminating spreadsheets and manual configuration. A registry database maintains up-to-date inventories of Senders and Receivers across the facility.

IS-05: Connection Management

IS-05 sits on top of IS-04, enabling controllers to actually connect available Senders to Receivers. The Connection API is exposed by each Device as a control endpoint advertised via the Device’s IS-04 data. Controllers use the control URI to stage transport parameters and activate connections—often via SDP files—first to a Sender, then to a Receiver.

Key behaviors:

• Two-stage connection workflow (stage then activate)
• SDP transport files exchanged to set up multicast flows or RTP parameters
• Versioning mechanism: when you change active parameters, the relevant IS-04 Sender or Receiver version attribute must update, avoiding unnecessary polling

Real-world examples and implementation notes

AWS Elemental Live provides an example: it discovers NMOS registry, advertises SMPTE 2110 inputs/outputs as IS-04 Senders and Receivers, and allows controllers to manage connections via IS-05. When configured, Elemental Live auto-detects the registry and handles SDP transport files behind the scenes.

In Vizrt environments, enabling NMOS requires configuration changes in JSON or XML files to register nodes/devices, set DNS-SD behavior, and map senders and receivers with labels and descriptions for human operators.

Scalability, performance and deployment insights

Sony’s NMOS scalability study tested the time to register 2,500 NMOS Nodes (each with a Sender, Receiver, Source, Flow, Device and Node resource) on a virtualised network: registration completed in under four minutes, demonstrating IS-04 performance at scale. Future plans included testing bulk connection operations via IS-05 and redundancy behaviors.

Best practices include using multiple registry instances, enabling versioning correctly, leveraging DNS-SD across subnets, and handling legacy Node API fallbacks until IS-04 v2.0 achieves full deployment.

Current trends and ecosystem alignment

NMOS remains a core part of the JTNM reference architecture and the EBU technology pyramid for ST 2110 and IPMX workflows. Open-source NMOS implementations such as Sony’s nmos-cpp (registry and node functions), BBC R&D’s Python reference implementations, and Streampunk’s ledger all support both IS-04 and IS-05.

Security hardening via BCP-003-01 TLS recommendations is increasingly adopted, especially for controlling devices in multi-vendor or cloud-based deployments.
 

Long-tail Keywords in questions integrators ask

What are long-tail questions? They are specific queries like:

• How does NMOS IS-04 discovery work across VLANs using DNS-SD?
• How do you stage and activate an IS-05 connection with SDP files?
• What steps ensure IS-04 and IS-05 work together in a multi-site deployment?
• How to monitor version changes on IS-04 Sender and Receiver resources?
• Can legacy Node API connections coexist with IS-05 controllers during transition?
• What performance can I expect when registering thousands of NMOS nodes in a facility?

Each question maps to a concept covered above, making your article SEO-rich while still grounded in real deployment advice.

Logical flow recap

You register systems via IS-04, controllers query resources, then use IS-05 to stage and activate connections. Nodes and Devices advertise control endpoints, controllers gather metadata, exchange SDP transport files, and versioning ensures minimal polling. Real products like Elemental Live and Vizrt show how deployments put this into practice, and OEM-agnostic open-source stacks make system integration smoother. Scalability testing validates performance, while current best practices recommend redundancy, BCP-003-01 security, and future migration paths.

This long-form guide stands as a starting point for AV integrators building NMOS-based IP media systems. It explains why IS-04 and IS-05 are essential, how they interact, what tools support them, and what deployment-level considerations matter most.