vicidial.org

I have big problems with vicidial. As mentioned in another thread sometimes the customer line is hangup. Agent calls customer with vicidial (manual dialing, no auto dial), speaks to customer, but then it seems the customer hang up. It seems the line is hangup by the other end, but the customer didn't hang up (nobody hangs up in the middle of speaking a sentence - we called back some customers and they definitively didn't hang up). Two times all customers were lost today. So all channels hang up.

Another issue: Agent calls customer. It rings. Nobody pick up the phone, so agent clicked "Hangup". But the line didn't hang up. So agent clicked "hang up again" in the review screen with the status codes. But it doesn't stop ringing. Agent logs out and in again, but it still rings.

Next issue: Agent calls customer and selects status "Not interested". Some minutes after that another agent has the customer on his screen for calling. Vicidial moved the customer to vicidial_hopper again, but there is no Dial status "Not interested" selected in the campaign. So it shouldn't dial it. Only leads with Dial status "New" should be called.

And one other issue: In vicidial admin I looked to the active list for the current campaign. The row "Called" with status "New" increases! It is normal for culumn "Not called" in row "New" to decrease, but the other way around it is frightening me.

In the morning I had campaign recording to "Allcalls". In the afternoon I switched it to "Never". But nothing changed except loadavg, we had the same issues. As I wrote the Auto Dial Level is Zero. Today we had 14 agents in vicidial, but there is no difference to working with 10 agents. The loadavg is between 0.7 to 3.0 on Asterisk server, normally something around 1.2. Asterisk on a dual-core Xeon with 64 bit Debian, Apache and MySQL on another server with dual-core Pentium 4. Both servers with 2 GB memory each.

Any help? Any way to solve it without reinstall the whole system?

What kind of outside lines are you using? Who is your carrier?

We have had horrible problems with a carrier through a PRI dropping random calls, call congestion and disconnect notices on non-disconnected numbers. We dropped the carrier and haven't had those issues with the new carrier.

What is the loadavg on your Database server when this happens?

Do you ever use the "CALLS IN THIS SESSION" link at the bottom of the vicidial.php screen to try to hangup calls?

For the NOT INTERESTED issue please post all vicidial_log entries for that lead along with the vicidial_list entry.

The NEW leads increasing in count, I would have no idea how that would be happening. Are you saying that if you have 100 NEW and 100 NA leads that you will then see 150 NEW and 50 NA leads the next day?

Are you using an SMP kernel of Linux?

mflorell wrote:What kind of outside lines are you using? Who is your carrier?

COLT Telecom in Switzerland. Today I called a technican, they want to switch to another carrier (whatever that means). He told me 5 different causes for the lost customers: 1. Customer pressed hold, after some time the line was disconnected 2. Customer hang up normally 3. Carrier hang up (and I wonder why) 4. Agent on vicidial hang up normally 5. Asterisk hang up (he mentioned "local network")

mflorell wrote:What is the loadavg on your Database server when this happens?

The database server with Apache on it is bored the whole time. I do not know the load at the "crash", but the loadavg is mostly 0.3 to 0.7.

mflorell wrote:Do you ever use the "CALLS IN THIS SESSION" link at the bottom of the vicidial.php screen to try to hangup calls?

No.

mflorell wrote:For the NOT INTERESTED issue please post all vicidial_log entries for that lead along with the vicidial_list entry.

At the moment I did not find that entry, but here is the same problem: Agent called customer two times. 1779 is a custom status in the campaign, it means "Not interested".

vicidial_agent_log:
28069 103 192.168.1.10 2006-07-26 09:34:01 42870 ECO 1153899241 0 1153899247 6 1153899591 344 1153899634 43 1779
29900 103 192.168.1.10 2006-07-26 13:22:03 42870 ECO 1153912923 0 1153912991 68 1153913067 76 1153913076 9 1779

vicidial_log:
1153899244.1377299 42870 20 ECO 2006-07-26 09:34:07 1153899247 1153899591 344 1779 41 62295XXXX 103 MANUAL N
1153912988.5603001 42870 20 ECO 2006-07-26 13:23:11 1153912991 1153913067 76 1779 41 62295XXXX 103 MANUAL N

vicidial_list:
lead_id: 42870, entry_date: 2006-07-20 14:30:41, modify_date: 2006-07-26 13:24:36, status: 1779, user: 103, vendor_lead_code: 54043641, source_id: 210238, list_id: 20, gmt_offset_now: 2.00, called_since_last_reset: Y, phone_code: 41, phone_number: 62295XXXX , title: Herr, first_name: Stefan, middle_initial: , last_name: XXXXX, address1: Any street 24, address2: , address3, city: Starrkirch-Wil, state: , province: , postal_code: 4656, country_code: 41 , gender: M, date_of_birth: 1984-01-01, alt_phone: , email: , security_phrase comments: , called_count: 2

mflorell wrote:The NEW leads increasing in count, I would have no idea how that would be happening. Are you saying that if you have 100 NEW and 100 NA leads that you will then see 150 NEW and 50 NA leads the next day?

Are you using an SMP kernel of Linux?

I have to look at it. I do not know which number decreases when "NEW Called" increases. But there is a user in vicidial_list. Is it possible the agent clicks "Lead preview" and then "Skip"? That would explain the agent number in the column user.

Is it possible that the audio between Asterisk and Agent is not transferred for some seconds? Or meetme stops working for some seconds? So Customer does not hear anything and hangs up. Agent don't hear customer and thinks the customer has hung up. That would explain some things. Agents are on idefisk (IAX).
Asterisk is 1.2.10

What kind of outside lines do you use? (VOIP or E1/T1/BRI)

As for the audio pauses I suppose it is possible, do you see any WARNINGs, NOTICEs or ERRORs on the Asterisk CLI output when you have full debugging turned on?

Outside lines are E1.
Yesterday I had
WARNING[8407]: app_meetme.c:1524 conf_run: Unable to write frame to channel: Resource temporarily unavailable
This line I had many many times in my Asterisk CLI. But at the crash yesterday I did not see such lines. I will search for some messages ...

I just received a recording of a call. It rings 5 Seconds. Agent speaks to customer. After 1 minute and 23 seconds there is a short break of one seconds, I hear noting. Then the agent is back and speaking, but the customer is away. At 2 minutes 59 seconds I hear the "bing" sound (anyone leaves the meetme room). Some seconds later the agent clicks hangup and the recording is ended.
call_log: start time 2006-07-27 14:52:55, end time 2006-07-27 14:55:59, length in seconds: 184
agent_log: wait_sec: 4, talk_sec: 227
vicidial_log: length_in_sec: 227, Comments: manual, processed: N

Asterisk CDR: Start 14:53:03, length 184, billsec 177

gschaller,

Your NEW "CALLED" leads incrementing is probably due to all channels being used. Have you defined the max available channels in the astguiclient/admin.php "under MAX VICIDIAL TRUNKS" If you do not define this and it tries to call as many lines as your dial level requires.

If you have insufficient lines those "NEW" leads will be considered "CALLED" you can reset the list and have them all go back to "NOT CALLED"

-enjay

Yes, max vicidial trunks is defined (60, there are two E1 lines). But we are using manual dialing (auto dial level is 0), so I think it does not matter.

I found something in Asterisk messages log. The time is definetly the second with silence in the recording. After these second of silence the customer was away. The zap channel was not hung up at this time, the agent hung it up later in vicidial with button "Hangup Customer". Agent was in meetme room 8600056.
Jul 27 14:54:24 DEBUG[5048] channel.c: Avoiding deadlock for 'Local/8600056@default-b358,2'
Jul 27 14:54:24 DEBUG[5048] channel.c: Avoiding deadlock for 'Local/8600056@default-b358,2'
Jul 27 14:54:24 DEBUG[5048] channel.c: Avoiding deadlock for 'Local/8600056@default-b358,2'
Jul 27 14:54:24 DEBUG[5048] channel.c: Avoiding deadlock for 'Local/8600056@default-b358,2'
Jul 27 14:54:24 DEBUG[5048] channel.c: Avoiding deadlock for 'Local/8600056@default-b358,2'
Jul 27 14:54:24 DEBUG[5048] channel.c: Avoiding deadlock for 'Local/8600056@default-b358,2'
Jul 27 14:54:24 DEBUG[5048] channel.c: Avoiding deadlock for 'Local/8600056@default-b358,1'
Google does not help very much. Matt, any comments to this messages? Some more information to the system: Debian 64 bit. Cause Debian do not use GCC 3.4 I had to set "PROC=athlon" in the Asterisk Makefile. And I only changed Asterisk Makefile. Zaptel compiled fine without changes. I hope thats not the reason....

What kind of zaptel card are you using?

How much concurrent recording are you doing?

What kind of hard drives are in this server?

Digium TE210P
Yesterday I had 8 agents in vicidial and another 2-3 persons with SIP phones outside vicidial. Recording was set to "ALLCALLS", so 8 concurrenct recordings. Switching it to "Never" doesn't help, the same issues. Tried that a day before.
Two SATA drives 80 GB. Second drive is standby at the moment.

The avoiding deadlock issue when you are recording with Zap channels usually means that the drives or computer cannot keep up with the writing of the recording files. Since your load is not crazy I would guess that running everything off of a single SATA drive is causing the problem. I would recommend first trying to use your second SATA drive to record onto (/var/log/asterisk/monitor as a mount point) and second I would recommend trying to record in the GSM format instead of WAV. See if either of those help.

Ok, I reconfigured my system. Now recordings will be on the second SATA drive. I hope it will work better the next days.

Just some lines of Asterisk messages log. At this time all agents lost their customers (I filtered out the lines with "deadlock"):

Jul 28 14:50:50 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600054@default-0393,2'
Jul 28 14:50:50 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/1-1'
Jul 28 14:50:50 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600054@default-edc0,2'
Jul 28 14:50:51 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600051@default-d2f6,2'
Jul 28 14:50:51 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/1-1'
Jul 28 14:50:52 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600051@default-1e70,2'
Jul 28 14:50:53 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/1-1'
Jul 28 14:50:54 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600053@default-ab7d,2'
Jul 28 14:50:54 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600053@default-ab7d,2'
Jul 28 14:50:55 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600053@default-ef3d,2'
Jul 28 14:50:56 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/3-1'
Jul 28 14:50:59 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600054@default-5cea,2'
Jul 28 14:50:59 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600054@default-5cea,2'
Jul 28 14:50:59 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600054@default-5cea,2'
Jul 28 14:50:59 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600054@default-5cea,2'
Jul 28 14:50:59 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600054@default-5cea,2'
Jul 28 14:50:59 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600054@default-5cea,2'
Jul 28 14:50:59 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/7-1'
Jul 28 14:51:01 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600054@default-86da,2'
Jul 28 14:51:03 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/6-1'
Jul 28 14:51:05 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600056@default-2059,2'
Jul 28 14:51:05 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/8-1'
Jul 28 14:51:06 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600056@default-6d65,2'
Jul 28 14:51:06 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/8-1'
Jul 28 14:51:15 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600052@default-5b9f,2'
Jul 28 14:51:15 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600052@default-c400,2'
Jul 28 14:51:22 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/8-1'
Jul 28 14:51:23 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600052@default-a66b,2'
Jul 28 14:51:24 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/1-1'
Jul 28 14:51:24 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600052@default-7eec,2'
Jul 28 14:51:25 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/4-1'
Jul 28 14:51:29 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600054@default-e38f,2'
Jul 28 14:51:29 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600054@default-226f,2'
Jul 28 14:51:30 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/1-1'
Jul 28 14:51:36 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600051@default-79e1,2'
Jul 28 14:51:36 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/1-1'
Jul 28 14:51:36 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600051@default-b078,2'
Jul 28 14:51:37 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/1-1'
Jul 28 14:51:38 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600053@default-5143,2'
Jul 28 14:51:38 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600053@default-5143,2'
Jul 28 14:51:38 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600053@default-92fc,2'
Jul 28 14:51:38 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600053@default-92fc,2'
Jul 28 14:51:39 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600054@default-238e,2'
Jul 28 14:51:58 DEBUG[6997] channel.c: Avoiding deadlock for 'Local/78600052@default-7eec,2'
Jul 28 14:51:58 DEBUG[6997] channel.c: Avoiding deadlock for 'Local/8600055@default-8ed9,2'
Jul 28 14:51:58 DEBUG[6997] channel.c: Avoiding deadlock for 'Local/8600055@default-8ed9,2'
Jul 28 14:51:58 DEBUG[6997] channel.c: Avoiding deadlock for 'Local/8600055@default-8ed9,2'
Jul 28 14:51:58 DEBUG[6997] channel.c: Avoiding deadlock for 'Local/8600055@default-8ed9,2'
Jul 28 14:51:58 DEBUG[6997] channel.c: Avoiding deadlock for 'Local/8600055@default-8ed9,2'
Jul 28 14:51:58 DEBUG[6997] channel.c: Avoiding deadlock for 'Local/8600055@default-8ed9,2'
Jul 28 14:51:58 DEBUG[6997] channel.c: Avoiding deadlock for 'Local/8600055@default-8ed9,2'
Jul 28 14:51:58 DEBUG[6997] channel.c: Avoiding deadlock for 'Local/8600055@default-8ed9,2'
Jul 28 14:51:58 DEBUG[6997] channel.c: Avoiding deadlock for 'Local/8600055@default-8ed9,2'
Jul 28 14:51:58 DEBUG[6997] channel.c: Avoiding deadlock for 'Local/8600055@default-8ed9,2'
Jul 28 14:51:58 WARNING[6997] channel.c: Avoided deadlock for '0x705ac0', 10 retries!
Jul 28 14:51:58 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/6-1'
Jul 28 14:51:58 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600054@default-1a5a,2'
Jul 28 14:51:58 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600058@default-943b,2'
Jul 28 14:51:58 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600058@default-943b,2'
Jul 28 14:51:58 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600058@default-44b4,2'
Jul 28 14:52:00 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600053@default-6292,2'
Jul 28 14:52:00 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600053@default-b0b5,2'
Jul 28 14:52:00 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600053@default-b0b5,2'
Jul 28 14:52:07 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/8600051@default-75f5,2'
Jul 28 14:52:07 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Zap/1-1'
Jul 28 14:52:07 DEBUG[31858] channel.c: Avoiding initial deadlock for 'Local/78600051@default-87b4,2'

Is that a timing issue?

Shouldn't have anything to do with timers, in my experience those are only cause by bad VOIP bandwidth to the outside lines or agents or not enough throughput to the recording device (the recording hard drive).

Since these are mostly Local/ channels I would bet this is a recording issue.

Try running with recordings off and see if you get those warnings.

Here a part of Asterisk log when calling out with IDEfisk (so no vicidial). I ring a number and hang up:

Code: Select all

Jul 31 07:41:33 DEBUG[20692] acl.c: ##### Testing 217.84.22.XX with 0.0.0.0
Jul 31 07:41:33 VERBOSE[20692] logger.c:     -- Accepting AUTHENTICATED call from 217.84.22.XX:
       > requested format = gsm,
       > requested prefs = (),
       > actual format = gsm,
       > host prefs = (gsm),
       > priority = mine
Jul 31 07:41:33 VERBOSE[25986] logger.c:     -- Executing AGI("IAX2/1999-4", "call_log.agi|0049170827XXXX") in new stack
Jul 31 07:41:33 VERBOSE[25986] logger.c:     -- Launched AGI Script /var/lib/asterisk/agi-bin/call_log.a
gi
Jul 31 07:41:33 VERBOSE[25986] logger.c:     -- AGI Script call_log.agi completed, returning 0
Jul 31 07:41:33 VERBOSE[25986] logger.c:     -- Executing Dial("IAX2/1999-4", "ZAP/g1/0049170827XXXX||tT
o") in new stack
Jul 31 07:41:33 VERBOSE[25986] logger.c:     -- Requested transfer capability: 0x00 - SPEECH
Jul 31 07:41:33 DEBUG[20685] channel.c: Avoiding initial deadlock for 'Zap/1-1'
Jul 31 07:41:33 VERBOSE[25986] logger.c:     -- Called g1/0049170827XXXX
Jul 31 07:41:33 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:34 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:34 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:35 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:35 DEBUG[20697] chan_zap.c: Queuing frame from PRI_EVENT_PROCEEDING on channel 0/1 span 1
Jul 31 07:41:35 VERBOSE[25986] logger.c:     -- Zap/1-1 is proceeding passing it to IAX2/1999-4
Jul 31 07:41:35 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:36 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:36 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:37 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:37 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:37 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:38 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:38 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:39 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:39 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:40 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:40 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:41 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:41 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:42 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:42 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:42 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:43 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:43 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:44 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:44 DEBUG[20697] chan_zap.c: Enabled echo cancellation on channel 1
Jul 31 07:41:44 DEBUG[20685] channel.c: Avoiding initial deadlock for 'Zap/1-1'
Jul 31 07:41:44 VERBOSE[25986] logger.c:     -- Zap/1-1 is ringing
Jul 31 07:41:44 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:45 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:45 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:46 DEBUG[20781] manager.c: Manager received command 'Command'
Jul 31 07:41:46 DEBUG[20692] chan_iax2.c: Immediately destroying 4, having received hangup
Jul 31 07:41:46 DEBUG[25986] chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/1-1
Jul 31 07:41:46 DEBUG[25986] chan_zap.c: Hangup: channel: 1 index = 0, normal = 19, callwait = -1, third
call = -1
Jul 31 07:41:46 DEBUG[25986] chan_zap.c: Not yet hungup...  Calling hangup once with icause, and clearin
g call
Jul 31 07:41:46 DEBUG[25986] chan_zap.c: disabled echo cancellation on channel 1
Jul 31 07:41:46 DEBUG[25986] chan_zap.c: Set option TDD MODE, value: OFF(0) on Zap/1-1
Jul 31 07:41:46 DEBUG[25986] chan_zap.c: Updated conferencing on 1, with 0 conference users
Jul 31 07:41:46 DEBUG[25986] chan_zap.c: Set option AUDIO MODE, value: OFF(0) on Zap/1-1
Jul 31 07:41:46 DEBUG[25986] chan_zap.c: disabled echo cancellation on channel 1
Jul 31 07:41:46 VERBOSE[25986] logger.c:     -- Hungup 'Zap/1-1'
Jul 31 07:41:46 DEBUG[25986] app_dial.c: Exiting with DIALSTATUS=CANCEL.
Jul 31 07:41:46 VERBOSE[25986] logger.c:   == Spawn extension (default, 0049170827XXXX, 2) exited non-ze
ro on 'IAX2/1999-4'
Jul 31 07:41:46 VERBOSE[25986] logger.c:     -- Executing DeadAGI("IAX2/1999-4", "call_log.agi|h") in ne
w stack
Jul 31 07:41:46 VERBOSE[25986] logger.c:     -- Launched AGI Script /var/lib/asterisk/agi-bin/call_log.a
gi
Jul 31 07:41:46 VERBOSE[25986] logger.c:     -- AGI Script call_log.agi completed, returning 0
Jul 31 07:41:46 VERBOSE[25986] logger.c:     -- Executing DeadAGI("IAX2/1999-4", "VD_hangup.agi|h") in n
ew stack
Jul 31 07:41:46 VERBOSE[25986] logger.c:     -- Launched AGI Script /var/lib/asterisk/agi-bin/VD_hangup.
agi
Jul 31 07:41:46 VERBOSE[25986] logger.c:     -- AGI Script VD_hangup.agi completed, returning 0
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is '"Test-Agent" <1999>'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is '1999'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is '0049170827XXXX'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is 'default'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is 'IAX2/1999-4'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is 'Zap/1-1'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is 'DeadAGI'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is 'VD_hangup.agi|h'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is '2006-07-31 07:41:33'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is '(null)'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is '2006-07-31 07:41:46'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is '13'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is '0'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is 'NO ANSWER'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is 'DOCUMENTATION'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is '1999'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is '1154324493.12'
Jul 31 07:41:46 DEBUG[25986] pbx.c: Function result is '(null)'
Jul 31 07:41:46 DEBUG[25986] chan_iax2.c: We're hanging up IAX2/1999-4 now...
Jul 31 07:41:46 DEBUG[25986] chan_iax2.c: Really destroying IAX2/1999-4 now...
Jul 31 07:41:46 VERBOSE[25986] logger.c:     -- Hungup 'IAX2/1999-4'



The "initial deadlock" line appears after Dial command and after anabling echo cancellation. No recording, meetme or vicidial except agi's here. But I will try with recording=never today.

This is with recording in gsm format, 11 agents in manual dialing mode. Recording is done on sdb. Without recording it is the same except sdb.

Code: Select all

asterisk01:/# iostat
Linux 2.6.16 (asterisk01)       31.07.2006

avg-cpu:  %user   %nice    %sys %iowait   %idle
           1.92    0.59    1.15    0.07   96.26

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               4.23        20.11       126.11    7967698   49972272
sdb               0.09         0.01        10.05       2304    3984154


What about screenlog.0? Can I stop the logging or is it needed?

I just read http://www.digium.com/en/docs/misc/comp ... _notes.php There is a note about Intel e1000 ethernet controller at the end of the side. There is such a network controller in the Asterisk server. I will try to disable it and use another PCI based card.

I have 4 servers with the e1000 Intel Ethernet chipset in them and active with Digium cards. Never had a problem with them.