Contents

• IXC overview
• ICM software and IXC interaction
• Toll-free caller
• LEC-to-IXC
• Network query
• ICM NIC
• Unified ICM CallRouter process
• Best destination address returned
• IXC network
• Connecting call
• Supported carrier connections
• Fault tolerance to NICs
• Goal of NIC fault tolerance
• Link redundancy
• Route diversity

IXC overview

---

If pre-routing is to be performed, the Unified ICM Enterprise Edition software requires access to the IntereXchange Carrier intelligent call routing network. Each interexchange carrier offers intelligent network services that allow customer-premises equipment to participate in network-level call routing. The Unified ICM software connects to one or more networks by using a Cisco Network Interface Controller (NIC).

Specifically, this chapter helps you to complete the following tasks:

• Choose one or more carriers. Cisco supports network interfaces with several carriers. You can use one or more carriers with the Unified ICM software.
• Choose the types of network link fault tolerance to apply. It is important to apply fault tolerance in the network interface and the links to the carrier's intelligent network.
• Order intelligent network service. Once you review the requirements for your specific Cisco NIC, order intelligent network service and work with the carrier and Cisco to bring the service on line.

• ICM software and IXC interaction
• Fault tolerance to NICs

ICM software and IXC interaction

The Network Interface Controller (NIC) is the interface between the Unified ICM software and the IXC intelligent network. The NIC communicates with the IXC network by using network control links. These links are typically offered as part of the carrier's intelligent network service.

Cisco provides a NIC to interface with the specific carrier network. For example, if you have Sprint toll-free service, your Unified ICM system is equipped with a Cisco-supplied Sprint NIC. The Sprint NIC allows the Unified ICM to interface with the Sprint intelligent network service. If you use both AT&T and Sprint as carriers, your Unified ICM system is equipped with AT&T and Sprint NICs. The following figure shows the interaction between the IXC network and the Unified ICM NIC.

Figure 1. Network Interface Controller

For clarity, the NIC in the figure above is shown as a separate computer. Actually, NICs are implemented as software on the Unified ICM software platform (for example, on the CallRouter or Logger machines).

You can implement a Unified ICM Network Gateway for SS7 networks. The Unified ICM Network Gateway is implemented as a separate node on the Unified ICM signaling access network. When this node is implemented, you can install the NIC software on the CallRouter machine. For Sigtran SS7 networks, you can deploy a Sigtran Gateway on either the CallRouter machine or a separate machine; the NIC software is installed on the CallRouter machine.However, the INAP Sigtran gateway must be installed on a separate machine.

The specific flow of messages to and from the NIC within the Unified ICM software and the IXC network is shown by the circled numbers in the above diagram, and is explained in the following sections below.

• Toll-free caller
• LEC-to-IXC
• Network query
• ICM NIC
• Unified ICM CallRouter process
• Best destination address returned
• IXC network
• Connecting call
• Supported carrier connections

Toll-free caller

As shown in the preceding figure, the flow of messages between the network and the Unified ICM begins when a caller dials a toll-free number (1).

LEC-to-IXC

The Local Exchange Carrier (LEC) determines which interexchange carrier (IXC) is providing transport for that particular number and forwards the call to the IXC switch (2).

Network query

The IXC switch holds the call momentarily while it queries a network database to determine where to route the call (3).

ICM NIC

The network database forwards the query to the NIC and requests an intelligent routing decision (4).

Unified ICM CallRouter process

The NIC software process receives the request, translates it into a standard format, and forwards it to the Unified ICM CallRouter process (5)

Best destination address returned

The Unified ICM software selects the appropriate call routing script, assesses the skills and current real-time status of agents throughout the contact center network, and returns the best destination address back to the NIC (6).

IXC network

The NIC sends the destination address to the IXC network (7).

Connecting call

The network instructs the originating IXC switch to connect the call to the destination specified by the Unified ICM software (8). The total time taken by the carrier to connect the call varies. However, the additional time added by the Unified ICM software to process the route request is typically less than half a second.

Supported carrier connections

The following table summarizes the basic supported carrier connections and their corresponding Unified ICM software routing client (NIC) and network transport protocol. Note that the SS7IN NIC is used for a number of carrier SS7 INAP interfaces.

Table 1 Interexchange carrier connections

Routing Client	Connection to ICM
AT&T	AT&T Network (SS7 INAP Gateway or AT&T Sigtran)
CRSP	Call Routing Service Protocol (UDP)
CWC	Cable and Wireless Gateway (SS7 Gateway) Note    Not supported in Release 8.5(2) at release. Contact your Cisco/partner account represenatative for current support details.
GKTMP	Gatekeeper GKTMP interface (TCP/IP)
ICRP	Intelligent CallRouter Protocol (UDP)
INCRP	NAM/ICM Gateway Call Routing Protocol interface (UDP)
MCI	MCI Network (TCP/IP)
Nortel	Nortel Network (SS7 INAP Gateway)
NTL	NTL Network (TCP/IP)
Sprint	Sprint Network (X.25) Note    Not supported in Release 8.5(2) at release. Contact your Cisco/partner account represenatative for current support details.
SS7IN	Generic / Extensible SS7 INAP (SS7 INAP Gateway or ITU Sigtran)
Stentor	Stentor Adv Toll-free Gateway (HyperStream, TCP/IP) Note    Not supported in Release 8.5(2) at release. Contact your Cisco/partner account represenatative for current support details.
Unisource INAP	Unisource (SS7 INAP Gateway or INAP Sigtran) Note    Not supported in Release 8.5(2) at release. Contact your Cisco/partner account represenatative for current support details.
TIM	Generic (SS7 INAP Gateway or INAP Sigtran) Note    Not supported in Release 8.5(2) at release. Contact your Cisco/partner account represenatative for current support details.

Fault tolerance to NICs

You may already have a strategy for fault tolerance for some parts of the Unified ICM system. For example, you may have decided to use a duplexed, distributed Unified ICM central controller and duplexed PGs at each call center. It is just as important to apply fault tolerance to the NICs and intelligent network access links. Without a connection to the carrier's intelligent network, the Unified ICM system cannot perform pre-routing. If these links are lost, calls are typically routed according to the default routing plans set up in the carrier network.

Note	For more information on Unified ICM system fault tolerance, see the Administration Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted.

• Goal of NIC fault tolerance
• Link redundancy
• Route diversity

Goal of NIC fault tolerance

The goal in applying NIC fault tolerance is to add levels of protection that successively eliminate single points of failure.

Cisco requires an order of importance to follow when choosing the types of fault tolerance to apply in the carrier network-to-ICM system connection:

• First, use redundant links from the Cisco NIC to the carrier's intelligent network.
• Next, if you have redundant links, provision those links on diverse facilities. This adds another level of fault tolerance to your network connection.
• For NICs that run on the Unified ICM CallRouter platform, the NIC processes are duplexed when the CallRouter is duplexed. The types of NIC fault tolerance you apply have a bearing on the number of links you need to provision for IXC intelligent network access.

Link redundancy

Cisco requires that you configure redundant links to the IXC network. In other words, rather than having a single link from the NIC to the IXC intelligent network, provision two links. Having just one link to the IXC network represents a single point of failure (that is, an area or node in the system that, should it fail, can cause the system to stop routing calls).

By using redundant links, you increase the reliability of the IXC network connection and add an important level of fault tolerance to the system. The following figure shows a simplexed Unified ICM central controller and NIC with redundant links to the IXC network.

Figure 2. Redundant Links

In the preceding figure, single points of failure still exist because the NIC, CallRouter, and Logger are simplexed. The simplexed central controller and NIC configuration are shown here only as an example. This type of simplexed configuration is used only for non-critical systems that can tolerate potentially long interruptions in service (for example, in lab or demo systems).

The major IXCs support redundant links to their intelligent networks. Contact your carrier for more information on access link options.

Route diversity

For even more protection against network outages, Cisco requires that the network links are provisioned on diverse network facilities. By having diverse links, you further reduce the risk that another single point of failure (in this case, the failure of a circuit) could cause you to lose the connection to the IXC network. For example, you might provision one access link on one T1 circuit and provision the other access link on a different T1 circuit. By having diverse links, you protect against network failures in which an entire circuit is lost.

The following figure shows a simplexed Unified ICM system with redundant links and route diversity:

Figure 3. Redundant Links and Route Diversity

This example provides more fault tolerance by protecting against circuit failure or the loss of an IXC Point Of Presence (POP). Although the NIC is at one location, the redundant links connect to two different POPs. If one IXC POP is taken out of service (for example, in the event of a natural disaster), one link can still access the IXC network through the other POP.

The major carriers provide options for route diversity. Check with your carrier to discuss having the links handled by different POPs. You need to make sure that both the IXC and the Local Exchange Carrier (LEC) are using diverse circuits. Your LEC may impose some limitations on link diversity from the NIC to the IXC POP (that is, over the "last mile"). These limitations often depend on whether the call center is located in a metropolitan or rural area.