vicidial.org

by **voipart** » Fri Feb 17, 2012 5:01 am

by **williamconley** » Fri Feb 17, 2012 6:16 pm

Post server load when this happens.

also try to capture agi logs (check /var/log/astguiclient) from an occurrence.

sounds like it could be overload, but since you have a scratch install I'm really more likely to believe it is installation related purely by reflex. in which case I would definitely suggest a Vicibox install to remove that possibility.

by **voipart** » Sat Feb 18, 2012 4:02 am

Pls find Logs

Two Sample calls which came to one agent

INBOUND/CLOSER CALLS FOR THIS TIME PERIOD: (10000 record limit)

# DATE/TIME LENGTH STATUS PHONE CAMPAIGN WAIT (S) AGENT (S) LIST LEAD HANGUP REASON
90 2012-02-16 11:09:27 58 BC 2223865033 RSEC_CNT 0.00 58 100 369673 CALLER
91 2012-02-16 11:09:12 73 Tra 2227714052 RSEC_CNT 0.00 73 999 369573 CALLER
=======================================================================================================================

From File : action_full.2012-02-16
==============================
|
2012-02-16 11:09:27|1248937|0|1|
Action: Originate
Exten: 83047777777777
Context: vicidial-auto
Channel: Local/010*064*020*021*78600097@default
Priority: 1
Callerid: "ding" <ding>
Timeout: 10

|
2012-02-16 11:09:27|1248927|1|||
2012-02-16 11:09:27|1248927|2|||
2012-02-16 11:09:28|1248929|1|||
2012-02-16 11:09:28|1248929|2|||
2012-02-16 11:09:28|1248931|1|||
2012-02-16 11:09:28|1248931|2|||
2012-02-16 11:09:28|1248933|1|||
2012-02-16 11:09:28|1248933|2|||
2012-02-16 11:09:28|1248939|0|1|
Action: Originate
Exten: 83047777777777
Context: vicidial-auto
Channel: Local/010*064*020*021*78600076@default
Priority: 1
Callerid: "ding" <ding>
Timeout: 10

|
2012-02-16 11:09:28|1248935|1|||
2012-02-16 11:09:28|1248935|2|||
2012-02-16 11:09:29|1248941|0|1|
Action: Originate
Exten: 83047777777777
Context: vicidial-auto
Channel: Local/010*064*020*021*78600063@default
Priority: 1
Callerid: "ding" <ding>
Timeout: 10

|
2012-02-16 11:09:29|1248937|1|||
2012-02-16 11:09:29|1248937|2|||
2012-02-16 11:09:29|1248943|0|1|
Action: Originate
Channel: Local/58600076@default
Context: default
Exten: 8309
Priority: 1
Callerid: IN_RSC_20120216-110928_2223865033_70081972

|
2012-02-16 11:09:29|1248945|0|1|
Action: Hangup
Channel: SIP/10.64.20.21-b2342168

|
2012-02-16 11:09:29|1248947|0|1|
Action: Hangup
Channel: SIP/10.64.20.21-b2342168
Variable: ctuserserverconfleadphone=0_70081895_10.64.20.21_8600074_369625_9219992365

|
2012-02-16 11:09:29|1248949|0|1|
Action: Hangup
Channel: Local/58600074@default-8d8f,2

|
2012-02-16 11:09:30|1248939|1|||
2012-02-16 11:09:30|1248939|2|||
2012-02-16 11:09:30|1248951|0|1|
=======================================================================

File:action_process.2012-02-16
-------------------------------

|
2012-02-16 11:09:11|SQL_QUERY|UPDATE vicidial_manager set status='SENT' where man_id='1248903'||
2012-02-16 11:09:12|SQL_QUERY|SELECT man_id,uniqueid,entry_date,status,response,server_ip,channel,a
ction,callerid,cmd_line_b,cmd_line_c,cmd_line_d,cmd_line_e,cmd_line_f,cmd_line_g,cmd_line_h,cmd_lin
e_i,cmd_line_j,cmd_line_k FROM vicidial_manager where server_ip = '10.64.20.21' and status = 'QUEUE
' order by man_id limit 1||
2012-02-16 11:09:12|----BEGIN NEW COMMAND----
CallerID: XLvdcW13293707353297
Action: Redirect
Channel: SIP/10.64.20.21-087ba430
Context: default
Exten: 990009*RSEC_CNT**369573**2227714052*70093297**
Priority: 1
CallerID: XLvdcW13293707353297

----END NEW COMMAND----

|
2012-02-16 11:09:29|SQL_QUERY|UPDATE vicidial_manager set status='SENT' where man_id='1248941'||
2012-02-16 11:09:29|SQL_QUERY|SELECT man_id,uniqueid,entry_date,status,response,server_ip,channel,a
ction,callerid,cmd_line_b,cmd_line_c,cmd_line_d,cmd_line_e,cmd_line_f,cmd_line_g,cmd_line_h,cmd_lin
e_i,cmd_line_j,cmd_line_k FROM vicidial_manager where server_ip = '10.64.20.21' and status = 'QUEUE
' order by man_id limit 1||
2012-02-16 11:09:29|----BEGIN NEW COMMAND----
CallerID: IN_RSC_20120216-1109
Action: Originate
Channel: Local/58600076@default
Context: default
Exten: 8309
Priority: 1
Callerid: IN_RSC_20120216-110928_2223865033_70081972

----END NEW COMMAND----

=====================================================================
MySQLerror.2012-02-16
---------------------

2012-02-16 11:22:54|11:22:54|agi-VDAD_ALL_inbound.agi|02147||1062|Duplicate entry '1329370794.51950
' for key 1|INSERT INTO vicidial_log_extended set uniqueid='1329370794.51950',server_ip='10.64.20.2
1',call_date='2012-02-16 11:22:54',lead_id = '369681',caller_code='Y2161122540000369681',custom_cal
l_id='';|Y2161122540000369681|369681|
2012-02-16 11:27:48|11:27:49|agi-VDAD_ALL_inbound.agi|02147||1062|Duplicate entry '1329371703.52715
' for key 1|INSERT INTO vicidial_log_extended set uniqueid='1329371703.52715',server_ip='10.64.20.2
1',call_date='2012-02-16 11:27:48',lead_id = '369897',caller_code='Y2161127480000369897',custom_cal
l_id='';|Y2161127480000369897|369897|
2012-02-16 11:27:56|11:27:57|agi-VDAD_ALL_inbound.agi|02147||1062|Duplicate entry '1329371842.52824
' for key 1|INSERT INTO vicidial_log_extended set uniqueid='1329371842.52824',server_ip='10.64.20.2
1',call_date='2012-02-16 11:27:56',lead_id = '369937',caller_code='Y2161127560000369937',custom_cal
l_id='';|Y2161127560000369937|369937|
2012-02-16 11:28:03|11:28:03|agi-VDAD_ALL_inbound.agi|02147||1062|Duplicate entry '1329371844.52829
' for key 1|INSERT INTO vicidial_log_extended set uniqueid='1329371844.52829',server_ip='10.64.20.2
1',call_date='2012-02-16 11:28:03',lead_id = '369939',caller_code='Y2161128030000369939',custom_cal
l_id='';|Y2161128030000369939|369939|
2012-02-16 11:31:40|11:31:40|agi-VDAD_ALL_inbound.agi|02147||1062|Duplicate entry '1329372054.53050
' for key 1|INSERT INTO vicidial_log_extended set uniqueid='1329372054.53050',server_ip='10.64.20.2
1',call_date='2012-02-16 11:31:40',lead_id = '369999',caller_code='Y2161131400000369999',custom_cal
l_id='';|Y2161131400000369999|369999|

by **voipart** » Sat Feb 18, 2012 4:59 am

Server load on peek hour

IP ACT LOAD CHAN DISK
10.64.20.21 Y 565 - 6% 196 58%

by **williamconley** » Sat Feb 18, 2012 4:24 pm

agi logs as in the decision making process. showing the "transfer of the call" is not entirely useful.

also for server load, i meant the 1/5/10 minute averages from "top/htop/uptime" any of those commands, not from the vicidial interpretation. and not from "peek hour", but from the moment of the occurrence.

since the linux server load from a command such as htop will show the previous 1/5/10 minute load averages, you should be able to grab the server load (hopefully within in 1 minute, but certainly within 5) to see if there was an overload.

the number of processors should be double that of the highest server load listed (ie: if you have 4 processors, your server load should not exceed 2.0 in the 1, 5 or 10 minute averages or you are indeed overloaded).

by **voipart** » Mon Feb 20, 2012 1:23 am

Regarding Load it is as fallows
1: Server A- Asterisk
top - 11:52:04 up 12 days, 15:29, 9 users, load average: 1.71, 1.81, 1.66
Tasks: 183 total, 1 running, 182 sleeping, 0 stopped, 0 zombie
Cpu(s): 4.5%us, 1.4%sy, 0.0%ni, 88.1%id, 5.8%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 33279016k total, 7050256k used, 26228760k free, 325100k buffers
Swap: 0k total, 0k used, 0k free, 6267268k cached

2.Server B: DB and Web
top - 11:53:17 up 20 days, 14:35, 1 user, load average: 0.15, 0.45, 0.63
Tasks: 136 total, 1 running, 135 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.4%us, 0.7%sy, 0.0%ni, 95.8%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 33279012k total, 22741056k used, 10537956k free, 195080k buffers
Swap: 1044216k total, 0k used, 1044216k free, 21684408k cached

-----------------

How about those MySQL errors? is that gives any reason?
Also do I need to check on any other log other than posted before?

by **williamconley** » Mon Feb 20, 2012 12:01 pm

1) reboot your server nightly

2) "load it is as follow" is not what was requested. i need to see the load at the moment you have this problem. the load now is not entirely helpful. also: the load without the number of processors ... is not entirely useful. huge difference between an 8 processor system and a 2 processor system.

3) look in the /var/log/astguiclient log folder. Read ALL of them until you find one with agi information. if you have logging turned off, turn it on (admin->servers, choose your server, and turn logging on!).

by **voipart** » Tue Feb 21, 2012 5:13 am

Hello Willima, Thanks for the prompt reply
the fallowing is the load in the Servers (with in 2 min of the problem happened today )

Asterisk Server (HP ProLiant DL360 G5 - QuadCore Xion 2.0Ghz x 2 )
top - 14:57:14 up 13 days, 18:34, 9 users, load average: 4.45, 3.29, 2.96
Tasks: 180 total, 1 running, 179 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.8%us, 2.2%sy, 0.0%ni, 76.5%id, 17.1%wa, 0.0%hi, 0.4%si, 0.0%st
Mem: 33279016k total, 16563340k used, 16715676k free, 267344k buffers
Swap: 0k total, 0k used, 0k free, 15769120k cached

Asterisk Server (HP ProLiant DL380 G5 - QuadCore Xion 2.0Ghz x 2 )
top - 15:01:06 up 21 days, 17:43, 1 user, load average: 0.52, 0.72, 0.81
Tasks: 137 total, 1 running, 135 sleeping, 0 stopped, 1 zombie
Cpu(s): 5.0%us, 1.3%sy, 0.0%ni, 93.5%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 33279012k total, 22223100k used, 11055912k free, 198972k buffers
Swap: 1044216k total, 0k used, 1044216k free, 21151248k cached

Regarding reboot in Night: Being this application is 24x7 reboot is a tuff call ( but we can plan a weekly reboot)

Details pf Processor for Asterisk Server as fallows:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
stepping : 11
cpu MHz : 2000.181
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
stepping : 11
cpu MHz : 2000.181
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 1

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
stepping : 11
cpu MHz : 2000.181
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 2

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
stepping : 11
cpu MHz : 2000.181
cache size : 4096 KB
physical id : 0
siblings : 4

processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
stepping : 11
cpu MHz : 2000.181
cache size : 4096 KB
physical id : 1
siblings : 4
core id : 0

processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
stepping : 11
cpu MHz : 2000.181
cache size : 4096 KB
physical id : 1
siblings : 4
core id : 1

processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
stepping : 11
cpu MHz : 2000.181
cache size : 4096 KB
physical id : 1
siblings : 4
core id : 2

processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
stepping : 11
cpu MHz : 2000.181
cache size : 4096 KB
physical id : 1
siblings : 4
core id : 3

by **voipart** » Fri Feb 24, 2012 3:14 am

Hi William
Any thing you could judge with this..

Any one else with same problem of two inbound calls to one agent (ware callers can talk to each others)

by **DomeDan** » Fri Feb 24, 2012 4:49 am

I have similar problem, but on outbound.
In the beginning we had no idea why this happen, but now agents have come to the conclusion that it happens when they go from READY to PAUSE and starts to make manual callback.

by **voipart** » Fri Feb 24, 2012 2:36 pm

Any Idea why this is happens ?
is it any chance the dialer missing to update the database?
if it so where can we get such log?

by **DomeDan** » Mon Feb 27, 2012 3:34 am

I would guess something like that, maybe because of a load-peak, I haven't looked in to it.
Regarding the logs, check all files in /var/log/astguiclient/ and /srv/www/htdocs/agc/vicidial_debug.txt & vicidial_mysql_errors.txt might contain some clues

by **voipart** » Wed Apr 25, 2012 1:03 am

I made a small php script running with Real time monitor as i have at least 2 guys see realtime monitor with 4 sec refreshing,
the script look for any conference room with more than 2 calls( other than local agents or extensions) and i could trace the incident of 2 calls to same agent, now I made to disconnect second call, so now the problem is resolved, with a cost of disconnecting one incoming call automatically

by **DomeDan** » Wed Apr 25, 2012 2:25 am

Cool, but it would be nice to get too the root of the problem,
if you log stuff with your script you might be able to find a pattern

by **cbsys** » Wed May 02, 2012 7:02 am

We have several sites out there showing the same problem on outbound calls
Campaign is outbound only
Agents are in a conference and speaking to a lead contact
a 2nd lead contact joins the same conference and all 3 are joined together

by **franklinsj** » Wed Jun 05, 2013 10:17 am

voipart wrote:I made a small php script running with Real time monitor as i have at least 2 guys see realtime monitor with 4 sec refreshing,
the script look for any conference room with more than 2 calls( other than local agents or extensions) and i could trace the incident of 2 calls to same agent, now I made to disconnect second call, so now the problem is resolved, with a cost of disconnecting one incoming call automatically

Hi I am having the same issue with inbound calls. Would it be possible for you to share that script?

Thanks,

by **adam.greenhalgh1** » Wed Jun 05, 2013 11:04 am

Ive had a issue like this before, and i search high and low for a solution. We updated our servers and pointed them to the same NTP server. Only because there was information stating that it could be down to a time synchronization issue.
THAT WAS WRONG.

After a few months of figuring it out etc. We was doing a desk move and realized that in actual fact. It was nothing to do with the servers config.

The issue was that the advisor had a faulty mouse!!!! In which clicked dial_lead twice! Thus giving two calls to the advisor.

Id suggest changing peripherals before digging too deep - hopefully this is helpful

Adam.

by **franklinsj** » Wed Jun 05, 2013 11:29 am

Thank you for your response! Yes I have seen that behavior before for outbound calls, it also happens if agents are used to double click on everything. However in this particular case I don't think that would be the problem because I am dealing with inbound calls.

I restart all servers nightly and server loads are usually very close to 0. The amount of processors per asterisk server is 4 and load does not exceed 0.20. DB server is not reaching 0.10 and it is multiprocessor as well.

by **adam.greenhalgh1** » Thu Jun 06, 2013 3:27 am

I'm not too savvy with inbound as I've literally only dealt with Outbound.

Have you checked the Identities on the soft phone? There could be 2 identical exts on the phone which is giving you 2x calls?
Do you have any priority settings that are active/Or Delay settings?? Because maybe the dialer is giving you a prioritized lead aswell as one that has exceeded wait time.

As i said, not to savvy with inbound but more than happy to try and help

Adam.

by **franklinsj** » Thu Jun 06, 2013 12:19 pm

The extensions are distributed and there are no duplicate extensions, some inbound queues have higher priority others but not sure if that would be what is causing the issue. I will have to see whenever that happens again and trace where the calls are comming from. Still a script like the one mentioned by voipart would be a temporary fix. Thanks again from your help

by **adam.greenhalgh1** » Fri Jun 07, 2013 3:24 am

Okay, so when the agents are waiting for a call - they will be in a particular 'state' Ready - Paused etc.

When they receive calls does the 'state' of the agent change? I.e. does it change to paused or Incall.

Attempt to watch the Real-Time report and assess whether this is happening or not. Defining the problem is the hard part

by **franklinsj** » Wed Jun 12, 2013 1:22 pm

Hi. Thanks for the reply again. Since this does not happen very frequently it is a little difficult to debug but on the realtime screen the just show as Incall I which should be ok,

I also ran screen -list on each server and this is what DB, Web and Archive server showed No Sockets found in /var/run/screens/S-root. which if I am not mistaken might be causing a lot of issues.

Then i did the same on each asterisk server and they showed something like this

1658.ASTfastlog (Detached)
1655.ASTVDremote (Detached)
1652.ASTVDauto (Detached)
1649.ASTlisten (Detached)
1646.ASTsend (Detached)
1643.ASTupdate (Detached)
1558.asterisk (Detached)
1553.astshell20130612040345 (Detached)
8 Sockets in /var/run/screens/S-root.

DB, Web and Archive server's crontab is empty besides a line that i put there for nightly reboot but asterisk server's crontab has

### keepalive script for astguiclient processes
* * * * * /usr/share/astguiclient/ADMIN_keepalive_ALL.pl

### remove old vicidial logs and asterisk logs more than 2 days old
28 0 * * * /usr/bin/find /var/log/astguiclient -maxdepth 1 -type f -mtime +2 -print | xargs rm -f
29 0 * * * /usr/bin/find /var/log/asterisk -maxdepth 3 -type f -mtime +2 -print | xargs rm -f
30 0 * * * /usr/bin/find / -maxdepth 1 -name "screenlog.0*" -mtime +4 -print | xargs rm -f
### recording mixing/compressing/ftping scripts
#0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_mix.pl
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_mix.pl --MIX
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_VDonly.pl
1,4,7,10,13,16,19,22,25,28,31,34,37,40,43,46,49,52,55,58 * * * * /usr/share/astguiclient/AST_CRON_audio_2_compress.pl --MP3
2,5,8,11,14,17,20,23,26,29,32,35,38,41,44,47,50,53,56,59 * * * * /usr/share/astguiclient/AST_CRON_audio_3_ftp.pl --MP3
#0 1 * * * /usr/share/astguiclient/AST_CRON_audio_4_ftp2.pl --ftp-server=server.ip --ftp-login=user --ftp-pass=pass --ftp-dir$

### kill Hangup script for Asterisk updaters
* * * * * /usr/share/astguiclient/AST_manager_kill_hung_congested.pl

### updater for voicemail
* * * * * /usr/share/astguiclient/AST_vm_update.pl

### updater for conference validator
* * * * * /usr/share/astguiclient/AST_conf_update.pl

### flush queue DB table every hour for entries older than 1 hour
11 * * * * /usr/share/astguiclient/AST_flush_DBqueue.pl -q

### reset several temporary-info tables in the database
2 1 * * * /usr/share/astguiclient/AST_reset_mysql_vars.pl

### remove old recordings more than 7 days old, and delete originals after 1 day
#24 0 * * * /usr/bin/find /var/spool/asterisk/monitorDONE -maxdepth 2 -type f -mtime +7 -print | xargs rm -f
24 1 * * * /usr/bin/find /var/spool/asterisk/monitorDONE/ORIG -maxdepth 2 -type f -mtime +1 -print | xargs rm -f

### Reboot nightly to manage asterisk issues and memory leaks - uncomment if issues arise
00 4 * * * /sbin/reboot

### remove text to speech file more than 4 days old
#20 0 * * * /usr/bin/find /var/lib/asterisk/sounds/tts/ -maxdepth 2 -type f -mtime +4 -print | xargs rm -f

Should I put the same crontab on the DB server or would it still be missing anything? and what should I put on the Web and Archive server's crontab? Should I also activate keep alive 5 and 7 in one of the asterisk servers even though this is supposed to be active in the DB server too?

Thanks

by **franklinsj** » Thu Jun 13, 2013 12:27 pm

Like I said in previous post I changed crontab in DB, WEB and Archive servers for them to be able to load keepalives. The keepalives. Screen list shows now as follows:

DB: astguiclient.conf VARactive_keepalives => 123456789
There are screens on:
1072.ASTVDremote (Detached)
1069.ASTVDauto (Detached)
2796.ASTVDautoFILL (Detached)
2794.ASTfastlog (Detached)
2792.ASTVDadapt (Detached)
5 Sockets in /var/run/screens/S-root.

Web: VARactive_keepalives => 123468
There are screens on:
482.ASTVDauto (Detached)
3071.ASTfastlog (Detached)
2 Sockets in /var/run/screens/S-root.

Archive: VARactive_keepalives => 123468
There are screens on:
32712.ASTVDauto (Detached)
1490.ASTfastlog (Detached)
2 Sockets in /var/run/screens/S-root.

Asterisk 1: VARactive_keepalives => 12345678
There are screens on:
1652.ASTVDautoFILL (Detached)
1649.ASTfastlog (Detached)
1646.ASTVDadapt (Detached)
1643.ASTVDremote (Detached)
1640.ASTVDauto (Detached)
1637.ASTlisten (Detached)
1634.ASTsend (Detached)
1631.ASTupdate (Detached)
1546.asterisk (Detached)
1541.astshell20130613040345 (Detached)
10 Sockets in /var/run/screens/S-root.

Asterisk 2 : VARactive_keepalives => 123468
There are screens on:
1645.ASTfastlog (Detached)
1642.ASTVDremote (Detached)
1639.ASTVDauto (Detached)
1636.ASTlisten (Detached)
1633.ASTsend (Detached)
1630.ASTupdate (Detached)
1545.asterisk (Detached)
1540.astshell20130613040235 (Detached)
8 Sockets in /var/run/screens/S-root.

Hopefully someone can tell me whether or not the above settings are correct. Still today got a case of an agent getting 2 inbound customers on the line:

This is from the vicidial_close_log table. The first call comes in, about a minute later comes another phone call from another client, apparently it changes the phone number information on the agent's interface, since first call is not handled by the agent's interface it stays in INCALL status, second client gets confused about what's going on and hangs up so the agent and the client that was talking to originally continue with the conversation but agent shows in Dead status in realtime view report. The second client calls again and finally is routed to another agent. Once the agent hangs up, the disposition selected by the agent is applied to the phone number of the 2nd client and the 1st client remains in INCALL status.

by **DomeDan** » Fri Jun 14, 2013 3:10 am

I'm pretty sure you should not be running those screens on the DB, web and archive,
find out what script the screens are running and read what they do and you will be able to figure out who should run them and if there is a chance to get into trouble if the script runs by multiple servers.
I only use 1 asterisk server so I'm not very familiar with this stuff,
but my DB server does not run any screens and I have stopped the cron daemon

by **franklinsj** » Mon Jun 17, 2013 8:53 am

Following your recommendation I turned of keepalives on DB, web and archive since i was experiencing the same issues anyways and turned on all keepalives on one of the asterisk servers and on the other 2 set them to 123468 and still same issues. Looking at other examples of the issue looks like it always involves inter-server calls so i transferred the problematic campaign to a single asterisk server to see what happens. I will post results later. Thanks for your help.

by **franklinsj** » Fri Jun 21, 2013 12:22 pm

After moving the campaign to a single asterisk server there were no incidents of 2 clients going to one agent for about 3 days but yesterday it started happening again. Seems like this involves calls from different ingroups going to the same agent, like if something coming from an ingroup sometimes could not detect when an agent is on a call from another ingroup. All ingroups were set up with next agent call oldest_inbound_call_finish not sure if ingroups were just taking into account their own calls and not other ingroups calls. I changed that value to oldest_call_finish. I will post back with more observations.

*****If anywone else is experiencing this or has any suggestions i would appreciate their participation on this. Thanks. ****

by **Nefariousparity** » Thu Nov 14, 2013 5:46 pm

I know this is an old thread. But I am someone who experiences this.

I have agent who is part of two ingroups. Sometimes while in mid call, another person will call in, and and both customers are on the line as well as agent, and everyone can hear everyone.

by **williamconley** » Thu Nov 14, 2013 8:20 pm

1) upgrade to latest to see if the problem fixes itself (why fix a fixed bug)
2) post cli output from an example and seriously consider posting the relevant /var/log/astguiclient output (which may require turning on admin->servers->(choose your server) agi debugging to "file" or "both".
3) server load from the moment of an occurrence. i prefer output from "htop" top right corner which shows 1,5,10 minute average server loads. also share the number of total cores in your server (physical, without hyperthreading on).

by **cbsys** » Fri Nov 15, 2013 4:58 am

could this be down to multiple servers having the same conference room numbers?

What if we try and make the conference room numbers on each server a unique range?

For example, 8600001 to 8600099 on server 1, 8600100 to 8600199 on server 2, and so on....

by **mflorell** » Fri Nov 15, 2013 7:04 am

cbsys, that's not the cause, and has nothing to do with your problem.

by **dspaan** » Tue Jun 24, 2014 2:21 pm

Hi Matt,

Can you shed some light on this what might be the possible causes?

We have experienced this today as well in a 2 server cluster, dialing outbound only.
I've seen it a couple of times before on other single server installs, but it happens very rarely but is very embarrassing.

by **mflorell** » Tue Jun 24, 2014 2:47 pm

The causes are pretty much always one of these:
- network problems
- server overloaded
- agent workstation problems
- misconfiguration in the system

by **Iz3k34l** » Wed Jun 25, 2014 4:21 pm

Matt,

Can you elaborate a little on your 1st, 3rd and fourth point. i am having the same problems, sometimes when there are a few agents (10-20) and sometimes it may not happen when there are a lot of agents on(60-90).

Interestingly enough we have recently come across a problem where we call different number but get the same persons answering machine. This only happens during automated dialing, we have called the numbers back and get the actual person number(voicemail or answer).

by **dspaan** » Wed Jun 25, 2014 4:34 pm

Your last sentence reminds of someone we experienced at some point. It had to do with a SIP provider who wasn't very kosher because after many complaints all i could conclude is that they did this on purpose, route random calls to the same voicemail message where you would hear a woman call 'hello hello' and then walk away from the phone as if she would fetch someone, very weird. I forgot the company name but they were based in Brussels and didn't have an office number, you could only reach them via a webform, very dubious.

by **Iz3k34l** » Wed Jun 25, 2014 4:38 pm

dspann,

interesting you say that because our provider is causing me concern

by **dspaan** » Wed Jun 25, 2014 4:52 pm

You should just try another provider and see if you get the same problems.

vicidial.org

Problem: Two inbound calls to same Agent at same time

Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Re: Problem: Two inbound calls to same Agent at same time

Who is online