JT-NM Tested August 2022
NMOS/TR-1001-1 Media Nodes,
Registries and Controllers
Results Catalog

Joint Task Force on Networked Media“JT-NM Tested Program August 2022””JT-NM Tested Program August 2022”
NMOS/TR-1001-1 Results Catalog
Abstract and motivation behind the program
The JT-NM Tested program offers documented insight into how vendor equipment conforms tospecific SMPTE standards and AMWA NMOS specifications. Vendors who meet the testing criteria
will have the opportunity to display badges and make public statements about their participation.
The JT-NM Tested Catalog lists vendor results along with a detailed test plan. Anyone with theequipment listed in the test plan may execute the tests which were administered by the JT-NM test
team, and you are encouraged to do so.
It is important to note that the JT-NM Tested program is not a certification program; rather, it is asnapshot in time of how vendor equipment conforms to key parts of SMPTE standards and AMWA
NMOS specifications.

Notation used in the document
JT-NM Tested Catalog results are presented as a capability map. This allows readers, especiallyend users, to focus on the capabilities demonstrated by devices during the JT-NM Tested event.
JT-NM Catalogs use the following terms to characterize test results:
Capable (green mark):
A test item marked as ‘Capable’ means a device has demonstrated a capability that was required
as part of a test listed in a JT-NM Tested Test Plan.
Capability not Demonstrated (no mark):
A test item marked as ‘Capability not Demonstrated’ means that a device did not demonstrate acapability that was required as part of a test listed in a JT-NM Tested Test Plan. Examples of why acapability might not have been demonstrated include: the test was not applicable to this type ofdevice (e.g., an audio-only device has no video capability), the device could not demonstratecapabilities that met the requirements of that test, the functionality was not implemented by design,
the vendor requested that the capability not be tested, the capability could not be tested.

JT-NM Tested August 2022 – NMOS/TR-1001-1 Testing Results

SDI IP Gateway

SDI-IP, IP-SDI Gateway

V3.5

V3.5

v1.3 v1.1 Tx/Rx Fullarkona technologies

at300

IP gateway, video and audio processing

n/a

2.1.52v1.2 v1.1 Tx/Rx FullBFE

KSC CORE

Broadcast Controller / NMOS-IS07

n/a

16.3

v1.3 v1.1 Tx/Rx Other

Calrec Audio Ltd

Fixed Format IO Box

Baseband Audio to ST2110-30 IP Convertor

SU6529IO 2.2.18

v1.3 v1.1 Tx/Rx Audio Only

Calrec Audio Ltd

Impulse Core

ST2110-30 IP Audio Router and Mixing Console

RY6427-8

Impulse 2.2.25

v1.3 v1.1 Tx/Rx Audio Only

Calrec Audio Ltd

Modular IO Box

Baseband Audio to ST2110-30 IP Convertor

UJ6429IO 2.2.18

v1.3 v1.1 Tx/Rx Audio Only

Calrec Audio Ltd

Type R Core

ST2110-30 IP Audio Router and Mixing Console

US6493-2

Type R 2.2.17

v1.3 v1.1 Tx/Rx Audio Only

Calrec Audio Ltd

Type R IO Box

Baseband Audio to ST2110-30 IP Convertor

US6525-2

IO 2.2.18

v1.3 v1.1 Tx/Rx Audio Only

Cobalt Digital

Indigo 2110-DC-01

IP Gateway and Processing

B

1.1.2

v1.3 v1.1 Tx/Rx Full

Evertz

670-X19

Virtualized Media Processing Platform

670IPG

590-L

v1.3 v1.1 Tx/Rx Full

Evertzev670-X30

Virtualized Media Processing Platform

ev670

1218-L

v1.3 v1.1 Tx/Rx Full

EvertzScorpion

Smart Media Processing Platform

Scorpion-X18

b126

v1.3 v1.1 Tx/Rx Full

EVS Broadcast Equipment SA Neuron

Network Attached Processor

0.2

5.4.1

v1.3 v1.1 Tx/Rx Full

EVS Broadcast Equipment SA XT-VIALive Production Server

6.3

20.3.21v1.2 v1.0 Tx/Rx Full

Grass Valley

LDX 150

CameraLDX 150

16.0

v1.3 v1.1 Tx/Rx Full

Grass ValleyXCU UNIVERSE UXF

Base StationXCU UNIVERSE UXF 20.0

v1.3 v1.1 Tx/Rx Full

Grass Valley

AMPP Edge

2110 (Tx/Rx)

N/A

1.2.17v1.2 v1.0 Tx/Rx Full

Imagine Communications

Selenio Network Processor (SNP)SDI-IP, IP-SDI Gateway

V1.0

2.1.2.12

v1.2 v1.0 Tx/Rx Full

Leader Electronics Corp.

LV5600

SDI / IP Waveform monitor

LV56006.3

v1.2 v1.0 Tx/Rx Full

Macnica

EASYSS10

SDI to ST2110 Gateway

EASYSS10

3.4.1

v1.3 v1.1 Tx/Rx Full

Macnica

M2S

ST2110 streaming library SDK

n/a

2.0.0

v1.3 v1.1 Tx/Rx Full

Matrox

VERO

ST2110 Reference Sender/Capture

1.0

1.3

v1.3 v1.1 Tx/Rx Full

Merging Technologies

Anubis - ZMAN platform

Audio Gateway2

1.4

v1.2 v1.0 Tx/Rx Audio Only

NEC Corporation

HD-IPO

IntegratedPlayoutServer

1.2.1.34

1.2.1.17

v1.3 v1.1 Tx/Rx Full

NevionVirtuoso

IP Media processing node/gateway

1.0

1.7.4

v1.2 v1.0 Tx/Rx Full

NVIDIA

Rivermax 1.20

ST 2110 Narrow Tx/Rx using COTS NIC

n/a

1.20

v1.3 v1.1 Tx/Rx Full

Panasonic Connect

AK-NP600 10G MoIP Board for AK-UCU600

Camera Control Unit for Studio Camera Systemn/a13.1C-000-01.4F

v1.3 v1.1 Tx/Rx Full

Panasonic Connect

KAIROS AT-KC100

Live Video Production Platform

n/a

1.2.3

v1.3 v1.1 Tx/Rx Full

Panasonic Connect

KAIROS AT-KC1000

Live Video Production Platform

n/a

1.2.3

v1.3 v1.1 Tx/Rx Full

PebbleIntegrated Channel

Playout Server

1

2.2.1

v1.3 v1.1 Tx/Rx Full

PHABRIXQxL (Tx/Rx)

SDI/IP Rasterizer

n/a

4.7

v1.3 v1.1 Tx/Rx Full

Riedel Communications

Artist AES67 Card AES67-108 G2

AES67 4-Wires In/Out for Intercom Frame

n/a

8.3

v1.3 v1.1 Tx/Rx Audio Only

Riedel Communications

Artist AES67 Card UIC-128

AES67 4-Wires In/Out for Intercom Frame

n/a

8.3

v1.3 v1.1 Tx/Rx Audio Only

Riedel Communications

MN-FusioN-3-B

ST2110-SDI Gateway

400

4.0

v1.2 v1.0 Tx/Rx Full

Riedel Communications

MN-FusioN-6-B

ST2110-SDI Gateway

400

4.0

v1.2 v1.0 Tx/Rx Full

Riedel Communications

MuoN B

ST2110-SDI Gateway

400

4.0

v1.2 v1.0 Tx/Rx Full

Ross

BACH Liberty

OEM AES67 Gateway Module

0.6.2

4.2.23v1.3 v1.1 Tx/Rx Audio Only

Ross

BACH Minuet

OEM AES67 Gateway SoC

0.6.2

4.2.23v1.3 v1.1 Tx/Rx Audio Only

Ross

BACH openModule OM512

OEM AES67 Gateway Modulen/a1.0.19v1.3 v1.1 Tx/Rx Audio Only

Ross

IGGY-MADI

AES67 - MADI Point-of-use gateway

n/a

2.0

v1.3 v1.1 Tx/Rx Audio Only

Ross

Newt

2110 - SDI/HDMI Point-of-use gateway

n/a

5.0a

v1.3 v1.1 Tx/Rx Full

Ross

Ultrix-IP-IO

12G Router / IP Gateway

n/a

4.8.1

v1.3 v1.1 Tx/Rx FullSony

NXLK-IP50Y series

SDI-IP Gateway (Sony's ST2110/NMOS Core implementation)

NXLK-IP50Y

3.12

v1.3 v1.1 Tx/Rx Full

TAG

MCM-9000

n/a

5.7.9

v1.3 v1.1 Tx/Rx Fullvizrt

VizEngine

Character Generator/Render Engine

n/a

5.0.0

v1.3 v1.1 Tx/Rx Full

Adeas/Nextera

HDMI IP Gateway

HDMI-IP JPEG-XS Encoder Gateway

V1.0

V1.0

v1.3 v1.1 Tx

Video Only

AppearECx210 Decoder

HEVC decoder with ST2110 output

3.17781.14.1v1.3 v1.1 Tx

FullMatroxConvertIP DSS-TX

ST 2110-22 Sender

3.0

1.01

v1.3 v1.1 Tx

FullMediaKind

RX1

ST2110 sender

n/a

v14

v1.3 v1.1 Tx

Full

PHABRIXSxTAG (Encap)

SDI/IP Handheld Waveform Monitor

n/a

2.01

v1.2 v1.0 Tx

Full

SencoreMRD 7000

4K/4HD Decoder with ST2110 output

n/a1593-G7C5B446F v1.3 v1.1 Tx

Full

Sumavision

S010

Baseband Live Processor (Tx)

V1.1

V1.0.1v1.3 v1.1 Tx

Full

Village Island

VICO-4L-ST2110 Encoder

4K /4HD ST2110 Encapsulator

4.1

v0.6.2.7

v1.3 v1.1 Tx

Full

Village Island

VICO-4L-XS-IP Encoder

4K JPEG-XS ST2110 Encoder Encap

4.0

v0.6.6.1

v1.3 v1.1 Tx

Full

Adeas/Nextera

IP HDMI Gateway

IP-HDMI JPEG-XS Decoder Gateway

V1.0

V1.0

v1.3 v1.1 Rx

Video Only

AppearECx210 Encoder

HEVC encoder with ST2110 input

3.1726

1.14.1v1.3 v1.1 Rx

Full

Bridge Technologies

VB440

IP Monitor and Generator

MK3

6.0.2

v1.3 v1.1 Rx

Full

Georg Neumann GmbHKH 150 AES67

DSP-controlled studio monitor with redundant AES67

KH150.2022

4.2.23v1.3 v1.1 Rx

Audio Only

Georg Neumann GmbHKH 750 AES67

DSP-controlled subwoofer with redundant AES67

KH750.2021

4.2.23v1.3 v1.1 Rx

Audio Only

MatroxConvertIP DSH-RX

ST 2110-20/-22 Receiver

3.0

1.01

v1.3 v1.1 Rx

Full

MatroxConvertIP DSS-RX

ST 2110-20/-22 Receiver

3.0

1.01

v1.3 v1.1 Rx

Full

PHABRIX

Qx (Rx)SDI/IP Rasterizer

n/a

4.7

v1.3 v1.1 Rx

Full

PHABRIXSxTAG (Decap)

SDI/IP Handheld Waveform Monitor

n/a

2.01

v1.2 v1.0 Rx

Full

Riedel Communications

Audio Monitoring App

AES67 Monitoring on a RSP-1216 panel

n/a

1.0

v1.3 v1.1 Rx

Audio Only

Sumavision

S010

Baseband Live Processor (Rx)

V1.1

V1.0.1v1.3 v1.1 Rx

Full

Telestream

Inspect 2110

IP Video Monitor

v1.0

4.0.1-28

v1.3 v1.1 Rx

Full

Telestream

PRISM MPD300

SDI/IP Waveform Monitor

MMC25 revB

3.3.1

v1.3 v1.1 Rx

Full

Telestream

PRISM MPI2-25

SDI/IP Waveform Monitor

MMC25 revA

3.3.1

v1.3 v1.1 Rx

Full

Telestream

PRISM MPS300

SDI/IP Waveform Monitor

MMC25 revB

3.3.1

v1.3 v1.1 Rx

Full

Village Island

VICO-4L-ST2110 Decoder

4K /4HD ST2110 Decapsulator

4.1

v0.7.2.8

v1.3 v1.1 Rx

Full

Village Island

VICO-4L-XS-IP Decoder

4K JPEG-XS ST2110 Decoder Decap

4.0

v0.7.8.9

v1.3 v1.1 Rx

Full

vizrt

ChannelRecorder

File Capture Device

n/a

2.1.0

v1.3 v1.1 Rx

Full

LEGEND
Green square = Capable
White square = Capability not demonstrated

A.3 Node API & Registration Behaviour (IS-04)

Unicast Discovery test_02: Node can discover
network registration service via unicast DNS

test_25: Receivers expose expected 'caps' for their API
version (Rx only)

test_26: Source 'format' matches Flow 'format'(Tx only)

test_24_01: Periodic Flows' 'grain_rate' is divisible bytheir parent Source 'grain_rate' (Tx only)

test_24: Periodic Sources specify a 'grain_rate'(Tx only)

test_20_01: Sender manifests use the expected
Content-Type (Tx only)

test_23: Senders and Receivers correctly use BCP-00201 grouping syntax

test_20: Node's resources correctly signal the current
protocol and IP/hostname

test_19: All Node interfaces are unique, and relate toany visible Senders and Receivers' interface_bindings

test_18: All Node clocks are unique, and relate to any
visible Sources' clocks

A.3.3

test_17: All Node resources use different UUIDs

Basic Node API Behaviour

OPTIONS /x-nmos/node/v1.x/receivers/{receiverId}/target (auto_node_10) (Rx only, v1.3 only)

GET /x-nmos/node/v1.x/receivers/{receiverId}(auto_node_9) (Rx only)

GET /x-nmos/node/v1.x/sources/{sourceId}(auto_node_15) (Tx only)

GET /x-nmos/node/v1.x/senders/{senderId}(auto_node_13) (Tx only)

GET /x-nmos/node/v1.x/flows/{flowId}(auto_node_7) (Tx only)

GET /x-nmos/node/v1.x/{invalidPath} (404)(auto_node_16)

GET /x-nmos/node/v1.x/sources (auto_node_14)

GET /x-nmos/node/v1.x/senders (auto_node_12)

GET /x-nmos/node/v1.x/self (auto_node_11)

GET /x-nmos/node/v1.x/receivers (auto_node_8)

GET /x-nmos/node/v1.x/flows (auto_node_6)

GET /x-nmos/node/v1.x/devices/{deviceId}(auto_node_5)

GET /x-nmos/node/v1.x/devices (auto_node_4)

GET /x-nmos/node/v1.x (auto_node_3)

GET /x-nmos/node (auto_node_2)

A.3.2

GET /x-nmos (auto_node_1)

Schema Conformancetest_09: Server exposes a valid chain of trust including
a certificate and intermediate

test_08: Server exposes both an RSA and ECDSA
certificate

A.3.1

test_07: Certificate is valid and matches the hostunder test

test_06: OCSP Stapling

test_05: Certificate revocation method is available

test_04: HSTS Header

test_02: TLS Ciphers

test_01: TLS Protocols

A.1.2.5 LLDP Port IDs are unique across Node1.2.4 Media LLDP matches interface MAC

A.1.2.3 Media LLDP TLVs present

1.2.2 Management LLDP matches interface MAC

A.1.2.1 Management LLDP TLVs present

LLDP

A.1.1.4 Media Ping

A.1.1.3 Media IP Addressing

A.1.1.2 Management Ping

DHCP

A.1.1.1 Management IP Addressing

Full, Audio Only, Video only

Tx/Rx, Tx, Rx

IS-05 Version

IS-04 Version

SW Version

Adeas/Nextera

A.2 Secure Communication

A.1.2

test_03: Certificate does not use IP addresses in
CN/SANs

A.1 Startup Behaviour

A 1.1

HW Version

Type of Product/ Functional Description

Device Under Test Details

Model

Vendor Name

Device Under Test

Page 1

Adeas/Nextera

arkona technologies
at300

BFE
KSC CORE

Calrec Audio Ltd
Fixed Format IO Box

Calrec Audio Ltd
Impulse Core

Calrec Audio Ltd
Modular IO Box

Calrec Audio Ltd
Type R Core

Calrec Audio Ltd
Type R IO Box

Cobalt Digital
Indigo 2110-DC-01

Evertz
670-X19

Evertzev670-X30

EvertzGrass Valley
Scorpion

LDX 150

Grass ValleyXCU UNIVERSE UXFGrass Valley
AMPP Edge

Imagine Communications
Selenio Network Processor (SNP)

Leader Electronics Corp.
LV5600Macnica
EASYSS10

Macnica
M2S

Matrox
VERO

Merging Technologies
Anubis - ZMAN platform

NEC Corporation
HD-IPO

NevionVirtuoso

NVIDIA
Rivermax 1.20

Panasonic Connect
AK-NP600 10G MoIP Board for AK-UCU600

Panasonic Connect
KAIROS AT-KC100

Panasonic Connect
KAIROS AT-KC1000

PebbleIntegrated Channel

PHABRIXQxL (Tx/Rx)

Riedel Communications
Artist AES67 Card AES67-108 G2

Riedel Communications
Artist AES67 Card UIC-128

Riedel Communications
MN-FusioN-3-B

Riedel Communications
MN-FusioN-6-B

Riedel Communications
MuoN B

Ross
BACH Liberty

Ross
BACH Minuet

Ross
BACH openModule OM512

Ross
IGGY-MADI

Ross
Newt

Ross
Ultrix-IP-IOSony
NXLK-IP50Y series

TAG
MCM-9000

vizrt
VizEngine

Adeas/Nextera

AppearECx210 Decoder

MatroxConvertIP DSS-TX

MediaKind
RX1

PHABRIXHDMI IP Gateway

SxTAG (Encap)

SencoreMRD 7000

Sumavision
S010

Village Island
VICO-4L-ST2110 Encoder

Village Island
VICO-4L-XS-IP Encoder

Adeas/Nextera
IP HDMI Gateway

AppearECx210 Encoder

Bridge Technologies
VB440

Georg Neumann GmbHKH 150 AES67

Georg Neumann GmbHKH 750 AES67

MatroxConvertIP DSH-RX

MatroxConvertIP DSS-RX

PHABRIX
Qx (Rx)PHABRIXSxTAG (Decap)

Riedel Communications
Audio Monitoring App

Sumavision
S010

Telestream
Inspect 2110

Telestream
PRISM MPD300

Telestream
PRISM MPI2-25

Telestream
PRISM MPS300

Village Island
VICO-4L-ST2110 Decoder

Village Island
VICO-4L-XS-IP Decoder

vizrt
ChannelRecorder

LEGEND
Green square = Capable
White square = Capability not demonstrated
A.4.1
test_42: Transport files use the expected ContentType (Tx only)

test_41: SDP transport files pass SDPoker tests(Tx only)

test_38: Number of legs matches on constraints,
staged and active endpoint for senders (Tx only)

test_25: Immediate activation of a sender is possible(Tx only)

test_23_01: Senders accept a patch request withempty leg(s) in transport parameters (Tx only)

test_23: Sender transport parameters are changeable(Tx only)

test_22: Receiver id on staged sender is changeable(Tx only)

test_19: Sender invalid patch is refused (Tx only)

test_17: Sender patch response schema is valid (Tx
only)

A.4.2
test_15: Staged parameters for senders comply withconstraints (Tx only)

A.4 Connection Management (IS-05)

Single Sender Routing

test_32: Receiver active response schema is valid (Rxonly)

test_14: Return of/single/receivers/{receiverId}/staged/ meets theschema (Rx only)

test_12_01: Receiver /active parameters do not use
the keyword 'auto' (Rx only)

test_12: Receiver are using valid combination ofparameters (Rx only)

test_10: All params listed in/single/receivers/{receiverId}/constraints/ matches/staged/ and /active/ (Rx only)

test_31: Sender active response schema is valid(Tx only)

test_13: Return of/single/senders/{senderId}/staged/ meets theschema (Tx only)

test_11_02: Patched 'auto' values are translated on‘/active’ endpoint for all receivers (Tx only)

test_11_01: Sender /active parameters do not use the
keyword 'auto' (Tx only)

test_11: Senders are using valid combination ofparameters (Tx only)

test_09: All params listed in/single/senders/{senderId}/constraints/ matches/staged/ and /active/ (Tx only)
test_09_01: All params listed in/single/senders/{senderId}/active/ match theircorresponding SDP files (Tx only)

test_40: Only valid transport types for a given API
version are advertised

Basic Connection API Behaviour

OPTIONS /xnmos/connection/v1.x/single/receivers/{receiverId}/staged (auto_connection_13)(Rx only, v1.1 only)
GET /xnmos/connection/v1.1/single/receivers/{receiverId}/transporttype (auto_connection_14) (Rxonly, v1.1 only)

GET /xnmos/connection/v1.x/single/receivers/{receiverId}/staged (auto_connection_12) (Rx only)

GET /xnmos/connection/v1.x/single/receivers/{receiverId}/constraints (auto_connection_11)(Rx only)

GET /xnmos/connection/v1.x/single/receivers/{receiverId}/active (auto_connection_10) (Rx only)

GET /xnmos/connection/v1.x/single/receivers/{receiverId} (auto_connection_9) (Rx only)

GET /xnmos/connection/v1.1/single/senders/{senderId}/transporttype (auto_connection_21)(Tx only, v1.1 only)

OPTIONS /xnmos/connection/v1.x/single/senders/{senderId}/staged (auto_connection_20)(Tx only, v1.1 only)

GET /xnmos/connection/v1.x/single/senders/{senderId}/staged (auto_connection_19) (Tx only)

GET /xnmos/connection/v1.x/single/senders/{senderId}/constraints (auto_connection_18)(Tx only)

GET /xnmos/connection/v1.x/single/senders/{senderId}/active (auto_connection_17) (Tx only)

GET /x-nmos/connection/v1.x/single/senders/{senderId} (auto_connection_16) (Tx only)

OPTIONS /x-nmos/connection/v1.x/bulk/senders(auto_connection_6) (v1.1 only)

OPTIONS /x-nmos/connection/v1.x/bulk/receivers(auto_connection_5) (v1.1 only)

GET /x-nmos/connection/v1.x/{invalidPath} (404)(auto_connection_22)

GET /x-nmos/connection/v1.x/single/senders(auto_connection_15)

GET /x-nmos/connection/v1.x/single/receivers(auto_connection_8)

GET /x-nmos/connection/v1.x/single(auto_connection_7)

GET /x-nmos/connection/v1.x/bulk(auto_connection_4)

GET /x-nmos/connection/v1.x (auto_connection_3)

GET /x-nmos/connection (auto_connection_2)

GET /x-nmos (auto_connection_1)

A.3.6

Schema Conformance

A.3.5

Consistency of UUIDs

test_16_01: Node correctly handles Registration APIs
whose connections time out

test_16: Node correctly fails over between advertised
Registration APIs when one fails

test_15: Node correctly selects a Registration API
based on advertised priorities

test_02_01: Node does not attempt to register with anunsuitable unicast DNS Registry

A.3 Node API & Registration Behaviour (IS-04)

Advanced Registration

test_11_01: Registered Receiver was POSTed after amatching referenced Device (Rx only)

test_11: Node can register a valid Receiver resourcewith the network registration service, matching its
Node API Receiver resource (Rx only)

test_10_01: Registered Sender was POSTed after amatching referenced Device (Tx only)

test_10: Node can register a valid Sender resourcewith the network registration service, matching its
Node API Sender resource (Tx only)

test_09_01: Registered Flow was POSTed after amatching referenced Device or Source (Tx only)

test_09: Node can register a valid Flow resource with
the network registration service, matching its Node
API Flow resource (Tx only)

test_08_01: Registered Source was POSTed after amatching referenced Device (Tx only)

A.3.4

test_08: Node can register a valid Source resourcewith the network registration service, matching its
Node API Source resource (Tx only)

test_21: Node correctly interprets a 200 code from a
registry upon initial registration

test_07_01: Registered Device was POSTed after amatching referenced Nodetest_07: Node can register a valid Device resourcewith the network registration service, matching its
Node API Device resource

test_05: Node maintains itself in the registry via
periodic calls to the health resource

test_04: Node can register a valid Node resource with
the network registration service, matching its Node
API self resource

test_03_01: Registration API interactions use thecorrect versioned path

test_03: Registration API interactions use the correct
Content-Type

Device Under Test

Basic Registration

Model

Vendor Name

JT-NM Tested August 2022 – NMOS/TR-1001-1 Testing Results

A.4.3

SDI IP Gateway

EVS Broadcast Equipment SA Neuron

EVS Broadcast Equipment SA XT-VIA

Page 2

Adeas/Nextera

arkona technologies
at300

BFE
KSC CORE

Calrec Audio Ltd
Fixed Format IO Box

Calrec Audio Ltd
Impulse Core

Calrec Audio Ltd
Modular IO Box

Calrec Audio Ltd
Type R Core

Calrec Audio Ltd
Type R IO Box

Cobalt Digital
Indigo 2110-DC-01

Evertz
670-X19

Evertzev670-X30

EvertzGrass Valley
Scorpion

LDX 150

Grass ValleyXCU UNIVERSE UXFGrass Valley
AMPP Edge

Imagine Communications
Selenio Network Processor (SNP)

Leader Electronics Corp.
LV5600Macnica
EASYSS10

Macnica
M2S

Matrox
VERO

Merging Technologies
Anubis - ZMAN platform

NEC Corporation
HD-IPO

NevionVirtuoso

NVIDIA
Rivermax 1.20

Panasonic Connect
AK-NP600 10G MoIP Board for AK-UCU600

Panasonic Connect
KAIROS AT-KC100

Panasonic Connect
KAIROS AT-KC1000

PebbleIntegrated Channel

PHABRIXQxL (Tx/Rx)

Riedel Communications
Artist AES67 Card AES67-108 G2

Riedel Communications
Artist AES67 Card UIC-128

Riedel Communications
MN-FusioN-3-B

Riedel Communications
MN-FusioN-6-B

Riedel Communications
MuoN B

Ross
BACH Liberty

Ross
BACH Minuet

Ross
BACH openModule OM512

Ross
IGGY-MADI

Ross
Newt

Ross
Ultrix-IP-IOSony
NXLK-IP50Y series

TAG
MCM-9000

vizrt
VizEngine

Adeas/Nextera

AppearECx210 Decoder

MatroxConvertIP DSS-TX

MediaKind
RX1

PHABRIXHDMI IP Gateway

SxTAG (Encap)

SencoreMRD 7000

Sumavision
S010

Village Island
VICO-4L-ST2110 Encoder

Village Island
VICO-4L-XS-IP Encoder

Adeas/Nextera
IP HDMI Gateway

AppearECx210 Encoder

Bridge Technologies
VB440

Georg Neumann GmbHKH 150 AES67

Georg Neumann GmbHKH 750 AES67

MatroxConvertIP DSH-RX

MatroxConvertIP DSS-RX

PHABRIX
Qx (Rx)PHABRIXSxTAG (Decap)

Riedel Communications
Audio Monitoring App

Sumavision
S010

Telestream
Inspect 2110

Telestream
PRISM MPD300

Telestream
PRISM MPI2-25

Telestream
PRISM MPS300

Village Island
VICO-4L-ST2110 Decoder

Village Island
VICO-4L-XS-IP Decoder

vizrt
ChannelRecorder

LEGEND
Green square = Capable
White square = Capability not demonstrated
IGMPv3

GET /x-nmos/channelmapping/v1.0/{invalidPath}(404) (auto_channelmapping_23)

GET /xnmos/channelmapping/v1.0/outputs/{outputId}/sourceid (auto_channelmapping_22)

GET /xnmos/channelmapping/v1.0/outputs/{outputId}/properties (auto_channelmapping_21)

GET /xnmos/channelmapping/v1.0/outputs/{outputId}/channels (auto_channelmapping_20)

GET /xnmos/channelmapping/v1.0/outputs/{outputId}/caps (auto_channelmapping_19)

GET /x-nmos/channelmapping/v1.0/outputs/{outputId} (auto_channelmapping_18)

GET /x-nmos/channelmapping/v1.0/outputs(auto_channelmapping_17)

GET /x-nmos/channelmapping/v1.0/map/active(auto_channelmapping_16)

OPTIONS /x-nmos/channelmapping/v1.0/map/
activations (auto_channelmapping_13)

GET /x-nmos/channelmapping/v1.0/map/
activations (auto_channelmapping_12)

GET /x-nmos/channelmapping/v1.0/map(auto_channelmapping_11)

GET /x-nmos/channelmapping/v1.0/io(auto_channelmapping_10)

GET /xnmos/channelmapping/v1.0/inputs/{inputId}/properties (auto_channelmapping_9)

A.6.1

GET /xnmos/channelmapping/v1.0/inputs/{inputId}/parent (auto_channelmapping_8)

GET /xnmos/channelmapping/v1.0/inputs/{inputId}/channels (auto_channelmapping_7)

GET /x-nmos/channelmapping/v1.0/inputs/{inputId}/caps (auto_channelmapping_6)

GET /x-nmos/channelmapping/v1.0/inputs/{inputId} (auto_channelmapping_5)

GET /x-nmos/channelmapping/v1.0/inputs(auto_channelmapping_4)

GET /x-nmos/channelmapping/v1.0(auto_channelmapping_3)

GET /x-nmos/channelmapping(auto_channelmapping_2)

GET /x-nmos (auto_channelmapping_1)

A.5.4

Channel Mapping API Schema Conformance

Source-filter matches interface source IP (Tx only)

A.5.3

SDP has source-filter (Tx only)

A.5 Streams (IS-05)

SDP source-filters

Source filter matches SDP source IP (Rx only)

Use IGMPv3 (Rx only)

A.5.2

Master_enable functions correctly (Rx only)

Receiver joins correct stream (Rx only)

A.5.1

Configuring Receivers and reception

Master_enable functions correctly (Tx only)

A.4.8

Sender stream matches configuration (Tx only)

A.4 Connection Management (IS-05)

Configuring Senders and streaming

test_18: Receiver correctly translates SDP fileattributes into transport_params (Rx only)

test_08: Activation of a receiver from a non-NMOS
sender updates the IS-04 subscription (Rx only)

test_07: Activation of a receiver from an NMOS
sender updates the IS-04 subscription (Rx only)

test_05: Activation of a receiver increments theversion timestamp (Rx only)

test_17: IS-05 transportfile ts-refclk matches IS-04
Source and Node (Tx only)

test_16: IS-05 transportfile optional fmtp parameters
match IS-04 Source and Flow (Tx only)

test_15: IS-05 transportfile fmtp parameters match IS04 Source and Flow (Tx only)

test_14: IS-05 transportfile rtpmap parameters match
IS-04 Source and Flow (Tx only)

test_11: Activation of a sender to a unicast nonNMOS receiver updates the IS-04 subscription(Tx only)

test_10: Activation of a sender to a unicast NMOS
receiver updates the IS-04 subscription (Tx only)

test_09: Activation of a sender to a multicast address
updates the IS-04 subscription (Tx only)

test_06: Activation of a sender increments the version
timestamp (Tx only)

test_13: IS-04 manifest_href matches IS-05transportfile

test_12: IS-04 interface bindings array matches lengthof IS-05 transport_params arraytest_04: Senders shown in Connection API matches
those shown in Node API

test_03: Receivers shown in Connection API matches
those shown in Node API

test_02: At least one Device is showing an IS-05
control advertisement matching the API under test

test_01: Check that version 1.2 or greater of the NodeAPI is available

A.4.7

Integration with IS-04

test_37: Bulk interface can be used to change
destination port on all receivers (Rx only)

test_35: GET on /bulk/receivers returns 405

A.4.6

Bulk Receiver Routing

test_36: Bulk interface can be used to change
destination port on all senders (Tx only)

test_34: GET on /bulk/senders returns 405

A.4.5

Bulk Sender Routing

test_30: Absolute activation of a receiver is possible(Rx only)

test_28: Relative activation of a receiver is possible(Rx only)

test_29: Absolute activation of a sender is possible (Txonly)

test_27: Relative activation of a sender is possible (Tx
only)

A.4.4

Scheduled Activation

test_39: Number of legs matches on constraints,
staged and active endpoint for receivers (Rx only)

test_26: Immediate activation of a receiver is possible(Rx only)

test_24_01: Receivers accept a patch request withempty leg(s) in transport parameters (Rx only)

test_24: Receiver transport parameters arechangeable (Rx only)

test_21: Sender id on staged receiver is changeable(Rx only)

test_20: Receiver invalid patch is refused (Rx only)

test_18: Receiver patch response schema is valid(Rx only)

test_16: Staged parameters for receivers comply withconstraints (Rx only)

Device Under Test

Single Receiver Routing

Model

Vendor Name

JT-NM Tested August 2022 – NMOS/TR-1001-1 Testing Results

A.6 Audio Channel Mapping (IS-08)

SDI IP Gateway

EVS Broadcast Equipment SA Neuron

EVS Broadcast Equipment SA XT-VIA

Page 3

Adeas/Nextera

LEGEND
Green square = Capable
White square = Capability not demonstrated
arkona technologies
at300

BFE
KSC CORE

Calrec Audio Ltd
Fixed Format IO Box

Calrec Audio Ltd
Impulse Core

Calrec Audio Ltd
Modular IO Box

Calrec Audio Ltd
Type R Core

Calrec Audio Ltd
Type R IO Box

Cobalt Digital
Indigo 2110-DC-01

Evertz
670-X19

Evertzev670-X30

EvertzGrass Valley
Scorpion

LDX 150

Grass ValleyXCU UNIVERSE UXFGrass Valley
AMPP Edge

Imagine Communications
Selenio Network Processor (SNP)

Leader Electronics Corp.
LV5600Macnica
EASYSS10

Macnica
M2S

Matrox
VERO

Merging Technologies
Anubis - ZMAN platform

NEC Corporation
HD-IPO

NevionVirtuoso

NVIDIA
Rivermax 1.20

Panasonic Connect
AK-NP600 10G MoIP Board for AK-UCU600

Panasonic Connect
KAIROS AT-KC100

Panasonic Connect
KAIROS AT-KC1000

PebbleIntegrated Channel

PHABRIXQxL (Tx/Rx)

Riedel Communications
Artist AES67 Card AES67-108 G2

Riedel Communications
Artist AES67 Card UIC-128

Riedel Communications
MN-FusioN-3-B

Riedel Communications
MN-FusioN-6-B

Riedel Communications
MuoN B

Ross
BACH Liberty

Ross
BACH Minuet

Ross
BACH openModule OM512

Ross
IGGY-MADI

Ross
Newt

Ross
Ultrix-IP-IOSony
NXLK-IP50Y series

TAG
MCM-9000

vizrt
VizEngine

Adeas/Nextera

AppearECx210 Decoder

MatroxConvertIP DSS-TX

MediaKind
RX1

PHABRIXHDMI IP Gateway

SxTAG (Encap)

SencoreMRD 7000

Sumavision
S010

Village Island
VICO-4L-ST2110 Encoder

Village Island
VICO-4L-XS-IP Encoder

Adeas/Nextera
IP HDMI Gateway

AppearECx210 Encoder

Bridge Technologies
VB440

Georg Neumann GmbHKH 150 AES67

Georg Neumann GmbHKH 750 AES67

MatroxConvertIP DSH-RX

MatroxConvertIP DSS-RX

PHABRIX
Qx (Rx)PHABRIXSxTAG (Decap)

Riedel Communications
Audio Monitoring App

Sumavision
S010

Telestream
Inspect 2110

Telestream
PRISM MPD300

Telestream
PRISM MPI2-25

Telestream
PRISM MPS300

Village Island
VICO-4L-ST2110 Decoder

Village Island
VICO-4L-XS-IP Decoder

vizrt
ChannelRecorder

test_27_8: Receiver 'caps' media type constraints
should be used consistently (Rx only)

test_27_7: Receiver 'caps' parameter constraints
should be used with the correct format (Rx only)

test_27_5: Node API implements BCP-004-01
Receiver Capabilities constraint set preferences(Rx only)
test_27_6: Node API implements BCP-004-01
Receiver Capabilities enabled/disabled constraint sets
(Rx only)

test_27_4: Node API implements BCP-004-01
Receiver Capabilities constraint set labels (Rx only)

test_27_3: Receiver 'caps' parameter constraints
should be listed in the Capabilities register (Rx only)

A.7 System Parameters (IS-09)
test_27_2: Receiver 'caps' version is valid (Rx only)

test_27_1: Node API implements BCP-004-01
Receiver Capabilities (Rx only)

test_04: Node correctly selects a System API based on
advertised priorities

test_03: System API interactions use the correct
versioned path

test_02_01: Node does not attempt to contact an
unsuitable System API

A.6.4
test_02: Node can discover System API via unicast
DNS

test_04: All Input Source/Receiver IDs match up to the
IS-04 Node API

test_03: All Output Source IDs match up to the IS-04
Node API

test_02: API is correctly advertised as a control
endpoint

A.6.3
test_01: Activations result in a Device version number
increment

A.6 Audio Channel Mapping (IS-08)

Integration with IS-04

test_06: Attempting to change a locked route results
in a 423 response

test_05: Activations can be deleted once createdtest_04: Absolute offset activations can be called on
the API

test_03: Relative offset activations can be called on
the API

test_02: Immediate activation can be called on theAPI

Activations

test_15: It is not possible to make an out-of-blockroute when block_size is anything other than 1

A.6.2
test_14: It is not possible to re-order channels when reordering is set to `false`

test_13: Attempting to violate routing constraints
results in an HTTP 400 response

test_12: Outputs have at least one channel
represented in their channels resource

test_11: Inputs have at least one channel represented
in their channels resource

test_07: Channels in the active resource where no
input channel is routed have `null` set as the `input`
and `channel_index`
test_08: If the device allows re-entrant matrices, theconstraints are set such that it is not possible to createa looptest_01: Content of the /io view matches resources
elsewhere in the API

Device Under Test

Channel Mapping API Behaviour

Model

Vendor Name

JT-NM Tested August 2022 – NMOS/TR-1001-1 Testing Results

A.8 Receiver Capabilities (BCP-004-01)

SDI IP Gateway

EVS Broadcast Equipment SA Neuron

EVS Broadcast Equipment SA XT-VIA

Page 4

Evertz
EVS Broadcast Equipment SA
Imagine Communications
BFE
Lawo
MatroxPebbleMAGNUM
Orchestration and Control System
Cerebrum
Broadcast control and monitoring system
Magellan Control System NMOS Controller, NMOS Registry
KSC SILKNET
Broadcast SDN Controller / NMOS Controller
HOME
HOME
ConductIP
NMOS IS‐05 Controller
Control
NMOS Controller

LEGEND
Green square = Capable
White square = Capability not demonstrated
C.1.2
C.2.1
C.2.2
C.2.3
C.2.4

C2.1 test_01: Identify which Receiver devices arecontrollable via IS‐05
C2.2 test_02: Instruct Receiver to subscribe to a
Sender's Flow via IS‐05
C2.3 test_03: Disconnecting a Receiver from aconnected Flow via IS‐05.
C2.4 test_04: Indicating the state of connections
via updates received from the IS‐04 Query API

MAGNUM‐HW 22.5
Controller, Registryn/a2,2
Controller, Registry
V1.0
3.8.0
Controller, Registryn/a
16.3
Controller
n/av1.4.0Controller
n/a1.00.00
Controller
n/aV1.4
Controller

Page 5

GET /x‐nmos/registration/v1.x/{invalidPath}(404)(auto_registration_7)

OPTIONS /x‐nmos/registration/v1.x/
resource (auto_registration_4)

GET /x‐nmos/registration/v1.x(auto_registration_3)

GET /x‐nmos/registration (auto_registration_2)

GET /x‐nmos (auto_registration_1)

GET /x‐nmos/query/v1.x/{invalidPath} (404)(auto_query_20)

OPTIONS /x‐nmos/query/v1.x/subscriptions/{subscriptionId} (auto_query_19)

GET /x‐nmos/query/v1.x/subscriptions/{subscriptionId} (auto_query_18)

OPTIONS /x‐nmos/query/v1.x/subscriptions(auto_query_17)

GET /x‐nmos/query/v1.x/subscriptions(auto_query_16)

GET /x‐nmos/query/v1.x/sources/{sourceId} (auto_query_15)

GET /x‐nmos/query/v1.x/
sources (auto_query_14)

GET /x‐nmos/query/v1.x/senders/{senderId} (auto_query_13)

GET /x‐nmos/query/v1.x/senders(auto_query_12)

GET /x‐nmos/query/v1.x/receivers/{receiverId} (auto_query_11)

B.1 Registry ‐ Secure Communication

GET /x‐nmos/query/v1.x/receivers(auto_query_10)

GET /x‐nmos/query/v1.x/nodes/{nodeId}(auto_query_9)

GET /x‐nmos/query/v1.x/nodes (auto_query_8)

GET /x‐nmos/query/v1.x/flows/{flowId}(auto_query_7)

GET /x‐nmos/query/v1.x/flows (auto_query_6)

GET /x‐nmos/query/v1.x/devices/{deviceId}(auto_query_5)

GET /x‐nmos/query/v1.x/devices (auto_query_4)

GET /x‐nmos/query/v1.x (auto_query_3)

GET /x‐nmos/query (auto_query_2)

GET /x‐nmos (auto_query_1)

Registry API Schema Conformancetest_09: Server exposes a valid chain of trust
including a certificate and intermediate

test_08: Server exposes both an RSA and ECDSA
certificate

test_07: Certificate is valid and matches the hostunder test

test_06: OCSP Stapling

test_05: Certificate revocation method is available

test_04: HSTS Header

test_03: Certificate does not use IP addresses in
CN/SANs

C.2 Connection Management

test_02: TLS Ciphers

C.1 Controller ‐ Discovery of Media Nodes

test_01: TLS Protocols

C.1.3

test_05: Reference Sender is put offline and thenback online

test_04: Query API should be able to discover all
the receivers that are registered in the Registry

test_03: Query API should be able to discover all
the senders that are registered in the Registry

test_02: Ensure NCuT can access the IS‐04 Query
API.

C1.1

Discovering registered resources via the IS‐04
Query API

Device Under Test Details

test_01: Ensure NCuT uses DNS‐SD to findRegistry.

Controller, Registry

SW Version

Device Under Test

HW Version

Type of Product/ Functional Description

Model

Vendor Name

JT-NM Tested August 2022 – NMOS/TR-1001-1 Testing Results

B.2.1

B.2 Registry ‐ APIs & Behaviour

ModelEvertzEVS Broadcast Equipment SA
Imagine Communications
BFE
Lawo
MatroxPebbleMAGNUM
Cerebrum
Magellan Control System
KSC SILKNET
HOMEConductIPControl

LEGEND
Green square = Capable
White square = Capability not demonstrated
test_21_1: Query API implements pagination (noquery or paging parameters)

Page 6(auto_system_5)(auto_system_4)(auto_system_3)(auto_system_2)

B.2 Registry ‐ APIs & Behaviour(auto_system_1)

test_25: Query API implements ancestry queries

test_24_1: Query API WebSockets implement RQL

test_24: Query API implements RQL

test_23_1: Query API WebSockets implement
basic query parameters

test_23: Query API implements basic queryparameters

test_22_2: Query API WebSockets implement
downgrade queries

test_22_1: Query API subscriptions resource does
not support downgrade queries

test_22: Query API implements downgrade
queriestest_21_9: Query API implements pagination(correct protocol and IP/hostname in Link header)

test_21_8: Query API implements pagination(correct encoding of URLs in Link header)

test_21_7: Query API implements pagination(updates between paged requests)

test_21_6: Query API implements pagination (badrequests)

test_21_5: Query API implements pagination(filters that select discontiguous resources)

test_21_4: Query API implements pagination(requests that require empty responses)

test_21_3: Query API implements pagination(edge cases)

test_21_2: Query API implements pagination(documentation examples)

test_21_1_1: Query API implements pagination(when explicitly requested)

B.2.3

Advanced Querying

test_31: Query API sends correct websocket
event messages for UNCHANGED (SYNC), ADDED,MODIFIED and REMOVED

test_29_1: Query API websocket subscription
requests default to the current protocol

test_29: Query API supports websocket
subscription request

B.2.2

Basic Querying

test_32: Registration API generates 409 codewhen a conflicting registration exists

test_30: Registration API accepts heartbeat
requests for a Node held in the Registry

test_28: Registry removes stale child‐resources ofan incorrectly unregistered Nodetest_27: Registration API cleans up Nodes andtheir sub‐resources when a heartbeat doesn't
occur for the duration of a fixed timeout period

test_26: Registration API responds with 400 HTTP
code on posting a resource without parent

test_20: Registration API responds with 200 HTTP
code on updating a registered Receiver

test_19: Registration API responds with 200 HTTP
code on updating a registered Sender

test_18: Registration API responds with 200 HTTP
code on updating a registered Flow

test_17: Registration API responds with 200 HTTP
code on updating a registered Source

test_16: Registration API responds with 200 HTTP
code on updating a registered Device

test_15: Registration API responds with 200 HTTP
code on updating a registered Nodetest_14: Registration API rejects an invalid
Receiver resource with a 400 HTTP code

test_13: Registration API accepts and stores avalid Receiver resource

test_12: Registration API rejects an invalid Senderresource with a 400 HTTP code

test_11_1: Registration API accepts and stores avalid Sender resource with null flow_id

test_11: Registration API accepts and stores avalid Sender resource

test_10: Registration API rejects an invalid Flow
resource with a 400 HTTP code

test_09: Registration API accepts and stores avalid Flow resource

test_08: Registration API rejects an invalid Source
resource with a 400 HTTP code

test_07: Registration API accepts and stores avalid Source resource

test_06: Registration API rejects an invalid Device
resource with a 400 HTTP code

test_05: Registration API accepts and stores avalid Device resource

test_03_1: Registration API responds with correct
Location header
test_03_2: Registration API accepts and stores avalid Node resource containing unicodecharacters
test_04: Registration API rejects an invalid Noderesource with a 400 HTTP code

test_03: Registration API accepts and stores avalid Node resource

Registration

Vendor Name

JT-NM Tested August 2022 – NMOS/TR-1001-1 Testing Results

B.2.4

B.3 Registry ‐ System Parameters

Appendix
JT-NM Tested August 2022
NMOS/TR-1001-1 Media Nodes,
Registries and Controllers
Test Plan

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

JT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
Changelog to v1.1, 4 September 2022●●

This is a post-face-to-face event update that reflects the changes introduced by the testingand experts teams on-site and outlines additional support equipment used during thetesting
Minor typos fixed

Changelog to v1.0, 21 August 2022●●●●

Added details about NMOS Testing Tool Configuration and an example of UserConfig.py
Added a link to scripts generateCA and generateCerts
Clarified some warning exceptions with the NMOS Test Suite
Corrected the note in section C. Controller allowing embedded Registry in a Controller

Changelog to “JT-NM Tested March 2020 Program”
NMOS/TR-1001 Test Plan v1.4”, 11 July 2022
●
●
●
●
●
●
●
●

JT-NM Tested March 2020 Program” NMOS/TR-1001 Test Plan v1.4 is used as the basis
for this revision.
Initial release. This document may undergo changes ahead of the final version.
Participants of previous JT-NM Tested events carefully familiarise themselves with the newrevision of the test plan.
Editorial corrections and ambiguities resolution throughout the text.
Replaced manual test plan for Media Nodes’ Discovery of System Parameters and theRegistry with the applicable automated test cases of the NMOS Testing Tool.
Added test for BCP-003-01 Secure Communication
Added test for BCP-004-01 Receiver Capabilities.
Adapted Controller test with using the new test suite for Controllers.

1/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

Notation used in the document
JT-NM Tested Catalog results are presented as a capability map. This allows readers, especiallyend users, to focus on the capabilities demonstrated by devices during the JT-NM Tested event.
JT-NM Catalogs use the following terms to characterize test results:
Capable (green mark):
A test item marked as ‘Capable’ means a device has demonstrated a capability that was required
as part of a test listed in a JT-NM Tested Test Plan.
Capability not Demonstrated (no mark):
A test item marked as ‘Capability not Demonstrated’ means that a device did not demonstrate acapability that was required as part of a test listed in a JT-NM Tested Test Plan. Examples of why acapability might not have been demonstrated include: the test was not applicable to this type ofdevice (e.g., an audio-only device has no video capability), the device could not demonstratecapabilities that met the requirements of that test, the functionality was not implemented by design,
the vendor requested that the capability not be tested, the capability could not be tested.
To avoid potential mistakes in the test descriptions outlined in this test plan, the wording “pass/nopass” is preserved in the criteria descriptions.

Acknowledgment
This revision of the test plan was prepared by an expert group within the Joint Task Force on
Networked Media (JT-NM) with key contributions from: Félix Poulin (CBC/Radio-Canada), Gareth
Sylvester-Bradley (NVIDIA), Jonathan Thorpe (Sony), Konrad Duda (Imagine Communications),
Patrick Keroulas (CBC/Radio-Canada), Simon Lo (Sony), Thomas Kernen (NVIDIA).
Other key contributors to previous versions of the test plan: Andrew Bonney (BBC R&D), Arne
Bönninghoff (Riedel), Bill McLaughlin (EEG), Jean Lapierre (Matrox), John Mailhot (Imagine
Communications), Leigh Whitcomb (Imagine Communications), Mike Overton (Tektronix), Pedro
Ferreira (Bisect), Peter Brightwell (BBC R&D), Serge Grondin (Grass Valley), Sunday Nyamweno(CBC), and Willem Vermost (EBU).
The test plan was executed on site by the following experts: David Butler (BBC), Ingmar Mielke(ARGE RBT), Kristof Demulder (VRT), Patrick Keroulas (CBC/Radio-Canada), Peter Brightwell(BBC), Randy Godwin (Natchez Trace), Stephen Remich (Riedel) and Félix Poulin(CBC/Radio-Canada) - NMOS Testing team leader and with support from Ievgen Kostiukevych

2/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
(EBU) - JT-NM Tested event coordinator and Brad Gilmer (Gilmer and associates) - Executive
director of AMWA and VSF, JT-NM Admin board member.

Applicable Standards, Specifications, and versions
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●

IETF RFC 792 Internet Control Message Protocol
IETF RFC 1034 Domain Names - Concepts and Facilities
IETF RFC 2131 Dynamic Host Configuration Protocol
IETF RFC 3376 Internet Group Management Protocol, Version 3
IETF RFC 4566 SDP: Session Description Protocol
IETF RFC 6763 DNS-Based Service Discovery
AMWA IS-04 v1.3 (or at least v1.2) NMOS Discovery and Registration Specification
AMWA IS-05 v1.1 (or at least v1.0) NMOS Device Connection Management Specification
AMWA IS-08 v1.0 NMOS Audio Channel Mapping Specification
AMWA IS-09 v1.0 NMOS System Parameters Specification
AMWA BCP-002-01 v1.0 Natural Grouping of NMOS Resources
AMWA BCP-003-01 v1.0 Secure Communication in NMOS Systems
AMWA BCP-004-01 v1.0 NMOS Receiver Capabilities
IEEE 802.1AB-2016 Station and Media Access Control Connectivity Discovery (LLDP)IEEE 1588-2008 Precision Clock Synchronization Protocol for Networked Measurement
and Control Systems
SMPTE ST 2059-1:2021 - Generation and Alignment of Interface Signals to the SMPTE
Epoch - https://ieeexplore.ieee.org/document/9452725
SMPTE ST 2059-2:2021 - SMPTE Profile for Use of IEEE-1588 Precision Time Protocol in
Professional Broadcast Applications - https://ieeexplore.ieee.org/document/9452731
SMPTE ST 2110-10:2017 - Professional Media over Managed IP Networks: System Timing
and Definitions - https://ieeexplore.ieee.org/document/8165974
SMPTE ST 2110-20:2017 - Professional Media over Managed IP Networks: Uncompressed
Active Video - https://ieeexplore.ieee.org/document/8167389
SMPTE ST 2110-30:2017 - Professional Media over Managed IP Networks: PCM Digital
Audio - https://ieeexplore.ieee.org/document/8167392
SMPTE ST 2110-40:2018 - Professional Media over Managed IP Networks: SMPTE ST
291-1 Ancillary Data - https://ieeexplore.ieee.org/document/8353279
SMPTE ST 2022-7:2019 - Seamless Protection Switching of SMPTE ST 2022 IP
Datagrams - https://ieeexplore.ieee.org/document/8716822●

JT-NM TR-1001-1:2020 (v1.1) System Environment and Device Behaviors For SMPTE ST
2110 Media Nodes in Engineered Networks

3/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

Test equipment and environment
The following equipment was selected by the JT-NM Test Experts Group to support the “JT-NM
Tested” event. In a number of cases, other vendors’ equipment would have worked equally well. To
preserve the integrity of the testing environment, the team needed to choose one set of support
equipment. The listing of a company below should not be taken to indicate that this is the only
equipment that could have performed the tasks required. Note also that support equipment was not“JT-NM Tested” unless it is specifically listed in the JT-NM Tested Catalog and that no special
status is awarded by the JT-NM to these companies other than to note that the JT-NM appreciates
their support.

Supporting equipment and software used during the event
●

●
●
●

●
●
●

AMWA NMOS Testing Tool
○ https://github.com/AMWA-TV/nmos-testing/releases/tag/jtnm.aug2022-v1.1○ See the Appendix for usage instructions for the NMOS Testing Tool itself, theTesting Façade for Controller testing and the UUID Checker tool.
SDPoker○ https://github.com/AMWA-TV/sdpoker/releases/tag/v0.2.0
Riedel NMOS Explorer v1.8.2 (Freeware, need account)○ https://www.riedel.net/en/downloads/firmware-software
Open-Source Sony nmos-cpp IS-04 Registry and IS-09 System API○ https://github.com/sony/nmos-cpp/commit/3a904a3○ Latest Conan package is used, ‘nmos-cpp/cci.20220620’.
ISC DHCP servers (main shared network + isolated NMOS testing environments)○ https://www.isc.org/dhcp/
Glass DHCP server user interface○ https://github.com/Akkadius/glass-isc-dhcp
Bind9 DNS Server (main shared network)○ https://www.isc.org/bind/

Network switches used during the event
For this event, the NMOS/TR-1001 Test plan will use the same infrastructure as for the “JT-NM
Tested Program August 2022 SMPTE ST 2110 Test Plan”. See this other test plan for a list of
network switches used.

4/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

Network configuration of the Device under Test
The management interface(s) and media interface(s) of the Device under Test (DuT) will beconnected to network ports of appropriate speed and media type.
For the majority of the NMOS tests, the attached network switch(es) will be reconfigured from theshared network environment by changing the VLAN (for the management interfaces of the DuT)
and/or DHCP relay (for the media interfaces) will be changed to the isolated network environment
having the mock DNS of the NMOS Testing Tool for the duration of testing.

PTP/NTP configuration used during the event
PTP distribution for these tests is described in the “JT-NM Tested Program August 2022 SMPTE
ST 2110 Test Plan”.
Some NMOS test cases rely on time to be synchronized between the Testing Tool and the Device
under Test. This includes Media Node tests for IS-05 and IS-08 scheduled activations (see A.4.5
and A.6.3) and Registry tests for IS-04 Query API (see B.2.4).
The network will provide NTP synchronized with PTP to enable consistent time between the
Testing Tool and Device under Test.

General statements and terms
●

●
●

●
●
●

This test plan outlines the principles and methods for IP Media Endpoint testing which will
be applied to on-site testing at the face-to-face events. These principles and methods inthis test plan can and should be applied to self-testing and any independent testing
performed by a third party.
The execution of the tests will be done with common sense in mind. Ambiguities will be
addressed by the test team on a case-by-case basis.
If the DuT fails any particular test, a Vendor representative will be given an opportunity to
explain and discuss the results.
NOTE: Unless explicitly noted otherwise in the test plan, the testing tool needs to indicate
the ‘PASS’ state for the test case. The test states ‘FAIL’, ‘WARNING’, ‘NOT
IMPLEMENTED’ are NOT considered as a pass. (One general exception is that warnings
about ‘charset’ will be marked as a pass.)
Vendor representatives will be given the IP and PTP configuration parameters via the event
spreadsheet well ahead of their test time.
Vendor representatives will be expected to configure their equipment themselves.
Standard MTU size (1500 octets) is required.
5/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2●●●

All baseband signals and/or files required for the testing will be provided by the JT-NM
Tested team.
Vendors may not change software/firmware once testing has commenced but may adjust
settings on their products as necessary during the testing process.
The JT-NM Tested team reserves the right to update the “JT-NM Tested Program” Test
Plans as required.

NMOS Testing Tool Configuration
The NMOS Testing Tool’s configuration mechanism via UserConfig.py will be used to set up thetesting tool for JT-NM Tested. This will be used to configure the domain name for the event, enable
Unicast DNS-SD mode, and to configure testing with TLS for those devices that support securecommunication (see A.2). Vendors may also request modifications to SDP preferences for devices
that require this. An example UserConfig.py is given in the Appendix.

A. Media Node Tests
This set of tests validates a Media Node according to the requirements of JT-NM TR-1001-1:2020.
Where implemented, Media Nodes will also be tested against the AMWA IS-08 Audio Channel
Mapping, AMWA BCP-003-01 Secure Communication and AMWA BCP-004-01 Receiver
Capabilities specifications.

A.1 Startup Behavior
A.1.1 DHCP
Description: The management interface(s) and media interface(s) of the Device under Test (DuT)
will be connected to network ports of appropriate speed and media type. The DuT shall participate
in a DHCP negotiation with the DHCP server on each network connection. In addition to hostaddress and CIDR mask, the DHCP server will offer a gateway route and DNS server information
to each interface. A large enough DHCP pool will be used in order to ensure that each device getsa unique IP address.
Validation method: The DHCP server will be examined to find the addresses assigned to the DuT.
The MAC address associated with the DHCP request will also be noted. ICMP Echo-Requests(Ping) will be sent from another subnet to each of the allocated addresses. Vendor-specificmethods, if available, will also be used to examine the assigned address information.
Pass criteria:

6/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2●●

The MAC addresses in the DHCP server for each assigned address shall be unique. If
vendor-specific means were available to determine the assigned addresses, these address
details will be checked against the DHCP server entries.
The DuT shall return the ICMP echo-request that is sent to each of the DHCP-assigned
interface addresses. This will validate that the gateway route is used.

If the test fails, then for the subsequent tests, the DuT shall be manually configured with Host,
CIDR, Gateway, and DNS server information.

A.1.2 LLDP
Description: The management interface(s) and media interface(s) of the Device under Test (DuT)
will be connected to network ports of appropriate speed and media type. The DuT shall supply the
LLDP mandatory TLV items to the attached switch on each interface.
Validation method: The LLDP information tables on the attached switches will be examined tofind the information from the DuT. The presence of mandatory TLV items is checked. The reported
MAC addresses will be matched to the MAC addresses in the DHCP server, and the reported
chassis-ID and port-ID information will be noted.
Pass criteria:● The LLDP mandatory TLV items are provided. These are listed in Table 8.1 of IEEE
802.1AB-2016, and are: chassis-ID, port-ID, and TTL.
● The LLDP-reported port-ID information shall be unique for each interface on the DuT.

A.2 Secure Communication
Description: This set of tests validates a Media Node’s ability to communicate using Transport
Layer Security (TLS), according to the requirements of AMWA BCP-003-01.
The vendor will be provided with a root certificate and a server certificate chain to be installed oneach DuT, issued by a Certificate Authority (CA) created for the duration of the JT-NM Tested
event.
The following test suite within the NMOS Testing Tool will be used to enable these tests:● BCP-003-01: BCP-003-01 Secure Communication
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_01: TLS Protocols● test_02: TLS Ciphers● test_03: Certificate does not use IP addresses in CN/SANs● test_04: HSTS Header
7/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2●●●●

test_05: Certificate revocation method is available
test_06: OCSP Stapling
test_07: Certificate is valid and matches the host under test
test_08: Server exposes both an RSA and ECDSA certificate
Note: Warnings about not providing one or other of these certificates will be marked as a fail for this test.

●

test_09: Server exposes a valid chain of trust including a certificate and intermediate

Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.
Media Nodes that implement BCP-003-01 Secure Communication shall subsequently be tested
using HTTPS via the secure mode of the NMOS Testing Tool, i.e., by configuring it with
ENABLE_HTTPS set to True.
If the test fails, then for the subsequent tests, the DuT shall be tested using HTTP (non secured).

A.3 Node API & Registration Behaviour
Description: This set of tests validates a Media Node’s ability to interact with an IS-04 Registry,
with discovery achieved via unicast DNS. Tests will be carried out using the NMOS Testing Tool.
See the Appendix for usage instructions. These tests are expected to be carried out in an isolated
network environment.
First steps: The management interface(s) and media interface(s) of the Device under Test (DuT)
will be connected to network ports of appropriate speed and media type. The DuT will be
configured with a DNS server IP address and a DNS search domain, either via DHCP or via
manual configuration. These DNS addresses will match those required by the NMOS Testing Tool.
The testing tool will be configured to use a DNS_SD_MODE of ‘unicast’ and a
DNS_SD_ADVERT_TIMEOUT sufficient to cover the DuT’s boot time. The vendor will be asked toprovide the IP address(es) and port which the IS-04 Node API is running on.
The following test suites within the NMOS Testing Tool will be used to enable these tests:● IS-04-01: IS-04 Node API
Media Nodes will be tested using the highest version of IS-04 which they support, with a minimum
version of v1.2.
The following tests will not be used as they cover deprecated or unnecessary items for TR-1001:● test_01: Node can discover network registration service via multicast DNS● test_01_01: Node does not attempt to register with an unsuitable mDNS Registry● test_12: Node publishes its own mDNS announcement

8/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2●●●●

test_12_01: Node does not advertise a Node type mDNS announcement in the presence ofa Registration API (v1.3+)
test_13: Node supports IS-04 native connection management (deprecated)
test_14: Node supports IS-04 native connection parking (deprecated)
test_17_01: IS-04 Device correctly indicates linked Senders and Receivers (deprecated)

A.3.1 Node API Schema Conformance
Description: Tests that the Media Node's IS-04 Node API exposes all of the expected resources,
and that each of these conforms to the JSON schema included in the specification.
Validation method: Execution of the NMOS Testing Tool, using the following tests with
MAX_TEST_ITERATIONS set to 0 (the default) for full coverage:● auto_node_1 - auto_node_16: Schema validation of GET and OPTIONS requests
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.3.2 Basic Node API Behaviour
Description: Tests that a Media Node correctly implements various behavioural aspects of the
IS-04 specification, including the BCP-002-01 grouping syntax.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_17: All Node resources use different UUIDs● test_18: All Node clocks are unique, and relate to any visible Sources' clocks● test_19: All Node interfaces are unique, and relate to any visible Senders and Receivers'‘interface_bindings’● test_20: Node's resources correctly signal the current protocol and IP/hostname
Note: Warnings regarding the protocol of Node service 'href' values will be marked as a pass for this test●●●

test_20_01: Sender manifests use the expected Content-Type
test_23: Senders and Receivers correctly use BCP-002-01 grouping syntax
test_24: Periodic Sources specify a 'grain_rate'
Note: Warnings will be marked as a fail for ST 2110 video as these are expected to be periodic●

test_24_01: Periodic Flows' 'grain_rate' is divisible by their parent Source 'grain_rate'
Note: Warnings will be marked as a pass for this test, but including a grain_rate for periodic Flows is strongly recommended●

test_25: Receivers expose expected 'caps' for their API version
Note: Warnings will be marked as a fail unless the device accepts all media_types (for example a generic stream analyser)●

test_26: Source 'format' matches Flow 'format'

Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

9/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

A.3.3 Unicast Discovery
Description: Tests that a Media Node is capable of automatically locating the IS-04 Registry
service using unicast DNS service discovery. This test will be carried out in an isolated network
segment.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_02: Node can discover network registration service via unicast DNS
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.
If the test fails, then for the subsequent tests, the DuT shall be manually configured with theRegistration API information.

A.3.4 Basic Registration
Description: Tests that a Media Node is capable of registering all of its advertised resources withan IS-04 Registry service. Additionally requires that Nodes maintain themselves in the Registry byusing the heartbeat mechanism using the default interval of 5 seconds as specified in IS-04.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_03: Registration API interactions use the correct Content-Type
Note: Warnings about ‘charset’ will be marked as a pass for this test.

●●●

test_03_01: Registration API interactions use the correct versioned path
test_04: Node can register a valid Node resource with the network registration service,
matching its Node API self resource
test_05: Node maintains itself in the Registry via periodic calls to the health resource
Note: Warnings about inclusion of a Content-Type header will be marked as a pass for this test.

●
●
●
●
●
●
●
●

test_07: Node can register a valid Device resource with the network registration service,
matching its Node API Device resource
test_07_01: Registered Device was POSTed after a matching referenced Nodetest_08: Node can register a valid Source resource with the network registration service,
matching its Node API Source resource
test_08_01: Registered Source was POSTed after a matching referenced Device
test_09: Node can register a valid Flow resource with the network registration service,
matching its Node API Flow resource
test_09_01: Registered Flow was POSTed after a matching referenced Device or Source
test_10: Node can register a valid Sender resource with the network registration service,
matching its Node API Sender resource
test_10_01: Registered Sender was POSTed after a matching referenced Device

10/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2●●●

test_11: Node can register a valid Receiver resource with the network registration service,
matching its Node API Receiver resource
test_11_01: Registered Receiver was POSTed after a matching referenced Device
test_21: Node correctly interprets a 200 code from a Registry upon initial registration

Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.3.5 Advanced Registration
Description: Tests that a Media Node is capable of handling the presence of multiple clustered
Registries on a network. It should be able to demonstrate selection of the preferred Registry using
the defined priority order, and demonstrate an ability to failover between the available instances inthe event that one Registry indicates an error state.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_02_01: Node does not attempt to register with an unsuitable unicast DNS Registry● test_15: Node correctly selects a Registration API based on advertised priorities● test_16: Node correctly fails over between advertised Registration APIs when one fails● test_16_01: Node correctly handles Registration APIs whose connections time out
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.3.6 Consistency of UUIDs
Description: This test validates that Media Nodes expose the same UUID values after a reboot orrestart event, even when the Media Node has moved to a new network environment.
Validation method: During initial setup in the shared environment, with the consent of the unit
under test, a snapshot will be taken of the UUIDs for the Node and its Devices, Senders, andReceivers. In the later isolated test, when the Media Node is on a different subnet, attached to adifferent Registry, the UUIDs will be compared after a reboot against the previous snapshot. In
order to assist with this test, the UUID Checker tool included in the NMOS Testing Tool repository
will be used.
Pass criteria:● The UUID values for Node, Devices, Senders, and Receivers shall be the same, forelements of the Media Node which are in the same configuration.

11/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

A.4 Connection Management
Description: This set of tests validates a Media Node’s ability to be controlled by a Controller
using the IS-05 Connection API. Tests will be carried out using the NMOS Testing Tool. See the
Appendix for usage instructions.
First steps: As described above, the management interface(s) and media interface(s) of theDevice under Test (DuT) will be connected to network ports of appropriate speed and media type.
The vendor will be asked to provide the IP address(es) and port(s) which the IS-04 Node API and
IS-05 Connection API are running on. The vendor will be asked to configure their device asnecessary, with the option to have the test run with or without ST 2022-7 support enabled (if thisoption is available). The tests will not be run twice to cover both modes due to time constraints.
The following test suites within the NMOS Testing Tool will be used to enable these tests:● IS-05-01: IS-05 Connection Management API (used by A.4.1 through A.4.7 below)● IS-05-02: IS-05 Interaction with IS-04 (used by A.4.8 only below)
Media Nodes will be tested using the highest versions of IS-04 and IS-05 which they support, witha minimum of v1.2 and v1.0 respectively.

A.4.1 Connection API Schema Conformance
Description: Tests that the Media Node's IS-05 Connection API exposes all of the expectedresources, and that each of these conforms to the JSON schema included in the specification.
Validation method: Execution of the NMOS Testing Tool, using the following tests with
MAX_TEST_ITERATIONS set to 0 (the default) for full coverage:● auto_connection_1 - auto_connection_22: Schema validation of GET and OPTIONS
requests
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.4.2 Basic Connection API Behaviour
Description: Tests that the IS-05 Connection API does not expose an invalid configuration, andthat violations of the advertised constraints are not permitted.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_09: All params listed in /single/senders/{senderId}/constraints/ matches /staged/ and/active/

12/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
●
●
●
●
●
●
●
●
●
●
●
●

test_09_01: All params listed in /single/senders/{senderId}/active/ match theircorresponding SDP files
test_10: All params listed in /single/receivers/{receiverId}/constraints/ matches /staged/ and/active/
test_11: Senders are using valid combination of parameters
test_11_01: Sender /active parameters do not use the keyword 'auto'
test_11_02: Patched 'auto' values are translated on ‘/active’ endpoint for all receivers
test_12: Receiver are using valid combination of parameters
test_12_01: Receiver /active parameters do not use the keyword 'auto'
test_13: Return of /single/senders/{senderId}/staged/ meets the schema
test_14: Return of /single/receivers/{receiverId}/staged/ meets the schema
test_31: Sender active response schema is valid
test_32: Receiver active response schema is valid
test_40: Only valid transport types for a given API version are advertised

Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.4.3 Single Sender Routing
Description: Tests that a Media Node with a ST 2110 transmission capability can have its
configuration managed via the IS-05 ‘single’ resource.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_15: Staged parameters for senders comply with constraints● test_17: Sender patch response schema is valid● test_19: Sender invalid patch is refused● test_22: Receiver id on staged sender is changeable● test_23: Sender transport parameters are changeable● test_23_01: Senders accept a patch request with empty leg(s) in transport parameters● test_25: Immediate activation of a sender is possible● test_38: Number of legs matches on constraints, staged and active endpoint for senders● test_41: SDP transport files pass SDPoker tests
Note: Whitespace warnings will be marked as a pass for this test.

●

test_42: Transport files use the expected Content-Type

Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

13/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

A.4.4 Single Receiver Routing
Description: Tests that a Media Node with a ST 2110 reception capability can have its
configuration managed via the IS-05 ‘single’ resource.

Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_16: Staged parameters for receivers comply with constraints● test_18: Receiver patch response schema is valid● test_20: Receiver invalid patch is refused● test_21: Sender id on staged receiver is changeable● test_24: Receiver transport parameters are changeable● test_24_01: Receivers accept a patch request with empty leg(s) in transport parameters● test_26: Immediate activation of a receiver is possible● test_39: Number of legs matches on constraints, staged and active endpoint for receivers
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.4.5 Scheduled Activation
Description: Tests that the Media Node permits activation of new IS-05 transmission or reception
parameters after a relative time offset or at an absolute time instant. This is in addition to
immediate activations which are tested in A.4.3 and A.4.4.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_27: Relative activation of a sender is possible
Note: A warning indicating one retry was required (“Tries: 2”) will be marked as a pass for test_27, test_28, test_29 or test_30●●●

test_28: Relative activation of a receiver is possible
test_29: Absolute activation of a sender is possible
test_30: Absolute activation of a receiver is possible

Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.4.6 Bulk Sender Routing
Description: Tests that a Media Node with a ST 2110 transmission capability can have its
configuration managed via the IS-05 ‘bulk’ resource, which allows multiple Senders to be
re-configured at the same time.
Validation method: Execution of the NMOS Testing Tool, using the following tests:
14/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2●●

test_34: GET on /bulk/senders returns 405
test_36: Bulk interface can be used to change destination port on all senders

Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.4.7 Bulk Receiver Routing
Description: Tests that a Media Node with a ST 2110 reception capability can have its
configuration managed via the IS-05 ‘bulk’ resource, which allows multiple Receivers to be
re-configured at the same time.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_35: GET on /bulk/receivers returns 405● test_37: Bulk interface can be used to change destination port on all receivers
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.4.8 Integration with IS-04
Description: Tests that the IS-05 Connection API is correctly advertised via the IS-04 Node API,and that the Senders and Receivers advertised in IS-05 match those in IS-04. This test also
ensures that when the IS-05 configuration is updated, the matching IS-04 resources are updated toreflect any changes to their state (parked/unparked) and which remote Sender or Receiver they
are currently connected to.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_01: Check that version 1.2 or greater of the Node API is available● test_02: At least one Device is showing an IS-05 control advertisement matching the API
under test
● test_03: Receivers shown in Connection API matches those shown in Node API● test_04: Senders shown in Connection API matches those shown in Node API● test_05: Activation of a receiver increments the version timestamp
Note: Failure related to Receiver ‘caps’ ‘version’ will be marked as a pass for this test and be indicated under the results
BCP-004-01 Receiver Capabilities instead.

●●

test_06: Activation of a sender increments the version timestamp
test_07: Activation of a receiver from an NMOS sender updates the IS-04 subscription
Note: If the receiver has constraints on its acceptable stream format, for example as expressed via Receiver ‘caps’‘constraint_sets’, the JT-NM Tested team may configure the required parameters in the Testing Tool using the‘SDP_PARAMETERS’ setting.

●●test_08: Activation of a receiver from a non-NMOS sender updates the IS-04 subscription
test_09: Activation of a sender to a multicast address updates the IS-04 subscription

15/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
Note: Failure is expected for senders that only support unicast. The JT-NM Tested results will indicate that the Device under
Test is not capable.

●

test_10: Activation of a sender to a unicast NMOS receiver updates the IS-04 subscription
Note: Failure is expected for senders that only support multicast. The JT-NM Tested results will indicate that the Device under
Test is not capable.

●

test_11: Activation of a sender to a unicast non-NMOS receiver updates the IS-04
subscription
Note: Failure is expected for senders that only support multicast. The JT-NM Tested results will indicate that the Device under
Test is not capable.

●
●
●
●
●
●
●

test_12: IS-04 interface bindings array matches length of IS-05 transport_params arraytest_13: IS-04 manifest_href matches IS-05 transportfile
test_14: IS-05 transportfile rtpmap parameters match IS-04 Source and Flow
test_15: IS-05 transportfile fmtp parameters match IS-04 Source and Flow
test_16: IS-05 transportfile optional fmtp parameters match IS-04 Source and Flow
test_17: IS-05 transportfile ts-refclk matches IS-04 Source and Nodetest_18: Receiver correctly translates SDP file attributes into transport_params

Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.5 Streams
Description: This set of tests validates that IS-05 usage on the DuT matches the production or
consumption of real ST 2110 streams on the network.These tests are expected to be carried out ina shared network environment. All media streams shall remain confined to the media portion of the
IP network. Testing will be performed using the IS-05 Control utility as part of the NMOS TestingTool: https://github.com/AMWA-TV/nmos-testing/tree/master/utilities/is-05-control
First steps: As described above, the management interface(s) and media interface(s) of theDevice under Test (DuT) will be connected to network ports of appropriate speed and media type.
At the time of testing the vendor should provide the following:● A sender and/or receiver (adhering to ST 2110-20/30/40) registered in the provided IS-04
Registry.
● The DuT is expected to support IGMPv3 and be configured to use it if this is not automatic.

A.5.1 Configuring Senders and successful reception of configured
ST 2110-20/30/40 stream via IS-05
A reference receiver that supports 2022-7 will be used to validate the sender configuration. If DuTs
support a 2022-7 and non-2022-7 mode, the participant may choose which one of these is tested.
If the DuT supports video, audio and ANC only one of these will be tested.

16/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
Description: The Test validates that IS-05 transport parameters can be used to successfully set a
multicast destination on the sender. The following steps will be done in IS-05 single mode. Where a2022-7 capable sender is being tested, the same checks and configuration will be performed forboth the ‘primary’ and ‘secondary’ streams.
Validation method:● DuT starts with a "no streaming" state. Active state should return ‘master_enable’ as false.
● Validate that the reference receiver can not receive the stream at the configured multicast
destination.
● Stage and activate the DuT sender with one multicast destination per stream with‘master_enable’ set to true and ‘rtp_enabled’ set to true.
● Validate that the reference receiver can now receive the stream at the configured multicast
destination.
● Stage and activate the DuT sender with ‘master_enable’ set to false.
● Validate that the stream has stopped on the reference receiver.
Pass criteria:● The DuT accepts the configuration and can be seen to send a stream using the correct
multicast configuration.
● The DuT could be successfully enabled and disabled using the ‘master_enable’ flag.

A.5.2 Configuring Receivers and successful reception of a ST 2110-20/30/40
stream using an SDP file via IS-05
A reference sender that supports ST 2022-7 will be used to validate the receiver configuration. If
DuTs support a 2022-7 and non-2022-7 mode, the participant may choose which one of these istested. If the DuT supports video, audio and ANC only one of these will be tested.
Description: The Test validates that IS-05 can be used to assign a configuration to a receiverusing the ‘transport_file’ parameter. The following steps will be done in IS-05 single mode. Where a2022-7 capable receiver is being tested, the same checks and configuration will be performed forboth the ‘primary’ and ‘secondary’ streams.
Validation method:● DuT starts with a "no streaming" state. Active state should return ‘master_enable’ as false.
● Validate that the DuT receiver is not receiving anything.
● Stage and activate the DuT receiver by providing the reference sender’s SDP in the‘transport_file’ staging. ‘master_enable’ will be set to true during this step.
● Validate that the DuT receiver can now receive the stream at the multicast destination.
● Stage and activate the DuT receiver with ‘master_enable’ set to false.
● Validate that the stream has stopped on the DuT receiver.

17/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
Pass criteria:● The DuT accepts the configuration and can be seen to receive the stream.
● The DuT could be successfully enabled and disabled using the ‘master_enable’ flag.

A.5.3 IGMPv3 including source addresses
Description: The Test validates that IS-05 can be used to assign a ‘source_ip’ to a receiver byusing SDP files containing multicast source-filters. The receiver should use IGMPv3 in order toselect the right source.
Validation method:● Validate that the receiver is not receiving anything.
● Stage and activate the receiver using the SDP transport_file of a reference sender,
including a valid source-filter line.
● Validate that the IGMP snooping table in the switch indicates that the source IP addressfrom the SDP file was included in the IGMPv3 request.
● Validate that the receiver can now receive the stream at the multicast destination.
Pass criteria:● The DuT sends a valid IGMPv3 request for the requested multicast group and can be seen
to receive the stream.
● The IGMPv3 request includes a filter matching the source IP address.

A.5.4 SDP files including source-filters in senders
Description: The Test validates that usage of source-filters in SDPs match the stream being sentby the sender.
Validation method:●●Get the SDP file from the DuT using the IS-05 /transportfile resource.
Validate that the stream generated by the DuT is sending packets from a source IP address
which matches the SDP source-filter line provided by the sender.

Pass criteria:● The DuT is providing an SDP with a source-filter present.
● The source-filter line(s) match the source interface IP addresses.

A.6 Audio Channel Mapping
Description: This set of tests validates a Media Node’s ability to remap audio channels either prior
to sending a stream onto the network, or after receiving one. Tests will be carried out using the
NMOS Testing Tool. See the Appendix for usage instructions.
18/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

First steps: The management interface(s) and media interface(s) of the Device under Test (DuT)
will be connected to network ports of appropriate speed and media type. The vendor will be asked
to provide the IP address(es) and port(s) which the IS-04 Node API and IS-08 Channel Mapping
API are running on. The vendor will be asked to configure their device as necessary.
The following test suites within the NMOS Testing Tool will be used to enable these tests:● IS-08-01: IS-08 Audio Channel Mapping API (used by A.6.1 through A.6.3 below)● IS-08-02: IS-08 Interaction with IS-04 (used by A.6.4 only below)
Media Nodes will be tested using the highest versions of IS-04 and IS-08 which they support, witha minimum of v1.2 and v1.0 respectively.

A.6.1 Channel Mapping API Schema Conformance
Description: Tests that the Media Node's IS-08 Channel Mapping API exposes all of the expectedresources, and that each of these conforms to the JSON schema included in the specification.
Validation method: Execution of the NMOS Testing Tool, using the following tests with
MAX_TEST_ITERATIONS set to 0 (the default) for full coverage:● auto_channelmapping_1 - auto_channelmapping_23: Schema validation of GET and
OPTIONS requests
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.6.2 Channel Mapping API Behaviour
Description: Tests that the IS-08 API does not expose an invalid configuration, and that violationsof the advertised constraints are not permitted.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_01: Content of the /io view matches resources elsewhere in the API● test_07: Channels in the active resource where no input channel is routed have `null` set asthe `input` and `channel_index`● test_08: If the device allows re-entrant matrices, the constraints are set such that it is notpossible to create a loop
● test_11: Inputs have at least one channel represented in their channels resource● test_12: Outputs have at least one channel represented in their channels resource● test_13: Attempting to violate routing constraints results in an HTTP 400 response● test_14: It is not possible to re-order channels when re-ordering is set to `false`

19/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2●

test_15: It is not possible to make an out-of-block route when block_size is anything otherthan 1

Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.6.3 Activations
Description: Tests that the Media Node permits activation of new IS-08 parameters either
immediately, or after a time offset.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_02: Immediate activation can be called on the API● test_03: Relative offset activations can be called on the API● test_04: Absolute offset activations can be called on the API● test_05: Activations can be deleted once created● test_06: Attempting to change a locked route results in a 423 response
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.6.4 Integration with IS-04
Description: Tests that the IS-08 Audio Channel Mapping API is correctly advertised via the IS-04
Node API, and that the Source and Receiver IDs advertised in IS-08 match those in IS-04. This
test also ensures that when the IS-08 configuration is updated, the matching IS-04 resources are
updated to reflect any changes to their state.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_01: Activations result in a Device version number increment● test_02: API is correctly advertised as a control endpoint● test_03: All Output Source IDs match up to the IS-04 Node API● test_04: All Input Source/Receiver IDs match up to the IS-04 Node API
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.7 System Parameters
Description: This set of tests validates a Media Node’s ability to discover the AMWA IS-09 System
API. Tests will be carried out using the NMOS Testing Tool. See the Appendix for usage
instructions. These tests are expected to be carried out in an isolated network environment.

20/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

The following test suite within the NMOS Testing Tool will be used to enable these tests:● IS-09-02: IS-09 System API Discovery
The following tests will not be used as they cover deprecated or unnecessary items for TR-1001:● test_01: Node can discover System API via multicast DNS● test_01_01: Node does not attempt to contact an unsuitable System API
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_02: Node can discover System API via unicast DNS● test_02_01: Node does not attempt to contact an unsuitable System API● test_03: System API interactions use the correct versioned path● test_04: Node correctly selects a System API based on advertised priorities
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

A.8 Receiver Capabilities
Description: This set of tests validates a Media Node’s use of BCP-004-01 Receiver Capabilities
to express parametric constraints on the types of streams that it is capable of consuming. Tests will
be carried out using the NMOS Testing Tool. See the Appendix for usage instructions.
The following test suite within the NMOS Testing Tool will be used to enable these tests:● IS-04-01: IS-04 Node API
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_27_1: Node API implements BCP-004-01 Receiver Capabilities● test_27_2: Receiver 'caps' version is valid● test_27_3: Receiver 'caps' parameter constraints should be listed in the Capabilities
register● test_27_4: Node API implements BCP-004-01 Receiver Capabilities constraint set labels● test_27_5: Node API implements BCP-004-01 Receiver Capabilities constraint set
preferences● test_27_6: Node API implements BCP-004-01 Receiver Capabilities enabled/disabledconstraint sets
● test_27_7: Receiver 'caps' parameter constraints should be used with the correct format● test_27_8: Receiver 'caps' media type constraints should be used consistently
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

21/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

B. NMOS Registry Tests
This set of tests validates an IS-04 Registry under test to ensure that it can correctly handle
interactions with Media Nodes and Controllers.
NOTE: In order to participate, stand alone Registries must expose both an IS-04 Registration andQuery API, operating with the default heartbeat and garbage collection intervals as specified. For
NMOS Controllers that have an embedded Registry, exposing the IS-04 Query API is a desired
capability so that it can be consulted by third parties, for instance for monitoring and inventory
purposes.
In order that all test cases can provide meaningful results, one Node will be registered by the
JT-NM Tested team with the Registration API under test, and one persistent Query API
Subscription will be requested, before the test suite is run.

B.1 Secure Communication
Description: This set of tests validates a Registry’s ability to provide its NMOS APIs, andcommunicate with other NMOS entities (e.g., Media Nodes and Controllers), with Transport Layer
Security (TLS), according to the requirements of AMWA BCP-003-01.
The vendor will be provided with a root certificate and a server certificate chain to be installed oneach DuT, issued by a Certificate Authority (CA) created for the duration of the JT-NM Tested
event. The generateCA and generateCerts scripts which are used to create the certificates are
documented at https://github.com/AMWA-TV/nmos-testing/tree/master/test_data/BCP00301.
The following test suite within the NMOS Testing Tool will be used to enable these tests:● BCP-003-01: BCP-003-01 Secure Communication
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_01: TLS Protocols● test_02: TLS Ciphers● test_03: Certificate does not use IP addresses in CN/SANs● test_04: HSTS Header● test_05: Certificate revocation method is available● test_06: OCSP Stapling● test_07: Certificate is valid and matches the host under test
● test_08: Server exposes both an RSA and ECDSA certificate● test_09: Server exposes a valid chain of trust including a certificate and intermediate

22/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.
Registries that implement BCP-003-01 Secure Communication shall subsequently be tested using
HTTPS via the secure mode of the NMOS Testing Tool, i.e., by configuring it with ENABLE_HTTPS
set to True.
If the test fails, then for the subsequent tests, the DuT shall be tested using HTTP (unsecured).

B.2 Registry APIs & Behaviour
Description: This set of tests validates the behaviour of an IS-04 Registry implementation. Tests
will be carried out using the NMOS Testing Tool. See the Appendix for usage instructions.
First steps: Any required network interface(s) of the Device under Test (DuT) will be connected to
network ports of appropriate speed and media type. The vendor will be asked to provide the IP
address(es) and port(s) which the IS-04 Registration API and IS-04 Query API are running on. The
vendor will be asked to configure their device as necessary.
The following test suite within the NMOS Testing Tool will be used to enable these tests:● IS-04-02: IS-04 Registry APIs
IS-04 Registries will be tested using the highest API version which they support, with a minimum
supported version of v1.2 expected for this event.
The following tests will not be used as they cover unnecessary items for TR-1001:● test_01: Registration API advertises correctly via mDNS
● test_02: Query API advertises correctly via mDNS

B.2.1 Registry API Schema Conformance
Description: Tests that the Registry’s IS-04 Registration API and Query API exposes all of the
expected resources, and that each of these conforms to the JSON schema included in thespecification.
Validation method: Execution of the NMOS Testing Tool, using the following tests with
MAX_TEST_ITERATIONS set to 0 (the default) for full coverage:● auto_query_1 - auto_query_20: Schema validation of GET and OPTIONS requests
Note: Many of these test cases require some resources to be registered in the Registry under Test. The JT-NM Tested teamwill handle this as described above (see B.).

●

auto_registration_1 - auto_registration_4 and auto_registration_7: Schema validation of
GET and OPTIONS requests

23/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

B.2.2 Registration
Description: Tests that the IS-04 Registration API behaves as expected, accepting valid
registrations from Nodes, and rejecting invalid registrations. Ensures that the ‘garbage collection’mechanism specified as part of the Registry operates correctly and removes stale data from thedatabase after a default timeout period.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_03: Registration API accepts and stores a valid Node resource● test_03_1: Registration API responds with correct Location header● test_03_2: Registration API accepts and stores a valid Node resource containing unicodecharacters● test_04: Registration API rejects an invalid Node resource with a 400 HTTP code● test_05: Registration API accepts and stores a valid Device resource● test_06: Registration API rejects an invalid Device resource with a 400 HTTP code● test_07: Registration API accepts and stores a valid Source resource● test_08: Registration API rejects an invalid Source resource with a 400 HTTP code● test_09: Registration API accepts and stores a valid Flow resource● test_10: Registration API rejects an invalid Flow resource with a 400 HTTP code● test_11: Registration API accepts and stores a valid Sender resource● test_11_1: Registration API accepts and stores a valid Sender resource with null flow_id● test_12: Registration API rejects an invalid Sender resource with a 400 HTTP code● test_13: Registration API accepts and stores a valid Receiver resource● test_14: Registration API rejects an invalid Receiver resource with a 400 HTTP code● test_15: Registration API responds with 200 HTTP code on updating a registered Node● test_16: Registration API responds with 200 HTTP code on updating a registered Device● test_17: Registration API responds with 200 HTTP code on updating a registered Source● test_18: Registration API responds with 200 HTTP code on updating a registered Flow
● test_19: Registration API responds with 200 HTTP code on updating a registered Sender● test_20: Registration API responds with 200 HTTP code on updating a registered Receiver● test_26: Registration API responds with 400 HTTP code on posting a resource withoutparent● test_27: Registration API cleans up Nodes and their sub-resources when a heartbeat
doesn't occur for the duration of a fixed timeout period● test_28: Registry removes stale child-resources of an incorrectly unregistered Node● test_30: Registration API accepts heartbeat requests for a Node held in the Registry● test_32: Registration API generates 409 code when a conflicting registration exists

24/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

B.2.3 Basic Querying(Required from standalone Registry. Desired for NMOS Controller with embedded Registry.)
Description: Tests that the IS-04 Query API behaves as expected, specifically ensuring that it ispossible to create and delete WebSocket subscriptions, and that these return the correct data as itis created via the Registration API.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_29: Query API supports websocket subscription request● test_29_1: Query API websocket subscription requests default to the current protocol● test_31: Query API sends correct websocket event messages for UNCHANGED (SYNC),ADDED, MODIFIED and REMOVED
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

B.2.4 Advanced Querying(Required from standalone Registry. Desired for NMOS Controller with embedded Registry.)
Description: Tests that the optional features of an IS-04 Query API are present and behave as
expected. Ensures that basic and advanced querying, pagination, downgrade and ancestry queries
meet the specification where implemented.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_21_1: Query API implements pagination (no query or paging parameters)● test_21_1_1: Query API implements pagination (when explicitly requested)● test_21_2: Query API implements pagination (documentation examples)● test_21_3: Query API implements pagination (edge cases)● test_21_4: Query API implements pagination (requests that require empty responses)● test_21_5: Query API implements pagination (filters that select discontiguous resources)● test_21_6: Query API implements pagination (bad requests)● test_21_7: Query API implements pagination (updates between paged requests)● test_21_8: Query API implements pagination (correct encoding of URLs in Link header)● test_21_9: Query API implements pagination (correct protocol and IP/hostname in Link
header)● test_22: Query API implements downgrade queries● test_22_1: Query API subscriptions resource does not support downgrade queries● test_22_2: Query API WebSockets implement downgrade queries

25/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
●
●
●
●
●

test_23: Query API implements basic query parameters
test_23_1: Query API WebSockets implement basic query parameters
test_24: Query API implements RQL
test_24_1: Query API WebSockets implement RQL
test_25: Query API implements ancestry queries
Note: This test case relies on at least one Source being registered in the Registry under Test. The JT-NM Tested team willhandle this as described above (see B.).

Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

B.3 System Parameters
Description: This set of tests validates an implementation of the AMWA IS-09 System API, which
may be provided by an NMOS Registry or independent service. Tests will be carried out using the
NMOS Testing Tool. See the Appendix for usage instructions. These tests are expected to be
carried out in an isolated network environment.
The following test suite within the NMOS Testing Tool will be used to enable these tests:● IS-09-01: IS-09 System API
Validation method: Execution of the NMOS Testing Tool, using the following tests with
MAX_TEST_ITERATIONS set to 0 (the default) for full coverage:● auto_system_1 - auto_system_5: Schema validation of GET and OPTIONS requests
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

C. NMOS Controller Tests
This set of tests validates an NMOS Controller under Test’s (NCuT) ability to query an IS-04
Registry with the IS-04 Query API and to control a Media Node using the IS-05 Connection API.
NOTE: It can be desirable that Controllers are capable of discovering and operating with an IS-04
Query API. Controllers which are tightly coupled to a specific Registry implementation without
using the IS-04 Query API of an external Registry are allowed, however the tests C.1 Discovery ofMedia Nodes will be marked as “failed/not supported”.
Tests will be carried out using the NMOS Testing Tool. See the Appendix for usage instructions.
These tests are expected to be carried out in an isolated network environment.

26/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
Where Controllers are tested to ensure they respond to changes in the IS-04 Registry, they will be
expected to indicate any changes within 30 seconds. This is based upon a perceived user
expectation as opposed to a figure from a specification. In practice, Controllers which make use of
the preferred WebSocket connection mechanism should be able to respond far quicker than this.
First steps: The management interface of the NCuT will be connected to the management
network at the appropriate speed and media type. A mock AMWA IS-04 v1.2/1.3 reference
registration service shall be available on the network once the NMOS Testing Tool is running,
reachable from each network segment, and advertised in the DNS server via unicast DNS-SD. The
vendor will be asked to configure any other parameter on their device as necessary. The vendor
will be asked to provide the IP address(es) and port which the NMOS Controller is running on (ifweb accessible), or access to a graphical user interface via other means.

C.1 Discovery of Media Nodes
Description: The NCuT should be capable of browsing an IS-04 Registry to obtain a list of online
resources and connection information. Browsing of the Query API may be performed via the
WebSocket protocol which is preferred for larger scale applications, or the RESTful API. Tests will
be performed based on the NCuT’s selected method of browsing the Registry. Where the RESTful
API is used, the NCuT must correctly implement pagination in order to pass the tests.
First steps: The NCuT will be configured with a DNS server IP address and a DNS searchdomain, either via DHCP or via manual configuration by the vendor.
The following test suite within the NMOS Testing Tool will be used to enable these tests:● IS-04-04: IS-04 Controller
The NMOS Testing Tool will be configured to use a DNS_SD_MODE of ‘unicast’. Users will need tofollow the instructions presented on the Testing Façade user interface in order to successfully run
and pass the tests in the test suite.

C.1.1 Using unicast DNS-SD to find the IS-04 Registry
Description: The NCuT shall use unicast DNS Service Discovery (DNS-SD) to locate the IS-04
Reference Registry. A DHCP server will provide all the connection details to discover the Registry.
Alternatively, manual configuration of the NCuT’s IP address, CIDR, Gateway, and DNS server
information will be permitted, but is less desirable.
Validation method: Execution of the NMOS Testing Tool, using the following test:● test_01: Ensure NCuT uses DNS-SD to find Registry.
Pass criteria for each test case:27/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2●

Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

C.1.2 Discovering registered resources via the IS-04 Query API
Description: The Query API should be able to discover all the devices that are registered in theRegistry. If using the RESTful API rather than WebSockets, Pagination must be implemented per
IS-04 APIs: Query Parameters: Pagination.
Validation method: Execution of the NMOS Testing Tool, using the following tests:● test_02: Ensure NCuT can access the IS-04 Query API.
● test_03: Query API should be able to discover all the senders that are registered in theRegistry.
● test_04: Query API should be able to discover all the receivers that are registered in theRegistry
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

C.1.3 Updating the list of resources dynamically from the IS-04 Registry
Description: The NCuT is able to update its list of resources, preferably by dynamic WebSocket
connection (if supported) or by polling the Registry with the RESTful API.
Validation method: Execution of the NMOS Testing Tool, using the following test:● test_05: Reference Sender is put offline and then back online.
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

C.2 Connection Management
Description: The NCuT shall use the IS-05 Connection API to establish (and remove) connections
between Senders and Receivers.
First steps:
The NCuT will be configured with a DNS server IP address and a DNS search domain, either via
DHCP or via manual configuration by the vendor.
The following test suite within the NMOS Testing Tool will be used to enable these tests:● IS-05-03: IS-05 Controller

28/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
The NMOS Testing Tool will be configured to use a ‘DNS_SD_MODE’ of ‘unicast’. Users will need
to follow the instructions presented on the Testing Façade user interface in order to successfully
run and pass the tests in the test suite.
Note: Current test suite uses the ‘single’ connection method of IS-05.

C.2.1 Discovering a Receiver’s Connection API via the Query API
Description: The NCuT shall be able to identify which Receiver devices are controllable via IS-05
and which are not based upon the advertisement of a relevant IS-04 Device ‘control’ entry. Devices
which omit the relevant ‘control’ must not be listed as available for control via IS-05.
Validation method: Execution of the NMOS Testing Tool, using the following test:● test_01: Identify which Receiver devices are controllable via IS-05
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

C.2.2 Instructing a Receiver to subscribe to a Sender’s Flow via IS-05
Description: All flows that are available in mock Senders should be able to be connected to mock
Receivers.
Validation method: Execution of the NMOS Testing Tool, using the following test:● test_02: Instruct Receiver to subscribe to a Sender's Flow via IS-05
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

C.2.3 Disconnecting a Receiver from a connected Flow via IS-05
Description: IS-05 provides a mechanism for removing an active connection through its API. This
test seeks to validate this operation on the NCuT UI.
Validation method: Execution of the NMOS Testing Tool, using the following test:● test_03: Disconnecting a Receiver from a connected Flow via IS-05.
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

29/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

C.2.4 Indicating the state of connections via updates received from the IS-04
Query API
Description: The Query API can monitor and update the connection status of all registereddevices. This test seeks to validate the NCuT’s ability to monitor connections that are madebetween Senders and Receivers outside on the NCuT’s control.
Validation method: Execution of the NMOS Testing Tool, using the following test:● test_04: Indicating the state of connections via updates received from the IS-04 Query API
Pass criteria for each test case:● Unless noted otherwise, the testing tool needs to indicate the ‘PASS’ state for the test case.

30/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

Appendix: Using the NMOS Testing Tool
The majority of AMWA NMOS testing will be carried out using the automated NMOS Testing Tool,available from https://github.com/AMWA-TV/nmos-testing.
If you intend to participate in NMOS/TR-1001 test of the event to confirm your Media Node orRegistry's adherence to the specifications, you must familiarize yourself with the testing tool. Referto the short video introduction, NMOS Test Tool Tutorial - Installing and using the NMOS TestingTool.
The tool can be used to test a range of NMOS specifications, but the following instructions target
how to use it for the specific testing which will be carried out at the JT-NM Tested event. The
testing tool is written in Python and is known to work on Linux and Windows.
Detailed documentation for installation and usage of the tool is hosted athttps://specs.amwa.tv/nmos-testing/, but the following is intended as a quick start guide.

Installation
●
●
●
●
●
●
●

Install Python 3.6 or above onto a computer on the same network as the Media Node (viahttps://www.python.org/downloads/ or a Linux package manager)
Install the Git version control software (via https://git-scm.com/download or a Linux package
manager)
Download the testing tool via
https://github.com/AMWA-TV/nmos-testing/archive/refs/tags/jtnm.aug2022.zip
Unzip the downloaded archive into a directory of your choice
Using the command prompt, change directory into the location of the testing tool (where
you will find a file called 'requirements.txt')
Install the tool's dependencies using Python's 'pip' package manager as follows: 'python -m
pip install -r requirements.txt'
Install the ‘SDPoker’ NodeJS dependency using the instructions in sdpoker Installation

Configuration
By default, the testing tool tests IS-04 Nodes in multicast discovery mode. For the purposes oftesting TR-1001 we need to use 'unicast' mode which does not make any multicast DNS
advertisements, but does run a mock DNS server on the testing host. Please consult Testing
Unicast Discovery for instructions on how to configure the testing tool and your Media Node (unitunder test) for this mode. If your Node cannot be configured to ignore mDNS announcements you

31/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
will need to run this testing on a network segment which is isolated from any IS-04 Registry mDNS
announcements.
Example: UserConfig.py
from . import Config as CONFIG
CONFIG.ENABLE_HTTPS = True
CONFIG.DNS_SD_MODE = "unicast"
CONFIG.DNS_DOMAIN = "tested.jt-nm.org"
CONFIG.HTTP_TIMEOUT = 2
CONFIG.CERT_TRUST_ROOT_CA = "tested.jt-nm.org.ca.cert.pem"
CONFIG.CERTS_MOCKS = ["ecdsa.mocks.tested.jt-nm.org.cert.chain.pem","rsa.mocks.tested.jt-nm.org.cert.chain.pem"]
CONFIG.KEYS_MOCKS = ["ecdsa.mocks.tested.jt-nm.org.key.pem","rsa.mocks.tested.jt-nm.org.key.pem"]
CONFIG.SDP_PREFERENCES = {"audio_channels": 16,"audio_sample_rate": 48000,"audio_packet_time": 0.125,"audio_max_packet_time": 1,"video_width": 1920,"video_height": 1080,"video_interlace": False,"video_depth": 10,"video_sampling": "YCbCr-4:2:2","video_colorimetry": "BT709","video_exactframerate": "50","video_transfer_characteristic": "SDR","video_type_parameter": "2110TPN"}

Operation
The testing tool can be run by typing 'python nmos-test.py' at the command prompt from the testing
tool's working directory. Note that in order to test with unicast DNS you will need to run thiscommand with elevated permissions. On Linux this can be achieved by prefixing the commandwith 'sudo'. On Windows you will need to open an elevated command prompt (otherwise known as
administrator mode).

32/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2
Having started the testing tool, browse to http://127.0.0.1:5000 in a web browser on the machine
hosting the tool.
Testing of NMOS Controllers also requires the Testing Façade, which can be run by typing ‘python
nmos-testing-facade.py’ at the command prompt from the testing tool’s working directory. Having
started the Testing Façade, browse to http://127.0.0.1:5001 in a web browser on the machine
hosting the tool. The Testing Façade will show instructions for users as part of the semi-automaticController test suites.
The following test suites listed in the dropdown will be used during the JT-NM Tested event for the
purposes of Media Node, Registry and Controller testing. Additional listed test suites may be used
if the event includes testing of further AMWA NMOS specifications.
● IS-04-01: IS-04 Node API● IS-04-02: IS-04 Registry APIs
● IS-04-04: IS-04 Controller● IS-05-01: IS-05 Connection Management API● IS-05-02: IS-05 Interaction with IS-04● IS-05-03: IS-05 Controller● IS-08-01: IS-08 Audio Channel Mapping API● IS-08-02: IS-08 Interaction with IS-04● IS-09-01: IS-09 System API● IS-09-02: IS-09 System API Discovery● BCP-003-01: BCP-003-01 Secure Communication
Select a test suite, and enter the IP address and port of the Node under test into the boxes. Ensurethat 'all' is selected in 'Test Selection' and press 'Run'. When the tests complete, press the‘Download JSON’ button at the top right of the page to download a copy of the results.
When executing the ‘IS-04 Controller’ or ‘IS-05 Controller’ test suite, enter the IP address and portof the Testing Façade, which by default will have an IP address of 127.0.0.1 and port number of
5001.
When executing the 'IS-04 Node API' or ‘IS-09 System API Discovery’ test suite, note that you may
need to restart your Media Node after having pressed 'Run' in order to force it to discover the test
suite's mock IS-04 Registries or IS-09 system resource. As noted in Testing Unicast Discovery, you
can increase the testing tool's 'DNS_SD_ADVERT_TIMEOUT' in order to allow enough time foryour Media Node to reboot when performing this test.

33/34

Joint Taskforce on Networked MediaJT-NM Tested August 2022 Program
NMOS/TR-1001 Test Plan v1.2

SupportIf you experience issues using the testing tool, please create an issue at
https://github.com/AMWA-TV/nmos-testing/issues and the team will be happy to assist.

34/34