RE: RTP matching rules and JSEP Section 7

Here is how the rules proposed in JSEP Section 7 appear to stack up against the proposed use cases.

"Whiskey & Soda Example"
The PT are all the same. Early packets, and any packets after a SSRC change, contain a MID. If the packet has  MID, it goes to the place that matches that MID *and* it latches that SSRC so any future SSRC that don't have a MID go the to the same place.

[BA] I believe that the proposed rules handle this use case. The early packets with a MID will match the configured MID and will latch an entry into the SSRC_table so that future packets without a MID will be routed to the same RtpReceiver.

"Coke Classic Example"
The PT are all unique. The SSRC changes. There is no RID, MID, FEC, or RTX. The packets get delivered to the thing with the matching PT.

[BA] I believe that the proposed rules handle this use case.  If there is no SSRC match, the PT_Table is consulted and since the PT are all unique, a match will be found there.

"Bloody Mary Example"
The PT are the same. The SSRC do not change and are signaled in SDP. There is no MID, RID, etc in the RTP.  The packets go to the thing the SSRC signaling would have indicated.

[BA] I believe that the proposed rules handle this use case.  The SSRC table is consulted first, and as long as a match is found, the packet will be routed to the matching RtpReceiver.

"Diet Coke Example"
The PT are all unique. The packet has a MID. The MID corresponds to an m-line that does not have PT associated with it that matches the PT in the packet. (the PT is from a different m-line). The packets gets dropped (or causes an event in ORTC). Note: I think of this that the MID sends it to the right m-line aka Receiver, but then that does not have a codec for that PT so it gets dropped.

[BA] The proposed rules as written do not handle this use case.  Here the proposed rules will route the packet to an RtpReceiver based on MID.  The rules do not describe what happens next, but presumably the RtpReceiver will check the PT field against the PTs configured for that RtpReceiver and will drop the packet.  Should an unhandledrtp Event be fired?  Probably.  So some additional text may be needed in the JSEP Section 7 rules.

"Diet Pepsi Example"
The PT are all unique. The packet has a SSRC. The SSRC does not correspond to any SSRC that were signaled for the m-line that the PT is on. The packet goes to the thing associated with that PT ignoring any SSRC.

[BA] The proposed rules handle this use case.  There is no SSRC match, so the PT_Table is consulted and a match is found.

"Red Bull Example"
The packet has a MID that does not match any MID in the signaling. The packets gets dropped (or event in ORTC).

[BA] The proposed rules handle this use case, since a MID mismatch results in a packet drop (SSRC and PT tables are not consulted). Should an unhandledrtp Event be fired in this case?  Probably.

Codec change, case 1: The PTs are all unique, and no SSRCs were signaled in SDP  There is no RID, MID, FEC or RTX. Sender switches codecs, and the PT changes (but SSRC stays the same).  The packet goes to the receiver that matches the new PT.

[BA] The proposed rules handle this use case. Since the proposed rules do not have SSRC latching based on PT matches, as long as the new PT is in the PT_Table there will be a match.

Codec change, case 2:  The PTs are all unique and SSRCs are signaled in SDP.  There is no RID, MID, FEC or RTX. Sender switches codecs and the PT changes (but SSRC stays the same).  SSRC does not match any signaled ones.  The packet goes to the receiver that matches the new PT.

[BA] The proposed rules handle this use case. Since there is no SSRC match and no PT latching, as long as the new PT is in the PT_Table there will be a match.

Conflicting PT examples:

Conflict, case 1:  The PTs are all the same and SSRCs are signaled in SDP.  There is no RID, MID, FEC or RTX.  SSRC changes from one that was signaled in the SDP to one that is not signaled (could be due to SSRC conflict).

[BA] The proposed rules do not define the behavior for this case. If there had been a MID, the packet would be routed to the RtpReceiver matching that MID and the SSRC would latch so that future packets would be directed to that RtpReceiver.  Without a MID or a matching SSRC we need to decide whether this packet should be dropped (and if so, whether it would generate an unhandledrtp event) or whether it should be routed to the first matching PT entry.  My personal take is that the packet should be dropped.