Remote Agents NOT hanging up

[AlexR]

Hello Everyone!


Im doing an outbound broadcast campaign. I have set up an extension playing a small sound file for leads in this campaign, the recording is about 30 secs long TOPS. Usually the system starts out fine and all the dial is done very nicely... but after a day or two of autodialing it start showing remote agents

For example (this is from VICIDiAL AGENT REALTIME MONITOR)

Code: Select all

R/408      | 408    | 8399      | INCALL | 10.27.1.217     |                 |    6:33 | broadcast

This agent has been on a call for 6:33 minutes?!

My extension 8399 (the one remote agents can be "reached") looks like this:

Code: Select all

exten => 8399,1,AGI(call_log.agi,${EXTEN})
exten => 8399,2,Wait(1)
exten => 8399,n,Playback(greeting)
exten => 8399,n,Hangup


The strange thing is that it worked perfectly for a while... but afterwards it goes crazy.

How can i troubleshoot this? can somebedy please help me?


Thank you


alejandro

[mflorell]

Are you running a campaign over night without stopping it?

What version of astguiclient?

[AlexR]

Thanks Matt! that was a fast reply!

No, im not running the campaign overnight I have created a schedule which goes from 9am to 8pm only. It is working well... as I said the trouble starts after several hours after it started and everything was running well before.

I have even tried creating NEW remote agents for this campaign but they end up working in the same issue.



my astguiclient version is :astguiclient_2.0.1

again thank you!!

alejandro

[mflorell]

I have changed several sections of code for remote agents in the 2.0.2 version that should be released this week(same code as is in the 2.0.2 beta releases) that should fix some of this.

If you get a chance please try 2.0.2 and let me know if that helps.

[AlexR]

So this has happened before then? At least it is not that scary then! hehehe

just wondering... in this update are there any database changes? or will it just affect the AGI scripts and web pages?

I'm just trying to imagine how difficult this upgrade can get.


Thanks for everything Matt!

[mflorell]

I have had that happen on large callout campaigns myself, but I have done some work with remote agents in the last few weeks so hopefully it should be a lot more stable for the 2.0.2 release.

I am working on the documentation right now, the code is pretty much finished for 2.0.2

To upgrade just read the UPGRADE document in the root directory of the beta release, it will show you step by step what has changed since 2.0.1.

Yes, there have been several database changes as well as bin/agi/web changes.

[AlexR]

Thank you Matt, I will try this version out and let you know the results, it should be a pretty nice test for this beta version, we are calling a LOT of people here.

Should I use the FASTagi changes for this to work?

One more question... after all this remote agents mess when i run

/usr/share/astguiclient/AST_VDhopper.pl --debug

Code: Select all

Starting hopper run for bpsi campaign- GMT: dia   HOPPER: 1
     hopper DONE cleared:  0E0
     hopper GMT BAD cleared:  0E0
     hopper READY count:   0
     hopper too low (0|1) starting hopper dump
     campaign lists count: 1 | '133'
     no lead filter defined for campaign: bpsi
     leads to call count:  95228
     ERROR CANNOT ADD ANY NEW LEADS TO HOPPER
     Getting Leads to add to hopper
     lead call order:      order by lead_id asc
     Adding to hopper:     1
     DONE with this campaign

and it just wont dial... and in the campaign tab i can see that i have lots of leads to be dialed.

I am particularly worried about the

ERROR CANNOT ADD ANY NEW LEADS TO HOPPER
part.


What table in MySQL should i clear to have the hopper working properly again?


Thanks a lot!

[mflorell]

FastAGI loggign is stable and I would recommend using it in production.

As for your AST_VDhopper.pl problem, what is the output when you run with the --debugX flag?

[AlexR]

Thanks for the reply Matt, Im looking at point 11 of the Upgrade document version 2.0.2.

I am wondering: this AST_VDauto_dial_FILL.pl is ONLY for multi server environment, so it should not be used for my setup.. I should go for the same "remote" agent setting for broadcasting a sound file, right?

By the way... 2.0.2 is HUGE step forwards. I love it that you have included a way to monitor IN GROUPs individually in timeonvdad script.


Thanks!!

alejandro

[mflorell]

Yes, the AST_VDauto_dial_FILL.pl script is only for multi-server setups. To do broadcast campaigns you should stick to using remote agents.

Thanks for the compliments. Yes, the reports have gone through some major changes for the better in 2.0.2

[AlexR]

Hi there!




Im still having troubles with version 2.0.2b and using remote agents for a broadcast type campaign.

It will start dialing but in a point i can see that user status remains in "INCALL" so calls are no longer pass to this agents.

afterwards if I log out (force log out) of this remote servers, they are in READY state but calls wont be pass to them unless I raise the Auto Dial level to a very high amount. After doing this the same action happens... agents get stuck in an INCALL state.


can someone guide me in how to trouble shoot this issue?


greetings!


alejandro

[mflorell]

I am going to be doing some load testing next week so I will try to duplicate your problem.

How many remote agent lines do you set?

About how long does it take before it stops sending calls to the fake agents?

[AlexR]

Im setting for 20 remote agents and it does not take that long... a few minutes the most.


Thank you for your help!


alejandro

[mflorell]

I have been testing for several hours with upto 100 remote agent entries on a single server and have not seen that happen with the 2.0.2 beta code.

[AlexR]

Thank you for your help Matt.


I did the upgrade to version 2.0.2b without ever restarting the server, I have done a reset and the remote agents now seem to be working just fine (that is GREAT news for me by the way!)

It seems that the upgrade does require a reset (maybe some stuff hangs when changing the Perl Scripts that are active from cron jobs?).


But overall eveyrthing is working great, I want to really thank you for your help Matt as you have gone to great lengths for helping me out. I hope i can return the favor soon.


alejandro

[mflorell]

I'm glad it's all working well for you!

Yes, several of the perl scripts do require that they be restarted, while it is easier to do a reset you can actually do an upgrade from 2.0.1 to 2.0.2b3 without stopping Asterisk.

[AlexR]

Matt, I just wanted to add that I have seen the same behavior today, BUT i have found out i was really short on Memory. I only had 512 on that "server" and now i have upgraded to 1 Gig.


Do you have some sort of rule of thumb as of memory and processor requirements?


Thanks!!

[mflorell]

With the 2.0.2 codebase I have seen that even on a very loaded 8 CPU-core server that I did not use more than 1.3GB RAM. I recommend 1GB for a smooth running system and I almost always put 2GB on all production systems I build.

[bobbymc]

im having a similar problem.. i setup a remote agent with 60 lines and set the campaign to ratio, dial level 1.. first off its not making 60 calls like it should.. but thats a seperate issue.. the main issue i got is that when it transfers the calls to the external number speicfied in the remote agents column under External Extension, it doesnt make the remote agent avaliable as ready after the person hangs up.. its status stays as INCALL... any idea why? is it because i transfer the calls to a external number and vicidial doesnt know whent he person hangs up

[bobbymc]

btw im using 2.0.3 with ulaw and the extension 8366 as the survaye taker