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

[celine.jeannotte]

Hello,

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?

[Anthony Holloway]

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?

EDIT: 

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).

Start
Accept (--Triggering Contact--)
Call Redirect (--Triggering Contact-- to "BUSY")
  Successful
  Busy
  Invalid
  Unsuccessful
Terminate (--Triggering Contact--)
End

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 seconds...you could get away with a lot less resources dedicated to it.

SIP-to-SIP

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.