RTP matching rules: don't remove pt_table[packet.pt]

[ibc]

Else if pt_table[packet.pt] is set: set rtp_receiver to pt_table[packet.pt], set ssrc_table[packet.ssrc] to rtp_receiver, set pt_table[packet.pt] to null and route the packet to rtp_receiver.
Question: Do we remove all pt_table[packet.pt] entries set to rtp_receiver?

Don't remove them. If the sender changes the SSRC (without signaling it to us) the RTP packet won't match any rule.

[ibc]

...because remember: "SSRCs can collide at any time because they are just 32 bits long !!!" so every RFC and RTP related spec must waste at least 10 lines to prevent this "probable" issue.

[ibc]

Even more: this problem also happen when encoding.ssrc is given. In that case, "RTP matching rules" do not fill the pt_table which means that, if the sender changes the SSRC, packets won't match anything.

So, two things:

• Fill pt_table always, even if ssrcs are given.
• Don't remove entries from pt_table.

[aboba]

@robin-raymond This Issue appears to exist in your proposed matching algorithm if an SSRC were previously specified or was locked and is then changed (e.g. due to a conflict). So Step 4 below may not be correct:

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;
6. If no match can be made above then fire an unhandled event for the muxid, ssrc, payload type combination.

[ibc]

Guys, there is a problem if we always store the PT values in the ptTable regardless ssrc was also signaled:

Many rtpReceivers may use the same transport to receive streams from many senders (example: a SFU forwarding N streams over the same transport). In such a scenario we want that all those senders are able to use the same PT:

• This is required in BUNDLE and those PTs must refer to the same codec+configuration.
• In pure ORTC the same PT may refer to different codecs.

So, the RtpListener of the transport cannot place a single PT entry in ptTable for a single rtpReceiver because there could be many rtpReceivers using the same PT over the same transport.

[ibc]

Friendly ping.

[aboba]

@ibc You are correct. It is not an error for multiple RtpReceivers to utilize the same PT value, since they can receive the correct stream via the SSRC (or muxId). Note that in the original routing rules, a PT_table entry is only created if all of the parameters.encodings[i].ssrc is unset. So if multiple receivers were to specify the same PT, this would not be a problem as long as each specified an SSRC. However, if more than one receiver left all of the parameters.encodings[i].ssrc unset, then an error would result since pt_table[pt] is already set to a value other than receiver. This is in fact a problem because it means that two receivers had registered to receive packets with the same PT value, regardless of SSRC.

Overall, I think this points out the complexity of the routing rules - and the difficulty of verifying that proposed changes do not result in regressions. It makes me wonder if we need to develop test cases that we run through whenever we propose changes.

[ibc]

After implementing it, my conclusions are:

• ptTable MUST NOT be filled if ssrcs are given for all the encodings and all the encoding.rtx.ssrc and encoding.fec.ssrc.
• If ssrcs are not given, ptTable must be filled and, on RTP packet receipt, the ssrcTable must be filled with the packet SSRC.
  • However, the corresponding entries in ptTable MUST NOT be removed (this is because SSRCs may change in the future).

So this is a kind of "first-come first-served" or, in other words, just the first of many rtpReceivers over the same transport can just signal PT values without signaling also SSRCs.

Some working test units here: https://github.com/ibc/mediasoup/blob/master/test/test_RtpReceiver.js#L23

[aboba]

@ibc I have consolidated all the proposed matching rule changes into PR #555 so we can review all of them in one place.

One issue that is not yet addressed is handling of RTX/RED/FEC. As you say, ptTable should not be filled for RTX if encoding.rtx.ssrc is set and for FEC if encoding.fec.ssrc is set. For RED, ptTable should not be filled if encoding.ssrc is set for the RED codec. Need to revisit this if/when the object model changes.

[aboba]

Robin believes that his algorithm doesn't exhibit this issue either. So we have assigned it to him :)

[aboba]

Routing Rules PR in JSEP: rtcweb-wg/jsep#320

[aboba]

Thread in RTCWEB WG: https://mailarchive.ietf.org/arch/msg/rtcweb/QnN6PBpIM-U5Q1NKvr64b2l8Vms

[aboba]

@ibc @robin-raymond In JSEP Section 7 rules, PT_Table entries are not removed, and there is no latching of SSRCs due to PT matches.

JSEP Section 7 rules do fill the PT table even if SSRCs are specified, though the PT table is only consulted if there is no MID or SSRC match. There is no statement about errors if PTs are not unique, so maybe there needs to be some arbitration mechanism (e.g. first PT_Table entry wins, last entry wins, etc.).

So the requests seem to be fulfilled:

Fill pt_table always, even if ssrcs are given.
Don't remove entries from pt_table.

Do you think that the JSEP Section 7 rules resolve this issue?

[aboba]

@ibc @robin-raymond - Can you check whether this issue is resolved by PR #602 (which is based on JSEP Section 7)?

[aboba]

It looks to me like this Issue is addressed by the JSEP Section 7 rules. The proposed algorithm does not remove pt_table entries, although it does latch on PT reception. If the SSRC changes, incoming packets will still be routed. Also when encoding.ssrc is given, the proposed algorithm still fills the pt_table entry.

The proposed algorithm also supports "first-come first-served" allowing the first of many rtpReceivers signaling a PT values to be routed packets with that PT, regardless of whether a muxID or SSRCs were provided.

[aboba]

JSEP rules have changed:
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-17#page-66

[aboba]

@ibc @robin-raymond @pthatcherg The JSEP Appendix B RTP matching rules appear to address this issue, correct?
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-18#appendix-B

The proposed rules do not remove pt_table entries except if PT overlap is created by a call to receive().
SSRC latching is included which should handle the SSRC change case.
pt_table entries are filled, regardless of whether encodings[].ssrc, encodings[].rtx.ssrc or encodings[].fec.ssrc are given, as long as PT does not overlap.

[aboba]

I believe that this issue has ben resolved in the current draft. Please reopen if it is not fixed.