Re: [rtcweb] BUNDLE with implicit rtcp-mux

[Justin Uberti <[e-mail]>]

By "RTCP transport in the offer", I mean separate ICE candidates generated
for a RTCP ICE component, the original problem that I was proposing to
solve.

I agree the rtcp-mux attribute must always be present if you are going to
do rtcp-mux.


On Fri, Mar 14, 2014 at 9:30 AM, Christer Holmberg <
[e-mail]> wrote:

>
> Hi Justin,
>
> What do you mean by "RTCP transport in the offer"? Are you referring to
> the a=rtcp attribute, or?
>
> Even if we mandate rtcp-mux within a BUNDLE group, the a=rtcp-mux
> attribute must still always be present - even if you know the remote
> endpoint supports rtcp-mux (or, even if you have already negotiated usage
> of rtcp-mux).
>
> Regards,
>
> Christer
> ________________________________________
> From: Justin Uberti [[e-mail]]
> Sent: Friday, 14 March 2014 6:26 PM
> To: Magnus Westerlund
> Cc: Christer Holmberg; [e-mail]; Eric Rescorla
> Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux
>
> On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund <
> [e-mail]<mailto:[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.
>