Page 1 of 1

Agents can't resume

PostPosted: Fri Jul 06, 2012 4:26 pm
by desrtwlf
ViciBox Redux v.3.1.15 64 bit
Vicidial Version: 2.6b0.5
Asterisk 1.4.39.2-vici
Kernel 2.6.34.10-0.6-default
Intel Xeon CPU E31220, 8GB RAM, Supermicro Mainboard
No dahdi hardware
"Single" server with DB on seperate mysql box

Brand new install. Agent can log in to testcamp and manually dial fine. When logged into a predictive dial campaign agent cannot resume.
I press the resume button, several seconds go by and the "Agent Alert Your session has been paused" notice pops up. No leads are dialed.
I'm wondering if I should not have allowed the installer to install from svn?

I've checked to be sure time is in sync everywhere, dahdi timing is good, tweaked mysql database settings as per elsewhere in the forums,
network communication (all local network on HP switch) is fine with no firewalls/antivirus. Tried Firefox 3.6 on WinXP, Firefox 10 on Linux,
Firefox 11/Safari on OSX.

I'm at my wit's end!

I've read through the manual, scoured the fourms, tried everything I can think of. But I can't shake the feeling that I'm just missing something
stupid.

Here is my dialplan:
exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,2,Dial(${IAXTRUNK}/${EXTEN:1},,To)
exten => _91NXXNXXXXXX,3,Hangup


Thanks in advance!

Re: Agents can't resume

PostPosted: Sat Jul 07, 2012 9:47 am
by williamconley
you left off the build from your install (version is nice, but the build is precise)

Code: Select all
screen -list

post results from this

Re: Agents can't resume

PostPosted: Sat Jul 07, 2012 5:52 pm
by desrtwlf
Edit: I think I may have given the wrong version number initially.. VERSION: 2.6-349c
BUILD: 120529-2112
Sorry about that.

There are screens on:
29231.ASTVDadapt (Detached)
4887.astshell20120707162454 (Detached)
5056.ASTVDremote (Detached)
29223.ASTVDadapt (Detached)
5051.ASTlisten (Detached)
5045.ASTupdate (Detached)
5048.ASTsend (Detached)
5054.ASTVDauto (Detached)
2878.ASTfastlog (Detached)
4904.asterisk (Detached)
10 Sockets in /var/run/screens/S-root.

Thanks for the reply!

Re: Agents can't resume

PostPosted: Sun Jul 08, 2012 2:13 pm
by williamconley
i note that you have two "adapt" screens, which is unusual.

and i am curious about this comment:
I'm wondering if I should not have allowed the installer to install from svn?
If you did not install from SVN, how did you get to this revision level?

Also, please describe the process involved in
I've checked to be sure time is in sync everywhere

Re: Agents can't resume

PostPosted: Mon Jul 09, 2012 8:48 pm
by desrtwlf
and i am curious about this comment:
I'm wondering if I should not have allowed the installer to install from svn?
If you did not install from SVN, how did you get to this revision level?


I was saying I did allow the installer to download from svn and I was wondering if I should have used the included stable version instead.

Also, please describe the process involved in
I've checked to be sure time is in sync everywhere


I suppose it wasn't very scientific, but I opened an ssh terminal to both boxes and a local terminal to my machine and just ran "date" in quick succession.
All of the results were within a couple second of each other.

Re: Agents can't resume

PostPosted: Mon Jul 09, 2012 11:25 pm
by williamconley
While that is an interesting method, I prefer:
Code: Select all
ntpq -p

And an interesting point to ponder is that if you sync the servers to the same source, and they get "pushed hard", they may veer slightly and actually get out of sync. But if you sync One to the Other, and then the Other to some external sync source ... it will be very difficult for them to get "out of sync".

When we build a cluster, we ordinarily make the DB server the "master" of the ntp and tell the other servers to trust it implicitly. Then we sync the DB server to government tier 1 servers (thus avoiding "hacker" servers in the general pool).

While this may be overkill, it definitely works. LOL

In your case: if the result of the above command is that several servers are listed, some with "+" next to them and one with "*" next to it, on both servers, you are indeed synced and good to go. Otherwise ...

Code: Select all
nano /etc/ntp.conf


Replace the government servers here with those from your own government if you are not in the US. (or a local server on your network, that you trust will not attack you!)

This is on the "Master" server
Code: Select all
driftfile /var/lib/ntp/drift/ntp.drift
logfile /var/log/ntp

server time-a.nist.gov
server time-b.nist.gov
#server nist1.columbiacountyga.gov
#server time-a.timefreq.bldrdoc.gov
server time.nist.gov
server 127.127.1.0

restrict default nomodify notrap
restrict 127.127.1.0

fudge 127.127.1.0 stratum 10


This is on the "slave" server(s):
Code: Select all
driftfile /var/lib/ntp/drift/ntp.drift
logfile /var/log/ntp

#server 0.north-america.pool.ntp.org
#server 1.north-america.pool.ntp.org
#server 2.north-america.pool.ntp.org
#server 3.north-america.pool.ntp.org
#server pool.ntp.org
server 127.127.1.0

#restrict default nomodify notrap
restrict 127.127.1.0

#fudge 127.127.1.0 stratum 10

server xxx.xxx.xxx.xxx iburst


Then restart the process
Code: Select all
/etc/init.d/ntp restart


Then run that command on both of them again. Slave should sync to master within 30 seconds.