Networked Media Open Specifications
HOME DOCS SPEC... VERSIONS... GITHUB INFO... TOOLS... IS-XX... MORE... SEARCH

Discovery: Registered Operation

←Discovery · Index↑ · Discovery - Peer to Peer Operation→

(c) AMWA 2016, CC Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)

This document describes usage of NMOS APIs for discovery in cases where where a distributed registry is available.

Registration

  1. Node comes online
  2. Node scans for an active Registration API on the network using unicast and/or multicast DNS service discovery (type ‘_nmos-registration._tcp’)
  3. Given multiple returned Registration APIs, the Node orders these based on their advertised priority (TXT pri), filtering out any APIs which do not support its required API version and protocol (TXT api_ver and api_proto).
    • Where a Node supports multiple API versions simultaneously, see the Upgrade Path for additional requirements in filtering the discovered API list.
  4. The Node selects a Registration API to use based on the priority, and a random selection if multiple Registration APIs of the same API version with the same priority are identified.
  5. Node proceeds to register its resources with the selected Registration API.

If the chosen Registration API does not respond correctly at any time, another Registration API should be selected from the discovered list. Should no further Registration APIs be available or TTLs on advertised services expired, a re-query may be performed.

If no Registration APIs are advertised on a network, the Node should assume peer to peer operation unless configured otherwise. The required TXT record advertisements for this mode are described in the Node API.

Querying

  1. Node (or control interface) comes online
  2. Node scans for an active Query API on the network using unicast and/or multicast DNS service discovery (type ‘_nmos-query._tcp’)
  3. Given multiple returned Query APIs, the Node orders these based on their advertised priority (TXT pri), filtering out any APIs which do not support its required API version and protocol (TXT api_ver and api_proto).
    • Where a Node supports multiple API versions simultaneously, see the Upgrade Path for additional requirements in filtering the discovered API list.
  4. The Node selects a Query API to use based on the priority, and a random selection if multiple Query APIs of the same version with the same priority are identified.
  5. Node proceeds to request data as required from the selected Query API.

If the chosen Query API does not respond correctly at any time, another Query API should be selected from the discovered list. Should no further Query APIs be available or TTLs on advertised services expired, a re-query may be performed.

If no Query APIs are advertised on a network, the Node should assume peer to peer operation (if supported) unless configured otherwise.

←Discovery · Index↑ · Discovery - Peer to Peer Operation→