And to add some RID based one … 

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


> On Sep 15, 2016, at 3:18 PM, Cullen Jennings <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 <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
>