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

[Harald Alvestrand <[e-mail]>]

On 05/17/2014 11:08 PM, Cullen Jennings (fluffy) wrote:
> On May 2, 2014, at 4:03 AM, Harald Alvestrand <[e-mail]> wrote:
>
>> On 04/30/2014 11:56 PM, Cullen Jennings (fluffy) wrote:
>>> On Apr 15, 2014, at 9:14 AM, Magnus Westerlund <[e-mail]> 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.
>>>
>> Seems the discussion of what the effects are belongs to the threads on topologies-update.
>>
>> RTCWEB implementations that ignore RTCP are going to break all our attempts at congestion control anyway, so I'm inclined to leave them out of the spec. They'll break on their own.
>>
> FWIW … Things doing audio only at relatively low bit rates that ignore RTCP will probably continue to work fine.
As long as "relatively low" means "low relative to the available 
bandwidth", I agree.

They'll break when that doesn't hold.