Network Working Group H. Schulzrinne Request for Comments: 3551 Columbia University Obsoletes: 1890 S. Casner Category: Standards Track Packet Design
July 2003
RTP Profile for Audio and Video Conferences
with Minimal Control
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
辞职信简短improvements. Plea refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
派拼音
and status of this protocol. Distribution of this memo is unlimited.
Network Communication Protocol Map. To order: /map.html Easy to u sniffing tool: /packet.html
Copyright Notice Copyright (C) The Internet Society (2003). All Rights Rerved.
Abstract
This document describes a profile called "RTP/AVP" for the u of the
real-time transport protocol (RTP), version 2, and the associated
天上的星星像什么control protocol, RTCP, within audio and video multiparticipant
conferences with minimal control. It provides interpretations of
generic fields within the RTP specification suitable for audio and
写景满分作文
video conferences. In particular, this document defines a t of
default mappings from payload type numbers to encodings.
This document also describes how audio and video data may be carried
within RTP. It defines a t of standard encodings and their names
when ud within RTP. The descriptions provide pointers to reference
implementations and the detailed standards. This document is meant
as an aid for implementors of audio, video and other real-time
multimedia applications.
This memorandum obsoletes RFC 1890. It is mostly backwards-
compatible except for functions removed becau two interoperable
implementations were not found. The additions to RFC 1890 codify
existing practice in the u of payload formats under this profile
and include new payload formats defined since RFC 1890 was published.
Table of Contents
1. Introduction (3)
1.1 Terminology (3)
2. RTP and RTCP Packet Forms and Protocol Behavior (4)
3. Registering Additional Encodings (6)
4. Audio (8)
背的组词
4.1 Encoding-Independent Rules (8)
4.2 Operating Recommendations (9)
4.3 Guidelines for Sample-Bad Audio Encodings (10)
4.4 Guidelines for Frame-Bad Audio Encodings (11)
4.5 Audio Encodings (12)
4.5.1 DVI4 (13)
4.5.2 G722 (14)
4.5.3 G723 (14)
4.5.4 G726-40, G726-32, G726-24, and G726-16 (18)
4.5.5 G728 (19)
4.5.6 G729 (20)
4.5.7 G729D and G729E (22)
4.5.8 GSM (24)
4.5.9 GSM-EFR (27)
4.5.10 L8 (27)
4.5.11 L16 (27)
4.5.12 LPC (27)
4.5.13 MPA (28)
4.5.14 PCMA and PCMU (28)
4.5.15 QCELP (28)
4.5.16 RED (29)
4.5.17 VDVI (29)
5. Video (30)
5.1 CelB (30)
5.2 JPEG (30)
5.3 H261 (30)
5.4 H263 (31)
5.5 H263-1998 (31)
5.6 MPV (31)
5.7 MP2T (31)
5.8 nv (32)
6. Payload Type Definitions (32)
7. RTP over TCP and Similar Byte Stream Protocols (34)
8. Port Assignment (34)
9. Changes from RFC 1890 (35)
10. Security Considerations (38)
11. IANA Considerations (39)
12. References (39)
12.1 Normative References (39)
12.2 Informative References (39)
13. Current Locations of Related Resources (41)
14. Acknowledgments (42)
15. Intellectual Property Rights Statement (43)
16. Authors' Address (43)
17. Full Copyright Statement (44)
1. Introduction
This profile defines aspects of RTP left unspecified in the RTP
Version 2 protocol definition (RFC 3550) [1]. This profile is
intended for the u within audio and video conferences with minimal ssion control. In particular, no support for the negotiation of
parameters or membership control is provided. The profile is
expected to be uful in ssions where no negotiation or membership control are ud (e.g., using the static payload types and the
membership indications provided by RTCP), but this profile may also be uful in conjunction with a higher-level control protocol.
U of this profile may be implicit in the u of the appropriate
applications; there may be no explicit indication by port number,
protocol identifier or the like. Applications such as ssion
directories may u the name for this profile specified in Section
11.
Other profiles may make different choices for the items specified
here.
This document also defines a t of encodings and payload formats for audio and video. The pa
yload format descriptions are included here only as a matter of convenience since they are too small to warrant parate documents. U of the payload formats is NOT REQUIRED to u this profile. Only the binding of some of the payload formats to static payload type numbers in Tables 4 and 5 is normative.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] and
indicate requirement levels for implementations compliant with this RTP profile.
This document defines the term media type as dividing encodings of
audio and video content into three class: audio, video and
audio/video (interleaved).
2. RTP and RTCP Packet Forms and Protocol Behavior
The ction "RTP Profiles and Payload Format Specifications" of RFC 3550 enumerates a number of items that can be specified or modified in a profile. This ction address the items. Generally, this profile follows the default and/or recommended aspects of the RTP
specification.
RTP data header: The standard format of the fixed RTP data
header is ud (one marker bit).
Payload types: Static payload types are defined in Section 6.
RTP data header additions: No additional fixed fields are
appended to the RTP data header.
RTP data header extensions: No RTP header extensions are
defined, but applications operating under this profile MAY u
such extensions. Thus, applications SHOULD NOT assume that the
RTP header X bit is always zero and SHOULD be prepared to ignore the header extension. If a header extension is defined in the
future, that definition MUST specify the contents of the first 16 bits in such a way that multiple different extensions can be
identified.
RTCP packet types: No additional RTCP packet types are defined
by this profile specification.
RTCP report interval: The suggested constants are to be ud for
the RTCP report interval calculation. Sessions operating under
this profile MAY specify a parate parameter for the RTCP traffic bandwidth rather than using the default fraction of the ssion
bandwidth. The RTCP traffic bandwidth MAY be divided into two
parate ssion parameters for tho participants which are
active data nders and tho which are not. Following the
recommendation in the RTP specification [1] that 1/4 of the RTCP bandwidth be dedicated to data nders, the RECOMMENDED default
values for the two parameters would be 1.25% and 3.75%,
respectively. For a particular ssion, the RTCP bandwidth for
non-data-nders MAY be t to zero when operating on
unidirectional links or for ssions that don't require feedback on the quality of reception. The RTCP bandwidth for data nders SHOULD be kept non-zero so that nder reports can still be nt for inter-media synchronization and to identify the source by
CNAME. The means by which the one or two ssion parameters for RTCP bandwidth are specified is beyond the scope of this memo.
SR/RR extension: No extension ction is defined for the RTCP SR
or RR packet.
SDES u: Applications MAY u any of the SDES items described
in the RTP specification. While CNAME information MUST be nt
every reporting interval, other items SHOULD only be nt every
third reporting interval, with NAME nt ven out of eight times within that slot and the remaining SDES items cyclically taking up the eighth slot, as defined in Section 6.2.2 of the RTP
specification. In other words, NAME is nt in RTCP packets 1, 4, 7, 10, 13, 16, 19, while, say, EMAIL is ud in RTCP packet 22.假如只有三天光明
Security: The RTP default curity rvices are also the default
under this profile.
String-to-key mapping: No mapping is specified by this profile.
Congestion: RTP and this profile may be ud in the context of
enhanced network rvice, for example, through Integrated Services (RFC 1633) [4] or Differentiated Services (RFC 2475) [5], or they may be ud with best effort rvice.
If enhanced rvice is being ud, RTP receivers SHOULD monitor
packet loss to ensure that the rvice that was requested is
actually being delivered. If it is not, then they SHOULD assume that they are receiving best-effort rvice and behave
accordingly.
力之金阁
If best-effort rvice is being ud, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within
acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same
network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing
congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast ssion), or by arranging for a receiver to leave the ssion if the loss
rate is unacceptably high.
The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round-
trip time of the connection. In esnce, this requirement states that it is not acceptable to deploy an application (using RTP or any other transport protocol) on the best-effort Internet which
consumes bandwidth arbitrarily and does not compete fairly with踏实的拼音
TCP within an order of magnitude.
