Re: [rtcweb] BUNDLE with implicit rtcp-mux

[Magnus Westerlund <[e-mail]>]

Please see inline.

This is as an individual!

On 2014-03-20 01:21, Justin Uberti wrote:

> On Mon, Mar 17, 2014 at 6:23 AM, Magnus Westerlund
> <[e-mail] <mailto:[e-mail]>>
> wrote:
> 

> 
>     (still as individual)
> 
>     Lets be clear what we are discussing here. I don't think this is lot of
>     cases. And if you don't want to implement this in your code generating
>     offer, that is fine. What this describes is that your code handling
>     reception of offers and generating answers must be able to handle the
>     lack of a=rtcp-mux in any offer, rather than just the initial one.
> 
>     I would question if even that assumption holds considering what happens
>     if people start implementing session resumption or session mobility
>     between devices using rehydration style establishment procedures. What
>     one sides consider an initial offer might not be the state the answering
>     party is in. Thus, I am worried about cases that are first offer/answer
>     exchange related.
> 
>     To my understanding you will have code to handle the following cases
>     when offers contains:
> 
>     1) No bundle, no a=rtcp-mux
>     2) No bundle, with a=rtcp-mux
>     3) Bundle, with a=rtcp-mux
> 
>     Considering that you support bundle, and you support usage or not of
>     a=rtcp-mux. Then I don't see how the code handling the SDP logic for
>     Bundle, without a=rtcp-mux is that significant.
> 
> 
> It is significant because you always know you can rtcp-mux. And you
> always know you can BUNDLE when rtcp-muxing. But I think trying to
> BUNDLE a no-rtcp-mux m= line into a rtcp-mux m= line is asking for
> problems. 

To be clear, I am arguing for consistent behavior and usage across the
whole bundle group. Certainly you MUST NOT be allowed to have some m=
line for RTP to use a=rtcp-mux and some other m= line in the same bundle
group to not use it.

What I am considering is the possibility to have a bundle group with
multiple m= RTP lines that do not use a=rtcp-mux and instead have RTCP
over a separate port.

I started arguing that this was important for being able to recover PT
space. But there is actually another reason for this. In cases when you
have QoS, for example in cellular environment, mandating the use of
rtcp-mux forces one to send the RTCP over the expensive QoS bearer. The
amount of RTCP to support adaptation as well as codec control means that
it is still likely that you want to spend at least 5% of the Video
bandwidth on RTCP. If the cost associated with providing QoS for video
can be reduced by 3-5% we in the cellular business definitely like to be
able to utilize it.

I would also like to stress that we are discussing what BUNDLE enables.
RTCWEB is the first user of bundle, but likely not the only one. We have
to be careful to apply all WebRTC context specific limitations on a
general mechanism.

First of all I really like to see that BUNDLE does not restrict ones
choices if one like to multiplex RTP or RTCP when doing BUNDLE. As a
general IETF SDP Signaling mechanism we need this generality.

Secondly, I would strongly prefer that also RTCWEB's specifications do
support this mode of operation.

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