×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

CUBAC external calls not presenting in queue

Answered Question
Aug 6th, 2013
User Badges:

Hi


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!


Thanks

Sean

Correct Answer by Jonathan Schulenberg about 4 years 2 weeks ago

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.



Please remember to rate helpful responses and identify helpful or correct answers.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
Amine Nouasri Wed, 08/07/2013 - 05:11
User Badges:
  • Bronze, 100 points or more

Something to check is if Force Delivery is checked on that particular queue. This will cause the call to ring the line without holding in the queue.


Hope this would help! 

Correct Answer
Jonathan Schulenberg Wed, 08/07/2013 - 09:36
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 IP Telephony

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.



Please remember to rate helpful responses and identify helpful or correct answers.

Sean K Thu, 08/08/2013 - 15:27
User Badges:

Thanks, that seems to have done the trick!

Actions

This Discussion