draft-ietf-payload-g7110-02.txt   draft-ietf-payload-g7110-03.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: September 4, 2014 N. Harada Expires: February 23, 2015 N. Harada
NTT NTT
M. Perumal M. Perumal
Cisco Systems Ericsson
L. Miao L. Miao
Huawei Technologies Huawei Technologies
March 3, 2014 August 22, 2014
RTP Payload Format for G.711.0 RTP Payload Format for G.711.0
draft-ietf-payload-g7110-02 draft-ietf-payload-g7110-03
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 September 4, 2014. This Internet-Draft will expire on February 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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
3.3.1. Multiple G.711.0 Output Frames per RTP Payload 3.3.1. Multiple G.711.0 Output Frames per RTP Payload
Considerations . . . . . . . . . . . . . . . . . . . 8 Considerations . . . . . . . . . . . . . . . . . . . 8
4. RTP Header and Payload . . . . . . . . . . . . . . . . . . . 9 4. RTP Header and Payload . . . . . . . . . . . . . . . . . . . 9
4.1. G.711.0 RTP Header . . . . . . . . . . . . . . . . . . . 9 4.1. G.711.0 RTP Header . . . . . . . . . . . . . . . . . . . 9
4.2. G.711.0 RTP Payload . . . . . . . . . . . . . . . . . . . 10 4.2. G.711.0 RTP Payload . . . . . . . . . . . . . . . . . . . 10
4.2.1. Single G.711.0 Frame per RTP Payload Example . . . . 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.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 . . . . . . 14 4.2.4. G.711.0 RTP Payload for Multiple Channels . . . . . . 14
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 16 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 17
5.1. Media Type Registration . . . . . . . . . . . . . . . . . 17 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 17
5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 19 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 19
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19
5.4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 20 5.4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 20
5.4.1. SDP Example 1 . . . . . . . . . . . . . . . . . . . . 20 5.4.1. SDP Example 1 . . . . . . . . . . . . . . . . . . . . 20
5.4.2. SDP Example 2 . . . . . . . . . . . . . . . . . . . . 20 5.4.2. SDP Example 2 . . . . . . . . . . . . . . . . . . . . 20
6. G.711.0 Storage Mode Conventions and Definition . . . . . . . 21 6. G.711.0 Storage Mode Conventions and Definition . . . . . . . 21
6.1. G.711.0 PLC Frame . . . . . . . . . . . . . . . . . . . . 21 6.1. G.711.0 PLC Frame . . . . . . . . . . . . . . . . . . . . 21
6.2. G.711.0 Erasure Frame . . . . . . . . . . . . . . . . . . 21 6.2. G.711.0 Erasure Frame . . . . . . . . . . . . . . . . . . 22
6.3. G.711.0 Storage Mode Definition . . . . . . . . . . . . . 22 6.3. G.711.0 Storage Mode Definition . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. Congestion Control . . . . . . . . . . . . . . . . . . . . . 25 11. Congestion Control . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 4 skipping to change at page 4, line 4
recommendation, G.711.0, has been established for defining a recommendation, G.711.0, has been established for defining a
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 3551 [RFC3551]. The only significant
difference for G.711.0 is the required use of a dynamic payload type difference for G.711.0 is the required use of a dynamic payload type
(the static PT of 0 or 8 is presently almost always used with G.711 (the static PT of 0 or 8 is presently almost always used with G.711
even though dynamic assignment of other payload types is allowed) and even though dynamic assignment of other payload types is allowed) and
the recommendation not to use Voice Activity Detection (see the recommendation not to use Voice Activity Detection (see
Section 4.1). 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 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,
the corresponding decompression of a G.711.0 RTP packet back to the the corresponding decompression of a G.711.0 RTP packet back to the
original source G.711 RTP packet can be accomplished by losslessly original source G.711 RTP packet can be accomplished by losslessly
decompressing the G.711.0 payload back to the original source G.711 decompressing the G.711.0 payload back to the original source G.711
skipping to change at page 6, line 21 skipping to change at page 6, line 21
function of the G.711 symbols input to it. function of the G.711 symbols input to it.
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 applications RFC 3550 [RFC3550]. PCMU in RTP applications RFC 3551 [RFC3551].
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 7, line 21 skipping to change at page 7, line 21
| 160, 240 or 320 octets) |<-----| G.711.0 ability to compress) | | 160, 240 or 320 octets) |<-----| G.711.0 ability to compress) |
|__________________________| B |______________________________| |__________________________| B |______________________________|
Figure 1 Figure 1
Note that the mapping is 1:1 (lossless) in both directions, subject Note that the mapping is 1:1 (lossless) in both directions, subject
to two constraints. The first constraint is that the input frame to two constraints. The first constraint is that the input frame
provided to the G.711.0 encoder (process "A") has a specific number provided to the G.711.0 encoder (process "A") has a specific number
of input G.711 symbols consistent with attribute A5 (40, 80, 160, 240 of input G.711 symbols consistent with attribute A5 (40, 80, 160, 240
or 320 octets). The second constraint is that the compression law or 320 octets). The second constraint is that the compression law
used to create the G.711 input frame (A-law or Mu-law) must be known, used to create the G.711 input frame (A-law or mu-law) must be known,
consistent with attribute A9. consistent with attribute A9.
Subject to these two constraints, the input G.711 frame is processed Subject to these two constraints, the input G.711 frame is processed
by the G.711.0 encoder ("A") and produces a "self-describing" G.711.0 by the G.711.0 encoder ("A") and produces a "self-describing" G.711.0
output frame, consistent with attribute A4. Depending on the source output frame, consistent with attribute A4. Depending on the source
G.711 symbols, the G.711.0 output frame can contain anywhere from 1 G.711 symbols, the G.711.0 output frame can contain anywhere from 1
to X+1 octets, where X is the number of input G.711 symbols. to X+1 octets, where X is the number of input G.711 symbols.
Compression results for virtually every zero-mean acoustic signal Compression results for virtually every zero-mean acoustic signal
encoded by G.711.0. encoded by G.711.0.
Since the G.711.0 output frame is "self-describing", a G.711.0 Since the G.711.0 output frame is "self-describing", a G.711.0
decoder (process "B") can losslessly reproduce the original G.711 decoder (process "B") can losslessly reproduce the original G.711
input frame with only the knowledge of which companding law was used input frame with only the knowledge of which companding law was used
(A-law or Mu-law). The G.711.0 frame, being "self-describing", (A-law or mu-law). The G.711.0 frame, being "self-describing",
allows for the G.711.0 decoder ("B") to know precisely how many G.711 allows for the G.711.0 decoder ("B") to know precisely how many G.711
symbols to create. symbols to create.
Since G.711.0 was designed with typical G.711 payload lengths as a Since G.711.0 was designed with typical G.711 payload lengths as a
design constraint (attribute A5), this lossless encoding can be design constraint (attribute A5), this lossless encoding can be
performed only with knowledge of the companding law being used. This performed only with knowledge of the companding law being used. This
information is anticipated to be signaled in SDP and will be information is anticipated to be signaled in SDP and will be
described later in this document. described later in this document.
If the original inputs were known to be from a zero-mean acoustic If the original inputs were known to be from a zero-mean acoustic
skipping to change at page 8, line 50 skipping to change at page 8, line 50
other possibilities (involving more G.711.0 frames) which were other possibilities (involving more G.711.0 frames) which were
unlikely to produce a more bit efficient result. unlikely to produce a more bit efficient result.
The design of ITU-T Rec. G.711.0 [G.711.0] foresaw the possibility of 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 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 decode what it refers to as an incoming "bit stream". For this
specification, the bit stream is the G.711.0 RTP payload itself. 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 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 an output frame containing the original G.711 symbols independent of
how many G.711.0 frames were present in it. Additionally, any number 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 of 0x00 padding octets placed between the G.711.0 frames will be
silently (and safely) ignored by the G.711.0 decoding process silently (and safely) ignored by the G.711.0 decoding process
Section 4.2.3). Section 4.2.3).
To recap, a G.711.0 encoder may choose to encode incoming G.711 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 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 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 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 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 frames that are contained within it, will decode the G.711.0 RTP
payload into the source G.711 symbols. Although examples of single payload into the source G.711 symbols. Although examples of single
skipping to change at page 9, line 43 skipping to change at page 9, line 43
the negotiation and use of dynamic payload types is allowed for the negotiation and use of dynamic payload types is allowed for
G.711. 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 [RFC3551] 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] and [RFC3551]
PT - The assignment of an RTP payload type for the format defined PT - The assignment of an RTP payload type for the format defined
in this memo is outside the scope of this document. The RTP in this memo is outside the scope of this document. The RTP
profiles in use currently mandate binding the payload type profiles in use currently mandate binding the payload type
dynamically for this payload format. 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 [RFC3551].
4.2. G.711.0 RTP Payload 4.2. G.711.0 RTP Payload
This section defines the G.711.0 RTP payload and illustrates it by This section defines the G.711.0 RTP payload and illustrates it by
means of two examples. means of two examples.
The first example, in Section 4.2.1, depicts the case when it is 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 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 case is expected to be the dominant use case and is shown separately
for the purposes of clarity. for the purposes of clarity.
skipping to change at page 12, line 7 skipping to change at page 12, line 7
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 one or more G.711.0 frames per The following Figure illustrates the one or more G.711.0 frames per
RTP 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. We note that when N is equal to 1 that this case is payload is N. We note that when N is equal to 1 that this case is
identical to the previous example. identical to the previous example.
One or More 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 |
|__________|_________|__________|_________|________________| |__________|_________|__________|_________|________________|
skipping to change at page 12, line 46 skipping to change at page 12, line 46
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. Any 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 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 payload is silently (and safely) ignored by the G.711.0 decoding
process. 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 algorithm 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
possible G.711.0 frame is created whenever the largest number of possible G.711.0 frame is created whenever the largest number of
G.711 symbols is encoded (320 from Section 3.2, property A5) and G.711 symbols is encoded (320 from Section 3.2, property A5) and
these 320 symbols are "uncompressible" by the G.711.0 encoder. In these 320 symbols are "uncompressible" by the G.711.0 encoder. In
this case (via property A6 in Section 3.2) the G.711.0 output frame this case (via property A6 in Section 3.2) the G.711.0 output frame
will be 321 octets long. We also note that the value 0x00 chosen for will be 321 octets long. We also note that the value 0x00 chosen for
the optional padding cannot be the first octet of a valid ITU-T Rec. the optional padding cannot be the first octet of a valid ITU-T Rec.
G.711.0 frame (see [G.711.0]). We also note that whenever more than G.711.0 frame (see [G.711.0]). We also note that whenever more than
one G.711.0 frame is contained in the RTP payload, the decoding of one G.711.0 frame is contained in the RTP payload, the decoding of
the individual G.711.0 frames will occur multiple times. the individual G.711.0 frames will occur multiple times.
For the decoding heuristic below, let N be the number of octets in For the decoding algorithm below, let N be the number of octets in
the RTP payload (i.e., excluding any RTP padding, but including any the RTP payload (i.e., excluding any RTP padding, but including any
RTP payload padding), let P equal the number of RTP payload octets RTP payload padding), let P equal the number of RTP payload octets
processed by the G.711.0 decoding process, let K be the number of processed by the G.711.0 decoding process, let K be the number of
G.711 symbols presently in the output buffer, let Q be the number of G.711 symbols presently in the output buffer, let Q be the number of
octets contained in the G.711.0 frame being processed and let "!=" octets contained in the G.711.0 frame being processed and let "!="
represent not equal to. The keyword "STOP" is used below to indicate represent not equal to. The keyword "STOP" is used below to indicate
the end of the processing of G.711.0 frames in the RTP payload. The the end of the processing of G.711.0 frames in the RTP payload. The
heuristic below assumes an output buffer for the decoded G.711 source algorithm below assumes an output buffer for the decoded G.711 source
symbols of length sufficient to accommodate the expected number of symbols of length sufficient to accommodate the expected number of
G.711 symbols and an input buffer of length 321 octets. G.711 symbols and an input buffer of length 321 octets.
G.711.0 RTP Payload Decoding Heuristic: G.711.0 RTP Payload Decoding Heuristic:
H1 Initialization: Initialize the number of processed octets to zero H1 Initialization of counters: Initialize P, the number of processed
(P = 0). Initialize the counter for how many G.711 symbols are octets counter, to zero. Initialize K, the counter for how
in the output buffer to zero (K = 0). Initialize N to the many G.711 symbols are in the output buffer, to zero.
number of octets in the RTP payload. Go to H2. Initialize N to the number of octets in the RTP payload
(including any RTP payload padding). Go to H2.
H2 Read internal buffer: Read min{320+1, (N-P)} octets into the H2 Read internal buffer: Read min{320+1, (N-P)-1} octets into the
internal buffer from the (P+1) octet of the RTP payload. We internal buffer from the (P+1) octet of the RTP payload. We
note at this point, N-P octets have yet to be processed and note at this point, N-P octets have yet to be processed and
that 320+1 octets is the largest possible G.711.0 frame. Go to that 320+1 octets is the largest possible G.711.0 frame. Also
H3. note that in the common case of zero-based array indexing of a
uint8 array of octets, that this operation will read octets
from index P through index [min{320+1, (N-P)}] from the RTP
payload. Go to H3.
H3 Analyze the first octet in the internal buffer: If this octet H3 Analyze the first octet in the internal buffer: If this octet
0x00 (a padding octet) go to H4, otherwise go to H5 (process a 0x00 (a padding octet) go to H4, otherwise go to H5 (process a
G.711.0 frame). G.711.0 frame).
H4 Process padding octet (no G.711 symbols generated): Increment the H4 Process padding octet (no G.711 symbols generated): Increment the
processed packets counter by one (set P = P + 1). If the processed packets counter by one (set P = P + 1). If the
result of this increment results in P >= N then STOP (as all result of this increment results in P >= N then STOP (as all
RTP Payload octets have been processed), otherwise go to H2. RTP Payload octets have been processed), otherwise go to H2.
skipping to change at page 14, line 13 skipping to change at page 14, line 17
The G.711.0 decoder will read the first octet (called the The G.711.0 decoder will read the first octet (called the
"prefix code" octet in ITU-T Rec. G.711.0 [G.711.0]) to "prefix code" octet in ITU-T Rec. G.711.0 [G.711.0]) to
determine the number of source G.711 samples M are contained in determine the number of source G.711 samples M are contained in
this G.711.0 frame. The G.711.0 decoder will produce exactly M this G.711.0 frame. The G.711.0 decoder will produce exactly M
G.711 source symbols. If K = 0, these M symbols will be the G.711 source symbols. If K = 0, these M symbols will be the
first in the output buffer and are placed at the beginning of first in the output buffer and are placed at the beginning of
the output buffer. If K != 0, concatenate these M symbols with the output buffer. If K != 0, concatenate these M symbols with
the prior symbols in the output buffer (there are K prior the prior symbols in the output buffer (there are K prior
symbols in the buffer). Set K = K + M (as there are now this symbols in the buffer). Set K = K + M (as there are now this
many G.711 source symbols in the output buffer). The G.711.0 many G.711 source symbols in the output buffer). The G.711.0
decoder will have consumed some number of packets, Q, in the decoder will have consumed some number of octets, Q, in the
internal buffer to produce the M G.711 symbols. Increment the internal buffer to produce the M G.711 symbols. Increment the
number of payload octet processed counter by this quantity (set number of payload octet processed counter by this quantity (set
P = P + Q). If the result of this increment results in P >= N P = P + Q). If the result of this increment results in P >= N
then STOP (as all RTP Payload octets have been processed), then STOP (as all RTP Payload octets have been processed),
otherwise go to H2. otherwise go to H2.
At this point, the output buffer will contain precisely K G.711 At this point, the output buffer will contain precisely K G.711
source symbols which should correspond to the ptime signaled if SDP source symbols which should correspond to the ptime signaled if SDP
was used and the encoding process was without error. was used and the encoding process was without error.
We also note, as an aside, that the heuristic above (and the ITU-T We also note, as an aside, that the algorithm above (and the ITU-T
G.711.0 reference code) accommodates padding octets (0x00) placed G.711.0 reference code) accommodates padding octets (0x00) placed
anywhere in between G.711.0 frames in the RTP payload as well as anywhere between G.711.0 frames in the RTP payload as well as prior
prior to or after any or all G.711.0 frames. The ITU-T G.711.0 to or after any or all G.711.0 frames. The ITU-T G.711.0 reference
reference code does not have Step H3 and H4 as separate steps (i.e., code does not have Step H3 and H4 as separate steps (i.e., Step H5
Step H5 immediately follows H2) at the added computational cost of immediately follows H2) at the added computational cost of some
some additional buffer passing to/from the G.711.0 frame decoder additional buffer passing to/from the G.711.0 frame decoder
functions. That is the G.711.0 decoder in the reference code functions. That is the G.711.0 decoder in the reference code
"silently ignores" 0x00 padding octets at the beginning of what it "silently ignores" 0x00 padding octets at the beginning of what it
believes to be a G.711.0 encoded frame boundary. Thus Step H3 and believes to be a G.711.0 encoded frame boundary. Thus Step H3 and
Step H4 above are an optimization over the reference code shown for Step H4 above are an optimization over the reference code shown for
clarity. clarity.
If the decoder is at a playout endpoint location, this G.711 buffer If the decoder is at a playout endpoint location, this G.711 buffer
SHOULD be used in the same manner as a received G.711 RTP payload SHOULD be used in the same manner as a received G.711 RTP payload
would have been used (passed to a playout buffer, to a PLC would have been used (passed to a playout buffer, to a PLC
implementation, etc.). implementation, etc.).
skipping to change at page 16, line 17 skipping to change at page 16, line 17
|----------|---------|----------|---------|---------| |----------|---------|----------|---------|---------|
| First | Second | | Nth | Zero | | First | Second | | Nth | Zero |
| G.711.0 | G.711.0 | ... | G.711.0 | or more | | G.711.0 | G.711.0 | ... | G.711.0 | or more |
| Channel | Channel | | Channel | 0x00 | | Channel | Channel | | Channel | 0x00 |
| Super- | Super- | | Super | Padding | | Super- | Super- | | Super | Padding |
| Frame | Frame | | Frame | Octets | | Frame | Frame | | Frame | Octets |
|__________|_________|__________|_________|_________| |__________|_________|__________|_________|_________|
Figure 4 Figure 4
We note that although the individual superframes can be of different
lengths in octets (and usually are), that the number of G.711 source
symbols represented - in compressed form - in each channel superframe
is identical (since all the channels represent the identically same
time interval).
The G.711.0 decoder at the receiving end simply decodes the entire The G.711.0 decoder at the receiving end simply decodes the entire
G.711.0 (multiple channel) payload into individual G.711 symbols. If G.711.0 (multiple channel) payload into individual G.711 symbols. If
M such G.711 symbols result and there were N channels, then the first M such G.711 symbols result and there were N channels, then the first
M/N G.711 samples would be from the first channel, the second M/N M/N G.711 samples would be from the first channel, the second M/N
G.711 samples would be from the second channel, and so on until the G.711 samples would be from the second channel, and so on until the
Nth set of G.711 samples are found. Similarly, if the number of Nth set of G.711 samples are found. Similarly, if the number of
channels was not known, but the payload "ptime" was known, one could channels was not known, but the payload "ptime" was known, one could
infer (knowing the sampling rate) how many G.711 symbols each channel infer (knowing the sampling rate) how many G.711 symbols each channel
contained; then with this knowledge determine how many channels of contained; then with this knowledge determine how many channels of
data were contained in the payload. When SDP is used, the number of data were contained in the payload. When SDP is used, the number of
channels is known because the optional parameter is a MUST when there channels is known because the optional parameter is a MUST when there
is more than one channel negotiated (see Section 5.1). Additionally, is more than one channel negotiated (see Section 5.1). Additionally,
when SDP is used the parameter ptime is a RECOMMENDED optional when SDP is used the parameter ptime is a RECOMMENDED optional
parameter. We note that if both parameters channels and ptime are parameter. We note that if both parameters channels and ptime are
known that one could provide a check for the other and the converse. known that one could provide a check for the other and the converse.
Whichever algorithm is used to determine the number of channels, if
the length of the source G.711 symbols in the payload (M) is not an
integer multiple of the number of channels (N), then the packet
SHOULD be discarded.
Lastly we note that although any padding for the multiple channel Lastly we note that although any padding for the multiple channel
G.711.0 payload is RECOMMENDED to be placed at the end of the G.711.0 payload is RECOMMENDED to be placed at the end of the
payload, the G.711.0 decoding heuristic described in Section 4.2.3 payload, the G.711.0 decoding algorithm described in Section 4.2.3
will successfully decode the payload in Figure 4 if the 0x00 padding will successfully decode the payload in Figure 4 if the 0x00 padding
octet is placed anywhere before or after any individual G.711.0 frame octet is placed anywhere before or after any individual G.711.0 frame
in the RTP payload. The number of padding octets introduced at any in the RTP payload. The number of padding octets introduced at any
G.711.0 frame boundary therefore does not affect the number M of the G.711.0 frame boundary therefore does not affect the number M of the
source G.711 symbols produced. Thus the decision for padding MAY be source G.711 symbols produced. Thus the decision for padding MAY be
made on a per-superframe basis. made on a per-superframe basis.
5. Payload Format Parameters 5. Payload Format Parameters
This section defines the parameters that may be used to configure This section defines the parameters that may be used to configure
skipping to change at page 17, line 11 skipping to change at page 17, line 21
The parameters defined here as a part of the media subtype The parameters defined here as a part of the media subtype
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: G711-0
Required parameters: Required parameters:
rate: The RTP timestamp clock rate, which is equal to the sampling clock rate: The RTP timestamp clock rate, which is equal to the
rate. The typical rate used with G.711 encoding is 8000, but sampling rate. The typical rate used with G.711 encoding is 8000,
other rates may be specified. The default rate is 8000. but other rates may be specified. The default rate is 8000.
complaw: Indicates the companding law (A-law or mu-law) employed. complaw: This format specific parameter, specified on the "a=fmtp:
The case-insensitive values are "al" or "mu" for A-law and mu-law, line", indicates the companding law (A-law or mu-law) employed.
respectively. This format specific parameter, as per RFC 4566 [RFC4566], is
given unchanged to the media tool using this format. The case-
insensitive values are "complaw=al" or "complaw=mu" are used for
A-law and mu-law, 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) and 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, ... ). Similar to the usual interpretation in RFC 3551
[RFC3551], the number of channels SHALL be a non-zero positive
integer.
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
"ptime" is RECOMMENDED and SHOULD be in the SDP unless there is an "ptime" is RECOMMENDED and SHOULD be in the SDP unless there is an
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
skipping to change at page 18, line 20 skipping to change at page 18, line 35
Published specification: Published specification:
ITU-T Rec. G.711.0 and RFC XXXX. ITU-T Rec. G.711.0 and RFC XXXX.
[ RFC Editor: please replace XXXXX 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:
Although initially conceived for VoIP, the use of G.711.0, like 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 G.711 before it, may find use within audio and video streaming
/or conferencing applications for the audio portion of those and/or conferencing applications for the audio portion of those
applications. applications.
Additional information: Additional information:
The following applies to stored-file transfer methods: The following applies to stored-file transfer methods:
Magic numbers: #!G7110A\n or #!G7110M\n (for A-law or MU-law Magic numbers: #!G7110A\n or #!G7110M\n (for A-law or MU-law
encodings respectively, see Section 6). encodings respectively, see Section 6).
File Extensions: None File Extensions: None
Macintosh file type code: None Macintosh file type code: None
Object identifier or OIL: None Object identifier or OIL: None
Person & email address to contact for further information: Person & email address to contact for further information:
Michael A. 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 A. Ramalho Author: Michael A. Ramalho
Change controller: Change controller:
IETF Payload 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.
o The media subtype ("G7110") goes in SDP "a=rtpmap" as the encoding o The media subtype ("G711-0") goes in SDP "a=rtpmap" as the
name. encoding name.
o The required parameter "rate" also goes in "a=rtpmap" as the clock o The required parameter "rate" also goes in "a=rtpmap" as the clock
rate. rate.
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
"a=maxptime" attributes, respectively. "a=maxptime" attributes, respectively.
o Remaining parameters go in the SDP "a=fmtp" attribute by copying o Remaining parameters go in the SDP "a=fmtp" attribute by copying
them directly from the media type string as a semicolon-separated them directly from the media type string as a semicolon-separated
list of parameter=value pairs. list of parameter=value pairs.
skipping to change at page 20, line 12 skipping to change at page 20, line 26
parameter that the answering endpoint cannot support, the answer parameter that the answering endpoint cannot support, the answer
MUST contain the optional maxptime parameter. MUST contain the optional maxptime parameter.
5.4. SDP Examples 5.4. SDP Examples
The following examples illustrate how to signal G.711.0 via SDP. The following examples illustrate how to signal G.711.0 via SDP.
5.4.1. SDP Example 1 5.4.1. SDP Example 1
m=audio RTP/AVP 98 m=audio RTP/AVP 98
a=rtpmap: 98 G7110/8000 a=rtpmap:98 G711-0/8000
a=fmtp:98 complaw = mu a=fmtp:98 complaw=mu
In the above example the dynamic payload type 98 is mapped to G.711.0 In the above example the dynamic payload type 98 is mapped to G.711.0
via the "a=rtpmap" parameter. The mandatory "complaw" is on the via the "a=rtpmap" parameter. The mandatory "complaw" is on the
"a=fmtp" parameter line. Note that neither optional parameters "a=fmtp" parameter line. Note that neither optional parameters
"ptime" nor "channels" is present; although it is generally good form "ptime" nor "channels" is present; although it is generally good form
to include "ptime" in the SDP for session diagnostic purposes. to include "ptime" in the SDP for session diagnostic purposes.
5.4.2. SDP Example 2 5.4.2. SDP Example 2
The following example illustrates an offering endpoint requesting 2 The following example illustrates an offering endpoint requesting 2
channels, but the answering endpoint can only support (or render) one channels, but the answering endpoint can only support (or render) one
channel. channel.
Offer: Offer:
m=audio RTP/AVP 98 m=audio RTP/AVP 98
a=rtpmap: 98 G7110/8000/2 a=rtpmap:98 G711-0/8000/2
a=ptime: 20 a=ptime:20
a=fmtp:98 complaw = al a=fmtp:98 complaw=al
Answer: Answer:
m=audio RTP/AVP 98 m=audio RTP/AVP 98
a=rtpmap: 98 G7110/8000/1 a=rtpmap: 98 G711-0/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 constant 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
skipping to change at page 21, line 51 skipping to change at page 22, line 12
a G.711.0 encoder, the resulting frames may be stored in G.711.0 a G.711.0 encoder, the resulting frames may be stored in G.711.0
frame format. As a result, there is nothing to specify here - the frame format. As a result, there is nothing to specify here - the
G.711.0 PLC Frames are stored as if they were received by the G.711.0 PLC Frames are stored as if they were received by the
receiving endpoint. In other words, PLC-generated G.711.0 frames receiving endpoint. In other words, PLC-generated G.711.0 frames
appear as "normal" or "ordinary" G.711.0 frames in the storage mode appear as "normal" or "ordinary" G.711.0 frames in the storage mode
file. file.
6.2. G.711.0 Erasure Frame 6.2. G.711.0 Erasure Frame
"Erasure Frames", or equivalently "Null Frames", have been designed "Erasure Frames", or equivalently "Null Frames", have been designed
for many frame-based codecs since G.711 was standardized. These null for many frame-based codecs since G.711 was standardized. These
/erasure frames explicitly represent data from incoming audio that null/erasure frames explicitly represent data from incoming audio
were either not received by the receiving system or represent data that were either not received by the receiving system or represent
that a transmitting system decided not to send. Transmitting systems data that a transmitting system decided not to send. Transmitting
may choose not to send data for a variety of reasons (e.g., not systems may choose not to send data for a variety of reasons (e.g.,
enough wireless link capacity in radio-based systems) and can choose not enough wireless link capacity in radio-based systems) and can
to send a "null frame" in lieu of the actual audio. It is also choose to send a "null frame" in lieu of the actual audio. It is
envisioned that erasure frames would be used in storage mode also envisioned that erasure frames would be used in storage mode
applications for specific archival purposes where there is a applications for specific archival purposes where there is a
requirement not to fabricate audio data that was not actually requirement not to fabricate audio data that was not actually
received. received.
Thus, a G.711.0 erasure frame is a representation of the amount of Thus, a G.711.0 erasure frame is a representation of the amount of
time in G.711.0 frames that were not received or not encoded by the time in G.711.0 frames that were not received or not encoded by the
transmitting system. transmitting system.
Prior to defining a G.711.0 erasure frame it is beneficial to note Prior to defining a G.711.0 erasure frame it is beneficial to note
what many G.711 RTP systems send when the endpoint is "muted". When what many G.711 RTP systems send when the endpoint is "muted". When
skipping to change at page 23, line 12 skipping to change at page 23, line 21
format for the G.711.0 storage mode file defined by this RFC is shown format for the G.711.0 storage mode file defined by this RFC is shown
below. below.
G.711.0 Storage Mode Format G.711.0 Storage Mode Format
|---------------------------|----------|--------------| |---------------------------|----------|--------------|
| Magic Number | | | | Magic Number | | |
| | Version | Concatenated | | | Version | Concatenated |
| "#!G7110A\n" (for A-law) | Octet | G.711.0 | | "#!G7110A\n" (for A-law) | Octet | G.711.0 |
| or | | Frames | | or | | Frames |
| "#!G7110M\n" (for Mu-law) | "0x00" | | | "#!G7110M\n" (for mu-law) | "0x00" | |
|___________________________|__________|______________| |___________________________|__________|______________|
Figure 5 Figure 5
The storage mode file consists of a magic number and a version octet The storage mode file consists of a magic number and a version octet
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
skipping to change at page 23, line 36 skipping to change at page 23, line 45
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 desirable 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.
The G.711.0 codec data frames, including any necessary erasure or PLC The G.711.0 codec data frames, including any necessary erasure or PLC
frames, are stored in consecutive order concatenated together as frames, are stored in consecutive order concatenated together as
shown in Section 4.2.2. shown in Section 4.2.2. As the Version 0 storage mode only supports
a single channel, the RTP payload format supporting multiple channels
defined in Section 4.2.4 is not supported in this storage mode
definition.
To decode the individual G.711.0 frames, the heuristic presented in To decode the individual G.711.0 frames, the algorithm presented in
Section 4.2.2 may be used to decode the individual G.711.0 frames. Section 4.2.2 may be used to decode the individual G.711.0 frames.
If the version octet is determined not to be zero, the remainder of If the version octet is determined not to be zero, the remainder of
the payload MUST NOT be passed to the G.711.0 decoder, as the ITU-T the payload MUST NOT be passed to the G.711.0 decoder, as the ITU-T
G.711.0 reference decoder can only decode concatenated G.711.0 frames G.711.0 reference decoder can only decode concatenated G.711.0 frames
and has not been designed to decode elements in yet to be specified and has not been designed to decode elements in yet to be specified
future storage mode formats. future storage mode formats.
7. Acknowledgements 7. Acknowledgements
There have been many people contributing to G.711.0 in the course of There have been many people contributing to G.711.0 in the course of
its development. The people listed here deserve special mention: its development. The people listed here deserve special mention:
Takehiro Moriya, Claude Lamblin, Herve Taddei, Simao Campos, Yusuke Takehiro Moriya, Claude Lamblin, Herve Taddei, Simao Campos, Yusuke
Hiwasaki, Jacek Stachurski, Lorin Netsch, Paul Coverdale, Patrick Hiwasaki, Jacek Stachurski, Lorin Netsch, Paul Coverdale, Patrick
Luthi, Paul Barrett, Jari Hagqvist, Pengjun (Jeff) Huang, John Gibbs, Luthi, Paul Barrett, Jari Hagqvist, Pengjun (Jeff) Huang, John Gibbs,
Yutaka Kamamoto, and Csaba Kos. Yutaka Kamamoto, and Csaba Kos. The review and oversight by the IETF
Payload Working Group chairs Ali Begen and Roni Even during the
development of this RFC is appreciated. Additionally, the careful
review and comments by Richard Barnes is likewise very much
appreciated.
8. Contributors 8. Contributors
The authors thank everyone who have contributed to this document. The authors thank everyone who have contributed to this document.
The people listed here deserve special mention: Ali Begen, Roni Even, The people listed here deserve special mention: Ali Begen, Roni Even,
and Hadriel Kaplan. and Hadriel Kaplan.
9. IANA Considerations 9. IANA Considerations
One media type (audio/G7110) has been defined and requires IANA One media type (audio/G711-0) has been defined and requires IANA
registration in the media types registry. See Section 5.1 for registration in the media types registry. See Section 5.1 for
details. details.
10. Security Considerations 10. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550], and in any appropriate RTP profile (for specification [RFC3550], and in any appropriate RTP profile (for
example RFC 3551 [RFC3551] or [RFC4585]. This implies that example RFC 3551 [RFC3551] or [RFC4585]). This implies that
confidentiality of the media streams is achieved by encryption; for confidentiality of the media streams is achieved by encryption; for
example, through the application of SRTP [RFC3711]. Because the data example, through the application of SRTP [RFC3711]. Because the data
compression used with this payload format is applied end-to-end, any compression used with this payload format is applied end-to-end, any
encryption needs to be performed after compression. encryption needs to be performed after compression.
Note that the appropriate mechanism to ensure confidentiality and Note that the appropriate mechanism to ensure confidentiality and
integrity of RTP packets and their payloads is very dependent on the integrity of RTP packets and their payloads is very dependent on the
application and on the transport and signaling protocols employed. application and on the transport and signaling protocols employed.
Thus, although SRTP is given as an example above, other possible Thus, although SRTP is given as an example above, other possible
choices exist. choices exist.
skipping to change at page 25, line 7 skipping to change at page 25, line 24
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). Therefore a G.711.0 payload does not carry "active are possible). We also note that the data read by the G.711.0
content" that could impose malicious side-effects upon the receiver. decoder is controlled by the length of the individual encoded G.711.0
frame(s) contained in the RTP payload. The decoding algorithm
specified in Section 4.2.3 above ensures that the G.711.0 decoder
will not read beyond the length of the internal buffer specified
(which is in turn specified to be no greater than the largest
possible G.711.0 frame of 321 octets). 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
skipping to change at page 27, line 42 skipping to change at page 28, line 15
[IEEE] C.V. Wright, , L. Ballard, , S.E. Coull, , F. Monrose, , [IEEE] C.V. Wright, , L. Ballard, , S.E. Coull, , F. Monrose, ,
and G.M. Masson, "Spot Me if You Can: Uncovering Spoken and G.M. Masson, "Spot Me if You Can: Uncovering Spoken
Phrases in Encrypted VoIP Conversations, IEEE Symposium on Phrases in Encrypted VoIP Conversations, IEEE Symposium on
Security and Privacy, 2008, ISBN: 978-0-7695-3168-7", May Security and Privacy, 2008, ISBN: 978-0-7695-3168-7", May
2008. 2008.
Authors' Addresses Authors' Addresses
Michael A. Ramalho (editor) Michael A. Ramalho (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
8000 Hawkins Road 6310 Watercrest Way Unit 203
Sarasota, FL 34241 Lakewood Ranch, FL 34202
USA USA
Phone: +1 919 476 2038 Phone: +1 919 476 2038
Email: mramalho@cisco.com Email: mramalho@cisco.com
Paul E. Jones Paul E. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Phone: +1 919 476 2048 Phone: +1 919 476 2048
Email: paulej@packetizer.com Email: paulej@packetizer.com
Noboru Harada Noboru Harada
skipping to change at page 28, line 23 skipping to change at page 28, line 41
Noboru Harada Noboru Harada
NTT Communications Science Labs. NTT Communications Science Labs.
3-1 Morinosato-Wakamiya 3-1 Morinosato-Wakamiya
Atsugi, Kanagawa 243-0198 Atsugi, Kanagawa 243-0198
JAPAN JAPAN
Phone: +81 46 240 3676 Phone: +81 46 240 3676
Email: harada.noboru@lab.ntt.co.jp Email: harada.noboru@lab.ntt.co.jp
Muthu Arul Mozhi Perumal Muthu Arul Mozhi Perumal
Cisco Systems, Inc. Ericsson
Cessna Business Park Ferns Icon
Sarjapur-Marathahalli Outer Ring Road Doddanekundi, Mahadevapura
Bangalore, Karnataka 560103 Bangalore, Karnataka 560037
India India
Phone: +91 9449288768 Phone: +91 9449288768
Email: mperumal@cisco.com Email: muthu.arul@gmail.com
Lei Miao Lei Miao
Huawei Technologies Co. Ltd Huawei Technologies Co. Ltd
Q22-2-A15R, Enviroment Protection Park Q22-2-A15R, Enviroment Protection Park
No. 156 Beiqing Road No. 156 Beiqing Road
HaiDian District HaiDian District
Beijing 100095 Beijing 100095
China China
Phone: +86 1059728300 Phone: +86 1059728300
Email: lei.miao@huawei.com Email: lei.miao@huawei.com
 End of changes. 56 change blocks. 
86 lines changed or deleted 119 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/