[asterisk-users] Transcoded G.722 calls unintelligible with recent SVN head

[P Milazzo]

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.

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:

    * 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.
    * Transcoding between u-law and GSM works fine.
    * Transcoding from G.722 to GSM produces unintelligible audio in
      both directions.

So far, the only other clue I have is this pair of messages upon startup:

[Feb  7 18:35:02] WARNING[17950] translate.c: plc_samples 160 format f
[Feb  7 18:35:02] VERBOSE[17950] logger.c:   == Registered translator 
'g722tolin16' from format g722 to slin16, cost 1999

A "core show translation recalc 240" shows that all the necessary 
translations are available and sufficiently fast:

         Recalculating Codec Translation (number of sample seconds: 240)

         Translation times between formats (in microseconds) for one 
second of data
          Source Format (Rows) Destination Format (Columns)

           g723   gsm  ulaw  alaw g726aal2 adpcm  slin lpc10  g729 
speex  ilbc  g726  g722 slin16
     g723     -     -     -     -        -     -     -     -     -     
-     -     -     -      -
      gsm     -     -   762   762     1682   866   733  4386     - 11102 
15076  1706  1707   1541
     ulaw     -  1578     -    24      969   153    20  3673     - 10389 
14363   993   994    828
     alaw     -  1578    20     -      969   153    20  3673     - 10389 
14363   993   994    828
 g726aal2     -  2332   803   803        -   907   774  4427     - 11143 
15117    24  1748   1582
    adpcm     -  1632   103   103     1023     -    74  3727     - 10443 
14417  1047  1048    882
     slin     -  1558    29    29      949   133     -  3653     - 10369 
14343   973   974    808
    lpc10     -  2686  1157  1157     2077  1261  1128     -     - 11497 
15471  2101  2102   1936
     g729     -     -     -     -        -     -     -     -     -     
-     -     -     -      -
    speex     -  3099  1570  1570     2490  1674  1541  5194     -     - 
15884  2514  2515   2349
     ilbc     -  3211  1682  1682     2602  1786  1653  5306     - 
12022     -  2626  2627   2461
     g726     -  2332   803   803       29   907   774  4427     - 11143 
15117     -  1748   1582
     g722     -  2403   874   874     1794   978   845  4498     - 11214 
15188  1818     -    999
   slin16     -  3124  1595  1595     2515  1699  1566  5219     - 11935 
15909  2539  2191      -

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...

    Thanks!
    Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080207/e8b28b04/attachment.htm