Re: [MMUSIC] BUNDLE Q14: Mandate usage of RTP/RTCP mux within a BUNDLE group? [was: On the sparsity of RTP Payload types]

[Magnus Westerlund <[e-mail]>]

On 2014-03-16 15:16, Christer Holmberg wrote:
> 
> Hi,
> 
> Do other people have opinions on this?

I have considered this proposal in a wider context and have the
following reflections and also an additional motivation why I personally
consider it important that a bundle-group shall be possible to be
established with RTCP on either the same transport flow (5-tuple) as
RTP, i.e. using a=rtcp-mux, or using separate transport flows (one for
RTP, one for RTCP), i.e. no a=rtcp-mux.

First of all BUNDLE is a general signaling mechanism it is possible to
apply to any user of SDP offer/answer. WebRTC is the first and the one
which pushed it into existence, but I am pretty certain it will not be
the only user of  the mechanism.

What Justin is pushing for, prevents one to have multiple media streams
of different or the same type, i.e. what ever you put in the same bundle
group, to have RTCP separated on transport level from RTP.

In most cases this doesn't matter, but where it can matter is when using
QoS, for example in cellular environments. Being forced to put RTCP on
the same QoS treatment as the media will either reduce the achievable
quality or increase the cost. Being able to spend these commonly 5% of
bandwidth on improving media or avoiding higher cost is significant in
such an environment.

Thus, I think everyone needs to thing twice about this. Shall really
relatively minor implementation concerns and focus on general Internet
only deployments win out over BUNDLEs applicability and the possibility
to get the most out of any QoS when available.

To be clear, I am fine with having usage of a=rtcp-mux as default
behavior, but from my perspective we need to be able to actually
negotiate if one turns on RTP/RTCP multiplexing using the a=rtcp-mux
attribute when doing an round of offer/answer based signaling.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------