Behaviour: Client Side

Active Constraints of Sender

An NMOS Controller manages stream compatibility using the Active Constraints of the Sender. The Active Constraints of the Sender are expressed as BCP-004-01 Constraint Sets that restrict the stream the Sender can transmit.

Building the Constraint Sets

The Controller MAY build these Constraint Sets by processing the Receiver Capabilities of one or more Receivers, or directly to represent User requirements.

The Controller MUST GET /constraints/supported from the Sender to determine the supported Parameter Constraints. If the Sender does not support all the Parameter Constraints needed to express the User requirements or used in the Receiver Capabilities, the Controller SHOULD inform the User about it.

Constraint Sets built from Receiver Capabilities SHOULD represent a consensus among the Receivers, satisfying all (by default) or some (depending on User preferences) of the Receivers. If the Controller cannot build any Constraint Sets that represent a consensus, the Controller SHOULD inform the User that not all of the chosen Receivers can be satisfied at the same time.

For example, there are Receiver A, Receiver B, Receiver C with equal Receiver Capabilities consisting of Constraint Sets 1, 2, 3, 4, 5 and Receiver D with Constraint Sets 2, 3, 4, 5, and 6 which is incompatible with the previous ones. In this case the consensus is Constraint Sets 2, 3, 4, 5 which are common for all four Receivers.

The Controller MAY allow the User to control how the consensus is obtained, providing preferences to the Controller among the Receivers and the Constraint Sets of each Receiver and criteria about the size of the consensus.

The urn:x-nmos:cap:meta:preference property in Constraint Sets of Receiver Capabilities indicates relative preference between Constraint Sets of that Receiver. The Controller MAY use these values to make a decision about how to process these Constraint Sets and determine preference of Constraint Sets of Active Constraints. It SHOULD NOT propagate values of this property as is from Receiver Capabilities to Active Constraints.

The urn:x-nmos:cap:meta:preference property in Constraint Sets of Active Constraints indicates relative preference between Constraint Sets of the Active Constraints of the Sender. The Controller MAY fill in this property in Constraint Sets based on any additional information about Receivers.

For example, if the User in any way informs the Controller that Receiver D has precedence over the consensus of Receivers A, B, C and urn:x-nmos:cap:meta:preference values of Receiver D state that Constraint Set 6 has higher preference than Constraint Sets 2, 3, 4, 5, then the Constraint Sets could be 2, 3, 4, 5, 6 where Constraint Set 6 has the highest preference.

Constraint Sets of Receiver Capabilities with urn:x-nmos:cap:meta:enabled set to false MUST be ignored completely during this process.

Using the Constraint Sets

If changing the configuration of the Sender, the Controller MUST PUT /constraints/active to the Sender to replace the Active Constraints. In case of changing the configuration of an active Sender, deactivating the Sender MAY be necessary. The Sender indicates that the Active Constraints cannot currently be updated with the 423 (Locked) response.

If keeping the configuration of the Sender, the Controller SHOULD GET /constraints/active from the Sender and evaluate these Active Constraints against the Constraint Sets it has built. If the current Active Constraints allow streams, that would not be compliant with the Constraint Sets it has built, the Controller SHOULD inform the User that compatibility of the Sender’s stream with the chosen Receivers cannot be assured without replacing the Active Constraints.

After this the Controller can make connections via IS-05.

Subsequently, after breaking these connections via IS-05, the Controller is RECOMMENDED to DELETE /constraints/active of the Sender after making it inactive.

The Controller MAY also change the configuration of the Sender without establishing an IS-05 connection.

Dynamic Update of Resources

The Controller uses Stream Compatibility API in conjunction with IS-04 APIs to discover and track the state of any relevant resources, including Inputs, Outputs, Senders and Receivers.

The Controller MUST indicate whether each Sender/Receiver discovered via IS-04 APIs is present in Stream Compatibility API and indicate statuses of such Senders/Receivers
The Controller MUST report to the User when state attribute of the status of a Sender remains active_constraints_violation or no_essence after a maximum of 30 seconds.
The Controller SHOULD report to the User when state attribute of the status of an active Receiver becomes non_compliant_stream.
The Controller SHOULD be capable of performing PATCH /staged of all the connected Receivers with the new transport_file requesting immediate activation when the related active Sender updates the transport file.
The Controller SHOULD indicate statuses of Inputs and Outputs and indicate the Inputs associated to a given Sender and Outputs associated to a given Receiver for Senders/Receivers listed in Stream Compatibility APIs.
The Controller SHOULD reflect changes in presence/absence of Inputs and Outputs to the User after a maximum of 30 seconds.

←Behaviour - Server Side · Index↑

Documentation built at 04:52:23 CDT on 2024-08-29.
(c) AMWA 2024. RAML/JSON licensed under Apache 2.0. Documentation licensed under CC BY-ND 4.0.