Change:
More examples of SDP for WebRTC call flows can be found in I- D.nandakumar-rtcweb-sdp. <del> 7.1. </del> <ins> 8.1. </ins> This section shows a very simple example that sets up a minimal audio / video call between two browsers and does not use trickle ICE.  The

Discussion:
I think this is close enough to merge it, put it out in a draft, and see what the WG things
This LGTM.
overall, this looks like it's on the right track. Main question (for NAME really) is whether this should be turned more into prose rather than a W3C-style algorithm. (i.e. "First, check this. Then, do that. Next, do this other thing. Finally, drop the packet.")
Peter, if there is anything I can do to help on this one today. Ping me and I will make it top priority.
A response to Bernard's comment about when the tables are constructed: I think it's clear that the tables need to be constructed after the transport exists, but before the first packet is routed. But an implementation could choose whether to construct it right after the transport is created or right before the first packet is routed. I don't think we need to specify that. You do bring up a really good point about updating the table over time. We know entries can be added by setLocalDescription/setRemoteDescription and removed by setLocalDescription/setRemoteDescription and URL But that's not covered at all by the text written so far.
FYI, I updated this to address Bernard's comment about updating the tables over time. I added a paragraph saying what the results of updates should be, but leaves the when and how up to the implementation.
Cover MID, RID, unsignaled SSRCs, and RTCP. Related to and .
Suggest doing this in a new Section 5.10 on demux.
Actually, now that I think about it, we don't need to specify how to handle RID at all. We could just way "receive all the source RTP streams that come in and use RtpStreamID and RepairedRtpStreamID to correlate source RTP streams and repair RTP streams". In other words, the RIDs don't need to be signalled to the receiver.

If I'm correct about this, we can have a simplified version: When an RtpReceiver is added, removed, or has its parameters modified, the following is done:
We had discussion during IETF that there is a need for a RTP media plane specification related to simulcast and the different types of RTP middleboxes to clarify where the various SDES items need to occur and which types of SSRC, MID and RID switching behavior that can occur on the various legs. This will clearly spark discussion as there was diverse views between Emil Ivov, Bernard Aboba, and Jonathan Lennox. Varun Singh had observed I think 4 different behaviours.
Need to not forget the case where there are multiple ports that help disambiguate.
For the case of multiple ports: I think all we need to do is point out that the algorithm applies to each of the RtpReceivers listening on a given port. In other words, demux is per-port. And obviously if you have only one RtpReceiver per port, there's nothing to do except check that the PT is known, which I think the algorithm I posted covers.
This looks reasonable except that the style is a bit inconsistent. specifically: for each encoding e in r.getParameters().encodings: receiverbyssrc[URL] = r
Here's some possible text, with slightly tweaked pseudo-code to match: When an RTP packet is received by a transport (typically a DtlsTransport), that packet MUST 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, let the key be the RtpReceiver's MID, and the value be the RtpReceiver. 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, let the key be the SSRC and the value be the RtpReceiver. 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, let the key be the Payload Type and the value be the RtpReceiver.

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. Drop the packet. Note: When designing these steps, a troubling possible use case was if the MIDs were lost in signaling, but still sent in RTP packets. But a packet would only be sent with MIDs if an answer were sent with MIDs in it. If there are no MIDs in the answer, then MIDs would not be present in the RTP. And if MIDs are in the answer, they weren't lost from the signaling. In other words, this case will not happen. This would correspond to pseudocode something like this:
PR: URL
Resolved by
Submitted some thoughts. As usual, the devil is the details. This overall LGTM. A handful of editorial comments. LGTM