Check for traffic shaping

[rbgodwin]

In the current code the caller must specify --shaping in order that the 2110-20 check is ran to check for 2110-21 items. SMPTE2110-22 (the version on the IEEE site) mandates use of 2110-21 with specific parameters. When I implement the test I will for the first cut also allow skipping the test to avoid inconsistencies with the existing code.

Question is - should this test be mandatory for 2110-20 and 2110-22? In which case I think we should remove the --shaping parameter or override it if we can key off of SSN in the fmpt values.

[garethsb]

I agree, ST 2110-20 and -22 require compliance to -21, so I'm not sure why this feature was originally added as an option in Streampunk/sdpoker@b7fe59e, disabled by default.

I think as the number of different RTP payload formats we need to handle increases, we will need flags on sdpoker to set expectations of the SDP data we want to find, as there's a kind of chicken-and-egg problem with confirming that an SDP file correctly indicates ST 2110-22 support. SSN is optional in ST 2110-22:2022 (and didn't exist in :2017), so the only thing that would distinguish ST 2110-22 compliance from an underlying RTP payload format would be the TP format-specific parameter.
So rather than shaping, for now we assume the SDP file must be compliant to one or other ST 2110 spec, and these tests should always be enabled. If we support non-ST 2110 RTP payload formats, we may need an --st2110 option.

[rbgodwin]

Looks like this parameter (--shaping) might be there in order to run sdpoker on SDPs that are audio (2110-30). So that makes sense to have it. If we keep the --smpte2110-22 flag we can turn on shaping tests automatically so no need to specify --shaping.

[garethsb]

Can you explain that, @rbgodwin ? I see the ST 2110-21 checks are also disabled by audioOnly, I don't see that shaping is related to audio...