Change:
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

Discussion:
7. <ins> 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 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. 8. </ins> Note that this example section shows several SDP fragments.  To format in 72 columns, some of the lines in SDP have been split into multiple lines, where leading whitespace indicates that a line is a

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

The SDP for |answer-A1| looks like: <del> 7.2. </del> <ins> 8.2. </ins> This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE

maintain the existing DTLS roles, and the use of a=recvonly to indicate that the video streams are one-way) <del> 8. </del> <ins> 9. </ins> The IETF has published separate documents I-D.ietf-rtcweb-security- arch I-D.ietf-rtcweb-security describing the security architecture

Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates. <del> 9. </del> <ins> 10. </ins> This document requires no actions from IANA.