Driver - NMOS Client (Generic)
Driver implemented in: vsmGadgetServer
Summary
This document provides information about the NMOS Client protocol implementation for VSM.
| Status of Driver | APPROVED |
|---|---|
| Component for Driver | GADGETSERVER |
| Release (Build) of Component | vsmGadgetserver 5.6.1.100 |
| Revision of Implementation | 1.0.2.0 or higher |
Connection
Connection Type | HTTP (no websocket, no MQTT) |
|---|---|
Default Port |
NMOS communication is via Http and currently this implementation only supports Http, no Websockets or MQTT.
Currently there is no support for IS-04 Registration and Query API's.
Supported Features
- Browse all devices via IS-04 Node API, where always the highest version will be selected.
- Find published IS-05 API's.
- Provide all senders and receivers of the device with their IS-05 streaming parameters and SDP's. Only active/ and staged/ paths are currently supported, where activation time is always set to now for stream patching.
Supported Commands
| HTTP | GET, PATCH, HEAD |
|---|---|
| IS-04 | x-nmos/node/v1.0-v1.3, -devices/, -self/, -senders/, -receivers/ |
IS-05 | x-nmos/connection/v1.0-v1.1, -single/, -single/senders, -single/receivers/ |
Supported Devices (Lab tested)
| Manufacturer | Device Type | Version |
|---|---|---|
| Riedel | ARTIST AES67-108 | 8.0 |
| Embrionix | emSFP | 3 |
Configuration UI
Status
| Name | Give this connection any name to identify it. |
| Protocol Status | Indicates protocol status |
| Connection | Indicates connection status |
| Active Address | Indicates address driver is connected to |
Port Settings
| Addresses | Leave this field empty, device addresses are configured via Device List |
| Stream Type | Set this field to "Virtual" |
| Binding | Set to "any" |
Mapped To
No settings required here.
Settings
| Logging | Activate the logging for this NMOS client connection |
| Subscription Poll Intervall | Set to any value to force a poll interval for subscribed parameters in [s]. It is recommended to increase the interval, the more devices are connected. |
| Device List | Link to a csv file containing details about devices grouped into this NMOS client connection. See below for details. |
| Transport Parameter HoldOff | Set to -1 for off. Waiting Time in [ms] until system sends a parameter. This setting is only relevant if system is configured to sends native multicast parameters, but no SDP data. |
| Tree Layout | Select "Default" to render the tree layout natively. Set to "Mapping" for custom layout. |
| Network Mapping | Link to mapping file for custom tree layout definition. |
Configuration Details
Currently there is no support of Registration and Query API, therefore this driver speaks directly to the devices. All devices must be specified in a .csv formatted file, which must be uploaded to the driver's “Device List”.
Stream Type
Set this value to "Virtual".
Disconnecting SDP
Driver version 1.0.8.0 introduces a way to define the sdp disconnect type per node.
empty(default) generates:transport_file.data=””(empty string)transport_file.type=”application/sdp”
nullgenerates:transport_file.data=nulltransport_file.type=null
Please note, that you need to edit the csv file to enable the null mode, if not set it will use the empty mode
Message Timeout
Driver version 1.1.4.0 introduces a new csv header type: messageTimeout. It can be defined for slow devices, which might respond to commands with "timeouts". Check the logfile for details. This value is in seconds and if left blank uses 2 seconds as default.
CSV Example
nodeEndpoint,nodeName,sdpDisconnectType,messageTimeout
10.1.2.3:1234,Sender 1,null
http://10.2.3.4:8080,Receiver1,empty
10.3.4.5:4200,SenderAndReceiver1
10.3.4.6,VerySlowDevice,null,15Subscription Poll Interval
A proper “Subscription poll interval” should be selected (the bigger the system, the higher).
Mapping
Driver version 1.1.0.0 and higher (vsmGadgetServer.Net 5.6.1.139) supports mapping of nodes/device/signals to be able to support the exchange of nodes or devices. To generate the ember+ tree following the setting in the mapping file, the protocol option Tree Layout should be set to Mapping. Default mode will use the nmos guids as identifiers! Next driver releases may use the Mapping layout as default.
Since the ordinary vsmGadgetServer XML mapping format is not designed to support multilevel mapping the NMOS Client introduces an JSON based mapping file.
The following sample describes a node with a single device which provides 3 receivers and senders each. A node can be seen as a frame and is always the top level of each nmos element. Device can be seen as a slot/card within the parent node. A node may contain multiple devices. A device may contain a list of receivers and/or senders.
[
{
"index": 0,
"nmos_id": "deadbeef-3059-1000-8000-000000000030",
"brief": "Nmos Node 1",
"type": 0,
"nmos_devices": [
{
"index": 0,
"nmos_id": "deadbeef-3059-1000-8000-000000000031",
"brief": "Nmos Device 1",
"type": 1,
"nmos_receivers": [
{
"index": 0,
"nmos_id": "deadbeef-3059-1000-8000-000000000024",
"brief": "hdmi-audio CH 0",
"type": 2
},
{
"index": 1,
"nmos_id": "deadbeef-3059-1000-8000-000000000025",
"brief": "hdmi-audio CH 1",
"type": 2
},
{
"index": 2,
"nmos_id": "deadbeef-3059-1000-8000-000000000026",
"brief": "hdmi-audio CH 1",
"type": 2
},
],
"nmos_senders": [
{
"index": 0,
"nmos_id": "deadbeef-3059-1000-8000-000000000027",
"brief": "hdmi-audio CH 0",
"type": 2
},
{
"index": 1,
"nmos_id": "deadbeef-3059-1000-8000-000000000028",
"brief": "hdmi-audio CH 1",
"type": 2
},
{
"index": 1,
"nmos_id": "deadbeef-3059-1000-8000-000000000028",
"brief": "hdmi-video CH 1",
"type": 2
},
]
}
]
}
]If NMOS Device 1 gets exchanged/permanently unavailable, the new device NMOS Device exchanged needs to be online and detected by this driver, see Configuration - cvs file. A new entry NMOS Device exchanged will be generated within NMOS Node 1.nmos_devices with an “index”: 1. To map NMOS device exchanged to the old path within the ember+tree, the user needs to download the mapping file via option Network Mapping and change at least the index of NMOS Device exchanged to “index”: 0 (index of NMOS Device 1).
If the receivers/senders layout of the new device correlates with the old, the mapping process is finished and the file can be saved and uploaded to the NMOS client driver instance again. Otherwise an edit of the corresponding signals is required.
The result should look like:
[
{
"index": 0,
"nmos_id": "deadbeef-3059-1000-8000-000000000030",
"brief": "Nmos Node 1",
"type": 0,
"nmos_devices": [
{
"index": 0,
"nmos_id": "deadbeef-3059-1000-8000-000000000031",
"brief": "Nmos Device 1",
"type": 1,
"nmos_receivers": [
{
"index": 0,
"nmos_id": "deadbeef-3059-1000-8000-000000000024",
"brief": "hdmi-audio CH 0",
"type": 2
},
{
"index": 1,
"nmos_id": "deadbeef-3059-1000-8000-000000000025",
"brief": "hdmi-audio CH 1",
"type": 2
},
{
"index": 2,
"nmos_id": "deadbeef-3059-1000-8000-000000000026",
"brief": "hdmi-audio CH 1",
"type": 2
},
],
"nmos_senders": [
{
"index": 0,
"nmos_id": "deadbeef-3059-1000-8000-000000000027",
"brief": "hdmi-audio CH 0",
"type": 2
},
{
"index": 1,
"nmos_id": "deadbeef-3059-1000-8000-000000000028",
"brief": "hdmi-audio CH 1",
"type": 2
},
{
"index": 1,
"nmos_id": "deadbeef-3059-1000-8000-000000000028",
"brief": "hdmi-video CH 1",
"type": 2
},
]
},
{
"index": 0,
"nmos_id": "000f9b03-3059-1000-8000-000000000031",
"brief": "Nmos Device exchanged",
"type": 1,
"nmos_receivers": [
{
"index": 0,
"nmos_id": "000f9b03-3059-1000-8000-000000000024",
"brief": "hdmi-audio CH 0",
"type": 2
},
{
"index": 1,
"nmos_id": "000f9b03-3059-1000-8000-000000000025",
"brief": "hdmi-audio CH 1",
"type": 2
},
{
"index": 2,
"nmos_id": "000f9b03-3059-1000-8000-000000000026",
"brief": "hdmi-audio CH 1",
"type": 2
},
],
"nmos_senders": [
{
"index": 0,
"nmos_id": "000f9b03-3059-1000-8000-000000000027",
"brief": "hdmi-audio CH 0",
"type": 2
},
{
"index": 1,
"nmos_id": "000f9b03-3059-1000-8000-000000000028",
"brief": "hdmi-audio CH 1",
"type": 2
},
{
"index": 1,
"nmos_id": "000f9b03-3059-1000-8000-000000000028",
"brief": "hdmi-video CH 1",
"type": 2
},
]
}
]
}
]