Agent phone rings lately on login

[muyousif]

Hi,

I installed a latest version of vicidial from scratch on Cent OS 7 on cloud, I know it is not recommend but I need to give a demo to a client and cloud was only option available for me. After installation, when I am trying to login as agent from web, it is taking much longer time, call coming to agent phone very lately even after the Error comes no one in your session and vicidial says Call agent again. Any idea what could be possible reason?



VERSION: 2.14-685a
BUILD: 180825-2100

[jmathew]

Just check if you put correct version of asterisk in Admin>Servers>Click on server ID>Asterisk Version.

you can find asterisk version while you do asterisk -r on ssh access.

Something like this:

Connected to Asterisk 1.8.23.0-vici currently running on localhost (pid = 1579)

The asterisk version would be 1.8.23.0-vici

[williamconley]

Hi,

I installed a latest version of vicidial from scratch on Cent OS 7 on cloud, I know it is not recommend but I need to give a demo to a client and cloud was only option available for me. After installation, when I am trying to login as agent from web, it is taking much longer time, call coming to agent phone very lately even after the Error comes no one in your session and vicidial says Call agent again. Any idea what could be possible reason?



VERSION: 2.14-685a
BUILD: 180825-2100

The nature of Virtual Vicidial: Timing is a problem. See if you can get at least 2 cores, preferably 4, and at least 2G RAM on the server. And do NOT try a cluster. Single Server Only. These servers rely on extremely fast inter-server communication. Virtual Vicidial Web sends query to Virtual DB. The DB stores the value. Then the Dialer (eventually) notices the change and makes the call, and notifies the DB. Then (eventually) the Web gets another "update request" from the Agent Screen and sends back the response that the call was made, thus updating the agent screen. With all this happening in Virtual servers possibly using very slow interconnects on physically separated hosts on virtual networks ... you have a recipe for disaster.

But: A single server system handles this all internally. As long as enough resources are available, you should be able to easily get ONE agent perfectly functional for proof of concept.

Next up: Never say "Latest", just provide the full Vicidial Version and the link to the instructions you used to perform the installation.

Last up: If you MUST use CentOS: Use Goautodial's wiki installaton instructions! Seriously! That's what it's for. Still free. Just a version or so behind. And it DOES install the stock Vicidial, just doesn't make the login links immediately obvious. And if you MUST have the Lates Vicidial combined with CentOS, you just install Goautodial and then upgrade. It'll blow away all the custom Goautodial pages, but it'll still be vicidial and still work very well. Gardo did a good job on that.

[muyousif]

Ok I found the error which was stopping AST_manager_send.pl and AST_manager_listen.pl to start in screen sessions.

There was error when AST_manager_listen.pl trying to start..

'Bad named parameter Max_buffer_length''

### connect to asterisk manager through telnet
$tn = new Net::Telnet (Port => $telnet_port,
Prompt => '/.*[\$%#>] $/',
Output_record_separator => '', )
# Max_buffer_length => 4*1024*1024, );

I had to comment that line and after that both process were able to start fine and everything started working normal. Can you please let me know what would be outcomes with commenting this line?

Thanks

[williamconley]

Probably nothing if it's working and you don't get any further errors. Where was this error (which log file)?

We have line 131:

Code: Select all

        ### connect to asterisk manager through telnet
        $tn = new Net::Telnet (Port => $telnet_port,
                                                  Prompt => '/.*[\$%#>] $/',
                                                  Output_record_separator => '',
                                                  Max_buffer_length => 4*1024*1024, );


Our sampler server version of that file shows as (last line of version area to show which version of the file):

Code: Select all

# 170921-2209 - Merged code from AST_manager_listenBUFFER.pl script

[muyousif]

I noticed both screen sessions were not present so I tried to start both scripts with --debugX and caught this error. After commenting Max_buffer_length both script started without any issue.

[williamconley]

Has Vicidial been upgraded since you installed the server?

[muyousif]

No it is fresh installation.

[williamconley]

Code: Select all

free -m

[muyousif]

Code: Select all

[root@ip-172-31-48-212 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:            990         523         112          56         354         221
Swap:             0           0           0
[root@ip-172-31-48-212 ~]#

[edited by williamconley for legibility]

[williamconley]

bingo. Standard installation assumes minimum 2G RAM. You only have 1G. There wasn't enough memory available to set the buffer to the stock value. If you add more memory, you can revert the change (and you'll have a better system) or you can modify 4*1024*1024 to a lower number: try 2*1024*1024 then 1024*1024