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

["Roni Even" <[e-mail]>]

Hi,
Comment on video switching in-line
Roni

> -----Original Message-----
> From: rtcweb [mailto:[e-mail]] On Behalf Of Magnus
> Westerlund
> Sent: 04 April, 2014 12:25 PM
> To: [e-mail]
> Cc: Colin Perkins
> Subject: [rtcweb] Draft proposal for updating Multiparty topologies in
draft-
> ietf-rtcweb-rtp-usage
> 
> 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]).
[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.

> 
>    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]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb