RE: RTP matching rules and JSEP Section 7

Here is how the rules proposed in JSEP Section 7 appear to apply to the open ORTC API issues.

Issue 368<https://github.com/w3c/ortc/issues/368>: RTP matching rules ignores FEC/RTX/RED

My interpretation of the proposed JSEP Section 7 rules is that SSRC table entries would be added for FEC and RTX, as well as PT entries for media codecs, as well as FEC/RTX/RED.
In ORTC terms, we would have PT_Table entries for parameters.codecs[k].payloadType as well as SSRC_table entries for
 parameters.encodings[i].fec.ssrc,  parameters.encodings[i].rtx.ssrc, and parameters.encodings[i].ssrc

So it appears to me that the proposed rules would resolve this issue.

Issue 546<https://github.com/w3c/ortc/issues/546>: RTP matching rules when no encoding.rtx.ssrc is given

In the proposed rules, PT entries are added to the PT_Table regardless of whether a muxId is set, or whether SSRCs are provided in parameters.encodings[i].fec.ssrc,  parameters.encodings[i].rtx.ssrc, and parameters.encodings[i].ssrc.
So it appears to me that the proposed rules would resolve this issue as well.

Issue 547<https://github.com/w3c/ortc/issues/547>: RTP matching rules: don't remove pt_table[packet.pt]

The proposed rules do not remove PT_Table entries.  So this issue would also appear to be resolved.

From: Bernard Aboba
Sent: Friday, September 30, 2016 2:26 PM
To: public-ortc@w3.org
Cc: 'Iñaki Baz Castillo' <ibc@aliax.net>; Robin Raymond <robin@myjoe.com>
Subject: RTP matching rules and JSEP Section 7

Currently, ORTC API has the following issues open relating to RTP matching rules:

Issue 368<https://github.com/w3c/ortc/issues/368>: RTP matching rules ignores FEC/RTX/RED
Issue 546<https://github.com/w3c/ortc/issues/546>: RTP matching rules when no encoding.rtx.ssrc is given
Issue 547<https://github.com/w3c/ortc/issues/547>: RTP matching rules: don't remove pt_table[packet.pt]

Since WebRTC 1.0 API now has RtpSender/RtpReceiver, the issue of RTP matching rules has come up in IETF RTCWEB WG as well, and to address the issue,
draft-ietf-rtcweb-jsep-16 has added a Section 7 with rules for routing of RTP packets (see below).

Also, there has been discussion on the IETF RTCWEB mailing list about how to evaluate proposed routing rules.  To that end, the following use cases have been proposed:

Basic use cases (from Cullen): https://www.ietf.org/mail-archive/web/rtcweb/current/msg16073.html
Additional use cases (from me): https://www.ietf.org/mail-archive/web/rtcweb/current/msg16074.html
Jonathan's RTCP use cases: https://www.ietf.org/mail-archive/web/rtcweb/current/msg16079.html

There is some disagreement on whether RIDs should be used for routing to an RtpReceiver, or only within an RtpReceiver.  This comes down to whether a RID can be used by itself (without MID) or whether when a RID is present, MID will always be in use (either present in the same packet or previously present and "latching" SSRCs).  For now, let us assume that MID is the primary routing mechanism, and that RID is not used by itself.

Cullen proposed RID use cases: https://www.ietf.org/mail-archive/web/rtcweb/current/msg16075.html
Peter's argument against use of RID for routing: https://www.ietf.org/mail-archive/web/rtcweb/current/msg16078.html

I have collected the use cases at the end of the message.

What I would like to propose is for the ORTC CG to discuss how the rules proposed in JSEP Section 7 stack up against the ORTC API open issues, as well as the proposed use cases.
7<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-16#section-7>.  Processing RTP packets



   Note: The following algorithm does not yet have WG consensus but is

   included here as something concrete for the working group to discuss.



   When an RTP packet is received by a transport and passes SRTP

   authentication, that packet needs to be routed to the correct

   RtpReceiver.  For each transport, the following steps MUST be

   followed to prepare to route packets:



      Construct a table mapping MID to RtpReceiver for each RtpReceiver

      configured to receive from this transport.



      Construct a table mapping SSRC to RtpReceiver for each RtpReceiver

      configured to receive from this transport and for each SSRC that

      RtpReceiver is configured to receive.  Some of the SSRCs may be

      presesnt in the m= section corresponding to that RtpReceiver in

      the remote description.



      Construct a table mapping payload type to RtpReceiver for each

      RtpReceiver configured to receive from this transport and for each

      payload type that RtpReceiver is configured to receive.  The

      payload types of a given RtpReceiver are found in the m= section

      corresponding to that RtpReceiver in the local description.  If

      any payload type could map to more than one RtpReceiver, map to

      the RtpReceiver whose m= section appears earliest in the local

      description.



   For each RTP packet received, the following steps MUST be followed to

   route the packet:



      If the packet has a MID and that MID is not in the table mapping

      MID to RtpReceiver, drop the packet and stop.



      If the packet has a MID and that MID is in the table mapping MID

      to RtpReceiver, update the SSRC mapping table to include an entry

      mapping the packet's SSRC to the RtpReceiver.



      If the packet's SSRC is in the SSRC mapping table, route the

      packet to the mapped RtpReceiver and stop.



      If the packet's payload type is in the payload type table, update

      the the SSRC mapping table to include an entry mapping the

      packet's SSRC to the RtpReceiver.  Deliver the packet to the

      RtpReceiver and stop.



      Otherwise, drop the packet.



   After packets are routed to the RtpReceiver, further processing of

   the RTP packets is done at the RtpReceiver level.  This includes

   using [I-D.ietf-mmusic-rid<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-16#ref-I-D.ietf-mmusic-rid>] to determine which RTP streams depend on

   or repair other RTP streams.



   As RtpTransceivers (and, thus, RtpReceivers) are added, removed,

   stopped, or reconfigured, the tables above must also be updated.





Core 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.

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

"Bloddy Mary Example"
The PT are the same. The SSRC do not changed and are signalled in SDP. There is no MID, RID, etc in the RTP.  The packets go to the thing the SSRC signalling would have indicated.

"Diet Coke Example"
The PT are all unique. The packet has a MID. The MID corresponds to a an m-line that does not have PT associated with it that match the PT. (the PT is from a different m-line). The packets gets dropped (or cause 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. ]

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

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

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.

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.


Jonathan's RTCP use cases
(same as "Whiskey and Soda" example above, but based on RTCP SDES packets containing MID, rather than RTP):

The PT are all the same.  An RTCP source description for an SSRC contains a MID.  This latches the MID.  Later, RTP packets with this SSRC arrive without a MID. They go to the place matching the MID that was in RTCP.

The PT are all the same.  A packet contains MID1.  It goes to the place that matches MID1, latching the SSRC to MID1.  Later, a packet with the same SSRC contains MID2. This moves the latching, so the SSRC is now latched to MID2.


Cullen's RID use cases
(currently assuming these are not needed for routing to an RtpReceiver, only within it)

"Double Expresso"
The PT are all the same. There are MIDs. There are RIDs. When a packet with a MID and RID drives, the MID is used to find the correct m-line, then if and only if there is a RID in that m-line that matches, the packet is delivered to the place associated with that a=rid line. Any future packet with the same SSRC but no RID or MID would go the same place.

"Capuchino"
All the PT are unique. There is no MID or RID in the RTP packet but the SDP has unique PT in every RID line in every "a=rid" line. The packet is sent to the stuff associated with that a=rid line.

"Decaf Carmel Non-Fat Latte"
Packets is discard (or even in ORTC) for any of the following cases:
(Decaf) There is a MID but the PT does match a PT for that m-line. (Carmel) There is a MID and RID but the RID does not exist in that m-line. (Non-fat) There is RID and PT but the PT does not match the set of PT allowed for that RID.