Timing and voice quality problems

[CHP]

Hello all,

we're using vicidialnow 1.1rc2 on a dual Server environment for outbound dialing. 1 Quad Xeon MP 2.2 Ghz for the vicidial and 1 Quad Xeon MP 3.0 Ghz for the Database/Webserver.

Connection to the Voip provider is an IAX2 Trunk using the uLAW codec. The Voip Provider is connected on the same LAN.
The Clients are connected throug through WAN using GSM codes and the Ping times from the vicidial server to the agents is about 10-15 ms.

At the moment there is no hardware used for timing, zttdummy is doing that.
That's why we've replaced the default Centos Kernel with the 2.6.22.19 and activated the HPET, High Resolution Timer Support (ztdummy), Preemption (Server), I/O Scheduler(deadline)...

The IRQ's for the vicidial servers are optimized (no USB, no IDE, ...).
name-resolve & host-cache at the DB-Server are disabled.
zttest reports about 99,995 %.

But our System has two major problems:

There is a delay from 3-5 seconds between the called customer is picking up the line until the call is tranfered to the meetme room and is displayed at the agent screen.
During testing (no overdialing, ratio=1) we've also noticed that sometimes the called customer picks up the line and the vicidial doesn't transfer the call to the meetme room, the customer is hanged up.

The second one is that the system doesn't support more than 5 Agents (outbound dialing factor 3-4), then the voice became choppy, noisy,...

We've tried also VicidialNow 1.1CE, and kernels from the 2.6.24.x and 2.6.25.x but with same results. We haven't tried the original installation from scratch with slackware, but I think that can't make such a big difference.

So I think that we having a major fault in our configuration/system, does somebody have any ideas?

Thanks for your help in advance.

[mflorell]

If you are using GSM, it might be a gcc GSM optimization bug that we see commonly on newer systems. If you use ULAW for the agents do you have the same quality issues?

[CHP]

we'll gonna give ULAW a try...

is that the patch for the gsm bug you mentioned before?
http://download.vicidial.com/asterisk-p ... c4.2.patch

but anyway i'm using gcc4.1.2.

Can the quality issues (maybe gsm opt. bug) also have something to do with the above explained delay?

[mflorell]

Yes, that shoul dbe the patch.

What is the loadavg on the server when the problems occur?

[CHP]

Sorry for the late reply, but we've need some time for testing...

Here is an example for a time period of 2h, in the graph there are heavy peaks every 6 minutes...

VICIDIAL: Server Performance
Time range: 2008-08-04 10:20:00 to 2008-08-04 12:30:00

---------- TOTALS, PEAKS and AVERAGES
Total Calls in/out on this server: 166
Total Off-Hook time on this server (min): 168.39
Average/Peak channels in use for server: 4.5347 / 24
Average/Peak load for server: 27.1359 / 101
Average USER process cpu percentage: 1.3623 %
Average SYSTEM process cpu percentage: 0.3498 %
Average IDLE process cpu percentage: 98.2264 %

Anyway we skipped trying to find the problem, and made a new setup with Slackware 12.1 according to the scratch install.

Troubles are gone, and the system seems to work.

I exactly don't know how significant the results of zttest are for quality, but there is an interesting fact we found out during our tests:

Same Hardware with compiled kernel 2.6.24.5 (high res. timer for ztdummy enabled):
Centos/VicidialNow CE 1.1: zttest average 99.95
Slackware 12.1. : zttest average 99.999

[mflorell]

Thank you very much for posting your results, they are pretty much what we have experienced as well.

Please let us know how your VICIDIAL setup works for you as you continue using it.

[xCape]

If you are using GSM, it might be a gcc GSM optimization bug that we see commonly on newer systems. If you use ULAW for the agents do you have the same quality issues?

What file do you patch?

Thanks.

[mflorell]

codecs/gsm/Makefile