Introduction

CTArchitect is a full-blown contact centre solution that:

• Manages all your inbound traffic
• Activates your outbound campaigns
• Ensures that you can monitor your quality and productivity

Thanks to its VoIP implementation, both on agent side and public network side, this system will bring your operational systems to a higher level of flexibility and manageability. From a technical point of view however, VoIP technology brings along new challenges. In order to help you with these technical challenges, we created this document. In what follows, we will focus on:

• The technical impact of a VoIP implementation on your network
• A couple of recommendations and guidelines for the setup of your environment, this on all levels: network layout, server infrastructure and agent equipment
• The quality controls we put in place to ensure that your VoIP telephony provider is acting in accordance with the standards needed in a professional environment

VoIP impact on infrastructure

Implementing a VoIP setup has an impact on several levels. A (non-exhaustive) list of topics that need to be considered when building a similar system can be found below.

First, the technology is subject to the constraints of the available bandwidth on the local (LAN) or wide area network (WAN). Every single VoIP call (agent-CTArchitect, supervisor-CTArchitect or CTArchitect-Phone network) requires a certain amount of bandwidth. The needed capacity mainly depends on 2 factors:

• Selected compression codec (G.711 or G.729)
• Voice activity detection (VAD)

Impact on required bandwidth is as follows:

Please bear in mind that the preferred codec choice might have an impact on voice quality. More compression could result in inferior voice/audio quality. This last remark is also valid if additional/external compression is applied to the voice flow.

Recommendations and guidelines

In order to reach the conditions mentioned above, with optimal voice quality as purpose, we would like to provide a couple of guidelines with regards to the different components implied:

1. General remarks
2. Network layout and implementation
3. Remote Connectivity
4. Server Specifications
5. Server Configuration
6. Client side recommendations

General remarks

A typical CTArchitect setup can be built in 2 ways, depending on the desired size of the platform:

• Stand Alone

If a basic system is required, CTArchitect’s core engine and Telephony node can be installed on one server.

• Multi Node

If more capacity is required, the Telephony system will be spread over multiple nodes.  

In case the number of calling agents is limited to 150 simultaneous working positions, CTArchitect’s core engine + Telephony Node software can be installed on a single server.

However, if the number of calling agents exceeds 150, a separate Telephony Node will need to be installed per 150 positions. In this case, setup will be as follows:

• A software module called “CTArchitect” will be installed on a separate server. This server will steer the separate Telephony Nodes.
• Per 150 agents, a separate server will be installed, performing as Telephony Node.

Network layout & implementation

Network and QoS

Simple file transfers are liable to saturate the network a networks bandwidth and cause trouble for VoIP traffic. To still allow reliable VoIP, it is advised to throttle non-VoIP traffic in favor of VoIP traffic. Depending on your router and switch configuration, it is possible to prioritise the VoIP traffic through VLAN QoS, DSCP values or even based on the IP+Port configuration. If your router has a built-in SIP/RTP QoS option, it is recommended to enable it.

Our software supports G.729 for compression but this comes at the cost of audio quality. And this also requires additional licenses.

For point-to-point connections with remote sites, header compression should be considered. Header compression is highly effective for VoIP traffic due to the small packet payload size.

When working with people working from home a VPN needs to be used.

Please note that most VPNs perform NAT by default, this needs to be disabled. The servers need to be able to open connections towards the agent PCs without obstruction of NAT or firewalls. The reverse is also true, Agent PCs need to be able to connect towards the servers without NAT modifying traffic or firewalls blocking the VoIP traffic. Please consult the Port Overview below for more details on the ports that are used.

Why is NAT such a problem?

Network Address Translation replaces IPs in the IP header. SIP however, and the SDP protocol, used to negotiate media ports also contain these source and destination IPs. Simply replacing the IPs in the Internet Layer will result in failure to establish or break SIP connections and in some cases one-way or no audio.

Some routers have SIP ALG built-in to deal with changing, not only the IP header but also the corresponding fields in the SIP/SDP traffic. These implementations are often of poor quality and do not solve the issues posed by SIP through NAT. Because there are so many bad implementation we do not support SIP ALG set-ups as a solution.

A second very important problem is that a NAT can behave like a firewall between the server and the agent PCs. If the client PCs are behind a NAT, the server is not able to initiate connections towards the agent PCs. This requires us to force the clients to always initiate the connection, which is not possible for all situations.

Lastly, NAT needs to keep track of all the ongoing sessions on the router. The capacity to do this is always limited and the experience when reaching that limit is best described as painful. No new connections can get established, yet the software gets no indication why that is the case, so it keeps trying until all VoIP resources are saturated and productivity plummets. These types of problems are also difficult to troubleshoot and, you risk getting stuck with a system that performs badly with no easy solutions.

Do not design your network with NAT between the VoIP server and the agent PCs.

Use the below infrastructure as a guideline for your network setup. See pages 12 and 13 for port info.

Please keep in mind that all SIP and RTP traffic should go via the same interface, as the SIP-stack does not support sip traffic on more than one interface. Therefore, our system cannot be used as SIP proxy.

All other network traffic can be split off if needed or wanted. It is possible to have a management-VLAN that allows RDP connections.

Finally, it is important to understand the flows between stations and servers to configure routing and firewalls. The below images show the different steps in the communication flow and which ports are being used. Please keep this in mind when securing your networks.

Basic Setup:

Advanced Setup:

Port Overview

A port overview is available in the below table and diagram. Use this info as a reference to configure your firewall settings.

Monitoring

It is strongly advised to have a network monitoring tool in place. Especially when you have leased lines or VPN tunnels or remote locations.

When voice quality issues arise, network capturing capabilities (e.g. WireShark) are essential to investigate the problems.

Recordings

The system provides multiple ways of recordings:

• Server-side recording
  • Mono
    • Requires one voice channel per call
    • More or less 0.5MB/minute speaking time
  • Stereo
    • Requires two voice channels per call
    • More or less 2.5MB/minute speaking time
• Whole survey recording
  • Requires one voice channel during recording
• Agent based stereo recording
  • Requires local pc resources and extra bandwidth between agent PC’s and servers to upload recordings at the end of the call
  • More or less 2MB/minute speaking time
  • This kind of recording is only meant for small pilot projects and/or for problem investigation
• Open question recording
  • Requires an additional voice channel during recording

Remote agent connectivity

When agents are working on a remote site it is essential to have a secure site-to-site VPN connection which assures bandwidth and QOS. The used technology can be IPsec, PPTP, L2TP or SSL.

Remote management connectivity

The Askia support team needs to have access to the different servers. This can be done using the RDP or VNC protocol. These servers should be accessible directly from an external IP address or using a VPN connection. We support VPN technologies from different providers like Microsoft, Cisco, Juniper, Citrix, …

Server Specifications

Overview

The number of required servers is directly dependant on the number of agents. See below the guidelines of server roles depending on the size of the platform.

The below numbers are only a guideline and can change depending on the actual available resources and used hardware.

Telephony Node (or CTArchitect) server

As described above, each CTArchitect platform will include one or more Telephony Nodes, depending on the number of agents. For systems smaller than 100 agent seats, the CTArchitect application will cover the functionality of the Telephony Node.

We strongly recommend using dedicated servers, solely to be used by the Telephony Node. If this recommendation is not followed, voice quality can be impacted by third-party applications running on the same server. Also pay attention with snapshots and its impact on performance.

Dedicated servers can be real physical servers, or Virtual Machines. When virtual machines are used for Telephony Nodes it is mandatory to use VMWare ESX or Hyper-V solutions because these are the only virtualisation software that are supported by Dialogic software.

For virtual telephony nodes it is also highly recommended to use dedicated CPU assignment. Dynamic assignment of CPU frequency introduces a high risk for performance impact when the system is under heavy use.

Also very important to know is that the NIC’s used for voice traffic on the Telephony Node Servers require a fixed MAC address because of licensing.

The Telephony Node application requires local administrator permissions. It is running as a graphical user interface and thus requires a windows user to be logged on at all times. An autologon is essential to guarantee a minimum downtime and allow automatic server boots.

Physical servers (if CTArchitect ran directly on it)

When it comes to technical specifications, we recommend a recent server with a minimum of 8GB ram any recent server class machine with redundant hardware

General Telephony Node (or CTArchitect) recommendations are as follows:

NOTE: Minimum requirements are only valid for small configurations.

As stated above, your equipment should perform equal or better than the recommended hardware. Special attention should go to low latency of all server components: even small delays can cause huge impact on VoIP quality because all data is handled in “real time”.

Also, it is important to prevent big kernel time jumps caused by network time synchronisation. Time adjustments under 1 second are handled fine but bigger corrections will lead to call and service interruptions.

Application server

Next to the CTArchitect/Telephony node(s), a separate application server needs to be installed, running our CCA (Contact Center Administrator) software. This application server can be a physical or virtual server.

The CCA can be installed either as an application or as a service.

Database server

Finally, a database server is needed, running a supported Microsoft SQL Server and having SQL Profiler installed. Depending on the size of the platform and the server’s technical specifications, it is also possible to install CCA and SQL on a single server. Please keep in mind that different editions and versions of Microsoft SQL Server provide different functionality and options. Also choose wisely your licensing. Set The transaction log to minimal, and backup model to full. A proper backup solution should be put in place to prevent data loss  

Operating system

Check the following website to verify if your OS is supported https://support.microsoft.com/en-us/lifecycle/search

For new installations we advise one of the recent operating systems.

Backup and redundancy servers

There are several ideas and strategies on reducing downtime in case of failure. One option is to install all servers on a virtual environment with a full mirror on a different physical location. This is however not always feasible. An alternative is to install a SQL mirror and foresee a backup server which can cover functionality on demand. If full agent capacity needs to be guaranteed as well, an additional Telephony Node is required to reach n+1.

Monitoring

It is strongly advised to have a server monitoring tool in place. Parameters like CPU usage, memory usage, free disk space, uptime, service availability and service response times should be checked on a regular basis.

Do not hesitate to contact Askia for further information.

Server configuration

Telephony Node, CTArchitect & application server

Physical server

BIOS and OS settings need to be optimized for high-performance / low-latency. For example, processor power saving states should be disabled. Also network and disk sleep states should be disabled.

Virtual server

When installing the servers on a virtualised environment it is essential to use dedicated CPU cores and RAM. Due to the real-time aspects of the solution (telephony & audio), the process of dynamically assigning resources is not compatible with our software setup. An exception can be made when it comes to HDD storage space: this can be assigned dynamically.

E1000 and E1000E virtual NICs are a known source for connection and stability problems on virtual machines. Please select VMX3 as the virtual network adaptor.

Third party software

Dialogic Powermedia HMP software will be installed on Telephony Node servers and CTArchitect server. More info about HMP software and how to configure the servers can be found here.

 Anti-virus Software Policy

Service Update 313 announces Dialogic’s general policy regarding third-party anti-virus software. Dialogic understands and acknowledges the desire for customers / end users to install anti-virus software in their environment and is providing this policy statement for guidance in this area. Loading and running any third-party anti-virus software on Dialogic® HMP-based servers, regardless of the operating system (Linux or Windows), may compromise the performance of a real time telephony system. Consequently, it is recommended that if such anti-virus software is required by the customer for security purposes, it should be configured to run during periods of minimal to no-call traffic (i.e., system inactivity) to minimize the risk of interference or disruption. If a problem requiring diagnosis occurs on a server running anti-virus software, and the antivirus software is suspected of causing or contributing to the problem, Dialogic Technical Support will likely ask the customer to remove or disable the anti-virus software before proceeding with further diagnosis. Dialogic does not validate any particular antivirus package nor does it endorse the use of a particular third-party anti-virus software vendor or product. Note: For 64-bit Windows 7, Windows Vista, and Windows Server 2008 operating systems using anti-virus programs, it is recommended that users exclude Dialogic subdirectories and also any application sub-directories from the system.

Database Server

Virtual server

When installing the servers on a virtualised environment it is essential to use dedicated CPU cores and RAM. Dynamic allocation of disk resources is supported.

Client side recommendations

First of all, when working with the integrated soft phone for agents or supervisors, both PC & headset specifications are crucial factors.

PC Specifications

PC should respect following minimum specifications (especially sufficient processing power & good network connection for voice handling):

Please note that even the most powerful PC can have a negative impact on voice quality if its resources are used by other applications at the same time. Therefore, a multi-core CPU is recommended as well.

Operating system

For a list of supported operating systems, we refer to http://windows.microsoft.com/en-us/windows/lifecycle.

Antivirus and Firewall

All 3rd party software installed on the client PCs should be configured to whitelist the CATI software and its connections.

Controversial but best is to use no antivirus as this guarantees the best performance firewall should always be enabled.

Headset

As far as headsets are concerned, we recommend professional USB headsets with (ultra-)noise cancellation and in-line volume and mute controls. The chosen headset needs to be compatible with the installed OS. Of course, we are always available to assist you in the choice of the correct headset (with advice or even with testing).

Internet/VoIP connectivity

Internet/VoIP connection performance needs to meet the requirements for VoIP. Pay special attention to round trip latency, packet loss, jitter and QoS. The bandwidth depends on the number of simultaneous calls and their compression methods.

Your sip provider can advise.

We recommend setting up a trusted connection with the network of your sip provider to ensure a proper routing of SIP and RTP traffic between the private IP address of our telephony node and the public IP address of the sip provider.

Best practice is to ask your sip provider to provide also a dedicated connectivity (private link). The sip provider sets up a private link between their core network and your server network to enable the sip provider to directly communicate with internal IP's of the telephony nodes.

And last but not least you could also use registration instead of IP-trusting/trunk with the disadvantage that acceptance of calls depends on it. If registration fails, calls will be blocked (this is not the preferred way but is not too bad).

SMTP

An SMTP server needs to be accessible to send out monitoring email notifications towards the support team. Following details are required: server, port, user, password, SSL.

The use of cloud-based machines

A setup where the agent connects to a cloud based VM can work, but a couple of things must be taken into account, please note that this setup is not officially supported.

Put the VMs, in the same physical environment as the CTA server, all connections (even VPN) are best effort and therefore a stable connection cannot be guaranteed. Only exception is if a dedicated link is intended to be used.

Make sure there is enough bandwidth. This is because the sound has to go through the same connection as the RDP data, the delay needs to be minimized as this is time sensitive.

Secondly on the VM, the windows sound subsystem must be installed and active, this consists of these two Windows services:

Also important is that the default audio device (this is set per user session) is set to remote audio. Do this for both playback and recording:

Furthermore, in the RDC connection properties, the ‘Play on this computer’ and ‘Record from this computer’ must be enabled.

Software version support

Our lifecycle management is based upon the following idea: https://en.wikipedia.org/wiki/Long-term_support.

This strategy has been used by other developers all over the world. For example, https://wiki.ubuntu.com/LTS.

Quality controls VoIP/SIP operator

General

SIP technology is an open protocol. As a result, many smaller providers have emerged in the market, with mixed quality and service as a result. This can make it difficult to choose a high-quality SIP provider.

Configuration

To configure the use of your preferred SIP provider we need some details like:

• Trunk IP address
• CLI(s) and CLI format
• DID format
• Which codecs are supported
• Optionally Inbound number and Inbound number format
• Confirmation about the usage of out-of-band signalling messages. The usage of in-band signalling messages, although still possible from a pure technical point of view, always require custom development time (extra cost) and are putting a burden on the overall performance of the system.

Validation

In order to assist CTArchitect users with the selection process and validation of a SIP provider, a procedure has been put in place to give you information about your preferred VoIP/SIP operator - even before installing it in a real production setup. The only thing needed is a test account, and after a battery of tests, a detailed report will be provided:

Items will be marked as:

• 'Approved'
• 'Not tested yet or test on-going' 
• 'Not approved, requires further modification'

Validation plan details

Test scenario

This scenario describes a setup where CTArchitect and soft phones are in a private network.

Trunk

IP trusting or SIP Registration

Purpose:  Validate digest authentication algorithm (specified by RFC 3261)

Test description:

• Make a test call based on IP Trusting

OR

• Connect to the SIP provider with the provided credentials.

Result: not tested yet

Basic Call

Call using G711a or G711u(KO)

Purpose: Test of capability to handle G711 RTP - Streams

Test description:

• Soft phone is configured with G711 exclusive coder preference.
• Soft phone calls an external phone

Result: not tested yet

Call using g729 (optional)

Purpose: Test of capability to handle G729 RTP - Streams

Test description:

• Soft phone is configured with G729 exclusive coder preference.
• Soft phone calls an external phone

Result: not tested yet

CLI can be blocked/altered (optional)

Purpose: Test if provider accepts anonymous calls

Test description:

• Soft phone is configured to not send his CGPN. 'User Setup'->'Number Presentation' = Off
• Soft phone calls an external phone. The display of the  phone should show as Calling Party: 'anonymous'

Result: not tested yet

Long time call possible (KO)

Purpose: Test if provider interrupts call after session timer expires (RFC 4028). It is possible that the provider awaits Re-Invite after the timer expires.

Test description:

• Soft phone calls an external phone
• Call is longer than session expire timeout.(usually 1800 seconds)

Result: not tested yet

Voice Quality OK? (KO)

Purpose: Simple test of overall voice quality during a call.

Test description:

• Soft phone calls soft phone. Soft phone picks up the call.
• Manual test of voice quality by speaking/listening on both ends.

Result: not tested yet

International call set-up (optional)

Purpose: Test of capability to handle the set-up of an international call

Test description:

• Soft phone dials an international number.
• Soft phone calls an external phone

Result: not tested yet

Outbound call disconnection

Delay in receipt of disconnection causes (KO)

Purpose: validate that disconnect causes (800) are received within an acceptable delay

Test description:

• Soft phone is configured to call a wrong and/or busy number
• Disconnect are received by CTArchitect

Result: not tested yet

Reception of busy disconnect cause (KO)

Purpose: validate that disconnect cause (17) busy is provided in a correct way

Test description:

• Soft phone is configured to call a busy number
• Disconnect are received by CTArchitect

Result: not tested yet

Reception of disconnect cause wrong number (complete number provided to SIP-operator) (KO)

Purpose: validate that disconnect cause wrong number is provided in a correct way if the complete number is provided to the SIP operator

Test description:

• Soft phone is configured to call a wrong number with a correct number format
• Disconnect are received by CTArchitect

Result: not tested yet

Reception of disconnect cause wrong number (incomplete number provided to SIP-operator) (KO)

Purpose: validate that disconnect cause wrong number is provided in a correct way if the incomplete number is provided to the SIP operator

Test description:

• Soft phone is configured to call a wrong number with an incorrect number format (e.g. not enough digits)
• Disconnect are received by CTArchitect

Result: not tested yet

Reception of disconnect cause wrong number (too large number provided to SIP-operator) (KO)

Purpose: validate that disconnect cause wrong number is provided in a correct way if the incomplete number is provided to the SIP operator

Test description:

• Soft phone is configured to call a wrong number with an incorrect number format (e.g. not enough digits)
• Disconnect are received by CTArchitect

Result: not tested yet

DTMF

DTMF tones sent correctly (KO)

Purpose: Test if DTMF signals going from CTArchitect to Provider are received and interpreted correctly.

Test description:

• Soft phone calls external phone.
• Check if the DTMF - tones are received at the external phone

Result: not tested yet

DTMF tones received correctly (KO)

Purpose: Test if DTMF signals going from Provider to CTArchitect are received and interpreted correctly.

Test description:

• External phone calls soft Phone.
• Check if the DTMF - tones are received at soft phone

Result: not tested yet