draft-ietf-avt-rtcp-feedback-07.txt   draft-ietf-avt-rtcp-feedback-08.txt 
INTERNET-DRAFT Joerg Ott/Uni Bremen TZI INTERNET-DRAFT Joerg Ott/Uni Bremen TZI
draft-ietf-avt-rtcp-feedback-07.txt Stephan Wenger/TU Berlin draft-ietf-avt-rtcp-feedback-08.txt Stephan Wenger/TU Berlin
Noriyuki Sato/Oki Noriyuki Sato/Oki
Carsten Burmeister/Matsushita Carsten Burmeister/Matsushita
Jose Rey/Matsushita Jose Rey/Matsushita
6 June 2003 31 January 2004
Expires December 2003 Expires July 2004
Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
specific mechanisms). This document defines an extension to the specific mechanisms). This document defines an extension to the
Audio-visual Profile (AVP) that enables receivers to provide, Audio-visual Profile (AVP) that enables receivers to provide,
statistically, more immediate feedback to the senders and thus statistically, more immediate feedback to the senders and thus
allow for short-term adaptation and efficient feedback-based repair allow for short-term adaptation and efficient feedback-based repair
mechanisms to be implemented. This early feedback profile (AVPF) mechanisms to be implemented. This early feedback profile (AVPF)
maintains the AVP bandwidth constraints for RTCP and preserves maintains the AVP bandwidth constraints for RTCP and preserves
scalability to large groups. scalability to large groups.
Table of Contents Table of Contents
1 Introduction...................................................3 1 Introduction.................................................3
1.1 Definitions................................................4 1.1 Definitions.............................................4
1.2 Terminology................................................5 1.2 Terminology.............................................6
2 RTP and RTCP Packet Formats and Protocol Behavior..............6 2 RTP and RTCP Packet Formats and Protocol Behavior............6
3 Rules for RTCP Feedback........................................6 2.1 RTP.....................................................6
3.1 Compound RTCP Feedback Packets.............................6 2.2 Underlying Transport Protocols..........................7
3.2 Algorithm Outline..........................................8 3 Rules for RTCP Feedback......................................7
3.3 Modes of Operation.........................................9 3.1 Compound RTCP Feedback Packets..........................7
3.4 Definitions and Algorithm Overview........................11 3.2 Algorithm Outline.......................................9
3.5 AVPF RTCP Scheduling Algorithm............................13 3.3 Modes of Operation.....................................10
3.5.1 Initialization......................................14 3.4 Definitions and Algorithm Overview.....................12
3.5.2 Early Feedback Transmission.........................14 3.5 AVPF RTCP Scheduling Algorithm.........................15
3.5.3 Regular RTCP Transmission...........................17 3.5.1 Initialization...................................15
3.5.4 Other Considerations................................18 3.5.2 Early Feedback Transmission......................16
3.6 Considerations on the Group Size..........................19 3.5.3 Regular RTCP Transmission........................18
3.6.1 ACK mode............................................19 3.5.4 Other Considerations.............................20
3.6.2 NACK mode...........................................19 3.6 Considerations on the Group Size.......................20
3.7 Summary of decision steps.................................21 3.6.1 ACK mode.........................................20
3.7.1 General Hints.......................................21 3.6.2 NACK mode........................................21
3.7.2 Media Session Attributes............................21 3.7 Summary of decision steps..............................22
4 SDP Definitions...............................................22 3.7.1 General Hints....................................22
4.1 Profile identification....................................22 3.7.2 Media Session Attributes.........................23
4.2 RTCP Feedback Capability Attribute........................22 4 SDP Definitions.............................................23
4.3 RTCP Bandwidth Modifiers..................................26 4.1 Profile identification.................................24
4.4 Examples..................................................26 4.2 RTCP Feedback Capability Attribute.....................24
5 Interworking and Co-Existence of AVP and AVPF Entities........27 4.3 RTCP Bandwidth Modifiers...............................27
6 Format of RTCP Feedback Messages..............................29 4.4 Examples...............................................28
6.1 Common Packet Format for Feedback Messages................30 5 Interworking and Co-Existence of AVP and AVPF Entities......30
6.2 Transport Layer Feedback Messages.........................32 6 Format of RTCP Feedback Messages............................31
6.2.1 Generic NACK........................................32 6.1 Common Packet Format for Feedback Messages.............32
6.2.2 Generic ACK.........................................33 6.2 Transport Layer Feedback Messages......................34
6.3 Payload Specific Feedback Messages........................35 6.2.1 Generic NACK.....................................34
6.3.1 Picture Loss Indication (PLI).......................35 6.2.2 Generic ACK......................................35
6.3.1.1 Semantics...................................35 6.3 Payload Specific Feedback Messages.....................37
6.3.1.2 Message Format..............................36 6.3.1 Picture Loss Indication (PLI)....................37
6.3.1.3 Timing Rules................................36 6.3.1.1 Semantics................................38
6.3.1.4 Remarks.....................................36 6.3.1.2 Message Format...........................38
6.3.2 Slice Lost Indication (SLI).........................37 6.3.1.3 Timing Rules.............................38
6.3.2.1 Semantics...................................37 6.3.1.4 Remarks..................................38
6.3.2.2 Format......................................37 6.3.2 Slice Lost Indication (SLI)......................39
6.3.2.3 Timing Rules................................38 6.3.2.1 Semantics................................39
6.3.2.4 Remarks.....................................38 6.3.2.2 Format...................................39
6.3.3 Reference Picture Selection Indication (RPSI).......39 6.3.2.3 Timing Rules.............................40
6.3.3.1 Semantics...................................39 6.3.2.4 Remarks..................................40
6.3.3.2 Format......................................40 6.3.3 Reference Picture Selection Indication (RPSI)....41
6.3.3.3 Timing Rules................................40 6.3.3.1 Semantics................................41
6.4 Application Layer Feedback Messages.......................41 6.3.3.2 Format...................................42
7 Early Feedback and Congestion Control.........................41 6.3.3.3 Timing Rules.............................42
8 Security Considerations.......................................42 6.4 Application Layer Feedback Messages....................43
9 IANA Considerations...........................................44 7 Early Feedback and Congestion Control.......................43
10 Acknowledgements..............................................47 8 Security Considerations.....................................44
11 Authors' Addresses............................................48 9 IANA Considerations.........................................46
12 Bibliography..................................................48 10 Acknowledgements.............................................50
12.1 Normative references.....................................48 11 Authors' Addresses...........................................50
12.2 Informative References...................................49 12 Bibliography.................................................51
13 IPR Notice....................................................50 12.1 Normative references...................................51
14 Full Copyright Statement......................................50 12.2 Informative References.................................52
13 IPR Notice...................................................53
14 Full Copyright Statement.....................................53
1 Introduction 1 Introduction
Real-time media streams that use RTP are, to some degree, resilient Real-time media streams that use RTP are, to some degree, resilient
against packet losses. RTP [1] provides all the necessary against packet losses. RTP [1] provides all the necessary
mechanisms to restore ordering and timing present at the sender to mechanisms to restore ordering and timing present at the sender to
properly reproduce a media stream at a recipient. RTP also properly reproduce a media stream at a recipient. RTP also
provides continuous feedback about the overall reception quality provides continuous feedback about the overall reception quality
from all receivers -- thereby allowing the sender(s) in the mid- from all receivers -- thereby allowing the sender(s) in the mid-
term (in the order of several seconds to minutes) to adapt their term (in the order of several seconds to minutes) to adapt their
skipping to change at page 5, line 45 skipping to change at page 5, line 47
Regular RTCP mode: Regular RTCP mode:
Mode of operation in which no preferred transmission of FB Mode of operation in which no preferred transmission of FB
messages is allowed. Instead, RTCP messages are sent messages is allowed. Instead, RTCP messages are sent
following the rules of [1]. Nevertheless, such RTCP following the rules of [1]. Nevertheless, such RTCP
messages may contain feedback information as defined in messages may contain feedback information as defined in
this document. this document.
Regular RTCP packet: Regular RTCP packet:
An RTCP packet that is not sent as an Early RTCP packet. An RTCP packet that is not sent as an Early RTCP packet.
RTP sender:
An RTP sender is an RTP entity that transmits media packets
as well as RTCP packets and receives Regular as well as
Early RTCP (i.e. feedback) packets. Note that the RTP
sender is a logical role and that the same RTP entity may
at the same time act as an RTP receiver.
RTP receiver:
An RTP receiver is an RTP entity that receives media
packets as well as RTCP packets and transmits Regular as
well as Early RTCP (i.e. feedback) packets. Note that the
RTP receiver is a logical role and that the same RTP entity
may at the same time act as an RTP sender.
1.2 Terminology 1.2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119 in this document are to be interpreted as described in RFC 2119
[5]. [5].
2 RTP and RTCP Packet Formats and Protocol Behavior 2 RTP and RTCP Packet Formats and Protocol Behavior
2.1 RTP
The rules defined in [2] also apply to this profile except for The rules defined in [2] also apply to this profile except for
those rules mentioned in the following: those rules mentioned in the following:
RTCP packet types: RTCP packet types:
Two additional RTCP packet types are registered and the Two additional RTCP packet types are registered and the
corresponding FB messages to convey feedback information corresponding FB messages to convey feedback information
are defined in section 6 of this memo. are defined in section 6 of this memo.
RTCP report intervals: RTCP report intervals:
This document describes three modes of operation which This document describes three modes of operation which
influence the RTCP report intervals (see section 3.2 of influence the RTCP report intervals (see section 3.2 of
this memo). In Regular RTCP mode, all rules from [1] apply this memo). In Regular RTCP mode, all rules from [1] apply
except for the minimal interval of five seconds between two except for the recommended minimal interval of five seconds
RTCP reports from the same RTP entity. In both Immediate between two RTCP reports from the same RTP entity. In both
Feedback and Early RTCP modes, the minimal interval of five Immediate Feedback and Early RTCP modes, the minimal
seconds between two RTCP reports is dropped and, interval of five seconds between two RTCP reports is
additionally, the rules specified in section 3 of this memo dropped and, additionally, the rules specified in section 3
apply if RTCP packets containing FB messages (defined in of this memo apply if RTCP packets containing FB messages
section 4 of this memo) are to be transmitted. (defined in section 4 of this memo) are to be transmitted.
The rules set forth in [1] may be overridden by session The rules set forth in [1] may be overridden by session
descriptions specifying different parameters (e.g. for the descriptions specifying different parameters (e.g. for the
bandwidth share assigned to RTCP for senders and receivers, bandwidth share assigned to RTCP for senders and receivers,
respectively). For sessions defined using the Session respectively). For sessions defined using the Session
Description Protocol (SDP) [3], the rules of [4] apply. Description Protocol (SDP) [3], the rules of [4] apply.
Congestion control: Congestion control:
The same basic rules as detailed in [2] apply. Beyond The same basic rules as detailed in [2] apply. Beyond
this, in section 5, further consideration is given to the this, in section 7, further consideration is given to the
impact of feedback and a sender's reaction to FB messages. impact of feedback and a sender's reaction to FB messages.
2.2 Underlying Transport Protocols
RTP is intended to be used on top of unreliable transport
protocols, including UDP and DCCP. This section briefly describes
the specifics beyond plain RTP operation introduced by RTCP
feedback as specified in this memo.
UDP: UDP provides best effort delivery of datagrams for point-
to-point as well as for multicast communications. UDP does
not support congestion control or error repair. The RTCP-
based feedback defined in this memo is able to provide
minimal support for congestion control for RTP-over-UDP
traffic as well as for limited error repair. It should be
noted, however, that RTCP feedback does not operate on RTT
timescales. This memo addresses both unicast and multicast
operation.
DCCP: DCCP [19] provides for congestion-controlled but unreliable
datagram flows for unicast communications. With TFRC-based
[20] congestion control (CCID 3), DCCP is particularly
suitable for audio and video communications. DCCP's
acknowledgement messages may provide detailed feedback
reporting about received and missed datagrams (and thus
about congestion). RTCP-based feedback using the Generic
Feedback messages (section 6.2) may be used to provide
similar information, albeit at a much lower rate.
When running RTP over DCCP, congestion control is performed
at the DCCP layer and no additional mechanisms are required
at the RTP layer. Furthermore, an RTCP-feedback capable
sender may leverage the more frequent DCCP-based feedback
and thus a receiver may abstain from using (additional)
Generic Feedback messages where appropriate.
3 Rules for RTCP Feedback 3 Rules for RTCP Feedback
3.1 Compound RTCP Feedback Packets 3.1 Compound RTCP Feedback Packets
Two components constitute RTCP-based feedback as described in this Two components constitute RTCP-based feedback as described in this
document: document:
o Status reports are contained in SR/RR packets and are o Status reports are contained in SR/RR packets and are
transmitted at regular intervals as part of compound RTCP transmitted at regular intervals as part of compound RTCP
packets (which also include SDES and possibly other messages); packets (which also include SDES and possibly other messages);
skipping to change at page 11, line 43 skipping to change at page 12, line 43
T that has been computed (because of reconsideration or to T that has been computed (because of reconsideration or to
determine tn). T_rr is also referred to as Regular RTCP interval determine tn). T_rr is also referred to as Regular RTCP interval
in this document. in this document.
f) Let t0 be the time at which an event that is to be reported is f) Let t0 be the time at which an event that is to be reported is
detected by a receiver. detected by a receiver.
g) Let T_dither_max be the maximum interval for which an RTCP g) Let T_dither_max be the maximum interval for which an RTCP
feedback packet MAY be additionally delayed to prevent feedback packet MAY be additionally delayed to prevent
implosions in multiparty sessions; the value for T_dither_max is implosions in multiparty sessions; the value for T_dither_max is
dynamically calculated based upon T_rr. For point-to-point dynamically calculated based upon T_rr (or may be derived by
sessions (i.e. sessions with exactly two members with no change means of another mechanism common across all RTP receivers to be
in the group size expected, e.g. unicast streaming sessions), specified in the future). For point-to-point sessions (i.e.
T_dither_max is set to 0. sessions with exactly two members with no change in the group
size expected, e.g. unicast streaming sessions), T_dither_max is
set to 0.
h) Let T_max_fb_delay be the upper bound within which feedback to h) Let T_max_fb_delay be the upper bound within which feedback to
an event needs to be reported back to the sender to be useful at an event needs to be reported back to the sender to be useful at
all. This value is application-specific; and no values are all. This value is application-specific; and no values are
defined in this document. defined in this document.
i) Let te be the time for which a feedback packet is scheduled. i) Let te be the time for which a feedback packet is scheduled.
j) Let T_fd be the actual (randomized) delay for the transmission j) Let T_fd be the actual (randomized) delay for the transmission
of FB message in response to an event at time t0. of FB message in response to an event at time t0.
skipping to change at page 12, line 33 skipping to change at page 13, line 37
last Regular RTCP transmission (i.e. at tp+T_rr). Instead, the last Regular RTCP transmission (i.e. at tp+T_rr). Instead, the
next Regular RTCP packet will be delayed until at least next Regular RTCP packet will be delayed until at least
T_rr_interval after the last Regular RTCP transmission, i.e. it T_rr_interval after the last Regular RTCP transmission, i.e. it
will be scheduled at or later than tp+T_rr_interval. Note that will be scheduled at or later than tp+T_rr_interval. Note that
T_rr_interval does not affect the calculation of T_rr and tp; T_rr_interval does not affect the calculation of T_rr and tp;
instead, Regular RTCP packets scheduled for transmission before instead, Regular RTCP packets scheduled for transmission before
tp+T_rr_interval will be suppressed if, for example, they do not tp+T_rr_interval will be suppressed if, for example, they do not
contain any FB messages. The T_rr_interval does not affect contain any FB messages. The T_rr_interval does not affect
transmission scheduling of Early RTCP packets. transmission scheduling of Early RTCP packets.
NOTE: Providing T_rr_interval as an independent variable is meant to NOTE: Providing T_rr_interval as an independent variable is meant
minimize Regular RTCP feedback (and thus bandwidth consumption) as to minimize Regular RTCP feedback (and thus bandwidth consumption)
needed by the application while additionally allowing the use of more as needed by the application while additionally allowing the use of
frequent Early RTCP packets to provide timely feedback. This goal more frequent Early RTCP packets to provide timely feedback. This
could not be achieved by reducing the overall RTCP bandwidth as RTCP goal could not be achieved by reducing the overall RTCP bandwidth
bandwidth reduction would also impact the frequency of Early feedback. as RTCP bandwidth reduction would also impact the frequency of
Early feedback.
n) Let t_rr_last be the point in time at which the last Regular n) Let t_rr_last be the point in time at which the last Regular
RTCP packet has been scheduled and sent, i.e. has not been RTCP packet has been scheduled and sent, i.e. has not been
suppressed due to T_rr_interval. suppressed due to T_rr_interval.
o) Let T_retention be the time window for which past FB messages o) Let T_retention be the time window for which past FB messages
are stored by an AVPF entity. This is to ensure that feedback are stored by an AVPF entity. This is to ensure that feedback
suppression also works for entities that have received FB suppression also works for entities that have received FB
messages from other entities prior to noticing the feedback messages from other entities prior to noticing the feedback
event itself. T_retention MUST be set to at least 2 seconds. event itself. T_retention MUST be set to at least 2 seconds.
skipping to change at page 13, line 17 skipping to change at page 14, line 23
the sender. the sender.
To avoid an implosion of feedback packets in multiparty sessions, To avoid an implosion of feedback packets in multiparty sessions,
the receiver MUST delay the transmission of the RTCP feedback the receiver MUST delay the transmission of the RTCP feedback
packet by a random amount of time T_fd (with the random number packet by a random amount of time T_fd (with the random number
evenly distributed in the interval [0, T_dither_max]). evenly distributed in the interval [0, T_dither_max]).
Transmission of the compound RTCP packet MUST then be scheduled for Transmission of the compound RTCP packet MUST then be scheduled for
te = t0 + T_fd. te = t0 + T_fd.
The T_dither_max parameter is derived from the Regular RTCP The T_dither_max parameter is derived from the Regular RTCP
interval, T_rr, which, in turn, is based upon the group size. interval, T_rr, which, in turn, is based upon the group size. A
future document may also specify other calculations for
T_dither_max (e.g. based upon RTT) if it can be assured that all
RTP receivers will use the same mechanism for calculating
T_dither_max.
For a certain application scenario, a receiver may determine an For a certain application scenario, a receiver may determine an
upper bound for the acceptable local delay of FB messages: upper bound for the acceptable local delay of FB messages:
T_max_fb_delay. If an a priori estimation or the actual T_max_fb_delay. If an a priori estimation or the actual
calculation of T_dither_max indicates that this upper bound MAY be calculation of T_dither_max indicates that this upper bound MAY be
violated (e.g. because T_dither_max > T_max_fb_delay), the receiver violated (e.g. because T_dither_max > T_max_fb_delay), the receiver
MAY decide not to send any feedback at all because the achievable MAY decide not to send any feedback at all because the achievable
gain is considered insufficient. gain is considered insufficient.
If an Early RTCP packet is scheduled, the time slot for the next If an Early RTCP packet is scheduled, the time slot for the next
skipping to change at page 15, line 26 skipping to change at page 16, line 46
i) If the session is a point-to-point session then i) If the session is a point-to-point session then
T_dither_max = 0. T_dither_max = 0.
ii) If the session is a multiparty session then ii) If the session is a multiparty session then
T_dither_max = l * T_rr T_dither_max = l * T_rr
with l=0.5. with l=0.5.
The value for T_dither_max MAY be calculated differently (e.g.
based upon RTT) which MUST then be specified in a future
document. Such a future specification MUST ensure that all
RTP receivers use the same mechanism to calculate
T_dither_max.
The values given above for T_dither_max are minimal values. The values given above for T_dither_max are minimal values.
Application-specific feedback considerations may make it Application-specific feedback considerations may make it
worthwhile to increase T_dither_max beyond this value. This worthwhile to increase T_dither_max beyond this value. This
is up to the discretion of the implementer. is up to the discretion of the implementer.
3. Then, R MUST check whether its next Regular RTCP packet would be 3. Then, R MUST check whether its next Regular RTCP packet would be
within the time bounds for the Early RTCP packet triggered at t0, within the time bounds for the Early RTCP packet triggered at t0,
i.e. if t0 + T_dither_max > tn. i.e. if t0 + T_dither_max > tn.
3.a) If so, an Early RTCP packet MUST NOT be scheduled; 3.a) If so, an Early RTCP packet MUST NOT be scheduled;
skipping to change at page 21, line 37 skipping to change at page 23, line 16
rate, assigned bandwidth, frame/packet rate, and group size -- rate, assigned bandwidth, frame/packet rate, and group size --
whether (and which) feedback mechanisms can be applied. whether (and which) feedback mechanisms can be applied.
Regular RTCP reception statistics provide valuable input to this Regular RTCP reception statistics provide valuable input to this
step, too. step, too.
3) If the application decides to send feedback, the application has 3) If the application decides to send feedback, the application has
to follow the rules for transmitting Early RTCP packets or to follow the rules for transmitting Early RTCP packets or
Regular RTCP packets containing FB messages. Regular RTCP packets containing FB messages.
4) The type of RTCP feedback sent should not duplicate information
available to the sender from a lower layer transport protocol.
That is, if the transport protocol provides negative or positive
acknowledgements about packet reception (such as DCCP), the
receiver should avoid repeating the same information at the RTCP
layer (i.e. abstain from sending Generic ACKs or Generic NACKs).
3.7.2 Media Session Attributes 3.7.2 Media Session Attributes
Media sessions are typically described using out-of-band mechanisms Media sessions are typically described using out-of-band mechanisms
to convey transport addresses, codec information, etc. between to convey transport addresses, codec information, etc. between
sender(s) and receiver(s). Such a mechanism is two-fold: a format sender(s) and receiver(s). Such a mechanism is two-fold: a format
used to describe a media session and another mechanism for used to describe a media session and another mechanism for
transporting this description. transporting this description.
In the IETF, the Session Description Protocol (SDP) is currently In the IETF, the Session Description Protocol (SDP) is currently
used to describe media sessions while protocols such as SIP, SAP, used to describe media sessions while protocols such as SIP, SAP,
skipping to change at page 22, line 48 skipping to change at page 24, line 34
for which the "AVPF" is specified. for which the "AVPF" is specified.
The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB
messages MAY be used in this media session for the indicated messages MAY be used in this media session for the indicated
payload type. A wildcard payload type ("*") MAY be used to payload type. A wildcard payload type ("*") MAY be used to
indicate that the RTCP feedback attribute applies to all payload indicate that the RTCP feedback attribute applies to all payload
types. If several types of feedback are supported and/or the same types. If several types of feedback are supported and/or the same
feedback shall be specified for a subset of the payload types, feedback shall be specified for a subset of the payload types,
several "a=rtcp-fb" lines MUST be used. several "a=rtcp-fb" lines MUST be used.
If no "rtcp-fb" attribute is specified the RTP receivers SHOULD If no "rtcp-fb" attribute is specified the RTP receivers MAY send
assume that the RTP senders only support generic NACKs. In feedback using other suitable RTCP feedback packets as defined for
addition, the RTP receivers MAY send feedback using other suitable the respective media type. The RTP receivers MUST NOT rely on the
RTCP feedback packets as defined for the respective media type. RTP senders reacting to any of the FB messages. The RTP sender MAY
The RTP receivers MUST NOT rely on the RTP senders reacting to any choose to ignore some feedback messages.
of the FB messages.
If one or more "rtcp-fb" attributes are present in a media session If one or more "rtcp-fb" attributes are present in a media session
description, the RTCP receivers for the media session(s) containing description, the RTCP receivers for the media session(s) containing
the "rtcp-fb" the "rtcp-fb"
o MUST ignore all "rtcp-fb" attributes of which they do not fully o MUST ignore all "rtcp-fb" attributes of which they do not fully
understand the semantics (i.e. where they do not understand the understand the semantics (i.e. where they do not understand the
meaning of all values in the "a=rtcp-fb" line); meaning of all values in the "a=rtcp-fb" line);
o SHOULD provide feedback information as specified in this o SHOULD provide feedback information as specified in this
skipping to change at page 24, line 7 skipping to change at page 25, line 40
rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
rtcp-fb-pt = "*" ; wildcard: applies to all formats rtcp-fb-pt = "*" ; wildcard: applies to all formats
/ fmt ; as defined in SDP spec / fmt ; as defined in SDP spec
rtcp-fb-val = "ack" rtcp-fb-ack-param rtcp-fb-val = "ack" rtcp-fb-ack-param
/ "nack" rtcp-fb-nack-param / "nack" rtcp-fb-nack-param
/ "trr-int" SP 1*DIGIT / "trr-int" SP 1*DIGIT
/ rtcp-fb-id rtcp-fb-param / rtcp-fb-id rtcp-fb-param
rtcp-fb-id = 1*(alpha-numeric | "-" | "_") rtcp-fb-id = 1*(alpha-numeric / "-" / "_")
rtcp-fb-param = SP "app" [SP byte-string] rtcp-fb-param = SP "app" [SP byte-string]
/ SP token [SP byte-string] / SP token [SP byte-string]
/ ; empty / ; empty
rtcp-fb-ack-param = SP "rpsi" rtcp-fb-ack-param = SP "rpsi"
/ SP "app" [SP byte-string] / SP "app" [SP byte-string]
/ SP token [SP byte-string] / SP token [SP byte-string]
/ ; empty / ; empty
skipping to change at page 26, line 47 skipping to change at page 28, line 32
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback s=Media with feedback
t=0 0 t=0 0
c=IN IP4 host.example.com c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 0 96 m=audio 49170 RTP/AVPF 0 96
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000 a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16 a=fmtp:96 0-16
a=rtcp-fb:96 ack a=rtcp-fb:96 ack
This allows sender and receiver to provide reliable transmission of
DTMF events in an audio session. Assuming a 64kbit/s audio stream
with one receiver, the receiver has 2.5% RTCP bandwidth available
for the acknowledgment stream, i.e. 250 bytes per second or some 2
RTCP feedback message. Hence, the receiver can individually
confirm receipt of two DTMF digits per seconds.
Example 2: The following session description indicates a multicast Example 2: The following session description indicates a multicast
video-only session (using either H.261 or H.263+) with the video video-only session (using either H.261 or H.263+) with the video
source accepting Generic NACKs for both codecs and Reference source accepting Generic NACKs for both codecs and Reference
Picture Selection for H.263. Such a description may have been Picture Selection for H.263. Such a description may have been
conveyed using the Session Announcement Protocol (SAP). conveyed using the Session Announcement Protocol (SAP).
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback s=Multicast video with feedback
t=3203130148 3203137348 t=3203130148 3203137348
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183 c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 99 m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184 c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000 a=rtpmap:99 H261/90000
a=rtcp-fb:* nack a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi a=rtcp-fb:98 nack rpsi
The sender may use an incoming Generic NACK as a hint to send a new
intra-frame as soon as possible (congestion control permitting).
Receipt of an RPSI message allows the sender to avoid sending a
large intra-frame; instead it may continue to send inter-frames,
however, choosing the indicated frame as new encoding reference.
Example 3: The following session description defines the same media Example 3: The following session description defines the same media
session as example 2 but allows for mixed mode operation of AVP and session as example 2 but allows for mixed mode operation of AVP and
AVPF RTP entities (see also next section). Note that both media AVPF RTP entities (see also next section). Note that both media
descriptions use the same addresses; however, two m= lines are descriptions use the same addresses; however, two m= lines are
needed to convey information about both applicable RTP profiles. needed to convey information about both applicable RTP profiles.
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback s=Multicast video with feedback
t=3203130148 3203137348 t=3203130148 3203137348
skipping to change at page 27, line 48 skipping to change at page 29, line 46
a=rtpmap:98 H263-1998/90000 a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000 a=rtpmap:99 H261/90000
a=rtcp-fb:* nack a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi a=rtcp-fb:98 nack rpsi
Note that these two m= lines SHOULD be grouped by some appropriate Note that these two m= lines SHOULD be grouped by some appropriate
mechanism to indicate that both are alternatives actually conveying mechanism to indicate that both are alternatives actually conveying
the same contents. A sample mechanism by which this can be the same contents. A sample mechanism by which this can be
achieved is defined in [7]. achieved is defined in [7].
In this example, the RTCP feedback-enabled receivers will gain an
occasional advantage to report events earlier back to the sender
(which may benefit the entire group). On average, however, all RTP
receivers will provide the same amount of feedback. The
interworking between AVP and AVPF entities is discussed in depth in
the next section.
5 Interworking and Co-Existence of AVP and AVPF Entities 5 Interworking and Co-Existence of AVP and AVPF Entities
The AVPF profile defined in this document is an extension of the The AVPF profile defined in this document is an extension of the
AVP profile as defined in [2]. Both profiles follow the same basic AVP profile as defined in [2]. Both profiles follow the same basic
rules (including the upper bandwidth limit for RTCP and the rules (including the upper bandwidth limit for RTCP and the
bandwidth assignments to senders and receivers). Therefore, bandwidth assignments to senders and receivers). Therefore,
senders and receivers of using either of the two profiles can be senders and receivers of using either of the two profiles can be
mixed in a single session (see e.g. example 3 in section 4.5). mixed in a single session (see e.g. example 3 in section 4.5).
AVP and AVPF are defined in a way that, from a robustness point of AVP and AVPF are defined in a way that, from a robustness point of
skipping to change at page 32, line 40 skipping to change at page 34, line 44
The Generic NACK message is identified by PT=RTPFB and FMT=1. The Generic NACK message is identified by PT=RTPFB and FMT=1.
The FCI field MUST contain at least one and MAY contain more than The FCI field MUST contain at least one and MAY contain more than
one Generic NACK. one Generic NACK.
The Generic NACK packet is used to indicate the loss of one or more The Generic NACK packet is used to indicate the loss of one or more
RTP packets. The lost packet(s) are identified by the means of a RTP packets. The lost packet(s) are identified by the means of a
packet identifier and a bit mask. packet identifier and a bit mask.
Generic NACK feedback SHOULD NOT be used if the underlying
transport protocol is capable of providing similar feedback
information to the sender (as may be the case e.g. with DCCP).
The Feedback control information (FCI) field has the following The Feedback control information (FCI) field has the following
Syntax (figure 4): Syntax (figure 4):
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP | | PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Syntax for the Generic NACK message Figure 4: Syntax for the Generic NACK message
skipping to change at page 33, line 44 skipping to change at page 36, line 5
The Generic ACK message is identified by PT=RTPFB and FMT=2. The Generic ACK message is identified by PT=RTPFB and FMT=2.
The FCI field MUST contain at least one and MAY contain more than The FCI field MUST contain at least one and MAY contain more than
one Generic ACK. one Generic ACK.
The Generic ACK packet is used to indicate that one or several RTP The Generic ACK packet is used to indicate that one or several RTP
packets were received correctly. The received packet(s) are packets were received correctly. The received packet(s) are
identified by the means of a packet identifier and a bit mask. identified by the means of a packet identifier and a bit mask.
ACKing of a range of consecutive packets is also possible. ACKing of a range of consecutive packets is also possible.
Generic ACK feedback SHOULD NOT be used if the underlying transport
protocol is capable of providing similar feedback information to
the sender (as may be the case e.g. with DCCP).
The Feedback control information (FCI) field has the following The Feedback control information (FCI) field has the following
syntax: syntax:
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |R| BLP/#packets | | PID |R| BLP/#packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Syntax for the Generic ACK message Figure 5: Syntax for the Generic ACK message
skipping to change at page 42, line 14 skipping to change at page 44, line 14
However, across all applications, there is a common requirement for However, across all applications, there is a common requirement for
(TCP-friendly) congestion control on the media stream as defined in (TCP-friendly) congestion control on the media stream as defined in
[1] and [2] when operating in a best-effort network environment. [1] and [2] when operating in a best-effort network environment.
Low delay feedback supports the use of congestion control Low delay feedback supports the use of congestion control
algorithms in two ways: algorithms in two ways:
o The potentially more frequent RTCP packets allow the sender to o The potentially more frequent RTCP packets allow the sender to
monitor the network state more closely than with Regular RTCP monitor the network state more closely than with Regular RTCP
packets and therefore enable reacting to upcoming congestion in packets and therefore enable a more timely reaction to upcoming
a more timely fashion. congestion.
o The FB messages themselves may convey additional information as o The FB messages themselves may convey additional information as
input to congestion control algorithms and thus improve reaction input to congestion control algorithms and thus improve reaction
over conventional RTCP. (For example, ACK-based feedback may over conventional RTCP. (For example, ACK-based feedback may
even allow to construct closed loop algorithms and NACK-based even allow to construct closed loop algorithms and NACK-based
systems may provide further information on the packet loss systems may provide further information on the packet loss
distribution.) distribution.)
A congestion control algorithm that shares the available bandwidth It should be noted, however, that RTCP feedback may operate at much
fairly with competing TCP connections, e.g. TFRC [8], SHOULD be slower timescales than other transport layer feedback mechanisms
used to determine the data rate for the media stream (if the low (that usually operate in the order of RTT). Therefore, any rate
delay RTP session is transmitted in a best effort environment). adaptation may occur slower than TCP.
RTCP FB messages or RTCP SR/RR packets that indicate recent packet A congestion control algorithm that shares the available bandwidth
loss MUST NOT lead to a (mid-term) increase in the transmission reasonably fairly with competing TCP connections, e.g. TFRC [8],
data rate and SHOULD lead to a (short-term) decrease of the MUST be used to determine the data rate for the media stream within
transmission data rate. Such messages SHOULD cause the sender to the bounds of the RTP sender's and the media session's capabilities
adjust the transmission data rate to the order of the throughput if the RTP/AVPF session is transmitted in a best effort
TCP would achieve under similar conditions (e.g. using TFRC). environment.
RTCP FB messages or RTCP SR/RR packets that indicate no recent That is, RTCP FB messages or RTCP SR/RR packets that indicate
packet loss MAY cause the sender to increase the transmission data recent packet loss SHOULD cause the sender to adjust the
rate to roughly the throughput TCP would achieve under similar transmission data rate to the order of the throughput TCP would
conditions (e.g. using TFRC). achieve under similar conditions (e.g. using TFRC). RTCP FB
messages or RTCP SR/RR packets that indicate no recent packet loss
MAY cause the sender to increase the transmission data rate to
roughly the throughput TCP would achieve under similar conditions
(e.g. using TFRC). Such messages MUST NOT cause a larger increase
in the sender's transmission rate than a comparable TCP flow would
achieve. The procedural details MUST be specified by the document
defining the sender behavior for a certain codec and/or
application.
8 Security Considerations 8 Security Considerations
RTP packets transporting information with the proposed payload RTP packets transporting information with the proposed payload
format are subject to the security considerations discussed in the format are subject to the security considerations discussed in the
RTP specification [1] and in the RTP/AVP profile specification [2]. RTP specification [1] and in the RTP/AVP profile specification [2].
This profile does not specify any additional security services. This profile does not specify any additional security services.
This profile modifies the timing behavior of RTCP and eliminates This profile modifies the timing behavior of RTCP and eliminates
the minimum RTCP interval of five seconds and allows for earlier the minimum RTCP interval of five seconds and allows for earlier
skipping to change at page 43, line 31 skipping to change at page 45, line 40
fewer frames or decrease audio/video quality). This may result in fewer frames or decrease audio/video quality). This may result in
a degradation of the quality of the reproduced media stream. a degradation of the quality of the reproduced media stream.
Finally, a malicious group member can act as a large number of Finally, a malicious group member can act as a large number of
group members and thereby obtain an artificially large share of the group members and thereby obtain an artificially large share of the
Early feedback bandwidth and reduce the reactivity of the other Early feedback bandwidth and reduce the reactivity of the other
group members -- possibly even causing them to no longer operate in group members -- possibly even causing them to no longer operate in
Immediate or Early feedback mode and thus undermining the whole Immediate or Early feedback mode and thus undermining the whole
purpose of this profile. purpose of this profile.
Senders as well as receivers SHOULD behave conservative when Senders as well as receivers SHOULD behave conservatively when
observing strange reporting behavior. For excessive failure observing strange reporting behavior. For excessive failure
reporting from one or a few receivers, the sender MAY decide to no reporting from one or a few receivers, the sender MAY decide to no
longer consider this feedback when adapting its transmission longer consider this feedback when adapting its transmission
behavior for the media stream. In any case, senders and receivers behavior for the media stream. In any case, senders and receivers
SHOULD still adhere to the maximum RTCP bandwidth but make sure SHOULD still adhere to the maximum RTCP bandwidth but make sure
that they are capable of transmitting at least regularly scheduled that they are capable of transmitting at least regularly scheduled
RTCP packets. Senders SHOULD carefully consider how to adjust RTCP packets. Senders SHOULD carefully consider how to adjust
their transmission bandwidth when encountering strange reporting their transmission bandwidth when encountering strange reporting
behavior; they MUST NOT increase their transmission bandwidth even behavior; they MUST NOT increase their transmission bandwidth even
if ignoring suspicious feedback. if ignoring suspicious feedback.
Attacks using false RTCP packets (Regular as well as Early ones) Attacks using false RTCP packets (Regular as well as Early ones)
can be avoided by authenticating all RTCP messages. This can be can be avoided by authenticating all RTCP messages. This can be
achieved by using the AVPF profile together with the Secure RTP achieved by using the AVPF profile together with the Secure RTP
profile as defined in [10]; as a prerequisite, an appropriate profile as defined in [22]; as a prerequisite, an appropriate
combination of those two profiles (an "SAVPF") needs to be combination of those two profiles (an "SAVPF") is being specified
specified. [21].
9 IANA Considerations 9 IANA Considerations
The following contact information shall be used for all The following contact information shall be used for all
registrations included here: registrations included here:
Contact: Joerg Ott Contact: Joerg Ott
mailto:jo@acm.org mailto:jo@acm.org
tel:+49-421-201-7028 tel:+49-421-201-7028
skipping to change at page 47, line 30 skipping to change at page 49, line 51
Name: AFB Name: AFB
Long name: Application Layer Feedback Long name: Application Layer Feedback
Value: 15 Value: 15
Reference: RFC XXXX. Reference: RFC XXXX.
Name: Extension Name: Extension
Long name: Reserved for future extensions. Long name: Reserved for future extensions.
Value: 31 Value: 31
Reference: RFC XXXX. Reference: RFC XXXX.
Further entries may be registered on a first-come first-serve Further entries may be registered following the "Specification
basis. Each registration needs to indicate the FMT value, if there Required" rules as defined in RFC 2434 [10]. Each registration
is a specific FB message to go into the FCI field, and whether or needs to indicate the FMT value, if there is a specific FB message
not multiple FB messages may be stacked in a single FCI field. For to go into the FCI field, and whether or not multiple FB messages
each new registration, it is mandatory that a permanent, stable, may be stacked in a single FCI field. For each new registration,
and publicly accessible document exists that specifies the it is mandatory that a permanent, stable, and publicly accessible
semantics of the registered parameter as well as the syntax and document exists that specifies the semantics of the registered
semantics of the associated FB message (if any). The general parameter as well as the syntax and semantics of the associated FB
registration procedures of [3] apply. message (if any). The general registration procedures of [3]
apply.
NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by
the RFC number assigned to this document. the RFC number assigned to this document.
10 Acknowledgements 10 Acknowledgements
This document is a product of the Audio-Visual Transport (AVT) This document is a product of the Audio-Visual Transport (AVT)
Working Group of the IETF. The authors would like to thank Steve Working Group of the IETF. The authors would like to thank Steve
Casner and Colin Perkins for their comments and suggestions as well Casner and Colin Perkins for their comments and suggestions as well
as for their responsiveness to numerous questions. The authors as for their responsiveness to numerous questions. The authors
skipping to change at page 48, line 31 skipping to change at page 51, line 4
Franklinstr. 28-29 Franklinstr. 28-29
D-10587 Berlin D-10587 Berlin
Germany Germany
Noriyuki Sato Noriyuki Sato
Oki Electric Industry Co., Ltd. Oki Electric Industry Co., Ltd.
1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan
Tel. +81 6 6949 5101 Tel. +81 6 6949 5101
Fax. +81 6 6949 5108 Fax. +81 6 6949 5108
Mail sato652@oki.com Mail sato652@oki.com
Carsten Burmeister Carsten Burmeister
Panasonic European Laboratories GmbH Panasonic European Laboratories GmbH
Monzastr. 4c, 63225 Langen, Germany
Tel. +49-(0)6103-766-263
Fax. +49-(0)6103-766-166
Mail burmeister@panasonic.de Mail burmeister@panasonic.de
Jose Rey Jose Rey
Panasonic European Laboratories GmbH Panasonic European Laboratories GmbH
Monzastr. 4c, 63225 Langen, Germany Monzastr. 4c, 63225 Langen, Germany
Tel. +49-(0)6103-766-134 Tel. +49-(0)6103-766-134
Fax. +49-(0)6103-766-166 Fax. +49-(0)6103-766-166
Mail rey@panasonic.de Mail rey@panasonic.de
12 Bibliography 12 Bibliography
12.1 Normative references 12.1 Normative references
[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP
- A Transport Protocol for Real-time Applications," Internet - A Transport Protocol for Real-time Applications," RFC 3550,
Draft, draft-ietf-avt-rtp-new-12.txt, Work in Progress, March July 2003.
2003.
[2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video [2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control," Internet Draft draft-ietf- Conferences with Minimal Control," RFC 3551, July 2003.
avt-profile-new-13.txt, March 2003.
[3] M. Handley, V. Jacobson, and Colin Perkins, "SDP: Session [3] M. Handley, V. Jacobson, and Colin Perkins, "SDP: Session
Description Protocol", Internet Draft draft-ietf-mmusic-sdp- Description Protocol", Internet Draft draft-ietf-mmusic-sdp-
new-12.txt, March 2003. new-15.txt, October 2003.
[4] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", [4] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", RFC
Internet Draft draft-ietf-avt-rtcp-bw-05.txt, November 2001. 3556, July 2003.
[5] S. Bradner, "Key words for use in RFCs to Indicate Requirement [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119, March 1997. Levels," RFC 2119, March 1997.
[6] T. Turletti and C. Huitema, "RTP Payload Format for H.261 [6] T. Turletti and C. Huitema, "RTP Payload Format for H.261
Video Streams, RFC 2032, October 1996. Video Streams, RFC 2032, October 1996.
[7] G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne, [7] G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne,
"Grouping of media lines in SDP," RFC 3388, December 2002. "Grouping of media lines in SDP," RFC 3388, December 2002.
[8] M. Handley, J. Padhye, S. Floyd, J. Widmer, "TCP friendly Rate [8] M. Handley, J. Padhye, S. Floyd, J. Widmer, "TCP friendly Rate
Control (TFRC): Protocol Specification," RFC 3448, January Control (TFRC): Protocol Specification," RFC 3448, January
2003. 2003.
[9] J. Rosenberg and H. Schulzrinne, "An offer/answer model with [9] J. Rosenberg and H. Schulzrinne, "An offer/answer model with
SDP," RFC 3264, June 2002. SDP," RFC 3264, June 2002.
12.2 Informative References [10] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs," RFC 2434, October 1998.
[10] M. Baugher, R. Blom, E. Carrarra, D. McGrew, M. Naslund, K. 12.2 Informative References
Norrman, D. Oran, "The Secure Real-Time Transport Protocol,"
Internet Draft, draft-ietf-avt-srtp-05.txt, Work in Progress,
June 2002.
[11] C. Perkins and O. Hodson, "Options for Repair of Streaming [11] C. Perkins and O. Hodson, "Options for Repair of
Media," RFC 2354, June 1998. Streaming Media," RFC 2354, June 1998.
[12] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for [12] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction,", RFC 2733, December 1999. Generic Forward Error Correction,", RFC 2733, December 1999.
[13] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, [13] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley,
J.C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload J.C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data," RFC 2198, September 1997. for Redundant Audio Data," RFC 2198, September 1997.
[14] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. [14] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D.
Newell, J. Ott, G. Sullivan, S. Wenger, and C. Zhu, "RTP Newell, J. Ott, G. Sullivan, S. Wenger, and C. Zhu, "RTP
skipping to change at page 50, line 19 skipping to change at page 52, line 34
1707 - 1723, October, 1999. 1707 - 1723, October, 1999.
[16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology - [16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology -
Coding of audio-visual objects - Part2: Visual", 2001. Coding of audio-visual objects - Part2: Visual", 2001.
[17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate [17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate
Communication," November 2000. Communication," November 2000.
[18] H. Schulzrinne and S. Petrack, "RTP Payload for DTMF Digits, [18] H. Schulzrinne and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals," RFC 2833, May 2000. Telephony Tones and Telephony Signals," RFC 2833, May 2000.
[19] E. Kohler, M. Handley, S. Floyd, and J. Padhye, "Datagram
Congestion Control Protocol (DCCP)," Internet Draft draft-
ietf-dccp-spec-05.txt, Work in Progress, October 2003.
[20] M. Handley, S. Floyd, J. Padhye, and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification," RFC 3448,
January 2003.
[21] J. Ott and E. Carrara, "Extended Secure RTP Profile for RTCP-
based Feedback (RTP/SAVPF)," Internet Draft draft-ietf-avt-
profile-savpf-00.txt, Work in Progress, October 2003.
[22] M. Baugher, R. Blom, E. Carrarra, D. McGrew, M. Naslund, K.
Norrman, D. Oran, "The Secure Real-Time Transport Protocol,"
Internet Draft, draft-ietf-avt-srtp-09.txt, Work in Progress,
June 2003.
13 IPR Notice 13 IPR Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and the IETF's procedures with respect to rights in standards-track and
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/