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

Pages: [1] 2 3 ... 202
Running WombatDialer / Re: view call details in Queuemetrics
« on: June 09, 2016, 15:06:59 »

If your says "useBatchUpdate" in the driver specs, please remove it.
We are about to release a new version of Wombat that should fix this error in its many ramifications.

No, Wombat uses queue presence exactly for that reason - so that it is consistent between inbound and outbound.
But usually is you use e.g. SIP channels, their presence should be correct on queues and even when used without a queue.

Please update to the current RPM version
Do this:

Code: [Select]
yum clean all
yum update wombat

And it should immediately download and install
Please let us know how it goes.

Improving QueueMetrics / Re: Agent blue pause
« on: December 05, 2015, 08:43:01 »
We cannot do much about this as Asterisk is likely not aware of anything; so it will still try to route calls to them. The need to use Asterisk pauses to go to pause.

WombatDialer Soporte en Español / Re: wombat dialer agent page
« on: December 04, 2015, 18:49:53 »
I was able to reproduce the issue.

Thanks that helped.
The problem seems to be that Wombat itself tries to connect to itself using the supplied URL, but that does not really work on your box.

What I did was that I edited the file agents/rd_pop.jsp forcing the URL to be

Code: [Select]
String localUrl = HttpUtils.getRequestURL(request).toString();
localUrl = "";

Now it appears like it's working.
As a general solution, I wonder whether we should add a parameter so that one can specify a local base URL.

Running WombatDialer / Re: Campaign report
« on: November 23, 2015, 12:16:00 »
This si because it depends on when the run was started, not when calls were placed. You can use QueueMetrics to get more in-depth analysis.

We trac this as bug #2943

Running WombatDialer / Re: Campaign report
« on: November 17, 2015, 11:25:59 »
The campaign report uses the start date for the specific run, no matter when the calls were done.

I would try:
- stop the dialer
- make a backup of the DB
- delete all rows from hopper, hop_calls and hop_lists
- restart

If you can send us the database dump to our email support, we can see if there is a workaround to avoid such situations in the future.

You can add them to a black list automatically.
First you crete a campaign, and add to it a blacklist (maybe empty).
You have them press a key or something that ends the call in a specific extended status, eg "NOCALL"
You then add a Disposition Rules so that numbers ending in ext status "NOCALL" are added to your blacklist.

See specifically 3.6.4

WombatDialer Soporte en Español / Re: wombat dialer agent page
« on: September 28, 2015, 13:05:16 »
How was WombatDialer installed? because it works fine in our RPMs. Maybe you are using Tomcat 8?

AGAW / Re: AGAW not working - update
« on: September 28, 2015, 13:03:55 »
As you can see from the date it is VEEERY old.

The tavern / Re: Welcome everyone
« on: September 28, 2015, 13:02:10 »

I think that you need a newer version of MySQL, like 5.5, and possibly set:


Introduced   5.5.14
Command-Line Format   --innodb_large_prefix
System Variable   Name   innodb_large_prefix
Variable Scope   Global
Dynamic Variable   Yes
Permitted Values   Type   boolean
Default   OFF
Enable this option to allow index key prefixes longer than 767 bytes (up to 3072 bytes), for InnoDB tables that use the DYNAMIC and COMPRESSED row formats. (Creating such tables also requires the option values innodb_file_format=barracuda and innodb_file_per_table=true.) See Section 14.8.7, “Limits on InnoDB Tables” for the relevant maximums associated with index key prefixes under various settings.

For tables using the REDUNDANT and COMPACT row formats, this option does not affect the allowed key prefix length. It does introduce a new error possibility. When this setting is enabled, attempting to create an index prefix with a key length greater than 3072 for a REDUNDANT or COMPACT table causes an ER_INDEX_COLUMN_TOO_LONG error.

Pages: [1] 2 3 ... 202