draft-ietf-avt-profile-new-03.txt   draft-ietf-avt-profile-new-04.txt 
Internet Engineering Task Force AVT WG Internet Engineering Task Force AVT WG
Internet Draft Schulzrinne Internet Draft Schulzrinne
ietf-avt-profile-new-03.txt Columbia U. ietf-avt-profile-new-04.txt Columbia U.
August 7, 1998 November 18, 1998
Expires: February 7, 1999 Expires: May 18, 1999
RTP Profile for Audio and Video Conferences with Minimal Control RTP Profile for Audio and Video Conferences with Minimal Control
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Distribution of this document is unlimited.
ABSTRACT ABSTRACT
This memo describes a profile called "RTP/AVP" for the This memorandum is a revision of RFC 1890 in preparation
use of the real-time transport protocol (RTP), version 2, for advancement from Proposed Standard to Draft Standard
and the associated control protocol, RTCP, within audio status. Readers are encouraged to use the PostScript form
and video multiparticipant conferences with minimal of this draft to see where changes from RFC 1890 are
control. It provides interpretations of generic fields marked by change bars. The revision process is not yet
within the RTP specification suitable for audio and video complete; some changes which have been discussed and
conferences. In particular, this document defines a set tentatively accepted in meetings of the Audio/Video
of default mappings from payload type numbers to Transport working group have not yet been incorporated
encodings. into this draft.
The document also describes how audio and video data may 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 be carried within RTP. It defines a set of standard
encodings and their names when used within RTP. However, encodings and their names when used within RTP. However,
the encoding definitions are independent of the the encoding definitions are independent of the
particular transport mechanism used. The descriptions particular transport mechanism used. The descriptions
provide pointers to reference implementations and the provide pointers to reference implementations and the
detailed standards. This document is meant as an aid for detailed standards. This document is meant as an aid for
implementors of audio, video and other real-time implementors of audio, video and other real-time
multimedia applications. multimedia applications.
Changes Changes
This draft revises RFC 1890. It is fully backwards-compatible with This draft revises RFC 1890. It is fully backwards-compatible with
RFC 1890 and codifies existing practice. It is intended that this RFC 1890 and codifies existing practice. It is intended that this
draft form the basis of a new RFC to obsolete RFC 1890 as it moves to draft form the basis of a new RFC to obsolete RFC 1890 as it moves to
Draft Standard. Draft Standard.
Besides wording clarifications and filling in RFC numbers for payload Besides wording clarifications and filling in RFC numbers for payload
type definitions, this draft adds payload types 4, 16, 17, 18, 19 and type definitions, this draft adds payload types 4, 16, 17, 18, 19 and
34. The PostScript version of this draft contains change bars marking 34. The PostScript version of this draft contains change bars marking
changes make since draft -00. changes to the RFC.
A tentative TCP encapsulation is defined. A tentative TCP encapsulation is defined.
According to Peter Hoddie of Apple, only pre-1994 Macintosh used the According to Peter Hoddie of Apple, only pre-1994 Macintosh used the
22254.54 rate and none the 11127.27 rate. 22254.54 rate and none the 11127.27 rate.
Note to RFC editor: This section is to be removed before publication Note to RFC editor: This section is to be removed before publication
as an RFC. All RFC TBD should be filled in with the number of the RTP as an RFC. All RFC XXXX should be filled in with the number of the
specification RFC submitted for Draft Standard status. RTP specification RFC submitted for Draft Standard status.
1 Introduction 1 Introduction
This profile defines aspects of RTP left unspecified in the RTP This profile defines aspects of RTP left unspecified in the RTP
Version 2 protocol definition (RFC XXXX). This profile is intended Version 2 protocol definition (RFC XXXX). This profile is intended
for the use within audio and video conferences with minimal session for the use within audio and video conferences with minimal session
control. In particular, no support for the negotiation of parameters control. In particular, no support for the negotiation of parameters
or membership control is provided. The profile is expected to be or membership control is provided. The profile is expected to be
useful in sessions where no negotiation or membership control are useful in sessions where no negotiation or membership control are
used (e.g., using the static payload types and the membership used (e.g., using the static payload types and the membership
indications provided by RTCP), but this profile may also be useful in indications provided by RTCP), but this profile may also be useful in
conjunction with a higher-level control protocol. conjunction with a higher-level control protocol.
Use of this profile occurs by use of the appropriate applications; Use of this profile occurs by use of the appropriate applications;
there is no explicit indication by port number, protocol identifier there is no explicit indication by port number, protocol identifier
or the like. Applications such as session directories should refer to or the like. Applications such as session directories should refer
this profile as "RTP/AVP". to this profile as 'RTP/AVP'.
Other profiles may make different choices for the items specified Other profiles may make different choices for the items specified
here. here.
This document also defines a set of payload formats for audio. This document also defines a set of payload formats for audio.
This draft defines the term media type as dividing encodings of audio This draft defines the term media type as dividing encodings of audio
and video content into three classes: audio, video and audio/video and video content into three classes: audio, video and audio/video
(interleaved). (interleaved).
2 RTP and RTCP Packet Forms and Protocol Behavior 2 RTP and RTCP Packet Forms and Protocol Behavior
The section "RTP Profiles and Payload Format Specification" of RFC The section "RTP Profiles and Payload Format Specification" of RFC
TBD enumerates a number of items that can be specified or modified in XXXX enumerates a number of items that can be specified or modified
a profile. This section addresses these items. Generally, this in a profile. This section addresses these items. Generally, this
profile follows the default and/or recommended aspects of the RTP profile follows the default and/or recommended aspects of the RTP
specification. specification.
RTP data header: The standard format of the fixed RTP data header is RTP data header: The standard format of the fixed RTP data header is
used (one marker bit). used (one marker bit).
Payload types: Static payload types are defined in Section 6. Payload types: Static payload types are defined in Section 6.
RTP data header additions: No additional fixed fields are appended to RTP data header additions: No additional fixed fields are appended to
the RTP data header. the RTP data header.
skipping to change at page 5, line 4 skipping to change at page 5, line 13
lower case and replace sequences of characters and non-spacing lower case and replace sequences of characters and non-spacing
accents with a single character, where possible. A minimum length of accents with a single character, where possible. A minimum length of
16 key characters (after applying the transformation) should be 16 key characters (after applying the transformation) should be
enforced by the application, while applications must allow up to 256 enforced by the application, while applications must allow up to 256
characters of input. characters of input.
Underlying protocol: The profile specifies the use of RTP over Underlying protocol: The profile specifies the use of RTP over
unicast and multicast UDP as well as TCP. (This does not unicast and multicast UDP as well as TCP. (This does not
preclude the use of these definitions when RTP is carried by preclude the use of these definitions when RTP is carried by
other lower-layer protocols.) other lower-layer protocols.)
Transport mapping: The standard mapping of RTP and RTCP to Transport mapping: The standard mapping of RTP and RTCP to
transport-level addresses is used. transport-level addresses is used.
Encapsulation: No encapsulation of RTP packets is specified. Encapsulation: No encapsulation of RTP packets is specified.
3 Registering Payload Types 3 Registering Additional Encodings with IANA
This profile defines a set of standard encodings and their payload This profile defines a set of encodings and assigns names to them. It
types when used within RTP. Other encodings and their payload types is expected that additional encodings beyond this set will be defined
are to be registered with the Internet Assigned Numbers Authority in the future. These additional encodings may be registered with the
(IANA). When registering a new encoding/payload type, the following Internet Assigned Numbers Authority (IANA) as explained here.
information should be provided:
o name and description of encoding, in particular the RTP It has been decided in discussions among the AVT and MMUSIC working
timestamp clock rate; the names defined here are 3 or 4 groups and the Area Directors that the encoding names used in this
profile should be registered as MIME subtype names under the "audio"
and "video" MIME types. However, the procedures for doing this have
not been established yet. This work must be completed before this
draft will be ready for publication as an RFC.
The MIME registration procedure needs to be extended to include
additional information specifying how the encoding is used with RTP
which is different from the information required to specify how an
encoding is used in multimedia mail. Determining exactly what
additional information is required is the open issue. At least the
following information should be provided:
o name of the encoding; the names defined here are 3 or 4
characters long to allow a compact representation if needed; characters long to allow a compact representation if needed;
o a description of encoding, including in particular the RTP
timestamp clock rate (or multiple rates for audio encodings
with multiple sampling rates);
o indication of who has change control over the encoding (for o indication of who has change control over the encoding (for
example, ISO, ITU-T, other international standardization example, ISO, ITU-T, other international standardization
bodies, a consortium or a particular company or group of bodies, a consortium or a particular company or group of
companies); companies);
o any operating parameters or profiles; o any operating parameters or profiles;
o a reference to a further description, if available, for o a reference to a further description, if available, for
example (in order of preference) an RFC, a published paper, a example (in order of preference) an RFC, a published paper, a
patent filing, a technical report, documented source code or a patent filing, a technical report, documented source code or a
computer manual; computer manual;
o for proprietary encodings, contact information (postal and o for proprietary encodings, contact information (postal and
email address); email address);
skipping to change at page 5, line 36 skipping to change at page 6, line 14
o any operating parameters or profiles; o any operating parameters or profiles;
o a reference to a further description, if available, for o a reference to a further description, if available, for
example (in order of preference) an RFC, a published paper, a example (in order of preference) an RFC, a published paper, a
patent filing, a technical report, documented source code or a patent filing, a technical report, documented source code or a
computer manual; computer manual;
o for proprietary encodings, contact information (postal and o for proprietary encodings, contact information (postal and
email address); email address);
o the payload type value for this profile, if necessary (see In addition to assigning names to encodings, this profile also also
below). assigns static RTP payload types to some of them. However, the
payload type number space is relatively small and cannot accommodate
Note that not all encodings to be used by RTP need to be assigned a assignments for all existing and future encodings. During the early
static payload type. There will be no additional static payload stages of RTP development, it was necessary to use statically
types assigned beyond the ones described in this document. Non-RTP assigned payload types because no other mechanism had been specified
to bind encodings to payload types. It was anticipated that non-RTP
means beyond the scope of this memo (such as directory services or means beyond the scope of this memo (such as directory services or
invitation protocols) may be used to establish a dynamic mapping invitation protocols) would be specified to establish a dynamic
between a payload type and an encoding ("dynamic payload types"). mapping between a payload type and an encoding. Now, mechanisms for
Applications should first use the range 96 to 127 for dynamic payload defining dynamic payload type bindings have been specified in the
types. Only applications which need to define more than 32 dynamic Session Description Protocol (SDP), RFC 2327 [1], and in other
payload types may redefine codes below 96. Redefining payload types protocols such as ITU-T recommendation H.323/H.245. These mechanisms
below 96 may cause incorrect operation if an attempt is made to join associate the registered name of the encoding/payload format, along
a session without obtaining session description information that with any additional required parameters such as the RTP timestamp
defines the dynamic payload types. clock rate and number of channels, to a payload type number. This
association is effective only for the duration of the RTP session in
which the dynamic payload type binding is made. This association
applies only to the RTP session for which it is made, thus the
numbers can be re-used for different encodings in different sessions
so the number space limitation is avoided.
This profile reserves payload type numbers in the range 96-127
exclusively for dynamic assignment. Applications should first use
values in this range for dynamic payload types. Only applications
which need to define more than 32 dynamic payload types may bind
codes below 96, in which case it is RECOMMENDED that unassigned
payload type numbers be used first. However, the statically assigned
payload types are default bindings and may be dynamically bound to
new encodings if needed. Redefining payload types below 96 may cause
incorrect operation if an attempt is made to join a session without
obtaining session description information that defines the dynamic
payload types.
Dynamic payload types should not be used without a well-defined Dynamic payload types should not be used without a well-defined
mechanism to indicate the mapping. Systems that expect to mechanism to indicate the mapping. Systems that expect to
interoperate with others operating under this profile should not interoperate with others operating under this profile should not make
assign proprietary encodings to particular, fixed payload types in their own assignments of proprietary encodings to particular, fixed
the range reserved for dynamic payload types. The Session Description payload types.
Protocol (SDP), RFC 2327 [1], defines such a mapping mechanism.
The available payload type space is relatively small. Thus, no new This specification establishes the policy that no additional static
static payload types will be assigned beyond the current list. For payload types will be assigned beyond the ones defined in this
implementor convenience, this profile contains descriptions of document. Establishing this policy avoids the problem of trying to
encodings which do not currently have a static payload type assigned create a set of criteria for accepting static assignments and
to them. SDP uses the encoding names defined here. encourages the implementation and deployment of the dynamic payload
type mechanisms.
4 Audio 4 Audio
4.1 Encoding-Independent Rules 4.1 Encoding-Independent Rules
For applications which send either no packets or comfort-noise For applications which send either no packets or comfort-noise
packets during silence, the first packet of a talkspurt, that is, the packets during silence, the first packet of a talkspurt, that is, the
first packet after a silence period, is distinguished by setting the first packet after a silence period, is distinguished by setting the
marker bit in the RTP data header to one. The marker bits in all marker bit in the RTP data header to one. The marker bits in all
other packets is zero. The beginning of a talkspurt may be used to other packets is zero. The beginning of a talkspurt may be used to
skipping to change at page 9, line 5 skipping to change at page 9, line 50
block. That is, for two-channel audio, right and left samples are block. That is, for two-channel audio, right and left samples are
coded independently, with the encoded frame for the left channel coded independently, with the encoded frame for the left channel
preceding that for the right channel. preceding that for the right channel.
All frame-oriented audio codecs should be able to encode and decode All frame-oriented audio codecs should be able to encode and decode
several consecutive frames within a single packet. Since the frame several consecutive frames within a single packet. Since the frame
size for the frame-oriented codecs is given, there is no need to use size for the frame-oriented codecs is given, there is no need to use
a separate designation for the same encoding, but with different a separate designation for the same encoding, but with different
number of frames per packet. number of frames per packet.
RTP packets shall contain a whole number of frames, with frames RTP packets SHALL contain a whole number of frames, with frames
inserted according to age within a packet, so that the oldest frame inserted according to age within a packet, so that the oldest frame
(to be played first) occurs immediately after the RTP packet header. (to be played first) occurs immediately after the RTP packet header.
The RTP timestamp reflects the capturing time of the first sample in The RTP timestamp reflects the capturing time of the first sample in
the first frame, that is, the oldest information in the packet. the first frame, that is, the oldest information in the packet.
4.5 Audio Encodings 4.5 Audio Encodings
name of sampling default name of sampling default
encoding sample/frame bits/sample rate ms/frame ms/packet encoding sample/frame bits/sample rate ms/frame ms/packet
____________________________________________________________________________ ____________________________________________________________________________
skipping to change at page 21, line 10 skipping to change at page 22, line 10
The SX9600P is a low-complexity, toll-quality CELP-based audio codec The SX9600P is a low-complexity, toll-quality CELP-based audio codec
operating at a sampling rate of 8000 Hz. It encodes blocks of 120 operating at a sampling rate of 8000 Hz. It encodes blocks of 120
audio samples (15 ms) into an encoded frame of 18 octets, yielding an audio samples (15 ms) into an encoded frame of 18 octets, yielding an
encoded bit rate of 9600 b/s. encoded bit rate of 9600 b/s.
4.5.19 VDVI 4.5.19 VDVI
VDVI is a variable-rate version of DVI4, yielding speech bit rates of VDVI is a variable-rate version of DVI4, yielding speech bit rates of
between 10 and 25 kb/s. It is specified for single-channel operation between 10 and 25 kb/s. It is specified for single-channel operation
only. Samples are packed into octets starting at the most-significant only. Samples are packed into octets starting at the most-
bit. significant bit.
It uses the following encoding: It uses the following encoding:
DVI4 codeword VDVI bit pattern DVI4 codeword VDVI bit pattern
_________________________________ _________________________________
0 00 0 00
1 010 1 010
2 1100 2 1100
3 11100 3 11100
4 111100 4 111100
skipping to change at page 23, line 31 skipping to change at page 24, line 31
The payload types currently defined in this profile are assigned to The payload types currently defined in this profile are assigned to
exactly one of three categories or media types : audio only, video exactly one of three categories or media types : audio only, video
only and those combining audio and video. A single RTP session only and those combining audio and video. A single RTP session
consists of payload types of one and only media type. consists of payload types of one and only media type.
Session participants agree through mechanisms beyond the scope of Session participants agree through mechanisms beyond the scope of
this specification on the set of payload types allowed in a given this specification on the set of payload types allowed in a given
session. This set may, for example, be defined by the capabilities session. This set may, for example, be defined by the capabilities
of the applications used, negotiated by a conference control protocol of the applications used, negotiated by a conference control protocol
or established by agreement between the human participants. The media or established by agreement between the human participants. The
types in Table 4 are marked as "A" for audio, "V" for video and "AV" media types in Table 4 are marked as "A" for audio, "V" for video and
for combined audio/video streams. "AV" for combined audio/video streams.
Audio applications operating under this profile should, at minimum, Audio applications operating under this profile should, at minimum,
be able to send and receive payload types 0 (PCMU) and 5 (DVI4). This be able to send and receive payload types 0 (PCMU) and 5 (DVI4). This
allows interoperability without format negotiation and successful allows interoperability without format negotiation and successful
negotation with a conference control protocol. negotation with a conference control protocol.
All current video encodings use a timestamp frequency of 90,000 Hz, All current video encodings use a timestamp frequency of 90,000 Hz,
the same as the MPEG presentation time stamp frequency. This the same as the MPEG presentation time stamp frequency. This
frequency yields exact integer timestamp increments for the typical frequency yields exact integer timestamp increments for the typical
24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates 24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates
skipping to change at page 30, line 21 skipping to change at page 31, line 21
PCMU, PCMA PCMU, PCMA
An implementation of these algorithm is available as part of the An implementation of these algorithm is available as part of the
ITU-T STL, described above. Code to convert between linear and mu-law ITU-T STL, described above. Code to convert between linear and mu-law
companded data is also available in [7]. companded data is also available in [7].
Table of Contents Table of Contents
1 Introduction ........................................ 2 1 Introduction ........................................ 2
2 RTP and RTCP Packet Forms and Protocol Behavior ..... 3 2 RTP and RTCP Packet Forms and Protocol Behavior ..... 3
3 Registering Payload Types ........................... 5 3 Registering Additional Encodings with IANA .......... 5
4 Audio ............................................... 6 4 Audio ............................................... 7
4.1 Encoding-Independent Rules .......................... 6 4.1 Encoding-Independent Rules .......................... 7
4.2 Operating Recommendations ........................... 7 4.2 Operating Recommendations ........................... 8
4.3 Guidelines for Sample-Based Audio Encodings ......... 8 4.3 Guidelines for Sample-Based Audio Encodings ......... 8
4.4 Guidelines for Frame-Based Audio Encodings .......... 8 4.4 Guidelines for Frame-Based Audio Encodings .......... 9
4.5 Audio Encodings ..................................... 9 4.5 Audio Encodings ..................................... 10
4.5.1 1016 ................................................ 10 4.5.1 1016 ................................................ 11
4.5.2 CN .................................................. 10 4.5.2 CN .................................................. 11
4.5.3 DVI4 ................................................ 11 4.5.3 DVI4 ................................................ 12
4.5.4 G722 ................................................ 12 4.5.4 G722 ................................................ 13
4.5.5 G723 ................................................ 12 4.5.5 G723 ................................................ 13
4.5.6 G726-16, G726-24, G726-32, G726-40 .................. 13 4.5.6 G726-16, G726-24, G726-32, G726-40 .................. 14
4.5.7 G727-16, G727-24, G727-32, G727-40 .................. 13 4.5.7 G727-16, G727-24, G727-32, G727-40 .................. 14
4.5.8 G728 ................................................ 13 4.5.8 G728 ................................................ 14
4.5.9 G729 ................................................ 14 4.5.9 G729 ................................................ 15
4.5.10 GSM ................................................. 16 4.5.10 GSM ................................................. 17
4.5.10.1 General Packaging Issues ............................ 16 4.5.10.1 General Packaging Issues ............................ 17
4.5.10.2 GSM variable names and numbers ...................... 17 4.5.10.2 GSM variable names and numbers ...................... 18
4.5.11 L8 .................................................. 17 4.5.11 L8 .................................................. 18
4.5.12 L16 ................................................. 17 4.5.12 L16 ................................................. 18
4.5.13 LPC ................................................. 17 4.5.13 LPC ................................................. 18
4.5.14 MPA ................................................. 17 4.5.14 MPA ................................................. 18
4.5.15 PCMA and PCMU ....................................... 17 4.5.15 PCMA and PCMU ....................................... 18
4.5.16 QCELP ............................................... 19 4.5.16 QCELP ............................................... 20
4.5.17 RED ................................................. 20 4.5.17 RED ................................................. 21
4.5.18 SX* ................................................. 20 4.5.18 SX* ................................................. 21
4.5.18.1 SX7300P ............................................. 20 4.5.18.1 SX7300P ............................................. 21
4.5.18.2 SX8300P ............................................. 20 4.5.18.2 SX8300P ............................................. 21
4.5.18.3 SX9600P ............................................. 20 4.5.18.3 SX9600P ............................................. 21
4.5.19 VDVI ................................................ 21 4.5.19 VDVI ................................................ 22
5 Video ............................................... 21 5 Video ............................................... 22
5.1 CelB ................................................ 21 5.1 CelB ................................................ 22
5.2 JPEG ................................................ 21 5.2 JPEG ................................................ 22
5.3 H261 ................................................ 21 5.3 H261 ................................................ 22
5.4 H263 ................................................ 22 5.4 H263 ................................................ 23
5.5 MPV ................................................. 22 5.5 MPV ................................................. 23
5.6 MP2T ................................................ 22 5.6 MP2T ................................................ 23
5.7 MP1S ................................................ 22 5.7 MP1S ................................................ 23
5.8 MP2P ................................................ 22 5.8 MP2P ................................................ 23
5.9 nv .................................................. 22 5.9 nv .................................................. 23
6 Payload Type Definitions ............................ 22 6 Payload Type Definitions ............................ 23
7 RTP over TCP and Similar Byte Stream Protocols ...... 24 7 RTP over TCP and Similar Byte Stream Protocols ...... 25
8 Port Assignment ..................................... 24 8 Port Assignment ..................................... 25
9 Bibliography ........................................ 24 9 Bibliography ........................................ 25
10 Acknowledgements .................................... 27 10 Acknowledgements .................................... 28
11 Address of Author ................................... 27 11 Address of Author ................................... 28
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/