diff options
Diffstat (limited to 'doc/rfc/rfc5104.txt')
| -rw-r--r-- | doc/rfc/rfc5104.txt | 3587 |
1 files changed, 3587 insertions, 0 deletions
diff --git a/doc/rfc/rfc5104.txt b/doc/rfc/rfc5104.txt new file mode 100644 index 0000000..ab35344 --- /dev/null +++ b/doc/rfc/rfc5104.txt @@ -0,0 +1,3587 @@ + + + + + + +Network Working Group S. Wenger +Request for Comments: 5104 U. Chandra +Category: Standards Track Nokia + M. Westerlund + B. Burman + Ericsson + February 2008 + + + Codec Control Messages in the + RTP Audio-Visual Profile with Feedback (AVPF) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +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 Rec. H.271 + Video Back Channel, Full Intra Request, Temporary Maximum Media + Stream Bit Rate, and Temporal-Spatial Trade-off. + + + + + + + + + + + + + + + + + + + + +Wenger, et al. Standards Track [Page 1] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Definitions .....................................................5 + 2.1. Glossary ...................................................5 + 2.2. Terminology ................................................5 + 2.3. Topologies .................................................8 + 3. Motivation ......................................................8 + 3.1. Use Cases ..................................................9 + 3.2. Using the Media Path ......................................11 + 3.3. Using AVPF ................................................11 + 3.3.1. Reliability ........................................12 + 3.4. Multicast .................................................12 + 3.5. Feedback Messages .........................................12 + 3.5.1. Full Intra Request Command .........................12 + 3.5.1.1. Reliability ...............................13 + 3.5.2. Temporal-Spatial Trade-off Request and + Notification .......................................14 + 3.5.2.1. Point-to-Point ............................15 + 3.5.2.2. Point-to-Multipoint Using + Multicast or Translators ..................15 + 3.5.2.3. Point-to-Multipoint Using RTP Mixer .......15 + 3.5.2.4. Reliability ...............................16 + 3.5.3. H.271 Video Back Channel Message ...................16 + 3.5.3.1. Reliability ...............................19 + 3.5.4. Temporary Maximum Media Stream Bit Rate + Request and Notification ...........................19 + 3.5.4.1. Behavior for Media Receivers Using TMMBR ..21 + 3.5.4.2. Algorithm for Establishing Current + Limitations ...............................23 + 3.5.4.3. Use of TMMBR in a Mixer-Based + Multipoint Operation ......................29 + 3.5.4.4. Use of TMMBR in Point-to-Multipoint Using + Multicast or Translators ..................30 + 3.5.4.5. Use of TMMBR in Point-to-Point Operation ..31 + 3.5.4.6. Reliability ...............................31 + 4. RTCP Receiver Report Extensions ................................32 + 4.1. Design Principles of the Extension Mechanism ..............32 + 4.2. Transport Layer Feedback Messages .........................33 + 4.2.1. Temporary Maximum Media Stream Bit Rate + Request (TMMBR) ....................................34 + 4.2.1.1. Message Format ............................34 + 4.2.1.2. Semantics .................................35 + 4.2.1.3. Timing Rules ..............................39 + 4.2.1.4. Handling in Translators and Mixers ........39 + 4.2.2. Temporary Maximum Media Stream Bit Rate + Notification (TMMBN) ...............................39 + 4.2.2.1. Message Format ............................39 + + + +Wenger, et al. Standards Track [Page 2] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + 4.2.2.2. Semantics .................................40 + 4.2.2.3. Timing Rules ..............................41 + 4.2.2.4. Handling by Translators and Mixers ........41 + 4.3. Payload-Specific Feedback Messages ........................41 + 4.3.1. Full Intra Request (FIR) ...........................42 + 4.3.1.1. Message Format ............................42 + 4.3.1.2. Semantics .................................43 + 4.3.1.3. Timing Rules ..............................44 + 4.3.1.4. Handling of FIR Message in Mixers and + Translators ...............................44 + 4.3.1.5. Remarks ...................................44 + 4.3.2. Temporal-Spatial Trade-off Request (TSTR) ..........45 + 4.3.2.1. Message Format ............................46 + 4.3.2.2. Semantics .................................46 + 4.3.2.3. Timing Rules ..............................47 + 4.3.2.4. Handling of Message in Mixers and + Translators ...............................47 + 4.3.2.5. Remarks ...................................47 + 4.3.3. Temporal-Spatial Trade-off Notification (TSTN) .....48 + 4.3.3.1. Message Format ............................48 + 4.3.3.2. Semantics .................................49 + 4.3.3.3. Timing Rules ..............................49 + 4.3.3.4. Handling of TSTN in Mixers and + Translators ...............................49 + 4.3.3.5. Remarks ...................................49 + 4.3.4. H.271 Video Back Channel Message (VBCM) ............50 + 4.3.4.1. Message Format ............................50 + 4.3.4.2. Semantics .................................51 + 4.3.4.3. Timing Rules ..............................52 + 4.3.4.4. Handling of Message in Mixers or + Translators ...............................52 + 4.3.4.5. Remarks ...................................52 + 5. Congestion Control .............................................52 + 6. Security Considerations ........................................53 + 7. SDP Definitions ................................................54 + 7.1. Extension of the rtcp-fb Attribute ........................54 + 7.2. Offer-Answer ..............................................55 + 7.3. Examples ..................................................56 + 8. IANA Considerations ............................................58 + 9. Contributors ...................................................60 + 10. Acknowledgements ..............................................60 + 11. References ....................................................60 + 11.1. Normative References .....................................60 + 11.2. Informative References ...................................61 + + + + + + + +Wenger, et al. Standards Track [Page 3] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + +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 experience of the conversational video + conferencing industry suggests that there is a need for a few + additional feedback messages, to support centralized multipoint + 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] bit strings for Video Back + Channel messages. + + In 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 [RFC3550]. These topologies are documented in + [RFC5117], and understanding this memo requires previous or parallel + study of [RFC5117]. + + Some of the messages defined here are forward only, in that they do + not require an explicit notification to the message emitter that they + have been received and/or indicating the message receiver's actions. + Other messages require a response, leading to a two-way communication + model that one could view as useful for control purposes. However, + it is not the intention of this memo to open up RTP Control Protocol + (RTCP) to a generalized control protocol. All mentioned messages + have relatively strict real-time constraints, in the sense that their + value diminishes with increased delay. This makes the use of more + traditional control protocol means, such as Session Initiation + Protocol (SIP) [RFC3261], undesirable when used for the same purpose. + That is why this solution is recommended instead of "XML Schema for + Media Control" [XML-MC], which uses SIP Info to transfer XML messages + with similar semantics to what are defined in this memo. + Furthermore, all messages are of a very simple format that can be + easily processed by an RTP/RTCP sender/receiver. Finally, and most + importantly, all messages relate only to the RTP stream with which + they are associated, and not to any other property of a communication + system. In particular, none of them relate to the properties of the + access links traversed by the session. + + + + +Wenger, et al. Standards Track [Page 4] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + +2. Definitions + +2.1. Glossary + + AIMD - Additive Increase Multiplicative Decrease + AVPF - The extended RTP profile for RTCP-based feedback + FCI - Feedback Control Information [RFC4585] + FEC - Forward Error Correction + FIR - Full Intra Request + MCU - Multipoint Control Unit + MPEG - Moving Picture Experts Group + PLI - Picture Loss Indication + PR - Packet rate + QP - Quantizer Parameter + RTT - Round trip time + SSRC - Synchronization Source + TMMBN - Temporary Maximum Media Stream Bit Rate Notification + TMMBR - Temporary Maximum Media Stream Bit Rate Request + TSTN - Temporal-Spatial Trade-off Notification + TSTR - Temporal-Spatial Trade-off Request + VBCM - Video Back Channel Message + +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]. + + + +Wenger, et al. Standards Track [Page 5] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + Decoder Refresh Point: + A bit string, packetized in one or more RTP packets, that + 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 subjected 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, etc.) to identify the content of the forward + RTP packet stream (carrying the codec data), to which the + codec control message applies. + + + + + + +Wenger, et al. Standards Track [Page 6] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + 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 (e.g., below 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 quality of service + (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 + + + +Wenger, et al. Standards Track [Page 7] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + 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 [RFC5117] for an in-depth discussion. The topologies + referred to throughout this memo are labeled (consistently with + [RFC5117]) as follows: + + Topo-Point-to-Point . . . . . Point-to-point communication + Topo-Multicast . . . . . . . Multicast communication + Topo-Translator . . . . . . . Translator based + Topo-Mixer . . . . . . . . . Mixer based + Topo-RTP-switch-MCU . . . . . RTP stream switching MCU + Topo-RTCP-terminating-MCU . . Mixer but terminating RTCP + +3. Motivation + + This section discusses the motivation and usage of the different + video and media control messages. The video control messages have + been under discussion for a long time, and a requirement document was + drawn up [Basso]. That document has expired; however, we quote + relevant sections of it to provide motivation and requirements. + + + + + +Wenger, et al. Standards Track [Page 8] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + +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 from the remote source, in order to avoid using + unrelated content as reference data for inter picture prediction. + After requesting the 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 decoder + refresh point. At that time, the 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 higher frame rate and + a lower spatial quality, and another user may prefer the opposite. + This choice is also highly content dependent. Many current video + conferencing systems offer in the user interface a mechanism to + make this selection, usually in the form of a slider. The + mechanism is helpful in point-to-point, centralized multipoint and + non-centralized multipoint uses. + + 4. Use case 4 of the Basso document applies only to Picture Loss + Indication (PLI) as defined in AVPF [RFC4585] and is not + reproduced here. + + 5. Use case 5 of the Basso document 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 this memo, and the use case discussion is not + reproduced here. + + + + +Wenger, et al. Standards Track [Page 9] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + 6. A video mixer dynamically selects one of the received video + streams to be sent out to participants and tries to provide the + highest bit rate possible to all participants, while minimizing + stream trans-rating. One way of achieving this is to set up + sessions with endpoints using the maximum bit rate accepted by + each endpoint, and accepted by the call admission method used by + the mixer. By means of commands that reduce the maximum media + stream bit rate below what has been negotiated during session set + up, the mixer can reduce the maximum bit rate sent by endpoints to + the lowest of all the accepted bit rates. As the lowest accepted + bit rate changes due to endpoints joining and leaving or due to + network congestion, the mixer can adjust the limits at which + endpoints can send their streams to match the new value. The + mixer then requests a new maximum bit rate, which is equal to or + less than the maximum bit rate negotiated at session setup for a + specific media stream, and the remote endpoint can respond with + the actual bit rate that it can support. + + The picture Basso, et al., draw up covers most applications we + foresee. However, we would like to extend the list with two + additional use cases: + + 7. Currently deployed congestion control algorithms (AIMD and TCP + Friendly Rate Control (TFRC) [RFC3448]) probe for additional + available capacity as long as there is something to send. With + congestion control algorithms using packet loss as the indication + for congestion, this probing generally results in reduced media + quality (often to a point where the distortion is large enough to + make the media unusable), due to packet loss and increased delay. + + In a number of deployment scenarios, especially cellular ones, the + bottleneck link is often the last hop link. That cellular link + also commonly has some type of QoS negotiation enabling the + cellular device to learn the maximal bit rate available over this + last hop. A media receiver behind this link can, in most (if not + all) cases, calculate at least an upper bound for the bit rate + available for each media stream it presently receives. How this + is done is an implementation detail and not discussed herein. + Indicating the maximum available bit rate to the transmitting + party for the various media streams can be beneficial to prevent + that party from probing for bandwidth for this stream in excess of + a known hard limit. For cellular or other mobile devices, the + known available bit rate for each stream (deduced from the link + bit rate) can change quickly, due to handover to another + transmission technology, QoS renegotiation due to congestion, etc. + To enable minimal disruption of service, quick convergence is + necessary, and therefore media path signaling is desirable. + + + + +Wenger, et al. Standards Track [Page 10] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + 8. The use of reference picture selection (RPS) as an error + resilience tool was introduced in 1997 as NEWPRED [NEWPRED], and + is now widely deployed. When RPS is in use, simplistically put, + the receiver can send a feedback message to the sender, + indicating a reference picture that should be used for future + prediction. ([NEWPRED] mentions other forms of feedback as + well.) AVPF contains a mechanism for conveying such a message, + but did not specify for which codec and according to which syntax + the message should conform. Recently, the ITU-T finalized Rec. + H.271, which (among other message types) also includes a feedback + message. It is expected that this feedback message will fairly + quickly enjoy wide support. Therefore, a mechanism to convey + feedback messages according to H.271 appears to be desirable. + +3.2. Using the Media Path + + There are two reasons why we use the media path for the codec control + messages. + + First, systems employing MCUs often separate the control and media + processing parts. As these messages are intended for or 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 + MCU is physically decomposed, the use of the media path avoids the + need for media control protocol extensions (e.g., in media gateway + control (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 their complex and more generic nature may + result in significant processing delay. The topological locations of + the signaling entities are also commonly not optimized for minimal + delay, but rather towards other architectural goals. Thus, the + signaling path can be significantly longer in both geographical and + delay sense. + +3.3. Using AVPF + + The AVPF feedback message framework [RFC4585] provides the + appropriate framework to implement the new messages. AVPF 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. + + + + + +Wenger, et al. Standards Track [Page 11] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + The signaling setup for AVPF allows each individual type of function + to be 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 this specification have different + requirements in terms 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 specified in [RFC3550] and [RFC4585] ensure that the + messages do not cause overload of the RTCP connection. The use of + multicast may result in the reception of messages with 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 Full Intra Request (FIR) Command, when received by the designated + media sender, requires that the media sender sends a Decoder Refresh + Point (see section 2.2) at the earliest opportunity. The evaluation + of such an opportunity includes the current encoder coding strategy + and the current available network resources. + + FIR is also known as an "instantaneous decoder refresh request", + "fast video update request" or "video fast update request". + + Using a decoder refresh point implies refraining from using any + picture sent prior to that point as a reference for the encoding + process of any subsequent picture sent in the stream. For predictive + media types that are not video, the analogue applies. For example, + if in MPEG-4 systems scene updates are used, the decoder refresh + point consists of the full representation of the scene and is not + delta-coded relative to previous updates. + + + + + + + + +Wenger, et al. Standards Track [Page 12] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + 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 use of a + decoder refresh point implies a delay that is significantly longer + than the typical picture duration. + + Usage in multicast is possible; however, aggregation of the commands + is recommended. A receiver that receives a request closely after + sending a decoder refresh point -- within 2 times the longest round + trip time (RTT) known, plus any AVPF-induced RTCP packet sending + delays -- should await a second request message to ensure that the + media receiver has not been served by the previously delivered + decoder refresh point. The reason for the 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 other request avoids this + issue. + + Using the FIR command to recover from errors is explicitly + disallowed, and instead the PLI message defined in AVPF [RFC4585] + should be used. The PLI message reports lost pictures and has been + included in AVPF for precisely that purpose. + + Full Intra Request is applicable in use-cases 1 and 2. + +3.5.1.1. Reliability + + The FIR message results in the delivery of a decoder refresh point, + unless the message is lost. Decoder refresh points are easily + identifiable from the bit stream. Therefore, there is no need for + protocol-level notification, and a simple command repetition + mechanism is sufficient for ensuring the level of reliability + required. However, the potential use of repetition does require a + mechanism to prevent the recipient from responding to messages + already received and responded to. + + To ensure the best possible reliability, a sender of FIR may repeat + the FIR until the desired content has been received. The repetition + interval is determined by the RTCP timing rules applicable to the + session. Upon reception of a complete decoder refresh point or the + detection of an attempt to send a decoder refresh point (which got + damaged due to a packet loss), the repetition of the FIR must stop. + If another FIR is necessary, the request sequence number must be + increased. A FIR sender shall not have more than one FIR (different + request sequence number) outstanding at any time per media sender in + the session. + + + + +Wenger, et al. Standards Track [Page 13] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + The receiver of FIR (i.e., the media sender) behaves in complementary + fashion to ensure delivery of a decoder refresh point. If it + receives repetitions of the FIR more than 2*RTT after it has sent a + decoder refresh point, it shall send a new decoder refresh point. + Two round trip times allow time for the decoder refresh point to + arrive back to the requestor and for the end of repetitions of FIR to + reach and be detected by the media sender. + + An RTP mixer or RTP switching MCU that receive a FIR from a media + receiver is responsible to ensure that a decoder refresh point is + delivered to the requesting receiver. It may be necessary for the + mixer/MCU to generate FIR commands. From a reliability perspective, + the two legs (FIR-requesting endpoint to mixer/MCU, and mixer/MCU 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 video + encoder to change its trade-off between temporal and spatial + resolution. Index values from 0 to 31 indicate monotonically a + desire for higher frame rate. That is, a requester asking for an + index of 0 prefers a high quality and is willing to accept a low + frame rate, whereas a requester asking 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 the typical picture duration. See use case 3 for an example. + The encoder decides whether and to what extent the request results in + a change of the trade-off. It returns a Temporal-Spatial Trade-off + Notification (TSTN) message to indicate the 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 allow for a reasonable user experience. + Consider, for example, a user interface where the remote user selects + the temporal/spatial trade-off with a slider. An immediate feedback + to any slider movement is required for a reasonable user experience. + A SIP re-INVITE [RFC3261] would require at least two round-trips more + (compared to the 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 the new trade-off is finally selected. + Furthermore, the use of RTCP solves the multicast use case very + efficiently. + + The use of TSTR and TSTN in multipoint scenarios is a non-trivial + subject, and can be achieved in many implementation-specific ways. + + + +Wenger, et al. Standards Track [Page 14] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + Problems stem from the fact that TSTRs will typically arrive + unsynchronized, and may request different trade-off values for the + same stream and/or endpoint encoder. This memo does not specify a + translator's, mixer's, or endpoint's reaction to the reception of a + suggested trade-off as conveyed in the TSTR. We only require the + receiver of a TSTR message to reply to it by sending a TSTN, carrying + the new trade-off chosen by its own criteria (which may or may not be + based on the trade-off conveyed by the TSTR). In other words, the + trade-off sent in a TSTR is a non-binding recommendation, nothing + more. + + Three TSTR/TSTN scenarios need to be distinguished, based on the + topologies described in [RFC5117]. The scenarios are described in + the following subsections. + +3.5.2.1. Point-to-Point + + In this most trivial case (Topo-Point-to-Point), the 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 new trade-off value (which may be identical + to the old one if, for example, 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 media multicast according to + 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 certain participants, + or continuing to use the previously selected trade-off (e.g., when + the sender is not capable of adjusting it). Again, all TSTR messages + need to be acknowledged by TSTN, and the value conveyed back has 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 has the opportunity to act on them based on its own + criteria. In most cases, the mixer should form a "consensus" of + potentially conflicting TSTR messages arriving from different + participants, and initiate its own TSTR message(s) to the media + sender(s). As in the previous scenario, the strategy for forming + + + + +Wenger, et al. Standards Track [Page 15] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + this "consensus" is up to the implementation, and can, for example, + encompass averaging the participants' request values, giving priority + to certain participants, or using session default values. + + Even if a mixer or translator performs transcoding, it is very + difficult to deliver media with the requested trade-off, unless the + content the mixer or translator receives is already close to that + trade-off. Thus, if the mixer changes its trade-off, it needs to + request the media sender(s) to use the new value, by creating a TSTR + of its own. Upon reaching a decision on the used trade-off, it + includes that value in the acknowledgement to the downstream + requestors. Only in cases where the original source has + substantially higher quality (and bit rate) is it likely that + transcoding alone can result in the requested trade-off. + +3.5.2.4. Reliability + + A request and reception acknowledgement mechanism is specified. The + Temporal-Spatial Trade-off Notification (TSTN) message informs the + requester that its request has been received, and what trade-off is + used henceforth. This acknowledgement mechanism is desirable for at + least the following reasons: + + o A change in the trade-off cannot be directly identified from the + media bit stream. + o User feedback cannot be implemented without knowing the chosen + trade-off value, according to the media sender's constraints. + o Repetitive 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. The structure defined in + this memo is used to transparently convey such a message from media + receiver to media sender. In this memo, we refrain from an in-depth + discussion of the available code points within H.271 and refer to the + specification text [H.271] instead. + + However, we note that some H.271 messages bear similarities with + native messages of AVPF and this memo. Furthermore, we note that + some H.271 message are known to require caution in multicast + environments -- or are plainly not usable in multicast or multipoint + scenarios. Table 1 provides a brief, simplified overview of the + messages currently defined in H.271, their roughly corresponding AVPF + or Codec Control Messages (CCMs) (the latter as specified in this + memo), and an indication of our current knowledge of their multicast + safety. + + + +Wenger, et al. Standards Track [Page 16] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + 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 and their AVPF/CCM equivalents + + Note: H.271 message type 0 is not a strict equivalent to + AVPF's Reference Picture Selection Indication (RPSI); it is an + indication of known-as-correct reference picture(s) at the + decoder. It does not command an encoder to use a defined + reference picture (the form of control information envisioned + to be carried in RPSI). However, it is believed and intended + 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 the opaqueness of the H.271 messages, especially with + respect to the multicast safety, the following guidelines MUST be + followed when an implementation wishes to employ the H.271 video back + channel message: + + 1. Implementations utilizing the H.271 feedback message MUST stay in + compliance with congestion control principles, as outlined in + section 5. + + 2. An implementation SHOULD utilize the IETF-native messages 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 to divert from + the SHOULD statement above would be if it is clearly understood + that, for a given application and video compression standard, the + aforementioned "similarity" is not given, in contrast to what the + table indicates. + + 3. It has been observed that some of the H.271 code points currently + in existence are not multicast-safe. Therefore, the sensible + thing to do is not to use the H.271 feedback message type in + multicast environments. It MAY be used only when all the issues + mentioned later are fully understood by the implementer, and + properly taken into account by all endpoints. In all other cases, + the H.271 message type MUST NOT be used in conjunction with + multicast. + + + +Wenger, et al. Standards Track [Page 17] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + 4. It has been observed that even in centralized multipoint + environments, where the mixer should theoretically be able to + resolve issues as documented below, the implementation of such a + 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 issues mentioned below are + fully understood by the 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 identical at any given point in time. The most obvious reason + for such a possible misalignment of state is a loss that occurs on + the path to only one of many media receivers. However, there are + other not so obvious reasons, such as recent joins to the + multipoint conference (be it by joining the multicast group or + through additional mixer output). Different states can lead the + media receivers to issue potentially contradicting H.271 messages + (or one media receiver issuing an H.271 message that, when + observed by the media sender, is not helpful for the other media + receivers). A naive reaction of the media sender to these + contradicting messages can lead to unpredictable and annoying + results. + + 2. Combining messages from different media receivers in a media + sender is 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 algorithm for + combining must be aware both of the network/protocol environment + (i.e., with respect to congestion) and of 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 to go beyond the basic + mechanisms described in AVPF (which are driven exclusively by + timing and transport considerations on the protocol level). For + example, a receiver is often required to refrain from (or delay) + generating requests, based on information it receives from the + media stream. For instance, it makes no sense for a receiver to + issue a FIR when a transmission of an Intra/IDR picture is + ongoing. + + + + + + +Wenger, et al. Standards Track [Page 18] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + 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 will likely be forced to 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 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 reception of a message can be + derived from the forward video bit stream. Therefore, no specific + reception acknowledgement is specified. + + With respect to re-sending rules, section 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") to request a sender to + limit the maximum bit rate for a media stream (see section 2.2) to, + or below, the provided value. The Temporary Maximum Media Stream Bit + Rate Notification (TMMBN) contains the media sender's current view of + the most limiting subset of the TMMBR-defined limits it has received, + to help the participants to suppress TMMBRs that would not further + restrict the media sender. The primary usage for the TMMBR/TMMBN + messages is in a 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 + tuple. The first component of the tuple is the maximum total media + bit rate (as defined in section 2.2) that the media receiver is + currently prepared to accept for this media stream. The second + component is the per-packet overhead that the media receiver has + observed for this media stream at its chosen reference protocol + layer. + + As indicated in section 2.2, the overhead as observed by the sender + of the TMMBR (i.e., the media receiver) may differ from the overhead + observed at the receiver of the TMMBR (i.e., the media sender) due to + use of a different reference protocol layer at the other end or due + to the intervention of translators or mixers that affect the amount + of per packet overhead. For example, a gateway in between the two + that converts between IPv4 and IPv6 affects the per-packet overhead + by 20 bytes. Other mechanisms that change the overhead include + tunnels. The problem with varying overhead is also discussed in + + + +Wenger, et al. Standards Track [Page 19] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + [RFC3890]. As will be seen in the description of the algorithm for + use of TMMBR, the difference in perceived overhead between the + sending and receiving ends presents no difficulty because + calculations are carried out in terms of variables that have the same + value at the sender as at the receiver -- for example, packet rate + and net media rate. + + Reporting both maximum total media bit rate and per-packet overhead + allows different receivers to provide bit rate and overhead values + for different protocol layers, for example, at the IP level, at the + outer part of a tunnel protocol, or at the link layer. The protocol + level a peer reports on depends on the level of integration the peer + has, as it needs to be able to extract the information from that + protocol level. For example, an application with no knowledge of the + IP version it is running over cannot meaningfully determine the + overhead of the IP header, and hence will not want to include IP + overhead in the overhead or maximum total media bit rate calculation. + + It is expected that most peers will be able to report values at least + for the IP layer. In certain implementations, it may be advantageous + to also include information pertaining to the link layer, which in + turn allows for a more precise overhead calculation and a better + optimization of connectivity resources. + + The Temporary Maximum Media Stream Bit Rate messages 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 types or payload + formats. The TMMBR functionality applies to the transport, and the + requirements the transport places on the media encoding. + + The reasoning below assumes that the participants have negotiated a + session maximum bit rate, using a signaling protocol. This value can + be global, for example, in case of point-to-point, multicast, or + translators. It may also be local between the participant and the + peer or mixer. In either case, the bit rate negotiated in signaling + is the one that the participant guarantees to be able to handle + (depacketize and 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 also beneficial to have negotiated a maximum packet rate for + the session or sender. RFC 3890 provides an SDP [RFC4566] attribute + that can be used for this purpose; however, that attribute is not + usable in RTP sessions established using offer/answer [RFC3264]. + Therefore, an optional maximum packet rate signaling parameter is + specified in this memo. + + + +Wenger, et al. Standards Track [Page 20] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + An already established maximum total media bit rate may be changed at + any time, subject to the timing rules governing the sending of + feedback messages. The limit may change to any value between zero + and the session maximum, as negotiated during session establishment + signaling. However, even if a sender has received a TMMBR message + allowing an increase in the bit rate, all increases must be governed + by a congestion control mechanism. TMMBR indicates known limitations + only, usually in the local environment, and does not provide any + guarantees about the full path. Furthermore, any increases in + TMMBR-established bit rate limits are to be executed only after a + certain delay from the sending of the TMMBN message that notifies the + world about the increase in limit. The delay is specified as at + least twice the longest RTT as known by the media sender, plus the + media sender's calculation of the required wait time for the sending + of another TMMBR message for this session based on AVPF 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 the session, the TMMBR sender is expected to + 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 informal description of behaviour described more + precisely in section 4.2. + + A media sender begins the 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 reference protocol layer, forms an estimate of the + overhead it is observing (or estimating it if no packets has been + seen yet) at that reference level, and determines the 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 current limitations are more restricting than what was agreed on + in the session signaling, the media receiver reports its initial + estimate of these two quantities to the media sender using a TMMBR + message. Overall message traffic is reduced by the possibility of + including tuples for multiple media senders in the same TMMBR + message. + + The media sender applies an algorithm such as that specified in + section 3.5.4.2 to select which of the tuples it has received are + most limiting (i.e., the bounding set as defined in section 2.2). It + modifies its operation to stay within the feasible region (as defined + + + +Wenger, et al. Standards Track [Page 21] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + in section 2.2), and also sends out a TMMBN to the media receivers + indicating the selected bounding set. That notification also + indicates who was responsible for the tuples in the bounding set, + i.e., the "owner"(s) of the limitation. A session participant that + owns no tuple in the bounding set is called a "non-owner". + + If a media receiver does not own one of the tuples in the bounding + set reported by the TMMBN, it applies the same algorithm as the media + sender to determine if its current estimated (maximum total media bit + rate, overhead) tuple would enter the bounding set if known to the + media sender. If so, it issues a TMMBR reporting the tuple value to + the sender. Otherwise, it takes no action for the moment. + Periodically, its estimated tuple values may change or it may receive + a new TMMBN. If so, it reapplies the algorithm to decide whether it + needs to issue a TMMBR. + + If, alternatively, a media receiver owns one of the tuples in the + reported bounding set, it takes no action until such time as its + estimate of its own tuple values changes. At that time, it sends a + TMMBR to the media sender to report the changed values. + + A media receiver may change status between owner and non-owner of a + bounding tuple between one TMMBN message and the next. Thus, it must + check the contents of each TMMBN to determine its subsequent actions. + + Implementations may use other algorithms of their choosing, as long + as the bit rate limitations resulting from the exchange of TMMBR and + TMMBN messages are at least as strict (at least as low, in the bit + rate dimension) as the ones resulting from the use of the + aforementioned algorithm. + + Obviously, in point-to-point cases, when there is only one media + receiver, this receiver becomes "owner" once it receives the first + TMMBN in response to its own TMMBR, and stays "owner" for the rest of + the session. Therefore, when it is known that there will always be + only a single media receiver, the above algorithm is not required. + Media receivers that are aware they are the only ones in a session + can send TMMBR messages with bit rate limits both higher and lower + than the previously notified limit, at any time (subject to the AVPF + [RFC4585] RTCP RR send timing rules). However, it may be difficult + for a session participant to determine if it is the only receiver in + the session. Because of this, any implementation of TMMBR is + required to include the algorithm described in the next section or a + stricter equivalent. + + + + + + + +Wenger, et al. Standards Track [Page 22] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + +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 calculation is at least as restrictive as the result + that is obtained by this algorithm. + + First, it is important to consider the implications of using a tuple + for limiting the media sender's behavior. The bit rate and the + overhead value result in a two-dimensional solution space for the + calculation of the bit rate of media streams. Fortunately, the two + variables are linked. Specifically, the bit rate available for RTP + payloads is equal to the TMMBR reported bit rate minus the packet + rate used, multiplied by the TMMBR reported overhead converted to + bits. As a result, when different bit rate/overhead combinations + need to 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 limiting one for this packet rate. However, at a + certain PR there is a switchover point at which receiver B becomes + the limiting one. The switchover point can be identified by setting + Max_media_BR_A equal to 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 the numbers above, yields 31.25 as the switchover point + between the two limits. That is, for packet rates below 31.25 per + second, receiver A is the limiting receiver, and for higher packet + rates, receiver B is more limiting. The implications of this + behavior have to be considered by implementations that are going to + + + +Wenger, et al. Standards Track [Page 23] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + 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 + packet rate being considered. + + This also has implications for how the TMMBR mechanism needs to work. + First, there is the possibility that multiple TMMBR tuples are + providing limitations on the media sender. Secondly, there is a need + for any session participant (media sender and receivers) to be able + to determine if a given tuple will become a limitation upon the media + sender, or if the set of already given limitations is stricter than + the given values. In the absence of the ability to make this + determination, the suppression of TMMBRs would not work. + + The basic idea of the algorithm is as follows. Each TMMBR tuple can + be viewed as the equation of a straight line (cf. equations (1) and + (2)) in a space where packet rate lies along the X-axis and net bit + rate along the Y-axis. The lower envelope of the set of lines + corresponding to the complete set of TMMBR tuples, together with the + X and Y axes, defines a polygon. Points lying within this polygon + are combinations of packet rate and bit rate that meet all of the + TMMBR constraints. The highest feasible packet rate within this + region is the minimum of the rate at which the bounding polygon meets + the X-axis or the session maximum packet rate (SMAXPR, measured in + packets per second) provided by signaling, if any. Typically, a + media sender will prefer to operate at a lower rate than this + theoretical maximum, so as to increase the rate at which actual media + content reaches the receivers. The purpose of the algorithm is to + distinguish the TMMBR tuples constituting the bounding set and thus + delineate the feasible region, so that the media sender can select + its preferred operating point within that 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 trade-offs between media + rate and packet rate. The line labeled ss..s represents the limit on + packet rate imposed by the session maximum packet rate (SMAXPR) + obtained by signaling during session setup. In Figure 1, the limit + determined by tuple B happens to be more restrictive than SMAXPR. + The situation could easily be the reverse, meaning that the bounding + polygon is terminated on the right by the vertical line representing + the SMAXPR constraint. + + + + + + + + + +Wenger, et al. Standards Track [Page 24] + +RFC 5104 Codec Control Messages in AVPF February 2008 + + + Net ^ + Media|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 canonical form: + + y = mx + b + + where + m is the slope and has value equal to the negative of the tuple + overhead (in bits), + and + b is the y-intercept and has value equal to the tuple maximum + total media bit rate. + + These observations lead to the conclusion that when processing the + TMMBR tuples to select the initial bounding set, one should sort and + process the tuples by order of increasing overhead. Once a + particular tuple has been added to the bounding set, all tuples not + already selected and having lower overhead can be eliminated, because + the next side of the bounding polygon has to be steeper (i.e., the + corresponding TMMBR must have higher overhead) than the 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 tuple contains a higher maximum total media bit + rate value. Since line cc..c is outside the bounding polygon, it + + + +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] + |