draft-ietf-avt-rtcp-feedback-09.txt   draft-ietf-avt-rtcp-feedback-10.txt 
INTERNET-DRAFT Joerg Ott/Uni Bremen TZI INTERNET-DRAFT Joerg Ott/Uni Bremen TZI
draft-ietf-avt-rtcp-feedback-09.txt Stephan Wenger/TU Berlin draft-ietf-avt-rtcp-feedback-10.txt Stephan Wenger/TU Berlin
Noriyuki Sato/Oki Noriyuki Sato/Oki
Carsten Burmeister/Matsushita Carsten Burmeister/Matsushita
Jose Rey/Matsushita Jose Rey/Matsushita
16 July 2004 9 August 2004
Expires January 2005 Expires February 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
By submitting this Internet-Draft, each author certifies that any By submitting this Internet-Draft, each author certifies that any
applicable patent or other IPR claims of which the author is aware applicable patent or other IPR claims of which the author is aware
have been disclosed, or will be disclosed, and any of which each have been disclosed, or will be disclosed, and any of which each
author becomes aware will be disclosed, in accordance with RFC 3668 author becomes aware will be disclosed, in accordance with RFC 3668
(BCP 79). (BCP 79).
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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.......................................8 3 Rules for RTCP Feedback.......................................8
3.1 Compound RTCP Feedback Packets...........................8 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...................................16 3.5.1 Initialization...................................15
3.5.2 Early Feedback Transmission......................16 3.5.2 Early Feedback Transmission......................16
3.5.3 Regular RTCP Transmission........................19 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.........................................21 3.6.1 ACK mode.........................................20
3.6.2 NACK mode........................................21 3.6.2 NACK mode........................................21
3.7 Summary of decision steps...............................23 3.7 Summary of decision steps..............................22
3.7.1 General Hints....................................23 3.7.1 General Hints....................................22
3.7.2 Media Session Attributes.........................23 3.7.2 Media Session Attributes.........................23
4 SDP Definitions..............................................24 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................................28 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..............33 6.1 Common Packet Format for Feedback Messages.............32
6.2 Transport Layer Feedback Messages.......................34 6.2 Transport Layer Feedback Messages......................34
6.2.1 Generic NACK.....................................35 6.2.1 Generic NACK.....................................34
6.3 Payload Specific Feedback Messages......................36 6.3 Payload Specific Feedback Messages.....................36
6.3.1 Picture Loss Indication (PLI)....................36 6.3.1 Picture Loss Indication (PLI)....................36
6.3.1.1 Semantics...............................36 6.3.1.1 Semantics...............................36
6.3.1.2 Message Format..........................37 6.3.1.2 Message Format..........................37
6.3.1.3 Timing Rules............................37 6.3.1.3 Timing Rules............................37
6.3.1.4 Remarks.................................37 6.3.1.4 Remarks.................................37
6.3.2 Slice Lost Indication (SLI)......................38 6.3.2 Slice Lost Indication (SLI)......................37
6.3.2.1 Semantics...............................38 6.3.2.1 Semantics...............................38
6.3.2.2 Format..................................38 6.3.2.2 Format..................................38
6.3.2.3 Timing Rules............................39 6.3.2.3 Timing Rules............................39
6.3.2.4 Remarks.................................39 6.3.2.4 Remarks.................................39
6.3.3 Reference Picture Selection Indication (RPSI)....40 6.3.3 Reference Picture Selection Indication (RPSI)....39
6.3.3.1 Semantics...............................40 6.3.3.1 Semantics...............................40
6.3.3.2 Format..................................41 6.3.3.2 Format..................................40
6.3.3.3 Timing Rules............................41 6.3.3.3 Timing Rules............................41
6.4 Application Layer Feedback Messages.....................42 6.4 Application Layer Feedback Messages....................41
7 Early Feedback and Congestion Control........................42 7 Early Feedback and Congestion Control........................42
8 Security Considerations......................................43 8 Security Considerations......................................43
9 IANA Considerations..........................................44 9 IANA Considerations..........................................44
10 Acknowledgements............................................48 10 Acknowledgements............................................48
11 Authors' Addresses..........................................49 11 Authors' Addresses..........................................48
12 Bibliography................................................49 12 Bibliography................................................49
12.1 Normative references...................................49 12.1 Normative references...................................49
12.2 Informative References.................................50 12.2 Informative References.................................50
13 Intellectual Property Notice................................51 13 Disclaimer of Validity......................................51
14 Disclaimer of Validity......................................52 14 Full Copyright Statement....................................51
15 Full Copyright Statement....................................52 15 Acknowledgment..............................................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 15, line 12 skipping to change at page 15, line 12
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
Regular RTCP packet MUST be updated accordingly to a new tn: Regular RTCP packet MUST be updated accordingly to a new tn:
tn=tp+2*T_rr and so MUST tp: tp=tp+T_rr afterwards. This is to tn=tp+2*T_rr and so MUST tp: tp=tp+T_rr afterwards. This is to
ensure that the short-term average RTCP bandwidth used with Early ensure that the short-term average RTCP bandwidth used with Early
feedback does not exceed the bandwidth used without Early feedback does not exceed the bandwidth used without Early feedback.
feedback.
event to event to
report report
detected detected
| |
| RTCP feedback range | RTCP feedback range
| (T_max_fb_delay) | (T_max_fb_delay)
vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) ) vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) )
|---+--------+-------------+-----+------------| |--------+---> |---+--------+-------------+-----+------------| |--------+--->
| | | | ( ( | | | | | ( ( |
skipping to change at page 21, line 18 skipping to change at page 21, line 12
MUST NOT grow, i.e. it MUST be point-to-point communications. MUST NOT grow, i.e. it MUST be point-to-point communications.
Unicast addresses SHOULD be used in the session description. Unicast addresses SHOULD be used in the session description.
For unidirectional as well as bi-directional communication between For unidirectional as well as bi-directional communication between
two parties, 2.5% of the RTP session bandwidth is available for two parties, 2.5% of the RTP session bandwidth is available for
RTCP traffic from the receivers including feedback. For a 64 RTCP traffic from the receivers including feedback. For a 64
kbit/s stream this yields 1,600 bit/s for RTCP. If we assume an kbit/s stream this yields 1,600 bit/s for RTCP. If we assume an
average of 96 bytes (=768 bits) per RTCP packet a receiver can average of 96 bytes (=768 bits) per RTCP packet a receiver can
report 2 events per second back to the sender. If acknowledgments report 2 events per second back to the sender. If acknowledgments
for 10 events are collected in each FB message then 20 events can for 10 events are collected in each FB message then 20 events can
be acknowledged per second. At 256 kbit/s 8 events could be be acknowledged per second. At 256 kbit/s, 8 events could be
reported per second; thus the ACKs may be sent in a finer reported per second; thus the ACKs may be sent in a finer
granularity (e.g. only combining three ACKs per FB message). granularity (e.g. only combining three ACKs per FB message).
From 1 Mbit/s upwards, a receiver would be able to acknowledge each From 1 Mbit/s upwards, a receiver would be able to acknowledge each
individual frame (not packet!) in a 30 fps video stream. individual frame (not packet!) in a 30 fps video stream.
ACK strategies MUST be defined to work properly with these ACK strategies MUST be defined to work properly with these
bandwidth limitations. An indication whether or not ACKs are bandwidth limitations. An indication whether or not ACKs are
allowed for a session and, if so, which ACK strategy should be allowed for a session and, if so, which ACK strategy should be
used, MAY be conveyed by out-of-band mechanisms, e.g. media- used, MAY be conveyed by out-of-band mechanisms, e.g. media-
skipping to change at page 28, line 18 skipping to change at page 28, line 15
Further types of feedback as well as further parameters may be Further types of feedback as well as further parameters may be
defined in other documents. defined in other documents.
It is up to the recipients whether or not they send feedback It is up to the recipients whether or not they send feedback
information and up to the sender(s) (how) to make use of feedback information and up to the sender(s) (how) to make use of feedback
provided. provided.
4.3 RTCP Bandwidth Modifiers 4.3 RTCP Bandwidth Modifiers
The standard RTCP bandwidth assignments as defined in [1] and [2] The standard RTCP bandwidth assignments as defined in [1] and [2]
may be overridden by bandwidth modifiers that explicitly define the MAY be overridden by bandwidth modifiers that explicitly define the
maximum RTCP bandwidth. For use with SDP, such modifiers are maximum RTCP bandwidth. For use with SDP, such modifiers are
specified in [4]: "b=RS:<bw>" and "b=RR:<bw>" MAY be used to assign specified in [4]: "b=RS:<bw>" and "b=RR:<bw>" MAY be used to assign
a different bandwidth (measured in bits per second) to RTP senders a different bandwidth (measured in bits per second) to RTP senders
and receivers, respectively. The precedence rules of [4] apply to and receivers, respectively. The precedence rules of [4] apply to
determine the actual bandwidth to be used by senders and receivers. determine the actual bandwidth to be used by senders and receivers.
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).
skipping to change at page 33, line 38 skipping to change at page 33, line 33
This field identifies the RTP version. The current version is This field identifies the RTP version. The current version is
2. 2.
padding (P): 1 bit padding (P): 1 bit
If set, the padding bit indicates that the packet contains If set, the padding bit indicates that the packet contains
additional padding octets at the end which are not part of the additional padding octets at the end which are not part of the
control information but are included in the length field. control information but are included in the length field.
Feedback message type (FMT): 5 bits Feedback message type (FMT): 5 bits
This field identifies the type of the FB message and is This field identifies the type of the FB message and is
interpreted relative to the type (transport, payload- interpreted relative to the type (transport, payload-specific,
specific, or application layer feedback). The values for each or application layer feedback). The values for each of the
of the three feedback types are defined in the respective three feedback types are defined in the respective sections
sections below. below.
Payload type (PT): 8 bits Payload type (PT): 8 bits
This is the RTCP packet type which identifies the packet as This is the RTCP packet type which identifies the packet as
being an RTCP FB message. Two values are defined (TBA. by being an RTCP FB message. Two values are defined (TBA. by
IANA): IANA):
Name | Value | Brief Description Name | Value | Brief Description
----------+-------+------------------------------------ ----------+-------+------------------------------------
RTPFB | 205 | Transport layer FB message RTPFB | 205 | Transport layer FB message
PSFB | 206 | Payload-specific FB message PSFB | 206 | Payload-specific FB message
skipping to change at page 34, line 46 skipping to change at page 34, line 41
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.
A single general purpose transport layer FB messages are defined so A single general purpose transport layer FB messages are defined so
far: Generic NACK. It is identified by means of the FMT parameter far: Generic NACK. It is identified by means of the FMT parameter
as follows: as follows:
0: unassigned 0: unassigned
1: Generic NACK 1: Generic NACK
2-30: unassigned 2-30: unassigned
31: reserved for future expansion of the identifier number 31: reserved for future expansion of the identifier number space
space
The following subsection defines the formats of the FCI field for The following subsection defines the formats of the FCI field for
this type of FB message. Further generic feedback messages MAY be this type of FB message. Further generic feedback messages MAY be
defined in the future. 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
skipping to change at page 39, line 29 skipping to change at page 39, line 19
fashion. Motion compensation propagates corrupted pixels that are fashion. Motion compensation propagates corrupted pixels that are
not reported as being corrupted. Therefore, the use of the not reported as being corrupted. Therefore, the use of the
algorithm discussed in section 3 is highly recommended. algorithm discussed in section 3 is highly recommended.
6.3.2.4 Remarks 6.3.2.4 Remarks
The term Slice is defined and used here in the sense of MPEG-1 -- a The term Slice is defined and used here in the sense of MPEG-1 -- a
consecutive number of macroblocks in scan order. More recent video consecutive number of macroblocks in scan order. More recent video
coding standards sometimes have a different understanding of the coding standards sometimes have a different understanding of the
term Slice. In H.263 (1998), for example, a concept known as term Slice. In H.263 (1998), for example, a concept known as
"rectangular Slice" exist. The loss of one Rectangular Slice may "rectangular Slice" exists. The loss of one Rectangular Slice may
lead to the necessity of sending more than one SLI in order to lead to the necessity of sending more than one SLI in order to
precisely identify the region of lost/damaged MBs. precisely identify the region of lost/damaged MBs.
The first field of the FCI defines the first macroblock of a The first field of the FCI defines the first macroblock of a
picture as 1 and not, as one could suspect, as 0. This was done to picture as 1 and not, as one could suspect, as 0. This was done to
align this specification with the comparable mechanism available in align this specification with the comparable mechanism available in
H.245. The maximum number of macroblocks in a picture (2**13 or H.245. The maximum number of macroblocks in a picture (2**13 or
8192) corresponds to the maximum picture sizes of most of the ITU-T 8192) corresponds to the maximum picture sizes of most of the ITU-T
and ISO/IEC video codecs. If future video codecs offer larger and ISO/IEC video codecs. If future video codecs offer larger
picture sizes and/or smaller macroblock sizes, then an additional picture sizes and/or smaller macroblock sizes, then an additional
skipping to change at page 41, line 29 skipping to change at page 41, line 9
(RPSI) (RPSI)
PB: 8 bits PB: 8 bits
The number of unused bits required to pad the length of the The number of unused bits required to pad the length of the
RPSI message to a multiple of 32 bits. RPSI message to a multiple of 32 bits.
0: 1 bit 0: 1 bit
MUST be set to zero upon transmission and ignored upon MUST be set to zero upon transmission and ignored upon
reception. reception.
Payload Type: 8 bits Payload Type: 78 bits
Indicates the RTP payload type in the context of which the Indicates the RTP payload type in the context of which the
native RPSI bit string MUST be interpreted. native RPSI bit string MUST be interpreted.
Native RPSI bit string: variable length Native RPSI bit string: variable length
The RPSI information as natively defined by the video codec. The RPSI information as natively defined by the video codec.
Padding: #PB bits Padding: #PB bits
A number of bits set to zero to fill up the contents of the A number of bits set to zero to fill up the contents of the
RPSI message to the next 32 bit boundary. The number of RPSI message to the next 32 bit boundary. The number of
padding bits MUST be indicated by the PB field. padding bits MUST be indicated by the PB field.
skipping to change at page 42, line 21 skipping to change at page 41, line 48
itself allows for stacking (e.g. by means of a fixed size or itself allows for stacking (e.g. by means of a fixed size or
explicit length indicator). explicit length indicator).
These messages are used to transport application defined data These messages are used to transport application defined data
directly from the receiver's to the sender's application. The data directly from the receiver's to the sender's application. The data
that is transported is not identified by the FB message. that is transported is not identified by the FB message.
Therefore, the application MUST be able to identify the messages Therefore, the application MUST be able to identify the messages
payload. payload.
Usually, applications define their own set of messages, e.g. Usually, applications define their own set of messages, e.g.
NEWPRED messages in MPEG-4 [16] or FB messages in H.263/Annex N, U NEWPRED messages in MPEG-4 [16] (carried in RTP packets according
[17]. These messages do not need any additional information from to RFC 3016 [23]) or FB messages in H.263/Annex N, U [17]
the RTCP message. Thus the application message is simply placed (packetized as per RFC 2429 [14]). These messages do not need any
into the FCI field as follows and the length field is set additional information from the RTCP message. Thus the application
accordingly. message is simply placed into the FCI field as follows and the
length field is set accordingly.
Application Message (FCI): variable length Application Message (FCI): variable length
This field contains the original application message that This field contains the original application message that
should be transported from the receiver to the source. The should be transported from the receiver to the source. The
format is application dependent. The length of this field is format is application dependent. The length of this field is
variable. If the application data is not 32-bit-aligned, variable. If the application data is not 32-bit-aligned,
padding bits and bytes must be added. Identification of padding bits and bytes must be added. Identification of
padding is up to the application layer and not defined in this padding is up to the application layer and not defined in this
specification. specification.
skipping to change at page 44, line 29 skipping to change at page 44, line 12
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 [22]; as a prerequisite, an appropriate profile as defined in [22]; as a prerequisite, an appropriate
combination of those two profiles (an "SAVPF") is being specified combination of those two profiles (an "SAVPF") is being specified
[21]. [21]. Note that, when employing group authentication (as opposed
to source authentication), the aforementioned attacks may be
carried out by malicious or malfunctioning group members in
possession of the right keying material.
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 49, line 24 skipping to change at page 49, line 4
Bibliothekstr. 1 Bibliothekstr. 1
D-28359 Bremen D-28359 Bremen
Germany Germany
Stephan Wenger stewe@stewe.org 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 sato652@oki.com
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
Carsten Burmeister Carsten Burmeister burmeister@panasonic.de
Panasonic European Laboratories GmbH Panasonic European Laboratories GmbH
Mail burmeister@panasonic.de
Jose Rey Jose Rey rey@panasonic.de
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
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
(STD0064), 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
skipping to change at page 51, line 20 skipping to change at page 50, line 40
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, and S. Floyd, "Datagram Congestion [19] E. Kohler, M. Handley, and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)," Internet Draft draft-ietf-dccp-spec- Control Protocol (DCCP)," Internet Draft draft-ietf-dccp-spec-
06.txt, Work in Progress, February 2004. 076.txt, Work in Progress, February July 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-01.txt, Work in Progress, July 2004. profile-savpf-01.txt, Work in Progress, July 2004.
[22] M. Baugher, D. McGrew, M. Naslund, E. Carrarra, and K. [22] M. Baugher, D. McGrew, M. Naslund, E. Carrarra, and K.
Norrman, "The Secure Real-Time Transport Protocol," RFC 3711, Norrman, "The Secure Real-Time Transport Protocol," RFC 3711,
March 2004. March 2004.
13 Intellectual Property Notice [23] Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, and H. Kimata,
"RTP Payload Format for MPEG-4 Audio/Visual Streams," RFC
3016, November 2000.
13 Disclaimer of Validity
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 Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
skipping to change at page 52, line 11 skipping to change at page 51, line 33
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. 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 that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
14 Disclaimer of Validity 14 Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
15 Full Copyright Statement 15 Acknowledgment
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
16 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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