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

Magnus Westerlund <> Mon, 07 April 2014 11:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5ADE61A06E8 for <>; Mon, 7 Apr 2014 04:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3WxiDABjzaCm for <>; Mon, 7 Apr 2014 04:15:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A69D21A03BF for <>; Mon, 7 Apr 2014 04:15:21 -0700 (PDT)
X-AuditID: c1b4fb28-b7fd58e000007bb5-b1-534288c31cf7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 09.06.31669.3C882435; Mon, 7 Apr 2014 13:15:15 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 7 Apr 2014 13:15:14 +0200
Message-ID: <>
Date: Mon, 07 Apr 2014 13:15:14 +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: Harald Alvestrand <>,
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvje7hDqdgg9lNohbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJ2/XvGWLBct2LpyuksDYz9Kl2MHBwSAiYS f+8ZdDFyApliEhfurWcDsYUETjJK7FgqCmEvY5R4ckoIxOYV0JY4f/0FC4jNIqAiMevFK1YQ m03AQuLmj0awXlGBYImlcxazQNQLSpyc+QTMFhGwl7g45yWYLSyQITGtaTPULh+JxYd7mUFs TgFdia0f5rJDnCYu0dMYBBJmFtCTmHK1hRHClpdo3jqbGaJVW6KhqYN1AqPgLCTbZiFpmYWk ZQEj8ypGyeLU4uLcdCNDvdz03BK91KLM5OLi/Dy94tRNjMCAPbjlt8YOxu5r9ocYpTlYlMR5 q2Z2BgkJpCeWpGanphakFsUXleakFh9iZOLglGpgVFy8v7K22zGK2cOWNdlrmtVtR9G9p1+V JHF9ypNXYfS+yeTr96ptZ/fK9jVa+p2Tl6ZFnAswntIbIu7m55ac0jtnt+lEZa3ewJDM6P/c D/f1NbLPlDx2mlV2X1C7VozEhj87A06+endm4gND81ThohNR8YGae0+fP7WxseiUTsGdIJF8 diklluKMREMt5qLiRABPdsx9JgIAAA==
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: Mon, 07 Apr 2014 11:15:29 -0000

On 2014-04-07 10:12, Harald Alvestrand wrote:
> Thanks for the update!
> It does seem reasonably clear now - clear enough that I found one point
> that I violently disagree with (if I'm interpreting it correctly). See
> below.
> I don't have any negative comments on the rest of the section.
> On 04/04/2014 11:24 AM, Magnus Westerlund wrote:
>> WG,
>> (As Author)
>> Colin and I have been working on resolving terminology usage and in
>> general giving the draft a polish over before the WG last call. One
>> section that has gotten quite some attention from us is the below one.
>> The changes are significantly from an editorial stand point. However,
>> the intended content has not been intended to be changed, although
>> clarified and better motivated. So please review it, we intended to
>> include this in the upcoming draft update. Feedback appreciated.
>> 5.1.  Conferencing Extensions and Topologies
>>     RTP is a protocol that inherently supports group communication.
>>     Groups can be implemented by having each endpoint sending its RTP
>>     packet streams to an RTP middlebox that redistributes the traffic, by
>>     using a mesh of unicast RTP packet streams between endpoints, or by
>>     using an IP multicast group to distribute the RTP packet streams.
>>     These topologies can be implemented in a number of ways as discussed
>>     in [I-D.ietf-avtcore-rtp-topologies-update].
>>     While the use of IP multicast groups is popular in IPTV systems, the
>>     topologies based on RTP middleboxes are dominant in interactive video
>>     conferencing environments.  Topologies based on a mesh of unicast
>>     transport-layer flows to create a common RTP session have not seen
>>     widespread deployment.  Accordingly, WebRTC implementations are not
>>     expected to support topologies based on IP multicast groups.  WebRTC
>>     implementations are also not expected to support mesh-based
>>     topologies, such as a point-to-multipoint mesh configured as a single
>>     RTP session (Topo-Mesh in the terminology of
>>     [I-D.ietf-avtcore-rtp-topologies-update]).  However, a point-to-
>>     multipoint mesh constructed using several RTP sessions, in the WebRTC
>>     context using independent RTCPeerConnections can be expected to be
>>     utilised by WebRTC applications.
>>     WebRTC implementations of RTP endpoints implemented according to this
>>     memo are expected to support all the topologies described in
>>     [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send
>>     and receive unicast RTP packet streams to some peer device, provided
>>     that peer can participate in performing congestion control on the RTP
>>     packet streams.  The peer device could be another RTP endpoint, or it
>>     could be an RTP middlebox that redistributes the RTP packet streams
>>     to other RTP endpoints.  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.6.2 of
>>        [I-D.ietf-avtcore-rtp-topologies-update]).
>>     o  Content modifying MCUs with RTCP termination (Topo-RTCP-
>>        terminating-MCU) SHOULD NOT be used since they break RTP loop
>>        detection, and prevent receivers from identifying active senders
>>        (see section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]).
> In my (strong) opinion: This recommendation is wrong.
> All central conferencing units that use individual RTP sessions with
> clients fall into this category. This includes, I believe, every single
> multiuser video conferencing system based on WebRTC in existence (and
> there are many of them).

Do they? The point of this topology is that it terminates the source
identification and hides when it is performing any type of mixing or
switching operation. You can perform this with a back to back RTP
session style without breaking this property. Just by correctly linking
information between the sessions. Which means that the individual RTP
session is from the identification part inseparable from an SFM or
classic RTP mixer. Only the SSRC level loop detection gets impacted.

I do understand that people have implemented it this way. Implementation
are not necessarily equivalent to recommended practice.

> I believe the recommendation should be:
> * Content modifying MCUs with RTCP termination
> (Topo-RTCP-terminating-MCU) MAY be used. Note that in this scenario, RTP
> loop detection and identification of active senders is the resposibility
> of the application; since the clients are isolated from each other at
> the RTP layer, RTP cannot assist with these functions.

If this topology was without issues, then one would simply remove the
bullet, and let it fall under the general clause. However, it clearly
needs that warning. Which results in this topology being both positively
and negatively treated in regards to the other "you may encounter this


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: