[Home]

Summary:ASTERISK-11849: Corrupted sound or call recording via IAX and GSM
Reporter:Jake Hansen (ztel)Labels:
Date Opened:2008-04-14 19:52:43Date Closed:2011-06-07 14:03:03
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Formats/format_gsm
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bad-playback-gsm.WAV
( 1) status.WAV
Description:I have a problem with installing Asterisk on Debian / Lenny, exact kernel / version is:

Linux version 2.6.22-3-686 (Debian 2.6.22-6) (maks@debian.org) (gcc version 4.1.3 20071019 (prerelease) (Debian 4.1.2-17)) #1 SMP Mon Nov 12 08:32:57 UTC 2007

STEPS TO REPRODUCE PROBLEM:
1) Download Debian / Lenny which is located at

http://www.us.debian.org/devel/debian-installer/

I use the iso which is located at:

http://cdimage.debian.org/cdimage/lenny_di_beta1/i386/iso-cd/debian-testing-i386-netinst.iso

2) Install on a server with two network cards and make eth0 the WAN and eth1 the LAN

3) Set up firewall that can masquerade and do nat... I can provide this firewall if it helps...

4) install the newest version of asterisk 1.4 on server

5) setup 1 sip device and a voicemail

6) route an extension to this server from a different asterisk server via IAX to the sip device using either GSM or ULAW.

7) The call will be clear, but the voicemail prompts and recordings will be garbled or vice versa depending on how you set up the codec in iax.conf

8) change iax.conf to not use gsm and instead use ULAW

9) the call will be garbled but the voicemail prompts will be clear..

there is no way to get them both working..

I have a system set up in this configuration that is currently experiencing the problem 100% of the time, and this is the 5th different server i have tried this it is 100% reproducible.
--------------------------------------------------
Basically the call flow would look like:

INCOMING SIP PROVIDER -> Asterisk TRUNK at datacenter -> application asterisk server (IAX connect / GSM) -> recoring on local box or forwarding to sip device

This configuration works great with the Debian Stable (2.6.18) and Debian Experimantal (2.6.23), but Testing (2.6.22) is broken...

This is annoying because stable does not work with most SATA controllers and experimental is too unstable to be a desirable production platform... I wish I could tell what is different between the versions but I thought it might be worth reporting to see if any ideas exist.  Google searches do not result in any significant information to report.


Please let me know if i can provide any additional information that would help.

Ztel
Comments:By: Jason Parker (jparker) 2008-04-15 10:10:50

Try recompiling Asterisk from source (1.4.19), and see if the problem goes away.  There was an issue with gcc and the gsm codec that sounds very similar to what you're describing.

Please let us know how it goes.
By: Jake Hansen (ztel) 2008-04-18 13:39:24

Tested the problem... the sound recordings still have no improvement and there was no change in quality... now we are running:

Connected to Asterisk 1.4.19 currently running on franserv-1 (pid = 24552)
By: Jake Hansen (ztel) 2008-04-21 01:25:49

I have done some more testing which might be helpful..

;exten => s,n,MixMonitor(${ARG1}) ;; corrupted sound
exten => s,n,Monitor(wav49,${ARG1},m) ;; works great!!!
;exten => s,n,Monitor(wav,${ARG1},m) ;; corrupted sound

where ${ARG1} is the name of the file to be recorded...

It seems that using ULAW of any kind on the system is where things go wrong.  If I completely avoid using ULAW for the inbound codec and the call recording then I have no problem.  If I use ULAW for the preferred codec, i get corrupted sound for the entire call.  If I stick to GSM and then try to record the call in ULAW format (wav) then the recording is corrupted but the call sounds clear..

Contrary to my previous post, I have tried to upgrade to unstable version of debian as well just to get it working and it has the same problem with no change.  

The only way it works is if i record it in wav49 format which is not an option with the mixmonitor app as far as i can tell and can only be done with monitor app...


By: Holger (hesser) 2008-04-23 14:07:15

Problem confirmed with ubuntu server 8.04 asterisk 1.4.19
Exact same issue.
By: Jason Parker (jparker) 2008-05-06 14:42:43

Can one of you upload a copy of a recording that sounds corrupted?

Also, if you could clearly describe the call path for the given recording, that would be very helpful.
By: gavin (gavin) 2008-06-22 05:19:15

Ubuntu 8.04
2.6.24-19-generic
2.6.24-18-generic
2.6.24-16-generic

asterisk:
1.4.17
1.4.21

dpkg -l | grep -i gcc
ii gcc 4:4.2.3-1ubuntu6 The GNU C compiler
ii gcc-3.3-base 1:3.3.6-15ubuntu6 The GNU Compiler Collection (base package)
ii gcc-4.1 4.1.2-21ubuntu1 The GNU C compiler
ii gcc-4.1-base 4.1.2-21ubuntu1 The GNU Compiler Collection (base package)
ii gcc-4.2 4.2.3-2ubuntu7 The GNU C compiler
ii gcc-4.2-base 4.2.3-2ubuntu7 The GNU Compiler Collection (base package)
ii libgcc1 1:4.2.3-2ubuntu7 GCC support library
ii libgomp1 4.2.3-2ubuntu7 GCC OpenMP (GOMP) support library




Incomming SIP ULAW call.  

Record("SIP/66.54.140.46-08297100", "/tmp/status.WAV|2|60|nt")
BackGround("SIP/66.54.140.46-08297100", "/tmp/status")

File sounds corupted via SIP/Ulaw and ZAP playback
WAV49 gsm file sounds normal when downloaded and played on Windows PC

See uploaded sound files:
http://forums.digium.com/viewtopic.php?p=72748
http://bugs.digium.com/view.php?id=10226


By: gavin (gavin) 2008-06-26 01:00:00

I do not know what is at fault but

gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

or asterisk code is broken.  Using

gcc version 4.1.3 20080308 (prerelease) (Ubuntu 4.1.2-21ubuntu1)

worked for me.


root@hh:/usr/lib/asterisk/modules# cd /usr/bin
root@hh:/usr/bin# ls -lsah gcc
0 lrwxrwxrwx 1 root root 7 2008-06-25 23:38 gcc -> gcc-4.2
root@hh:/usr/bin# rm gcc
root@hh:/usr/bin# ln -s gcc-4.1 gcc
root@hh:/usr/bin# ls -lsah gcc
0 lrwxrwxrwx 1 root root 7 2008-06-25 23:54 gcc -> gcc-4.1
root@hh:/usr/bin# cd /usr/src/asterisk/20080621/asterisk-1.4.21
root@hh:/usr/src/asterisk/20080621/asterisk-1.4.21#

make clean
./configure
make menuselect
make
make install





root@hh:/usr/bin# gcc-4.2 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)





root@hh:/usr/bin# gcc-4.1 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20080308 (prerelease) (Ubuntu 4.1.2-21ubuntu1)
By: gavin (gavin) 2008-06-26 01:09:57

Looks like ubuntu is a little behind.  Could someone try 4.3?

http://gcc.gnu.org/gcc-4.3/
By: Tilghman Lesher (tilghman) 2008-06-26 23:15:24

gcc 4.3 also has this problem, and it is an acknowledged defect in one of the 3rd set (-O3) of the gcc optimization engine.  You can prove this to yourself by turning on the DONT_OPTIMIZE flag, which will cause the audio distortion to disappear.

If you'd like to assist the gcc team in tracking down where this issue lies, you can do so by checking out their instructions on the defect page:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34216
By: Leif Madsen (lmadsen) 2008-09-08 14:20:30

Feel free to reopen if this is an issue that you can duplicate with a newer version of GCC, but this issue appears to be resolved in later versions of GCC.