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

[Magnus Westerlund <[e-mail]>]

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

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


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------