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.


Messages - mudslide567

Pages: 1 [2]
16
is your queue_log file is rolling over every day because that would cause this to happen exactly every 24 hours.

17
Running QueueMetrics / Re: queue call questions please help
« on: May 20, 2010, 06:47:52 »
Note that if you are using asterisk 1.4.x, the queue is unable to correctly determine the device state and sees all devices as available and will therefore keep calling agents' phones even wen they are already on a call.  the solution to this was a workaround of using AgentCallbackLogin [which is deprecated and has its own set of issues but does correctly determine the device state).

this problem has been solved properly in asterisk 1.6 and there is now a back port available to asterisk 1.4 (http://svncommunity.digium.com/svn/russell/asterisk-1.4/func_devstate-1.4/) that will correct the problem in asterisk 1.4 so that queues correctly determine device state without having to resort to ACBL.

also make sure in your queue config you also have set "ringinuse=no"


18
Is there a quick way for a supervisor to log an agent out of his/her assigned queues?  It seems we often get agents who forget to log out when they leave and leaving them logged in creates a wide assortment of operational issues.  Obviously there are ways to do this [log in as the agent, manually log them off via asterisk CLI etc] but did I miss a nice simple way for a supervisor? Like a button to log off an agent etc?  If the answer is in the manual, I will accept the flame..

19
QueueMetrics installation / WHat happened to Pie Charts
« on: April 25, 2010, 23:52:29 »
Upgraded to 1.6.0.1 on two different systems and in both cases the pie charts on the reports pages disappeared.  All data is present and correct and other charts [bar charts] are also present and correct.  Any idea how to get them to reappear?

Running on standalone machines running Centos 5.4.


20
Running QueueMetrics / Re: AgentCallBackLogin-replacement
« on: February 17, 2010, 18:01:14 »
We have a similar setup in that agent numbers are employee numbers and similar scale [300 active agents at any given time, 10 queues], but the analog phones definitely rules out any ability to spoof hot seating.  We had already tried the solution that you are currently trying but after much head banging, could never really get it to work properly [for the same reasons you are finding].

We are currently testing another approach that should be more robust which is to track agent login/logouts with an AGI script that writes to separate table and then use that data source to overwrite the entries in queue_log table in QM [we have found that it is too much stress on the asterisk server to try to overwrite directly in the queue_log file].  This looks like it will solve the problem but we are probably a couple of weeks out from being able to roll that into production.

21
Running QueueMetrics / Re: AgentCallBackLogin-replacement
« on: February 17, 2010, 16:46:20 »
As far as I can tell based on experience across a dozen or so installations, none of the replacements for AgentCallBackLogin() really work in a hot seating environment, especially on versions of asterisk 1.4.x and each of the suggested methods I have seen write ups for have one or more problems such as the one you are seeing when you try to adapt QM for hot seating.

I have a really brute force [inelegant] workaround that goes back to basics for the time being until these is a true solution for the hot seating environment: implement a modified version of hot seating.  I use softphones [I chose Zoiper since our agents love it] and set each one to have several registrations on it reflecting all the agents who might use that particular work station.  When an agent comes to work at that desk, they register Zoiper only on the extension that matches their agent number.  Since all agents are registered on extensions that match their agent number, I can use the QM "rewrite" option again and operate the center as if it were not in hot seating mode.  I still add agents to queues dynamically etc.  Crude but it works. In a high employee turnover call center, it is relatively high maintenance but I have tried the other solutions [workarounds] without success so far.


22
Running QueueMetrics / Re: Agent's couldn't get calls
« on: February 11, 2010, 19:20:52 »
i have seen this many times.  it is not usually a QM problem. i have found a number of different reasons usually rooted in a combination of member behavior and queue configuration. 

For example:  ring strategy is "least recent"... but least recent member is not answering and queue not set up with auto logoff...so queue simply keeps trying to route call to the one member who does not answer while others sit there idly.  the corollary to this is that if a second call comes in and the queue is set to autofill, the second call will glide right by to an available agent [second lest recent] while the first call is still stuck on the first non answering agent.

another example: a least recent agent who has previously taken a call and performed an attended transfer, effectively locking up their extension so that it shows available to the queue (and QM).  However, the phone is actually tied up until the transferred call ends and so when the calls are routed there, they will show in the log as RINGNOANSWER [and have the same result as previous example].

Generally I can find logical explanations for apparent anomalies like that described by simply watching QM, figuring out where the next call should be routed to and then going to see what is going on at that endpoint. 

23
this will not help much but this looks amazingly similar to my issue (http://forum.queuemetrics.com/index.php?topic=753.0) on asterisk 1.4.2x with QM on the same server.  In my case, agent activity is all good but calls show up with the ENTERQUEUE event but as soon as CONNECT is logged, the call disappears completely from the realtime report.

all the historical reports are fine and if you pull a detail report, it will show ongoing calls accurately even though it does not show up on the realtime page.

you included a log snippet but it was for a call that was abandoned.  can you show a snippet for a call that was answered and completed successfully?

24
I think the device state problem is one that is underestimated in its role in causing a lot of these problems.  I have had two recenter installations that were using softphones where the asterisk [1.4.x] server was properly configured but the queue was ringing extensions that were already handling a queue call...so the agent would see the second line ring on e.g. Zoiper.  This was despite the fact that the server was correctly set up with "skip busy agents" etc...

The problem was that the phones were never presenting themselves as busy to the queue distribution service.  The cure for this is [gulp] to reinsert AgentCallBackLogin() onto the plan!!!  This deprecated function seems to be one of the few functions that will easily and accurately control  dev_state! 


25
Running QueueMetrics / Re: Real Time Calls Not Showing Up
« on: January 15, 2010, 16:00:55 »
yes...agents show up on the realtime report's first refresh every time.  all of the logged events (both the agent login/logouts and the call related events) show up in the queue_log table in the database more or less instantaneously. 

yes...this is a single server setup.  just for "fun" i did try running QM directly from the log file instead of the data base but with exactly the same result.

i have also tested/checked opening up all permissions wide open in case this was being caused by some sort of permissions issue somewhere.

other symptoms i forgot to mention: if an agent logs into QM, no call records ever show up on that agent's page, so the agent is unable to see their own call history for the day.  the admin account sees all call details just fine.

i am managing several other QM installations so I have been able to compare the configuration.properties file against good working systems but nothing seems to be out of the ordinary.


26
Running QueueMetrics / Re: Real Time Calls Not Showing Up
« on: January 14, 2010, 18:58:37 »
here is a snippet from the log...[correctly loaded into the database which is actually the QM source]:

1263467188|1263467188.17235|600|Local/1701@from-internal/n|ADDMEMBER|

1263470729|1263470724.17243|600|NONE|ENTERQUEUE||6842529800
1263470765|1263470724.17243|600|Local/1701@from-internal/n|CONNECT|36|1263470760.17253
1263470787|1263470724.17243|600|Local/1701@from-internal/n|COMPLETEAGENT|36|22|1

27
there are in fact other reasons where this can occur.  in a situation where there are multiple calls backed up and using an autofill type ring strategy, calls can in fact "overtake" each other in the hunt process.  you can minimize this by making sure that you get accurate reading on device state and make sure that you set your queue up to skip busy devices.  Otherwise, while call #1 is wasting time ringing some busy device, call #2 goes directly to another device that happens to be available and jumps queue position.

28
Running QueueMetrics / Real Time Calls Not Showing Up
« on: January 14, 2010, 18:06:05 »
Asterisk 1.4.x running on same machine as QM using MySQL database as the data source.

All events are properly showing up in queue_log file and in the MySQL DB table queue_log on a very timely basis.


On Real Time, having following issue(s):

Agents show up fine when they log in and log out so we can correctly see logged in agents.  However, when a call comes in, it shows up under "Calls Being Processed" while it is in the queue waiting for pickup [i.e. it sees the ENTERQUEUE correctly] but as soon as the call is picked up by an agent, the call disappears from the Real Time page.  The queue_log file and the queue_log table both show a correct "CONNECT" entry but no sign of the call on the page.  It is consistent in the sense that the Agent also shows up "green" [available] on the page.  Asterisk itself is handling everything just fine.

Data in all reports is just fine.  If you pull the report detail of the answered calls while the call is ongoing, it will correctly show up as an ongoing call.

Any ideas as to what is going on?

Pages: 1 [2]