vicidial.org

Have any one experienced a call not hanging up? I mean I've seen calls that takes 3 to 4 hours and if you dont restart the asterisk the calls wont even disconnect. any ideas?

What kind of calls?

Where are the calls when they do not hang up?

What is the peak loadavg on this server when these calls are placed?

Asterisk version and astguiclient version?

Are the phones related somewhere else and connect over internet and maybe with very bad connection ?

They are calls from the VICIDIAL to the SIP provider.

I havent had a chance to look at the load average but it never went past 1.50

asterisk 1.2.17 / astguiclient 2.0.3

Do you have any CLI output of one of these calls? or the action_full log entries when that call is attempted to be hung up?

Hi matt
I got same problems. we have 6 seats agent , when do autodialing ,sometimes agent click 'hungup' but voice not be cut eventhough finished disposition.
asterisk 1.2.14
vicidial 2.0.2 .
FC4
mysql4.1
I got action_full log .due to too big how do I post here?
Thanks in advance

mflorell wrote:Do you have any CLI output of one of these calls? or the action_full log entries when that call is attempted to be hung up?

What is the loadavg on the system when this happens?

Does this happen for every call, or just randomly?

Weird, this is also happenning to 2 centers I'm handling. The problem is reproducible.

I logged into the vicidial agent page and did a manual call on this number: 9254275868. The phone kept on ringing and after a few seconds, on the "show conference call channel", another link would appear. Now normally this would appear if the call got connected. However, the phone is still ringing. There should be 3 entries in the "show conference channel" only when the call gets connected. Clicking the "Hangup Customer" link hangs-up the call however, there is still a 2nd entry left in the "show conference call channel" link. On the realtime page, the agent still show as having a call. Manually hanging-up the 2nd entry doesn't change the status on the realtime page. This is happenning w/ only 1 agent logged in.

The campaign is set to "Manual" mode. Here's the asterisk CLI:

xecuting MeetMe("Local/8600051@default-2d18,2", "8600051") in new stack
> Channel Local/8600051@default-2d18,1 was answered.
-- Executing AGI("Local/8600051@default-2d18,1", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing Dial("Local/8600051@default-2d18,1", "SIP/Accela/19254275868|60|Tto") in new stack
-- Called Accela/19254275868
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
-- Executing MeetMe("Local/78600051@default-97c2,2", "8600051|q") in new stack
> Channel Local/78600051@default-97c2,1 was answered.
-- Executing Answer("Local/78600051@default-97c2,1", "") in new stack
-- Executing MixMonitor("Local/78600051@default-97c2,1", "20070928-005108_9254275868_TMSHARE_demian.gsm||/root/move_file.sh 20070928-005108_9254275868_TMSHARE_demian.gsm") in new stack
-- Executing Wait("Local/78600051@default-97c2,1", "3600") in new stack
== Begin MixMonitor Recording Local/78600051@default-97c2,1
-- SIP/Accela-007639c0 is making progress passing it to Local/8600051@default-2d18,1
== Manager 'sendcron' logged off from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Spawn extension (default, 8600051, 1) exited non-zero on 'Local/8600051@default-2d18,2'
-- Executing DeadAGI("Local/8600051@default-2d18,2", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing DeadAGI("Local/8600051@default-2d18,2", "agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0---------------)") in new stack
-- AGI Script agi://127.0.0.1:4577/VD_hangup--HVcause ... ----------) completed, returning 0
== Spawn extension (default, 919254275868, 2) exited non-zero on 'Local/8600051@default-2d18,1'
-- Executing DeadAGI("Local/8600051@default-2d18,1", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing DeadAGI("Local/8600051@default-2d18,1", "agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------)") in new stack
-- AGI Script agi://127.0.0.1:4577/VD_hangup--HVcause ... ----------) completed, returning 0
== Manager 'sendcron' logged off from 127.0.0.1
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
-- Saved useragent "X-Lite release 1006e stamp 34025" for peer 2001
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
-- Executing MeetMe("Local/8600051@default-908a,2", "8600051") in new stack
> Channel Local/8600051@default-908a,1 was answered.
-- Executing AGI("Local/8600051@default-908a,1", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing Dial("Local/8600051@default-908a,1", "SIP/Accela/12062136815|60|Tto") in new stack
-- Called Accela/12062136815
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
-- Executing MeetMe("Local/78600051@default-94f0,2", "8600051|q") in new stack
> Channel Local/78600051@default-94f0,1 was answered.
-- Executing Answer("Local/78600051@default-94f0,1", "") in new stack
-- Executing MixMonitor("Local/78600051@default-94f0,1", "20070928-005248_2062136815_TMSHARE_demian.gsm||/root/move_file.sh 20070928-005248_2062136815_TMSHARE_demian.gsm") in new stack
-- Executing Wait("Local/78600051@default-94f0,1", "3600") in new stack
== Begin MixMonitor Recording Local/78600051@default-94f0,1
== Manager 'sendcron' logged off from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
-- SIP/Accela-007639c0 is making progress passing it to Local/8600051@default-908a,1
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Spawn extension (default, 8600051, 1) exited non-zero on 'Local/8600051@default-908a,2'
-- Executing DeadAGI("Local/8600051@default-908a,2", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing DeadAGI("Local/8600051@default-908a,2", "agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0---------------)") in new stack
-- AGI Script agi://127.0.0.1:4577/VD_hangup--HVcause ... ----------) completed, returning 0
== Spawn extension (default, 912062136815, 2) exited non-zero on 'Local/8600051@default-908a,1'
-- Executing DeadAGI("Local/8600051@default-908a,1", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing DeadAGI("Local/8600051@default-908a,1", "agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------)") in new stack
-- AGI Script agi://127.0.0.1:4577/VD_hangup--HVcause ... ----------) completed, returning 0

The 2nd entry on the "show conference call channel" link needs to be manually hangup before proceeding to the next call.

Another thing I encountered is when doing manual calls, when I click "Hangup Customer" link while the call hasn't been connected yet, the disposition screen doesn't show up. I'm stuck on the agent page w/ no way to make the next call except to logout and login back again.

I would recommend upgrading to 2.0.3, not sure if it will fix your problem, but I know if fixes a lot of similar problems.

I'm using 2.0.3. This happens when the campaign is set to Manual Dial. Setting it to Auto Dial and disabling the leads reduces those problems. However, the problem still exists.

What is the loadavg on the Asteirsk server and the DB server when this happens?

Have you tried a different carrier?

Load average on both server is insignificant since I'm testing this w/ only 1 agent. I'm also thinking that this has something to do w/ my carrier. I can't test this w/ other carriers since most of the centers I handle use the same provider.

One of the most persistent issue I noticed is that when the campaign is set to manual dial, vicidial doesn't automatically disconnect the necessary channels (in "show call conference" - Local/78600051@default-5414) when the agent clicks the hangup link while the call is not completed. If I'm not mistaken, this is the one handling the meetme recordings. Now the agent's don't know this so they just continue dialing manually and this keeps piling up until vicidial behaves improperly and they are forced to logout. Running "show channels" in the asterisk cli when all agents are already logged-out show:

Channel Location State Application(Data)
Local/8600061@defaul 8600061@default:1 Up MeetMe(8600061)
Local/8600061@defaul 914082620920@default Up Congestion()
Local/8600057@defaul 8600057@default:1 Up MeetMe(8600057)
Local/8600057@defaul 914089378971@default Up Congestion()
Local/8600061@defaul 8600061@default:1 Up MeetMe(8600061)
Local/8600061@defaul 919169236323@default Up Congestion()
Zap/pseudo-296010848 s@unused:1 Rsrvd (None)
Local/8600061@defaul 8600061@default:1 Up MeetMe(8600061)
Local/8600061@defaul 919167865192@default Up Congestion()
Local/8600061@defaul 8600061@default:1 Up MeetMe(8600061)
Local/8600061@defaul 919166490751@default Up Congestion()
Local/8600061@defaul 8600061@default:1 Up MeetMe(8600061)
Local/8600061@defaul 915102529508@default Up Congestion()
Zap/pseudo-130808960 s@unused:1 Rsrvd (None)
14 active channels
12 active calls

This is no longer related to my voip carrier.

Ah Ha!

Congestion is your problem, replace it in your dialplan with Hangup()

It seems that somewhere in Asterisk 1.2 releases they changed the behavour of Congestion() so that it doesn't always hangup the call.

Removed "Congestion ()". Seems that they must have really changed something. Let me do some more tests and see if this resolves the issue.

I had this issue when I installed 2.0.3, the Hangup() -> Congestion() did decrease it, but I experienced it happened as the system was utilized more and more. So the systems degraded with time.

What we noticed was the directories were incorrect in the recording and it was causing the load to peak at times ... way high.

I would guess this problem may be a combination of the two.

Changing Congestion to Hangup did decrease some of the problems. However, we're still encountering calls not hanging up properly. The issue is still the same. On Manual mode, when the agent click the Hangup link before the call connects, not all of the channels are disconnected. This results to multiple channels showing on their "show call conference" link.