Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 15 April 2014 12:22 UTC
Return-Path: <magnus.westerlund@ericsson.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 E3F221A069F for <rtcweb@ietfa.amsl.com>;
Tue, 15 Apr 2014 05:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.054
X-Spam-Level:
X-Spam-Status: No,
score=0.054 tagged_above=-999 required=5 tests=[BAYES_05=-0.5,
FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_MED=-2.3,
RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
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 gvxTXcTb9xwc for
<rtcweb@ietfa.amsl.com>; Tue, 15 Apr 2014 05:22:16 -0700 (PDT)
Received: from sesbmg23.ericsson.net (unknown [193.180.251.37]) by
ietfa.amsl.com (Postfix) with ESMTP id 8B2741A069B for <rtcweb@ietf.org>;
Tue, 15 Apr 2014 05:22:15 -0700 (PDT)
X-AuditID: c1b4fb25-f798a6d000005ede-e3-534d24738dbc
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by
sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id
37.2B.24286.3742D435; Tue, 15 Apr 2014 14:22:12 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com
(153.88.183.26) with Microsoft SMTP Server id 14.3.174.1;
Tue, 15 Apr 2014 14:22:11 +0200
Message-ID: <534D2473.7020007@ericsson.com>
Date: Tue, 15 Apr 2014 14:22:11 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>, <rtcweb@ietf.org>
References: <533E7A50.5040909@ericsson.com>
<010501cf533d$143546a0$3c9fd3e0$@gmail.com>
In-Reply-To: <010501cf533d$143546a0$3c9fd3e0$@gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+JvjW6Jim+wwd5mVovlL08wWvxtZ7ZY
+6+d3YHZY9r9+2weO2fdZfdYsuQnUwBzFJdNSmpOZllqkb5dAlfGl13tbAUnpCtudp9kaWB8
LNrFyMkhIWAi0XvmLSOELSZx4d56ti5GLg4hgaOMEicWvWeFcJYzSmy7d5cFpIpXQFti6a5n
zCA2i4CqxO7nnWBxNgELiZs/GtlAbFGBYImlcxZD1QtKnJz5BMwWEbCUmPVnCxOIzSygLvFs
9n6wOcICGRLTmjaD9QoJhEusbvgPFucEmrnk0DX2LkYOoOvEJXoagyBa9SSmXG1hhLDlJZq3
zmaGaNWWaGjqYJ3AKDQLyeZZSFpmIWlZwMi8ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMw
sA9u+a26g/HyG8dDjAIcjEo8vFq3fYKFWBPLiitzDzFKc7AoifN+uQUUEkhPLEnNTk0tSC2K
LyrNSS0+xMjEwSnVwFiVmn43Xzcp0fTPB9bEvT+SA5JCUnM/Hn+4vv0869vdery/dKp3v77v
skBjuu4bjgN6LtdqVQvml+cePPd36bd7ahG90RdfBNfeaJJkCdub9z9AeNayPdsVmqOuxTTP
i2I9YVaU4N64bCX/9kqt6/9dsx++yfPd+cry9fqVf5Jae6f+Kgms4FBiKc5INNRiLipOBACw
+ePBTQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VOrUjxufX24h-Zna8ADyPCEsuYM
Cc: 'Colin Perkins' <csp@csperkins.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: Tue, 15 Apr 2014 12:22:20 -0000
On 2014-04-08 17:13, Roni Even wrote: > Hi, > Comment on video switching in-line >> >> 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.6.2 of >> [I-D.ietf-avtcore-rtp-topologies-update]). > [Roni Even] I think that SHOULD NOT is too strong here better use MAY be > used, this is a simple common mode of centralized video conferencing being > used. If you are talking about the RTP layer the MCU gets all the RTCP > reports. The problem of loop detection may occur when cascading MCUs and the > avtcore topology should point it out. I do not see it as a major problem > since the video switching is managed by the application layer who should > prevent such situations. > Roni, I think you need to go read the definition of the topology in the draft. As defined in the topologies update draft, that behaviour is not acceptable towards an WebRTC end-point that uses RTCP for congestion control. I quote the most important parts (Section 3.8) from -01: "A video switching MCU forwards to a participant a single media stream, selected from the available streams. The criteria for selection are often based on voice activity in the audio-visual conference, but other conference management mechanisms (like presentation mode or explicit floor control) are known to exist as well. The video switching MCU may also perform media translation to modify the content in bit-rate, encoding, or resolution. However, it still may indicate the original sender of the content through the SSRC. In this case, the values of the CC and CSRC fields are retained. If not terminating RTP, the RTCP Sender Reports are forwarded for the currently selected sender. All RTCP Receiver Reports are freely forwarded between the participants. In addition, the MCU may also originate RTCP control traffic in order to control the session and/or report on status from its viewpoint. The video switching MCU has most of the attributes of a Translator. However, its stream selection is a mixing behavior. This behavior has some RTP and RTCP issues associated with it. The suppression of all but one media stream results in most participants seeing only a subset of the sent media streams at any given time, often a single stream per conference. Therefore, RTCP Receiver Reports only report on these streams. Consequently, the media senders that are not currently forwarded receive a view of the session that indicates their media streams disappear somewhere en route. This makes the use of RTCP for congestion control, or any type of quality reporting, very problematic." I think the behaviour you are interested in falls under the RTP mixer behaviour either the Mixing (Section 3.6.1) or the Switching (Section 3.6.2) where RTCP is properly handled. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [rtcweb] Draft proposal for updating Multiparty t… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Christian Groves
- Re: [rtcweb] Draft proposal for updating Multipar… Harald Alvestrand
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Harald Alvestrand
- Re: [rtcweb] Draft proposal for updating Multipar… Roni Even
- Re: [rtcweb] Draft proposal for updating Multipar… Roni Even
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Harald Alvestrand
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Roni Even
- Re: [rtcweb] Draft proposal for updating Multipar… Cullen Jennings (fluffy)
- Re: [rtcweb] Draft proposal for updating Multipar… Magnus Westerlund
- Re: [rtcweb] Draft proposal for updating Multipar… Harald Alvestrand
- Re: [rtcweb] Draft proposal for updating Multipar… Cullen Jennings (fluffy)
- Re: [rtcweb] Draft proposal for updating Multipar… Harald Alvestrand
- Re: [rtcweb] Draft proposal for updating Multipar… Bernard Aboba