Re: [rtcweb] BUNDLE with implicit rtcp-mux

["Stach, Thomas" <[e-mail]>]

Some thoughts/proposal about the fixup inline.

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.
[TS] The fixup is only introduced to accommodate a certain variety of middleboxes that want to see the used ports also  in the SDP offer/answer. The fixup offer is not technically necessary for the two bundle clients. They already know after the first offer/anwer cycle that usage of bundle is successfully negotiated and which port to use.
However, there is also exist situations and another variety of middleboxes for which the fixup offer/answer exchange does harm. Some of the related issues are described in draft-elwell-mmusic-ice-updated-offer, but there are more. I think that having the possibility to avoid the fixup offer/answer is a good thing. Since both scenarios mutually exclude themselves, this behavior needs to be configurable, dependent on the network environment.
Independent of the fixup being used or not,  both cases could use the same offer. With that a  new JSEP policy is not needed and things could be kept backwardcompatible. It might however be beneficial, to use an explicit indicator in the SDP that fixup is done/must be done/must not be done…
Regards
Thomas
BTW: Althought this discussion is about a new policy for JSEP, the details  are deep in the SDP territory of MMUSIC. Should it be moved there or MMUsIC made aware?
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.