Algorithm in "RTP matching rules" ignores FEC/RTX/RED packets

[ibc]

If the browser selects payload 101 with ssrc 1111111 for "opus" codec, and payload 152 with ssrc 22222222 for RTX, that would mean that the receiver must be ready to handle incoming RTP packets with payload 152 and ssrc 22222222 (RTX).

But section "8.3 RTP matching rules" fails to describe that, because the ptTable and ssrcTable tables of the RTCRtpListener are just filled with parameters.encodings[i].ssrc and parameters.codecs[j].payloadType. This means that the RTX packets would be ignored according to the algorithm defined in the same section.

[aboba]

Right. Since RTX/FEC/RED is set up as a codec, the RED, RTX or FEC PT would be set in parameters.codecs[k].payloadType. However, the RTX SSRC (22222222) and PT would be set in parameters.encodings[i].rtx.ssrc and parameters.encodings[i].rtx.payloadType. In the case of FEC, (including "red+fec"), the SSRC would be set in parameters.encodings[i].fec.ssrc.

[ibc]

Thanks. So then, should SSRC 22222222 be included in the ssrcTable of the RtpListener?

[aboba]

Yes, SSRCs relating to RTX and FEC need to be added to the ssrcTable so that these streams will be routed to the correct receiver. Also, PT's related to RTX need to be added to the ptTable, so that they will be routed to the correct receiver. RED does not need special treatment, since the PT for RED will be set in the codec entry, and the SSRC for RED will be set via fec.ssrc.

[ibc]

Thanks.

[aboba]

@ibc @robin-raymond Can you review PR #394 ?

[ibc]

LGTM

[robin-raymond]

I'm going to add a set of rules that I think make sense after having implemented it.

[robin-raymond]

Here's my steps:

1. Check for MuxID - if present, add to mapped SSRC entry table and forward packet to receiver
2. Check if a known previous SSRC mapping exists, and forward to mapped receiver
3. Check for SSRC in encoding params (all encodings, RTX and FEC); if any match then create a mapped SSRC entry and forward to receiver;
4. If encodings[0..n] exist, Check payload types in encoding params where an SSRC does NOT exist; find "best" match that works (where earliest non-conflicting match works) and internally set non-set SSRC entry (i.e. lock in SSRC value) and then create an SSRC mapping and forward to mapped receiver; "Best" is where payload type is a direct match to an entry (where no SSRC value has previous been set or previously "locked-in" to a value); if none exist then where a codec matches from codec list but payload type nor SSRC is not set in the encoding; finally, the order receiver's .receive() was called originally is chosen before other receiver's .receive() called later, thus making two equally matched receivers choose one over the other.
5. If no list of encodings[0..n] were specified, then find codec payload match from codec list and create a new internal encoding to match with a filled in payload type and fill in SSRC based on the incoming packet;

If no match can be made above then fire an unhandled event for the muxid, ssrc, payload type combination.