[rtcweb] BUNDLE with implicit rtcp-mux

[Justin Uberti <[e-mail]>]

In my JSEP preso during the RTCWEB session last Wednesday, I discussed
adding a new BUNDLE policy to JSEP. This policy, which would be called
something like “force-bundle”, would force the use of the same ports for
BUNDLEd m-sections, as well as RTCP mux. When one knows a priori that the
other side supports BUNDLE, this would reduce candidate gathering even over
the currently defined “max-bundle” policy, since there would be no need to
gather RTCP ports at all, and also avoid the need for the BUNDLE fixup
offer (where the ports are updated to be the same for all BUNDLEd
m-sections).

To explain the differences here, here are some example offers for an
audio+video call:

Default bundle policy - separate ports for audio, video, RTP and RTCP:
m=audio 10000
a=rtcp:10001
a=rtcp-mux
m=video 11000
a=rtcp:11001
a=rtcp-mux

Existing "max-bundle" policy - video port is 0 because bundle-only, but
both RTP and RTCP ports allocated for audio:
m=audio 10000
a=rtcp:10001
a=rtcp-mux
m=video 0
a=bundle-only
a=rtcp-mux

The new “force-bundle” policy - only a single set of ports allocated -
audio, video, RTP, RTCP share the same port.
m=audio 10000
a=rtcp:10000
a=rtcp-mux
m=video 10000
a=rtcp:10000
a=rtcp-mux

During the discussion, the ability to avoid RTCP port gathering was seen as
valuable, but not the ability to avoid the fixup offer. However, after
thinking about it a bit, I don’t think that there is a viable solution that
avoids RTCP port gathering that *doesn’t* use a single set of ports. The
only other option would be to do something like this:

m=audio 10000
a=rtcp:10000 # same as m=audio port
a=rtcp-mux
m=video 0
a=bundle-only
a=rtcp-mux

but this will almost surely will result in a malfunction when talking to a
non-rtcp-mux client, due to the same port being used for RTP and RTCP, and
still requires the fixup offer, and as such is net worse than the
force-bundle approach indicated above.

So I think we the force-bundle approach is the one we want to minimize port
gathering. The only question is whether we should keep max-bundle as well.
To be specific, we need to decide between:

a) Keep max-bundle as it is (separate RTP and RTCP ports allocated), and
add a new force-bundle policy that creates an offer with a single port
shared between all m-sections (RTP and RTCP). max-bundle remains nominally
backwards compatible with non-BUNDLE/non-rtcp-mux endpoints, in that it
will still send a single audio stream. force-bundle is not backwards
compatible with non-BUNDLE endpoints.

b) Add force-bundle, but get rid of max-bundle.