draft-ietf-payload-g7110-01.txt   draft-ietf-payload-g7110-02.txt 
Network Working Group M. Ramalho, Ed. Network Working Group M. Ramalho, Ed.
Internet-Draft P. Jones Internet-Draft P. Jones
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: June 14, 2014 N. Harada Expires: September 4, 2014 N. Harada
NTT NTT
M. Perumal M. Perumal
Cisco Systems Cisco Systems
L. Miao L. Miao
Huawei Technologies Huawei Technologies
December 11, 2013 March 3, 2014
RTP Payload Format for G.711.0 RTP Payload Format for G.711.0
draft-ietf-payload-g7110-01 draft-ietf-payload-g7110-02
Abstract Abstract
This document specifies the Real-Time Transport Protocol (RTP) This document specifies the Real-Time Transport Protocol (RTP)
payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0
defines a lossless and stateless compression for G.711 packet defines a lossless and stateless compression for G.711 packet
payloads typically used in IP networks. This document also defines a payloads typically used in IP networks. This document also defines a
storage mode format for G.711.0 and a media type registration for the storage mode format for G.711.0 and a media type registration for the
G.711.0 RTP payload format. G.711.0 RTP payload format.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 14, 2014. This Internet-Draft will expire on September 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. G.711.0 Codec Background . . . . . . . . . . . . . . . . . . 3 3. G.711.0 Codec Background . . . . . . . . . . . . . . . . . . 3
3.1. General Information and Use of the ITU-T G.711.0 Codec . 3 3.1. General Information and Use of the ITU-T G.711.0 Codec . 3
3.2. Key Properties of G.711.0 Design . . . . . . . . . . . . 4 3.2. Key Properties of G.711.0 Design . . . . . . . . . . . . 4
3.3. G.711 Input Frames to G.711.0 Output Frames . . . . . . . 6 3.3. G.711 Input Frames to G.711.0 Output Frames . . . . . . . 6
4. RTP Header and Payload . . . . . . . . . . . . . . . . . . . 8 3.3.1. Multiple G.711.0 Output Frames per RTP Payload
4.1. G.711.0 RTP Header . . . . . . . . . . . . . . . . . . . 8 Considerations . . . . . . . . . . . . . . . . . . . 8
4.2. G.711.0 RTP Payload . . . . . . . . . . . . . . . . . . . 9 4. RTP Header and Payload . . . . . . . . . . . . . . . . . . . 9
4.2.1. Single G.711.0 Frame per RTP Payload Example . . . . 9 4.1. G.711.0 RTP Header . . . . . . . . . . . . . . . . . . . 9
4.2.2. Multiple G.711.0 Frames per RTP Payload Example . . . 10 4.2. G.711.0 RTP Payload . . . . . . . . . . . . . . . . . . . 10
4.2.1. Single G.711.0 Frame per RTP Payload Example . . . . 10
4.2.2. G.711.0 RTP Payload Definition . . . . . . . . . . . 11
4.2.3. G.711.0 RTP Payload Decoding Process . . . . . . . . 12 4.2.3. G.711.0 RTP Payload Decoding Process . . . . . . . . 12
4.2.4. G.711.0 RTP Payload for Multiple Channels . . . . . . 13 4.2.4. G.711.0 RTP Payload for Multiple Channels . . . . . . 14
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 15 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 16
5.1. Media Type Registration . . . . . . . . . . . . . . . . . 16 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 17
5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 17 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 19
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 18 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19
5.4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 18 5.4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 20
5.4.1. SDP Example 1 . . . . . . . . . . . . . . . . . . . . 18 5.4.1. SDP Example 1 . . . . . . . . . . . . . . . . . . . . 20
5.4.2. SDP Example 2 . . . . . . . . . . . . . . . . . . . . 19 5.4.2. SDP Example 2 . . . . . . . . . . . . . . . . . . . . 20
6. G.711.0 Storage Mode Conventions and Definition . . . . . . . 19 6. G.711.0 Storage Mode Conventions and Definition . . . . . . . 21
6.1. G.711.0 PLC Frame . . . . . . . . . . . . . . . . . . . . 20 6.1. G.711.0 PLC Frame . . . . . . . . . . . . . . . . . . . . 21
6.2. G.711.0 Erasure Frame . . . . . . . . . . . . . . . . . . 20 6.2. G.711.0 Erasure Frame . . . . . . . . . . . . . . . . . . 21
6.3. G.711.0 Storage Mode Definition . . . . . . . . . . . . . 21 6.3. G.711.0 Storage Mode Definition . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Congestion Control . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The International Telecommunication Union (ITU-T) Recommendation The International Telecommunication Union (ITU-T) Recommendation
G.711.0 [G.711.0] specifies a stateless and lossless compression for G.711.0 [G.711.0] specifies a stateless and lossless compression for
G.711 packet payloads typically used in Voice over IP (VoIP) G.711 packet payloads typically used in Voice over IP (VoIP)
networks. This document specifies the Real-Time Transport Protocol networks. This document specifies the Real-Time Transport Protocol
(RTP) RFC 3550 [RFC3550] payload format and storage modes for this (RTP) RFC 3550 [RFC3550] payload format and storage modes for this
compression. compression.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
stateless and lossless compression for G.711 packet payloads stateless and lossless compression for G.711 packet payloads
typically used in VoIP networks. ITU-T Rec. G.711.0 is also known as typically used in VoIP networks. ITU-T Rec. G.711.0 is also known as
ITU-T Rec. G.711 Annex A [G.711-A1], as ITU-T Rec. G.711 Annex A is ITU-T Rec. G.711 Annex A [G.711-A1], as ITU-T Rec. G.711 Annex A is
effectively a pointer ITU-T Rec. G.711.0. Henceforth in this effectively a pointer ITU-T Rec. G.711.0. Henceforth in this
document, ITU-T Rec. G.711.0 will simply be referred to as "G.711.0" document, ITU-T Rec. G.711.0 will simply be referred to as "G.711.0"
and ITU-T Rec. G.711 simply as "G.711". and ITU-T Rec. G.711 simply as "G.711".
G.711.0 may be employed end-to-end; in which case the RTP payload G.711.0 may be employed end-to-end; in which case the RTP payload
format specification and use is nearly identical to the G.711 RTP format specification and use is nearly identical to the G.711 RTP
specification found in RFC 3550 [RFC3550]. The only significant specification found in RFC 3550 [RFC3550]. The only significant
difference for G.711.0 is the use of a dynamic payload type (the difference for G.711.0 is the required use of a dynamic payload type
static PT of 0 or 8 are virtually always used with G.711) and the (the static PT of 0 or 8 is presently almost always used with G.711
recommendation not to use Voice Activity Detection (see Section 4.1). even though dynamic assignment of other payload types is allowed) and
the recommendation not to use Voice Activity Detection (see
Section 4.1).
G.711.0, being both lossless and stateless, may also be employed as a G.711.0, being both lossless and stateless, may also be employed as a
lossless compression mechanism anywhere in between end systems which lossless compression mechanism anywhere in between end systems which
have negotiated use of G.711. Because the only significance between have negotiated use of G.711. Because the only significance between
the G.711 RTP payload format header and the G.711.0 payload format the G.711 RTP payload format header and the G.711.0 payload format
header is the payload type, a G.711 RTP packet can be losslessly header is the payload type, a G.711 RTP packet can be losslessly
converted to a G.711.0 RTP packet simply by compressing the G.711 converted to a G.711.0 RTP packet simply by compressing the G.711
payload (thus creating a G.711.0 payload), changing the payload type payload (thus creating a G.711.0 payload), changing the payload type
to the dynamic value desired and copying all the remaining G.711 RTP to the dynamic value desired and copying all the remaining G.711 RTP
header fields into the corresponding G.711.0 RTP header. Conversely, header fields into the corresponding G.711.0 RTP header. Conversely,
skipping to change at page 4, line 49 skipping to change at page 4, line 51
The fundamental design of G.711.0 resulted from the desire to The fundamental design of G.711.0 resulted from the desire to
losslessly encode and compress frames of G.711 symbols independent of losslessly encode and compress frames of G.711 symbols independent of
what types of signals those G.711 frames contained. The primary what types of signals those G.711 frames contained. The primary
G.711.0 use case is for G.711 encoded, zero-mean, acoustic signals G.711.0 use case is for G.711 encoded, zero-mean, acoustic signals
(such as speech and music). (such as speech and music).
G.711.0 attributes are below: G.711.0 attributes are below:
A1 Compression for zero-mean acoustic signals: G.711.0 was designed A1 Compression for zero-mean acoustic signals: G.711.0 was designed
as its primary use case for the compression of G.711 payloads as its primary use case for the compression of G.711 payloads
which contained "speech" or other zero-mean acoustic signals. that contained "speech" or other zero-mean acoustic signals.
G.711.0 obtains greater than 50% average compression in service G.711.0 obtains greater than 50% average compression in service
provider environments [ICASSP]. provider environments [ICASSP].
A2 Lossless for any G.711 payload: G.711.0 was designed to be A2 Lossless for any G.711 payload: G.711.0 was designed to be
lossless for any valid G.711 payload - even if the payload lossless for any valid G.711 payload - even if the payload
consisted of apparently random G.711 symbols (e.g., a modem or consisted of apparently random G.711 symbols (e.g., a modem or
FAX payload). G.711.0 could be used for "aggregate 64 kbps FAX payload). G.711.0 could be used for "aggregate 64 kbps
G.711 channels" carried over IP without explicit concern if a G.711 channels" carried over IP without explicit concern if a
subset of these channels happened to be carrying something subset of these channels happened to be carrying something
other than voice or general audio. To the extent that a other than voice or general audio. To the extent that a
skipping to change at page 6, line 20 skipping to change at page 6, line 23
A7 Algorithmic delay: G.711.0 was designed to have the algorithmic A7 Algorithmic delay: G.711.0 was designed to have the algorithmic
delay equal to the time represented by the number of samples in delay equal to the time represented by the number of samples in
the G.711 input frame (i.e., no "look-ahead"). the G.711 input frame (i.e., no "look-ahead").
A8 Low Complexity: Less than 1.0 WMOPS average and low memory A8 Low Complexity: Less than 1.0 WMOPS average and low memory
footprint (~5k octets RAM, ~5.7k octets ROM and ~3.6 basic footprint (~5k octets RAM, ~5.7k octets ROM and ~3.6 basic
operations) [ICASSP] [G.711.0]. operations) [ICASSP] [G.711.0].
A9 Both A-law and Mu-law supported: G.711 has two operating laws, A9 Both A-law and Mu-law supported: G.711 has two operating laws,
A-law and Mu-law. These two laws are also known as PCMA and A-law and Mu-law. These two laws are also known as PCMA and
PCMU in RTP applicaitons RFC 3550 [RFC3550]. PCMU in RTP applications RFC 3550 [RFC3550].
These attributes generally make it trivial to compress a G.711 input These attributes generally make it trivial to compress a G.711 input
frame consisting of 40, 80, 160, 240 or 320 samples. After the input frame consisting of 40, 80, 160, 240 or 320 samples. After the input
frame is presented to a G.711.0 encoder, a G.711.0 "self-describing" frame is presented to a G.711.0 encoder, a G.711.0 "self-describing"
output frame is produced. The number of samples contained within output frame is produced. The number of samples contained within
this frame is easily determined at the G.711.0 decoder by virtue of this frame is easily determined at the G.711.0 decoder by virtue of
attribute A4. The G.711.0 decoder can decode the G.711.0 frame back attribute A4. The G.711.0 decoder can decode the G.711.0 frame back
to a G.711 frame by using only data within the G.711.0 frame. to a G.711 frame by using only data within the G.711.0 frame.
Lastly we note that losing a G.711.0 encoded packet is identical in Lastly we note that losing a G.711.0 encoded packet is identical in
skipping to change at page 8, line 15 skipping to change at page 8, line 18
from zero-mean acoustic signals, an intelligent G.711.0 encoder could from zero-mean acoustic signals, an intelligent G.711.0 encoder could
tell if the G.711.0 payload had been encrypted - as the symbols would tell if the G.711.0 payload had been encrypted - as the symbols would
not have the distribution expected in either companding law and would not have the distribution expected in either companding law and would
appear random. Such determination is also not further discussed in appear random. Such determination is also not further discussed in
this document. this document.
It is easily seen that this process is 1:1 and that G.711.0 based It is easily seen that this process is 1:1 and that G.711.0 based
lossless compression can be employed multiple times, as the original lossless compression can be employed multiple times, as the original
G.711 input symbols are always reproduced with 100% fidelity. G.711 input symbols are always reproduced with 100% fidelity.
G.711.0 frames containing more source G.711 symbols from a given 3.3.1. Multiple G.711.0 Output Frames per RTP Payload Considerations
channel will typically result in higher compression as a general
rule, but there are exceptions. For example, an intelligent G.711.0 As a general rule, G.711.0 frames containing more source G.711
encoder may choose to encode 20 ms of G.711 as two individual 10 ms symbols (from a given channel) will typically result in higher
G.711.0 frames if a higher overall compression will result (this compression, but there are exceptions to this rule. A G.711.0
might occur if the first 10 ms was "silence" and two, 10 ms G.711.0 encoder may choose to encode 20 ms of input G.711 symbols as: 1) a
frames contained fewer octets than one 20 ms G.711.0 frame). For single 20 ms G.711.0 frame, or 2) as two 10 ms G.711.0 frames, or 3)
this reason, we will explicitly allow multiple G.711.0 encoded frames any other combination of 5 ms or 10 ms G.711.0 frames - depending on
in the G.711.0 RTP payload in Section 4.2.2 below even though the which encoding resulted in fewer bits. As an example, an intelligent
usual case is anticipated to be only one G.711.0 frame per RTP encoder might encode 20 ms of G.711 symbols as two 10 ms G.711.0
payload. frames if the first 10 ms was "silence" and two G.711.0 frames took
fewer bits than any other possible encoding combination of G.711.0
frame sizes.
During the process of G.711.0 standardization it was recognized that
although it is sometimes advantageous to encode integer multiples of
40 G.711 symbols in whatever input symbol format resulted in the most
compression (as per above), the simplest choice is to encode the
entire ptime's worth of input G.711 symbols into one G.711.0 frame
(if the ptime supported it). This is especially so since the larger
number of source G.711 symbols typically resulted in the highest
compression anyway and there is added complexity in searching for
other possibilities (involving more G.711.0 frames) which were
unlikely to produce a more bit efficient result.
The design of ITU-T Rec. G.711.0 [G.711.0] foresaw the possibility of
multiple G.711.0 input frames in that the decoder was defined to
decode what it refers to as an incoming "bit stream". For this
specification, the bit stream is the G.711.0 RTP payload itself.
Thus, the decoder will take the G.711.0 RTP payload and will produce
an output frame containing the original G.711 symbols independent of
how many G.711.0 frames were present in it. Additionally, any number
of 0x00 padding octets placed in between the G.711.0 frames will be
silently (and safely) ignored by the G.711.0 decoding process
Section 4.2.3).
To recap, a G.711.0 encoder may choose to encode incoming G.711
symbols into one or more than one G.711.0 frames and put the
resultant frame(s) into the G.711.0 RTP payload. Zero or more 0x00
padding octets may also be included in the G.711.0 RTP payload. The
G.711.0 decoder, being insensitive to the number of G.711.0 encoded
frames that are contained within it, will decode the G.711.0 RTP
payload into the source G.711 symbols. Although examples of single
or multiple G.711 frame cases will be illustrated in Section 4.2, the
multiple G.711.0 frame cases MUST be supported and there is no need
for negotiation (SDP or otherwise) required for it.
4. RTP Header and Payload 4. RTP Header and Payload
In this section we describe the precise format for G.711.0 frames In this section we describe the precise format for G.711.0 frames
carried via RTP. We begin with RTP header description relative to carried via RTP. We begin with RTP header description relative to
G.711, then provide two G.711.0 payload examples. G.711, then provide two G.711.0 payload examples.
4.1. G.711.0 RTP Header 4.1. G.711.0 RTP Header
Relative to G.711 RTP headers, the utilization of G.711.0 does not Relative to G.711 RTP headers, the utilization of G.711.0 does not
create any special requirements with respect to the contents of the create any special requirements with respect to the contents of the
RTP packet header. The only significant difference is that the RTP packet header. The only significant difference is that the
payload type (PT) RTP header field will have a value corresponding to payload type (PT) RTP header field will have a value corresponding to
the dynamic payload type assigned to the flow (whereas G.711 PCMU the dynamic payload type assigned to the flow. This is in contrast
typically has a static PT = 0 and G.711 PCMA typically has a static to most current uses of G.711 which typically use the static payload
PT = 8 [RFC3551]). assignment of PT = 0 (PCMU) or PT = 8 (PCMA) [RFC3551] even though
the negotiation and use of dynamic payload types is allowed for
G.711.
Voice Activity Detection (VAD) SHOULD NOT be used when G.711.0 is Voice Activity Detection (VAD) SHOULD NOT be used when G.711.0 is
negotiated because G.711.0 obtains high compression during "VAD negotiated because G.711.0 obtains high compression during "VAD
silence intervals" and one of the advantages of G.711.0 over G.711 silence intervals" and one of the advantages of G.711.0 over G.711
with VAD is the lack of any VAD-inducing artifacts in the received with VAD is the lack of any VAD-inducing artifacts in the received
signal. However, if VAD is employed, the Marker bit (M) MUST be set signal. However, if VAD is employed, the Marker bit (M) MUST be set
in the first packet of a talkspurt (the first packet after a silence in the first packet of a talkspurt (the first packet after a silence
period in which packets have not been transmitted contiguously as per period in which packets have not been transmitted contiguously as per
rules specified in [RFC3550] for G.711 payloads). This definition, rules specified in [RFC3550] for G.711 payloads). This definition,
being consistent with the G.711 RTP VAD use, further allows lossless being consistent with the G.711 RTP VAD use, further allows lossless
skipping to change at page 9, line 11 skipping to change at page 10, line 4
period in which packets have not been transmitted contiguously as per period in which packets have not been transmitted contiguously as per
rules specified in [RFC3550] for G.711 payloads). This definition, rules specified in [RFC3550] for G.711 payloads). This definition,
being consistent with the G.711 RTP VAD use, further allows lossless being consistent with the G.711 RTP VAD use, further allows lossless
transcoding between G.711 RTP packets and G.711.0 RTP packets as transcoding between G.711 RTP packets and G.711.0 RTP packets as
described in Section 3.1. described in Section 3.1.
With this introduction, the RTP packet header fields are defined as With this introduction, the RTP packet header fields are defined as
follows: follows:
V - As per [RFC3550] V - As per [RFC3550]
P - As per [RFC3550] P - As per [RFC3550]
X - As per [RFC3550] X - As per [RFC3550]
CC - As per [RFC3550] CC - As per [RFC3550]
M - As per [RFC3550] M - As per [RFC3550]
PT- Dynamic PT assigned, consistent with MIME allocation for PT - The assignment of an RTP payload type for the format defined
G711.0 defined in Media Type Definition (Section 5.1). in this memo is outside the scope of this document. The RTP
profiles in use currently mandate binding the payload type
dynamically for this payload format.
SN - As per [RFC3550] SN - As per [RFC3550]
timestamp - As per [RFC3550] timestamp - As per [RFC3550]
SSRC - As per [RFC3550] SSRC - As per [RFC3550]
CSRC - As per [RFC3550] CSRC - As per [RFC3550]
Where V (version bits), P (padding bit), X (extension bit), CC (CSRC Where V (version bits), P (padding bit), X (extension bit), CC (CSRC
count), M (marker bit), PT (payload type), SN (sequence number), count), M (marker bit), PT (payload type), SN (sequence number),
timestamp, SSRC (synchronizing source) and CSRC (contributing timestamp, SSRC (synchronizing source) and CSRC (contributing
sources) are as defined in [RFC3550] and as typically used with sources) are as defined in [RFC3550] and as typically used with
G.711. PT (payload type) is as defined in [RFC3550]. G.711. PT (payload type) is as defined in [RFC3550].
4.2. G.711.0 RTP Payload 4.2. G.711.0 RTP Payload
In this section we provide two examples for carrying G.711.0 frames This section defines the G.711.0 RTP payload and illustrates it by
in RTP payloads. The first example is used when it is desired to means of two examples.
carry only one G.711.0 frame in the RTP payload. This example is a
subset of the second and shown separately for clarity. The first example, in Section 4.2.1, depicts the case when it is
desired to carry only one G.711.0 frame in the RTP payload. This
case is expected to be the dominant use case and is shown separately
for the purposes of clarity.
The second example, in Section 4.2.2, depicts the general case when
it is desired to carry one or more G.711.0 frames in the RTP payload.
This is the actual definition of the G.711.0 RTP payload.
4.2.1. Single G.711.0 Frame per RTP Payload Example 4.2.1. Single G.711.0 Frame per RTP Payload Example
This example depicts a single G.711.0 frame in the RTP payload. This This example depicts a single G.711.0 frame in the RTP payload. This
is expected to be the dominant RTP payload case for G.711.0, as the is expected to be the dominant RTP payload case for G.711.0, as the
G.711.0 encoding process supports the SDP packet times (ptime and G.711.0 encoding process supports the SDP packet times (ptime and
maxptime, see [RFC4566]) commonly used when G.711 is transported in maxptime, see [RFC4566]) commonly used when G.711 is transported in
RTP. Additionally, as mentioned previously, larger G.711.0 frames RTP. Additionally, as mentioned previously, larger G.711.0 frames
generally compress more effectively than a multiplicity of smaller generally compress more effectively than a multiplicity of smaller
G.711.0 frames. G.711.0 frames.
The following Figure illustrates the single G.711.0 frame per RTP The following Figure illustrates the single G.711.0 frame per RTP
payload case. payload case.
skipping to change at page 10, line 40 skipping to change at page 11, line 35
padding may be desired based on security considerations (see padding may be desired based on security considerations (see
Section 10). Section 10).
Decoding Process: Passing the entire RTP payload to the G.711.0 Decoding Process: Passing the entire RTP payload to the G.711.0
decoder is sufficient for the G.711.0 decoder to create the source decoder is sufficient for the G.711.0 decoder to create the source
G.711 symbols. Any padding inserted after the G.711.0 frame (i.e., G.711 symbols. Any padding inserted after the G.711.0 frame (i.e.,
the 0x00 octets) present in the RTP payload is silently ignored by the 0x00 octets) present in the RTP payload is silently ignored by
the G.711.0 decoding process. The decoding process is fully the G.711.0 decoding process. The decoding process is fully
described in Section 4.2.3 below. described in Section 4.2.3 below.
4.2.2. Multiple G.711.0 Frames per RTP Payload Example 4.2.2. G.711.0 RTP Payload Definition
This example depicts the case where multiple G.711.0 frames are
desired in the RTP payload.
As described in Section 3.3, an "intelligent G.711.0 encoder" can This section defines the G.711.0 RTP payload and illustrates the case
decide to encode, let's say, 20 ms of G.711 symbols as two, 10 ms of when one or more G.711.0 frames are to be placed in the payload.
G.711.0 frames because a greater compression is attained for that All G.711.0 RTP decoders MUST support the general case described in
particular 20 ms segment. The "smart encoding" of such inputs is this section (rationale presented previously in Section 3.3.1).
accommodated by the ability to have multiple G.711.0 frames in the
RTP payload.
Note that since each G.711.0 frame is self-describing (see Attribute Note that since each G.711.0 frame is self-describing (see Attribute
A4 in Section 3.2), the individual G.711.0 frames in the RTP payload A4 in Section 3.2), the individual G.711.0 frames in the RTP payload
need not represent the same duration of time (i.e., a 5 ms G.711.0 need not represent the same duration of time (i.e., a 5 ms G.711.0
frame could be followed by a 20 ms G.711.0 frame). Owing to this, frame could be followed by a 20 ms G.711.0 frame). Owing to this,
the amount of time represented in the RTP payload MAY be any integer the amount of time represented in the RTP payload MAY be any integer
multiple of 5 ms (as 5 ms is the smallest interval of time that can multiple of 5 ms (as 5 ms is the smallest interval of time that can
be represented in a G.711.0 frame). be represented in a G.711.0 frame).
The following Figure illustrates the multiple G.711.0 frame per RTP The following Figure illustrates the one or more G.711.0 frames per
payload case where the number of G.711.0 frames placed in the RTP RTP payload case where the number of G.711.0 frames placed in the RTP
payload is N. payload is N. We note that when N is equal to 1 that this case is
identical to the previous example.
Multiple G.711.0 Frames in RTP Payload Case One or More G.711.0 Frames in RTP Payload Case
|----------|---------|----------|---------|----------------| |----------|---------|----------|---------|----------------|
| First | Second | | Nth | Zero or more | | First | Second | | Nth | Zero or more |
| G.711.0 | G.711.0 | ... | G.711.0 | 0x00 | | G.711.0 | G.711.0 | ... | G.711.0 | 0x00 |
| Frame | Frame | | Frame | Padding Octets | | Frame | Frame | | Frame | Padding Octets |
|__________|_________|__________|_________|________________| |__________|_________|__________|_________|________________|
Figure 3 Figure 3
We note here that the individual G.711.0 frames can be, and generally We note here that when we have multiple G.711.0 frames that the
are, of different lengths. The decoding process in the following individual frames can be, and generally are, of different lengths.
section is used to determine the frame boundaries. The decoding process in the following section is used to determine
the frame boundaries.
Encoding Process: One or more G.711.0 frames are placed in the RTP Encoding Process: One or more G.711.0 frames are placed in the RTP
payload simply by concatenating the G.711.0 frames together. The payload simply by concatenating the G.711.0 frames together. The
amount of time represented by the G.711 symbols compressed in all the amount of time represented by the G.711 symbols compressed in all the
G.711.0 frames in the RTP payload MUST correspond to the ptime G.711.0 frames in the RTP payload MUST correspond to the ptime
signaled for applications using SDP. Although not generally desired, signaled for applications using SDP. Although not generally desired,
padding in the RTP payload SHOULD be placed after the last G.711.0 padding in the RTP payload SHOULD be placed after the last G.711.0
frame in the payload and MAY be created by placing one or more 0x00 frame in the payload and MAY be created by placing one or more 0x00
octets after the last G.711.0 frame. Such padding may be desired octets after the last G.711.0 frame. Such padding may be desired
based on security considerations (see Section 10). based on security considerations (see Section 10).
Decoding Process: As G.711.0 frames can be of varying length, the Decoding Process: As G.711.0 frames can be of varying length, the
payload decoding process described in the following section is used payload decoding process described in the following section is used
to determine where the individual G.711.0 frame boundaries are. to determine where the individual G.711.0 frame boundaries are. Any
padding octets inserted before or after any G.711.0 frame in the RTP
payload is silently (and safely) ignored by the G.711.0 decoding
process.
4.2.3. G.711.0 RTP Payload Decoding Process 4.2.3. G.711.0 RTP Payload Decoding Process
The G.711.0 decoding process is a standard part of G.711.0 bit stream The G.711.0 decoding process is a standard part of G.711.0 bit stream
decoding and is implemented in the ITU-T Rec. G.711.0 reference code. decoding and is implemented in the ITU-T Rec. G.711.0 reference code.
The decoding process heuristic described in this section is a slight The decoding process heuristic described in this section is a slight
enhancement of the ITU-T reference code to explicitly accommodate RTP enhancement of the ITU-T reference code to explicitly accommodate RTP
padding (as described above). padding (as described above).
Before describing the decoding, we note here that the largest Before describing the decoding, we note here that the largest
skipping to change at page 16, line 18 skipping to change at page 17, line 13
registration for the G.711.0 codec. Mapping of the parameters into registration for the G.711.0 codec. Mapping of the parameters into
Session Description Protocol (SDP) RFC 4566 [RFC4566] is also Session Description Protocol (SDP) RFC 4566 [RFC4566] is also
provided for those applications that use SDP. provided for those applications that use SDP.
5.1. Media Type Registration 5.1. Media Type Registration
Type name: audio Type name: audio
Subtype name: G7110 Subtype name: G7110
Required Parameters: Required parameters:
rate: The RTP timestamp clock rate, which is equal to the sampling rate: The RTP timestamp clock rate, which is equal to the sampling
rate. The typical rate used with G.711 encoding is 8000, but rate. The typical rate used with G.711 encoding is 8000, but
other rates may be specified. The default rate is 8000. other rates may be specified. The default rate is 8000.
complaw: Indicates the companding law (A-law or mu-law) employed. complaw: Indicates the companding law (A-law or mu-law) employed.
The case-insensitive values are "al" or "mu" for A-law and mu-law, The case-insensitive values are "al" or "mu" for A-law and mu-law,
respectively. respectively.
Optional parameters: Optional parameters:
channels: See RFC 4566 [RFC4566] for definition. Specifies how channels: See RFC 4566 [RFC4566] for definition. Specifies how
many audio streams are represented in the G.711.0 payload and MUST many audio streams are represented in the G.711.0 payload and MUST
be present if the number of channels is greater than one. This be present if the number of channels is greater than one. This
parameter defaults to 1 if not present (as per RFC 4566) an is parameter defaults to 1 if not present (as per RFC 4566) and is
typically a non-zero small-valued positive integer. It is typically a non-zero small-valued positive integer. It is
expected that implementations that specify multiple channels will expected that implementations that specify multiple channels will
also define a mechanism to map the channels appropriately within also define a mechanism to map the channels appropriately within
their system design, otherwise the channel order specified in RFC their system design, otherwise the channel order specified in RFC
3551 [RFC3551] Section 4.1 will be assumed (e.g., left, right, 3551 [RFC3551] Section 4.1 will be assumed (e.g., left, right,
center, ... ). center, ... ).
maxptime: See RFC 4566 [RFC4566] for definition. maxptime: See RFC 4566 [RFC4566] for definition.
ptime: See RFC 4566 [RFC4566] for definition. The inclusion of ptime: See RFC 4566 [RFC4566] for definition. The inclusion of
skipping to change at page 17, line 7 skipping to change at page 17, line 50
application specific reason not to include it (e.g., an application specific reason not to include it (e.g., an
application that has a variable ptime on a packet-by-packet application that has a variable ptime on a packet-by-packet
basis). For constant ptime applications, it is considered good basis). For constant ptime applications, it is considered good
form to include "ptime" in the SDP for session diagnostic form to include "ptime" in the SDP for session diagnostic
purposes. For the constant ptime multiple channel case described purposes. For the constant ptime multiple channel case described
in Section 4.2.2, the inclusion of "ptime" can provide a desirable in Section 4.2.2, the inclusion of "ptime" can provide a desirable
payload check. payload check.
Encoding considerations: Encoding considerations:
This media type is framed binary data (see Section 4.8 in RFC 4288 This media type is framed binary data (see Section 4.8 in RFC 6838
[RFC4288]) compressed as per ITU-T Rec. G.711.0. [RFC6838]) compressed as per ITU-T Rec. G.711.0.
Security considerations: Security considerations:
This media type does not carry active content. It does transfer See Section 10.
compressed data. See Section 4 of RFC 4856 [RFC4856].
Interoperability considerations: none Interoperability considerations: none
Published specification: Published specification:
ITU-T Rec. G.711.0 and RFC QQQQ. ITU-T Rec. G.711.0 and RFC XXXX.
[ RFC Editor: please replace QQQQ with a reference to this RFC ] [ RFC Editor: please replace XXXXX with a reference to this RFC ]
Applications that use this media type: Applications that use this media type:
Audio and video streaming and conferencing tools. Although initially conceived for VoIP, the use of G.711.0, like
G.711 before it, may find use within audio and video streaming and
/or conferencing applications for the audio portion of those
applications.
Additional information: none Additional information:
The following applies to stored-file transfer methods:
Magic numbers: #!G7110A\n or #!G7110M\n (for A-law or MU-law
encodings respectively, see Section 6).
File Extensions: None
Macintosh file type code: None
Object identifier or OIL: None
Person & email address to contact for further information: Person & email address to contact for further information:
Michael Ramalho <mramalho@cisco.com> or <mar42@cornell.edu> Michael A. Ramalho <mramalho@cisco.com> or <mar42@cornell.edu>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: Restrictions on usage:
This media type depends on RTP framing, and hence is only defined This media type depends on RTP framing, and hence is only defined
for transfer via RTP [RFC3550]. Transport within other framing for transfer via RTP [RFC3550]. Transport within other framing
protocols is not defined at this time. protocols is not defined at this time.
Author: Michael Ramalho Author: Michael A. Ramalho
Change controller: Change controller:
IETF Audio/Video Transport working group delegated from the IESG. IETF Payload working group delegated from the IESG.
5.2. Mapping to SDP Parameters 5.2. Mapping to SDP Parameters
The information carried in the media type specification has a The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP), specific mapping to fields in the Session Description Protocol (SDP),
which is commonly used to describe RTP sessions. When SDP is used to which is commonly used to describe RTP sessions. When SDP is used to
specify sessions employing G.711.0, the mapping is as follows: specify sessions employing G.711.0, the mapping is as follows:
o The media type ("audio") goes in SDP "m=" as the media name. o The media type ("audio") goes in SDP "m=" as the media name.
skipping to change at page 19, line 38 skipping to change at page 20, line 47
a=rtpmap: 98 G7110/8000/1 a=rtpmap: 98 G7110/8000/1
a=ptime: 20 a=ptime: 20
a=fmtp:98 complaw = al a=fmtp:98 complaw = al
In this example the offer had an optional channels parameter. The In this example the offer had an optional channels parameter. The
answer must have the optional channels parameter also unless the answer must have the optional channels parameter also unless the
value in the answer is one. Shown here is when the answer explicitly value in the answer is one. Shown here is when the answer explicitly
contains the channels parameter (it need not have and it would be contains the channels parameter (it need not have and it would be
interpreted as one channel). As mentioned previously, it is interpreted as one channel). As mentioned previously, it is
considered good form to include "ptime" in the SDP for session considered good form to include "ptime" in the SDP for session
diagnostic purposes if the session is a contstant ptime session. diagnostic purposes if the session is a constant ptime session.
6. G.711.0 Storage Mode Conventions and Definition 6. G.711.0 Storage Mode Conventions and Definition
The G.711.0 storage mode definition in this section is similar to The G.711.0 storage mode definition in this section is similar to
many other IETF codecs (e.g., iLBC, EVRC-NW) and is essentially a many other IETF codecs (e.g., iLBC, EVRC-NW) and is essentially a
concatenation of individual G.711.0 frames. concatenation of individual G.711.0 frames.
We note that something must be stored for any G.711.0 frames that not We note that something must be stored for any G.711.0 frames that not
received at the receiving endpoint, no matter what the cause. In received at the receiving endpoint, no matter what the cause. In
this section we describe two mechanisms, a "G.711.0 PLC Frame" and a this section we describe two mechanisms, a "G.711.0 PLC Frame" and a
skipping to change at page 21, line 17 skipping to change at page 22, line 30
muted, many of these systems will send an entire G.711 payload of muted, many of these systems will send an entire G.711 payload of
either 0+ or 0- (i.e., one of the two levels closest to "analog zero" either 0+ or 0- (i.e., one of the two levels closest to "analog zero"
in either G.711 companding law). Next we note that a desirable in either G.711 companding law). Next we note that a desirable
property for a G.711.0 erasure frame is for "non G.711.0 Erasure property for a G.711.0 erasure frame is for "non G.711.0 Erasure
Frame aware" endpoints to be able to playback a G.711.0 erasure frame Frame aware" endpoints to be able to playback a G.711.0 erasure frame
with the existing G.711.0 ITU-T reference code. with the existing G.711.0 ITU-T reference code.
A G.711.0 Erasure Frame is defined as any G.711.0 frame for which the A G.711.0 Erasure Frame is defined as any G.711.0 frame for which the
corresponding G.711 sample values are either the value 0++ or the corresponding G.711 sample values are either the value 0++ or the
value 0-- for the entirety of the G.711.0 frame. The levels of 0++ value 0-- for the entirety of the G.711.0 frame. The levels of 0++
and 0-- are defined two levels above or below analog zero, and 0-- are defined to be the two levels above or below analog zero,
respectively. An entire frame of value 0++ or 0-- is expected to be respectively. An entire frame of value 0++ or 0-- is expected to be
extraordinarily rare when the frame was in fact generated by a extraordinarily rare when the frame was in fact generated by a
natural signal (on the order of one in 2^{ptime in samples, minus natural signal (on the order of one in 2^{ptime in samples, minus
one}), as analog inputs such as speech and music are zero-mean and one}), as analog inputs such as speech and music are zero-mean and
are typically acoustically coupled to digital sampling systems. Note are typically acoustically coupled to digital sampling systems. Note
that the playback of a G.711.0 frame characterized as an erasure that the playback of a G.711.0 frame characterized as an erasure
frame is auditorially equivalent to a muted signal (a very low value frame is auditorially equivalent to a muted signal (a very low value
constant). constant).
These G.711.0 erasure frames can be reasonably characterized as null These G.711.0 erasure frames can be reasonably characterized as null
skipping to change at page 22, line 16 skipping to change at page 23, line 28
followed by the individual G.711.0 frames concatenated together. followed by the individual G.711.0 frames concatenated together.
The magic number for G.711.0 A-law corresponds to the ASCII character The magic number for G.711.0 A-law corresponds to the ASCII character
string "#!G7110A\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x30 0x41 string "#!G7110A\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x30 0x41
0x0A". Likewise, the magic number for G.711.0 MU-law corresponds to 0x0A". Likewise, the magic number for G.711.0 MU-law corresponds to
the ASCII character string "#!G7110M\n", i.e., "0x23 0x21 0x47 0x37 the ASCII character string "#!G7110M\n", i.e., "0x23 0x21 0x47 0x37
0x31 0x31 0x4E 0x4D 0x0A". 0x31 0x31 0x4E 0x4D 0x0A".
The version number octet allows for the future specification of other The version number octet allows for the future specification of other
G.711.0 storage mode formats. The specification of other storage G.711.0 storage mode formats. The specification of other storage
mode formats may be desireable as G.711.0 frames are of variable mode formats may be desirable as G.711.0 frames are of variable
length and a future format may include an indexing methodology that length and a future format may include an indexing methodology that
would enable playout far into a long G.711.0 recording without the would enable playout far into a long G.711.0 recording without the
necessity of decoding all the G.711.0 frames since the beginning of necessity of decoding all the G.711.0 frames since the beginning of
the recording. Other future format specification may include support the recording. Other future format specification may include support
for multiple channels, metadata and the like. For these reasons it for multiple channels, metadata and the like. For these reasons it
was determined that a versioning strategy was desirable for the was determined that a versioning strategy was desirable for the
G.711.0 storage mode definition specified by this RFC. This RFC only G.711.0 storage mode definition specified by this RFC. This RFC only
specifies Version 0 and thus the value of "0x00" must be used for the specifies Version 0 and thus the value of "0x00" must be used for the
storage mode defined by this RFC. storage mode defined by this RFC.
skipping to change at page 23, line 47 skipping to change at page 25, line 7
other than discarding complete packets. To allow any (media-aware) other than discarding complete packets. To allow any (media-aware)
intermediate network element to perform its operations, it is intermediate network element to perform its operations, it is
required to be a trusted entity which is included in the security required to be a trusted entity which is included in the security
context establishment. context establishment.
G.711.0 has no known denial-of-service attacks due to decoding, as G.711.0 has no known denial-of-service attacks due to decoding, as
data posing as a desired G711.0 payload will be decoded into data posing as a desired G711.0 payload will be decoded into
something (as per the decoding algorithm) with a finite amount of something (as per the decoding algorithm) with a finite amount of
computation. This is due to the decompression algorithm having a computation. This is due to the decompression algorithm having a
finite worst-case processing path (no infinite computational loops finite worst-case processing path (no infinite computational loops
are possible). are possible). Therefore a G.711.0 payload does not carry "active
content" that could impose malicious side-effects upon the receiver.
G.711.0 is a variable bit rate (VBR) audio codec. There have been G.711.0 is a variable bit rate (VBR) audio codec. There have been
recent concerns with VBR speech codecs where a passive observer can recent concerns with VBR speech codecs where a passive observer can
identify phrases from a standard speech corpus by means of the identify phrases from a standard speech corpus by means of the
lengths produced by the encoder even when the payload is encrypted lengths produced by the encoder even when the payload is encrypted
[IEEE]. In this paper, it was determined that some code excited [IEEE]. In this paper, it was determined that some code excited
linear prediction (CELP) codecs would produce discrete packet lengths linear prediction (CELP) codecs would produce discrete packet lengths
for some phonemes. And furthermore with the use of appropriately for some phonemes. And furthermore with the use of appropriately
designed Hidden Markov Models (HMMs) that such a system could predict designed Hidden Markov Models (HMMs) that such a system could predict
phrases with unexpected accuracy. One CELP codec studied, SPEEX, had phrases with unexpected accuracy. One CELP codec studied, SPEEX, had
the property that it produced 21 different packet lengths in its the property that it produced 21 different packet lengths in its
wideband mode and that these packet lengths probabilistically mapped wideband mode and that these packet lengths probabilistically mapped
to phonemes that a HMM system could be trained on. In this paper it to phonemes that a HMM system could be trained on. In this paper it
was determined that a mitigation technique would be to pad the output was determined that a mitigation technique would be to pad the output
of the encoder with random padding lengths to the effect: 1) that of the encoder with random padding lengths to the effect: 1) that
skipping to change at page 24, line 29 skipping to change at page 25, line 38
lengths which are not likely to have a strong mapping to phonemes. lengths which are not likely to have a strong mapping to phonemes.
Thus G.711.0 is not expected to have this same vulnerability. It Thus G.711.0 is not expected to have this same vulnerability. It
should be noted that "silence" (only one value of G.711 in the entire should be noted that "silence" (only one value of G.711 in the entire
G.711 input frame)" or "near silence" (only a few G.711 values) is G.711 input frame)" or "near silence" (only a few G.711 values) is
easily detectable as G.711.0 frame lengths or one or a few octets. easily detectable as G.711.0 frame lengths or one or a few octets.
If one desires to mitigate for silence/non-silence detection, If one desires to mitigate for silence/non-silence detection,
statistically variable padding should be added to G.711.0 frames that statistically variable padding should be added to G.711.0 frames that
resulted in very small G.711.0 frames (less than about 20% of the resulted in very small G.711.0 frames (less than about 20% of the
symbols of the corresponding G.711 input frame). Methods of symbols of the corresponding G.711 input frame). Methods of
introducing padding in the G.711.0 payloads have been provided in the introducing padding in the G.711.0 payloads have been provided in the
G.711.0 RTP payload definitions in Section 4.2.1 and Section 4.2.2. G.711.0 RTP payload definition in Section 4.2.2.
11. References 11. Congestion Control
11.1. Normative References The G.711 codec is a Constant Bit Rate (CBR) codec which does not
have a means to regulate the bitrate. The G.711.0 lossless
compression algorithm typically compresses the G.711 CBR stream into
a smaller VBR stream. However, being lossless, it does not possess
means of further reducing the bitrate beyond the G.711.0-based
compression result. The G.711.0 RTP payloads can be made arbitrarily
large by means of adding optional padding bytes (subject only to MTU
limitations).
Therefore, there are no explicit ways to regulate the bit-rate of the
transmissions outlined in this RTP Payload format except by means of
modulating the number of optional padding bytes in the RTP payload.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Registration Procedures", RFC 4288, December 2005. Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in
the RTP Profile for Audio and Video Conferences", RFC
4856, February 2007.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
skipping to change at page 25, line 43 skipping to change at page 27, line 15
[G.711-AP1] [G.711-AP1]
ITU-T G.711 Appendix 1, , "Recommendation G.711 ITU-T G.711 Appendix 1, , "Recommendation G.711
Appendix 1: A high quality low-complexity algorithm for Appendix 1: A high quality low-complexity algorithm for
packet loss concealment with G.711", September 1999. packet loss concealment with G.711", September 1999.
[G.711-A1] [G.711-A1]
ITU-T G.711 Amendment 1, , "Recommendation ITU-T G.711 ITU-T G.711 Amendment 1, , "Recommendation ITU-T G.711
Amendment 1 - Amendment 1: New Annex A on Lossless Amendment 1 - Amendment 1: New Annex A on Lossless
Encoding of PCM Frames", September 2009. Encoding of PCM Frames", September 2009.
11.2. Informative References 12.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[G.729] ITU-T G.729, , "Recommendation ITU-T G.729 - Coding of [G.729] ITU-T G.729, , "Recommendation ITU-T G.729 - Coding of
speech at 8 kbit/s using conjugate-structure algebraic- speech at 8 kbit/s using conjugate-structure algebraic-
code-excited linear prediction (CS-ACELP)", January 2007. code-excited linear prediction (CS-ACELP)", January 2007.
[G.722] ITU-T G.722, , "Recommendation ITU-T G.722 - 7 kHz audio- [G.722] ITU-T G.722, , "Recommendation ITU-T G.722 - 7 kHz audio-
coding within 64 kbit/s", November 1988. coding within 64 kbit/s", November 1988.
[ICASSP] N. Harada, , Y. Yamamoto, , T. Moriya, , Y. Hiwasaki, , M. [ICASSP] N. Harada, , Y. Yamamoto, , T. Moriya, , Y. Hiwasaki, , M.
A. Ramalho, , L. Netsch, , Y. Stachurski, , Miao Lei, , H. A. Ramalho, , L. Netsch, , Y. Stachurski, , Miao Lei, , H.
 End of changes. 43 change blocks. 
108 lines changed or deleted 179 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/