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 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.

Groups

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 2^nd string.  If the 2^nd 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 2^nd on the 2^nd, 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]
}

 

Routes

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: [
415,510
],
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: [
{
Name:losangeles,
Match: [
213,310,323,424,
562,626,657,714,
747,818
],
Callpath:  spread_out_calls
},
{
Name: sfbayarea,
Match: [
408,415,510,650,669,650,925
],
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.

EX:

~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.

EX:

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

 

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.