Change:
Justin, this isn't done, but PTAL and see if you think it's going in the right direction.
looks on right path to me
My only issue with this is what happens if you get an offer that does not do mux, I think it should be accepted regardless of what this is set to. I think this should be purely about what is generated in offer. Other than that it looks good.
We should discuss this on today's call. Justin and I spent a while on it last time and one of the relevant arguments was consistency. Specifically, say you have two endpoints, one of which is old (i.e., pre-WebRTC) and doesn't support mux at all and the other of which is set to "require", i.e., only do mux. With the current text, any attempt between these two to communicate will fail. If you only apply these polices to the offer, however: If the old endpoint is the offerer, then it will not offer mux but the WebRTC endpoint will accept it and the call will succeed. If the new endpoint is the offerer, then it will only provide mux candidates and the call will fail in a fairly ugly fashion. The point being that the current text allows you to fail fast.
lgtm
Push -f due to rebase screwup. Cullen and I discussed this PR and he is unconvinced that we should fail when the offer does not include mux but the answerer has set "require". In the interest of landing the rest of this, I have added an issue and an open issue section in the draft. URL Cullen, Justin, if this is acceptable LMK and I will merge this PR in.
This seems fine to me - good topic to discuss in Dallas, if we are still of two minds at that point.
NAME can you confirm this matches your expectations?
LGTM and this open issue is not a huge deal one way or the other
Cullen thinks it should accept and non-mux. EKR and Justin currently believe it should reject the offer.
Original text: when acting as answerer will reject any m= section that does not provide an "a=rtcp-mux" attribute.
LGTM at IETF 92
open issue in text to be removed

Discussion:
application request, and therefore the default candidate pool size MUST be zero. <del> Lastly, the application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic- sdp-bundle-negotiation.  By specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together.  The set of available policies is as follows: </del> <ins> The application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp- bundle-negotiation.  By specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together.  The set of available policies is as follows: </ins> The application will BUNDLE all media streams of the same type together.  That is, if there are multiple audio and multiple video

candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints. <del> Similar to max-bundle, but RTCP candidates are not gathered.  This policy reduces the candidates that must be gathered to the absolute minimum, but will not be compatible with legacy endpoints that do not support RTCP mux. </del> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST be set to "balanced". <ins> The application can specify its preferred policy regarding use of RTP/RTCP multiplexing RFC5761 using one of the following policies: The browser will gather both RTP and RTCP candidates but also will offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. The browser will only gather RTP candidates.  [[OPEN ISSUE: how should the answerer behave.  https://github.com/rtcweb-wg/jsep/ issues/114]] This halves the number of candidates that the offerer needs to gather. </ins> 4.1.2. The createOffer method generates a blob of SDP that contains a

immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded. <del> Any changes to the BUNDLE policy take effect immediately, i.e. any future tracks added to the PeerConnection will have their bundle-only state marked accordingly. </del> <ins> The BUNDLE and RTCP-multiplexing policies MUST NOT be changed after the construction of the PeerConnection. </ins> This call may result in a change to the state of the ICE Agent, and may result in a change to media state if it results in connectivity

"active" role is RECOMMENDED. If present in the offer, an "a=rtcp-mux" line, as specified in <del> RFC5761, Section 5.1.1. </del> <ins> RFC5761, Section 5.1.1.  If the "require" RTCP multiplexing policy is set and no "a=rtcp-mux" line is present in the offer, then the m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. </ins> If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5.

This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE <del> is used in full trickle mode with a policy of max-bundle-and-rtcp-mux and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's browser.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server. </del> <ins> is used in full trickle mode with a bundle policy of max-bundle, an RTCP mux policy of require, and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's browser.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server. </ins> The SDP for |offer-B1| looks like: