Re: [rtcweb] JSEP: RTP demux algorithms

I’m not going to come up with beverage names for my examples, but feel free to make up your own.

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

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

On Sep 15, 2016, at 6:18 PM, Cullen Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>> wrote:

To propose a few use case….

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

On Sep 14, 2016, at 10:49 AM, Bernard Aboba <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>> wrote:

There is now a JSEP PR relating to RTP demux algorithms:
https://github.com/rtcweb-wg/jsep/pull/320

Rather than commenting in detail on that PR in this post, I would like to prove some thoughts on how we evaluate proposed RTP demux algorithms.

The goal of an RTP demux algorithm is to determine whether an incoming RTP packet received on a DtlsTransport can be forwarded to one of the RtpReceivers attached to that DtlsTransport.  If none of the RtpReceivers qualify, then the packet is either dropped (WebRTC 1.0) or generates an RTP unhandled event (ORTC).

In principle, RTP demux algorithms do not seem complicated, since they often can be expressed in less than half a dozen steps, typically with less than a page of text.

However, in practice the difficulty has turned out to be not in stating an algorithm, but in evaluating whether it is correct. This challenges include:

1. Agreement on a set of use cases and desired outcomes that a proposed algorithm must satisfy.  Think of this as a set of regression tests that insure that a proposed algorithm behaves as we expect, as well as ensuring that changes to that algorithm do not result in unintended consequences.

2. Agreement on all the inputs that the algorithm takes into account.  This includes fields within the RTP packet (e.g. SSRC, PT, RID, MID, etc.) as well as methods within the API (e.g. setLocalDescription, setRemoteDescription, setParameters, etc.).

With respect to Issue #1, some of the trickiest use cases involve both PT and SSRC signaling, SSRC "latching" and handling FEC and RTX.  Examples include:
    a. Change of SSRCs (e.g. due to conflict).
    b. Codec switching (e.g. changing PT but same SSRC, or changing both PT and SSRC).
    c. Use of both FEC and RTX (and perhaps RTX of FEC).

IMHO it would be useful to come up a few (less than half a dozen) use cases with agreed-upon outcomes.

With respect to Issue #2, the proposed algorithms so far look at the SSRC & PT fields in the RTP header as well as the MID RTP extension.  However, I have not seen algorithms which take into account the role of the RID RTP extension.  So agreement on whether the RID needs to be considered or not would be helpful.

Also, for WebRTC 1.0 it would appear to me that the algorithm will depend on the inputs to the setLocalDescription/setRemoteDescription methods, so that there is a potential dependency on the signaling state of the PeerConnection.

Overall, I believe that the discussion of RTP demux algorithms is likely to go more smoothly (and conclude more quickly) if we get agreement on these meta-issues upfront.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb