This document describes the configuration of Cisco IP Transfer Point
(ITP) on the Cisco PGW 2200 in a Call Control mode. The Cisco PGW 2200 can now
use MTP3 User Adaptation (M3UA) and SCCP User Adaption (SUA) to communicate
with Cisco ITPs.

The information in this document is based on the Cisco PGW 2200
Releases 9.4(1) and later.

The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.

Number codes [x] have been added to this PGW 2200
configuration to show corresponding sections within the ITP configuration (also denoted with number codes
[x]. The ITP details are added to the existing
configuration and the prov-sta::ssrcver="active''
command is used.

ISDN-user part (ISUP) and TUP routing keys are defined by the
Origination point code (OPC), DPC, and Service Indicator (SI) values. The
Origination point code (OPC) of the routing key is the point code of the
external PSTN switch. The DPC of the routing key is the point code of the node,
which is also the OPC of each Call Agent. The SI value indicates the user part.
Multiple routing keys can be assigned to the same autonomous system, but
multiple autonomous systems cannot use the same Routing Key. These routing keys
are provisioned via a CLI on the Signaling Gateway.

The SCCP routing keys will define by the SI and SSN. Each Call Agent
pair must use its own local SSNs for SCCP queries, so that the Signaling
Gateway can route the responses to the correct Call Agent. The SSN in the
Signaling Gateway routing key refers the local SSN of each Call Agent. Multiple
Call Agents can query the same remote SSN. These routing keys will be
provisioned via CLI on the Signaling Gateway.

Note: If multiple M3UAKEY or SUAKEYs are defined that are either disabled
on the Signaling Gateway or not configured on the Signaling Gateway, the Cisco
PGW 2200 sends an ASP ACTIVE or ASP INACTIVE message for each M3UAKEY and
SUAKEY that has not responded.

Since the Cisco PGW 2200 does not specify the Routing Contexts affected
in the ASP ACTIVE/INACTIVE message, only one ASP ACTIVE/INACTIVE message needs
to be sent. The M3UA and SUA I/O channel controllers (IOCCs) have been modified
to not call the routing_key_state call for each key when the key is added or
when the key's timer has expired. This causes the ASP ACTIVE or ASP INACTIVE
message to be sent once every five seconds for all outstanding ACKs.

The minor alarm M3UAKEY Ack Pending is
raised against the Signaling Gateway and the SS7PATH. It is raised against the
Signaling Gateway when there is at least one M3UA ASP ACK still pending from
that Signaling Gateway. It is raised against an SS7PATH when there is one ASP
ACK pending but there is one ASP ACK received.

The minor alarm SUAKEY Ack Pending is
raised against the Signaling Gateway and the SS7SUBSYS. It is raised against
the Signaling Gateway when there is at least one SUA ASP ACK still pending from
that Signaling Gateway. It is raised against an SS7SUBSYS when there is one ASP
ACK pending but there is one ASP ACK received.

The major alarm All M3UAKEY Ack
Pending is raised against an SS7PATH when no ASP ACKs have been
received for the M3UAKEY associated with the SS7PATH. The SS7PATH is out of
service (OOS).

The major alarm All SUAKEY Ack Pending
is raised against an SS7SUBSYS when no ASP ACKs have been received for the
SUAKEY associated with the SS7SUBSYS. The SS7SUBSYS is OOS.

When the IOCC receives an ASP INACTIVE ACK while on the active
platform, it also starts sending ASP ACTIVE messages until an ASP ACTIVE ACK is
received.

Note: In case you need to open a case with
Cisco Technical Support for any
help with this configuration, make sure you run an SS7 sniffer or snooper trace
in combination with a PGW 2200 MDL trace and attach it to the Technical Support
case. Do this in combination with debug cs7 m3ua or
debug cs7 sua command information plus a
show tech and
prov-exp:all:dirname="cisco1" information.