Change in size of transport_params

[aholzinger]

Hi,

when patching (http PATCH) staged parameters for a sender or receiver the merge fails if the current transport_params array size differs from the transport_params array size in the patch (see handle_connection_resource_patch in connection_api.cpp).

Does this mean that a once configured redundant (transport_params array size > 1) sender or receiver can and shall not be operated in a single stream mode?

In other words: Shall a redundant configured receiver not being able to to receive a non-redudnant stream?

As a second point:
The array size of the transport_params array is checked, but the number of streams inside the SDP (transport_file) is not check when merging. To me this is not consistent, is it?

[Gareth Sylvester-Bradley]

A client needs to be explicit when updating the transport_params, so to set up to receive a single-legged stream on the first leg of a ST 2022-7 capable Receiver:

  "transport_params": [
    {
      "rtp_enabled": true,
      "destination_port": ...
    },
    {
      "rtp_enabled": false
    }
  ]

A client can also stage changes to only one leg or other by including an empty object for the other leg.
E.g.

  "transport_params": [
    {},
    {
      "destination_port": ...
    }
  ]

the number of streams inside the SDP (transport_file) is not check when merging. To me this is not consistent, is it?

It is checked and handled specifically. With transport_params the client has full control over which parameters of which leg are to be updated. With a transport_file, a -7 capable is required to handle both single-legged and two-legged SDP files. The spec describes how the Node must update the transport parameters for both legs when it receives a single-legged SDP file - it updates the transport parameters of the first leg, and sets the second leg as "rtp_enabled": false.

[aholzinger]

Great, thanks Gareth for the (alwasy) detailed and (always) prompt explanation.