usually operate in the order of RTT). Therefore, additional
mechanisms are required to perform proper congestion control.
A congestion control algorithm that shares the available bandwidth
reasonably fairly with competing TCP connections, e.g., TFRC [7],
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
if the RTP/AVPF session is transmitted in a best-effort environment.
8. Security Considerations
RTP packets transporting information with the proposed payload format
are subject to the security considerations discussed in the RTP
specification [1] and in the RTP/AVP profile specification [2]. This
profile does not specify any additional security services.
This profile modifies the timing behavior of RTCP and eliminates the
minimum RTCP interval of five seconds and allows for earlier feedback
to be provided by receivers. Group members of the associated RTP
session (possibly pretending to represent a large number of entities)
may disturb the operation of RTCP by sending large numbers of RTCP
packets thereby reducing the RTCP bandwidth available for Regular
RTCP reporting as well as for Early FB messages. (Note that an
entity need not be a member of a multicast group to cause these
effects.) Similarly, malicious members may send very large RTCP
messages, thereby increasing the avg_rtcp_size variable and reducing
the effectively available RTCP bandwidth.
Feedback information may be suppressed if unknown RTCP feedback
packets are received. This introduces the risk of a malicious group
member reducing Early feedback by simply transmitting payload-
specific RTCP feedback packets with random contents that are not
recognized by any receiver (so they will suppress feedback) or by the
sender (so no repair actions will be taken).
A malicious group member can also report arbitrary high loss rates in
the feedback information to make the sender throttle the data
transmission and increase the amount of redundancy information or
take other action to deal with the pretended packet loss (e.g., send
fewer frames or decrease audio/video quality). This may result in a
degradation of the quality of the reproduced media stream.
Finally, a malicious group member can act as a large number of group
members and thereby obtain an artificially large share of the Early
feedback bandwidth and reduce the reactivity of the other group
members -- possibly even causing them to no longer operate in
Immediate or Early feedback mode and thus undermining the whole
purpose of this profile.
Senders as well as receivers SHOULD behave conservatively when
observing strange reporting behavior. For excessive failure
reporting from one or a few receivers, the sender MAY decide to no
longer consider this feedback when adapting its transmission behavior
for the media stream. In any case, senders and receivers SHOULD
still adhere to the maximum RTCP bandwidth but make sure that they
are capable of transmitting at least regularly scheduled RTCP
packets. Senders SHOULD carefully consider how to adjust their
transmission bandwidth when encountering strange reporting behavior;
they MUST NOT increase their transmission bandwidth even if ignoring
suspicious feedback.
Attacks using false RTCP packets (Regular as well as Early ones) can
be avoided by authenticating all RTCP messages. This can be achieved
by using the AVPF profile together with the Secure RTP profile as
defined in [22]; as a prerequisite, an appropriate combination of
those two profiles (an "SAVPF") is being specified [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
The following contact information shall be used for all registrations
included here:
Contact: Joerg Ott
mailto:jo@acm.org
tel:+358-9-451-2460
The feedback profile as an extension to the profile for audio-visual
conferences with minimal control has been registered for the Session
Description Protocol (specifically the type "proto"): "RTP/AVPF".
SDP Protocol ("proto"):
Name: RTP/AVPF
Long form: Extended RTP Profile with RTCP-based Feedback
Type of name: proto
Type of attribute: Media level only
Purpose: RFC 4585
Reference: RFC 4585
SDP Attribute ("att-field"):
Attribute name: rtcp-fb
Long form: RTCP Feedback parameter
Type of name: att-field
Type of attribute: Media level only
Subject to charset: No
Purpose: RFC 4585
Reference: RFC 4585
Values: See this document and registrations below
A new registry has been set up for the "rtcp-fb" attribute, with the
following registrations created initially: "ack", "nack", "trr-int",
and "app" as defined in this document.
Initial value registration for the attribute "rtcp-fb"
Value name: ack
Long name: Positive acknowledgement
Reference: RFC 4585.
Value name: nack
Long name: Negative Acknowledgement
Reference: RFC 4585.
Value name: trr-int
Long name: Minimal receiver report interval
Reference: RFC 4585.
Value name: app
Long name: Application-defined parameter
Reference: RFC 4585.
Further entries may be registered on a first-come first-serve basis.
Each new registration needs to indicate the parameter name and the
syntax of possible additional arguments. For each new registration,
it is mandatory that a permanent, stable, and publicly accessible
document exists that specifies the semantics of the registered
parameter, the syntax and semantics of its parameters as well as
corresponding feedback packet formats (if needed). The general
registration procedures of [3] apply.
For use with both "ack" and "nack", a joint sub-registry has been set
up that initially registers the following values:
Initial value registration for the attribute values "ack" and "nack":
Value name: sli
Long name: Slice Loss Indication
Usable with: nack
Reference: RFC 4585.
Value name: pli
Long name: Picture Loss Indication
Usable with: nack
Reference: RFC 4585.
Value name: rpsi
Long name: Reference Picture Selection Indication
Usable with: ack, nack
Reference: RFC 4585.
Value name: app
Long name: Application layer feedback
Usable with: ack, nack
Reference: RFC 4585.
Further entries may be registered on a first-come first-serve basis.
Each registration needs to indicate the parameter name, the syntax of
possible additional arguments, and whether the parameter is
applicable to "ack" or "nack" feedback or both or some different
"rtcp-fb" attribute parameter. For each new registration, it is
mandatory that a permanent, stable, and publicly accessible document
exists that specifies the semantics of the registered parameter, the
syntax and semantics of its parameters as well as corresponding
feedback packet formats (if needed). The general registration
procedures of [3] apply.
Two RTCP Control Packet Types: for the class of transport layer FB
messages ("RTPFB") and for the class of payload-specific FB messages
("PSFB"). Per Section 6, RTPFB=205 and PSFB=206 have been added to
the RTCP registry.
RTP RTCP Control Packet types (PT):
Name: RTPFB
Long name: Generic RTP Feedback
Value: 205
Reference: RFC 4585.
Name: PSFB
Long name: Payload-specific
Value: 206
Reference: RFC 4585.
As AVPF defines additional RTCP payload types, the corresponding
"reserved" RTP payload type space (72-76, as defined in [2]), has
been expanded accordingly.
A new sub-registry has been set up for the FMT values for both the
RTPFB payload type and the PSFB payload type, with the following
registrations created initially:
Within the RTPFB range, the following two format (FMT) values are
initially registered:
Name: Generic NACK
Long name: Generic negative acknowledgement
Value: 1
Reference: RFC 4585.
Name: Extension
Long name: Reserved for future extensions
Value: 31
Reference: RFC 4585.
Within the PSFB range, the following five format (FMT) values are
initially registered:
Name: PLI
Long name: Picture Loss Indication
Value: 1
Reference: RFC 4585.
Name: SLI
Long name: Slice Loss Indication
Value: 2
Reference: RFC 4585.
Name: RPSI
Long name: Reference Picture Selection Indication
Value: 3
Reference: RFC 4585.
Name: AFB
Long name: Application Layer Feedback
Value: 15
Reference: RFC 4585.
Name: Extension
Long name: Reserved for future extensions.
Value: 31
Reference: RFC 4585.
Further entries may be registered following the "Specification
Required" rules as defined in RFC 2434 [9]. Each registration needs
to indicate the FMT value, if there is a specific FB message to go
into the FCI field, and whether or not multiple FB messages may be
stacked in a single FCI field. For each new registration, it is
mandatory that a permanent, stable, and publicly accessible document
exists that specifies the semantics of the registered parameter as
well as the syntax and semantics of the associated FB message (if
any). The general registration procedures of [3] apply.
10. Acknowledgements
This document is a product of the Audio-Visual Transport (AVT)
Working Group of the IETF. The authors would like to thank Steve
Casner and Colin Perkins for their comments and suggestions as well
as for their responsiveness to numerous questions. The authors would
also like to particularly thank Magnus Westerlund for his review and
his valuable suggestions and Shigeru Fukunaga for the contributions
on FB message formats and semantics.
We would also like to thank Andreas Buesching and people at Panasonic
for their simulations and the first independent implementations of
the feedback profile.
11. References
11.1. Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video
Streams", RFC 2032, October 1996.
[7] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification", RFC 3448, January
2003.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
11.2. Informative References
[10] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[11] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.
[12] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[13] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[14] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C.,
Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. Zhu, "RTP
Payload Format for the 1998 Version of ITU-T Rec. H.263 Video
(H.263+)", RFC 2429, October 1998.
[15] B. Girod, N. Faerber, "Feedback-based error control for mobile
video transmission", Proceedings IEEE, Vol. 87, No. 10, pp.
1707 - 1723, October, 1999.
[16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology -
Coding of audio-visual objects - Part2: Visual", 2001.
[17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate
Communication", November 2000.
[18] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[19] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
[20] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification", RFC 3448, January
2003.
[21] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-
based Feedback (RTP/SAVPF)", Work in Progress, December 2005.
[22] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[23] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H.
Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams",
RFC 3016, November 2000.
[24] ITU-T Recommendation H.245, "Control protocol for multimedia
communication", May 2006.
Authors’ Addresses
Joerg Ott
Helsinki University of Technology (TKK)
Networking Laboratory
PO Box 3000
FIN-02015 TKK
Finland
EMail: jo@acm.org
Stephan Wenger
Nokia Research Center
P.O. Box 100
33721 Tampere
Finland
EMail: stewe@stewe.org
Noriyuki Sato
Oki Electric Industry Co., Ltd.
1-16-8 Chuo, Warabi-city, Saitama 335-8510
Japan
Phone: +81 48 431 5932
Fax: +81 48 431 9115
EMail: sato652@oki.com
Carsten Burmeister
Panasonic R&D Center Germany GmbH
EMail: carsten.burmeister@eu.panasonic.com
Jose Rey
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
EMail: jose.rey@eu.panasonic.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).