cid_channels_recent table

[alo]

Hello Firends and Foes!

I noticed a new table on the new SVNs called cid_channels_recent_ with some numbers.

It seems to be filling up the disk space pretty quickly (although I assume it may automatically clear after X days maybe?)

My question is, what is it being used for? I haven't seen it before and I am wondering if it might cause any performance issues since it seems to be another log writing to another table.

Anyone know what its for and if it can be deleted?

Thanks.


VERSION: 2.14-694a
BUILD: 181005-1738
SVN Version: 3052
DB Schema Version: 3052
Installed using vicibox 8.0.1
Asterisk 13.21.1-vici

[mflorell]

It is for Asterisk 13 compatibility, and there should be an automatic process clearing it out if you are running more recent svn/trunk code. If it is not, then there is probably a configuration issue on your system.

[alo]

Okay cool. I am sure it is clearing it out then.

I just noticed when I am watching mtop or the processlist for mysql it seems to be a lot of activity, so wasn't sure if I could turn it off to potentially save the database a bit of work.

[mflorell]

This new table was basically a requirement for us to add after Local/ channel resolution was removed from the Asterisk code in the Asterisk 12 branch. The good news is that greatly reduced Asterisk load and allows you to get more capacity out of an Asterisk 13 server than you could out of an Asterisk 11 server. The bad news is that we had to create our own method for looking up Local/ channels, but that new method is much more efficient than keeping that function in Asterisk, so it ended up being a win/win.

[alo]

I noticed you mentioned there should be an automatic processes for clearing these out. but I also noticed it doesn't appear to be clearing them out. Is there a place I should be looking for this automation? otherwise I was planning on just truncating the tables nightly.

[mflorell]

The "flush" script that should be in the crontab running at least once an hour on one of your servers is the one that should be clearing out that table.

[alo]

Interesting Thank you!

I run that every 4 minutes with the --seconds=240 flag.

I ran it with Debug on and see it only clearing the cid_channels for the Database server. (The one the script ones on).

I see its supposed ### Gather active servers from the database and I see nothing wrong with the table `servers` that it looks to be pulling this from. Do you have any idea what may be stopping this from clearing?

I wonder if this is also the cause of my leave three way call issue that pops up every once and awhile. maybe it should be clearing something its not?

[alo]

Anyone else having it not clear on the Dialing servers?

Anyone know why they wouldn't or where to look?

[mflorell]

What is the last line in the "CHANGES" section of the comments at the top of that "AST_flush_DBqueue.pl" scirpt on that server?

[alo]

# 181003-2115 - Added optimize of cid_channels_recent_ tables

[mflorell]

What is the output when you run that script with the --debugX flag?

[alo]

It looks like it only shows the table for the database. the server the script is running on. for fun, I also ran the script on one of the dialing servers, and it was the same result. only listed the database server.

I also ran the query from the code that checks to see what servers are active and it looks like it lists out the servers correctly. See the bottom for the ouput.

Code: Select all

-----DEBUGGING -----

TEST

NOW DATETIME:         2019-01-26 10:05:34
1 HOUR AGO DATETIME:  2019-01-26 09:05:34


|DELETE from vicidial_manager where entry_date < '2019-01-26 09:35:34';|
 - vicidial_manager flush: 0E0 rows

|DELETE from vicidial_dtmf_log where dtmf_time < '2019-01-26 09:35:34';|
 - vicidial_dtmf_log flush: 0E0 rows

|DELETE from routing_initiated_recordings where launch_time < '2019-01-26 09:35:34';|
 - routing_initiated_recordings flush: 0E0 rows

|DELETE from parked_channels_recent where park_end_time < '2019-01-26 09:35:34';|
 - parked_channels_recent flush: 0E0 rows

|DELETE from cid_channels_recent where call_date < '2019-01-26 10:03:33';|
 - cid_channels_recent flush: 0E0 rows

|OPTIMIZE table vicidial_manager;|
|asterisk.vicidial_manager|optimize|status|Table is already up to date|
 - OPTIMIZE vicidial_manager

|OPTIMIZE table vicidial_dtmf_log;|
|asterisk.vicidial_dtmf_log|optimize|status|Table is already up to date|
 - OPTIMIZE vicidial_dtmf_log

|OPTIMIZE table routing_initiated_recordings;|
|asterisk.routing_initiated_recordings|optimize|status|Table is already up to date|
 - OPTIMIZE routing_initiated_recordings

|OPTIMIZE table parked_channels_recent;|
|asterisk.parked_channels_recent|optimize|status|Table is already up to date|
 - OPTIMIZE parked_channels_recent

|OPTIMIZE table cid_channels_recent;|
|asterisk.cid_channels_recent|optimize|status|Table is already up to date|
 - OPTIMIZE cid_channels_recent

|OPTIMIZE table vicidial_live_agents;|
|asterisk.vicidial_live_agents|optimize|status|Table is already up to date|
 - OPTIMIZE vicidial_live_agents

|OPTIMIZE table vicidial_drop_rate_groups;|
|asterisk.vicidial_drop_rate_groups|optimize|status|Table is already up to date|
 - OPTIMIZE vicidial_drop_rate_groups

|OPTIMIZE table vicidial_campaigns;|
|asterisk.vicidial_campaigns|optimize|status|Table is already up to date|
 - OPTIMIZE vicidial_campaigns

|OPTIMIZE table vicidial_lists;|
|asterisk.vicidial_lists|optimize|status|Table is already up to date|
 - OPTIMIZE vicidial_lists

|OPTIMIZE table vicidial_inbound_groups;|
|asterisk.vicidial_inbound_groups|optimize|status|Table is already up to date|
 - OPTIMIZE vicidial_inbound_groups

|1|SHOW TABLES LIKE "cid_channels_recent_192168000033";|

|DELETE from cid_channels_recent_192168000033 where call_date < '2019-01-26 10:03:33';|
 - cid_channels_recent_192168000033 flush: 0E0 rows

|OPTIMIZE table cid_channels_recent_192168000033;|
|asterisk.cid_channels_recent_192168000033|optimize|status|Table is already up to date|
 - OPTIMIZE cid_channels_recent_192168000033


SELECT server_ip,server_id FROM servers where active='Y' and active_asterisk_server='Y';

Code: Select all

 192.168.0.33  | mainDB    |
| 192.168.0.229 | mn229     |
| 192.168.0.228 | mn228     |
| 192.168.0.227 | mn227     |


[mflorell]

Well that is quite strange. I've tested this code on 3 separate clusters and I can't replicate the issue.

Could you try adding a debug output line in the code right after that servers select query to see how many results it's returning to the script?

[williamconley]

try running that command directly in mysql as cron and as root to see if the results are interesting.

[alo]

I tried running SELECT server_ip,server_id FROM servers where active='Y' and active_asterisk_server='Y'; as Cron user and it listed ther server_ips and the server ids the same as the root user.

I also deleted all the dialing servers and added one from scratch in case there was something weird like a space or character in the server_id.

I wasn't 100% sure where or how you wanted me to add a debugging line, but I did manage to add a few to print $stmtA (showed correct statement) and $sthArows (showed correct number of rows in the servers table)

After I finished messing around and adding the debugging, I did a SVN update to and ran the install script to reset the file. just in case, and its still only clearing the one table.

I have to assume I messed something up but its happening on our other offices system too.

Do you have any specific debugging additions you think might be helpful?

Thanks again.

[williamconley]

I tried running SELECT server_ip,server_id FROM servers where active='Y' and active_asterisk_server='Y'; as Cron user and it listed ther server_ips and the server ids the same as the root user.

I also deleted all the dialing servers and added one from scratch in case there was something weird like a space or character in the server_id.

I wasn't 100% sure where or how you wanted me to add a debugging line, but I did manage to add a few to print $stmtA (showed correct statement) and $sthArows (showed correct number of rows in the servers table)

After I finished messing around and adding the debugging, I did a SVN update to and ran the install script to reset the file. just in case, and its still only clearing the one table.

I have to assume I messed something up but its happening on our other offices system too.

Do you have any specific debugging additions you think might be helpful?

Thanks again.

Don't know where you got those queries (also you didn't post queries, but text statements describing queries), but I was talking about these:

Code: Select all

DELETE from vicidial_manager where entry_date < '2019-01-26 09:35:34';

Only you should be running fresh ones from a fresh debug execution of the perl script in question so the date/time is correct.

[alo]

the vicidial_manager table is being trimmed just fine. Its the cid_recent tables for the Dialing servers that are not.

Anything else I should look at that might lead me in the correct direction?

[williamconley]

perhaps searching the HD for that table name would provide something resembling an answer. if a script alters it, that script will contain its name.

[alo]

Well I know what the tables are called. They are generated for each asterisk 13 dialing server and called cid_channels_recent_ then the IP of the Dialing server Like cid_channels_recent_192168000212 if the IP was 192.168.0.212. I just don't know why its not trimming. I see the flush script queries the servers table and then is supposed to loop through them. I just don't know where is the script to add some additional debug output to print the results of the queries.

[williamconley]

You weren't searching for the purpose of getting the name, you were searching for the purpose of finding scripts that access the table. If you expect changes to the table, those changes aren't magic: a script will make them. Scripts are in:

Code: Select all

/srv/www/htdocs/vicidial
/srv/www/htdocs/agc
/usr/share/astguiclient
/var/lib/asterisk/agi-bin

Searching these locations for scripts with that table name will result in knowing where changes are made. If you are expecting a change, and it's not happening, the "if" or "switch" or other logical coding of the scripts in question can tell you what is required for a change to occur. They will also provide the sql query itself which you CAN execute manually, if you like.

To test the output of the queries, it's not necessary to add debug code (although you CAN), just execute the query yourself: It's easier and faster AND you get the output yourself immediately.

[bourneshell]

I have the same issue here

On one of our clusters where this has been monitored we are using
Version: 2.14b0.5
SVN Version: 3053
DB Schema Version: 1561

When I look at the tables it would seem that only one table is being flushed

Code: Select all

-rw-rw---- 1 mysql mysql 2.1K Nov 11 04:41 cid_channels_recent_010001096020.frm
-rw-rw---- 1 mysql mysql    0 Feb  5 16:11 cid_channels_recent_010001096020.MYD
-rw-rw---- 1 mysql mysql 1.0K Feb  5 16:11 cid_channels_recent_010001096020.MYI
-rw-rw---- 1 mysql mysql 2.1K Nov 11 04:44 cid_channels_recent_010001096021.frm
-rw-rw---- 1 mysql mysql  35G Feb  5 23:36 cid_channels_recent_010001096021.MYD
-rw-rw---- 1 mysql mysql 2.7G Feb  5 23:36 cid_channels_recent_010001096021.MYI
-rw-rw---- 1 mysql mysql 2.1K Nov 11 04:52 cid_channels_recent_010001096022.frm
-rw-rw---- 1 mysql mysql  35G Feb  5 23:36 cid_channels_recent_010001096022.MYD
-rw-rw---- 1 mysql mysql 2.6G Feb  5 23:36 cid_channels_recent_010001096022.MYI
-rw-rw---- 1 mysql mysql 2.1K Nov 22 05:03 cid_channels_recent_010001096031.frm
-rw-rw---- 1 mysql mysql  30G Feb  5 23:36 cid_channels_recent_010001096031.MYD
-rw-rw---- 1 mysql mysql 2.3G Feb  5 23:36 cid_channels_recent_010001096031.MYI
-rw-rw---- 1 mysql mysql 2.1K Dec 18 14:00 cid_channels_recent_010001096040.frm
-rw-rw---- 1 mysql mysql  20G Feb  5 23:36 cid_channels_recent_010001096040.MYD
-rw-rw---- 1 mysql mysql 1.5G Feb  5 23:36 cid_channels_recent_010001096040.MYI
-rw-rw---- 1 mysql mysql 2.1K Feb  4 14:35 cid_channels_recent_010001096078.frm
-rw-rw---- 1 mysql mysql 1.4G Feb  6 01:14 cid_channels_recent_010001096078.MYD
-rw-rw---- 1 mysql mysql 100M Feb  6 01:14 cid_channels_recent_010001096078.MYI


Would upgrading to the latest SVN release fix this issue?

[bourneshell]

Just verified this with one of our newer clusters and saw the same.

Here are the details
Version: 2.14b0.5
SVN Version: 3061
DB Schema Version: 1562

[bourneshell]

Looks like I found the culprit for the issue.

I made a very small adjustment on the flush script and will be monitoring our systems today to check if the performance will be affected.

I'll update the forum on my findings tomorrow

[alo]

Hello bourneshell!

Very interested to hear how it turned out!

[alo]

Anybody else having the same problem or find a solution here?

[bourneshell]

Hi everyone,

So here is what I found...

On the 8.0.1 vicibox version the last few lines of the script shows

Code: Select all

while ($sthArows > $aas)
        {
        $CCRrec=0;
        $stmtA = "SHOW TABLES LIKE \"cid_channels_recent_$PADserver_ip[$aas]\";";
        $sthA = $dbhA->prepare($stmtA) or die "preparing: ",$dbhA->errstr;
        $sthA->execute or die "executing: $stmtA ", $dbhA->errstr;
        $CCRrec=$sthA->rows;
        if($DB){print STDERR "\n|$CCRrec|$stmtA|\n";}

        if ($CCRrec > 0)
                {
                $stmtA = "DELETE from cid_channels_recent_$PADserver_ip[$aas] where call_date < '$SQLdate_NEG_2min';";
                if($DB){print STDERR "\n|$stmtA|\n";}
                if (!$T) {      $affected_rows = $dbhA->do($stmtA);}
                if (!$Q) {print " - cid_channels_recent_$PADserver_ip[$aas] flush: $affected_rows rows\n";}
                }
        $aas++;
        }


While on 8.1.2 vicibox it shows

Code: Select all

while ($sthArows > $aas)
        {
        $CCRrec=0;
        $stmtA = "SHOW TABLES LIKE \"cid_channels_recent_$PADserver_ip[$aas]\";";
        $sthA = $dbhA->prepare($stmtA) or die "preparing: ",$dbhA->errstr;
        $sthA->execute or die "executing: $stmtA ", $dbhA->errstr;
        $CCRrec=$sthA->rows;
        if($DB){print STDERR "\n|$CCRrec|$stmtA|\n";}

        if ($CCRrec > 0)
                {
                $stmtA = "DELETE from cid_channels_recent_$PADserver_ip[$aas] where call_date < '$SQLdate_NEG_2min';";
                if($DB){print STDERR "\n|$stmtA|\n";}
                if (!$T) {      $affected_rows = $dbhA->do($stmtA);}
                if (!$Q) {print " - cid_channels_recent_$PADserver_ip[$aas] flush: $affected_rows rows\n";}

                $stmtA = "OPTIMIZE table cid_channels_recent_$PADserver_ip[$aas];";
                if($DB){print STDERR "\n|$stmtA|\n";}
                if (!$T)
                        {
                        $sthA = $dbhA->prepare($stmtA) or die "preparing: ",$dbhA->errstr;
                        $sthA->execute or die "executing: $stmtA ", $dbhA->errstr;
                        $sthArows=$sthA->rows;
                        @aryA = $sthA->fetchrow_array;
                        if (!$Q) {print "|",$aryA[0],"|",$aryA[1],"|",$aryA[2],"|",$aryA[3],"|","\n";}
                        $sthA->finish();
                        }
                if (!$Q) {print " - OPTIMIZE cid_channels_recent_$PADserver_ip[$aas]          \n";}
                }
        $aas++;
        }


As you can see on the newer version the optimise table procedure was added. Unfortunately if the optimize table process executes with zero results it would then break the $sthArows variable thus rendering on the next while loop to fail since $sthArows is now valued at "0".

What I did as a temporary measure would be to rename the $sthArows on the optimize part to say $sthArows1 so that it won't affect the while loop.

I hope we can apply an update to the next SVN for this.

[williamconley]

Try this on a fresh install with no imported db. If the problem is still present:

Use the vicidial issue tracker (link in the top of the page). Be sure to provide the precise version of the file in which you found the flaw.

Post a link to the Issue you created here in this ticket for others.

[mflorell]

Thanks for the details on this, I was finally able to find a cluster that had this problem and I have fixed it in SVN/trunk. Please test it out and confirm it is working for you.

[VFRDavid]

FTF: SVN 2973 / db schema 1542 / VICIdial version 2.14-670a

I know this is an older thread that I'm replying to - but - this just started being an issue for us - our clustered system has 11 servers, 4 of which were very small (100 trunk) asterisk 13 servers, but recently I replaced 3 of my older systems with more powerful servers, and asterisk 13 servers are taking a much larger percentage of our call volume (1500+ of our 3,000+ active calls at any given moment). Anyway - I noticed a back-log on MTOP as well - I also saw that the table was being emptied/trimmed about every hour (I found the AST_flush_DBqueue.pl cron job running at 11 minutes after the hour) - but - in that hour - I was generating around 1 or 2 million records in the table.

Before I read the AST_flush_DBqueue.pl code - I noticed the fields involved in the WHERE clause - and, instead of dropping the data more often, I added them to the table's index (caller_id_name and connected_line_name) - which seemed to keep them from piling up on MTOP.

My questions are...

---> How often can I run the AST_flush_DBqueue.pl code? Can I change the "11" to "/11" in my crontab? Or is it better for me to add "--seconds=660" to the crontab's command line (in keeping with the "11-minute" example)?
---> How much of this data do I need to safely keep? (Meaning - does asterisk 13 just need the table to be there - or are any rows required for successful calls? ... if rows - do I need to keep them for 60 seconds? for any/all active calls? or...?) Since I see a bunch of SELECTs related to this table - I have to assume that you DO need SOME of it to be available...otherwise - why bother with the SELECTs, right???
---> Why are there so many "duplicate" records in the table? I noticed at least 60 duplicate records for every call placed (I know that the call_time field does differ - but - again - based on the SELECT statements I noticed in MTOP which use either caller_id_name or connected_line_name - the number of records that match that query must continue to grow and grow if the SELECT is run more than once during the life of the call...what is the point of getting every record back for every second (or more) that the call was alive? (I'm sure it's more than I need to know - so - feel free to ignore that question if you like

Thanks for your help with this!

David

[mflorell]

For our highest call-volume clients, we have set the AST_flush_DBqueue.pl script to run as often as every 4 minutes(see crontab entry below):

Code: Select all

1,5,9,13,17,21,25,29,33,37,41,45,49,53,57 * * * * /usr/share/astguiclient/AST_flush_DBqueue.pl --seconds=240 --session-flush -q

As for how it works, it's a bit complicated but it is required for how Asterisk 13+ handles Local channel calls.

As for dozens of duplicates, you might have something configured wrong if that is happening, although that is difficult to diagnoze without access to the system.

As for how long the records need to stay in those tables, that depends on how your outbound dialing is configured and what options you have on it. As mentioned above, 4 minutes is pretty much the safest shortest length of time we would recommend in most cases.

[VFRDavid]

Thanks! I just shortened the run frequency - I used "*/6" instead of the 1,7,14,20...etc - that should be fine, correct? It is running MUCH better / more consistently now!

As far as how it works - please see the "duplicates" below - it seems that it's generating multiple records for the same caller_id_name and/or connected_line_name - they're technically not duplicates, since the fractional seconds probably do not match - but - as far as the fields I see in the SELECT statement from mtop - I would imagine that if the SELECT is run more than once during the life of the call - the number of records returned would/could vary - unless there is more to the statement than what shows on mtop (like a LIMIT 1 clause or something). Of course, I have no idea what happens after the SELECT - haven't dug into that yet - but - in the absence of some other limiting code, any cursor/loop could be running several times - but - again - I have no idea what I'm talking about - so - maybe it needs to.

As far as "duplicates" - after modifying the flush routine to run every 6 minutes - here are the details for one of the caller_id_name values about a minute after the last flush ran:

caller_id_name connected_line_name server_ip call_date channel dest_channel linkedid dest_uniqueid uniqueid
V826141235xxx7860433 V826141235xxx7860433 6x.xxx.xxx.xx7 8/26/2022 14:14:41 Local/TSTC21469xxx5354@default-000915f1;1 SIP/AGTW104-00083065 1661541159 1661541159 1661541159
V826141235xxx7860433 V826141235xxx7860433 6x.xxx.xxx.xx7 8/26/2022 14:14:41 Local/TSTC21469xxx5354@default-000915f1;1 SIP/AGTW104-00083065 1661541159 1661541159 1661541159
V826141235xxx7860433 V826141235xxx7860433 6x.xxx.xxx.xx7 8/26/2022 14:14:40 Local/TSTC21469xxx5354@default-000915f1;1 SIP/AGTW104-00083065 1661541159 1661541159 1661541159
V826141235xxx7860433 V826141235xxx7860433 6x.xxx.xxx.xx7 8/26/2022 14:14:41 Local/TSTC21469xxx5354@default-000915f1;1 SIP/AGTW104-00083065 1661541159 1661541159 1661541159
V826141235xxx7860433 V826141235xxx7860433 6x.xxx.xxx.xx7 8/26/2022 14:14:43 Local/TSTC21469xxx5354@default-000915f1;1 SIP/AGTW104-00083065 1661541159 1661541159 1661541159
V826141235xxx7860433 V826141235xxx7860433 6x.xxx.xxx.xx7 8/26/2022 14:14:43 Local/TSTC21469xxx5354@default-000915f1;1 SIP/AGTW104-00083065 1661541159 1661541159 1661541159

As far as how long the records need to stay in the cid_channels_recent table - what outbound dialing settings do you need to know about? I'm not sure what to describe here - but - basically - I'm trying to keep ~150 agents connected from 9am - 10pm eastern Mon - Sat. We have 11 servers in the cluster, half of which are asterisk 13 at this point. We cancel calls at about 30 seconds (No Answer), we use the AMD provided by extension 8369. Our average sales call is about 20 - 30 minutes, but they can last over an hour at times. We are using "old school" load balancing with IAX2 soft-phones (Zoiper) over 3 or more servers per agent (no web phones...yet). Our outbound carriers are all SIP and our gateways are all local to the telephony servers (our servers and our carrier's gateways all reside on the same public IP subnet). We typically use ADAPT_TAPERED for our dial method and maintain a single-digit drop rate by the end of each day. When contact is good, we can be placing a couple hundred calls - but - when it's not - we can place over 3,000 calls at any given moment (at least as far as what shows on the Real Time screen - our carrier maintains that the actual number of calls we're processing is around 20 - 60% the number on the Real Time screen - and not to go off on a tangent/different topic - but - it appears that the "current active calls" from the Real Time screen is close to the total of the "active channels" and what our carrier reports is close to the "active calls" that is reported from a "core show channels" on each of our servers - if that's relevant).

Thanks again for your help...it is very much appreciated!

[mflorell]

The records in those tables need to be in there as long as the outbound calls have a chance of being routed through the outbound AGI script. As such, it's the dial timeout plus the amount of time AMD takes to process the call plus any survey prompts and timeout(if that is enabled) and add a few seconds for good measure. The 4-minute minimum is very conservative, since there is almost no way a call could go unrouted for that long. You can certainly try lowering it if you want, but if you ever get to the point where you are deleting a call's record from that table before it has been routed to an agent or anywhere else, it will become unroutable and a lot more problems will start to show up on your system.

[VFRDavid]

Thank you very much for the additional details!

Not to beat a dead horse, but I have one last question...

Any idea why I'm getting multiple records for each caller_id_name / connected_line_name? Again - they're probably not technically duplicate records, since the call_date field changes (especially if I assume that there are partial seconds involved in the stored date/time). Anyway - of my 11 servers that make calls, 5 are asterisk v13.x and the remaining 6 are v11.x. As you know - only the v13.x servers generate records into the cid_channels_recent table - and ALL 5 of them generate multiple records for each call as far as I can tell - but only the call_date field differs...every other field (caller_id_name, connected_line_name, server_ip, channel, dest_channel, linkedid, dest_uniqueid, and uniqueid) appear to be identical. They're all running v13, but - there are three different versions: two running 13.21.1-vici - two running 13.27.0-vici and one running 13.38.2-vici - I don't know what I could have done to mis-configure the servers to create multiple records in a table I didn't know existed - so if you could tell me where to look - that would be very much appreciated...unless you think that it could be related to other aspects of the SVN/etc that I'm running (SVN 2973, DB Schema 1542 and VICI version 2.14-670a / 2.14b0.5)?

I know I need to update my SVN version - I've seen later versions - and there are a LOT of features that I would love to implement here - but - 11 servers / 34MM leads along with an operation that runs 6 of 7 days that I am hesitant to put at risk keep me putting it off

[mflorell]

We have made a lot of changes in the last four and a half years. I really would suggest upgrading your system before attempting to do any further troubleshooting on this issue.

I'd also recommend doing a full DB back before you do your upgrade as well as archiving a lot of those leads if possible.

[nextdial]

My problem is cid_channel_recent_XXXXX
Is always empty nothing is inserted and on autodial mode agents did not receive calls !

I'm on vicibox 10 (installed from ISO)
Asterisk 16.30.0-vici
Version: 2.14b0.5
SVN Version: 3789
DB Schema Version: 1702

[mflorell]

First thing to check is the Asterisk Version that is set on the Server in the web admin. If that looks correct, then check the dialplan that the calls are running through to make sure it is using the "...AGI(agi://127.0.0.1:4577/call_log)" line before the "Dial(" line.

[nextdial]

Thanks for your reply
asterisk version 16.30.0-vici checked in both sides
and
in my dial plan : exten => _998892X.,1,AGI(agi://127.0.0.1:4577/call_log)

In server config
auto dial extension: 8368 prefix: 13
do I have to use the prefix, or i can use autodial extension without prefix ? cause the problem is there !
using agi_VDAD_local_optimize.agi : Executing [138368@default:1] AGI("Local/998899XXXXXXXXX@default-0000001d;1", "agi-VDAD_local_optimize.agi,V2260005410000003319") in new stack