vicidial.org

Here I quote some the code from the install_vici.sh on vicidialnow cd:

cd zaptel-1.2.24
# replace incorrect optimizations in Makefile
sed 's/-O4/-O2/' Makefile > Makefile.new
mv -f Makefile.new Makefile
#make clean > /dev/null
echo "compiling zaptel-1.2.24"

# replace incorrect optimizations in Makefile
sed 's/-O6/-O2\ -pipe/' Makefile > Makefile.new
mv -f Makefile.new Makefile
cd apps

What is the purpose of these modifications ?
is it suitable for SIP or for ZIP truncks ?
or its just because of Vicidial works (but its not in scratch install)

Thanks

This has nothing to do with SIP or ZAP trunks. This just replaces the incorrect GCC optimization flags included in the Makefiles of Asterisk and Zaptel. By default they use the "-O4" GCC optimization flag which is invalid.

I am experiencing bad audio quality, micro cuts that come & go during conversation.
I am looking for information about Makefiles in zaptel & asterisk, changes to be made before compile to help me with my problem

By default they use the "-O4" GCC optimization flag which is invalid

so why do you think -O4 is invalid ? would they commit this error in all versions ?

What is your hardware configuration and version numbers for your installation.

have you had this issue since may or is it recent?

have you replaced any hardware or upgraded any software during the time that this issue surfaced?

what is your server load during this issue (does it happen all the time)?

You can check the website of the GNU C compiler (http://gcc.gnu.org) for the optimization codes. -O4 is valid for GCC 2.X versions and below. Maximum optimization for versions 3.X and above is -O3. Versions 2.X are very old GCC versions and I doubt that it's still being packaged in any modern Linux distributions.

The issue you're having might be related to something else as Williamconley suggests.

newx22 wrote:I am experiencing bad audio quality, micro cuts that come & go during conversation.
I am looking for information about Makefiles in zaptel & asterisk, changes to be made before compile to help me with my problem

By default they use the "-O4" GCC optimization flag which is invalid

so why do you think -O4 is invalid ? would they commit this error in all versions ?

Hi & thanks for your replies,

I am experiencing bad audio quality on my calls thru a Digium TE212P card configured for E1/euroisdn technology.
My Install is :

scratch install of vicidial on a debian system : linux-2.6.24-etchnhalf.1-686 / asterisk-1.2.27 / zaptel-1.2.24 / libpri-1.2.5 on a small HP Server ML110 G5

I experience micro cuts in the voice, this does not happen during the whole call, it happens during 2 seconds then audio becomes normal, & then back again 2 or 3 seconds then goes away.

I have compiled libpri, zaptel & asterisk with thier default config files.

I am sticking to asterisk 1.2.30 because I believe it is the
recommended version isn't it ?

With 10 to 15 concurrent calls load on the server is 0.2 sometimes
less, (thats why I was told that I don't need to recompile asterisk
since I have no cpu overloading)

but here is what zttest says :

zttest
Opened pseudo zap interface, measuring accuracy...
99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586%
99.975586% 99.975586% 99.975586% 99.975586% 99.975586% 99.975586%
99.975586% 99.975586%
--- Results after 15 passes ---
Best: 99.975586 -- Worst: 99.975586 -- Average: 99.975586

I read on the web it should be at least 99.99% - Do you know HOW can I
improve it ? maybe its the source of the problem.

besides this, I paste my zaptel.conf :

span=1,1,6,ccs,hdb3
span=2,1,6,ccs,hdb3
bchan=1-15,17-31
dchan=16
bchan=32-46,48-62
dchan=47
loadzone=fr
defaultzone=fr

when I put 6 in LINE BUILD OUT (1,1,6,ccs,hdb3) value I got better
call quality than when it was 5 (1,1,5,ccs,hdb3).

I also added echotrainning = 1600 in my zapata.conf file as some
website suggested.

[trunkgroups]
[channels]
language=fr
loadzone=fr
defaultzone=fr
context=default
switchtype=euroisdn
pridialplan=dynamic
signalling=pri_cpe
internationalprefix=+
nationalprefix=34
;rxwink=250 ; Atlas seems to use long (250ms) winks
;rxwink=200
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
echotrainning=1600
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
group=1
channel => 1-15
channel => 17-31
channel => 32-46
channel => 48-62

here is interupts file :

cat /proc/interrupts
CPU0 CPU1
0: 84 1 IO-APIC-edge timer
1: 2 1 IO-APIC-edge i8042
8: 0 0 IO-APIC-edge rtc
9: 0 1 IO-APIC-fasteoi acpi
14: 1960 2009 IO-APIC-edge libata
15: 0 0 IO-APIC-edge libata
16: 20 21 IO-APIC-fasteoi uhci_hcd:usb1
17: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
18: 41 41 IO-APIC-fasteoi libata
19: 312691 312616 IO-APIC-fasteoi wct2xxp
219: 28650 28674 PCI-MSI-edge eth0
NMI: 0 0 Non-maskable interrupts
LOC: 37798 36818 Local timer interrupts
RES: 191 216 Rescheduling interrupts
CAL: 153 91 function call interrupts
TLB: 727 751 TLB shootdowns
TRM: 0 0 Thermal event interrupts
SPU: 0 0 Spurious interrupts
ERR: 0
MIS: 0

I think there is no "interrupt conflicts / sharing" ?

Disk IO activity I am sure I don't have, but Ethernet activity I have
a lot, the server is constantly querying a mysql database.

and here is lspci output:

lspci
00:00.0 Host bridge: Intel Corporation Unknown device 29f0 (rev 01)
00:01.0 PCI bridge: Intel Corporation Unknown device 29f1 (rev 01)
00:1c.0 PCI bridge: Intel Corporation Unknown device 2940 (rev 02)
00:1c.4 PCI bridge: Intel Corporation Unknown device 2948 (rev 02)
00:1c.5 PCI bridge: Intel Corporation Unknown device 294a (rev 02)
00:1d.0 USB Controller: Intel Corporation Unknown device 2934 (rev 02)
00:1d.1 USB Controller: Intel Corporation Unknown device 2935 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation Unknown device 2916 (rev 02)
00:1f.2 IDE interface: Intel Corporation Unknown device 2920 (rev 02)
00:1f.3 SMBus: Intel Corporation Unknown device 2930 (rev 02)
00:1f.5 IDE interface: Intel Corporation Unknown device 2926 (rev 02)
0d:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e
[Pilot] ServerEngines (SEP1) (rev 02)
0e:00.0 Ethernet controller: Broadcom Corporation Unknown device 165a
11:00.0 Communication controller: Digium, Inc. Wildcard TE210P (rev 02)

Sorry, that would be the reason I no longer use debian. I didn't have the time available to tweak the kernel. You could try a scratch install on the recommended OS or a vicidialNOW install.

I use Gentoo, personally, for my installs. I have a tech who swears debian is best, but even he gave up because of issues exactly like this one.

You could also contact digium for support on the hardware, but they may point to the OS/kernel and want to charge you for the support if you want them to actually resolve the issue.

I'd like to be more help, but you actually have technology I've never had to deal with (digium/euroisdn). Matt has probably dealt with it, but I know I've not.

I found this while googling :

/usr/bin/setpci -v -s ##:##.# LATENCY_TIMER=ff

(##:##:# : hardware id taken from output of lspci)

I added it to rc.local just before loading zaptel modules.
& I got 99.987793%


Opened pseudo zap interface, measuring accuracy...
99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793%
99.987793% 99.987793% 99.987793% 99.987793% 99.975586% 99.987793% 99.987793% 99.987793%
99.987793% 99.987793%
--- Results after 17 passes ---
Best: 99.987793 -- Worst: 99.975586 -- Average: 99.987075


which is acceptable for me when I added to it usb headsets.

As of my choice of debian distribution, it is because it has been the fastest distro I have put on trial, I could even say I never had to worry about server load when I had a debian installed.

just one more thing, I changed a few settings in the bios & I got 100% !!!
eventhough after that I spent two more hours of changing things that I forgot what were the exact bios settings & I got tired (a reboot & a test after each change) & finaly decided to stick to 99.987793% as it was acceptable to me.

so I think it's possible on an hp ml110 server to get a 100%.
& it was on a debian system

good to know. i have a client that is using debian and will have him try it (he's not using vicidial, only freepbx, and has occasional sound quality issues that are not severe enough to care about, but he'd like them to go away without paying anyone).

my problem with debian is just that, you spend hours tweaking the bios ... if you were charging by the hour it would have cost the customer less $$ to rebuild it in slackware or gentoo.

but if you've gotten 100%, i'd love to find out what those settings were.

newx22- have you tried the stable Debian?

We have it on 3 systems- Dell 1750 firstly with 2 T1 ports Digium card, now with 4 ports one, Dell 1850 which used to run all-in-one setup with up to 45 agents without a glitch, and the third HP DL320 G5p machine, which now holds MySQL+Apache+vicidial for 5-10 agents load balanced with the 1850.
All this on Debian etch stable without any issues related to OS for more than an year.

Output from the 1750 with TE412P
kernel 2.6.18-6-686

Opened pseudo zap interface, measuring accuracy...
99.995712% 99.983391% 99.996193% 99.997169% 99.996185% 99.995125% 99.985252%
99.994820% 99.990440% 99.994240% 99.989944% 99.997559% 99.998329% 99.998047% 99.986816%
99.991310% 99.997353% 99.998543% 99.994049% 99.986916% 99.993851% 99.988678% 99.999023%
99.985748% 99.990929% 99.993065% 99.988480% 99.997948% 99.986526% 99.999115% 99.998138%
99.989342% 99.998245% 99.988480% 99.995033% 99.997070% 99.991119% 99.992485% 99.993744%
99.999023% 99.995117% 99.990135% 99.996681% 99.993652% 99.996880% 99.999985% 99.988869%
99.996490% 99.992287% 99.996292% 99.993065% 99.982819% 99.997749% 99.994034% 99.995209%
99.994530% 99.978714% 99.997940% 99.992279% 99.990532% 99.996292% 99.989357% 99.996880%
99.990623% 99.995323% 99.998337% 99.987701% 99.997856% 99.992279% 99.986130% 99.991295%
99.987885% 99.998436% 99.993942% 99.996391%
--- Results after 75 passes ---
Best: 100.000 -- Worst: 99.979 -- Average: 99.993272, Difference: 99.994971