Change:
Reference transceiver direction as opposed to "active" senders/receivers We initially thought there would be an "active" bit on senders/receivers to control the direction of a media description, but instead we now have a "setDirection" API on the transceiver. So we should reference that.
lgtm

Discussion:
3.4.2. RtpSenders allow the application to control how RTP media is sent. <del> In particular, the application can control whether an RtpSender is active or not, which affects the directionality attribute of the associated m= section. </del> 3.4.3. RtpReceivers allows the application to control how RTP media is <del> received.  In particular, the application can control whether an RtpReceiver is active or not, which affects the directionality attribute of the associated m= section. </del> <ins> received. </ins> 3.5.

policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line. <del> If the RtpSender of the RtpTransceiver associated with this m=section is active: </del> <ins> If the RtpTransceiver has a sendrecv or sendonly direction: </ins> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2.

and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <del> If the RtpTransceiver's RtpSender is active, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified.  The "a=rid" line is specified in I-D.ietf-mmusic-rid, and its direction MUST be "send".  If the application has chosen a RID value, it MUST be used as the rid-identifier; otherwise a RID value MUST be generated by the implementation.  When generating RID values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-avtext-rid, Section 11.  If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. If the RtpTransceiver's RtpSender is active and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in I-D.ietf-mmusic-sdp-simulcast, Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. </del> <ins> If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified.  The "a=rid" line is specified in I- D.ietf-mmusic-rid, and its direction MUST be "send".  If the application has chosen a RID value, it MUST be used as the rid- identifier; otherwise a RID value MUST be generated by the implementation.  When generating RID values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in I-D.ietf-avtext-rid, Section 11.  If no encodings have been specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in I-D.ietf-mmusic-sdp- simulcast, Section 6.2.  The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. </ins> The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a

MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. <del> If the RtpSender of the RtpTransceiver associated with this m=section is active: </del> <ins> If the RtpTransceiver has a sendrecv or sendonly direction: </ins> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2.

RtpTransceiver. If no RtpTransceiver was found in the previous step, create <del> one with an inactive RtpSender and active RtpReceiver. </del> <ins> one with a recvonly direction. </ins> Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid