IETF Logo Mail Archive

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

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Sat, 17 May 2014 21:08 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC3C1A017F for <rtcweb@ietfa.amsl.com>; Sat, 17 May 2014 14:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.152
X-Spam-Level:
X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBIKjqF2DeuE for <rtcweb@ietfa.amsl.com>; Sat, 17 May 2014 14:08:46 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEFC1A017C for <rtcweb@ietf.org>; Sat, 17 May 2014 14:08:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1844; q=dns/txt; s=iport; t=1400360926; x=1401570526; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=I+Jm2zixUZR+5HiswdfGUbboeEAFyzN9gkq8sB9xOHQ=; b=IHoaxQHa0k5JLoxkeaZ8u/92VQYbt2D8fMRuU/q5SnjMVjd3N2Ij1JHJ cplecPR6QGhXWh7nBOkYbU5robT9MithLt9uw8KkhgUJ6SWqfhW8SsHrj sOIt3i+JbVYk9roMDXLFo1gv2A64O4PYv5gpuTi+8gEDUuVSd2w3T3Ea6 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQHAArPd1OtJV2U/2dsb2JhbABZgwaBJ6lPAQUFAZorAYELFnSCJQEBAQMBaBEFCwIBCBguMiUCBA4FiDkI0RYXhVWISDMHgyuBFQEDmVqTGoF3gUCCMA
X-IronPort-AV: E=Sophos;i="4.98,859,1392163200"; d="scan'208";a="44756090"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP; 17 May 2014 21:08:45 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4HL8jOW032550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 17 May 2014 21:08:45 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Sat, 17 May 2014 16:08:45 -0500
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.144.167]
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
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 May 2014 21:08:49 -0000

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@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.
>> 
> 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.

v2.19.0 | Report a Bug | By Email