Survox Dialer Features

VOIP Dialing

Session Initiation Protocol (SIP) Client

The Survox Dialer is a soft dialer solution that does not require traditional telephony components. It can connect to any new or existing SIP based PBX system allowing interviewers the ability to interview from home or in a call center. It is compatible with any SIP client so there is no need to use hard-wired phones. Being based off of an Open Source platform, the Survox Dialer, used in conjuntion with Survox’s Survent platform, the first commercially available computer assisted telephone interviewing software, enables data collection and call centers of all sizes to efficiently collect data anywhere around the world.

Survox has tested using Zoiper and Zoiper Biz soft phone however, there are no known issues with other brands or versions.

Predictive Dialing

Predictive dialing is an outbound call process which calls numbers based on how many interviewers are available. As such, it assumes an interviewer will be available when a connect is achieved. This allows the system to handle busies and no answers without the interviewer specifically waiting for each call and is highly efficient in that regard, but may result in occasional calls being “abandoned”, that is, the call is connected with no interviewer available. The Survox Dialer allows you to control how fast the dialer dials (how long the interviewers wait for a call) versus what the abandonment rate is. The system also “learns” how many calls to make as a study progresses based on the length of interviews and connect rate.

Targeted Dialing

Targeted dialing is an outbound call process in which each phone number is sent to a particular interviewer station (Survent session) before it is dialed. This allows you to take full advantage of Survent’s logic functions to determine whether or not to dial the number.  There are two modes to target dialing:  Power and Preview.

  • Power

In power mode the dialing of the number is controlled by the individual Survent process and the interviewer waits while the number is dialed. The interviewer may or may not hear the actual call progress as it depends on the brand of the dialer being used.  Once a call result is returned from the dialer, the interview can commence if it is a connect, otherwise the Survent process can look at the call result and decide what to do next.  Typically if the call is returned as a non-connect such as busy or no answer, it will immediately try to dial another number. This is dialing at a 1 to 1 ratio, 1 number per waiting interviewer.

  • Preview

In preview mode the interviewer is in full control of the call and hears the entire call progress including any ringing, busy, tri-tones or other audio information passed from the carrier.  The interviewer must initiate the dial by coming to a point in the questionnaire that send the number to be dialed.  The interviewer is required to status all calls in this mode.

This if further extended with features that now allow sample to be marked for Targeted dialing so that non-marked sample may be dialed predictively and marked sample will be dialed in targeted mode in the same study dynamically.

We have defined four different possibilities for the Targeted Numbers.  Optionally, you may also MASK the phone number, so the interviewer never sees the respondent number.  This may be a default approach or used for studies working to meet various privacy and security compliances.

The four options are:

  • NONE = No interviewer interaction, number is automatically dialed.
  • CLICK (default) = Interviewer has single click to dial.
  • KEYPAD = Dial on physical phone (phone number masking is not allowed with this option) using the new HandDial function.
  • KEYBOARD = Dial on computer keyboard.

If Masking is enabled, the interviewer will get a random number that must entered correctly to continue and they never see the actual phone number.

One way to think about these options is in order from most automated to least:

  1. Predictive
  2. Power Targeted
  3. Targeted 1-Click
  4. Targeted Keyboard
  5. Targeted KeyPad HandDial
  6. Manual


If an interviewer is using a dialer and the phone line is disconnected for any reason, the interviewer can cause the dialer to redial the number by using the REDIAL command. This sends a message to the dialer to redial the current phone number at that extension. No history of this action is kept, other than the redial command is logged in the Server log files. Currently this is only supported on the Survox and SER dialers.

Caller ID Number

You can put a caller ID Number on a shop-wide basis, a study basis, or a different caller ID Number on each record. The number to display is at the discretion of the Survox user. Caller ID Name is based on the information provided to your telecommunications provider when you acquired the number, and is at the discretion of the LEC if it will be displayed.

Answering Machine Detection

The  Survox Dialer can optionally filter out answering machines with answering machine detection. This spares the interviewer from having to wait for the phone to be answered each time and find that they received an answering machine. When an answering machine is detected you can either immediately hang up the call or play a recorded message. You can control the parameters that determine which calls are answering machines.  AMD is an art not a science and Survox support can work with you to find the right settings for your specific needs.

Call Transfer

Interviewers can transfer calls to a third party using the Survox Dialer. You can put the respondent on hold, do a “warm” transfer (with all parties on the line) or “cold” transfer (respondent goes on hold and connects with the transferred to party).

Conference Calls

Interviewers can set up and control conference calls. They can include as many users as they want in the call. They can set up a call then remove themselves from the call and continue interviewing.

IVR Functionality

The Survox Dialer can play a recorded question and allow the response to come from the phone keypad.

Real-Time Supervisor Control of Dialer functions

You can change the number of rings for a no answer, whether to use whole recording of  interviews and the abandonment rate directly from the supervisor in real-time while the dialer is operating.

Audio Monitoring

The Survox Dialer allows audio monitoring of an interviewer by supervisors, other on-site personnel, or remote clients.  Voice monitoring will hear the agent at all points they are connected including during call transfers.

Simultaneous Full and Partial Audio Recording

The Survox Dialer provides two simultaneous recording modes. You can record the whole interview to a file and simultaneously record the responses to particular questions to other files. You have complete programmatic control of which questions get recorded. File names are automatically generated including study name, interviewer ID, time, and question recorded, or you can use your own names. Recordings can be automatically emailed to clients, for instance, to report on responses to key questions.

Sound Playback

You can play any pre-recorded audio at anytime during the survey. For instance, you can rotate a set of songs to get respondent opinions. Radio commercials, music clips, commercials and previously recorded open ends are just a few of the sound clips that you can play back.

Play back files are stored in wav format.  You can upload wav or mp3 files to use on the dialer using the Survox Dialer Console.

Another use for this is for transcription or translation of recorded snippets. The interviewer can use the phone keypad to control the playback going forward or back, rewinding or stopping the playback.

Files can also be automatically played back as part of the “View” utility as you go back through a completed interview.

Real-time Dialer Dashboard

The dashboard lets a supervisor see and monitor the activity on the system across all loaded studies, projects or campaigns including connection rate, current status, etc.

Hand-Dialing Option8_8_3+


Hand Dialing is a feature that enables a number to be dialed by a human being pushing the keys on a physical telephone set as opposed to entering them on the computer keyboard. Using this option, the interviewer is presented with a telephone number on the computer screen and instructed to dial the number on a separate, physical phone. After dialing the number, the interviewer will hear the target phone ringing and then will be given total control of the call, whether it is answered or not.  Note, the phone number is still dialed through the Survox dialer so that sound recordings are still done along with audio monitoring.

Implementing this in Survent is very straightforward.  When doing targeted dialing, not “predictive dialing” the interviewer is always presented with a phone number to consider.  The number can be dialed or it can be returned to the phone number database for later use.

If the number is to be dialed now, it can be dialed by the computer by using a “PHONE, DIALNUMBER” statement that will tell the computer to dial the phone and connect the call immediately to the interviewer’s phone set.

If the user wishes to have the interviewer physically dial the number, instead of using “PHONE, DIALNUMBER” use “PHONE, HANDDIAL”.  In this case, the number is presented on the screen and no further action is taken by the computer until the interviewer pushes the keys on the phone to dial the number displayed.

If the number dialed by the interviewer does not match the number displayed on the screen, no dialing will be done and a status code of “891” will be returned so the interviewer can be given another chance.

The sequence of operations is:

  1. Obtain the next phone number from the phone number database with a statement “PHONE, GETNUMBER”.
  2. Ask the interviewer if this number is to be dialed.
  3. If not, go back to step 1.
  4. If it is to be dialed, do “PHONE, HANDDIAL.” There are no options on this statement.
  5. The interviewer will hear a prompt and will then dial the number displayed on the screen.
  6. If the number does not match, then a flag will be returned so the interviewer can be given another chance to dial the number correctly. Go back to step 4.
  7. The interviewer hears the phone ringing, or a busy signal, or a SIT tone and responds accordingly.

The prompt mentioned is the file “cfmc/handdial.wav,” which is located in the sound files directory on the Asterisk machine, in the sub-directory ‘cfmc’.

Call Routing/Call Pathing

Call routing is used to control which trunk will be used when the call is placed.  There are 2 main use cases:

  • Call distribution where calls are placed on multiple trunks in a way that spreads the load across them to try to avoid overloading any particularly one.
  • Least Cost Routing where calls are placed on the trunk that will have the lowest cost for that call. This is usually done by area code or country code.

To use call routing there must have a call_routing file stored in the control sub-directory.   If file does not exist then calls will be placed on the trunks according to the settings in the cdiparms file in callout numeric order using the strategy overflow.  Once call routing is set up it can be invoked either at the study level or at the record level.   To invoke it at the study level use the keyword “call_path=” in the <studyname>.dial file.  The call_path can point at either a specific callout string, a group or a route.   Groups and Routes are defined in call_routing file.  If the call_path is set in the shopwide.dial then that will be the default for any study that does not have a specific call_path set in their <studyname>.dial file.  If the callout, group, or route does not exist, then the study will not load.

You can also control the call path at the record level.  When the sample file is built you can use the keyword call_path_location= to define where in the record the callout string number, the group, or the route is defined.  If a record is blank in that field, then it will use whatever the study is set to use.  If the record has “bad” data in the field, then it will not be dialed and be put immediately into the Error stack with a status of 995.

Call Routing File

There are two different types of elements that are defined in the call_routing file:

  • Groups: A group defines a set of callout strings and how they will be used.
  • Routes: A route maps a list of strings that a phone number can be matched to with to a group or directly to a callout string.  Typical strings would be area codes or country codes.

You can have up to 9 callout strings which are still defined in the cdiparms file.  If there are errors in the syntax of the call_routing file, then the dialer (CDI) will not start.

The call_routing file can be built either through command line syntax or via the Survox Dialer Console. To access the file via the Survox Console you need to first go to the Status Configuration Menu and then the Call Routing Configuration under it. Once on that page you can create and/or edit groups and routes.

If you are going to create or edit the file through the CLI then you need to understand the syntax that is used which is based on JSON.   JSON is designed to be easy for humans and machines to read and write.  It is based on a couple of simple structures.   The following is from the JSON.ORG website.  You can go there to get more information on what the rules for JSON are.

JSON is built on two structures:

  • A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
  • An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangeable with programming languages also be based on these structures.


A group element consists of the name of the group and 3 name/value pairs.

  • The “type” group
  • The “strategy” which can be overflow (old default) or round_robin.
  • The “callouts” which are a list of the callout strings defined in the cdiparms file.

If you use the strategy overflow, then the dialer will use the first callout string until it hits its maximum set on the callout string and then “overflow” to the 2nd string.  If the 2nd string would hit its defined maximum, it would roll to the third and so on.  If you use the strategy round robin, then each new call rotates to the next callout string on the list.  The first call goes out on the first string, the 2nd on the 2nd, and so on until the last callout on the list is used and it then goes back to the first call out string again.  If a given callout hits its maximum it won’t be used until another one of those lines becomes available.

The simplest group to define has a single callout, although there is no reason to do this other than to give that callout a name.


Single_callout= {
Type: group,
Strategy: overflow,
Callouts: [1]

A much more useful example is if you have 2 or more trunks defines on a dialer and you want to distribute the load between the two trunks in such a way as to minimize the usage on both trunks as much as possible.  The example below would rotate calls between trunks 1 and 2.  Note, this does not do call balancing between the trunks as it does not look at each call to see which trunk is less busy, but in most cases it should be very close.

Spread_out_calls= {
Type: group,
Strategy: round_robin,
Callouts: [1,2]



A route element can be much more complex.  It has a mappings section which allows individual phone numbers or groups of phone numbers to be sent out a specific callout string.  Examples of this are Least Cost Routing (LCR) or other “area” based calling rules.

A route element consists of the name of the route and following sub-pieces.

  • The “type” route
  • A “mapping” section which contains
    1. The “name” pair for each set of matched items
    2. The “match” section which lists all of the matching criteria
    3. The “callpath” which defines which callout string or group that will be used for the matched items

A simple although not necessarily realistic example to understand would be suppose you had 2 area codes 415,510 that you wanted to go out through one trunk/carrier and all other calls to go out through a separate carrier.   Note the name “default” is a special keyword which causes all numbers not matched in a earlier match item to match the default setting and it should be the last thing in the route.

Splitoff_415_510 = {
Type: route,
Mappings: [
Name: SFbayarea,
Match: [
Callpath: 1
Name: default,
Callpath: 2

A slightly more complex example would be that you are calling California and you have 4 different trunks/carriers that you want to use.   If the call is going into the Los Angeles area you want to rotate between trunks 1 and 2.  Calls into the SF Bay Area will use trunk 3 and all other calls in California would use trunk 4.  Note the callpath for the losangeles match is the group “spread_out_calls”.   You can use a previously defined group as the callpath for a match group.

California= {
Type: route,
Mappings: [
Match: [
Callpath:  spread_out_calls
Name: sfbayarea,
Match: [
Callpath: 3
Name: default,
Callpath: 4

To create a real Least Cost Routing setup you would likely have many more items in the list for a match group, but the logic is the same.    If you have a particularly large set of groupings, you can contact Support and we might be able to help you set it up.  One good thing about using JSON compatible coding is that it is often easy to take in other forms (from Excel or other data bases) and run them through a simple script to get the desired output.

One additional note about the syntax that can be in the match strings.  You can use a string of X’s (xxx) in the middle or at the end of the string to denote a specific number of characters that are needed.  The most common use of this would be if you were dialing both US and International numbers and you wanted to make sure the US numbers of length 10 were affected by the rules, but not numbers of other lengths.  For example, you would do the following if you wanted to make sure that only 10 digit numbers were matched:  415xxxxxxx


Testing the call routing in Mentor

In Mentor you can test to not only make sure the syntax of your call routing is correct, but also verify that the correct callout is being used.  The ~test_route command is used to do this.  It takes two sets of options.  The first is the list of the valid callout strings you have defined in the cdiparms file each separated by a comma and the second option is either the location of where you want the test to find the group or route for each record or the keyword NOLOC if you just want to test the syntax of the file.


~test_route 1,2,3 NOLOC

Would say that callout strings 1, 2, and 3 are valid callouts and only the syntax will be checked.  You could then copy and/or ampersand in your entire call_routing file and it will verify that the syntax is correct.   The keyword “start_phone_numbers” then tells Mentor that you are going to start delivering it sample phone records to see how they are assigned.  For each phone number that is tested, 4 values will be displayed.

  • The route that would be used otherwise the keyword NONE is printed
  • The name of the mapping that would be used inside the route otherwise keyword NONE is printed
  • The name of the group that would be used otherwise keyword NONE is printed.
  • The callout or list of callouts that would be used otherwise the keyword NONE is printed.

The example below will now only test the syntax in the call_routing file, but there are several test numbers that are sent to see how they will be handled.


~test_route 1,2,3,4,5  14.20
4157770001   spread_out_calls
4157770002   spread_out_calls
4157770004   baddata
4157770005   spread_out_calls
4157770006   california
2137770007   california
8187770008   california
9167770009   california
4157770010   5


Here is the information that is put into the list file to help diagnose how the numbers will be called.

callout(4157770001) NONE/NONE/Spread_out_calls/[1,2-round_robin]
callout(4157770002) NONE/NONE/Spread_out_calls/[1,2-round_robin]
callout(4157770003) = NONE/NONE/NONE/NONE
ERROR: For (4157770004) user Data 'baddata' does not resolve to group or route
callout(4157770005) NONE/NONE/Spread_out_calls/[1,2-round_robin]
callout(4157770006) = California/sfbayarea/NONE/3
callout(2137770007) California/losangeles/Spread_out_calls/[1,2-round_robin]
callout(8187770008) California/losangeles/Spread_out_calls/[1,2-round_robin]
callout(9167770009) = California/default/NONE/4
callout(4157770010) = NONE/NONE/NONE/5

Rrecords 1,2, and 5 there was no route, the group used was “spread_out_calls” and callouts 1 and 2 will be used in a round_robin strategy.
Record 3 had no data, so no information is returned.  It will be called using the first available callout in the cdiparms file.
Record 4 had invalid data, so an Error was returned
Record 6 is the California route, area code 415 is in the sfbayarea mapping, there is no group, and callout 3 was used
Records 7 and 8 are using the California route, area codes 213 and 818 are both in the losangeles mapping, the group is spread_out_calls, and then callouts 1 and 2 will be used in a round_robin strategy.
Record 9 is using the California route, but area code 916 has no mapping, so it gets the default mapping, it has no group, and callout 4 will be used.
Record 10 is directly set to callout5 so all the route and group settings are empty.