Carrier-Sensitive Routing User Guide
Overview of Cisco Carrier-Sensitive Routing

Table of Contents

Overview of Cisco Carrier Sensitive Routing

Overview of Cisco Carrier Sensitive Routing

The Cisco Carrier Sensitive Routing (CSR) application provides end users with the capability to manipulate the routing of calls from the gatekeeper based on the ingress carrier and the DNIS. The routing can be based on QoS along with many other attributes pertaining to a carrier. With CSR, you can provision data specific to carriers that pertain to your network to maximize cost, QoS, and carrier relations. CSR can run on a Sun/Solaris system that has a network connection to gatekeepers.

This chapter contains the following sections:

Prerequisites

  • Root access to a UNIX machine for the following tasks:

    • Create users

    • Modify Syslog.conf

    • Setting database security

  • Configured Cisco gatekeeper and gateway

  • Network that provides DNS capabilities

  • Knowledge of the following:

    • UNIX operating system and commands

    • SQL commands

    • TCP/IP network that the CSR is connected to

    • Sun computer system

CSR Components

The three major components of CSR are as follows.

  • postgreSQL Database

  • CSR application

  • CSR GUI

The CSR GUI and the CSR application are not directly connected. They are both connected to the database. Figure 1-1 illustrates these components.


Figure 1-1: CSR Components


CSR Basics

This section describes the basic operation of CSR.

After CSR is started, it registers with the gatekeeper connected to a network. Any one or a combination of the following registration messages are used:

The gatekeeper responds with any of the following messages:

CSR evaluates the predetermined selection and rejection criteria as part of the source carrier and DNIS information to determine what routing information to return to the gatekeeper.


Note   CSR can operate with multiple gatekeepers. CSR passes through the ANI, but its work is not based on the ANI. If the CSR receives the destination carrier, it passes the call through with the same information that it receives.

PostgreSQL Database

The postgreSQL database stores all the provisioned data associated with the CSR. The data can be entered into the database by using the GUI or by importing. The database supports active dataset, inactive dataset, and configuration data.

Information contained in the active and inactive datasets includes:

Configuration data contained in the database includes:

CSR Application

The CSR application contains the logic (selection and rejection) to determine the proper routing for calls based on inputs from the gatekeeper. CSR operates by the rules described in the following section.

Ingress Rejection Rules

Egress Rejection Rules

Selection Rules

CSR operates on an internal copy of the active dataset, which is loaded from the active dataset of the postgreSQL database. CSR can also operate without the postgreSQL database running as long as it has an active dataset. For more information on the active dataset, see the "Loading the Active Dataset" section.

CSR GUI

The CSR GUI provides an interface that can be used to enter, change, and modify provisioned data in the postgreSQL database. You can import data into the database with the import capabilities provided by postgreSQL. The CSR GUI can run on Sun/Solaris and Microsoft NT platforms.

CSR Limitations

  • When two rules are available (a rule associated with the carrier and a rule associated with a route), the rule associated with the carrier is chosen first. If one of the rules (carrier's rule) does not exist, the rule associated with a route is used.

  • When two contact lists are available (the contact list associated with the carrier and the contact list associated with the EgressRouteAttribute), the carrier's contact list is used first. If one of the contact lists (carrier's contact list) does not exist, then the contact list associated with the EgressRouteAttribute is used.

  • If a contact is provisioned with a DNS name and a DNS server is not found—that is, cannot get an IP address—the dataset verification fails and the CSR cannot be started correctly.

  • Static triggers are not supported by the CSR.

  • Performance may deteriorate if more than five gatekeepers are connected to the CSR. This is also related to hardware capabilities and call volume.