Network Working Group                                   Stephan Wenger
INTERNET-DRAFT                                           Umesh Chandra
Expires: May October 2007                                            Nokia
                                                     Magnus Westerlund
                                                             Bo Burman
                                                              Ericsson
                                                         March 5,
                                                          May 14, 2007

                        Codec Control Messages in the
                RTP Audio-Visual Profile with Feedback (AVPF)
                       draft-ietf-avt-avpf-ccm-04.txt>
                       draft-ietf-avt-avpf-ccm-05.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies a few extensions to the messages defined in
   the Audio-Visual Profile with Feedback (AVPF).  They are helpful
   primarily in conversational multimedia scenarios where centralized
   multipoint functionalities are in use.  However some are also usable
   in smaller multicast environments and point-to-point calls.  The
   extensions discussed are messages related to the ITU-T H.271 Video
   Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit-
   rate Bit
   Rate and Temporal Spatial Trade-off.

TABLE OF CONTENTS

1. Introduction....................................................5
2. Definitions.....................................................7 Definitions.....................................................6
   2.1. Glossary...................................................7 Glossary...................................................6
   2.2. Terminology................................................8 Terminology................................................6
   2.3. Topologies.................................................9
3. Motivation (Informative).......................................10
   3.1. Use Cases.................................................10
   3.2. Using the Media Path......................................12
   3.3. Using AVPF................................................13
      3.3.1. Reliability..........................................13
   3.4. Multicast.................................................13
   3.5. Feedback Messages.........................................13
      3.5.1. Full Intra Request Command...........................13
         3.5.1.1. Reliability.....................................14
      3.5.2. Temporal Spatial Trade-off Request and Announcement..15 Notification..15
         3.5.2.1. Point-to-point..................................16 Point-to-Point..................................16
         3.5.2.2. Point-to-Multipoint using Using Multicast or Translators16
                  Translators.....................................16
         3.5.2.3. Point-to-Multipoint using Using RTP Mixer.............17
         3.5.2.4. Reliability.....................................17
      3.5.3. H.271 Video Back Channel Message conforming to ITU-T Rec.
      H.271.......................................................17 Message.....................17
         3.5.3.1. Reliability.....................................20
      3.5.4. Temporary Maximum Media Bit-rate Request.............20 Stream Bit Rate Request and
      Notification................................................20
         3.5.4.1. MCU based Multi-point operation.................25 Behavior for media receivers using TMMBR........22
         3.5.4.2. Algorithm for establishing current limitations..24
         3.5.4.3. Use of TMMBR in a Mixer Based Multipoint
                  Operation.......................................30
         3.5.4.4. Use of TMMBR in Point-to-Multipoint using Using
                  Multicast or Translators27
         3.5.4.3. Translators........................32
         3.5.4.5. Use of TMMBR in Point-to-point operation........................27
         3.5.4.4. Reliability.....................................28 operation........32
         3.5.4.6. Reliability.....................................32
4. RTCP Receiver Report Extensions................................29 Extensions................................34
   4.1. Design Principles of the Extension Mechanism..............29 Mechanism..............34
   4.2. Transport Layer Feedback Messages.........................30 Messages.........................35
      4.2.1. Temporary Maximum Media Bit-rate Stream Bit Rate Request (TMMBR).....30
             (TMMBR)..............................................36
         4.2.1.1. Semantics.......................................31
         4.2.1.2. Message Format..................................33 Format..................................36
         4.2.1.2. Semantics.......................................37
         4.2.1.3. Timing Rules....................................34 Rules....................................40
         4.2.1.4. Handling in Translator and Mixers...............40
      4.2.2. Temporary Maximum Media Bit-rate Stream Bit Rate Notification (TMMBN) 35
             (TMMBN)..............................................41
         4.2.2.1. Semantics.......................................35
         4.2.2.2. Message Format..................................36 Format..................................41
         4.2.2.2. Semantics.......................................41
         4.2.2.3. Timing Rules....................................36 Rules....................................43
         4.2.2.4. Handling by Translators and Mixers..............43
   4.3. Payload Specific Feedback Messages........................37 Messages........................43
      4.3.1. Full Intra Request (FIR) command.....................37 (FIR).............................44
         4.3.1.1. Semantics.......................................37
         4.3.1.2. Message Format..................................39 Format..................................44
         4.3.1.2. Semantics.......................................45
         4.3.1.3. Timing Rules....................................40 Rules....................................47
         4.3.1.4. Remarks.........................................40 Handling of FIR Message in Mixer and
                  Translators.................................... 47
         4.3.1.5. Remarks.........................................47
      4.3.2. Temporal-Spatial Trade-off Request (TSTR)............41 (TSTR)............47
         4.3.2.1. Semantics.......................................41
         4.3.2.2. Message Format..................................41 Format..................................47
         4.3.2.2. Semantics.......................................48
         4.3.2.3. Timing Rules....................................42 Rules....................................49
         4.3.2.4. Remarks.........................................42 Handling of message in Mixers and Translators...49
         4.3.2.5. Remarks.........................................49
      4.3.3. Temporal-Spatial Trade-off Announcement (TSTA).......43 Notification (TSTN).......50
         4.3.3.1. Semantics.......................................43
         4.3.3.2. Message Format..................................44 Format..................................50
         4.3.3.2. Semantics.......................................50
         4.3.3.3. Timing Rules....................................44 Rules....................................51
         4.3.3.4. Remarks.........................................45 Handling of TSTN in Mixer and Translators.......51
         4.3.3.5. Remarks.........................................51
      4.3.4. H.271 VideoBackChannelMessage (VBCM).................45 Video Back Channel Message (VBCM)..............51
         4.3.4.1. Message Format..................................52
         4.3.4.2. Semantics.......................................52
         4.3.4.3. Timing Rules....................................54
         4.3.4.4. Handling of message in Mixer or Translator......54
         4.3.4.5. Remarks.........................................54
5. Congestion Control.............................................48 Control.............................................54
6. Security Considerations........................................48 Considerations........................................55
7. SDP Definitions................................................49 Definitions................................................56
   7.1. Extension of the rtcp-fb attribute............................49 Attribute........................56
   7.2. Offer-Answer..............................................51 Offer-Answer..............................................58
   7.3. Examples..................................................51 Examples..................................................58
8. IANA Considerations............................................54 Considerations............................................61
9. Acknowledgements...............................................54 Acknowledgements...............................................62
10. References....................................................56 References....................................................63
   10.1. Normative references.....................................56 references.....................................63
   10.2. Informative references...................................56 references...................................63
11. Authors' Addresses............................................57
12. List of Changes relative to previous draftsError! Bookmark not defined.

1. Addresses............................................64

1.1. Introduction

   When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was
   developed, the main emphasis lay in the efficient support of point-
   to-point and small multipoint scenarios without centralized
   multipoint control.  However, in practice, many small multipoint
   conferences operate utilizing devices known as Multipoint Control
   Units (MCUs).  Long standing  Long-standing experience of the conversational video
   conferencing industry suggests that there is a need for a few
   additional feedback messages, to efficiently support centralized multipoint conferencing.
   conferencing efficiently.  Some of the messages have applications
   beyond centralized multipoint, and this is indicated in the
   description of the message.  This is especially true for the message
   intended to carry ITU-T Rec. H.271 [H.271] bitstrings bit strings for Video Back
   Channel messages.

   In RTP Real-time Transport Protocol (RTP) [RFC3550] terminology, MCUs
   comprise mixers and translators.  Most MCUs also include signaling
   support.  During the development of this memo, it was noticed that
   there is considerable confusion in the community related to the use
   of terms such as mixer, translator, and MCU.  In response to these
   concerns, a number of topologies have been identified that are of
   practical relevance to the industry, but are not documented in
   sufficient detail in RTP. [RFC3550].  These topologies are documented in
   [Topologies], and understanding this memo requires previous or
   parallel study of [Topologies].

   Some of the messages defined here are forward only, in that they do
   not require an explicit notification to the message emitter
   indicating their reception that they
   have been received and/or indicating the message receiver's actions.
   Other messages require notification, a response, leading to a two way communication
   model that one could suggest to some to be view as useful for control purposes.  It  However,
   it is not the intention of this memo to open up
   RTCP RTP Control Protocol
   (RTCP) to a generalized control protocol.  All mentioned messages
   have relatively strict real-time constraints -- constraints, in the sense that their
   value diminishes with increased delay.  This makes the use of more
   traditional control protocol means, such as SIP re-invites Session Initiation
   Protocol (SIP) re-INVITEs [RFC3261],
   undesirable. undesirable when used for the
   same purpose.  Furthermore, all messages are of a very simple format
   that can be easily processed by an RTP/RTCP sender/receiver.
   Finally, all messages infer relate only to the RTP stream with which they
   are related
   to, associated, and not to any other property of a communication
   system.

   The Full Intra Request (FIR) requires the receiver  In particular, none of them relate to the message
   (and sender properties of the stream) to immediately insert a decoder refresh
   point.  In video coding, one commonly used form of a decoder refresh
   point is an IDR or Intra picture, depending on
   access links traversed by the video compression
   technology in use.  Other codecs may have other forms of decoder
   refresh points.  In order to fulfill congestion session.

2. Definitions

2.1. Glossary

   AMID   - Additive Increase Multiplicative Decrease
   AVPF   - The extended RTP profile for RTCP-based feedback
   FEC    - Forward Error Correction
   FCI    - Feedback Control Information [RFC4585]
   FIR    - Full Intra Request
   MCU    - Multipoint Control Unit
   MPEG   - Moving Picture Experts Group
   TMMBN  - Temporary Maximum Media Stream Bit Rate Notification
   TMMBR  - Temporary Maximum Media Stream Bit Rate Request
   PLI    - Picture Loss Indication
   PR     - Packet rate
   QP     - Quantizer Parameter
   RTT    - Round trip time
   SSRC   - Synchronization Source
   TSTN   - Temporal Spatial Trade-off Notification
   TSTR   - Temporal Spatial Trade-off Request
   VBCM   - Video Back Channel Message indication.

2.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 RFC 2119 [RFC2119].

      Message:
          An RTCP feedback message [RFC4585] defined by this
          specification, of one of the following types:

          Request:
              Message that requires acknowledgement

          Command:
              Message that forces the receiver to an action

          Indication:
              Message that reports a situation

          Notification:

             Message that provides a notification that an event has
              occurred. Notifications are commonly generated in response
              to a Request.

          Note that, with the exception of "Notification", this
          terminology is in alignment with ITU-T Rec. H.245 [H245].

     Decoder Refresh Point:
          A bit string, packetized in one or more RTP packets, which
          completely resets the decoder to a known state.

          Examples for "hard" decoder refresh points are Intra pictures
          in H.261, H.263, MPEG-1, MPEG-2, and MPEG-4 part 2, and
          Instantaneous Decoder Refresh (IDR) pictures in H.264.
          "Gradual" decoder refresh points may also be used; see for
          example [AVC].  While both "hard" and "gradual" decoder
          refresh points are acceptable in the scope of this
          specification, in most cases the user experience will benefit
          from using a "hard" decoder refresh point.

          A decoder refresh point also contains all header information
          above the picture layer (or equivalent, depending on the video
          compression standard) that is conveyed in-band.  In H.264, for
          example, a decoder refresh point contains parameter set
          Network Adaptation Layer (NAL) units that generate parameter
          sets necessary for the decoding of the following slice/data
          partition NAL units (and that are not conveyed out of band).

   Decoding:
          The operation of reconstructing the media stream.

   Rendering:
          The operation of presenting (parts of) the reconstructed media
          stream to the user.

   Stream thinning:
          The operation of removing some of the packets from a media
          stream.  Stream thinning, preferably, is media-aware, implying
          that media packets are removed in the order of increasing
          relevance to the reproductive quality.  However even when
          employing media-aware stream thinning, most media streams
          quickly lose quality when subject to increasing levels of
          thinning.  Media-unaware stream thinning leads to even worse
          quality degradation.  In contrast to transcoding, stream
          thinning is typically seen as a computationally lightweight
          operation.

   Media:

          Often used (sometimes in conjunction with terms like bit rate,
          stream, sender ...) to identify the content of the forward RTP
          packet stream (carrying the codec data), to which the codec
          control message applies.

   Media Stream:
          The stream of RTP packets labeled with a single
          Synchronization Source (SSRC) carrying the media (and also in
          some cases repair information such as retransmission or
          Forward Error Correction (FEC) information).

   Total media bit rate:
          The total bits per second transferred in a media stream,
          measured at an observer-selected protocol layer and averaged
          over a reasonable timescale, the length of which depends on
          the application.  In general, a media sender and a media
          receiver will observe different total media bit rates for the
          same stream, first because they may have selected different
          reference protocol layers, and second, because of changes in
          per-packet overhead along the transmission path.  The goal
          with bit rate averaging is to be able to ignore any burstiness
          on very short timescales, below for example 100 ms, introduced
          by scheduling or link layer packetization effects.

   Maximum total media bit rate:
          The upper limit on total media bit rate for a given media
          stream at a particular receiver and for its selected protocol
          layer. Note that this value cannot be measured on the received
          media stream, instead it needs to be calculated or determined
          through other means, such as QoS negotiations or local
          resource limitations. Also note that this value is an average
          (on a timescale that is reasonable for the application) and
          that it may be different from the instantaneous bit-rate seen
          by packets in the media stream.

   Overhead:
          All protocol header information required to convey a packet
          with media data from sender to receiver, from the application
          layer down to a pre-defined protocol level (for example down
          to, and including, the IP header).  Overhead may include, for
          example, IP, UDP, and RTP headers, any layer 2 headers, any
          Contributing Sources (CSRCs), RTP-Padding, and RTP header
          extensions.  Overhead excludes any RTP payload headers and the
          payload itself.

   Net media bit rate:
          The bit rate carried by a media stream, net of overhead.  That
          is, the bits per second accounted for by encoded media, any
          applicable payload headers, and any directly associated meta
          payload information placed in the RTP packet.  A typical
          example of the latter is redundancy data provided by the use
          of RFC 2198 [RFC2198].  Note that, unlike the total media bit
          rate, the net media bit rate will have the same value at the
          media sender and at the media receiver unless any mixing or
          translating of the media has occurred.

          For a given observer, the total media bit rate for a media
          stream is equal to the sum of the net media bit rate and the
          per-packet overhead as defined above multiplied by the packet
          rate.

   Feasible region:
          The set of all combinations of packet rate and net media bit
          rate that do not exceed the restrictions in maximum media bit
          rate placed on a given media sender by the Temporary Maximum
          Media Stream Bit-rate Request (TMMBR)  messages it has
          received.  The feasible region will change as new TMMBR
          messages are received.

   Bounding set:
          The set of TMMBR tuples, selected from all those received at a
          given media sender, that define the feasible region for that
          media sender.  The media sender uses an algorithm such as that
          in section 3.5.4.2 to determine or iteratively approximate the
          current bounding set, and reports that set back to the media
          receivers in a Temporary Maximum Media Stream Bit-rate
          Notification (TMMBN) message.

2.3. Topologies

   Please refer to [Topologies] for an in depth discussion.  The
   topologies referred to throughout this memo are labeled (consistently
   with [Topologies]) as follows:

   Topo-Point-to-Point . . . . . point-to-point communication
   Topo-Multicast  . . . . . . . multicast communication as in RFC 3550
   Topo-Translator . . . . . . . translator based as in RFC 3550
   Topo-Mixer  . . . . . . . . . mixer based as in RFC 3550
   Topo-Video-switch-MCU . . . . video switching MCU,
   Topo-RTCP-terminating-MCU . . mixer but terminating RTCP

3. Motivation (Informative)

   This section discusses the motivation and usage of the different
   video and media control constraints,
   sending messages.  The video control messages have
   been under discussion for a long time, and a requirement draft was
   drawn up [Basso].  This draft has expired; however we quote relevant
   sections of it to provide motivation and requirements.

3.1. Use Cases

   There are a number of possible usages for the proposed feedback
   messages.  Let us begin by looking through the use cases Basso et al.
   [Basso] proposed.  Some of the use cases have been reformulated and
   comments have been added.

   1. An RTP video mixer composes multiple encoded video sources into a
      single encoded video stream.  Each time a video source is added,
      the RTP mixer needs to request a decoder refresh point from the
      video source, so as to start an uncorrupted prediction chain on
      the spatial area of the mixed picture occupied by the data from
      the new video source.

   2. An RTP video mixer receives multiple encoded RTP video streams
      from conference participants, and dynamically selects one of the
      streams to be included in its output RTP stream.  At the time of a
      bit stream change (determined through means such as voice
      activation or the user interface), the mixer requests a decoder
      refresh point may imply a significant drop from the remote source, in frame
   rate, order to avoid using
      unrelated content as they are commonly much larger than regular predicted
   content.  The use reference data for inter picture prediction.
      After requesting the decoder refresh point, the video mixer stops
      the delivery of this message is restricted the current RTP stream and monitors the RTP stream
      from the new source until it detects data belonging to cases where no
   other means of the decoder
      refresh can be employed, e.g. during point.  At that time, the join-
   phase of RTP mixer starts forwarding the
      newly selected stream to the receiver(s).

   3. An application needs to signal to the remote encoder that the
      desired trade-off between temporal and spatial resolution has
      changed.  For example, one user may prefer a new participant in higher frame rate and
      a multipoint conference.  It lower spatial quality, and another user may prefer the opposite.
      This choice is
   explicitly disallowed also highly content dependent.  Many current video
      conferencing systems offer in the user interface a mechanism to use
      make this selection, usually in the FIR command for error resilience
   purposes, and instead it form of a slider.  The
      mechanism is referred helpful in point-to-point, centralized multipoint and
      non-centralized multipoint uses.

   4. Use case 4 of the Basso draft applies only to AVPF's Picture Loss
      Indication (PLI) as defined in AVPF [RFC4585] PLI message,
   which reports lost pictures and is not
      reproduced here.

   5. Use case 5 of the Basso draft relates to a mechanism known as
      "freeze picture request".  Sending freeze picture requests
      over a non-reliable forward RTCP channel has been identified as
      problematic.  Therefore, no freeze picture request has been
      included in AVPF for
   precisely that purpose.  The message does not require a reception
   notification, as this memo, and the presence use case discussion is not
      reproduced here.

   6. A video mixer dynamically selects one of a decoder refresh point can the received video
      streams to be
   easily derived from sent out to participants and tries to provide the media
      highest bit stream.  Today, the FIR message
   appears rate possible to be useful primarily all participants, while minimizing
      stream trans-rating.  One way of achieving this is to set up
      sessions with video streams, but in endpoints using the future
   it may also prove helpful in conjunction with other media codecs maximum bit rate accepted by
      each endpoint, and accepted by the call admission method used by
      the mixer.  By means of commands that
   support prediction across RTP packets.

   The Temporary Maximum Media Stream Bitrate Request (TMMBR) allows to
   signal, from media receiver to media sender, reduce the current maximum media
      stream bit-rate for a given media stream.  The bit rate below what has been negotiated during session set
      up, the mixer can reduce the maximum media
   stream bit-rate is defined as a tuple. The first value is bit rate sent by endpoints to
      the lowest of all the accepted bit rates.  As the bit- lowest accepted
      bit rate available for changes due to endpoints joining and leaving or due to
      network congestion, the packet stream mixer can adjust the limits at which
      endpoints can send their streams to match the layer reported on. new value.  The
   second value
      mixer then requests a new maximum bit rate, which is equal to or
      less than the measured header sizes between the start of the
   header maximum bit rate negotiated at session setup for the layer reported on and the beginning of the RTP
   payload.    Once, the a
      specific media sender has received stream, and the TMMBR request on remote endpoint can respond with
      the bitrate limitation, actual bit rate that it notifies the initiator of the request, and
   all other session participants, by sending a Temporal Maximum Media
   Stream Bitrate Notification (TMMBN). can support.

   The TMMBN contains a list of
   the current applicable restrictions picture Basso, et al draws up covers most applications we
   foresee.  However we would like to help extend the participants list with two
   additional use cases:

   7. Currently deployed congestion control algorithms (AMID and TFRC
      [RFC3448]) probe for additional available capacity as long as
      there is something to
   suppress TMMBR requests that wouldn't send.  With congestion control algorithms
      using packet loss as the indication for congestion, this probing
      does generally result in further restrictions
   for the sender.  One usage scenario can be seen as limiting reduced media
   senders in multiparty conferencing quality (often to the slowest receiver's Maximum
   Media Stream bitrate reception/handling capability.  Such a use point
      where the distortion is
   helpful, for example, because large enough to make the receiver's situation may have
   changed media unusable),
      due to computational load, or because packet loss and increased delay.

      In a number of deployment scenarios, especially cellular ones, the receiver has just
   joined
      bottleneck link is often the conference, and considers it helpful to inform media
   sender(s) about its constraints, without waiting for congestion
   induced bitrate reduction.  Another application involves graceful
   bitrate adaptation in scenarios where last hop link.  That cellular link
      also commonly has some type of QoS negotiation enabling the upper limit connection
   bitrate
      cellular device to a learn the maximal bit rate available over this
      last hop.  A media receiver changes, but is known behind this link can, in most (if not
      all) cases, calculate at least an upper bound for the interval between
   these dynamic changes.  The TMMBR/TMMBN messages are useful bit rate
      available for all each media types that are not inherently of constant bit rate.  However,
   TMMBR stream it presently receives.  How this
      is not a congestion control mechanism done is an implementation detail and can't replace not discussed herein.
      Indicating the
   need to implement one.

   The Video Back Channel Message (VBCM) allows conveying maximum available bit rate to the transmitting
      party for the various media streams
   conforming can be beneficial to ITU-T Rec. H.271 [H.271], prevent
      that party from a video receiver to
   video sender.  This ITU-T Recommendation defines codepoints probing for a
   number of video-specific feedback messages.  Examples include
   messages to signal:
   - the corruption of reference pictures or parts thereof,
   - the corruption of decoder state information, e.g. parameter sets,
   - the suggestion bandwidth for this stream in excess of using
      a reference picture known hard limit.  For cellular or other than the one
      typically used, e.g. to support mobile devices, the NEWPRED algorithm [NEWPRED].
   The ITU-T has
      known available bit rate for each stream (deduced from the authority link
      bit rate) can change quickly, due to add codepoints handover to H.271 every time a
   need arises, e.g. with the introduction another
      transmission technology, QoS renegotiation due to congestion, etc.
      To enable minimal disruption of new video codecs or new
   tools into existing video codecs.

   There exists some overlap between VBCM messages service, quick convergence is
      necessary, and native messages
   specified therefore media path signaling is desirable.

    8. The use of reference picture selection (RPS) as an error
       resilience tool has been introduced in this memo 1997 as NEWPRED [NEWPRED],
       and is now widely deployed.  When RPS is in AVPF.  Examples include use, simplistically
       put, the PLI receiver can send a feedback message
   of [RFC4585] and to the FIR message specified herein.  As sender,
       indicating a general
   rule, the native messages reference picture that should be preferred over the sending of
   VBCM messages when all senders and receivers implement this memo.
   However, if gateways are in the picture, it may be more advisable to
   utilize VBCM.  Similarly, used for future
       prediction. ([NEWPRED] mentions other forms of feedback message types that exist in
   H.271 as well.)
       AVPF contains a mechanism for conveying such a message, but do did
       not exist in this memo or AVPF, there is no other choice
   but using VBCM.

   Video Back Channel Messages specify for which codec and according to which syntax the
       message should conform.  Recently, the ITU-T finalized Rec. H.271 do not require
       which (among other message types) also includes a
   notification on feedback
       message.  It is expected that this feedback message will fairly
       quickly enjoy wide support.  Therefore, a protocol level, because the appropriate reaction of
   the video encoder and sender can mechanism to convey
       feedback messages according to H.271 appears to be derived from desirable.

3.2. Using the forward video
   bit stream.

   Finally, Media Path

   There are multiple reasons why we use the Temporal-Spatial Trade-off Request (TSTR) enables a
   video receiver to signal to media path for the video sender its preference codec
   control messages.

   First, systems employing MCUs often separate the control and media
   processing parts.  As these messages are intended for
   spatial quality or high temporal resolution (frame rate).  Typically, generated by
   the media part rather than the signaling part of the MCU, having them
   on the media path avoids transmission across interfaces and
   unnecessary control traffic between signaling and processing.  If the receiver
   MCU is physically decomposed, the use of the video stream generates this signal based on input
   from its user interface, media path avoids the
   need for media control protocol extensions (e.g. in reaction MEGACO
   [RFC3525]).

   Secondly, the signaling path quite commonly contains several
   signaling entities, e.g. SIP proxies and application servers.
   Avoiding going through signaling entities avoids delay for several
   reasons.  Proxies have less stringent delay requirements than media
   processing and due to explicit requests their complex and more generic nature may
   result in significant processing delay.  The topological locations of
   the
   user.  However, some implicit use forms signaling entities are also known.  For example,
   the trade-offs commonly used not optimized for live video minimal
   delay, but rather towards other architectural goals.  Thus the
   signaling path can be significantly longer in both geographical and document camera
   content are different.  Obviously, this indication is relevant only
   with respect to video transmission.
   delay sense.

3.3. Using AVPF

   The AVPF feedback message is acknowledged by a
   notification message indicating framework [RFC4585] provides the newly chosen tradeoff, so
   appropriate framework to
   allow immediate user feedback.

2.   Definitions

2.1.     Glossary

   AMID   - Additive Increase Multiplicative Decrease
   ASM    - Asynchronous Multicast implement the new messages.  AVPF   - The Extended RTP Profile for RTCP-based Feedback
   FEC    - Forward Error Correction
   FIR    - Full Intra Request
   MCU    - Multipoint Control Unit
   MPEG   - Moving Picture Experts Group
   PtM    - Point to Multipoint
   PtP    - Point to Point
   TMMBN  - Temporary Maximum Media Stream Bitrate Notification
   TMMBR  - Temporary Maximum Media Stream Bitrate Request
   PLI    - Picture Loss Indication
   TSTN   - Temporal Spatial Trade-off Notification
   TSTR   - Temporal Spatial Trade-off Request
   VBCM   - Video Back Channel Message indication.

2.2.     Terminology implements
   rules controlling the timing of feedback messages to avoid congestion
   through network flooding by RTCP traffic.  We re-use these rules by
   referencing AVPF.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are signaling setup for AVPF allows each individual type of function
   to be interpreted as described configured or negotiated on an RTP session basis.

3.3.1. Reliability

   The use of RTCP messages implies that each message transfer is
   unreliable, unless the lower layer transport provides reliability.
   The different messages proposed in RFC 2119 [RFC2119].

      Message:
          Codepoint defined by this specification, of one specification have different
   requirements in terms of reliability.  However, in all cases, the
          following types:

     Request:
              Message that requires Acknowledgement

     Command:
              Message that forces the receiver
   reaction to an action

     Indication:
              Message that reports (occasional) loss of a situation

     Notification:
             See Indication.

            Note that, feedback message is specified.

3.4. Multicast

   The codec control messages might be used with multicast.  The RTCP
   timing rules specified in [RFC3550] and [RFC4585] ensure that the exception
   messages do not cause overload of ''Notification'', this
            terminology is the RTCP connection.  The use of
   multicast may result in alignment the reception of messages with ITU-T Rec. H.245.

     Decoder Refresh Point: inconsistent
   semantics.   The reaction to inconsistencies depends on the message
   type, and is discussed for each message type separately.

3.5. Feedback Messages

   This section describes the semantics of the different feedback
   messages and how they apply to the different use cases.

3.5.1. Full Intra Request Command

   A bit string, packetised in one or more RTP packets, which
            completely resets Full Intra Request (FIR) Command, when received by the designated
   media sender, requires that the decoder to media sender sends a known state. Typical
            examples of Decoder Refresh Points are H.261 Intra pictures
   Point (see 2.2) at the earliest opportunity.  The evaluation of such
   opportunity includes the current encoder coding strategy and H.264 IDR pictures. However, there are the
   current available network resources.

   FIR is also much more
            complex decoder refresh points, known as discussed below.

            Examples for "hard" decoder refresh points are Intra pictures
            in H.261, H.263, MPEG 1, MPEG 2, and MPEG-4 part 2, and IDR
            pictures in H.264.  "Gradual" decoder refresh points may also
            be used; see for example [AVC].  While both "hard" and
            "gradual" an "instantaneous decoder refresh points are acceptable in the scope
            of this specification, in most cases the user experience will
            benefit from using request" or
   "video fast update request".

   Using a "hard" decoder refresh point.

            A decoder refresh point also contains all header information
            above the implies refraining from using any
   picture layer (or equivalent, depending on the
            video compression standard) sent prior to that is conveyed in-band.  In
            H.264, for example, a decoder refresh point contains
            parameter set NAL units that generate parameter sets
            necessary as a reference for the decoding encoding
   process of any subsequent picture sent in the following slice/data
            partition NAL units (and stream.  For predictive
   media types that are not conveyed out of band).

   Decoding:
            The operation video, the analogue applies.  For example,
   if in MPEG-4 systems scene updates are used, the decoder refresh
   point consists of reconstructing the media stream.

   Rendering:
            The operation full representation of presenting (parts of) the reconstructed
            media stream to scene and is not
   delta-coded relative to previous updates.

   Decoder refresh points, especially Intra or IDR pictures, are in
   general several times larger in size than predicted pictures.  Thus,
   in scenarios in which the available bit rate is small, the user.

   Stream thinning:
           The operation of removing some use of the packets from a media
            stream.  Stream thinning, preferably, is media-aware,
            implying
   decoder refresh point implies a delay that media packets are removed in is significantly longer
   than the order typical picture duration.

   Usage in multicast is possible; however aggregation of their
            relevance to the reproductive quality. However even when
            employing media-aware stream thinning, most media streams
            quickly lose quality when subject to increasing levels of
            thinning.  Media-unaware stream thinning leads to even worse
            quality degradation.  In contrast to transcoding, stream
            thinning commands
   is typically seen as recommended.  A receiver that receives a computationally lightweight
            operation

   Media:   Often used (sometimes in conjunction with terms like
            bitrate, stream, sender, ...) to identify the content of request closely (within 2
   times the
            forward RTP longest Round Trip Time (RTT) known, plus any AVPF-induced
   RTCP packet stream carrying the codec data sending delays, if those are known) after sending a
   decoder refresh point, should await a second request message to which
   ensure that the codec control message applies to.

   Media Stream: media receiver has not been served by the previously
   delivered decoder refresh point.  The stream of packets carrying reason for the media (and in some
            case also repair information such as retransmission or
            Forward Error Correction (FEC) information). We further
            include within this specification specified delay
   is to avoid sending unnecessary decoder refresh points.  A session
   participant may have sent its own request while another participant's
   request was in-flight to them.  Suppressing those requests that may
   have been sent without knowledge about the RTP packetization and other request avoids this
   issue.

   Using the usage of additional protocol headers on these packets FIR command to
            carry them recover from sender to receiver.

2.3.     Topologies
   Please refer to [Topologies] for an in depth discussion. errors is explicitly
   disallowed, and instead the
   topologies referred to throughout this memo are labeled (consistent
   with [Topologies] as follows:

   Topo-Point-to-Point . . . . . point-to-point communication
   Topo-Multicast  . . . . . . . multicast communication as PLI message defined in RFC 3550
   Topo-Translator . . . . . . . translator based as AVPF [RFC4585]
   should be used.  The PLI message reports lost pictures and has been
   included in RFC 3550
   Topo-Mixer  . . . . . . . . . mixer based as AVPF for precisely that purpose.

   Full Intra Request is applicable in RFC 3550
   Topo-Video-switch-MCU . . . . video switching MCU,
   Topo-RTCP-terminating-MCU . . mixer but terminating RTCP

3.   Motivation (Informative)

   This section discusses the motivation use-cases 1 and usage 2.

3.5.1.1. Reliability

   The FIR message results in the delivery of a decoder refresh point,
   unless the different
   video and media control messages. The video control messages have
   been under discussion message is lost.  Decoder refresh points are easily
   identifiable from the bit stream.  Therefore, there is no need for a long time, and a requirement draft was
   drawn up [Basso]. This draft has expired; however we do quote
   relevant sections of it to provide motivation
   protocol-level notification, and requirements.

3.1.     Use Cases

   There are a number of possible usages simple command repetition
   mechanism is sufficient for ensuring the proposed feedback
   messages. Let's begin with looking through level of reliability
   required.  However, the potential use cases Basso et al.
   [Basso] proposed. Some of repetition does require a
   mechanism to prevent the use cases have been reformulated recipient from responding to messages
   already received and
   commented:

   1. An RTP video mixer composes multiple encoded video sources into a
      single encoded video stream. Each time responded to.

   To ensure the best possible reliability, a video source sender of FIR may repeat
   the FIR request until the desired content has been received.  The
   repetition interval is added, determined by the RTP mixer needs RTCP timing rules applicable
   to request the session.  Upon reception of a complete decoder refresh point from
   or the
      video source, so as to start detection of an uncorrupted prediction chain on attempt to send a decoder refresh point (which
   got damaged due to a packet loss), the spatial area repetition of the mixed picture occupied by the data from
      the new video source.

   2. An RTP video mixer that receives multiple encoded RTP video
      streams from conference participants, and dynamically selects one
      of FIR must
   stop.  If another FIR is necessary, the streams to request sequence number must
   be included increased.  A FIR sender shall not have more than one FIR request
   (different request sequence number) outstanding at any time per media
   sender in its output RTP stream.  At the
      time session.

   The receiver of a bit stream change (determined through means such as
      voice activation or the user interface), FIR (i.e. the mixer requests media sender) behaves in complementary
   fashion to ensure delivery of a decoder refresh point from the remote source, in order to avoid
      using unrelated content as reference data for inter picture
      prediction.  After requesting point.  If it
   receives repetitions of the FIR more than 2*RTT after it has sent a
   decoder refresh point, the video
      mixer stops the delivery of the current RTP stream and monitors
      the RTP stream from the new source until it detects data belonging
      to the shall send a new decoder refresh point.  At that time, the RTP mixer starts
      forwarding the newly selected stream to
   Two round trip times allow time for the receiver(s).

   3. An application needs decoder refresh point to signal
   arrive back to the remote encoder a request requestor and for the end of
      change repetitions of the desired trade-off in temporal/spatial resolution.
      For example, one user may prefer a higher frame rate and a lower
      spatial quality, FIR to
   reach and another user may prefer the opposite.  This
      choice is also highly content dependent.  Many current video
      conferencing systems offer in be detected by the user interface media sender.

   An RTP mixer that receives an FIR from a mechanism media receiver is
   responsible to
      make this selection, usually in the form of ensure that a slider.  The
      mechanism decoder refresh point is helpful in point-to-point, centralized multipoint and
      non-centralized multipoint uses.

   4. Use case 4 of the Basso draft applies only delivered to AVPF's PLI [RFC4585]
      and is not reproduced here.

   5. Use case 5 of
   the Basso draft relates requesting receiver.  It may be necessary for the mixer to
   generate FIR commands.  From a mechanism known as
      "freeze picture request".  Sending freeze picture requests
      over a non-reliable forward RTCP channel has been identified as
      problematic.  Therefore, no freeze picture request has been
      included in this memo, and reliability perspective, the use case discussion is not
      reproduced here.

   6. A video two legs
   (FIR-requesting endpoint to mixer, and mixer dynamically selects one of to decoder refresh point
   generating endpoint) are handled independently from each other.

3.5.2. Temporal Spatial Trade-off Request and Notification

   The Temporal Spatial Trade-off Request (TSTR) instructs the received video
      streams to be sent out
   encoder to participants change its trade-off between temporal and tries to provide the
      highest bit rate possible spatial
   resolution.  Index values from 0 to all participants, while minimizing
      stream transrating. One way 31 indicate monotonically a
   desire for higher frame rate.  That is, a requester asking for an
   index of achieving this 0 prefers a high quality and is willing to setup sessions
      with endpoints using the maximum bit rate accepted by that
      endpoint, and by the call admission method used by accept a low
   frame rate, whereas a requester asking for 31 wishes a high frame
   rate, potentially at the mixer. By
      means cost of commands that allow reducing the Maximum Media Stream
      bitrate beyond what has been negotiated during session setup, low spatial quality.

   In general the
      mixer can then reduce encoder reaction time may be significantly longer than
   the maximum bit rate sent by endpoints typical picture duration.  See use case 3 for an example.  The
   encoder decides whether and to what extent the lowest common denominator request results in a
   change of all received streams. As the
      lowest common denominator changes due trade-off.  It returns a Temporal Spatial Trade-Off
   Notification (TSTN) message to endpoints joining,
      leaving, or network congestion, the mixer can adjust indicate the limits to
      which endpoints can send their streams trade-off that it will
   use henceforth.

   TSTR and TSTN have been introduced primarily because it is believed
   that control protocol mechanisms, e.g. a SIP re-invite, are too
   heavyweight and too slow to match the new limit. The
      mixer then would request allow for a new maximum bit rate, which is equal or
      less than the maximum bit-rate negotiated at session setup, reasonable user experience.

   Consider, for example, a
      specific media stream, and user interface where the remote endpoint can respond with user selects
   the actual bit-rate that temporal/spatial trade-off with a slider (as it can support.

   The picture Basso, et al draws up covers most applications we
   foresee. However we is common in
   state-of-the-art video conferencing systems).  An immediate feedback
   to any slider movement is required for a reasonable user experience.
   A SIP re-INVITE [RFC3261] would like require at least two round-trips more
   (compared to extend the list with two additional TSTR/TSTN mechanism) and may involve proxies and
   other complex mechanisms.  Even in a well-designed system, it could
   take a second or so until finally the new trade-off is selected.
   Furthermore the use cases:

   7. of RTCP solves the multicast use case very
   efficiently.

   The used congestion control algorithms (AMID use of TSTR and TFRC [RFC3448])
      probe for more available capacity as long as there TSTN in multipoint scenarios is something to
      send. With congestion control using packet-loss as a non-trivial
   subject, and can be achieved in many implementation-specific ways.
   Problems stem from the indication fact that TSTRs will typically arrive
   unsynchronized, and may request different trade-off values for congestion, this probing the
   same stream and/or endpoint encoder.  This memo does generally result in reduced
      media quality (often not specify a
   translator, mixer or endpoint's reaction to the reception of a point where
   suggested trade-off as conveyed in the distortion is large
      enough TSTR.  We only require the
   receiver of a TSTR message to make the media unusable), due reply to packet loss and
      increased delay. In it by sending a number of deployment scenarios, especially
      cellular ones, TSTN, carrying
   the bottleneck link is often new trade-off chosen by its own criteria (which may or may not be
   based on the last hop link.
      That cellular link also commonly has some type of QoS negotiation
      enabling trade-off conveyed by the cellular device TSTR).  In other words, the
   trade-off sent in TSTR is a non-binding recommendation, nothing more.

   Four TSTR/TSTN scenarios need to learn be distinguished, based on the maximal bit-rate
      available over
   topologies described in [Topologies].  The scenarios are described in
   the following sub-clauses.

3.5.2.1. Point-to-Point

   In this last hop. Thus, indicating most trivial case (Topo-Point-to-Point), the maximum
      available bit-rate media sender
   typically adjusts its temporal/spatial trade-off based on the
   requested value in TSTR, subject to its own capabilities.  The TSTN
   message conveys back the transmitting part can new trade-off value (which may be beneficial to
      prevent it from even trying identical
   to exceed the known hard limit that
      exists. For cellular or other mobile devices old one if, for example, the available known
      bit-rate can also quickly change due sender is not capable of
   adjusting its trade-off).

3.5.2.2. Point-to-Multipoint Using Multicast or Translators

   RTCP Multicast is used either with media multicast according to handover Topo-
   Multicast, or following RFC 3550's translator model according to
   Topo-Translator.  In these cases, unsynchronized TSTR messages from
   different receivers may be received, possibly with different
   requested trade-offs (because of different user preferences).  This
   memo does not specify how the media sender tunes its trade-off.
   Possible strategies include selecting the mean or median of all
   trade-off requests received, giving priority to another
      transmission technology, QoS renegotiation due certain participants,
   or continuing to congestion, etc.
      To enable minimal disruption of service quick convergence is
      necessary, and therefore media path signaling is desirable.

    8. The use the previously selected trade-off (e.g. when the
   sender is not capable of reference picture selection (RPS) as an error
       resilience tool adjusting it).  Again, all TSTR messages
   need to be acknowledged by TSTN, and the value conveyed back has been introduced in 1997 as NEWPRED [NEWPRED], to
   reflect the decision made.

3.5.2.3. Point-to-Multipoint Using RTP Mixer

   In this scenario (Topo-Mixer) the RTP mixer receives all TSTR
   messages, and is now widely deployed.  When RPS is in use, simplisticly put, has the receiver can send a feedback message opportunity to act on them based on its own
   criteria.  In most cases, the sender, indicating
       a reference picture that mixer should be used for future prediction.
       ([NEWPRED] mentions other forms of feedback as well.)  AVPF
       contains a mechanism for conveying such form a message, but did not
       specify for which codec "consensus" of
   potentially conflicting TSTR messages arriving from different
   participants, and according initiate its own TSTR message(s) to which syntax the message
       conforms to.  Recently, media
   sender(s).  As in the ITU-T finalized Rec. H.271 which
       (among other message types) also includes a feedback message.  It
       is expected that previous scenario, the strategy for forming
   this feedback message will enjoy wide support and
       fairly quickly.  Therefore, a mechanism "consensus" is up to convey feedback
       messages according the implementation, and can, for example,
   encompass averaging the participants' request values, giving priority
   to H.271 appears certain participants, or using session default values.

   Even if a mixer or translator performs transcoding, it is very
   difficult to be desirable.

3.2.     Using the Media Path

   There are multiple reasons why we use the deliver media path for with the codec
   control messages.

   First, systems employing MCUs are often separating requested trade-off, unless the control and
   media processing parts. As these messages are intended
   content the mixer or generated
   by translator receives is already close to that
   trade-off.  Thus if the mixer changes its trade-off, it needs to
   request the media part rather than sender(s) to use the signaling part new value, by creating a TSTR
   of the MCU, having
   them its own.  Upon reaching a decision on the media path avoids interfaces and unnecessary control
   traffic between signaling and processing.  If the MCU is physically
   decomposite, the use of used trade-off it
   includes that value in the media path avoids acknowledgement to the need for media
   control protocol extensions (e.g. downstream
   requestors.  Only in MEGACO [RFC3525]).

   Secondly, cases where the signaling path quite commonly contains several
   signaling entities, e.g. SIP-proxies and application servers.
   Avoiding going through signaling entities avoids delay for several
   reasons. Proxies have less stringent delay requirements than media
   processing and due to their complex and more generic nature may original source has
   substantially higher quality (and bit rate), is it likely that
   transcoding alone can result in significant processing delay. the requested trade-off.

3.5.2.4. Reliability

   A request and reception acknowledgement mechanism is specified.  The topological locations of
   Temporal Spatial Trade-off Notification (TSTN) message informs the signaling entities are also commonly not optimized
   request-sender that its request has been received, and what trade-off
   is used henceforth.  This acknowledgment mechanism is desirable for minimal
   delay, but rather towards other architectural goals. Thus
   at least the following reasons:

   o A change in the
   signaling path can trade-off cannot be significantly longer in both geographical and
   delay sense.

3.3.     Using AVPF

   The AVPF directly identified from the
     media bit stream.
   o User feedback message framework [RFC4585] provides a simple way
   of implementing cannot be implemented without knowing the new messages.  Furthermore, AVPF implements rules
   controlling chosen
     trade-off value, according to the timing media sender's constraints.
   o Repetitive sending of feedback messages so requesting an unimplementable trade-
     off can be avoided.

3.5.3. H.271 Video Back Channel Message
   ITU-T Rec. H.271 defines syntax, semantics, and suggested encoder
   reaction to avoid congestion
   through network flooding by RTCP traffic.  We re-use these rules by
   referencing AVPF. a video back channel message.  The signaling setup for AVPF allows each individual type of function structure defined in
   this memo is used to be configured or negotiated on transparently convey such a RTP session basis.

3.3.1.       Reliability

   The use message from media
   receiver to media sender.  In this memo, we refrain from an in-depth
   discussion of RTCP the available code points within H.271 and refer to the
   specification text [H.271] instead.

   However, we note that some H.271 messages implies bear similarities with
   native messages of AVPF and this memo.  Furthermore, we note that each
   some H.271 message transfer is
   unreliable, unless the lower layer transport provides reliability.
   The different messages proposed are known to require caution in this specification have different
   requirements multicast
   environments -- or are plainly not usable in terms multicast or multipoint
   scenarios.  Table 1 provides a brief, oversimplifying overview of reliability. However, in all cases, the
   reaction to an (occasional) loss of a feedback message is specified.

3.4.     Multicast

   The codec control
   messages might be used with multicast. The RTCP
   timing rules currently defined in H.271, their roughly corresponding AVPF
   or CCM messages (the latter as specified in [RFC3550] this memo), and [RFC4585] ensure that the
   messages do not cause overload an
   indication of the RTCP connection.  The use our current knowledge of their multicast may result in the reception safety.

   H.271 msg type       AVPF/CCM msg type    multicast-safe
   ---------------------------------------------------------------------
   0 (when used for
     reference picture
      selection)        AVPF RPSI        No (positive ACK of pictures)
   1 picture loss       AVPF PLI         Yes
   2 partial loss       AVPF SLI         Yes
   3 one parameter CRC  N/A              Yes (no required sender action)
   4 all parameter CRC  N/A              Yes (no required sender action)
   5 refresh point      CCM FIR          Yes

   Table 1: H.271 messages with inconsistent
   semantics.   The reaction to inconsistencies depends on the message
   type, and is discussed for each their AVPF/CCM equivalents

          Note: H.271 message type separately.

3.5.     Feedback Messages

   This section describes the semantics of the different feedback
   messages and how they apply to the different use cases.

3.5.1.       Full Intra Request Command

   A Full Intra Request (FIR) Command, when received by the designated
   media sender, requires that the media sender sends 0 is not a Decoder Refresh
   Point (see 2.2) at the earliest opportunity. The evaluation strict equivalent to
          AVPF's Reference Picture Selection Indication (RPSI); it is an
          indication of such
   opportunity includes the current encoder coding strategy and known-as-correct reference picture(s) at the
   current available network resources.

   FIR is also known as
          decoder.  It does not command an ''instantaneous decoder refresh request''
   or ''video fast update request''.

   Using a decoder refresh point implies refraining from using any
   picture sent prior to that point as encoder to use a defined
          reference for the encoding
   process of any subsequent picture sent (the form of control information envisioned
          to be carried in the stream.  For predictive
   media types RPSI).  However, it is believed and intended
          that are not video, H.271 message type 0 will be used for the analogue applies.  For example,
   if in MPEG-4 systems scene updates same purpose as
          AVPF's RPSI -- although other use forms are used, also possible.

   In response to the decoder refresh
   point consists opaqueness of the full representation of H.271 messages especially with
   respect to the scene and is not
   delta-coded relative multicast safety, the following guidelines MUST be
   followed when an implementation wishes to previous updates.

   Decoder Refresh Points, especially Intra or IDR pictures, are employ the H.271 video back
   channel message:

   1. Implementations utilizing the H.271 feedback message MUST stay in
   general several times larger
      compliance with congestion control principles, as outlined in size than predicted pictures.  Thus,
      section 5.

   2. An implementation SHOULD utilize the IETF-native messages as
      defined in scenarios [RFC4585] and in which the available bit-rate is small, the use this memo instead of a
   Decoder Refresh Point implies a delay that is significantly longer
   than the typical picture duration.

   Usage similar messages
      defined in multicast is possible; however aggregation [H.271].  Our current understanding of the commands similar messages
      is recommended. A receiver that receives a request closely (within 2
   times documented in Table 1 above.  One good reason to divert from
      the longest Round Trip Time (RTT) known) after sending a
   Decoder Refresh Point should await SHOULD statement above would be if it is clearly understood
      that, for a second request message given application and video compression standard, the
      aforementioned "similarity" is not given, in contrast to ensure
   that what
      the media receiver table indicates.

   3. It has not been served by observed that some of the previously
   delivered Decoder Refresh Point. The reason for delaying 2 times H.271 code points currently
      in existence are not multicast-safe.  Therefore, the
   longest known RTT is sensible
      thing to avoid sending unnecessary Decoder Refresh
   Points. A session participant may have sent its own request while
   another participant's request was in-flight do is not to them. Suppressing
   those requests that may have been sent without knowledge about use the
   other request avoids this issue.

   Full Intra Request is applicable H.271 feedback message type in use-case 1, 2,
      multicast environments.  It MAY be used only when all the issues
      mentioned later are fully understood by the implementer, and 5.

3.5.1.1.         Reliability

   The FIR
      properly taken into account by all endpoints.  In all other cases,
      the H.271 message results type MUST NOT be used in conjunction with
      multicast.

   4. It has been observed that even in centralized multipoint
      environments, where the delivery mixer should theoretically be able to
      resolve issues as documented below, the implementation of such a Decoder Refresh Point,
      mixer and cooperative endpoints is a very difficult and tedious
      task.  Therefore, H.271 messages MUST NOT be used in centralized
      multipoint scenarios, unless all the message is lost. Decoder Refresh Points issues mentioned below are easily
   identifiable from
      fully understood by the bit stream. Therefore, there implementer, and properly taken into
      account by both mixer and endpoints.

   Issues to be taken into account when considering the use of H.271 in
   multipoint environments:

   1. Different state on different receivers.  In many environments it
      cannot be guaranteed that the decoder state of all media receivers
      is no need identical at any given point in time.  The most obvious reason
      for
   protocol-level notification, and such a simple command repetition
   mechanism possible misalignment of state is sufficient for ensuring a loss that occurs on
      the level path to only one of reliability
   required. many media receivers.  However, the potential use of repetition does require a
   mechanism there are
      other not so obvious reasons, such as recent joins to prevent the recipient from responding to messages
   already received and responded to.

   To ensure
      multipoint conference (be it by joining the best possible reliability, a sender of FIR may repeat multicast group or
      through additional mixer output).  Different states can lead the FIR request until a response has been received. The repetition
   interval is determined
      media receivers to issue potentially contradicting H.271 messages
      (or one media receiver issuing an H.271 message that, when
      observed by the RTCP timing rules applicable to media sender, is not helpful for the
   session. Upon reception other media
      receivers).  A naive reaction of a complete Decoder Refresh Point or the
   detection of an attempt media sender to send a Decoder Refresh Point (which got
   damaged due these
      contradicting messages can lead to unpredictable and annoying
      results.

   2. Combining messages from different media receivers in a packet loss), the repetition of the FIR must stop.
   If another FIR media
      sender is necessary, a non-trivial task.  As reasons, we note that these
      messages may be contradicting each other, and that their transport
      is unreliable (there may well be other reasons).  In case of many
      H.271 messages (i.e. types 0, 2, 3, and 4), the request sequence number algorithm for
      combining must be
   increased. To combat loss aware both of the Decoder Refresh Points sent, the
   sender that receives repetitions network/protocol environment
      (i.e. with respect to congestion) and of the FIR 2*RTT after the
   transmission media codec employed,
      as H.271 messages of the Decoder Refresh Point shall send a new Decoder
   Refresh Point. Two round trip times allow time given type can have different semantics for the request
      different media codecs.

   3. The suppression of requests may need to
   arrive at go beyond the media sender basic
      mechanisms described in AVPF (which are driven exclusively by
      timing and transport considerations on the Decoder Refresh Point to arrive
   back protocol level).  For
      example, a receiver is often required to refrain from (or delay)
      generating requests, based on information it receives from the requestor.  A FIR sender shall not have more than one FIR
   request (different request sequence number) outstanding at any time
   per
      media sender in the session.

   An RTP Mixer that receives an stream.  For instance, it makes no sense for a receiver to
      issue a FIR from when a transmission of an Intra/IDR picture is
      ongoing.

   4. When using the non-multicast-safe messages (e.g. H.271 type 0
      positive ACK of received pictures/slices) in larger multicast
      groups, the media receiver is
   responsible will likely be forced to ensure that delay or even
      omit sending these messages.  For the media sender this looks like
      data has not been properly received (although it was received
      properly), and a Decoder Refresh Point is delivered naively implemented media sender reacts to these
      perceived problems where it should not.

3.5.3.1. Reliability

   H.271 Video Back Channel messages do not require reliable
   transmission, and confirmation of the requesting receiver.  It may reception of a message can be necessary for
   derived from the mixer to
   generate FIR commands.  The two legs (FIR-requesting endpoint to
   mixer, and mixer forward video bit stream.  Therefore, no specific
   reception acknowledgement is specified.

   With respect to Decoder Refresh Point generating endpoint) are
   handled independently from each other from a reliability perspective.

3.5.2.       Temporal Spatial Trade-off re-sending rules, clause 3.5.1.1. applies.

3.5.4. Temporary Maximum Media Stream Bit Rate Request and Notification

   The Temporal Spatial Trade-off Request (TSTR) instructs

   A receiver, translator or mixer uses the video
   encoder to change its trade-off between temporal and spatial
   resolution.  Index values from 0 Temporary Maximum Media
   Stream Bit Rate Request (TMMBR, "timber") to 31 indicate monotonically a
   desire for higher frame rate.  That is, a requester asking for an
   index of 0 prefers request a high quality and is willing sender to accept a low
   frame rate, whereas a requester asking
   limit the maximum bit rate for 31 wishes a high frame
   rate, potentially at the cost of low spatial quality.

   In general the encoder reaction time may be significantly longer than media stream (see 2.2) to, or below,
   the typical picture duration.  See use case 3 for an example. provided value.  The
   encoder decides if Temporary Maximum Media Stream Bit Rate
   Notification (TMMBN) contains the request results in a change media sender's current view of the trade off.
   The Temporal Spatial Trade-Off Notification message (TSTN) has been
   defined to provide feedback
   most limiting subset of the trade-off that is used henceforth.

      Informative note: TSTR and TSTN have been introduced primarily
      because TMMBR-defined limits it is believed that control protocol mechanisms, e.g. a SIP
      re-invite, are too heavyweight, and too slow has received, to allow
   help the participants to suppress TMMBR requests that would not
   further restrict the media sender.  The primary usage for the
   TMMBR/TMMBN messages is in a
      reasonable user experience.  Consider, for example, scenario with an MCU or mixer (use case
   6), corresponding to Topo-Translator or Topo-Mixer, but also to Topo-
   Point-to-Point.

   Each temporary limitation on the media stream is expressed as a user
      interface where
   tuple.  The first component of the remote user selects tuple is the temporal/spatial trade-
      off with a slider maximum total media
   bit rate (as it is common defined in state-of-the-art video
      conferencing systems).  An immediate feedback section 2.2) that the media receiver is
   currently prepared to any slider
      movement accept for this media stream.  The second
   component is required the per-packet overhead that the media receiver has
   observed for a reasonable user experience.  A SIP re-
      invite [RFC3261] would require this media stream at least 2 round-trips more
      (compared to the TSTR/TSTN mechanism) and may involve proxies and
      other complex mechanisms.  Even its chosen reference protocol
   layer.

   As indicated in a well-designed system, it may
      take a second or so until finally section 2.2, the new trade-off is selected.
      Furthermore overhead as observed by the use sender
   of RTCP solves very efficiently the multicast
      use case.

   The use of TSTR and TSTN in multipoint scenarios is a non-trivial
   subject, and can be solved in many implementation-specific ways.
   Problems are stemming from TMMBR (i.e. the fact that TSTRs will typically arrive
   unsynchronized, and media receiver) may request different trade-off values for differ from the
   same stream and/or endpoint encoder.  This memo does not specify a
   translator, mixer or endpoint's reaction overhead
   observed at the receiver of the TMMBR (i.e. the media sender) due to the reception
   use of a
   suggested trade-off as conveyed in different reference protocol layer at the TSTR -- we only require other end or due
   to the
   receiver intervention of translators or mixers that affect the amount
   of per packet overhead.  For example, a TSTR message to reply to it by sending a TSTN, carrying gateway in between the new trade-off chosen by its own criteria (which may or may not be
   based on two
   that converts between IPv4 and IPv6 affects the trade-off conveyed per-packet overhead
   by TSTR).  In other words, 20 bytes.  Other mechanisms that change the trade-
   off sent in TSTR overhead include
   tunnels.  The problem with varying overhead is a non-binding recommendation; nothing more.

   With respect to TSTR/TSTN, four scenarios based on the topologies
   described also discussed in [Topologies] need to
   [RFC3890].  As will be distinguished. The scenarios are
   described seen in the following sub-clauses.

3.5.2.1.         Point-to-point

   In this most trivial case (Topo-Point-to-Point), description of the media sender
   typically adjusts its temporal/spatial trade-off based on algorithm for
   use of TMMBR, the
   requested value difference in TSTR, perceived overhead between the
   sending and within its capabilities.  The TSTN
   message conveys back receiving ends presents no difficulty because
   calculations are carried out in terms of variables (packet rate, net
   media bit rate) that have the new trade-off same value (which may be identical
   to the old one if, for example, at the sender is not capable of
   adjusting its trade-off).

3.5.2.2.         Point-to-Multipoint using Multicast or Translators

   RTCP Multicast is used either with as at the
   receiver.

   Reporting both maximum total media multicast according to Topo-
   Multicast, or following RFC 3550's translator model according to
   Topo-Translator.  In these cases, TSTR messages from bit rate and per-packet overhead
   allows different receivers may be received unsynchronized, to provide bit rate and possibly with different
   requested trade-offs (because of overhead values
   for different user preferences).  This
   memo does not specify how protocol layers, for example at the media sender tunes its trade-off.
   Possible strategies include selecting IP level, at the mean, or median,
   outer part of all
   trade-off requests received, prioritize certain participants, a tunnel protocol, or
   continue using at the previously selected trade-off (e.g. when link layer.  The protocol
   level a peer reports on depends on the
   sender is not capable level of adjusting it).  Again, all TSTR messages
   need integration the peer
   has, as it needs to be acknowledged by TSTN, and the value conveyed back has able to
   reflect extract the decision made.

3.5.2.3.         Point-to-Multipoint using RTP Mixer

   In this scenario (Topo-Mixer) information from that
   protocol level.  For example, an application with no knowledge of the RTP Mixer receives all TSTR
   messages,
   IP version it is running over can not meaningfully determine the
   overhead of the IP header, and has hence will not want to include IP
   overhead in the opportunity overhead or maximum total media bit rate calculation.

   It is expected that most peers will be able to act on them based on its own
   criteria. report values at least
   for the IP layer.  In most cases, certain implementations it may be advantageous
   to also include information pertaining to the Mixer should form link layer, which in
   turn allows for a more precise overhead calculation and a ''consensus'' better
   optimization of
   potentially conflicting TSTR connectivity resources.

   The Temporary Maximum Media Stream Bit Rate messages arriving from different
   participants, and initiate its own TSTR message(s) are generic
   messages that can be applied to any RTP packet stream.  This
   separates them from the other codec control messages defined in this
   specification, which apply only to specific media
   sender(s). types or payload
   formats.  The strategy of forming this ''consensus'' is open for TMMBR functionality applies to the implementation, transport, and can, for example, encompass averaging the
   participants request values, prioritizing certain participants, or
   use session default values. If
   requirements the Mixer changes its trade-off, it
   needs to request from transport places on the media sender(s) the use of encoding.

   The reasoning below assumes that the new value,
   by creating participants have negotiated a TSTR of its own. Upon reaching
   session maximum bit rate, using a decision on the used
   trade-off it includes that signaling protocol.  This value can
   be global, for example in the acknowledgement.

   Even if a Mixer case of point-to-point, multicast, or Translator performs transcoding, it is very
   difficult to deliver media with the requested trade-off, unless
   translators.  It may also be local between the
   content participant and the Mixer
   peer or Translator receives is already close to that
   trade-off. Only in cases where mixer.  In either case, the original source has substantially
   higher quality (and bit-rate), it bit rate negotiated in signaling
   is likely the one that transcoding can
   result in the requested trade-off.

3.5.2.4.         Reliability

   A request participant guarantees to be able to handle
   (depacketize and reception acknowledgement mechanism decode).  In practice, the connectivity of the
   participant also influences the negotiated value -- it does not make
   much sense to negotiate a total media bit rate that one's network
   interface does not support.

   It is specified. The
   Temporal Spatial Trade-off Notification (TSTN) message informs also beneficial to have negotiated a maximum packet rate for
   the
   request-sender session or sender.  RFC 3890 provides an SDP [RFC4566] attribute
   that its request has been received, and what trade-off can be used for this purpose; however, that attribute is used henceforth. This acknowledgment mechanism not
   usable in RTP sessions established using offer/answer [RFC3264].
   Therefore an optional maximum packet rate signaling parameter is desirable for at
   least the following reasons:

   o A change
   specified in the trade-off cannot be directly identified from the this memo.

   An already established maximum total media bit stream,
   o User feedback cannot rate may be implemented without information of the
     chosen trade-off value, according changed at
   any time, subject to the media sender's
     constraints,
   o Repetitive timing rules governing the sending of messages requesting an unimplementable trade-
     off can be avoided.

3.5.3.       H.271 Video Back Channel Message

   ITU-T Rec. H.271 defines syntax, semantics, and suggested encoder
   reaction to a video back channel message.
   feedback messages. The codepoint defined in
   this memo is used limit may change to transparently convey such any value between zero and
   the session maximum, as negotiated during session establishment
   signaling.  However, even if a sender has received a TMMBR message from media
   receiver to media sender.  In this memo, we refrain from
   allowing an in-depth
   discussion of increase in the available codepoints within H.271 and refer to bit rate, all increases must be governed
   by a congestion control mechanism.  TMMBR indicates known limitations
   only, usually in the
   specification text instead [H.271].

   However, we note that some H.271 messages bear similarities with
   native messages of AVPF local environment, and this memo. does not provide any
   guarantees about the full path.  Furthermore, we note that
   some H.271 message are known to require caution any increases in multicast
   environments -- or TMMBR-
   established bit rate limits are plainly not usable in multicast or multipoint
   scenarios.  Table 1 provides to be executed only after a brief, oversimplifying overview certain
   delay from the sending of the
   messages currently defined TMMBN message that notifies the world
   about the increase in H.271, their similar AVPF or CCM
   messages (the latter as limit.  The delay is specified in this memo), and an indication as at least
   twice the longest RTT as known by the media sender, plus the media
   sender's calculation of
   our current knowledge the required wait time for the sending of their multicast safety.

   H.271 msg type       AVPF/CCM msg type    multicast-safe
   ---------------------------------------------------------------------
   0 (when used
   another TMMBR message for
     reference picture
      selection) this session based on AVPF RPSI        No (positive ACK timing rules.
   This delay is introduced to allow other session participants to make
   known their bit rate limit requirements, which may be lower.

   If it is likely that the new value indicated by TMMBR will be valid
   for the remainder of pictures)
   1                    AVPF PLI         Yes
   2                    AVPF SLI         Yes
   3                    N/A              Yes (no required sender action)
   4                    N/A              Yes (no required the session, the TMMBR sender action)

   Table 1: H.271 messages and their AVPF/CCM equivalents

          Note: H.271 message type 0 is not a strict equivalent expected to
          AVPF's RPSI; it
   perform a renegotiation of the session upper limit using the session
   signaling protocol.

3.5.4.1. Behavior for media receivers using TMMBR

   This section is an indication informal description of known-as-correct reference
          picture(s) at behaviour described more
   precisely in section 4.2.

   A media sender begins the decoder.  It does not command an encoder to
          use session limited by the maximum media bit
   rate and maximum packet rate negotiated in session signaling, if any.

   Note that this value may be negotiated for another protocol layer
   than the one the participant uses in its TMMBR messages.  Each media
   receiver selects a defined reference picture (the form protocol layer, forms an estimate of control
          information envisioned to be carried in RPSI).  However, the
   overhead it is
          believed and intended observing (or estimating it if no packets has been
   seen yet) at that H.271 message type 0 will be used
          for the same purpose as AVPF's RPSI -- although other use
          forms are also possible.

   In response to reference level, and determines the opaqueness maximum total
   media bit rate it can accept, taking into account its own limitations
   and any transport path limitations of which it may be aware.  In case
   the H.271 messages especially with
   respect to current limitations are more restricting then what was agreed on
   in the multicast safety, session signaling, the following guidelines MUST be
   followed when an implementation wishes media receiver reports its initial
   estimate of these two quantities to employ the H.271 video back
   channel message:

   1. Implementations utilizing the H.271 feedback media sender using a TMMBR
   message.  Overall message MUST stay traffic is reduced by the possibility of
   including tuples for multiple media senders in
      compliance with congestion control principles, the same TMMBR
   message.

   The media sender applies an algorithm such as outlined that specified in
   section 5              ..
   2. An implementation SHOULD utilize 3.5.4.2 to select which of the native messages tuples it has received are
   most limiting (i.e. the bounding set as defined in
      [RFC4585] and in this memo instead of similar messages defined in
      [H.271].  Our current understanding of similar messages is
      documented in Table 1 above.  One good reason section 2.2).  It
   modifies its operation to divert from the
      SHOULD statement above would be if it is clearly understood that,
      for a given application and video compression standard, stay within the
      aforementioned ''similarity'' is not given, feasible region (as defined
   in contrast section 2.2), and also sends out a TMMBN notification to what
      the table indicates.

   3. It has been observed that some of the H.271 codepoints currently
      in existence are not multicast-safe.  Therefore, media
   receivers indicating the sensible
      thing to do is selected bounding set.

   If a media receiver does not to use own one of the H.271 feedback message type tuples in
      multicast environments.  It MAY be used only when all the issues
      mentioned later are fully understood bounding
   set reported by the implementer, and
      properly taken into account by all endpoints.  In all other cases, TMMBN, it applies the H.271 message type MUST NOT be used in conjunction with
      multicast.
   4. It has been observed that even in centralized multipoint
      environments, where same algorithm as the mixer should theoretically be able media
   sender to
      resolve issues as documented below, determine if its current estimated (maximum total media bit
   rate, overhead) tuple would enter the implementation of such a
      mixer and cooperative endpoints is a very difficult and tedious
      task.  Therefore, H.271 message MUST NOT be used in centralized
      multipoint scenarios, unless all bounding set if known to the
   media sender.  If so, it issues mentioned below are
      fully understood by a TMMBR request reporting the implementer, and properly taken into
      account by both mixer and endpoints.

   Issues tuple
   value to be taken into account when considering the use of H.271 in
   multipoint environments:

   1. Different state on different receivers.  In many environments it
      cannot be guarantied that the decoder state of all media receivers
      is identical at any given point in time.  The most obvious reason
      for such a possible misalignment of state is sender.  Otherwise it takes no action for the moment.
   Periodically, its estimated tuple values may change or it may receive
   a loss that occurs on new TMMBN.  If so, it reapplies the link algorithm to only decide whether it
   needs to issue a TMMBR request.

   If, alternatively, a media receiver owns one of many media receivers.  However, there are
      other not so obvious reasons, the tuples in the
   reported bounding set, it takes no action until such time as recent joins to the
      multipoint conference (be its
   estimate of its own tuple values changes.  At that time it by joining the multicast group or
      through additional mixer output).  Different states can lead sends a
   TMMBR request to the media receivers sender to issue potentially contradicting H.271 messages
      (or one report the changed values.

   A media receiver issuing an H.271 may change status between owner and non-owner of a
   bounding tuple between one TMMBN message that, when
      observed by and the media sender, is not helpful for next.  Thus it must
   check the contents of each TMMBN to determine its subsequent actions.

   Implementations may use other media
      receivers).  A naive reaction algorithms of their choosing, as long
   as the media sender to these
      contradicting messages can lead to unpredictable bit rate limitations resulting from the exchange of TMMBR and annoying
      results.
   2. Combining
   TMMBN messages are at least as strict (at least as low, in the bit
   rate dimension) as the ones resulting from different media receivers the use of the
   aforementioned algorithm.

   Obviously, in a media
      sender point-to-point cases, when there is a non-trivial task.  As reasons, we note that these
      messages may be contradicting each other, only one media
   receiver, this receiver becomes "owner" once it receives the first
   TMMBN in response to its own TMMBR, and that their transport stays "owner" for the rest of
   the session.  Therefore, when it is unreliable (there may well known that there will always be other reasons).  In case of many
      H.271 messages (i.e. types 0, 2, 3, and 4),
   only a single media receiver, the above algorithm for
      combining must be both is not required.
   Media receivers that are aware of they are the network/protocol environment
      (i.e. only ones in a session
   can send TMMBR messages with respect to congestion) bit rate limits both higher and of lower
   than the media codec employed,
      as H.271 messages of a given type can have different semantics for
      different media codecs.
   3. The suppression of requests may need previously notified limit, at any time (subject to go beyond the basic
      mechanism described in AVPF (which are driven exclusively by
   [RFC4585] RTCP RR send timing and transport considerations on the protocol level).  For
      example, rules).  However, it may be difficult
   for a receiver is often required session participant to refrain from (or delay)
      generating requests, based on information determine if it receives from is the
      media stream.  For instance, it makes no sense for a only receiver to
      issue a FIR when a transmission in
   the session.  Because of an Intra/IDR picture this any implementation of TMMBR is
      ongoing.
   4. When using required
   to include the non-multicast-safe messages (e.g. H.271 type 0
      positive ACK of received pictures/slices) algorithm described in larger multicast
      groups, the media receiver will likely be forced to delay next section or even
      omit sending these messages.  For a stricter
   equivalent.

3.5.4.2. Algorithm for establishing current limitations

   This section introduces an example algorithm for the calculation of a
   session limit.  Other algorithms can be employed, as long as the
   result of the media sender calculation is at least as restrictive as the result
   that is obtained by this looks like
      data has not been properly received (although algorithm.

   First it was received
      properly), and is important to consider the implications of using a naively implemented tuple
   for limiting the media sender reacts to these
      perceived problems where it shouldn't.

3.5.3.1.         Reliability

   H.271 Video Back Channel messages do not require reliable
   transmission, sender's behavior.  The bit rate and the reception of
   overhead value result in a message can be derived from two-dimensional solution space for the
   calculation of the
   forward video bit stream.  Therefore, no specific reception
   acknowledgement rate of media streams.  Fortunately the two
   variables are linked. Specifically, the bit rate available for RTP
   payloads is specified.

   With respect equal to re-sending rules, clause 3.5.1.1. applies.

3.5.4.       Temporary Maximum Media Stream Bit-rate Request and Notification

   A receiver, translator or mixer uses the Temporary Maximum Media
   Stream Bit-rate Request (TMMBR, "timber") TMMBR reported bit rate minus the packet
   rate used, multiplied by the TMMBR reported overhead converted to request
   bits.  As a sender result, when different bit rate/overhead combinations
   need to
   limit be considered, the packet rate determines the correct
   limitation.  This is perhaps best explained by an example:

   Example:

   Receiver A: TMMBR_max total BR = 35 kbps, TMMBR_OH = 40 bytes
   Receiver B: TMMBR_max total BR = 40 kbps, TMMBR_OH = 60 bytes

   For a given packet rate (PR) the bit rate available for media
   payloads in RTP will be:

   Max_net media_BR_A = TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ...
   (1)
   Max_net media_BR_B = TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ...
   (2)

   For a PR = 20 these calculations will yield a Max_net media_BR_A =
   28600 bps and Max_net media_BR_B = 30400 bps, which suggests that
   receiver A is the maximum bit-rate limiting one for this packet rate.  However at a media stream to, or below,
   certain PR there is a switchover point at which receiver B becomes
   the
   provided value. limiting one.  The Temporary Maximum Media Stream Bit-rate
   Notification (TMMBN) advises the media receiver(s) of the changed
   bitrate it is not going switchover point can be identified by setting
   Max_media_BR_A equal to exceed henceforth.  The primary usage Max_media_BR_B and breaking out PR:

         TMMBR_max total BR_A - TMMBR_max total BR_B
   PR =  ------------------------------------------- ... (3)
                8*(TMMBR_OH_A - TMMBR_OH_B)

   which, for
   this is a scenario with a MCU or Mixer (use case 6), corresponding to
   Topo-Translator or Topo-Mixer, but also Topo-Point-to-Point.

   The temporary limitation on the media stream is expressed numbers above yields 31.25 as a tuple;
   one value limiting the bit-rate at switchover point
   between the layer two limits.  That is, for which the overhead
   is calculated to. packet rates below 31.25 per
   second, receiver A second value provides is the per limiting receiver, and for higher packet header
   overhead
   rates, receiver B is more limiting.  The implications of this
   behavior have to be considered by implementations that are going to
   control media encoding and its packetization.  As exemplified above,
   multiple TMMBR limits may apply to the trade-off between net media
   bit rate and packet rate.  Which limitation applies depends on the layer
   packet rate being considered.

   This also has implications for which bit-rate is reported and how the
   start of TMMBR mechanism needs to work.
   First, there is the RTP payload. By having both values possibility that multiple TMMBR tuples are
   providing limitations on the media stream sender.  Secondly there is a need
   for any session participant (media sender can and receivers) to be able
   to determine the effect of changing the packet rate for if a given tuple will become a limitation upon the media stream in an environment which contains translators
   sender, or mixers
   that affect if the amount set of per packet overhead. For example a gateway
   that convert between IPv4 and IPv6 would affect already given limitations is stricter than
   the per packet
   overhead commonly with 20 bytes. There exist also other mechanisms,
   like tunnels, that change given values.  In the amount absence of headers that are present at a
   particular bottleneck for which the ability to make this
   determination the suppression of TMMBR sending entity has
   knowledge about. requests would not work.

   The problem with varying overhead basic idea of the algorithm is also discussed as follows.  Each TMMBR tuple can
   be viewed as the equation of a straight line (cf. equations (1) and
   (2)) in [RFC3890]. a space where packet rate lies along the X-axis and maximum
   bit rate lies along the Y-axis. The above way lower envelope of measuring allows for one the set of
   lines corresponding to provide bit-rate and
   overhead values for different protocol layers, for example on IP
   level, out part the complete set of TMMBR tuples defines a tunnel protocol,
   polygon. Points lying along or below this polygon are combinations of
   packet rate and bit rate that meet all of the link layer. TMMBR constraints. The level a
   peer report on,
   highest feasible packet rate within this region is fully dependent on the level minimum of integration the
   peer has, as it needs to be able to extract the information from that
   level. It is expected that peers will be able to report values
   rate at
   least for which the IP layer, but in certain implementations link layer may
   be available to allow for more precise information.

   The temporary bounding polygon meets the X-axis or the session
   maximum media stream bit-rate messages are generic
   messages that can be applied to any RTP packet stream.  This
   separates it rate (SMAXPR) provided by signaling, if any. Typically
   a media sender will prefer to operate at a bit from the other codec control messages defined in lower rate than this specification that applies only
   theoretical maximum, so as to specific increase the rate at which actual media types or
   payload formats.
   content reaches the receivers.  The TMMBR functionality applies purpose of the algorithm is to
   distinguish the transport TMMBR tuples constituting the bounding set and thus
   delineate the requirements it places on feasible region, so that the media encoding.

   The reasoning below assumes sender can select
   its preferred operating point within that the participants have negotiated region

   Figure 1 below shows a bounding polygon formed by TMMBR tuples A and
   B. A third tuple C lies outside the bounding polygon and is therefore
   irrelevant in determining feasible tradeoffs between media rate and
   packet rate.  The line labeled ss..s represents the limit on packet
   rate imposed by the session maximum bit-rate, using a packet rate (SMAXPR) obtained by
   signaling protocol. This value can during session setup.  In Figure 1 the limit determined by
   tuple B happens to be global, for example in case of point-to-point, multicast, or
   translators.  It may also more restrictive than SMAXPR.  The situation
   could easily be local between the participant and the
   peer or mixer. In both cases, reverse, meaning that the bit-rate negotiated in signaling bounding polygon is
   terminated on the right by the vertical line representing the SMAXPR
   constraint.

        ^
        |a   c   b             s
   Bit  |  a   c  b            s
   Rate |    a   c b           s
        |      a   cb          s
        |        a   c         s
        |          a  bc       s
        |            a b c     s
        |              ab  c   s
        |  Feasible      b   c s
        |   region        ba   s
        |                  b a s c
        |                   b  s   c
        |                    b s a
        |_____________________bs________
        +------------------------------>____________

              Packet rate

    Figure 1 - Geometric Interpretation of TMMBR Tuples

   Note that the slopes of the lines making up the bounding polygon are
   increasingly negative as one moves in the direction of increasing
   packet rate.  Note also that with slight rearrangement, equations (1)
   and (2) have the participant guarantees to be able to handle (encode canonical form:

          y = mx + b

   where
     m is the slope and decode).  In practice, has value equal to the connectivity negative of the participant also
   bears an influence to tuple
     overhead (in bits),
   and
     b is the negotiated y-intercept and has value -- it does not necessarily
   make much sense equal to negotiate a the tuple maximum total
     media bit rate that one's network
   interface does not support.

   It is also beneficial rate.

   These observations lead to have negotiated a maximum packet rate for the session or sender. RFC 3890 provides such a SDP [RFC4566]
   attribute, however conclusion that is not usable in RTP sessions established
   using offer/answer [RFC3264].  Therefore a max packet rate signaling
   parameter is specified.

   An already established temporary limit may be changed at any time
   (subject to the timing rules of when processing the feedback message sending), and
   TMMBR tuples to
   any values between zero select the initial bounding set, one should sort and
   process the session maximum, as negotiated during
   session establishment signaling. Even if tuples by order of increasing overhead. Once a sender particular
   tuple has received a
   TMMBR message allowing an increase in been added to the bit-rate, bounding set, all increases
   must be governed by a congestion control mechanism. TMMBR only
   indicates known limitations, usually in the local environment, and
   does tuples not provide any guarantees about already
   selected and having lower overhead can be eliminated, because the full path.

   If it is likely that
   next side of the new value  indicated by TMMBR will bounding polygon has to be valid
   for steeper (i.e. the remainder of
   corresponding TMMBR must have higher overhead) than the session, latest added
   tuple.

   Line cc..c in Figure 1 illustrates another principle. This line is
   parallel to line aa..a, but has a higher Y-intercept.  That is, the
   corresponding TMMBR sender can perform tuple contains a
   renegotiation of higher maximum total media bit
   rate value.  Since line cc..c is outside the session upper limit using bounding polygon, it
   illustrates the session signaling
   protocol.

3.5.4.1.         Behavior for media receivers using conclusion that if two TMMBR

   In multipart scenarios, different receivers likely tuples have different
   limits for receiving bitrate.  Therefore, an algorithm to identify the most restrictive TMMBR requests is specified in section 4                                                               ..2.2.1.
   The general behavior is explaind in this section and same
   overhead value, the gist one with higher maximum total media bit rate
   value cannot be part of the
   algorithm to determine bounding set and can be set aside.

   Two further observations complete the most restrictive values are explained
   informally in algorithm.  Obviously, moving
   from the next section.

   Immediately after session setup, left, the bitrate limit is set to successive corners of the
   session limit as established by bounding polygon (i.e.
   the session setup signaling (or
   equivalent).  The overhead value is intersection points between successive pairs of sides) lie at
   successively higher packet rates.  On the other hand, again moving
   from the left, each successive line making up the bounding set to 0.  When
   crosses the session setup
   signaling does not specify a limit, then unlimited bitrate is
   assumed.  Note that many codecs specify their own limits, e.g.
   through H.264's level concept.

   At any given time, X-axis at a media receiver lower packet rate.

   The complete algorithm can send a TMMBR now be specified.  The algorithm works
   with a limit
   that is lower than two lists of TMMBR tuples, the current limit.  The media receiver use candidate list X and the selected
   list Y, both ordered by increasing overhead value.  The algorithm outlined in
   terminates when all members of X have been discarded or removed for
   processing.  Membership of the below Section 3.5.4.2 to determine if its
   limit selected list Y is stricter than already existing ones.  The media sender upon
   receiving the TMMBR request will also excersie probationary until
   the algorithm to
   determine the set is complete.  Each member of most restrictive limitations and then send a
   TMMBN containg that set. Once the media sender has sent selected list is
   associated with an intersection value, which is the TMMBN
   message, packet rate at
   which the receivers indicated in line corresponding to that message becomes ''owners''
   of TMMBR tuple intersects with the limitations.  Most likely,
   line corresponding to the owner is previous TMMBR tuple in the original sender selected list.
   Each member of the TMMBR -- for selected list is also associated with a maximum
   packet rate value, which is the handling lesser of corner-cases (i.e. concurrent TMMBRs
   from different receivers, lost TMMBRs and sender side optimisations)
   please see the formal specification.  ''Owners'' and limits are
   usually known session wide, as both TMMBR maximum packet
   rate SMAXPR (if any) and TMMBN are forwarded the packet rate at which the line
   corresponding to
   all that tuple crosses the X-axis.

   When the algorithm terminates, the selected list is equal to the
   bounding set as defined in section 2.2.

Initial Algorithm

   This algorithm is used by the session unless a Mixer media sender when it has received one
   or Translator separate more TMMBR requests and before it has determined a bounding set
   for the session
   from RTCP handling point first time.

   1. Sort the TMMBR tuples by order of view.

   Only a ''owner'' increasing overhead.  This is allowed to raise
      the bitrate limit to a value
   higher than initial candidate list X.

   2. When multiple tuples in the session has been notified of, candidate list have the same
      overhead value, discard all but not higher than the
   session limit negotiated by one with the lowest maximum
      total media bit rate value.

   3. Select and remove from the candidate list the session setup signaling (see above).
   A ''owner'' does not need to take into account TMMBR messages sent by
   anyone else (although that may well be a desirable optimization). tuple with the
      lowest maximum total media bit rate value.  If
   a ''owner'' sets a new session limit there is more than
      one tuple with that value, choose the one with the highest
      overhead value.  This is too high for someone
   else's liking, other media receivers can react the first member of the selected list Y.
      Set its intersection value equal to zero.  Calculate its maximum
      packet rate as the situation by
   emmitting their own TMMBR message (and, in minimum of SMAXPR (if available) and the process, become a
   ''owner'').  Limitations belonging to ''owners'' timing out value
      obtained from the
   session are removed by following formula, which is the media sender who notifies packet rate at
      which the session
   about corresponding line crosses the event by sending X-axis.

          Max PR = TMMBR max total BR / (8 * TMMBR OH) ... (4)

   4. Discard from the candidate list all tuples with a TMMBN.

   Obviously, when there is only one media receiver, this receiver
   becomes ''owner'' once it receives lower overhead
      value than the selected tuple.

   5. Remove the first TMMBN in response to its
   own TMMBR, and stays ''owner'' remaining tuple from the candidate list for
      processing.  Call this the rest current candidate.

   6. Calculate the packet rate PR at the intersection of the session.
   Therefore, when it is known that there will always be only a single
   media receiver, line
      generated by the above algorithm is not required.  Media receivers
   that are aware they are current candidate with the only ones line generated by the
      last tuple in a session can send TMMBR
   messages with bitrate limits both higher and the selected list Y, using equation (3).

   7. If the calculated value PR is equal to or lower than the
   previously notified limit at any time (subject to AVPF's RTCP RR send
   timing rules).  However, it may be difficult
      intersection value stored for a session
   participant the last tuple of the selected list,
      discard the last tuple of the selected list and go back to determine if it is step 6
      (retaining the only receiver same current candidate).

      Note that the choice of the initial member of the selected list Y
      in step 3 guarantees that the session.
   Due to selected list will never be emptied
      by this process, meaning that any one implementing TMMBR are required the algorithm must eventually (if
      not immediately) fall through to implement this
   algorithm.

3.5.4.2.         Algorithm for exstablishing current limitations

   First it the step 8.

   8. (This step is important to consider reached when the implications calculated PR value of using a tuple
   for limiting the media sender's behavior. The bit-rate and current
      candidate is greater than the
   overhead intersection value results in a 2-dimensional solution space for possible
   media streams. Fortunately of the two variables are linked. The bit-rate
   available for RTP payloads will be equal to current
      last member of the TMMBR reported bit-
   rate minus selected list Y.)  If the calculated value PR
      of the current candidate is lower than the maximum packet rate used times the TMMBR reported overhead.
   This has
      associated with the result last tuple in a session with two different participants
   having set limitations, the used selected list, add the
      current candidate tuple to the end of the selected list.  Store
      PR as its intersection value.  Calculate its maximum packet rate will determine which
      as the lesser of SMAXPR (if available) and the two that applies.

   Example:

   Receiver A: TMMBR_BR = 35 kbps, TMMBR_OH = 40
   Receiver B: TMMBR_BR = 40 kbps, TMMBR_OH = 60

   For a given maximum packet
      rate (PR) calculated using equation (4).

   9. If any tuples remain in the candidate list, go back to step 5.

Incremental Algorithm
   The previous algorithm covered the initial case, where no selected
   list had previously been created.  It also applied only to the bit-rate available for media
   payloads in RTP will be:

   Max_media_BR_A = TMMBR_BR_A - PR * TMMBR_OH_A * 8
   Max_media_BR_B = TMMBR_BR_B - PR * TMMBR_OH_B * 8

   For a PR = 20 these calculations will yield
   sender.  When a Max_media_BR_A = 28600
   bps and Max_media_BR_B = 30400 bps, which shows that receiver A previously-created selected list is available at
   either the limiting one for this packet rate. However there will media sender or media receiver, two other cases can be
   considered:

        o when a PR TMMBR tuple not currently in the selected list is a
          candidate for addition;

        o when the difference values change in bit-rate restriction will be equal to the
   difference a TMMBR tuple currently in packet overheads. This can be found by setting
   Max_media_BR_A equal the
          selected list.

   At the media receiver these cases correspond respectively to Max_media_BR_B and breaking out PR:

         TMMBR_BR_A - TMMBR_BR_B
   PR = ---------------------------
        8*(TMMBR_OH_A - TMMBR_OH_B)

   Which, for those
   of the numbers above yields 31.25 as non-owner and owner of a tuple in the intersection point
   between TMMBN-reported bounding
   set.

   In either case, the two limits. The implications process of this have to be
   considered by application implementors that are going updating the selected list to control
   media encoding and its packetization. Because, as exemplified take
   account of the new/changed tuple can use the basic algorithm
   described above,
   there might be multiple TMMBR limits with the modification that applies to the trade-off
   between media bit-rate initial candidate
   set consists only of the existing selected list and packet rate. Which limitation the new or
   changed tuple.  Some further optimization is possible (beyond
   starting with a reduced candidate set) by taking advantage of the
   following observations.

   The first observation is that applies
   depends on if the packet rate considered new/changed candidate becomes
   part of the new selected list, the result may be to cause zero or
   more other tuples to be used. dropped from the list.  However, if more than
   one other tuple is dropped, the dropped tuples will be consecutive.
   This also has implications for how can be confirmed geometrically by visualizing a new line that
   cuts off a series of segments from the TMMBR mechanism needs previously-existing bounding
   polygon.  The cut-off segments are connected one to work.
   First, there the next, the
   geometric equivalent of consecutive tuples in a list ordered by
   overhead value.  Beyond the dropped set in either direction all of
   the tuples that were in the earlier selected list will be in the
   updated one.  The second observation is that, leaving aside the possibility that multiple TMMBR new
   candidate, the order of tuples are
   providing limitations on remaining in the media sender. Secondly there updated selected list
   is a need
   for any session participant (meda sender unchanged because their overhead values have not changed.

   The consequence of these two observations is that, once the placement
   of the new candidate and receivers) to be able to
   determine if a given tuple will become a limitation upon the media
   sender, or if extent of the dropped set of already given limitations are stricter than
   the given values. Otherwise tuples (if
   any) has been determined, the suppression of TMMBR requests would
   not work.

   Thus any session participant needs to remaining tuples can be able copied directly
   from a given set X the candidate list into the selected list, preserving their
   order.  This conclusion suggests the following modified algorithm:

       o Run steps 1-4 of
   tuples determine which is the minimal set need basic algorithm.

       o If the new candidate has survived steps 2 and 4 and has become
          the new first member of the selected list, run steps 5-9 on
          subsequent candidates until another candidate is added to express the
   limitations for
          selected list.  Then move all packet rates from 0 remaining candidates to highest possible. Where the highest possible either is application limited
          selected list, preserving their order.

       o If the new candidate has survived steps 2 and indicated
   trough session setup signaling or as a result of 4 and has not
          become the given
   limitations when new first member of the available bit-rate is fully consumed selected list, start by headers.

   First determine what the highest possible bit-rate given
          moving all tuples in the
   limitations is. If there is provided a session maximum packet rate
   (SMAXPR) then this can be used. In addition one needs candidate list with lower overhead
          values than that of the new candidate to calculate the selected list,
          preserving their order.  Run steps 5 through 9 for each tuple in the set what its new
          candidate, with the modification that the intersection values
          and maximum is by calculating bit-rate
   (BR) divided by overhead (OH) per packet converted rates for the tuples on the selected list
          have to bits.

   MaxPR = SMAXPR
   For i=1 be calculated on the fly because they were not
          previously stored.  Continue processing only until a
          subsequent tuple has been added to size(X) {
      tmp_pr = X(i).BR / 8*X(i).OH;
      If (tmp_pr < MaxPR) the selected list, then MaxPR = tmp_pr
   }

   For a zero packet rate
          move all remaining candidates to the TMMBR signaled bit-rate will selected list, preserving
          their order.

          Note that the new candidate could be added to the selected
          list only
   limiting factor, thus to be dropped again when the next tuple with the smallest available bit-rate is a limitation at
          processed.  It can easily be seen that in this point case the new
          candidate does not displace any of the range and function as a start
   value earlier tuples in the algorithm.

   Start by finding the element X(l)
          selected list.  The limitations of ASCII art make this
          difficult to show in X with the lowest bit-rate value
   and the highest overhead a figure.  Line cc..c in Figure 1 would
          be an example if there are multiple on the same bit-rate. it had a steeper slope (tuple C had a higher
          overhead value), but still intersected line aa..a beyond where
          line aa..a intersects line bb..b.

   The set Y that algorithm just described is the minimal set approximate, because it does not take
   account of tuples that provide restrictions
   initially contain only X(l). Then for each other tuple X(i) calculate
   if there exist an intersection between outside the currently selected tuple
   X(s) (initially s=l) list.  To see how such tuples
   can become relevant, consider Figure 1 and which of suppose that the tuples within maximum
   total media bit rate in tuple A increases to the set point that has
   this intersection at line
   aa..a moves outside line cc..c.  Tuple A will remain in the lowest packet rate. Having found bounding
   set calculated by the lowest
   packet rate, compare media sender.  However, once it with the sessions maximum packet rate. If
   lower than that limit this tuple provide issues a session limit and new
   TMMBN, media receiver C will apply the algorithm and discover that
   its tuple is added to Y. Update C should now enter the value of s bounding set.  It will issue a TMMBR
   request to the found tuple and media sender, which will repeat search for its calculation and
   come to the tuple appropriate conclusion.

   The rules of section 4.2 require that has the intersection at the lowest
   packet rate, but still higher than the previous intersection.
   Algorithm has finished when it can't find any new tuple with an
   intersection at a packet media sender refrain from
   raising its sending rate lower than until media receivers have had a chance to
   respond to the session maximum.

   // Find TMMBN.  In the element with example just given, this delay ensures
   that the lowest bit-rate in X
   l=0;
   for (i=1:size(X)){
     if (X(i).BR <= X(l).BR) & (X(i).OH > X(l).OH) then
       l=I;
   }

   tuple_index = l; // The lowest bit-rate relaxation of tuple
   Y = X(l);     // Initilize Y to X(l)
   start_pr = 0;    // Start from zero bit-rate
   do {
      current_low = MaxPr; //Reset packet-rate
      current_index = tuple_index; // To allow for no intersection
      For i=each element in X
           pr = (X(i).BR - X(tuple_index).BR) /
                (X(i).OH - X(tuple_index).OH)
                // Calculate packet rate compared to element i
           If (pr < current_low && pr > start_pr) then {
           // Update lowest intersection packet rate
              current_low = pr;
              current_index = i;
           }
        }
        If (current_index != tuple_index) {
          // A tuple intersecting below maxpacket rate
          Y(size(Y)+1) = X(current_index) // Add to Y
          tuple_index = current_index;   // Update which does not actually result in an attempt
   to compare with
          start_pr = current_low;   // Update packet send media at a rate to seek from.
      }
   } while (current_low < MaxPr)

   The above algorithm yields exceeding the set of applicable restriction Y. capacity at C.

3.5.4.3. Use of TMMBR in a Mixer based Multi-point operation Based Multipoint Operation

   Assume a small mixer-based multiparty conference is ongoing, as
   depicted in Topo-Mixer of [Topologies].  All participants have
   negotiated a common maximum bit-rate bit rate that this session can use.  The
   conference operates over a number of unicast paths between the
   participants and the mixer.  The congestion situation on each of
   these paths can be monitored by the participant in question and by
   the mixer, utilizing, for example, RTCP Receiver Reports receiver reports (RR) or the
   transport protocol, e.g. DCCP [RFC4340].  However, any given
   participant has no knowledge of the congestion situation of the
   connections to the other participants.  Worse, without mechanisms
   similar to the ones discussed in this draft, the mixer (who (which is
   aware of the congestion situation on all connections it manages) has
   no standardized means to inform media senders to slow down, short of
   forging its own receiver reports (which is undesirable).  In
   principle, a mixer confronted with such a situation is obliged to
   thin or transcode streams intended for connections that detected
   congestion.

   In practice, media-aware stream thinning is unfortunately a very
   difficult and cumbersome operation and adds undesirable delay.  If
   media-unaware, it leads very quickly to unacceptable reproduced media
   quality.  Hence, a means to slow down senders even in the absence of
   congestion on their connections to the mixer are is desirable.

   To allow the mixer to perform congestion control throttle traffic on the individual links,
   without performing transcoding, there is a need for a mechanism that
   enables the mixer to request the ask a participant's media encoders to limit their Maximum Media Stream bit-rate the
   media stream bit rate they are currently used.
   The mixer handles generating.  TMMBR provides
   the detection of a required mechanism.  When the mixer detects congestion state between
   itself and a participant as follows: given participant, it executes the following procedure:

   1. Start It starts thinning the media traffic to the congested participant
      to the supported bit-rate. bit rate.

   2. Use the It uses TMMBR to request the media sender(s) to reduce the total
      media
      bit-rate bit rate sent by them to the mixer, to a value that is in
      compliance with congestion control principles for the slowest
      link.  Slow refers here to the available
      bandwidth/bitrate/capacity bandwidth / bit rate /
      capacity and packet rate after congestion control.

   3. As soon as the bit-rate bit rate has been reduced by the sending part, the
      mixer stops stream thinning implicitly, because there is no need
      for it any more as once the stream is in compliance with congestion control.

   Above algorithms may suggest to some that there is no need for the
   TMMBR - it should be sufficient to solely rely on stream thinning.
   As much as this is desirable from a network protocol designer's
   viewpoint, it has the disadvantage that it doesn't work very
   well - the reproduced media quality quickly becomes unusable.

   It appears to be a reasonable compromise to rely on

   This use of stream thinning as an immediate reaction tool to combat congestions, and have followed up
   by a quick control mechanism that instructs the original sender to reduce its
   bitrate.

   Note also that the standard RTCP receiver report cannot serve for the
   purpose mentioned.  In an environment with RTP mixers, the RTCP RR is
   being sent between the RTP receiver in the endpoint and the RTP
   sender in the mixer only - as there is no multicast transmission.
   The stream that needs appears to be bitrate-reduced, however, is the one a reasonable compromise
   between the original sending endpoint and the mixer.  This endpoint
   doesn't see the aforementioned RTCP RRs, media quality and hence needs to be
   explicitly informed about desired bitrate adjustments.

   In this topology it is the mixer's responsibility need to collect, and
   consider jointly, the different bit-rates which the different links
   may support, into the bit rate requested. This aggregation may also
   take into account that the mixer may contain certain transcoding
   capabilities (as discussed in under Topo-Mixer in [Topologies]),
   which can be employed for those few of the session participants that
   have the lowest available bit-rates. combat congestion.

3.5.4.4. Use of TMMBR in Point-to-Multipoint using Using Multicast or
   Translators

   In these topologies, corresponding to Topo-Multicast or Topo-
   Translator
   Translator, RTCP RRs are transmitted globally which globally.  This allows for the
   detection of all
   participants to detect transmission problems such as congestion, on a
   medium timescale.  As all media senders are aware of the congestion
   situation of all media receivers, the rationale of for the use of TMMBR
   of
   in the previous section 3.5.4.3 does not apply.  However, even in this case
   the congestion control response can be improved when the unicast
   links are employing using congestion controlled transport protocols (such as
   TCP or DCCP).  A peer may also report local limitation limitations to the media
   sender.

3.5.4.5. Use of TMMBR in Point-to-point operation

   In use case 7 it is possible to use TMMBR to improve the performance
   at times of changes in
   when the known upper limit of the bit-rate. bit rate changes.  In this use case
   the signaling protocol has established an upper limit for the session
   and total media bit-rates. bit rates.  However, at the time of transport link bit-rate
   bit rate reduction, a receiver could can avoid serious congestion by
   sending a TMMBR to the sending side.  Thus TMMBR is useful for
   putting restrictions on the application and thus placing the
   congestion control mechanism in the right ballpark.  However TMMBR is
   usually unable to have provide the continuously quick feedback loop
   required for real congestion control. Its  Nor do its semantics is also not a match for
   those of congestion control due to given its different purpose. Because of  For these
   reasons TMMBR SHALL NOT be used as a substitute for congestion
   control.

3.5.4.6. Reliability

   The reaction of a media sender to the reception of a TMMBR message is
   not immediately identifiable through inspection of the media stream.
   Therefore, a more explicit mechanism is needed to avoid unnecessary
   re-sending of TMMBR messages.  Using a statistically based
   retransmission scheme would only provide statistical guarantees of
   the request being received.  It would also not avoid the
   retransmission of already received messages.  In addition, it does would
   not allow for easy suppression of other participants participants' requests.  For the
   reasons mentioned,
   these reasons, a mechanism based on explicit notification is
   used, as discussed already in section 3.5.4.1. used.

   Upon the reception of a request a media sender sends a TMMBN
   notification containing the current applicable limitation of the bit-rate, bounding set, and indicating
   which session participants that own that limit.  In multicast scenarios,
   that allows all other participants to suppress any request they may
   have, with limitation values if their limitations are less strict than the current
   ones. The identity of ones
   (i.e. define lines lying outside the owners feasible region as defined in
   section 2.2).  Keeping and notifying only the bounding set of tuples
   allows for small message sizes and media sender states.  A media
   sender only keeps state for the SSRCs of the current owners of the limitations;
   bounding set of tuples; all other requests and their sources are not
   saved. Only  Once the bounding set has been established, new TMMBR
   messages should be generated only by owners are allowed to remove of the bounding tuples
   and by other entities that determine (by applying the algorithm of
   section 3.5.4.2 or
   change its limitation. Otherwise, anyone equivalent) that ever set a limitation
   would need to remove it to allow the maximum bit-rate to their limitations should now
   be raised
   beyond that value. part of the bounding set.

4. RTCP Receiver Report Extensions

   This memo specifies six new feedback messages.  The Full Intra
   Request (FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal-Spatial Temporal-
   Spatial Trade-off Notification (TSTN), and Video Back Channel Message
   (VBCM) are "Payload Specific Feedback Messages" as defined in Section
   6.3 of AVPF [RFC4585].  The Temporary Maximum Media Stream Bit-rate Bit Rate
   Request (TMMBR) and Temporary Maximum Media Stream Bit-rate Bit Rate
   Notification (TMMBN) are "Transport Layer Feedback Messages" as
   defined in Section 6.2 of AVPF.

   In the following subsections, the

   The new feedback messages are defined, defined in the following subsections,
   following a similar structure as to that in the AVPF specification's sections 6.2 and 6.3, respectively. 6.3 of the
   AVPF specification [RFC4585].

4.1. Design Principles of the Extension Mechanism

   RTCP was originally introduced as a channel to convey presence,
   reception quality statistics and hints on the desired media coding.
   A limited set of media control mechanisms have been were introduced in early
   RTP payload formats for video formats, for example in RFC 2032
   [RFC2032]. 4587
   [RFC4587].  However, this specification, for the first time, suggests
   a two-way handshake for some of its messages.  There is danger that
   this introduction could be misunderstood as the precedence a precedent for the use
   of RTCP as an RTP session control protocol. In order to  To prevent
   these misunderstandings, such a
   misunderstanding, this subsection attempts to clarify the scope of
   the extensions specified in this memo, and strongly suggests that
   future extensions follow the rationale spelled out here, or
   compellingly explain why they divert from the rationale.

   In this memo, and in AVPF [RFC4585], only such messages have been
   included which as:

   a) have comparatively strict real-time constraints, which prevent the
      use of mechanisms such as a SIP re-invite in most application
      scenarios.  The real-time constraints are explained separately for
      each message where necessary necessary.

   b) are multicast-safe in that the reaction to potentially
      contradicting feedback messages is specified, as necessary for
      each message message; and

   c) are directly related to activities of a certain media codec, class
      of media codecs (e.g. video codecs), or a given RTP packet stream.

   In this memo, a two-way handshake is only introduced only for such messages that for
   which:

   a) require a notification or acknowledgement is required due to their nature,
      which is motivated nature.
      An analysis to determine whether this requirement exists has been
      performed separately for each message message.

   b) the notification or acknowledgement cannot be easily derived from
      the media bit stream.

   All messages in AVPF [RFC4585] and in this memo implement present their
   codepoints
   contents in a simple, fixed binary format.  The reason behind this
   design principle lies in that  This accommodates media
   receivers do which have not always implement implemented higher control protocol
   functionalities (SDP, XML parsers and such) in their media path.  Therefore, simple binary representations are
   used in the feedback messages and not an (otherwise desirable)
   flexible format such as, for example, XML.

4.2. Transport Layer Feedback Messages

   As specified in section 6.1 of RFC 4585 [RFC4585], Transport Layer FB
   Feedback messages are identified by the value RTPFB (205)
   as RTCP packet type (see section 6.1 of RFC 4585 [RFC4585]. packet type value RTPFB
   (205).

   In AVPF, one message of this category had been defined.  This memo
   specifies two more messages, for a total of three messages of this
   type. such messages.  They are identified by means of
   the FMT parameter as follows:

      0:    unassigned

   Assigned in AVPF [RFC4585]:

      1:    Generic NACK (as per AVPF)
      31:   reserved for future expansion of the identifier number space

   Assigned in this memo:

      2:    reserved (see note below)
      3:    Temporary Maximum Media Stream Bit-rate Bit Rate Request (TMMBR)
      4:    Temporary Maximum Media Stream Bit-rate Bit Rate Notification (TMMBN)
      5-30: unassigned
      31:   reserved for future expansion of the identifier number space

          Note: early drafts of AVPF [RFC4585] reserved FMT=2 for a
          codepoint code
          point that has later been removed.  It has been pointed out
          that there may be implementations in the field using this
          value for according to in accordance with the expired draft.  As there is
          sufficient numbering space available, we mark FMT=2 as
          reserved so to avoid possible interoperability problems with
          implementations that are standard-incompliant
          any such early implementations.

   Available for assignment:

      0:    unassigned
      5-30: unassigned
   The following subsection defines the formats of the FCI entries for
   the TMMBR and TMMBN messages respectively and specify the associated
   behaviour at the media sender and receiver.

4.2.1. Temporary Maximum Media Stream Bit Rate Request (TMMBR)

   The FCI field of a Temporary Maximum Media Stream Bit-Rate Request
   (TMMBR) message SHALL contain one or more FCI entries.

4.2.1.1. Message Format

   The Feedback Control Information (FCI) consists of one or more TMMBR
   FCI entries with respect the following syntax:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2 - Syntax of an FCI entry in the TMMBR message

     SSRC (32 bits): The SSRC value of the media sender that is
              requested to obey the new maximum bit rate.

     MxTBR Exp (6 bits): The exponential scaling of the mantissa for the
              maximum total media bit rate value.  The value is an
              unsigned integer [0..63].

     MxTBR Mantissa (17 bits): The mantissa of the maximum total media
              bit rate value as an unsigned integer.

     Measured Overhead (9 bits): The measured average packet overhead
              value in bytes.  The measurement SHALL be done according
              to
          RFC 4585 description in this very point. section 4.2.1.2. The following subsection defines value is an
              unsigned integer [0..512].

   The maximum total media bit rate (MxTBR) value in bits per second is
   calculated from the formats of MxTBR exponent (exp) and mantissa in the FCI field
   following way:

      MxTBR = mantissa * 2^exp

   This allows for
   this type 17 bits of FB message.

4.2.1. Temporary Maximum Media Stream Bit-rate Request and Notification resolution in the range 0 to 131072*2^63
   (approximately 1.2*10^24).

   The FCI field length of a Temporary Maximum Media Stream Bit-Rate Request
   (TMMBR) the TMMBR feedback message SHALL contain one or more be set to 2+2*N where
   N is the number of TMMBR FCI entries.

4.2.1.1.

4.2.1.2. Semantics

Behaviour at the Media Receiver (Sender of the TMMBR)

   TMMBR is used to indicate the a transport related limitation in at the
   reporting entity acting as a media receiver.  TMMBR has the form of a tuple.
   tuple containing two components.  The first value is the highest bit-rate bit
   rate per sender of a media, media stream, observed at a receiver-chosen
   protocol layer, which the receiver currently supports in this RTP session
   observed at a particular protocol layer.
   session.  The second value is the measured header overhead in bytes on
   as defined in section 2.2 and measured at the chosen protocol layer
   in the packets received for the stream. Counting from the start of the header on the protocol layer
   for which the bit-rate is reported until the RTP payload's start.  The measurement of the
   overhead is a running averaging average that is updated for each packet
   received for this particular media source
   (SSRC). For each packet received the overhead is calculated (pckt_OH)
   and then added to (SSRC), using the average overhead (avg_OH) by calculating: following
   formula:

       avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH.

   The bit-rate values used 1/16*pckt_OH,

   where avg_OH is the running (exponentially smoothed) average and
   pckt_OH is the overhead observed in this formats are averaged out over a
   reasonable timescale. What reasonable timescales are, depends on the
   application. However latest packet.

   If a maximum bit rate has been negotiated through signaling, the goal is be able to ignore any burstiness on
   very short timescales, below for example 100 ms, introduced by
   scheduling or link layer packetization effects.

   The
   maximum total media sender MAY use any combination of packet bit rate and RTP
   payload bit-rate that the receiver reports in a TMMBR
   message MUST NOT exceed the negotiated value converted to produce a lower media stream bit-rate, as common
   basis (i.e. with overheads adjusted to bring it may
   need to address a congestion situation or other limiting factors.
   See section 5               . (congestion control) the same reference
   protocol layer).

   Within the common packet header for more discussion.

   The ''SSRC feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of the packet sender'' sender" field
   indicates the source of the request, and the ''SSRC "SSRC of media source'' source"
   is not used and SHALL be set to 0. The SSRC  Within a particular TMMBR FCI
   entry, the "SSRC of media sender sender" in the FCI field denotes the media
   sender the message tuple applies to.  This is useful in the multicast or
   translator topologies where the reporting entity may address all of
   the media senders in a single TMMBR message using multiple FCI
   entries.

   The media receiver SHALL save the contents of the latest TMMBN
   message received from each media sender.

   The media receiver MAY send a TMMBR FCI entry to a particular media
   sender under the following circumstances:

     o   before any TMMBN message has been received from that media
          sender;

     o   when the media receiver has been identified as the source of a
          bounding tuple within the latest TMMBN message received from
          that media sender, and the value of the maximum total media
          bit rate or the overhead relating to that media sender has
          changed;

     o   when the media receiver has not been identified as the source
          of a bounding tuple within the latest TMMBN message received
          from that media sender, and, after the media receiver applies
          the incremental algorithm from section 3.5.4.2 or a stricter
          equivalent, the media receiver's tuple relating to that media
          sender may be addressed in a
   single TMMBR message using multiple FCIs. is determined to belong to the bounding set.

   A TMMBR FCI entry MAY be repeated in subsequent TMMBR messages if no
   applicable Temporal
   Temporary Maximum Media Stream Bit-Rate Notification (TMMBN) FCI has
   been received from the media sender at the time of transmission of
   the next RTCP packet. A TMMBN is applicable if it either indicate the sender
   of the TMMBR as an owner, or contains limitations that are stricter
   than one sent in the TMMBR message.  The bit-rate bit rate value of a TMMBR FCI entry MAY be
   changed from a previous one TMMBR message and the next,
   regardless of to the eventual reception of an applicable TMMBN FCI. next.  The overhead measurement
   SHALL be updated to the current value of avg_OH.

   A TMMBN message SHALL be sent by the media sender at the earliest
   possible point in time, as a result of any TMMBR messages received
   since the last sending of TMMBN.  The TMMBN message indicates the
   limits and the owners of those limits at the time of the transmission
   of the message. The limits SHALL be set to the set of the stricts
   limits of the previous limits and all limits received in TMMBR FCI's
   since the last TMMBN was transmitted.

   A media receiver considering sending a TMMBR, who is not a ''owner''
   of a limitation, SHOULD request a limitation stricter than their
   knowledge of the currently established limits for this media sender,
   or suppress their transmission of the TMMBR.  The exception to the
   above rule is when a receiver either doesn't know the limit or is
   certain that their local representation of the set of limitations are
   in error.  All received requests for limits equally or less strict
   compared to the ones currently established MUST BE ignored, with the
   exception of them resulting in the transmission of a TMMBN containg
   the current set of limitations.  A media receiver who is updated to the owner of
   a current limitation MAY lower the value further, raise of avg_OH each time the value or
   remove entry
   is sent.

   If the restriction completely value set by a TMMBR message is expected to be permanent, the
   TMMBR setting party SHOULD renegotiate the bit-rate part session parameters to
   reflect that using session setup signaling, e.g. a SIP re-invite.

Behaviour at the Media Sender (Receiver of the
   limit equal TMMBR)

   When it receives a TMMBR message containing an FCI entry relating to
   it, the session bit-rate limit.

   A limitation tuple LT can be determined to be stricter media sender SHALL use an initial or not
   compared incremental algorithm as
   applicable to determine the current bounding set of limitations if LT is part of tuples based on the set Y
   produced by new
   information.  The algorithm used SHALL be at least as strict as the
   corresponding algorithm described defined in Section section 3.5.4.2.

   Once  The media sender
   MAY accumulate TMMBR requests over a session participant receives the TMMBN in response small interval (relative to its
   TMMBR, with its own SSRC, it knows that it "owns" the bitrate
   limitation.  Only the "owner" of a bitrate limitation can raise it or
   reset
   RTCP sending interval) before making this calculation.

   Once it to the session limit.

   Note that, due to has determined the unreliable nature of transport bounding set of TMMBR and
   TMMBN, the above rules may lead to tuples, the sending media sender
   MAY use any combination of TMMBR messages
   disobeying packet rate and net media bit rate within
   the rules above.  Furthermore, in multicast scenarios it
   can happen feasible region that more than one session participants believes these tuples describe to produce a lower
   total media stream bit rate, as it "owns"
   the current bitrate limitation.  This is not critical for may need to address a number of
   reasons:
   a) congestion
   situation or other limiting factors.  See section 5 (congestion
   control) for more discussion.

   If a TMMBR message is lost in transmission, the media sender does
      not learn about concludes that it can increase the restrictions imposed on it.  However, maximum total
   media bit rate value, it also
      does not send SHALL wait before actually doing so, for a TMMBN message notifying reception of
   period long enough to allow a request media receiver to respond to the TMMBN
   if it
      has never received.  Therefore, no new limit determines that its tuple belongs in the bounding set.  This
   delay period is established, estimated by the
      media receiver sending a more restrictive TMMBR formula:

      2 * RTT + T_Dither_Max,

   where RTT is not the owner.
      Since this media receiver has not seen a notification
      corresponding longest round trip time known to its request, it the media sender
   and T_Dither_Max is free to re-send it.
   b) Similarly, if a defined in section 3.4 of [RFC4585].

   A TMMBN message gets lost, SHALL be sent by the media receiver that
      has sent sender at the corresponding earliest
   possible point in time, in response to any TMMBR request does not receive the
      Notification.  In that case, it is also not messages received
   since the "owner" last sending of TMMBN.  The TMMBN message indicates the
      restriction
   calculated set of bounding tuples and is free the owners of those tuples at
   the time of the transmission of the message.

   An SSRC may time out according to re-send the request.
   c) If multiple competing TMMBR messages are sent by different default rules for RTP session
   participants, then i.e. the media sender has not received any RTP or RTCP
   packets from the owner for the last five regular reporting intervals.
   An SSRC may also explicitly leave the session, with the participant
   indicating this through the transmission of an RTCP BYE packet or
   using an external signaling channel.  If the resulting TMMBN indicates media sender determines
   that the most
      restrictive limits requested including its owners.

   d) If more than one session participant incidently send TMMBR
      messages at owner of a tuple in the same time and with bounding set has left the same limit, session,
   the media sender selects one shall transmit a new TMMBN containing the
   previously-determined set of them and addresses it as bounding tuples but with the ''owner''.
      Session-wide, tuple
   belonging to the correct limit is thereby established.

   It is also important departed owner removed.

Discussion

   Due to consider the security risks involved with
   faked TMMBRs. See security considerations in Section 6.

   The feedback messages may be used in both multicast and unicast
   sessions of any unreliable nature of the specified topologies.

   For sessions with a large number transport of participants using TMMBR and TMMBN, the lowest
   common denominator, as required by this mechanism,
   above rules may not be lead to the
   most suitable course sending of action. Large TMMBR messages which appear to
   disobey those rules.  Furthermore, in multicast scenarios it can
   happen that more than one "non-owning" session participant may need to consider
   other ways to support adapted bit-rate to participants, such as
   partitioning
   determine, rightly or wrongly, that its tuple belongs in the session bounding
   set.  This is not critical for a number of reasons:

   a) If a TMMBR message is lost in different quality tiers, or use transmission, either the media
      sender sends a new TMMBN message in response to some other method media
      receiver or it does not send a new TMMBN message at all.  In the
      first case, the media receiver applies the incremental algorithm
      and, if it determines that its tuple should be part of achieving bit-rate scalability.

   If the value set by
      bounding set, sends out another TMMBR.  In the second case, it
      repeats the sending of a TMMBR message is expected to be permanent, unconditionally.  Either way, the
   TMMBR setting party is RECOMMENDED to renegotiate
      media sender eventually gets the session
   parameters to reflect that using session setup signaling, e.g. information it needs.

   b) Similarly, if a SIP
   re-invite.

   An SSRC may time out according to the default rules for RTP session
   participants, i.e. TMMBN message gets lost, the media sender receiver that
      has not received any RTCP packet
   from sent the owner for corresponding TMMBR request does not receive the last five regular reporting intervals. An SSRC
   may also leave
      notification and is expected to re-send the session, indicating this through request and trigger
      the transmission of an RTCP BYE packet or an external signaling channel. In another TMMBN.

   c) If multiple competing TMMBR messages are sent by different session
      participants, then the algorithm can be applied taking all of
      these cases the entity is considered to have left the session. In the
   case the "owner" leaves the session, the limit SHALL be removed messages into account, and the transmission of a resulting TMMBN is scheduled indicating provides the remaining
   limitations.

4.2.1.2.         Message Format

   The Feedback Control Information (FCI) consists
      participants with an updated view of one or more TMMBR
   FCI entries how their tuples compare with
      the following syntax:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MMBR Exp  |  MMBR Mantissa                  |Measured Overhead|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1 - Syntax for the bounded set.

   d) If more than one session participant happens to send TMMBR message
     SSRC:   The SSRC value of
      messages at the media sender that same time and with the same tuple component
      values, it does not matter which if either tuple is requested to
              obey taken into the new maximum bit-rate).
     MMBR Exp (6 bits):
      bounding set.  The exponential scaling of losing session participant will determine after
      applying the mantissa for algorithm that its tuple does not enter the
              Maximum Media Stream bit-rate value. The value bounding
      set, and will therefore stop sending its TMMBR request.

   It is non
              signed integer [0..63].

     MMBR Mantissa (17 bits): The mantissa of the Maximum Media Stream
              Bit-rate value as a non-signed integer.

     Measured Overhead (9 bits): The measured average packet overhead
              value in bytes. The measurement SHALL be done according important to
              above description consider the security risks involved with faked
   TMMBRs.  See the security considerations in Section 4.2.1.1.

   The maximum media stream bit-rate (MMBR) value in bits per second is
   calculated from 6.

   As indicated already, the MMBR exponent (exp) feedback messages may be used in both
   multicast and mantissa unicast sessions in any of the following
   way:

      MMBR = mantissa * 2^exp

   This allows specified topologies.
   However, for 17 bits sessions with a large number of resolution in participants, using the range 0 to 131072*2^63
   (approximately 1.2*10^24).

   The length
   lowest common denominator, as required by this mechanism, may not be
   the most suitable course of action.  Large sessions may need to
   consider other ways to adapt the FB message is be set bit rate to 2+2*N where N is participants'
   capabilities, such as partitioning the number session into different quality
   tiers, or using some other method of TMMBR FCI entries. achieving bit rate scalability.

4.2.1.3. Timing Rules

   The first transmission of the TMMBR request message MAY use early or
   immediate feedback in cases when timeliness is desirable.  Any
   repetition of a request message SHOULD use regular RTCP mode for its
   transmission timing.

4.2.1.4. Handling in Translator and Mixers

   Media Translators translators and Mixers mixers will need to receive and respond to
   TMMBR messages as they are part of the chain that provides a certain
   media stream to the receiver.  The mixer or translator may act
   locally on the TMMBR request and thus generate a TMMBN to indicate
   that it has done so. Alternatively it can forward the request  Alternatively, in the case of a media translator,
   translator it can forward the request, or generate one of itself in the case of the
   mixer. In case it generates of a TMMBR, mixer
   generate one of its own and pass it forward.  In the latter case, the
   mixer will need to send a TMMBN back to the original requestor to
   indicate that it is handling the request.

4.2.2. Temporary Maximum Media Stream Bit-rate Bit Rate Notification (TMMBN)

   The FCI field of the TMMBN Feedback message may contain zero, one or
   more TMMBN FCI entry. entries.

4.2.2.1. Message Format

   The Feedback Control Information (FCI) consists of zero, one or more
   TMMBN FCI entries with the following syntax:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 3 - Syntax of an FCI entry in the TMMBN message

     SSRC (32 bits): The SSRC value of the "owner" of this tuple.

     MxTBR Exp (6 bits): The exponential scaling of the mantissa for the
              maximum total media bit rate value.  The value is an
              unsigned integer [0..63].

     MxTBR Mantissa (17 bits): The mantissa of the maximum total media
              bit rate value as an unsigned integer.

     Measured Overhead (9 bits): The measured average packet overhead
              value in bytes represented as an unsigned integer.

   Thus the FCI within the TMMBN message contains entries indicating the
   bounding tuples.  For each tuple, the entry gives the owner by the
   SSRC, followed by the applicable maximum total media bit rate and
   overhead value.

   The length of the TMMBN message SHALL be set to 2+2*N where N is the
   number of TMMBN FCI entries.

4.2.2.2. Semantics

   This feedback message is used to notify the senders of any TMMBR
   message that one or more TMMBR messages have been received or that a an
   owner has left the session.  It indicates to all participants the
   current set of currently employed limitations bounding tuples and the ''owners'' "owners" of those.

   The ''SSRC those tuples.

   Within the common packet header for feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of the packet sender'' sender" field
   indicates the source of the notification.  The ''SSRC "SSRC of media source'' source"
   is not used and SHALL be set to 0.

   A TMMBN message SHALL be scheduled for transmission after the
   reception of a TMMBR message with a an FCI entry identifying this media
   sender.  Only a single TMMBN SHALL be sent, even if more than one
   TMMBR messages are message is received between the scheduling of the transmission
   and the actual transmission of the TMMBN message.  The TMMBN message
   indicates the limits bounding tuples and their owners at the time of
   transmitting the message.  The limits bounding tuples included SHALL be the
   set arrived at through application of the applicable algorithm of
   most restrictive values in
   section 3.5.4.2 or an equivalent, applied to the previously established previous bounding
   set if any and tuples received in TMMBR messages since the last TMMBN
   was transmitted.

   The reception of a TMMBR message with a transmission limit equally or
   less restrictive than the set of current limits SHALL still result in the
   transmission of a TMMBN message. However message even if, after application of the limits
   algorithm, the newly reported TMMBR tuple is not accepted into the
   bounding set.  In such a case the bounding tuples and their owners
   are not changed, unless it the TMMBR was from an owner of a limit tuple within
   the current set of limitations. previously calculated bounding set.  This procedure allows
   session participants that haven't seen did not see the last TMMBN message to get a
   correct view of this media sender's state.

   When

   As indicated in section Error! Reference source not found., when a
   media sender determines an ''owner'' of a limitation has left
   the session, then that limitation is removed, and the media sender
   SHALL send a TMMBN message indicating the remaining limitations.  In
   case there are no remaining limitations a TMMBN without any FCI SHALL
   be sent to indicate this.

   In unicast scenarios (i.e. where a single sender talks to a single
   receiver), the aforementioned algorithm to determine ownership
   degenerates to the media receiver becoming the ''owner'' as soon as
   the media receiver has issued the first TMMBR message.

4.2.2.2.         Message Format

   The Feedback Control Information (FCI) consists of zero, one or more
   TMMBN FCI entries with the following syntax:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MMBR Exp  |  MMBR Mantissa                  |Measured Overhead|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2 - Syntax for the TMMBR message

     SSRC:   The SSRC value of the ''owner'' of this limitation.

     MMBR Exp (6 bits): The exponential scaling an "owner" of a bounding tuple has left
   the mantissa for the
              Maximum Media Stream bit-rate value. The value session, then that tuple is non-
              signed integer [0..63].

     MMBR Mantissa (17 bits): The mantissa of removed from the Maximum Media Stream
              Bit-rate value as non-signed integer.

     Measured Overhead (9 bits): The measured average packet overhead
              value in bytes represented as non-signed integer.

   Thus bounding set, and
   the FCI contains blocks media sender SHALL send a TMMBN message indicating the applicable limitations as
   the owner followed by the applicable maximum remaining
   bounding tuples.  If there are no remaining bounding tuples a TMMBN
   without any FCI SHALL be sent to indicate this.

     Note: if any media stream bit-rate
   and overhead value.

   The length of receivers remain in the FB message is session, this last will
     be set a temporary situation.  The empty TMMBN will cause every
     remaining media receiver to 2+2*N determine that its limitation belongs
     in the bounding set and send a TMMBR in consequence.

   In unicast scenarios (i.e. where N is a single sender talks to a single
   receiver), the number aforementioned algorithm to determine ownership
   degenerates to the media receiver becoming the "owner" of the one
   bounding tuple as soon as the media receiver has issued the first
   TMMBR FCI entries. message.

4.2.2.3.         Timing Rules

   The TMMBN acknowledgement SHOULD be sent as soon as allowed by the
   applied timing rules for the session.  Immediate or early feedback
   mode SHOULD be used for these messages.

4.2.2.4. Handling by Translators and Mixers

   As discussed in Section 4.2.1.4 mixer mixers or translators may need to
   issue TMMBN messages as response responses to TMMBR messages for SSRC's
   handled by the
   mixer or translator. them.

4.3. Payload Specific Feedback Messages

   As specified by section 6.1 of RFC 4585 [RFC4585], Payload-Specific
   FB messages are identified by the value PT=PSFB
   (206) as RTCP packet type (see section 6.1 of RFC 4585 [RFC4585]). value PT=PSFB
   (206).

   AVPF [RFC4585] defines three payload-specific FB feedback messages and
   one application layer FB feedback message.  This memo specifies four
   additional payload-
   specific payload-specific feedback messages.  All are identified by
   means of the FMT parameter as follows:

     0:     unassigned

   Assigned in [RFC4585]:

     1:     Picture Loss Indication (PLI)
     2:     Slice Lost Indication (SLI)
     3:     Reference Picture Selection Indication (RPSI)
     15:    Application layer FB message
     31:    reserved for future expansion of the number space

   Assigned in this memo:

     4:     Full Intra Request Command (FIR)
     5:     Temporal-Spatial Trade-off Request (TSTR)
     6:     Temporal-Spatial Trade-off Notification (TSTN)
      7:     Video Back Channel Message (VBCM)
      8-14:  unassigned
     15:    Application layer FB message
     16-30:

   Unassigned:

     0:     unassigned
      8-14:  unassigned
     16-30: unassigned
     31:    reserved for future expansion of the number space

   The following subsections define the new FCI formats for the payload-
   specific FB feedback messages.

4.3.1. Full Intra Request (FIR)

   The FIR message is identified by RTCP packet type value PT=PSFB and
   FMT=4.

   There

   The FCI field MUST be contain one or more FIR entries.  Each entry contained
   applies to a different media sender, identified by its SSRC.

4.3.1.1. Message Format

   The Feedback Control Information (FCI) for the Full Intra Request
   consists of one or more FCI entries, the content of which is depicted
   in Figure 4.  The length of the FIR feedback message MUST be set to
   2+2*N, where N is the number of FCI field.

4.3.1.1. entries.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Seq. nr       |    Reserved                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 4 - Syntax of an FCI entry in the FIR message

     SSRC (32 bits): The SSRC value of the media sender which is
              requested to send a decoder refresh point.

     Seq. nr (8 bits): Command sequence number.  The sequence number
              space is unique for each pairing of the SSRC of command
              source and the SSRC of the command target.  The sequence
              number SHALL be increased by 1 modulo 256 for each new
              command.  A repetition SHALL NOT increase the sequence
              number.  The initial value is arbitrary.

     Reserved (24 bits): All bits SHALL be set to 0 by the sender and
              SHALL be ignored on reception.

   The semantics of this feedback message is independent of the RTP
   payload type.

4.3.1.2. Semantics

   Upon reception of FIR, the encoder MUST send a Decoder Refresh Point decoder refresh point
   (see Section 2                ..2) section 2.2) as soon as possible.

     Note: Currently, video appears to be the only useful application
     for FIR, as it appears to be the only RTP payloads payload widely deployed
     that relies heavily on media prediction across RTP packet
     boundaries.  However, use of FIR could also reasonably be
     envisioned for other media types that share essential properties
     with compressed video, namely cross-frame prediction (whatever a
     frame may be for that media type).  One possible example may be the
     dynamic updates of MPEG-4 scene descriptions.  It is suggested that
     payload formats for such media types refer to FIR and other message
     types defined in this specification and in AVPF, AVPF [RFC4585], instead
     of creating similar mechanisms in the payload specifications.  The
     payload specifications may have to explain how the payload-specific
     terminologies map to the video-centric terminology used herein.

     Note: In environments where the sender has no control over the
     codec (e.g. when streaming pre-recorded and pre-coded content), the
     reaction to this command cannot be specified.  One suitable
     reaction of a sender would be to skip forward in the video bit
     stream to the next decoder refresh point.  In other scenarios, it
     may be preferable not to react to the command at all, e.g. when
     streaming to a large multicast group.  Other reactions may also be
     possible.  When deciding on a strategy, a sender could take into
     account factors such as the size of the receiving group, the
     ''importance''
     "importance" of the sender of the FIR message (however
     ''importance'' "importance"
     may be defined in this specific application), the frequency of Decoder Refresh Points
     decoder refresh points in the content, and others. so on.  However a
     session which predominately handles pre-coded content is not
     expected to use FIR at all.

   The sender MUST consider congestion control as outlined in
   section 5                                                                      ., 5., which MAY restrict its ability to send a decoder refresh
   point quickly.

     Note: The relationship between the Picture Loss Indication and FIR
     is as follows.  As discussed in section 6.3.1 of AVPF, AVPF [RFC4585], a
     Picture Loss Indication informs the decoder about the loss of a
     picture and hence the likeliness likelihood of misalignment of the reference
     pictures in between the encoder and decoder.  Such a scenario is
     normally related to losses in an ongoing connection.  In point-to-point point-to-
     point scenarios, and without the presence of advanced error
     resilience tools, one possible option of for an encoder consists in
     sending a Decoder Refresh
     Point. decoder refresh point.  However, there are other options.
     One example is that the media sender ignores the PLI, because the
     embedded stream redundancy is likely to clean up the reproduced
     picture within a reasonable amount of time.  The FIR, in contrast,
     leaves a (real-
     time) (real-time) encoder no choice but to send a Decoder Refresh Point. decoder
     refresh point.  It
     disallows does not allow the encoder to take into account
     any considerations such as the ones mentioned above.

     Note: Mandating a maximum delay for completing the sending of a
     Decoder Refresh Point
     decoder refresh point would be desirable from an application
     viewpoint, but may be is problematic from a congestion control point of
     view.  ''As  "As soon as possible'' possible" as mentioned above appears to be a
     reasonable compromise.

   FIR SHALL NOT be sent as a reaction to picture losses -- it is
   RECOMMENDED to use PLI instead.  FIR SHOULD be used only in such
   situations where not sending a decoder refresh point would render the
   video unusable for the users.

     Note: A typical example where sending FIR is appropriate is when,
     in a multipoint conference, a new user joins the session and no
     regular Decoder Refresh Point decoder refresh point interval is established.  Another
     example would be a video switching MCU that changes streams.  Here,
     normally, the MCU issues a FIR to the new sender so to force it to
     emit a Decoder Refresh Point. decoder refresh point.  The Decoder Refresh Point includes decoder refresh point normally
     includes a Freeze Picture Release (defined outside this
     specification), which re-starts the rendering process of the
     receivers.  Both techniques mentioned are commonly used in MCU-
     based multipoint conferences.

   Other RTP payload specifications such as RFC 2032 [RFC2032] 4587 [RFC4587] already
   define a feedback mechanism for certain codecs.  An application
   supporting both schemes MUST use the feedback mechanism defined in
   this specification when sending feedback.  For backward compatibility
   reasons, such an application SHOULD also be capable to receive and
   react to the feedback scheme defined in the respective RTP payload
   format, if this is required by that payload format.

   The ''SSRC

   Within the common packet header for feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of the packet sender'' sender" field
   indicates the source of the request, and the ''SSRC "SSRC of media source'' source"
   is not used and SHALL be
   set to 0. The SSRC of media sender to which the FIR command applies
   to is in the FCI.

4.3.1.2.            Message Format

   Full Intra Request uses one additional FCI field, the content of
   which is depicted in Figure 3  The length of the FB message MUST be
   set to 2+2*N, where N is the number of FCI entries.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Seq. nr       |    Reserved                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3 - Syntax for the FIR message
     SSRC:   The SSRC value of the media sender which is requested to
              send a Decoder Refresh Point.

     Seq. nr: Command sequence number. The sequence number space is
              unique for each tuple consisting of the SSRC of command
              source and the SSRC of the command target. The sequence
              number SHALL be increased by 1 modulo 256 for each new
              command. A repetition SHALL NOT increase the sequence
              number. Initial value is arbitrary.

     Reserved: All bits and SHALL be set to 0 and SHALL be ignored on
              reception. 0.  The semantics of this FB message is independent SSRCs of the RTP payload
   type. media senders to
   which the FIR command applies are in the corresponding FCI entries.
   A TSTR message MAY contain requests to multiple media senders, using
   one FCI entry per target media sender.

4.3.1.3. Timing Rules

   The timing follows the rules outlined in section 3 of [RFC4585].  FIR
   commands MAY be used with early or immediate feedback.  The FIR
   feedback message MAY be repeated.  If using immediate feedback mode
   the repetition SHOULD wait at least one RTT before being sent.  In
   early or regular RTCP mode the repetition is sent in the next regular
   RTCP packet.

4.3.1.4. Handling of message FIR Message in Mixer and Translators

   A media translator or a mixer performing media encoding of the
   content for which the session participant has issued a FIR is
   responsible for acting upon it.  A mixer acting upon a FIR SHOULD NOT
   forward the message unaltered, unaltered; instead it SHOULD issue a FIR itself.

4.3.1.5. Remarks

   In conjunction with video codecs, FIR messages typically trigger the
   sending of full intra or IDR pictures.  Both are several times larger
   then predicted (inter) pictures.  Their size is independent of the
   time they are generated.  In most environments, especially when
   employing bandwidth-limited links, the use of an intra picture
   implies an allowed delay that is a significant multitude multiple of the
   typical frame duration.  An example: If if the sending frame rate is 10
   fps, and an intra picture is assumed to be 10 times as big as an
   inter picture, then a full second of latency has to be accepted.  In
   such an environment there is no need for a particularly short delay
   in sending the FIR message.  Hence waiting for the next possible time
   slot allowed by RTCP timing rules as per [RFC4585] may should not have an
   overly negative impact on the system performance.

4.3.2.       Temporal-Spatial Trade-off Request (TSTR)

   The TSTR FB message is identified by PT=PSFB and FMT=5.

   There MUST be one or more TSTR entry contained in the FCI field.

4.3.2.1.         Semantics

   A decoder can suggest the use of a temporal-spatial trade-off by
   sending a TSTR message to an encoder.  If the encoder is capable of
   adjusting its temporal-spatial trade-off, it SHOULD take into account
   the received TSTR message for future coding of pictures.  A value of
   0 suggests a high spatial quality and a value of 31 suggests a high
   frame rate. The values from 0 to 31 indicate monotonically a desire
   for higher frame rate. Actual values do not correspond to precise
   values of spatial quality or frame rate.

   The reaction to the reception of more than one TSTR message by a
   media sender from different media receivers is left open to the
   implementation.  The selected trade-off SHALL be communicated to the
   media receivers by the means of the TSTN message.

   The ''SSRC of the packet sender'' field indicates the source of the
   request, and the ''SSRC of media source'' is not used and SHALL be
   set to 0. The SSRC of media sender to which
   overly negative impact on the system performance.

4.3.2. Temporal-Spatial Trade-off Request (TSTR)

   The TSTR applies to feedback message is in
   the identified by RTCP packet type value
   PT=PSFB and FMT=5.

   The FCI entries.

   A TSTR message may field MUST contain multiple requests to different media
   senders, using multiple one or more TSTR FCI entries.

4.3.2.2.

4.3.2.1. Message Format

   The content of the FCI entry for the Temporal-Spatial Trade-off
   Request uses one FCI field, the
   content of which is depicted in Figure 4. 5.  The length of the FB feedback message
   MUST be set to 2+2*N, where N is the number of FCI entries included.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Seq nr.      |  Reserved                           | Index   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 4 5 - Syntax of an FCI Entry in the TSTR

     SSRC: Message

     SSRC (32 bits): The SSRC of the media sender which is requested to
              apply the tradeoff value given in Index.

     Seq. nr: nr (8 bits): Request sequence number.  The sequence number
              space is unique for each tuple consisting pairing of the SSRC of request source
              and the SSRC of the request target.  The sequence number
              SHALL be increased by 1 modulo 256 for each new command.
              A repetition SHALL NOT increase the sequence number. Initial  The
              initial value is arbitrary.

     Index:

     Reserved (19 bits): All bits SHALL be set to 0 by the sender and
              SHALL be ignored on reception.

     Index (5 bits): An integer value between 0 and 31 that indicates
              the relative trade off that is requested.  An index value
              of 0 index highest possible spatial quality, while 31
              indicates
              highest possible temporal resolution.

     Reserved: All bits highest possible temporal resolution.

4.3.2.2. Semantics

   A decoder can suggest a temporal-spatial trade-off level by sending a
   TSTR message to an encoder.  If the encoder is capable of adjusting
   its temporal-spatial trade-off, it SHOULD take into account the
   received TSTR message for future coding of pictures.  A value of 0
   suggests a high spatial quality and a value of 31 suggests a high
   frame rate.  The progression of values from 0 to 31 indicate
   monotonically a desire for higher frame rate.  The index values do
   not correspond to precise values of spatial quality or frame rate.

   The reaction to the reception of more than one TSTR message by a
   media sender from different media receivers is left open to the
   implementation.  The selected trade-off SHALL be communicated to the
   media receivers by the means of the TSTN message.

   Within the common packet header for feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of the packet sender" field
   indicates the source of the request, and the "SSRC of media source"
   is not used and SHALL be set to 0 and SHALL be ignored on
              reception. 0.  The SSRCs of the media senders to
   which the TSTR applies to are in the corresponding FCI entries.

   A TSTR message MAY contain requests to multiple media senders, using
   one FCI entry per target media sender.

4.3.2.3. Timing Rules

   The timing follows the rules outlined in section 3 of [RFC4585].
   This request message is not time critical and SHOULD be sent using
   regular RTCP timing.  Only if it is known that the user interface
   requires a quick feedback, the message MAY be sent with early or
   immediate feedback timing.

4.3.2.4. Handling of message in Mixers and Translators

   Mixer

   A mixer or Media translators media translator that encodes content sent to the session
   participant issuing the TSTR SHALL consider the request to determine
   if it can fulfill it by changing its own encoding parameters.  A
   media translator unable to fulfill the request MAY forward the
   request unaltered towards the media sender.  A Mixer mixer encoding for
   multiple session participants will need to consider the joint needs
   of these participants before generating a TSTR for itself on its own behalf
   towards the media sender.  See also the discussion in Section . 3.5.2.

4.3.2.5. Remarks

   The term "spatial quality" does not necessarily refer to the
   resolution, measured by the number of pixels the reconstructed video
   is using.  In fact, in most scenarios the video resolution stays
   constant during the lifetime of a session.  However, all video
   compression standards have means to adjust the spatial quality at a
   given resolution, often influenced by the Quantizer Parameter or QP.
   A numerically low QP results in a good reconstructed picture quality,
   whereas a numerically high QP yields a coarse picture.  The typical
   reaction of an encoder to this request is to change its rate control
   parameters to use a lower frame rate and a numerically lower (on
   average) QP, or vice versa.  The precise mapping of Index, Index value to
   frame
   rate, rate and QP is intentionally left open here, as it depends on
   factors such as the compression standard employed, spatial
   resolution, content, bit rate, and many more. so on.

4.3.3. Temporal-Spatial Trade-off Notification (TSTN)

   The TSTN message is identified by RTCP packet type value PT=PSFB and
   FMT=6.

   There

   The FCI field SHALL be contain one or more TSTN contained FCI entries.

4.3.3.1. Message Format

   The content of an FCI entry for the Temporal-Spatial Trade-off
   Notification is depicted in Figure 6.  The length of the TSTN message
   MUST be set to 2+2*N, where N is the number of FCI entries.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Seq nr.      |  Reserved                           | Index   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 6 - Syntax of the TSTN

     SSRC (32 bits): The SSRC of the source of the TSTR request which
              resulted in this Notification.

     Seq. nr (8 bits): The sequence number value from the TSTN request
              that is being acknowledged.

     Reserved (19 bits): All bits SHALL be set to 0 by the sender and
              SHALL be ignored on reception.

     Index (5 bits): The trade-off value the media sender is using
              henceforth.

      Informative note: The returned trade-off value (Index) may differ
      from the FCI field.

4.3.3.1. requested one, for example in cases where a media encoder
      cannot tune its trade-off, or when pre-recorded content is used.

4.3.3.2. Semantics

   This feedback message is used to acknowledge the reception of a TSTR.
   A
   One TSTN entry in a TSTN feedback message SHALL be sent for each TSTR
   entry targeted to this session participant, i.e. each TSTR received
   that in the SSRC field in the entry has the receiving entities SSRC.

   A single TSTN message MAY acknowledge multiple requests using
   multiple FCI entries.  The index value included SHALL be the same in
   all FCI's part FCI entries of the TSTN message.  Including a FCI for each
   requestor allows each requesting entity to determine that the media
   sender targeted have received the request.  The Notification SHALL also be sent also for in
   response to TSTR repetitions received.  If the request receiver has
   received TSTR with several different sequence numbers from a single
   requestor it SHALL only respond to the request with the highest
   (modulo 256) sequence number.

   The TSTN SHALL include the Temporal-Spatial Trade-off index that will
   be used as a result of the request.  This is not necessarily the same
   index as requested, as the media sender may need to aggregate
   requests from several requesting session participants.  It may also
   have some other policies or rules that limit the selection.

   The ''SSRC of

   Within the common packet sender'' field indicates the source of the
   Notification, and the ''SSRC of media source'' is not used and SHALL
   be set to 0. The SSRC of the requesting entity to which the
   Notification applies to is in the FCI.

4.3.3.2.            Message Format

   The Temporal-Spatial Trade-off Notification uses one additional FCI
   field, the content of which is depicted header for feedback messages (as defined in Figure 5.  The length
   section 6.1 of [RFC4585]), the FB message MUST be set to 2+2*N, where N is the number of FCI
   entries.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Seq nr.      |  Reserved                           | Index   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 5 - Syntax "SSRC of the TSTN

     SSRC:   The SSRC of packet sender" field
   indicates the source of the TSTR request which resulted
              in this Notification.

     Seq. nr: The sequence number value from the TSTN request that is
              being acknowledged.

     Index:  The trade-off value the media sender is using henceforth.

     Reserved: All bits SHALL be set to 0 Notification, and SHALL be ignored on
              reception.

      Informative note: The returned trade-off value (Index) may differ
      from the requested one, for example in cases where a the "SSRC of media encoder
      cannot tune its trade-off, or when pre-recorded content
   source" is used. not used and SHALL be set to 0.  The SSRCs of the
   requesting entities to which the Notification applies are in the
   corresponding FCI entries.

4.3.3.3. Timing Rules

   The timing follows the rules outlined in section 3 of [RFC4585].
   This acknowledgement message is not extremely time critical and
   SHOULD be sent using regular RTCP timing.

4.3.3.4. Handling of message TSTN in Mixer and Translators

   A Mixer mixer or Translator translator that act acts upon a TSTR SHALL also send the
   corresponding TSTN.  In cases where it needs to forward a TSTR itself
   the notification message MAY need to be delayed until that request the TSTR has
   been responded to.

4.3.3.5. Remarks

   None

4.3.4. H.271 Video Back Channel Message (VBCM)

   The VBCM is identified by RTCP packet type value PT=PSFB and FMT=7.

   There

   The FCI field MUST contain one or more VBCM FCI entries.

4.3.4.1.         Message Format

   The syntax of an FCI entry within the VBCM indication is depicted in
   Figure 7.

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Seq. nr       |0| Payload Type| Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    VBCM Octet String....      |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 7 - Syntax of an FCI Entry in the VBCM Message

   SSRC (32 bits): The SSRC value of the media sender that is requested
          to instruct its encoder to react to the VBCM message

   Seq. nr (8 bits): Command sequence number.  The sequence number space
          is unique for pairing of the SSRC of command source and the
          SSRC of the command target.  The sequence number SHALL be
          increased by 1 modulo 256 for each new command.  A repetition
          SHALL NOT increase the sequence number.  The initial value is
          arbitrary.

   0: Must be set to 0 by the sender and should not be acted upon by the
          message receiver.

   Payload Type (7 bits): The RTP payload type for which the VBCM bit
          stream must be one or more interpreted.

   Length (16 bits): The length of the VBCM entry contained octet string in octets
          exclusive of any padding octets

   VBCM Octet String (Variable length): This is the FCI field.

4.3.4.1. octet string
          generated by the decoder carrying a specific feedback sub-
          message.

   Padding (Variable length): Bits set to 0 to make up a 32 bit
          boundary.

4.3.4.2. Semantics
   The "payload" of the VBCM indication carries codec-specific, different types of
   codec-specific, feedback information.  The type of feedback
   information can be classified as a 'status report' (such as receiving an
   indication that a bit stream was received without errors, or loss of that a
   partial or complete picture or block) block was lost) or 'update requests'
   (such as complete refresh of the bit stream).

          Note: There are possible overlaps between the VBCM sub-
          messages and CCM/AVPF feedback messages, such FIR.  Please see
          section 3                  ..5.3 3.5.3 for further discussions. discussion.

   The different types of feedback sub-messages carried in the VBCM are
   indicated by the ''payloadType'' "payloadType" as defined in [VBCM]. The different
   sub-message  These sub-
   message types as defined in [VBCM] are re-produced reproduced below for convenience.  ''payloadType'',  "payloadType",
   in ITU-T Rec. H.271 terminology, refers to the sub-type of the H.271
   message and should not be confused with an RTP payload type.

   Payload Type          Message Content
   Type
   ---------------------------------------------------------------------
   0      One or more pictures without detected bitstream bit stream error
          mismatch
   1      One or more pictures that are entirely or partially lost
   2      A set of blocks of one picture that is entirely or partially
          lost
   3      CRC for one parameter set
   4      CRC for all parameter sets of a certain type
   5      A "reset" request indicating that the sender should completely
          refresh the video bitstream bit stream as if no prior bitstream bit stream data
          had been received
   > 5    Reserved for future use by ITU-T

   Table 2: H.271 message types ("payloadTypes")

   The bit string or the "payload" of a VBCM message is of variable
   length and is self-contained and coded in a variable length, binary
   format.  The media sender necessarily has to be able to parse this
   optimized binary format to make use of VBCM messages messages.

   Each of the different types of sub-messages (indicated by
   payloadType) may have different semantic based semantics depending on the codec
   used.

   The ''SSRC of

   Within the common packet sender'' field indicates the source of the
   request, and the ''SSRC of media source'' is not used and SHALL be
   set to 0. The SSRC of the media sender to which the VBCM message
   applies to is in the FCI.

4.3.4.2.         Message Format

   The VBCM indication uses one FCI field and the syntax is depicted in
   Figure 6.

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Seq. nr       |0| Payload Type| Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    VBCM Octet String....      |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 6 - Syntax for VBCM Message
   SSRC:  The SSRC value of the media sender that is requested to
          instruct its encoder to react to the VBCM message

   Seq. nr: Command sequence number. The sequence number space is unique header for each tuple consisting feedback messages (as defined in
   section 6.1 of [RFC4585]), the SSRC "SSRC of command source and the SSRC packet sender" field
   indicates the source of the command target. The sequence number SHALL be
          increased by 1 modulo 256 for each new command. A repetition
          SHALL NOT increase request, and the sequence number. Initial value "SSRC of media source"
   is
          arbitrary.

   0: Must not used and SHALL be set to 0 and should not be acted upon receiving.

   Payload: 0.  The RTP payload type for SSRCs of the media senders to
   which the VBCM bit stream must be
          interpreted.

   Length: message applies to are in the corresponding FCI
   entries.  The length sender of the VBCM octet string in octets exclusive any
          padding octets

   VBCM Octet String: This is the octet string generated by the decoder
          carrying a specific feedback sub-message. It is of variable
          length.

   Padding: Bytes set message MAY send H.271 messages to 0
   multiple media senders and MAY send more than one H.271 message to make up a 32 bit boundary.
   the same media sender within the same VBCM message.

4.3.4.3. Timing Rules

   The timing follows the rules outlined in section 3 of [RFC4585].  The
   different sub-message types may have different properties in regards
   to the timing of messages that should be used.  If several different
   types are included in the same feedback packet then the requirements
   for the sub-message type with the most stringent requirements should
   be followed.

4.3.4.4. Handling of message in Mixer or Translator

   The handling of VBCM in a mixer or translator are is sub-message type
   dependent.

4.3.4.5. Remarks

   Please see section 3.5.3 for the applicability a discussion of the VBCM message in
   relation to usage of H.271
   messages and messages defined in both AVPF [RFC4585] and this memo with
   similar functionality.

     Note: There has been some discussion whether the payload type field
     in this message is needed.  It would will be needed if there were is
     potentially more than one VBCM-capable RTP payload types type in the same
     session, and that the semantics of a given VBCM message changes from
   PT to PT.  This appears to be the case. between
     payload types.  For example, the picture identification mechanism
     in messages of H.271 type 0 is fundamentally different between
     H.263 and H.264 (although both use the same syntax. syntax).  Therefore,
     the payload field is justified here.  It  There was a further
   commented comment
     that for TSTS and FIR such a need does not exist, because the
     semantics of TSTS and FIR are either loosely enough defined, or
     generic enough, to apply to all video payloads currently in
     existence/envisioned.

5. Congestion Control

   The correct application of the AVPF [RFC4585] timing rules prevents
   the network from being flooded by feedback messages.  Hence, assuming
   a correct
   implementation, implementation and configuration, the RTCP channel cannot
   break its bit-rate bit rate commitment and introduce congestion.

   The reception of some of the feedback messages modifies the behaviour
   of the media senders or, more specifically, the media encoders.  All
   of these modifications  Thus
   modified behaviour MUST only be performed within respect the bandwidth limits that the applied
   application of congestion control provides.  For example, when a
   media sender is reacting to a FIR, the unusually high number of
   packets that form the decoder refresh point have to be paced in
   compliance with the congestion control algorithm, even if the user
   experience suffers from a slowly transmitted decoder refresh point.

   A change of the Temporary Maximum Media Stream Bit-rate Bit Rate value can
   only mitigate congestion, but not cause congestion as long as
   congestion control is also employed.  An increase of the value by a
   request REQUIRES the media sender to use congestion control when
   increasing its transmission rate to that value.  A reduction of the
   value results in a reduced transmission bit-rate bit rate thus reducing the
   risk for congestion.

6. Security Considerations

   The defined messages have certain properties that have security
   implications.  These must be addressed and taken into account by
   users of this protocol.

   The defined setup signaling mechanism is sensitive to modification
   attacks that can result in session creation with sub-optimal
   configuration, and, in the worst case, session rejection.  To prevent
   this type of attack, authentication and integrity protection of the
   setup signaling is required.

   Spoofed or maliciously created feedback messages of the type defined
   in this specification can have the following implications:

        a. Severely severely reduced media bit-rate bit rate due to false TMMBR messages
           that sets the maximum to a very low value. value;

        b. The assignment of the ownership of a bit-rate limit with a
           TMMBN message bounding tuple to the wrong participant. Thus
           participant within a TMMBN message, potentially
           freezing causing
           unnecessary oscillation in the mechanism bounding set as the mistakenly
           identified owner reports a change in its tuple and the true
           owner possibly holds back on changes until a correct TMMBN
           message reached reaches the participants. participants;

        c. Sending sending TSTR requests that result in a video quality
           different from the user's desire, rendering the session less
           useful.

        d. Frequent FIR commands will potentially reduce the frame-rate frame-rate,
           making the video jerky jerky, due to the frequent usage of decoder
           refresh points.

   To prevent these attacks there is a need to apply authentication and
   integrity protection of the feedback messages.  This can be
   accomplished against threats external to the current RTP session
   using the RTP profile that combines SRTP [SRTP] and AVPF into SAVPF
   [SAVPF].  In the Mixer mixer cases, separate security contexts and
   filtering can be applied between the Mixer mixer and the participants thus
   protecting other users on the Mixer mixer from a misbehaving participant.

7. SDP Definitions

   Section 4 of [RFC4585] defines a new SDP [RFC4566] attributes attribute, rtcp-
   fb, that are may be used for to negotiate the capability exchange of the to handle specific
   AVPF commands and indications, such as Reference Picture selection, Selection,
   Picture loss
   indication Loss Indication etc.  The defined SDP attribute is known as rtcp-fb and its ABNF for rtcp-fb is described in
   section 4.2 of [RFC4585].  In this section we extend the rtcp-fb
   attribute to include the commands and indications that are described in this document
   for codec control protocol. protocol in the present document.  We also discuss
   the Offer/Answer implications for the codec control commands and
   indications.

7.1. Extension of the rtcp-fb attribute Attribute

   As described in AVPF [RFC4585], the rtcp-fb attribute is defined to
   indicate indicates the
   capability of using RTCP feedback. As defined in  AVPF specifies that the rtcp-fb
   attribute must only be used as a media level attribute and must not
   be provided at session level.  All the rules described in [RFC4585]
   for rtcp-fb attribute relating to payload type and to multiple rtcp-fb rtcp-
   fb attributes in a session description also apply to the new feedback
   messages defined in this memo.

   The ABNF [RFC4234] for rtcp-fb as defined in [RFC4585] is

   Rtcp-fb-syntax =

     "a=rtcp-fb: " rtcp-fb-pt SP rtcp-fb-val CRLF

   Where

   where rtcp-fb-pt is the payload type and rtcp-fb-val defines the type
   of the feedback message such as ack, nack, trr-int and rtcp-fb-id.
   For example to indicate the support of feedback of picture loss
   indication, the sender declares the following in SDP

         v=0
         o=alice 3203093520 3203093520 IN IP4 host.example.com
         s=Media with feedback
         t=0 0
         c=IN IP4 host.example.com
         m=audio 49170 RTP/AVPF 98
         a=rtpmap:98 H263-1998/90000
         a=rtcp-fb:98 nack pli

   In this document we define a new feedback value type called "ccm" which indicates
   the support of codec control using RTCP feedback messages.  The "ccm"
   feedback value should SHOULD be used with parameters, which indicates indicate the support of which
   specific codec control commands the session may
   use. supported.  In this draft we define
   four parameters, which can be used with the ccm feedback value type.

      o  "fir" indicates the support of the Full Intra Request (FIR).
      o  "tmmbr" indicates the support of Temporal the Temporary Maximum Media
         Stream
         Bit-rate. Bit Rate Request/Notification (TMMBR/TMMBN).  It has an
         optional sub parameter to indicate the session maximum packet
         rate to be used.  If not included it this defaults to infinity.
      o  "tstr" indicates the support of temporal spatial trade-off
         request. the Temporal-Spatial Trade-off
         Request/Notification (TSTR/TSTN).
      O  "vbcm" indicates the support of H.271 video back channel
         messages.
         messages (VBCM).  It has zero or more subparameters identifying
         the supported H.271 "payloadType" values.

   In the ABNF for rtcp-fb-val defined in [RFC4585], there is a
   placeholder called rtcp-fb-id to define new feedback types. The ccm  "ccm" is
   defined as a new feedback type in this document and the ABNF for the
   parameters for ccm are defined here (please refer to section 4.2 of
   [RFC4585] for complete ABNF syntax).

   Rtcp-fb-param

   rtcp-fb-param = SP "app" [SP byte-string]
                 / SP rtcp-fb-ccm-param
                 /     ; empty

   rtcp-fb-ccm-param = "ccm" SP ccm-param

   ccm-param  = "fir"   ; Full Intra Request
              / "tmmbr" [SP "smaxpr=" MaxPacketRateValue]
                        ; Temporary max media bit rate
              / "tstr"  ; Temporal Spatial Trade Off
              / "vbcm" *(SP subMessageType] subMessageType) ; H.271 VBCM messages
              / token [SP byte-string]
                         ; for future commands/indications
   subMessageType = 1*8DIGIT
   byte-string = <as defined in section 4.2 of [RFC4585] >
   MaxPacketRateValue = 1*15DIGIT

7.2. Offer-Answer

   The Offer/Answer [RFC3264] implications to for codec control protocol
   feedback messages are similar those described in [RFC4585].  The
   offerer MAY indicate the capability to support selected codec
   commands and indications.  The answerer MUST remove all ccm
   parameters which it does not understand or does not wish to use in
   this particular media session.  The answerer MUST NOT add new ccm
   parameters in addition to what has been offered.  The answer is
   binding for the media session and both offerer and answerer MUST only
   use feedback messages negotiated in this way.

   The session maximum packet rate parameter part of the TMMBR
   indication is declarative and everyone shall use the highest value
   indicated in a response.  If the session maximum packet rate
   parameter is not present in a an offer is it SHALL NOT be included by the
   answerer.

7.3. Examples

   Example 1: The following SDP describes a point-to-point video call
   with H.263 H.263, with the originator of the call declaring its capability
   to support the FIR and TSTR/TSTN codec control messages - fir, tstr. messages.  The SDP is
   carried in a high level signaling protocol like SIP SIP.

         v=0
         o=alice 3203093520 3203093520 IN IP4 host.example.com
         s=Point-to-Point call
         c=IN IP4 172.11.1.124 192.0.2.124
         m=audio 49170 RTP/AVP 0
         a=rtpmap:0 PCMU/8000
         m=video 51372 RTP/AVPF 98
         a=rtpmap:98 H263-1998/90000
         a=rtcp-fb:98 ccm tstr
         a=rtcp-fb:98 ccm fir

   In the above example example, when the sender when it receives a TSTR message from
   the remote party can adjust it is capable of adjusting the trade off as
   indicated in the RTCP TSTN feedback message.

   Example 2: The following SDP describes a SIP end point joining a
   video Mixer mixer that is hosting a multiparty video conferencing session.
   The participant supports only the FIR (Full Intra Request) codec
   control command and it declares it in its session description. The
   video Mixer can send an FIR RTCP feedback message to this end point
   when it needs to send this participants video to other participants
   of the conference.

         v=0
         o=alice 3203093520 3203093520 IN IP4 host.example.com
         s=Multiparty Video Call
         c=IN IP4 172.11.1.124 192.0.2.124
         m=audio 49170 RTP/AVP 0
         a=rtpmap:0 PCMU/8000
         m=video 51372 RTP/AVPF 98
         a=rtpmap:98 H263-1998/90000
         a=rtcp-fb:98 ccm fir

   When the video MCU decides to route the video of this participant it
   sends an RTCP FIR feedback message.  Upon receiving this feedback
   message the end point is mandated required to generate a full intra request.

   Example 3: The following example describes the Offer/Answer
   implications for the codec control messages.  The Offerer wishes to
   support "tstr", "fir" and "tmmbr" messages. "tmmbr".  The offered SDP is

   -------------> Offer
         v=0
         o=alice 3203093520 3203093520 IN IP4 host.example.com
         s=Offer/Answer
         c=IN IP4 172.11.1.124 192.0.2.124
         m=audio 49170 RTP/AVP 0
         a=rtpmap:0 PCMU/8000
         m=video 51372 RTP/AVPF 98
         a=rtpmap:98 H263-1998/90000
         a=rtcp-fb:98 ccm tstr
         a=rtcp-fb:98 ccm fir
         a=rtcp-fb:* ccm tmmbr smaxpr=120

   The answerer only wishes to support only the FIR and TSTR message as the codec
   control TSTR/TSTN messages
   and the answerer SDP is

   <---------------- Answer

         v=0
         o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
         s=Offer/Answer
         c=IN IP4 189.13.1.37 192.0.2.37
         m=audio 47190 RTP/AVP 0
         a=rtpmap:0 PCMU/8000
         m=video 53273 RTP/AVPF 98
         a=rtpmap:98 H263-1998/90000
         a=rtcp-fb:98 ccm tstr
         a=rtcp-fb:98 ccm fir

   Example 4: The following example describes the Offer/Answer
   implications for H.271 Video back channel messages (VBCM).  The
   Offerer wishes to support VBCM and the submessages sub-messages of payloadType 1
   (One
   (one or more pictures that are entirely or partially lost) and 2 (a
   set of blocks of one picture that is are entirely or partially lost).

   -------------> Offer
         v=0
         o=alice 3203093520 3203093520 IN IP4 host.example.com
         s=Offer/Answer
         c=IN IP4 172.11.1.124 192.0.2.124
         m=audio 49170 RTP/AVP 0
         a=rtpmap:0 PCMU/8000
         m=video 51372 RTP/AVPF 98
         a=rtpmap:98 H263-1998/90000
         a=rtcp-fb:98 ccm vbcm 1 2

   The answerer only wishes to support sub-messages of type 1 only

   <---------------- Answer

         v=0
         o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
         s=Offer/Answer
         c=IN IP4 189.13.1.37 192.0.2.37
         m=audio 47190 RTP/AVP 0
         a=rtpmap:0 PCMU/8000
         m=video 53273 RTP/AVPF 98
         a=rtpmap:98 H263-1998/90000
         a=rtcp-fb:98 ccm vbcm 1

   So in the above example only VBCM indication comprising indications comprised of only
   "payloadType" 1 will be supported.

8. IANA Considerations

   The new value new value "ccm" needs to be registered with IANA in the "rtcp-fb"
   Attribute Values registry located at the time of publication at:
   http://www.iana.org/assignments/sdp-parameters

   Value name:       ccm
   Long Name:        Codec Control Commands and Indications
   Reference:        RFC XXXX

   A new registry "Codec Control Messages" needs to be created to hold
   "ccm" parameters located at time of publication at:
   http://www.iana.org/assignments/sdp-parameters

   New registration in this registry follows the "Specification
   required" policy as defined by [RFC2434]. In addition they are
   required to indicate which, if any additional RTCP feedback types,
   such as "nack", "ack".

   The initial content of ccm for the rtcp-fb attribute needs to be registered
   with IANA.

   Value name:       ccm
   Long Name:        Codec Control Commands and Indications
   Reference:        RFC XXXX

   For use with "ccm" registry is the following values also needs to be
   registered. values:

   Value name:       fir
   Long name:        Full Intra Request Command
   Usable with:      ccm
   Reference:        RFC XXXX

   Value name:       tmmbr
   Long name:        Temporary Maximum Media Stream Bit-rate Bit Rate
   Usable with:      ccm
   Reference:        RFC XXXX

   Value name:       tstr
   Long name:        temporal Spatial Trade Off
   Usable with:      ccm
   Reference:        RFC XXXX

   Value name:       vbcm
   Long name:        H.271 video back channel messages
   Usable with:      ccm
   Reference:        RFC XXXX

   The following values need to be registered as FMT values in the "FMT
   Values for RTPFB Payload Types" registry located at the time of
   publication at: http://www.iana.org/assignments/rtp-parameters

   RTPFB range
   Name           Long Name                         Value  Reference
   -------------- --------------------------------- -----  ---------
                  Reserved                             2   [RFCxxxx]
   TMMBR          Temporary Maximum Media Stream Bit   3   [RFCxxxx]
                  Rate Request
   TMMBN          Temporary Maximum Media Stream Bit   4   [RFCxxxx]
                  Rate Notification

   The following values need to be registered as FMT values in the "FMT
   Values for PSFB Payload Types" registry located at the time of
   publication at: http://www.iana.org/assignments/rtp-parameters

   PSFB range
   Name           Long Name                             Value  Reference
   -------------- ---------------------------------     -----  ---------
   FIR            Full Intra Request Command              4    [RFCxxxx]
   TSTR           Temporal-Spatial Trade-off Request      5    [RFCxxxx]
   TSTN           Temporal-Spatial Trade-off Notification 6    [RFCxxxx]
   VBCM           Video Back Channel Message              7    [RFCxxxx]

9. Contributors

   Tom Taylor has made a very significant contribution, for which the
   authors are very grateful, to this specification by helping rewrite
   the specification. Especially the parts regarding the algorithm for
   determining bounding sets for TMMBR have benefited.

10.  Acknowledgements

   The authors would like to thank Andrea Basso, Orit Levin, Nermeen
   Ismail for their work on the requirement and discussion draft
   [Basso].

   Drafts of this memo were reviewed and extensively commented by Roni
   Even, Colin Perkins, Randell Jesup, Keith Lantz, Harikishan Desineni,
   Guido Franceschini and others.  The authors appreciate these reviews.

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

10.

11.  References

10.1.

11.1. Normative references

   [RFC4585]    Ott, J., Wenger, S., Sato, N., Burmeister, C., Rey, J.,
                "Extended RTP Profile for Real-Time Transport Control
                Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
   [RFC3550]    Schulzrinne, H.,  Casner, S., Frederick, R., and V.
                Jacobson, "RTP: A Transport Protocol for Real-Time
                Applications", STD 64, RFC 3550, July 2003.
   [RFC2327]
   [RFC4566]    Handley, M. and V. M., Jacobson, V., and C. Perkins, "SDP: Session
                Description Protocol", RFC 2327, April 1998. 4566, July 2006.
   [RFC3264]    Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
                with Session Description Protocol (SDP)", RFC 3264, June
                2002.
   [Topologies] M. Westerlund, and S. Wenger, "RTP Topologies", draft-
                ietf-avt-topologies-00,
                ietf-avt-topologies-04, work in progress, August 2006

10.2. Feb 2007.
   [RFC2434]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 2434,
                October 1998.
   [RFC4234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", RFC 4234, October 2005.

11.2. Informative references

   [Basso]      A. Basso, et. al., "Requirements for transport of video
                control commands", draft-basso-avt-videoconreq-02.txt,
                expired Internet Draft, October 2004.
   [AVC]        Joint Video Team of ITU-T and ISO/IEC JTC 1, Draft ITU-T
                Recommendation and Final Draft International Standard of
                Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC
                14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG
                and ITU-T VCEG, JVT-G050, March 2003.
   [H245]       ITU-T Rec. HG.245, "Control protocol for multimedia
                communication", MAY 2006
   [NEWPRED]    S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient
                Video Coding by Dynamic Replacing of Reference
                Pictures," in Proc. Globcom'96, vol. 3, pp. 1503 - 1508,
                1996.
   [SRTP]       Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
                K. Norrman, "The Secure Real-time Transport Protocol
                (SRTP)", RFC 3711, March 2004.
   [RFC2032]   Turletti, T. and C. Huitema,
   [RFC4587]    Even, R., "RTP Payload Format for H.261 Video Streams",
                RFC 2032, October 1996. 4587, August 2006.

   [SAVPF]      J. Ott, E. Carrara, "Extended Secure RTP Profile for
                RTCP-based Feedback (RTP/SAVPF)," draft-ietf-avt-profile-
                savpf-02.txt, July, 2005.
                draft-ietf-avt-profile-savpf-10.txt, Feb, 2007.
   [RFC3525]    Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
                "Gateway Control Protocol Version 1", RFC 3525, June
                2003.
   [RFC3448]    M. Handley, S. Floyd, J. Padhye, J. Widmer, "TCP
                Friendly Rate Control (TFRC): Protocol Specification", RFC 3448,
   [VBCM]       ITU-T Rec. H.271, "Video Back Channel Messages", June
                2006
   [RFC3890]    Westerlund, M., "A Transport Independent Bandwidth
                Modifier for the Session Description Protocol (SDP)",
                RFC 3890, September 2004.
   [RFC4340]    Kohler, E., Handley, M., and S. Floyd, "Datagram
                Congestion Control Protocol (DCCP)", RFC 4340, March
                2006.
   [RFC4566]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
                Description Protocol", RFC 4566, July 2006.
   [RFC3261]    Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
                A., Peterson, J., Sparks, R., Handley, M., and E.
                Schooler, "SIP: Session Initiation Protocol", RFC 3261,
                June 2002.

11.
   [RFC2198]    Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
                Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
                Parisis, "RTP Payload for Redundant Audio Data", RFC
                2198, September 1997.

12.  Authors' Addresses

   Stephan Wenger
   Nokia Corporation
   P.O. Box 100
   FIN-33721 Tampere
   FINLAND
   975, Page Mill Road,
   Palo Alto,CA 94304
   USA

   Phone: +358-50-486-0637 +1-650-862-7368
   EMail: stewe@stewe.org

   Umesh Chandra
   Nokia Research Center
   975, Page Mill Road,
   Palo Alto,CA 94304
   USA

   Phone: +1-650-796-7502
   Email: Umesh.Chandra@nokia.com
   Magnus Westerlund
   Ericsson Research
   Ericsson AB
   SE-164 80 Stockholm, SWEDEN

   Phone: +46 8 7190000
   EMail: magnus.westerlund@ericsson.com

   Bo Burman
   Ericsson Research
   Ericsson AB
   SE-164 80 Stockholm, SWEDEN

   Phone: +46 8 7190000
   EMail: bo.burman@ericsson.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor Considerations

   The RFC editor is requested to replace all occurrences of XXXX with
   the RFC number this document receives.