没有合适的资源?快使用搜索试试~ 我知道了~
首页RTP协议-RFC3551
资源详情
资源评论
资源推荐

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. Please 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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a profile called “RTP/AVP” for the use of the real-time transport protocol
(RTP), version 2, and the associated control protocol, RTCP, within audio and video multipartici-
pant 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 set 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 set
of standard encodings and their names when used 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 because two interoperable implementations were not found. The additions to RFC 1890
codify existing practice in the use of payload formats under this profile and include new payload
formats defined since RFC 1890 was published.
Schulzrinne & Casner Standards Track [Page 1]

RFC 3551 RTP A/V Profile July 2003
Table of Contents
1. Introduction 4
1.1 Terminology ........................................ 4
2. RTP and RTCP Packet Forms and Protocol Behavior 4
3. Registering Additional Encodings 6
4. Audio 7
4.1 Encoding-IndependentRules............................... 7
4.2 OperatingRecommendations............................... 9
4.3 GuidelinesforSample-BasedAudioEncodings..................... 9
4.4 GuidelinesforFrame-BasedAudioEncodings ..................... 9
4.5 AudioEncodings ..................................... 10
4.5.1 DVI4........................................ 11
4.5.2 G722........................................ 12
4.5.3 G723........................................ 12
4.5.4 G726-40, G726-32, G726-24, and G726-16 . .................. 15
4.5.5 G728........................................ 16
4.5.6 G729........................................ 16
4.5.7 G729D and G729E . . . . . . . ......................... 18
4.5.8 GSM........................................ 20
4.5.9 GSM-EFR..................................... 23
4.5.10 L8 ......................................... 23
4.5.11 L16......................................... 23
4.5.12 LPC ........................................ 23
4.5.13 MPA........................................ 23
4.5.14 PCMAandPCMU ................................ 24
4.5.15 QCELP ...................................... 24
4.5.16 RED ........................................ 24
4.5.17 VDVI........................................ 24
Schulzrinne & Casner Standards Track [Page 2]

RFC 3551 RTP A/V Profile July 2003
5. Video 25
5.1 CelB ............................................ 26
5.2 JPEG............................................ 26
5.3 H261 ............................................ 26
5.4 H263 ............................................ 26
5.5 H263-1998 . . . . . . ................................... 26
5.6 MPV............................................ 26
5.7 MP2T ........................................... 27
5.8 nv.............................................. 27
6. Payload Type Definitions 27
7. RTP over TCP and Similar Byte Stream Protocols 29
8. Port Assignment 29
9. Changes from RFC 1890 30
10. Security Considerations 32
11. IANA Considerations 33
12. References 33
12.1NormativeReferences................................... 33
12.2InformativeReferences .................................. 33
13. Current Locations of Related Resources 34
14. Acknowledgments 36
15. Intellectual Property Right s Statement 36
16. Authors’ Addresses 37
17. Full Copyright Statement 38
Schulzrinne & Casner Standards Track [Page 3]

RFC 3551 RTP A/V Profile July 2003
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 use within audio and video conferences with
minimal session control. In particular, no support for the negotiation of parameters or member-
ship control is provided. The profile is expected to be useful in sessions where no negotiation or
membership control are used (e.g., using the static payload types and the membership indications
provided by RTCP), but this profile may also be useful in conjunction with a higher-level control
protocol.
Use of this profile may be implicit in the use of the appropriate applications; there may be no
explicit indication by port number, protocol identifier or the like. Applications such as session
directories may use 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 set of encodings and payload formats for audio and video. These
payload format descriptions are included here only as a matter of convenience since they are too
small to warrant separate documents. Use of these payload formats is NOT REQUIRED to use
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 de-
scribed 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 classes: audio, video and audio/video (interleaved).
2. RTP and RTCP Packet Forms and Protocol Behavior
The section “RTP Profiles and Payload Format Specifications” of RFC 3550 enumerates a number
of items that can be specified or modified in a profile. This section addresses these 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 used (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 operat-
ing under this profile may use 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.
Schulzrinne & Casner Standards Track [Page 4]

RFC 3551 RTP A/V Profile July 2003
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 typ es: No additional RTCP packet types are defined by this profile specification.
RTCP report interval: The suggested constants are to be used for the RTCP report interval
calculation. Sessions operating under this profile may specify a separate parameter for the
RTCP traffic bandwidth rather than using the default fraction of the session bandwidth.
The RTCP traffic bandwidth may be divided into two separate session parameters for those
participants which are active data senders and those which are not. Following the recom-
mendation in the RTP specification [1] that 1/4 of the RTCP bandwidth be dedicated to
data senders, the recommended default values for these two parameters would be 1.25%
and 3.75%, respectively. For a particular session, the RTCP bandwidth for non-data-senders
may be set to zero when operating on unidirectional links or for sessions that don’t require
feedback on the quality of reception. The RTCP bandwidth for data senders should be
kept non-zero so that sender reports can still be sent for inter-media synchronization and to
identify the source by CNAME. The means by which the one or two session parameters for
RTCP bandwidth are specified is beyond the scope of this memo.
SR/RR extension: No extension section is defined for the RTCP SR or RR packet.
SDES use: Applications may use any of the SDES items described in the RTP specification.
While CNAME information must be sent every reporting interval, other items should only
be sent every third reporting interval, with NAME sent seven 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 sent in RTCP packets 1, 4, 7, 10,
13, 16, 19, while, say, EMAIL is used in RTCP packet 22.
Security: The RTP default security services 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 used in the context of enhanced network service, for
example, through Integrated Services (RFC 1633) [4] or Differentiated Services (RFC 2475)
[5], or they may be used with best effort service.
If enhanced service is being used, RTP receivers should monitor packet loss to ensure that
the service that was requested is actually being delivered. If it is not, then they should
assume that they are receiving best-effort service and behave accordingly.
If best-effort service is being used, 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 session), or by arranging for a receiver to leave the session if the loss rate
is unacceptably high.
Schulzrinne & Casner Standards Track [Page 5]
剩余37页未读,继续阅读








安全验证
文档复制为VIP权益,开通VIP直接复制

评论2