Re: [rtcweb] BUNDLE with implicit rtcp-mux

Christer said:

"BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp
attributes. I remember we had discussions about that, but I don't remember
the justification at the moment."

[BA] The justification was that an implementation interested in
multiplexing A/V would almost certainly also want to multiplex RTP and
RTCP, because the motivation for both is minimizing port usage.

On Mon, Mar 10, 2014 at 1:24 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>
>
> Before I comment on your proposal, let's take a few steps back (maybe it
> can even solve your issue).
>
>
>
> BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp
> attributes. I remember we had discussions about that, but I don't remember
> the justification at the moment. But, I wonder whether that text is from
> before we made a decision that, unless both endpoints support BUNDLE, no
> endpoint will use a single address:port.
>
>
>
> So, the question is: do we really need the SDP rtcp attribute?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
> *From:* Justin Uberti [mailto:juberti@google.com]
> *Sent:* 10. maaliskuuta 2014 8:18
> *To:* rtcweb@ietf.org; Eric Rescorla; Christer Holmberg
> *Subject:* BUNDLE with implicit rtcp-mux
>
>
>
> 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.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>