CTI Integration - Best Practice

There are some characteristics that are fundamental to a successful CTI integration with Softdial CallGem™:

1. The call to the customer and the call to the agent (nailup leg) must be managed as two separate calls through their lifetime, and media must be switched between the two calls to deliver end-to-end voice.
   
   There are 2 main reasons for this architecture:
   1. Because of the amount of time it takes, and the reliability of redirecting the customer and agent endpoints to talk to each other. In the SIP world, if the customer and agent endpoints are remote, as is typical when hosting, this redirection can take several seconds and is dependent on functionality that not all SIP user agents support.
      
   2. It provides a media takeoff point for recording calls, other media processing such as sound playback, and provides a switching point to enable call transfers to be achieved without having to rely on specific endpoint or trunk functionality.
2. Signal detection needs to be both inband and out-of-band. It is not possible to rely solely on out-of-band signalling (SIP or ISDN) in order to classify calls. The fact that most calls now traverse different networks to reach a final destination means that inband signal detection is required. A large part of this document is devoted to signal detection strategies.
3. In order to do inband signal detection effectively, including Answer Machine Detection (AMD), media must be delivered to the call originator as soon as the call is proceeding. In a VoIP environment this means that the carrier must deliver 'early media'. In addition, voice media should ideally be delivered using an uncompressed (typically G.711) codec. It is possible to perform media processing on compressed audio, but this involves re-inflation of the audio stream and loss of resolution, which is not ideal. In circumstances where the bearer network is delivering media using G.729 or another low-bandwidth codec, carrier compliance with RFC2833 MUST be undertaken to ensure the carrier equipment reliably converts inband audio to out-of-band signalling before compressing the audio stream.

The life cycle signalling events for an outbound are as follows:

• for a call that does not connect:
   

  Originator	Network
  Launch Call to Network - ISDN setup / SIP invite	-
  -	Launch Acknowledged (optional) - ISDN Proceeding / SIP 100
  -	Call Alerting - ISDN Alerting / SIP 180/183 / inband ring detected
  Drop on timeouts (ring, no ring) (optional) - ISDN Disconnect / SIP cancel	-
  -	Call dropped - ISDN idle / SIP <final cause>

• for a call that does connect:
   

  Originator	Network
  Launch Call to Network - ISDN setup / SIP invite	-
  -	Launch Acknowledged (optional) - ISDN Proceeding / SIP 100
  -	Call Alerting - ISDN Alerting / SIP 180/183 / inband ring detected
  -	Call Connected - ISDN connect / SIP 200
  Originator drop (optional) - ISDN disconnect / SIP bye	-
  -	Call dropped - ISDN idle / SIP <final cause>

When a call is launched, timers for ring timeout and no ring need to be established.

Ring Timeout

The ring timeout is used to guarantee that a call will ring for a specified period at the called party.

It should be implemented as follows:

• On Launch Call, set a timer for the configured ring timeout value, plus 3 seconds. The additional seconds are to compensate for how long it may take to set the call up and establish a media path to the remote party. The 3 seconds should ideally be configurable.
• On first Call Alerting event (detected out-of-band or inband), reset the timer to the configured ring timeout value.
• On Call Connected, cancel the timer.
• If the timer is fired, drop the call and signal no answer

No Ring

The no ring timer is used to terminate a call that has not presented any sort of ring.

It should be implemented as follows:

• On Launch Call, set a timer for 11 seconds. (It may take up to 10 seconds to set up a call into the cellular network)
• On Launch Acknowledged, reset the timer 6 seconds (slightly longer than the North American ring cycle)
• On Call Alerting (out-of-band or inband), cancel the timer.
• If the timer is fired, drop the call and signal hi and dry.

Implementing the No Ring timer also provides a sure-fire way to pick up if your carrier has disabled early media.

In order to detect inband signalling you will need to run a tone detection algorithm. Tone detection uses a fast fourrier transform (FFT) algorithm to pick out pure tone frequencies. These frequencies can then be compared against a tone table to get a frequency match for:

• Ringback
• Busy
• Fast Busy
• Dead Line
• SIT Tones

The document does not discuss the national tones for different geographies - a web search will uncover all the reference data you might need for this. There are, however, various strategies that you will need to employ in order to ensure your generic algorithm covers as many different scenarios as possible. The strategies to be aware of are:

1. SIT detection
   SIT tones are 3 tones played in ascending frequency sequence. The first 2 tones each have 2 different possible frequencies, meaning that there are 4 permutations of SIT tones, each indicating a different type of failure. When doing SIT detect you should implement a state machine that detects one of the first 2 SIT1 tones, then move on to detecting one of the two SIT2 tones, and only after successful pickup of SIT1 and SIT2 look for a SIT3 tone. If you run the FFT algorithm against speech it may yield false positive matches against the various SIT frequencies. It is only by scanning in sequence that a valid SIT can be confirmed.
2. Cadence checks
   In certain territories (notably the UK and Europe), the busy and ring signals have the same frequency. They tend to sound different in the UK at least because the ring tone is modulated but the FFT algorithm will yield the same base frequency for both. This means that the only way to differentiate between both signals is to consider the time that the tone is played for.
   
   These patterns can be fairly complex:
   
   

   Signal Type	Pattern
   UK ring	.4s on, .2s off, .4s on, 2.0s off
   UK busy	1s on, .375s off, .375s on, .375s off
   EU ring	1s on, 4s off
   EU busy	.5s on, .5s off

   
   We would recommend building cadence checks into all tone signalling. This enables patterns to be catered for, and helps prevent glitches caused by nonstandard carrier audio announcements leading to false positives. It also helps to mitigate occasional packet loss for packet-switched voice.
3. Non-standard carrier announcements
   It has become a common practice for carriers in deregulated markets (notably North America) to play audio announcements for intercepts that don't include a SIT tone. Assuming that timers are implemented as suggested and the SIT detect strategies listed above are employed, these calls may be picked up by the no ring timer mechanism. However, in multiple network scenarios, the LEC may start playing ringback before he announcement switches in from the far end network.
   
   The way to trap this scenario, which is not uncommon, is to continue to monitor for ring once it has been established that the call is ringing. If the ring cycle is interrupted for a period of, say, 5 seconds without a connect being signalled, the call is going to be a non-standard carrier intercept announcement and should be classified as some form of intercept. Choice of intercept type is not easy. There is no reliable way to tell whether the failure is permanent without dialing the number manually and listening to the audio message.

The basic algorithm for answer machine detection is the same the world over; it relies on detecting patterns of presence or absence of speech. For basic information on this please refer to Sytel's paper entitled Demystifying Answer Machine Detection.

AMD is of limited commercial value in reality although the industry at large persists in using AMD. Suitable campaigns for AMD are those with low connect rates and a low transaction value (and where abusing the dialed parties will not damage your proposition!)

In order to optimise AMD for best possible results there are various strategies one should employ. These are:

1. Check ring time on answer
   If ring time is between 2 and 10 seconds classify the call as live. Note that in order to do this successfully you must have received an alerting signal either inband or out-of-band. Calls answering within this window are usually live.
2. Set realistic timeouts
   The AMD timeout should ideally be 3 seconds, and never longer than 3.3 seconds. A longer timeout will lead to more called party hangups and more unresponsive customers when they get on the phone.
3. Tune signal-to-noise ratio against cellphones
   When GSM media is converted to G.711 there is an increased level of noise in the audio stream. As part of your AMD algorithm you will have a noise threshold. If voice energy goes above this threshold then it is considered speech, below the threshold is silence. You should set this threshold based on sampled cellphone calls.
4. A grammar-based approach is best
   There are two basic patterns to pick up:
   1. A short greeting followed by silence indicates human voice
   2. A long greeting indicates answer machine
   There are other scenarios to consider. What happens if there is silence on the line for 3 seconds? What if the long greeting is interspersed with short periods of silence? If the periods of speech and silence for a call are expressed as a sequence and then compared to a grammar.

In a VoIP environment the carrier must deliver early media as the AMD algorithm relies on this for accurate detection.

This is another area of inexact science. Ideally you want to leave a message after the answer machine beep tone. However there is no such thing as a standard answer machine beep, or indeed there may not be a beep. This leaves you with 2 choices; either

1. you play a message that loops twice, in the hope that when the answer machine greeting is finished the called party will be able to make sense of it, or
2. you need to use silence detection to figure out when the answer machine greeting finishes

Silence detection for answer machine message laydown monitors the line to detect a period of continuous silence, then starts to play the message. The period of silence will need to be configured to best fit your locale. Too short and pauses in the message may trigger; too long and the answer machine may hang up in response to silence. In our experience something between 3 and 5 seconds works but this should be tested.

An overall timer governing how long the silence detection should run for is also required. Again only trial in your local area will allow you to set a sensible default. If you sample the major carrier standard voicemail messages for length this will give some indication as to how to set the silence detection timer.