Support SDP creation/processing for remaining modes of RTP operation specified by IS-05

[garethsb]

IS-05 documentation on Interpretation of SDP Files describes 7 modes of operation. A few of these are not yet implemented by nmos-cpp. If you are interested in FEC, SMPTE 2022-7 Temporal Redundancy, or RTCP, help would be welcome.

• Unicast
• Source Specific Multicast
• Operation with SMPTE 2022-5 (FEC)
• Operation with SMPTE 2022-7 - Separate Source Addresses
• Operation with SMPTE 2022-7 - Separate Destination Addresses
• Operation with SMPTE 2022-7 - Temporal Redundancy
• Operation with RTCP

[garethsb]

There are some other things that would help with building senders/receivers that support RTCP or FEC.

We should add these to nmos/json_fields.h

        const web::json::field_as_bool_or fec_enabled{ U("fec_enabled"), false };
        const web::json::field_as_bool_or rtcp_enabled{ U("rtcp_enabled"), false };

We could refactor nmos/connection_resources.{cpp,h} to support creating senders and receivers with the other RTP "parameter sets" in the spec. At the moment, e.g. make_connection_rtp_receiver_core_constraints actually adds both the "core" and "multicast" parameter set (because this is by far the most common kind of device), and there are no helper functions for the "FEC" and "RTCP" parameter sets.

[garethsb]

Also noting that an example app would need to be updated to demonstrate resolving auto for fec_mode as well as interface_ip.

nmos-cpp/Development/nmos-cpp-node/node_implementation.cpp

Line 1738 in 0718fa4

nmos::details::resolve_auto(transport_params[0], nmos::fields::interface_ip, [&] { return web::json::front(nmos::fields::constraint_enum(constraints.at(0).at(nmos::fields::interface_ip))); });

nmos-cpp/Development/nmos/connection_api.cpp

Line 896 in 0718fa4

// nmos::fields::fec_mode

[thangldw]

Hi @garethsb, I'd like to work on this issue. I've reviewed the current implementation and IS-05 v1.1.1.

I propose starting with a reviewable first slice: refactor RTP connection-resource creation into composable core/multicast/FEC/RTCP parameter sets, add the missing JSON fields, preserve the existing public API, and implement RTCP SDP parsing/generation with spec-example and round-trip tests.

Follow-up work would cover SMPTE 2022-5 FEC and SMPTE 2022-7 temporal redundancy, including SDP grammar support, auto resolution, example-node updates, and negative tests.

Would you prefer this as separate PRs, or a single combined PR? Unless you suggest otherwise, I'll keep the changes in small, independently reviewable commits and start with the parameter-set/RTCP slice.

[thangldw]

Progress update: the parameter-set/RTCP slice is in #501, and the independent temporal-redundancy slice is in #502.

Before starting the FEC slice, I want to confirm the API boundary. RFC 6364 SDP requires flow IDs, FEC encoding IDs, and optional SS-FSSI/FSSI values that are not fully derivable from the IS-05 FEC transport parameters. My proposed approach is to:

• add structured grammar for FEC-FR, fec-source-flow, fec-repair-flow, and UDP/FEC repair media descriptions;
• represent the RFC 6364-only metadata explicitly in sdp_parameters, rather than inventing encoding IDs or FSSI values;
• map one/two repair flows to the IS-05 1D/2D destination IP and port parameters;
• add the exact IS-05/RFC 6364 example, 1D/2D round trips, malformed grouping tests, and example-node fec_mode auto resolution.

@garethsb, would you prefer that generic RFC 6364 metadata model, or a narrower SMPTE 2022-5-specific helper API?

[garethsb]

Thanks for your work on these.

Two design rules that are in tension - (1) make implementation have no surprises vs. the defining spec; (2) only implement things that people will actually use.

If this can be layered, I would try:

• implementing the RFC 6364 ABNF fully in the sdp/ module (grammar, etc.), unless there are parts that are unused in practice
• implementing only what is compatible with IS-05 at the nmos/sdp* layer, and potentially even less if some variants are unused in practice

[thangldw]

Thanks, that layering makes sense. I'll follow that split in an independent FEC PR:

• In sdp/, add structured RFC 6364 converters for fec-source-flow, fec-repair-flow, and repair-window, plus the registered FEC-FR group semantics and UDP/FEC protocol. The converters will cover the RFC ABNF, including optional source tags, repair-flow preference and FSSI name/value elements, with RFC examples and malformed/range tests.
• In nmos/sdp*, keep the mapping deliberately narrower: the SMPTE 2022-5 form documented by IS-05, mapping one or two repair media descriptions to the 1D/2D FEC transport parameters. RFC-only metadata that cannot be derived from IS-05 will remain explicit SDP data; it will not be guessed.
• Update the example node so fec_mode: auto is resolved consistently with the enabled/configured FEC legs.
• Add separate tests for the RFC grammar and for the IS-05 example/1D/2D interpretation and generation, including malformed grouping and unsupported-layout cases.

I'll start with the RFC layer and its tests, then add the smaller NMOS mapping on top so the boundary remains reviewable.

[thangldw]

The layered FEC implementation is now available in #505.

It is split into two commits so the generic RFC 6364 grammar and the narrower IS-05 mapping can be reviewed independently. The PR includes the exact IS-05 example, 1D/2D text round trips, malformed/range tests, unsupported-topology handling, example-node fec_mode resolution, and a full local test run.