vicidial.org

by **DomeDan** » Fri Jul 08, 2011 5:33 am

I have been looking more deeply in whats happening when calls are being made from asterisk
and found that call that gets a dialstatus: CONGESTION or CANCEL (cause 1 or 0) will still be in mysql-table: vicidial_auto_calls as status SENT
and thous prevent the system from dialing an other number.
Dial timeout is set to 40 sec in my campaigns.
A call can get dialstatus CONGESTION a few seconds after asterisk started ringing but still will be in vicidial_auto_calls about 50 seconds.
I would like to optimize the system to end those calls faster. Does anyone know what to do?

I will show an example on a call that gets dialstatus CONGESTION.
first in vicidial_auto_calls (Not exactly from that table, but its the source for the data)

Code: Select all: +---------------------+---------+------+--------------+--------+--------+-------------------+ | call_time | lead_id | code | phone_number | status | length | status_text | +---------------------+---------+------+--------------+--------+--------+-------------------+ | 2011-07-07 13:52:59 | 159091 | 0047 | 11111111 | SENT | 6 | Call being placed | +---------------------+---------+------+--------------+--------+--------+-------------------+

At the same time the length is 6 sec, this is how vicidial_carrier_log looks like:

Code: Select all: +---------------------+----------+--------+------------+-----------+ | call_date | lead_id | cause | dialstatus | dial_time | +---------------------+----------+--------+------------+-----------+ | 2011-07-07 13:53:01 | 159091 | 1 | CONGESTION | 0 | +---------------------+----------+--------+------------+-----------+

I dont know technically what cause 1 and CONGESTION is, but i see a lot of them. (I found this info http://networking.ringofsaturn.com/Rout ... ecodes.php on an other topic in this forum, and that is all i know)
here is vicidial_log:

Code: Select all: +-----------------+---------+---------+-------------+---------------------+-------------+------------+---------------+--------+------------+--------------+------+----------+-----------+------------+-------------+----------+ | uniqueid | lead_id | list_id | campaign_id | call_date | start_epoch | end_epoch | length_in_sec | status | phone_code | phone_number | user | comments | processed | user_group | term_reason | alt_dial | +-----------------+---------+---------+-------------+---------------------+-------------+------------+---------------+--------+------------+--------------+------+----------+-----------+------------+-------------+----------+ | 1310039579.5833 | 159091 | 1005 | A_CAMP | 2011-07-07 13:53:53 | 1310039633 | 1310039633 | 0 | NA | 0047 | 11111111 | VDAD | NULL | N | NULL | NONE | NONE | +-----------------+---------+---------+-------------+---------------------+-------------+------------+---------------+--------+------------+--------------+------+----------+-----------+------------+-------------+----------+

and here is call_log:

Code: Select all: +-----------------+------------------------------------+--------------------+---------+-----------------+---------------+-----------------+----------------------+---------------------+-------------+---------------------+------------+---------------+ | uniqueid | channel | channel_group | type | server_ip | extension | number_dialed | caller_code | start_time | start_epoch | end_time | end_epoch | length_in_sec | +-----------------+------------------------------------+--------------------+---------+-----------------+---------------+-----------------+----------------------+---------------------+-------------+---------------------+------------+---------------+ | 1310039579.5833 | Local/9004711111111@default-baf2,2 | Local Channel Line | Local | 111.111.111.111 | 9004711111111 | 9004711111111 | V7071352590000159091 | 2011-07-07 13:52:59 | 1310039579 | 2011-07-07 13:53:01 | 1310039581 | 2 | +-----------------+------------------------------------+--------------------+---------+-----------------+---------------+-----------------+----------------------+---------------------+-------------+---------------------+------------+---------------+

here is asterisk log /var/log/asterisk/messages

Code: Select all: [Jul 7 13:52:59] VERBOSE[21244] logger.c: [Jul 7 13:52:59] -- Executing [9004711111111@default:1] AGI("Local/9004711111111@default-baf2,2", "agi://127.0.0.1:4577/call_log") in new stack [Jul 7 13:52:59] VERBOSE[21244] logger.c: [Jul 7 13:52:59] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0 [Jul 7 13:52:59] VERBOSE[21244] logger.c: [Jul 7 13:52:59] -- Executing [9004711111111@default:2] Dial("Local/9004711111111@default-baf2,2", "SIP/tele2carrier/004711111111||tTor") in new stack [Jul 7 13:52:59] VERBOSE[21244] logger.c: [Jul 7 13:52:59] -- Called tele2carrier/004711111111 [Jul 7 13:52:59] VERBOSE[21248] logger.c: [Jul 7 13:52:59] -- Executing [9004722222222@default:1] AGI("Local/9004722222222@default-e5dc,2", "agi://127.0.0.1:4577/call_log") in new stack [Jul 7 13:52:59] VERBOSE[21248] logger.c: [Jul 7 13:52:59] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0 [Jul 7 13:52:59] VERBOSE[21246] logger.c: [Jul 7 13:52:59] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0 [Jul 7 13:52:59] VERBOSE[21248] logger.c: [Jul 7 13:52:59] -- Executing [9004722222222@default:2] Dial("Local/9004722222222@default-e5dc,2", "SIP/tele2carrier/004722222222||tTor") in new stack [Jul 7 13:52:59] VERBOSE[21246] logger.c: [Jul 7 13:52:59] -- Executing [9004733333333@default:2] Dial("Local/9004733333333@default-a368,2", "SIP/tele2carrier/004733333333||tTor") in new stack [Jul 7 13:52:59] VERBOSE[21248] logger.c: [Jul 7 13:52:59] -- Called tele2carrier/004722222222 [Jul 7 13:52:59] VERBOSE[21246] logger.c: [Jul 7 13:52:59] -- Called tele2carrier/004733333333 [Jul 7 13:53:01] VERBOSE[21233] logger.c: [Jul 7 13:53:01] -- SIP/tele2carrier-00000658 is ringing [Jul 7 13:53:01] VERBOSE[21246] logger.c: [Jul 7 13:53:01] -- SIP/tele2carrier-0000065c is ringing [Jul 7 13:53:01] VERBOSE[21244] logger.c: [Jul 7 13:53:01] -- SIP/tele2carrier-0000065a is circuit-busy [Jul 7 13:53:01] VERBOSE[21244] logger.c: [Jul 7 13:53:01] == Everyone is busy/congested at this time (1:0/1/0) [Jul 7 13:53:01] VERBOSE[21244] logger.c: [Jul 7 13:53:01] -- Executing [9004711111111@default:3] Hangup("Local/9004711111111@default-baf2,2", "") in new stack [Jul 7 13:53:01] VERBOSE[21244] logger.c: [Jul 7 13:53:01] == Spawn extension (default, 9004711111111, 3) exited non-zero on 'Local/9004711111111@default-baf2,2' [Jul 7 13:53:01] VERBOSE[21244] logger.c: [Jul 7 13:53:01] -- Executing [h@default:1] DeadAGI("Local/9004711111111@default-baf2,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----1-----CONGESTION----------") in new stack

it hangs up after 1 sec, so why does it take about 50 sec before it continue on a other phone number?

here is the last log, and there you can see its deleted 54 seconds after asterisk started to dial /var/log/astguiclient/vdautodial.2011-07-07:

Code: Select all: 2011-07-07 13:53:53||SELECT auto_alt_dial,auto_alt_dial_statuses,use_internal_dnc,use_campaign_dnc FROM vicidial_campaigns where campaign_id='A_CAMP';|NONE| B N NA DC -|NA|167837|NONE| 2011-07-07 13:53:53|| dead call vac deleted|1576|159091|V7071352590000159091|1310039581|1||OUT|40|5|45|2|47|0E0|| 2011-07-07 13:53:53||SELECT result FROM vicidial_cpd_log where callerid='V7071352590000159091' order by cpd_id desc limit 1;|| 2011-07-07 13:53:53||SELECT list_id from vicidial_list where lead_id='159091' limit 1;|| 2011-07-07 13:53:53|| dead NA call added to log 1310039579.5833|159091|11111111|SENT|NA|1|0| 2011-07-07 13:53:53|| dead call vac lead marked NA|159091|11111111|SENT|| 2011-07-07 13:53:53||SELECT auto_alt_dial,auto_alt_dial_statuses,use_internal_dnc,use_campaign_dnc FROM vicidial_campaigns where campaign_id='A_CAMP';|NONE| B N NA DC -|NA|159091|NONE| 2011-07-07 13:53:53|| dead call vac deleted|1574|161536|V7071352590000161536|1310039619|1||OUT|40|5|45|40|47|0E0||

Maybe you need my carrier information, Account Entry:
[tele2carrier]
disallow=all
allow=ulaw
allow=alaw
allow=gsm
type=friend
username=XXXXXXXXXX
secret=XXXXXXXXXX
host=sip-corporate.tele2.se
dtmfmode=rfc2833
context=trunkinbound
insecure=invite

Globals String: TELE2SIPTRUNK = SIP/tele2carrier

Dialplan Entry:
exten => _90047XXXXXX.,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _90047XXXXXX.,2,Dial(${TELE2SIPTRUNK}/${EXTEN:1},,tTor)
exten => _90047XXXXXX.,3,Hangup

Notes:
its the same thing with dialstatus CANCEL, about 54 seconds before an other phone number is called, but it wont get the dialstatus before the dial timeout is reached
I tried to manually call a phone number that got dialstatus CONGESTION and I hear one regular signal and then the busy signal starts beeping

by **williamconley** » Fri Jul 08, 2011 7:59 am

congestion is your carrier rejecting the call. either because they don't like something about your method of implementing it or there is a problem calling the number (for instance: you are allowed 10 channels, but you are initiating a call on channel 11, which is being rejected) or because your carrier cannot handle the traffic (they sell you minutes at 1.2cents and that particular number is a 1.3cents per minute call so they don't want to lose money and simply reject the call OR they do not have enough channels available in THEIR upline).

by **DomeDan** » Fri Jul 08, 2011 8:29 am

Ok, thank you for the reply!
I'm gonna check with my sip-provider whats causing the problem.
But the main question remains,
how can i prevent the congestion calls from stopping the system to call an other number in 50 seconds?
This is a small call-center so there can be a lot of waiting for the agents.

by **williamconley** » Fri Jul 08, 2011 11:14 pm

Experiment with your drop call seconds and Dial Timeout. Try setting Dial Timeout to something between 15 and 25 and drop seconds to 0 or 1 to see either that reduces your wait time.

by **Michael_N** » Sat Jul 09, 2011 7:20 am

Have you looked at this tread?

http://www.vicidial.org/VICIDIALforum/v ... congestion

by **DomeDan** » Mon Jul 18, 2011 5:13 am

Thank you for that link Michael_N!
That was exactly what i was looking for, now i know the cause but aint got no solution yet.

I called my SIP-provider and asked what SIP response they got when the results here where Cause-code: 1 and dialstatus: congestion and they saw a 404 (Not found).

With that info i found this post: http://www.eflo.net/VICIDIALforum/viewt ... 64b682163f witch confirms the results from my example in my first post.

By the way, do i need to enable debugging in asterisk to be able to see the SIP-response i get from my provider?
And is it possible to let asterisk to send the SIP-response-code to FastAGI_log.pl with agi://127.0.0.1:4577/call_log so a 404 gets vicidial-status: ADC or something like that?
The other possibility is of course to do as the guy in Michael_N link, rely on the $hangup_cause that ISDN-response 1 = SIP-response 404 and rewrite the script.
To bad FastAGI_log.pl 110324-2336 looks a bit different, I will check if I can rewrite it, will add that to my todo list.

by **DomeDan** » Thu Jul 21, 2011 4:32 am

I did some experimenting with drop call seconds and stuff you tipped me about williamconley but it didn't fix the problem.

I made some more research and started with enabling DEBUG and check what more info i could get:

Code: Select all: ;exten => h,1,DeadAGI(agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME}) exten => h,1,DeadAGI(agi://127.0.0.1:4577/call_log--HVcauses--PRI-----DEBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME})

So i got this file HANGUP_cause-output.txt, lets check it out:
Hangup cause 2011-07-19 12:00 - 15:59

Code: Select all: cat /var/log/astguiclient/HANGUP_cause-output.txt | grep '2011-07-19 1[2-5]' | cut -d '|' -f 2,3 | sort -n | uniq -c 1328 0| 632 0|CANCEL 593 1|CONGESTION 110 16| 582 16|ANSWER 130 17|BUSY 80 19|CONGESTION 28 34|CONGESTION

Ok, 593 1|CONGESTION that's a lot with cause 1... all of those will get status NA and be called again later on and will probably get the same result, and i guess that all of those are SIP 404 (yeah this data can be found in the database to)

I checked the load to be able to compare when I'm doing some changes to the script FastAGI_log.pl:
System Load 2011-07-19 12:00 - 15:59

Code: Select all: while true; do date; uptime; sleep $[15*60]; echo; done tis jul 19 12:30 up 10 days 20:48, 2 users, load average: 0,14, 0,12, 0,18 tis jul 19 12:45 up 10 days 21:03, 3 users, load average: 0,21, 0,27, 0,21 tis jul 19 13:00 up 10 days 21:18, 3 users, load average: 0,10, 0,18, 0,18 tis jul 19 13:15 up 10 days 21:33, 3 users, load average: 1,03, 0,50, 0,29 tis jul 19 13:30 up 10 days 21:48, 4 users, load average: 0,93, 0,66, 0,49 tis jul 19 13:45 up 10 days 22:03, 4 users, load average: 0,55, 0,47, 0,45 tis jul 19 14:00 up 10 days 22:18, 4 users, load average: 0,34, 0,32, 0,34

Here is part of the script FastAGI_log.pl that takes care of ADC and BUSY

Code: Select all: if ( ($PRI =~ /^PRI$/) && ($callerid =~ /\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d/) && ( ( ($dialstatus =~ /BUSY/) || ( ($dialstatus =~ /CHANUNAVAIL/) && ($hangup_cause =~ /^1$|^28$/) ) ) || ($CPDfound > 0) ))

This IF statement wont do anything with CONGESTION.
Ok, I will add that to the IF statement and check if it works, first lets see what hangupcauses I get on CONGESTION:

Code: Select all: SELECT COUNT( * ) AS `Rows` , `hangup_cause` FROM `vicidial_carrier_log` WHERE `dialstatus` LIKE 'CONGESTION' GROUP BY `hangup_cause` ORDER BY `hangup_cause` Rows hangup_cause 25936 1 140 16 (weird!) 7048 19 8 21 3433 34

Cause codes from: http://networking.ringofsaturn.com/Rout ... ecodes.php

Cause No. l - Unallocated (unassigned) number.
This cause indicates that the destination requested by the calling user cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated).
What it usually means:
1 The SPIDS may be incorrectly entered in the router or the Telco switch, giving a SPID failure in the router logs.
2 The ISDN phone number being dialed by the router is invalid and the telco switch cannot locate the number to complete the call, as it is invalid.
3 On long distance calls, the call cannot be properly routed to its destination.

Cause No. 16 - normal call clearing.
This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared.

Cause No. 19 - no answer from user (user alerted).
This cause is used when the called party has been alerted but does not respond with a connect indication within a prescribed period of time. Note - This cause is not necessarily generated by Q.931 procedures but may be generated by internal network timers.

Cause No. 21 - call rejected.
This cause indicates that the equipment sending this cause does not wish to accept this call. although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. This cause may also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.
What it means:
This is usually a telco issue. The call never reaches the final destination, which can be caused by a bad switch translation, or a misconfiguration on the equipment being called.

Cause No. 34 - no circuit/channel available.
This cause indicates that there is no appropriate circuit/channel presently available to handle the call.
What it means:
There is no place on the Public Telephone network to place the call; the call never gets to its destiation. This is usually a temporary problem.

Here is my patch to take care of CONGESTION hanupcause 1:

Code: Select all: *** FastAGI_log.pl 2011-07-21 08:18:44.000000000 +0200 --- FastAGI_log.pl.congestion_hangupcause1 2011-07-21 08:17:50.000000000 +0200 *************** *** 830,841 **** ### END - CPD Look for result for B/DC calls ############################################################## } ! if ( ($PRI =~ /^PRI$/) && ($callerid =~ /\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d/) && ( ( ($dialstatus =~ /BUSY/) || ( ($dialstatus =~ /CHANUNAVAIL/) && ($hangup_cause =~ /^1$|^28$/) ) ) || ($CPDfound > 0) )) { if ($CPDfound < 1) { if ($dialstatus =~ /BUSY/) {$VDL_status = 'AB'; $VDAC_status = 'BUSY';} if ($dialstatus =~ /CHANUNAVAIL/) {$VDL_status = 'ADC'; $VDAC_status = 'DISCONNECT';} } $stmtA = "UPDATE vicidial_list set status='$VDL_status' where lead_id = '$CIDlead_id';"; --- 830,842 ---- ### END - CPD Look for result for B/DC calls ############################################################## } ! if ( ($PRI =~ /^PRI$/) && ($callerid =~ /\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d/) && ( ( ($dialstatus =~ /BUSY/) || ( ($dialstatus =~ /CHANUNAVAIL/) && ($hangup_cause =~ /^1$|^28$/) ) || ( ($dialstatus =~ /CONGESTION/) && ($hangup_cause =~ /^1$/) ) ) || ($CPDfound > 0) )) { if ($CPDfound < 1) { if ($dialstatus =~ /BUSY/) {$VDL_status = 'AB'; $VDAC_status = 'BUSY';} if ($dialstatus =~ /CHANUNAVAIL/) {$VDL_status = 'ADC'; $VDAC_status = 'DISCONNECT';} + if ($dialstatus =~ /CONGESTION/) {$VDL_status = 'ADC'; $VDAC_status = 'DISCONNECT';} } $stmtA = "UPDATE vicidial_list set status='$VDL_status' where lead_id = '$CIDlead_id';";

It seams to work, the customers is removed from vicidial_auto_calls as I want them to, and they get registered as DC when CONGESTION and hangup cause 1.

Here is the load when using the patch and there is the same amount of agents:
System Load 2011-07-21 09:00 - 10:30

Code: Select all: while true; do date; uptime; sleep $[15*60]; echo; done tor jul 21 09:15 up 0:53, 2 users, load average: 0,31, 0,48, 0,30 tor jul 21 09:30 up 1:08, 2 users, load average: 0,44, 0,29, 0,27 tor jul 21 09:45 up 1:23, 2 users, load average: 0,11, 0,17, 0,18 tor jul 21 10:00 up 1:38, 2 users, load average: 0,23, 0,26, 0,23 tor jul 21 10:15 up 1:53, 2 users, load average: 0,40, 0,28, 0,21 tor jul 21 10:30 up 2:08, 2 users, load average: 0,12, 0,13, 0,15

It don't seem to kill the server, I guess its even less load, but its probably because there aren't many real-time reports and stuff running.

I don't care about hangup cause 19 and 34 because they are mostly temporary problems and there is not so many of them as cause 1.

I found a similar posts about this in the issue tracker: http://www.vicidial.org/VICIDIALmantis/view.php?id=289
But that's more about manual dial, I'm gonna do a post about my problem and the patch.

by **omarrodriguezt** » Thu Sep 29, 2011 2:31 pm

Thank you for your post. It will help us a lot.
I implemented the patch that you posted, but the calls are still with 'NA' in vicidial_list status field.

Is like the system never go to this line:
$stmtA = "UPDATE vicidial_list set status='$VDL_status' where lead_id = '$CIDlead_id';"
We are not using sangoma, we are not using Answer machine detection.

I implemented the patch using the patch command in Linux.

by **DomeDan** » Thu Sep 29, 2011 4:33 pm

Hi omarrodriguezt!

Try checking what hangup cause those calls get, either as above from: /var/log/astguiclient/HANGUP_cause-output.txt or the database-table: vicidial_carrier_log
I have made a kind of real time report that i personally thinks gets a good view of whats happening with the calls being made and how long they are stuck in vicidial_auto_calls-table, i posted it here: http://www.vicidial.org/VICIDIALmantis/view.php?id=518

In my case the troublesome calls got CONGESTION and hangup cause 1,
the patch made that part of the script take care of those calls as it does with CHANUNAVAIL and BUSY.
I have edited that script even more to take care of those others i mentioned (hangup cause 19 and 34) and added a system status for temporary DC and thats the reason why I havent posted the updated one here or in the issue tracker. Its probably very different from carrier to carrier any way.

by **omarrodriguezt** » Fri Sep 30, 2011 6:43 am

Thank you DomeDan,
I'm looking the hangup causes in the table vicidial_carrier_log and same like you, I want to remove from the auto_calls table all the CONGESTION and hangup cause 1.

I applied the patch, I'm using same vicidial/astguicient version. But the vicidial_status table never gets updated with the DC code.
Also, where do you change in order to remove from vicidial_auto_calls table the disconnect leads?

by **DomeDan** » Mon Oct 03, 2011 2:28 am

That's strange, because this part: "|| ( ($dialstatus =~ /CONGESTION/) && ($hangup_cause =~ /^1$/) )" of the script should take care of those calls.
First thing you can do is to verify that the patch is applied.
If thats ok then look at a few leads and find out how long are they stuck in vicidial_auto_calls.

About "But the vicidial_status table never gets updated with the DC code." can you explain what you mean here?

"Also, where do you change in order to remove from vicidial_auto_calls table the disconnect leads?"
The patch makes the CONGESTION hangup cause 1 get treated the same as BUSY and CHANUNAVAIL

by **omarrodriguezt** » Mon Oct 03, 2011 6:59 am

Thank you for the follow up.

About "But the vicidial_status table never gets updated with the DC code." can you explain what you mean here?

I mean, that the vicidial_list table (I put vicidial_status my bad) was not being updated with the ADC status.

The patch is applied correctly, I made a change to the code in order to see if was working and yes it is.

$stmtA = "UPDATE vicidial_list set source_id = '$VDL_status' , status='$VDL_status' where lead_id = '$CIDlead_id';"

The source_id field of the vicidial_list table was updated with ADC, but teh field status still have 'NA' is like the status field is getting updated again in another part of vicidial?
Any idea?

Thank you again for the follow up.

by **omarrodriguezt** » Mon Oct 03, 2011 1:16 pm

More info:

If I run this query:
select user,source_id,status from vicidial_list where
status in ('ADC' ) it does not returns any records.

But if I run this:
select user,source_id,status from vicidial_list
where source_id ='ADC'

It returns a lot of records.
At this moment what I think is, that this update is working:
$stmtA = "UPDATE vicidial_list set source_id = '$VDL_status' , status='$VDL_status' where lead_id = '$CIDlead_id';"

Because the field source_Id is getting updated, but for any reason the field status is not updated, or is being updated again with another value.
Any help is appreciated.

by **DomeDan** » Tue Oct 04, 2011 3:02 am

Thats strange, but in my case vicidial_list gets status DC and vicidial_log gets status ADC.
I don't know why you get status NA, but as you say its probably at some other part of the system, maybe some script that flush vicidial_auto_calls and updates vicidial_list.
I'm just guessing now though.
Find out how long the leads are stuck in vicidial_auto_calls and check what status the leads got in vicidial_log.

Here is what I'm using right now: (its a patch for the original FastAGI_log.pl 110324-2336)

Code: Select all: *** /usr/share/astguiclient/FastAGI_log.pl.orig 2011-09-21 16:54:12.000000000 +0200 --- /usr/share/astguiclient/FastAGI_log.pl 2011-09-21 17:30:19.000000000 +0200 *************** *** 830,841 **** ### END - CPD Look for result for B/DC calls ############################################################## } ! if ( ($PRI =~ /^PRI$/) && ($callerid =~ /\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d/) && ( ( ($dialstatus =~ /BUSY/) || ( ($dialstatus =~ /CHANUNAVAIL/) && ($hangup_cause =~ /^1$|^28$/) ) ) || ($CPDfound > 0) )) { if ($CPDfound < 1) { if ($dialstatus =~ /BUSY/) {$VDL_status = 'AB'; $VDAC_status = 'BUSY';} if ($dialstatus =~ /CHANUNAVAIL/) {$VDL_status = 'ADC'; $VDAC_status = 'DISCONNECT';} } $stmtA = "UPDATE vicidial_list set status='$VDL_status' where lead_id = '$CIDlead_id';"; --- 830,843 ---- ### END - CPD Look for result for B/DC calls ############################################################## } ! if ( ($PRI =~ /^PRI$/) && ($callerid =~ /\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d/) && ( ( ($dialstatus =~ /BUSY/) || ( ($dialstatus =~ /CHANUNAVAIL/) && ($hangup_cause =~ /^1$|^28$/) ) || ( ($dialstatus =~ /CONGESTION/) && ($hangup_cause =~ /^1$|^19$|^34$/) ) ) || ($CPDfound > 0) )) { if ($CPDfound < 1) { if ($dialstatus =~ /BUSY/) {$VDL_status = 'AB'; $VDAC_status = 'BUSY';} if ($dialstatus =~ /CHANUNAVAIL/) {$VDL_status = 'ADC'; $VDAC_status = 'DISCONNECT';} + if ($dialstatus =~ /CONGESTION/ && $hangup_cause =~ /^1$/) {$VDL_status = 'ADC'; $VDAC_status = 'DISCONNECT';} + if ($dialstatus =~ /CONGESTION/ && $hangup_cause =~ /^19$|^34$/) {$VDL_status = 'ADCT'; $VDAC_status = 'DISCONNECT';} } $stmtA = "UPDATE vicidial_list set status='$VDL_status' where lead_id = '$CIDlead_id';";

as you can see hangup cause 19 and 34 will get status ADCT because i consider them as temporary disconnects (T as in Temporary).
I have added that to system statuses and using lead recycle on that status

by **omarrodriguezt** » Tue Oct 04, 2011 6:57 am

Thank you.
I will follow up your suggestions in order to find out my issue.
By the way, what other hangup causes are'nt you recycling?
I will not recycle 16,
But what means: 19 and 34 temporary disconnect?
Are you going to dialed again?

by **fibres** » Tue Oct 04, 2011 11:51 am

Just a quick query.

Has something been changed in TRUNK so that cause 1 calls are dropped from auto_calls quicker. I dont see anything as disconnected numbers but from domedan's realtime monitor page I dont see and congestion calls with a dialtime of more than 0 seconds.

Regards

by **fibres** » Tue Oct 04, 2011 12:34 pm

Also I have made the above amendment to my FastAGI_Log.pl but I dont see anything being dispositioned as ADC

I have looked in my extensions.conf and noticed that I have the following line.

exten => h,1,DeadAGI(agi://127.0.0.1:4577/call_log--HVcauses ... EBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME})

For both mentions of the script Should I change them both to

exten => h,1,DeadAGI(agi://127.0.0.1:4577/call_log--HVcauses ... EBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME})

Regards

by **omarrodriguezt** » Wed Oct 05, 2011 7:38 am

Hello,
Can some one please tell me what script run next on vicidial after FastAGI_log.pl ?

What is the file responsible of put 'NA' on the field status of the table vicidial_list after FastAGI_log.pl runs?

Your help is very appreciated.
Thank you!

by **mflorell** » Wed Oct 05, 2011 8:58 am

Might be the AST_VDauto_dial.pl script.

by **omarrodriguezt** » Wed Oct 05, 2011 9:06 am

Thank you Matt. I will look into it.

by **DomeDan** » Thu Oct 06, 2011 4:31 am

omarrodriguezt:
hangup cause 16 is a normal answer, i got some CONGESTION on that hangup cause for some reason but i haven't investigated that.
regarding 19 and 34, i wrote some info about them in this topic, link to post: http://www.vicidial.org/VICIDIALforum/v ... 7003#72808 thats the info I found when goggling for "hangup cause" and I consider them as temporary and yes, I will recycle them, make them be called again.

fibres:
I don't think this issue affects everyone, but in my case it does, (SIP in sweden.)
I have been patching my trunk when updating so I'm not sure if something is made to prevent this in trunk right now, but I have read about the changes when updating and haven't found anything about it.
About dial_time 0, I'm not sure, maybe its only counted when a call gets transfered to an agent, because I get dial_time 0 on all calls except normal answers, it would be interesting to see dial_time on those to, and busy/disconnect.

To check if this problem affecting you, you need to see a lead thats both in auto_calls and carrier_log, status CONGESTION and will be stuck in auto_calls for a while and ends up with status NA in vicidial_list.
This is where my "real-time" carrier report comes in handy.

About ADC, thats the status in vicidial_log, the lead should get status DC in vicidial_list.

What is that about 127.0.0.1:4577/call_log--HVcauses--PRI and SIP? (I got PRI in my extensions.conf.)

omarrodriguezt:
yeah maybe its AST_VDauto_dial.pl but strange that it works for me but not you, check those things i wrote about earlier.

btw, you wrote this a few posts back: "I'm using same vicidial/astguicient version"
and your signature says: "Astguiclient V 2.20"
I'm a bit confused, witch version are you using? (I'm using astGUIclient 2.4b0.5)

by **omarrodriguezt** » Thu Oct 06, 2011 6:39 am

Thank you for reply.
I put this in my signature, because I use different vicidial versions.
I'm the admin of 4 dialers.

by **fibres** » Thu Oct 06, 2011 10:15 am

Hi DomeDan

I have downloaded your real_time script and it seems as if I dont have congested calls staying in my live_calls.

However I do have all DC numbers being dispo as NA

I have manually added the line from your patch file to my FastAGI_Log.pl file but I still see all numbers as NA it does not seem to be doing anything.

Thats why I was wondering if it was where it is called in the extensions.conf causing issues. Wasnt ure if I needed that set to SIP.

Regards

by **omarrodriguezt** » Thu Oct 06, 2011 12:51 pm

Hi Fibres, thats the same situation that I'm having.
As Matt said:
Might be the AST_VDauto_dial.pl script.

by **DomeDan** » Thu Oct 06, 2011 1:04 pm

omarrodriguezt:
Ah, I see.

fibres:
Ok, do they seem to get NA status right after the call was made?
When you manually added the line, did you notice that there's also a change in the IF-statement?:
"|| ( ($dialstatus =~ /CONGESTION/) && ($hangup_cause =~ /^1$|^19$|^34$/) ) )"

okay, well no editing in extensions.conf is needed, PRI is ISDN cause-codes or something, here's some info: http://www.voip-info.org/wiki/index.php ... angupCodes

by **omarrodriguezt** » Thu Oct 06, 2011 2:31 pm

In my case the vicidial_log table is getting updated with teh correct status code 'ADC' but vicidial_list still being updated with 'NA'
As Matt Said, the reason could be the AST_VDauto_dial.pl

But I'm trying to figure out how to get this done

The only place were I can see the 'NA' is line 1309 of AST_VDauto_dial
But I'm still a little lost, I'm trying to understand how AST_VDauto put the 'NA' and why.

if ($CLstatus !~ /XFER|CLOSER/)
{
$stmtA = "DELETE from vicidial_auto_calls where auto_call_id='$auto_call_id'";
$affected_rows = $dbhA->do($stmtA);

$stmtA = "UPDATE vicidial_live_agents set ring_callerid='' where ring_callerid='$KLcallerid[$kill_vac]';";
$affected_rowsX = $dbhA->do($stmtA);

$event_string = "| dead call vac deleted|$auto_call_id|$CLlead_id|$KLcallerid[$kill_vac]|$end_epoch|$affected_rows|$KLchannel[$kill_vac]|$CLcall_type|$CLdial_timeout|$CLdrop_call_seconds|$call_timeout|$dialtime_log|$dialtime_catch|$affected_rowsX|";
&event_logger;

$CLstage =~ s/LIVE|-//gi;
if ($CLstage < 0.25) {$CLstage=0;}

if ($CLstatus =~ /BUSY/) {$CLnew_status = 'B';}

else
{
if ($CLstatus =~ /DISCONNECT/) {$CLnew_status = 'DC';}
else {$CLnew_status = 'NA';}
}

by **omarrodriguezt** » Fri Oct 07, 2011 1:23 pm

Hello,
After a few restart of teh server is working.

DomeDan your patch works.

Matt, it could be great if you can implement this patch for the next version.

Thank you guys for your help

by **mflorell** » Fri Oct 07, 2011 2:52 pm

Just make sure it's a proper diff -u patch and it's uploaded to the Issue Tracker and we will take a look at it.

by **DomeDan** » Mon Oct 10, 2011 5:00 am

omarrodriguezt:
Nice!

mflorell:
Yeah, I will start using the -u flag.
But in the trunk right now (2.4b0.5) how come there is no part of the scrips that looks for congestion, only chanunavail?
One more question, what do you say about using different statuses in vicidial_list depending on the type of disconnect?

by **mflorell** » Mon Oct 10, 2011 8:12 am

Using CONGESTION is very unreliable here in the USA. With telco deregulation many carriers oversell their lines and use very restrictive LCR so that you can get a CONGESTION frequently on valid numbers.

by **DomeDan** » Mon Oct 10, 2011 3:56 pm

Even tough its unreliable, isn't it better to take care of the call then to ignore it?
A way to approach the problem from both side of the Atlantic is to look at the hangup cause
http://www.voip-info.org/wiki/view/Aste ... esfromRFC3
I have been looking in the asterisk CLI and "sip set debug" and confirmed that hangup cause 1 == SIP 404, 19 == SIP 480 and so on as in the link,
What hangup cause do you get when the carrier is failing to forward a call in the USA?
It's probably 34 "no circuit available 503 Service unavailable", why not add a system status for those instead of letting them get NA when they are cleaned out from vicidial_auto_calls after about 50 sec of dead time?

That system status can be treated the same as NA or as the administrator wish. and the status of the leads will be more correct.
in my second patch I added ADCT to be set in vicidial_log to be able to sort out what kind of DC the lead got, but I would rather set that status in vicidial_list.

Does the hangup cause differ if your using Zap, IAX etc. or is there any other problem that i should know of?

by **Michael_N** » Mon Oct 10, 2011 4:04 pm

DomeDan

Have you checked if different voip-providers give the same hangup-reason?

by **DomeDan** » Mon Oct 10, 2011 4:20 pm

No I haven't, but how about you, what can you see in vicidial_carrier_log on leads with dialstatus congestion or chanunavail, what hangup cause and what status on the lead?

by **mflorell** » Mon Oct 10, 2011 4:54 pm

Hangup causes can differ between Zap/DAHDI, IAX2 and SIP.

by **DomeDan** » Thu Oct 20, 2011 7:52 am

Ok, I'm gonna give the "hangup cause patch" some more thoughts...

I have been wondering what causes normal NA to be left in vicidial_auto_calls after it is hung up by asterisk, checked the source for AST_VDauto_dial.pl and found the reason.

Code: Select all: if ($CLcall_type =~ /IN/) { $stmtA = "SELECT drop_call_seconds FROM vicidial_inbound_groups where group_id='$CLcampaign_id';"; $timeout_leeway = 30; } else { $stmtA = "SELECT dial_timeout,drop_call_seconds FROM vicidial_campaigns where campaign_id='$CLcampaign_id';"; $timeout_leeway = 7; } $sthA = $dbhA->prepare($stmtA) or die "preparing: ",$dbhA->errstr; $sthA->execute or die "executing: $stmtA ", $dbhA->errstr; $sthArows=$sthA->rows; if ($sthArows > 0) { @aryA = $sthA->fetchrow_array; $CLdial_timeout = $aryA[0]; $CLdrop_call_seconds = $aryA[1]; } $sthA->finish(); $dialtime_log = ($end_epoch - $start_epoch); $dialtime_catch = ($now_date_epoch - ($start_epoch + $timeout_leeway)); $hanguptime_manual = ($end_epoch + 60); if ($dialtime_catch > 100000) {$dialtime_catch=0;} $call_timeout = ($CLdial_timeout + $CLdrop_call_seconds); if ($CLstage =~ /SURVEY|REMIND/) {$call_timeout = ($call_timeout + 120);} if ( ($CLstage =~ /SENT/) && ($call_timeout > 110) ) {$call_timeout = 110;} if ( ( ($dialtime_log >= $call_timeout) || ($dialtime_catch >= $call_timeout) || ($CLstatus =~ /BUSY|DISCONNECT|XFER|CLOSER/) ) && ($PARKchannel < 1) ) { if ( ($CLcall_type !~ /IN/) && ($CLstatus !~ /IVR/) ) { if ($CLstatus !~ /XFER|CLOSER/) { $stmtA = "DELETE from vicidial_auto_calls where auto_call_id='$auto_call_id'"; $affected_rows = $dbhA->do($stmtA);

In my case the NA is removed after 12 seconds after a hangup (as what I can see in my "Real-Time Carrier Report")
and this is because I got "Drop Call Seconds" is set to 5 and "$timeout_leeway = 7" is probably used in the code.

Why does $timeout_leeway exist?
Why doesnt the IF-statement match "$dialtime_log >= $call_timeout" and matches "$dialtime_catch >= $call_timeout" instead?
Why is "Drop Call Seconds" added to $call_timeout?

by **mflorell** » Thu Oct 20, 2011 8:29 am

That is to clear out calls that have been dialed but received no disposition within 2 minutes of the start of the dial.

by **DomeDan** » Thu Oct 20, 2011 9:01 am

Ok, oh yeah, it it the right script I'm looking at to be able to find what takes care of normal NA?
Does it exist some documentation for this kind of stuff?

by **mflorell** » Thu Oct 20, 2011 11:43 am

The code is the documentation, there are several different types of calls that have to be handled in various ways(manual, auto-dial, 3way, etc...) and it is a rather complex process for handling NA calls.

by **DomeDan** » Mon May 28, 2012 5:55 am

yeah, it takes time and the code is not always the obvious documentation :wink:

but now I got an other tweak to optimize calling, found it when investigating this thread: http://vicidial.org/VICIDIALforum/viewt ... 060#p86411

I've seen some people writing threads about the dialling is to slow and so on, so I hope they will find this and try it out too see if it helps them

by **DomeDan** » Thu Oct 25, 2012 6:29 am

mflorell wrote:Just make sure it's a proper diff -u patch and it's uploaded to the Issue Tracker and we will take a look at it.

I didn't remember that my old patch was not a proper diff -u
I've uploaded a new one now, with improvements http://www.vicidial.org/VICIDIALmantis/view.php?id=510

vicidial.org

Optimize dialing, call next number faster

Optimize dialing, call next number faster

Hello

Re: Optimize dialing, call next number faster

Re:

Who is online