GOautodial Open Source Omni-channel Contact Center Suite

Hi,

You can try to check each of this might be the cause.

- The agent clicking BACK and FORWARD on their web browser while logged in
- anti-virus software suspending the network connection for a few seconds
- network congestion issues between the workstation and the server
- High Load of the server

Cheers
q^_^p

I have this same problem and it is really affecting business.
The agents are not clicking BACK or FORWARD. It happens with Internet Explorer, Mozilla FireFox and Google Chrome.
No anti-virus is running, Windows Firewall and Defender is turned off.
Network is not congested.
Server load is not high.
It does not happen when agents click pause, so pausing from the disposition screen does not apply.

Whenever an agent is showing as Paused with no pause code in the Real-Time report and I go over to that agent, their system is showing them as Ready and waiting for a call. It takes very long (sometimes up to 5 minutes) to display the "Your session has been paused" error. The time being displayed in the agent screen is behind the computer time by a few minutes (sometimes up to 4 minutes behind). When I log the agent out and log them back in, the time in the agent screen matches the computer time and they start to received calls again.
Sometimes (but less frequently) the Real-Time report shows an agent in 'Dead' but they are actually on a call or shows the agent as 'In Call' but they are actually waiting for a call.
The computer time is always in sync with the dialer. It is the agent screen time that gets out of sync.
I have searched through many forums but have not found any explanation or resolution.

Dialer Config
Vicidial: 2.4-309a Build: 110430-1642
Asterisk: 1.4.39.1-vici
Cluster Config: Single Server
Processor: Intel Xeon CPU (8 Cores) @ 2.53GHz
Memory: 8GB
Kernel: 2.6.18-274.3.1.el5.go (SMP)
Distro: CentOS release 5.7 (Final 64bit)
Network: Public Static IP Address (Linux Firewall Enabled)
Additional HW: Sangoma UT-50 (Dahdi 1.03)
Additional SW: WebMin, ProFTPD, NTPD

Agent Config
OS: Windows
SIP: Bria 3 / G.729
Firewall: Linux (pfSense)
Timesync: synced with NTPD on dialer.

Please let me know what else I need to provide in order to resolve this issue.

Go to the user stats and see what the hang up reason is. Caller and Agent is fine, None and Abandon is also ok, but if you can see LAGGED, then your network is congested in some point. The LAGGED status says, server and client lost the connection and the client cannot correctly send its messages to the server. That's why you see things different as the agent does.

How many agents do you have at the same time ? Sometimes it helps to tweak apache, setting min_workers and max_workers. If you have less then 50 Agents, apache should not be blamed.

Do you see some LAGGED status ?

+1 Subscribing

We have less than 50 agents. Between 15-20 at any given time.
I have seen LAGGED in the Agent Time Detail Report but very rarely and usually only between 1-5 seconds for the entire day. In this report there is always a column with no column heading where the unexplained pauses are calculated.
This problem has affected every agent. I have computers from different manufacturers with different NICs; some have Windows XP, some have Windows Vista and others have Windows 7. I have tried three different network hubs from different manufacturers.
It is hard to correct a problem when you can't determine its cause and this problem occurs so randomly.

Hi Ruth,

Kindly check the following. Can you also post your server specs? Is it single or multi-servers?

- The agent clicking BACK and FORWARD on their web browser while logged in
- anti-virus software suspending the network connection for a few seconds
- network congestion issues between the workstation and the server
- High Load of the server

Regards,
Levy

I have this same problem and it is really affecting business.

The agents are not clicking BACK or FORWARD. It happens with Internet Explorer, Mozilla FireFox and Google Chrome.
No anti-virus is running, Windows Firewall and Defender is turned off.
Network is not congested.
Server load is not high.
It does not happen when agents click pause, so pausing from the disposition screen does not apply.

Whenever an agent is showing as Paused with no pause code in the Real-Time report and I go over to that agent, their system is showing them as Ready and waiting for a call. It takes very long (sometimes up to 5 minutes) to display the "Your session has been paused" error. The time being displayed in the agent screen is behind the computer time by a few minutes (sometimes up to 4 minutes behind). When I log the agent out and log them back in, the time in the agent screen matches the computer time and they start to received calls again.

Sometimes (but less frequently) the Real-Time report shows an agent in 'Dead' but they are actually on a call or shows the agent as 'In Call' but they are actually waiting for a call.
The computer time is always in sync with the dialer. It is the agent screen time that gets out of sync.
I have searched through many forums but have not found any explanation or resolution.

Dialer Config

Vicidial: 2.4-309a Build: 110430-1642
Asterisk: 1.4.39.1-vici
Cluster Config: Single Server
Processor: Intel Xeon CPU (8 Cores) @ 2.53GHz
Memory: 8GB
Kernel: 2.6.18-274.3.1.el5.go (SMP)
Distro: CentOS release 5.7 (Final 64bit)
Network: Public Static IP Address (Linux Firewall Enabled)
Additional HW: Sangoma UT-50 (Dahdi 1.03)
Additional SW: WebMin, ProFTPD, NTPD

Agent Config

OS: Windows
SIP: Bria 3 / G.729
Firewall: Linux (pfSense)
Timesync: synced with NTPD on dialer.

Please let me know what else I need to provide in order to resolve this issue.

Folks,
We are having the same problem with similar Asterisk version (2.4). We don't see any load and/or lagging issues within our network. In fact we just got off a good holiday with 800 agents using the system with no problems. About 2 weeks ago we started seeing a problem with agents being put on pause automatically and is continuing to happen on a daily basis. It happens only at peak usage times though, yet the server stats show very minimal usage.

Hoping to see if any solution to above scenario may put us in the right direction.

Thanks,