Telephony Issues

Most call centers will not have the inhouse means to easily calculate trunk requirements. They may have limited knowledge and understanding of their current data and future calling patterns. And they may also lack the tools to forecast future volumes, from their base data.

Call throughput limits are imposed by SIP carriers. They protect their SIP networks with session border controllers (SBCs) that do several things:

1. Provide security (deny calls from unauthorised parties)
2. Convert SIP traffic from different types of device to a consistent 'flavour' of SIP
3. Re-encode and/or re-frame RTP streams to be consistent (number of frames per packet, codec)

The SBC can be thought of as a call and media processing device (STG may be configured as a kind of SBC). SBCs are generally hardware devices which have finite limits on call processing capacity.

These limits are set by SBC manufacturers based on the throughput capabilities of their devices. A typical SBC configuration allows for a call launch rate of 1 call per second for each 100 trunk lines, with a healthy safety margin (~300%). This is consistent with call launch rates across the network at large from domestic subscribers.

Predictive dialers need to have a higher rate of calls being launched than is typical. This requirement must made clear to the service provider when specifying the service requirement.

As a rule of thumb, a good predictive dialer can launch 1 call per second for each 10 trunk lines, or 1 call for each 5 predictive agents per second, roughly ten times the throughput that most carrier SBCs are designed to provide.

In all sites where SIP trunking is used, STG should be configured to limit the number of calls per second to a value that is appropriate for the size of the installation (See Managing Throughput ).

Setting this limit will ensure that the carrier does not reject calls at the SBC owing to lack of capacity and also prompt the user to verify that the carrier can handle the throughput rates needed by a dialer.

(See also CTI Integration - Best Practice)

Calls may be delivered to the network via a wide range of media and signalling types. In practice there are two main groups of telephony protocols in regular use. The advice below reflects the state of the industry at the time of writing. This will be subject to change.

In card based (ProsodyX) systems the number of available channels is dictated by the number of physical DSPs fitted to the card. Typically this is 120 channels per DSP but may vary depending on the type of card.

In a host based (ProsodyS) system, the number of available channels is dictated by the specification of the host platform (See Sytel Media Server ).

Whatever the configuration the number of agents and calls that can be supported depends on

the total telephony system channel capacity and

the number of channel resources that will be consumed per call.

The number of channels used per call session will vary depending on typical business practice and workflow.

To determine this, the following factors must be considered:

Process	No. of Channels Consumed
Inbound Call	1 per call
Outbound Call	1 per call
Call Recording	1 per recording
Playing a Wav File	1 per call
Playing a TTS Fragment	1 per call
Echo Cancellation	2 per call (1 for echo canceller, one for ref input)
Call Progress Detection	1 per call (DTMF, SIT, AMD, FAX)
Conferencing	1 per conference leg

Add up the number of channels used based on your workflow this will give you the maximum number of channels used per call.

Divide the value from 1. above by the value from 2. above and enter the result into the <maxIpCallsPerDsp> element in the STG config.xml file.

This will provide the system with the correct set of variables to anticipate channel exhaustion and prevent resource errors (-107) from occuring.

Most carrier echo cancellation has a 64ms tail and processing is done in the DSPs on the media gateways. Prosody S echo cancellation has a 200ms tail to allow for transcode latency.

In extreme circumstances some calls can have up to 500ms echo. In these unusual cases it is likely that the far end carrier is mediating the call from SS7 to SIP, transcoding to G.729 for transmission over an internet connection to the respondent's home, which then gets converted back to Analog, for example, a respondent using MagicJack Plus connected to an analog handset. There is nothing that any carrier or Sytel can do to eliminate an echo tail of this duration.

Prerecorded messages to be played by the telephony layer must be recorded in a compatible format. For messages to be played using the Aculab Prosody/ ProsodyS system, sound files must be recorded in CCITT 8KHz Mono, ALaw or ULaw depending on the locale set on installation.

See Playing Messages for details on how Softdial CallGem™ handles sound files.

For detailed information on how to manage RNA timeout effectively, see Performance Issues, Ring No Answer Timeout - Best Pactise section.

In an ISDN trunking environment (the norm for most installations), running at or close to trunk capacity can lead to local fast busies. Even though Softdial CallGem™'s API expressly caters for such resource management issues there will inevitably be some crossover.

To avoid problems in live running, there are a number of steps integrators should take:

• Ensure that predictive dialer trunk resources are exclusive to Softdial CallGem™. These cannot be shared with other telephony applications or used for inbound traffic, regardless of the fact that telephony signalling environments cater for negotiating in/out traffic on the same trunk.
• It is often the case that carriers report idle state on a trunk line before that trunk is ready to be reused. This has the potential to cause fast busies when operating under full load. Best practice is to build in a configurable delay in notifying Softdial CallGem™ that a trunk is idle (via the Now Disconnected [ND] message). The delay may need to be anything between 300ms and 2 seconds depending on local conditions.
• Ensure that fast busies get reported accurately. If the telephony equipment used in the call center fails to report fast busies accurately, this will lead to Softdial CallGem™ launching ever increasing numbers of calls as the live call rate drops.

Softdial CallGem™ has logic to throttle trunk utilisation when fast busies are signalled. If fast busies are mis-signalled as some other type of failure, this will lead to Softdial CallGem™ working very quickly through the calling list and disposing potential live contacts as calls failed. (See also Resilience Measures - Network provider issues - Fast Busies section)

A typical 100-seat outbound call center generates a similar level of busy hour call attempts to a telephone exchange serving 25,000 residential customers. This is why call centers can fall foul of telephone network bottlenecks. There are a number of actions that can and should be taken to minimise this problem.

• Randomising Data
  All too often data is sorted by telephone number which has the effect of grouping calls by area code and putting unnecessary load on the remote exchange. This will lead to fast busies.
• Cellular Campaigns
  Often call centers will run campaigns that address cellular subscribers. Such calls often end up routed via a single GSM gateway into the cellular network. This is a major source of bottlenecks. Whenever possible, such campaigns should be run against both cellular and landline numbers, in order to reduce load on the cellular gateways.

When a predictive call connects there are two ways of getting the connected call to an agent; the dialing engine can make a routing decision, or a telephony device may route the call to an agent.

Because Softdial CallGem™ is 'in charge' of call center resources it is generally safer to have Softdial CallGem™ make the routing decision. There are good reasons why the telephony device may want, or need, to make the routing decision (skills-based routing support on the telephony device, or PBX integration where some form of MakePredictiveCall API is supported). In these cases there are a number of additional things that integrators must manage carefully:

Call progress analysis in abstract terms is about determining the outcome of a call from a number of signalling sources; out-of band signalling, inband signalling and media stream analysis.

For most call centers this often gets simplified to 'run Answering Machine Detection (AMD)'.

Generally, hardware architectures that support multiple media/signal analysis tasks on the same call are better than architectures that support one only type of task for a given call. Support for SIT (carrier intercepts) and signalling tone detection is usually highly desirable if:

• dialing into North America,
• calls are launched via an IP-based carrier,
• calls will terminate in the GSM network.

Support for inband signalling protocols such as robbed-bit only has value if dialing into North America AND the signal analysis equipment does not support SIT/tone detection.

AMD has business value only in environments where nuisance calling is tolerated and it will not affect the likely outcome of a call. AMD is inherently failure-prone and so managing detection failures should form part of an AMD delivery strategy. Because of the delays in doing such detection (i.e. the called party is kept waiting), then AMD is often best avoided.

When customers are keen to use AMD, despite its inherent delays, we advise that controlled campaigns should be run. One week, say, with AMD on and one week with it turned off. When AMD is turned off, talk time per agent hour will drop, but very often overall results will improve, because of better call quality. See also Performance Issues - Answer Machine Detection section.