Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive

[Christer Holmberg <[e-mail]>]

Hi,

> Changing the subject since we are not talking just about BUNDLE any more.

Well, I’d like to talk about BUNDLE, and whether it should mandate support of mux-exclusive :)

>> I don’t think using a=rtcp for signalling mux-exclusive is new functionality. We still use it to signal the 
>> RTCP port, which in the case of mux-exclusive happens to be same as the RTP port.
>
> I agree rtcp mux exclusive is not entirely new functionality for a=rtcp. What I am trying to say is that at this point a=rtcp attribute 
> is required to be generated by ICE but it could be safely ignored when received. It carries no additional or useful information for 
> anything ICE enabled. It also not used or carries no useful information when legacy server side NAT traversal is used. In practice, 
> there is no need to parse a=rtcp or do anything based on its value. With a=rtcp being used to signal rtcp mux exclusive, modern 
> end points will need to parse a=rtcp and make decisions based on its value. This extends the lifetime of the feature which is essentially 
> under-designed and never operated properly. This is the reason I was asking for a way to signal mux-exclusive for anything ICE enabled 
> without relying on a=rtcp.
>
> I have no problem with a=rtcp being used to improve interop with legacy end points, but I do not like seeing new use scenarios 
> which are centered exclusively around a=rtcp. If we do this, we run into problem that we need to fix all the exiting a=rtcp problems 
> with offer/answer, which I do not think is even possible in backwards compatible manner.
>
> Bottom line -- I would prefer another SDP attribute to signal RTCP mux exclusive which is negotiated over offer/answer so that both end points 
> can detect that it is used. This attribute can be used in parallel with a=rtcp, but I believe a=rtcp will be made totally redundant in this case.
>
> I would also like to update ICE-SDP not include a=rtcp when it carries no additional information. I believe after switching rtcp mux 
> exclusive to a different attribute and ICE not being required to insert a=rtcp when it carries no additional information, a=rtcp will 
> almost never be used in practical deployments, so the need to fix it disappears.

We can for sure define a new attribute, if people prefer that. 

But, it still wouldn't solve Paul's issue, that a non-ICE endpoint that doesn't support the attribute may start sending RTCP on RTP+1. But, at least the offerer would see from the answer that the answerer does not support mux-exclusive, and can take proper actions.

Regards,

Christer