Resilience Measures

When there are doubts as to the ability of the telephony layer and the switch to manage resource allocation in a timely way, then integrators will want to consider using CTI Schema 2 fromTelephony Resource Management.

There are other actions an integrator can take to ensure CTI resilience, as follows:

Softdial CallGem™ CTI timeouts

Softdial CallGem™ supports timeouts for certain CTI activities. We would recommend that when going live for the first time with a Softdial CallGem™ installation or expanding the installation that you specify these in your CTI layer integration.

Refer to the Timeout Trigger (TT) parameter in the Open Campaign [OC] message. This will time out calls initiated after 1 minute if there is no response from the CTI layer. Numbers timed out will be sent back to the application layer in a Number Back [NB] message.

Using timeouts, however, should not be viewed as a permanent solution. If they come into play, it is an indication that you have performance problems in your switch or CTI layer which should be addressed and solved.

Timeouts for switch activity in the CTI layer

You may want to consider dropping calls being dialed after a given period if there has been no response from the network. Usually if a call that has been dialed is ringing, the network will send back a response to this effect. If the network 'loses' the request to dial then the CTI layer should time this out, otherwise this will consume trunk resources and lower dialing performance.

Timeouts for switch-determined routing

In order for Softdial CallGem™ to track agent availability and manage preview and abandon retry calls there is quite a complex handshaking arrangement between Softdial CallGem™ and the CTI layer. Softdial CallGem™ will automatically timeout requests for agents to go unavailable after 30 seconds.

This timeout may need to be varied (using the Unavailable Timeout (UT) parameter in the Open Campaign [OC] message) depending on how the switch handles allocation and deallocation of agents. Ideally the CTI layer should respond in timely fashion to requests as timing out this operation can have potentially undesirable effects.

Network provider issues - Fast Busies

A common source of problems for predictive dialing systems is network provider quality of service. Sometimes network providers cannot deal with the volume of calls generated by a predictive dialer, so the call fails and the network provider returns some sort of Q.931 code identifying this. We call this condition a Fast Busy.

Sometimes you may also find conditions where the local exchange of the area being dialed into may not have the capacity to deal with a significant volume of calls. This situation may also generate fast busies, even if the local network provider gives an adequate quality of service. This is a good argument for randomising call lists but more importantly it means that when developing a CTI layer integration you must consider the effects that fast busies have.

Unless it is possible to identify and tell Softdial CallGem™ that a certain call (or more likely several calls at once) have failed as fast busies, Softdial CallGem™ will determine that there are a large proportion of calls failing in very short order. This will cause the dialing rate to be increased, which would be the correct thing to do if the calls were genuine busies. However, in the scenario where the network cannot cope with the volume of calls being put through at that point in time, attempting to force even more calls through to compensate for this will exacerbate the problem.

Softdial CallGem™ has a throttling mechanism to prevent this from happening. To take advantage of this, your CTI layer must recognise fast busies and send back a Call Failed [CF] message with an Cause (CA) parameter value of 26 (Fast Busy)

This will artificially damp the dialing rate until such time as the network can place calls successfully. Whilst this reduces the performance of Softdial CallGem™ it does not cause the same level of problem that swamping the network with calls will bring.

Softdial CallGem™ will also log information about fast busies to the Event Log. This is useful in that it provides concrete information to enable the end-user to tackle errant network providers about poor quality of service.

Persistent network congestion issues

In the UK and elsewhere there have been reports of regular fast busies (Raw ISDN cause 41) occurring when the far end picks up but the network lacks the capacity (either SS7 or GSM network) to carry the audio stream.

In the short term any users suffering from systemic and repeated fast busy meltdowns (because of > 15% fast busies) should follow this advice:

Map ISDN cause 41 or SIP cause 503 to outcome 27 (Hi and dri). Normally Fast Busies are mapped to outcome code 26 - mapping to outcome code 27 will avoid the fast busy meltdown temporarily but is a mis-reporting of fast busies within Softdial Contact Center™.
Run an external fast busy report to give to your carrier. To assist with this we have created a simple AWK script based report (download here) that will analyse a msglog and generate a report listing phone numbers, launch, progress and fail timestamps for fast busies with more than 10 seconds of ring time. If you do not know how to do this, please contact your local Sytel representative.
Do not use the Call Progress Analysis setting None or Native (Detection Option 0) as this does not perform any inband or out-of-band detection of network signalling. See Telephony Settings for details or check the API Guide for the details of the Detection Option (DO) parameter if not using Softdial Campaign Manager™. The Detection Option (DO) parameter is present in the following messages: