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

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 04 April 2014 09:24 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 45CD61A0213 for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 02:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AxGNTVOhB3x9 for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 02:24:38 -0700 (PDT)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net []) by ietfa.amsl.com (Postfix) with ESMTP id CB5991A001D for <rtcweb@ietf.org>; Fri, 4 Apr 2014 02:24:37 -0700 (PDT)
X-AuditID: c1b4fb32-b7fe98e0000034f3-dd-533e7a5091bb
Received: from ESESSHC010.ericsson.se (Unknown_Domain []) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 03.FA.13555.05A7E335; Fri, 4 Apr 2014 11:24:32 +0200 (CEST)
Received: from [] ( by smtp.internal.ericsson.com ( with Microsoft SMTP Server id; Fri, 4 Apr 2014 11:24:32 +0200
Message-ID: <533E7A50.5040909@ericsson.com>
Date: Fri, 04 Apr 2014 11:24:32 +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: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupiluLIzCtJLcpLzFFi42KZGfG3Rjegyi7Y4OciY4vlL08wWqz9187u wOQx7f59No8lS34yBTBFcdmkpOZklqUW6dslcGUc//yGtWCDWsXuafdZGhhvyXUxcnJICJhI PFiwnA3CFpO4cG89kM3FISRwklFixa4prBDOMkaJ2Yt/MoNU8QpoSzyb/Z8FxGYRUJFY8v8+ K4jNJmAhcfNHI9gkUYFgiaVzFrNA1AtKnJz5BMwWEVCXuPzwAjuIzSygKnF+33mwXmGBSIm/ u1cD9XIAXSEu0dMYBFGiJzHlagsjhC0v0bx1NtgJQkAnNDR1sE5gFJiFZMMsJC2zkLQsYGRe xShZnFpcnJtuZKCXm55bopdalJlcXJyfp1ecuokRGJ4Ht/w22sF4co/9IUZpDhYlcd7rrDVB QgLpiSWp2ampBalF8UWlOanFhxiZODilGhhD69YYvciYyLn/8veGMwdlVKb6P9v02F/u5h2b mxcWnaxSdun/o/1gKnPgS03fHY59yQfbCl/bivccONedJvHQbi/H40OTdtjnzXl75opRzeII b/Xfr9cWaDEwdt606ltx0EboQZ9W1po7u/yOOr7kVmUN2XfGkaFqU9rSEAbd6i3GUefCT+xT YinOSDTUYi4qTgQAN2/XDB0CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Tbyay8-zE9sm-QIGfkg1jr2phlQ
Cc: Colin Perkins <csp@csperkins.org>
Subject: [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: Fri, 04 Apr 2014 09:24:42 -0000

(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

   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]).

   o  The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology
      SHOULD NOT be used because its safe use requires a point to
      multipoint congestion control algorithm or RTP circuit breaker,
      which has not yet been standardised.

   The RTP extensions described in Section 5.1.1 to Section 5.1.6 are
   designed to be used with centralised conferencing, where an RTP
   middlebox (e.g., a conference bridge) receives a participant's RTP
   packet streams and distributes them to the other participants.  These
   extensions are not necessary for interoperability; an RTP end-point
   that does not implement these extensions will work correctly, but
   might offer poor performance.  Support for the listed extensions will
   greatly improve the quality of experience and, to provide a
   reasonable baseline quality, some of these extensions are mandatory
   to be supported by WebRTC end-points.

   The RTCP conferencing extensions are defined in Extended RTP Profile
   for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
   AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio-
   Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully
   usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124].


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