[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

AVTCORE Working Group                                           B. Aboba
INTERNET-DRAFT                                     Microsoft Corporation
Category: Informational
Expires: January 6, 2016                                     6 July 2015

                 Codec-Independent Selective Forwarding
                   draft-aboba-avtcore-sfu-rtp-00.txt

Abstract

   Selective Forwarding Units (SFUs) supporting Scalable Video Coding
   (SVC) typically parse the RTP payload in the forwarding plane, and
   often utilize codec-specific control messages within the control
   plane.  As a result, the control and/or forwarding planes of these
   implementations need to be modified (sometimes substantially) in
   order to support additional video codecs.  With SFUs now supporting
   VP8 in addition to H.264/SVC, and with additional video codecs
   expected to become popular, the inflexibility of SFU designs that
   depend on RTP payload parsing has become increasingly apparent.  In
   addition, these designs cannot function where the RTP payload is
   inaccessible, such as when it is encrypted with a key not available
   to the SFU.  Based on a summary of SFU implementation practice, this
   document develops requirements for codec-independent SFUs.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 6, 2016.











Aboba                         Informational                     [Page 1]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Performance  . . . . . . . . . . . . . . . . . . . . . .  4
       1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Control Plane  . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.1   RTCP . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Forwarding Plane . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1   RTP header . . . . . . . . . . . . . . . . . . . . . . .  7
       3.2   RTP payload  . . . . . . . . . . . . . . . . . . . . . .  8
       3.3   Problematic payload fields . . . . . . . . . . . . . . . 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       6.1. Informative references  . . . . . . . . . . . . . . . . . 12
   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15



















Aboba                         Informational                     [Page 2]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


1.  Introduction

   Selective Forwarding Units (SFUs) supporting simulcast and Scalable
   Video Coding (SVC) are widely deployed for use in video conferencing.
   While initial deployments focused on H.264/SVC [H.264] [RFC6190],
   SFUs supporting the VP8 [RFC6386] [I-D.ietf-payload-vp8] codec have
   also been deployed and implementations supporting VP9 [I-D.grange-
   vp9-bitstream] [I-D.uberti-payload-vp9] and HEVC [HEVC] [I-D.ietf-
   payload-rtp-h265] are expected.

   Given the growing demand for SFUs supporting multiple codecs, the
   disadvantages of codec-specific forwarding and control planes have
   become apparent.  These include:

   1. Forwarding plane maintenance.  SFU implementations originally
   developed for a specific codec such as H.264/SVC typically require
   updates and testing to support each additional codec.  Where the
   original forwarding logic depended on on RTP payload fields in the
   original supported codec that have no analog within additional video
   codecs (such as the PACSI NAL unit in H.264/SVC), forwarding path re-
   design or per-codec forwarding logic may be required, increasing
   complexity and potentially adversely impacting implementation
   performance.

   2. Control plane maintenance.  SFU implementations developed for a
   specific codec often utilize codec-specific control messages (such as
   the SEI layer drop message [RFC6190]) that may have no analog within
   other video codecs.  In addition, SFU implementations may depend on
   support for RTCP feedback messages [RFC4585] outside the mainstream
   [I-D.ietf-rtcweb-rtp-usage], thereby requiring control path re-design
   and/or support for additional feedback messages in order to support
   additional codecs.

   3. Interoperability issues.  Experience has shown that SFUs that
   depend on the RTP payload can be sensitive to differences in the
   encoder implementation.  As an example, implementations supporting
   H.264/SVC [RFC6190] vary in their treatment of the PACSI NAL unit.
   While some implementations require the PACSI NAL unit to be present
   in each packet and to be located first within the RTP payload, other
   implementations do not impose these restrictions, and some do not
   generate or parse the PACSI NAL unit at all.  Due to these
   differences, even implementations that are compatible at the
   bitstream level [H.264] and are generally conformant to the RTP
   payload specification [RFC6190] can fail to interoperate.

   4. Payload snooping.  While all SFUs require access to the IP header
   as well as RTCP, and many require the ability to modify RTP header
   fields and to insert, delete or modify RTP header extensions, in



Aboba                         Informational                     [Page 3]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


   addition codec-dependent SFU implementations require access to the
   RTP payload.  Therefore codec-dependent SFUs have access to audio and
   video data in addition to metadata.  This is potentially problematic
   for multi-tenant SFUs where the same SFU may be shared by multiple
   customers, each of whom can require assurance that the contents of
   the RTP payload is available only to endpoints under their control.

   To address these problems, this document develops requirements for
   codec-independent SFU operation, both within the control and
   forwarding planes.

1.1.  Performance

   This document does not take a position on whether codec-independent
   SFUs offer enduring performance benefits.  By itself, substituting
   RTP header extension(s) for RTP payload fields within the SFU
   forwarding plane seems unlikely to have a long-term impact on SFU
   performance, although in the short-term, forwarding performance might
   be improve in some implementations.

   As described in Section 3.1, SFU implementations frequently modify
   one or more RTP [RFC3550] header fields covered by the SRTP [RFC3711]
   authentication tag, requiring the authentication tag to be recomputed
   and modified prior to forwarding.  In addition, where an SRTP cipher-
   suite is negotiated that depends upon one or more modified RTP header
   fields (such as the SSRC field), it is also necessary for the SFU to
   decrypt and then re-encrypt SRTP packets.  As a result, SFUs
   modifying RTP header fields cannot reduce cryptographic operations
   where SRTP per-packet integrity protection and confidentiality is
   desired.

   Nevertheless, measurements presented in [Hellwagner] indicate
   reductions in forwarding latency and improvements in performance from
   removing cryptographic operations from the forwarding plane.  Such a
   savings might be possible if only per-packet integrity protection
   were utilized within SRTP.  Investigating the security implications
   of this (which would involve reliance on end-to-end confidentiality
   and integrity protection applied to the RTP payload) is outside the
   scope of this document.

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   "media aware network element (MANE)" is defined as in [RFC6184]
   Section 4.1:



Aboba                         Informational                     [Page 4]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


      A network element, such as a middle-box, selective forwarding
      unit, or application layer gateway that is capable of parsing
      certain aspects of the RTP payload headers or the RTP payload and
      reacting to their contents.

   "Selective Forwarding Unit" is defined as in [I-D.ietf-avtcore-rtp-
   topologies-update] Section 3.7:

      The selective forwarding middle-box has been introduced in
      recently developed videoconferencing systems in conjunction with,
      and to capitalize on, scalable video coding as well as
      simulcasting...  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
      middle-box selects which parts of a scalable bitstream (or which
      bitstream, in the case of simulcasting) to forward to each of the
      receiving End Points.  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 middle-
      box.  They are also capable of scaling to a large number of
      concurrent users, and--due to their very low delay-- can also be
      cascaded.

   A "Codec Independent SFU" is an SFU that only utilizes information
   from the the RTP header or header extensions, but does not parse or
   modify the RTP payload.  This implies that, unlike a MANE, a codec-
   independent SFU cannot do NAL-unit re-packetization, and needs to
   rely on IP fragmentation in the event of an MTU mismatch.  In
   addition, codec-independent SFUs cannot source or interpret codec-
   specific control messages, such as the SEI layer-drop message defined
   in H.264/SVC [RFC6190].

   Multiple RTP streams on a Single Transport (MRST): Multiple RTP
   streams on a single transport, carrying either a single Scalable
   Video Coding (SVC) bitstream or multiple simulcast streams.

   Multiple RTP streams on Multiple Transports (MRMT):  Multiple RTP
   streams carrying a single Scalable Video Coding (SVC) bitstream on
   Multiple Transports.

   RTP stream: See [I-D.ietf-avtext-rtp-grouping-taxonomy].  Within this
   document, one RTP stream can be utilized to transport one or more
   sub-layers.

   Single RTP stream on a Single Transport (SRST):  Single RTP stream



Aboba                         Informational                     [Page 5]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


   carrying a single Scalable Video Coding (SVC) bitstream on a Single
   (Media) Transport.

   Transport: A tuple comprising the source and destination IP address
   and ports.

2.  Control Plane

2.1.  RTCP

   Within the Control Plane, SFU implementations require cleartext
   access to RTCP messages as well as to information provided within
   signaling.  This implies that an SFU supporting SRTP MUST have access
   to SRTCP master keys.

   RTCP messages commonly used by SFUs include the Sender Report (SR),
   Receiver Report (RR), SDES and BYE messages, as well as feedback
   messages.  Note that even though SFU implementations need to decrypt
   RTCP messages, designs that do not modify SSRCs can forward RTCP
   messages such as SDES without modification (or even parsing), which
   has the additional potential advantage of enabling SFUs to forward
   RTCP messages they do not understand.

2.1.1.  Feedback Messages

   RTCP feedback messages widely supported by existing SFU
   implementations include Generic NACK [RFC4585], PLI [RFC4585] and FIR
   [RFC5104].  Generic NACK, defined in [RFC4585] Section 6.2.1 and
   retransmission payload, defined in [RFC4588] are particularly
   effective where temporal scalability is supported, making it possible
   to repair losses within the base layer of an SVC bitstream in time to
   enable decoding of the succeeding base layer P frame.

   FIR, defined in [RFC5104] Section 4.3.1, is frequently employed
   within SFUs when switching between video streams.  When the SFU
   decides to forward an alternative simulcast stream to a participant,
   or when an SFU decides to switch from forwarding video stream(s) sent
   by a now-quiet participant to stream(s) originated by an active
   speaker, an FIR is sent by the SFU to the sender of the switched-in
   RTP stream.  The sender responds with an I-frame that is subsequently
   forwarded to the recipients, ensuring that they can decode subsequent
   frames within the switched in RTP stream.

   In contrast, feedback messages such as SLI, defined in [RFC4585]
   Section 6.3.2 and RPSI, defined in [RFC4585] Section 6.3.3 are rarely
   supported in modern SFU implementations.  SLI is infrequently
   supported because Generic NACK provides similar functionality in a
   codec-independent manner, while more efficiently supporting non-



Aboba                         Informational                     [Page 6]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


   contiguous packet loss.

   RPSI is rarely supported since it requires that the encoder revert to
   use of an alternative reference picture not only for the participant
   experiencing the loss but for all participants.  Thus RPSI implies
   additional bandwidth usage not only on the link experiencing the
   loss, but also on the links utilized by other conference
   participants, thereby potentially exacerbating congestion problems.
   When temporal scalability is implemented, it is typically possible to
   employ retransmission [RFC4588] and/or Forward Error Correction
   [RFC5109] to protect against loss within the base layer.  In the
   (unlikely) event that these measures are insufficient, PLI and/or FIR
   feedback messages can be employed, so that RPSI support is
   unnecessary.

3.  Forwarding Plane

3.1.  RTP header

   Most existing SFU implementations modify one or more RTP header
   fields, including the payload type (PT), SSRC, CSRC, and sequence
   number fields.  SFU implementations may also modify RTP header
   extensions such as the abs-send-time extension [ABS-SEND].

   In signaling mechanisms such as SDP Offer/Answer [RFC3264], each
   conference participant can specify the PT they wish to receive and/or
   send for a particular codec.  Since conference participants can
   choose different PT values for the same codec, the SFU needs to be
   able to modify the PT field before forwarding RTP packets to a
   recipient.

   Some SFU implementations allocate their own SSRCs, which they place
   within RTP packets that they send to recipients, as well as within
   RTCP messages that they send.  As a result, the SSRC of RTP packets
   they receive is re-written prior to forwarding to conference
   participants.  As noted in [I-D.ietf-avtcore-rtp-topologies-update],
   SSRC re-writing has implications for the control plane as well as the
   forwarding plane.

   Some SFUs only forward video streams from participants that are
   considered to be active or recent speakers or (to enable access by
   hearing or speech impaired users) recent real-time text and/or chat
   contributors.  Techniques used for switching are described in
   [LASTN].  In order to determine the active or recent speakers, RTP
   header extensions such as the client-to-mixer audio level extension
   [RFC6464] may be used, and this header extension may therefore need
   to be available to the SFU in cleartext.




Aboba                         Informational                     [Page 7]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


   SFUs that allocate their own SSRCs and re-write the SSRC field may
   utilize the CSRC field with video streams they forward in order to
   indicate a switch of an RTP stream from one contributor to another.
   SFUs that do not allocate their own SSRCs typically do not utilize
   the CSRC field in this way.

   Where an SFU drops one or more layers within an SVC bitstream
   utilizing SRST transport, it is necessary to rewrite sequence numbers
   as well as to customize RTCP sender reports to reflect the packets
   actually sent to individual participants.  Rewriting of sequence
   numbers is also required in SFUs that receive simulcast streams with
   distinct SSRCs, but forward a single stream with a fixed SSRC, a
   practice common in SFUs supporting VP8.

   Where MRST transport is used for SVC and/or simulcast, it is not
   necessary to rewrite sequence numbers on dropping a layer or
   simulcast stream, since each one uses its own SSRC and therefore has
   its own sequence number space.  However, in order to avoid rewriting
   of sequence numbers on resuming a previously dropped stream, it is
   necessary to indicate the drop explicitly, such as via the PAUSED
   mechanism described in [I-D.ietf-avtext-rtp-stream-pause] or via the
   SEI layer drop message.  The latter requires the SFU to insert a
   sequence number within RTP packets originated by the SFU.

   One of the implications of SFU modifications to RTP header fields is
   that SFUs require access to SRTP master keys so as to be able to
   recompute the authentication tag, which covers the modified RTP
   header fields.

3.2.  RTP payload

   In addition to utilizing information from the RTP header in the
   forwarding path, existing SFU implementations also utilize
   information present in the RTP payload field. Within the VP8 and
   H.264/SVC codecs, this includes the following fields:

   Frame type: IDR

      Knowledge of the frame type enables the SFU to better protect I-
      frames using mechanisms such as QoS, FEC or RTX, as well as to
      determine when a stream switch can take place.  Within H.264/SVC,
      the frame type can be determined from the idr_flag; within VP8,
      the P bit (Inverse key frame flag) can be used.

   Discardable

      A 'Discardable' bit indicates whether other frames depend on this
      one.  For example within an implementation of temporal



Aboba                         Informational                     [Page 8]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


      scalability, only the highest temporal extension layer would
      provide a 'Discardable' indication - all other temporal layers
      would not.  Within H.264/SVC this information is provided by the D
      bit;  within VP8, it is provided by the N bit.

   Layer identifier

      Layer identifiers enable the SFU to determine the temporal,
      spatial or quality layer of a given packet.  This is used in
      forwarding/drop decisions.  Within H.264/SVC this information is
      present in the DID(3 bits), QID (4 bits) and TID (3 bits) fields.
      Within VP8, it is present in the TID field (2 bits).  Within
      H.265, it is present in the LayerID (6 bits) and TID (3 bits)
      fields.

   TL0PICIDX

      This field enables an SFU to determine whether a received frame is
      dependent on a base layer frame which the SFU has not previously
      received in its entirety.  This is important information since it
      may represent the first indication that all or part of a base
      layer frame needs to be recovered before the arrival of subsequent
      base layer frames that depend on it.  Within H.264/SVC the
      IDRPICID and TL0PICIDX fields are present if the Y bit is set.
      Within VP8, the TL0PICIDX field is present if the Y bit is set.

   S/E

      The S bit indicates the first packet within a frame for a given
      layer.  For example, the S bit would always be set in the first
      packet of a base layer frame, as well as in the first packet of a
      spatial, quality or temporal enhancement to that base layer frame.
      Similarly, the E bit indicates the last packet within a frame for
      a given layer.

      Note that the E bit does not have an identical meaning to the M
      bit within the RTP header, which indicates the last packet in an
      access unit.  As an example, where spatial scalability is in use,
      the last packet of a base layer frame would have the E bit set,
      but would not have the M bit set - the M bit would only be set on
      the last packet of the spatial enhancement to that base layer
      frame.

      Both the S and E bits are defined within H.264/SVC as well as
      within H.265.  Only the S bit is defined within VP8;  the lack of
      an E bit within VP8 is not an issue since VP8 only supports
      temporal scalability.




Aboba                         Informational                     [Page 9]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


3.3.  Problematic payload fields

   In addition to payload fields recommended for support within codec-
   independent SFUs, it is also useful to cover payload fields that are
   not recommended, because there are better alternatives.  These
   include the following fields:

   PictureID

      While the PictureID field is utilized within the RPSI feedback
      message, as well as being supported within the VP8 and VP9 codecs,
      its use is not recommended within codec-independent SFUs.  As
      noted earlier, RPSI feedback messages are rarely supported within
      existing SVC and simulcast implementations, since better loss
      recovery mechanisms are available.  As a result, an SFU does not
      need to originate an RPSI message which would require the
      PictureID.  Where it is necessary for the SFU to determine which
      picture a given packet belongs to, RTP header fields such as the
      timestamp and sequence number can be used instead.

   Macroblocks

      While macroblock identifiers are universally supported within
      video codecs, their use by codec-independent SFUs is not
      recommended.  As noted earlier, SLI feedback messages (which
      require a starting macroblock) are rarely supported within
      existing SFUs, since better loss recovery mechanisms are
      available.  Therefore a codec-independent SFU should never need to
      source an SLI message.

   NRI

      While the NRI field defined in H.264/SVC is used by some SFU
      implementations, its use in codec-independent SFUs is not
      recommended since there is no equivalent within the VP8 and VP9
      codecs, and the IDR, discardable and layer identification
      information provide an adequate substitute.

   PRID

      The PRID field defined in H.264/SVC has no analog in VP8 or VP9.
      While some SFU implementations do use this field (sometimes for
      purposes other than those for which it was originally defined),
      its use in codec independent SFUs is not recommended, since the
      D/N bits as well as the layer identification fields provide much
      the same information.

   F



Aboba                         Informational                    [Page 10]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


      The F bit defined in H.264/SVC has no analog in VP8 or VP9 and is
      always set to zero in H.265.  Therefore its use in codec-
      independent SFUs is not recommended.

   KEYIDX

      The KEYIDX field is defined in VP8 as well as VP9, providing
      information on the key frame that a given packet is dependent on.
      Existing SFU implementations do not utilize this field in their
      forwarding/drop decisions, preferring to instead utilize the
      TL0PICIDX field.

4.  Security Considerations

   Codec-independent forwarding provides significant architectural
   benefits, even in situations where it is not possible to fully
   protect the privacy of conference participants.

   As noted earlier in this document, SFUs require cleartext access to
   control plane information such as information provided in signaling
   as well as RTCP reports and feedback messages.  SFUs also require
   access to information required for forwarding plane operation, such
   as information available within RTP extensions (such as frame
   start/end bits, layer information, etc.) and RTP header extensions
   (e.g. abs-send-time [ABS-SEND] and client-to-mixer audio level
   indication [RFC6464]).

   In addition, it should be understood that the information available
   to passive observers is significant, since this includes metadata
   such as the IP addresses of conference participants (unless protected
   via a relay or onion routing service),  statistics such as
   packets/bytes sent, and packet sizes.

   Based on frame size, an SFU can determine periods of rapid motion,
   and based on the client-to-mixer audio level indication, the SFU can
   determine recent speakers.  Much of this same information may also be
   gleaned by a passive observer with access to packet size and RTP
   header data (such as the SSRC field).  Combined with metadata, this
   information would allow the SFU or a passive observer to determine
   the roles of various participants within the conference as well as
   their levels of engagement.

   Based on RTCP reports and feedback message providing information on
   delay, jitter and losses, the SFU can determine the bandwidth
   available to participants as well as aspects of endpoint connectivity
   (e.g. whether their network access is wireless/wired,
   satellite/terrestrial, etc.).




Aboba                         Informational                    [Page 11]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


   Even when the RTP payload is encrypted with a key unavailable to the
   SFU, the ability of the SFU to obtain and potentially forge signaling
   implies that end-to-end privacy is only guaranteed when media is
   authenticated end-to-end by an entity that can be considered
   trusthworthy even when presented with an intercept order.

5.  IANA Considerations

   This document does not require actions by IANA.

6.  References

6.1.  Informative References

[ABS-SEND]   WebRTC site, "The Absolute Send Time extension",
             http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time,
             retrieved July 6, 2015.

[H.264]      ITU-T Recommendation H.264, "Advanced video coding for
             generic audiovisual services", March 2010.

[Hellwagner] Hellwagner, H., Kuschnig, R., Stutz, T. and Andreas Uhl,
             "Efficient In-Network Adaptation of Encrypted H.264/SVC
             Content", Journal of Image Communication, Volume 24, Issue
             9, October 2009 Pages 740-758, Esevier Science, retrieved
             from http://wavelab.at/papers/Hellwagner09a.pdf

[HEVC]       ITU-T Recommendation H.265, "High efficiency video coding",
             April 2013.

[I-D.grange-vp9-bitstream]
             Grange, A. and H. Alvestrand, "A VP9 Bitstream Overview",
             draft-grange-vp9-bitstream-00 (work in progress), February
             2013.

[I-D.ietf-avtcore-rtp-multi-stream]
             Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
             "Sending Multiple Media Streams in a Single RTP Session",
             draft-ietf-avtcore-rtp-multi-stream-07 (work in progress),
             March 2015.

[I-D.ietf-avtcore-rtp-topologies-update]
             Westerlund, M. and S. Wenger, "RTP Topologies", draft-ietf-
             avtcore-rtp-topologies-update-10 (work in progress), July
             2015.

[I-D.ietf-avtext-rtp-grouping-taxonomy]
             Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and



Aboba                         Informational                    [Page 12]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


             B. Burman, "A Taxonomy of Grouping Semantics and Mechanisms
             for Real-Time Transport", draft-ietf-avtext-rtp-grouping-
             taxonomy-07 (work in progress), June 2015.

[I-D.ietf-avtext-rtp-stream-pause]
             Burman, B., Akram, A., Even, R. and M. Westerlund, "RTP
             Stream Pause and Resume", draft-ietf-avtext-rtp-stream-
             pause-08 (work in progress), July 2015.

[I-D.ietf-payload-rtp-h265]
             Wang, Y.-K., Sanchez, Y., Schierl, T., Wenger, S. and M. M.
             Hannuksela, "RTP Payload Format for High Efficiency Video
             Coding", draft-ietf-payload-rtp-h265-13 (work in progress),
             June 2015.

[I-D.ietf-payload-vp8]
             Westin, P., Lundin, H., Glover, M., Uberti, J. and F.
             Galligan, "RTP Payload Format for VP8 Video", draft-ietf-
             payload-vp8-16 (work in progress), June 2015.

[I-D.ietf-rtcweb-rtp-usage]
             Perkins, C., Westerlund, M. and J. Ott, "Web Real-Time
             Communication (WebRTC): Media Transport and Use of RTP",
             draft-ietf-rtcweb-rtp-usage-25 (work in progress), June
             2015.

[I-D.uberti-payload-vp9]
             Uberti, J., Holmer, S., Flodman, M. and J. Lennox, "RTP
             Payload Format for VP9 Video", draft-uberti-payload-vp9-01
             (work in progress), March 2015.

[LASTN]      Grozev, B., Marinov, L., Singh, V. and E. Ivov, "Last N:
             relevance-based selectivity for forwarding video in
             multimedia conferences",  Proceedings of the 25th ACM
             Workshop on Network and Operating Systems Support for
             Digital Audio and Video, pp. 19-24, 2015, ISBN:
             978-1-4503-3352-8

[RFC2119]    Bradner, S., "Key Words for Use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3264]    Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
             with Session Description Protocol (SDP)", RFC 3264, June
             2002.

[RFC3550]    Schulzrinne, H., Casner, S., Frederick, R., and V.
             Jacobson, "RTP: A Transport Protocol for Real-Time
             Applications", STD 64, RFC 3550, July 2003.



Aboba                         Informational                    [Page 13]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


[RFC3711]    Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
             Norrman, K., "The Secure Real-time Transport Protocol
             (SRTP)", RFC 3711, March 2004.

[RFC4585]    Ott, J., Wenger, S., Sato, N., Burmeister, C., and Rey, J.,
             "Extended RTP Profile for Real-time Transport Control
             Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
             2006.

[RFC4588]    Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
             Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
             July 2006.

[RFC5104]    Wenger, S., Chandra, U., Westerlund, M., and Burman, B.,
             "Codec Control Messages in the RTP Audio-Visual Profile
             with Feedback (AVPF)", RFC 5104, February 2008.

[RFC5109]    Li, A., "RTP Payload Format for Generic Forward Error
             Correction", RFC 5109, December 2007.

[RFC6184]    Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP
             Payload Format for H.264 Video", RFC 6184, May 2011.

[RFC6190]    Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
             "RTP Payload Format for Scalable Video Coding", RFC 6190,
             May 2011.

[RFC6386]    Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
             Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding
             Guide", RFC 6386, November 2011.

[RFC6464]    Lennox, J., Ivov, E. and E. Marocco, "A Real-time Transport
             Protocol (RTP) Header Extension for Client-to-Mixer Audio
             Level Indication", RFC 6464, December 2011.

Acknowledgments

   The author acknowledges discussions relating to the topic of this
   memo within the IETF PAYLOAD, AVTCORE and AVTEXT WGs, as well as
   discussions with the IMTC MANE Activity Group.  In particular, Emil
   Ivov, Alex Eleftheriadis and Stephan Wenger have provided helpful
   comments relating to this topic.









Aboba                         Informational                    [Page 14]


INTERNET-DRAFT   Codec-Independent Selective Forwarding      6 July 2015


Authors' Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   Email:  bernard_aboba@hotmail.com










































Aboba                         Informational                    [Page 15]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/