Showing results for 
Search instead for 
Did you mean: 

UCCX Maximum number of sessions reached does not give a busy tone



I want to manage the maximum number of calls per application with the "Maximum number of sessions" parameter in the UCCX application and the telephony trigger.


I programmed a large group of ports shared by all the applications. I have defined a maximum number of sessions for each application. When the maximum number of sessions is reached, external callers hear an error message rather than a busy tone.


When the call goes through a SIP trunk: the CUBE receives 403 Forbidden.  When the call goes through a PRI (Q931): Call Rejected.  


Have you ever experienced this problem and what solution did you apply?

1 Reply 1

Anthony Holloway
Cisco Employee
Cisco Employee

I have not really dealt with this too much, but I can replicate it to see what I can find out. But first, in your two PSTN connectivity scenarios, is the CUBE one sip-to-sip and is the PRI one mgcp-to-pri?




Confirmed that max sessions on an Application get answered like normal, but the default script on the Application gets executed, which is the "I'm sorry" message we're all familiar with.


I suppose you could write your own default script to play busy signal using the following script, but then you'd need to make sure your trigger sessions are always higher than your application sessions (which is not how it works by default - especially with multiple triggers on your app).


Accept (--Triggering Contact--)
Call Redirect (--Triggering Contact-- to "BUSY")
Terminate (--Triggering Contact--)

Confirmed that max sessions on trigger get rejected instead, with a fast busy signal heard on PSTN side, and an ISDN cause of 0x8095 - Call rejected is sent to telco


I suppose you could forward busy on the production trigger to a dedicated trigger/app combo which all it does is play busy tone.  You could use the same script as above, or there's actually a dedicate application type called Busy you could use for this one.  Though, you'd need to always make sure this trigger/app combo has resources available to play.  Since it's short lived....maybe 3 could get away with a lot less resources dedicated to it.



Not tested yet, though, it might just be the same as the above, since I feel like the solution will have to come from uccx and not the gateway anyway.