Dynamic format changes on Sender

[garethsb]

I'm struggling a bit with this section.

Changes which break Active Constraints

NMOS Controller MUST track Sender's subscription's active property during and after the IS-05 connection. If it became false unexpectedly, NMOS Controller SHOULD GET /status to figure out the reason of breaking the connection. If the State of the Sender is active_constraints_violation, then NMOS Controller SHOULD either disconnect all the Receivers or PUT /constraints/active once again and re-enable Sender via IS-05.

• This section is called "Changes which break Active Constraints" but making/breaking connections using IS-05 doesn't change the stream format. In the case of an RTP multicast Sender, making "the IS-05 connection" may not need any requests to the Sender's Connection API at all. What are the "changes" being discussed? The Controller doesn't directly ask for a stream format change, it updates the Active Constraints, and the Sender may change the format in response. Are we talking about enabling an inactive Sender via IS-05 for the first time after changing Active Constraints?
• Why "MUST" the Controller track subscription.active if it only SHOULD do anything about anything it discovers as a result?

Changes which do not break Active Constraints

Sender's changes which meet the Active Constraints do not affect the active property so if the transport file of the Sender has changed, the NMOS Controller SHOULD PATCH /staged of all the connected Receivers with the new transport_file requesting immediate activation.

• The "so" here seems strange. Is it saying that the Controller SHOULD/MUST track the IS-04 version instead of/as well as subscription.active in order to identify changes in the transport file?

[alabou]

The "Changes" that we are referring to here are about the signal flowing through the Source->Flow->Sender .. i.e. Flow attributes changes.

Changes which break Active Constraints => means that the Flow became non-compliant with the active constraints. => active_constraints_violation

Changes which do not break Active Constraints => means that the Flow may have changed but is still compliant with the active constraints. => constrained

"The "so" here seems strange" ... agreed ... the sentence indicate that even if Flow attributes have changed, the Flow may still be compliant with the active constraints, the Sender remains active and the Controller SHOULD patch the Receivers again if the SDP transport file have changed because the Receiver are assumed as not being able to continue streaming if the SDP transport file has changed.

[garethsb]

The "Changes" that we are referring to here are about the signal flowing through the Source->Flow->Sender .. i.e. Flow attributes changes

Are we talking about changes initiated by some other means than IS-11? If not, I don't understand why changes would happen that would cause constraints violation. And if so, I don't see what the relationship to making connections is.

[alabou]

Are we talking about changes initiated by some other means than IS-11?

YES: for example the HDMI captured signal changes ... the configuration of the camera changes ... anything that could change the signal associated with the Flow ..

For example my HDMI source is capturing an HD signal ... it is compliant with the current active constraints and everything is ok status.state is constrained but then suddenly the HDMI signal changes to 4K and for example say it is no longer compliant with the active constraints ... then it would cause the status.state to change to active_constraints_violation

[garethsb]

So, I think the point of this section is quite unrelated to the sequential operations described in the previous section "Active Constraints of Senders". This section is about asynchronous continuous monitoring the Senders in which the Controller is interested, in order to respond to format changes that may require intervention to maintain connections with chosen Receivers. I think we need to rewrite this.

The IS-04 spec includes a section on Controllers response to Dynamic Update of Resources. This section of IS-11 should describe the additional requirements. (Is the 30s response time in IS-04 sufficient for IS-11 use cases?!)

[alabou]

The 30sec seems to related to the appearing and disappearing of Senders/Receivers ...

Agreed that this section may need a rewrite ... It is slightly more than Dynamic Update of Resources I think because IS-11 is probably the first API to indicate how a Sender / Receiver may/must become inactive ... So it is an important issue that users of IS-11 must be aware.

[N-Nagorny]

Created #117 to cover it.