RTP/RTCP协议文档3551

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

Network Communication Protocol Map. To order: http://www.javvin.com/map.html

Easy to use sniffing tool: http://www.javvin.com/packet.html

Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

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

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

4.5 Audio Encodings ......................................... 12

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

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

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

parameters or membership control is provided. The profile is

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.

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 described in RFC 2119 [2] and

indicate requirement levels for implementations compliant with this

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

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

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

recommendation 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

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

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

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]