Re: [rtcweb] BUNDLE with implicit rtcp-mux

Sort of. The idea is whether JSEP should have a mode which _gathers_ only a
single set of ports, in effect assuming the other side supports rtcp-mux.
The use of a=rtcp is incidental here, and only used to point out that the
RTP and RTCP ports that are offered will be identical.

On Tue, Mar 11, 2014 at 12:51 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>   "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.
>
> [Christer] So, again, the idea is to use a=rtcp to indicate the *same*
> port as a=rtcp-mux indicates, and hope that the receiver supports at least
> either a=rtcp or a=rtcp-mux?
>
> Regards,
>
> Christer
>
>
>
> 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
>>
>>
>