vicidial.org

by **mxtreme311** » Wed Sep 10, 2008 10:43 pm

Ever since upgrading to 2.0.4.1rc4 from rc2 we are experiencing an issue where in the evening / later hours while agents are in the READY state the system will abandon many calls. The load is quite low as it is only happening during our smallest shift and the only errors I can see are on the asterisk CLI where it states the following quite often:

NOTICE[31340]: app_meetme.c:2210 admin_exec: Conference Number not found

using asterisk 1.2.30.2 (worked fine before on 2.0.4.1rc2)
Zaptel 1.2.27
libpri 1.2.8
2 PRI circuits
13 agents

where else should I look for problems??

by **mflorell** » Thu Sep 11, 2008 3:09 am

If you do an "lsmod" command in Linux, do you see ztdummy loaded?

by **mxtreme311** » Thu Sep 11, 2008 10:32 am

I'm not using ztdummy, I have a Digium 2 port T1 card and it is working properly.

by **mflorell** » Thu Sep 11, 2008 1:38 pm

Oh, that error looks like a meetmeadmin kickall error, that is not really an error.

Do a test and see if it only happens when an agent logs out of VICIDIAL.

As for your abandon issues, do you see any specific instances where a call will abandon when there are agents available? If so, please post the agiout logfile output from when this happens.

by **mxtreme311** » Fri Sep 12, 2008 1:43 pm

Matt, I'm ok with the meetmeadmin error if its not an error. The problem with the drops happens whether there are agents available or not... Here is the agiout log for two calls, the first lists as 101 seconds in the vicidial_log, the second is 1 sec (odd) I've removed the phone numbers for obvious reasons.

Code: Select all: 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|Perl Environment Dump: 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|0|8368 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|callerID changed: V0911171254018584145 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|AGI Environment Dump: 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- accountcode = 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- callerid = 8007930282 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- calleridname = V0911171254018584145 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- callingani2 = 0 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- callingpres = 0 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- callingtns = 0 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- callington = 0 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- channel = Zap/3-1 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- context = default 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- dnid = unknown 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- enhanced = 0.0 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- extension = 8368 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- language = en 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- priority = 2 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- rdnis = unknown 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- request = agi-VDAD_LB_transfer.agi 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- type = Zap 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi| -- uniqueid = 1221174774.105455 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|AGI Variables: |1221174774.105455|Zap/3-1|8368|Zap|V0911171254018584145|V0911171254018584145|2| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|+++++ VDAD START : |18584145|2008-09-11 17:13:11|1.2.30|2| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi||SELECT count(*) FROM vicidial_live_agents where callerid='V0911171254018584145';| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi||SELECT count(*) FROM vicidial_auto_calls where callerid='V0911171254018584145' and status IN('LIVE','XFER');| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|-- VDAD : |1|update of vac table: V0911171254018584145 |UPDATE vicidial_auto_calls set uniqueid='1221174774.105455', channel='Zap/3-1',status='LIVE',stage='LIVE-0' where callerid='V0911171254018584145' order by call_time desc limit 1;| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi||INSERT INTO vicidial_log (uniqueid,lead_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,processed) values('1221174774.105455','18584145','2410','2008-09-11 17:13:11','1221174791','QUEUE','1','-removed--','VDAD','N')| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|-- VDAD : |18584145|18584145|insert to vicidial_log: 1221174774.105455 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi||SELECT count(*) FROM vicidial_auto_calls where status = 'LIVE' and campaign_id = '2410' and call_time < "2008-09-11 17:12:54" and lead_id != '18584145';| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi||SELECT count(*) FROM vicidial_live_agents where campaign_id = '2410' and last_update_time > '20080911171306';| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi||CONCURRENT TRANSFERS AUTO SETTING: 3 (19)| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|-- VDAD get agent: |1|update of vla table: 2410|10.1.0.33 |UPDATE vicidial_live_agents set status='QUEUE',lead_id='18584145',uniqueid='1221174774.105455', channel='Zap/3-1', call_server_ip='10.1.0.33', callerid='V0911171254018584145' where status = 'READY' and campaign_id='2410' and last_update_time > '20080911171306' order by last_call_finish limit 1;| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi||SELECT conf_exten,user,extension,server_ip FROM vicidial_live_agents where status IN('QUEUE','INCALL') and campaign_id='2410' and callerid='V0911171254018584145' and channel='Zap/3-1' order by last_call_time limit 1;| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|-- VDAD XFER : |1|update of vac table: V0911171254018584145 |UPDATE vicidial_auto_calls set status='XFER', stage='XFER-0' where callerid='V0911171254018584145';| 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|exiting the VDAD app, transferring call to 8600080 2008-09-11 17:13:11|agi-VDAD_LB_transfer.agi|XXXXXXXXXX VDAD transferred: start|stop 2008-09-11 17:13:11|2008-09-11 17:13:11

Second Call:

Code: Select all: 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|Perl Environment Dump: 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|0|8368 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|callerID changed: V0911171554018584103 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|AGI Environment Dump: 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- accountcode = 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- callerid = 8007930282 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- calleridname = V0911171554018584103 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- callingani2 = 0 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- callingpres = 0 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- callingtns = 0 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- callington = 0 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- channel = Local/91--removed-@default-0929,1 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- context = default 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- dnid = unknown 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- enhanced = 0.0 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- extension = 8368 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- language = en 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- priority = 2 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- rdnis = unknown 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- request = agi-VDAD_LB_transfer.agi 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- type = Local 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- uniqueid = 1221174954.105699 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|AGI Variables: |1221174954.105699|Local/91--removed-@default-0929,1|8368|Local|V0911171554018584103|V0911171554018584103|2| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|+++++ VDAD START : |18584103|2008-09-11 17:16:13|1.2.30|2| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|+++++ VDAD START LOCAL CHANNEL: EXITING- 2 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|Perl Environment Dump: 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|0|8368 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|callerID changed: V0911171554018584103 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|AGI Environment Dump: 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- accountcode = 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- callerid = unknown 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- calleridname = V0911171554018584103 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- callingani2 = 0 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- callingpres = 0 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- callingtns = 0 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- callington = 0 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- channel = Zap/12-1 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- context = default 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- dnid = unknown 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- enhanced = 0.0 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- extension = 8368 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- language = en 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- priority = 3 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- rdnis = unknown 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- request = agi-VDAD_LB_transfer.agi 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- type = Zap 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi| -- uniqueid = 1221174954.105699 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|AGI Variables: |1221174954.105699|Zap/12-1|8368|Zap|V0911171554018584103|V0911171554018584103|3| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|+++++ VDAD START : |18584103|2008-09-11 17:16:13|1.2.30|3| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi||SELECT count(*) FROM vicidial_live_agents where callerid='V0911171554018584103';| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi||SELECT count(*) FROM vicidial_auto_calls where callerid='V0911171554018584103' and status IN('LIVE','XFER');| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|-- VDAD : |1|update of vac table: V0911171554018584103 |UPDATE vicidial_auto_calls set uniqueid='1221174954.105699', channel='Zap/12-1',status='LIVE',stage='LIVE-0' where callerid='V0911171554018584103' order by call_time desc limit 1;| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi||INSERT INTO vicidial_log (uniqueid,lead_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,processed) values('1221174954.105699','18584103','2410','2008-09-11 17:16:13','1221174973','QUEUE','1','--removed-','VDAD','N')| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|-- VDAD : |18584103|18584103|insert to vicidial_log: 1221174954.105699 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi||SELECT count(*) FROM vicidial_auto_calls where status = 'LIVE' and campaign_id = '2410' and call_time < "2008-09-11 17:15:54" and lead_id != '18584103';| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi||SELECT count(*) FROM vicidial_live_agents where campaign_id = '2410' and last_update_time > '20080911171608';| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi||CONCURRENT TRANSFERS AUTO SETTING: 3 (22)| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|-- VDAD get agent: |1|update of vla table: 2410|10.1.0.33 |UPDATE vicidial_live_agents set status='QUEUE',lead_id='18584103',uniqueid='1221174954.105699', channel='Zap/12-1', call_server_ip='10.1.0.33', callerid='V0911171554018584103' where status = 'READY' and campaign_id='2410' and last_update_time > '20080911171608' order by last_call_finish limit 1;| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi||SELECT conf_exten,user,extension,server_ip FROM vicidial_live_agents where status IN('QUEUE','INCALL') and campaign_id='2410' and callerid='V0911171554018584103' and channel='Zap/12-1' order by last_call_time limit 1;| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|-- VDAD XFER : |1|update of vac table: V0911171554018584103 |UPDATE vicidial_auto_calls set status='XFER', stage='XFER-0' where callerid='V0911171554018584103';| 2008-09-11 17:16:13|agi-VDAD_LB_transfer.agi|exiting the VDAD app, transferring call to 010*001*000*031*8600061

by **mflorell** » Fri Sep 12, 2008 5:19 pm

It looks like the calls get transferred, where is it showing that these calls are drops?

by **mxtreme311** » Fri Sep 12, 2008 5:51 pm

In the vicidial_log:

Code: Select all: +--------------------+----------+---------+-------------+---------------------+-------------+------------+---------------+--------+------------+------+----------+-----------+------------+ | uniqueid | lead_id | list_id | campaign_id | call_date | start_epoch | end_epoch | length_in_sec | status | phone_code | user | comments | processed | user_group | +--------------------+----------+---------+-------------+---------------------+-------------+------------+---------------+--------+------------+------+----------+-----------+------------+ | 1221174954.1056991 | 18584103 | NULL | 2410 | 2008-09-11 17:16:13 | 1221174973 | 1221174974 | 1 | DROP | 1 | VDAD | NULL | N | NULL | | 1221174774.1054549 | 18584145 | NULL | 2410 | 2008-09-11 17:13:11 | 1221174791 | 1221174892 | 101 | DROP | 1 | VDAD | NULL | N | NULL | +--------------------+----------+---------+-------------+---------------------+-------------+------------+---------------+--------+------------+------+----------+-----------+------------+

by **mflorell** » Sun Sep 14, 2008 6:43 am

Did the calls make it to an agent at all?

It looks like they were sent. You might want to check the FastAGI logfile to see if these calls or the lead_id for them show up in there, and if that is where they are set to DROP.

by **mxtreme311** » Thu Sep 18, 2008 4:14 pm

I'm not sure what to look for in that file, I'm at wits end on this... the problem disappears when we reset the affected dailers (not the web server or the MySQL server, or our other dialers), the problem only happens in the afternoon, about 8 hours after we start dialing. Thinking of rolling back to 2.0.4.1rc2 tonight as the problem didn't exits in that version. Any tips or ideas I'd be more than happy to look into.

by **mxtreme311** » Thu Sep 18, 2008 6:46 pm

Matt, I'm gonna send you the FASTagiout files pertaining to this issue, hopefully we can find a resolution.

by **mflorell** » Thu Sep 18, 2008 8:01 pm

We have several clients on 2.0.4.1rc4 and we do not see these kinds of problems.

Looking at the agiout logfile may help as well, since I didn't see anything sticking out on the Fastagi logfile.

by **mxtreme311** » Wed Sep 24, 2008 2:41 pm

matt, I'm working on pulling some meaningful data out of the agiout log, one thing that is strange is that if we have the agents all log out for a few minutes, the problem persists, but if we reset the dialers the problem completely disappears. Today I'm gonna try just running the AST_reset_mysql_vars.pl instead of resetting the dialers. Also the error message:

NOTICE[31340]: app_meetme.c:2210 admin_exec: Conference Number not found

Is only seen in the asterisk "screen" when this problem is happening, when everything is running smoothly this notice is not found.

by **mxtreme311** » Wed Sep 24, 2008 8:01 pm

Update, running the AST_reset_mysql_vars.pl DID NOT fix the problem... not sure what that means at this time...

by **mflorell** » Thu Sep 25, 2008 11:14 am

Is meetme being loaded by your asterisk?

does the meetme room exist in your meetme.conf file?

by **mxtreme311** » Thu Sep 25, 2008 3:58 pm

Matt, yes meetme is being loaded, today the problem didn't start until we hit about 50,000 dials... the meetme room should exist as I copied my meetme.conf from the examples in the astguiclient package. I also just saw this on the console...

WARNING[30221]: channel.c:2290 ast_write: Thread 1118157136 Blocking 'SIP/305-026902e0', already blocked by thread 1118423376 in procedure ast_waitfor_nandfds

Any idea where I should look next?

Mike

by **mflorell** » Thu Sep 25, 2008 5:06 pm

The warning is not an issue.

Is this on an inbound or outbound call?

any more Asterisk CLI output?

by **ramaseshi** » Thu Oct 23, 2008 8:32 am

Hi all

I am also facing same problem. I am in manual dial mode. I logged in vicidial.php i got call on SIP phone i enetered in to conference.

After some time i clicked on log out button.It does't say that you have been kicked from the conference.

here are logs please help me.

---
> Channel SIP/9000-082078e8 was answered.
[Oct 23 09:25:39] DEBUG[4325]: res_config_mysql.c:651 mysql_reconnect: MySQL RealTime: Everything is fine.
[Oct 23 09:25:39] DEBUG[4325]: res_config_mysql.c:139 realtime_mysql: MySQL RealTime: Retrieve SQL: SELECT * FROM asv_sip WHERE name = '9000'
-- Executing [8600051@default:1] MeetMe("SIP/9000-082078e8", "8600051|F") in new stack
== Parsing '/usr/local/netzgate/etc/netzgate/meetme.conf': Found
[Oct 23 09:25:39] WARNING[4325]: channel.c:2962 ast_request: translator path exists for channel type zap (native 76) to 64
[Oct 23 09:25:39] DEBUG[4325]: chan_zap.c:5611 zt_new: #372 If (core) Needs a rethink i = 8208f10, i->rdnis = 8209c48
[Oct 23 09:25:39] WARNING[4325]: channel.c:2962 ast_request: translator path exists for channel type zap (native 76) to 64
[Oct 23 09:25:39] DEBUG[4325]: chan_zap.c:5611 zt_new: #372 If (core) Needs a rethink i = 8238d20, i->rdnis = 8239a58
-- Created MeetMe conference 1023 for conference '8600051'
> 2438 CONFFLAG_RECORDCONF :: 0
> 1068 CONFFLAG_RECORDCONF :: 0
[Oct 23 09:25:39] DEBUG[4325]: app_meetme.c:1069 conf_run: confflags => 0
> 1095 CONFFLAG_RECORDCONF :: 0
-- SIP Seeding peer from astdb: '9000' at 9000@192.168.1.19:55699 for 3600
[Oct 23 09:25:39] DEBUG[4325]: file.c:411 ast_filehelper: From function ast_filehelper ACTION
-- <SIP/9000-082078e8> Playing 'conf-onlyperson' (language 'en')
== Manager 'sendcron' logged off from 192.168.1.204
== Parsing '/usr/local/netzgate/etc/netzgate/manager.conf': Found
== Manager 'sendcron' logged on from 192.168.1.204
== Parsing '/usr/local/netzgate/etc/netzgate/manager.conf': Found
== Manager 'sendcron' logged on from 192.168.1.204
-- Hungup 'Zap/pseudo-1320747968'
-- Hungup 'Zap/pseudo-829236493'
== Spawn extension (default, 8600051, 1) exited non-zero on 'SIP/9000-082078e8'
-- Executing [h@default:1] DeadAGI("SIP/9000-082078e8", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Oct 23 09:25:45] DEBUG[4325]: cdr.c:630 ast_cdr_end: The value of billtime is :0
[Oct 23 09:25:45] DEBUG[4325]: cdr_addon_mysql.c:245 mysql_log: cdr_mysql: inserting a CDR record.
[Oct 23 09:25:45] DEBUG[4325]: cdr_addon_mysql.c:258 mysql_log: @@@@@@@@@@@@ actual_ip= 192.168.1.19 PORT= 55699@@@@@@@@@@@@@@
[Oct 23 09:25:45] DEBUG[4325]: cdr_addon_mysql.c:395 mysql_log: cdr_mysql: SQL command as follows: INSERT INTO astcdr (accountcode,date_created,callerid,callednum,brand,channel,dstchannel,lastapp,lastdata,type,duration,dialedtime,answeredtime,billtime,dialstatus,amaflags,userfield,master,submaster,useragent,ipport,trunk,vom_file) VALUES ('9000','2008-10-23 09:25:39','S0810230925368600051','8600051','default', 'SIP/9000-082078e8','','DeadAGI','agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------','SIP/9000-DeadAGI-agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------',6,'2008-10-23 09:25:39','1969-12-31 19:00:00',0,'ANSWERED',3,'','9000','9000','','192.168.1.19:55699','','')
[Oct 23 09:25:45] DEBUG[4325]: chan_sip.c:3717 sip_hangup: Just before sending BYE p->username is 9000
[Oct 23 09:25:45] WARNING[4325]: channel.c:2962 ast_request: translator path exists for channel type Local (native -1) to 64 -- Executing [55558600051@default:1] MeetMeAdmin("Local/55558600051@default-4b95,2", "8600051|K|8600051") in new stack
[Oct 23 09:25:45] WARNING[4325]: app_meetme.c:2678 admin_exec: Conference number '8600051' not found!
-- Executing [55558600051@default:2] Hangup("Local/55558600051@default-4b95,2", "") in new stack
== Spawn extension (default, 55558600051, 2) exited non-zero on 'Local/55558600051@default-4b95,2'
-- Executing [h@default:1] DeadAGI("Local/55558600051@default-4b95,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
Scheduling destruction of SIP dialog '35e8bdf62690f1b55178d4857e2ae165@192.168.1.204' in 32000 ms (Method: INVITE)
[Oct 23 09:25:45] DEBUG[4325]: chan_sip.c:6184 reqprep: Strict routing enforced for session 35e8bdf62690f1b55178d4857e2ae165@192.168.1.204
set_destination: Parsing <sip:9000@192.168.1.19:55699> for address/port to send to
set_destination: set destination to 192.168.1.19, port 55699
Reliably Transmitting (NAT) to 192.168.1.19:55699:
BYE sip:9000@192.168.1.19:55699 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.204:5075;branch=z9hG4bK23b31626;rport
Max-Forwards: 70
From: "S0810230925368600051" <sip:netzgate@192.168.1.204:5075>;tag=as25378349
To: <sip:9000@192.168.1.19:55699>;tag=691e442c76026500

################################

screen -r

4457.ASTVDremote (Detached)
4451.ASTVDauto (Detached)
4448.ASTlisten (Detached)
4445.ASTsend (Detached)
4426.ASTupdate (Detached)
24109..seshi (Dead ???)
4189.ASTfastlog (Detached)
4185.ASTVDadapt (Detached)
Remove dead screens with 'screen -wipe'.

######################
screen -x

4457.ASTVDremote (Detached)
4451.ASTVDauto (Detached)
4448.ASTlisten (Detached)
4445.ASTsend (Detached)
4426.ASTupdate (Detached)
24109..seshi (Dead ???)
4189.ASTfastlog (Detached)
4185.ASTVDadapt (Detached)
Remove dead screens with 'screen -wipe'.
Type "screen [-d] -r [pid.]tty.host" to resume o

by **mflorell** » Thu Oct 23, 2008 9:08 am

Asterisk version?

astguiclient version?

Are you using any kind of dialplan generator like FreePBX or Druid?

by **ramaseshi** » Thu Nov 06, 2008 7:09 am

Asterisk version is 1.4beta
Astguiclient version is 2.0.4.1rc4

I am using your example extensions.conf for dialplan and asterisk cdr addons for UI.

by **mflorell** » Thu Nov 06, 2008 8:23 pm

1.4beta, what is that?

by **ramaseshi** » Fri Nov 07, 2008 12:41 am

svn revision 48965

by **mflorell** » Fri Nov 07, 2008 12:52 am

I believe that is an extremely old version of 1.4 and I would not recommend using it. Only Asterisk 1.4.18 and higher releases are VICIDIAL-approved in the 1.4 tree, due to the serious bugs that exist in Asterisk 1.4.17 and earlier that cause Asterisk to crash.

by **mxtreme311** » Mon Mar 02, 2009 8:27 pm

Well his problem aside, mine is still happening at numerous locations on different servers setup by different IT teams, only seems to happen when we hit around 50,000 dials or so between two servers. We've found a work around, and that is to reset the dialers mid-day. Not sure where to go from here.

by **mflorell** » Mon Mar 02, 2009 8:51 pm

Well, you could try upgrading to SVN trunk, none of our clients are running 2.0.4 branch any more, they all run SVN trunk, and none of them have to reset their servers in the middle of the day.

by **mxtreme311** » Thu Mar 26, 2009 4:07 pm

Interesting update. We have a pretty large setup here and have been doing more troubleshooting than I would like to admit to working on this and we have found something quite interesting. This issue is related to a memory leak somewhere. I'm not sure if its in app_meetme or some of the vicidial perl scripts, but what we have found is this:

On our Fedora dialers w/2GB of RAM all RAM is in use after about 6 hours with 48 agents on the dialer, once the RAM is exhausted the dialer starts dropping calls.

On our Debian dialers w/2GB of RAM all RAM is in use after about 10 hours with 48 agents on the dialer, once the RAM is exhausted the dialer starts dropping calls.

We have a few machines that are handling inbound traffic only that are not using the astguiclient package, just a generic Debian box with Asterisk 1.2.31.1 and some SIP clients, NOT using meetme, and these boxes can go weeks without showing a significant decrease in memory usage.

This leads me to believe that there is a memory leak either in the astguiclient perl scripts that are constantly running in the background or the app_meetme portion of the asterisk package.

To alleviate the problem we now have 4GB RAM in all our dialers and the problem seems to be resolved if we reset the dialers every night in the middle of the night (crontab task).

Does anyone want to look into this? I would be more than willing to help in any way that I can to resolve the problem.

by **mflorell** » Thu Mar 26, 2009 4:45 pm

When you run 'top' you can see memory usage, can you post that when you run out of RAM?

Have you run full VICIDIAL on a non-RedHat-family distro? Redhat has consistent issues with messing perl up(yet another reason we do not recommend using it)

What version of astguiclient?

vicidial.org

Problem with 2.0.4.1rc4

Problem with 2.0.4.1rc4

Who is online