REDCOM’s Service Delivery Platform consists of three elements:

  1. The REDCOM Application Server
  2. The REDCOM Service Creation Environment
  3. The REDCOM Management Console

These elements work together to provide a complete solution for creating, deploying and managing voice services in your network.

REDCOM IMSWorkX Application Server

The REDCOM Application Server offers rapid customization and adaptation of existing applications as well as the ease and flexibility of creating new applications, all of which can be built and delivered reliably across a wide variety of networks including IMS, VoIP, VoLTE, VoWifi, IN, GSM, CDMA and converged TDM/IP.

REDCOM Application Server

A flexible architecture for every network

The robust architecture combined with the use of next generation network standards provide a multi-service deployment environment that is both flexible and scalable. Instead of relying on costly single application platforms, you can deliver multiple SIP or AIN-based services starting with a single REDCOM Application Server. A 2x2x4 virtual machine (dual vCore, 2 GHz processor, 4GB memory) provides up to 1,200 active sessions (application dependent). When you are ready, the REDCOM Application Server’s distributed call processing and load balancing lets you rapidly add or modify services as needed with no service interruption.

High Availability Cluster – paired instances for redundant deployment

The application server is a cluster of machines that work together to serve network applications to the clients. The server communicates with several network peers in order to best serve the intended clients. 

The server consists of several machines (usually a minimum of 3) that can be either physical hardware servers or virtual machines. The first machine in the application server is the Network Interface Unit (NIU). The NIU is the machine that has the public IP address for external communication. All calls that come into the server are first received by the NIU. 

The remaining machines in the server are Application-Processing Servers (AS). These machines actually process the calls by executing the service logic for the applications that are running and performing all the call treatments. Each AS contains an embedded media server so it can act as an endpoint during the call to play or receive media. This feature is useful for IVR applications, collecting digits, and call recording. The AS contains the session and media licenses so the actually call session state machine is maintained in these machines. 

REDCOM High Availability Cluster

Call handling for high availability demands

The Network Interface Unit allows distribution of call processing across many Application-Processing Servers in an N+1 configuration within a cluster. This high availability cluster can be co-located or distributed across an IP network. For redundancy, the NIU can be paired in an active/standby configuration. For load balancing, the NIU directs calls to the least busy AS in the cluster. This load balancing enables a single service access point to the Application Server cluster that can scale from a very small network to one that supports millions of subscribers. All AS within the cluster are always active.

Failovers

When the active NIU goes down, a failover automatically switches all incoming traffic to the standby NIU. The following situations can cause a failover:

  • Network is determined to be down by the online NIU
  • There is a critical process crash on the online NIU
  • Online NIU goes offline

Failover state machine

This high availability configuration ensures that revenue-generating services stay running under any failure scenario.

Failover

Based on industry standards

Compliance with and the use of industry standards ensures that the REDCOM Application Server is easily integrated into VoIP, VoLTE, IMS, and converged networks. This adherence to industry standards guarantees that the REDCOM portfolio of applications stays current with the ever evolving nature of next generation network architecture and specifications.

Internet Engineering Task Force (IETF)

  • RFC 3261 – Session Initiation Protocol (SIP)
  • RFC 3264 – An Offer/Answer Model with the Session
  • RFC 2327 – Session Description Protocol (SDP)
  • RFC 3262 – Reliability of Provisional Responses in SIP
  • RFC 2976 – SIP INFO Method
  • RFC 3265 – SIP-Specific Event Notification (not fully compliant)
  • RFC 3515 – SIP Refer method
  • RFC 3892 – SIP Referred-By Mechanism
  • RFC 3891 – SIP “Replaces” Header
  • RFC 3842 – Message Summary and Message Waiting Indication Event Package for SIP
  • RFC 2806 – tel URI for Telephony Calls
  • RFC 3389 – Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)
  • RFC 3665 – SIP Basic Call Flow Examples
  • RFC 2045/46 – Multipurpose Internet Mail Extensions (MIME) Parts One and Two
  • RFC 2396 – Uniform Resource Identifiers (URI):Generic Syntax
  • RFC 1889 – RTP: Transport Protocol for RealTime Applications
  • RFC 3666 – SIP PSTN Call Flows
  • RFC 2617 – HTTP Authentication: Basic and Digest Access Authentication
  • RFC 2833 – RTP Payload for DTMF Digits,Telephony Tones and Telephony Signals
  • RFC 3550 – RTP: Transport Protocol for Real-Time Applications
  • RFC 3489 – STUN – Simple Traversal of UDP through Network Address Translators
  • RFC 3323 – Privacy Mechanism for SIP
  • RFC 3863 – Presence Information Data Format (PIDF)

MS-specific SIP standards compliance

  • RFC 3325 – Private Extensions to SIP for Asserted Identity within Trusted Networks
  • RFC 3311 – SIP UPDATE Method
  • RFC 3312 – Integration of Resource Management and Session Invitation Protocol
  • RFC 3891 – SIP “Replaces” Header
  • RFC 4032 – Update to SIP Preconditions Framework
  • RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax
  • RFC 4004/05/06 – Diameter: proper handling of vendor-specific applications and AVPs

3GPP technical specifications

  • IMS sh interface for subscriber information – 3GPP TS 29.329 (Sh interface)
  • IMS rf interface for offline charging – 3GPP TS 32.260 (Ro/Rf charging)
  • IMS ISC interface for session control – 3GPP TS 24.228 (core signaling) – 3GPP TS 24.229 (IMS call control)
  • IMS Multimedia Telephony Service and supplementary services – 3GPP TS 22.173 version 12.7.0 Release 12 

IN technical specifications

  • GR-1299 AINGR for switch-Service Control Point (SCP)/adjunct interface information
  • GR-1188 LSSGR: CLASS℠ Feature: Calling Name Delivery Generic Requirements
  • GR-533 LSSGR: Database Services Service Switching Points – Toll-Free Service

Network performance measures

The REDCOM 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%

REDCOM recommends that you use QoS to grant VoIP traffic the highest priority and thus minimize the network’s impact on voice quality. An MPLS-based network is also recommended.

Software product distribution

The REDCOM Application Server is a software-only platform that is provided as an installable .rpm file and is built for machines (physical or virtual) with the Red Hat Enterprise Linux 6.x or CentOS 6.x (32 or 64 bit) operating system.  The platform software takes advantage of other services in the operating system including Tomcat and Apache. Application services executing as part of the REDCOM Application Server take advantage of direct Java and JDBC interfaces to integrate with PostgreSQL, and other database engines.

Complete voice service solution

REDCOM provides powerful service layer applications for VoIP, VoLTE, IMS and Converged IP/TDM networks that are flexible to meet the needs of any network and subscriber. The highly scalable REDCOM software platform brings added value to service providers because of its proven ability to provide current services on legacy networks while simultaneously allowing rapid development of new services for evolving networks.

REDCOM Service Creation Environment

The REDCOM Service Creation Environment (SCE) is an industry-leading visual service development environment that enables developers to build sophisticated applications using drag-and-drop Plug-in Action Components (PACs) to enable a variety of built-in operations and link them in a visual call flow. This windows-based, intuitive interface makes applications faster to develop, customize, and modify to meet changing market needs.

Highlights:

  • Visual call flow representation provides an intuitive development user interface.
  • Plug-in Action Components allow straightforward drag and drop development of next-generation network applications – including actions for:
    • Applications
    • Communications
    • Intelligent Networks
    • Mail
    • Media/IVR
    • Session/Call Control
    • Subscriber Profile
    • Third Party Call Control
  • “Drop to Java” feature allows full programmatic control for custom features directly in the call flow
  • Applications are automatically translated into XTML to deliver enhanced voice services with speed and flexibility comparable to XML-based internet applications.
  • Protocol support includes SIP, HTTP (REST/SOAP), RADIUS, SIGTRAN, Mail and select DIAMETER interfaces

Visual Call Flow Representation

Developers build applications using drag and drop PACs to enable a variety of built-in operations and then link them in a visual call flow. This simple, intuitive interface makes applications faster to develop, customize, and modify to meet changing market needs.

XTML Language Flexibility

Applications built with the REDCOM SCE are automatically saved into XTML (eXtensible Telephony Markup Language), an XML-based service description language. These XTML-based applications run natively on the REDCOM Application Server. With its extensive use of XTML, users of the REDCOM SCE are able to deliver enhanced voice services with speed and flexibility comparable to XML-based Internet applications.

SIP, IN, and IMS Protocol Support

Just like the REDCOM Application Server, the REDCOM SCE supports SIP (RFC 3261 and others), AIN via SIGTRAN (RFC 2719 and others), as well as important IMS protocols. Developers need not become SIP or signaling “experts” because the SCE abstracts protocol specifics and handles implementation details; developers simply specify the policies to be applied to the multimedia sessions the application creates and controls. The environment offers native support for protocols including HTTP, RADIUS, Mail, and select DIAMETER interfaces.

Built-In Programming Tools

The REDCOM SCE includes a JavaScript editor that can be invoked from any PAC, and an integrated XML parser for checking SCE XML output. Developers can also add Java code using the “Drop to” PAC to easily incorporate their own programming logic into a call flow.

Extensive Set of Plug-in Action Components and Plug-in Event Components

The REDCOM SCE has a rich set of PACs and PECs for creating next generation network services.

Plug-in Action Components (PACs)

PACs are the building blocks of a function and each one performs a specific action. These PACs are selected, customized, and then linked in the call flow to create the application.

  • Application: Call a Function, Drop to Java – static method, End the Session, Generic Action, Import Application Properties, Perform Timer Operations, Return from a Function, Sleep, Test Values and Branch
  • Communication: Handoff the Call to another Application, HTTP Request, Send a Message, Wait for an Event
  • Conferencing: Create a Conference, Delete a Conference, Modify a Conference, Modify Party in Conference, Remove Party from Conference
  • IN Calling Name Delivery (GR-1188): Return Error, Return Result Last
  • IN Service Control Point Interface (GR-1299): Analyze Route, Authorize_Terminiation, Continue, Disconnect, Forward_Call, Info_Analyzed, Info_Collected, Send_To_Resource,Terminiation_Notification, Update, Update_Data, Update_Request
  • IN Toll Free (GR-533): Connect, Provide Instructions/Start
  • Mail: Create Mailbox, Delete Mailbox, Get Mailbox Status, Read Mail, Search Mailbox, Send Mail, Update Mail
  • Media Server Commands: Audit Media Server, Connect to Media Server
  • Media/IVR: Create/Modify/Delete Connection, Notify Request, Play and Collect, Record Audio Stream, RTP Relay, Set Digit Map
  • Radius Commands: Send a Radius Message
  • Session/Call Control: Generate a SIP Dialog Request, Modify SIP Dialog, Respond to SIP Dialog Request, Send SIP Message Terminate SIP Dialog
  • Subscriber Profile (IMS Sh Interface): Profile Update Answer/Request, Push Notification Answer/Request, Subscribe Notification Answer/Request, User Data Answer/Request
  • TCAP: TCAP Forward Message
  • Third-Party Call Control: Outdial from Application Server, Place a Call on Hold

Plug-in Event Components (PECs)

The comprehensive set of PECs can be specified as call flow functions to trigger logic at any point during a call. PECs simplify the design of call flows by eliminating embedded conditional logic that would otherwise be needed to handle these events explicitly.

  • Application: SigtranNotification
  • Application Server Events: ServiceLoad, ServiceUnload, SessionStart, SessionEnd, Timer
  • Communication Events: Handoff
  • Conferencing Events: ActiveSpeakerNotification
  • IN Calling Name Delivery Events (GR-1188): ParameterProvideValue
  • IN Service Control Point Events (GR-1299): Analyze_Route, Close, Continue, Disconnect,Info_Analyzed, Info_Collected, Resource_Clear, Termination_Attempt,Termination_Notification,Update_Data
  • IN Toll Free Events (GR-533): Connect, ProvideInstructionsStart
  • Media/IVR Events: MediaActiveSpeaker, MediaDTMF, MediaInactiveSpeaker, MediaPlayDone,MediaPlayFailed, MediaRecordDone, MediaRecordFailed
  • Radius Events: AccessAccept, AccessChallenge, AccessReject, AccessRequest, AccountingRequest, AccountingResponse, ClientStatus, ServerStatus
  • Session Call/Control Events: SIPDialogRequested, SIPDialogTerminated, SIPMsgOutsideDialog, SIPMsgWithinDialog
  • Subscriber Profile Events (IMS Sh Interface): ShMessage
  • User/Device Registration Events: RegisterRequest, UnregisterRequest

Facilities to Provision XTML Applications

Once an application is created, developers can transfer application XTML files from the SCE directly to an REDCOM Application Server.

REDCOM Management Console

The REDCOM Management Console (Console) is a robust Element Management System that offers views into the applications, process, and events running on the REDCOM Application Server. The Console allows Application Servers to be managed as a system regardless of the number of physical servers. The Console is fully backwards compatible with all versions of REDCOM servers, and provides some of the same functionality as an Element Management System commonly used in telecommunications.

Feature Highlights

The Console supports the following features:

  • Configuring and monitoring SIP, IN (AIN) applications running on application servers
  • Connecting to both secure and unsecure servers
  • Monitoring the server inventory
  • Monitoring endpoints on media servers
  • Viewing connection states between message peers
  • Viewing log files
  • Managing licenses
  • Receiving and displaying SNMP traps

The Secure Console Feature

The console can connect to the Application Server using a secure TLS connections. This connection can be configured with or without a trusted certificate.

Console Functionality

The console displays service hosts in the Object Panel. These hosts can be explicitly added, or they can be found using the Discover feature. When a service host has been added, they can be saved in a configuration file and be reopened upon subsequent use of the console.  Each service host can have any of the following three types of service agents:

  • Applications: All applications running on the associated service host
  • Media Servers: All media server on the associated service host
  • Message Peers: All connections from the associated service host to other service hosts

The service agents are either manually configured or automatically added through the Discover feature. The console allows you to navigate and obtain more detailed information about service agents. For example, if you select message peers, you can view outage logs for its peers.

Management Functions

You can also use the console to perform management functions, such as starting and stopping sessions or applications. Viewing the details of a specific session can help to quickly diagnose problems during that session. This type of system monitoring is similar to using a debugging tool for a process, but is implemented at the application level.