IS-05: Automate remaining workshop/interop checklist items for RTP Senders and Receivers

[garethsb]

Based on the most recent interop checklists, the following items remain to be automated if possible. NB: Not all test cases are applicable for all Device Classes.

AMWA NMOS Connection Management (IS-05) Checklist

Version 1.2 (2nd July 2018)

Section 2: API Operation with RTP Senders and Receivers

• [x] 2.1 The sr-ctrl type is advertised against the IS-04 device with the correct HREF for each device the API represents
• [x] 2.2 When a sender or receiver is registered to an IS-04 device, it is populated in the connection management API
• [x] 2.3 When a new sender or receiver is added to the API, its staged and active transport parameters are set to reflect their current state
• [x] 2.4 When a sender or receiver is removed from a device, it is removed from the connection management API
• [x] 2.5 Changes to staged parameters have no impact on the behaviour of streams from/to senders/receivers
• [x] 2.6 When new parameters become active they have the expected effect on streams from/to senders/receivers
• [x] 2.7 Senders make available a transport file for the “tuning” of receivers, which matches the one available from manifest_href advertised via the Node API
• [x] 2.8 When senders receive updates to their transport parameters, these are correctly reflected in an update to its transport file.
• [ ] 2.9 Senders and receivers should express any restrictions on available parameters (for example available source IP addresses for senders) in their constraints
• [ ] 2.10 All instances of “auto” settings are interpreted as per the specification
• [x] 2.11 Sender and receivers list their available interfaces under source_ip and interface_ip under constraints along with an “auto” option.
• [ ] 2.12 Senders and receivers are able to be configured for multicast operation via the API
• [ ] 2.13 Senders and receivers are able to be configured for unicast operation via the API

[garethsb]

W.r.t. 2.1 The sr-ctrl type is advertised against the IS-04 device with the correct HREF for each device the API represents, 2.2 When a sender or receiver is registered to an IS-04 device, it is populated in the connection management API, 2.7 Senders make available a transport file for the “tuning” of receivers, which matches the one available from manifest_href advertised via the Node API, these may form part of #16.

[simonrankine]

2.3 - This is very hard to test. Some devices may not even be able to dynamically add/remove senders or receivers if they represent hardware. Also, the test suite has now way to assess "current state" 2.4 - See above 2.5 - We can only test this by ingesting the streams and checking them 2.6 - See above. 2.8 - This should be tested by making changes to the transport params, downloading the SDP and then checking it correctly advertises the new parameters. This is harder than it sounds because you need to respect the constraints of the sender when you set the params. 2.9 - Best you can do here is try a few values that meet the constraints and make sure nothing crashes, more of a smoke test really. 2.10 - Set everything that can be set to 'auto' in /staged, activate then check that 'auto' doesn't turn up in /active, and that the values there are at least sane. 2.12 - Best you can do is prod the relevant transport params in and check it doesn't fall over 2.13 - See above

[garethsb]

Completely agree with all of those comments, and I think we ought to just drop 2.3-2.6. They're almost "not our business"?

2.10 - Set everything that can be set to 'auto' in /staged, activate then check that 'auto' doesn't turn up in /active, and that the values there are at least sane.

And conform to the "the behaviour [that] is very clearly defined in the relevant transport parameter schemas" for many values... (e.g. auto destination_port must be 5004)