AMWA-TV
[IS-05-02] Should tests on RTP senders and receivers consider their unicast/multicast support?
An IS-05 sender or receiver with the /transporttype of urn:x-nmos:transport:rtp may support both unicast and multicast or only one or the other.
But it looks like test cases like IS-05-02 test_07 through test_11 do not check that and assume both unicast and multicast are supported.
In a Sender or Receiver, the IS-04 transport_type may indicate the constrained subtypes ...rtp.mcast or ...rtp.ucast.
With IS-05, a Receiver's transport_params may indicate lack of support for multicast by omitting the multicast_ip parameter. However, there is no way to indicate lack of support for unicast, except via /constraints. Similary, with IS-05, a Sender's only means to indicate it does not support unicast or multicast is via /constraints.
E.g.
https://github.com/AMWA-TV/nmos-testing/blob/9bcb054e37df6d8c03b76119a25a29198b4559cd/nmostesting/suites/IS0502Test.py#L239
- IS-05 /transporttype is useless as it removes the mcast/unicast suffix as per the JSON schema "Transport type URN base used by the Sender or Receiver (i.e. with any subclassifications or versions removed)"
- IS-04 transport property is the easiest way to specify support for mcast/ucast using the suffix if only either mcast or ucast is supported and not using a suffix if both are supported.
- IS-05 /constraints is the ultimate way of verifying what a Sender/Receiver supports and no matter what other properties indicate, the constraints shall have the final word.
