Behaviour
←Interoperability - Non-NMOS Devices · Index↑ · Behaviour - RTP Transport Type→
Re-Activating Senders & Receivers
If an explicit activation is performed against a Sender or Receiver, the API must request a re-application of settings to the underlying Sender or Receiver implementation whether the setting have changed or not. For example in the case of multicast Receivers it is suggested that this involves an explicit IGMP leave and join. For a Sender this may involve stopping and re-starting the stream.
Transport Files & Caching
It is strongly recommended that the following caching headers are included via the /transportfile endpoint (or whatever this endpoint redirects to).
Cache-Control: no-cache
This is important to ensure that connection management clients do not cache the contents of transport files which are liable to change.
Multi-Client Operation
In environments where multiple clients may be operating against a single Connection Management API, it is possible that staging of parameters may result in conflicts. There is intentionally no mechanism to prevent this in the API, however clients should examine the results of HTTP PATCH operations which will return the full complement of current settings, allowing the client to confirm that only the changes it had requested have been made.
‘Salvo’ Operation
Where a server implementation supports concurrent application of settings changes to underlying Senders and Receivers, it may choose to perform ‘bulk’ resource operations in a parallel fashion internally. This is an implementation decision and is not a requirement of this specification.
←Interoperability - Non-NMOS Devices · Index↑ · Behaviour - RTP Transport Type→