Messages

1771

Outbound and QueueMetrics / Re: Outbound with LCR

« on: October 14, 2009, 10:32:57 »

You should simply use the dialout script and have your LCR script set the QDIALER_CHANNEL variable.

This way , when your agent just dials (say) 1-234-567-8900, it gets to be Zap/g0/012345678900 or SIP/provider/12345678900 or IAX2/peername/12345678900 or whatever your LCR script likes best....

1772

Improving QueueMetrics / Re: yum upgrade always trashes my configuration.properties file

« on: October 12, 2009, 18:13:35 »

We track this as bug #884

1773

Improving QueueMetrics / Re: yum upgrade always trashes my configuration.properties file

« on: October 12, 2009, 18:12:42 »

I agree. It would be better if there was some "local" configuration file where you only put your changes, plus a "default" that is not to be touched. At the moment we always overwrite the default file so that new options are visible.

1774

Problems / MOVED: yum upgrade always trashes my configuration.properties file

« on: October 12, 2009, 18:09:59 »

This topic has been moved to Improving QueueMetrics.

http://forum.queuemetrics.com/index.php?topic=667.0

1775

Lost licences / Re: No email yet-Lost mail and licences

« on: October 12, 2009, 18:08:21 »

You should have received it now. It was sent about 8 hours ago as well. If you still do not see it, it means there is some problem with some spam dfilter along the path.

1776

QueueMetrics installation / Re: No queues found. Check your datasource validity

« on: October 12, 2009, 11:51:10 »

Thanks! that's great.

1777

General Asterisk configuration / Re: reports on outbound calls

« on: October 10, 2009, 09:35:01 »

You need a special piece of dialplan that does the logging. See e.g. http://queuemetrics.com/manuals/QM_Trixbox-chunked/ar01s03.html

There is a forum here that is specific for Outbound, in case you need help!

1778

QueueMetrics installation / Re: Unable to finish "JDBC connection tester"

« on: October 10, 2009, 09:32:26 »

So the problem was that Qm was not finding its own tables in the DB. Maybe we should add a sanity check - if there are no tables in the DB, just refuse to upgrade.

1779

Running QueueMetrics / Re: HELP!! Stuck calls in Queue

« on: October 09, 2009, 08:08:49 »

This is of course an Asterisk issue, so it is not related to QM - QM has no say on how calls are distributed. 

Still I understand it is a major PITA. This is what I would do:
- turn on maximum verbosityu in Asterisk logging
- wait for the problem to happen and write down the time and ID of a call
- try and look back on the log for any suspicious entries

Do you have autofill enabled? if not, it may be worth trying.

1780

QueueMetrics installation / Re: Unable to finish "JDBC connection tester"

« on: October 09, 2009, 08:04:00 »

Because the error you seem to have is that a table is missing, but that table is created by default since a very old installation.

The MySQL connector has no "physical" dependencies - is it available in the WEB-INF/lib/ path? (even if it is installed on the system, QM may not see it if it's not copied in the correct location).



 

1781

QueueMetrics installation / Re: Unable to finish "JDBC connection tester"

« on: October 08, 2009, 17:36:52 »

This is okay - but are you sure you did upload the database?

1782

Running QueueMetrics / Re: Call attempts: Avg ring is greater than agent timeout

« on: October 07, 2009, 19:13:17 »

The ring time is taken if after the ringing the agent answers, and lost if the ring is "empty". Ring time can be way higher that the timeout because Asterisk will try again and again, and it's all cumulated.

E.g. imagine this call

Time: 10: Agent 101 not answered for 10 seconds
Time: 20: Agent 102 not answered for 10 seconds
Time: 30: Agent 101 not answered for 10 seconds
Time: 40: Agent 102 answers

Agent 101 has 20 seconds of "lost" rings (10+10)
Agent 102 has 10 seconds lost and 10 seconds taken.
 

1783

Running QueueMetrics / Re: callfiles

« on: October 07, 2009, 19:08:32 »

Either a callfile or a TCP connection. When your * box will have its own Twitter account, we'll use that as well :-)

1784

General Asterisk configuration / Re: Transfers Not Showing

« on: October 06, 2009, 09:06:33 »

This is correct - the first "queue" terminates on a transfer out, so that's why it's so. We need a second "queue" to keep track of the transferred call.

There are basically two ways ahead:

1. create a queue for the second level and have the call transferred to the new queue. This will make it visible joined to the first call in Multi-Stint mode.

2. use the dial-out piece of dial-plan (the one generally used to log outbound correctly, see the Outbound forum) to log the second part of the call as if it were on a queue. This is more flexible but more complex to set up.
 

1785

QueueMetrics installation / Re: No data retrieve

« on: October 06, 2009, 09:02:29 »

You have to configure it - this is because QM will display to each user only what he is supposed to see, so in order for a queue to be displayed it must be configured and an optional security key can be set.