Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - trymes

Pages: 1 [2]
16
Running QueueMetrics / Allow user to see statistics for just themselves?
« on: September 17, 2008, 21:06:51 »
Currently, if we give a user the AGENT key, they can only see a list of incoming calls that they have received. The cannot see what their stats on availability, time logged in, paused, etc. If I give them the USER key, they can do this, but they can also see everyone else's statistics, and I'd like to avoid that.

How would I go about doing this?

Tom

17
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

18
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

Pages: 1 [2]