draft-ietf-avt-rtcp-feedback-08.txt   draft-ietf-avt-rtcp-feedback-09.txt 
INTERNET-DRAFT Joerg Ott/Uni Bremen TZI INTERNET-DRAFT Joerg Ott/Uni Bremen TZI
draft-ietf-avt-rtcp-feedback-08.txt Stephan Wenger/TU Berlin draft-ietf-avt-rtcp-feedback-09.txt Stephan Wenger/TU Berlin
Noriyuki Sato/Oki Noriyuki Sato/Oki
Carsten Burmeister/Matsushita Carsten Burmeister/Matsushita
Jose Rey/Matsushita Jose Rey/Matsushita
31 January 2004 16 July 2004
Expires July 2004 Expires January 2005
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 By submitting this Internet-Draft, each author certifies that any
all provisions of Section 10 of RFC 2026. Internet-Drafts are applicable patent or other IPR claims of which the author is aware
working documents of the Internet Engineering Task Force (IETF), have been disclosed, or will be disclosed, and any of which each
its areas, and its working groups. Note that other groups may also author becomes aware will be disclosed, in accordance with RFC 3668
distribute working documents as Internet-Drafts. (BCP 79).
By submitting this Internet-Draft, each author accepts the
provisions of Section 3 of RFC 3667 (BCP 78).
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 Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
"Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document is a product of the Audio-Visual Transport (AVT)
working group of the Internet Engineering Task Force. Comments are
solicited and should be addressed to the working group's mailing
list at avt@ietf.org and/or the authors.
Abstract Abstract
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. Receivers may use the base mechanisms of against packet losses. Receivers may use the base mechanisms of
RTCP to report packet reception statistics and thus allow a sender RTCP to report packet reception statistics and thus allow a sender
to adapt its transmission behavior in the mid-term as sole means to adapt its transmission behavior in the mid-term as sole means
for feedback and feedback-based error repair (besides a few codec- for feedback and feedback-based error repair (besides a few codec-
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.............................................6 1.2 Terminology..............................................6
2 RTP and RTCP Packet Formats and Protocol Behavior............6 2 RTP and RTCP Packet Formats and Protocol Behavior.............6
2.1 RTP.....................................................6 2.1 RTP......................................................6
2.2 Underlying Transport Protocols..........................7 2.2 Underlying Transport Protocols...........................7
3 Rules for RTCP Feedback......................................7 3 Rules for RTCP Feedback.......................................8
3.1 Compound RTCP Feedback Packets..........................7 3.1 Compound RTCP Feedback Packets...........................8
3.2 Algorithm Outline.......................................9 3.2 Algorithm Outline........................................9
3.3 Modes of Operation.....................................10 3.3 Modes of Operation......................................10
3.4 Definitions and Algorithm Overview.....................12 3.4 Definitions and Algorithm Overview......................12
3.5 AVPF RTCP Scheduling Algorithm.........................15 3.5 AVPF RTCP Scheduling Algorithm..........................15
3.5.1 Initialization...................................15 3.5.1 Initialization...................................16
3.5.2 Early Feedback Transmission......................16 3.5.2 Early Feedback Transmission......................16
3.5.3 Regular RTCP Transmission........................18 3.5.3 Regular RTCP Transmission........................19
3.5.4 Other Considerations.............................20 3.5.4 Other Considerations.............................20
3.6 Considerations on the Group Size.......................20 3.6 Considerations on the Group Size........................20
3.6.1 ACK mode.........................................20 3.6.1 ACK mode.........................................21
3.6.2 NACK mode........................................21 3.6.2 NACK mode........................................21
3.7 Summary of decision steps..............................22 3.7 Summary of decision steps...............................23
3.7.1 General Hints....................................22 3.7.1 General Hints....................................23
3.7.2 Media Session Attributes.........................23 3.7.2 Media Session Attributes.........................23
4 SDP Definitions.............................................23 4 SDP Definitions..............................................24
4.1 Profile identification.................................24 4.1 Profile identification..................................24
4.2 RTCP Feedback Capability Attribute.....................24 4.2 RTCP Feedback Capability Attribute......................24
4.3 RTCP Bandwidth Modifiers...............................27 4.3 RTCP Bandwidth Modifiers................................28
4.4 Examples...............................................28 4.4 Examples................................................28
5 Interworking and Co-Existence of AVP and AVPF Entities......30 5 Interworking and Co-Existence of AVP and AVPF Entities.......30
6 Format of RTCP Feedback Messages............................31 6 Format of RTCP Feedback Messages.............................31
6.1 Common Packet Format for Feedback Messages.............32 6.1 Common Packet Format for Feedback Messages..............33
6.2 Transport Layer Feedback Messages......................34 6.2 Transport Layer Feedback Messages.......................34
6.2.1 Generic NACK.....................................34 6.2.1 Generic NACK.....................................35
6.2.2 Generic ACK......................................35 6.3 Payload Specific Feedback Messages......................36
6.3 Payload Specific Feedback Messages.....................37 6.3.1 Picture Loss Indication (PLI)....................36
6.3.1 Picture Loss Indication (PLI)....................37 6.3.1.1 Semantics...............................36
6.3.1.1 Semantics................................38 6.3.1.2 Message Format..........................37
6.3.1.2 Message Format...........................38 6.3.1.3 Timing Rules............................37
6.3.1.3 Timing Rules.............................38 6.3.1.4 Remarks.................................37
6.3.1.4 Remarks..................................38 6.3.2 Slice Lost Indication (SLI)......................38
6.3.2 Slice Lost Indication (SLI)......................39 6.3.2.1 Semantics...............................38
6.3.2.1 Semantics................................39 6.3.2.2 Format..................................38
6.3.2.2 Format...................................39 6.3.2.3 Timing Rules............................39
6.3.2.3 Timing Rules.............................40 6.3.2.4 Remarks.................................39
6.3.2.4 Remarks..................................40 6.3.3 Reference Picture Selection Indication (RPSI)....40
6.3.3 Reference Picture Selection Indication (RPSI)....41 6.3.3.1 Semantics...............................40
6.3.3.1 Semantics................................41 6.3.3.2 Format..................................41
6.3.3.2 Format...................................42 6.3.3.3 Timing Rules............................41
6.3.3.3 Timing Rules.............................42 6.4 Application Layer Feedback Messages.....................42
6.4 Application Layer Feedback Messages....................43 7 Early Feedback and Congestion Control........................42
7 Early Feedback and Congestion Control.......................43 8 Security Considerations......................................43
8 Security Considerations.....................................44 9 IANA Considerations..........................................44
9 IANA Considerations.........................................46 10 Acknowledgements............................................48
10 Acknowledgements.............................................50 11 Authors' Addresses..........................................49
11 Authors' Addresses...........................................50 12 Bibliography................................................49
12 Bibliography.................................................51 12.1 Normative references...................................49
12.1 Normative references...................................51 12.2 Informative References.................................50
12.2 Informative References.................................52 13 Intellectual Property Notice................................51
13 IPR Notice...................................................53 14 Disclaimer of Validity......................................52
14 Full Copyright Statement.....................................53 15 Full Copyright Statement....................................52
16 Acknowledgment..............................................52
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 7, line 16 skipping to change at page 7, line 29
The same basic rules as detailed in [2] apply. Beyond The same basic rules as detailed in [2] apply. Beyond
this, in section 7, 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 2.2 Underlying Transport Protocols
RTP is intended to be used on top of unreliable transport RTP is intended to be used on top of unreliable transport
protocols, including UDP and DCCP. This section briefly describes protocols, including UDP and DCCP. This section briefly describes
the specifics beyond plain RTP operation introduced by RTCP the specifics beyond plain RTP operation introduced by RTCP
feedback as specified in this memo. feedback as specified in this memo.
UDP: UDP provides best effort delivery of datagrams for point- UDP: UDP provides best effort delivery of datagrams for point-
to-point as well as for multicast communications. UDP does to-point as well as for multicast communications. UDP does
not support congestion control or error repair. The RTCP- not support congestion control or error repair. The RTCP-
based feedback defined in this memo is able to provide based feedback defined in this memo is able to provide
minimal support for congestion control for RTP-over-UDP minimal support for limited error repair. As RTCP feedback
traffic as well as for limited error repair. It should be is not guaranteed to operate on sufficiently small
noted, however, that RTCP feedback does not operate on RTT timescales (in the order of RTT), RTCP feedback is not
timescales. This memo addresses both unicast and multicast suitable to support congestion control. This memo
operation. addresses both unicast and multicast operation.
DCCP: DCCP [19] provides for congestion-controlled but unreliable DCCP: DCCP [19] provides for congestion-controlled but unreliable
datagram flows for unicast communications. With TFRC-based datagram flows for unicast communications. With TFRC-based
[20] congestion control (CCID 3), DCCP is particularly [20] congestion control (CCID 3), DCCP is particularly
suitable for audio and video communications. DCCP's suitable for audio and video communications. DCCP's
acknowledgement messages may provide detailed feedback acknowledgement messages may provide detailed feedback
reporting about received and missed datagrams (and thus reporting about received and missed datagrams (and thus
about congestion). RTCP-based feedback using the Generic about congestion).
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 When running RTP over DCCP, congestion control is performed
at the DCCP layer and no additional mechanisms are required at the DCCP layer and no additional mechanisms are required
at the RTP layer. Furthermore, an RTCP-feedback capable at the RTP layer. Furthermore, an RTCP-feedback capable
sender may leverage the more frequent DCCP-based feedback sender may leverage the more frequent DCCP-based feedback
and thus a receiver may abstain from using (additional) and thus a receiver may abstain from using (additional)
Generic Feedback messages where appropriate. Generic Feedback messages where appropriate.
3 Rules for RTCP Feedback 3 Rules for RTCP Feedback
skipping to change at page 23, line 21 skipping to change at page 23, line 38
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 4) The type of RTCP feedback sent should not duplicate information
available to the sender from a lower layer transport protocol. available to the sender from a lower layer transport protocol.
That is, if the transport protocol provides negative or positive That is, if the transport protocol provides negative or positive
acknowledgements about packet reception (such as DCCP), the acknowledgements about packet reception (such as DCCP), the
receiver should avoid repeating the same information at the RTCP receiver should avoid repeating the same information at the RTCP
layer (i.e. abstain from sending Generic ACKs or Generic NACKs). layer (i.e. abstain from sending 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
skipping to change at page 26, line 18 skipping to change at page 26, line 40
The literals of the above grammar have the following semantics: The literals of the above grammar have the following semantics:
Feedback type "ack": Feedback type "ack":
This feedback type indicates that positive acknowledgements This feedback type indicates that positive acknowledgements
for feedback are supported. for feedback are supported.
The feedback type "ack" MUST only be used if the media session The feedback type "ack" MUST only be used if the media session
is allowed to operate in ACK mode as defined in 3.6.1.2. is allowed to operate in ACK mode as defined in 3.6.1.2.
Parameters MAY be provided to further distinguish different Parameters MUST be provided to further distinguish different
types of positive acknowledgement feedback. If no parameters types of positive acknowledgement feedback.
are present, the Generic ACK as specified in section 6.2.2 is
implied.
The parameter "rpsi" indicates the use of Reference Picture The parameter "rpsi" indicates the use of Reference Picture
Selection Indication feedback as defined in section 6.3.3. Selection Indication feedback as defined in section 6.3.3.
If the parameter "app" is specified, this indicates the use of If the parameter "app" is specified, this indicates the use of
application layer feedback. In this case, additional application layer feedback. In this case, additional
parameters following "app" MAY be used to further parameters following "app" MAY be used to further
differentiate various types of application layer feedback. differentiate various types of application layer feedback.
This document does not define any parameters specific to This document does not define any parameters specific to
"app". "app".
skipping to change at page 28, line 16 skipping to change at page 28, line 34
Applications operating knowingly over highly asymmetric links (such Applications operating knowingly over highly asymmetric links (such
as satellite links) SHOULD use this mechanism to reduce the as satellite links) SHOULD use this mechanism to reduce the
feedback rate for high bandwidth streams to prevent deterministic feedback rate for high bandwidth streams to prevent deterministic
congestion of the feedback path(s). congestion of the feedback path(s).
4.4 Examples 4.4 Examples
Example 1: The following session description indicates a session Example 1: The following session description indicates a session
made up from audio and DTMF [18] for point-to-point communication made up from audio and DTMF [18] for point-to-point communication
in which the DTMF stream uses Generic ACKs. This session in which the DTMF stream uses Generic NACKs. This session
description could be contained in a SIP INVITE, 200 OK, or ACK description could be contained in a SIP INVITE, 200 OK, or ACK
message to indicate that its sender is capable of and willing to message to indicate that its sender is capable of and willing to
receive feedback for the DTMF stream it transmits. receive feedback for the DTMF stream it transmits.
v=0 v=0
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 nack
This allows sender and receiver to provide reliable transmission of This allows sender and receiver to provide reliable transmission of
DTMF events in an audio session. Assuming a 64kbit/s audio stream DTMF events in an audio session. Assuming a 64kbit/s audio stream
with one receiver, the receiver has 2.5% RTCP bandwidth available with one receiver, the receiver has 2.5% RTCP bandwidth available
for the acknowledgment stream, i.e. 250 bytes per second or some 2 for the negative acknowledgment stream, i.e. 250 bytes per second
RTCP feedback message. Hence, the receiver can individually or some 2 RTCP feedback messages every second. Hence, the receiver
confirm receipt of two DTMF digits per seconds. can individually communicate up to two missing DTMF audio packets
per second.
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
skipping to change at page 31, line 35 skipping to change at page 32, line 4
6 Format of RTCP Feedback Messages 6 Format of RTCP Feedback Messages
This section defines the format of the low delay RTCP feedback This section defines the format of the low delay RTCP feedback
messages. These messages are classified into three categories as messages. These messages are classified into three categories as
follows: follows:
- Transport layer FB messages - Transport layer FB messages
- Payload-specific FB messages - Payload-specific FB messages
- Application layer FB messages - Application layer FB messages
Transport layer FB messages are intended to transmit general Transport layer FB messages are intended to transmit general
purpose feedback information, i.e. information independent of the purpose feedback information, i.e. information independent of the
particular codec or the application in use. The information is particular codec or the application in use. The information is
expected to be generated and processed at the transport/RTP layer. expected to be generated and processed at the transport/RTP layer.
Currently, only a general positive acknowledgement (ACK) and a Currently, only a generic negative acknowledgement (NACK) message
negative acknowledgement (NACK) message are defined. is defined.
Payload-specific FB messages transport information that is specific Payload-specific FB messages transport information that is specific
to a certain payload type and will be generated and acted upon at to a certain payload type and will be generated and acted upon at
the codec "layer". This document defines a common header to be the codec "layer". This document defines a common header to be
used in conjunction with all payload-specific FB messages. The used in conjunction with all payload-specific FB messages. The
definition of specific messages is left to either RTP payload definition of specific messages is left to either RTP payload
format specifications or to additional feedback format documents. format specifications or to additional feedback format documents.
Application layer FB messages provide a means to transparently Application layer FB messages provide a means to transparently
convey feedback from the receiver's to the sender's application. convey feedback from the receiver's to the sender's application.
skipping to change at page 34, line 19 skipping to change at page 34, line 39
i.e. same FMT. If multiple types of feedback messages, i.e. i.e. same FMT. If multiple types of feedback messages, i.e.
several FMTs, need to be conveyed, then several RTCP FB messages several FMTs, need to be conveyed, then several RTCP FB messages
MUST be generated and SHOULD be concatenated in the same compound MUST be generated and SHOULD be concatenated in the same compound
RTCP packet. RTCP packet.
6.2 Transport Layer Feedback Messages 6.2 Transport Layer Feedback Messages
Transport Layer FB messages are identified by the value RTPFB as Transport Layer FB messages are identified by the value RTPFB as
RTCP message type. RTCP message type.
Two general purpose transport layer FB messages are defined so far: A single general purpose transport layer FB messages are defined so
General ACK and General NACK. They are identified by means of the far: Generic NACK. It is identified by means of the FMT parameter
FMT parameter as follows: as follows:
0: unassigned 0: unassigned
1: Generic NACK 1: Generic NACK
2: Generic ACK 2-30: unassigned
3-30: unassigned
31: reserved for future expansion of the identifier number 31: reserved for future expansion of the identifier number
space space
The following two subsections define the formats of the FCI field The following subsection defines the formats of the FCI field for
for these types of FB messages: this type of FB message. Further generic feedback messages MAY be
defined in the future.
6.2.1 Generic NACK 6.2.1 Generic NACK
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
skipping to change at page 35, line 41 skipping to change at page 36, line 11
simply because bits 2 through 15 of the BLP are 0; all the simply because bits 2 through 15 of the BLP are 0; all the
sender knows is that the receiver has not reported them as lost sender knows is that the receiver has not reported them as lost
at this time. at this time.
The length of the FB message MUST be set to 2+n, with n being the The length of the FB message MUST be set to 2+n, with n being the
number of Generic NACKs contained in the FCI field. number of Generic NACKs contained in the FCI field.
The Generic NACK message implicitly references the payload type The Generic NACK message implicitly references the payload type
through the sequence number(s). through the sequence number(s).
6.2.2 Generic ACK
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
one Generic ACK.
The Generic ACK packet is used to indicate that one or several RTP
packets were received correctly. The received packet(s) are
identified by the means of a packet identifier and a bit mask.
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |R| BLP/#packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Syntax for the Generic ACK message
Packet ID (1st PID): 16 bits
This PID field is used to specify a correctly received packet.
The PID field refers to the RTP sequence number of the lost
packet.
Range of ACKs (R): 1 bit
The R-bit indicates that a range of consecutive packets are
received correctly. If R=1 then the PID field specifies the
first packet of that range and the next field (BLP/#packets)
will carry the number of packets being acknowledged. If R=0
then PID specifies the first packet to be acknowledged and
BLP/#packets provides a bit mask to selectively indicate
individual packets that are acknowledged.
Bit mask of lost packets (BLP)/#packets (PID): 15 bits
The semantics of this field depends on the value of the R-bit.
If R=1, this field is used to identify the number of additional
packets of to be acknowledged:
#packets = <highest seq# to be ACKed> - <PID>
That is, #packets MUST indicate the number of packet to be
ACKed minus one. In particular, if only a single packet is to
be ACKed and R=1 then #packets MUST be set to 0x0000.
Example: If all packets between and including PIDx = 380 and
PIDy = 422 have been received, the Generic ACK would contain
PID = PIDx = 380 and #packets = PIDy - PID = 42. In case the
PID wraps around, modulo arithmetic is used to calculate the
number of packets.
If R=0, this field carries a bit mask. The BLP allows for
reporting reception of any of the 15 RTP packets immediately
following the RTP packet indicated by the PID. The BLP's
definition is identical to that given in [6] except that, here,
BLP is only 15 bits wide. Denoting the BLP's least significant
bit as bit 1, and its most significant bit as bit 15, then bit
i of the bitmask is set to 1 if the receiver has received RTP
packet number (PID+i) (modulo 2^16) and decides to ACK this
packet; bit i is set to 0 otherwise. If only the packet
indicated by PID is to be ACKed and R=0 then BLP MUST be set to
0x0000.
The length of the FB message MUST be set to 2+n, with n being the
number of Generic ACKs contained in the FCI field.
The Generic ACK message implicitly references the payload type
through the sequence number(s).
6.3 Payload Specific Feedback Messages 6.3 Payload Specific Feedback Messages
Payload-Specific FB messages are identified by the value PT=PSFB as Payload-Specific FB messages are identified by the value PT=PSFB as
RTCP message type. RTCP message type.
Three payload-specific FB messages are defined so far plus an Three payload-specific FB messages are defined so far plus an
application layer FB message. They are identified by means of the application layer FB message. They are identified by means of the
FMT parameter as follows: FMT parameter as follows:
0: unassigned 0: unassigned
skipping to change at page 44, line 9 skipping to change at page 43, line 9
In the previous sections, the FB messages were defined as well as In the previous sections, the FB messages were defined as well as
the timing rules according to which to send these messages. The the timing rules according to which to send these messages. The
way to react to the feedback received depends on the application way to react to the feedback received depends on the application
using the feedback mechanisms and hence is beyond the scope of this using the feedback mechanisms and hence is beyond the scope of this
document. document.
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 It should be noted that RTCP feedback itself is insufficient for
algorithms in two ways: congestion control purposes as it is likely to operate at much
o The potentially more frequent RTCP packets allow the sender to
monitor the network state more closely than with Regular RTCP
packets and therefore enable a more timely reaction to upcoming
congestion.
o The FB messages themselves may convey additional information as
input to congestion control algorithms and thus improve reaction
over conventional RTCP. (For example, ACK-based feedback may
even allow to construct closed loop algorithms and NACK-based
systems may provide further information on the packet loss
distribution.)
It should be noted, however, that RTCP feedback may operate at much
slower timescales than other transport layer feedback mechanisms slower timescales than other transport layer feedback mechanisms
(that usually operate in the order of RTT). Therefore, any rate (that usually operate in the order of RTT). Therefore, additional
adaptation may occur slower than TCP. mechanisms are required to perform proper congestion control.
A congestion control algorithm that shares the available bandwidth A congestion control algorithm that shares the available bandwidth
reasonably fairly with competing TCP connections, e.g. TFRC [8], reasonably fairly with competing TCP connections, e.g. TFRC [8],
MUST be used to determine the data rate for the media stream within MUST be used to determine the data rate for the media stream within
the bounds of the RTP sender's and the media session's capabilities the bounds of the RTP sender's and the media session's capabilities
if the RTP/AVPF session is transmitted in a best effort if the RTP/AVPF session is transmitted in a best effort
environment. environment.
That is, RTCP FB messages or RTCP SR/RR packets that indicate
recent packet loss SHOULD cause the sender to adjust the
transmission data rate to the order of the throughput TCP would
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
feedback to be provided by receivers. Group members of the feedback to be provided by receivers. Group members of the
skipping to change at page 49, line 5 skipping to change at page 47, line 13
Reference: RFC XXXX. Reference: RFC XXXX.
As AVPF defines additional RTCP payload types, the corresponding As AVPF defines additional RTCP payload types, the corresponding
"reserved" RTP payload type space (72--76, as defined in [2]), "reserved" RTP payload type space (72--76, as defined in [2]),
needs to be expanded accordingly. needs to be expanded accordingly.
A new sub-registry needs to be set up for the FMT values for both A new sub-registry needs to be set up for the FMT values for both
the RTPFB payload type and the PSFB payload type, with the the RTPFB payload type and the PSFB payload type, with the
following registrations created initially: following registrations created initially:
Within the RTPFB range, the following three format (FMT) values are Within the RTPFB range, the following two format (FMT) values are
initially registered: initially registered:
Name: Generic NACK Name: Generic NACK
Long name: Generic negative acknowledgement Long name: Generic negative acknowledgement
Value: 1 Value: 1
Reference: RFC XXXX. Reference: RFC XXXX.
Name: Generic ACK
Long name: Generic positive acknowledgement
Value: 2
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.
Within the PSFB range, the following five format (FMT) values are Within the PSFB range, the following five format (FMT) values are
initially registered: initially registered:
Name: PLI Name: PLI
Long name: Picture Loss Indication Long name: Picture Loss Indication
skipping to change at page 50, line 39 skipping to change at page 49, line 18
11 Authors' Addresses 11 Authors' Addresses
Joerg Ott {sip,mailto}:jo@tzi.org Joerg Ott {sip,mailto}:jo@tzi.org
Uni Bremen TZI Uni Bremen TZI
MZH 5180 MZH 5180
Bibliothekstr. 1 Bibliothekstr. 1
D-28359 Bremen D-28359 Bremen
Germany Germany
Stephan Wenger stewe@cs.tu-berlin.de Stephan Wenger stewe@stewe.org
TU Berlin TU Berlin
Sekr. FR 6-3 Sekr. FR 6-3
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
skipping to change at page 51, line 20 skipping to change at page 49, line 48
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," RFC 3550, - A Transport Protocol for Real-time Applications," RFC 3550
July 2003. (STD0064), July 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," RFC 3551, July 2003. Conferences with Minimal Control," RFC 3551 (STD0065), July
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-15.txt, October 2003. new-18.txt, June 2004.
[4] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", RFC [4] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", RFC
3556, July 2003. 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.
skipping to change at page 52, line 7 skipping to change at page 50, line 37
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.
[10] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA [10] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs," RFC 2434, October 1998. Considerations Section in RFCs," RFC 2434, October 1998.
12.2 Informative References 12.2 Informative References
[11] C. Perkins and O. Hodson, "Options for Repair of [11] C. Perkins and O. Hodson, "Options for Repair of Streaming
Streaming Media," RFC 2354, June 1998. 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 52, line 35 skipping to change at page 51, line 18
[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 [19] E. Kohler, M. Handley, and S. Floyd, "Datagram Congestion
Congestion Control Protocol (DCCP)," Internet Draft draft- Control Protocol (DCCP)," Internet Draft draft-ietf-dccp-spec-
ietf-dccp-spec-05.txt, Work in Progress, October 2003. 06.txt, Work in Progress, February 2004.
[20] M. Handley, S. Floyd, J. Padhye, and J. Widmer, "TCP Friendly [20] M. Handley, S. Floyd, J. Padhye, and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification," RFC 3448, Rate Control (TFRC): Protocol Specification," RFC 3448,
January 2003. January 2003.
[21] J. Ott and E. Carrara, "Extended Secure RTP Profile for RTCP- [21] J. Ott and E. Carrara, "Extended Secure RTP Profile for RTCP-
based Feedback (RTP/SAVPF)," Internet Draft draft-ietf-avt- based Feedback (RTP/SAVPF)," Internet Draft draft-ietf-avt-
profile-savpf-00.txt, Work in Progress, October 2003. profile-savpf-01.txt, Work in Progress, July 2004.
[22] M. Baugher, R. Blom, E. Carrarra, D. McGrew, M. Naslund, K. [22] M. Baugher, D. McGrew, M. Naslund, E. Carrarra, and K.
Norrman, D. Oran, "The Secure Real-Time Transport Protocol," Norrman, "The Secure Real-Time Transport Protocol," RFC 3711,
Internet Draft, draft-ietf-avt-srtp-09.txt, Work in Progress, March 2004.
June 2003.
13 IPR Notice 13 Intellectual Property 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 Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; neither does it represent that it rights might or might not be available; nor does it represent that
has made any effort to identify any such rights. Information on it has made any independent effort to identify any such rights.
the IETF's procedures with respect to rights in standards-track and Information on the procedures with respect to rights in RFC
standards-related documentation can be found in BCP-11. Copies of documents can be found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made Copies of IPR disclosures made to the IETF Secretariat and any
to obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification attempt made to obtain a general license or permission for the use
can be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF this standard. Please address the information to the IETF at ietf-
Executive Director. ipr@ietf.org.
14 Full Copyright Statement 14 Disclaimer of Validity
Copyright (C) The Internet Society (2003). All Rights Reserved. This document and the information contained herein are provided on
This document and translations of it may be copied and furnished to an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
others, and derivative works that comment on or otherwise explain REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
it or assist in its implementation may be prepared, copied, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
published and distributed, in whole or in part, without restriction EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
of any kind, provided that the above copyright notice and this THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
paragraph are included on all such copies and derivative works. ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
However, this document itself may not be modified in any way, such 15 Full Copyright Statement
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be Copyright (C) The Internet Society (2004). This document is
revoked by the Internet Society or its successors or assigns. 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 is provided on 16 Acknowledgment
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR Funding for the RFC Editor function is currently provided by the
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF Internet Society.
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
 End of changes. 

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