Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
RFC 5104

Wenger, et al.              Standards Track                    [Page 25]
RFC 5104             Codec Control Messages in AVPF        February 2008

   illustrates the conclusion that if two TMMBR tuples have the same
   overhead value, the one with higher maximum total media bit rate
   value cannot be part of the bounding set and can be set aside.

   Two further observations complete the algorithm.  Obviously, moving
   from the left, the successive corners of the bounding polygon (i.e.,
   the 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
   crosses the X-axis at a lower packet rate.

   The complete algorithm can now be specified.  The algorithm works
   with two lists of TMMBR tuples, the candidate list X and the selected
   list Y, both ordered by increasing overhead value.  The algorithm
   terminates when all members of X have been discarded or removed for
   processing.  Membership of the selected list Y is probationary until
   the algorithm is complete.  Each member of the selected list is
   associated with an intersection value, which is the packet rate at
   which the line corresponding to that TMMBR tuple intersects with the
   line corresponding to the previous TMMBR tuple in the selected list.
   Each member of the selected list is also associated with a maximum
   packet rate value, which is the lesser of the session maximum packet
   rate SMAXPR (if any) and the packet rate at which the line
   corresponding to 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 media sender when it has received one
   or more TMMBRs and before it has determined a bounding set for the
   first time.

   1. Sort the TMMBR tuples by order of increasing overhead.  This is
      the initial candidate list X.

   2. When multiple tuples in the candidate list have the same overhead
      value, discard all but the one with the lowest maximum total media
      bit rate value.

   3. Select and remove from the candidate list the TMMBR tuple with the
      lowest maximum total media bit rate value.  If there is more than
      one tuple with that value, choose the one with the highest
      overhead value.  This is the first member of the selected list Y.
      Set its intersection value equal to zero.  Calculate its maximum

Wenger, et al.              Standards Track                    [Page 26]
RFC 5104             Codec Control Messages in AVPF        February 2008

      packet rate as the minimum of SMAXPR (if available) and the value
      obtained from the following formula, which is the packet rate at
      which the corresponding line crosses the X-axis.

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

   4. Discard from the candidate list all tuples with a lower overhead
      value than the selected tuple.

   5. Remove the first remaining tuple from the candidate list for
      processing.  Call this the current candidate.

   6. Calculate the packet rate PR at the intersection of the line
      generated by the current candidate with the line generated by the
      last tuple in the selected list Y, using equation (3).

   7. If the calculated value PR is equal to or lower than the
      intersection value stored for the last tuple of the selected list,
      discard the last tuple of the selected list and go back to step 6
      (retaining the same current candidate).

      Note that the choice of the initial member of the selected list Y
      in step 3 guarantees that the selected list will never be emptied
      by this process, meaning that the algorithm must eventually (if
      not immediately) fall through to step 8.

   8. (This step is reached when the calculated PR value of the current
      candidate is greater than the intersection value of the current
      last member of the selected list Y.)  If the calculated value PR
      of the current candidate is lower than the maximum packet rate
      associated with the last tuple in the 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 as
      the lesser of SMAXPR (if available) and the maximum packet rate
      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 media
   sender.  When a previously created selected list is available at
   either the media sender or media receiver, two other cases can be
   considered:

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

Wenger, et al.              Standards Track                    [Page 27]
RFC 5104             Codec Control Messages in AVPF        February 2008

        o when the values change in a TMMBR tuple currently in the
          selected list.

   At the media receiver, these cases correspond, respectively, to those
   of the non-owner and owner of a tuple in the TMMBN-reported bounding
   set.

   In either case, the process of updating the selected list to take
   account of the new/changed tuple can use the basic algorithm
   described above, with the modification that the initial candidate set
   consists only of the existing selected list and 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 if the new/changed candidate becomes
   part of the new selected list, the result may be to cause zero or
   more other tuples to be dropped from the list.  However, if more than
   one other tuple is dropped, the dropped tuples will be consecutive.
   This can be confirmed geometrically by visualizing a new line that
   cuts off a series of segments from the previously existing bounding
   polygon.  The cut-off segments are connected one to 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 new
   candidate, the order of tuples remaining in the updated selected list
   is unchanged because their overhead values have not changed.

   The consequence of these two observations is that, once the placement
   of the new candidate and the extent of the dropped set of tuples (if
   any) has been determined, the remaining tuples can be copied directly
   from the candidate list into the selected list, preserving their
   order.  This conclusion suggests the following modified algorithm:

       o Run steps 1-4 of the 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 the
          selected list.  Then move all remaining candidates to the
          selected list, preserving their order.

       o If the new candidate has survived steps 2 and 4 and has not
          become the new first member of the selected list, start by
          moving all tuples in the candidate list with lower overhead
          values than that of the new candidate to the selected list,
          preserving their order.  Run steps 5-9 for the new candidate,

Wenger, et al.              Standards Track                    [Page 28]
RFC 5104             Codec Control Messages in AVPF        February 2008

          with the modification that the intersection values and maximum
          packet rates for the tuples on the selected list have to be
          calculated on the fly because they were not previously stored.
          Continue processing only until a subsequent tuple has been
          added to the selected list, then move all remaining candidates
          to the selected list, preserving their order.

          Note that the new candidate could be added to the selected
          list only to be dropped again when the next tuple is
          processed.  It can easily be seen that in this case the new
          candidate does not displace any of the earlier tuples in the
          selected list.  The limitations of ASCII art make this
          difficult to show in a figure.  Line cc..c in Figure 1 would
          be an example if 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 algorithm just described is approximate, because it does not take
   account of tuples outside the selected list.  To see how such tuples
   can become relevant, consider Figure 1 and suppose that the maximum
   total media bit rate in tuple A increases to the point that line
   aa..a moves outside line cc..c.  Tuple A will remain in the bounding
   set calculated by the media sender.  However, once it issues a new
   TMMBN, media receiver C will apply the algorithm and discover that
   its tuple C should now enter the bounding set.  It will issue a TMMBR
   to the media sender, which will repeat its calculation and come to
   the appropriate conclusion.

   The rules of section 4.2 require that the media sender refrain from
   raising its sending rate until media receivers have had a chance to
   respond to the TMMBN.  In the example just given, this delay ensures
   that the relaxation of tuple A does not actually result in an attempt
   to send media at a rate exceeding the capacity at C.

3.5.4.3.  Use of TMMBR in a Mixer-Based Multipoint Operation

   Assume a small mixer-based multiparty conference is ongoing, as
   depicted in Topo-Mixer of [RFC5117].  All participants have
   negotiated a common maximum 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 (RRs) or the
   transport protocol, e.g., Datagram Congestion Control Protocol (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
   document, the mixer (which is aware of the congestion situation on

Wenger, et al.              Standards Track                    [Page 29]
RFC 5104             Codec Control Messages in AVPF        February 2008

   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, unfortunately, media-aware streaming thinning is 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 is desirable.

   To allow the mixer to throttle traffic on the individual links,
   without performing transcoding, there is a need for a mechanism that
   enables the mixer to ask a participant's media encoders to limit the
   media stream bit rate they are currently generating.  TMMBR provides
   the required mechanism.  When the mixer detects congestion between
   itself and a given participant, it executes the following procedure:

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

   2. It uses TMMBR to request the media sender(s) to reduce the total
      media 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 / bit rate /
      capacity and packet rate after congestion control.

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

   This use of stream thinning as an immediate reaction tool followed up
   by a quick control mechanism appears to be a reasonable compromise
   between media quality and the need to combat congestion.

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

   In these topologies, corresponding to Topo-Multicast or Topo-
   Translator, RTCP RRs are transmitted globally.  This allows 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 for the use of TMMBR
   in the previous section does not apply.  However, even in this case
   the congestion control response can be improved when the unicast

Wenger, et al.              Standards Track                    [Page 30]
RFC 5104             Codec Control Messages in AVPF        February 2008

   links are using congestion controlled transport protocols (such as
   TCP or DCCP).  A peer may also report local 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
   when the known upper limit of the bit rate changes.  In this use
   case, the signaling protocol has established an upper limit for the
   session and total media bit rates.  However, at the time of transport
   link bit rate reduction, a receiver 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 provide the continuously quick feedback loop
   required for real congestion control.  Nor do its semantics match
   those of congestion control given its different purpose.  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 would
   not allow for easy suppression of other participants' requests.  For
   these reasons, a mechanism based on explicit notification is used.

   Upon the reception of a TMMBR, a media sender sends a TMMBN
   containing the current bounding set, and indicating which session
   participants own that limit.  In multicast scenarios, that allows all
   other participants to suppress any request they may have, if their
   limitations are less strict than the current ones (i.e., define lines
   lying outside the 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 bounding set
   of tuples; all other requests and their sources are not saved.  Once
   the bounding set has been established, new TMMBR messages should be
   generated only by owners of the bounding tuples and by other entities
   that determine (by applying the algorithm of section 3.5.4.2 or its
   equivalent) that their limitations should now be part of the bounding
   set.

Wenger, et al.              Standards Track                    [Page 31]
RFC 5104             Codec Control Messages in AVPF        February 2008

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 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
   Request (TMMBR) and Temporary Maximum Media Stream Bit Rate
   Notification (TMMBN) are "Transport Layer Feedback Messages" as
   defined in section 6.2 of AVPF.

   The new feedback messages are defined in the following subsections,
   following a similar structure to that in sections 6.2 and 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 was introduced in early RTP
   payload formats for video formats, for example, in RFC 2032 [RFC2032]
   (which was obsoleted by RFC 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 a precedent for the use of RTCP as an RTP session
   control protocol.  To prevent such a misunderstanding, this
   subsection attempts to clarify the scope of the extensions specified
   in this memo, and it 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 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);

   b) are multicast-safe in that the reaction to potentially
      contradicting feedback messages is specified, as necessary for
      each 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.

Wenger, et al.              Standards Track                    [Page 32]
RFC 5104             Codec Control Messages in AVPF        February 2008

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

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

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

   All messages in AVPF [RFC4585] and in this memo present their
   contents in a simple, fixed binary format.  This accommodates media
   receivers that have not implemented higher control protocol
   functionalities (SDP, XML parsers, and such) in their media path.

   Messages that do not conform to the design principles just described
   are not an appropriate use of RTCP or of the Codec Control Framework
   defined in this document.

4.2.  Transport Layer Feedback Messages

   As specified in section 6.1 of RFC 4585 [RFC4585], transport layer
   feedback messages are identified by the RTCP packet type value RTPFB
   (205).

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

   Assigned in AVPF [RFC4585]:

      1:    Generic NACK
      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 Request (TMMBR)
      4:    Temporary Maximum Media Stream Bit Rate Notification (TMMBN)

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

Wenger, et al.              Standards Track                    [Page 33]
RFC 5104             Codec Control Messages in AVPF        February 2008

   Available for assignment:

      0:    unassigned
      5-30: unassigned

   The following subsection defines the formats of the Feedback Control
   Information (FCI) entries for the TMMBR and TMMBN messages,
   respectively, and specifies the associated behaviour at the media
   sender and receiver.

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

   The Temporary Maximum Media Stream Bit Rate Request is identified by
   RTCP packet type value PT=RTPFB and FMT=3.

   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 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 the description in section 4.2.1.2. The value is an
              unsigned integer [0..511].

Wenger, et al.              Standards Track                    [Page 34]
RFC 5104             Codec Control Messages in AVPF        February 2008

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

      MxTBR = mantissa * 2^exp

   This allows for 17 bits of resolution in the range 0 to 131072*2^63
   (approximately 1.2*10^24).

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

4.2.1.2.  Semantics

   Behaviour at the Media Receiver (Sender of the TMMBR)

   TMMBR is used to indicate a transport-related limitation at the
   reporting entity acting as a media receiver.  TMMBR has the form of a
   tuple containing two components.  The first value is the highest bit
   rate per sender of a media stream, available at a receiver-chosen
   protocol layer, which the receiver currently supports in this RTP
   session.  The second value is the measured header overhead in bytes
   as defined in section 2.2 and measured at the chosen protocol layer
   in the packets received for the stream.  The measurement of the
   overhead is a running average that is updated for each packet
   received for this particular media source (SSRC), using the following
   formula:

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

   where avg_OH is the running (exponentially smoothed) average and
   pckt_OH is the overhead observed in the latest packet.

   If a maximum bit rate has been negotiated through signaling, the
   maximum total media bit rate that the receiver reports in a TMMBR
   message MUST NOT exceed the negotiated value converted to a common
   basis (i.e., with overheads adjusted to bring it to the same
   reference protocol layer).

   Within the common packet header for feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of packet sender" field
   indicates the source of the request, and the "SSRC of media source"
   is not used and SHALL be set to 0.  Within a particular TMMBR FCI
   entry, the "SSRC of media source" in the FCI field denotes the media
   sender that the 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.

Wenger, et al.              Standards Track                    [Page 35]
RFC 5104             Codec Control Messages in AVPF        February 2008

   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 is determined to belong to the bounding set.

   A TMMBR FCI entry MAY be repeated in subsequent TMMBR messages if no
   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.  The bit rate value of a TMMBR FCI entry MAY be
   changed from one TMMBR message to the next.  The overhead measurement
   SHALL be updated to the current value of avg_OH each time the entry
   is sent.

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

   Behaviour at the Media Sender (Receiver of the TMMBR)

   When it receives a TMMBR message containing an FCI entry relating to
   it, the media sender SHALL use an initial or incremental algorithm as
   applicable to determine the bounding set of tuples based on the new
   information.  The algorithm used SHALL be at least as strict as the
   corresponding algorithm defined in section 3.5.4.2.  The media sender
   MAY accumulate TMMBRs over a small interval (relative to the RTCP
   sending interval) before making this calculation.

   Once it has determined the bounding set of tuples, the media sender
   MAY use any combination of packet rate and net media bit rate within
   the feasible region that these tuples describe to produce a lower

Wenger, et al.              Standards Track                    [Page 36]
RFC 5104             Codec Control Messages in AVPF        February 2008

   total media stream bit rate, as it may need to address a congestion
   situation or other limiting factors.  See section 5 (congestion
   control) for more discussion.

   If the media sender concludes that it can increase the maximum total
   media bit rate value, it SHALL wait before actually doing so, for a
   period long enough to allow a media receiver to respond to the TMMBN
   if it determines that its tuple belongs in the bounding set.  This
   delay period is estimated by the formula:

      2 * RTT + T_Dither_Max,

   where RTT is the longest round trip time known to the media sender
   and T_Dither_Max is defined in section 3.4 of [RFC4585].  Even in
   point-to-point sessions, a media sender MUST obey the aforementioned
   rule, as it is not guaranteed that a participant is able to determine
   correctly whether all the sources are co-located in a single node,
   and are coordinated.

   A TMMBN message SHALL be sent by the media sender at the earliest
   possible point in time, in response to any TMMBR messages received
   since the last sending of TMMBN.  The TMMBN message indicates the
   calculated set of bounding tuples and the owners of those tuples at
   the time of the transmission of the message.

   An SSRC may time out according to the default rules for RTP session
   participants, 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 media sender determines
   that the owner of a tuple in the bounding set has left the session,
   the media sender SHALL transmit a new TMMBN containing the previously
   determined set of bounding tuples but with the tuple belonging to the
   departed owner removed.

   A media sender MAY proactively initiate the equivalent to a TMMBR
   message to itself, when it is aware that its transmission path is
   more restrictive than the current limitations.  As a result, a TMMBN
   indicating the media source itself as the owner of a tuple is being
   sent, thereby avoiding unnecessary TMMBR messages from other
   participants.  However, like any other participant, when the media
   sender becomes aware of changed limitations, it is required to change
   the tuple, and to send a corresponding TMMBN.

Wenger, et al.              Standards Track                    [Page 37]
RFC 5104             Codec Control Messages in AVPF        February 2008

   Discussion

   Due to the unreliable nature of transport of TMMBR and TMMBN, the
   above rules may lead to the sending of TMMBR messages that appear to
   disobey those rules.  Furthermore, in multicast scenarios it can
   happen that more than one "non-owning" session participant may
   determine, rightly or wrongly, that its tuple belongs in the bounding
   set.  This is not critical for a number of reasons:

   a) If a TMMBR message is lost in transmission, either the media
      sender sends a new TMMBN message in response to some other 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 the
      bounding set, sends out another TMMBR.  In the second case, it
      repeats the sending of a TMMBR unconditionally.  Either way, the
      media sender eventually gets the information it needs.

   b) Similarly, if a TMMBN message gets lost, the media receiver that
      has sent the corresponding TMMBR does not receive the notification
      and is expected to re-send the request and trigger the
      transmission of another TMMBN.

   c) If multiple competing TMMBR messages are sent by different session
      participants, then the algorithm can be applied taking all of
      these messages into account, and the resulting TMMBN provides the
      participants with an updated view of how their tuples compare with
      the bounded set.

   d) If more than one session participant happens to send TMMBR
      messages at the same time and with the same tuple component
      values, it does not matter which of those tuples is taken into the
      bounding set.  The losing session participant will determine,
      after applying the algorithm, that its tuple does not enter the
      bounding set, and will therefore stop sending its TMMBR.

   It is important to consider the security risks involved with faked
   TMMBRs.  See the security considerations in section 6.

   As indicated already, the feedback messages may be used in both
   multicast and unicast sessions in any of the specified topologies.
   However, for sessions with a large number of participants, using the
   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 bit rate to participants'
   capabilities, such as partitioning the session into different quality
   tiers or using some other method of achieving bit rate scalability.

Wenger, et al.              Standards Track                    [Page 38]
RFC 5104             Codec Control Messages in AVPF        February 2008

4.2.1.3.  Timing Rules

   The first transmission of the TMMBR 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 Translators and Mixers

   Media translators and 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 and thus generate a TMMBN to indicate that it
   has done so.  Alternatively, in the case of a media translator it can
   forward the request, or in the case of a 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 Notification (TMMBN)

   The Temporary Maximum Media Stream Bit Rate Notification is
   identified by RTCP packet type value PT=RTPFB and FMT=4.

   The FCI field of the TMMBN feedback message may contain zero, one, or
   more TMMBN FCI 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].

Wenger, et al.              Standards Track                    [Page 39]
RFC 5104             Codec Control Messages in AVPF        February 2008

     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
              [0..511].

   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 an
   owner has left the session.  It indicates to all participants the
   current set of bounding tuples and the "owners" of those tuples.

   Within the common packet header for feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of packet sender" field
   indicates the source of the notification.  The "SSRC of media 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 an FCI entry identifying this media
   sender.  Only a single TMMBN SHALL be sent, even if more than one
   TMMBR message is received between the scheduling of the transmission
   and the actual transmission of the TMMBN message.  The TMMBN message
   indicates the bounding tuples and their owners at the time of
   transmitting the message.  The bounding tuples included SHALL be the
   set arrived at through application of the applicable algorithm of
   section 3.5.4.2 or an equivalent, applied to the previous bounding
   set, if any, and tuples received in TMMBR messages since the last
   TMMBN was transmitted.

   The reception of a TMMBR message SHALL still result in the
   transmission of a TMMBN message even if, after application of the
   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 the TMMBR was from an owner of a tuple within
   the previously calculated bounding set.  This procedure allows
   session participants that did not see the last TMMBN message to get a
   correct view of this media sender's state.

Wenger, et al.              Standards Track                    [Page 40]
RFC 5104             Codec Control Messages in AVPF        February 2008

   As indicated in section 4.2.1.2, when a media sender determines that
   an "owner" of a bounding tuple has left the session, then that tuple
   is removed from the bounding set, and the media sender SHALL send a
   TMMBN message indicating the remaining bounding tuples.  If there are
   no remaining bounding tuples, a TMMBN without any FCI SHALL be sent
   to indicate this.  Without a remaining bounding tuple, the maximum
   media bit rate and maximum packet rate negotiated in session
   signaling, if any, apply.

     Note: if any media receivers remain in the session, this last will
     be a temporary situation.  The empty TMMBN will cause every
     remaining media receiver to determine that its limitation belongs
     in the bounding set and send a TMMBR in consequence.

   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" of the one
   bounding tuple as soon as the media receiver has issued the first
   TMMBR 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, mixers or translators may need to
   issue TMMBN messages as responses to TMMBR messages for SSRCs handled
   by 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 RTCP packet type value PSFB (206).

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

Wenger, et al.              Standards Track                    [Page 41]
RFC 5104             Codec Control Messages in AVPF        February 2008

   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 (FIR) Command
     5:     Temporal-Spatial Trade-off Request (TSTR)
     6:     Temporal-Spatial Trade-off Notification (TSTN)
     7:     Video Back Channel Message (VBCM)

   Unassigned:

         0: unassigned
      8-14: unassigned
     16-30: unassigned

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

4.3.1.  Full Intra Request (FIR)

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

   The FCI field MUST contain one or more FIR entries.  Each entry
   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 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

Wenger, et al.              Standards Track                    [Page 42]
RFC 5104             Codec Control Messages in AVPF        February 2008

     SSRC (32 bits): The SSRC value of the media sender that 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

   Within the common packet header for feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of 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 SSRCs of the media senders to
   which the FIR command applies are in the corresponding FCI entries.
   A FIR message MAY contain requests to multiple media senders, using
   one FCI entry per target media sender.

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

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

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

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

Wenger, et al.              Standards Track                    [Page 43]
RFC 5104             Codec Control Messages in AVPF        February 2008

   Other RTP payload specifications such as RFC 2032 [RFC2032] 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 of receiving and
   reacting to the feedback scheme defined in the respective RTP payload
   format, if this is required by that payload format.

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 FIR Message in Mixers 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; instead, it SHOULD issue a FIR itself.

4.3.1.5. Remarks

   Currently, video appears to be the only useful application for FIR,
   as it appears to be the only RTP 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 [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.

   In conjunction with video codecs, FIR messages typically trigger the
   sending of full intra or IDR pictures.  Both are several times larger
   than 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 multiple of the
   typical frame duration.  An example: if the sending frame rate is 10
   fps, and an intra picture is assumed to be 10 times as big as an

Wenger, et al.              Standards Track                    [Page 44]
RFC 5104             Codec Control Messages in AVPF        February 2008

   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] should not
   have an overly negative impact on the system performance.

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

   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" of the sender of the FIR
   message (however "importance" may be defined in this specific
   application), the frequency of decoder refresh points in the content,
   and so on.  However, a session that predominantly handles pre-coded
   content is not expected to use FIR at all.

   The relationship between the Picture Loss Indication and FIR is as
   follows.  As discussed in section 6.3.1 of AVPF [RFC4585], a Picture
   Loss Indication informs the decoder about the loss of a picture and
   hence the likelihood of misalignment of the reference pictures
   between the encoder and decoder.  Such a scenario is normally related
   to losses in an ongoing connection.  In point-to-point scenarios, and
   without the presence of advanced error resilience tools, one possible
   option for an encoder consists in sending a 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) encoder no
   choice but to send a decoder refresh point.  It does not allow the
   encoder to take into account any considerations such as the ones
   mentioned above.

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

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

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

Wenger, et al.              Standards Track                    [Page 45]
RFC 5104             Codec Control Messages in AVPF        February 2008

4.3.2.1.  Message Format

   The content of the FCI entry for the Temporal-Spatial Trade-off
   Request is depicted in Figure 5.  The length of the 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 5 - Syntax of an FCI Entry in the TSTR Message

     SSRC (32 bits): The SSRC of the media sender that is requested to
              apply the trade-off value given in Index.

     Seq nr. (8 bits): Request sequence number.  The sequence number
              space is unique for 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.  The
              initial value is arbitrary.

     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 indicates the highest possible spatial quality, while
              31 indicates the 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 indicates
   monotonically a desire for higher frame rate.  The index values do
   not correspond to precise values of spatial quality or frame rate.

Wenger, et al.              Standards Track                    [Page 46]
RFC 5104             Codec Control Messages in AVPF        February 2008

   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 means of the TSTN message.

   Within the common packet header for feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of 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 SSRCs of the media senders to
   which the TSTR 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.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 quick feedback, the message MAY be sent with early or
   immediate feedback timing.

4.3.2.4.  Handling of Message in Mixers and Translators

   A mixer or 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 encoding for
   multiple session participants will need to consider the joint needs
   of these participants before generating a TSTR 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 as 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 value to

Wenger, et al.              Standards Track                    [Page 47]
RFC 5104             Codec Control Messages in AVPF        February 2008

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

   The FCI field SHALL contain one or more TSTN 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 that resulted in
              this Notification.

     Seq nr. (8 bits): The sequence number value from the TSTR 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 requested one, for example, in cases where a media
      encoder cannot tune its trade-off, or when pre-recorded content is
      used.

Wenger, et al.              Standards Track                    [Page 48]
RFC 5104             Codec Control Messages in AVPF        February 2008

4.3.3.2.  Semantics

   This feedback message is used to acknowledge the reception of a TSTR.
   For each TSTR received targeted at the session participant, a TSTN
   FCI entry SHALL be sent in a TSTN feedback message.  A single TSTN
   message MAY acknowledge multiple requests using multiple FCI entries.
   The index value included SHALL be the same in all FCI entries of the
   TSTN message.  Including a FCI for each requestor allows each
   requesting entity to determine that the media sender received the
   request.  The Notification SHALL also be sent 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.  Note that the highest sequence number may be a smaller
   integer value due to the wrapping of the field.  Appendix A.1 of
   [RFC3550] has an algorithm for keeping track of the highest received
   sequence number for RTP packets; it could be adapted for this usage.

   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.

   Within the common packet header for feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of 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 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 TSTN in Mixers and Translators

   A mixer or translator that 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 the
   TSTR has been responded to.

4.3.3.5.  Remarks

   None.

Wenger, et al.              Standards Track                    [Page 49]
RFC 5104             Codec Control Messages in AVPF        February 2008

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

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

   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

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

   Seq nr. (8 bits): Command sequence number.  The sequence number space
          is unique for pairing of the SSRC of the 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 interpreted.

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

   VBCM Octet String (variable length): This is the 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.

Wenger, et al.              Standards Track                    [Page 50]
RFC 5104             Codec Control Messages in AVPF        February 2008

4.3.4.2.  Semantics

   The "payload" of the VBCM indication carries different types of
   codec-specific, feedback information.  The type of feedback
   information can be classified as a 'status report' (such as an
   indication that a bit stream was received without errors, or that a
   partial or complete picture or 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 as FIR.  Please
          see section 3.5.3 for further discussion.

   The different types of feedback sub-messages carried in the VBCM are
   indicated by the "payloadType" as defined in [H.271].  These sub-
   message types are reproduced below for convenience.  "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          Message Content
   Type
   ---------------------------------------------------------------------
   0      One or more pictures without detected 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 bit stream as if no prior 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 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 VBCMs.

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

   Within the common packet header for feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of packet sender" field
   indicates the source of the request, and the "SSRC of media source"

Wenger, et al.              Standards Track                    [Page 51]
RFC 5104             Codec Control Messages in AVPF        February 2008

   is not used and SHALL be set to 0.  The SSRCs of the media senders to
   which the VBCM applies are in the corresponding FCI entries.  The
   sender of the VBCM MAY send H.271 messages to multiple media senders
   and MAY send more than one H.271 message to the same media sender
   within the same VBCM.

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 Mixers or Translators

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

4.3.4.5.  Remarks

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

     Note: There has been some discussion whether the RTP payload type
     field in this message is needed.  It will be needed if there is
     potentially more than one VBCM-capable RTP payload type in the same
     session, and the semantics of a given VBCM changes 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).  Therefore, the
     payload field is justified here.  There was a further comment that
     for TSTR and FIR such a need does not exist, because the semantics
     of TSTR 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 and configuration, the RTCP channel cannot
   break its 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.

Wenger, et al.              Standards Track                    [Page 52]
RFC 5104             Codec Control Messages in AVPF        February 2008

   Thus, modified behaviour MUST respect the bandwidth limits that the
   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 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, 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 reduced media bit rate due to false TMMBR messages
           that sets the maximum to a very low value;

        b. assignment of the ownership of a bounding tuple to the wrong
           participant within a TMMBN message, potentially causing
           unnecessary oscillation in the 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 reaches the participants;

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

        d. sending multiple FIR commands to reduce the frame rate, and
           make the video jerky, due to the frequent usage of decoder
           refresh points.

Wenger, et al.              Standards Track                    [Page 53]
RFC 5104             Codec Control Messages in AVPF        February 2008

   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 Secure RTP [SRTP] and AVPF into
   SAVPF [SAVPF].  In the mixer cases, separate security contexts and
   filtering can be applied between the mixer and the participants, thus
   protecting other users on the mixer from a misbehaving participant.

7.  SDP Definitions

   Section 4 of [RFC4585] defines a new SDP [RFC4566] attribute, rtcp-
   fb, that may be used to negotiate the capability to handle specific
   AVPF commands and indications, such as Reference Picture Selection,
   Picture Loss Indication, etc.  The 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
   for codec control 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

   As described in AVPF [RFC4585], the rtcp-fb attribute indicates the
   capability of using RTCP feedback.  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 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

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

   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

Wenger, et al.              Standards Track                    [Page 54]
RFC 5104             Codec Control Messages in AVPF        February 2008

   In this document, we define a new feedback value "ccm", which
   indicates the support of codec control using RTCP feedback messages.
   The "ccm" feedback value SHOULD be used with parameters that indicate
   the specific codec control commands supported.  In this document, we
   define four such parameters, namely:

      o  "fir" indicates support of the Full Intra Request (FIR).
      o  "tmmbr" indicates support of the Temporary Maximum Media Stream
         Bit Rate Request/Notification (TMMBR/TMMBN).  It has an
         optional sub-parameter to indicate the session maximum packet
         rate (measured in packets per second) to be used.  If not
         included, this defaults to infinity.
      o  "tstr" indicates support of the Temporal-Spatial Trade-off
         Request/Notification (TSTR/TSTN).
      o  "vbcm" indicates support of H.271 Video Back Channel Messages
         (VBCMs).  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.  "ccm" is
   defined as a new feedback type in this document, and the ABNF for the
   parameters for ccm is defined here (please refer to section 4.2 of
   [RFC4585] for complete ABNF syntax).

   rtcp-fb-val        =/ "ccm" rtcp-fb-ccm-param

   rtcp-fb-ccm-param  = SP "fir"   ; Full Intra Request
                      / SP "tmmbr" [SP "smaxpr=" MaxPacketRateValue]
                                   ; Temporary max media bit rate
                      / SP "tstr"  ; Temporal-Spatial Trade-Off
                      / SP "vbcm" *(SP subMessageType) ; H.271 VBCMs
                      / SP 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 for codec control protocol
   feedback messages are similar to those described in [RFC4585].  The
   offerer MAY indicate the capability to support selected codec
   commands and indications.  The answerer MUST remove all CCM
   parameters corresponding to the CCMs that it does not wish to support
   in this particular media session (for example, because it does not
   implement the message in question, or because its application logic
   suggests that support of the message adds no value).  The answerer
   MUST NOT add new ccm parameters in addition to what has been offered.

Wenger, et al.              Standards Track                    [Page 55]
RFC 5104             Codec Control Messages in AVPF        February 2008

   The answer is binding for the media session and both offerer and
   answerer MUST NOT use any feedback messages other than what both
   sides have explicitly indicated as being supported.  In other words,
   only the joint subset of CCM parameters from the offer and answer may
   be used.

   Note that including a CCM parameter in an offer or answer indicates
   that the party (offerer or answerer) is at least capable of receiving
   the corresponding CCM(s) and act upon them.  In cases when the
   reception of a negotiated CCM mandates the party to respond with
   another CCM, it must also have that capability.  Although it is not
   mandated to initiate CCMs of any negotiated type, it is generally
   expected that a party will initiate CCMs when appropriate.

   The session maximum packet rate parameter part of the TMMBR
   indication is declarative, and the highest value from offer and
   answer SHALL be used.  If the session maximum packet rate parameter
   is not present in an offer, 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, with the originator of the call declaring its capability
   to support the FIR and TSTR/TSTN codec control messages.  The SDP is
   carried in a high-level signaling protocol like SIP.

         v=0
         o=alice 3203093520 3203093520 IN IP4 host.example.com
         s=Point-to-Point call
         c=IN IP4 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, when the sender receives a TSTR message from
   the remote party 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 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.

Wenger, et al.              Standards Track                    [Page 56]
RFC 5104             Codec Control Messages in AVPF        February 2008

         v=0
         o=alice 3203093520 3203093520 IN IP4 host.example.com
         s=Multiparty Video Call
         c=IN IP4 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 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".  The offered SDP is

   -------------> Offer
         v=0
         o=alice 3203093520 3203093520 IN IP4 host.example.com
         s=Offer/Answer
         c=IN IP4 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 wishes to support only the FIR and 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 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

Wenger, et al.              Standards Track                    [Page 57]
RFC 5104             Codec Control Messages in AVPF        February 2008

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

   -------------> Offer
         v=0
         o=alice 3203093520 3203093520 IN IP4 host.example.com
         s=Offer/Answer
         c=IN IP4 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 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 indications comprised of
   "payloadType" 1 will be supported.

8.  IANA Considerations

   The new value "ccm" has been 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 5104

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

Wenger, et al.              Standards Track                    [Page 58]
RFC 5104             Codec Control Messages in AVPF        February 2008

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

   The initial content of the registry is the following values:

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

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

      Value name:       tstr
      Long name:        Temporal Spatial Trade Off
      Usable with:      ccm
      Reference:        RFC 5104

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

   The following values have been 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   [RFC5104]
   TMMBR          Temporary Maximum Media Stream Bit   3   [RFC5104]
                  Rate Request
   TMMBN          Temporary Maximum Media Stream Bit   4   [RFC5104]
                  Rate Notification

   The following values have been 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

Wenger, et al.              Standards Track                    [Page 59]
RFC 5104             Codec Control Messages in AVPF        February 2008

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

9.  Contributors

   Tom Taylor has made a very significant contribution to this
   specification, for which the authors are very grateful, 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, and Nermeen
   Ismail for their work on the requirement and discussion document
   [Basso].

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

11.  References

11.1.  Normative References

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

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

   [RFC4566]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
               Description Protocol", RFC 4566, July 2006.

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

Wenger, et al.              Standards Track                    [Page 60]
RFC 5104             Codec Control Messages in AVPF        February 2008

   [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]     Basso, A., Levin, O., and N. Ismail, "Requirements for
               transport of video control commands", Work in Progress,
               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. H.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, "RTP Payload Format for
               H.261 Video Streams", RFC 2032, October 1996.

   [SAVPF]     Ott, J. and E. Carrara, "Extended Secure RTP Profile for
               RTCP-based Feedback (RTP/SAVPF)", Work in Progress,
               November 2007.

   [RFC3525]   Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
               "Gateway Control Protocol Version 1", RFC 3525, June
               2003.

   [RFC3448]   Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
               Friendly Rate Control (TFRC): Protocol Specification",
               RFC 3448, January 2003.

   [H.271]     ITU-T Rec. H.271, "Video Back Channel Messages", June
               2006.

Wenger, et al.              Standards Track                    [Page 61]
RFC 5104             Codec Control Messages in AVPF        February 2008

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

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

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

   [RFC4587]   Even, R., "RTP Payload Format for H.261 Video Streams",
               RFC 4587, August 2006.

   [RFC5117]   Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
               January 2008.

   [XML-MC]    Levin, O., Even, R., and P. Hagendorf, "XML Schema for
               Media Control", Work in Progress, November 2007.

Wenger, et al.              Standards Track                    [Page 62]
RFC 5104             Codec Control Messages in AVPF        February 2008

Authors' Addresses

   Stephan Wenger
   Nokia Corporation
   975, Page Mill Road,
   Palo Alto,CA 94304
   USA

   Phone: +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.1.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

Wenger, et al.              Standards Track                    [Page 63]
RFC 5104             Codec Control Messages in AVPF        February 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

Wenger, et al.              Standards Track                    [Page 64]