RTCP MUX is a way of sending both RTP and RTCP of a media stream over the same port. Many traditional VoIP applications use a non-MUX mode where RTP is sent over an even port and its related RTCP over the next port.
The decision not to mandate support for non-MUX mode in WebRTC may seem weird as it creates interoperability problems between WebRTC and VoIP applications but this decision was taken based on current common practice information and needs.
Generally speaking, many WebRTC applications prefer to send all user media over the same port. This simplifies things and reduces ICE setup time.
Actual usage information indicates that use of non-MUX in WebRTC is rare.
More on this decision and reasons for it in the Details section.
This should have no significant impact on existing WebRTC-to-WebRTC applications. It may have an impact on any WebRTC application intended to work with existing VoIP systems.
This is in the draft RFCs.
The original design of SIP assumed that different ports would be used for different media types and for additional information and controls such as RTCP and simulcast. Eventually RFC 5761 (RTCP-MUX) defined how RTCP could be multiplexed over the same port as the RTP it controlled. To ensure backwards compatibility, offering RTCP-MUX was optional and accepting it was as well. This meant that RTCP non-mux was mandatory to support.
Since then, and most particularly since WebRTC work began, there has been inexorable pressure to be able to send/receive all traffic intended for a single recipient, regardless of type or purpose, over a single port. Early in the development of WebRTC we developed BUNDLE, a way of combining media of different types (audio and video) together over the same port.
During the recent IETF meeting two decisions were made. First, it was decided that endpoints would be permitted to support RTCP mux-only when using BUNDLE.
Then, when Google reported that only a very tiny fraction of the apps it saw used RTCP non-mux at all, the further decision was made to allow endpoints to refuse RTCP non-mux. It was made clear that, in practice, Chrome and Firefox expected not to support RTCP non-mux at all.
This means that any application on the Internet that needs RTCP sent separately from RTP will need to use a gateway of some sort.