mandatory check for source filters in presence of multicast

[rbgodwin]

The SMPTE 2110 tests require a source filter in the SDP file when a multicast address is used for media. RFC 4570 Section 3 does not require a source filter. This test should be removed?

[garethsb]

I think you're referring to checkRFC4570, test_30_2, is that right? This was introduced by @andrewbonney's commit: 244f7ae

I also recollect guidance that Source-Specific Multicast (SSM) should be used, and that SSM requires the use of a source-filter in the SDP... But I'm not sure where I've remembered that from, and I agree it doesn't seem to be found in RFC 4570 or ST 2110-10. 🤔

[andrewbonney]

Yes it looks like this might be in the wrong place. I suspect I put it there knowing it came from an RFC rather than SMPTE doc, but perhaps it should have been in its own file.

JT-NM TR-1001 does have a 'SHOULD' for including source-filters (specifically Senders should include source address information in the SDP.).

Personally I think it should be very strongly flagged to implementations when this is missing. It's very straightforward for a Sender to include the information, but if it's omitted a Receiver simply can't operate in SSM mode, making the Sender incompatible with SSM-only networks for a very simply omission.

[garethsb]

Thanks, @andrewbonney, I agree. I hadn't thought to look for the context in TR-1001-1 .

Quoting from section 10.3 Multicast Media Streams,

Media Nodes [...] shall use the source-specific method if the source address information is provided in the SDP. [...] Senders and Receivers shall support the entire range of multicast addresses [...], including the ability to request SSM across this whole range.

Senders should include source address information in the SDP.

So, (a) could be refactored into a different suite, and (b) could use the params.should mechanism... though let's first discuss whether downgrading this error is the right thing to do.

[rbgodwin]

I'd be in favor or moving into 'should' using the param and then communicating to vendors that we strongly recommend that all their implementations follow the "should". I'm thinking also that it might be a good idea to include TR-1001-1 tests in sdpoker so that when for instance there i no source in the SDP and params is set to strict (should) then we reference the location in the specs that is failing to avoid discussions about where the tests came from.

Are we testing only SMPTE conformance or more broad conformance to specs including TR-1001-1, TR-08 etc? We can add tests that reference these specs also.

[garethsb]

I'd be in favor or moving into 'should' using the param and then communicating to vendors that we strongly recommend that all their implementations follow the "should".

I think that makes sense... how about we make the default for should be True?

Are we testing only SMPTE conformance or more broad conformance to specs including TR-1001-1, TR-08 etc?

The latter - whatever the industry finds will improve interoperability!
Just, as you said, we should factor the test suites appropriately and reference the locations in the relevant specs to be clear where the requirements/recommendations come from.