Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage

Cullen said:

"My understanding was several companies at the last WebRTC Expo conference
were demonstrating system that used this type of MCU."

[BA] Indeed, this type of MCU is likely to be popular, because at some
point the browser itself becomes the limitation.  For example, tests seem
to show rendering limits kicking in at roughly a dozen streams (though
there have been some successful test with up to 20 streams rendered
simultaneously).  One way for the MCU to deal with this is to only show the
"last N" speakers.  This does not necessarily imply usage of the "video
switching" topology, but a number of vendors are implementing it this way.

Cullen also said:

"If SRTP were more flexible and there was a way to a mixer work without
giving it the keys to the decrypt the media, I think people would be keener
on mixers"

[BA] This issue also affects Scalable Forwarding Units, not just "mixers".
 There have been some studies of "codec-specific encryption" that show the
performance effects of this, as well as the security impact. [1]

[1] Efficient In-Network Adaptation of Encrypted H.264/SVC Content (2009)
by by Hermann Hellwagner , Robert Kuschnig , Thomas Stütz , Andreas Uhl

On Wed, Apr 30, 2014 at 2:56 PM, Cullen Jennings (fluffy)
<fluffy@cisco.com>wrote:

>
> On Apr 15, 2014, at 9:14 AM, Magnus Westerlund <
> magnus.westerlund@ericsson.com> wrote:
>
> > This limitation means that
> >   some of the RTP middlebox-based topologies are not suitable for use
> >   in the WebRTC environment.  Specifically:
> >
> >   o  Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used,
> >      since they make the use of RTCP for congestion control and quality
> >      of service reports problematic (see Section 3.8 of
> >      [I-D.ietf-avtcore-rtp-topologies-update]).
>
> I think this is deserving of some WG discussion as people may not be up to
> speed of what this is allowing or not allowing. My understanding was
> several companies at the last WebRTC Expo conference were demonstrating
> system that used this type of MCU.
>
> If SRTP were more flexible and there was a way to a mixer work without
> giving it the keys to the decrypt the media, I think people would be keener
> on mixers but right it seems like the pro / cons invovle a trade off
> between significant security functionally loss and possible loss of some
> RTCP data which many systems totally ignore.  Anyway, not taking any
> opinion other than this seems like a significant enough change to have some
> discussion on it.
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>