[AVTCORE] Slight rewording on Selective Forwarding Middlebox

[Magnus Westerlund <[e-mail]>]

WG,

Based on last weeks discussion with David Benham, I have attempted to
write the SFM section more neutral in regards to if one must have
independent SSRC spaces or not. Please review if you think this is
better or if you have further suggestion on changes needed.

Cheers

Magnus


3.7.  Selective Forwarding Middlebox

   Another method for handling media in the RTP mixer is to "project",
   or make available, all potential RTP sources (SSRCs) into a per-
   endpoint, independent RTP session.  The middlebox can select which of
   the potential sources that are currently actively transmitting media
   will be sent to each of the endpoints.  This is similar to the media
   switching Mixer but has some important differences in RTP details.


          +-A---------+             +-Middlebox-----------------+
          | +-RTP1----|             |-RTP1------+       +-----+ |
          | | +-Video-|             |-Video---+ |       |     | |
          | | |    AV1|------------>|---------+-+------>|     | |
          | | |       |<------------|BV1 <----+-+-------|  S  | |
          | | |       |<------------|CV1 <----+-+-------|  W  | |
          | | |       |<------------|DV1 <----+-+-------|  I  | |
          | | |       |<------------|EV1 <----+-+-------|  T  | |
          | | |       |<------------|FV1 <----+-+-------|  C  | |
          | | +-------|             |---------+ |       |  H  | |
          | +---------|             |-----------+       |     | |
          +-----------+             |                   |  M  | |
                                    |                   |  A  | |
          +-B---------+             |                   |  T  | |
          | +-RTP2----|             |-RTP2------+       |  R  | |
          | | +-Video-|             |-Video---+ |       |  I  | |
          | | |    BV1|------------>|---------+-+------>|  X  | |
          | | |       |<------------|AV1 <----+-+-------|     | |
          | | |       |<------------|CV1 <----+-+-------|     | |
          | | |       | :    :    : |: :  : : : : :  : :|     | |
          | | |       |<------------|FV1 <----+-+-------|     | |
          | | +-------|             |---------+ |       |     | |
          | +---------|             |-----------+       |     | |
          +-----------+             |                   |     | |
                                    :                   :     : :
                                    :                   :     : :
          +-F---------+             |                   |     | |
          | +-RTP6----|             |-RTP6------+       |     | |
          | | +-Video-|             |-Video---+ |       |     | |
          | | |    FV1|------------>|---------+-+------>|     | |
          | | |       |<------------|AV1 <----+-+-------|     | |
          | | |       | :    :    : |: :  : : : : :  : :|     | |
          | | |       |<------------|EV1 <----+-+-------|     | |
          | | +-------|             |---------+ |       |     | |
          | +---------|             |-----------+       +-----+ |
          +-----------+             +---------------------------+

                 Figure 17: Selective Forwarding Middlebox

   In the six endpoint conference depicted above in (Figure 17) one can
   see that endpoint A is aware of five incoming SSRCs, BV1-FV1.  If
   this middlebox intends to have a similar behavior as in Section 3.6.2
   where the mixer provides the endpoints with the two latest speaking
   endpoints, then only two out of these five SSRCs need concurrently
   transmit media to A.  As the middlebox selects the source in the
   different RTP sessions that transmit media to the endpoints, each RTP
   stream requires rewriting of certain RTP header fields when being
   projected from one session into another.  In particular, the sequence
   number needs to be consecutively incremented based on the packet
   actually being transmitted in each RTP session.  Therefore, the RTP
   sequence number offset will change each time a source is turned on in
   a RTP session.  The timestamp (possibly offset) stays the same.

   The RTP sessions can be considered independent, the SSRC numbers used
   can also be handled independently, thereby bypassing the requirement
   for SSRC collision detection and avoidance.  This will require tools
   such as remapping tables between the RTP sessions.However, using
   independent RTP sessions are not required, the switching behavior is
   possible to perform also with a common SSRC space.  However, in this
   case collision detection and handling becomes a different problem.
   Therefore, it is up to the implementation to use a single common SSRC
   space or separate ones.

   Using separate SSRC spaces have some implications.  For example, the
   RTP stream that is being sent by endpoint B to the middlebox (BV1)
   may use an SSRC value of 12345678.  When that RTP stream is sent to
   endpoint F by the middlebox, it can use any SSRC value, e.g.
   87654321.  As a result, each endpoint may have a different view of
   the application usage of a particular SSRC.  Any RTP level identity
   information, such as SDES items also needs to update the SSRC
   referenced, if the included SDES items are intended to be global.
   Thus the application must not use SSRC as references to RTP streams
   when communicating with other peers directly.  This also affects loop
   detection which will fail to work, as there is no common namespace
   and identities across the different legs in the communication session
   on RTP level.  Instead this responsibility falls onto higher layers.

   The middlebox is also responsible to receive any RTCP codec control
   requests coming from an endpoint, and decide if it can act on the
   request locally or needs to translate the request into the RTP
   session/transport leg that contains the media source.  Both endpoints
   and the middlebox need to implement conference related codec control
   functionalities to provide a good experience.  Commonly used are Full
   Intra Request to request from the media source to provide switching
   points between the sources, and Temporary Maximum Media Bit-rate
   Request (TMMBR) to enable the middlebox to aggregate congestion
   control responses towards the media source so to enable it to adjust
   its bit-rate (obviously only in case the limitation is not in the
   source to middlebox link).

   The selective forwarding middlebox has been introduced in recently
   developed videoconferencing systems in conjunction with, and to
   capitalize on, scalable video coding as well as simulcasting.  An
   example of scalable video coding is Annex G of H.264, but other
   codecs, including H.264 AVC and VP8 also exhibit scalability, albeit
   only in the temporal dimension.  In both scalable coding and
   simulcast cases the video signal is represented by a set of two or
   more bitstreams, providing a corresponding number of distinct
   fidelity points.  The middlebox selects which parts of a scalable
   bitstream (or which bitstream, in the case of simulcasting) to
   forward to each of the receiving endpoints.  The decision may be
   driven by a number of factors, such as available bit rate, desired
   layout, etc.  Contrary to transcoding MCUs, these "Selective
   Forwarding Units" (SFUs) have extremely low delay, and provide
   features that are typically associated with high-end systems
   (personalized layout, error localization) without any signal
   processing at the middlebox.  They are also capable of scaling to a
   large number of concurrent users, and--due to their very low delay--
   can also be cascaded.

   This version of the middlebox also puts different requirements on the
   endpoint when it comes to decoder instances and handling of the RTP
   streams providing media.  As each projected SSRC can, at any time,
   provide media, the endpoint either needs to be able to handle as many
   decoder instances as the middlebox received, or have efficient
   switching of decoder contexts in a more limited set of actual decoder
   instances to cope with the switches.  The application also gets more
   responsibility to update how the media provided is to be presented to
   the user.

   Note that this topology could potentially be seen as a media
   translator which include an on/off logic as part of its media
   translation.  The topology has the property that all SSRCs present in
   the session is visible to an endpoint.  It also has mixer aspects, as
   the streams it provides are not basically translated version, but
   instead they have conceptual property assigned to them and can be
   both turned on/off as well as being fully or partially delivered.
   Thus this topology appears to be some hybrid between the translator
   and mixer model.

   The differences between selective forwarding middlebox and a
   switching mixer (Section 3.6.2) are minor, and they share most
   properties.  The above requirement on having a large number of
   decoding instances or requiring efficient switching of decoder
   contexts, are one point of difference.  The other is how the
   identification is performed, where the Mixer uses CSRC to provide
   information on what is included in a particular RTP stream that
   represent a particular concept.  Selective forwarding gets the source
   information through the SSRC, and instead have to use other mechanism
   to make clear the streams current purpose.



-- 

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