Two specifications, two jobs
IS-04 is discovery and registration. Each device runs a node that describes itself — devices, senders, receivers, flows — and either registers with a registry or answers for itself over multicast DNS. The result is an inventory: what exists, what it can send, what it can receive.
IS-05 is connection management. A controller stages a change on a sender or receiver, activates it, and the device begins transmitting or subscribing. The transport parameters — multicast addresses, ports, and the SDP that describes the stream — move through this API.
The media itself never passes through either. Registry and controller arrange the introduction; the packets go directly between nodes. This is why a plant with a dead registry keeps passing video, and why people wrongly conclude NMOS is not needed.
Registry or peer-to-peer
With a registry, nodes find it through a DNS-SD record — advertised over multicast DNS on a flat network, or through unicast DNS in larger plants. Without one, nodes advertise themselves and controllers browse for them directly. Peer-to-peer is simpler to start and does not scale; a registry scales and adds a dependency that must be monitored.
Most "the device is invisible" reports come down to the network rather than the specification:
- mDNS is link-local multicast. Across a routed boundary it simply does not arrive, so nodes and controller must share a subnet or the plant must use unicast DNS-SD.
- Some switches filter or rate-limit multicast in ways that drop mDNS while ordinary traffic passes.
- A host firewall that blocks UDP 5353 makes a device invisible while leaving it perfectly reachable by address.
- Two registries on the same network give different controllers different worlds, which produces a memorable afternoon.
"It appears, but it will not connect"
This is the classic IS-05 failure, and it usually falls into one of four buckets:
| What you see | What it usually is |
|---|---|
| Activation is accepted, no packets arrive | The receiver joined a multicast group the network does not deliver — IGMP snooping or no querier on the VLAN |
| Receiver rejects the staged parameters | SDP describes a format the receiver does not support, often a colour sampling or depth mismatch rather than resolution |
| Connection drops after a few seconds | The sender is transmitting, but the receiver cannot lock — check PTP before blaming NMOS |
| Works from one controller, not another | The controllers are reading different registries, or one is using peer-to-peer discovery and seeing stale data |
Read the SDP, not the label. The device list shows friendly names; the SDP shows what will actually be sent — media type, sampling, depth, packing mode, the PTP reference and the multicast destination. When a connection fails for no visible reason, comparing the sender's SDP against what the receiver claims to accept resolves it faster than any amount of clicking.
Bringing up an environment to test against
The hard part of testing NMOS is having something correct to test against. A device that will not register could be wrong, or the registry could be. Running a known-good registry, node and controller on one machine removes that ambiguity: point the device at your registry and watch whether it appears, then connect it to your own receiver and watch whether packets flow.
That is also the quickest way to answer the question vendors ask during interoperability testing — whether the fault is on their side or yours — with evidence rather than opinion.