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

[Magnus Westerlund <[e-mail]>]

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

Roni,

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

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

   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.


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