Original text:
Construct a table mapping MID to RtpReceiver for each RtpReceiver configured to receive from this transport. <del> 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. </del>  Construct a table mapping payload type to RtpReceiver for each RtpReceiver configured to receive from this transport and for each 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: MID to RtpReceiver, drop the packet and stop. If the packet has a MID and that MID is in the table mapping MID <del> to RtpReceiver, update the SSRC mapping table to include an entry mapping the packet's SSRC to the RtpReceiver. </del>  <del> If the packet's SSRC is in the SSRC mapping table, route the packet to the mapped RtpReceiver and stop. </del>  If the packet's payload type is in the payload type table, update <del> 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. </del>  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 <del> 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. </del>  7.

Reviewer comments:
Fixes URL URL
LGTM
I made a bunch of edits to cover how the different types of RTCP packets should be handled, including compound RTCP packets. I also tweaked the RTP text slightly to be more consistent with the RTCP text. NAME NAME NAME PTAL.
NAME can you take a look?
LGTM
Fixed by
If the RTCP SDES has a MID value, update the SSRC mapping table for that SSRC to map to the receiver associated with that MID
This LGTM

Revised text:
Construct a table mapping MID to RtpReceiver for each RtpReceiver configured to receive from this transport.  <ins> Construct a table mapping incoming 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 present in the m= section corresponding to that RtpReceiver in the remote description. Construct a table mapping outgoing SSRC to RtpSender for each RtpSender configured to transmit from this transport and for each SSRC that RtpSender is configured to use when sending. </ins> Construct a table mapping payload type to RtpReceiver for each RtpReceiver configured to receive from this transport and for each the RtpReceiver whose m= section appears earliest in the local description. <ins> As RtpTransceivers (and, thus, RtpReceivers) are added, removed, stopped, or reconfigured, the tables above must also be updated. </ins> For each RTP packet received, the following steps MUST be followed to route the packet: MID to RtpReceiver, drop the packet and stop. If the packet has a MID and that MID is in the table mapping MID  <ins> to RtpReceiver, update the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the RtpReceiver for that MID. </ins>  <ins> If the packet's SSRC is in the incoming SSRC mapping table, deliver the packet to the associated RtpReceiver and stop. </ins> If the packet's payload type is in the payload type table, update  <ins> the the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the RtpReceiver for that payload type.  In addition, deliver the packet to the associated RtpReceiver and stop. </ins> Otherwise, drop the packet. <ins> For each RTCP packet received (including each RTCP packet that is part of a compound RTCP packet), the following type-specific handling MUST be performed to route the packet: If the packet is of type SR, and the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC.  In addition, for each report block in the report whose SSRC is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC. If the packet is of type RR, for each report block in the packet whose SSRC is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC. If the packet is of type SDES, and the sender SSRC for the packet is found in the incoming SSRC table, deliver the packet to the RtpReceiver associated with that SSRC.  In addition, for each chunk in the packet that contains a MID that is in the table mapping MID to RtpReceiver, update the incoming SSRC mapping table to include an entry that maps the SSRC for that chunk to the RtpReceiver associated with that MID.  (This case can occur when RTCP for a source is received before any RTP packets.) If the packet is of type BYE, for each SSRC indicated in the packet that is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC. If the packet is of type RTPFB or PSFB, as defined in RFC4585, and the media source SSRC for the packet is found in the outgoing SSRC table, deliver the packet to the RtpSender associated with that SSRC. </ins> After packets are routed to the RtpReceiver, further processing of the RTP packets is done at the RtpReceiver level.  This includes  <ins> using I-D.ietf-mmusic-rid to distinguish between multiple Encoded Streams, as well as determine which Source RTP stream should be repaired by a given Redundancy RTP stream.  If the RTP packet's PT does not match any codec in use by the RtpReceiver, the packet will be dropped. </ins> 7.