Re: [rtcweb] BUNDLE with implicit rtcp-mux

[Justin Uberti <[e-mail]>]

On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund <
[e-mail]> wrote:

> Hi,
> (as individual)
>
> Although this discussion really should be on MMUSIC, I am still
> following up here. Anything we come to conclude here really need to go
> to MMUSIC for confirmation.
>
> Justin, I do agree that it appear unnecessarily of having to include an
> RTCP transport in an OFFER when the offerer know the answerer is BUNDLE
> capable. I am fine with that and think the rule needed here is something
> along the line of the below:
>
> A BUNDLE supporting endpoint MUST implement a=rtcp-mux (that is already
> required). In any answer by a BUNDLE capable endpoint, it MUST NOT
> change the usage of a=rtcp-mux. If it is present in the offer, it must
> be confirmed to be used in the answer, and if not present in the offer,
> it MUST NOT be added in the answer. An BUNDLE capable endpoint is
> RECOMMENDED to use a=rtcp-mux whenever suitable. Cases when it might not
> be suitable include, lack RTP payload types, or cases when RTCP traffic
> is needed to be on its own transport flow (5-tuple) to enable QoS or
> other traffic handling functionalities.
>
> The reason for writing the rule like the above, is that then an endpoint
> can choose when creating an offer to renegotiate the use of a=rtcp-mux.
> For example due to it running out of available PTs.
>
> Feedback on this proposal?
>

I am not OK with this. It just gets too complicated to deal with all the
cases, especially if with the provision that rtcp-mux can change during the
session.

I think Christer's current language is what we want - if you are going to
BUNDLE, you MUST also use rtcp-mux for any RTP m-lines. If the answerer
cannot do that, it needs to reject the BUNDLE.

I agree with your initial point though - if you know that both sides are
going to BUNDLE and rtcp-mux, it makes sense to allow them to do that from
the outset, i.e. no need to include a RTCP transport in the offer.