音频AUDIO-G726 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

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 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 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

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 ................................................. 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-Based Audio Encodings ............. 10

4.4 Guidelines for Frame-Based 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.13 MPA ............................................. 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.5 H263-1998 ............................................... 31

5.6 MPV ..................................................... 31

11. IANA Considerations .......................................... 39

12. References ................................................... 39

12.1 Normative References .................................... 39

12.2 Informative References .................................. 39

13. Current Locations of Related Resources ....................... 41

Schulzrinne & Casner Standards Track [Page 2]

RFC 3551 RTP A/V Profile July 2003

14. Acknowledgments .............................................. 42

15. Intellectual Property Rights Statement ....................... 43

16. Authors’ Addresses ........................................... 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 use within audio and video conferences with minimal

session control. In particular, no support for the negotiation of

parameters or membership 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

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.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

audio/video (interleaved).

Schulzrinne & Casner Standards Track [Page 3]

RFC 3551 RTP A/V Profile July 2003

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.

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

active data senders and those which are not. Following the

recommendation in the RTP specification [1] that 1/4 of the RTCP

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.

Schulzrinne & Casner Standards Track [Page 4]

RFC 3551 RTP A/V Profile July 2003

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.

actually being delivered. If it is not, then they SHOULD assume

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

achieving. This condition can be satisfied by implementing

congestion control mechanisms to adapt the transmission rate (or

trip time of the connection. In essence, 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.

Schulzrinne & Casner Standards Track [Page 5]