OneContact solution enables organizations to differentiate themselves with the level of service they provide to customers. OneContact is an IP-based, truly multimedia solution, meeting the need for a contact center that integrates next generation communications.
In addition, One Contact’s SIP-based architecture within the contact center can leverage the existing corporate IP network: The use of a single network to manage various corporate solutions reduces equipment and maintenance costs by removing the need to maintain multiple networks. The result is a cost-efficient, future-proof solution that will grow with customers’ requirements. This means increasing operational efficiency and making the best use of existing resources, including the ability to integrate multiple sites into a single contact center that delivers consistently high-quality customer service across all the channels customers want to use. It also can mean extending the focus on providing a superior customer experience with a contact center and with “back-office” touch points with customers, such as loan processing among other scenarios.
OneContact is 100% software solution that runs in regular “wintel” servers and can be deployed from a single server up to a fully redundant architecture with no single point of failure. OneContact solutions can range from a few agents up to thousands of agents in a single system or in a single tenant in a system.
OneContact can also be deployed with geographical redundancy over a multi-site environment in hot stand by or active-active configurations as pretended.
A typical solution with OneContact is composed by the following parts:
- IP Communication infra-structure: Integration with PSTN (voice and sms), existing PBXs, remote agents over IP, Instant Messaging and e-mail interactions;
- Server side OneContact infra-structure: (architectures ranging from single server to fully redundant solutions)
- Client-side infra-structure: Applications and requirements for agents and supervisors
- 3rd party integration: Integration with existing applications and infra-structure like CRMs, business applications, Mail server, SMS gateway, etc.
The following picture has a high level overview of a contact center:
IP communication infra-structure
The solution relies on the existing switching infra-structure as well as data center rack space, interrupt power supply and adequate acclimatization.
OneContact can connect with any SIP Gateway or Telco operator’s VoIP link using a SIP trunk to handle voice and video calls. No PBXs are needed in OneContact solutions. Integration with chat client and an email server is also possible to handle chat and email sessions. Additional hardware for such scenarios is not included on this architecture.
Please refer to requirements section to see further information about certified SIP gateways.
Agents can work locally or remotely as long as they stay connected to the OneContact VLAN through an IPSec tunnel or NAT scenarios by Internet. In any case, IP connectivity and QoS must be assured on the link between the Agents VLAN and OneContact VLAN.
OneContact can integrate with the following infra-structures:
- Telco SIP Trunk: Some telecom operators already deliver voice traffic directly in SIP; this is a cost effective solution since it does not require the companies to have and maintain specific media gateways to convert PSTN traffic into VoIP.
- Media Gateways: If the telecom operation does not deliver voice traffic directly in SIP, gateways are needed to convert any technology (ISDN, Skype, 3G Networks, etc.) into SIP (Session Initiation Protocol). OneContact also integrates with PBX that can handle SIP trunks.
Server-side OneContact infra-structure
For small contact center solutions, OneContact can be installed in one single “wintel” server. The basic software requirements to run are the operation system and MS SQL Server 2012/2014 as database engine.
Additionally, OneContact can be deployed in a redundant infra-structure. In this case, the minimum requirement for the solution is a Microsoft Cluster with at least 2 servers supported by a SAN (Storage Area Network).
Most often the implementation of an active directory domain services only requires the presence of a single server. However, when deploying a redundant clustering OneContact solution, having a single AD server can compromise the business continuity in case of a primary AD DS server failure. Therefore, for redundant solutions, Collab strongly recommends the presence of a secondary AD DS server.
In high scale solutions OneContact uses standard load balancing to achieve horizontal high scalability.
The redundant mechanisms used by OneContact are the following:
- Level 1: Hardware redundancy: The entry level for a redundant system is to redundant components within a server or appliance. In this scenario the most frequent redundant components are: multiple hot swap disks; power supplies; and redundant fans.
- Level 2: System redundancy
- Through MS Clustering: OneContact uses MS Clustering to make databases and statefull components redundant. In case of a server failure, the applications switch to other nodes without disrupting services;
- Through load balancing: OneContact uses simple load balancing mechanisms to balance and redundancy on stateless components, which includes the majority of the OneContact components (including media servers). HTTP and SIP requests are load balanced to load balanced servers/components;
- Level 3: Geographical redundancy: In this scenario OneContact is deployed in a multi-site environment and in case of failure of an entire site, the backup site will failover and accommodates all the traffic and components that were previously running on the faulty site.
Failover clusters provide support for mission-critical applications—such as databases, messaging systems, file and print services, and virtualized workloads—that require high availability, scalability, and reliability.
A failover cluster is a group of independent computers or nodes that are physically connected by a local-area network (LAN) or a wide-area network (WAN) and that are programmatically connected by cluster software. The group of nodes is managed as a single system and shares a common namespace. The group usually includes multiple network connections and data storage connected to the nodes via storage area networks (SANs). The failover cluster operates by moving resources between nodes to provide service if system components fail.
Normally, if a server that is running a particular application crashes, the application will be unavailable until the server is fixed. Failover clustering addresses this situation by detecting hardware or software faults and immediately restarting the application on another node without requiring administrative intervention—a process known as failover. Users can continue to access the service and may be completely unaware that it is now being provided from a different server.
OneContact’s stateless components can be configured in a load balancing environment. A Farm pool is a set of N machines, in a load-balancing environment that replies to requests without maintaining memory state. To accomplish this, all the relevant state information is kept in system databases. In case of a machine or application failure, the load balancer routes requests to one of the remaining N-1 machines. To deploy such an infrastructure, a load-balancer is required. The load balancer component in question can be either a switch or a dedicated machine.
The following OneContact components support load balancing:
- Web Applications (OneContact Host, OneAdmin, OneSupervisor).
- SIP Components (OneProxy, OnePark and OneMedia).
- OneContact Service.
- OneContact Scripting Service.
- OneContact Importer Service.
In terms of component distribution, there are farms for components that work directly with SIP (OneProxy, OnePark, OneMedia), and farms for web servers, which communicate over HTTP (OneContact web applications). For SIP-enabled components, the load-balancer should be SIP-aware, i.e., as soon as one of the N machines responds to an INVITE request, all SIP messages referring to this SIP transaction must be routed to that same machine. This means that the load balancer should be able to examine incoming SIP messages, notably the “via” header. OneContact web applications (OneSupervisor and OneAdmin) require “session affinity” for HTTP requests state keeping.
OneContact web applications (OneSupervisor and OneAdmin) require "no-affinity" for HTTP request state keeping. This setting distributes client requests more evenly. When maintaining session state is not an issue, you can use this setting to speed up response time to requests. For example, because multiple requests from a particular client can go to more than one cluster host, clients that access Web pages can get different parts of a page or different pages from different hosts. This setting is used for most applications. With this setting, the load balancer's statistical mapping algorithm uses both the port number and the entire IP address of the client to influence the distribution of client requests.
Client site infra-structure
OneContact agents use the OneAgent application on their PCs to answer the contact center interactions. OneAgent has a built-in SIP soft phone, allowing the application to act as a SIP endpoint for different media (audio, video, instant messaging…), enabling the agent to answer all interaction in the same application interface.
In OneContact solution, agents typically will not use physical phones. Nevertheless, it’s possible to use SIP physical telephones (compliant with SIP2.0 RFC3261, SDP RFC2327) registered in OneContact with a dedicated line to the contact center. In this case all call control operations will be done in the OneAgent interface except the answering action that must be done in the SIP telephone.
Agents don’t require more than a PC, an USB headset and an IP connection to OneContact to operate.