draft-ietf-avt-profile-new-01.txt   draft-ietf-avt-profile-new-02.txt 
Internet Engineering Task Force AVT WG Internet Engineering Task Force AVT WG
Internet Draft Schulzrinne Internet Draft Schulzrinne
ietf-avt-profile-new-01.txt Columbia U. ietf-avt-profile-new-02.txt Columbia U.
July 29, 1997 November 20, 1997
Expires: January 1, 1998 Expires: January 1, 1998
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 learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, 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), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). 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 memo describes a profile called ''RTP/AVP'' for the
use of the real-time transport protocol (RTP), version 2, use of the real-time transport protocol (RTP), version 2,
and the associated control protocol, RTCP, within audio and the associated control protocol, RTCP, within audio
and video multiparticipant conferences with minimal and video multiparticipant conferences with minimal
control. It provides interpretations of generic fields control. It provides interpretations of generic fields
within the RTP specification suitable for audio and video within the RTP specification suitable for audio and video
conferences. In particular, this document defines a set conferences. In particular, this document defines a set
of default mappings from payload type numbers to of default mappings from payload type numbers to
encodings. encodings.
The document also describes how audio and video data may The document also describes how audio and video data may
skipping to change at page 5, line 30 skipping to change at page 5, line 30
timestamp clock rate; the names defined here are 3 or 4 timestamp clock rate; 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 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 oa reference to a further description, if available, for example
example (in order of preference) an RFC, a published paper, a (in order of preference) an RFC, a published paper, a patent
patent filing, a technical report, documented source code or a 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 o the payload type value for this profile, if necessary (see
below). below).
Note that not all encodings to be used by RTP need to be assigned a Note that not all encodings to be used by RTP need to be assigned a
static payload type. Non-RTP means beyond the scope of this memo static payload type. Non-RTP means beyond the scope of this memo
skipping to change at page 6, line 16 skipping to change at page 6, line 16
defined mechanism to indicate the mapping. Systems that expect to defined 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
assign proprietary encodings to particular, fixed payload types in assign proprietary encodings to particular, fixed payload types in
the range reserved for dynamic payload types. SDP (RFC XXXX ) defines the range reserved for dynamic payload types. SDP (RFC XXXX ) defines
such a mapping mechanism. such a mapping mechanism.
The available payload type space is relatively small. Thus, new The available payload type space is relatively small. Thus, new
static payload types are assigned only if the following conditions static payload types are assigned only if the following conditions
are met: are met:
o The encoding is of interest to the Internet community at oThe encoding is of interest to the Internet community at large.
large.
o It offers benefits compared to existing encodings and/or is o It offers benefits compared to existing encodings and/or is
required for interoperation with existing, widely deployed required for interoperation with existing, widely deployed
conferencing or multimedia systems. conferencing or multimedia systems.
o The description is sufficient to build a decoder. o The description is sufficient to build a decoder.
For implementor convenience, this profile contains descriptions of For implementor convenience, this profile contains descriptions of
encodings which do not currently have a static payload type assigned encodings which do not currently have a static payload type assigned
to them. to them.
The Session Description Protocol (SDP) (RFC XXXX) uses the encoding The Session Description Protocol (SDP) (RFC XXXX) uses the encoding
names defined here. names defined here.
4 Audio 4 Audio
4.1 Encoding-Independent Rules 4.1 Encoding-Independent Rules
For applications which send no packets during silence, the first For applications which send either no packets or comfort-noise
packet of a talkspurt, that is, the first packet after a silence packets during silence, the first packet of a talkspurt, that is, the
period, is distinguished by setting the marker bit in the RTP data first packet after a silence period, is distinguished by setting the
header to one. The marker bits in all other packets is zero. The marker bit in the RTP data header to one. The marker bits in all
beginning of a talkspurt may be used to adjust the playout delay to other packets is zero. The beginning of a talkspurt may be used to
reflect changing network delays. Applications without silence adjust the playout delay to reflect changing network delays.
suppression set the bit to zero. Applications without silence suppression set the bit to zero.
The RTP clock rate used for generating the RTP timestamp is The RTP clock rate used for generating the RTP timestamp is
independent of the number of channels and the encoding; it equals the independent of the number of channels and the encoding; it equals the
number of sampling periods per second. For !N!-channel encodings, number of sampling periods per second. For !N!-channel encodings,
each sampling period (say, 1/8000 of a second) generates !N! samples. each sampling period (say, 1/8000 of a second) generates !N! samples.
(This terminology is standard, but somewhat confusing, as the total (This terminology is standard, but somewhat confusing, as the total
number of samples generated per second is then the sampling rate number of samples generated per second is then the sampling rate
times the channel count.) times the channel count.)
If multiple audio channels are used, channels are numbered left-to- If multiple audio channels are used, channels are numbered left-to-
skipping to change at page 10, line 37 skipping to change at page 10, line 37
MPA frame N/A var. 20 MPA frame N/A var. 20
PCMA sample 8 var. 20 PCMA sample 8 var. 20
PCMU sample 8 var. 20 PCMU sample 8 var. 20
SX7300P frame N/A 8,000 15 30 SX7300P frame N/A 8,000 15 30
SX8300P frame N/A 8,000 15 30 SX8300P frame N/A 8,000 15 30
VDVI sample var. var. 20 VDVI sample var. var. 20
Table 1: Properties of Audio Encodings (N/A: not applicable; var.: Table 1: Properties of Audio Encodings (N/A: not applicable; var.:
variable) variable)
The noise level is expressed in dBov, with values from 0 to 63 dBov. The noise level is expressed in dBov, with values from 0 to 127 dBov.
dBov is the level relative to the overload of the system. (Note: dBov is the level relative to the overload of the system. (Note:
Representation relative to the overload point of a system is Representation relative to the overload point of a system is
particularly useful for digital implementations, since one does not particularly useful for digital implementations, since one does not
need to know the relative calibration of the analog circuitry.) need to know the relative calibration of the analog circuitry.)
Example: In 16-bit linear PCM system (L16), a signal with 0 dBov Example: In 16-bit linear PCM system (L16), a signal with 0 dBov
represents a square wave with the maximum possible amplitude (+/- represents a square wave with the maximum possible amplitude (+/-
32767). -63 dBov corresponds to -58 dBm0 in a standard telephone 32767). -63 dBov corresponds to -58 dBm0 in a standard telephone
system. (dBm is the power level in decibels relative to 1 mW, with an system. (dBm is the power level in decibels relative to 1 mW, with an
impedance of 600 Ohms.) impedance of 600 Ohms.)
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0 0| level | |0| level |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The RTP header for the comfort noise packet should be constructed as The RTP header for the comfort noise packet should be constructed as
if the comfort noise were an independent codec. Thus, the RTP if the comfort noise were an independent codec. Thus, the RTP
timestamp designates the beginning of the silence period. A static timestamp designates the beginning of the silence period. A static
payload type is assigned for a sampling rate of 8,000 Hz; if other payload type is assigned for a sampling rate of 8,000 Hz; if other
sampling rates are needed, they should be defined through dynamic sampling rates are needed, they should be defined through dynamic
payload types. The RTP packet should not have the marker bit set. payload types. The RTP packet should not have the marker bit set.
The CN payload type is primarily for use with L16, DVI4, PCMA, PCMU The CN payload type is primarily for use with L16, DVI4, PCMA, PCMU
skipping to change at page 11, line 29 skipping to change at page 11, line 29
systems as part of Annexes A (G.723.1) and B (G.729), respectively. systems as part of Annexes A (G.723.1) and B (G.729), respectively.
4.5.3 DVI4 4.5.3 DVI4
DVI4 is specified, with pseudo-code, in [6] as the IMA ADPCM wave DVI4 is specified, with pseudo-code, in [6] as the IMA ADPCM wave
type. type.
However, the encoding defined here as DVI4 differs in three respects However, the encoding defined here as DVI4 differs in three respects
from this recommendation: from this recommendation:
o The header contains the predicted value rather than the first oThe RTP DVI4 header contains the predicted value rather than
sample value. the first sample value contained the IMA ADPCM block header.
o IMA ADPCM blocks contain an odd number of samples, since the o IMA ADPCM blocks contain an odd number of samples, since the
first sample of a block is contained just in the header first sample of a block is contained just in the header
(uncompressed), followed by an even number of compressed (uncompressed), followed by an even number of compressed
samples. DVI4 has an even number of compressed samples only, samples. DVI4 has an even number of compressed samples only,
using the 'predict' word from the header to decode the first using the 'predict' word from the header to decode the first
sample. sample.
o For DVI4, the 4-bit samples are packed with the first sample oFor DVI4, the 4-bit samples are packed with the first sample in
in the four most significant bits and the second sample in the the four most significant bits and the second sample in the
four least significant bits. In the IMA ADPCM codec, the four least significant bits. In the IMA ADPCM codec, the
samples are packed in little-endian order. samples are packed in little-endian order.
Each packet contains a single DVI block. This profile only defines Each packet contains a single DVI block. This profile only defines
the 4-bit-per-sample version, while IMA also specifies a 3-bit-per- the 4-bit-per-sample version, while IMA also specifies a 3-bit-per-
sample encoding. sample encoding.
The "header" word for each channel has the following structure: The "header" word for each channel has the following structure:
int16 predict; /* predicted value of first sample int16 predict; /* predicted value of first sample
skipping to change at page 14, line 8 skipping to change at page 14, line 8
octets as follows: the first code word is placed in the four least octets as follows: the first code word is placed in the four least
significant bits of the first octet, with the least significant bit significant bits of the first octet, with the least significant bit
of the code word in the least significant bit of the octet; the of the code word in the least significant bit of the octet; the
second code word is placed in the four most significant bits of the second code word is placed in the four most significant bits of the
first octet, with the most significant bit of the code word in the first octet, with the most significant bit of the code word in the
most significant bit of the octet. Subsequent pairs of the code words most significant bit of the octet. Subsequent pairs of the code words
shall be packed in the same way into successive octets, with the shall be packed in the same way into successive octets, with the
first code word of each pair placed in the least significant four first code word of each pair placed in the least significant four
bits of the octet. It is prefered that the voice sample be extended bits of the octet. It is prefered that the voice sample be extended
with silence such that the encoded value comprises an even number of with silence such that the encoded value comprises an even number of
code words. code words. [TBD: Shouldn't we just require an even number of
samples?]
4.5.7 G727-16, G727-24, G727-32, G727-40 4.5.7 G727-16, G727-24, G727-32, G727-40
ITU-T Recommendation G.727, "5-, 4-, 3- and 2-bits sample embedded ITU-T Recommendation G.727, "5-, 4-, 3- and 2-bits sample embedded
adaptive differential pulse code modulation (ADPCM)", specifies an adaptive differential pulse code modulation (ADPCM)", specifies an
embedded ADPCM algorithm which has the intrinsic capability of embedded ADPCM algorithm which has the intrinsic capability of
dropping bits in the encoded words to alleviate network congestion dropping bits in the encoded words to alleviate network congestion
conditions. The algorithm, although not bitstream compatible with conditions. The algorithm, although not bitstream compatible with
G.726, was based and has a structure similar to the G.726 ADPCM G.726, was based and has a structure similar to the G.726 ADPCM
algorithm. algorithm.
skipping to change at page 16, line 41 skipping to change at page 16, line 41
7 7
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C2 | S2 | GA2 | GB2 | | C2 | S2 | GA2 | GB2 |
| | | | | | | | | |
|8 9 1 1 1|0 1 2 3|0 1 2|0 1 2 3| |8 9 1 1 1|0 1 2 3|0 1 2|0 1 2 3|
| 0 1 2| | | | | 0 1 2| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding name "G729B" is assigned for the case when a particular
RTP payload type is to contain G.729 Annex B comfort noise packets
only. This may be necessary if the underlying RTP mechanism has no
means of distinguishing talkspurt from comfort-noise packets.
4.5.10 GSM 4.5.10 GSM
GSM (group speciale mobile) denotes the European GSM 06.10 GSM (group speciale mobile) denotes the European GSM 06.10
provisional standard for full-rate speech transcoding, prI-ETS 300 provisional standard for full-rate speech transcoding, prI-ETS 300
036, which is based on RPE/LTP (residual pulse excitation/long term 036, which is based on RPE/LTP (residual pulse excitation/long term
prediction) coding at a rate of 13 kb/s [8,9,10]. The text of the prediction) coding at a rate of 13 kb/s [8,9,10]. The text of the
standard can be obtained from standard can be obtained from
ETSI (European Telecommunications Standards Institute) ETSI (European Telecommunications Standards Institute)
ETSI Secretariat: B.P.152 ETSI Secretariat: B.P.152
skipping to change at page 17, line 29 skipping to change at page 17, line 35
The GSM standard specifies the bit stream produced by the codec, but The GSM standard specifies the bit stream produced by the codec, but
does not specify how these bits should be packed for transmission. does not specify how these bits should be packed for transmission.
Some software implementations of the GSM codec use a different Some software implementations of the GSM codec use a different
packing than that specified here. packing than that specified here.
In the GSM encoding used by RTP, the bits are packed beginning from In the GSM encoding used by RTP, the bits are packed beginning from
the most significant bit. Every 160 sample GSM frame is coded into the most significant bit. Every 160 sample GSM frame is coded into
one 33 octet (264 bit) buffer. Every such buffer begins with a 4 bit one 33 octet (264 bit) buffer. Every such buffer begins with a 4 bit
signature (0xD), followed by the MSB encoding of the fields of the signature (0xD), followed by the MSB encoding of the fields of the
frame. The first octet thus contains 1101 in the 4 most significant frame. The first octet thus contains 1101 in the 4 most significant
bits (4-7) and the 4 most significant bits of F1 (2-5) in the 4 least bits (0-3) and the 4 most significant bits of F1 (0-3) in the 4 least
significant bits (0-3). The second octet contains the 2 least bits of significant bits (4-7). The second octet contains the 2 least
F1 in bits 6-7, and F2 in bits 0-5, and so on. The order of the significant bits of F1 in bits 0-1, and F2 in bits 2-7, and so on.
fields in the frame is as follows: The order of the fields in the frame is as follows:
4.5.10.2 GSM variable names and numbers 4.5.10.2 GSM variable names and numbers
So if F.i signifies the ith bit of the field F, and bit 0 is the most So if F.i signifies the ith bit of the field F, and bit 0 is the most
significant bit, and the bits of every octet are numbered from 0 to 7 significant bit, and the bits of every octet are numbered from 0 to 7
from most to least significant, then in the RTP encoding we have: from most to least significant, then in the RTP encoding we have:
4.5.11 L8 4.5.11 L8
L8 denotes linear audio data, using 8-bits of precision with an L8 denotes linear audio data, using 8-bits of precision with an
offset of 128, that is, the most negative signal is encoded as zero. offset of 128, that is, the most negative signal is encoded as zero.
4.5.12 L16
L16 denotes uncompressed audio data, using 16-bit signed
representation with 65535 equally divided steps between minimum and
maximum signal level, ranging from --32768 to 32767. The value is
field field name bits field field name bits field field name bits field field name bits
__________________________________________________________ __________________________________________________________
1 LARc[0] 6 39 xmc[22] 3 1 LARc[0] 6 39 xmc[22] 3
2 LARc[1] 6 40 xmc[23] 3 2 LARc[1] 6 40 xmc[23] 3
3 LARc[2] 5 41 xmc[24] 3 3 LARc[2] 5 41 xmc[24] 3
4 LARc[3] 5 42 xmc[25] 3 4 LARc[3] 5 42 xmc[25] 3
5 LARc[4] 4 43 Nc[2] 7 5 LARc[4] 4 43 Nc[2] 7
6 LARc[5] 4 44 bc[2] 2 6 LARc[5] 4 44 bc[2] 2
7 LARc[6] 3 45 Mc[2] 2 7 LARc[6] 3 45 Mc[2] 2
8 LARc[7] 3 46 xmaxc[2] 6 8 LARc[7] 3 46 xmaxc[2] 6
skipping to change at page 18, line 47 skipping to change at page 18, line 48
32 xmc[15] 3 70 xmc[45] 3 32 xmc[15] 3 70 xmc[45] 3
33 xmc[16] 3 71 xmc[46] 3 33 xmc[16] 3 71 xmc[46] 3
34 xmc[17] 3 72 xmc[47] 3 34 xmc[17] 3 72 xmc[47] 3
35 xmc[18] 3 73 xmc[48] 3 35 xmc[18] 3 73 xmc[48] 3
36 xmc[19] 3 74 xmc[49] 3 36 xmc[19] 3 74 xmc[49] 3
37 xmc[20] 3 75 xmc[50] 3 37 xmc[20] 3 75 xmc[50] 3
38 xmc[21] 3 76 xmc[51] 3 38 xmc[21] 3 76 xmc[51] 3
Table 2: Ordering of GSM variables Table 2: Ordering of GSM variables
represented in two's complement notation and network byte order. 4.5.12 L16
4.5.13 LPC L16 denotes uncompressed audio data, using 16-bit signed
representation with 65535 equally divided steps between minimum and
Octet Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Octet Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7
_____________________________________________________________________________________________ _____________________________________________________________________________________________
0 1 1 0 1 LARc0.0 LARc0.1 LARc0.2 LARc0.3 0 1 1 0 1 LARc0.0 LARc0.1 LARc0.2 LARc0.3
1 LARc0.4 LARc0.5 LARc1.0 LARc1.1 LARc1.2 LARc1.3 LARc1.4 LARc1.5 1 LARc0.4 LARc0.5 LARc1.0 LARc1.1 LARc1.2 LARc1.3 LARc1.4 LARc1.5
2 LARc2.0 LARc2.1 LARc2.2 LARc2.3 LARc2.4 LARc3.0 LARc3.1 LARc3.2 2 LARc2.0 LARc2.1 LARc2.2 LARc2.3 LARc2.4 LARc3.0 LARc3.1 LARc3.2
3 LARc3.3 LARc3.4 LARc4.0 LARc4.1 LARc4.2 LARc4.3 LARc5.0 LARc5.1 3 LARc3.3 LARc3.4 LARc4.0 LARc4.1 LARc4.2 LARc4.3 LARc5.0 LARc5.1
4 LARc5.2 LARc5.3 LARc6.0 LARc6.1 LARc6.2 LARc7.0 LARc7.1 LARc7.2 4 LARc5.2 LARc5.3 LARc6.0 LARc6.1 LARc6.2 LARc7.0 LARc7.1 LARc7.2
5 Nc0.0 Nc0.1 Nc0.2 Nc0.3 Nc0.4 Nc0.5 Nc0.6 bc0.0 5 Nc0.0 Nc0.1 Nc0.2 Nc0.3 Nc0.4 Nc0.5 Nc0.6 bc0.0
6 bc0.1 Mc0.0 Mc0.1 xmaxc00 xmaxc01 xmaxc02 xmaxc03 xmaxc04 6 bc0.1 Mc0.0 Mc0.1 xmaxc00 xmaxc01 xmaxc02 xmaxc03 xmaxc04
7 xmaxc05 xmc0.0 xmc0.1 xmc0.2 xmc1.0 xmc1.1 xmc1.2 xmc2.0 7 xmaxc05 xmc0.0 xmc0.1 xmc0.2 xmc1.0 xmc1.1 xmc1.2 xmc2.0
8 xmc2.1 xmc2.2 xmc3.0 xmc3.1 xmc3.2 xmc4.0 xmc4.1 xmc4.2 8 xmc2.1 xmc2.2 xmc3.0 xmc3.1 xmc3.2 xmc4.0 xmc4.1 xmc4.2
9 xmc5.0 xmc5.1 xmc5.2 xmc6.0 xmc6.1 xmc6.2 xmc7.0 xmc7.1 9 xmc5.0 xmc5.1 xmc5.2 xmc6.0 xmc6.1 xmc6.2 xmc7.0 xmc7.1
10 xmc7.2 xmc8.0 xmc8.1 xmc8.2 xmc9.0 xmc9.1 xmc9.2 xmc10.0 10 xmc7.2 xmc8.0 xmc8.1 xmc8.2 xmc9.0 xmc9.1 xmc9.2 xmc10.0
11 xmc10.1 xmc10.2 xmc11.0 xmc11.1 xmc11.2 xmc12.0 xmc12.1 xcm12.2 11 xmc10.1 xmc10.2 xmc11.0 xmc11.1 xmc11.2 xmc12.0 xmc12.1 xcm12.2
12 Nc1.0 Nc1.1 Nc1.2 Nc1.3 Nc1.4 Nc1.5 Nc1.6 bc1.0 12 Nc1.0 Nc1.1 Nc1.2 Nc1.3 Nc1.4 Nc1.5 Nc1.6 bc1.0
13 bc1.1 Mc1.0 Mc1.1 xmaxc10 xmaxc11 xmaxc12 xmaxc13 xmaxc14 13 bc1.1 Mc1.0 Mc1.1 xmaxc10 xmaxc11 xmaxc12 xmaxc13 xmaxc14
skipping to change at page 19, line 40 skipping to change at page 19, line 41
24 xmc33.2 xmc34.0 xmc34.1 xmc34.2 xmc35.0 xmc35.1 xmc35.2 xmc36.0 24 xmc33.2 xmc34.0 xmc34.1 xmc34.2 xmc35.0 xmc35.1 xmc35.2 xmc36.0
25 Xmc36.1 xmc36.2 xmc37.0 xmc37.1 xmc37.2 xmc38.0 xmc38.1 xmc38.2 25 Xmc36.1 xmc36.2 xmc37.0 xmc37.1 xmc37.2 xmc38.0 xmc38.1 xmc38.2
26 Nc3.0 Nc3.1 Nc3.2 Nc3.3 Nc3.4 Nc3.5 Nc3.6 bc3.0 26 Nc3.0 Nc3.1 Nc3.2 Nc3.3 Nc3.4 Nc3.5 Nc3.6 bc3.0
27 bc3.1 Mc3.0 Mc3.1 xmaxc30 xmaxc31 xmaxc32 xmaxc33 xmaxc34 27 bc3.1 Mc3.0 Mc3.1 xmaxc30 xmaxc31 xmaxc32 xmaxc33 xmaxc34
28 xmaxc35 xmc39.0 xmc39.1 xmc39.2 xmc40.0 xmc40.1 xmc40.2 xmc41.0 28 xmaxc35 xmc39.0 xmc39.1 xmc39.2 xmc40.0 xmc40.1 xmc40.2 xmc41.0
29 xmc41.1 xmc41.2 xmc42.0 xmc42.1 xmc42.2 xmc43.0 xmc43.1 xmc43.2 29 xmc41.1 xmc41.2 xmc42.0 xmc42.1 xmc42.2 xmc43.0 xmc43.1 xmc43.2
30 xmc44.0 xmc44.1 xmc44.2 xmc45.0 xmc45.1 xmc45.2 xmc46.0 xmc46.1 30 xmc44.0 xmc44.1 xmc44.2 xmc45.0 xmc45.1 xmc45.2 xmc46.0 xmc46.1
31 xmc46.2 xmc47.0 xmc47.1 xmc47.2 xmc48.0 xmc48.1 xmc48.2 xmc49.0 31 xmc46.2 xmc47.0 xmc47.1 xmc47.2 xmc48.0 xmc48.1 xmc48.2 xmc49.0
32 xmc49.1 xmc49.2 xmc50.0 xmc50.1 xmc50.2 xmc51.0 xmc51.1 xmc51.2 32 xmc49.1 xmc49.2 xmc50.0 xmc50.1 xmc50.2 xmc51.0 xmc51.1 xmc51.2
maximum signal level, ranging from --32768 to 32767. The value is
represented in two's complement notation and network byte order.
4.5.13 LPC
LPC designates an experimental linear predictive encoding contributed LPC designates an experimental linear predictive encoding contributed
by Ron Frederick, Xerox PARC, which is based on an implementation by Ron Frederick, Xerox PARC, which is based on an implementation
written by Ron Zuckerman, Motorola, posted to the Usenet group written by Ron Zuckerman, Motorola, posted to the Usenet group
comp.dsp on June 26, 1992. The codec generates 14 octets for every comp.dsp on June 26, 1992. The codec generates 14 octets for every
frame. The framesize is set to 20 ms, resulting in a bit rate of frame. The framesize is set to 20 ms, resulting in a bit rate of
5,600 b/s. 5,600 b/s.
4.5.14 MPA 4.5.14 MPA
MPA denotes MPEG-I or MPEG-II audio encapsulated as elementary MPA denotes MPEG-I or MPEG-II audio encapsulated as elementary
streams. The encoding is defined in ISO standards ISO/IEC 11172-3 streams. The encoding is defined in ISO standards ISO/IEC 11172-3
and 13818-3. The encapsulation is specified in RFC 2038 [11]. and 13818-3. The encapsulation is specified in RFC 2038 [11].
Sampling rate and channel count are contained in the payload. MPEG-I Sampling rate and channel count are contained in the payload. MPEG-I
audio supports sampling rates of 32000, 44100, and 48000 Hz (ISO/IEC audio supports sampling rates of 32000, 44100, and 48000 Hz (ISO/IEC
11172-3, section 1.1; "Scope"). MPEG-II additionally supports ISO/IEC 11172-3, section 1.1; "Scope"). MPEG-II additionally supports ISO/IEC
11172-3 Audio..."). 11172-3 Audio. "TBD"). [Something missing here.]
4.5.15 PCMA and PCMU 4.5.15 PCMA and PCMU
PCMA and PCMU are specified in ITU-T Recommendation G.711. Audio data PCMA and PCMU are specified in ITU-T Recommendation G.711. Audio data
is encoded as eight bits per sample, after logarithmic scaling. PCMU is encoded as eight bits per sample, after logarithmic scaling. PCMU
denotes mu-law scaling, PCMA A-law scaling. A detailed description is denotes mu-law scaling, PCMA A-law scaling. A detailed description is
given by Jayant and Noll [12]. Each G.711 octet shall be octet- given by Jayant and Noll [12]. Each G.711 octet shall be octet-
aligned in an RTP packet. The sign bit of each G.711 octet shall aligned in an RTP packet. The sign bit of each G.711 octet shall
correspond to the most significant bit of the octet in the RTP packet correspond to the most significant bit of the octet in the RTP packet
(i.e., assuming the G.711 samples are handled as octets on the host (i.e., assuming the G.711 samples are handled as octets on the host
skipping to change at page 23, line 45 skipping to change at page 24, line 5
are possible. However, it is not sufficient to use the video frame are possible. However, it is not sufficient to use the video frame
rate (typically between 15 and 30 Hz) because that does not provide rate (typically between 15 and 30 Hz) because that does not provide
adequate resolution for typical synchronization requirements when adequate resolution for typical synchronization requirements when
calculating the RTP timestamp corresponding to the NTP timestamp in calculating the RTP timestamp corresponding to the NTP timestamp in
an RTCP SR packet. The timestamp resolution must also be sufficient an RTCP SR packet. The timestamp resolution must also be sufficient
for the jitter estimate contained in the receiver reports. for the jitter estimate contained in the receiver reports.
The standard video encodings and their payload types are listed in The standard video encodings and their payload types are listed in
Table 3. Table 3.
7 RTP over TCP and Similar Byte Stream Protocols
Under special circumstances, it may be necessary to carry RTP in
protocols offering a byte stream abstraction, such as TCP, possibly
multiplexed with other data. If the application does not define its
own method of delineating RTP and RTCP packets, it SHOULD prefix each
packet with a two-octet length field.
PT encoding media type clock rate channels PT encoding media type clock rate channels
name (Hz) (audio) name (Hz) (audio)
_______________________________________________________________ _______________________________________________________________
0 PCMU A 8000 1 0 PCMU A 8000 1
1 1016 A 8000 1 1 1016 A 8000 1
2 G726-32 A 8000 1 2 G726-32 A 8000 1
3 GSM A 8000 1 3 GSM A 8000 1
4 G723 A 8000 1 4 G723 A 8000 1
5 DVI4 A 8000 1 5 DVI4 A 8000 1
6 DVI4 A 16000 1 6 DVI4 A 16000 1
skipping to change at page 25, line 4 skipping to change at page 25, line 4
32 MPV V 90000 32 MPV V 90000
33 MP2T AV 90000 33 MP2T AV 90000
34 H263 V 90000 34 H263 V 90000
35--71 unassigned ? 35--71 unassigned ?
72--76 reserved N/A N/A N/A 72--76 reserved N/A N/A N/A
77 RED A N/A N/A 77 RED A N/A N/A
78--95 unassigned ? 78--95 unassigned ?
96--127 dynamic ? 96--127 dynamic ?
Table 3: Payload types (PT) for standard audio and video encodings Table 3: Payload types (PT) for standard audio and video encodings
7 RTP over TCP and Similar Byte Stream Protocols
Under special circumstances, it may be necessary to carry RTP in
protocols offering a byte stream abstraction, such as TCP, possibly
multiplexed with other data. If the application does not define its
own method of delineating RTP and RTCP packets, it SHOULD prefix each
packet with a two-octet length field.
(Note: RTSP [17] provides its own encapsulation and does not need an (Note: RTSP [17] provides its own encapsulation and does not need an
extra length indication.) extra length indication.)
8 Port Assignment 8 Port Assignment
As specified in the RTP protocol definition, RTP data is to be As specified in the RTP protocol definition, RTP data is to be
carried on an even UDP or TCP port number and the corresponding RTCP carried on an even UDP or TCP port number and the corresponding RTCP
packets are to be carried on the next higher (odd) port number. packets are to be carried on the next higher (odd) port number.
Applications operating under this profile may use any such UDP or TCP Applications operating under this profile may use any such UDP or TCP
skipping to change at page 30, line 17 skipping to change at page 30, line 22
4.5 Audio Encodings ..................................... 9 4.5 Audio Encodings ..................................... 9
4.5.1 1016 ................................................ 9 4.5.1 1016 ................................................ 9
4.5.2 CN .................................................. 9 4.5.2 CN .................................................. 9
4.5.3 DVI4 ................................................ 11 4.5.3 DVI4 ................................................ 11
4.5.4 G722 ................................................ 12 4.5.4 G722 ................................................ 12
4.5.5 G723 ................................................ 12 4.5.5 G723 ................................................ 12
4.5.6 G726-16, G726-24, G726-32, G726-40 .................. 13 4.5.6 G726-16, G726-24, G726-32, G726-40 .................. 13
4.5.7 G727-16, G727-24, G727-32, G727-40 .................. 14 4.5.7 G727-16, G727-24, G727-32, G727-40 .................. 14
4.5.8 G728 ................................................ 14 4.5.8 G728 ................................................ 14
4.5.9 G729 ................................................ 15 4.5.9 G729 ................................................ 15
4.5.10 GSM ................................................. 16 4.5.10 GSM ................................................. 17
4.5.10.1 General Packaging Issues ............................ 17 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 ...................... 17
4.5.11 L8 .................................................. 17 4.5.11 L8 .................................................. 17
4.5.12 L16 ................................................. 17 4.5.12 L16 ................................................. 18
4.5.13 LPC ................................................. 18 4.5.13 LPC ................................................. 19
4.5.14 MPA ................................................. 19 4.5.14 MPA ................................................. 20
4.5.15 PCMA and PCMU ....................................... 20 4.5.15 PCMA and PCMU ....................................... 20
4.5.16 RED ................................................. 20 4.5.16 RED ................................................. 20
4.5.17 SX7300P ............................................. 20 4.5.17 SX7300P ............................................. 20
4.5.18 SX8300P ............................................. 20 4.5.18 SX8300P ............................................. 20
4.5.19 VDVI ................................................ 20 4.5.19 VDVI ................................................ 21
5 Video ............................................... 21 5 Video ............................................... 21
5.1 CelB ................................................ 21 5.1 CelB ................................................ 21
5.2 JPEG ................................................ 21 5.2 JPEG ................................................ 21
5.3 H261 ................................................ 21 5.3 H261 ................................................ 22
5.4 H263 ................................................ 22 5.4 H263 ................................................ 22
5.5 MPV ................................................. 22 5.5 MPV ................................................. 22
5.6 MP2T ................................................ 22 5.6 MP2T ................................................ 22
5.7 nv .................................................. 22 5.7 nv .................................................. 22
6 Payload Type Definitions ............................ 22 6 Payload Type Definitions ............................ 22
7 RTP over TCP and Similar Byte Stream Protocols ...... 23 7 RTP over TCP and Similar Byte Stream Protocols ...... 25
8 Port Assignment ..................................... 25 8 Port Assignment ..................................... 25
9 Bibliography ........................................ 25 9 Bibliography ........................................ 25
10 Acknowledgements .................................... 27 10 Acknowledgements .................................... 27
11 Address of Author ................................... 27 11 Address of Author ................................... 27
 End of changes. 

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