<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
For about 10 months I have been running a succession of Asterisk SVN
trunk versions on an Athlon 64 X2 4400+ based machine with OpenSuSE
10.2 at my home. I have a variety of SIP phones (mostly Polycom)
internally; my external connections are two POTS lines on a TDM400P
(with HPEC) and an IAX2 link to a VoIP provider. I had Asterisk
configured to allow G.722 and u-law on the Polycom phones, u-law on the
POTS lines, and u-law and GSM on the IAX2 link.<br>
<br>
All was well until last month when I foolishly updated my Asterisk to
Revision 99188; previously I had been running a version from circa
October 20, 2007 (version number unknown; sorry). Since updating to
r99188 and subsequent versions (I'm currently running r102802), any
calls requiring transcoding of G.722 connect but have variously
unintelligible audio. For example:<br>
<ul>
<li>If I call from a Polycom IP 650 out through the POTS line, the
first leg uses G.722 to the Asterisk box, which transcodes to u-law for
the outbound leg. The incoming audio (u-law -> G.722) sounds fine,
but the outgoing audio (G.722 -> u-law) is almost (but not
completely) unintelligible. An incoming call from a POTS line sounds
fine in both directions because Asterisk creates the leg to the Polycom
IP 650 using u-law, so no transcoding takes place.<br>
</li>
<li>Transcoding between u-law and GSM works fine.</li>
<li>Transcoding from G.722 to GSM produces unintelligible audio in
both directions.</li>
</ul>
So far, the only other clue I have is this pair of messages upon
startup:<br>
<br>
<tt>[Feb 7 18:35:02] WARNING[17950] translate.c: plc_samples 160
format f<br>
[Feb 7 18:35:02] VERBOSE[17950] logger.c: == Registered translator
'g722tolin16' from format g722 to slin16, cost 1999<br>
</tt><br>
A "core show translation recalc 240" shows that all the necessary
translations are available and sufficiently fast:<br>
<tt><br>
Recalculating Codec Translation (number of sample seconds: 240)<br>
<br>
Translation times between formats (in microseconds) for one
second of data<br>
Source Format (Rows) Destination Format (Columns)<br>
<br>
g723 gsm ulaw alaw g726aal2 adpcm slin lpc10 g729
speex ilbc g726 g722 slin16<br>
g723 - - - - - - - - -
- - - - -<br>
gsm - - 762 762 1682 866 733 4386 -
11102 15076 1706 1707 1541<br>
ulaw - 1578 - 24 969 153 20 3673 -
10389 14363 993 994 828<br>
alaw - 1578 20 - 969 153 20 3673 -
10389 14363 993 994 828<br>
g726aal2 - 2332 803 803 - 907 774 4427 -
11143 15117 24 1748 1582<br>
adpcm - 1632 103 103 1023 - 74 3727 -
10443 14417 1047 1048 882<br>
slin - 1558 29 29 949 133 - 3653 -
10369 14343 973 974 808<br>
lpc10 - 2686 1157 1157 2077 1261 1128 - -
11497 15471 2101 2102 1936<br>
g729 - - - - - - - - -
- - - - -<br>
speex - 3099 1570 1570 2490 1674 1541 5194 -
- 15884 2514 2515 2349<br>
ilbc - 3211 1682 1682 2602 1786 1653 5306 -
12022 - 2626 2627 2461<br>
g726 - 2332 803 803 29 907 774 4427 -
11143 15117 - 1748 1582<br>
g722 - 2403 874 874 1794 978 845 4498 -
11214 15188 1818 - 999<br>
slin16 - 3124 1595 1595 2515 1699 1566 5219 -
11935 15909 2539 2191 -</tt><br>
<br>
For the moment, I have simply disabled G.722 everywhere (sigh). How
might I best go about diagnosing the real problem? I see that there
have been half a dozen or so G.722-related commits since the version
that worked for me, so I suppose I could just compile various old
versions in binary-search fashion, but I'm hoping someone might
recognize the symptoms before I embark on that endeavor...<br>
<br>
Thanks!<br>
Paul<br>
</body>
</html>