With your purchase of the Evolve ® Application Server, you are now ready to integrate the Application Server into your lab and production networks and deploy network applications. This section of the guide provides information about the overall server architecture and the rest of the sections discuss specifics of configuring and managing the Application Server.
Note
A basic knowledge of XML is required to make changes to the configuration files.
The Application Server fully implements the protocols required in the IP network. New service offerings can be quickly and reliably delivered across a wide variety of networks including IP Multimedia System (IMS), converged TDM/IP, and VoIP networks. The open architecture and use of next-generation network (NGN) standards - including SIP, IMS, VoiceXML, MGCP, and XML - provide a multi-service deployment environment with marked flexibility and scalability.
The Application Server also includes a full-featured Advanced Intelligent Network (AIN) messaging interface built over a SIGTRAN/M3UA protocol implementation. With this functionality, new service offerings can be quickly delivered across your legacy network elements, replacing existing service implementations on legacy Service Control Points (SCP). Using the Application Server allows you to plan your network migration from legacy Time-Division Multiplexing (TDM) infrastructure to the all-IP network, all while maintaining your current service offerings.
The Application Server consists of several machines (typically a minimum of three) that can be either physical hardware servers or virtual machines and that work together to provide network applications to the clients. The server communicates with several network peers to best serve the intended clients and is dedicated to the efficient execution of service logic while processing a call.
The first machine in the Application Server is the Network Interface Unit (NIU). The NIU is the machine with the well-known IP address for external communication, and all calls that come into the server are first received by the NIU.
The remaining machines are the Application-Processing Servers (AS) that process the calls by executing the service logic for the applications and performing the call treatments. Each AS contains an embedded media server so that it can act as an endpoint during the call to play or receive media. This feature is useful for Interactive Voice Response (IVR) applications, collecting dual-tone multi-frequency (DTMF) digits, and recording calls. Because the AS contains the session and media licenses, the actual call session state machine is maintained here.
All calls that come into the server are first received by the NIU. The NIU then evaluates which AS to pass the call to for continued handling based on the current load, available licenses, health of the AS, defined routing rules, and registered applications on each AS. The call is forwarded to the chosen AS. The NIU acts as a proxy for the first portion of the call and stays in the call until the initial INVITE is acknowledged by the selected AS. After an ACK is returned, the NIU sends a REDIRECT message to allow the far end and the selected AS communicate directly for the remaining duration of the call.
For high availability (HA) demands, the NIU can be paired with a secondary NIU. In this scenario, there is a single primary NIU that directs calls to the AS machines as previously described. In addition, this NIU shares some call state information with its partner NIU. If there is a failure on the primary NIU, the paired secondary NIU takes over and continues to direct calls to the AS machines. In a paired scenario, the primary and secondary NIUs can either route to the same set of AS machines or use completely different sets of machines depending on the reliability requirements of the network.
For more information, see High Availability Services.
The following minimum system specifications refer to either physical hardware or a VM.
Note
Any VM software can be used to create and manage VMs for the Application Server.
dual core CPU
2Ghz processor
4G memory
8G disc storage
CentOS 7.x or Red Hat Enterprise Linux 7.x operating system
Note
When installing the Application Server, there are more dependencies than just the base OS installation. These dependencies are for the compatible libraries for the OS and the xerces-c and boost library packages. Performing a yum install
of the Service Delivery Platform RPM package file attempts to resolve these dependencies.
The Service Delivery Platform is an IMS Next Generation Telephony network device. To maintain call quality, the following minimum network performance measures must be met:
end-to-end, one-way latency does not exceed 100ms
jitter does not exceed 20ms
packet loss is less than 0.5%
We recommend using Quality of Service (QoS) to grant VoIP traffic the highest priority and minimize the network impact on voice quality. A Multiprotocol Label Switching (MPLS) based network is also recommended.
For more information about monitoring and managing the Application Server, see the Console User’s Guide.
The Application Server licensing manages access to either the SIP call flow (session), AIN messaging, or media server (endpoint) functions. The Application Server will not function in a call flow without a license.
Session licensing embeds the maximum number of simultaneous SIP and/or AIN sessions that can be instantiated on the server. Media endpoint licensing embeds the maximum number of media connections that can be established on the server. A single call can consume one or more of each type of license. Every call consumes at least one session license.
License keys are provided to you with the product. These keys must be installed on the server before starting services. For more information about using the Console License Manager, see Using the Console.