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

Magnus Westerlund <> Tue, 15 April 2014 12:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E3F221A069F for <>; Tue, 15 Apr 2014 05:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.054
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gvxTXcTb9xwc for <>; Tue, 15 Apr 2014 05:22:16 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 8B2741A069B for <>; Tue, 15 Apr 2014 05:22:15 -0700 (PDT)
X-AuditID: c1b4fb25-f798a6d000005ede-e3-534d24738dbc
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 37.2B.24286.3742D435; Tue, 15 Apr 2014 14:22:12 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 15 Apr 2014 14:22:11 +0200
Message-ID: <>
Date: Tue, 15 Apr 2014 14:22:11 +0200
From: Magnus Westerlund <>
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 <>,
References: <> <010501cf533d$143546a0$3c9fd3e0$>
In-Reply-To: <010501cf533d$143546a0$3c9fd3e0$>
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==
Cc: 'Colin Perkins' <>
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: 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.


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

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

   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.


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: