Subject: [rtcweb] Thoughts on JSEP Section 7

From: Bernard Aboba <[email-masked]>
Date: Fri, 30 Sep 2016 15:06:23 -0700

IMHO, the RTP routing rules in JSEP Section 7 are a good start.  Aside from
addressing Jonathan's comments about handling of RTCP SDES packets (which
can set MID mappings), here are some thoughts on how the rules handle the
use cases we have been discussing:

Here is how the rules proposed in JSEP Section 7 appear to stack up against
the basic proposed use cases. Overall, I think a bit more detail is needed
with respect to matching of PT values, but the rules seem to be OK.

“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.  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).

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.

Where the rules perhaps have some gaps is in use cases with conflicting
PTs. This isn't really due to a deficiency in the rules, but rather due to
gaps in the BUNDLE document.  If BUNDLE described what should happen in
these cases, the rules in JSEP Section 7 could be updated to support that
guidance. But with no guidance, it's hard to write proposed rules.

A conflicting PT example:

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.