Features discussion - Disconnected Numbers detection

[dspaan]

So, i have spent some time thinking about these features over the last few months and the goal of this topic is to discuss these features and hopefully let them end up in the Projects forum as bounties so we can fund the development together.

I have been working with outbound mainly so once i get some more inbound experience you can bet i will make a topic about that too .

In my opinion right now the most important missing features for Outbound VICIdial are:

1.Reliably manage disconnected numbers<--this topic
2.Status code for maximum attempts
3.Manager friendly Reports
4.(Realtime) Sales report
5.Import and export leads templates

Since it would become a mess to discuss all of these subject in one thread i made a thread for each of them. I know that for some of these subjects there have been discussions about them in the past. I will try to reference these older threads as far as i can.

Reliably manage disconnected numbers

Here are some threads of interest:

http://www.vicidial.org/VICIDIALforum/v ... hp?t=18872
http://www.vicidial.org/VICIDIALforum/v ... hp?t=16984
http://www.vicidial.org/VICIDIALforum/v ... hp?t=12950
http://www.vicidial.org/VICIDIALforum/v ... hp?t=12705
http://www.vicidial.org/VICIDIALforum/v ... php?t=8574
http://www.vicidial.org/VICIDIALforum/v ... php?t=5748
http://www.vicidial.org/VICIDIALforum/v ... php?t=5620

And i would not be surprised if the issues with disconnected numbers result into these problems:

http://www.vicidial.org/VICIDIALforum/v ... hp?t=12863
http://www.vicidial.org/VICIDIALforum/v ... php?t=3694
http://www.vicidial.org/VICIDIALforum/v ... php?t=2936

So the problem is:
1.Asterisk is unable to recognize disconnected numbers.
2.These numbers get flagged with NA status.
3.NA numbers start piling up, endlessly!
4.Clients start asking questions, why are there no disconnected numbers. How can you have so many NA calls?
5.Because of the ratio between NEW leads and NA leads grows in the favor of NA leads (of which a large part are actually DC leads) the agent wait time between calls keeps increasing resulting in problems with auto-dialing coming to a halt and wait time between calls increasing to over 1 minute average
6.This last part makes the whole auto-dialing function a financial loss. You can't have agents who are waiting all the time.

It all depends on your carrier and whether you can trust the hangup cause codes coming back. Most carriers in the USA are not reliable on their disconnect codes by over 20%.

The only good solution we have found is using the paid-add-on Sangoma CPA call progress analysis proxy.

if you're dialing in the US, last time i checked the vicidial system categorized all as NA without regard for the coding (or lack thereof) regarding DC vs no answer.

i have a script that will check for zero second na (which indicates the provider didn't even attempt to call, translates to DC), but i have recent clients who have re-called those and found a fairly large percentage are real numbers ... if called through the same provider even.

so you may need to experiment with this. a useful tool is the carrier log.

We have been over this several times. Asterisk is not capable of detecting pre-answer signals, and carrier disconnect signaling is extremely inconsistent resulting in setting disconnect signals for valid phone numbers.

The only solution that works is a paid one, the Sangoma CPA that we have set up for several clients using ViciDial is very good at this, but you have to pay for it on a per channel basis.

The solution seems to be Sangoma Netborder CPA. I would like to hear from some people what there experience is with CPA regarding disconnected numbers, does it detect them?

And if it's the only proper solution why not advertising it more and maybe including a standard integrated trial license in the VICIbox distro?

But isn't there really another work-around we can think of?
Poundteam has made the NA harvester script which basically changes each call that was flagged CANCELED within 0 seconds in the carrier log as a DC call during a nightly job. Only the problem that i have seen so far is that a large part of the numbers that have been set to CANCELED within 0 seconds in the carrier log could still be called afterwards. So maybe a script that sets them to DC status after a call has been canceled 3 times within 0 in a row? I don't know.

I'm wondering how other callcenters deal with this. Thousands of VICIdial users out there and does everyone use Sangoma CPA? I have to say i'm rather disapointed by this, VICIdial is open source but now we still have to pay an expensive license for a piece of software that manages to do what Asterisk can't do. Aren't there any other work-arounds?

If not i think the management of disconnected numbers is something that could be addressed in the manager manual in more detail. There is a chapter about Sangoma integration, maybe expand it a bit.

[mflorell]

Zero second NAs don't mean a thing. Some carriers signal an immediate generic disconnect code when it should be a congestion instead, because you can place a call to that number an hour later and it will go through. Those show up as 0 seconds on some carriers. The solution really needs to be carrier dependent, because here in the USA there is no universal solution for this.

As for Sangoma CPD, I'm not sure how running it on the same server as a standalone Vicibox would work, we have never tried that. We have only set it up as a standalone SIP proxy server.

[DarknessBBB]

Where are you from, dspan? In Europe, if you use ISDN lines (PRI or BRI), the telco always send an isdn cause code

[dspaan]

We are located in South America but only make calls to the Netherlands, Europe. How could we use those cause codes to our benefit then?

[DarknessBBB]

We are located in South America but only make calls to the Netherlands, Europe. How could we use those cause codes to our benefit then?

I think you have to talk with your telco, if you use ISDN, and tell him to send the properly codes.
Then you can see them in the vicidial logs

http://networking.ringofsaturn.com/Rout ... ecodes.php

Usually the codes 16, 1 and 17 cover the 99% of the calls.

And, months ago we had a issues with a brand new E1 line, our telco configured it to send, for DC numbers, a vocal message in call progress mode. This way the call was archived as NA. I've just asked them to send instead the code "1".

[Jones]

I have the same issue as DSpaan wrote in his original post. I've dealt with it by calling through the NA's at a very high ratio speed to weed out the good numbers that are still caught in the NA list. This is a band-aid though.

mflorrell - what would it cost to set up Sangoma on a 20 seat call centre in North America that runs full time year round?

[mflorell]

There are a few options with CPA, and it is licensed per channel not per seat, we can give you a quote if you send an email to sales@vicidial.com

[dspaan]

We are located in South America but only make calls to the Netherlands, Europe. How could we use those cause codes to our benefit then?

I think you have to talk with your telco, if you use ISDN, and tell him to send the properly codes.
Then you can see them in the vicidial logs

http://networking.ringofsaturn.com/Rout ... ecodes.php

Usually the codes 16, 1 and 17 cover the 99% of the calls.

And, months ago we had a issues with a brand new E1 line, our telco configured it to send, for DC numbers, a vocal message in call progress mode. This way the call was archived as NA. I've just asked them to send instead the code "1".

Hi Darkness, actually the calls we make are in the Netherlands/Europe. So i'm going to look for another provider who can supply us with these cause codes. But once i have found a provider. How do i manage these cause codes to be translated to the proper statuses? Where do i configure this? Which cause codes do you translate to DC status apart from code 1? Shouldn't a vocal message end up with the agents? I wonder why they were coded as NA calls in your case.

[TroyD]

We have purchased the CPA analyzer and its benefit was immediately noticed as a ton of those NA numbers we kept calling were now dispositioned as something more meaningful. We cut down on NA's by about 75-80% right off the bat. We used to count the NA's before we started using the CPA and if we had called it more than 5 times and each resulted in NA we would set it as DC and stop calling it. The call progress analyzer in my opinion is worth every cent, as now we knew what we were dealing with for the most part, we knew which clients to go look for better numbers for and stopped dialing the NA numbers as frequently leading to high wait times merely because the sheer number of NA's.. Which are now reduced by such a significant number. I will however recommend staying with the older windows version of the CPA as we have not yet got satisfactory results with the linux version, it makes the time between customer answer and transfer to agent about 10 seconds IF it works at all. we have about 35 agents using it with a 38 channel license..

[mflorell]

Thank you very much for telling us about your experience with Sangoma CPD.

I do want to mention that the Linux CPD and Windows CPD are the same versions(meaning they have the same features), we have just found the Windows version to be more reliable.

[Framercy]

For those of you who can trust your carrier responses i wrote a small mysql trigger with the purpose to update the relevant leads in vicidial_list to an other status:

Code: Select all


delimiter //
create trigger vicidial_carrier_log_ai
AFTER INSERT
ON vicidial_carrier_log
FOR EACH ROW

BEGIN

IF NEW.hangup_cause = '34'
THEN
UPDATE vicidial_list
SET status = 'PRI34'
WHERE vicidial_list.lead_id = NEW.lead_id;
END IF;

END;//
delimiter ;


Hope you like it
Framercy

Edit:
My idea was good but VD overwrites my trigger set status right after the trigger update. Or the cron DB user needs more rights...
Okay so maybe I have to wrap the hole shit into a stored proc that will be fired each night!
I will post my effords soon...
Sorry

[Framercy]

Okay - let's do it vice versa...

If the carrier_log is written prior to te lead status update then let's trigger vicidial_list...

Maybe there is room for improvements to this and yes I know that this is a little bit crappy - but I need a solution - soon.

Code: Select all

delimiter //

create trigger vicidial_list_bu BEFORE UPDATE ON vicidial_list
FOR EACH ROW

BEGIN
DECLARE huccount INTEGER;
DECLARE huc INTEGER;

IF NEW.status = "NA" THEN
SELECT count(DISTINCT hangup_cause) INTO huccount FROM vicidial_carrier_log WHERE lead_id = OLD.lead_id;
IF huccount = 1 THEN
SELECT hangup_cause INTO huc FROM vicidial_carrier_log WHERE lead_id = OLD.lead_id GROUP BY lead_id;
IF huc = "34" THEN
SET NEW.status = "PRI34";
END IF;
END IF;
END IF;
END;//
delimiter ;


I will test this tomorrow with agents
Fram

EDIT

Small Tune UP:

Code: Select all

delimiter //
create trigger vicidial_list_bu BEFORE UPDATE ON vicidial_list
FOR EACH ROW
BEGIN
DECLARE callcount INTEGER;
DECLARE huccount INTEGER;
DECLARE huc INTEGER;
IF NEW.status = "NA" THEN
SELECT count(DISTINCT hangup_cause), count(hangup_cause)  INTO huccount, callcount FROM vicidial_carrier_log WHERE lead_id = OLD.lead_id;
IF callcount >= 4 AND huccount = 1 THEN     /* Leads are hung up min. 4-times and all times hangup_cause was the same */
SELECT hangup_cause INTO huc FROM vicidial_carrier_log WHERE lead_id = OLD.lead_id GROUP BY lead_id;
IF huc = "34" THEN
SET NEW.status = "PRI34";
END IF;
END IF;
END IF;
END;//
delimiter ;


PS.:
I added an index on the lead_id column from table vicidial_carrier_log to speed up the query inside the trigger....

Best regards
Framercy

[dspaan]

Thanks for posting this. Is your script working?

[DomeDan]

There's an other way for you who can trust your carrier responses.
Edit FastAGI_log.pl to take care of CONGESTION, I've been running with these changes since July http://www.vicidial.org/VICIDIALforum/v ... g.pl#72808

The original purpose for this change was to reduce the wait-time for the agents, because now the DC calls are ended in a few seconds instead of waiting for them to timeout as NA calls.
I'm recycling them a few times so if the response from the carrier would be wrong I would probably reach the lead in one of the attempts, and its faster to recycle DC compared to NA and DC mixed together.

[williamconley]

this does seem to smooth out the calling process (more predictable)

[Framercy]

Sorry Dspaan for my long response time but in meantime I had some issures while updating the german translations of the agend interface to the latest svn sources.
Belive me or not but strange things happened after running the tranlation Perl script against my modified german translation file -
But this is an other story and told here only by the way...

Short answer: Yes my posted trigger will do its job right. But I made some evolutions to the script this evening witch will do it even better in my opinion.

Okay let us lift the so far untested secret:

Code: Select all


delimiter //

create trigger vicidial_list_bu BEFORE UPDATE ON vicidial_list

FOR EACH ROW

BEGIN

DECLARE callcount INTEGER;
DECLARE huccount INTEGER;
DECLARE huc INTEGER;

IF NEW.status = "NA" OR NEW.status = "N" THEN

SELECT count(DISTINCT hangup_cause), count(hangup_cause), hangup_cause INTO huccount, callcount, huc FROM vicidial_carrier_log WHERE lead_id = NEW.lead_id;

IF callcount >= 1 AND huccount = 1 AND huc = 1 THEN   
/* Number unassigned - put it away asap */

SET NEW.status = "PRI1";

ELSEIF callcount >= 3 AND huccount = 1 AND huc = 34 THEN   
/* Dialed 3times and all times hangup_cause was no circuit or channel */

SET NEW.status = "PRI34";

END IF;
END IF;

END;//
 
delimiter ;



This catches my two "major problem hangup causes" and it is very easy to customize. Simply add one ore more ELSEIFs to catch more statuses.

Further more one can add this trigger temporary as before insert trigger on an empty copy of the vicidial_list table.
Insert all leads into the empty table to process all leads at one time.
With Phpmyadmin this is an easy task....
And remember to add an index on the lead_id column from table vicidial_carrier_log to speed up the query inside the trigger!

Best regards
Fram

[Framercy]

Hello there,

Two days of intesive testing are showing that the last trigger is working like a charm in auto dialing mode.
I see no increasing of database load further.
Manual dialing (status N) is untestet so far.

This helps us a lot - because if our carrier sends an ISDN response code of 1 back to us than is it 100% an unassigned number. There was no mistake ever.
At a percentage of ~20% from all delivered or generated leads (somtimes less - sometimes even more) this is a huge Ammount of 'sure dead leads' that went out of my sight since I developed and implemented this simple solution.

Hope that someone gets inspired of this because many many more things (not all for sure) could be done faster and better on the dbserver as with client side scripting.


Best regards
Fram

[dspaan]

Thanks for posting your updates, i will discuss this with my partner and test your script

[Framercy]

Thanks for posting your updates, i will discuss this with my partner and test your script

Hope it helps you too....

Best regards
Fram

[ciacho]

Your mySQL trigger works great, but when I try to restart 'lead called on this list' I got mySQL process freeze.

[dspaan]

Hi Fram,

We have also implemented the trigger and also can confirm that it works. Don't understand why VICIidial doesn't do this out of the box...

We can also confirm that when resetting the leads the mysqld process goes to 100% processor util.

[DomeDan]

Don't understand why VICIidial doesn't do this out of the box...

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.

I've patched FastAGI_log.pl to set status DC on calls thats congestion and hangup cause 1,19 and 34.
And then I decide how much I will try to call them with lead recycle and a list cleaner I've written (that is written to work with a separate customer database)

for example, I would like to try to call leads registered with this hangup cause:
19 no answer from the user 480 Temporarily unavailable
more then this onces:
1 unallocated number 404 Not Found

Anyway, as I mention earlier in this thread, I've been using this patch since July 2011 and still no problems

[ciacho]

This query:

Code: Select all

UPDATE vicidial_list set called_since_last_reset='N' where list_id='$list_id';

in file vicidial/admin.php
is freezing MySQL process in Framercy trigger.

Maybe solution is:

Code: Select all

DROP trigger vicidial_list_bu;
UPDATE vicidial_list set called_since_last_reset='N' where list_id='$list_id';
CREATe trigger....


[Framercy]

Hmmm,

I noticed no problems reseting lists so far - but it is in fact an update on vicidial_list table and it forces the trigger to do it's job on all updated records.

It may be that our hardware is strong enough to handle that job, my config is different and/or our lists are relative small chunks of less than 10000 leads each, so that here are no probs of freezing something.

Here are the relevant parts of my my.cnf

Code: Select all

[mysqld]
user      = mysql
socket      = /var/run/mysqld/mysqld.sock
port      = 3306
basedir      = /usr
datadir      = /var/lib/mysql
tmpdir      = /tmp
skip-external-locking
bind-address      = 0.0.0.0
key_buffer      = 384M
max_allowed_packet   = 16M
# thread_stack      = 128K
thread_cache_size   = 8
max_connections         = 400
#table_cache             = 512
table_cache             = 1M
thread_concurrency      = 4
sort_buffer_size        = 2M
read_buffer_size        = 2M
read_rnd_buffer_size    = 8M
myisam_sort_buffer_size = 64M
tmp_table_size          = 32M
myisam-recover         = BACKUP
query_cache_limit   = 8M
query_cache_size        = 32M
log_error                = /var/log/mysql/error.log
log_warnings = 0
log_slow_queries   = /var/log/mysql/mysql-slow.log
long_query_time = 2
log_bin         = /mnt/datastore/dbbackup/mysql-bin.log
expire_logs_days   = 10
max_binlog_size         = 100M


Give it a try and give fedback pls. because I do not want to run into trouble in the future on our systems with that kind of things.

And did you remember to add an index on the lead_id column of table vicidial_carrier_log to speed up the query inside the trigger?

Code: Select all

ALTER TABLE `vicidial_carrier_log` ADD INDEX ( `lead_id` )


Best regards
Fram

[Framercy]

This is untested so far but should stop the freezing...

Code: Select all

/* Add an index on the lead_id column of  vicidial_carrier_log table!*/
ALTER TABLE `vicidial_carrier_log` ADD INDEX ( `lead_id` ) ;

delimiter //

create trigger vicidial_list_bu BEFORE UPDATE ON vicidial_list

FOR EACH ROW

BEGIN

DECLARE callcount INTEGER;
DECLARE huccount INTEGER;
DECLARE huc INTEGER;

IF (NEW.called_since_last_reset != "N") AND (NEW.status = "NA" OR NEW.status = "N") THEN

SELECT count(DISTINCT hangup_cause), count(hangup_cause), hangup_cause INTO huccount, callcount, huc FROM vicidial_carrier_log WHERE lead_id = NEW.lead_id;

IF callcount >= 1 AND huccount = 1 AND huc = 1 THEN   
/* Number unassigned - put it away asap */

SET NEW.status = "PRI1";

ELSEIF callcount >= 3 AND huccount = 1 AND huc = 34 THEN   
/* Dialed 3times and all times hangup_cause was no circuit or channel */

SET NEW.status = "PRI34";

ELSEIF callcount >= 3 AND huccount = 1 AND huc = 38 THEN   
/* Dialed 3times and all times hangup_cause was network out of order */

SET NEW.status = "PRI38";

END IF;
END IF;

END;//
 
delimiter ;


@DomeDan
I saw your solution to late - after I had written the trigger.

for example, I would like to try to call leads registered with this hangup cause:
19 no answer from the user 480 Temporarily unavailable
more then this onces:
1 unallocated number 404 Not Found

Anyway, as I mention earlier in this thread, I've been using this patch since July 2011 and still no problems

This is no problem anyway - simply add status i.e. PRI38 to your system statuses and add it to the campaign dial statuses.
Then this leads will be dialed again for sure...

The ammount of dial attempts can be set inside the trigger as you can see.

This way gives the maximum ammount of control over this dead leads to me - in practical- and in statistical manner .

Best regards

Fram

[Framercy]

Hello there,

I did some tests with the modified trigger.
It seems to work fine and I can see no relevant cpu load while reseting lists on our system.

Best regards
Fram

[dspaan]

Don't understand why VICIidial doesn't do this out of the box...

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.

But then why isn't there a script that flags a lead with a specific status after it has had status CONGESTION more than X tries? The way VICIdial currently works is to keep calling bad numbers endlessly? It's disastrous. Bad numbers keep piling up and waiting times for agents keep rising. Besides Sangoma CPA also just uses SIP responses to flag leads as 'Disconnected number'.

Thanks for the updated script Fram. We will test.

[omarrodriguezt]

These are a very interesting approach to SIT detection with a free version
See the links




Links
http://www.tucny.com/telephony/asterisk-sit-detection
http://www.voip-info.org/wiki/view/NVLineDetect
http://kostyanx.game-host.org/app_nv_linedetect.c
https://issues.asterisk.org/jira/browse/ASTERISK-15559

[omarrodriguezt]

Thanks to DomeDan and the Vicidial Team, in the svn version 1912, it was included an option in Vicidial->Admin->System Settings ->Enhanced Disconnect Logging
that detects more than 70% of disconnect numbers.
If you enable this option the vicidial will mark as 'DC' any lead with hangup cause /^19$|^21$|^34$|^38$/ http://telos-systems.com/support/csb/TCSB-022101.pdf
This is working, and this is Special Tone Information (disconnect numbers) auto detection. This is almost the open source feature that a lot of us were looking for. Vicidial Team, we appreciate when you implement things that the community suggest!

The only thing that I notice is that in the line 865 of FastAGI_log.pl you are updating the table vicidial_list using the status ADC, $

Code: Select all

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

and then a couple seconds later the AST_VDauto_dial.pl update the same table using the status 'DC'. In order to maintain an standard I suggest to put also 'ADC' that in the file AST_VDauto_dial.pl.

Vicidial Team explaining better, the only change I suggest is to change the line 1459 of AST_VDauto_dial.pl to

Code: Select all

if ($CLstatus =~ /DISCONNECT/) {$CLnew_status = 'ADC';}

because now it is

Code: Select all

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

More information about my actual version:
Last Changed Rev: 1912
Last Changed Date: 2012-12-23 17:30:05 -0400 (Sun, 23 Dec 2012)
Repository UUID: 3d104415-ff17-0410-8863-d5cf3c621b8a

[mflorell]

Post a diff -u file patch against current svn/trunk to the Issue tracker please.

[DomeDan]

Thank you for those words omarrodriguezt! glad my efforts are appreciated!

It was added in r1891 but anyway.
yeah the status in vicidial_list will be DC in any of the hangup causes.
but in vicidial_log it will be ADC if its hangup cause 1
and ADCT if its any of these hangup causes: 19, 21, 34, 38
you can see those statuses under "CALL STATUS STATS" in the Outbound Calling Report /AST_VDADstats.php?group%5B%5D=--ALL--&SUBMIT=SUBMIT

[omarrodriguezt]

Post a diff -u file patch against current svn/trunk to the Issue tracker please.

http://www.vicidial.org/VICIDIALmantis/view.php?id=641

[omarrodriguezt]

Thank you for those words omarrodriguezt! glad my efforts are appreciated!

It was added in r1891 but anyway.
yeah the status in vicidial_list will be DC in any of the hangup causes.
but in vicidial_log it will be ADC if its hangup cause 1
and ADCT if its any of these hangup causes: 19, 21, 34, 38
you can see those statuses under "CALL STATUS STATS" in the Outbound Calling Report /AST_VDADstats.php?group%5B%5D=--ALL--&SUBMIT=SUBMIT

Thank you, for share your tools to the community!

[SlavaE]

Question on topic! In my system $hangup_cause only appears to be either 0, 16, 17 or 19!
All actual disconnected numbers get $hangup_cause 0. But normal numbers get $hangup cause 0 from time to time too and get NA status.

Does it mean my carrier doesn't send proper codes to me? Im in USA on Broadband Dynamics.

[williamconley]

1) Welcome to the Party!

2) Newbie News:
when you post, please post your entire configuration including (but not limited to) your installation method and vicidial version with build.

this IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "from scratch" you must post your operating system and should also post the .iso version from which you installed your original operating system. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) What did you do to acquire the values you state are "$hangup_cause"? (IE: Where are you seeing this value?)

[SlavaE]

1) Thank you!
2) ViciBox Redux v.3.1.10 | VERSION: 2.4-334a BUILD: 110831-2038 | Asterisk 1.4.39.2-vici | Single Server | No Digium/Sangoma Hardware | Only custom php scripts written, no vital vicidial modifications | 8 Gb Ram / AMD Athlon(tm) II X4 630 Processor / 15-23 agents
3) I modified FastAGI_log.pl. Added this piece of code

Code: Select all

$stmtA = "UPDATE vicidial_list set comments='$hangup_cause|$dialstatus|$dial_time|$ring_time|$channel|$extension|$type|$callerid|$calleridname' where lead_id = '$CIDlead_id';";
$VDADaffected_rows = $dbhA->do($stmtA);

to this section

Code: Select all

                  ##############################################################
                  ### BEGIN - CPD Look for result for B/DC calls
                  ##############################################################

And these are the codes I get(can't post links but this is a screenshot)
i(dot)imgur(dot)com(slash)vsXERph(dot)png

Lately about 50%-80% of phone numbers we get in our new lists are disconnected.

[DomeDan]

I would suggest you to try an other carrier for comparison, its most likely the cause
and query vicidial_carrier_log to compare the results

[williamconley]

I would suggest you to try an other carrier for comparison, its most likely the cause
and query vicidial_carrier_log to compare the results

concur. you can also just call some of them to find out.

this, by the way, is the reason that this feature was controversial: every carrier is different! there are no rules in the use of these codes.

you could also consider failover for these calls (and have another carrier attempt the same call after the first one claims disconnected ..)

[fibres]

Hi Guys

Thanks Domedan for your work on this. Very useful, especially here in the uk where carriers are "generally" pretty good at sending codes.

One issue I am having though is that Code 1 with all carriers I have found is disconnected number.

However, codes 19, 21, 34, 38 are almost always temporary issues, normally congestion on the network somewhere.

I not that it sets code 1 as status ADC and the rest as ADCT which I assume is for AutoDisConnectTemporary.

I therefore feel that maybe this should be passed through to the status of the lead, this would make life a lot easier as you would want to retry ADCT numbers after a period of time but not necessarily ADC numbers. Could this possibly be done?

I know I can just remove the line from the FastAGI_log.pl or change it to mark them as NA or something, but I would rather not make changes to code as causes havoc at upgrades.

Regards

[williamconley]

Actually I agree with that. I would want as much granularity in the list status as possible. Having it in the log is useful ... to determine if there is a problem. But the solution to the problem is then left to us programmers.

Honestly, I think it would be best to "DC##" where the ## is the actual code returned. Then every user could call some numbers for each code and determine for themselves which numbers were temporary and which were really disconnected ... and add those to the dialable statuses (perhaps with a delay filter?) based on the results.

But that's me.