Messages

1

Improving QueueMetrics / Re: Password security with Quemetrics 1.4.4

« on: June 10, 2008, 10:26:50 »

Regardless of whether you're looking at implementing the option for external security or not, it's vital that passwords are obscured when entering them for local accounts.  It's the most basic tenant of security that passwords shouldn't be displayed in cleartext on the screen - after all, you obscure the password when someone enters it at the login screen - why not obscure it when an administrator is modifying an account?

2

Improving QueueMetrics / Password sexurity with Quemetrics 1.4.4

« on: June 07, 2008, 16:58:42 »

Whilst creating a new account for someone recently, I was horrified to discover that whenever you edit a user account, their password is displayed in clear text on the screen with no obfuscation at all.

It's been some time since I last edited user accounts on our system, so it's possible that this isn't a new problem - though generally speaking it's the kind of thing I look for when entering passwords.

Could we please look at obscuring passwords when they are being entered?  Additionally, this raises the concern of how passwords are stored in the database - are they encrypted at all?  If not, this too is a significant security problem.

3

General Asterisk configuration / Re: Minor bug and a question

« on: January 08, 2008, 11:49:20 »

Basically, it tracks the queueu position of a caller in queue and how much time it takes for the caller to be answered.
QM averages this for all calls and gives the result per hour.
This is experimental, so improvements are welcome

Hmmm... my results would seem to indicate that it's likely adding them all together, not averaging them.  An average step of around 250 would indicate that our queues advance one step per 15 seconds (approximately)

Unfortunately we're not quite that efficient.   

4

General Asterisk configuration / Re: Minor bug and a question

« on: January 07, 2008, 10:17:57 »

No: if it shows 320, it means that you are processing 320 calls per hour, i.e. the queue is advancing at 320 steps per hour.

Then I'm not sure the results I'm getting make a great deal of sense.  Our call centre has 3 staff that answer an average of 110 calls per day, with an average talk time of 2.5 minutes per call.  This would theoretically mean that in one hour, we could answer no more than (60 / 2.5) x 3 = 72 calls, whereas in a typical day we seem to have a step rate of anywhere between 67 and 338 per hour - and those stats are fairly well spread.

Our abandoned call rate is somewhere between 5 and 10%, depending on how busy the day has been, so I wouldn't think that would contribute to this metric.

How is this metric calculated?

5

General Asterisk configuration / Re: Minor bug and a question

« on: January 02, 2008, 13:07:41 »

Cover is coverage as those stats cannot be computed for all calls because Asterisk does not log it in every case.
Step is a tenative metrics to see how "fast" your queue is turning, i.e. how much time it took on average to advance one place in queue.

Thanks for the clarification.  I hadn't considered the "step" metric, but it certainly does sound like a very useful statistic to watch.  Just to clarify, if I'm showing a step of 320, this means that on average it's taken 5 minutes and 20 seconds for a call to progress one step further in the queue, correct?

An idea possibly for future development - it would perhaps be very useful if a tooltip could be added to each statistic so that hovering over the column name in each report would give a more thorough description of what the statistic represents.  It would prevent (or at least reduce) questions such as this on the forums.

6

General Asterisk configuration / Minor bug and a question

« on: December 26, 2007, 12:44:07 »

I've spotted one minor bug in QueueMetrics 1.4.3 - a mis-spelling of length ("lenght") on the Distribution page of a report.  Very minor and probably already spotted, but best to be sure. 

One other quick question - I've noted on this same page (under Queue length per hour and Queue length per day of week) the statistics "Cover" and "Steps".  What are "steps"?  While I can guess at what "cover" is, I'd be interested to know how it's calculated.  The current documentation is for version 1.4.1 of QueueMetrics and thus doesn't address these stats.

7

Improving QueueMetrics / Re: Peak/Average queue length

« on: October 21, 2007, 13:56:27 »

I confirm this is going to be in 1.4.3.

Wonderful!  Looking forward to it!

8

Improving QueueMetrics / Re: Peak/Average queue length

« on: September 22, 2007, 14:17:31 »

For your information, this is bug #210.

Thanks greatly.  This will be most helpful.

9

Improving QueueMetrics / Peak/Average queue length

« on: September 20, 2007, 10:43:49 »

One metric that I can't seem to find anywhere is a graph/data chart that shows what the maximum and (almost as useful) average queue lengths.

Our queues run on a 10 channel ISDN service and we've very occasionally been getting busy signals on incoming calls to the queues and the rest of the office (the queue indials are in the same number group as the general office numbers) and would like to be able to get an indication of the maximum length of a queue at certain times of the day to help us identify the queues with larger numbers of people waiting.

Average wait times do give us a hint, but don't give us an exact picture.

10

QueueMetrics news / Re: QueueMetrics 1.4.1 out today

« on: September 09, 2007, 13:16:42 »

If that is your setup, you can simply set up two different instances of QM (free version) to monitor each box separately. While all older QueueMetrics versions were single-server (1 QM for 1 Asterisk), QM 1.4 included a free but time-expiring clustering mode. From 1.4.1 onwards, this should be purchased if needed.
I am sorry if this was not very clear - we are revisng the licence page and will surely make it clearer there. Thanks for pointing that out.

The reason I chose to set up the "clustered" implementation as opposed to two separate installations was to allow us to retain historical information from both servers, regardless of which one was active at the time.

Please don't think I'm unhappy about the restriction - for a free version of commercial software, I wouldn't expect it to support clustering - my only concern was that I was caught by surprise when upgrading and was hoping to make sure others don't get caught the same way.  Hopefully now I'll have a little more leverage with management to get the funding cut loose!

11

General Asterisk configuration / Re: Asterisk log rotating

« on: September 09, 2007, 12:53:51 »

I'm new to QueueMetrics and my problem is that you have to disable log rotate on the asterisk log files.

I have full logging enable to do debugging but the file gets really big and when I work in the full log file asterisk stop responding for a while.

There must be a way to still do a log rotate but not rotate the queue_log, as that is the most important file for QueueMetrics, or do I maybe miss something here?

If you are going to use the queue_log files directly then in order for you to retain historical data, you need to disable log rotation.

If this is a problem for you (as it was for me) then you need to move to logging queue data to a MySQL database by using qloaderd.  If you take this approach, you can rotate your logs as much as you like since the queue_log file is no longer the primary data store.

12

General Asterisk configuration / Re: Queue Metrics on Trixbox 2 with softphones only

« on: September 09, 2007, 12:49:20 »

I don't quite understand the difference between the different methods listed in the QM manual and the QM + TB 2 tutorial. Are they simply alternatives with the same end result? Are they mutually exclusive? (Use one or the other, but not both?)

Right now with very few queues, it is not an issue if they have to manually dial each queue they are assigned to, but in the future, it could get quite cumbersome. Any suggestions on other methods for having agents log into and out of queues?

The approach I've chosen is to have agents log on and off using the AgentCallbackLogin application.  Then in each queue I want a particular agent to receive calls from, I define them as a static agent using their agent number - e.g "Agent/101"  This allows one login code to log an agent in to multiple queues.  I use the following dialplan fragment in the [from-internal-custom] context in extensions_custom.conf to allow users to log in and out...

Code: [Select]

exten => _25XXX,1,Answer()
exten => _25XXX,n,AgentCallbackLogin(${EXTEN:2}||${CALLERID(num)}@from-internal)
exten => _25XXX,n,Hangup()

exten => _35XXX,1,Answer()
exten => _35XXX,n,AgentCallbackLogin(${EXTEN:2}||#)
exten => _35XXX,n,Hangup()

(to clarify - agents dial 25 or 35 before their agent number to log in our out respectively)

I should make mention though that Digium have deprecated the AgentCallbackLogin application and plan to remove it in some future version of Asterisk (despite the fact that there is no easy alternative!)

13

QueueMetrics news / Re: QueueMetrics 1.4.1 out today

« on: September 09, 2007, 12:35:52 »

I noticed in upgrading from 1.4.0 to 1.4.1 that QueueMetrics started complaining about running a cluster of 2 nodes as being more than that allowed by the free license.  Whilst we run 2 Asterisk servers, only one is ever active at a time (the other is either a hot-backup or being used to put upgrades through testing before going in to production) and our call centre only has 2 or 3 agents at any one time.

I understand and accept that we can not run reports for those times when 3 agents are logged in, however the change to restrict us to one Asterisk server was both unexpected and a little inconvenient.  Was this new restriction intended?  If so, it would perhaps be in your best interest to make it clear up-front to ensure that others don't run into the same surprise that I did.

14

QueueMetrics installation / Re: QueueMetrics and CallWeaver

« on: August 10, 2007, 01:48:08 »

Given my recent redundancy, I've been focusing my efforts elsewhere at the moment.

At this stage, I haven't made the move to CallWeaver yet.

15

MySQL storage and Qloaderd/Uniloader / Re: What mean partition in qloader

« on: July 27, 2007, 00:51:47 »

What partition is?
What is the meaning of "partition"?
Witch value should be in the partition fileld?

A partition is nothing more than an arbitrary identifier for the server that the queue logging data has come from.  There's no specific format for the partition - P001 is simply an example.

On my Asterisk installation, I have two partitions - PBX1 and PBX2, representing the machines known as pbxbelgrave1 and pbxbelgrave2.  If you are only running one server, you don't need to worry too much about the partition value - it's of little relevance to you.  However, if you are (or will be) running more than one server, put a little thought into the naming convention for partitions.