ETSI TS 103 161-3 V1.1.1 (2011-04)

Access, Terminals, Transmission and Multiplexing (ATTM); Integrated Broadband Cable and Television Networks; IPCablecom 1.5; Part 3: Audio Codec Requirements for the Provision of Bi-Directional Audio Service over Cable Television Networks using Cable Modems

DTS/ATTM-003011-3

General Information

• Status: Published
• Publication Date: 12-Apr-2011
• Technical Committee: ATTM AT3 - Integrated broadband cable and television networks
• Current Stage: 12 - Completion
• Due Date: 20-Apr-2011
• Completion Date: 13-Apr-2011

Standards Content (Sample)

Technical Specification
Access, Terminals, Transmission and Multiplexing (ATTM);
Integrated Broadband Cable and Television Networks;
IPCablecom 1.5;
Part 3: Audio Codec Requirements for the Provision of
Bi-Directional Audio Service over Cable
Television Networks using Cable Modems

2 ETSI TS 103 161-3 V1.1.1 (2011-04)

Reference
DTS/ATTM-003011-3
Keywords
access, broadband, cable, IP, multimedia, PSTN
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 161-3 V1.1.1 (2011-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 9
3 Definitions and abbreviations . 10
3.1 Definitions . 10
3.2 Abbreviations . 11
4 Void . 12
5 Background . 12
5.1 IPCablecom Voice Communications Quality Requirements . 13
5.2 Network Preparation for Codec Support . 13
5.2.1 Packet Loss Control . 13
5.2.2 Latency Control . 13
5.2.2.1 Latency Control: Buffering . 14
5.2.2.2 Latency Control: Optimal Framing/P acke tization . 14
5.2.2.3 Latency Control: Packet Timing Optimization . 14
5.2.3 Codec Transcoding Minimization . 14
5.2.4 Bandwidth Minimization . 15
6 Device Requirements for Audio codec support. 15
6.1 Dynamic Update Capability . 15
6.2 Maximum Service Outage . 15
6.3 Minimum Processing Capability . 15
6.4 Minimum Audio Codec Storage Capability . 16
7 Audio Codecs Specifications. 17
7.1 Feature Support . 17
7.1.1 DTMF Support . 17
7.1.2 Fax and Modem Support . 17
7.1.3 Echo Compensation Support. 18
7.1.4 Asymmetrical Services Support . 18
7.1.5 Hearing-impaired Services Support . 18
7.1.6 A-law and μ-law Support . 19
7.1.7 Packet Loss Concealment . 19
7.1.8 Fax Relay . 19
7.1.8.1 T.38 Over UDPTL . 19
7.1.8.2 T.38 Over RTP . 20
7.1.9 DTMF Relay . 20
7.1.10 V.152 Transmission . 21
7.1.10.1 V.152 Transition Triggers . 21
7.1.10.1.1 Considerations for Simultaneous T.38 and Voice Band Data Support . 22
7.1.11 Security Considerations . 23
7.2 Mandatory Codecs . 23
7.2.1 G.711 . 23
7.3 Recommended Codecs . 23
7.3.1 iLBC . 23
7.3.2 BV16 . 24
7.4 Optional Codecs . 24
7.4.1 G.728 . 24
7.4.2 G.729 Annex E . 24
7.4.3 G.722 . 24
7.5 Optional Features . 24
ETSI
4 ETSI TS 103 161-3 V1.1.1 (2011-04)
7.5.1 Wideband Codecs . 24
7.5.2 Optional Codecs . 24
7.5.3 Voice Activity Detection (VAD) . 25
7.6 Session Description of Codecs . 25
7.6.1 iLBC Session Description . 28
7.6.2 BV16 Session Description . 28
7.6.3 G.722 Session Description . 28
8 Video Requirements . 29
8.1 Overview . 29
8.2 IPCablecom Video Devices . 29
8.3 Video Encoder Requirements . 29
8.4 Video Format Requirements. 30
8.5 H.263 Annexes . 31
8.6 Multipoint Conferencing Support . 33
8.6.1 Freeze Picture Request . 33
8.6.2 Fast Update Request . 33
8.6.3 Freeze Picture Release . 33
8.6.4 Continuous Presence Multipoint (CPM) . 34
8.7 Signalling Messages . 34
9 RTCP Requirements and RTCP Usage . 35
9.1 RTP Requirements . 35
9.2 RTCP Requirements . 35
9.2.1 General Requirements of the IPCablecom RTCP Profile . 35
9.2.2 Security Requirements for RTP and RTCP in IPCablecom . 37
9.2.3 Extended RTCP Reports . 37
9.2.3.1 Reporting Call Quality Metrics using RTCP XR . 37
9.2.3.1.1 RTCP XR VoIP Metrics Requirements . 37
9.2.3.1.2 Definition of Metrics related to Packet Loss and Discard . 37
9.2.3.1.3 Definition of Metrics Related to Delay . 38
9.2.3.1.4 Definition of Metrics related to Signal . 38
9.2.3.1.5 Definition of Metrics related to Call Quality . 38
9.2.3.1.6 Definition of Parameters related to endpoint configuration . 40
Annex A (informative): Codec Comparison Tables . 42
Annex B (informative): Bibliography . 45
History . 46

ETSI
5 ETSI TS 103 161-3 V1.1.1 (2011-04)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Access, Terminals, Transmission
and Multiplexing (ATTM).
The present document is part 3 of a multi-part deliverable covering Access, Terminals, Transmission and Multiplexing
(ATTM); Integrated Broadband Cable and Television Networks; IPCablecom 1.5, as identified below:
Part 1: "Overview";
Part 2: "Architectural framework for the delivery of time critical services over cable Television networks using
cable modems";
Part 3: "Audio Codec Requirements for the Provision of Bi-Directional Audio Service over Cable
Television Networks using Cable Modems";
Part 4: "Network Call Signalling Protocol";
Part 5: "Dynamic Quality of Service for the Provision of Real Time Services over Cable Television Networks
using Cable Modems";
Part 6: "Event Message Specification";
Part 7: "Media Terminal Adapter (MTA) Management Information Base (MIB)";
Part 8: "Network Call Signalling (NCS) MIB Requirements";
Part 9: "Security";
Part 10: "Management Information Base (MIB) Framework";
Part 11: "Media Terminal Adapter (MTA) device provisioning";
Part 12: "Management Event Mechanism";
Part 13: "Trunking Gateway Control Protocol - MGCP option";
Part 14: "Embedded MTA Analog Interface and Powering Specification";
Part 15: "Analog Trunking for PBX Specification";
Part 16: "Signalling for Call Management Server";
Part 17: "CMS Subscriber Provisioning Specification";
Part 18: "Media Terminal Adapter Extension MIB";
ETSI
6 ETSI TS 103 161-3 V1.1.1 (2011-04)
Part 19: "IPCablecom Audio Server Protocol Specification - MGCP option";
Part 20: "Management Event MIB Specification";
Part 21: "Signalling Extension MIB Specification".
NOTE 1: Additional parts may be proposed and will be added to the list in future versions.
NOTE 2: The choice of a multi-part format for this deliverable is to facilitate maintenance and future
enhancements.
ETSI
7 ETSI TS 103 161-3 V1.1.1 (2011-04)
1 Scope
The present document specifies the media aspects of the interfaces between IPCablecom client devices for audio and
video communication. Specifically, it identifies the audio and video codecs necessary to provide the highest quality and
the most resource-efficient service delivery to the customer. The present document also specifies the performance
required in client devices to support future IPCablecom codecs, describes a suggested methodology for optimal network
support for codecs.
The present document also extends the existing IPCablecom 1.0 Codec specification by introducing two new low-bit
codecs, ITU-T Recommendation T.38 [20] fax relay for reliable fax transmission, RFC 2833 [24] DTMF Relay for
reliable DTMF transmission and metrics to measure voice quality.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] PKT-TR-ARCH1.5-V02-070412: "PacketCable 1.5, Architecture Framework Technical Report",
April 12, 2007, Cable Television Laboratories, Inc.
[2] PKT-SP-DQOS1.5-I04-090624: "PacketCable 1.5 Specifications, Dynamic Quality-of-Service",
Cable Television Laboratories, Inc.
[3] PKT-SP-NCS1.5-I03-070412: "PacketCable 1.5 Specifications, Network-Based Call Signaling
Protocol", April 12, 2007, Cable Television Laboratories, Inc.
[4] ATIS-0152100-2005(R2010): "Packet Loss Concealment for Use with ITU-T Recommendation
G.711".
NOTE: Available at http://webstore.ansi.org/RecordDetail.aspx?sku=ATIS-0100521.2005(R2010).
[5] Voice-Over-IP Forum Service Interoperability Implementation Agreement 1.0, December 1, 1997.
[6] "Current Methods of Speech Coding." R.V. Cox. International Journal of High Speed Electronics
& Systems, Vol 8, No 1 (1997) pp 13-68.
[7] IETF RFC 1890 (1996): "RTP Profile for Audio and Video Conferences with Minimal Control".
[8] IETF RFC 2327 (1998): "SDP: Session Description Protocol".
[9] Void.
[10] Void.
[11] Void.
[12] Void.
[13] Void.
ETSI
8 ETSI TS 103 161-3 V1.1.1 (2011-04)
[14] Void.
[15] Void.
[16] IETF RFC 1889 (1996): "RTP: A Transport Protocol for Real-Time Applications".
[17] ITU-T Recommendation G.711 (1998): "Pulse code modulation (PCM) of voice frequencies".
[18] ITU-T Recommendation G.165 (1993): "Echo Cancellers".
[19] ITU-T Recommendation G.168 (2002): "Digital network echo cancellers".
[20] ITU-T Recommendation T.38 (2004): "Procedures for real-time Group 3 facsimile communication
over IP networks".
[21] ITU-T Recommendation V.18 (2000): "Operational and interworking requirements for DCEs
operating in the text telephone mode".
[22] ITU-T Recommendation G.728 (1992): "Coding of speech at 16 kbit/s using low-delay code
excited linear prediction".
[23] ITU-T Recommendation G.729 (1998) Annex E: "11.8 kbit/s CS-ACELP speech coding
algorithm".
[24] IETF RFC 2833 (2000): "RTP Payload for DTMF Digits, Telephony Tones and Telephony
Signals".
[25] Telcordia GR-506 (2006): "LSSGR: Signaling for Analog Interfaces".
[26] Void.
[27] Void.
[28] Void.
[29] IETF RFC 3611 (2003): "RTP Control Protocol Extended Reports (RTCP XR)".
[30] ITU-T Recommendation P.56 (1993): "Objective measurement of active speech level".
[31] ITU-T Recommendation P.561 (1996): " In-service non-intrusive measurement device - Voice
service measurements".
[32] ITU-T Recommendation G.107 (2003): "The E-Model: a computational model for use in
transmission planning".
[33] ITU-T Recommendation P.862 (2001): " Perceptual evaluation of speech quality (PESQ): An
objective method for end-to-end speech quality assessment of narrow-band telephone networks
and speech codecs".
[34] IETF RFC 3952 (2004): "Real-time Transport Protocol (RTP) Payload Format for internet Low
Bit Rate Codec (iLBC) Speech".
[35] IETF RFC 3951 (2004): "Internet Low Bit Rate Codec (iLBC)".
[36] ANSI/SCTE 24-22 (2007): "iLBCv2.0 Speech Codec Specification for Voice over IP Applications
in Cable Telephony".
NOTE: Available at http://www.scte.org/documents/pdf/Standards/ANSI_SCTE%2024-22%202007.pdf.
[37] IETF RFC 4298 (2005): "RTP Payload Format for BroadVoice Speech Codecs".
[38] ANSI/SCTE 24-21 (2006): "BV16 Speech Codec Specification for Voice over IP Applications in
Cable Telephony".
[39] ITU-T Recommendation V.152 (2005): " Procedures for supporting voice-band data over IP
networks".
ETSI
9 ETSI TS 103 161-3 V1.1.1 (2011-04)
[40] IETF RFC 2198 (1997): "RTP Payload for Redundant Audio Data".
[41] IETF RFC 3407 (2002): "Session Description Protocol (SDP) Simple Capability Declaration".
[42] ITU-T Recommendation G.722 (1988): "7 kHz audio-coding within 64 kbit/s".
[43] ITU-T Recommendation G.722 Appendix III: "A high quality packet loss concealment algorithm
for G.722".
[44] ITU-T Recommendation G.722 Appendix IV: "A low-complexity algorithm for packet loss
concealment with G.722".
[45] ITU-T Recommendation G.711 Appendix II (2000): "A comfort noise payload definition for ITU-
T G.711 use in packet-based multimedia communication systems".
[46] ITU-T Recommendation V.150.1: "Modem-over-IP networks: Procedures for the end-to-end
connection of V-series DCEs".
[47] ITU-T Recommendation V.22: "1200 bits per second duplex modem standardized for use in the
general switched telephone network and on point-to-point 2-wire leased telephone-type circuits".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] PKT-SP-SEC1.5-I03-090624, PacketCable 1.5 Security Specification, June 24, 2009, Cable
Television Laboratories, Inc.
[i.2] Void.
[i.3] Void.
[i.4] Void.
[i.5] Void.
[i.6] Void.
[i.7] Void.
[i.8] ITU-T Recommendation H.245 (2003): "Control protocol for multimedia communication".
[i.9] ITU-T Recommendation H.261 (1993): "Video codec for audiovisual services at p x 64 kbit/s".
[i.10] ITU-T Recommendation H.263 (1998): "Video coding for low bit rate communication".
[i.11] ITU-T Recommendation H.323 (2003): "Packet-based multimedia communications systems".
[i.12] ITU-T Recommendation H.324 (2002): "Terminal for low bit-rate multimedia communication".
[i.13] ITU-T Recommendation Q.24: "Multifrequency push-button signal reception".
ETSI
10 ETSI TS 103 161-3 V1.1.1 (2011-04)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
audio server: audio server plays informational announcements in IPCablecom network
NOTE: Media announcements are needed for communications that do not complete and to provide enhanced
information services to the user. The component parts of audio server services are media players and
media player controllers.
call management server (CMS): controls the audio connections
NOTE: Also called a call agent in MGCP/SGCP terminology. This is one example of an application server.
cable modem termination system (CMTS): device at a cable head-end which implements the DOCSIS RFI MAC
protocol and connects to CMs over an HFC network
delay: absolute time required for a signal to transit from source to receiver
dynamic quality of service (DQoS): assigned on the fly for each communication depending on the QoS requested
hybrid fibre/coaxial cable (HFC): HFC system is a broadband bidirectional shared media transmission system using
fibre trunks between the head-end and the fibre nodes, and coaxial distribution from the fibre nodes to the customer
locations
Internet control message protocol (ICMP): extension to the Internet Protocol, ICMP supports packets containing
error, control and information messages
jitter: variability in the delay of a stream of incoming packets making up a flow such as a voice communication
latency: time, expressed in quantity of symbols, taken for a signal element to pass through a device
media gateway (MG): provides the bearer circuit interfaces to the PSTN and transcodes the media stream
media gateway controller (MGC): overall controller function of the PSTN gateway
NOTE: Receives, controls and mediates call-signalling information between the IPCablecom and PSTN.
multimedia terminal adapter (MTA): contains the interface to a physical voice device, a network interface, codecs,
and all signalling and encapsulation functions required for VoIP transport, class features signalling and QoS signalling
off-net call: communication connecting an IPCablecom subscriber out to a user on the PSTN
on-net call: communication placed by one customer to another customer entirely on the IPCablecom network
pulse code modulation (PCM): commonly employed algorithm to digitize an analog signal (such as a human voice)
into a digital bit stream using simple analog to digital conversion techniques
quality of service (QoS): guarantees network bandwidth and availability for applications
registered Jack-11 (RJ-11): standard 4-pin modular connector commonly used for connecting a phone unit into a wall
jack
real-time transport protocol (RTP): protocol for encapsulating encoded voice and video streams
transit delays: time difference between the instant at which the first bit of a PDU crosses one designated boundary, and
the instant at which the last bit of the same PDU crosses a second designated boundary
trunk: analog or digital connection from a circuit switch that carries user media content and may carry voice signalling
(MF, R2, etc.)
ETSI
11 ETSI TS 103 161-3 V1.1.1 (2011-04)
user datagram protocol (UDP): connectionless protocol built upon Internet protocol (IP)
NOTE: Delay and latency are similar concepts and frequently used interchangeably. However, delay focuses on
the time to transit from transmitter (such as a speaker's mouth) to a receiver (such as a listener's ear),
while latency focuses on the time to transit from a receiver to a transmitter, as would be the case for a
signal going through a piece of equipment.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ANS Answer Tone
NOTE: As per ITU-T Recommendation V.25.
ASCII American Standard Code for Information Interchange
CDMA Code Division Multiple Access
CED Facsimile CallED tone
NOTE: Defined in ITU-T Recommendation T.30.
CIF Common Intermediate Format
CM DOCSIS Cable Modem
CMS Call Management Server
CMTS Cable Modem Termination System
CNG Facsimile Calling tone
NOTE: Per ITU-T Recommendation T.30.
Codec Coder-DECoder
CPE Consumer Premise Equipment
CPM Continuous Presence Multipoint
CSRC Contributing source lists
DIS Digital Identification Signal
DOCSIS® Data-Over-Cable Service Interface Specification
DQoS Dynamic Quality of Service
DSC Dynamic Service Change
DTMF Dual-tone Multi Frequency (tones)
FEC Forward Error Correction
GOB Group of Blocks
GSM Global System for Mobility
HFC Hybrid Fibre/Coaxial cable
ICMP Internet Control Message Protocol
INTRA intra
IP Internet Protocol
ISDN Integrated Services Digital Network
ISP Internet Service Provider
IVR Interactive Voice Response System
LCO Local Connection Option
LSSGR LATA Switching System Generic Requirements
LUB Least-Upper-Bound
MG Media Gateway
MGC Media Gateway Controller
MIB Management Information Base
MOS Mean Opinion Score
MOS-CQ Mean Opinion Score-Conversational Quality
MOS-LQ Mean Opinion Score-Listening Quality
MTA Multimedia Terminal Adapter
NCS Network Call Signalling
NTSC National Television Standards Committee
NOTE: Defines the analog colour television, broadcast standard used today in North America.
ETSI
12 ETSI TS 103 161-3 V1.1.1 (2011-04)
PAL Phase Alternate Line
NOTE: The European colour television format that evolved from the American NTSC standard.
PCM Pulse Code Modulation
PCMA Pulse Code Modulation A-Law
NOTE: As defined in ITU-T Recommendation G.711 [17].
PCMU Pulse Code Modulation μ-law
NOTE: As defined in ITU-T Recommendation G.711 [17].
PDU Protocol Data Unit
PSTN Public Switched Telephone Network
QCIF Quarter Common Intermediate Format
QoS Quality of Service
RAM Random Access Memory
RJ-11 Registered Jack-11
RR Receiver Report
RR Receiver Report
RSVP Resource Reservation Protocol
RTCP Real-time Transport Control Protocol
RTP Real-time Transport Protocol
SDP Session Description Protocol
SQCIF Sub-Quarter Common Intermediate Format
SR Sender Report
SR Sender Report
SSRC Synchronization Source
NOTE: Telephony, real-time control protocol.
TCP Transmission Control Protocol
TDD Telecom Devices for the Deaf
TDM Time Division Multiplex(ing)
TDM Time Division Multiplexing
TDMA Time Division Multiplexing Access
TTY Text Telephone
UDP User Datagram Protocol
UDPTL UDP Transport Layer
NOTE: A transport protocol defined in ITU-T Recommendation T.38 [20].
VAD Voice Activity Detection
VBD Voice-band Data
VBR Variable Bit Rate
VoIP Voice over IP
XR Extended Reports
4 Void
5 Background
This clause outlines the IPCablecom 1.5 architecture support elements and the DOCSIS network infrastructure
necessary to deliver quality audio and video service. It is intended to clarify external interfaces and functional
requirements necessary to implement the targeted audio and video quality using speech and video codecs.
ETSI
13 ETSI TS 103 161-3 V1.1.1 (2011-04)
The key requirement for voice communications using IP transmission is the ability to attain "toll" or better audio
quality. Given the variable nature of shared packet mediums and the stringent human-factor requirements of this quality
standard, it is necessary to optimize multiple system parameters to attain this goal. Additionally, IPCablecom has been
tasked with offering superior quality, exceeding current PSTN standards where feasible. Key requirements from the
IPCablecom product definition requiring architectural optimization for codecs follow.
5.1 IPCablecom Voice Communications Quality Requirements
As defined in the IPCablecom architecture document [1], requirements for toll-quality voice communications service in
IPCablecom include numerous metrics to ensure competitive or superior quality and service to the PSTN. In order to
support these requirements, network plant and equipment may have to be groomed. In order to provide guidelines for
that grooming, several network implications affecting codec performance are discussed below.
5.2 Network Preparation for Codec Support
The critical areas of network performance, which must be optimized in tandem with codecs, are packet loss, latency,
and jitter. Elaboration of network/codec implications for each of these areas follows.
5.2.1 Packet Loss Control
There is a direct correlation between packet integrity and audio quality. Anecdotal codec research suggests initial 3 %
packet loss rate results, on average, in a reduction in Mean Opinion Score (MOS) scores of 0,5 point, on a scale of 5.
Due to less-than-pristine conditions and human-detectable compromises with most codecs, the resulting audio quality
for a 3 % packet loss rate will be well below PSTN "toll" quality. Above 3 %, codec performance falls off rapidly, and
resulting voice quality is unacceptable.
Applications and/or codecs may provide error correction or concealment mechanisms, which may increase latency
through buffering. Once latency thresholds have been exceeded, the tradeoff between latency and fidelity becomes an
untenable situation.
5.2.2 Latency Control
Control of overall latency requires a hand-in-hand effort by the system resources and the application-in this case, a
speech or video application dominated by the codec component.
There are multiple device elements and network components inducing latency during traversal of an audio signal from
capture of the speaker's voice until reception at the receiver's ear. The primary contributors to latency for an on-net voice
and off-net communication along this path are:
• Audio sampling and analog-to-digital conversion.
• Buffering of samples (audio framing, plus look-ahead).
• Compression processing.
• Packetization of compressed data.
• Local network (DOCSIS) traversal.
• Routing to the backbone network.
• Backbone traversal.
• Far-end reception of packets and traversal of local access.
• Buffering of out-of-order and delayed packets.
• Decoding, decompression, and reconstruction of the audio stream.
The major contributors to codec-related latency in the network are described below.
ETSI
14 ETSI TS 103 161-3 V1.1.1 (2011-04)
5.2.2.1 Latency Control: Buffering
While network jitter and corresponding buffering increase call latency, another source of buffering can be induced by
the application as a corrective response to severe packet loss. Although the ultimate solution to additional buffering
delay is a pristine network, realistically some packet loss will occur.
Accounting for lost packets suggests the need for support concealment or reconstruction of lost data, and in many
instances these techniques employ some mechanism of redundant information encoding, temporally shifting and
embedding audio frames in the data stream. This not only increases the effective bandwidth requirement, but also
creates, in effect, an additional buffer to allow for reassembly, increasing latency.
In order to apply certain reconstruction methodologies in an optimal fashion, the application needs accurate data
regarding the statistical characteristics of the media stream. Some information is available through real-time control
protocol (RTCP) mechanisms, such as a gross measure of packet loss. Additional information, such as burst frequency
and predictive time-of-day effects, would improve the potential of the application to make optimal adjustments.
Planning for the collection and analysis of this type of network information will allow developers more options in the
future, potentially creating applications that will increase network utilization efficiency or quality.
5.2.2.2 Latency Control: Optimal Framing/Packetization
As outlined in clause 5.2.1, the loss of audio data frames can have a severe impact on audio quality. The packing of
multiple audio frames into a single packet will exacerbate the problem, effectively expanding the loss of one packet into
the loss of multiple adjacent audio frames of data. This also increases latency by buffering larger portions of audio
samples prior to sending.
One way to minimize these effects is to send small packets containing the minimum number of frames. This will
increase bandwidth use by increasing the header-to-data ratio for packets, but will minimize latency and potentially
increase reconstruction quality. This suggests that the optimal packet size for voice applications is fairly small,
containing compressed information for one, two, or, at most, three frames of sampling data (typically corresponding to
10, 20, or 30 milliseconds of voice frames).
5.2.2.3 Latency Control: Packet Timing Optimization
To avoid additional buffering delay, packets shall be sent at a rate equal to integral multiples of the audio sample frame
rate of the codec. This synchronization results in lockstep between the codec framing and packet transmission.
The frame sizes of the codecs are shown in table 1. Default packetization periods are specified in [7].
Table 1: Frame Sizes of the Codecs
Codec Frame Size (msec)
G.711 0,125
iLBC 20
iLBC 30
BV16 5
G.728 0,625
G.729E 10
G.722 0,0625
5.2.3 Codec Transcoding Minimization
Transcoding occurs whenever a packetized voice signal encounters an edge device without compatible codec support.
Transcoding introduces additional latency during the decode/recode stage. Additionally, if transcoding resources at the
edge gateway are shared, additional delay can be introduced.
Transcoding between compressed codecs also results in degradation of the original sample, as current codec
compression techniques are not loss less. In the event that a combination of transcoding and packet loss causes a signal
to be reduced below minimum quality, it is likely that a higher bandwidth codec will be employed. Thus, transcoding
artifacts can result in the unintended side effect of higher system bandwidth utilization.
ETSI
15 ETSI TS 103 161-3 V1.1.1 (2011-04)
In the case of on-net and off-net IP connections, transcoding can be eliminated if all necessary codecs are supported on
the client. This is, in fact, impractical but can be optimized statistically if a device supports multiple codecs and can be
updated periodically.
5.2.4 Bandwidth Minimization
There are two primary mechanisms that client devices may employ to minimize the amount of bandwidth used for their
audio/video applications:
• A compressed, low bitrate codec may be applied, thus reducing the bandwidth required.
• A codec may employ some form of variable bitrate transmission.
The selection of codecs occurs at the device's discretion or via network selection, depending on the protocol employed.
Regardless, this takes place after the initial capabilities exchange to determine a compatible codec between endpoints,
and assumes that the requested bandwidth is granted by the bandwidth broker element.
Variable rate transmission may occur when a codec employs methods resulting in a non-constant bitstream
representation of voice data. Voice activity detection (VAD) - silence suppression - is a basic form of variable rate
transmission, sending little or no data during speaker silence periods. More advanced variable bitrate encoding (VBR)
occurs when a codec dynamically optimizes the compression bitstream.
6 Device Requirements for Audio codec support
As markets evolve, endpoint codecs will change too, and neither a provider nor a customer can be expected to replace
their cable modem/MTA frequently to accommodate these market changes. Given the rapid growth of the digital
wireless market in particular, it is likely that, at some point, a statistically significant portion of voice communications
will require a new codec in the standard suite in order to maintain voice quality.
Since interconnection between diverse codecs requires transcoding - which introduces unwelcome latency and
artifacts - one goal of the IPCablecom network is to minimize transcoding. Thus, a forward-looking approach to codec
evolution is necessary - one which supports the most important interconnect codecs, as well as improved performance
of on-net codecs introduced in the marketplace over the next several years.
However, now and for the immediate future, it is not cost-feasible to provide support for every possible interconnecting
codec. Thus, a compromise must be established limiting the required power of the processors and local memory.
Therefore, IPCablecom requires a minimum threshold of programmable upgradeability in its MTA devices, as
described below. These requirements include support for downloading new software from an authorized system
resource, headroom in processing for slightly more complex new codecs, and additional local storage to hold program
data.
6.1 Dynamic Update Capability
All MTA devices shall be capable of downloading new software from authorized sources.
6.2 Maximum Service Outage
If the MTA supports life-line services (such as 911 emergency service), service disruption shall not exceed 20 seconds
excluding reboot time when downloading new software to the MTA.
6.3 Minimum Processing Capability
All MTA devices shall be capable of supporting the equivalent simultaneous execution of codec combinations shown in
the following table. Although the present specification does not mandate the support of either G.728 or G.729 Annex E,
this requirement provides the necessary reserve capacity for additional future codecs to be provisioned (configured and
downloaded) on the MTA. The MTA shall support T.38 fax relay on all ports simultaneously. Media Gateway shall be
configurable to allow a specified proportion of ports to transmit T.38 fax simultaneously. However, the use of T.38 fax
relay and a voice codec on a given port for both the MTA and Media Gateway is mutually exclusive at any given time.
ETSI
16 ETSI TS 103 161-3 V1.1.1 (2011-04)
In addition DTMF Relay and Voice Metrics shall be supported on all connections simultaneously by both MTA and
Media Gateway.
Table 2: MTA Processing Capability
Maximum Ports G.711 ports iLBC Ports BV16 Ports G.728 ports G.729E ports
supported by MTA
1 1
1 1
1  1
1  1
...