How to setup CATI Interviewers & Supervisors to work remotely
This is a big topic which will vary depending on your own specific network architecture, but the complexity will depend mainly if you have telephony integration (CTArchitect) or not.
The explanations available in this article will give you details focused on the Askia applications communications only. If your CATI questionnaires embed direct SQL queries, please keep this in mind when evaluating the permissions of the [VPN] used by the remote users.
To run the CATI or SUPERVISOR applications, they can use the Click&Go version available from your CCAPortal link to share with them or by installing the applications on their computers like following.
Please find below the link to the download centre.
https://installers.askia.com/helpdesk/askiafield/
The remote users will be able to download the CATI or SUPERVISOR setup corresponding to your CCA version. If required, they can follow the article below which describes step by step the setups.
https://support.askia.com/hc/en-us/articles/200039372-Install-askiafield-Workstation-
The only information that you will have to provide them is the CCA server address (local or public depending on the connection through [VPN] or not that they will use).
The remote users that will be connected to the VOIP system will have to take care of their devices setup in case of voice communication troubles (change for another headset, swap from WIFI to LAN, reboot their Internet box,...).
As neither their material nor their Internet connection can be checked, we won’t be able to take care of any voice communication failure happening to remote users.
Without telephony integration (no CTArchitect)
- Ports management
The CATI & SUPERVISOR applications communicate with the CCA server through the following ports.
- CATI : TCP (901, 1901, 923, 1923, 1991, 15500) & UDP (1918)
- SUPERVISOR : TCP (903, 1903, 922, 1922, 1991, 15900) & UDP (1918)
The connection flow starts from the client application towards CCA. More details on the following article.
https://support.askia.com/hc/en-us/articles/200003221-Install-askiafield-CCA-Server-#chapter1
- Remote connection through VPN
This is the most possible secure solution as you authenticate the remote users allowed to connect to your network and all the traffic between these 2 points is encrypted.
- Remote connection without VPN
This is possible by allowing your CCA server to be reachable from the Internet.
The ports mentioned above should be accessible then through a [PUBLIC IP] address or a [DOMAIN] name.
If the CCA server is not located into a [DMZ], you could set up [NAT] rules from your router to redirect the incoming connections on the above ports toward the CCA server.
Even if possible and easy to set up, this is not a solution that we recommend without the server being located into a [DMZ] as this can create a breach in the network security level.
With telephony integration (CTArchitect)
- Port management
The CATI & SUPERVISOR applications communicate with the CCA server through the following ports.
- CATI : TCP (901, 1901, 923, 1923, 1991, 15500) & UDP (1918)
- SUPERVISOR : TCP (903, 1903, 922, 1922, 1991, 15900) & UDP (1918)
Both of these application will communicate with the CTARCHITECT server and the telephony nodes through the following ones.
- UDP (5060) & UDP (49152 to XXX) > XXX = 49152 + (max simultaneous calls * 2)
The connection flow starts from the client application toward the CCA and the telephony servers. More details on the following article.
https://support.askia.com/hc/en-us/articles/200003221-Install-askiafield-CCA-Server-#chapter1
The telephony system can be used with the remote agents & supervisors in 2 ways:
- Keeping the VOIP management as from your fieldwork
To allow this, a [VPN] connection will be mandatory because of the amount of dynamic ports required.
The remote users will then use a computer with a compatible headset connected and all the data and voice traffic will remain on the network side.
The main difference between internal and remote CATI/SUPERVISOR concerns the first connection flow. The local computers being on the same network than the CTArchitect, these ones are easily reachable by the CTArchitect while it's not the case for the users connecting remotely as going through a router. For them, the connection flow has to be inverted to force the VOIP connection to be initialized from the CATI/SUPERVISOR to the CTArchitect.
To do so, you need to activate the option “Cati dials CTArchitect” or “Supervisor dials CTArchitect” on the locations that will be used by the remote users (GlobalCca > Locations overview).
- Using the remote users phone devices
Here, the CATI and SUPERVISOR applications will only manage the survey data and no longer the voice communication data, as the aim will be to have the CTArchitect calling both parties (remote user & the respondent) and merge them into a conference call on its side.
Before enabling this feature, please take into account that for each conversation, 2 live calls will go toward the SIP provider (1 call agent + 1 call respondent). The consumption of SIP calls will be doubled then.
To enable this, you need to configure the remote users personal phone numbers on each locations that will be individually dedicated to each of the remote users (GlobalCca > Locations overview).
You can have an look below on a few obstacles that could prevent optimum performance.
Connection Initiation
The initial communication to open the VoIP connection happens in the following directions.
Default Behaviour |
CATI Dials CTArchitect | |
Manual Call | CATI ==> CTArchitect | CATI ==> CTArchitect |
Progressive Dialing | CATI <== CTArchitect | CATI ==> CTArchitect |
Predictive Dialing | CATI <== CTArchitect | CATI ==> CTArchitect |
Inbound Call | CATI <== CTArchitect | CATI <== CTArchitect |
This is important to know because several network devices will block initial connections in one direction but not the other.
It is necessary to allow connections to be initiated in both directions if you want to use all CTArchitect features and maximize your system performance. The CATI Dials CTArchitect can be a live saver in some scenario's but as the above table shows it does not allow inbound.
Typical Network Obstacles
There are some network devices with potential configurations that tend to prevent connections initiated from the CTArchitect towards the CATI-client.
All of these usually allow a connection to persist once a connection has been made, but will block the initial request from one of both sides.
Network Address Translation (NAT)
When NAT is present in the network between the CTArchitect and the CATI agents, it needs to be removed.
Firewall
When a firewall is the cause of the problem it needs to be configured to allow SIP traffic between the server and the softphones. Allow UDP port 5060 to fix this issue.
VPN
Typically most VPNs will allow connections from the computer towards the company network but will block connections that are initiated from the company network towards the agent computer.