WombatDialer uses a "fat client" model where the client - running in your browser -
is a complex JavaScript application. If you update WombatDialer, it may be possible that
your browser still caches the previous version of the application client, so you get an
"IncompatibleRemoteServiceException" because the server detects the client is out of sync.
In order to fix this issue, just click the "refresh" button of your browser or clear
the browser's cache.
This error is usually caused by an otdated version of the web.xml file. In order to fix it,
please follow the procedure below:
/etc/init.d/qm-tomcat6 stop
cd /usr/local/queuemetrics/webapps/wombat-0.6.8-448/
cd WEB-INF/
mv web.xml web.xml.old
cp web.xml.ORIG-0.6.8-448 web.xml
/etc/init.d/qm-tomcat6 start
If you go to the License page and you see that the license's expiry date is incorrect,
you should check the state it appears in. If it is not in state:
ACTIVE
as licenses usually are, but it appears as:
ACTIVE_P
this means that the license is Active pending verification. It is also possible
that WombatDialer displays the license in state:
W/P
that basically means it is not able to activate a new license.
Both these errors means that WombatDialer cannot talk to the licensing server to activate the license. In this case, if the license was activated at least once, it can be still be used but only for a limited period until it is properly verified, and thence it shows has an incorrect expiry date. WombatDialer tries verifying it up to that point in time, but if that's not possible, the license is shut down.
The solution is to make sure that WombatDialer can connect to the internet for license verification - it will use an HTTPS connection to our servers. WombatDialer requires outbound internet connetivity and cannot run without. It can use a direct connection or can go through a proxy (eg SOCKS) - to set ut up, look at Using an outbound proxy on the User Manual.
The User Manual also details all different states a license may be in - have a look at the The License page section.
There was a slight change in the JDBC format, so you must edit the tpf.properties file that you usually find under:
/usr/local/queuemetrics/tomcat/webapps/wombat/WEB-INF.
Look for the tpf.properties file and replace the entry:
JDBC_DRIVER=com.mysql.jdbc.Driver
JDBC_URL=jdbc:mysql://127.0.0.1/wombat?user=wombat&password=dials&useUnicode=true&characterEncoding=UTF-8
With:
JDBC_DRIVER=org.mariadb.jdbc.Driver
JDBC_URL=jdbc:mariadb://127.0.0.1/wombat?user=wombat&password=dials&autoReconnect=true
See also the Upgrading section of our manual for the changes, and then restart.
You may often want to set the Caller ID of the call when sent to the agent
to something that makes sense to the agent - for example, the number
just called, or the name of the person called, or the name of your campaign.
In order to do this, you need to intercept the call before it is sent to your queue
and rewrite the Caller ID. Consider that all the attributes you set on the call
are available as channel variables in Asterisk, so you can set any attributes
you want the agent to see.
For example, imagine that your queue 999 is located at extension 999@from-internal.
Instead of sending connected calls to that extension, you could create a piece of
dialplan to do the rewriting and the jump to that extension, like for
example:
[wbt-rewrite]
exten => 999,1,Answer
exten => 999,n,Set(CALLERID(num)=#${ID} ${PERS})
exten => 999,n,Goto(from-internal,999,1)
Though it is not possible to have different time-zones for numbers in a call list, WombatDialer lets you run
multiple campaigns in parallel.
So we suggest running a separate campaign for each time-zone, so it can have separate "opening hours" for each.
It is perfectly okay to have multiple campaigns running using the same trunk and end-point, and they will share
the load based on their priority (as a starting point, make sure they are have the same priority).
The issue seems to be related to WombatDialer not being able to initialize its environment properly,
and this is usually caused by the JVM not being able to detect the current network configuration.
This seems to be a transient issue and can easily be fixed by issuing a:
/etc/init.d/qm-tomcat6 restart