UCCX Simple Busy Query

Answered Question
Mar 25th, 2010

I have a simple script. It works fine. It takes upto 12 calls.

Unfortunately the numbers of people in the call centre answering calls is low and the lines are

always busy.

I would like to play a busy message.

I have set the Cisco Script application 'Maximum number of sessions' to 12

I have set the Trigger to match this (When I set this number higher I get a 'we are currently experiencing system problems' prompt, this works but its not desired)

I have set all the trigger call forward settings to my busy number (a simple app that plays my busy prompt)

Yet users still hear fast busy. Its not forwarding calls on busy to my number.

Please note if I add the busy number to the 'forward all' field, the call forwards fine and I hear the desired busy prompt. So I know its not a CSS / region / codec /partition issue.

Why isnt the trigger / UCCX honouring the 'forward busy internal' / 'forward busy external field' ????

I notice you can setup a busy application, but I dont see how you attach that to existing applications or how you add a prompt to it.

Maybe I am doing this all wrong.

Any advice would be greatly appreciated.

I have this problem too.
0 votes
Correct Answer by Anthony Holloway about 6 years 8 months ago

From what I have read, you set this up correctly, and it should have worked.  I just validated it in the lab against CUCM 6.1(2) and UCCX 7.0(1) SR5.

You may have run into a defect, or perhaps a simple restart could get this working.

Here is what I tested:

     Components:

          Trigger 4001/internal with Application Test (simple ACD queue)

          Trigger 4002/internal with Application BUSY (busy app)

          CUCM CfwdBusy Internal/External to 4002 with CSS allinternal

     Tests

          App Test Sessions = 1; Trigger 4001 sessions = 1

               First call gets treatment

               Second call gets slow busy from App

          App Test Sessions = 2; Trigger 4001 sessions = 1

               First call gets treatment

               Second call gets slow busy from App

          App Test Sessions = 1; Trigger 4001 sessions = 2

               First call gets treatment

               Second call gets slow busy from App

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
keanej Fri, 03/26/2010 - 05:21

I got a solution for this one

Set the trigger to 20

Set the application to 12

Set the default application to a simple app that plays a busy prompt

Then when the script fails due to max calls being exceeded it will fail over to the default and play the busy.

Correct Answer
Anthony Holloway Fri, 03/26/2010 - 08:46

From what I have read, you set this up correctly, and it should have worked.  I just validated it in the lab against CUCM 6.1(2) and UCCX 7.0(1) SR5.

You may have run into a defect, or perhaps a simple restart could get this working.

Here is what I tested:

     Components:

          Trigger 4001/internal with Application Test (simple ACD queue)

          Trigger 4002/internal with Application BUSY (busy app)

          CUCM CfwdBusy Internal/External to 4002 with CSS allinternal

     Tests

          App Test Sessions = 1; Trigger 4001 sessions = 1

               First call gets treatment

               Second call gets slow busy from App

          App Test Sessions = 2; Trigger 4001 sessions = 1

               First call gets treatment

               Second call gets slow busy from App

          App Test Sessions = 1; Trigger 4001 sessions = 2

               First call gets treatment

               Second call gets slow busy from App

Clifford McGlamry Mon, 05/11/2015 - 10:53

Anthony,

 

Realize this is a very old thread.  I cannot get your method to work on UCCX 10.5, and suspect this might be the case for all the appliance versions. 

I was able to get it to work using the method "keanej" pointed out.

Any chance you can validate against your earlier findings with the newer versions?

keanej Tue, 05/12/2015 - 00:49

I have this working on a VM version running on UCS, We are on UCCX 9.0.2

The concept is simple enough

 

Go into the trigger and click  'advanced trigger information'. Enable that and set the sessions to a number higher than the application.

 

The trigger will accept the call but the application will not. This lead to the application failing over to the 'default script' at the bottom.

Set this script to be an office busy.

 

The default script is invoked whenever there is a fault or the main script has an issue. In this case the issue is that the max sessions has been exceeded.

 

I cant see how this wouldn't work !

 

 

Clifford McGlamry Tue, 05/12/2015 - 20:04

Yes, that solution does work.  However, I was curious about Anthony's original test where he had diversion working on the CTI RP.  I have a feeling the behavior changed when the platform was ported to Linux, and I was curious if he could repeat his previous test and report the results since he WAS able to get it to work. 

Actions

This Discussion