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

"Cullen Jennings (fluffy)" <> Wed, 30 April 2014 21:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CD4B41A09A5 for <>; Wed, 30 Apr 2014 14:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.152
X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y5YvXFctAf93 for <>; Wed, 30 Apr 2014 14:56:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 90E5B1A09A3 for <>; Wed, 30 Apr 2014 14:56:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1251; q=dns/txt; s=iport; t=1398895001; x=1400104601; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zoxVLl1rMSBd+SLdDqR2hh66p+afOzfJKNMuzdJ8RNY=; b=VtV+LR2W/8OmBPn/q2l10nEKigvYBu3EhWn8rAvTddpvavmo938jeSh7 9P3Xi+sHaga3JzhPJST9fNtdrK+cK4qeI6A0WGglwWuKn+ntc7doZQh3f s2PgkKIz2IQxLRprrdRODuV1/r90NxjvRkbPBDtId2SkSY3mSAvdOwR+V 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjAFAAlxYVOtJV2a/2dsb2JhbABZgwaBJsRLgSEWdIIlAQEBAwFoEQULAgEIRjIlAgQOBYg5CMoDF44eMweDJIEVAQOJS49ckmuBcoE/gis
X-IronPort-AV: E=Sophos;i="4.97,960,1389744000"; d="scan'208";a="40114943"
Received: from ([]) by with ESMTP; 30 Apr 2014 21:56:40 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s3ULueqU028112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 21:56:40 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 16:56:40 -0500
From: "Cullen Jennings (fluffy)" <>
To: Magnus Westerlund <>
Thread-Topic: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage
Thread-Index: AQHPZL8Q59672nYevkqhkexdZdxtQw==
Date: Wed, 30 Apr 2014 21:56:40 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Apr 2014 21:56:43 -0000

On Apr 15, 2014, at 9:14 AM, Magnus Westerlund <> 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.