Download Rationalizing G.722 Overload Points

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Public address system wikipedia , lookup

Transcript
Rationalizing G.722 overload points
Document Number:
TR 41.3.3_00-02-009
STANDARDS PROJECT:
TITLE:
Rationalizing G.722 overload points
SOURCE:
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
CONTACTS:
Michael Knappe
Phone:
(408) 527-3849
Fax:
(408) 526-0455
E-mail:
[email protected]
DATE:
February 17, 2000
DISTRIBUTION TO:
TIA TR-41.3.3
NOTICE
This contribution has been prepared to assist TIA Standards Committee TR-41. It is offered to the committee as a
basis for discussion and is not binding on Cisco Systems or any other company. The recommendations are subject to
change in form and/or numerical value after further study. Cisco Systems specifically reserves the right to add to, or
amend, the quantitative statements contained herein. Nothing contained herein shall be construed as conferring by
implication, or otherwise any license or right under any patent, whether or not the use of information herein
necessarily employs an invention of any existing or later issued patent.
The contributor grants a free, irrevocable license to the Telecommunications Industry Association (TIA) to incorporate text
contained in this contribution and any modifications thereof in the creation of a TIA standards publication; to copyright in TIA's
name any standards publication even though it may include portions of this contribution; and at TIA's sole discretion to permit
others to reproduce in whole or in part the resulting TIA standards publication.
Cisco Systems, Inc.
Page 1
of 3
Rationalizing G.722 overload points
1. Introduction
This contribution discusses the impact of mixing overload points in a wideband speech network.
1.1 Background
The ITU-T recommendation for wideband 64 kbps speech coding, G.722, currently specifies that the digital
overload point of that codec represents an analog signal of 9 dBmO. This is approximately 6 dB higher than the
3.17/3.14 (mu-law/A-law) overload points of 64 kbps PCM and other narrowband compression algorithms such as
G.729. It is assumed that the higher overload point in G.722 was meant to allow for additional signal headroom for
dedicated conference phone facilities where a higher dynamic range might be needed. This is similar to differences
in the music/recording world between consumer audio devices operating at –10 dBu and pro-audio devices operating
at +4 dBu overload points.
Analog operation at 9 dBmO overloads requires relatively large p-p voltage swings in input and output circuitry. For
high margin dedicated conference facilities, this might be an acceptable design criteria. However, with the vast
majority of phone electronics and powering developed for the 3 dBmO overload point, it does not seem practical to
redesign these endpoints to handle the additional headroom.
2
Rationalizing G.722 overload points
2. Recommendation
This contribution recommends that in the short-medium term, nothing be done about the mismatch and to redefine
new terminals employing G.722 to use the lower overload point of mu/A-law PCM. Given that there are very few 9
dBmO endpoints in use, and even fewer that will ever inter-operate G.722 samples directly with new wideband
endpoints, it appears that the occurrence of such a mismatch would be unlikely.
In the event there was a mismatch between G.722 terminal overload points, the following conditions would occur:
1.
The user with the 3 dBmO overload point terminal would hear speech from the far end 6 dB quieter than normal
(the OLR would drop 6 dB in the direction of the 3 dBmO overload point terminal.
2.
Conversely, speech received at the 9 dBmO overload point device would be heard 6 dB louder than normal (the
OLR would increase 6 dB in the direction of the 9 dBmO overload point terminal).
In our opinion, these impacts are relatively minor given the expected rarity of the event. In the longer term, it may
be worthwhile to work through the ITU-T and IETF to define a variant of G.722 that specifies the lower overload
point and to give it a separate RTP payload type such that it can be identified and compensated for on a per-call
basis. The effort involved to make those changes in two separate standards bodies, however, might not be warranted
given the relative benign nature of the mismatch.
3