Emergency call system operates with a large number of incoming calls, which can lead to overload and system failure. Custom call routing software allows server to configure routing and call processing rules, and edit the list of servers to which calls are routed and the list of servers that detect callers’ locations. This software reduces load and protects whole system against failures with the help of call routing system. Learn more about our expertise and services.
RedSky Technologies, Inc. develops and deploys distributed high-load software solutions for routing calls to public-safety answering points.
To create a proxy server that routes calls to public-safety answering points (PSAP). The server first accepts an incoming phone call, emulating one or more public-safety answering points. It then detects the location of the caller (using the main LIS or a backup one) and reroutes the call to the least busy public-safety answering point or to the one that is closest to the caller, depending on current routing rules.
According to NENA (National Emergency Number Association) standards, the proxy server is a part of the Emergency Services IP Network (ESInet) architecture.
One of the key tasks was to ensure that the server would be scalable and capable of routing any number of incoming SIP calls with little or no delay. To do this, the application was designed to be deployed in a fault-tolerant cluster environment based on Corosync and DRBD. The inbound load is balanced between active nodes of a JBoss cluster, which ensures that response times are low and the infrastructure is loaded evenly. DRBD replication of data partitions between cluster nodes ensures that the application settings and audit logs for all processed calls are safe.
The server was to provide the following functionality: configuring routing and call processing rules, and editing the list of servers to which calls are routed and the list of servers that detect callers’ locations. To achieve this, we developed a web-based console deployed on the same JBoss cluster where the main application was running. The console provides several access levels, depending on the user’s role. The access rights and user identity are determined using digital certificates installed into the browsers on the customer's side. The user interface is GWT-based.
As the project went on, the customer reconsidered several testing and production deployment schemes. As a result, the requirements for the operating system for the solution changed. Since we initially designed the system to be independent of both the physical infrastructure and the operating system, the transition from Debian to CentOS went smoothly and relatively fast.