draft-ietf-avt-profile-new-06.txt   draft-ietf-avt-profile-new-07.txt 
Internet Engineering Task Force AVT WG Internet Engineering Task Force AVT WG
Internet Draft Schulzrinne/Casner Internet Draft Schulzrinne/Casner
draft-ietf-avt-profile-new-06.txt Columbia U./Cisco Systems draft-ietf-avt-profile-new-07.txt Columbia U./Cisco Systems
June 25, 1999 October 21, 1999
Expires: December 25, 1999 Expires: April 21, 2000
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 and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 11, line 31 skipping to change at page 11, line 31
MPA frame N/A var. var. MPA frame N/A var. var.
PCMA sample 8 var. 20 PCMA sample 8 var. 20
PCMU sample 8 var. 20 PCMU sample 8 var. 20
QCELP frame N/A 8,000 20 20 QCELP frame N/A 8,000 20 20
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)
MUST be used to define a dynamic payload type and MUST indicate the MUST be used to define a dynamic payload type and MUST indicate the
selected sampling rate. selected RTP timestamp clock rate, which is usually the same as the
sampling rate for audio.
4.5.1 1016 4.5.1 1016
Encoding 1016 is a frame based encoding using code-excited linear Encoding 1016 is a frame based encoding using code-excited linear
prediction (CELP) and is specified in Federal Standard FED-STD 1016 prediction (CELP) and is specified in Federal Standard FED-STD 1016
[7,8,9,10]. [7,8,9,10].
4.5.2 CN 4.5.2 CN
The CN (comfort noise) packet contains a single-octet message to the The CN (comfort noise) packet contains a single-octet message to the
skipping to change at page 13, line 46 skipping to change at page 13, line 47
4.5.4 G722 4.5.4 G722
G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding
within 64 kbit/s". The G.722 encoder produces a stream of octets, within 64 kbit/s". The G.722 encoder produces a stream of octets,
each of which SHALL be octet-aligned in an RTP packet. The first bit each of which SHALL be octet-aligned in an RTP packet. The first bit
transmitted in the G.722 octet, which is the most significant bit of transmitted in the G.722 octet, which is the most significant bit of
the higher sub-band sample, SHALL correspond to the most significant the higher sub-band sample, SHALL correspond to the most significant
bit of the octet in the RTP packet. bit of the octet in the RTP packet.
Even though the actual sampling rate for G.722 audio is 16000 Hz, the
RTP clock rate for the G722 payload format is 8000 Hz because that
value was erroneously assigned in RFC 1890 and must remain unchanged
for backward compatibility. The octet rate or sample-pair rate is
8000 Hz.
4.5.5 G723 4.5.5 G723
G723 is specified in ITU Recommendation G.723.1, "Dual-rate speech G723 is specified in ITU Recommendation G.723.1, "Dual-rate speech
coder for multimedia communications transmitting at 5.3 and 6.3 coder for multimedia communications transmitting at 5.3 and 6.3
kbit/s". The G.723.1 5.3/6.3 kbit/s codec was defined by the ITU-T as kbit/s". The G.723.1 5.3/6.3 kbit/s codec was defined by the ITU-T as
a mandatory codec for ITU-T H.324 GSTN videophone terminal a mandatory codec for ITU-T H.324 GSTN videophone terminal
applications. The algorithm has a floating point specification in applications. The algorithm has a floating point specification in
Annex B to G.723.1, a silence compression algorithm in Annex A to Annex B to G.723.1, a silence compression algorithm in Annex A to
G.723.1 and an encoded signal bit-error sensitivity specification in G.723.1 and an encoded signal bit-error sensitivity specification in
G.723.1 Annex C. G.723.1 Annex C.
skipping to change at page 18, line 43 skipping to change at page 19, line 4
here for the original GSM 06.10 codec and is specified in ETSI here for the original GSM 06.10 codec and is specified in ETSI
Technical Specification TS 101 318. Technical Specification TS 101 318.
4.5.11 GSM-EFR 4.5.11 GSM-EFR
GSM-EFR denotes GSM 06.60 enhanced full rate speech transcoding, GSM-EFR denotes GSM 06.60 enhanced full rate speech transcoding,
specified in ETS 300 969 which is available from ETSI at the address specified in ETS 300 969 which is available from ETSI at the address
given in Section 4.5.9. This codec has a frame length of 244 bits. given in Section 4.5.9. This codec has a frame length of 244 bits.
For transmission in RTP, each codec frame is packed into a 31 octet For transmission in RTP, each codec frame is packed into a 31 octet
(248 bit) buffer beginning with a 4-bit signature 0xC in a manner (248 bit) buffer beginning with a 4-bit signature 0xC in a manner
similar to that specified here for the original GSM 06.10 codec. The
packing is specified in ETSI Technical Specification TS 101 318.
4.5.12 L8
L8 denotes linear audio data samples, using 8-bits of precision with
an offset of 128, that is, the most negative signal is encoded as
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 19, line 47 skipping to change at page 19, line 47
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
zero. similar to that specified here for the original GSM 06.10 codec. The
packing is specified in ETSI Technical Specification TS 101 318.
4.5.13 L16
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
skipping to change at page 20, line 42 skipping to change at page 20, line 43
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
Table 3: GSM payload format Table 3: GSM payload format
4.5.12 L8
L8 denotes linear audio data samples, using 8-bits of precision with
an offset of 128, that is, the most negative signal is encoded as
zero.
4.5.13 L16
L16 denotes uncompressed audio data samples, using 16-bit signed L16 denotes uncompressed audio data samples, using 16-bit signed
representation with 65535 equally divided steps between minimum and representation with 65535 equally divided steps between minimum and
maximum signal level, ranging from -32768 to 32767. The value is maximum signal level, ranging from -32768 to 32767. The value is
represented in two's complement notation and transmitted in network represented in two's complement notation and transmitted in network
byte order (most significant byte first). byte order (most significant byte first).
4.5.14 LPC 4.5.14 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.15 MPA 4.5.15 MPA
MPA denotes MPEG-1 or MPEG-2 audio encapsulated as elementary MPA denotes MPEG-1 or MPEG-2 audio encapsulated as elementary
skipping to change at page 21, line 19 skipping to change at page 21, line 27
5,600 b/s. 5,600 b/s.
4.5.15 MPA 4.5.15 MPA
MPA denotes MPEG-1 or MPEG-2 audio encapsulated as elementary MPA denotes MPEG-1 or MPEG-2 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 2250 [16]. and 13818-3. The encapsulation is specified in RFC 2250 [16].
The encoding may be at any of three levels of complexity, called The encoding may be at any of three levels of complexity, called
Layer I, II and III. The selected layer as well as the sampling rate Layer I, II and III. The selected layer as well as the sampling rate
and channel count are indicated in the payload. MPEG-1 audio supports and channel count are indicated in the payload. The RTP timestamp
sampling rates of 32, 44.1, and 48 kHz (ISO/IEC 11172-3, section 1.1; clock rate is always 90000, independent of the sampling rate. MPEG-1
"Scope"). MPEG-2 supports sampling rates of 16, 22.05 and 24 kHz. audio supports sampling rates of 32, 44.1, and 48 kHz (ISO/IEC
The number of samples per frame is fixed, but the frame size will 11172-3, section 1.1; "Scope"). MPEG-2 supports sampling rates of 16,
vary with the sampling rate and bit rate. 22.05 and 24 kHz. The number of samples per frame is fixed, but the
frame size will vary with the sampling rate and bit rate.
4.5.16 PCMA and PCMU 4.5.16 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 [17]. Each G.711 octet SHALL be octet- given by Jayant and Noll [17]. 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 26, line 13 skipping to change at page 26, line 23
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. or established by agreement between the human participants.
Audio applications operating under this profile SHOULD, at a minimum, Audio applications operating under this profile SHOULD, at a minimum,
be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4).
This allows interoperability without format negotiation and ensures This allows interoperability without format negotiation and ensures
successful negotation with a conference control protocol. successful negotation with a conference control protocol.
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 [27] provides its own encapsulation and does not need an
extra length indication.)
8 Port Assignment
As specified in the RTP protocol definition, RTP data SHOULD be
carried on an even UDP or TCP port number and the corresponding RTCP
packets SHOULD be carried on the next higher (odd) port number.
Applications operating under this profile MAY use any such UDP or TCP
port pair. For example, the port pair MAY be allocated randomly by a
session management program. A single fixed port number pair cannot be
required because multiple applications using this profile are likely
to run on the same host, and there are some operating systems that do
not allow multiple processes to use the same UDP port with different
multicast addresses.
However, port numbers 5004 and 5005 have been registered for use with
this profile for those applications that choose to use them as the
PT encoding media type clock rate channels PT encoding media type clock rate channels
name (Hz) name (Hz)
___________________________________________________ ___________________________________________________
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
7 LPC A 8000 1 7 LPC A 8000 1
8 PCMA A 8000 1 8 PCMA A 8000 1
9 G722 A 16000 1 9 G722 A 8000 1
10 L16 A 44100 2 10 L16 A 44100 2
11 L16 A 44100 1 11 L16 A 44100 1
12 QCELP A 8000 1 12 QCELP A 8000 1
13 unassigned A 13 CN A
14 MPA A 90000 (see text) 14 MPA A 90000 (see text)
15 G728 A 8000 1 15 G728 A 8000 1
16 DVI4 A 11025 1 16 DVI4 A 11025 1
17 DVI4 A 22050 1 17 DVI4 A 22050 1
18 G729 A 8000 1 18 G729 A 8000 1
19 CN A 8000 1 19 unassigned A 8000 1
20 unassigned A 20 unassigned A
21 unassigned A 21 unassigned A
22 unassigned A 22 unassigned A
23 unassigned A 23 unassigned A
dyn GSM-HR A 8000 1 dyn GSM-HR A 8000 1
dyn GSM-EFR A 8000 1 dyn GSM-EFR A 8000 1
dyn RED A dyn RED A
Table 4: Payload types (PT) for audio encodings Table 4: Payload types (PT) for audio encodings
7 RTP over TCP and Similar Byte Stream Protocols default pair. Applications that operate under multiple profiles MAY
use this port pair as an indication to select this profile if they
are not subject to the constraint of the previous paragraph.
Applications need not have a default and MAY require that the port
pair be explicitly specified. The particular port numbers were chosen
to lie in the range above 5000 to accommodate port number allocation
practice within some versions of the Unix operating system, where
port numbers below 1024 can only be used by privileged processes and
port numbers between 1024 and 5000 are automatically assigned by the
operating system.
9 Changes from RFC 1890
PT encoding media type clock rate PT encoding media type clock rate
name (Hz) name (Hz)
____________________________________________ ____________________________________________
24 unassigned V 24 unassigned V
25 CelB V 90000 25 CelB V 90000
26 JPEG V 90000 26 JPEG V 90000
27 unassigned V 27 unassigned V
28 nv V 90000 28 nv V 90000
29 unassigned V 29 unassigned V
30 unassigned V 30 unassigned V
skipping to change at page 27, line 30 skipping to change at page 28, line 30
77-95 unassigned ? 77-95 unassigned ?
96-127 dynamic ? 96-127 dynamic ?
dyn BT656 V 90000 dyn BT656 V 90000
dyn H263-1998 V 90000 dyn H263-1998 V 90000
dyn MP1S V 90000 dyn MP1S V 90000
dyn MP2P V 90000 dyn MP2P V 90000
dyn BMPEG V 90000 dyn BMPEG V 90000
Table 5: Payload types (PT) for video and combined encodings Table 5: Payload types (PT) for video and combined encodings
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 [27] provides its own encapsulation and does not need an
extra length indication.)
8 Port Assignment
As specified in the RTP protocol definition, RTP data SHOULD be
carried on an even UDP or TCP port number and the corresponding RTCP
packets SHOULD be carried on the next higher (odd) port number.
Applications operating under this profile MAY use any such UDP or TCP
port pair. For example, the port pair MAY be allocated randomly by a
session management program. A single fixed port number pair cannot be
required because multiple applications using this profile are likely
to run on the same host, and there are some operating systems that do
not allow multiple processes to use the same UDP port with different
multicast addresses.
However, port numbers 5004 and 5005 have been registered for use with
this profile for those applications that choose to use them as the
default pair. Applications that operate under multiple profiles MAY
use this port pair as an indication to select this profile if they
are not subject to the constraint of the previous paragraph.
Applications need not have a default and MAY require that the port
pair be explicitly specified. The particular port numbers were chosen
to lie in the range above 5000 to accommodate port number allocation
practice within some versions of the Unix operating system, where
port numbers below 1024 can only be used by privileged processes and
port numbers between 1024 and 5000 are automatically assigned by the
operating system.
9 Changes from RFC 1890
This RFC revises RFC 1890. It is fully backwards-compatible with RFC This RFC revises RFC 1890. It is fully backwards-compatible with RFC
1890 and codifies existing practice. The changes are listed below. 1890 and codifies existing practice. The changes are listed below.
o Additional payload formats and/or expanded descriptions were o Additional payload formats and/or expanded descriptions were
included for CN, G722, G723, G726, G728, G729, GSM, GSM-HR, included for CN, G722, G723, G726, G728, G729, GSM, GSM-HR,
GSM-EFR, QCELP, RED, VDVI, BT656, H263-1998, MP1S, MP2P and GSM-EFR, QCELP, RED, VDVI, BT656, H263-1998, MP1S, MP2P and
BMPEG. BMPEG.
o Static payload types 4, 12, 16, 17, 18, 19 and 34 were added. o Static payload types 4, 12, 13, 16, 17, 18 and 34 were added.
o The policy is established that no additional registration of o The policy is established that no additional registration of
static payload types for this Profile will be made beyond static payload types for this Profile will be made beyond
those included in Tables 4 and 5, but additional encoding those included in Tables 4 and 5, but additional encoding
names may be registered as MIME subtypes. names may be registered as MIME subtypes.
o In Section 4.1, the requirement level for setting of the o In Section 4.1, the requirement level for setting of the
marker bit on the first packet after silence for audio was marker bit on the first packet after silence for audio was
changed from "is" to "SHOULD be". changed from "is" to "SHOULD be".
skipping to change at page 29, line 19 skipping to change at page 29, line 29
o According to Peter Hoddie of Apple, only pre-1994 Macintosh o According to Peter Hoddie of Apple, only pre-1994 Macintosh
used the 22254.54 rate and none the 11127.27 rate, so the used the 22254.54 rate and none the 11127.27 rate, so the
latter was dropped from the discussion of suggested sampling latter was dropped from the discussion of suggested sampling
frequencies. frequencies.
o Table 1 was corrected to move some values from the o Table 1 was corrected to move some values from the
"ms/packet" column to the "default ms/packet" column where "ms/packet" column to the "default ms/packet" column where
they belonged. they belonged.
o A note has been added for G722 to clarify a discrepancy
between the actual sampling rate and the RTP timestamp clock
rate.
o Small clarifications of the text have been made in several o Small clarifications of the text have been made in several
places, some in response to questions from readers. In places, some in response to questions from readers. In
particular: particular:
- A definition for "media type" is given in Section 1.1 to - A definition for "media type" is given in Section 1.1 to
allow the explanation of multiplexing RTP sessions in allow the explanation of multiplexing RTP sessions in
Section 6 to be more clear regarding the multiplexing of Section 6 to be more clear regarding the multiplexing of
multiple media. multiple media.
- The explanation of how to determine the number of audio - The explanation of how to determine the number of audio
skipping to change at page 36, line 18 skipping to change at page 36, line 33
4 Audio ............................................... 7 4 Audio ............................................... 7
4.1 Encoding-Independent Rules .......................... 7 4.1 Encoding-Independent Rules .......................... 7
4.2 Operating Recommendations ........................... 9 4.2 Operating Recommendations ........................... 9
4.3 Guidelines for Sample-Based Audio Encodings ......... 9 4.3 Guidelines for Sample-Based Audio Encodings ......... 9
4.4 Guidelines for Frame-Based Audio Encodings .......... 10 4.4 Guidelines for Frame-Based Audio Encodings .......... 10
4.5 Audio Encodings ..................................... 10 4.5 Audio Encodings ..................................... 10
4.5.1 1016 ................................................ 11 4.5.1 1016 ................................................ 11
4.5.2 CN .................................................. 11 4.5.2 CN .................................................. 11
4.5.3 DVI4 ................................................ 12 4.5.3 DVI4 ................................................ 12
4.5.4 G722 ................................................ 13 4.5.4 G722 ................................................ 13
4.5.5 G723 ................................................ 13 4.5.5 G723 ................................................ 14
4.5.6 G726-32 ............................................. 14 4.5.6 G726-32 ............................................. 14
4.5.7 G728 ................................................ 15 4.5.7 G728 ................................................ 15
4.5.8 G729 ................................................ 16 4.5.8 G729 ................................................ 16
4.5.9 GSM ................................................. 17 4.5.9 GSM ................................................. 17
4.5.9.1 General Packaging Issues ............................ 17 4.5.9.1 General Packaging Issues ............................ 18
4.5.9.2 GSM variable names and numbers ...................... 18 4.5.9.2 GSM variable names and numbers ...................... 18
4.5.10 GSM-HR .............................................. 18 4.5.10 GSM-HR .............................................. 18
4.5.11 GSM-EFR ............................................. 18 4.5.11 GSM-EFR ............................................. 18
4.5.12 L8 .................................................. 18 4.5.12 L8 .................................................. 20
4.5.13 L16 ................................................. 19 4.5.13 L16 ................................................. 20
4.5.14 LPC ................................................. 20 4.5.14 LPC ................................................. 21
4.5.15 MPA ................................................. 21 4.5.15 MPA ................................................. 21
4.5.16 PCMA and PCMU ....................................... 21 4.5.16 PCMA and PCMU ....................................... 21
4.5.17 QCELP ............................................... 21 4.5.17 QCELP ............................................... 21
4.5.18 RED ................................................. 22 4.5.18 RED ................................................. 22
4.5.19 VDVI ................................................ 22 4.5.19 VDVI ................................................ 22
5 Video ............................................... 22 5 Video ............................................... 23
5.1 BT656 ............................................... 23 5.1 BT656 ............................................... 23
5.2 CelB ................................................ 23 5.2 CelB ................................................ 23
5.3 JPEG ................................................ 23 5.3 JPEG ................................................ 24
5.4 H261 ................................................ 23 5.4 H261 ................................................ 24
5.5 H263 ................................................ 24 5.5 H263 ................................................ 24
5.6 H263-1998 ........................................... 24 5.6 H263-1998 ........................................... 24
5.7 MPV ................................................. 24 5.7 MPV ................................................. 24
5.8 MP2T ................................................ 24 5.8 MP2T ................................................ 24
5.9 MP1S ................................................ 24 5.9 MP1S ................................................ 25
5.10 MP2P ................................................ 24 5.10 MP2P ................................................ 25
5.11 BMPEG ............................................... 25 5.11 BMPEG ............................................... 25
5.12 nv .................................................. 25 5.12 nv .................................................. 25
6 Payload Type Definitions ............................ 25 6 Payload Type Definitions ............................ 25
7 RTP over TCP and Similar Byte Stream Protocols ...... 26 7 RTP over TCP and Similar Byte Stream Protocols ...... 26
8 Port Assignment ..................................... 27 8 Port Assignment ..................................... 26
9 Changes from RFC 1890 ............................... 28 9 Changes from RFC 1890 ............................... 27
10 Security Considerations ............................. 29 10 Security Considerations ............................. 30
11 Full Copyright Statement ............................ 30 11 Full Copyright Statement ............................ 30
12 Acknowledgements .................................... 30 12 Acknowledgements .................................... 31
13 Addresses of Authors ................................ 31 13 Addresses of Authors ................................ 31
A Bibliography ........................................ 31 A Bibliography ........................................ 31
 End of changes. 

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