vicidial.org

which version of the agent screen are you using? the one that came with vicidial 2.4?

yes the one that come with 2.4 and i have tried with the 2.2 also but still the same problem.

simplest solution: reinstall with vicibox redux.

harder solution: find out why the error occurs ... ordinarily it is because the agents are losing contact with the server, but if it happened as part of an upgrade it could be something else entirely.

back up your data, rebuild the system, make sure it WORKS, then restore your data ... if it stops working at that point, we can "modify" and import your data instead of restoring it so you can still have it.

I have successfully synchronize the time of my server with the vicidial administrative interface but the time in the agent interface is 2 hour less. can someone tell me where to set this time or where to synchronize it please. Does it not syn with the server time?

agent interface time is set by the value of the time zone in the phone definition (it is assumed that phones are stationary and therefor belong in a specific time zone, whereas agents are mobile and may move from zone to zone, so this value is placed in the phone definition instead of the agent definition)

when you post, please post your entire configuration including (but not limited to) your installation method and OS with kernel or version, vicidial version and build, 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.

Similar to This:
Vicibox X.X from .iso | Vicidial X.X.X Build XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation

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)

I had the same error, in my case the mysql table asterisk.server_performance had become corrupt and needed to be repaired. I find that most of the times I see this screen on a regular basis it is best to look into the mysql asterisk tables and repair any which have become corrupted.

This time synchronization error will pop up when your asterisk version number does not end in a 0 or a 1.
The cause is in a limitation in the /usr/share/astguiclient/AST_update.pl script when it tries to connect
via telnet to the asteriskserver. It waits for a telnet response ending in a 0 or a 1. But when you
have Asterisk version 1.3 for instance the script exits with a timeout error and Vicidial will then
send the time synchronization error screen to your agents.

The solution is to modify the following pattern in line 457 :
$t->waitfor('/[01]\n$/');

to:

$t->waitfor('/[0123456789]\n$/');

Then you will be able to run any version of Asterisk without synchronization errors!!

KVM1-port wrote:This time synchronization error will pop up when your asterisk version number does not end in a 0 or a 1.
The cause is in a limitation in the /usr/share/astguiclient/AST_update.pl script when it tries to connect
via telnet to the asteriskserver. It waits for a telnet response ending in a 0 or a 1. But when you
have Asterisk version 1.3 for instance the script exits with a timeout error and Vicidial will then
send the time synchronization error screen to your agents.

The solution is to modify the following pattern in line 457 :
$t->waitfor('/[01]\n$/');

to:

$t->waitfor('/[0123456789]\n$/');

Then you will be able to run any version of Asterisk without synchronization errors!!

AFAIK, no one else has ever had this problem. So ... what version of Vicidial (with Build) are you running?

I have version Asterisk 11.13.1~dfsg-2+b1 here , with Asterisk Call Manager version 1.3.
When I telnet to the server on port 5038
"Asterisk Call Manager/1.3" is displayed. But the AST_update.pl then waits for a "0" or a "1",
and quits after a time-out, because the "3" is obviously not valid.
I had the same issue with the AST_conf_update.pl script
The script failed and on line 259 and 388 I changed the pattern "[01]" into "[0-9]" and the script
finished successfully thereafter.

You know, if you were using the most recent svn/trunk code, that would have already been fixed. We added Asterisk 11 support several months ago, you seem to be using older vicidial code, so I would recommend upgrading.

Can this be a design flaw?

The fact that all os vs db or apache vs db time comparison indicates a design issue

In the first place, time should be handle by os alone.

The db time shouldn't have been queried. It should have been passed as a parameter from os to database table.

Wouldn't this solve the issue.. permanently?