draft-ietf-payload-g7110-04.txt   draft-ietf-payload-g7110-05.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 26, 2015 N. Harada Expires: September 26, 2015 N. Harada
NTT NTT
M. Perumal M. Perumal
Ericsson Ericsson
L. Miao L. Miao
Huawei Technologies Huawei Technologies
December 23, 2014 March 25, 2015
RTP Payload Format for G.711.0 RTP Payload Format for G.711.0
draft-ietf-payload-g7110-04 draft-ietf-payload-g7110-05
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 26, 2015. This Internet-Draft will expire on September 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . 7
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 . . . . 11 4.2.1. Single G.711.0 Frame per RTP Payload Example . . . . 11
4.2.2. G.711.0 RTP Payload Definition . . . . . . . . . . . 11 4.2.2. G.711.0 RTP Payload Definition . . . . . . . . . . . 12
4.2.2.1. G.711.0 RTP Payload Encoding Process . . . . . . 13 4.2.2.1. G.711.0 RTP Payload Encoding Process . . . . . . 13
4.2.3. G.711.0 RTP Payload Decoding Process . . . . . . . . 13 4.2.3. G.711.0 RTP Payload Decoding Process . . . . . . . . 14
4.2.4. G.711.0 RTP Payload for Multiple Channels . . . . . . 16 4.2.4. G.711.0 RTP Payload for Multiple Channels . . . . . . 16
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 18 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 18
5.1. Media Type Registration . . . . . . . . . . . . . . . . . 18 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 18
5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 20 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 20
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 21 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 21
5.4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 21 5.4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 21
5.4.1. SDP Example 1 . . . . . . . . . . . . . . . . . . . . 21 5.4.1. SDP Example 1 . . . . . . . . . . . . . . . . . . . . 21
5.4.2. SDP Example 2 . . . . . . . . . . . . . . . . . . . . 21 5.4.2. SDP Example 2 . . . . . . . . . . . . . . . . . . . . 22
6. G.711.0 Storage Mode Conventions and Definition . . . . . . . 22 6. G.711.0 Storage Mode Conventions and Definition . . . . . . . 22
6.1. G.711.0 PLC Frame . . . . . . . . . . . . . . . . . . . . 22 6.1. G.711.0 PLC Frame . . . . . . . . . . . . . . . . . . . . 22
6.2. G.711.0 Erasure Frame . . . . . . . . . . . . . . . . . . 23 6.2. G.711.0 Erasure Frame . . . . . . . . . . . . . . . . . . 23
6.3. G.711.0 Storage Mode Definition . . . . . . . . . . . . . 24 6.3. G.711.0 Storage Mode Definition . . . . . . . . . . . . . 24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. Congestion Control . . . . . . . . . . . . . . . . . . . . . 27 11. Congestion Control . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 5, line 42 skipping to change at page 5, line 42
to this stateless property, the frames input to the G.711.0 to this stateless property, the frames input to the G.711.0
encoder may be changed "on-the-fly" (a 5 ms encoding could be encoder may be changed "on-the-fly" (a 5 ms encoding could be
followed by a 20 ms encoding). followed by a 20 ms encoding).
A4 Self-describing: This property is defined as the ability to A4 Self-describing: This property is defined as the ability to
determine how many source G.711 samples are contained within determine how many source G.711 samples are contained within
the G.711.0 frame solely by information contained within the the G.711.0 frame solely by information contained within the
G.711.0 frame. Generally, the number of source G.711 symbols G.711.0 frame. Generally, the number of source G.711 symbols
can be determined by decoding the initial octets of the can be determined by decoding the initial octets of the
compressed G.711.0 frame (these octets are called "prefix compressed G.711.0 frame (these octets are called "prefix
codes" in the standard) [ICASSP]. A G.711.0 decoder need not codes" in the standard). A G.711.0 decoder need not know how
know what ptime is, as it is able to decompress the G.711.0 many symbols are contained in the original G.711 frame (e.g.,
frame presented to it without signaling knowledge. parameter ptime in Session Description Protocol, SDP,
[RFC4566]), as it is able to decompress the G.711.0 frame
presented to it without signaling knowledge.
A5 Accommodate G.711 payload sizes typically used in IP: G.711 input A5 Accommodate G.711 payload sizes typically used in IP: G.711 input
frames of length typically found in VoIP applications represent frames of length typically found in VoIP applications represent
SDP ptimes (see RFC 4566 [RFC4566]) of 5 ms, 10 ms, 20 ms, 30 SDP ptime values of 5 ms, 10 ms, 20 ms, 30 ms or 40 ms. Since
ms or 40 ms. Since the dominant sampling frequency for G.711 the dominant sampling frequency for G.711 is 8000 samples per
is 8000 samples per second, G.711.0 was designed to compress second, G.711.0 was designed to compress G.711 input frames of
G.711 input frames of 40, 80, 160, 240 or 320 samples. 40, 80, 160, 240 or 320 samples.
A6 Bounded expansion: Since attribute A2 above requires G.711.0 to A6 Bounded expansion: Since attribute A2 above requires G.711.0 to
be lossless for any payload (which could consist of any be lossless for any payload (which could consist of any
combination of octets with each octet spanning the entire space combination of octets with each octet spanning the entire space
of 2^8 values), by definition there exists at least one of 2^8 values), by definition there exists at least one
potential G.711 payload which must be "uncompressible". Since potential G.711 payload which must be "uncompressible". Since
the quantum of compression is an octet, the minimum expansion the quantum of compression is an octet, the minimum expansion
of such an uncompressible payload was designed to be the of such an uncompressible payload was designed to be the
minimum possible of one octet. Thus G.711.0 "compressed" minimum possible of one octet. Thus G.711.0 "compressed"
frames can be of length one octet to X+1 octets, where X is the frames can be of length one octet to X+1 octets, where X is the
skipping to change at page 7, line 36 skipping to change at page 7, line 42
G.711.0 output frame, consistent with attribute A4. Depending on the G.711.0 output frame, consistent with attribute A4. Depending on the
source G.711 symbols, the G.711.0 output frame can contain anywhere source 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. from 1 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 first octet of a G.711.0 frame is called the (A-law or mu-law). The first octet of a G.711.0 frame is called the
"Prefix Code" octet; the value of this octet conveys how many G.711 "Prefix Code" octet; the information within this octet conveys how
symbols the decoder is to create from a given G.711.0 input frame. many G.711 symbols the decoder is to create from a given G.711.0
The Prefix Code value of 0x00 is used to denote zero G.711 source input frame (i.e., 0, 40, 80, 160, 240 or 320). The Prefix Code
symbols, which allows the use of 0x00 as a payload padding octet (to value of 0x00 is used to denote zero G.711 source symbols, which
be described later). allows the use of 0x00 as a payload padding octet (to be described
later in Section 3.3.1).
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
signal coded by G.711, an intelligent G.711.0 encoder could infer the signal coded by G.711, an intelligent G.711.0 encoder could infer the
G.711 companding law in use (via G.711 input signal amplitude G.711 companding law in use (via G.711 input signal amplitude
skipping to change at page 13, line 7 skipping to change at page 13, line 14
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 Section 4.2.3 is used to payload decoding process described in Section 4.2.3 is used to
determine where the individual G.711.0 frame boundaries are. Any 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 specified in Section 4.2.3. process specified in Section 4.2.3.
4.2.2.1. G.711.0 RTP Payload Encoding Process 4.2.2.1. G.711.0 RTP Payload Encoding Process
The ITU-T G.711.0 supports five possible input frame lengths: 40, 80, ITU-T G.711.0 supports five possible input frame lengths: 40, 80,
160, 240, and 320 samples per frame and the rationale for choosing 160, 240, and 320 samples per frame and the rationale for choosing
those lengths was given in the description of property A5 in those lengths was given in the description of property A5 in
Section 3.2. Assuming 8000 sample per second, these lengths Section 3.2. Assuming 8000 sample per second, these lengths
correspond to input frames representing 5 ms, 10 ms, 20 ms, 30 ms or correspond to input frames representing 5 ms, 10 ms, 20 ms, 30 ms or
40 ms. So while the standard assumed the input "bit stream" 40 ms. So while the standard assumed the input "bit stream"
consisted of G.711 symbols of some integer multiple of 5 ms in consisted of G.711 symbols of some integer multiple of 5 ms in
length, it did not specify exactly what frame lengths to use as input length, it did not specify exactly what frame lengths to use as input
to the G.711.0 encoder itself. The intent of this section is to to the G.711.0 encoder itself. The intent of this section is to
provide some guidance for the selection. provide some guidance for the selection.
skipping to change at page 13, line 29 skipping to change at page 13, line 36
samples represented in a G.711.0 payload and signaled by using the samples represented in a G.711.0 payload and signaled by using the
SDP parameter ptime. As described in Section 3.3.1, the simplest way SDP parameter ptime. As described in Section 3.3.1, the simplest way
to encode these 160 octets is to pass the entire 160 octet to the to encode these 160 octets is to pass the entire 160 octet to the
G.711.0 encoder, resulting in precisely one G.711.0 compressed frame, G.711.0 encoder, resulting in precisely one G.711.0 compressed frame,
and put that singular frame into the G.711.0 RTP payload. However, and put that singular frame into the G.711.0 RTP payload. However,
neither the ITU-T G.711.0 standard nor this IETF payload format neither the ITU-T G.711.0 standard nor this IETF payload format
mandates this. In fact 20 ms of input G.711 symbols can be encoded mandates this. In fact 20 ms of input G.711 symbols can be encoded
as 1, 2, 3 or 4 G.711.0 frames in any one of six combinations (i.e., as 1, 2, 3 or 4 G.711.0 frames in any one of six combinations (i.e.,
{20ms}, {10ms:10ms}, {10ms:5ms:5ms}, {5ms:10ms:5ms}, {5ms:5ms:10ms}, {20ms}, {10ms:10ms}, {10ms:5ms:5ms}, {5ms:10ms:5ms}, {5ms:5ms:10ms},
{5ms:5ms:5ms:5ms}) and any of these combinations would decompress {5ms:5ms:5ms:5ms}) and any of these combinations would decompress
into the same source 160 G.711 octets. into the same source 160 G.711 octets. As an aside, we note that the
first octet of any G.711.0 frame will be the prefix code octet and
information in this octet determines how many G.711 symbols are
represented in the G.711.0 frame.
Notwithstanding the above, we expect one of two encodings to be used Notwithstanding the above, we expect one of two encodings to be used
by implementers: the simplest possible (one 160 byte input to the by implementers: the simplest possible (one 160 byte input to the
G.711.0 encoder which usually results in the highest compression) or G.711.0 encoder which usually results in the highest compression) or
the combination of possible input frames to a G.711.0 encoder that the combination of possible input frames to a G.711.0 encoder that
resulted in the highest compression for the payload. The explicit resulted in the highest compression for the payload. The explicit
mention of this issue in this IETF document was deemed important mention of this issue in this IETF document was deemed important
because the ITU-T G.711.0 standard is silent on this issue and there because the ITU-T G.711.0 standard is silent on this issue and there
is a desire for this issue to be documented in a formal Standards is a desire for this issue to be documented in a formal Standards
Development Organization (SDO) document (i.e., here). Developing Organization (SDO) document (i.e., here).
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 algorithm 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
 End of changes. 17 change blocks. 
29 lines changed or deleted 35 lines changed or added

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