We have installed CUBAC and followed the manual to get a basic test install working. So far so good, but for one big problem. We are trying to set up two queues - one for internal "operator" calls, and one for external calls. The intention is that the receptionist can press + to pick up the next most important call and this will give preference to external calls.
To do this we have created two separate queue numbers in the CUBAC web admin tool, as normal (these are 9430 and 9432, as it happens). If we call these from a local IP handset the calls present as expected, and in the correct queue. We have then created a translation pattern that maps an external test number to 9432. When we call that from outside, the call rings to the caller but does not present on any CUBAC queue.
If we change the translation pattern to point to a different number, say a handset, it rings normally so we're catching the call and the translation seems to be working. CAR shows no difference between the two cases other than the different target DN, of course.
The call is entering the system on a SIP trunk via a CUBE on our site, talking to a voice gateway at our provider (assume there is an upstream CUBE there too). We're stumped so far - can anyone suggets places we can go look to see what could be going wrong?
We've tried checking everything is in the right CSS etc. but no luck so far.
Please let me know if you need any more detail, and thanks in advance for any help and suggestions!
Are all of the CUBAC CTI Route Points *and Ports* as well as the target operator DN in the Incoming CSS of the SIP trunk? We have seen this many times where the underpinning CTI behavior uses the original calling party CSS instead of the Route Points (DDI) CSS which can't see the ports.