ip telephony and the interaction center platform · platform provides a number of methods to...

7601 Interactive Way Indianapolis, Indiana 46278

Telephone/Fax: (317) 872-3000 www.inin.com

IP Telephony and the Interaction Center Platform®

White Paper

By

David Fuller

Managing Director, Strategic Consulting

Last updated April 12, 2005

Abstract

Telephony remains the dominant form of customer interaction for most businesses today, and is certainly a fundamental component of effective customer service. Traditional telephony is now being joined by IP-based telephony options to reduce the cost of telecommunications and to increase communications options. The Interaction Center Platform provides a number of methods to combine traditional circuit and IP telephony utilizing comprehensive support for a variety of telecommunications architectures. The benefits to enterprises and contact centers are quite dramatic. This white paper discusses how the Interaction Center Platform and IP telephony combine to offer a powerful self-service as well as live service solution to various types of businesses.

IP Telephony and the 2 ©2002-2005 Interactive Intelligence Inc. Interaction Center Platform

Copyright and Trademark information ©1994–2005 Interactive Intelligence Inc. All rights reserved. Interactive Intelligence®, Interactive Intelligence Inc.®, Interaction Center Platform®, Communité®, Enterprise Interaction Center®, Interactive Intelligence Customer Interaction Center®, e-FAQ®, e-FAQ Knowledge Manager™, Interaction Dialer®, Interaction Director®, Interaction Recorder®, Interaction Supervisor™, Mobilité®, Interaction Administrator®, Interaction Attendant®, Interaction Client®, Interaction Designer®, Interaction Fax Viewer™, Interaction FAQ™, Interaction Melder™, Interaction Scripter®, Interaction Server™, Wireless Interaction Client™, InteractiveLease®, and the Interactive Intelligence “Spirograph” logo design® are all trademarks or registered trademarks of Interactive Intelligence Inc.

Other brand and/or product names referenced in this document are the trademarks or registered trademarks of their respective companies.

DISCLAIMER

INTERACTIVE INTELLIGENCE (INTERACTIVE) HAS NO RESPONSIBILITY UNDER WARRANTY, INDEMNIFICATION OR OTHERWISE, FOR MODIFICATION OR CUSTOMIZATION OF ANY INTERACTIVE SOFTWARE BY INTERACTIVE, CUSTOMER OR ANY THIRD PARTY EVEN IF SUCH CUSTOMIZATION AND/OR MODIFICATION IS DONE USING INTERACTIVE TOOLS, TRAINING OR METHODS DOCUMENTED BY INTERACTIVE.

Interactive Intelligence Inc. 7601 Interactive Way Indianapolis, Indiana 46278 Telephone/Fax (317) 872-3000 www.ININ.com


Table of Contents Introduction................................................................................................4

The Need for Complete Media Control .........................................................4

Multimedia Interaction Management Using the Interaction Center Platform......................................................................5

IP Telephony Communications Options.......................................................7

SIP Explained ...................................................................................................... 7

IP Telephony and the Interaction Center Platform......................................9

SIP Session Initiation/Termination ..........................................................14

SIP Session Control and Media Control Distinctions..................................15

SIP Resource Differences in Enterprise and Contact Center Applications .............................................................16

Multi-site Applications of IP telephony .....................................................17

Multi-Site Using SIP .......................................................................................... 17

Multi-Site Using Cisco CallManager.................................................................... 18

SIP Line and Station Configuration ...........................................................19

IP Telephony Impact on Scalability and Reliability ...................................23

Large Call Center Operations............................................................................. 25

Clustering, Scalability and Load Balancing ........................................................ 26

Cisco AVVID ...................................................................................................... 26

SIP Softswitch Architectures and the Interaction Center Platform ...........27

Summary ..................................................................................................28

Reality Check ............................................................................................29


Introduction IP telephony introduces new ways for organizations to communicate more flexibly and cost effectively. But simply putting voice over an IP network does not provide the additional value these communications can generate between organizations, their employees, and external parties such as customers and suppliers.

Interactive Intelligence (ININ) has created a suite of interaction management software products that address self-service as well as live service within the communications process. Among these ININ products, both the Customer Interaction Center® (CIC) and the Enterprise Interaction Center® (EIC) are built on the Interaction Center Platform event-processing engine, and extend the Platform’s many live service capabilities.

To meet the communications requirements of distinct businesses, and to protect investments in applications and software, the Interaction Center Platform technology offers several options for communications systems hardware. This flexibility allows organizations such as enterprises and contact centers to move CIC, EIC and other Interactive Intelligence software — along with system customizations, administrative information, and data — transparently from one communications platform to another. It also allows an organization to implement a communications solution using voice processing boards in a time division multiplex (TDM) architecture from Intel/Dialogic or Aculab, then migrate later to an advanced voice over IP (VoIP) system using additional components from vendors such as Cisco, Siemens or Microsoft. Organizations can even move to more open IP telephony standards such as the Session Initiation Protocol (SIP).

The Need for Complete Media Control One of the fastest growing technologies being adopted by organizations today is the “all-in-one” communications server. Such technology lets companies replace PBX-style and CTI-based switching and call control architectures with a server-based solution that not only handles call switching and call control, but also performs various call processing and media processing with fewer “boxes.”

The importance of full media control in a communications solution cannot be overstated, since many communications-based applications rely on extensive media control to perform critical application functions, such as:

• Playing and recording audio for IVR, ACD and unified messaging applications

• Conducting multi-party conferencing (used as a conference bridge), or addressing complex customer service scenarios

• Supervisor monitoring for ACD

• Call analysis/call progress detection for outbound predictive dialing/campaign management environments

• Voice recognition as an enhanced IVR, ACD or unified messaging capability

While IP-PBXs and softswitches have made it possible to run voice over IP (VoIP) and perform a number of call control and call management features, many IP-PBXs and softswitches now on the market are not capable of handling media processing in the same server architecture. If media processing is required, additional servers or third-party solutions must be added to the IP network, which begins to limit how media processing can be used within the organization — and which increases the points of integration and, ultimately, system failure (see Figure 1). The result is really no different than the multi-system, CTI-oriented solutions that have existed for many traditional circuit-based PBX environments.


Figure 1 – The media control problem: most IP telephony architectures still require a number of application and media processing servers.

For organizations that have a combined IP telephony requirement and high media processing or complex application requirement, or that are moving in this direction, the best solution will provide as many switching and media processing capabilities as possible from the same vendor, with the fewest systems possible. And while the selected IP telephony platform might impose certain requirements on the application architecture, the overall goal of reducing the number of servers and system integration points eventually results in a lower total cost of ownership.

Multimedia Interaction Management Using the Interaction Center Platform

The Interaction Center Platform is a revolutionary set of interaction-processing components. Unlike proprietary devices such as switches, voice mail systems, call distributors, and voice response units used to manage interactions in the past, the Interaction Center Platform is a set of open software objects that run on Windows NT (for earlier versions) and Windows 2000 servers (version 2.0 and higher).

At the heart of the Interaction Center Platform is the Interaction Processor multi-threaded event-processing engine. In offering a single point of control through which all communication events pass — regardless of origin (see Figure 2) — the Interaction Processor is capable of handling many different types of communication events. These


events include incoming and outgoing telephone calls, e-mail messages, faxes, digital and alphanumeric pages, button clicks on Web pages, generic interactions such as trouble tickets and customer records, and other interaction types. The Interaction Center Platform and its processor also interface seamlessly with e-mail systems (iPlanet, Microsoft Exchange, Lotus Notes, other SMTP/IMAP-compliant platforms), Web servers (Microsoft IIS, iPlanet, Apache), and database servers (SQL Server, Oracle, Sybase, Informix, etc.) on a local or wide area network. For voice capabilities, the Interaction Center Platform can interface to legacy switches or communicate directly with the telephone network via analog, T1, E1, and ISDN PRI trunks.

Figure 2 – The Interaction Center Platform offers a single point of control for all communication events.

To customize the processing of any communications event, the Interaction Center Platform includes the Interaction Designer® graphical application generator. Interaction Designer’s development tools and drag & drop environment enable programmers to visually lay out the logic that determines how a given event, such as an incoming telephone call, is to be handled. Once a “handler” and its logic are configured, Interaction Designer automatically generates a program that is compiled and executed in its own thread within the Interaction Processor.


It is this combination of:

• a powerful, multi-threaded event-processing engine,

• a wide range of interfaces to e-mail systems, central office trunks, Web servers, and database management systems, and

• a graphical application generator

that allows the Interaction Center Platform to fulfill an amazing number of interaction processing roles and eliminate the need for multiple legacy telecommunications devices.

(For more detailed information on the Interaction Center Platform, please refer to the Interaction Center Platform white paper.)

IP Telephony Communications Options As organizations look beyond existing “hub and spoke” approaches to telephony, architectures based on Internet Protocol (IP) telephony quickly come to mind. Certainly, many organizations can utilize IP-based telephony to reduce costs associated with calls between various locations. Carriers have proven that packet telephony can significantly increase the number of calls per physical data connection and, as a result, dramatically reduce long distance calling costs for consumers. Also as more and more consumers utilize the Web as their primary initial contact point with businesses, enabling voice communications directly from the Web can handsomely increase customer satisfaction.

Although this white paper is not intended to cover all benefits of IP telephony, a few important considerations are indeed worth noting — especially for multi-location enterprise and contact center applications.

One area in which organizations require added capability is the multi-site enterprise. For organizations that maintain multiple offices, and that house workers with particular skills in each office, such distributed organizations are faced with centralizing their technology into core data centers to provide a single point of access and communications control for all employees. Unfortunately, technology often keeps distributed organizations from providing a single contact view for customers to reach workers and workgroups at various locations. Utilizing IP-based approaches, however, individuals in various offices can be placed into virtual workgroups, thus making the group view larger than the sum of its separate parts. Regardless of location, agents as well as business users can be available to take calls that match their particular skill-set.

Or, an organization may need to provide seamless transfer or conferencing features to users at many locations. In this scenario, it’s critical that full call control features are preserved. Moreover, organizations want to easily set up call routing schemes to better protect against disasters and other outages that might impact certain locations. With distributed agents, only agents local to the outage should be directly impacted.

SIP Explained Many approaches are available to enable packet-based telephony, including proprietary communications protocols and point-to-point only strategies, along with sophisticated device identification plus carrier-class and enterprise-oriented call management/call control methods. While there are many considerations, one thing is clear: Standards and simplicity are critical for IP telephony to achieve the full support of business. One IP telephony approach quickly gaining international support is the Session Initiation Protocol, or SIP.


Prominent reasons why Interactive Intelligence provides extensive SIP support are that SIP is:

• Widely regarded as the successor to H.323 for IP-based telephony

• Gaining increased attention and visibility due to major technology supporters

• An alternative to TAPI-based IP telephony models

• A protocol that eliminates the need for a separate IP-PBX and contact center solution

• An emerging standard for session control for a variety of other communications mediums

The following sections discuss each of these points in more detail.

Successor to H.323 for IP-based telephony First, SIP is widely regarded as the successor to H.323 as the preferred call control standard for IP-based telephony. Whereas H.323 has promulgated the initial adoption of packet-based call control, SIP is expected to move this adoption to new levels in overtaking H.323 IP telephony. One reason is SIP’s addressing and routing methods. Currently, H.323 utilizes call control techniques similar to those used in traditional telecommunications architectures, which adds many layers of complexity. SIP, however, uses standards akin to the Domain Naming Services (DNS) of the Internet, as well as HTTP-style addressing for SIP-compliant phones and other SIP-compliant devices such as softphones. In addition, SIP is widely known to be a much lighter control protocol for IP telephony and other media types. This means SIP can scale in a more linear fashion to earlier control protocols such as H.323, and has less processing overhead since there are fewer standards to be encapsulated in the telephony packet stream to initiate and terminate sessions. As a result, when compared to H.323, SIP tends to be much simpler to understand and set up.

Increased attention and visibility due to major technology supporters Additional reasons SIP is gaining increased attention and visibility come from major technology supporters. Microsoft has specifically targeted SIP to drive added communications capabilities within their operating systems. In line with this approach, Microsoft has bundled its Microsoft Messenger SIP client within Windows XP, thus enabling audio communication and other SIP-compliant session management to be supported directly from the desktop workstation. Another Microsoft component is the server-side real-time communications solution called RTC that offers SIP Proxy and Registrar capabilities from Windows.Net platforms. Other vendors are providing support for SIP as well. For example, Cisco has built SIP support into its line of gateways, routers, and IP phones. Siemens, PingTel, and other vendors also are now offering SIP-based IP phones in their product lineups. Many traditional phone providers have likewise pledged to support SIP. For routers and switches, several vendors in that sector are incorporating ways to move from existing H.323-based or proprietary call management models to SIP via simple firmware downloads and switch software upgrades. All of these signs point to a broad range of new SIP support both from telephony and data communications vendors.

In fact, many SIP-compliant IP phones have already been designed with enhanced features such as Hold, Transfer, and Conference buttons along with Message Waiting Indicators (MWI lights), with some phones also supporting multiple call appearances.


Other phone-based features will certainly be added over time as SIP standards are approved by the agencies that govern them.

Alternative to TAPI-based IP telephony models Another important distinction organizations must consider is that SIP provides an alternative to TAPI-based IP telephony models. This is significant since TAPI-oriented approaches, while providing more comprehensive capabilities as time progresses, are still limited in their feature support with respect to contact center applications. At a minimum, TAPI-oriented solutions require TAPI WAV port support for any auto-attendant or IVR-style applications. Similarly, features such as multi-party conference, listen, and record are difficult to achieve in TAPI environments. Scalability poses yet other potential problems depending on how TAPI service providers (TSPs) are designed by various TAPI vendors.

Eliminates the need for a separate IP-PBX and contact center solution Still with regards to SIP, many businesses and organizations might wonder why there’s a need for a separate IP-PBX and contact center solution in the first place. From a customer/user standpoint, there should be no reason to maintain two separate systems for enterprise users and contact center users, as long as a single solution provides required telephony and data communications features and application features for both user groups. By moving to a SIP-based IP telephony support model that provides all required user and departmental features, organizations can eliminate the need for a separate IP-PBX altogether, while still achieving a great degree of call handling and media processing flexibility. For a variety of reasons, some companies may not follow this train of thought, though many organizations can certainly make IP telephony a more affordable and supportable communications option.

Emerging standard for session control for other communications mediums While SIP is quickly becoming a critical call control standard, it also is an emerging standard for session control for a variety of other communications mediums. For example, certain instant messaging products utilize SIP for managing the delivery and receipt of messages. Other media such as video conferencing also hold the potential to utilize SIP control, rather than continuing to rely on the complex and somewhat proprietary communications architectures that now exist. As effectively, SIP can be utilized to route user-defined or custom messages and media. Since it relies on TCP/IP, XML and HTTP, SIP allows the media type to be encapsulated in a SIP-oriented control session, thus enabling the media control.

IP Telephony and the Interaction Center Platform To contrast the difference between traditional circuit based architectures and supported IP telephony architectures, let’s take a look at the Customer Interaction Center (CIC) architecture as built on the Interaction Center Platform.

Though we cite CIC in this example, other Platform-based, telephony-oriented products from Interactive Intelligence, including Communité and the Enterprise Interaction Center (EIC), can also be represented within their respective functional areas. For this discussion, however, we’ll describe various telephony options for the Interaction Center Platform using CIC as a point of detail. These options are as follows:


• (Figure 3) CIC with only circuit-based telephony boards for trunk and station connections.

• (Figure 4) CIC with Cisco CallManager using a TAPI interface for call management and call control. There are no circuit-based telephony resources used in this architecture.

• (Figure 5) CIC with a hybrid configuration using circuit-based telephony boards for trunk and some station connections, and SIP-based IP telephony boards for station connections to SIP compliant IP phones and SIP softphone clients.

• (Figure 6) CIC working in conjunction with a SIP gateway and SIP proxy server to service all call requests using IP telephony boards and connecting to SIP-compliant IP phones and SIP softphone clients.

Figure 3 – Interaction Center Platform supporting a circuit telephony architecture.

In Figure 3, we represent CIC functioning with traditional telephony components in the Interaction Center Platform (IC) server utilizing either Intel/Dialogic or Aculab telephony boards. Connectivity with telephony devices is completely encapsulated in a single component of the Interaction Center Platform — Telephony Services, or TS. Interactive Intelligence offers two versions of TS. The first contains code to control Intel/Dialogic and Aculab boards and to perform all telephony functions (e.g., make a call, transfer, conference, record, play prompts, etc.). The second version contains code to integrate with the Cisco CallManager product, the software used to perform call control in a Cisco AVVID installation. The rest of the Interaction Center Platform is essentially oblivious to the underlying hardware; therefore no application changes are required to switch between a Intel/Dialogic or Aculab configuration and a Cisco AVVID configuration. For example, specifying a Transfer operation in an application running on a CIC server will


execute a transfer regardless of whether that application is residing on a circuit-based or Cisco-based telephony architecture.

Figure 4 – Interaction Center Platform supporting the Cisco AVVID IP telephony architecture via a TAPI interface.

In Figure 4, CIC is represented as a bundled contact center suite that is also fully IP-enabled using the Cisco IP telephony CallManager solution. As a certified Cisco AVVID solution for CallManager, CIC controls calls via a TAPI interface directly between the CIC server and the CallManager master server. CIC acts as the audio termination point for call processing while calls are being processed for auto attendant, IVR, ACD hold, voice message play, and voice message record functions. CIC also acts via TAPI as the point for first-party call control when calls need to be transferred from one of these server-level audio processing states to a Cisco IP phone. In addition, the CIC server handles third-party call control events from the Interaction Client® user interface if calls need to be transferred to other phones or back to the CIC server.

CIC also provides a separate telephony services component to specifically perform call management and call control with Cisco’s AVVID IP telephony architecture — thereby providing the same level of circuit-based telephony platform features obtained using Intel/Dialogic and Aculab telephony boards. As stated earlier, while telephony services components are different depending on the telephony platform architecture, the remaining communications connection components and application logic in CIC remain unchanged, virtually eliminating any specific system or applications changes when moving from one environment to another. Additional servers may be necessary to address recording, supervisory listen and/or fax requirements; however, these servers are managed in a common fashion under the Interaction Center Platform.


Figure 5 – Interaction Center Platform supporting BOTH a hybrid circuit and IP telephony architecture.

As shown here (Figure 5), the next step for CIC beyond Cisco-based IP telephony is SIP. Utilizing SIP, CIC can function in a variety of new ways, including as a standalone “all-in-one”-style communications solution, or as a communication server in conjunction with an existing SIP gateway and SIP proxy server to manage all SIP-enabled IP phones for a given location.

Using traditional T1/E1 carrier circuits, CIC can function as the gateway for SIP phones that are directly associated with the CIC server. By using SIP-compatible IP telephony boards in the CIC server, CIC acts as the switching point for all calls while still performing all other multimedia queuing and interaction management duties for faxes, e-mails and Web events. CIC can even mix traditional circuit-based telephony resources and IP-based telephony resources in the same physical server — allowing an organization to utilize analog station phones for local users, and IP phones for users at other, more remote locations. The same IP telephony boards may also be used to take calls or receive calls from the extended IP network, depending on SIP routing schemes enabled within the extended IP network.


Figure 6 – Interaction Center Platform using a SIP proxy and gateway.

When CIC is implemented as a communication server in conjunction with an existing SIP gateway and proxy server (as shown in Figure 6), organizations achieve additional possibilities.

Initially, an organization can implement SIP so that IP-based calls can be routed between multiple locations and also adhere to a common routing method. Second, separate gateways may make more sense for organizations utilizing specific switching hardware as a networking standard within their overall organization. Another option is to allow certain SIP clients (either hard-phones or soft-phones) to be devices managed by CIC and other SIP clients to be unmanaged. Managed devices are those that are registered with the CIC server. Also, calls to and from managed devices can be controlled from CIC’s Interaction Client user interface, which also manages call authorization. Calls to and from these devices are logged according to CIC’s interaction logging standards.

Unmanaged devices are SIP clients that are not registered with a CIC server, meaning that all call routing is performed strictly by SIP proxy servers. For some organizations, this may make sense if certain employees maintain reduced telephony requirements. Unmanaged devices are still reachable from a CIC server, however, and can place calls to SIP clients managed by a given CIC server.


SIP Session Initiation/Termination A simple SIP-based call setup example should help explain how devices establish audio connections. First, a given SIP client requests a session with another SIP client. This is accomplished by having the requesting SIP client send an INVITE request. Second, once the requested SIP client has been located, the SIP proxy sends a TRYING message back to the requesting SIP client. Third, the proxy server sends a RINGING message to update the current connection status. Fourth, once the requested SIP client has been reached, it sends back an OK message with specific communication information on how an audio connection can be established between the SIP clients. Fifth, the requesting SIP client sends an ACK message to acknowledge the receipt of the OK message. Sixth, an audio session is established utilizing a packet type called Real-Time Protocol, or RTP, between the SIP clients. This session flow is diagrammed in Figure 7 here. Thes basic SIP client call flow is then extended to include communications with SIP proxy, redirect and location servers in order to complete the session setup, as shown in Figure 8.

Figure 7 – SIP basic session initiation flow between two SIP clients.


Figure 8 – Session initiation utilizing SIP registration, proxy, and redirect services.

SIP Session Control and Media Control Distinctions One important point to make regarding SIP is that the audio portion of a given session is separated from the session control portion associated with that media session. Using a phone call as an example, the audio portion (the media) is separated into a different set of IP packets from the call control portion (the session control). Because IP is a distributed and routed network architecture, this means the media packets may follow a different path than the session control packets. This is especially important to note with respect to CIC’s SIP capability.

Also since session control packets are the first communication packets used to establish a given media session, these session control packets will typically be routed to SIP proxy servers (and possibly SIP redirect servers) to identify the IP address of the device to which the media session will ultimately be established. Once this device has been located, the media packets will follow whatever network routing path is determined to be the most efficient.

CIC is the physical server that, in the absence of a separate proxy server, performs the function of the proxy server and handles SIP session control. Given that CIC houses the IP telephony boards as well, the CIC solution also functions as the media termination point. However, the path for session control for a given call and media control for that call is different. As shown in Figure 9, the media portion terminates directly on the IP telephony board utilizing a Real-Time Protocol (RTP) media packet type. The session


control packets are routed to the CIC server through the network interface card, or NIC, which is typically an Ethernet card. If a CIC server contains multiple IP telephony boards, all session control is routed via the NIC while RTP-based media sessions may be terminating on different IP telephony boards.

As stated previously, the reason for using IP telephony boards is to provide the media processing capabilities required by many voice-oriented applications. Being able to perform voice processing on the same server that’s running the entire voice application dramatically reduces the complexity of voice application development — especially if the application requires messaging, ACD, or IVR-style capabilities.

Figure 9 – Separate SIP session control and RTP audio paths of the Interaction Center Platform.

SIP Resource Differences in Enterprise and Contact Center Applications

When a SIP-based architecture is used in contact center environments, a contact center must have enough channels of Real-Time Protocol (RTP) available to handle the maximum number of calls connected to agents, and also the maximum number of calls on hold. Let’s consider, for example, a 200-agent contact center configured with standard carrier T1 connections and SIP station phones. If all agents are on connected calls simultaneously and 40 additional calls are on hold during peak times, 10 T1s would need to be provisioned in the server. Also, 200 RTP sessions would need to be provisioned in the server to handle agent calls. Conversely, if the server is connected to a SIP gateway instead of via T1s to the carrier, 440 RTP sessions need to be available on the server. This requirement stems from each active agent call requiring one RTP


session connecting to the station and one RTP session connecting to the SIP gateway; each call on hold additionally requires one RTP session.

When SIP is used in enterprise scenarios with CIC, the Enterprise Interaction Center (EIC) or Communité as the product, it is important to note that a given IP telephony board may handle a greater number of SIP stations than there are RTP sessions provisioned in a given server. This is due to the logical connection architecture of IP telephony. For example, if a 200-person organization is realistically only going to have 48 people on phone calls at a given time during peak times, only enough RTP sessions need to be provisioned on the server to process 50 simultaneous calls. If the server is configured with standard carrier T1 connections, a 60 session IP telephony board in the server will be able to handle station calls. Or if the server is connected to a SIP gateway, 100 RTP sessions need to be available on the server — one connecting to the station and one connecting to the SIP gateway.

Multi-site Applications of IP Telephony The possibilities are limitless for multi-site configurations using IP telephony and the Interaction Center Platform. As discussed earlier in this paper, circuit-based models require physical wiring between the switch, trunk lines and stations. As a result, multi-site configurations end up being engineered based mainly on fixed call routing rules. With IP telephony, however, lines and—more importantly, stations—can be placed logically in the network wherever they make the most sense.

Multi-Site Using SIP These benefits apply to various IP telephony configurations, including those that provide a SIP-based IP telephony architecture (see Figure 10). Multi-site configurations using local SIP gateways and distributed proxy servers can effectively distribute communications from a single server to multiple locations.


Figure 10 – Interaction Center Platform supporting multiple locations via a WAN.

Multi-Site Using Cisco CallManager As would be expected, multi-site configurations are also possible using the Cisco AVVID architecture (see Figure 11). By placing Cisco IP phones throughout a managed IP network connected to a common Cisco CallManager cluster, multiple locations can be connected to the same CIC server. Gateways at various locations can be utilized as well to provide inbound call switching and outbound call placement as needed — while still utilizing the call processing capabilities of CIC for IVR, ACD, screen pop, etc.

When implementing IP telephony across a wide area network (WAN), the available bandwidth, network latency, and quality of service must be considered. Once an approach is determined, however, the benefits of virtual agents throughout the organization can be quite compelling.


Figure 11 – Multi-site configuration using the Cisco AVVID architecture.

SIP Line and Station Configuration One of the most powerful capabilities of the Interaction Center Platform technology is having a common set of administration tools to configure various system resources. Using the Interaction Administrator® graphical interface inherent to the Interaction Center Platform and CIC, organizations can configure and manage lines, stations, users, workgroups, etc. in a consistent manner enterprise-wide. Managing SIP resources is no different. Configuring SIP stations and SIP lines is easy using Interaction Administrator’s line station configuration options!

SIP station configuration (see Figure 12) essentially identifies a SIP-compatible device — a SIP hard-phone or SIP softphone client — as a device that is addressable from the CIC server. Once a SIP station is created, it is also identified as being reachable based on a SIP address, such as [email protected]. Identifying a SIP station is likewise the first step in eventually being able to reach a given SIP-compliant device.


Figure 12 – SIP station configuration.

The next step is to configure SIP lines (see Figures 13 through 16). These are the Real-Time Protocol (RTP) sessions used to connect calls. SIP lines are identified by a phone number, a domain name used to reach this line as a suffix to a SIP address, IP parameters to determine various communication and packet retry parameters, and the maximum number of calls that can be made using this SIP line (Figure 13). A given SIP line can be used to place and/or receive multiple calls by establishing RTP sessions up to the number defined under the Maximum Number of Calls Inbound and Outbound fields.


Figure 13 – SIP line configuration, line parameters.

Once the SIP Configuration tab is complete, the acceptable compression and decompression methods, or codecs, are selected (Figure 14). A given IP telephony board will support various codecs, which in turn determine how much bandwidth on the IP network each call will take. Because various networks have different architectures, various codecs should be tested to determine the best combination for a given network.

Figure 14 – SIP codec selection to determine available audio compression/decompression rates.


For a given SIP line, it’s important to identify whether or not a proxy server will be used to resolve SIP addresses that are not directly reachable from the CIC server (see Figure 15). Multiple proxy servers can be identified to guarantee that routing will take place.

Figure 15 – SIP line configuration, identify proxy servers for SIP routing.

The final SIP line configuration step is determining the information about which telephony numbers are to be established for the SIP line when external calls are attempted within the extended SIP-routable network (see Figure 16). The IP address of the SIP registrar server or servers is identified on the Registrar page. Phone numbers to be registered for this SIP line also are entered. The CIC server then forwards these phone numbers to the selected registrar server, enabling external parties to call them to be connected to the CIC server. The registrar server makes these phone numbers visible in available SIP location directories, allowing parties placing phone calls to these numbers to be properly routed to specific servers based on DNIS-style services, or even routed to specific users via DID-style number identification and routing.


Figure 16 – SIP line configuration, register standard phone numbers for the specified SIP line.

IP Telephony Impact on Scalability and Reliability Utilizing IP telephony can handsomely improve scalability and reliability. Since physical tie lines no longer are required to link communications systems together, networking communications systems becomes easier and eliminates the “spider web” of communications links previously needed to implement highly scalable/fault-tolerant configurations.

Figure 17 represents how multiple CIC servers can be interlinked using the Interaction Director® application from Interactive Intelligence as the “traffic cop.” Interaction Director keeps track of key workgroup statistics in real-time, and also knows what servers are available to service interactions handled by Enterprise Groups. An Enterprise Group is a collection of server-specific workgroups established as a way to ensure that calls are handled according to pre-defined service level rules.


Figure 17 – SIP line configuration: Register standard phone numbers for the specified SIP line.

When a call is connected to a given CIC server, that CIC server will typically perform an IVR process on the call to profile the caller and their request. If agents associated with that server are available to service the call within a specified service level interval, the call is processed by agents associated with that server. (Note that while all stations phones are depicted as SIP stations in Figure 17, stations can be either analog or IP-based). However, if the target service level can’t be met locally, the CIC server offers the call to the Enterprise Group. Interaction Director then determines where the call should be sent, and uses either circuit-based point-to-point tie lines or SIP-based IP connections to route the call to the target CIC server. As a result of this approach, organizations can configure up to 1,800 agents to handle these interactions, dramatically increasing the number of interactions processed.

Another significant technology for scaling beyond single server configuration is spanned workgroup support. On a given CIC server, a workgroup represents a group of users (typically agents) that may be formed to process a specific type of task, such as answering customer calls, e-mails, etc. Spanned workgroup support takes this single server workgroup concept to the next level by allowing workgroups on separate servers to be logically grouped together into a spanned workgroup. The result is that all universal queuing, reporting, and real-time monitoring capabilities of single-server workgroups are preserved in the spanned workgroup. Real-time workgroup summary information is also collected and displayed in CIC’s Interaction Client user interface. Additionally, since all interactions are logged in a common database, reports on spanned workgroup activities are easily generated.


Large Call Center Operations The combination of SIP station support and spanned workgroup capability dramatically increases the flexibility, scalability and reliability of various communication scenarios. One of the most compelling scenarios is in large call center environments (see Figure 18). By provisioning a given set of CIC servers with T1/E1 interfaces to the traditional PSTN, each server can receive calls for agents regardless of agent location or initial server association. Utilizing spanned workgroups, calls can be routed to agents based solely on agent availability and skills-based matching. Agents also are alerted as if they were locally attached to the server processing the call. Once a given call is connected, agents have full call control features such as Record, Conference, Request Supervisor Assistance, etc. After an agent disconnects from a given call, they are placed back into the spanned workgroup to receive the next call designated to that agent.

Figure 18 - CIC 3.0 N+1 clustered server architecture using SIP stations.

Supervisors also factor into spanned workgroups. As an identified supervisor for a given workgroup, supervisors are alerted when agents request assistance, can listen into agent calls, and can record one or multiple calls in the spanned workgroup simultaneously. Each of these monitoring activities also is logged and available for reporting.


Clustering, Scalability and Load Balancing A major advantage of combining more than one CIC server in a spanned workgroup is scalability. Utilizing pre-configured carrier routing rules, calls can be evenly distributed across multiple servers. This load balancing helps even out server processing demands as an organization needs to scale from 300 agents in a single server to many hundreds or thousands of agents across multiple servers.

In addition to scalability and load balancing, clustering multiple CIC servers also provides reliability. Utilizing an N+1 style architecture, universal queuing can not only scale beyond single server architectures, but can also rely on multiple servers for overall processing capacity. Yet another advantage of spanned workgroups is that they dynamically grow and shrink based on the number of available servers. As a result, providing one extra server will allow any server to fail without reducing overall system capacity. Agents therefore losing a connection to a given server are automatically reconnected to another available server utilizing IP telephony-based auto switchover functions.

Once N+1 clustering is achieved, another benefit is that a given server doesn’t necessarily need to process as many simultaneous calls as previously required with a single server call center architecture. In a single server requirement, scalability is primarily a function of a given server’s available slots to hold telephony-oriented boards, as well as that server’s ability to hold a given single board computer (SBC) and its associated memory. With N+1 clustering enabled as a result of SIP stations, a given server need not house hundreds of connections. In fact, with the availability of network appliances in rack-mount form factors from name brand vendors, utilizing two to four slots per server may be optimal for certain customer and operational environments.

Cisco AVVID Similar scalability and reliability improvements can also be achieved utilizing the Cisco AVVID architecture. The Cisco CallManager softswitch framework allows up to four Telephony Service Provider (TSP) connections to the same cluster of CallManager servers (see Figure 19). The result is that multiple CIC servers can connect to the CallManager cluster, with each providing a pre-defined number of call-processing connections known as CTI ports. This architecture also supports load balancing and N+1 style clustering of CIC servers for greater scalability and reliability.


Figure 19 - CIC 3.0 N+1 clustered server architecture using Cisco CallManager.

SIP Softswitch Architectures and the Interaction Center Platform Interactive Intelligence supports software-based IP telephony interfacing via Cisco’s AVVID architecture and hardware-based IP telephony using SIP-compliant IP telephony boards in a given server based in the Interaction Center Platform. Interactive Intelligence also expects future SIP-based IP telephony developments to enhance scalability and related options in a given server. In addition to the initial H.100-based SIP support for the Interaction Center Platform, Interactive Intelligence plans support for H.110 Compact-PCI based IP telephony resources.

Additional SIP-based IP telephony options are also being developed to utilize the increasingly powerful processing capacities of Intel-compatible PC-based processors, without requiring IP telephony boards in a given server. Utilizing software-based audio mixing algorithms added to existing SIP session control features removes the requirement of having an IP telephony board in a server. This way, IP-based RTP sessions can be directly connected to a CIC server, and SIP gateways can be used as necessary to convert from circuit-based telephony to IP telephony (see Figure 20). While it is not currently known how many total ports these emerging architectures will scale to in a given server, combining multi-server based spanned workgroup functionality and software-based audio mixing will allow future multi-server clustered solutions to emerge as a scalable solution for a variety of organizations.


Figure 20 – Pure SIP softswitch architecture for the Interaction Center Platform.

Summary Overall, the main reasons why the Interaction Center Platform is the most flexible way to deploy IP telephony are:

• Full media control. Many communications-based applications rely on extensive media control in order to perform critical application functions such as:

• Play and record audio for IVR, ACD, auto attendant and unified messaging applications

• Multi-party conferencing used as a conference bridge or for addressing complex customer service scenarios

• Supervisor monitoring for ACD

• Call analysis/call progress detection for outbound predictive dialing/campaign management environments

• Voice recognition as an enhanced IVR, ACD or unified messaging capability

These functions are inherently supported in the same server architecture on the Interaction Center Platform. The result is a greatly simplified architecture for deploying IP-based communication and related application services. While IP-PBXs and softswitches have made it possible to run voice over IP and perform a number of call control and call management features, many IP-PBXs and softswitches are not capable of handling media processing on the same platform and require adjunct servers.


• Migration from traditional circuit-based telephony to various IP-based telephony architectures without redesigning applications. Applications built using the Interaction Center Platform run virtually unmodified regardless of whether the telephony service layer is circuit-based or IP-based. This allows organizations to migrate to IP telephony as they see fit while protecting their investment in applications.

• Interoperability with other communication services for full interaction management. The Interaction Center Platform has out-of-the-box interfaces to a variety of adjunct communication services such as e-mail, database, Web, and directory services that are in many cases already part of the installed IT infrastructure.

• Single points of administration, customization, reporting and desktop control. Regardless of whether circuit-based or IP-based, organizations use only common modules to manage system resources. Configure lines, stations, users, workgroups, dial plans, etc. using Interaction Administrator. Build interaction handling business rules using Interaction Designer. Route all voice, fax, e-mail and Web interactions and generate reports across all supported communications channels using a common desktop interface called Interaction Client. This dramatically reduces administration and training costs throughout the organization.

Whether an organization is a single location or has multiple branches, IP telephony is bound to offer benefits from more efficient moves, adds, and changes — along with centralized telecommunications routing configurations to distributed agents and virtual contact centers. Interactive Intelligence’s comprehensive circuit telephony and IP telephony support means that migrating to new architectures need not force application rewrites. As importantly, completely moving these applications to new locations and new architectures is supported, especially if an organization utilizes Cisco-based or SIP-oriented IP telephony today, or will consider other emerging voice technologies and architectures of the future.

Moreover, as IP telephony cost savings move from the carrier networks into the enterprise, businesses will need to move business routing and customer service applications to these new architectures. As already experienced with the adoption of PCs and LANs versus mainframe-style systems, IP telephony will gradually emerge as the predominant technology to communicate in the Internet Age.

Reality Check N+1 clustered architectures are now available for IVR and unified messaging configurations. Spanned workgroup queue support (available in Release 3.0 of the Interaction Center Platform) will allow N+1 configurations for ACD applications.

ip telephony and the interaction center platform · platform provides a number of methods to...

Documents