draft-ietf-avt-rtp-g718-04.txt   draft-ietf-avt-rtp-g718-05.txt 
Network Working Group G. Zorn, Ed. Network Working Group G. Zorn, Ed.
Internet-Draft Network Zen Internet-Draft Network Zen
Intended status: Standards Track Y. Wang Intended status: Standards Track Y. Wang
Expires: June 11, 2011 Huawei Technologies Expires: June 13, 2011 Huawei Technologies
A. Lakaniemi A. Lakaniemi
Nokia Nokia
December 8, 2010 December 10, 2010
RTP Payload Format for G.718 Speech/audio RTP Payload Format for G.718 Speech/Audio
draft-ietf-avt-rtp-g718-04.txt draft-ietf-avt-rtp-g718-05.txt
Abstract Abstract
This document specifies the Real-Time Transport Protocol (RTP) This document specifies the Real-Time Transport Protocol (RTP)
payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/ payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/
audio codec, specified in ITU-T G.718. A media type registration for audio codec, specified in ITU-T G.718. A media type registration for
this RTP payload format is also included. this RTP payload format is also included.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 11, 2011. This Internet-Draft will expire on June 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. The G.718 Codec . . . . . . . . . . . . . . . . . . . . . 3 3.1. The G.718 Codec . . . . . . . . . . . . . . . . . . . . . 4
3.2. Benefits of Layered Design . . . . . . . . . . . . . . . . 5 3.2. Benefits of Layered Design . . . . . . . . . . . . . . . . 6
3.3. Transmitting Layered Data . . . . . . . . . . . . . . . . 5 3.3. Transmitting Layered Data . . . . . . . . . . . . . . . . 6
3.4. Scaling Scenarios and Rate Control . . . . . . . . . . . . 6 3.4. Scaling Scenarios and Rate Control . . . . . . . . . . . . 7
4. G.718 RTP Payload Format . . . . . . . . . . . . . . . . . . . 7 4. G.718 RTP Payload Format . . . . . . . . . . . . . . . . . . . 7
4.1. Payload Structure . . . . . . . . . . . . . . . . . . . . 7 4.1. Payload Structure . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Payload Header . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Payload Header . . . . . . . . . . . . . . . . . . . . 8
4.1.2. G.718 Transport Blocks . . . . . . . . . . . . . . . . 7 4.1.2. G.718 Transport Blocks . . . . . . . . . . . . . . . . 8
4.2. Handling The Encoded Data . . . . . . . . . . . . . . . . 10 4.2. Handling The Encoded Data . . . . . . . . . . . . . . . . 11
4.3. G.718 Scaling . . . . . . . . . . . . . . . . . . . . . . 12 4.3. G.718 Scaling . . . . . . . . . . . . . . . . . . . . . . 13
4.4. CRC Verification . . . . . . . . . . . . . . . . . . . . . 12 4.4. CRC Verification . . . . . . . . . . . . . . . . . . . . . 13
4.5. G.718 Session . . . . . . . . . . . . . . . . . . . . . . 13 4.5. G.718 Session . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Cross-stream/Cross-layer Timing Synchronization . . . . . 13 4.6. Cross-stream/Cross-layer Timing Synchronization . . . . . 14
4.7. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 13 4.7. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 14
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 14 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 15
5.1. Media Type Registration . . . . . . . . . . . . . . . . . 14 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 15
5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 16 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 17
5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 16 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 17
5.4. Declarative Usage of SDP . . . . . . . . . . . . . . . . . 17 5.4. Declarative Usage of SDP . . . . . . . . . . . . . . . . . 18
5.5. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . 18
5.5.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17 5.5.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 18
5.5.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 17 5.5.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 18
5.5.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 18 5.5.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 19
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 19 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Payload Examples . . . . . . . . . . . . . . . . . . 22 Appendix A. Payload Examples . . . . . . . . . . . . . . . . . . 23
A.1. Simple Payload Examples . . . . . . . . . . . . . . . . . 22 A.1. Simple Payload Examples . . . . . . . . . . . . . . . . . 23
A.1.1. All The Layers in The Same Payload . . . . . . . . . . 22 A.1.1. All The Layers in The Same Payload . . . . . . . . . . 23
A.1.2. Layers in Seperate RTP Streams . . . . . . . . . . . . 23 A.1.2. Layers in Seperate RTP Streams . . . . . . . . . . . . 24
A.2. Advanced Examples . . . . . . . . . . . . . . . . . . . . 24 A.2. Advanced Examples . . . . . . . . . . . . . . . . . . . . 25
A.2.1. Different Update Rate for Subset of Layers . . . . . . 24 A.2.1. Different Update Rate for Subset of Layers . . . . . . 25
A.2.2. Redundant Frames With Limited Set of Layers . . . . . 25 A.2.2. Redundant Frames With Limited Set of Layers . . . . . 26
1. Introduction 1. Introduction
The International Telecommunication Union (ITU-T) Recommendation The International Telecommunication Union (ITU-T) Recommendation
G.718 [ITU.G718.2008] specifies the Embedded Variable Bit Rate (EV- G.718 [ITU.G718.2008] specifies the Embedded Variable Bit Rate (EV-
VBR) speech/audio codec. This document specifies the Real-time VBR) speech/audio codec. This document specifies the Real-time
Transport Protocol (RTP) [RFC3550] payload format for this codec. Transport Protocol (RTP) [RFC3550] payload format for this codec.
2. Requirements Language 2. Requirements Language
skipping to change at page 4, line 18 skipping to change at page 5, line 18
---------------------------------------------------------------- ----------------------------------------------------------------
L1' 32 12.8 kbit/s 16 kHz WB L1' 32 12.8 kbit/s 16 kHz WB
L3' 9 16.4 kbit/s 16 kHz WB L3' 9 16.4 kbit/s 16 kHz WB
L4 20 24.4 kbit/s 16 kHz WB L4 20 24.4 kbit/s 16 kHz WB
L5 20 32.4 kbit/s 16 kHz WB L5 20 32.4 kbit/s 16 kHz WB
The G.718 codec also includes an operating mode that is compatible The G.718 codec also includes an operating mode that is compatible
with the Adaptive Multi-Rate Wideband (AMR-WB) codec [AMR-WB], for with the Adaptive Multi-Rate Wideband (AMR-WB) codec [AMR-WB], for
which the RTP payload format is specified in [RFC4867]. In this AMR- which the RTP payload format is specified in [RFC4867]. In this AMR-
WB interoperable mode, layers L1 and L2 are replaced by L1' WB interoperable mode, layers L1 and L2 are replaced by L1'
consisting of AMR-WB encoded data. Furthermore, together with L1'. consisting of AMR-WB encoded data and L3' is used instead of L3. The
modified L3' is used instead of L3. The usage of layers L4 and L5 is usage of layers L4 and L5 is not affected by transmitting AMR-WB data
not affected by transmitting AMR-WB data in the lower layers. If in the lower layers. If layer L3' is present in the encoded bit-
layer L3' is present in the encoded bit-stream, the base layer L1' stream, the base layer L1' must use the AMR-WB mode 2 with a bit-rate
must use the AMR-WB mode 2 with a bit-rate of 12.65 kbits/s. of 12.65 kbits/s. Otherwise (the encoded bit-stream contains only
Otherwise (the encoded bit-stream contains only the L1' layer), any the L1' layer), any of the 9 AMR-WB coding modes 0, 1, 2, 3, 4, 5, 6,
of the 9 AMR-WB coding modes 0, 1, 2, 3, 4, 5, 6, 7, and 8 correspond 7, and 8 correspond to the bit- rates of 6.60, 8.85, 12.65, 14.25,
to the bit- rates of 6.60, 8.85, 12.65, 14.25, 15.85, 18.25, 19.85, 15.85, 18.25, 19.85, 23.05, and 23.85 kbit/s, respectively, may be in
23.05, and 23.85 kbit/s, respectively, may be in use. Table 2 use. Table 2 summarizes the AMR-WB interoperable mode when more than
summarizes the AMR-WB interoperable mode when more than one layer may one layer may be present.
be present.
Table 2: G.718 layers in the AMR-WB interoperable mode Table 2: G.718 layers in the AMR-WB interoperable mode
Layer Bytes Cumulative bit-rate Sampling rate Output Layer Bytes Cumulative bit-rate Sampling rate Output
---------------------------------------------------------------- ----------------------------------------------------------------
L1' 32 12.8 kbit/s 16 kHz WB L1' 32 12.8 kbit/s 16 kHz WB
L3' 9 16.4 kbit/s 16 kHz WB L3' 9 16.4 kbit/s 16 kHz WB
L4 20 24.4 kbit/s 16 kHz WB L4 20 24.4 kbit/s 16 kHz WB
L5 20 32.4 kbit/s 16 kHz WB L5 20 32.4 kbit/s 16 kHz WB
skipping to change at page 13, line 27 skipping to change at page 14, line 27
A G.718 session consists of one or several RTP sessions carrying A G.718 session consists of one or several RTP sessions carrying
G.718 data encoded according to the payload format specified in G.718 data encoded according to the payload format specified in
Section 4.1. Section 4.1.
4.6. Cross-stream/Cross-layer Timing Synchronization 4.6. Cross-stream/Cross-layer Timing Synchronization
In the case where a G.718 session consists of multiple RTP sessions, In the case where a G.718 session consists of multiple RTP sessions,
the RTP packets transmitted on separate RTP sessions need to be the RTP packets transmitted on separate RTP sessions need to be
synchronized in order to enable reconstruction of the frames in the synchronized in order to enable reconstruction of the frames in the
receiving end. Since each of the RTP sessions uses its own random receiving end [RFC6051]. Since each of the RTP sessions uses its own
initial value for the RTP timestamp, there is also a random offset random initial value for the RTP timestamp, there is also a random
between the RTP timestamps values carrying the EDUs belonging to the offset between the RTP timestamps values carrying the EDUs belonging
same encoded frame in different RTP sessions. to the same encoded frame in different RTP sessions.
The receiver MUST use the traditional RTCP-based mechanism to The receiver MUST use the traditional RTCP-based mechanism to
synchronize streams by using the RTP and NTP timestamps of the RTCP synchronize streams by using the RTP and NTP timestamps of the RTCP
Sender Reports (SR) it receives. Sender Reports (SR) it receives [RFC3550].
4.7. RTP Header Usage 4.7. RTP Header Usage
This section specifies the usage of some fields of the RTP header This section specifies the usage of some fields of the RTP header
(specified in Section 5 of [RFC3550]) with the G.718 RTP payload (specified in Section 5 of [RFC3550]) with the G.718 RTP payload
format. The settings for other RTP header fields are as specified in format. The settings for other RTP header fields are as specified in
[RFC3550]. [RFC3550].
The RTP timestamp corresponds to the sampling instant of the first The RTP timestamp corresponds to the sampling instant of the first
encoded sample of the earliest frame in the payload. The timestamp encoded sample of the earliest frame in the payload. The timestamp
skipping to change at page 19, line 18 skipping to change at page 20, line 18
control by providing a possibility for 'thinning' the bitstream. The control by providing a possibility for 'thinning' the bitstream. The
RTP payload format according to this specification provides several RTP payload format according to this specification provides several
different means for reducing the G.718 session bandwidth. The most different means for reducing the G.718 session bandwidth. The most
appropriate mechanism (in terms of impact to the user experience) appropriate mechanism (in terms of impact to the user experience)
depends on the employed payload structure and also on the employed depends on the employed payload structure and also on the employed
session configuration (single RTP session or multiple RTP sessions). session configuration (single RTP session or multiple RTP sessions).
The following means (in no particular order) can be used to assist The following means (in no particular order) can be used to assist
congestion control procedures -- either by the sender or by the congestion control procedures -- either by the sender or by the
intermediate node. intermediate node.
o The transport blocks carrying the EDUs representing the highest
layers within the payload may be dropped
o The payloads carrying the EDUs representing the highest layers in o The payloads carrying the EDUs representing the highest layers in
an G.718 session are dropped an G.718 session can be dropped, along with all associated
transport blocks
o The transport blocks carrying the EDUs representing the highest
layers within the payload can be dropped
o Transport blocks or payloads carrying EDUs belonging to redundant o Transport blocks or payloads carrying EDUs belonging to redundant
frames included in the payload are dropped frames included in the payload can be dropped
7. Security Considerations 7. 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 [RFC3551] or [RFC4585]. This implies that confidentiality of example [RFC3551] or [RFC4585]. This implies that confidentiality of
the media streams is achieved by encryption; for example, through the the media streams is achieved by encryption; for example, through the
application of SRTP [RFC3711]. Because the data compression used application of SRTP [RFC3711]. Because the data compression used
with this payload format is applied end-to-end, any encryption needs with this payload format is applied end-to-end, any encryption needs
skipping to change at page 22, line 17 skipping to change at page 23, line 19
L-E., and G. Fairhurst, "The Lightweight User L-E., and G. Fairhurst, "The Lightweight User
Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, Congestion Control Protocol (DCCP)", RFC 4340,
March 2006. March 2006.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies",
RFC 5117, January 2008. RFC 5117, January 2008.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation
of RTP Flows", RFC 6051, November 2010.
Appendix A. Payload Examples Appendix A. Payload Examples
The G.718 payload structure enables flexible transport either by The G.718 payload structure enables flexible transport either by
carrying all layers in the same payload or separating the layers into carrying all layers in the same payload or separating the layers into
separate payloads. The following subsections illustrate different separate payloads. The following subsections illustrate different
possibilities for transport by simple examples. Note that examples possibilities for transport by simple examples. Note that examples
do not show the full payload structure to keep the illustration do not show the full payload structure to keep the illustration
simple. simple.
A.1. Simple Payload Examples A.1. Simple Payload Examples
 End of changes. 14 change blocks. 
65 lines changed or deleted 80 lines changed or added

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