vicidial.org

by **marcin** » Tue Mar 31, 2009 7:41 am

I run successfully vicidialnow 1.2 with 20+ agents and every 3 to 4 days I get the asterisk hanged. I am using a tc400b but no timer source like x100p, only ztdummy with sip provider.
This is an part of messages when asterisk goes down:

Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 WARNING[2081] channel.c: Avoided deadlock for '0xa01c9e8', 9 retries!

May the timer (lack off) be an issue? Digium will not help me due to a version of asterisk.

VERSION: 2.0.4-122 BUILD: 81011-0855

by **mcargile** » Tue Mar 31, 2009 8:20 am

Sounds like your server is overloaded. What are the spec's of the server (processor, ram, etc).

by **marcin** » Tue Mar 31, 2009 8:40 am

asterisk+web server is a dual 1gb pentium 3 with 1.5 gig of ram and I have been monitoring my load average, 1.0 or less at all times. Mysql is on dedicated sever with a 1gig nic.
I am planning on moving the asterisk+web to a dual 3.06 xeon with 4 gig of ram today ( ibm 1u) will this solve my problem?
Do I need x100p in it as well? If so I would have to take the remote admin board out.

by **mcargile** » Tue Mar 31, 2009 8:51 am

The system you are currently using for Asterisk is under powered for use with Vicidial. This is what is causing the deadlocks.

For 20 agents what we normally recommend is a two system setup, with the web interface and database running from one system and asterisk running on its own dedicated system. We recommend a quad core processor with 4 gigs of ram for both systems. Though you might be fine with the dual core Xeon you have.

by **marcin** » Wed Apr 01, 2009 9:11 am

Is there a document describing separation of asterisk from the rest of the system?
What cron jobs to run on asterisk server?
what startup scripts must start on asterisk server?

by **mflorell** » Wed Apr 01, 2009 9:27 am

There are many ways of separating components of VICIDIAL onto separate servers. Thsi first thing we recommend is moving the database and webserver to a separate machine. No crontab entries will be moved, those stay on the Asterisk server, just the database and web directories are moved to the new machine.

by **marcin** » Wed Apr 01, 2009 2:16 pm

Thank you for advise, it works very well.

by **marcin** » Wed Apr 01, 2009 9:02 pm

Well, it has been working during a testing but when I put only 7 agents on dual xeon 3.06 with 4 gigs of ram ( new server ) the same problem accrued again and hung the server 3 to 3.5 hours in to a shift.
It is not a hardware issue.
I am almost ready to follow the scratch_install and base the system on slackware in place of centos.
any ideas?

by **mflorell** » Wed Apr 01, 2009 9:07 pm

Getting rid of CentOS can't hurt

by **williamconley** » Fri Apr 03, 2009 8:00 pm

Absolutely: Follow the scratch_install instructions on Slackware and you will have a system that was designed by the makers of Vicidial. This is your best method and will allow you to get your system working reliably AND (in the future), should you need help, you can easily post your system specs and get help with your standardized system.

If you have your wits about you, you could even go as far as an SVN install and have the latest-greatest at all times.

VicidialNOW is EXCELLENT to get beginners into the game, but if you're past that (or don't need a PlugNPlay solution), scratch install on slackware is THE way to go.

by **gardo** » Sun Apr 05, 2009 12:43 pm

Do you still encounter the following errors on your new server?

What' s the load average when this happens? Can you post the output of "df -h"?

marcin wrote:I run successfully vicidialnow 1.2 with 20+ agents and every 3 to 4 days I get the asterisk hanged. I am using a tc400b but no timer source like x100p, only ztdummy with sip provider.
This is an part of messages when asterisk goes down:

Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 DEBUG[2081] channel.c: Avoiding deadlock for 'SIP/protectedip-0a03baf0'
Mar 30 20:24:22 WARNING[2081] channel.c: Avoided deadlock for '0xa01c9e8', 9 retries!

May the timer (lack off) be an issue? Digium will not help me due to a version of asterisk.

VERSION: 2.0.4-122 BUILD: 81011-0855

by **marcin** » Sun Apr 05, 2009 2:53 pm

The new server configuration is two single core 3.06 gig xeon ( cent os see this as 4 processors) 4.6 gig of ecc RAM ( precompiled kernel sees only 4 gigs) and it is happening on a new server as well. I can clearly eliminate the hardware issue. and I do not have a df output for you at this time but I will post it as soon as it happens again. Load average is bellow 0.5
I have to hold on with slackware install since I have ordered the x100p to have a solid a timer source for meetme and they should arrive within next day or two. tc400b is not a timer source.
williamconley ; you are correct I do not need a pnp solution and I am very familiar with slackware.
Thank you for all the help.

by **gardo** » Mon Apr 06, 2009 2:41 am

We have centers running VicidialNOW with more than 50 seats on a multi-server setup. On a dual core Xeon (HP Proliant) with only ztdummy as timer, it runs stable with 20 agents. Ztdummy still relies on the USB host on your machine. Check if it's enabled in your BIOS.

by **marcin** » Mon Apr 06, 2009 9:03 am

I checked and USb is enabled, and driver is loaded.
this is an output from zttest:

--- Results after 30 passes ---
Best: 99.975586 -- Worst: 99.926758 -- Average: 99.956462

It could be better.

by **marcin** » Mon Apr 06, 2009 9:11 am

I only get a deadlock when sip message is send to a termination provider to initiate the calls. We also run 1.4 version of asterisk with same provider without any deadlock errors (deferent server).

by **gardo** » Mon Apr 06, 2009 3:10 pm

Can you trunk your VicidialNOW and make all calls pass through the Asterisk server (with IAX trunk) and see if this still happens. Or if you can update to Asterisk 1.4 on the VicidialNOW server and see if the issue still persists.

by **marcin** » Tue Apr 07, 2009 1:02 am

this is a df -h output when it happend:

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 32G 2.0G 29G 7% /
/dev/sda1 99M 12M 83M 12% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
I will try iax and/or upgrade to 1.4 and post the results.

by **marcin** » Tue Apr 07, 2009 10:38 am

Changing to iax did not make a deferance the deadlocl debug shows in a messages:
Apr 7 10:32:46 DEBUG[24718] channel.c: Avoiding initial deadlock for 'SIP/cc130-08465d68'
###cc130 is a cisco phone using SIP###
Apr 7 10:32:46 VERBOSE[24844] logger.c: -- Executing AGI("SIP/cc130-08465d68", "agi://127.0.0.1:4577/call_log") in new stack
Apr 7 10:32:46 VERBOSE[24844] logger.c: -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
Apr 7 10:32:46 VERBOSE[24844] logger.c: -- Executing Dial("SIP/cc130-08465d68", "IAX2/user:pass@host/18005551212|55|To") in new stack
Apr 7 10:32:46 DEBUG[24718] channel.c: Avoiding initial deadlock for 'IAX2/user-9465'

by **gardo** » Tue Apr 07, 2009 10:53 am

Any special entries/config in your extensions.conf? Can you try using a softphone instead of the cisco. Looks like the issue might be related to the cisco phone.

by **marcin** » Tue Apr 07, 2009 11:04 am

Same deadlock messages with softphone (x-lite)

by **williamconley** » Tue Apr 07, 2009 11:08 am

What version of asterisk are you using? Have you tried a different provider? and have you tried dropping back one (or a few) version of asterisk (or zaptel)?

by **marcin** » Tue Apr 07, 2009 11:49 am

I am using default install od VICIDIALNOW 1.2 did not try to upgrade nor downgrade any software yet, the provider is 3utelecom

by **williamconley** » Tue Apr 07, 2009 1:15 pm

Perhaps it would be good to try another provider, just for a test, to see if the problem persists (i recommend having at least two and preferably three active providers anyway, just in case: then when you have a problem you can "rule out" provider issues quickly).

by **marcin** » Wed Apr 08, 2009 9:43 am

I took fifth look at my configuration files and found entry for chanspy.
After removing it most of the deadlock messages are gone but not all.
btw; same problem with deferant provider as well.
Perhaps there is a problem with my routing.
on asterisk server I have two nic
one with external IP address and gateway
and one with internal 192.168.1.2 without a gateway.
all of the phones are an private network.
deadlock message also shows when I place a call from one extension to an other on the same subnet, ulaw.
Am I overlooking something?

by **gardo** » Wed Apr 08, 2009 1:11 pm

Have you completely removed the chanspy entries in your extensions.conf? There shouldn't be any issues with your server having 2 lan cards - one public and one private.

by **marcin** » Wed Apr 08, 2009 1:38 pm

Yes, I have removed the chanspy entries.
I will monitor the system for next day or so and post the results.

by **marcin** » Thu Apr 09, 2009 5:58 pm

I did not had to wait for long. The asterisk deadlocked again:
some outputs from deadlock:

Apr 9 17:37:10 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8951708', 9 retries!
Apr 9 17:37:10 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8928440', 9 retries!
Apr 9 17:37:10 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x888f548', 9 retries!
Apr 9 17:37:10 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8818df0', 9 retries!
Apr 9 17:37:10 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8951d38', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x897cb28', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8973f90', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x87b9840', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x888ea50', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x89471d8', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8927528', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8951708', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8928440', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x888f548', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8818df0', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8951d38', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x897cb28', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8973f90', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x87b9840', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x888ea50', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x89471d8', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8927528', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8951708', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8928440', 9 retries!
Apr 9 17:37:11 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x888f548', 9 retries!
Apr 9 17:37:12 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8818df0', 9 retries!
Apr 9 17:37:12 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8951d38', 9 retries!
Apr 9 17:37:12 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x897cb28', 9 retries!
Apr 9 17:37:12 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8973f90', 9 retries!
Apr 9 17:37:12 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x87b9840', 9 retries!
Apr 9 17:37:12 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x888ea50', 9 retries!
Apr 9 17:37:12 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x89471d8', 9 retries!
Apr 9 17:37:12 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8927528', 9 retries!
Apr 9 17:37:12 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8951708', 9 retries!
Apr 9 17:37:12 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x8928440', 9 retries!
Apr 9 17:37:12 WARNING[25903]: channel.c:780 channel_find_locked: Avoided deadlock for '0x888f548', 9 retries!

# free
total used free shared buffers cached
Mem: 4025132 129588 3895544 0 2452 30024
-/+ buffers/cache: 97112 3928020
Swap: 1044216 0 1044216

# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 32G 2.5G 28G 9% /
/dev/sda1 99M 12M 83M 12% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm

load average: 0.16, 0.12, 0.17

and asterisk log:
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'SIP/PROVIDERIP-088dc1a0'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'SIP/PROVIDERIP-088dc1a0'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'SIP/PROVIDERIP-088dc1a0'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'SIP/PROVIDERIP-088dc1a0'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'SIP/PROVIDERIP-088dc1a0'
Apr 9 17:46:30 WARNING[25903] channel.c: Avoided deadlock for '0x8927528', 9 retries!
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'Local/LEADPHONENUMBER@default-5593,1<ZOMBIE>'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'Local/LEADPHONENUMBER@default-5593,1<ZOMBIE>'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'Local/LEADPHONENUMBER@default-5593,1<ZOMBIE>'
Apr 9 17:46:30 DEBUG[7298] channel.c: Dropping voice to exceptionally long queue on Local/8600054@default-8942,1
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'Local/LEADPHONENUMBER@default-5593,1<ZOMBIE>'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'Local/LEADPHONENUMBER@default-5593,1<ZOMBIE>'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'Local/LEADPHONENUMBER@default-5593,1<ZOMBIE>'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'Local/LEADPHONENUMBER@default-5593,1<ZOMBIE>'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'Local/LEADPHONENUMBER@default-5593,1<ZOMBIE>'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'Local/LEADPHONENUMBER@default-5593,1<ZOMBIE>'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'Local/LEADPHONENUMBER@default-5593,1<ZOMBIE>'
Apr 9 17:46:30 WARNING[25903] channel.c: Avoided deadlock for '0x8951708', 9 retries!
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'SIP/PROVIDERIP-08906838'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'SIP/PROVIDERIP-08906838'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'SIP/PROVIDERIP-08906838'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'SIP/PROVIDERIP-08906838'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'SIP/PROVIDERIP-08906838'
Apr 9 17:46:30 DEBUG[25903] channel.c: Avoiding deadlock for 'SIP/PROVIDERIP-08906838'

I can include a extensions.conf and sip.conf if this will help

by **marcin** » Fri Apr 10, 2009 10:24 am

Well I did one more experiment and install vicidialnow on brand new server. without changing ANY configuration I register one cisco 7960 and x-lite soft phone on new server and deadlock message continue to show in messages:
Apr 7 05:30:27 DEBUG[3722] manager.c: Manager received command 'Command'
Apr 7 05:30:27 DEBUG[3665] chan_sip.c: Setting NAT on RTP to 0
Apr 7 05:30:27 DEBUG[3665] chan_sip.c: Checking SIP call limits for device cc130
Apr 7 05:30:27 DEBUG[3665] chan_sip.c: build_route: Contact hop: <sip:cc130@192.168.1.252:5061>
Apr 7 05:30:27 DEBUG[3653] channel.c: Avoiding initial deadlock for 'SIP/cc130-b7a1a048'
Apr 7 05:30:27 VERBOSE[3970] logger.c: -- Executing Dial("SIP/cc130-b7a1a048", "sip/cc129|20|to") in new stack
Apr 7 05:30:27 DEBUG[3970] chan_sip.c: Setting NAT on RTP to 0
Apr 7 05:30:27 DEBUG[3970] chan_sip.c: Outgoing Call for cc129
Apr 7 05:30:27 VERBOSE[3970] logger.c: -- Called cc129
Apr 7 05:30:28 DEBUG[3665] chan_sip.c: (Provisional) Stopping retransmission (but retaining packet) on '798ca9504ea13afc0d722
4f854086a3c@192.168.1.2' Request 102: Found
Apr 7 05:30:28 DEBUG[3665] chan_sip.c: (Provisional) Stopping retransmission (but retaining packet) on '798ca9504ea13afc0d722
4f854086a3c@192.168.1.2' Request 102: Found
Apr 7 05:30:28 DEBUG[3653] channel.c: Avoiding initial deadlock for 'SIP/cc129-088d35f0'
Apr 7 05:30:28 VERBOSE[3970] logger.c: -- SIP/cc129-088d35f0 is ringing

I even downgrade the cisco sip firmware to 7.4 with same result.

by **williamconley** » Fri Apr 10, 2009 3:06 pm

In this situation, did it make the call? because occasional avoidance of deadlock that does not stop the calls is part of asterisk ... (informational message) whereas attempts to avoid deadlock that do not succeed are an actual problem.

by **marcin** » Fri Apr 10, 2009 4:13 pm

The call was made sucessfully, but every time the sip call is made the 2 deadlocks occurs.

by **okli** » Fri Apr 10, 2009 5:00 pm

Have a look at Matt's response to a similar problem:
http://www.vicidial.org/VICIDIALforum/v ... hp?p=19297

by **williamconley** » Fri Apr 10, 2009 5:17 pm

"occurs" or "is avoided"? read the message ... deadlock avoidance in a normal part of sip call negotiation/handling, there's a system in place to detect "the moment" a deadlock could occur and stop it. if it is avoided, it was a normal call.

if it tries 9 times to avoid it and fails and deadlock occurs ... well, that's a different story.

by **marcin** » Tue Apr 14, 2009 11:25 am

None of these apply:
- recording
We do not do any
- high system load
not with 5-7 agents on this system and total of 4.6 gig ram and 2 3.06 gig of processors, this is not a resource starvation
- insufficient bandwidth
tc400b , g729 codecs, 3M connection dedicated to voip only.
I have also follow the scratch install and with 1.2 version of asterisk I am getting same results:
every call, even from sip phone to sip phone on lan the debug shows "avoided" twice.
will post the outcome when I upgrade to recommended 1.4 version.

by **williamconley** » Tue Apr 14, 2009 12:54 pm

5-7 agents with 8:1 dialing (a low ratio if using broadcast/press one) could peak at 56 calls through the net and a total of up to 64 calls on the server. With g729 for outbound calls, this could create enough of a load to cause an issue; what is your server load?

however, if the calls are succeeding, then there may actually be nothing wrong.

During the negoatiation and routing of a call there are circumstances that COULD cause deadlock (even during a normal call). The detection and avoidance of a possible deadlock is a normal part of call processing. If the calls are succeeding, you may not have anything wrong with your system.

by **marcin** » Tue Apr 21, 2009 8:11 pm

I only use 2:1 ratio and I have resolve the issue with asterisk 1.4 running on slackware 11. g729 is not using any cpu resources, I have tc400b transcoder card installed.
Thank you for all your help.

by **mflorell** » Tue Apr 21, 2009 8:57 pm

What are you using for a zaptel timer?

by **marcin** » Wed Apr 22, 2009 5:06 pm

I have plan to use x100p but it is not supported by the hardware have xpci and tc400p is not a timer source , so I am forced to use ztdummy.
It is not so bad:
Opened pseudo zap interface, measuring accuracy...
99.962791% 99.935356% 99.964653% 99.941895% 99.967194% 99.965034% 99.939262%
99.964752% 99.940422% 99.968361% 99.953415% 99.927536% 99.964539% 99.941200% 99.964951%
99.937996% 99.966988% 99.965034% 99.941612% 99.966309% 99.937210% 99.964928% 99.941887%
99.965927%
--- Results after 24 passes ---
Best: 99.968 -- Worst: 99.928 -- Average: 99.953719, Difference: 99.994978

by **mflorell** » Thu Apr 23, 2009 12:23 am

What was the call load during that zttest run?

Have you looked into trying the Sangoma Voicetime USB timer?

by **marcin** » Thu Apr 23, 2009 12:53 pm

I had 5 agents with 2:1 ratio dial and 10-12 open channels and load average: 0.1-0.15
I will look in to Sangoma Voicetime USB timer.

by **marcin** » Wed Apr 29, 2009 2:00 pm

It turns up as I was wrong. Even with 1.4 version of asterisk, about 6-8 hours in to dialing I run in to a errors what caused asterisk to crash.
I disabled g729 (tc400b) and use only gsm codecs. Success.
The server has been working without any interruptions for over a week.
In the meantime I did open the case with Digium and got respond that they been having lot of problems with stability of tc400b and recommendation was to upgrade asterisk to 1.4.22 or higher and DAHDI to zaptel 1.4.12.1.
Apparently $1200 tc400b card is unable to handle traffic that was design to handle, at least not with any stable versions of asterisk.

vicidial.org

deadlock --RESOLVED--

deadlock --RESOLVED--

Re: deadlock

Resolved

Who is online