UCCX 10.6 Call to Main CTIRP busy, Port Capacity reached

[sross]

How do we send a call to a CTIRP to Voice Mail if Maximum calls is reached?  No ports available for it to go to UCCX to read a script, so we just want callers to hear a Voice Mail Message?  We have tried setting the fwd bsy on the CTIRP to vm, no success?  Any direction would be appreciatied.

[sross]

FYI, I'm sure it is not a script error as it is not getting to the UCCX system from CUCM. It must be some configuration that I am not aware of how to set on the CUCM side.

[Gergely Szabo · Accepted solution]

Hi,

you can use the Default Script setting (on the Application page). It should be able to perform a single operation like sending the call off to a VM.

It is the "last resort" when something goes wrong with the regular script - including an exception thrown by the CCX Engine when there are no CTI ports left.

G.

EDIT: corrected a typo.

[sross]

Are you saying.....If I create a very simply script that sends callers to VM and point the default to this script on this page, the maximum number of sessions will not apply? Or am I mixing up the terms ports/sessions.  From my perspective I'm assuming they're the same thing, but that may be wrong. say we have 100 total ports.  the script below already has 30 active sessions, callers receive a fast busy, is that caused by port unavailability or session count?  If session count will the default script to vm still work or is there another solution?

Thanks in advance for your help.

[Gergely Szabo]

Hi,

that's an interesting question. I always used the Default Script to handle a situation when something goes wrong with "the" script (so it's kind of coming back from "the" script meaning the Maximum Number of Sessions limit has not been reached yet). Whether the Maximum Number of Sessions setting is a hard limit that won't let anything past the application (meaning it will just sort of crash, not giving a chance to "the" script or the Default Script) - well, this is something I never tried.

Actually, you can test it easily if you have a spare UCCX handy, just set the Max Number of Sessions to 1 and place two calls. I strongly believe it will reach the Default Script, and the reason is simple: UCCX won't just disconnect the call without actually giving the Programmer a chance to implement a sort of a workaround.

G.

[sross]

Cool.  I'll give that a try.  Thank you so much for your assistance.

[Sivanesan Rathinam]

Hi All - I have few clarifications here 

1. Maximum session is used to define the simultaneous session that can be handled at a time, even if we have 100 ports and we set max session as 10, system can handle only 10 calls at a time simultaneously, 11th call is disconnecting with busy tone tough we have 90 ports left

2. Default Script is used to route the call  goes wrong with the regular script until Application Manager Subsystem is INSERVICE 

3. So in that case if no CTI Ports left how the control will tranfer back to CUCM to route the call to Voice Mail ?

4. If no ports available calls will be terminated which you can find in Reports as Rejected call Report 

If possible create another call control Group with 2 CTI Ports and associate to Trigger and try to make 3th calls when two calls are already active in IVR and see the result

Regards,

Siva

[Sivanesan Rathinam]

I believe you are transferring to VM without any IVR treatment in that case no CTI Ports required

But here we need to check how calls will take Default Script if no CTI ports left,  Default Script will come in to picture when calls is abort not Rejected by system.

[sross]

Thank you for the clarification.  Our case is one where the sessions are 30, but the total ports is much higher. The callers receive a busy because of the session threshold.  I do not want to increase the session allowance because it would take away from the other applications.  Perhaps I simply decrease the session limit and add a reporting statistic to the app to check for calls in queue >X?  then if that is true send the calls to VM.  That will be my next question to the group.  How to add this reporting statistic and where. 

[Sivanesan Rathinam]

I do not want to increase the session allowance because it would take away from the other applications.

Session is not related to CTI Port and it wont take away from the other applications, Session can be 0 less than 2147483648

I have 25 ports with 5 Application each having 100 session

Logic is 

when Trigger Session is less than App Session, Call will be disconnected by Busy Tone when Trigger reaches max limit even call cannot be process by Application 

If application session is less than Trigger session, when App Session reaches max limit it cannot process the call which will be disconnected by system

Its highly difficult to process the call based on Real Time info of CTI ports which i never seen in my deployment, Any how will check for the same and update.

[Sivanesan Rathinam]

Below is the result of two scenarios which i mentioned above 

com.cisco.app.ApplicationMaxSessionsException = Aborted

Reject: Trigger Max Session = Rejected

[sross]

EXTREMELY helpful.  Thank you very much.  I will be able to resolve this just by adjusting my session/trigger limits which I did not clearly understand before.

Thank you for alleviating the need for me to open a TAC case.

[Sivanesan Rathinam]

TAC will not help you out on Scripting Part from 10.x we have Reports which gives your info about CTI Ports which is not Real Time even RTMT doesn't have 

If you get any info please update on this thread

[sross]

I can work on the scripting, I would have been contacting TAC about the busy, which is not an application issue, but just misunderstanding on my part of the session/trigger limits.  Now that you have clarified that for me I can resolve the busy issue and have more time to work on scripts.

If not RTMT, where do I go to get accurate CTI port info?

[Sivanesan Rathinam]

There is no real time info about CTI Ports as of my knowledge even i was searching for when i was working on earlier issue.

so my ques is if we doesn't know / System is not having real time info table how we can read the info through Script 

FWD busy of Trigger in Line config will not match when CTI Ports is not available which is not returned by CCX to CUCM, Earlier i worked by routing calls to Hunt when CTI RP is unregistered 

When App session  reaches max limit system will abort the call in that case we can invole Default Script 

If system doesn't have CTI Ports which is consider as Rejected which will never give ctrl back