From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Harald Tveit Alvestrand <harald@alvestrand.no>
Thread-Topic: [rtcweb] Draft proposal for updating Multiparty topologies in
 draft-ietf-rtcweb-rtp-usage
Thread-Index: AQHPchQvO0wMWIDrME26aQCJfgCeoA==
Date: Sat, 17 May 2014 21:08:44 +0000
Message-ID: <1B57A7DB-DF0B-4956-A6B8-1DA0B9A7FC1E@cisco.com>
References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no>
 <534288C2.6010906@ericsson.com> <5342ABBB.9050300@alvestrand.no>
 <534D4CC4.9040107@ericsson.com>
 <BEE377D4-4E1F-4958-8F59-842F92606C5B@cisco.com>
 <53635F4A.5040508@alvestrand.no>
In-Reply-To: <53635F4A.5040508@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <D3EAA21D1755EB44AC58506718754EAC@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/70Ldmg-l-ldHBeUwJWZKsNK3fg0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in
 draft-ietf-rtcweb-rtp-usage
Precedence: list


On May 2, 2014, at 4:03 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> On 04/30/2014 11:56 PM, Cullen Jennings (fluffy) wrote:
>> On Apr 15, 2014, at 9:14 AM, Magnus Westerlund <magnus.westerlund@ericss=
on.com> wrote:
>>=20
>>> This limitation means that
>>>   some of the RTP middlebox-based topologies are not suitable for use
>>>   in the WebRTC environment.  Specifically:
>>>=20
>>>   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 sev=
eral companies at the last WebRTC Expo conference were demonstrating system=
 that used this type of MCU.
>>=20
>> If SRTP were more flexible and there was a way to a mixer work without g=
iving 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 betwee=
n significant security functionally loss and possible loss of some RTCP dat=
a 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.
>>=20
> Seems the discussion of what the effects are belongs to the threads on to=
pologies-update.
>=20
> RTCWEB implementations that ignore RTCP are going to break all our attemp=
ts at congestion control anyway, so I'm inclined to leave them out of the s=
pec. They'll break on their own.
>=20

FWIW =85 Things doing audio only at relatively low bit rates that ignore RT=
CP will probably continue to work fine. =