-
Notifications
You must be signed in to change notification settings - Fork 20
IS 04
AMWA NMOS IS-04 consists of three API specifications which provide the means to discover Nodes and their associated resources related to the processing of video, audio or other data. IS-04 systems are intended to enable 'zero-configuration' deployments, reducing the necessity to spend time manually configuring equipment before it is used.
IS-04 can be operated in two primary modes:
- Registered mode: Each Node automatically discovers a network registry service implementing the IS-04 Registration API. The Node is responsible for registering its capabilities with the Registration API, with the registry taking on responsibility for aggregating this data and distributing it to clients via the IS-04 Query API.
- Peer to peer mode: Nodes advertise their own presence onto the network in the absence of a registry, allowing any client (including other Nodes) to find them directly and interact with their capabilities via their IS-04 Node API.
The IS-04 APIs expose Nodes, Devices, Sources, Flows, Senders and Receivers as described in the Glossary. Each resource is identified by a UUID (Universally Unique Identifier) which provides a reliable reference point to build on top of, meaning that even the most complex deployments can easily map control systems onto the IS-04 data model.
From the main page for this Specification you can access the API definitions, which are written in RAML and JSON Schema, text documentation and examples.
You can also select a release of a version, the development branch for a version, or the GitHub repository for the Specification.
The full list of NMOS Specifications is here.
Note: JT-NM TR-1001-1 requires v1.2 or later
| Feature | v1.0 | v1.1 | v1.2 | v1.3 |
|---|---|---|---|---|
| Core functions including basic queries | x | x | x | x |
| Peer to peer mode (Optional from v1.3) | x | x | x | x |
| Basic connection management (Deprecated) | x | x | - | - |
| BCP-003-01 HTTPS and secure WebSockets | x | x | x | |
| Multiplexed Flows (ST.2022-6) | x | x | x | |
| Paged queries | x | x | x | |
| Advanced (RQL & ancestry) queries (Optional) | x | x | x | |
| Support for IS-05 connection management | x | x | ||
| Support for IS-07 and future transports | x | |||
| BCP-003-02 Authorization signalling | x |
Yes, Nodes are permitted to run differing versions of the specification provided the registry and any controllers are compatible with the full range of versions in operation. Please see the Upgrade Path for more details.
When building an IS-04 system, you may require one or more optional features of Nodes or Registries. The guide below is intended to indicate when these features may be required.
Note: This is an optional feature as of v1.3
Peer to peer mode enables an additional multicast DNS advertisement to be made directly from IS-04 Nodes. This provides the means for a basic control system (which may be integrated into a Node or separate) to discover IS-04 resources and other NMOS API endpoints without the need for a registry. Given the additional network traffic generated by mDNS and the number of requests required to gather data from Nodes individually, use of this mechanism is not recommended in systems which include more than a few tens of Nodes. More information
Note: This feature is deprecated as of v1.2 and optional as of v1.3
Prior to the existence of IS-05, the IS-04 specification provided the means to perform basic connection management for RTP multicast streams. This involves passing an SDP file to any IS-04 Receiver via an API resource. This mechanism is due to be removed in v2.0 and use of IS-05 instead is strongly recommended. More information
Note: This is a new optional feature as of v1.3
The IS-04 v1.2 specification requires Nodes to report their local network interface information in the /self resource. This has been extended in v1.3 to allow Nodes to report information about the peer network device for each interface. Adding this attached_network_device information is recommended, especially for media network interfaces, though it is not required since it needs LLDP support in the Node and the peer network device. It is required by JT-NM TR-1001-1.
This is a recommended feature for all IS-04 registries. It provides the means to return a limited subset of resources in response to a request, for example narrowing the 'Nodes' down by those which have a specific 'tag'. This can assist with scalability by ensuring that resource constrained clients do not have to handle all of the data presented by a registry if it is not relevant to them. More information
This is a recommended feature for IS-04 registries which support multiple API versions. It provides the means for a client which may operate at the maximal API version (for example v1.2) to gain access to lower versioned resources (for example v1.0) without making additional requests. This is important to ensure that large systems can transition between API versions and gain access to new features, without losing access to Nodes which do not yet support latest version of the specification. More information
This is a recommended feature for IS-04 registries which may be used at scale. It provides the means to limit the number of resources returned in a single API request, and allows a client to page through the list of resources available at its own pace. This is important to ensure that clients are not overwhelmed by data in large systems, and that registries are not over-burdened in returning large lists of results. More information
This is a recommended feature for IS-04 registries which may be used at scale. Much like basic queries, it provides the means for clients to narrow down the list of returned resources to only those which are of interest. This query mechanism is much more powerful than basic queries, permitting for example pattern matching in the returned results, and the use of logical operators such as 'and' and 'or'. More information
This is an advanced feature of IS-04 registries. It enables content to be tracked through a system as it progresses through numerous production operations. Content can be tracked in reverse (to indicate where it originated) or forwards (to indicate what new content is now forms part of). More information
NMOS is brought to you by the Advanced Media Workflow Association