Re: [rtcweb] BUNDLE with implicit rtcp-mux

[Christer Holmberg <[e-mail]>]

Hi,

> 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.

Ok.

But, again, we do have a decision that we are not going to specify procedures based on pre-knoweldge of BUNDLE support by the answerer. Or, at least that was the outcome in London, I guess it still has to be verified on the list.

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

Good :)

Regards,

Christer


On Fri, Mar 14, 2014 at 9:30 AM, Christer Holmberg <[e-mail]<mailto:[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]<mailto:[e-mail]>]
Sent: Friday, 14 March 2014 6:26 PM
To: Magnus Westerlund
Cc: Christer Holmberg; [e-mail]<mailto:[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]><mailto:[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.