Aws Asterisk Vicidial Time Snyc Problem

[albertgacute]

Hello,

I would like to ask if there is anyone that have configured successfully a working asterisk, vicidial set up on aws. Outbound, Inbound, all functionalities of a vicidial system? as we are experiencing time snyc problems

I have configured and installed the following

Scratch Installation | Vicidial 2.14-697a Build 190121-2019 | Asterisk 15.7.1 | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Cloud AWS Server | M4XLARGE EC2 INSTANCE 4CPU 16GB

Sources for Installation are

https://linuxize.com/post/how-to-instal ... -centos-7/
http://uniquesupport.blogspot.com/2014/ ... entos.html
https://my.cloudastrix.com/knowledgebas ... cle&id=200

We have transferred a database from a working set up of below

VERSION: 2.12-549a BUILD: 160404-0940 | Asterisk 1.8.23.0 Vici |

database upgrade was followed and provided no errors. Screen running are below

11441.ASTconf3way (Detached)
11438.ASTVDadapt (Detached)
14850.ASTVDremote (Detached)
14847.ASTVDauto (Detached)
14844.ASTlisten (Detached)
14841.ASTsend (Detached)
14838.ASTupdate (Detached)
5958.asterisk (Detached)
5898.ASTfastlog (Detached)
5841.astshell20190128133200 (Detached)

We can see, sip show peers without error as well and says eyebeam is connected.

Have updated time and other troubleshooting based on below source

https://striker24x7.blogspot.com/2012/1 ... idial.html

Would appreciate the help and would like to ask again if there is a working system that was installed on aws and if it is worth to invest on the cloud server, AWS particularly

thank you

[mflorell]

We do not recommend using any type of virtual machine for VICIdial use. The time-sync issue is one of the biggest reasons. Poor audio quality, system instability and decreased capacity per server are some others.

We have not done any testing on Asterisk 15 with VICIdial. Also, Asterisk 15 is a short term release that will no longer be supported by Digium in a matter of months.

[albertgacute]

Thank you. Does this mean that no one really tries or well someone have tried to make a system on cloud but as you said, it will always be prone to those errors and functionality, quality problems

[mflorell]

Of course a lot of people have tried, but the shortcomings of any VM platform are very apparent on real-time media systems like Asterisk, and if you operate on a VM platform you just have to accept that it will operate at a reduced capacity with reduced reliability.

You have to remember what a VM is: In essence, an additional bottleneck between your running Linux system and the hardware it runs on. It is by necessity a throttling and limiting force for access of your Linux system to that hardware, and because of that it can never be run at the capacity or reliability of that same Linux system running on bare hardware.

[williamconley]

Thank you. Does this mean that no one really tries or well someone have tried to make a system on cloud but as you said, it will always be prone to those errors and functionality, quality problems

1) Yes people have tried.
2) Yes people are STILL trying.
3) Yes many of those tried/trying are seriously professional and know what they are doing.
4) In the end, they admit that there are limitations that do not allow heavy use and virtualization. Very light use, in some cases, works well.
5) CLOUD is not virtual. Those words are not synonymous. You can have a hardware/dedicated server in the cloud. You can also have a VPN or actual "cloud" which should really be reserved for "shared resource pool" applications, but most people just think "it's not in my office, so it's in the cloud". For example: Vicihost.com is considered a "cloud-based" hosting system by many people. It's actually dedicated servers leased to clients (just like we do at PoundTeam.com, even though we have a mix of dedicated and virtualized).

[albertgacute]

Thank you william, could you help me a bit though, on where can i check possible errors, on why i am having time snyc problems.

i am quite on a roadblock on where to look as i have already done all troubleshooting i can have under my knowledge on the system and all screens running as well, etc

thank you

[williamconley]

Time sync bakes down to two possibilities:

1) Time is wrong somewhere in the system (ie: it does not agree with another place in the system, thus out of sync). Ordinarily this only happens on a multi-server system where at least one server is actually showing a time different than the others by more than just a second or two. If you have a single server system, it's unlikely to be this.

2) The field that is updated every second for live agents is not being updated. This can be because ...

* The agent's web client is not getting packets back to the server reliably
* The script responsible for the update in question is misfiring

You have a virtualized system. This also includes (quite likely) a virtualized network. Between those two, it's entirely possible that packets are being delayed enough to be too late and cause "out of sync". This is not viable on a system that's expected to make decisions in a nanosecond. More than one second "off" is bad, but The Vicidial Group has set the tolerance to (I believe) about six seconds. If your system is off (out of sync OR late OR missing the updates entirely) by as much as six seconds, it'll never be right. Agents won't get data they need, the Vicidial server will be making decisions with outdated or flat-out incorrect data.

So the system tosses that poorly worded "time-sync" error to alert you to the problem.

Dropping packets? Delay between agent web browser, virtual network, and virtual server's apache/php script and then DB?

There are ... quite a few posts on this topic. But they almost all boil down to:
* Web clients dropping packets (often in a firewall or bad internet device)
* Vicidial servers actually have different times on them (ntp process not running properly?)
* Delays on an overloaded server or scripts NOT running properly on that server (this one's not as prevalent, but when the server is virtual it becomes MUCH more likely)

Is the server "RED" if you look at the server list under "Reports" tab?

[albertgacute]

Vicidial servers actually have different times on them (ntp process not running properly?)

*i can try and use another servers to get the timezone updated , i saw a post that it should be included as well on the rclocal service

Delays on an overloaded server or scripts NOT running properly on that server (this one's not as prevalent, but when the server is virtual it becomes MUCH more likely)

What script can i check to see if there will be errors as all screens are displayed. I would assume its the AST Send and Listen? or nope. would just run each script with --debugx if there would errors

Is the server "RED" if you look at the server list under "Reports" tab?

As per checking, no it is not

**** i have also gotten time snyc errors and was able to troubleshoot it but this was on a local server i established in our office so i get there really is a gap on time on aws if thats the case.

Thank you william

[albertgacute]

i forgot, i transferred a database from a multi server, two server running, and deleted the other server after doing the upgrade. does this have something to do with it?

but since i deleted the secondary server that was listed. i would assume all data that was under it was as well delete

[williamconley]

If it wasn't red, it isn't likely a misfiring script. If the agent's phone rings, and the agent answers it, then you likely have a networking issue which may very well be related to the virtual nature of the server itself.

If not sure, look at the live agents table and watch the time field update (vicidial_live_agents: random_id) every second. If it does not ... then the update packet is not having the desired effect. Somewhere between your agent and the execution of the sql command you lose it. Find out where.

i forgot, i transferred a database from a multi server, two server running, and deleted the other server after doing the upgrade. does this have something to do with it?

but since i deleted the secondary server that was listed. i would assume all data that was under it was as well delete

There is no "data under it". You deleted the "record of the existence of a server". That's a single line in a single table. That's all there was. You did not delete all the calls, logs, phones, etc, assigned to that server, they are still there. This is not a Microsoft SQL cascade-deleting record system. All calls and other records are related to VICIDIAL and may have a server IP as a "side-note" that they touched that server at some point. But those records don't "belong" to the server at all. Same with a user or other record in Vicidial: Deleting a user does not delete the records associated, just the line you would have seen in "Users", that one line would be gone. You can even put the user back, and run reports that will include those logs that were never deleted.

Did you run the "IP Update Script"? It's shown in the splash screen during ssh/console login. Reboot is needed after running this script.

If you brought your database from another system, then you may need to update your Admin->System Settings to match your new system as well as your Admin->Servers settings to reflect your Asterisk version. It's also worth mentioning if you brought anything other than the database from the old system to the new one.

[albertgacute]

yes i did, i followed the upgrade instructions, got no errors on it and reboot as advised. have run the IP update script as well.

One thing i noticed is that once we test the system, there is no ring as well upon agent log in. I solved this before by running the update ip script but it did not work this time

[williamconley]

there is no ring as well upon agent log in

Well, that's your problem. It's possible (likely) that your system has the incorrect asterisk information.

I note you didn't state whether you brought more than just the DB from the prior system. did you copy other files as well?

There were other suggestions about the upgrade, too ... system settings, server settings ...

Most often the Asterisk Version in the admin->server settings (and in /etc/astguiclient.conf) are wrong, causing all sorts of problems with asterisk. Then your vicidial screens don't start properly and (usually) the server turns red. But not always. Sometimes asterisk will start, but the commands don't match the version of asterisk so many processes just fail.

If you run asterisk -V at the cli and compare that to the asterisk version in server settings ... do they match? what are they? and what's the value for asterisk version in astguiclient.conf?

Plus what values did you run the admin ip update script using? If you used the wrong values the last time, that would also break vicidial.

[albertgacute]

Most often the Asterisk Version in the admin->server settings (and in /etc/astguiclient.conf) are wrong, causing all sorts of problems with asterisk. Then your vicidial screens don't start properly and (usually) the server turns red. But not always. Sometimes asterisk will start, but the commands don't match the version of asterisk so many processes just fail

**Have made sure that the version matches the system, 15.7.1

If you run asterisk -V at the cli and compare that to the asterisk version in server settings ... do they match? what are they? and what's the value for asterisk version in astguiclient.conf?

** Have check this and its the same as well 15.7.1

Plus what values did you run the admin ip update script using? If you used the wrong values the last time, that would also break vicidial?

** the vicidial system that the database is from is VERSION: 2.12-549a BUILD: 160404-0940

so i run the script 2.12 and 2.14, and i got no errors on it. I was able to log in, view the data all there from the old servers

[williamconley]

Vicidial is not compatible with asterisk 15 AFAIK

How did you install your server? Vicibox.com's .iso? If not, that could be your problem.