This document provides supplementary information to the System Manager
Guide that is specific to the Sprint Site Remote Processor (RP) and Enhanced
Site RP network interface.
For more information on document conventions, see the
Cisco Technical Tips
Readers of this document should be knowledgeable of the
The information in this document is based on the software and hardware
The information presented in this document was created from devices in
a specific lab environment. All of the devices used in this document started
with a cleared (default) configuration. If you are working in a live network,
ensure that you understand the potential impact of any command before using
The Sprint Intelligent Network Service Delivery facility allows
customer premise-based equipment to participate in the Sprint Network
N00-number (for example: 700, 800, 900) call routing. A set of Service Control
Points (SCPs) in the Sprint network provide the communications function between
the Sprint network and customer premises equipment (called External Routing
Processor, or “SiteRP”) involved in the call routing process.
The SCP is an end node responsible for processing N00-number call
inquiry requests received from telephone switches throughout the Sprint
network. The SiteRP node is an end node located at a customer site to which the
SCP redirects inquiry requests. Cisco ICM assumes the role of the SiteRP. The
SiteRP interface in the ICM system is implemented as a Microsoft Windows NT
process, known as the Sprint NIC, running on the ICM Central Controller. ICM
receives call inquiries from and returns inquiry responses to the Sprint
network through the Sprint NIC.
The SCP executes N00-number routing plans the customer, in conjunction
with Sprint, creates and maintains using the Sprint routing control
applications. The N00-number routing plans specify the forwarding of call
inquiry requests from the SCP to the SiteRP.
The Sprint network incorporates fault-tolerance for network nodes and
communications links. Currently, there are five geographically distributed SCPs
in the Sprint network. One of the five SCPs is a back-up, ready to assume the
load of any one of the four active SCPs, should an outage occur. Each SCP
shares the routing load in the network and has spare capacity to ride through
A SiteRP is typically connected to each of the five SCPs through a
Sprint-provided 56-kilobit Fibernet circuit. In the event of an SCP failure,
the back-up SCP picks up the load. In the event of a link failure between an
SCP and a SiteRP, Sprint Fibernet provides automatic re-routing of the data
links. Each SCP continues to communicate with the SiteRP through an alternate
path and no redistribution of load is required. The International
Telecommunication Union Telecommunication Standardization Sector (ITU-T) (1984)
standard X.25 link protocol is used to interconnect each SCP to each
The Sprint network architecture supports both link redundancy and node
redundancy. Redundant links from a SiteRP to the SCPs may be used. Redundant
SiteRPs are supported. Each of the redundant SiteRPs must be connected to each
Sprint SCP using at least one data link. All the SiteRPs in a redundant
configuration are used by the Sprint SCPs in a load sharing manner.
Figure 1 depicts the Sprint Network routing
Figure 1: Sprint Network Architecture
In Cisco ICM terminology, the Sprint NIC is a logical interface
controller that connects the ICM to the SCPs in the Sprint
For reliability, the Sprint NIC can be duplexed, for example, a pair of
computers is used to perform the job of a single Sprint NIC. Each computer is a
separate physical interface controller. Both computers
however, correspond to the same logical interface controller. The Sprint
network perceives this configuration as a single SiteRP with redundant links to
A single SiteRP corresponds to one logical interface controller and
either one or two physical interface controllers.
A routing client is an abstraction for any source of
routing requests processed by Cisco ICM. The Sprint NIC behaves as a routing
client on behalf of the Sprint network. In the Sprint network, a single SiteRP
(consisting of either one or two Sprint NICs) is regarded as one routing client
A label is an identifier associated with a particular
termination or branch within a N00-number routing tree. When an SCP sends a
route request to ICM, it expects to receive a reply message that contains a
select code. The label can specify one of several possible call termination
types or, alternatively, can specify continued execution under the current
The label types defined by ICM are a superset of the select code types
defined by Sprint SiteRP. The relationship between ICM labels and SiteRP select
codes is described below.
Note: Valid SiteRP select codes must contain only valid ASCII characters
and must not exceed 10 characters in length.
Cisco ICM destination label maps directly to a SiteRP,
select code of type "
Cisco ICM defines a special announcement label, @NPA Blocked
Recording, for the Sprint SiteRP interface. This special announcement
label maps to the SiteRP select code type, R with the reject
treatment code of 02. The SiteRP select code type,
R is used to reject a N00-number call. The reject treatment
code, 02 directs a N00-number call to a recording which
states, “The number you have dialed cannot be called from this
calling area.” All other ICM announcement labels map to SiteRP
select codes of type, T.
Cisco ICM defines a special busy label , @Slow Busy,
for the Sprint SiteRP interface. This special busy label maps to the SiteRP
select code type, R with the reject treatment code
01. The reject treatment code 01 directs an
N00-number call to the “network busy”
Cisco ICM ring label is not supported in the Sprint SiteRP
Cisco ICM post-query label maps to a SiteRP select code type
The ICM DNIS override label is not supported in the Sprint SiteRP
This section describes configuration requirements specific to Sprint
NIC. Configuration data created and maintained by you, is kept in the Cisco ICM
database. This data is managed using the Configure_ICR tool. Additional
configuration data created and maintained by Cisco is kept in the Microsoft
Windows NT registry on the ICM Central Controller, where Sprint NIC
This section describes the use of Configure_ICR to add Sprint NIC
specific configuration elements to the ICM database.
The following parameter settings are required for the Sprint
Network Interface Controller
There are no parameter settings required specific to the Sprint
The following parameter settings are required for the Sprint
Local configuration data for the Sprint NIC is kept in the Microsoft
Windows NT registry on the Cisco ICM Central Controller. The registry keys are
created during the ICM CallRouter Device Setup with the Sprint NIC option
selected. The configuration data specifies the parameters of the SiteRP network
interface as well as internal ICM parameters.
Prior to the release of ICM version 4.1, no changes were required
although the correct labeling of the SCP entries is helpful. Starting with the
release of ICM version 4.1, there is a new Windows NT Registry entry for each
SCP starting with “SCP1CardNumbers”. They specify which card each SCP port
resides. The individual bytes in the long word indicate the Eicon card numbers.
The high order byte contains the card number of the first port used by the SCP
while the low order byte contains the card number of the fourth port used by
the SCP. The default values assume that only one port is used by each SCP and
that the Eicon cards used by the SCP start with number one.
the first SCP has a single port residing on card number one while
the first SCP has three ports with the first and second ports residing on card
one while the third port resides on card two.
The Sprint network does not support the following Cisco ICM
There are five SCPs in the Sprint network. In a duplexed Cisco ICM
environment, each NIC connects to the Sprint network using five 56-kbps
point-to-point communication links, one to each SCP, provisioned on the Sprint
Fibernet network. The five communications links are five DS0 channels derived
from a dedicated T1.5 circuit. Two T1.5 circuits are provisioned on the Sprint
Fibernet network to connect the duplexed ICM to the five Sprint SCPs. The
Sprint Fibernet circuit terminating equipment for each side of a duplexed ICM
consists of a channel bank-like device called TP7. The terminating equipment is
provided by Sprint.
Each Sprint NIC contains three Eicon Technology Dual-Port Network
Adapter/PC (DPNA) cards. The two ports on a DPNA card are designated as port 1
and port 2, where port 1 is the port closest to the top edge of the card and
port 2 is the port closest to the PC connector edge of the card. Five of the
six DPNA ports are used to connect to the SCPs. The remaining DPNA port is not
used and is disabled. In a simplexed ICM configuration, five DPNA cards are
required if the Sprint NIC is connected to the SCPs through redundant
Cisco supplies five 9-foot cables, each of which connects from a DPNA
port to the Sprint circuit terminating equipment using a V.35 interface. The
cable has a male DB-26 connector to the DPNA card and a standard male 34-pin
V.35 connector to the Sprint circuit terminating device. The communication
links are routed to the SCPs in the Sprint network. The physical network
interface for the duplexed ICM configuration is shown in Figure 2.
Figure 2: Network Interface for Duplexed ICM
Cisco ICM may be deployed in either colocated or geographically
separated configurations. The physical connection to the Sprint network is the
same in both ICM configurations. As mentioned in Logical and Physical Interface Controllers, ICM (in
either configuration) is logically considered as one single SiteRP to the
Sprint network. In a colocated configuration, the ICM nodes are connected using
LAN. In a geographically separated configuration, the ICM nodes communicate
In a colocated configuration, ICM may be either simplexed or duplexed.
In either case, ICM connects to all the SCPs in the Sprint network through
redundant links. Ten dedicated point-to-point links connect ICM to the SCPs, as
shown in Figure 2. Redundant links from a
simplexed ICM to the SCPs are recommended. Simplexed links from a simplexed ICM
to the SCPs, although not recommended, are also supported.
In a geographically separated configuration, Cisco ICM connects to the
Sprint network SCPs using a total of ten physical connections (five from each
Central Controller site), as shown in Figure 2.
An SCP spreads the traffic to a SiteRP over the direct connect links.
Upon startup, the Sprint NIC calls the Eicon card administration
command ecmodule status to get a list of active
virtual circuits (if any), and it then hangs up those connections in an attempt
to flush out lingering SVCs from a previous run. Since the Eicon card setup
program does not set up a path to the command line utilities such as
ecmodule, this must be done manually.
The path environment variable already exists on Microsoft Windows
Select the path variable from the category of user
Move the cursor to the end of the text field.
Add it to the directory where Eicon card administration commands
To ensure the path is set correctly, run
ecmodule status x25
from a command
window, the output should look like Figure
Figure 3: Output of ecmodule status
The following Sprint SiteRP interface features are not supported by the
current implementation of the Sprint NIC:
EnhanCED SiteRP supports routing based on call context information
carried in the EnhanCED inquiry message, such as Caller Entered Digits (CED),
as well as all SiteRP routing features.
The Sprint NIC conveys call context information carried in inquiry
messages (both EnhanCED Inquiry and Inquiry) to the Router through peripheral
variables, with an exception that CED is accessed through a dedicated script
node. The Script Editor allows the user to examine the value of peripheral
variables and direct script execution to the desired branch. There are ten
peripheral variables defined, from
PeripheralVariable10. For convenience,
PeripheralVariableN is referred as
PV#N in the following sections.
The CED node is used in a routing script to differentiate various
values of Customer Entered Digits, see Figure 4
for an example.
Figure 4: CED Routing Script
The X25 label is populated into PV#1. The script “IF” node may be used
to check the value of PV#1. Figure 5 shows an
example of X25 label routing script. X25 label routing is not new with EnhanCED
SiteRP. The preceding supports SiteRP as well.
Figure 5: X25 Label Routing Script
II Digit and Feature Indicator exclusively exist. PV#2 represents II
Digit in the case an EnhanCED inquiry message is received and represents
Feature Indicator in the case an inquiry message is received. Since the formats
are different, you can differentiate one from the other in a routing script by
examining the value of PV#2.
An Object (excluding CED) is populated into a peripheral variable (PV#3
~ PV#10) in the format of “Type(2 characters) + Nature(2 characters) +
Content(≤ 35 characters) + \02
”, where the
plus sign does not really exist. For example, if an object has Type 03h (like
DNIS), Nature 02h and Digits “1111”, the corresponding peripheral variable is
encoded as “03021111\0”. Notice there is no fixed mapping between the object
and peripheral variable. For example, PV#3 might represent DNIS or SSN. Objects
can be identified according to the first four characters.
Figure 5 shows an example of routing based on
DNIS (Type: 03h, Nature: 02h) and SSN (Type: 0Bh, Nature: 02h). Label
“SELCOD02” is returned if the first three digits of DNIS are “111” and the
first three digits of SSN are “018”; label “SELCOD03” is returned if the first
three digits of DNIS are “111” and the first three digits of SSN are “019”; the
SelectCodeType “E” is returned otherwise.
The Sprint NIC accepts, at most, 35 characters as the content of an
object (see the following note for explanation). The excess is truncated, which
causes an unconditional tracing message to be generated.
Note: Since a peripheral variable has the length limit of 40 characters,
this format explains why the Sprint NIC accepts, at most, 35 characters as the
content of an object. While this does not generate the prefix of “Type +
Nature” for CED, the 35-character limit also applies to it for
The Sprint NIC is able to process at most eight objects excluding CED,
as shown in Figure 6, because there are ten
peripheral variables available, and PV#1 and PV#2 are used for X25 label and II
digit (or feature indicator) respectively. If an EnhanCED inquiry message
contains more than eight objects excluding CED, the Sprint NIC discards the
excess and generates an unconditional tracing message.
Figure 6: DNIS Object and SSN Object Routing