Cisco CallManager Call Queues

[Yarin Ezra]

Hello Cisco Community,

I have an issue with one of my customers that he needs to have a endless queue for calls.

The situations is this, they have UCCX which of course uses scripts to redirect calls, the calls are redirected to Hunt Pilots.

When a call enters the Hunt Pilot it has a timer for unanswered or busy to go to a destination (another script) which redirects them again to that Hunt Pilot over and over again.

That solved their problem for a "Queue" the issue is the callmanager is configured to a number of HOPS then after the call reaches that number, the call drops so we configured it from the default 12 to 17.

The customer doesn't want the call to drop, he wants it to continue endlessly or to play a prompt at the last hop that says: "there aren't any available agents please call again later".

Note that the customer does not want to integrate CSQ's in their scripts nor use Finesse, they also never configured Queues in their Hunt Pilot.

The solution would probably be to configure Queues in all of their Hunt Pilots but the problem is that they have over a 1000 Active ones.

If i were to configure Queues in their Hunt Pilot and again over a 1000, would that be an issue regarding the Cisco Software/Hardware in terms of excessive resources? Note that we would not use MOH for the Queue.

Is there another way to configure a Queue without the use of CSQ's or Hunt Pilot Queue or 3rd Party Servers?

[Roger Kallberg]

What you’re doing is not a queue, it’s a string of hops that the call is put through. If you want to queue the call you’d need to use a queuing mechanism. It’s as simple as that.

[Yarin Ezra]

Yes of course i know the HOPs doesn't solve the queue problem but it did solve the amount of time a customer holds the call until it reaches the end.

My question is, as far as a queuing mechanism, the obvious choice would be to configure the Hunt Pilots to hold the queue, but would that be a resources problem? like would that be a load on the system? is there any other solution for queues other than Hunt Pilot or CSQs?

[Roger Kallberg · Accepted solution]

Yes there will be a strain on the system if you start using queuing on Hunt Pilots. Also do note that the queuing mechanism in CM on HPs is quite rudimentary. It would very likely not operate as you seem to think that it does. The only, at least IMHO, queuing is with a CC service. Recent evolvement in cloud calling platforms could have functionality that potentially could be equated to that of a CC service.

[Yarin Ezra]

The Client has a secure environment which would not allow to use cloud services, so using queues in that number of hunt pilots would not be a good idea and CC is the only logical way without using 3rd Party services or Cloud services.

Thank you very much Roger

[muhammadhaseeb18051998]

The situation you have described can be challenging. While it is possible to configure queues in all of the hunt pilots, this may not be the most efficient solution and can consume excessive resources on the Cisco software/hardware. Additionally, this solution may not be scalable if the customer needs to add more hunt pilots in the future.

One possible solution that could be considered is to modify the current script that redirects the call to the hunt pilot. You could modify the script to play a prompt to the caller when the call reaches the last hop indicating that there are no available agents and to call back later. You could also modify the script to redirect the call to another destination, such as a voicemail box, after a certain number of hops if no agents are available.

Another possible solution is to use the built-in queue feature of UCCX. This would require the use of CSQs, but it can provide a more scalable and efficient solution. You could create a single CSQ and configure all of the hunt pilots to use this CSQ as their destination. This would allow the system to manage the queue and provide more advanced features such as estimated wait time, position in queue, and the ability to configure multiple queues.

[Yarin Ezra]

I was thinking about modifying the scripts but the problem is since the call is leaving the script and redirecting to the hunt pilot it send the call back to the script as new so i cant modify a counter to note how many hops it has been an play a prompt at the end, also because the CUCM ends the call not the UCCX.

About the CSQs also a reliable solution but the customer doesn't want to use Finesse or to modify the scripts at all.

[Roger Kallberg]

Sounds like your customer is “fun” to work with. ‘:-/‘ How can they expect to get a different outcome if they’re not willing to make any modifications?

On the counter part of the script. You could use a number of different trigger numbers associated with the same script to send the call from the hops trough the string of HPs. For example HP1 sends to trigger 1, HP2 sends to trigger 2 and so on. That way you could take action on the number of loops it’s gone through, based on the trigger number the call came in to and program an action at a point that you want.

[Yarin Ezra]

So much fun to work with, couldn't agree more.

Could you please explain further the solution ? how do you mean action on the loop based on the trigger number?

Creating a script or modifying one and add(if callednumber==XXXX) play prompt > Goto terminate?

how would you control the counter for the HOPS if the cucm manages that part?

[Roger Kallberg]

Let’s see if I could get it clearer. Say that you have a script/application in CCX. On that application you can have multiple trigger numbers. Now let’s say you have a need to loop the call trough a construct containing 10 hunt pilots and want to know when the call returns to CCX again for each of the loops. To do that you can use individual forward numbers to send the call from each of the HPs, like I outlined in my previous response. Then in the CCX script you can use that to take any action that you want based on the called number, aka the trigger number. The control/counter part of number of hops will be set by what trigger number that is used, ie trigger 1 = one loop, trigger 2 = two loops and so on.

[Yarin Ezra]

If i understand it correctly, that means to configure say 10 Extra hunt pilots that Forwards the Busy/Unanswered calls to different hunt pilots for each currently configured Hunt pilots?

[Roger Kallberg]

Yes, that would be about correct, with the distinction you pass the call past the CCX script before it enters the next HP. Having multiple HPs is how I understood that you have setup already, but going back to read your original post I now understand that you might possibly have one HP that you loop the call back to. If that’s the case then you can not do anything to count the number of loops.

An outline of the call would be this.
Caller > CCX (trigger start) > HP 1 > CCX (trigger 1) > HP 2 > CCX (trigger 2) > HP 3 and so on.

[Yarin Ezra]

That would mean to multiply the HP by the number the customer would want the HOP to be since there's each HP for each Branch/Team which were already at over a 1000 HP configured ATM, appears to be that there's no real solution but 3rd party or CSQs and Finesse or FIPPA

[Roger Kallberg]

That is correct and why I stated that the only real queuing option is to use a CC service.

[Jonathan Schulenberg]

You should be able to calculate the load on CUCM and demonstrate that the cluster will operate within supported limits by using the Collaboration Sizing Tool (partners access required). Annunciator and media termination point resources are required for Native Call Queuing - so be careful sizing those accordingly. The call will lose its position in queue every time it bounces between CCX and the Hunt Pilot.

Also, there is a decent (not air tight) argument that the current call flow is not supported anyway. Transfers/redirects from a CCX Application to a target number in CUCM that does not match another CCX Trigger but which is then immediately transferred back to CCX can create a memory leak. In this instance I’m thinking of call forward busy on the Hunt Pilot. There is some evidence of this in the Release Notes.

• Use of "Consult Transfer", "Direct Transfer", or "Redirect" to a translation pattern that maps back to a route point.

• The following scenarios have issues: External -> Redirect to Unmonitored device -> Call Forward No Answer (CFNA) to UCCX RP. Use of Redirect Step to an unmonitored device which then uses CFNA to a UCCX route point.

This is probably worth getting clarification from the BU via your Cisco account team so you have an answer in writing in case you ever need to open a TAC case.