Closed aholzinger closed 2 years ago
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
.
Great, thanks Gareth for the (alwasy) detailed and (always) prompt explanation.
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?