Network Working Group Stephan Wenger
INTERNET-DRAFT Umesh Chandra
Expires: April 2006 Nokia
Magnus Westerlund
Bo Burman
Ericsson
October 24, 2005
Codec Control Messages in the
Audio-Visual Profile with Feedback (AVPF)
draft-wenger-avt-avpf-ccm-01.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 Full Intra Request, Temporary Maximum Media
Bit-rate and Temporal Spatial Tradeoff.
Wenger, Chandra, Westerlund [Page 1]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
TABLE OF CONTENTS
1. Introduction....................................................4
2. Definitions.....................................................5
2.1. Glossary...................................................5
2.2. Terminology................................................5
2.3. Topologies.................................................7
2.3.1. Point to Point........................................7
2.3.2. Point to Multi-point using Multicast..................8
2.3.3. Point to Multipoint using relaying MCU................8
2.3.4. Point to Multipoint using content modifying MCU.......9
2.3.5. Combining Topologies..................................9
3. Motivation (Informative).......................................10
3.1. Use Cases.................................................10
3.2. Using the Media Path......................................12
3.3. Using AVPF................................................12
3.3.1. Reliability..........................................13
3.4. Multicast.................................................13
3.5. Feedback Messages.........................................13
3.5.1. Full Intra Request Command...........................13
3.5.1.1. Reliability.....................................14
3.5.2. Freeze Request Indication............................14
3.5.3. Temporal Spatial Tradeoff Request and Acknowledgement 15
3.5.3.1. Point-to-point..................................16
3.5.3.2. Point-to-Multipoint using multicast or relaying MCU16
3.5.3.3. Point-to-Multipoint using content modifying MCU.17
3.5.3.4. Reliability.....................................17
3.5.4. Temporary Maximum Media Bit-rate Request and Acknowledgement
............................................................17
3.5.4.1. MCU based Multi-point operation.................18
3.5.4.2. Point-to-Multipoint using Multicast or relaying MCU20
3.5.4.3. Point-to-point operation........................20
3.5.4.4. Reliability.....................................20
4. RTCP Receiver Report Extensions................................20
4.1. Design Principles of the Extension Mechanism..............21
4.2. Transport Layer Feedback Messages.........................21
4.2.1. Temporary Maximum Media Bit-rate Request (TMMBR).....22
4.2.1.1. Semantics.......................................22
4.2.1.2. Message Format..................................23
4.2.1.3. Timing Rules....................................24
4.2.2. Temporary Maximum Media Bit-rate Acknowledgement (TMMBA) 24
4.2.2.1. Semantics.......................................24
4.2.2.2. Message Format..................................25
4.2.2.3. Timing Rules....................................25
4.3. Payload Specific Feedback Messages........................25
4.3.1. Full Intra Request (FIR).............................26
4.3.1.1. Semantics.......................................26
4.3.1.2. Message Format..................................28
4.3.1.3. Timing Rules....................................28
4.3.1.4. Remarks.........................................29
Wenger, Chandra, Westerlund Standards Track [Page 2]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
4.3.2. Temporal-Spatial Tradeoff Request (TSTR).............29
4.3.2.1. Semantics.......................................29
4.3.2.2. Message Format..................................29
4.3.2.3. Timing Rules....................................30
4.3.2.4. Remarks.........................................30
4.3.3. Temporal-Spatial Tradeoff Acknowledgement (TSTA).....31
4.3.3.1. Semantics.......................................31
4.3.3.2. Message Format..................................31
4.3.3.3. Timing Rules....................................32
4.3.3.4. Remarks.........................................32
4.3.4. Freeze Indication..........Error! Bookmark not defined.
4.3.4.1. Semantics.............Error! Bookmark not defined.
4.3.4.2. Message Format........Error! Bookmark not defined.
4.3.4.3. Timing Rules..........Error! Bookmark not defined.
4.3.4.4. Remarks...............Error! Bookmark not defined.
5. Congestion Control.............................................32
6. Security Considerations........................................32
7. SDP Definitions................................................33
7.1. Extension of rtcp-fb attribute............................33
7.2. Offer-Answer..............................................34
7.3. Examples..................................................35
8. IANA Considerations............................................36
9. Open Issues....................................................37
10. Acknowledgements..............................................37
11. References....................................................38
11.1. Normative references.....................................38
11.2. Informative references...................................38
12. Authors' Addresses............................................38
12. List of Changes relative to previous draft....................39
13................................................................39
Wenger, Chandra, Westerlund Standards Track [Page 3]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
1. Introduction
When the Audio-Visual Profile with Feedback (AVPF) [AVPF] was
developed, the main emphasis lied 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). MCUs comprise mixers and translators (in RTP [RFC3550]
terminology), but also signalling support. Long standing experience
of the conversational video conferencing industry suggests that there
is a need for a few additional feedback messages, to efficiently
support MCU-based multipoint conferencing. Some of the messages have
applications beyond centralized multipoint, and this is indicated in
the description of the message.
Some of the messages defined here are forward only, in that they do
not require an explicit acknowledgement. Other messages require
acknowledgement, leading to a two way communication model that could
suggest to some to be useful for control purposes. It is not the
intention of this memo to open up the use of RTCP to generalized
control protocol functionality. All mentioned messages have
relatively strict real-time constraints and are of transient nature,
which make the use of more traditional control protocol means, such
as SIP re-invites, undesirable. Furthermore, all messages are of a
very simple format that can be easily processed by an RTP/RTCP
sender/receiver. Finally, all messages infer only to the RTP stream
they are related to, and not to any other property of a communication
system.
The Full Intra Request (FIR) Command requires the receiver of the
message (and sender of the stream) to immediately insert a decoder
refresh point (e.g. an IDR/Intra picture). In order to fulfil
congestion control constraints, this may imply a significant drop in
frame rate, as decoder refresh points are commonly much larger than
regular predicted pictures. The use of this message is restricted to
cases where no other means of decoder refresh can be employed, e.g.
during the join-phase of a new participant in a multipoint
conference. It is explicitly disallowed to use the FIR command for
error resilience purposes, and instead it is referred to AVPF's PLI
message, which reports lost pictures and has been included in AVPF
for that purpose. The message does not require an acknowledgement,
as the presence of a decoder refresh point can be easily derived from
the media bit stream. Today, the FIR message appears to be useful
primarily with video streams, but in the future it may become helpful
also in conjunction with other media codecs that support temporal
prediction across RTP packets.
Wenger, Chandra, Westerlund Standards Track [Page 4]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
The Temporary Maximum Media Bandwidth Request (TMMBR) Message allows
to signal, from media receiver to media sender, the current maximum
supported media bit-rate for a given media stream. The message is
acknowledged by its receiver. One usage scenarios comprises limiting
media senders in multiparty conferencing to the slowest receiver's
maximum media bandwidth reception/handling capability (the receiver's
situation may have changed due to computational load, or it may be
that the receiver has just joined the conference). Another
application involves graceful bandwidth adaptation in scenarios where
the upper limit connection bandwidth to a receiver changes but is
known in the interval between these dynamic changes. The TMMBR
message is useful for all media types that are not inherently of
constant bit rate.
Finally, the Temporal-Spatial Tradeoff Request (TSTR) Message enables
a video receiver to signal to the video sender its preference for
spatial quality or high temporal resolution (frame rate). The
receiver of the video stream generates this signal typically based on
input from its user interface, so to react to explicit requests of
the user. However, some implicit use forms are also known. For
example, the trade-offs commonly used for live video and document
camera content are different. Obviously, this indication is relevant
only with respect to video transmission. The message is acknowledged
so to allow immediate user feedback.
2. Definitions
2.1. Glossary
ASM - Asynchronous Multicast
AVPF - The Extended RTP Profile for RTCP-based Feedback
FEC - Forward Error Correction
FIR - Full Intra Request
MCU - Multipoint Control Unit
MPEG - Moving Picture Experts Group
PtM - Point to Multipoint
PtP - Point to Point
TMMBA - Temporary Maximum Media Bit-rate Acknowledgement
TMMBR - Temporary Maximum Media Bit-rate Request
PLI - Picture Loss Indication
TSTA - Temporal Spatial Tradeoff Acknowledgement
TSTR - Temporal Spatial Tradeoff Request
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].
Wenger, Chandra, Westerlund Standards Track [Page 5]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
Message:
Codepoint defined by this specification, of one of the
following types:
Request:
Message that requires Acknowledgement
Acknowledgment:
Message that answers a Request
Command:
Message that forces the receiver to an action
Indication:
Message that reports a situation
Note that this terminology is in alignment with ITU-T Rec. H.245.
Decoder Refresh Point:
A bit string, packetised in one or more RTP packets, which
completely resets the decoder to a known state. Typical
examples of Decoder Refresh Points are H.261 Intra pictures
and H.264 IDR pictures. However, there are also much more
complex decoder refresh points.
Typical examples for "hard" decoder refresh points are Intra
pictures in H.261, H.263, MPEG 1, MPEG 2, and MPEG-4 part 2,
and IDR pictures in H.264. "Gradual" decoder refresh points
may also be used; see for example [11]. 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 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).
To the best of the author's knowledge, the term "Decoder
Refresh Point" has been formally defined only in H.264; hence
we are referring here to this video compression standard.
Decoding:
The operation of reconstructing the media stream.
Wenger, Chandra, Westerlund Standards Track [Page 6]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
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 performed in a media
aware fashion implying that the media packets are removed in
the order of their relevance to the reproductive quality.
However even when employing media-aware stream thinning, most
media streams quickly lose quality when subject to increasing
levels of thinning. Media-unaware stream thinning leads to
even worse quality degradation.
2.3. Topologies
This subsection defines four basic topologies that are relevant for
codec control. Further topologies can be constructed by combining
them, see Section 2.3.5.
2.3.1. Point to Point
The Point to Point (PtP) topology (Figure 1) is the simplest and
consists of two end-points with unicast capabilities between them.
+---+ +---+
| A |<------->| B |
+---+ +---+
Figure 1 - Point to Point
The main properties of this topology is that A send to B and only B,
while B send to A and only A. This avoids all complexities of
handling multiple participants and combining the requirements from
them.
Wenger, Chandra, Westerlund Standards Track [Page 7]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
2.3.2. Point to Multi-point using Multicast
+-----+
+---+ / \ +---+
| A |--- / \---| B |
+---+ / Multi- \ +---+
+ Cast +
+---+ \ Network / +---+
| C |----\ /---| D |
+---+ \ / +---+
+-----+
Figure 2 - Point to Multipoint using Multicast
The Point to Multipoint (PtM) using multicast topology is defined as
the transmission from any participant to reach all the other
participants (unless packet loss occurs). The number of participants
can be one or many. However this draft is primarily interested in the
subset of multicast session where the number of participants in the
multicast group allows the participants to use early or immediate
feedback as defined in AVPF. This document refers to those groups as
as "small multicast groups".
2.3.3. Point to Multipoint using relaying MCU
+---+ +------------+ +---+
| A |------| Multipoint |------| B |
+---+ | Control | +---+
| Unit |
+---+ | (MCU) | +---+
| C |------| |------| D |
+---+ +------------+ +---+
Figure 3 - Point to Multipoint using relaying MCU
The PtM using relaying MCU is defined such that each participant uses
unicast traffic between itself and the MCU. The MCU relays that
traffic to all other participants. This relaying is performed for all
media traffic and RTCP control traffic. However, the MCU may also
originate RTCP control traffic to control the session or report on
status as it sees it.
In this usage the codec control messages are conveyed transparently
to the media-transmitting participant for handling. The MCU does not,
by itself, take action on the control messages it relayes.
Wenger, Chandra, Westerlund Standards Track [Page 8]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
2.3.4. Point to Multipoint using content modifying MCU
+---+ +------------+ +---+
| A |<---->| Multipoint |<---->| B |
+---+ | Control | +---+
| Unit |
+---+ | (MCU) | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 4 - Point to Multipoint using content modifying MCU
In a PtM scenario using a content modifying MCU, each participant
runs a point-to-point session between itself and the MCU. The content
that the MCU provides to each participant is either:
a) A selection of the content received from the other participants.
b) The mixed aggregate of what the MCU receives from the other PtP
links, which are part of the same conference session.
In case a) the MCU may modify the content in bit-rate, encoding,
resolution; however it still indicates the original sender of the
content.
In case b) the MCU is the content source as it mixes the content and
then encodes it for transmission to a participant. The participant's
content that is included in the aggregated content is indicated
through the RTP CSRC field.
In both scenarios, the MCU is responsible for receiving the codec
control messages and handle them appropriately. In some cases, the
reception of a codec control message may result in the generation and
transmission of codec control messages by the MCU to some or all of
the other participants.
Mixing forms of the two scenarios are possible. An MCU may
transparently relay some codec control messages and intercept,
modify, and (when appropriate) generate codec control messages of its
own and transmit them to the media senders.
2.3.5. Combining Topologies
An MCU can be used to combine the different topologies depending on
what is most suitable or possible. Different combinations that are
possible (non exhaustive):
- Employing a relaying MCU to allow participants without multicast
capabilities to join a PtM Multicast session. The MCU joins the
Wenger, Chandra, Westerlund Standards Track [Page 9]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
multicast group as one participant of the multicast group. The MCU
relays all traffic received on the multicast address to the
participant using unicast. It also forwards the unicast
participant's traffic to the multicast group.
- Utilizing an MCU session that employs both transcoding and mixing,
depending on participant and network capabilities. Due to limited
bandwidth, processing capabilities, etc, the MCU can perform
transcoding of content to what is suitable for some participants,
while others receive unmodified, relayed traffic.
3. Motivation (Informative)
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 draft was
drawn up [Basso]. This draft has expired; however we do quote
relevant parts out of that draft to provide motivation and
requirements.
3.1. Use Cases
There are a number of possible usages for the proposed feedback
messages. Let's begin with looking through the use cases Basso et al.
[Basso] proposed. Some of the use cases have been reformulated and
commented:
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 that 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 a request of
change of the desired tradeoff in temporal/spatial resolution.
For example, one user may prefer a higher frame rate and a lower
Wenger, Chandra, Westerlund Standards Track [Page 10]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
spatial quality, and another use 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 draft applies only to AVPF's PLI and is
not reproduced here.
5. A video mixer switches its output stream to a new video source,
similar to use case 2. The video mixer instructs the receiving
endpoints by means of a freeze message to complete the decoding of
the current picture and then freezing the picture (stop rendering
but continue decoding), until the freeze picture request is
released. The freeze picture release codepoint is a mechanism that
can be selected on a per picture basis and can be conveyed in-band
in most video coding standards. Concurrently, the video mixer
request a decoder refresh point from the new video source and
immediately switches to the new source. Once the new source
receives the request for the reference picture and acts on it, it
produces a decoder refresh point with an embedded Freeze-Release.
Once having received the decoder refresh point with the freeze
release information, the receiving endpoints restart rendering and
displays an uncorrupted new picture. The main benefit of this
method as opposed to the one of use case 2 is that the video mixer
does not have to discover the beginning of a decoder refresh
point.
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 transrating. One way of achieving this is to setup sessions
with endpoints using the maximum bit rate accepted by that
endpoint, and by the call admission method used by the mixer. By
means of commands that allow reducing the maximum media bitrate
beyond what has been negotiated during session setup, the mixer
can then reduce the maximum bit rate sent by endpoints to the
lowest common denominator of all received streams. As the lowest
common denominator changes due to endpoints joining, leaving, or
network congestion, the mixer can adjust the limits to which
endpoints can send their streams to match the new limit. The mixer
then would request a new maximum bit rate, which is equal 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 draws up covers most applications we
foresee. However we would like to extend the list with one additional
use case:
Wenger, Chandra, Westerlund Standards Track [Page 11]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
7. The used congestion control algorithms (AMID and TFRC) probe for
more bandwidth as long as there is something to send. With
congestion control using packet-loss as the indication for
congestion, this probing does generally result 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. Thus indicating the maximum available bit-rate to the
transmitting part can be beneficial to prevent it from even trying
to exceed the known hard limit that exists. For cellular or other
mobile devices the available known bit-rate can also quickly
change due to handover to another transmission technology, QoS
renegotiation due to congestion, etc. To enable minimal disruption
of service a possibility for quick convergence, especially in
cases of reduced bandwidth, a media path signalling method is
desired.
3.2. Using the Media Path
There are multiple reasons why we propose to use the media path for
the messages. First, systems employing MCUs are usually separating
the control and media processing parts. As these messages are
intended or generated by the media processing rather than the
signalling part of the MCU, having them on the media path avoids
interfaces and unnecessary control traffic between signalling and
processing. If the MCU is physically decomposite, the use of the
media path avoids the need for media control protocol extensions
(e.g. in MEGACO).
Secondly, the signalling path quite commonly contains several
signalling entities, e.g. SIP-proxies and application servers.
Avoiding signalling 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
signalling entities are also commonly not optimized for minimal
delay, rather other architectural goals. Thus the signalling path can
be significantly longer in both geographical and delay sense.
3.3. Using AVPF
The AVPF feedback message framework provides a simple way of
implementing the new messages. Furthermore, AVPF implements rules
controlling the timing of feedback messages so to avoid congestion
through network flooding, which are re-used by reference.
Wenger, Chandra, Westerlund Standards Track [Page 12]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
The signalling setup for AVPF allows each individual type of function
to be configured or negotiated on a 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 media related requests might be used with multicast. The RTCP
timing rules specified in [RTP] and [AVPF] ensure that the messages
do not cause overload of the RTCP connection. Inconsistent messages
arriving at the RTP sender from different receivers are more
problematic when multicast is employed. 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 that applies 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 2.2) at the earliest opportunity. The evaluation of such
opportunity includes the current encoder coding strategy and the
current available network resources.
FIR is also known as an "instantaneous decoder refresh request" or
"video fast update request".
Using a decoder refresh point implies refraining from using any
picture sent prior to that point as a reference for the encoding
process of any subsequent picture sent in the stream. For predictive
media types that are not video, the analogon applies.
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 bandwidth is small, the use of a
decoder refresh point implies a delay that is significantly longer
than the typical picture duration.
Wenger, Chandra, Westerlund Standards Track [Page 13]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
Usage in multicast is possible; however aggregation of the commands
is recommended. A receiver that receives a request closely (within
2*RTT) after sending a decoder refresh point should await a second
request message to ensure that the media receiver has not been served
by the previously delivered decoder refresh point.
Full Intra Request is applicable in use-case 1, 2, and 5.
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. Therfore, there is no need for
protocol-level acknowledgement, 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 request until a response has been received. The repetition
interval is determined by the RTCP timing rules the session operates
under. 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. To combat loss of the decoder refresh points sent, the
sender that receives repetitions of the FIR 2 RTT after the
transmission of the decoder refresh point shall send a new decoder
refresh point. A FIR sender shall not have more than one FIR request
(different request sequence number) outstanding at any time per media
sender in the session.
A content modifying MCU that receives an FIR from a media receiver is
responsible to ensure that a decoder refresh point is delivered to
the requesting receiver. Due to a participants request it may be
necessary for the MCU to generate FIR commands itself. These two legs
are handled independently of each other from a reliability
perspective.
3.5.2. Freeze Request Indication
The Freeze Request Indication instructs the video decoder to complete
the decoding of the current video picture and subsequently display it
until either a timeout period has elapsed, or until the reception of
a signal (in band in the video stream) that indicates the release of
the frozen picture. Note that a freeze picture release signal is part
of the at least the H.261, H.263 and H.264 video coding
Wenger, Chandra, Westerlund Standards Track [Page 14]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
specifications. Coding schemes that support picture freeze release in
their bitstreams are required to use freeze release to signal the
remote end to resume decoding.
Historically, the freeze indication has been used in MCUs according
to use case 5. Nowadays, most MCUs operate media aware and simply
stop sending media data of the old stream, at a defined picture
boundary. The new stream is spliced in at a decoder refresh point.
Hence, for modern MCUs, the Freeze indication is of much less
relevance.
However, a mechanism known as gradual decoder refresh may make the
Freeze indication attractive again. Using a gradual decoder refresh,
a new user can join a conference by listening in to a sequence of
pictures (spanning a perhaps a second of video), which are guaranteed
to gradually refresh for a complete reference picture. The
associated problems in the video encoding are non-trivial, but
solvable, and applications exist where they have been solved
successfully. In order to shield the user from the slow and annoying
gradual built-up of the picture, a stop of the rendering is
desirable. The freeze picture indication can serve for this purpose
(although other, more complex means (that may involve control
protocols) may also be available.
Usage of RTCP feedback messages for indication of Freeze Request
Indication has one substantial issue. The late delivery of a Freeze
request will usually result in annoying picture artifacts that will
remain in a frozen picture until freeze release happens.
Ideally, the freeze indication requires synchronous delivery with the
media data. The only obvious solution we found (apart from pushing
the problem to the media coding standardization) appears to somehow
splice the freeze request into the forward media stream. Such a
possibility exist using header extensions [Singer].
Due to isssue with performing Freeze Request in RTCP and the
possibility to perform it in the media path it will not be specified
in this document.
3.5.3. Temporal Spatial Tradeoff Request and Acknowledgement
The Temporal Spatial Tradeoff 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. 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 if the request
results in a change of the trade off. An acknowledgement process has
been defined to provide feedback of the tradeoff that is used
henceforth.
Wenger, Chandra, Westerlund Standards Track [Page 15]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
Informative note: TSTR and TSTA 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
tradeoff with a slider (as it is common in state-of-the-art video
conferencing systems). An immediate feedback to any slider
movement is required for a reasonable user experience. A SIP re-
invite would require at least 2 round-trips more (compared to the
TSTR/TSTA mechanism, and may involve proxies and other complex
mechanisms. Even in a well-designed system, it may take a second
or so until finally the new tradeoff is selected.
Furthermore the use of RTCP solves very efficiently the multicast
use case.
The use of TSTR and TSTA in multipoint scenarios is a non-trivial
subject, and can be solved in many implementation specific ways.
Problems are stemming from the fact that TSTRs will typically arrive
unsynchronized, and may request different tradeoff values for the
same stream and/or endpoint encoder. This memo does not specify a
Mixer's or endpoint's behaviour to the suggested tradeoff as conveyed
in the TSTR -- we only require the receiver of a TSTR message to
reply to it by sending a TSTA, carrying the new tradeoff chosen by
its own criteria (which may or may not be based on the tradeoff
conveyed by TSTR). In other words, the tradeoff sent in TSTR is a
non-binding recommendation; nothing more.
With respect to TSTR/TSTA, four scenarios based on the topologies in
section 2.3 needs to be distinguished. The scenarios are described in
the following sub-clauses.
3.5.3.1. Point-to-point
In this most trivial case, the media sender typically adjusts its
temporal/spatial tradeoff based on the requested value in TSTR, and
within its capabilities. The TSTA message conveys back the new
tradeoff value (which may be identical to the old one if, for
example, the sender is not capable to adjust its tradeoff).
3.5.3.2. Point-to-Multipoint using multicast or relaying MCU
The problem here lies in the fact that TSTR messages from different
receivers may be received unsynchronized, and possibly with different
requested tradeoffs (because of different user preferences). It is
not specified here, and open to the implementation, how the media
sender is tuning its tradeoff. One possible strategy would be to
select the mean, or median, of all tradeoff requests received.
Another would be to prioritize certain participants, for example
Wenger, Chandra, Westerlund Standards Track [Page 16]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
session moderators, and hence their input treated as of higher
importance. Again, all TSTR messages need to be acknowledged by
TSTA, and the value conveyed back has to reflect the decision made.
3.5.3.3. Point-to-Multipoint using content modifying MCU
In this scenario the MCU receives the TSTR message from a
participant. As the MCU can receive multiple requests from different
participants, it needs to determine the future tradeoff for the whole
session. This can be implemented in several ways, e.g. by averging
the participants requests, prioritizing certain participants, or use
session default values. If the MCU changes its tradeoff, it needs to
request from the media sender(s) the use the new value, by creating a
TSTR of its own. Upon reaching a decision on the used tradeoff it
includes that value in the acknowledgement.
Even if a MCU performs transcoding, it is very difficult to deliver
media with the requested tradeoff, unless the content the MCU
receives is already close to that tradeoff. Only in cases where the
original source has substantially higher bit-rate, it is likely that
transcoding can result in requested trade-off.
3.5.3.4. Reliability
A request and reception acknowledgement mechanism is specified. The
Temporal Spatial Tradeoff Acknowledge (TSTA) message informs the
request-sender that its request has been received, and what tradeoff
is used henceforth. This acknowledgment mechanism is desirable for at
least the following reasons:
o A change in the tradeoff cannot be directly identified from the
media bit stream,
o User feedback cannot be implemented without information of the
chosen tradeoff value, according to the media sender's constraints,
o Repetitive sending of messages requesting an unimplementable
tradeoff can be avoided.
3.5.4. Temporary Maximum Media Bit-rate Request and Acknowledgement
A receiver or MCU uses the Temporary Maximum Media Bit-rate Request
(TMMBR, "timber") to request a sender to limit the maximum bit-rate
for a media stream to, or below, the provided value. The primary
usage for this is a scenario with MCU (use case 6), corresponding to
topologies in 2.3.3 (relaying MCU) and 2.3.4 (content modifying MCU),
but also 2.3.1 (point-to-point).
The temporary maximum media bit-rate messages are generic messages
that can be applied to any media.
Wenger, Chandra, Westerlund Standards Track [Page 17]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
The reasoning below assumes that the participants have negotiated a
session maximum bit-rate, using the signalling protocol. This value
can be global, for example in case of point-to-point, multicast, or
relaying MCUs. It may also be local between the participant and the
MCU, in case of content modifying MCUs. In both cases, the bit-rate
negotiated in signalling is the one that the participant guarantees
to be able to handle (encode and decode). In practice, the
connectivity of the participant also bears an influence to the
negotiated value -- it does not necessarily make much sense to
negotiate a media bit rate that one's network interface does not
support.
An already established temporary bit-rate value may be changed at any
time (subject to the timing rules of the feedback message sending),
and to any value between zero and the session maximum, as negotiated
during signalling. Even if a sender has received a TMMBR message
increasing the bit-rate, all increases must be goverend by a
congesiton control algorithm. TMMBR only indicates known limitations,
usually in the local environement, and does not provide any
guarantees.
When it is likely that the new bit-rate indicated by TMMBR will be
valid for the remainder of the session, the TMMBR sender can perform
a renegotiation of the session upper limit using the session
signalling protocol.
3.5.4.1. MCU based Multi-point operation
Assume a small multipart conference is ongoing, as depicted in Figure
3 of 2.3.3 or Figure 4 of 2.3.4. All participants (A-D) have
negotiated a common maximum bit-rate that this session can use. The
conference operates over a number of unicast links between the
participants and the MCU. The congestion situation on each of these
links can easily be monitored by the participant in question and by
the MCU, utilizing, for example, RTCP Receiver Reports. However, any
given participant has no knowledge of the congestion situation of the
connections to the other participants. Worse, without mechanisms
similar to the ones discussed in this draft, the MCU (who is aware of
the congestion situation on all connections it manages) has no
standardized means to inform participants to slow down, short of
forging receiver reports (which is undesirable). In principle, an
MCU confronted with such a situation is obliged to thin or transcode
streams intended for connections that detected congestion.
In practice, stream thinning - if done media aware - is unfortunately
a very difficult and cumbersome operation and adds undesirable delay.
If done media unaware, it leads very quickly to unacceptable
reproduced media quality. Hence, means to slow down senders even in
Wenger, Chandra, Westerlund Standards Track [Page 18]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
the absence of congestion on their connections to the MCU are
desirable.
To allow the MCU to perform congestion control on the individual
links, without performing transcoding, there is a need for a
mechanism that enables the MCU to request the participant's media
encoders to limit their maximum media bit-rate currently used. The
MCU handles the detection of a congestion state between itself and a
participant as follows:
1. Start thinning the media traffic to the supported bit-rate.
2. Use the TMMBR to request the media sender(s) to reduce the media
bit-rate sent by them to the MCU, to a value that is in compliance
with congestion control principles for the slowest link. Slow
refers here to the available bandwidth and packet rate after
congestion control.
3. As soon as the bit-rate has been reduced by the sending part, the
MCU stops stream thinning implicitly, because there is no need for
it any more as the stream is in compliance with congestion
control.
Above algorithms may suggest to some that there is no need for the
TMMBR - it should be sufficient to solely rely on stream thinning.
As much as this is desirable from a network protocol designer's
viewpoint, it has the disadvantage that it doesn't work very
well - the reproduced media quality quickly becomes unusable.
It appears to be a reasonable compromise to rely on stream thinning
as an immediate reaction tool to combat congestions, and have a quick
control mechanism that instructs the original sender to reduce its
bitrate.
Note also that the standard RTCP receiver report cannot serve for the
purpose mentioned. In an environment with content modifying MCU, the
RTCP RR is being sent between the RTP receiver in the endpoint and
the RTP sender in the MCU only - as there is no multicast
transmission. The stream that needs to be bandwidth-reduced,
however, is the one between the original sending endpoint and the
MCU. This endpoint doesn't see the aforementioned RTCP RRs, and
hence needs explicitly informed about desired bandwidth adjustments.
In this topology it is the MCU's responsibility to aggregate the
different bit-rates, which the different links may support, into the
bit rate requested. This aggregation may also take into account that
the MCU may contain certain transcoding capabilities (as in 2.3.4),
which can be employed for those few of the session participants that
have the lowest available bit-rates. It is the MCU's responsibility
to take into consideration the multiple max media bit rates, which it
learns from the receivers, and select the lowest of those bit rate
values. The MCU may also support certain transcoding capabilities,
which can be employed for some of the receivers so as not to reduce
Wenger, Chandra, Westerlund Standards Track [Page 19]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
the conference bit rate to a lowest common denominator, which would
affect the user experience of all users.
3.5.4.2. Point-to-Multipoint using Multicast or relaying MCU
In this topology, RTCP RRs are transmitted globally which allows for
the detection of transmission problems such as congestion, on a
medium timescale. As all media senders are aware of the congestion
situation of all media receivers, the rationale of the use of TMMBR
of section 3.5.4.1 does not apply. However, even in this case the
congestion control response can be improved when the unicast links
are employing congestion controlled transport protocols (such as TCP
or DCCP).
3.5.4.3. Point-to-point operation
In use case 7 it is possible to use TMMBR to improve the performance
at times of changes in the known upper limit of the bit-rate. In
this use case the signalling protocol has established an upper limit
for the session and media bit-rates. However at the time of
transport link bit-rate reduction, a receiver could avoid serious
congestion by sending a TMMBR to the sending side.
3.5.4.4. Reliability
A request and reception acknowledgement mechanism is required.
Temporary Maximum Media Bit-rate Acknowledgement (TMMBA) is used to
allow the TMMBR sender to know that the recipient has received the
request. This is desirable behaviour as the result of TMMBR is not
immediately identifiable through inspection of the media stream.
Unless acknowledged, it can be expected that multiple TMMBR will be
sent in an attempt to limit the probability of congestion and
degraded media quality.
4. RTCP Receiver Report Extensions
This memo specifies 5 new feedback messages. The Full Intra Request
(FIR), Temporal-Spatial Tradeoff Request (TSTR), and Temporal-Spatial
Tradeoff Acknowledgement (TSTA) are "Payload Specific Feedback
Messages" in the sense of section 6.3 of AVPF [AVPF]. The Temporary
Maximum Media Bit-rate Request (TMMBR) and Temporary Maximum Media
Bit-rate Acknowledgement (TMMBA) are "Transport Layer Feedback
Messages" in the sense of section 6.2 of AVPF.
In the following subsections, the new feedback messages are defined,
following a similar structure as in the AVPF specification's sections
6.2 and 6.3, respectively.
Wenger, Chandra, Westerlund Standards Track [Page 20]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
4.1. Design Principles of the Extension Mechanism
RTCP was originally introduced as a channel to convey presence,
reception quality statistics and hints on the desired media coding.
A limited set of media control mechanisms have been introduced in
early RTP payload formats for video formats, for example in RFC 2032
[RFC2032]. However, this specification, for the first time, suggests
a two-way handshake for two of its messages. There is danger that
this introduction could be misunderstood as the precedence for the
use of RTCP as an RTP session control protocol. In order to prevent
these misunderstandings, this subsection attempts to clarify the
scope of the extensions specified in this memo, and strongly suggests
that future extensions follow the rationale spelled out here, or
compellingly explain why they divert from the rationale.
In this memo, and in AVPF [AVPF], only such messages have been
included which
a) have comparatively strict real-time constraints, that 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
c) are directly related to activities of a certain media codec, class
of media codecs (e.g. video codecs), or the given media stream.
In this memo, a two-way handshake is only introduced for such
messages that
a) require an acknowledgement due to their nature, which is motivated
separately for each message
b) the acknowledgement cannot be easily derived from the media bit
stream.
All messages in AVPF [AVPF] and in this memo follow a number of
common design principles. In particular:
a) Media receivers are not always implementing higher control
protocol functionalities (SDP, XML parsers and such) in their
media path. Therefore, simple binary representations are used in
the feedback messages and not an (otherwise desirable) flexible
format such as, for example, XML.
4.2. Transport Layer Feedback Messages
Wenger, Chandra, Westerlund Standards Track [Page 21]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
Transport Layer FB messages are identified by the value RTPFB (205)
as RTCP packet type.
In AVPF, one message of this category had been defined. This memo
specifies two more messages for a total of three messages of this
type. They are identified by means of the FMT parameter as follows:
0: unassigned
1: Generic NACK (as per AVPF)
2: Maximum Media Bit-rate Request
3: Maximum Media Bit-rate Acknowledgement
4-30: unassigned
31: reserved for future expansion of the identifier number space
The following subsection defines the formats of the FCI field for
this type of FB message.
4.2.1. Temporary Maximum Media Bit-rate Request (TMMBR)
The FCI field of a TMMBR Feedback message MUST contain one or more
FCI entries.
4.2.1.1. Semantics
The TMMBR is used to indicate the highest bit-rate per sender of a
media, which the receiver currently supports in this RTP session.
The media sender MAY use any lower bit-rate, as it may need to
address a congestion situation or other limiting factors. See
section 5 (congestion control) for more discussions.
The "SSRC of the packet sender" field indicates the source of the
request, and the "SSRC of media source" is not used and SHALL be set
to 0. The SSRC of media sender in the FCI field denotes the media
sender the message applies to. This is useful in the multicast or
relay MCU topologies. The above mentioned requirement implies that a
receiver desiring to set a maximum bit-rate to all active media
sender must address them all individually (which can be done in a
single or in multiple TMMBR requests).
A TMMBR message MAY be repeated if no TMMBA has been received at the
time of transmission of the next RTCP packet. A repeated TMMBR
request SHALL NOT change any of the SSRC or FCI fields of the request
relative to the first transmission with the same sequence number. A
TMMBR sender MAY change a value of the request prior to receving a
TMMBA, however, in this case it SHALL increment the sequence number.
Please note that the media sender's state is now undetermined in
regards to the set maximum bit-rate until a TMMBA is received at the
media receiver.
Wenger, Chandra, Westerlund Standards Track [Page 22]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
TMMBR feedback SHOULD NOT be used if the underlying transport
protocol is capable of providing similar feedback information from
the receiver to the sender.
It also important to consider the security risks involved with faked
TMMBRs. See security considerations in Section 6.
The feedback messages may be used in both multicast and unicast
sessions of any of the specified topologies. However the need for
TMMBR in multicast and relaying MCU usage is limited and the
operation is not optimized for these cases.
If multiple maximum bit-rates are set by different media recievers in
a given session, where the media is common to all the receivers (for
example multicast), then the sender SHOULD set its sending bit rate
to the lowest value received. For sessions with a larger number of
participants using the lowest common denominator may not be the most
suitable course of action. Larger session may need to consider other
ways to support adapted bit-rate to participants, such as partioning
the session in different quality tiers, or use some other method of
achieving bit-rate scalability.
If the value set by a TMMBR message is expected to be permanent the
TMMBR setting party is RECOMMENDED to renegotiate the session
parameters to reflect that using the setup signalling.
4.2.1.2. Message Format
The Feedback control information (FCI) consist 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq. nr | Maximum bit-rate in units of 128 bits/s |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - Syntax for the TMMBR message
SSRC: The SSRC value of the target of this specific maximum bit-
rate request.
Seq. nr: Request sequence number. The sequence number space is
unique for each tuple consisting 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
Wenger, Chandra, Westerlund Standards Track [Page 23]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
request. A repetition SHALL NOT increase the sequence
number. Initial value is arbitary.
Maximum bit-rate: The temporary maximum media bit-rate value in
units of 128 bit/s. This provides range from 0 to
2147483647 bits/s (~2.15 Gbit/s) with a resolution of 128
bits/s.
The length of the FB message is be set to 2+2*N where N is the number
of TMMBR FCI entries.
4.2.1.3. Timing Rules
The first transmission of the request message MAY use early or
immediate feedback in cases when timeliness is desirable. Any
repetition of a request message SHOULD use regular RTCP mode for its
transmission timing.
4.2.2. Temporary Maximum Media Bit-rate Acknowledgement (TMMBA)
The FCI field of the TMMBA Feedback message SHALL contain one or more
TMMBA FCI entries.
4.2.2.1. Semantics
This feedback message is used to acknowledge the reception of a
TMMBR. It SHALL be sent for each TMMBR targeted to this receiver,
i.e. for each TMMBR received in which the "SSRC" field in a TMMBR FCI
entry is identical to the receiving entities SSRC. The
acknowledgement SHALL be sent also for any recevied request, even if
the request is repeated. If each recevied request didn't generate a
acknowledgement then no reliability against losses of acknowledgement
would exist.
The TMMBA feedback message's "SSRC of packet sender" SHALL be set to
the SSRC of the acknowledger. The "SSRC of media source" is not used
and SHALL be set to 0.
The receiver of TMMBR messages can acknowledge one or more TMMBR
message in the same TMMBA feedback message. The FCI entry's SSRC
field identifies the sender of the TMMBR requests, and the sequence
number identifies which particular request, that is being
acknowledged. The media sender SHALL acknowledge only the highest
sequence number (modulo 256) if serveral TMMBR request with different
sequence numbers has been received from the same SSRC.
Wenger, Chandra, Westerlund Standards Track [Page 24]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
4.2.2.2. Message Format
The TMMBA Feedback control information (FCI) entry has 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq. nr | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - Syntax for the TMMBA message
SSRC: The SSRC of the source of the TMMBR request that is
acknowledged.
Seq. nr: The sequence number value from the TMMBR request that is
being acknowledged.
Reserved: All bits SHALL be set to 0 and SHALL be ignored on
reception.
The length field value of the FB message SHALL be 2+2*N, where N is
the number of TMMBA FCI entries.
4.2.2.3. Timing Rules
The acknowledgement SHOULD be sent as soon as allowed by the applied
timing rules for the session. Immediate or early feedback mode MAY be
used for these messages.
4.3. Payload Specific Feedback Messages
Payload-Specific FB messages are identified by the value PT=PSFB
(206) as RTCP packet type.
AVPF defines three payload-specific FB messages and one application
layer FB message. This memo specifies three additional payload
specific feedback messages. All are identified by means of the FMT
parameter as follows:
0: unassigned
1: Picture Loss Indication (PLI)
2: Slice Lost Indication (SLI)
3: Reference Picture Selection Indication (RPSI)
Wenger, Chandra, Westerlund Standards Track [Page 25]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
4: Full Intra Request Command (FIR)
5: Temporal-Spatial Tradeoff Request (TSTR)
6: Temporal-Spatial Tradeoff Acknowledgement (TSTA)
7-14: unassigned
15: Application layer FB message
16-30: unassigned
31: reserved for future expansion of the sequence number space
The following subsections define the new FCI formats for the payload-
specific FB messages.
4.3.1. Full Intra Request (FIR) command
The FIR command FB message is identified by PT=PSFB and FMT=4.
There MUST be one or more FIR entry contained in the FCI field.
4.3.1.1. Semantics
Upon reception of a FIR message, an encoder MUST send a decoder
refresh point (see Section 2.2) as soon as possible.
Note: Currently, video appears to be the only useful application
for FIR, as it appears to be the only RTP payloads 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, 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 here.
Note: In environments where the sender has no control over the
codec (e.g. when streaming pre-recorded and pre-coded content), the
reaction to this command cannot be specified. One suitable
reaction of a sender would be to skip forward in the video bit
stream to the next decoder refresh point. In other scenarios, it
may be preferable not to react to the command at all, e.g. when
streaming to a large multicast group. Other reactions may also be
possible. When deciding on a strategy, a sender could take into
account factors such as the size of the receiving multicast 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 others.
Wenger, Chandra, Westerlund Standards Track [Page 26]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
However the usage of FIR in a session which predominately handles
pre-coded content shouldn't use the FIR at all.
The sender MUST consider congestion control as outlined in section 5,
which MAY restrict its ability to send a decoder refresh point
quickly.
Note: The relationship between the Picture Loss Indication and FIR
is as follows. As discussed in section 6.3.1 of AVPF, a Picture
Loss Indication informs the decoder about the loss of a picture and
hence the likeliness of misalignment of the reference pictures in
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 an encoder has is to send a decoder refresh point. However,
there are other options including ignoring the PLI, for example if
only one receiver of many has sent a PLI or when 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 disallows the encoder to take any
considerations such as the ones mentioned above into account.
Note: Mandating a maximum delay for completing the sending of a
decoder refresh point would be desirable from an application
viewpoint, but may be problematic from a congestion control point
of view. "As soon as possible" as mentioned above appears to be a
reasonable compromise.
FIR SHALL NOT be sent as a reaction to picture losses - it is
RECOMMENDED to use PLI instead. FIR SHOULD be used only in such
situations where not sending a decoder refresh point would render the
video unusable for the users.
Note: a typical example where sending FIR is adequate 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 freeze picture request to the
receiver(s), switches the streams, and issues a FIR to the new
sender so to force it to emit a decoder refresh point. The decoder
refresh point includes normally a Freeze Picture Release, which re-
starts the rendering process of the receivers. Both techniques
mentioned are commonly used in MCU-based multipoint conferences.
Other RTP payload specifications such as RFC 2032 [4] 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
Wenger, Chandra, Westerlund Standards Track [Page 27]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
reasons, such an application SHOULD also be capable to receive and
react to the feedback scheme defined in the respective RTP payload
format, if this is required by that payload format.
4.3.1.2. Message Format
Full Intra Request uses one additional FCI field, the content of
which is depicted in Figure 8. The length of the FB message MUST be
set to 3.
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 7 - Syntax for the FIR message
SSRC: The SSRC value of the target of this specific FIR command.
Seq. nr: Command sequence number. The sequence number space is
unique for each tuple consisting of the SSRC of command
source and the SSRC of the command target. The sequence
number SHALL be increased by 1 modulo 256 for each new
command. A repetition SHALL NOT increase the sequence
number. Initial value is arbitary.
Reserved: All bits SHALL be set to 0 and SHALL be ignored on
reception.
The semantics of this FB message is independent of the RTP payload
type.
4.3.1.3. Timing Rules
The timing follows the rules outlined in section 3 of [AVPF]. 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 on RTT before being sent. In
early or regular RTCP mode the repetition is sent in the next regular
RTCP packet.
Wenger, Chandra, Westerlund Standards Track [Page 28]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
4.3.1.4. Remarks
FIR messages typically trigger the sending of full intra or IDR
pictures. Both are several times larger then predicted (inter)
pictures. Their size is independent of the time they are generated.
In most environments, especially when employing bandwidth-limited
links, the use of an intra picture implies an allowed delay that is a
significant multitude 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 inter picture, then a full second of latency
has to be accepted. In such an environment there is no need for a
particular short delay in sending the FIR message. Hence waiting for
the next possible time slot allowed by RTCP timing rules as per
[AVPF] may not have an overly negative impact on the system
performance.
4.3.2. Temporal-Spatial Tradeoff Request (TSTR)
The TSTR FB message is identified by PT=PSFB and FMT=5.
There MUST be one or more TSTR entry contained in the FCI field.
4.3.2.1. Semantics
A decoder can suggest the use of a temporal-spatial tradeoff by
sending a TSTR message to an encoder. If the encoder is capable of
adjusting its temporal-spatial tradeoff, it SHOULD take the received
TSTR message into account for future coded pictures. A value of 0
suggests a high spatial quality and a value of 31 suggests a high
frame rate. The values from 0 to 31 indicate monotonically a desire
for higher frame rate. Actual values do not correspond to precise
values of spatial quality or frame rate.
The reaction to the reception of more than one TSTR messages by a
media sender from different media receivers, but with identical SSRC
and sequence numbers, is left open to the implementation. The
selected tradeoff SHALL be communicated to the media receivers by the
means of the TSTA message.
4.3.2.2. Message Format
The Temporal-Spatial Tradeoff Request uses one additional FCI field,
the content of which is depicted in Figure 8. The length of the FB
message MUST be set to 3.
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
Wenger, Chandra, Westerlund Standards Track [Page 29]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 - Syntax of the TSTR
SSRC: The SSRC value of the target of this specific TSTR request.
Seq. nr: Request sequence number. The sequence number space is
unique for each tuple consisting of the SSRC of request
source and the SSRC of the request target. The sequence
number SHALL be increased by 1 modulo 256 for each new
command. A repetition SHALL NOT increase the sequence
number. Initial value is arbitary.
Index: An integer value between 0 and 31 that indicates the
relative trade off that is requested. An index value of 0
index highest possible spatial quality, while 31 indicates
highest possible temporal resolution.
4.3.2.3. Timing Rules
The timing follows the rules outlined in section 3 of [AVPF]. This
request message is not time critical and SHOULD be sent using regular
RTCP timing.
4.3.2.4. Remarks
The term "spatial quality" does not necessarily refer to the
resolution, measured by the number of pixels the reconstructed video
is using. In fact, in most scenarios the video resolution will
likely stay constant during the lifetime of a session. However, all
video compression standards have means to adjust the spatial quality
at a given resolution, normally referred to as 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, frame
rate, and QP is intentionally left open here, as it depends on
factors such as compression standard employed, spatial resolution,
content, bit rate, and many more.
Wenger, Chandra, Westerlund Standards Track [Page 30]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
4.3.3. Temporal-Spatial Tradeoff Acknowledgement (TSTA)
The TSTA FB message is identified by PT=PSFB and FMT=6.
There SHALL be one or more TSTA contained in the FCI field.
4.3.3.1. Semantics
This feedback message is used to acknowledge the reception of a TSTR.
A TSTA entry in a TSTA feedback message SHALL be sent for each TSTR
entry targeted to this receiver, i.e. each TSTR received that in the
SSRC field in the entry has the receiving entities SSRC. The
acknowledgement SHALL be sent also for repetitions received. If the
request receiver has received TSTR with several different sequence
numbers from a single requestor it SHALL only respond to the request
with the highest (modulo 256) sequence number.
The TSTA SHALL include the Temporal-Spatial Tradeoff index that will
be used as a result of the request. This is not necessary the same
index as requested as media sender may need to aggregate requests
from several requesting session participants. It may also have some
other policies or rules that limits the selection.
4.3.3.2. Message Format
The Temporal-Spatial Tradeoff Acknowledgement uses one additional FCI
field, the content of which is depicted in Figure 9. The length of
the FB message MUST be set to 3.
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. | | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 - Syntax of the TSTA
SSRC: The SSRC of the source of the TMMBR request that is
acknowledged.
Seq. nr: The sequence number value from the TMMBR request that is
being acknowledged.
Index: The tradeoff value the media sender is using henceforth.
Wenger, Chandra, Westerlund Standards Track [Page 31]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
Informative note: The returned tradeoff value (Index) may differ
from the requested one, for example in cases where a media encoder
cannot tune its tradeoff, or when pre-recorded content is used.
4.3.3.3. Timing Rules
The timing follows the rules outlined in section 3 of [AVPF]. This
acknowledgement message is not extremely time critical and SHOULD be
sent using regular RTCP timing.
4.3.3.4. Remarks
None
5. Congestion Control
The correct application of the AVPF timing rules prevents the network
flooding by feedback messages. Hence, assuming a correct
implementation, 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. All
of these modifications MUST only be performed within the bandwidth
limits the applied congestion control provides. For example, when
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 Bit-rate value can only
mitigate congestion, but not cause congestion. An increase of the
value REQUIRES that the value is chosen such that any transmission up
to that value is allowed by the used congestion control mechanism, at
the time of sending. A reduction of the value may result 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 signalling 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
Wenger, Chandra, Westerlund Standards Track [Page 32]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
this type of attack, authentication and integrity protection of the
setup signalling is required.
Spoofing of feedback messages 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. Sending TSTR that result in a video quality different from
the user's desire, rendering the session less useful.
c. Frequent FIR commands will potentially reduce the frame-rate
making the video jerky due to the frequent usage of decoder
refresh points.
To prevent these attacks there is need to apply authentication and
integrity protection of the feedback messages. This can be
accomplished against group external threats using the RTP profile
that combines SRTP [SRTP] and AVPF into SAVPF [SAVPF]. In the MCU
cases separate security contexts and filtering can be applied between
the MCU and the participants thus protecting other MCU users from a
misbehaving participant.
7. SDP Definitions
Section 4 of [AVPF] defines new SDP attributes that are used for the
capability exchange of the AVPF commands and indications, like
Reference Picture selection, Picture loss indication etc. The defined
SDP attribute is known as rtcp-fb and its ABNF is described in
section 4.2 of [AVPF]. In this section we extend the rtcp-fb
attribute to include the commands and indications that are described
in this document for codec control protocol. We also discuss the
Offer/Answer implications for the codec control commands and
indications.
7.1. Extension of rtcp-fb attribute
As described in [AVPF], the rtcp-fb attribute is defined to indicate
the capability of using RTCP feedback. As defined in AVPF 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 [AVPF] for rtcp-fb attribute relating to
payload type, multiple rtcp-fb attributes in a session description
hold for the new feedback messages for codec control defined in this
document.
The ABNF for rtcp-fb attributed as defined in [AVPF] is
Rtcp-fb-syntax = "a=rtcp-fb: " rtcp-fb-pt SP rtcp-fb-val CRLF
Wenger, Chandra, Westerlund Standards Track [Page 33]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
Where rtcp-fb-pt is the payload type and rtcp-fb-val defines the type
of the feedback message such as ack, nack, trr-int and rtcp-fb-id.
For example to indicate the support of feedback of picture loss
indication, the sender declares the following in SDP
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 nack pli
In this document we define a new feedback value type called "ccci"
which indicates the support of codec control commands using RTCP
feedback messages. The "ccci" feedback value should be used with
parameters, which indicates the support of which codec commands the
session would use. In this draft we define three parameters, which
can be used with the ccci feedback value type.
o "fir" indicates the support of Full Intra Request
o "tmmbr" indicates the support of Temporal Maximum Media Bit-rate
o "tstr" indicates the support of temporal spatial tradeoff
request.
In ABNF for rtcp-fb-val defined in [AVPF], there is a placeholder
called rtcp-fb-id to define new feedback types. The ccci is defined
as a new feedback type in this document and the ABNF for the
parameters for ccci are defined here (please refer section 4.2 of
[AVPF] for complete ABNF syntax).
Rtcp-fb-param = SP "app" [SP byte-string]
/ SP rtcp-fb-ccci-param
/ ; empty
rtcp-fb-ccci-param = "ccci" SP ccci-param
ccci-param = "fir" ; Full Intra Request
/ "tmmbr" ; Temporary max media bit rate
/ "tstr" ; Temporal Spatial Trade Off
/ token [SP byte-string]
; for future commands/indications
byte-string = <as defined in section 4.2 of [AVPF]>
7.2. Offer-Answer
Wenger, Chandra, Westerlund Standards Track [Page 34]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
The Offer/Answer [RFC3264] implications to codec control protocol
feedback messages are similar to as described in [AVPF]. The offerer
MAY indicate the capability to support selected codec commands and
indications. The answerer MUST remove all ccci parameters, which it
does not understand or does not wish to use in this particular media
session. The answerer MUST NOT add new ccci parameters in addition to
what has been offered. The answer is binding for the media session
and both offerer and answerer MUST only use feedback messages
negotiated in this way.
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 codec control commands and indications - fir, tstr. The
SDP is carried in a high level signalling protocol like SIP
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Point-to-Point call
c=IN IP4 172.11.1.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 ccci tstr
a=rtcp-fb:98 ccci fir
In the above example the sender when it receives a TSTR message from
the remote party can adjust the trade off as indicated in the RTCP
TSTA feedback message.
Example 2: The following SDP describes a SIP end point joining a
video MCU that is hosting a multiparty video conferencing session.
The participant supports only the FIR (Full Intra Request) codec
control command and it declares it in its session description. The
video MCU can send an FIR RTCP feedback message to this end point
when it needs to send this participants video to other participants
of the conference.
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multiparty Video Call
c=IN IP4 172.11.1.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
Wenger, Chandra, Westerlund Standards Track [Page 35]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
a=rtcp-fb:98 ccci fir
When the video MCU decides to route the video of this participant it
sends an RTCP FIR feedback message. Upon receiving this feedback
message the end point is mandated 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 all the commands and indications of codec control messages.
The offered SDP is
-------------> Offer
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer
c=IN IP4 172.11.1.124
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 ccci tstr
a=rtcp-fb:98 ccci fir
a=rtcp-fb:98 ccci tmmbr
The answerer only wishes to support FIR and TSTO message as the codec
control messages and the answerer SDP is
<---------------- Answer
v=0
o=alice 3203093520 3203093524 IN IP4 host.anywhere.com
s=Offer/Answer
c=IN IP4 189.13.1.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 ccci tstr
a=rtcp-fb:98 ccci fir
8. IANA Considerations
The new value of ccci for the rtcp-fb attribute needs to be
registered with IANA.
Value name: ccci
Long Name: Codec Control Commands and Indications
Reference: RFC XXXX
Wenger, Chandra, Westerlund Standards Track [Page 36]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
For use with ''ccci'' the following values also needs to be
registered.
Value name: fir
Long name: Full Intra Request Command
Usable with: ccci
Reference: RFC XXXX
Value name: tmmbr
Long name: Temporary Maximum Media Bit-rate
Usable with: ccci
Reference: RFC XXXX
Value name: tstr
Long name: temporal Spatial Trade Off
Usable with: ccci
Reference: RFC XXXX
9. Open Issues
As this draft is under development, certain open issues are to be
resolved. Please provide feedback on the following open issues:
1. For the TSTA, should it be possible to indicate both semantic
positive (will take it into account) and negative (request
received but will ignore it) acknowledgement? OR should support
from an end-point only be negotiated at session setup time?
2. How strict transmission rules should different messages have? For
example should the acknowledgement have to be sent using early or
immediate feedback if availalbe? Or is regular RTCP timing
sufficient?
3. "Dave Singer expressed concern that repeating requests does not
always work; might want a method to stop a receiver making
repeated requests to a sender that cannot satisfy them. " Is this
still an issue with the current definitions?
4. TMMA: relay back "chosen" maximum bit rate? Could be helpful
for resource management in receiver.
10. Acknowledgements
The authors would like to thank Andrea Basso, Orit Levin, Nermeen
Ismail for their work on the requirement and discussion draft
[Basso].
Wenger, Chandra, Westerlund Standards Track [Page 37]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
11. References
11.1. Normative references
[AVPF] draft-ietf-avt-rtcp-feedback-11.txt
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
11.2. Informative references
[Basso] A. Basso, et. al., "Requirements for transport of video
control commands", draft-basso-avt-videoconreq-02.txt,
expired Internet Draft, October 2004.
[AVC] Joint Video Team of ITU-T and ISO/IEC JTC 1, Draft ITU-T
Recommendation and Final Draft International Standard of
Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC
14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG and
ITU-T VCEG, JVT-G050, March 2003.
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[Singer] D. Singer, "A general mechanism for RTP Header Extensions,"
draft-ietf-avt-rtp-hdrext-00, Aug 11, 2005.
[RFC2032] Turletti, T. and C. Huitema, "RTP Payload Format for H.261
Video Streams", RFC 2032, October 1996.
[SAVPF] J. Ott, E. Carrara, "Extended Secure RTP Profile for RTCP-
based Feedback (RTP/SAVPF)," draft-ietf-avt-profile-savpf-
02.txt, July, 2005.
Any 3GPP document can be downloaded from the 3GPP webserver,
"http://www.3gpp.org/", see specifications.
12. Authors' Addresses
Stephan Wenger
Nokia Corporation
Wenger, Chandra, Westerlund Standards Track [Page 38]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
P.O. Box 100
FIN-33721 Tampere
FINLAND
Phone: +358-50-486-0637
EMail: Stephan.Wenger@nokia.com
Umesh Chandra
Nokia Research Center
6000 Connection Drive
Irving, Texas 75063
USA
Phone: +1-972-894-6017
Email: Umesh.Chandra@nokia.com
Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm, SWEDEN
Phone: +46 8 7190000
EMail: magnus.westerlund@ericsson.com
Bo Burman
Ericsson Research
Ericsson AB
SE-164 80 Stockholm, SWEDEN
Phone: +46 8 7190000
EMail: bo.burman@ericsson.com
13. List of Changes relative to previous draft
The following changes since draft version 00 has been made:
- The draft is restructured to remove redundancy in text. The
motivation has been cleaned up and should be easier to read.
- Freeze picture has been been removed from this draft for separate
developement if interest exist.
- Added a section on the usage scenarios (topologies) considered in
the document.
- All message formats has been restructured to allow several targets
in a single message for better efficiency when multiple media
senders needs to be sent requests or commands.
- Added "semantic Ack" to the acknowledgement messages
Full Copyright Statement
Wenger, Chandra, Westerlund Standards Track [Page 39]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
Copyright (C) The Internet Society (2005).
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 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 Statement
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wenger, Chandra, Westerlund Standards Track [Page 40]
INTERNET-DRAFT AVPF RTCP-RR Extensions July 11, 2005
RFC Editor Considerations
The RFC editor is requested to replace all occurrences of XXXX with
the RFC number this document receives.
Wenger, Chandra, Westerlund Standards Track [Page 41]