Specifications by type¶
NMOS Interface Specifications (IS)¶
APIs defined with RAML, JSON Schema and normative text.
| Spec | Title | Themes | Status | Default branch | Release(s) |
|---|---|---|---|---|---|
| IS-04Discovery & RegistrationWhat does it do?• Allows control and monitoring applications to find the resources on a network• Resources include Nodes, Devices, Senders, Receivers, Sources, Flows...Why does it matter?• Enables automation and reduces manual overhead in setting up networked sytems• Essential for dynamic deploymentHow does it work?• Media Nodes locate IS-04 registry using DNS-SD (unicast preferred)• Media Nodes register their resource information with HTTP + JSON• Applications query with HTTP and/or subscribe with WebSocket | Discovery & Registration | RESOURCE, PRO-AV | AMWA Specification (Stable) | v1.3.x |
v1.3.3 ↓ v1.2.2 ↓ v1.1.3 ↓ |
| IS-05Device Connection ManagementWhat does it do?• Provides a transport-independent way of connecting Media Nodes• Supports RTP, WebSocket, MQTT and other transports via the Transports register• Supports single + bulk connections, immediate + delayed connectionsWhy does it matter?• ST 2110 does not specify how to do this• So without IS-05 there is a danger of multiple proprietary approaches• ...and difficulty in adopting new stream formats.• Provides support for new specifications• such as IS-07 event transportHow does it work?• Control application sends instructions to Media Nodes• transport_params conveys the connection information | Device Connection Management | CONNECTION, PRO-AV | AMWA Specification (Stable) | v1.2.x |
v1.2.0 ↓ v1.1.2 ↓ v1.0.2 ↓ |
| IS-06Network ControlWhat does it do?• IS-06 lets broadcast control applications manage what happens on the network itselfHow does it work?• Provides a “Northbound” API from network fabric’s controller• Includes topology discovery, flow authorization and assurances of flow bandwidth | Network Control | — | Deprecated | v1.0.x |
v1.0.1 ↓ |
| IS-07Event & TallyWhat does it do?• Provides an IP-friendly mechanism to carry time-sensitive information• For example: camera tally information, audio levels, control panel button presses and statusWhy does it matter?• ST 2110 does not provide an equivalent to GPI functionality• This leads to the danger of multiple proprietary approaches• Consistency with other NMOS specificationsHow does it work?• Media Nodes emit and consume state and state change info• Lightweight messages sent using WebSockets or MQTT• Message flows connected using IS-05 | Event & Tally | CONTROL | AMWA Specification | v1.0.x |
v1.0.1 ↓ |
| IS-08Audio Channel MappingWhat does it do?• Allows channel-level operations within NMOS environments• For example: muting channels, swapping languages…Why does it matter?• Provides expected functionality for typical production/broadcast operations• Extends usefulness of IS-05 and other NMOS specs.How does it work?• Controller gets channel information from sending Node• …and sends mapping information to the receiving Node• Can also do sender-side mapping | Audio Channel Mapping | CONNECTION, PRO-AV | AMWA Specification (Stable) | v1.0.x |
v1.0.1 ↓ |
| IS-09System ParametersWhat does it do?• Allows an NMOS Node (also known as a "Media Node") to obtain global configuration parameters that are common across the system.Why does it matter?• Enables the Node to start, or re-start, in a well defined way that is consistent with the environment it's running in.How does it work?• Defines the System API 'global configuration resource' and the expected behaviour for Nodes using it. | System Parameters | RESOURCE | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| IS-10AuthorizationWhat does it do?• Allows an API server to accept or reject requests depending on what a client is authorized to doWhy does it matter?• Security in the control plane is essential• Best practice is to limit what clients can doHow does it work?• Control client provides credentials and gets an access token• Sends token with API requests• Based on JSON Web Tokens and OAuth 2.0• Encryption is a prerequisite (see BCP-003-01) | Authorization | SECURITY | AMWA Specification | v1.0.x |
v1.0.1 ↓ |
| IS-11Stream Compatibility ManagementWhat does it do?• Introduces Inputs associated with Senders and Outputs associated with Receivers• Allows the configuration of media parameters of Senders and Inputs using information coming from Receivers and Outputs.Why does it matter?• State of a Sender can be tuned to be compatible with a corresponding Receiver or many compatible ReceiversHow does it work?• An endpoint on the side of Senders is introduced for media parameters control• Senders and Receivers are followed with endpoints which list Inputs and Outputs respectively and describe them in detail | Stream Compatibility Management | CONFIGURATION, PRO-AV | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| IS-12Control ProtocolWhat does it do?• Describes the specification for the NMOS Device Control & Monitoring Protocol.Why does it matter?• Sets out the rules and requirements for implementing the NMOS Device Control & Monitoring Protocol in devices and controllers.How does it work?• Describes a standard way of exposing NMOS Control models which can be consumed and interacted with. | Control Protocol | CONTROL, PRO-AV | AMWA Specification | v1.0.x |
v1.0.1 ↓ |
| IS-13AnnotationWhat does it do?• Allows control and monitoring applications to update resource labels, descriptions and tagsWhy does it matter?• Operators need to be able to distinguish between different resources• Often this is aided by user-provided information (beyond what is provided by the vendor through BCP-002-02)How does it work?• Media Nodes advertise it in their Node services | Annotation | RESOURCE | Work In Progress | v1.0-dev |
— |
| IS-14Device ConfigurationHow does it work?• It specifies an HTTP API for backing up an NMOS Nodes' MS-05-02 model as a JSON backup dataset.• The API can be used to restore that backup dataset to the NMOS Node.• The API can be used to change the structure of 'rebuildable' parts of the MS-05-02 model dynamically, if the NMOS Node allows. | Device Configuration | CONFIGURATION | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
NMOS Data Model Specifications (MS)¶
Models for the resources used in NMOS APIs.
| Spec | Title | Themes | Status | Default branch | Release(s) |
|---|---|---|---|---|---|
| MS-04ID & Timing ModelWhat does it do?• Documents a model for identity and timing that applies to AMWA NMOS specifications that apply to content• Builds on models of the JT-NM Reference ArchictureWhy does it matter?• Provides a basis for future specificationsHow does it work?• Defines the main time-related entities used in NMOS specs• Provides further explanation of their meaning• Gives guidance on how they can be used for media operations | ID & Timing Model | — | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| MS-05-01NMOS Control ArchitectureWhat does it do?• It defines the architecture for modelling various types of devices which interrelates with existing NMOS Specifications and the JT-NM Reference Architecture.Why does it matter?• The modelling system provides for the definition of device configuration, control and monitoring APIs using a set of published class definitions and operating rules.• The model includes the abilities for controllers to discover full device APIs in live systems, and to reconfigure devices dynamically (i.e. at run time).• In all cases, multiple simultaneous controllers are fully supported with no requirement for polling to maintain synchronization.How does it work?• It provides the architecture for control and monitoring class hierarchies and core mechanisms for building device control and monitoring APIs. | NMOS Control Architecture | CONTROL | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| MS-05-02NMOS Control FrameworkWhat does it do?• Describes the specification for using NMOS Control modelsWhy does it matter?• Sets out the rules and framework for building control models in NMOS devices.How does it work?• Model definitions and supporting documentation describe the way control models can be created. | NMOS Control Framework | CONTROL | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| MS-05-03AMWA NMOS Control Block SpecsWhat does it do?• Describes the specification for creating NMOS Control Blockspecs.Why does it matter?• Sets out the rules and requirements for creating Blockspec files which can be used by device manufacturers for implementation.How does it work?• Describes a uniform way of specifying block functionality and constraints for standardising feature sets. | AMWA NMOS Control Block Specs | — | Work In Progress | v1.0-dev |
— |
NMOS Best Common Practices (BCP)¶
Best practice for use of NMOS APIs.
| Spec | Title | Themes | Status | Default branch | Release(s) |
|---|---|---|---|---|---|
| BCP-002-01Natural GroupingWhat does it do?• Documents best practice and recommendations for how to indicate and handle "Natural Groups" of Resources in AMWA NMOS APIs.• These are those created by the default operation of a Node/Device, and not user- or automation-defined Groups.Why does it matter?• Provides a consistent way of referring to groups of related Resources (e.g. video and audio Senders of a camera)• This helps with interoperability and integration.How does it work?• Nodes add a grouphint tag to the JSON representation of each member of a Natural Group. | Natural Grouping | RESOURCE, PRO-AV | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-002-02Asset Distinguishing InformationWhat does it do?• It defines how to provide human-readable distinguishing information for NMOS Assets - Nodes and Devices.Why does it matter?• Inconsistent naming approaches across vendors and products can complicate configuration and operation.How does it work?• It defines tags for fixed information about Nodes and Devices.• These include Manufacturer, Product Name, Instance Identifier, and (for Devices only) Function. | Asset Distinguishing Information | RESOURCE, PRO-AV | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-003-01Secure Communications in NMOS SystemsWhat does it do?• Documents best practice for using secure transport for NMOS API communications.Why does it matter?• A secure control plane is essential.• Need to ensure encryption is sufficient.• These recommendations allow interoperability using widely adopted open technologies.How does it work?• Recommends using TLS 1.2 or better for HTTP and WebSocket messages.• Recommends cipher suites. | Secure Communications in NMOS Systems | SECURITY | AMWA Specification | v1.0.x |
v1.0.1 ↓ |
| BCP-003-02Authorization in NMOS SystemsWhat does it do?• Documents best practice for an API server to accept or reject requests depending on what a client is authorized to do.Why does it matter?• A secure control plane is essential.• Authorization limits what clients can do to what is allowed.• These recommendations allow interoperability using widely adopted open technologies.How does it work?• Recommends using AMWA IS-10 Authorization Specification• This specifies how client provides credentials and gets access tokens.• Encryption is a prerequisite (see BCP-003-01). | Authorization in NMOS Systems | SECURITY | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-003-03Certificate Provisioning in NMOS SystemsWhat does it do?• Documents best practice for automated provisioning of TLS Server Certificates to NMOS APIs.Why does it matter?• A secure control plane is essential.• Certificates are an important part of this, and automation makes their use practical.• These recommendations allow interoperability using widely adopted open technologies.How does it work?• Recommends behaviour, based on Enrollment over Secure Transport (RFC 7030)• Encryption is a prerequisite (see BCP-003-01). | Certificate Provisioning in NMOS Systems | SECURITY | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-004-01Receiver CapabilitiesWhat does it do?• Allows an IS-04 Receiver to express parametric constraints on the types of streams that it is capable of consumingWhy does it matter?• Controllers need to know whether a Receiver is capable of handling a specific Sender's stream before connecting the twoHow does it work?• Establishes an open Capabilities register in the NMOS Parameter Registers that lists specifications for parametric constraints (such as width, height, frame rate, number of channels, etc.)• Defines how a Receiver instantiates these Parameter Constraints to make up a list of acceptable Constraint Sets, within the IS-04 caps attribute• Defines how Controllers evaluate whether an IS-04 Sender satisfies these constraints, based on the target parameters specified for each constraint (such as IS-04 Flow attributes and SDP format-specific parameters) | Receiver Capabilities | CONNECTION, PRO-AV | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-004-02Sender CapabilitiesWhat does it do?• Allows an IS-04 Sender to express parametric constraints on the types of streams that it is capable of producingWhy does it matter?• Controllers need to know whether a Receiver is capable of handling the streams a Sender is capable of producing before connecting the two• Controllers need to know whether a Sender is capable of handling specific stream parameters before applying IS-11 active constraintsHow does it work?• Establishes an open Capabilities register in the NMOS Parameter Registers that lists specifications for parametric constraints (such as width, height, frame rate, number of channels, etc.)• Defines how a Sender instantiates these Parameter Constraints to make up a list of acceptable Constraint Sets, within the IS-04 caps attribute | Sender Capabilities | CONNECTION, PRO-AV | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-005-01EDID to Receiver Capabilities MappingWhat does it do?• Provides a scheme and guidelines for expressing EDID information via Receiver CapabilitiesWhy does it matter?• Receivers associated with Outputs that provide EDID may need to present its contents to ControllersHow does it work?• Describes how each EDID section is translated into Receiver Capabilities• Gives recommendations regarding taking certain EDID sections into account | EDID to Receiver Capabilities Mapping | PRO-AV | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-005-02NMOS Support for IPMX/HKEPWhat does it do?• Establishes a standardized mechanism for NMOS Senders and Receivers to declare support for HDCP over IP streaming using IPMX/HKEP (VSF TR-10-5).Why does it matter?• An NMOS Controller can verify that any Receiver is compliant with a Sender producing HDCP-encrypted streams, as only IPMX/HKEP-compliant Receivers can process such content.• A standardized framework enables Controllers to systematically verify and/or enforce compliance.How does it work?• Documents how IPMX/HKEP capabilities are announced by both Senders and Receivers.• Explains how to constrain a Sender’s IPMX/HKEP capability.• Outlines the requirements for Senders, Receivers, and Controllers regarding the IPMX/HKEP feature. | NMOS Support for IPMX/HKEP | PRO-AV | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-005-03NMOS Support for IPMX/PEPWhat does it do?• Establishes a standardized mechanism for NMOS Senders and Receivers to declare support for Privacy-encrypted streaming using IPMX/PEP (VSF TR-10-13).Why does it matter?• An NMOS Controller can verify that any Receiver is compliant with a Sender producing Privacy-encrypted streams, as only IPMX/PEP-compliant Receivers can process such content.• A standardized framework enables Controllers to systematically verify and/or enforce compliance.How does it work?• Documents how IPMX/PEP capabilities are announced by both Senders and Receivers.• Outlines the requirements for Senders, Receivers, and Controllers regarding the IPMX/PEP feature. | NMOS Support for IPMX/PEP | PRO-AV | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-006-01NMOS With JPEG XSWhat does it do?• Enables Registration, Discovery, and Connection Management of JPEG XS Endpoints using the AMWA IS-04 and IS-05 NMOS Specifications.Why does it matter?• It helps ensure consistency between implementations offering NMOS control for JPEG XS endpoints.How does it work?• It specifies what resources and attributes MUST be provided when using NMOS with JPEG XS streams.• It specifies requirements for SDP files.• It provides examples of how to use IS-04 and IS-05 in the context of JPEG XS streams - specifically JPEG XS encapsulated in RTP as described in IETF RFC 9134. | NMOS With JPEG XS | CONNECTION, PRO-AV | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-006-02NMOS With H.264What does it do?• Enables Registration, Discovery, and Connection Management of H.264 Endpoints using the AMWA IS-04, IS-05 and IS-11 NMOS Specifications.Why does it matter?• It helps ensure consistency between implementations offering NMOS control for H.264 endpoints.How does it work?• It specifies what resources and attributes MUST be provided when using NMOS with [H.264][] streams.• It specifies requirements for SDP when it is used with a transport supporting SDP transport files.• It provides examples of how to use IS-04, IS-05 and IS-11 in the context of H.264 streams - specifically H.264 encapsulated in RTP as described in IETF [RFC 6184][RFC-6184]. It also describe to some extent how to use H.264 with RTP and other transports that encapsulate the H.264 video streams in an MPEG2-TS transport stream. | NMOS With H.264 | CONNECTION | Work In Progress | v1.0-dev |
— |
| BCP-006-03NMOS With H.265What does it do?• Enables Registration, Discovery, and Connection Management of H.265 Endpoints using the AMWA IS-04, IS-05 and IS-11 NMOS Specifications.Why does it matter?• It helps ensure consistency between implementations offering NMOS control for H.265 endpoints.How does it work?• It specifies what resources and attributes MUST be provided when using NMOS with [H.265][] streams.• It specifies requirements for SDP when it is used with a transport supporting SDP transport files.• It provides examples of how to use IS-04, IS-05 and IS-11 in the context of H.265 streams - specifically H.265 encapsulated in RTP as described in IETF [RFC 7798][RFC-7798]. It also describe to some extents how to use H.265 with RTP and other transports that encapsulate the H.264 video streams in an MPEG2-TS transport stream. | NMOS With H.265 | CONNECTION | Work In Progress | v1.0-dev |
— |
| BCP-006-04NMOS Support for MPEG Transport StreamsWhat does it do?• Enables Registration, Discovery, and Connection Management of MPEG TS Endpoints using the AMWA IS-04 and IS-05 NMOS Specifications.Why does it matter?• It creates a set of requirements for interoperable implementations offering the Discovery and Connection Management of MPEG TS endpoints.How does it work?• It specifies what resources and attributes MUST be provided when using NMOS with MPEG TS streams.• MPEG TS streams are considered as mux format, and this specification does not consider streams within the multiplex.• It provides examples of how to use IS-04 and IS-05 in the context of MPEG TS streams with RTP transport, such as VSF TR-01 and VSF TR-07 | NMOS Support for MPEG Transport Streams | CONNECTION | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-007-01NMOS With NDIWhat does it do?• Enables Registration, Discovery, and Connection Management of NDI endpoints using the AMWA IS-04 and IS-05 NMOS Specifications.• Specifies the interaction of NMOS-enabled NDI nodes and non-NMOS NDI nodes.Why does it matter?• It allows NDI endpoints and gateways to integrate in an NMOS-managed control environment.How does it work?• It specifies how NDI senders and receivers are defined within the scope of IS-04 and IS-05• It specifies how NDI receivers can be connected to NMOS NDI senders or native NDI senders• It defines the representation of muxed NDI flows of video, audio and metadata | NMOS With NDI | CONNECTION | Work In Progress | v1.0-dev |
— |
| BCP-007-02NMOS Support for IPMX/USBWhat does it do?• Establishes a new IS-05 transport for NMOS Senders and Receivers implementing USB over IP and allows Controllers to establish compatible connections.• Establishes a standardized mechanism for NMOS Senders and Receivers to declare support for USB over IP transport streams using IPMX/USB (VSF TR-10-14).Why does it matter?• An NMOS Controller can verify that any Receiver is compliant with a Sender producing USB over IP transport streams, as only IPMX/USB-compliant Receivers can process such content.• A standardized framework enables Controllers to systematically verify and/or enforce compliance.How does it work?• Documents how IPMX/USB capabilities are announced by both Senders and Receivers.• Outlines the requirements for Senders, Receivers, and Controllers regarding the IPMX/USB feature. | NMOS Support for IPMX/USB | CONNECTION, PRO-AV | Work In Progress | v1.0-dev |
— |
| BCP-007-03NMOS Support for MXLWhat does it do?• Establishes a new IS-05 transport for NMOS Senders and Receivers implementing MXL and allows Controllers to establish compatible connections.• Establishes a standardized mechanism for NMOS Senders and Receivers to declare support for MXL.Why does it matter?• An NMOS Controller can connect compatible MXL Receivers to MXL Senders.How does it work?• Documents how MXL capabilities are announced by both Senders and Receivers.• Outlines the requirements for Senders, Receivers, and Controllers regarding MXL support. | NMOS Support for MXL | CONNECTION | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-008-01NMOS Receiver Status MonitoringWhat does it do?• It provides a standard way of monitoring the statuses of ReceiversWhy does it matter?• It offers standard models for minimum status reporting• It provides guidance, sets out expectations and requirements for receiver status monitoringHow does it work?• It documents the standard models Devices have to use in order to offer receiver status monitoring• It lists the prerequisites and dependencies in terms of NMOS specifications• It describes the status monitoring domains along with expectations, behaviour and conformance requirements | NMOS Receiver Status Monitoring | CONTROL, PRO-AV | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
| BCP-008-02NMOS Sender Status MonitoringWhat does it do?• It provides a standard way of monitoring the statuses of SendersWhy does it matter?• It offers standard models for minimum status reporting• It provides guidance, sets out expectations and requirements for sender status monitoringHow does it work?• It documents the standard models Devices have to use in order to offer sender status monitoring• It lists the prerequisites and dependencies in terms of NMOS specifications• It describes the status monitoring domains along with expectations, behaviour and conformance requirements | NMOS Sender Status Monitoring | CONTROL, PRO-AV | AMWA Specification | v1.0.x |
v1.0.0 ↓ |
NMOS Informative Documents (INFO)¶
Implementation guides and background information.
| Spec | Title | Themes | Status | Default branch | Release(s) |
|---|---|---|---|---|---|
| INFO-002Security Implementation GuideWhat does it do?• It's a guide for implementers who want to add security to their NMOS Nodes and/or NMOS Controllers, according to the IS-10, BCP-003-01, BCP-003-02 and BCP-003-03 specifications.• Please note that this guide is informative and therefore is not a substitute for reading the normative specifications.Why does it matter?• This guide makes the job of adding security to your NMOS implementations easier.How does it work?• It details what you need to know, and the steps you need to take when implementing security.• It also mentions some tools to help in your implementation. | Security Implementation Guide | SECURITY | AMWA Specification | main |
— |
| INFO-004Implementation Guide for DNS-SDWhat does it do?• Explains the use of DNS-SD in NMOS environments.• Provides a practical "how-to" example of how to set up a BIND9 DNS server for NMOS use.• Gives example configurations for other DNS servers.Why does it matter?• DNS Service Discovery (DNS-SD) provides a simple and flexible method to discover NMOS Registration and Discovery Server (RDS) Services.• The NMOS RDS provides information about NMOS nodes, devices, and APIs. There must be a common way to locate the RDS in order for an NMOS component to register itself for discovery by other NMOS components.How does it work?• The fact that the DNS server provides Service Discovery• Where the NMOS RDS may be found on the network | Implementation Guide for DNS-SD | RESOURCE | AMWA Specification | main |
— |
| INFO-005Implementation Guide for NMOS ControllersWhat does it do?• It is a guide for implementers of Controllers who want to support the NMOS suite of specifications.• It defines the role of an NMOS Controller.• It describes the requirements of an NMOS Controller with respect to each of the NMOS specifications, together with implementation guidance where appropriate.Why does it matter?• This guide makes adding NMOS support to Controllers easier by providing clear guidance on which parts of the specifications are relevant.How does it work?• It is divided into sections that explain the expectations of an NMOS Controller with respect to each NMOS Specification.• It provides references to the relevant sections of the NMOS specifications where the normative language can be found.• It provides additional guidance to implementers where appropriate. | Implementation Guide for NMOS Controllers | RESOURCE, CONNECTION, SECURITY | AMWA Specification | main |
— |
| INFO-006Implementation guide for NMOS Device Control & MonitoringWhat does it do?• It guides the reader through some of the most important aspects when implementing a compliant AMWA IS-12, BCP-008 device or controller.Why does it matter?• It provides an easy way of navigating the NMOS Device Control & Monitoring suite when attempting to create a compliant device or controller implementation.How does it work?• It provides tutorials and How-To examples to assist with implementing a compliant AMWA IS-12, BCP-008 device or controller. | Implementation guide for NMOS Device Control & Monitoring | CONTROL | AMWA Specification | main |
— |
NMOS Registers & Feature Sets¶
Parameter registers and control feature sets.
| Spec | Title | Themes | Status | Default branch | Release(s) |
|---|---|---|---|---|---|
| NMOS-PARAMETER-REGISTERSParameter RegistersWhat does it do?• Lists constants for many types of parameter values used in NMOS specifications• Defines procedures for updating theseWhy does it matter?• Supports extensibility of NMOS• Promotes interoperability by ensuring common definitions can be shared easilyHow does it work?• Each type of parameter has a register, listed on this site• In most parameter registers, values are specified as urn:x-nmos:<type>:<value>[/<version>]• Updates are proposed and reviewed using GitHub pull requests (PRs) | Parameter Registers | — | Continuing | main |
— |