JTAPI Maximum Number of Sessions / Call Overflow

[tony.blackwell]

Does anyone out there know what should happen if the number of incoming calls to a JTAPI trigger exceeds the maximum number configured for that trigger.

I am trying to work out what should happen as I am trying to route an incoming call to a different JTAPI trigger if the number of calls on the first JTAPI trigger has been exceeded.

I thought that by configuring a Call Forward Busy, or no answer or failure on CallManager would send the call to another trigger but I only seem to get Number Unavailable tone. A more detailed explanation of my current scenario is listed below.

Any comments or suggestions would be greatly appreciated

Detailed Scenario

I have created two scripts, two applications and 2 JTAPI Triggers. On my first application I have set the maximum number of sessions to 1 (it doesn’t matter if I make this 2 or higher). I have also set the maximum number of sessions to 1 for the JTAPI trigger that is associated with this application.

On CallManager I have set Call Forward Busy, Call Forward No Answer, and Call Forward on Failure to point to the 2nd CTI Route Point (and therefore 2nd JTAPI Trigger).

I place my first call into the first CTI Route Point (i.e. first JTAPI Trigger) and the call is successfully handle my the first application.

I then place a second call into the first CTI Route Point and receive NU tone.

When I check the JTAPI logs the call seems to be routed from CallManager into the IPCC Express server and then the call gets rejected, and the log states that there is no forward destination so I guess this is why the call gets NU tone.

[adignan]

For this scenario you have to set the CFB, CFNA, and CFF on the CTI Ports. Therefore, you would have to create two CTI Port groups in order to send busy/failed calls to the correct spot.

Andy - Berbee

[tony.blackwell]

Andy, many thanks for the post. I now understand how to get the fail over scenario to work as the customer requires. Your solution works but here is the soultion I used. Someone may find it useful.

The scenario is:-

If the number of calls directed to a branch exceeds the maximum number allocated to that branch the call should be routed to its’ buddy office.

For example if the maximum number of calls for Branch A is set to 8 the 9th call should overflow to Branch B. On the CallManager the Call Forward Busy option was set to the extension number of Branch B. The Application for Branch A on the IPCC Express server was set to handle a maximum of 8 calls (this was set on both the application and the JTAPI trigger). The JTAPI Call Control Group had a pool of 30 CTI Ports allocated to it.

Unfortunately with this configuration the overflow scenario did not work. After extensive investigation it became apparent that the reason for the failure is the way that IPCC Express and CallManager handle a call on a CTI Rote Point that is ultimately controlled by the IPCC Express server.

The call comes in on the CTI Route Point (e.g. 12345), and this call is immediately terminated on a CTI Port. It is at this point that the CTI Port tries to launch the application assigned to the CTI Route Point (or JTAPI Trigger). The application then runs and executes the appropriate script.

This is true for calls 1-8. When the 9th call is placed into the CTI Route Point there are still CTI Ports available (as 30 CTI Ports are configured for this application). Therefore the Call Forward Busy setting on the CTI Route Point is not invoked. At this point the call is terminated on an available CTI Port. This CTI port then tries to execute the application. The application rejects the call as the maximum number of calls has been exceeded. As the CTI Port has NO Call Forward Busy option set the caller receives fast busy tone.

The solution therefore is to configure CTI Port Groups for each branch so that the number of CTI Ports for each branch is equal to the maximum amount of calls that each branch can accept. The Call Forward Busy setting on the CTI Route Point will then take effect.

[tracey.marshall]

Tony, thank you so much for posting details of your scenario. I have the same problem. In my case, there is one pool of cti ports for all applications. I think I need to create individual pools and assign the number of ports that match the max session of each application. Your posting was most helpful.

Regards,

Tracey

[stevecrumbaugh]

Alternate solution:

1) Have as many CTI Ports as you wish to have calls enter the system (all sites).

2) Set the number of sessions in the application config screen to the number of calls you wish to go to the first site.

3) Create a new queue script, CTI-RP, and application for the the second location, use the same CTI Port group.

4) Create a new transfer script that simply transfers calls to the new queue CTI-RP

5) Set the default script on the first application configuration to the transfer script.

When calls come into the first CTI-RP, they hit the first queue app. If the number of sessions is larger than the threshold, it will transfer the calls to the second queue. If the system-wide total is exceeded, callers will get busy. (You could bump up the number of CTI ports, create a busy script that asks callers to try again later then disconnects, and set this as the default for the second queue app - this will handle the overflow without a busy signal.)

Alternately, you could have everyone in the same queue, make it skills-based, and give the first location agents priority for incoming calls.