Potential implementation guidance / spec clarifications

[garethsb]

Questions from @maweit on AMWA Slack that we think are worth tracking to clarify in the spec or an accompanying INFO doc...

We're having difficulties to judge if an activation request is erroneous. We cannot catch all failure modes against constraints. Constraints can express only a very basic set of restrictions and cannot catch all cases. Example: senders and receivers that support IS-05 control but are restricted to a subset of AES67.
Should these additional restrictions be applied to /staged or can it be deferred to activation time?
There are activations coming from controllers with master_enable=true but all rtp_enabled=false. How to deal with this? What is the intention of sending such an activation request?
What to populate on staged and active endpoints if activation does not come from NMOS-IS-05 (i.e. user interface)?
More specifically, what address to use in the second entry of transport_params for senders that support 2022-7 but are configured not to use it (i.e. through the UI).
Related to the above, what addresses to use in transport_params for senders that have not been configured at all?

[garethsb]

Taking questions one at a time... First, you can reject PATCH requests for other reasons besides schema and constraints validation, including for example identifying unsupported stream via the SDP transport_file in a Receiver. However, the quirk is that such rejection has to be reported via 500 not 400.

So if you can identify the issue at staging time, then do so, as in the case of scheduled activations it ensures the client gets an immediate error rather than having to watch for a failed/missed activation later.

Activations with master_enable true but all rtp_enabled false sound very odd... although are valid.

Activations that are made by device specific means, e.g. front panel, web UI or non-NMOS API, should be reflected into /active when they happen for certain. The rule for IS-04 /target interop with IS-05 was that such immediate activations would also be applied to /staged so that a partial PATCH activation via IS-05 subsequently would use the most recent params. That seems like a reasonable device behaviour generally to me...

The other parameters on a leg that is rtp_enabled false should have no effect on the stream... but should be consistent with the SDP /transportfile for Senders, so it is a good question. source_port and destination_port are required to have sensible defaults applied when the controller stages "auto" so those defaults would make sense as values in the case you describe. The same goes for source_ip, destination_ip and interface_ip. Receiver multicast_ip can be null reasonably enough...

The sensible defaults for Sender destination_ip and Receiver source_ip have been discussed before... I seem to remember some vendors using 0.0.0.0 and others using random SSM addresses.

Of course after initialization, such PATCHes also have the option of just leaving the existing values on the disabled leg alone.

[peterbrightwell]

Architecture Review Group review: place on backlog