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 - cgarza1978

Pages: [1]
1
QueueMetrics installation / Re: Call Waiting Tone
« on: December 31, 2010, 20:22:00 »
SIP/1234 - but, it doesn't seem to matter which way you do it.  Tested it both ways before applying the solution and neither worked.

2
QueueMetrics installation / Re: Call Waiting Tone
« on: December 21, 2010, 11:41:21 »
I was messing with this all night and I seem to have found the solution.  It consists in adding an additional parameter (ringinuse=no) to the queue configuration in the queues_post_custom.conf file.

The solution is documented on the following post: http://www.freepbx.org/forum/freepbx/development/queues-skip-busy-agents-call-limit-or-ringinuse

For the record, I run trixbox 2.8.0.4 and QueueMetrics 1.6.2.1.  5502 is my queue name.  The entry goes as follows:


[5502](+)
ringinuse=no

3
QueueMetrics installation / Re: Call Waiting Tone
« on: December 21, 2010, 07:39:52 »
I'm having the same issue on QueueMetrics 1.6.2.1.  Call center employees are extremely annoyed at getting inbound calls through call waiting while trying to help customers.  Callers have to wait in queue longer than necessary while agents that are on a call are rung inspite of having call-waiting disabled and the queue being configured to "skip busy agents" are being called.  The response regarding CALL-LIMIT is beside the point and a bad work-around because setting CALL-LIMIT to one would break announced transfers which are important to most call center installations.

Since there is now a dial plan file that needs to be included in the install and it contains a special Queuemetrics context, I thought it might be related to the context.  I created a test queue and configured it exactly as the QueueMetrics queue and had the agents dial into the queue.  The "skip-busy-agents" feature worked properly when I did this.

I wrote into support about this but the respose I got was that the QueueMetrics context does nothing but "add member" the agent into the queue.  Also seams beside the point.  The problem, INHO, is either something that the QueueMetrics context is doing or NOT doing.  Either way, I don't think it matters.  This bug, is something that affects our opertion enough that if we don't find a solution, we may have to consider another software solution.  It is really too bad because I just paid for a license expansion.

Pages: [1]