We have trouble understanding how Nodes and Clients should behave in some 2022-7 "corner cases".
There was a discussion (#68) about a mismatch of the amount of legs in a PATCH
request. The conclusion of that discussion was, a PATCH
must always contain the exact amount of legs as announced on the /constraints
endpoint.
This means, it is not directly possible to PATCH
the transport_params
of a 1-legged sender onto a 2-legged receiver without modification. The Client must manually add a second empty object to the transport_params
to make it a valid request.
On the other hand, in the 4.1. Behaviour - RTP Transport Type document the following is stated:
Where a Receiver supports SMPTE 2022-7 but is required to receive a non-SMPTE 2022-7 stream, only the first set of transport parameters should be used. rtp_enabled in the second set of parameters must be set to false and transport parameters in the SDP file should be mapped onto that first set of parameters in the array.
Where a Receiver does not support SMPTE 2022-7 but receives a SMPTE 2022-7 transport file containing two sets of transport parameters it is recommended that it parses the first set of transport parameters found in the file and joins the stream as if it were a non-SMPTE 2022-7 stream. This ensures compatibility with Senders which do not support operation in a non-SMPTE 2022-7 mode.
The quoted text makes the assumption, that for example a 2-legged receiver receives a PATCH
with only 1 leg, therefore he should just rtp_enable=false
his second, unused leg. The other case is, that a receiver receives a PATCH
containing transport_params
for 2 legs, but only supports 1, therefore he should neglect the second leg.
Regarding the discussion in #68 and it's changes on the spec, the conditions described in the quote are invalid.
Where should the logic reside?
Should the Client take care of the different amount of legs or should the Node act intelligent and take care of this mismatch.
Best what I can read from the current intersection of the specs & the schema is the following:
- a
PATCH
containing a different amount of legs compared to the 'to-be-patched' transceiver should be discarded by the Node
- the Client should take care of differences in these cases by adding empty objects (
{}
) in the transport_params
array.*
(*) In some cases even more: if we want to PATCH
a one-legged sender onto a receiver who currently has 2 active legs, the Client must even include a rtp_enabled=false
in the missing leg to prevent having a receiver in a complete messed up state.