search

AMWA-TV / nmos-testing

Testing tool for the AMWA NMOS Specifications
https://specs.amwa.tv/nmos-testing/
Apache License 2.0
38 stars 48 forks source link

IS-05-01: test_25 doesn't wait before checking the SDP #504

Open lautran opened 4 years ago

lautran commented 4 years ago

IS-05-02 - test_25 – Immediate activation of a sender is possible => FAIL : SDP file for Sender dbe263d3-8ecc-44c1-8269-322761ed519d does not match the transport_params: SDP destination port 12805 does not match transport_params: 26875

This test is failing on our setup but we're not quite sure how to tackle it. Unlike the IS-05-02 tests, this one doesn't wait for processing time before checking the change in the SDP file. Similar to the IS-04 API update, the result of this action takes some time to be visible in our SDP.

On one hand, I see the benefit of having everything updated when the action returns. On the other hand, the SDP contains extra information that cannot be changed in IS-05. And processing those extras affects the system performance wise. Most of the time, the response of the IS-05 is sufficient. An instant SDP update would only be useful when a reconfig of a sender must be immediately followed by a SDP connection.

So I wonder we should aim accuracy or focus on responsiveness of the system in this case, similar to the IS-05 and IS-04 interaction ?

garethsb commented 4 years ago

Clients that use activate_immediate care about the operation having been completed synchronously. Clients that don't care should use activate_scheduled_relative with "requested_time": "0:0".

garethsb commented 4 years ago

@andrewbonney, do you think we can close this as invalid, as the spec is clear that the difference between a scheduled activation and an immediate activation is that "the API should only return a response once the new transport parameters have been applied to the underlying sender." Do we need to clarify this with the error message or with a More Information link?

andrewbonney commented 4 years ago

I feel like this isn't the first time it's come up, so clarifying via either of those methods might be worth it. I agree that the issue can be closed though.

lautran commented 4 years ago

Woops, I just realize that I forgot to react to your response due to a crazy workload and other the circumstances.

I agree, we can close this. A More Information link might indeed be worth it. Even a link to the NMOS documentation on the first page of the test suite. I've came across people who were less familiar with NMOS, used nmos-testing but weren't sure where to find the full NMOS specifications.

Also, An activate_scheduled_relative with "requested_time": "0:0" when we don't care about the response is a nice trick. Noting it somewhere might also be useful.