Messages

76

General Asterisk configuration / Re: Incoming calls generate single-ring calls randomly

« on: July 26, 2008, 21:55:09 »

Where would this be set? Also, this reminds me, if qloaderd is reading queue_log, is it ok to rotate it so it doesn't get so big?

77

General Asterisk configuration / Re: Incoming calls generate single-ring calls randomly

« on: July 26, 2008, 19:21:38 »

I doubt it, because ongoing calls are not interrupted, and the phones indeed ring, but only once.

Tom

78

General Asterisk configuration / Re: Incoming calls generate single-ring calls randomly

« on: July 23, 2008, 18:56:36 »

I was able to pull this from Master.cdr:

Code: [Select]

6038273245 400 ext-queues "WEBER,STEVE &AL" <6038273245> Zap/7-1 Agent/135 Queue 400|t|| 7/10/08 10:18 7/10/08 10:18 7/10/08 10:25 409 409 ANSWERED
6038273245 270 from-internal "WEBER,STEVE &AL" <6038273245> Local/270@from-internal-3b41,2 SIP/270-08bd8978 ResetCDR w 7/10/08 10:18 7/10/08 10:18 0 0 BUSY
6038273245 250 from-internal "WEBER,STEVE &AL" <6038273245> Local/250@from-internal-91c0,2 SIP/250-08bd8978 ResetCDR w 7/10/08 10:18 7/10/08 10:18 1 0 BUSY
6038273245 270 from-internal "WEBER,STEVE &AL" <6038273245> Local/270@from-internal-b7fa,2 SIP/270-08bd8978 ResetCDR w 7/10/08 10:18 7/10/08 10:18 0 0 BUSY
6038273245 250 from-internal "WEBER,STEVE &AL" <6038273245> Local/250@from-internal-2198,2 SIP/250-08bd8978 ResetCDR w 7/10/08 10:18 7/10/08 10:18 1 0 BUSY
6038273245 270 from-internal "WEBER,STEVE &AL" <6038273245> Local/270@from-internal-8d92,2 SIP/270-08bd8978 ResetCDR w 7/10/08 10:18 7/10/08 10:18 0 0 BUSY
6038273245 250 from-internal "WEBER,STEVE &AL" <6038273245> Local/250@from-internal-9af3,2 SIP/250-08bd8978 ResetCDR w 7/10/08 10:18 7/10/08 10:18 1 0 BUSY
6038273245 270 from-internal "WEBER,STEVE &AL" <6038273245> Local/270@from-internal-89a0,2 SIP/270-08bd8978 ResetCDR w 7/10/08 10:18 7/10/08 10:18 1 0 BUSY
6038273245 250 from-internal "WEBER,STEVE &AL" <6038273245> Local/250@from-internal-1b4e,2 SIP/250-08bd8978 ResetCDR w 7/10/08 10:18 7/10/08 10:18 0 0 BUSY
6038273245 270 from-internal "WEBER,STEVE &AL" <6038273245> Local/270@from-internal-f5bb,2 SIP/270-08bd8978 ResetCDR w 7/10/08 10:18 7/10/08 10:18 1 0 BUSY
6038273245 250 from-internal "WEBER,STEVE &AL" <6038273245> Local/250@from-internal-fdba,2 SIP/250-08bd8978 ResetCDR w 7/10/08 10:18 7/10/08 10:18 0 0 BUSY
6038273245 270 from-internal "WEBER,STEVE &AL" <6038273245> Local/270@from-internal-528f,2 SIP/270-08bd8978 ResetCDR w 7/10/08 10:19 7/10/08 10:19 1 0 BUSY
6038273245 250 from-internal "WEBER,STEVE &AL" <6038273245> Local/250@from-internal-bf24,2 SIP/250-08bd8978 ResetCDR w 7/10/08 10:19 7/10/08 10:19 0 0 BUSY
6038273245 270 from-internal "WEBER,STEVE &AL" <6038273245> Local/270@from-internal-6767,2 SIP/270-08bd8978 ResetCDR w 7/10/08 10:19 7/10/08 10:19 1 0 BUSY
6038273245 250 from-internal "WEBER,STEVE &AL" <6038273245> Local/250@from-internal-fb6b,2 SIP/250-08bd8978 ResetCDR w 7/10/08 10:19 7/10/08 10:19 0 0 BUSY
6038273245 270 from-internal "WEBER,STEVE &AL" <6038273245> Local/270@from-internal-4d2f,2 SIP/270-08bd8978 ResetCDR w 7/10/08 10:19 7/10/08 10:19 1 0 BUSY
6038273245 250 from-internal "WEBER,STEVE &AL" <6038273245> Local/250@from-internal-527a,2 SIP/250-08bd8978 ResetCDR w 7/10/08 10:19 7/10/08 10:19 0 0 BUSY
6038273245 270 from-internal "WEBER,STEVE &AL" <6038273245> Local/270@from-internal-53bd,2 SIP/270-08bd8978 ResetCDR w 7/10/08 10:19 7/10/08 10:19 0 0 BUSY
6038273245 250 from-internal "WEBER,STEVE &AL" <6038273245> Local/250@from-internal-9f54,2 SIP/250-08bd8978 ResetCDR w 7/10/08 10:19 7/10/08 10:19 0 0 BUSY
6038273245 270 from-internal "WEBER,STEVE &AL" <6038273245> Local/270@from-internal-db41,2 SIP/270-08bd8978 ResetCDR w 7/10/08 10:19 7/10/08 10:19 0 0 BUSY
6038273245 250 from-internal "WEBER,STEVE &AL" <6038273245> Local/250@from-internal-35e0,2 SIP/250-08bd8978 ResetCDR w 7/10/08 10:19 7/10/08 10:19 1 0 BUSY
6038273245 135 from-internal "WEBER,STEVE &AL" <6038273245> Local/135@from-internal-3594,2 SIP/135-08bd8978 Dial SIP/135|25|trwM(auto-blkvm) 7/10/08 10:19 7/10/08 10:19 7/10/08 10:19 6 0 ANSWERED
It seems that the system thinks the phones are busy, but they are not. Any thoughts on this?

Tom

PS: My apologies for the messy post...

79

General Asterisk configuration / Re: Incoming calls generate single-ring calls randomly

« on: July 23, 2008, 18:34:12 »

From QM, by clicking on the call details, I get this:

Code: [Select]

Asterisk Call ID:      1216217403.21894
Date and time:    16/07/2008 - 10:10:10
Caller ID:   
Handled by:    agent/103
Duration:    146 sec.
Waiting time:    284 sec.
Original position    # 3
Disconnection cause:    Caller disconnected
Transferred to:   
URL:   
Status code:   
Srv   
Sound files:
- q400-20080716-101005-1216217403.21894.WAV
I haven't had much luck deciphering the CDRs from Freepbx or Trixbox, and so any help providing some useful information would be appreciated.

Tom

80

General Asterisk configuration / Re: Incoming calls generate single-ring calls randomly

« on: July 22, 2008, 14:49:38 »

This is definitely an asterisk problem; I know that QM has no effect on the call flow. I posted here because I thought that maybe the custom setup that QM recommends in the setup docs might be to blame.

I'll try to look up the CDRs for one of these calls. What other info would be useful?

Tom

81

General Asterisk configuration / Incoming calls generate single-ring calls randomly

« on: July 21, 2008, 20:24:21 »

I am struggling to track down a problem we have been experiencing here on our system running Trixbox 2.2 and QM 1.4.4. On a seemingly random basis, certain calls will not be passed through to an agent as normally happens. Most calls work just fine. Call comes in, placed in queue, sent to an agent, agent answers phone, all is good. However, some calls come in, get placed in the queue, and then bounce from agent to agent ringing only once before it goes to the next agent. Agents are not able to pick these calls up, even if they are really fast (ie: they pick it up while it is still ringing). We had one last week that bounced around like this for 4:44 (four minutes, 44 seconds) before being sent to an agent properly. Of course, due to Asterisk 1.2's lack of an atuofill feature, (ie: only one call is handled at a time, all other calls pile up behind it) this causes all calls to wait for longer until the problem call is finally answered.

Is this something that has been seen before? This server was originally set up a while back, and the instructions I used in the past had me add an entry for the queue to the Queues.conf file, so that file looks like this:

[general]
;
; Global settings for call queues

persistentmembers=yes

;   (none exist currently)
;
; Note that a timeout to fail out of a queue may be passed as part of applicati$
; from extensions.conf:
; Queue(queuename|[options]|[optionalurl]|[announceoverride]|[timeout])
; example: Queue(dave|t|||45)

[default]
;
; Default settings for queues (currently unused)
;

#include queues_custom.conf
#include queues_additional.conf

[400]
announce-frequency=0
timeout=25
strategy=rrmemory
retry=1
queue-youarenext=
queue-thereare=
queue-thankyou=queue-thankyou
queue-callswaiting=
music=default
monitor-join=yes
monitor-format=wav49
maxlen=0
leavewhenempty=no
joinempty=Yes
eventwhencalled=no
eventmemberstatus=no
context=
announce-holdtime=no
wrapuptime=35

member=Agent/100,1
member=Agent/101,1

and so on...

This entry in queues.conf is in addition to the entry made via FreePBX, which shows up in queues_additional.conf. Also, I have two custom contexts in from-internal-custom to avoid having to punch in an agent code when logging in (this is instead of the simpler one number to dial example given in the QM docs):

[from-internal-custom]
exten => *98,1,Answer()
exten => *98,n,Wait(0.25)
exten => *98,n,AgentCallBackLogin(${CALLERID(num)}||${CALLERID(num)}@from-inter$
exten => *98,n,Hangup()

exten => *99,1,Answer()
;exten => *99,n,Wait(0.5)
exten => *99,n,System(asterisk -rx "agent logoff Agent/${CALLERID(num)}")
exten => *99,n,Playback(agent-loggedoff)
exten => *99,n,Hangup()

Any help or insight would be appreciated.

Tom

82

MySQL storage and Qloaderd/Uniloader / Re: qloaderd not loading after log rotation started again

« on: February 26, 2008, 15:22:34 »

I think that you lost some data due to a rotation then - but you can manually load the previous data from partition P001 to P002.

Would the easiest way to do this be to copy Partition P001 to P003 and then force qloaderd to use that?

83

MySQL storage and Qloaderd/Uniloader / Re: qloaderd not loading after log rotation started again

« on: February 25, 2008, 20:50:05 »

OK, I modified the partition name in the /etc/init.d/qloaderd file, and it loaded the info to the p002 partition. However, there seems to be some information missing, as P001 has data from October through Feb 12, while P002 has info just from November through Feb 12. (I had the permissions wrong on the /var/log/asterisk file, so it seems that asterisk has been unable to write anything to it since Feb 12) Maybe the "chown asterisk.asterisk /var/log/asterisk/queue_log" command and the appropriate chmod command would be a good thing to add to the tutorial on combining previously rotated call log files.

84

MySQL storage and Qloaderd/Uniloader / qloaderd not loading after log rotation started again

« on: February 22, 2008, 16:47:25 »

I had a working qloaderd install on Trixbox until I removed and reinstalled asterisk (don't ask, it was a bad idea). Anyhow, that forced asterisk to start rotating the queue_log file again, and I didn't notice until a week or so later. I repeated to process of combining the rotated queue_log files into one big file and I restarted qloaderd, checked all of the settings, etc, and all appears to be working, except that the database is not receiving any new data.

qloader.log prints out multiple lines of "Heart is still beating... Imported 0 lines." and it just spits out "Skipped xxxxxx lines" if I restart it.

In the Queuemetrics datbase inspector, it only shows data up to Jan 15, though we have data all the way to today in the queue_log file.

If I connect to mysql using the parameters specified in the qloaderd.pl script, (username, password, database), I can connect successfully.

Does anyone have any suggestions as to where I can look next? I'm sure it's something obvious, but I can't seem to figure it out.

Tom