draft-ietf-payload-g7110-05.txt   draft-ietf-payload-g7110-06.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 26, 2015 N. Harada Expires: November 12, 2015 N. Harada
NTT NTT
M. Perumal M. Perumal
Ericsson Ericsson
L. Miao L. Miao
Huawei Technologies Huawei Technologies
March 25, 2015 May 11, 2015
RTP Payload Format for G.711.0 RTP Payload Format for G.711.0
draft-ietf-payload-g7110-05 draft-ietf-payload-g7110-06
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 26, 2015. This Internet-Draft will expire on November 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . 12 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 . . . . . . . . 14 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 . . . . . . . . . . . . . . . . 21
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 21 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 21
5.4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 21 5.4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . 22
5.4.1. SDP Example 1 . . . . . . . . . . . . . . . . . . . . 21 5.4.1. SDP Example 1 . . . . . . . . . . . . . . . . . . . . 22
5.4.2. SDP Example 2 . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . 23
6.1. G.711.0 PLC Frame . . . . . . . . . . . . . . . . . . . . 22 6.1. G.711.0 PLC Frame . . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . . . . . . . 26
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. Congestion Control . . . . . . . . . . . . . . . . . . . . . 27 11. Congestion Control . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 27 skipping to change at page 4, line 27
packet simply by compressing the G.711 payload (thus creating a packet simply by compressing the G.711 payload (thus creating a
G.711.0 payload), changing the payload type to the dynamic value G.711.0 payload), changing the payload type to the dynamic value
desired and copying all the remaining G.711 RTP header fields into desired and copying all the remaining G.711 RTP header fields into
the corresponding G.711.0 RTP header. In a similar manner, the the corresponding G.711.0 RTP header. In a similar manner, the
corresponding decompression of the G.711.0 RTP packet thus created corresponding decompression of the G.711.0 RTP packet thus created
back to the original source G.711 RTP packet can be accomplished by back to the original source G.711 RTP packet can be accomplished by
losslessly decompressing the G.711.0 payload back to the original losslessly decompressing the G.711.0 payload back to the original
source G.711 payload, changing the payload type back to the payload source G.711 payload, changing the payload type back to the payload
type of the original G.711 RTP packet and copying all the remaining type of the original G.711 RTP packet and copying all the remaining
G.711.0 RTP header fields into the corresponding G.711 RTP header. G.711.0 RTP header fields into the corresponding G.711 RTP header.
Negotiation specifics for this lossless G.711 payload compression for As a packet produced by the compression and decompression as
RTP use case is not in scope for this document. described above is indistinguishable in every detail to the source
G.711 packet, such compression can be made invisible to the end
systems. Specification of how systems on the path between the end
systems discover each other and negotiate the use of G.711.0
compression as described in this paragraph is outside the scope of
this document.
It is special to note that G.711.0, being both lossless and It is special to note that G.711.0, being both lossless and
stateless, can be employed multiple times (e.g., on multiple, stateless, can be employed multiple times (e.g., on multiple,
individual hops or series of hops) of a given flow with no individual hops or series of hops) of a given flow with no
degradation of quality relative to end-to-end G.711. Stated another degradation of quality relative to end-to-end G.711. Stated another
way, multiple "lossless transcodes" from/to G.711.0/G.711 do not way, multiple "lossless transcodes" from/to G.711.0/G.711 do not
affect voice quality as typically occurs with lossy transcodes to/ affect voice quality as typically occurs with lossy transcodes to/
from dissimilar codecs. from dissimilar codecs.
Lastly, it is expected that G.711.0 will be used as an archival Lastly, it is expected that G.711.0 will be used as an archival
skipping to change at page 10, line 26 skipping to change at page 10, line 26
X - As per [RFC3550] X - As per [RFC3550]
CC - As per [RFC3550] CC - As per [RFC3550]
M - As per [RFC3550] and [RFC3551] 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 (see [RFC3550], [RFC4585]).
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
skipping to change at page 16, line 15 skipping to change at page 16, line 15
"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.).
We explicitly note that a framing error condition will result
whenever the buffer sent to a G.711.0 decoder does not begin with a
valid first G.711.0 frame octet (i.e., a valid G.711.0 prefix code or
a 0x00 padding octet). The expected result is that the decoder will
not produce the desired/correct G.711 source symbols. However, as
already noted, the output returned by the G.711.0 decoder will be
bounded (to less than 321 octets per G.711.0 decode request) and if
the number of the (presumed) G.711 symbols produced is known to be in
error, the decoded output MUST be discarded.
4.2.4. G.711.0 RTP Payload for Multiple Channels 4.2.4. G.711.0 RTP Payload for Multiple Channels
In this section we describe the use of multiple "channels" of G.711 In this section we describe the use of multiple "channels" of G.711
data encoded by G.711.0 compression. data encoded by G.711.0 compression.
The dominant use of G.711 in RTP transport has been for single The dominant use of G.711 in RTP transport has been for single
channel use cases. For this case, the above G.711.0 encoding and channel use cases. For this case, the above G.711.0 encoding and
decoding process is used. However, the multiple channel case for decoding process is used. However, the multiple channel case for
G.711.0 (a frame-based compression) is different from G.711 (a G.711.0 (a frame-based compression) is different from G.711 (a
sample-based encoding) and is described separately here. sample-based encoding) and is described separately here.
 End of changes. 13 change blocks. 
15 lines changed or deleted 30 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/