MSP Printer-Friendly Documentation

MSP 1010 – Multi-Services Platform
Release 10.2.2 Controlled Introduction
Printer-Friendly Documentation
This version of the MSP 1010 documentation is formatted specifically for printing. Cantata’s primary format for
documentation is web-based help and is available from the Cantata support site: www.cantata.com
Important Notice
Disclaimer
The contents of this document are subject to change without notice; therefore, the
information presented herein shall not be construed as a commitment or warranty.
Cantata Technology shall not be liable for any technical or editorial errors or omissions
contained herein or for incidental or consequential damages resulting from the
performance, furnishing, reliance on, or use of this material.
Patents
Certain equipment and software described in this document is protected by issued and
pending U.S. and foreign patents.
All products and services are trademarks or registered trademarks of their respective
manufacturer.
Copyright
This document contains confidential and proprietary information protected by copyright.
All rights reserved. Copying or other reproduction of all or parts of this document is
prohibited without the permission of Cantata.
Copyright 2006 by Cantata Technology
Table Of Contents
Cantata Technology Excel Product Line Warranty .................................................1
Changes From Previous Release .........................................................................4
Multi-Services Platform Overview .......................................................................5
ClientView ..................................................................................................... 16
EventView ................................................................................................... 168
AdminView .................................................................................................. 171
Hardware Guide ........................................................................................... 181
Intelligent Network & Wireless Protocols Overview ........................................... 210
SwitchKit Installation & Maintenance .............................................................. 223
SwitchKit Programmer's Information............................................................... 281
SwitchKit TCAP Interface............................................................................... 412
Developer Information .................................................................................. 549
PPL Developer's Guide .................................................................................. 947
Index........................................................................................................ 1235
iii
Cantata Technology Excel Product Line Warranty
Unless otherwise stated in an applicable product purchase agreement between the
Customer and Cantata Technology, Inc. ("Cantata"), Cantata warrants that during
the Warranty Period, products will operate in substantial conformance with Cantata's
standard published documentation accompanying the product. If a product does not
operate in accordance therewith during the Warranty Period, the Customer must
promptly notify Cantata. Cantata, at its option, will either repair or replace the
product without charge. The Customer has the right, as their exclusive remedy, to
return the product for a refund of purchase price or license fee if Cantata is unable to
repair or replace it.
Warranty Period
The period for which the warranty shall apply (the "Warranty Period") with respect to
Cantata's Excel-branded products or software shall be:
12 months for new hardware purchases;
90 days for software defects;
90 days for hardware repairs for products for which the original Warranty Period has
expired; and
30 day "out-of-box" failure expedited replacement for inoperative new hardware
The Warranty Period begins on the date of shipment of any products or software by
Cantata.
The Warranty Period for repaired, replaced or corrected products and software shall
be coterminous to the Warranty Provided for the original products or software
purchased.
To report warranty claims, Customer may contact Cantata via email at
techsupport@cantata.com or call (781) 433-6900.
Warranty Provisions
A. During the Warranty Period, Cantata warrants to Customer only that:
(i) Products manufactured by Cantata (including those manufactured for Cantata by
an original equipment manufacturer) will be free from defects in material and
workmanship and will substantially conform to specifications for such products;
(ii) software developed by Cantata will be free from defects which materially affect
performance in accordance with the specifications for such software. With respect to
products or software or partial assembly of products furnished by Cantata but not
manufactured by Cantata, Cantata hereby assigns to Customer, to the extent
permitted, the warranties given to Cantata by its vendors of such items.
B. If, under normal and proper use, a defect or non conformity appears in warranted
products or software during the applicable Warranty Period and Customer promptly
notifies Cantata in writing during the applicable warranty period of such defect or
non conformance, and follows Cantata's instructions regarding return of such
defective or non conforming Product or Software, then Cantata will, at no charge to
Customer, either:
(i) repair, replace or correct the same at its manufacturing or repair facility or
1
MSP
(ii) if Cantata determines that it is unable or impractical to repair, replace or correct
the product or software, provide a refund or credit not to exceed the original
purchase price or license fee.
C. No product or software will be accepted for repair or replacement without the
written authorization of and in accordance with instructions from Cantata. Removal
and reinstallation expenses as well as transportation expenses associated with
returning such product or software to Cantata shall be borne by Customer. Cantata
shall pay the costs of transportation of the repaired or replaced product or software
to the destination designated in the original Order. If Cantata determines that any
returned product or software is not defective, Customer shall pay Cantata's costs of
handling, inspecting, testing and transportation. In repairing or replacing any
product, part of product, or software medium under this warranty, Cantata may use
new, remanufactured, reconditioned, refurbished or functionally equivalent products,
parts or software media. Replaced products or parts shall become Cantata's
property.
D. Cantata makes no warranty with respect to defective conditions or non
conformities resulting from any of the following: Customer's modifications, misuse,
neglect, accident or abuse; improper wiring, repairing, splicing, alteration,
installation, storage or maintenance performed in a manner not in accordance with
Cantata's or its vendor's specifications, or operating instructions; failure of Customer
to apply Cantata's previously applicable modifications or corrections; or items not
manufactured by Cantata or purchased by Cantata pursuant to its procurement
specifications. Cantata makes no warranty with respect to products which have had
their serial numbers removed or altered; with respect to expendable items,
including, without limitation, fuses, light bulbs, motor brushes and the like; or with
respect to defects related to Customer's data base errors. Improper packaging of
product for repair will not be covered under this warranty agreement. No warranty is
made that software will run uninterrupted or error free.
E. Warranty does not include:
a) Cantata's assistance in diagnostic efforts;
b) access to Cantata's Technical Support web sites, databases or tools;
c) product integration testing;
d) on-site assistance; or
e) product documentation updates.
These services are available either during or after warranty at Cantata's published
prices.
F. THE FOREGOING WARRANTIES ARE EXCLUSIVE & ARE GRANTED IN LIEU OF ALL
OTHER EXPRESS & IMPLIED WARRANTIES (WHETHER WRITTEN, ORAL, STATUTORY
OR OTHERWISE), INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTY OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT.
CUSTOMER'S SOLE AND EXCLUSIVE REMEDY AND CANTATA SWITCHING'S SOLE
OBLIGATION HEREUNDER, SHALL BE TO REPAIR, REPLACE, CREDIT OR REFUND AS
SET FORTH ABOVE.
G. IN NO EVENT SHALL CANTATA, ITS DIRECTORS, OFFICERS, EMPLOYEES, AGENTS
OR AFFILIATES, BE LIABLE FOR ANY COSTS OR DAMAGES ARISING DIRECTLY OR
INDIRECTLY FROM YOUR USE OF ANY PRODUCT INCLUDING ANY INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, MULTIPLE, PUNITIVE OR CONSEQUENTIAL
2
Cantata Technology Excel Product Line Warranty
DAMAGES, INCLUDING LOST PROFITS, WHETHER BASED ON CONTRACT, TORT
(INCLUDING NEGLEGENCE), STRICT LIABILITY OR OTHER LEGAL THEORY, EVEN IF
CANTATA, OR ANY OF ITS DIRECTORS, OFFICERS, EMPLOYEES, AGENTS OR
AFFILIATES HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN ANY
EVENT, CANTATA'S CUMULATIVE LIABILITY TO YOU FOR ANY AND ALL CLAIMS
RELATING TO THE USE OF ANY PRODUCT SHALL NOT EXCEED THE TOTAL AMOUNT
OF THE PURCHASE PRICE OR LICENSE FEES PAID TO CANTATA FOR SUCH
PRODUCT.
H. CUSTOMER AND CANTATA HEREBY WAIVE THEIR RIGHT TO TRIAL BY JURY TO
THE FULLEST EXTENT PERMITTED BY LAW IN CONNECTION WITH ALL CLAIMS
ARISING OUT OF OR RELATED TO THIS WARRANTY, THE PRODUCTS COVERED
HEREBY OR THE PERFORMANCE OF ANY PARTY HEREUNDER.
I. THIS WARRANTY SHALL BE CONSTRUED UNDER AND GOVERNED BY THE LAWS OF
THE COMMONWEALTH OF MASSACHUSETTS WITHOUT GIVING EFFECT TO ANY
CHOICE OR CONFLICT OF LAW PROVISION OR RULE (WHETHER OF THE
COMMONWEALTH OF MASSACHUSETTS OR ANY OTHER JURISDICTION) THAT
WOULD CAUSE THE APPLICATION OF THE LAWS OF ANY JURISDICTION OTHER
THAN THE COMMONWEALTH OF MASSACHUSETTS. CUSTOMER SPECIFICALLY AND
IRREVOCABLY CONSENTS TO THE PERSONAL AND SUBJECT MATTER JURISDICTION
AND VENUE OF THE FEDERAL AND STATE COURTS OF THE COMMONWEALTH OF
MASSACHUSETTS AND SUCH COURTS SHALL HAVE EXCLUSIVE JURISDICTION WITH
RESPECT TO ALL MATTERS CONCERNING THIS WARRANTY OR THE ENFORCEMENT
OF ANY OF THE FOREGOING.
J. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY ALSO HAVE
OTHER RIGHTS WHICH VARY FROM JURISDICTION TO JURISDICTION.
3
Changes From Previous Release
This 10.2.2 Controlled Introduction includes the following new features. Click below
for an overview of each.
Sigtran or Message Transport Part Level 3 User Adaptation Layer (M3UA)
Virtual Circuit Identification Codes
TTC ISUP - Japanese Telecommunication Technology Committee (TTC) unified ISDN
User Part (ISUP)
SNMP Client
Increased Number of Multi-sockets: Four More
Voice Recording on High Impedance Span
Radvision SIP Stack (This links to part of the Radvision SIP documentation. For
more details contact your sales representative.)
This documentation set now includes a section on migrating Converged Services
Platform (CSP) applications to the MSP. For this information click here.
4
Multi-Services Platform Overview
Introduction to the Multi-Services Platform (MSP) 1010
The MSP 1010 (also referred to as the MSP) is a cost-effective, high-performance,
multi-functional platform. It is highly flexible, supporting TDM and IP interfaces as
well as fixed and mobile signaling protocols. The MSP 1010 is a high-density solution
with an unmatched price-performance ratio. The single-shelf (1u) form factor and
comprehensive graphical user interface make the MSP 1010 easy to install and
maintain.
The MSP simultaneously supports signaling and bearer traffic over circuit and packetswitched networks.
Applications
This telecommunications-grade platform allows the user to develop different
signaling applications in a wireless or wireline environment.
The MSP 1010 supports applications including:

Short Message Service (SMS)

Intelligent Network (IN) applications


Location based services
Interactive Voice Recognition (IVR) application
Supported Protocols
SS7 Protocols
The MSP 1010 supports the ITU and ANSI versions of the following SS7 protocols:

Message Transfer Part 2 and 3 (MTP2/MTP3) - China and Japan

Transaction Capabilities Application Part (TCAP)


Signaling Connection Control Part (SCCP) - China and Japan
Integrated Services Digital Network User Parts (ISUP) including the following
variants:

ANSI 97, ANSI 95, ANSI 92

ETSI V1, ETSI V2, ETSI V3


ITU 97, ITU 93, CCITT 88
China
IN Protocols
The MSP 1010 supports the following IN protocols on the host:

Customized Applications for Mobile Network Enhanced Logic (CAMEL) - ITU

Intelligent Network Application Protocol (INAP) mostly for wireline networks ITU

Wireless Intelligent Network (WIN) for ANSI Wireless Networks - ANSI
5
MSP
Wireless Protocols
The MSP 1010 supports the following wireless protocols on the host:


Mobile Application Part for Global System for Mobile communication (GSMMAP) - ITU
Mobile Application Part for ANSI networks (ANSI-41) - ANSI
These protocols were developed by IntelliNet Technologies, and allow the MSP 1010
to access IN and wireless networks.
Physical Interfaces

64 SS7 links

24 E1/J1








32 T1
1 DS3
4 10/100 Mb/s Ethernet
2 10/100/1000 Mb/s Ethernet
2 External clocking
2 USB Ports
RS-232 for debug
1+1 Redundancy Connection
IP Interfaces

2 Fast Ethernet for Gate Control EMS

2 GIG-E for IP Bearer Traffic

2 Fast Ethernet for VoIP Signaling
VoIP
The MSP supports two VoIP modules, each supporting the following features:

384 VoIP resources

G3 Fax Relay that is compliant with the T.38 ASN.1 standard.





6
Codecs: G.711, G.723.1, G.729/A/B, G.726, G.728, iLBC, FR/EFR, AMR, EVRC
Voice/Fax/Data: Automatic Switching
Fax Support: Group 3 2.4 – 14.4 kbps, T.38 compliant fax relay or automatic
switch to PCM
Modem Support: Up to V.92 rates
Echo Cancellation: G.168-2000 Compliant; Maximum tail length of 128
milliseconds.
Multi-Services Platform Overview

Ping and Trace Route Capabilities
If the MSP has two VoIP modules in it, the software will automatically distribute all
the licenses evenly across the two modules. This process is done in groups of 32
channels, so if there is an odd number of blocks, module 0 will have the extra
channels.
Hardware Overview
The MSP 1010 is a high-density single-shelf (1u) signaling server that can support
TDM interfaces and mobile signaling protocols in this release.
The 1010 supports Central Office locations where -48 V DC power is used or in the
enterprise market where AC is the only power source option
Physically, the 1010 consists of two parts:


docking station
field-replaceable tray (includes main board)
The tray and docking station mate together to form a single unit. This unit can either
be mounted in a 19-inch rack or set on a secure, level surface.
Refer to the MSP 1010 Platform Hardware Product OverView for more information.
SS7 Capacity
The MSP 1010 provides the following SS7 capacity:










64 SS7 links in a stand-alone configuration and 128 SS7 links in a redundant
configuration
128 link sets for redundant configuration
512 route sets
Four SS7 stacks
128 Destinations per stack
100,000 Global Title Translation entries
32,000 concurrent TCAP dialogs per stack shared by all configured stacks
(maximum is 4)
4 spans for SS7 signaling
32 nodes
672 channels per node
SS7 Monitoring
The MSP 1010 has the ability to monitor SS7 links. It allows you to set up monitoring
links on a host to receive SS7 traffic. In doing this, Message Signal Units (MSUs) are
sent directly to the host with no intervention by an operator or intrusion into
communications. The signaling data that is received by the MSP 1010 is intercepted
and interpreted automatically and in real time. Since there is no transmission
7
MSP
allowed on the monitoring links, these links do not interfere with the "live" SS7 links
— the links that are being monitored. The SS7 monitoring software module is
capable of monitoring E1 and T1. The SS7 monitoring module supports ITU, ANSI,
China MTP and Japan MTP. The SS7 monitoring module and the high impedance
spans co-exist with low impedance spans without any interference — monitoring
links co-exist with duplex SS7 links.
Licensing
SS7 Monitoring Links are licensed in increments of 16 links up to 64. This license is
available to enable the monitoring feature only if the MSP 1010 includes the base
SS7 protocol license.
See Introduction to SS7 Monitoring.
DS3 Technology
A DS3 has a bandwidth of 44.736 Mbps, which is the capacity of 28 T1 spans. Every
85th bit in a DS3 bit sequence is used for overhead functions such as frame
alignment, error detection, and terminal-to-terminal data communication. All other
bits are payload bits.
The DS3 signal format typically transports 672 channels at 64 Kbps per channel. The
DS3 signaling interface is bipolar with Bit 3 Zero Substitution (B3ZS).
DS3 in the MSP




The MSP supports loop timing for DS1's residing on the DS3.
The DS3 uses the M-Frame format and supports the following framing modes:


M13
C-bit (default)
Use the DS3 AIB (0x32) for configuring with the Excel API
The MSP supports the following type of loopbacks diagnostics:


local loop back
request a remote loop back from the far-end switch
You can query the MSP to determine if a local or remote loop back is
enabled/disabled. Refer to DS3 Loopback Diagnostics.
DSP Media Module
Cantata’s DSP Media module is a high-performance media processing resource that is
fully integrated into the developer’s MSP platform, providing a consistent and easyto-manage integrated telecommunications and media services environment.
The DSP Media module eliminates the need for separate voice response units (VRU)
by providing powerful media processing services and resources within the DSP
environment. This also reduces T1/E1 communications, saving service providers both
capital expense costs and on-going operating costs.
8
Multi-Services Platform Overview
The DSP Media module enables the MSP platform to operate as a service node or
intelligent peripheral. Configured with DSP media resources, the MSP can be
programmed to inter-operate with speech recognition and/or bulk storage to provide
a comprehensive media server solution. The MSP supports up to Network File System
(NFS) with on-board cache for voice file storage. You can have up to eight NFS
servers.
Benefits
The DSP Media module was designed to meet the demand for an integrated solution
for media-intensive services with the MSP architecture. Design criteria for media-rich
resources, streamlined development, cost reduction and operational ease of use
results in important benefits for developers, including:




Ability to offer Media-Rich Revenue Generating Services: the DSP Media
module offers a rich, programmable environment in which to create
innovative services.
Faster Time-to-Market: since media processing is integrated into the MSP
platform, there is no need to develop interfaces between external VRU
systems and the service platform.
Reduced Costs: since media resources are built-in, costs for external VRU
systems, plus the cost of T1/E1 service are eliminated
Ability to provide a single, integrated solution offering.
VoIP
The VoIP module in the MSP performs two-way conversion between circuit-switched
data and packet-switched data. This conversion is required by packetized voice
applications, such as the Voice over Internet Protocol (VoIP). The module also
integrates media resources over IP technology.
Circuit-switched voice is converted to IP packets, using compression algorithms that
can increase capacity toward the IP network side. You can have parameters modified
for an individual call, often while the call is active, changing the quality of service, as
needed.
Related Topics
VoIP Overview
VoIP Module
Introduction to the NG API
The MSP uses a combination of existing EXS API messages and Next Generation
(NG) API messages.
This section provides a brief overview of NG API benefits. For more information open
the link on the Cantata website (http://excelsupport.cantata.com) for the web-based
documentation: MSP 1010 API Reference.
Portable
9
MSP
The NG API abstracts the message from the MSP 1010 physical hardware by
addressing functionality. Backward compatibility is supported where necessary to
address existing functions.
Streamlined
The NG API design provides a more consistent and logical message structure. This
API design also means more simplified development for our application developer
customers.
Versatile
The NG API messages are generic so that they can be used and re-used for different,
but related, purposes. Because the messages are generic, it will be much easier for
Cantata to add functionality to them in a modular way, without having to create a
new special purpose message.
Logical
The NG API messages use new addressing methods with a consistent and logical
hierarchy. For example, in an Address Information Block, the message is guided
down through logical levels that become more specific as you go deeper into the
hierarchy. Because of this new design, application developers can re-use much of
their existing code, making changes only where the logic must branch.
Configurations
The MSP 1010 can function in the following configurations:


Stand Alone
Redundant
Stand alone
The following figure shows a typical stand-alone configuration.
MSP 1010 in Stand Alone Configuration
10
Multi-Services Platform Overview
Redundant
The following two diagrams depict two types of redundancy:


MSP 1010 Redundancy
Network Redundancy
MSP 1010 Redundancy
11
MSP
The MSP 1010 redundant configuration ensures that if an MSP 1010 fails, no
signaling traffic is lost. The MTP3 layer in each MSP 1010 receives all the MTP3 traffic
from both MSP 1010s, through the Ethernet connection, and only the master MSP
1010 controls the traffic.
Network Redundancy
12
Multi-Services Platform Overview
Network redundancy load shares the traffic between the two MSP 1010s. If one of
the MSP 1010 malfunctions,the second MSP 1010 handles the traffic.
Highlights of ClientView
ClientView is a graphical user interface that helps you with the administration and
configuration of your Multi-Services Platform (MSP). ClientView provides a simple,
data-driven environment that you can customize and extend at run-time without
recompiling. The communication between ClientView and the DataManager server is
based on XML messaging. ClientView provides context-sensitive Help for easy access
to information when using the tool. ClientView accompanies SwitchKit (see SwitchKit
Features and Components).
Features
ClientView is a real-time node configuration, maintenance, and administration
application. It also lets you monitor the current state of your system in real-time.
You can apply changes to the connected nodes with simple point-and-click
operations. Through ClientView, system developers avoid low level, code-intensive
channel and trunk group assignments and maintenance. Instead you can create and
13
MSP
maintain trunk groups through the interface. You can examine detailed alarms and
statistics without decoding log files.
The user guide describes ClientView interface and procedures that can be performed
and includes screen shots of the application’s configuration panes that graphically
show tasks that can be completed. In some cases, it may be necessary to consult the
API developer’s guides for more information on the various options available in the
fields shown in ClientView windows. ClientView user’s guide explains the
administrative steps you can perform using the application. It contains all the
information you need to get your ClientView started. It also outlines and
demonstrates all the features provided.
For more details see: An Overview of ClientView.
ClientView Functionality Defined
ClientView provides easy access to configure, monitor, and provision functionality on
the MSP. The functionality is defined as follows:
• Configuration
Ability to graphically configure an MSP 1010 from initial setup to channel
configuration.
• Monitoring
Real-time view of a MSP 1010 used to monitor hardware status, application status,
alarm status, and calls in progress.
• Provisioning
Allows real-time changes required to maintain optimal processing on the MSP 1010.
This includes bringing components in or out of service, busying out components, and
managing channel groups.
DataManager
ClientView was designed using a client-server software architecture. ClientView is the
client. DataManager is the database server.
DataManager does the following:




Manages the data model to a configured specification
Provides configuration and provisioning data to ClientView
Interfaces between ClientView and SwitchManager for configuration and
provisioning.
Generates log files: maintenance_datamanager.xxxx.log
It is required that DataManager be running for ClientView to function.
AdminManager
AdminManager is the server for the AdminView client, which is also a component of
SwitchKit. AdminManager manages access levels in AdminView. AdminManager
validates users and passwords created in AdminView and used by ClientView. If
AdminView is not running, the log-in to ClientView will fail.
See An Overview of AdminView.
Licensing
14
Multi-Services Platform Overview
The following are licensed components in the MSP 1010.

System Software per MSP (includes the four signaling spans)

Base SS7 MTP2/MTP3 License per MSP













Number of SS7 links
SS7 Monitoring
SCCP/TCAP licensed by transactions per second
ISUP licensed per CIC
Call Control licensed by channel manager license
DSP Resource Points
E1/T1 spans
SwitchKit
IN and Wireless protocol stacks
M3UA is a licensable feature
Voice Recording and Monitoring requires a Clear Channel license.
Virtual SS7 Channels (require a base SS7 license)
SIP
Refer to General Licensing Information for more information.
15
ClientView
Conventions Used in ClientView Documentation
ClientView presents the configuration of the MSP 1010 as an Element Management
System. All the elements are displayed as individual objects that are created in a
hierarchical structure as shown. (These are accessible from right-click menus on the
objects.):
Since ClientView allows you to configure your MSP 1010 based on a hierarchy of
objects, each object in this documentation has been described in an individual topic.
Each object's description explains how to access the configuration pane for that
object. For example, this is what you would see:
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP Name -> New Media ->
New Media Module -> New Media DSP
The objects described in the ClientView "book" are shown in Alphabetical List of
Configurable MSP 1010 Objects in the table of contents of the web-based
documentation.
16
ClientView
An Overview of ClientView
ClientView is a real-time Graphical User Interface that allows you to do the following,
depending on the Roles a user has been assigned:

Configuration

Monitoring

Provisioning
Ability to graphically configure an MSP 1010 from initial setup to channel
configuration. You can apply changes to the connected nodes with simple point-andclick operations.
Real-time view of an MSP 1010 to monitor hardware status, alarm status, and calls
in progress. You can examine detailed alarms and statistics without decoding log
files.
Allows real-time changes required to maintain optimal processing, including bringing
components in or out of service, busying out components, and managing channel
groups. You can avoid low level channel and trunk group assignments and
maintenance by creating and maintaining trunk groups through the interface.
Main Window
17
MSP
Panes
The following panes appear in the main window.

Configuration Tree (Top-Left)

Configuration Pane (Top-Right)
This pane contains all of the items that can be configured. You right-click an
item to access additional configuration items. Creating an entry in the
Configuration Tree opens the corresponding Configuration Pane (top right).
This pane shows the properties of the selected object. You use this pane to
view and edit your configuration.
The column entitled As Configured shows the current configuration when
connected to an MSP 1010. You enter or edit values in the User-Specified
column.

Status Pane (Lower-Right)
Object Table - an "at a glance" view of data related to that object
Object Status - status messages relating to that object
System Status - status messages relating to the entire system

Socket Log - used for debugging client/server messaging
Client/Server Monitor Pane (Lower-Left)
This pane shows the activity between ClientView and DataManager.
System Requirements for ClientView
18
ClientView
This section describes the recommended minimum system requirements supported
with this release of the Multi-Services Platform, ClientView. The ClientView works in
conjunction with SwitchKit. To find out more about the operating systems ClientView
is supported on, see SwitchKit Supported Operating Environments.
Windows Requirements
To run ClientView on Windows, a host machine with the following minimal
specifications is required:
• A minimum of Pentium IV, 1.3 GHz.
• Display resolution: 1024 x 768 pixels
• Free Disk Space: 2 GB
• Memory: 512 MB of RAM
Linux Requirements
To run ClientView on Linux, a host machine with the following minimal specifications
is required:
• A minimum of Pentium IV, 1.3 GHz.
• Display resolution: 1024 x 768 pixels
• Free Disk Space: 2 GB
• Memory: 512 MB of RAM
Solaris Requirements
To run ClientView on Solaris, a host machine with the following minimal
specifications is required:
• A minimum of Sparc, 360 MHz.
• Display resolution: 1024 x 768 pixels
• Free Disk Space: 2 GB
• Memory: 512 MB of RAM
Installation Process
SwitchKit software must be installed to support ClientView functionality on an MSP
1010. Please check the SwitchKit Supported Operating Environments before
installing ClientView.
Before You Begin
If there is a previous version of the ClientView already installed on your system,
remove that version. Cantata recommends that your versions of SwitchKit ClientView
and SwitchKit match.
Windows:
19
MSP
You can remove the program using the Control Panel utility or you can use the
Uninstall MSPUserInterface.exe file in your installation folder which by default is:
MSP Switchkit:
C:\Program
Files\Cantata\installs\MSPSwitchkit_<version>\Uninstall_MSPSwitchkit\
SwitchKit MSP User Interface:
C:\Program
Files\Cantata\installs\MSPUserInterface_version\MSPUserInterface\Uninstall_MSPUserInter
face
Version refers to the software release for the installation. For example:
C:\Program
Files\Cantata\installs\MSPUserInterface_10.2.1.91\MSPUserInterface\Uninstall_
MSPUserInterface
Linux and Solaris:
MSP SwitchKit:
/opt/cantata/installs/MSPSwitchkit_<version>/Uninstall_MSPSwitchkit/
SwitchKIt MSP User Inerface:
Use this command:
./Uninstall_MSPUserInterface
from:
/opt/cantata/installs/MSPUserInterface_<version>/MSPUserInterface/Unin
stall_MSPUserInterface/
Steps
Cantata recommends the following sequence of installations before installing
ClientView:
1. Download the system software to your MSP 1010. See Downloading System
Software to the MSP.
2. Install SwitchKit. See Installing SwitchKit on Windows. Or, see Installing SwitchKit
on UNIX.
Windows Defaults File
During the SwitchKit installation the Defaults file is created in the environment
variable, SK_LIB_DIR, which by default is located in C:\Program Files\Cantata
20
ClientView
\common. This file defines the directory for the proper running of SwitchKit
processes. Here is an example of the contents of the Defaults file:
UNIX Defaults File
During the SwitchKit installation the Defaults file is created in the environment
variable, SK_LIB_DIR, which by default is located in ./opt/canata/MSP/switchkit. This
file defines the directory for the proper running of SwitchKit processes. Here is an
example of the contents of the Defaults file:
Installing ClientView and EventView
On Windows
To install ClientView and/or EventView on a host running Windows, do the following.
1. Transfer the MSP user interface software file (MSPUserInterface.exe) to the host.
2. Go to the location where you stored the file and click the MSPUserInterface.exe
file. This will launch the InstallAnywhere installation wizard.
3. If you wish, accept the defaults as each screen appears.
On UNIX
To install ClientView and/or EventView on a host running Linux or Solaris do the
following.
1. Transfer the MSP user interface software file (MSPUserInterface.exe) to the host.
2. Enter the location where you stored the file and type the following:
./MSPUserInterface.bin
3. This will launch the InstallAnywhere installation wizard.
21
MSP
4. If you wish, accept the defaults as each option is presented. You will be given
the option to install both EventView and ClientView by selecting the appropriate
option.
Open ClientView
Before you start ClientView, the following SwitchKit components should be started in
this order:
1. LLC
2. SwitchManager
3. DataManager
4. AdminManager
1. To start the ClientView, use any one of the methods you specified in your
installation. For example, double-click the ClientView icon on your desktop, if
using Windows. If you are using Linux or Solaris, type:
./ClientView
2.
3.
Close the About ClientView window.
In the Client Socket window you must log in. Unless you have been
assigned a different user name and password, enter the following:
Username: admin
22
ClientView
Password: admin
4. Enter the Host Name or IP Address for the host where the SwitchKit
components are running: AdminManager, DataManager, LLC and
SwitchManager. If these SwitchKit components are running on the same host
as ClientView, use localhost. If the SwitchKit components are running on
different hosts, then use the IP address of the host where DataManager
resides.
5. Click OK
The ClientView opens.
You are now ready to begin configuration. See Creating a Configuration for the First
Time.
Opening Multiple Instances of ClientView
23
MSP
You can run multiple instances of ClientView. This feature allows more than one user
to connect to the SwitchKit controlling the MSP 1010.
Any instance of ClientView connects to the system by first registering with the
AdminManager, using a user ID and password. The AdminManager authenticates the
user and determines the scope of configuration privileges for that user. The three
levels of user privileges are

Monitor (view-only mode)

Configure (full-access mode)

Provision (limited-access mode)
Once authenticated by the AdminManager, ClientView connects to the DataManager.
Though multiple instances of ClientView can connect to the system, only one
instance can be running with configure privileges. At login, the AdminManager
determines whether there is already an instance of ClientView running with configure
privileges. If so, any new instance of ClientView that connects to the system is
granted either provision or monitor status, depending on the privileges defined for
that user. Only when the current user with configure privileges logs off the system,
can another user log in and be granted configure privileges.
A prerequisite to this is create additional users as required, with the different
levels of privileges.
See Assigning Users in AdminView.
Using Configuration Files
Creating a Configuration File
A default configuration called "default" is created when ClientView connects to
DataManager.
To save the configuration file with a new name:
1. Click Configuration default in the object configuration tree.
2. Enter a new name in the Filename field of the Configuration default pane.
3. Click File->Save Configuration File.
Opening a Saved File
To open this configuration going forward:
1. Select File - Open and Commit Configuration File.
2. Select the desired configuration file.
24
ClientView
See Also Upgrading ClientView.
MSP Licensing
ClientView displays your current MSP license information, if it has been installed.
Your license must be installed in the installation folder or directory.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Licensing Info
Default Location of License
Windows
C:\Program Files\Cantata\common\license
Linux, Solaris
/opt/cantata/common/license
If you have acquired a new license for additional functionality, click the Download
Node License button to download the license to the MSP 1010. The license with the
most recent timestamp will be downloaded.
The MSP license file name contains a unique serial number of the MSP 1010. The
format of the file includes the eight digit serial number followed by the timestamp:
NNNNNNNN_YYYYMMDDHHSS.cfg
If you rename or alter the license file in any way, it becomes unusable.
ClientView Pane
25
MSP
This pane verifies that the MSP 1010 license is valid. If there is no license, See
Verifying a license After Failure in ClientView.
Creating a Configuration for the First Time
The following is the first basic procedure towards configuring an MSP using
ClientView. Regardless of the object or feature being configured, this part is common
to all the configurations. The Configuration object facilitates the communication
between the node (MSP 1010) and SwitchKit and serves the purpose of configuring
the node and creating a configuration file. This is what is meant by the configuration
object in ClientView:
Use the User-Specified column for configuration and double click in the rows below
to enter data or edit existing data.
You cannot leave an object configuration pane until it has been successfully
configured. See ClientView Indicators.
Steps
1. Right-click Cantata MSP EMS in the left pane and from the drop-down menu
select New Node Group.
26
ClientView
2. Enter the Filename. A logical MSP is created after you move focus to the
next object.
3. In the left pane, right-click the Logical MSP... and from the drop-down menu
select New Node.
4. Enter the MSP Name.
5. Click in the cell for the IP Address of the MSP. You will be presented with
this dialog box:
After this IP address is committed, it cannot be edited. If you need to change the IP
address, you must delete the node object and create another one. Then, you can
enter a new IP address.
6. Click OK.
7. If you want to change the Resend Logic, select another option from the
drop-down list.
27
MSP
Downloading a License for Upgraded Capabilities
When you receive upgrades for your MSP (for example, additional SS7 links) you
must download the new license to the appropriate MSP 1010.
Steps
1. Ensure that the license file is in the correct folder on the host:
Windows
C:\Program Files\Cantata\common\license
Linux or Solaris
/opt/cantata/MSP/license
2. Right-click the Physical MSP and select MSP Licensing Info.
3. Right-click MSP License Info and select Commit.
4. The MSP Licensing Info ClientView pane appears. Click the Download
Node License button.
5. The license downloads to the MSP based on the serial number of the MSP.
Verifying a license After Failure in ClientView
If the license is not present, ClientView will display a broken lock icon beside the
physical node. When you right-click the physical node and select New Licensing
Info, no licenses will be shown.
To allow SwitchKit to find your license file, you must first do the following:
1. Ensure that the MSP 1010 license file has been installed in this folder:
Windows
28
ClientView
C:\Program Files\Cantata\common\license
Linux or Solaris
/opt/cantata/MSP/license
2. Reset the node. See Resetting a Node.
Configuration should proceed and succeed past licensing verification.
ClientView Indicators
The color of User-Specified fields, the progress indicator, alerts of mandatory fields
and different icons are intended to make ClientView a user-friendly interface. The
following describes these elements in more detail.
Configuration Fields
The following are the color indicators in Configuration pane fields under UserSpecified.

Blue

Green

Beige

Yellow
Indicates a field that can be edited by either entering a value or selecting an
option from a drop-down list.
Indicates a field that has been committed and is read-only (cannot be
changed).
Indicates a field that has been edited and not yet committed.
29
MSP
Indicates a field that is for informational purposes only and is not configurable.
Progress Indicator
The progress indicator window pops up between configuration of different objects.
The colors indicate the status of a commit attempt. When a certain object is being
configured on the MSP 1010, the user is blocked from adding new configuration.

Flashing Yellow/Orange

Gray

Red
When you send a configuration, the progress indicator flashes yellow/orange and
provides text on what process is occurring.
When the progress indicator is gray, the configuration was successful.
When the progress indicator is red, the configuration was unsuccessful. At this point
you must either fix the problem with the configuration or delete the object.
Mandatory fields
When you have not entered values for all of the mandatory fields of an object and
then try to select another object, a dialog box, <object name> Mandatory Fields
Empty opens. You can go back to the object by clicking Continue Editing Object or
you can select Delete Object and Children.
Icons in Left Pane
You will see the following list of icons in the left pane of the ClientView window.
Committed configuration which is still being processed by DataManager but has
not reached the MSP 1010 is shown with the cached icon. Only when the
configuration has reached the MSP 1010 does the icon change to configured.
30
ClientView
Here is what the icons indicate:
ClientView Menus
File
Edit
View
31
MSP
Communication
Tools
Help
- Open a configuration file. The configuration is automatically sent to the
MSP
- Save the configuration file you are working on
- Exit ClientView
32
ClientView
- Delete the object currently selected in the Configuration Tree
- Commit the object currently selected in the Configuration Tree
- Undo any changes made
- Opens all entries in the Configuration Tree
- Closes all entries in the Configuration Tree
- Opens all tree nodes under the selected object
- Opens only direct child nodes under the selected object
- Opens a Client Socket window showing messaging between ClientView and
DataManager
- When Auto-Commit is enabled, the entries you make in a pane are
automatically saved and downloaded to the MSP when click on another
entry in the Configuration Tree. Auto-Commit is enabled by default and
cannot be disabled by the user.
IMPORTANT NOTE: Under certain circumstances involving complex messaging
between ClientView and GCEMS, Auto-Commit may be disabled and changes
you make will not be automatically sent to the MSP. The fields in the
Configuration Pane will be orange when this condition exists and the box next
to the Auto-Commit selection will not be checked (as shown above). You should
re-enable Auto-Commit by selecting Auto-Commit from the Tools menu.
- Select Launch EventView to launch the EventView utility
- Properties: Configure various attributes of ClientView including, Number of
Hosts Retained in History, Auto-Launch EventView, Product Name and
Number of Usernames Retained in History.
- Validation Report: Use the Validation Report utility to confirm that your
configuration does not contain any errors that may cause improper
operation. In the left pane object tree right-click Cantata MSP EMS and
select Validation Report.
- Opens the Cantata website in a browser: www.cantata.com
- Provides information on Java Heap statistics, ClientView version, and
Environment Variables
- Opens the MSP 1010 web-based Help
- Opens the MSP 1010 API web-based Help
Options Available in Node Configuration
For information on navigating to an MSP 1010 node, see Physical MSP.
The buttons, Reset Node, Clear Software and Download Raw File are found in
the Excel MSP EMS object pane.
33
MSP
Validation Report
This generates a report about the node status.
Help
Access the information about the node object.
Reset Node
This button allows you to perform a reset on your node without losing configuration.
Clear Software
This button allows you to remove all configuration on a node.
Download Raw File
This button is used to send the file, rawapi.cfg. This file allows you to send API
messages that are not available through ClientView, such as, custom PPLs. You must
create this file or contact Excel technical support to get one. This file must be located
in the config directory before clicking the button. By default, the location would be:
Windows
C:\Program Files\Cantata\common\config
UNIX
/opt/cantata/MSP/switchkit/config
If the messages in the file have logical node IDs different from the node for which
the button is pressed, that logical node ID will be overwritten. You can use the same
rawapi.cfg file for multiple nodes without having to change the file. If a message in
the file is NACKed by the MSP 1010, the succeeding messages in the file will not be
sent.
Other options available specific to the node object are:
34
ClientView
Network Interfaces
Raw API Commands
Facility
Signaling
Media Object
Timing Synchronization Priority List
License Information
Telnet Client
Resetting an MSP 1010
Outlined below are the four methods for resetting an MSP 1010:
Configuration is not maintained on a reset of the MSP 1010.




Use the Reset Node button in the user interface. (This will not work if the
license has failed.)
Hold the two horizontal (left/right) arrows next to the LCD screen on the MSP
1010 for five seconds.
Hold the two vertical (up/down) arrows next to the LCD screen on the MSP for
five seconds.
Press On/Off Switch on the back of the MSP 1010.
Importing and Exporting a Signaling Variant
You can import or export a signaling variant based on ISUP. See Signaling Variant.
To import or export a signaling variant do the following:
For Importing
Cantata MSP EMS -> Signaling Variants -> Signaling Variant -> Import
Variant Entry File
Browse to the file you want to import and Open it.
35
MSP
For Exporting
Excel MSP EMS -> Signaling Variants -> Signaling Variant -> Export Variant
Entry File
Browse to the file you want to import and Open it.
Upgrading ClientView
When you upgrade to a newer version of ClientView, there may be some changes to
panes or fields that affect your existing configuration. If there are any such changes
detected, a report is generated and displayed in a Configuration File Conversion
Report, shown below. The report includes the following information for each change:



36
REFERENCE OBJECT - The ClientView object that has changed (for example,
Cantata MSP EMS).
DESCRIPTION - Identifies what has changed or is missing.
ACTION - Indicates how ClientView will handle the discrepancy.
ClientView
After reviewing the report, you will have the following options:

Do not configure or save
If the configuration file does not contain object properties that are
mandatory with default values, you only have the choice of Do not
configure or save.

Configure with changes but do not save

Configure and save with changes

Save with changes but do not configure
Once you select an option, the Configuration File Conversion window no longer
appears.
Report Files
Reports are saved in the following directory:
Program Files\Cantata\common\log\"filename_timestamp.html"
37
MSP
File Changes/Actions
Change
Action
Config file has a property
that ClientView does not
recognize.
Property ignored.
Config file has a property
value that is no longer
allowed by ClientView.
Property is set with the default
value. Possibly we will keep value
and just inform user.
Invalid XML attribute added
to Config file by user.
Added attribute will be ignored.
ClientView has a property
that the Config File does not
contain a value for.
Required XML
attribute/element removed
from Config file by user
Property renamed.
Config file has an object that
is no longer in ClientView
Property is set with the default
value.
No report generated.
Added element will be ignored and
reported in the log file
Attributes/elements are populated
with the default value.
Reports are generated.
Property is ignored.
Object and all children ignored
Object changed position in
the new ClientView hierarchy
Object ignored.
Object name has changed in
ClientView.
Should support the backward
compatibility. Changes will client
and sever side modification to
agreed upon Class names. No
report logged
Config file format changes to
remove another attribute or
element
Log generated.
It’s a mandatory attribute;
removed attribute will be set with
empty string.
Removed element will be set with
the default value in the definition
file.
Configuration File Missing Mandatory Value
In rare cases, an object may have a mandatory field added where there is no default
value populated. In this case you will not be able to open your existing configuration
file. The only option available is "Do not configure or save". Contact Technical
Support if you see this condition.
38
ClientView
Configure SS7 Stack for JT-ISUP
Do the following to configure the Japanese ISUP variant, JT-ISUP (TTC-ISUP), on the
MSP 1010 using ClientView.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP-> SS7 -> SS7 Stack
ClientView Pane
Steps
1. Right-click the SS7 object and select New SS7 Stack
2. Choose JTISUP for the ISUP option.
3. Commit the object
Removing JT-ISUP
Delete the SS7 Stack object.
Common Example Configurations
Example Configuration for DS3 Spans
To configure a range of DS3 spans, use the TDM DS3 Wizard in ClientView.
1. Right-click Facility and select New TDM DS3.
The TDM DS3 object is created with the pane titled as Bearer - DS3 ID:N.
2. Complete the fields as required. See the TDM DS3 pane reference for details.
3. Click the DS3 Wizard button at the bottom of the TDM DS3 pane. The DS3
Wizard pane appears.
39
MSP
4. Enter the Start Logical Span ID.
5. Enter the Starting Offset and the Span Count to identify the range of DS3
spans you are configuring.
6. Click NEXT. The DS3 Physical Span wizard pane opens.
40
ClientView
7. Complete the fields as required. See the DS3 Physical Span pane reference
for details.
8. Click NEXT to finish to finish this configuration.
Related Topic
Configuring a Single DS3 Span
Example Configuration for SS7 Voice Circuits
Use this procedure as an example of how to configure SS7 voice circuits using
ClientView. For more information see ISUP Introduction.
Before You Begin
You must have a T1 Physical Span or an E1 Physical Span Configured. The Signaling
Method should be set to Clear Channel. See E1 Physical Span or T1 Physical Span.
Configure SS7
41
MSP
To complete SS7 configuration you must configure the following objects in the
sequence shown:
1. SS7 object
2. Stack
3. LinkSet
4. Links
5. Route
Configure Routing for ISUP CICs
1. Establish the routing configuration object. See Routing Configuration.
2. Create a new channel group. See Channel Groups.
3. Configure ISUP circuit identification code (CIC) groups. See ISUP Group.
4. Configure the CICs. See Circuit Group.
Now ISUP is configured to route calls.
Example Configuration for SS7 Redundancy
Use this procedure as an example of how to configure SS7 redundancy using
ClientView.
To configure using the API, refer to Configuring Redundancy on the SS7.
Before You Begin
You must have a T1 Physical Span or an E1 Physical Span configured on both MSP
1010s. See T1 Physical Span or E1 Physical Span.
You must configure both the primary and secondary nodes within the same
node group.
Configure SS7
To complete SS7 configuration you must configure the following objects in the
sequence shown:
1. SS7 object. (From this topic, be sure to click the link to Procedure for
Redundant SS7 Objects.)
2. Stack
3. LinkSet
4. Links
5. Route
42
ClientView
Example Configuration for SS7 Monitoring
Use the following sequence to configure SS7 monitoring on your MSP 1010. For more
information, see Introduction to SS7 Monitoring.
1. Impedance
The Bearer spans assigned to the monitor links may be configured as either
high or low impedance facilities. This setting is configurable on a per-link basis
meaning high and low impedance facilities may co-exist, so long as both the Tx
and Rx side of any particular monitoring link have the same impedance setting.
The four Signaling/Timing spans may not be configured for high impedance.
2. Sockets
Up to five logical Socket IDs (1-5) may be mapped to TCP ports for routing
traffic to the monitor applications. Ports can range from 1-65534 with the
exception being port 12610 (0x3142), which is reserved for LLC/MSP
communication.
3. Monitoring Applications
To allow an application to monitor SS7 traffic on the MSP 1010, you must first
create a monitoring object. See Monitoring Object. Next, map an application to
a socket.
In order to receive SS7 monitoring traffic, MA(s) must be configured and
mapped to one or more logical Socket IDs. There can be multiple MA(s)
associated to the same socket.
4. Links
SS7 monitoring link(s) define the timeslot being monitored along with MTP link
characteristics.
You must first create a link configuration object. From this object you select
the links you want to monitor. See Monitoring a Link.
5. Filter Rules
The MSP 1010 provides a filtering module enabling the host to restrict the flow
of traffic to monitoring applications. Whenever possible, filters should be as
specific as possible. Following are four types of filters that can be applied to
the MSP, in any combination.
From the filter rules menu you must configure these objects:
Links
Service Indicator
Network Indicator
Point Code
43
MSP
Example Configuration for SS7 Monitoring
Use the following sequence to configure SS7 monitoring on your MSP 1010. For more
information, see Introduction to SS7 Monitoring.
1. Impedance
The Bearer spans assigned to the monitor links may be configured as either
high or low impedance facilities. This setting is configurable on a per-link basis
meaning high and low impedance facilities may co-exist, so long as both the Tx
and Rx side of any particular monitoring link have the same impedance setting.
The four Signaling/Timing spans may not be configured for high impedance.
2. Sockets
Up to five logical Socket IDs (1-5) may be mapped to TCP ports for routing
traffic to the monitor applications. Ports can range from 1-65534 with the
exception being port 12610 (0x3142), which is reserved for LLC/MSP
communication.
3. Monitoring Applications
To allow an application to monitor SS7 traffic on the MSP 1010, you must first
create a monitoring object. See Monitoring Object. Next, map an application to
a socket.
In order to receive SS7 monitoring traffic, MA(s) must be configured and
mapped to one or more logical Socket IDs. There can be multiple MA(s)
associated to the same socket.
4. Links
SS7 monitoring link(s) define the timeslot being monitored along with MTP link
characteristics.
You must first create a link configuration object. From this object you select
the links you want to monitor. See Monitoring a Link.
5. Filter Rules
The MSP 1010 provides a filtering module enabling the host to restrict the flow
of traffic to monitoring applications. Whenever possible, filters should be as
specific as possible. Following are four types of filters that can be applied to
the MSP, in any combination.
From the filter rules menu you must configure these objects:
Links
Service Indicator
Network Indicator
Point Code
Example Configuration for Virtual Circuit Identification Codes (CICs)
44
ClientView
Use this procedure as an example of how to configure virtual SS7 voice circuits using
ClientView. For more information, see Virtual Spans.
Before You Begin
Spans need to be configured based on ANSI or ITU setup. Configure a T1 Physical
Span for ANSI and E1 Physical Span for ITU.
For more information on configuring Physical spans go to: T1 Physical Span or E1
Physical Span.
Configuration Sequence
1.
Configure SS7
To complete SS7 configuration you must configure the following objects in the
sequence shown:
SS7 object
Stack
LinkSet
Links
Route
2. Configure a Virtual Facility.
3. Configure a Virtual Span.
4. Configure a Virtual Channel Group.
5. Configure ISUP configuration groups. See ISUP Group.
6. Configure the CICs. See Circuit Group.
Now ISUP is configured to route calls.
Example Configuration for SNMP
Use the following sequence to configure SNMP on your MSP 1010 using ClientView.
For more information, see Introduction to SNMP on the MSP 1010.
Steps
1. Compile MIBs. See Supported MIBs on the MSP 1010.
2. Configure SNMP Agent for all Physical MSPs. See Configuring an SNMP Agent.
For each MSP that you want to monitor, configure a different SNMP
Agent.
45
MSP
3. Configure an SNMP Manager. See Configuring an SNMP Manager.
Example Configuration for MTP3 User Adaptation Layer
Use the following sequence to configure SS7 monitoring on your MSP 1010 using
ClientView. For more information, see Message Transfer Part Level 3 User Adaptation
Layer (M3UA).
Step
Do This...
2
Right click the SS7 object and add an
MTP3 User Adaptation Layer object. This
also associates the corresponding SS7
stack and configures the protocol
parameter.
1
4
5
6
7
8
9
10
11
12
13
14
Configure the SS7 Stack to include the
M3UA module.
Add the network appearance of the SS7
stack using M3UA.
Add the Signaling Gateway Process
(SGP).
Add the Signaling Gateway (SG).
Add the Application Server Process
(ASP). You can add up to two ASPs.
Add the Application Server (AS). The
Object ID of the Application Server must
match the Stack ID. You can add up to
four ASPs; one per SS7 stack.
Add the AS-ASP.
Add the AS Routing Key.
Add the AS Routing Context.
Add the Route Sets.
Add the Route.
Add the Connection.
Example Configuration for Voice Recording
Use the following sequence to configure voice recording on high or low impedance
spans on your MSP 1010 using ClientView. If you want to use low impedance spans
46
ClientView
for recording, when configuring spans select 120 Ohm for the Impedance field. For
more information, see Voice Recording over a High Impedance Span: OverView.
E1 Configuration
1. Configure an E1 physical span object. For this procedure see: E1 Physical
Span. Ensure that the these settings are selected:
Field
Required Option
Coding
Method
Signalless
Signaling
Method
Impedance
Clear Channel
High Impedance
120 Ohm (Low
Impedance)
2. Create a Signalless Channel Group.
3. Create a Signalless Circuit Group.
T1 Configuration
1. Configure a T1 physical span object. For this procedure see: T1 Physical
Span. Ensure that the these settings are selected:
Field
Required Option
Framing
Signalless
Signaling
Method
Impedance
Clear Channel
High Impedance
120 Ohm (Low
Impedance)
2. Create a Signalless Channel Group.
3. Create a Signalless Circuit Group.
Example Configuration for Media Resources
47
MSP
You can change the settings for the digital signal processor (DSP) chips on the MSP
1010. The default settings for the DSP chips are: Universal Generators and Universal
Receivers.
If you want to access media resources from an external network interface, such as, a
Network File System (NFS) server, you must configure this before making changes to
the DSP chips. See NFS Servers.
Steps
Do the following to change the DSP settings on the MSP 1010 using ClientView:
1.
Create a Media object.
2. Configure a Media Module.
3. Configure a Media DSP.
If you want to change the configuration of these media resources, click on the links
for more details:
Conference Parameters
Echo Cancellation Parameters
PVD Answering Machine
T.30 Parameters
Example Configuration for SCCP/TCAP
Use the following sequence to configure SS7 SCCP/TCAP on your MSP 1010 using
ClientView. For more information, see Introduction to SCCP/TCAP.
1. Create the SCCP/TCAP object.
2. Before you can configure other options using the SCCP-TCAP object, you must
configure the Sub-System Number.
Now that the sub-system number is configured, you can configure these
options from the SCCP/TCAP object:


SCCP/TCAP Default Parameter Table
Global Title Translation
You can also configure these options from the sub-system number object:

Adjacent Translator

SSN Default Parameter



Other Concerned Point Codes
Network DPC and SSN
Replicated DPC and SSN
Example Configuration for VoIP Modules
Licensing
48
ClientView
If the MSP has two VoIP modules in it, the software will automatically spread all the
licenses evenly across the two modules. This process is done in groups of 32
channels, so if there is an odd number of blocks, module 0 will have the extra
channels.
Steps
Configure the following in the order shown using ClientView:
1. Network Interface for VoIP Modules
2. IP Bearer Profiles
3. Facility
For more details see the VoIP Module.
Related Topic
VoIP Overview
Example Configuration for ISDN
Use this procedure as an example of how to configure ISDN on your MSP 1010 using
ClientView. For more information see ISDN Introduction.
Use the following sequence:
1. Configure a T1 Physical Span or an E1 Physical Span.
2. Create a Signaling object.
3. Create an ISDN Channels object.
4. Configure an ISDN D channel.
5. Created the Routing Config object.
6. Create a new Channel Configuration Groups object.
7. Configure an ISDN channel group.
8. Configure the ISDN B channels (voice circuits).
Now, ISDN is configured to route calls.
Alphabetical List of Configurable MSP 1010 Objects
Adjacent Translator
By default, all adjacent translators are concerned point codes.
Accessing This Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New SS7 -> New SS7 Stack
-> New SCCP/TCAP -> New Sub-System Number -> Sub-System Number
49
MSP
-> New Adjacent Translator.
ClientView Pane
Steps
1. Right-click the Sub-System Number object.
2. Select New Adjacent Translator.
3. Select a point code from the drop-down list which is populated with the
already configured destinations in the Route() object.
Application Instance Routing
This is a container object for viewing a TCAP route.
Accessing this Pane
Cantata MSP EMS -> New Routing Configuration -> New Application
Instance Routing
BERT Test
Use this object to enable a Bit Error Rate Test (BERT) on a DS1 span or a DS3 span.
Accessing this Pane
Cantata MSP EMS -> Logical MSP-> Physical MSP-> Facility->Bearer->Bearer
DS3 Offset->New BERT Test
ClientView Pane
50
ClientView
Steps
1. Right-click the Bearer DS3 Offset, and select New BERT Test.
2. For the Test Mode, if you select a DS3 Test under User-Specified, the
following pane will appear with the default options populated for the
configurable fields.
For the Test Mode, if you select a DS1 Test under User-Specified, the following
pane will appear with the default options populated for the configurable fields.
51
MSP
Field Descriptions
Test Mode
Disable (Default)
DS1 Test
DS3 Test
DS1 Offset
Defaults in with DS1 offset.
Monitor/Generate
Monitor only (default)
Generate only
Monitor and Generate
Pattern
All Ones (Default)
Alternating 01
PRBS15
PRBS20
PRBS23
QRSS
User Defined
User Defined Pattern (0xnnnn)
If the pattern is user define, define the pattern in this field.
Test Pattern Framing
Framed DS1 test Pattern (Default)
Unframed DS1 Test Pattern
The following fields are not configurable:
Monitor Status
Out of synch
Out of Frame
Detecting AIS
52
ClientView
Bit Error Detected
Framing Error Detected
BPV Violation
Bits Received (Mbits)
This is the amount of bits received in megabits.
Errors Received
This is the amount of bit errors received
Elapsed Time
This is the length of the time the test has been enabled
Error Mode
This field is not configurable but there is a toggle button below this pane that is used
to enable or disable the error mode.
Circuit Group
This pane configures a circuit Identification codes (CICs) group for SS7 ISUP. See
Field Descriptions for more information. Follow the steps below.
Accessing this Pane
Cantata MSP EMS -> New Routing Config -> Routing Configuration -> New
Channel Configuration Groups -> New ISUP Config Group -> New Circuit
Group -> Circuits:Start CIC
1. Right-click the ISUP Config Group and select New Circuit Group.
From the next pane you can configure a range of Span/ Channels under a
circuit group. The spans entered here have been previously configured, and
the values selected are logical Span ID's. The Start CIC is the Base CIC
number and has to be matched with the CIC's configured on the other end.
53
MSP
6. Enter a Start CIC.
7. Right-click and select Commit. You will see the status of the circuits
displayed in the lower right pane similar to the following.
Field Descriptions
MSP Name
The name of the MSP on which the group resides.
Trunk Type
54
ClientView
Choices:
T1
E1
Start Channel
Number of the first channel in the group.
Start CIC
Number of the first CIC in the group.
CIC Count
The number of CICs in the group.
Button Description
UpdateStatus
Updates the status of CICs shown in the Status Pane
Conference Parameters
Use this object to change the conference parameters on a DSP chip.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Media -> New
Conference Parameters
ClientView Pane
55
MSP
Channel Configuration Groups
You create a new channel group by right-clicking on the Routing Configuration
object and selecting New Channel Configuration Groups. Now you can create a new
ISDN group, an ISUP configuration group or a signalless group.
Accessing this Pane
Cantata MSP EMS -> New Routing Configuration -> New Channel
Configuration Groups
ClientView Tree
DS3 Physical Span
Use this pane to configure a single DS3 span.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> Facility -> TDM DS3 ->
New DS3 Physical Span
Maximum Objects
28
56
ClientView
ClientView Pane
Steps
1. Right click the object Bearer - DS3 ID:N and select New DS3 Physical
Span.
2. Select the options you require for each field under User-Specified.
Field Descriptions
Logical Span ID
The range of values is 0-4095. It defaults to the lowest available span.
Offset
The physical span being configured.
Loop Timing Type
Specifies whether that specific span is used for primary loop timing, secondary loop
timing or not.
Primary
Secondary
Not Timing Source
Framing
Specifies whether the framing of the span.
57
MSP
ESF
D4
Signaling
Clear Channel
Line Length
Specifies the length of the T1 line
0-133 ft
134-166 ft
167-299 ft
300-533 ft
534-655 ft
G.703 ITU-T
Line Coding
Specifies the line coding of T1 span.
Bit 7 zero suppressing
B8ZS zero suppressing
Loopback Mode
No Loopback
Local Loopback
Remote Loopback
Span Status
This non-configurable field shows the status of the span using a combination of the
following information:
Receiving Red Alarm
Receiving Yellow Alarm
Receiving Loss of Signal
Receiving Out of Frame
58
ClientView
Sending Red Alarm
Sending Yellow Alarm
Receiving AIS
In Remote Loopback
DS1 Loopback Status
This non-configurable field shows the status of a span's loopback status.
No Loopback
Local Loopback
Remote Loopback
DS3 Physical Span Display Table
This table shows all of the DS3 spans configured.
DSP Alarm Threshold
Use this object to configure a DSP Alarm Threshold.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> MSP Name -> New Media -> New DSP
Alarm Thresholds -> New DSP Alarm Threshold
ClientView Pane
Field Descriptions
Alarm Number
Choices:
Number of Reads
Total Bytes Read
59
MSP
Average Read Delay
Maximum Read Delay
Number of Writes
Total Bytes Written
Average Write Delay
Maximum Write Delay
Maximum Simultaneous Files Opened
Average Simultaneous Files Opened
CPU Idle Time
VRA Process Delay
VRA IO Queue Delay
Severity
Choices:
Minor
Major
M Value (Hits in window)
Choices:
Minimum 1
Maximum 16
Default 3
N Value (Samples in window) (N >= M)
Choices:
Minimum 1
Maximum 16
Default 5
Threshold Value
If this is a time value, it is in microseconds.
60
ClientView
DSP Alarm Thresholds
Use this object to configure a DSP Alarm Threshold. To configure a DSP Alarm
Threshold, see DSP Alarm Threshold.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Media -> New DSP
Alarm Thresholds
E1 Physical Span
This object specifies the physical format of an E1 logical span. The user will be
allowed to configure an E1 span, if the MSP 1010 is configured for E1 via the host
flags.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> Facility -> TDM DS1 (of
type E1) -> E1 Physical Span
Maximum E1 Physical Span Objects
Only one E1 physical span is allowed per TDM DS1 object.
Technical Notes
When configuring a E1 Physical Span, an E1 logical span ID is configured for the TDM
DS1 offset, the logical span ID is based on the following formulas:
Bearer span IDs
Signaling span IDs
= (32*Logical_Node_ID) + Physical_Offset
= (32*Logical_Node_ID) + 28 + Physical_Offset
It also configures the format of the E1 span based on the parameters selected for the
E1 Physical Span offset.
ClientView Pane
61
MSP
Field Descriptions
Logical Span ID
The range of values is 0-4095. It defaults to the lowest available span.
Loop Timing Type
Specifies whether that specific span is used for primary loop timing, secondary loop
timing or not.
Choices:
Primary
Secondary
Not Timing Source
Coding Method
Specifies the line coding of that specific span:
Choices:
AMI
HDB3
Enable CRC4
Specifies whether CRC4 error checking is enabled or disabled:
Choices:
True
False
62
ClientView
Enable FEBE
Specifies whether FEBE is enabled or disabled:
Choices:
True
False
Line Length
Specifies whether the E1 interface is 75 Ohm. or 120 Ohm.
Choices:
G.703 ITU-T (75 ohm)
G.703 ITU-T (120 ohm)
Signaling Method
Choices:
CAS
Clear Channel
Signalless
Layer 1 Management
Choices:
E1 Layer 1 Mgmt
Euro-ISDN E1 Layer 1 Mgmt
Austel-ISDM E1 Layer 1 Mgmt
Transmit All Zeros
Specifies whether transmit all zeros is enabled or disabled.
Choices:
True
False
Span Status
This monitoring field indicates the current status of the E1 span.
Button Descriptions
In Service
63
MSP
This button brings the E1 span in service.
Out Of Service
This spans takes the E1 span out of service.
E1 Physical Span Display Table
This table is not applicable for this object.
Echo Cancel Parameters
Use this object to change the echo cancellation parameters on a DSP chip.
Accessing this Dialog Box
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Media -> New
Echo Cancellation
ClientViewPane
Cantata MSP EMS
This pane is informational only. You do not enter any values.
Accessing This Pane
Cantata MSP EMS -> New Node Group -> Logical MSP -> New Node ->
Physical MSP
Here is an explanation of the IP addresses you see in the Excel MSP EMS object
pane:
• IP Address 1 is the IP address set through the SwitchKit environment variable
SK_LLC_HOST.
• IP Address 2 is the IP address set through the SwitchKit environment variable
SK_RLLC_HOST. Port Number 1 and Port Number 2 default to 1312 unless
64
ClientView
specified otherwise through environment variable SK_LLC_PORT and
SK_RLLC_PORT, respectively.
ClientView Pane
Right-click Excel MSP EMS to configure any of the following:

New Node Group

New Signaling Variants


New Routing Config
New External Network Elements
External Network Elements
This object is used to create a Network File System (NFS) server. See NFS Servers.
Accessing this Pane
Cantata MSP EMS -> New External Network Element
Facility
This is a container object used to configure TDM or IP facilities. You can use the
Facility Wizard to configure a range of spans, or use individual panes for single
spans.
NOTE: You must commit the Facility object before you proceed with further
configuration.
65
MSP
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Facility
Single TDM Span
To configure a single TDM span:
1. Right-click Facility and select New TDM DS1.
2. Complete the fields in the TDM DS1 pane as required
See the TDM-DS1 pane reference.
3. Right-click the entry and select New T1 Physical Span or New E1 Physical
Span, as appropriate, and complete fields.
See T1 Physical Span pane reference or E1 Physical Span pane reference.
Range of TDM Spans
To configure a range of TDM spans:
1. Right-click Facility.
2. Click the Facility Wizard button.
3. The first pane that appears is the TDM DS1 Wizard Pane. Complete the
fields as required and click OK.
4. The next pane that appears depends on whether the span is E1 or T1. See the
T1 Physical Span pane reference or E1 Physical Span pane reference.
TDM DS1 Wizard Pane
TDM DS1 Wizard Field Descriptions
Trunk Type
66
ClientView
This field is automatically set to T1 or E1 depending on the type of MSP you have.
Component ID
This field specifies whether the TDM DS1 objects to be configured through the wizard
are part of the Signaling spans or the Bearer spans.
Choices:
Signaling
Bearer
Start Interface ID
This field specifies the starting interface to configure. Allowable values will be 0 to 3,
if the Component ID is set to ‘Signaling’ and will be 0 –27, if the Component ID is set
to ‘Bearer’.
Choices:
0–3
(If Component ID is set to Signaling)
0 – 27 (If Component ID is set to Bearer)
Span count
This field specifies how many offsets to be configured including the Start Interface.
Comments
Enter any comments you wish to add about this facility.
Filter Rules
Use this to filter messages that are sent to host SS7 monitoring applications. See
Filtering.
Rules are applied when you press the button, Save Rules Filter, while the
Filter Rules object is highlighted.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New Monitoring -> Monitoring -> New Filter Rules.
ClientView Pane
67
MSP
Filter Rules Menu
Global Title Entry
Accessing This Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New SS7 -> New SS7 Stack -> New SCCP/TCAP -> New Global
Title Translation -> Global Title Translation -> New Global Title Group ->
Global Title Group -> New Global Title Entries.
ClientView Pane
68
ClientView
Steps
1. Right-click the Global Title Group.
2. Select values for the properties that you want to change.
Global Title Group
Accessing This Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New SS7 -> New SS7 Stack -> New SCCP/TCAP -> New Global
Title Translation -> Global Title Translation -> New Global Title Group.
ClientView Pane
69
MSP
Steps
1. Right-click the Global Title Translation object and select New Global Title
Group.
2. Select values for the properties that you want to change.
Global Title Translation
This is a container object used to configure a new global title group.
Accessing This Pane
Cantata MSP EMS -> Logical MSP ->Physical MSP -> New Signaling ->
Signaling -> New SS7 -> New SS7 Stack
-> New SCCP/TCAP -> New Global Title Translation.
Steps
1. Right-click the SCCP/TCAP object.
2. Select New Global Title Translation.
Now you are ready to configure a global title group.
IP Bearer Profile
This object allows the user to define a set of VoIP parameter values such as Silence
Suppression, Echo Cancellation and RTP Redundancy. You cannot change an existing
IP Bearer Profile because it could be in use by a VoIP Module. You need to create a
new IP Bearer Profile rather than change an existing one.
Accessing this Pane
Cantata MSP EMS-> New IP Bearer Profiles-> New IP Bearer Profile
70
ClientView
Maximum Objects
A maximum of 16 IP Bearer Profiles can be defined.
Technical Notes
When configuring an IP Bearer Profile, the following happens:
A record is added for each profile that is created. When the desired number profiles
has been added, the user should then press the “Save Profiles” button in the IP
Bearer Profiles object. This causes DataManager to build and send a resource table
with all the records to each of the Logical MSPs.
ClientView Pane
This pane shows the default values under the User-Specified column.
Steps
Enter a name for the IP Bearer Profile. Select options in the fields that can be
modified. See the Field Descriptions below.
Field Descriptions
IP Bearer Profile Name
71
MSP
This value provides a name to the profile being defined. This value is subsequently
used in the Channel Group object to specify the IP Bearer Profile instance.
Payload Type
The following payload types are available:
G.711 alaw
G.711 ulaw
G.723 5.3 Kbps
G.723 6.3 Kbps
G.726 16 Kbps
G.726 24 Kbps
G.726 32 Kbps
G.726 40 Kbps
G.729
iLBC (internet Low Bitrate Codec) 20 ms
iLBC (internet Low Bitrate Codec) 30 ms
EVRC (Enhanced Variable Rate Codec)
GSM-AMR (Global System for Mobile - Adaptive Multi-Rate)
Preferred Payload Size (ms)
The payload size depends on the codec (payload type) selected.
Choices:
10
20
30
40
50
60
Dynamic Payload Type
Indicates the dynamic payload type number that the MSP will use for specifying the
RFC 2833 multi-unicast media stream to the peer endpoint.
Silence Suppression
During a normal voice conversation, much of the time is wasted on silence from one
or both ends. Bandwidth can be conserved if, during these periods of silence, RTP
packets are sent with silence-encoded, compressed payloads.
72
ClientView
The MSP Silence Suppression feature supports the concepts of Voice Activity
Detection (VAD) and Comfort Noise Generation (CNG). When enabled, Silence
suppression will
not send RTP traffic during periods of silence, saving bandwidth usage. Also, at the
beginning of a silence period, a single packet will be sent to the distant end to inform
it that a period of silence is being entered, and that the distant end should begin to
regenerate comfort noise to its TDM stream.
Choices:
Enable: Silence Suppression is used
Disable: Silence Suppression is not used
Echo Cancellation
This feature eliminates TDM-side echo introduced by impedance mismatched hybrids.
The echo canceller is G.168 compliant.
Choices:
Enable: Echo Cancellation is used
Disable: Echo Cancellation is not used
RTP Redundancy
This feature provides RTP packet redundancy to guard against network packet loss
(RFC 2198). This applies to RTP traffic in voice or fax/modem bypass calls.
Choices:
No Redundancy: RTP Redundancy is not used
Redundancy Level 1: RTP Redundancy at Level 1 is used.
RTP Payload Type for Redundancy
This numeric value (96-101, 104, 106-127) defines the packet type used for RTP
Redundancy. If RTP redundancy is disabled, the Payload Type should be set to Not
Used. In addition, values for Digit Relay Packet Type and RTP Payload Type for
Redundancy cannot be the same.
Fax Mode
This defines the mode of operation for Fax Calls.
Choices:
Enable Relay: The fax is delivered using T.38 packets.
Enable Bypass: The Fax Bypass codec is used while sending the fax. This
functionality is not supported for the AMR and EVRC codecs.
73
MSP
Fax Bypass Codec
This is the codec the user wishes to use when the Fax Mode is set to Enable Bypass
Choices:
G711 ulaw: 64 kbps North American
G711 alaw: 64 kbps ITU
Fax Packet Redundancy
This feature provides Fax packet redundancy to guard against network packet loss.
This is only applicable to Relay Fax Mode.
Choices:
No Redundancy: Fax Redundancy is not used
Redundancy Level 1: Original payload is duplicated one time
Redundancy Level 2: Original payload is duplicated two times
Redundancy Level 3: Original payload is duplicated three times
Digit Relay
This setting specifies the method to use to propagate DTMF digits.
Choices:
DTMF In-band: Digits are sent in the same packets as the voice
DTMF Packetized: Digits are sent in separate packet type (defined by RFC
2833) using payload type specified by the Digit Relay Packet Type
DTMF via H.245 UII (out-of-band, IP suppressed): Digits are propagated
using H.245 signaling. This option is not applicable for SIP signaling.
Digit Relay Packet Type
This numeric value (96-101, 104, 106-127) defines the packet type used for Digit
Relay.
Initial Inactivity Timer (10ms)
This timer defines the maximum amount of time the switch will initially wait for UDP
data before generating an event.
Media Inactivity Timer (10ms)
This timer defines the maximum amount of time the MSP will wait for subsequent
UDP data before generating an event.
Minimum Jitter Buffer Delay
74
ClientView
The range of legitimate values is 0-150 millisecond units.
Maximum Jitter Buffer Delay
The range of legitimate values is 150-300 millisecond units.
TOS: Precedence
Choices:
Routine
Priority
Immediate
Flash
Flash Override
CRITIC/ECP
Internetwork Control
Network Control
TOS: Delay
Choices:
Normal Delay
Normal Throughput
Normal Reliability
Normal Cost
TOS: Throughput
Choices:
Normal Throughput
High Throughput
TOS: Reliability
Choices:
Normal Reliability
High Reliability
TOS: Cost
75
MSP
Choices:
Normal Cost
Low Cost
IP Bearer Profile Display Table
This table lists the Supported Vocoders to be used by SIP or H.323 for codec
negotiation during call. The entries are listed in descending priority
IP Bearer Profiles
Use this object to configure an IP Bearer Profile. To configure an IP Bearer Profile,
see IP Bearer Profile.
Accessing this Pane
Cantata MSP EMS-> New IP Bearer Profiles
ISDN D Channels
The ISDN object is the high-level parent object for all ISDN configuration.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
ISDN
Congestion Threshold
Use this object to configure an ISDN D Channel congestion threshold.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> Signaling -> ISDN ->
ISDN D Channels -> New Congestion Threshold
ClientView Pane
76
ClientView
ISDN Circuits: B Channels
Use this object to configure ISDN B channels.
Accessing this Pane
Cantata MSP EMS ->New Routing Config-> New ISDN Group -> ISDN Circuit
Group
ClientView Pane
ISDN D Channel
Use this object to configure ISDN D channels. After the D channels are configured
you can create a new ISDN group, and then add spans and B channels.
Before You Begin
You must have bearer spans (TDM DS1 objects) previously configured in order for
the primary span and secondary span fields to be populated. See E1 Physical Span or
T1 Physical Span.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> Signaling-> ISDN D
Channel-> ISDN D Channel-> New ISDN D Channel
ClientView Pane for an E1 Span
77
MSP
ClientView Pane for an T1 Span
Field Descriptions
Primary Span
The span on which the primary D Channel is located.
Primary DChannel
The channel on which the primary D Channel is located.
NFAS Supported
This field is only available for T1 configuration.


78
Yes
No
ClientView
Secondary Span
This field is only available for T1 configuration.
Select Not Used if you are not configuring secondary spans. Otherwise, select a
span.
Secondary DChannel
This field is only available for T1 configuration.
Select Not Used if you are not configuring secondary channels. Otherwise, select a
channel.
Base Variant
The base ISDN variant options for E1 spans are:


Euro-ISDN 2 Network Side (default)
Euro-ISDN User Side
The base ISDN variant options for T1 spans are:

National-ISDN 2 Network Side (default)

ATT 4ESS Q.931 PRI




National-ISDN User Side
ATT 5ESS Q.931 PRI
Northern Tel DMS-100 Q.931 PRI
Northern Tel DMS-250 Q.931 PRI
HDLC Bit Polarity


Normal (default)
Inverted
Network Side Layer 2 Override


Network (default)
User
Location
79
MSP
The value populated in the Location parameter in the Cause information element
when a call is released.

User (0 - Message Generated by User) (default)

Local public network (2 - Message generated by public network serving the
local user)






Local Private Network (1 - Message generated by private network serving the
local user)
Transit network (3 - Message generated by transit network)
Remote public network (4 - Message generated by public network serving the
remote user)
Remote private network (5 - Message generated by private network serving
the remote user)
International network (7 - Message generated by international network)
Network Beyond Interworking Point (0A - Message generated by network
beyond inter-working point)
Display Table
This table shows all of the D Channels configured
D Channel Entity
Use this object to configure an ISDN D Channel entity.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> Signaling -> ISDN ->
ISDN D Channels -> New D Channel Entity
ClientView Pane
Field Descriptions
D Channel Physical Medium
64 kbps (T1/E1/J1)
80
ClientView
B Channel Selection Mode
Disabled
Linear Clockwise
Linear Counter Clockwise
Circular Clockwise
Circular Counter Clockwise
Layer 4 Channel Release Request on ISDN Disconnect
Do not send host Channel Release Request on ISDN Disconnect
Send host Channel Release Request on ISDN Disconnect.
Protocol Discriminator Value for Maintenance Messages
0x03
0x0A B Channel Encoding for Transmission
Channel Number
Slot Map
Fill Mask Functionality
Enter a range
ISDN Group
The is object is used to configure an ISDN group. Next, you can configure an ISDN
circuit.
Accessing this Pane
Cantata MSP EMS-> New Routing Config-> New Channel Configuration
Groups->New ISDN Group
ClientView Pane
81
MSP
Field Information
ISDN D Channel
Select a previously configured D channel.
Network Type
Do Not Include Network-Specific Facilities (NSF) IE
ATT Software Defined Network
ATT Megacom 800 Service
ATT Megacom
ATT Accunet
ATT Long Distance Service
ATT International 800
ATT Multiquest
Bearer Capabilities Allowed
Voice
3.1 KHz Audio
Unrestricted 56K
Unrestricted 64K
Restricted 64K
384K
7.1 KHz Audio
82
ClientView
Outgoing Information Transfer Capability
Voice (Default)
Modem(3.1 KHz audio)
56 KBPS
64KBPS
64KBPS Restricted
Ho (Information Transfer Rate 384 Kbps)
H11 (Information Transfer Rate 1536 Kbps)
Multi-rate
Calling Number Type
Unknown
International Number
National Number (Default)
Subscriber Number
Abbreviated Number
Calling Number Plan ID
Unknown
ISDN Numbering Plan/Recommendation E.164/E.163
Private Numbering Plan
Telephony Numbering Plan
Calling Screening Indicated
User provided, not screened (Default)
User provided, verified and passed
User provided, verified and failed
Network provided
Called Number Type
Unknown type of number
83
MSP
International Number
National Number (Default)
Subscriber Number
Abbreviated Number
Called Number Plan ID
Unknown numbering plan (Default)
ISDN Numbering Plan/Recommendation E.164/E.163
Private Numbering Plan
Telephony Numbering Plan
Request for Service Format
BCD Encoded
Formatted ICB
Exact Frame
Send ALERTING Request to L3P
Send
Do Not Send
Send DISCONNECT INDICATION to L5
Disable (Default)
Enable
Send ALERTING INDICATION to host
Disable (Default)
Enable
Send PROGRESS to host
Disable (Default)
84
ClientView
Enable
Send CONNECT to host
Disable (Default)
Enable
Send RELEASE (COMPLETE) to host
Disable (Default)
Enable
Send Call Proceeding event to host (on receipt of CALL PROCEEDING indication from
network)
Disable (Default)
Enable
Send Outseize ACK event to host (on receipt of CALL PROCEEDING indication from
network)
Disable (Default)
Enable
Overlap Receive mode
This field is not visible if the physical spans are T1.
Disable (Default)
Enable
Overlap Receive Supported Digit Length
This field is not visible if the physical spans are T1.
Select a value for the length.
Answer Supervisor Mode
0x00 Propagate Answer to Distant End (default)
85
MSP
0x01 Notify Host of Answer
0x02 Propagate Answer to Distant End and Notify Host of Answer
0x03 No Answer Supervision – No propagation of answer or notification
Local End Release Mode
0x01 Park Channel
0x02 Release Release (Default)
Distant End Release Mode
0x01 Park Channel
0x02 Release Release (Default)
PCM Encoding Format
Disable
0x01 µ-law encoded PCM (North America & Japan)
0x02 A-law encoded PCM (Europe)
ISDN Timers
Use this object to configure an ISDN D Channel timer.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> Signaling -> ISDN ->
ISDN D Channels -> New ISDN Timers
ClientView Pane
ISUP Group
This object allows you to create an ISUP group and set attributes for this group. You
must have previously configured an SS7 stack.
86
ClientView
Accessing this Pane
Cantata MSP EMS -> New Routing Config -> Routing Configuration -> New
Channel Configuration Groups -> New ISUP Config Group
ClientView Pane
See steps below.
Steps
1. Right-click Cantata MSP EMS and select New Routing Config. A Routing
Configuration object is created.
2. Right-click the Routing Configuration object and select New Channel
Configuration Groups. A New Channel Configuration Groups object is
created.
3. Right-click the New Channel Configuration Groups object and select New
ISUP Config Group. The following is displayed in the right pane if you are
using ANSI (T1).
If you are using ITU (E1), the following is displayed:
4. Enter a Group Name.
5. Select the OPC-DPC you want to use.
6. Select the values you wish to use for the following:
Local CLLI (Common Language Location Identifier)
Information used for circuit validation to identify a switching office by town,
state, and building subdivision. A maximum of 421 characters can be entered.
87
MSP
Remote CLLI
Information used for circuit validation to identify a switching office by town,
state, and building subdivision. A maximum of 421 characters can be entered.
Answer Supervisor Mode

0x00 Propagate Answer to Distant End

0x02 Propagate Answer to Distant End and Notify Host of Answer


0x01 Notify Host of Answer
0x03 No Answer Supervision - no propagation of answer or notification
Local End Release Mode


0x00 Park Channel
0x01 Release Channel (Default)
Distant End Release Mode


0x00 Park Channel
0x01 Release Channel (Default)
Request for Service With Data


0x00 Raw ISUP
0x01 BCD Digits
PCM Encoding Format


0x00 u-Law encoded PCM (E1)
0x01 a-Law encoded PCM (T1)
You are ready to configure the ISUP circuit group. See configuration of a Circuit
Group.
License Information
ClientView displays your current MSP license information, if it has been installed.
Your license must be installed in the installation folder or directory.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Licensing Info
Default Location of License
Windows
88
ClientView
C:\Program Files\Cantata\common\license
Linux or Solaris
/opt/cantata/common/license
If you have acquired a new license for additional functionality, click the Download
Node License button to download the license to the MSP 1010. The license with the
most recent timestamp will be downloaded.
The MSP license file name contains a unique serial number of the MSP 1010. The
format of the file includes the eight digit serial number followed by the timestamp:
NNNNNNNN_YYYYMMDDHHSS.cfg
If you rename or alter the license file in any way, it becomes unusable.
ClientView Pane
This pane verifies that the MSP 1010 license is valid. If there is no license, See
Verifying a license After Failure in ClientView.
Link Configuration
Use this object to set up monitoring of SS7 links.
Accessing this Pane
89
MSP
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New Monitoring -> New Link Configuration
Note
To monitor SS7 links you must select previously configured high impedance spans.
Node Group
The node group object is used to configure a node. Selecting the Node Group menu
item creates the Logical MSP.
Accessing this Pane
Cantata MSP EMS -> Logical MSP
ClientView Pane
You must enter a name in under the User-Specified column.
Logical Spans
Use this object to map a logical span ID to a physical location. You must assign a
unique ID to each span in the system before you can configure any spans or
channels.
The Bearer spans assigned to SS7 monitoring links may be configured as either
high or low impedance facilities. This setting is configurable on a per-link basis
meaning high and low impedance facilities may co-exist, so long as both the
transmitting and receiving sides of any particular monitoring link have the same
impedance setting. The four Signaling/Timing spans may not be configured for
high impedance.
Before You Begin
You must have previously configured the physical T1 or E1 spans on your MSP 1010.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> Facility -> Bearer ->
New T1 Physical Span -> Logical Span ID
Or, if you are configuring E1 spans:
90
ClientView
Cantata MSP EMS -> Logical MSP -> Physical MSP -> Facility -> Bearer ->
New E1 Physical Span -> Logical Span ID
ClientView Pane
Configuration
Select values from the drop-down menus in the User-Specified column for the
following:

Logical Span ID (1-4095)

Framing





Loop Timing Type
Signaling
Line Length
Line Coding
Impedance
Span Status
This monitoring field indicates the current status of the E1 or T1 span.
MTP3 User Adaptation Layer
91
MSP
Use this object to configure M3UA using ClientView. For more information see
Message Transfer Part Level 3 User Adaptation Layer (M3UA).
Before You Begin
Configure the SS7 stacks that you will tie to M3UA and enable M3UA for these
stacks. See SS7 Stack.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer
ClientView Pane
Field Descriptions
Stack Type
The options are:
ITU
ANSI
JT-ISUP
China
Network Identity
Information sent to identify the network that administers the supplementary service.
Each Application Server in the system must have a unique network appearance. The
network appearance can have the same parameters (protocol type and network
identity) but must have a different number. The choices are:
M3UA Network International
M3UA Network National No Priority
M3UA Network National Priority
92
ClientView
Service State
This indicates the status of this M3UA object — whether it is in-service or out-ofservice.
Configured State
This indicates the state that you configured this M3UA object to be — in-service or
out-of-service.
M3UA Application Server
Use this object to configure an application server (AS).
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New ASs -> New AS
ClientView Pane
Field Descriptions
SS7 Stack
ID of the SS7 stack that is associated with the application server.
Traffic Mode
1 Override - This means that all the Mobile Subscriber Unit traffic sent from an
Application Server to a specific Signaling Gateway will be sent by the same
Application Server Process, even if the Application Server has more than one
Application Server Process configured.
2 Loadshare
3 Broadcast
Routing Key Type
93
MSP
0 - M3UA DPC
1 - M3UA DPC SIO
2 - M3UA DPC SSN
3 - M3UA DPC CIC SIO
4 - M3UA DPC OPC
5 - M3UA DPC OPC CIC
Originating Point Code
The OPC (Originating Point Code) as defined in the SS7 Signaling Stack Configure
message must match the value that the distant end signaling point expects.
Network Appearance ID
The range of values is 0-9.
Service State
This indicates the status of this M3UA object — whether it is in-service or out-ofservice.
Configured State
This indicates the state that you configured this M3UA object to be — in-service or
out-of-service.
Buttons
In-Service - use this to bring the M3UA Application Server in-service.
Out-of-Service - use this to bring the M3UA Application Server out-of-service.
Query State - use this to query whether the M3UA Application Server is in-service or
out-of-service.
M3UA Application Servers
Use this object to configure an application server. See AS.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New ASs
M3UA Application Server Process
Use this object to configure an application server process (ASP).
94
ClientView
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New ASPs -> New ASP
ClientView Pane
Field Descriptions
ASP ID
Choose either zero or 1.
Primary IP
This is the primary IP address of a configured application server process (ASP).
Secondary IP
When present, this enables Stream Control Transmission Protocol (SCTP) multihoming. This IP address is the same as the Primary IP address but is accessible from
another network. The primary IP address and the secondary IP address must be on
physically and logically separate subnets.
Service State
This indicates the status of this M3UA object — whether it is in-service or out-ofservice.
Configured State
This indicates the state that you configured this M3UA object to be — in-service or
out-of-service.
M3UA Application Server Processes
95
MSP
Use this object to configure an ASP. See ASP.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New ASPs
M3UA Application Server to Application Server Process
Use this object to associate an application server (AS) to an application server
process (ASP).
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New ASs -> New AS -> New AS
to ASP
M3UA Connection
Use this object to configure a connection for the M3UA.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New Connections -> New
Connection
ClientView Pane
Field Descriptions
Connection ID
The range of values for this field is: 0-39.
ASP
96
ClientView
Select a value from the drop-down list.
SGP
Select a value from the drop-down list.
Service State
This indicates the status of this M3UA object — whether it is in-service or out-ofservice.
Configured State
This indicates the state that you configured this M3UA object to be — in-service or
out-of-service.
M3UA Connections
Use this object to configure a connection for M3UA.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New Connections
M3UA Route
Use this object to configure a route in a route set for the M3UA.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New Route Sets -> New Route
Set -> New Route
ClientView Pane
Field Descriptions
Route Name
97
MSP
Enter a name for the M3UA route you are configuring.
Route ID
Read-only field.
Route Set
Signaling Gateway ID
Network Appearance ID
Route Priority
M3UA Route Set
Use this object to configure a route set for the M3UA.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New Route Sets -> New Route
Set
ClientView Pane
Field Descriptions
Route Set ID
The range of values for this field is: 0-63.
DPC
The destination point code.
AS
98
ClientView
The application server ID. An application server is a logical entity serving a specific
routing key. An example is a virtual switch element handling call processing for a
unique range of PSTN trunks.
AS ID
Read-only field.
OPC
Read-only field.
Variant
Read-only field.
Service State
This indicates the status of this M3UA object — whether it is in-service or out-ofservice.
Configured State
This indicates the state that you configured this M3UA object to be — in-service or
out-of-service.
M3UA Route Sets
Use this object to configure route sets for the M3UA. See configuring an M3UA route
set.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New Route Sets
M3UA Routing Context
Use this object to configure a routing context for an application server.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New ASs -> New AS -> New
Routing Context
ClientView Pane
99
MSP
Field Desriptions
AS
The application server ID. An application server is a logical entity serving a specific
routing key. An example is a virtual switch element handling call processing for a
unique range of PSTN trunks.
Routing Context ID
The unique number assigned to each SG to AS logical connection. The range of
values is: 1-10. This number appears in M3UA messages.
Signaling Gateway ID
The signaling gateway ID. A signaling gateway is a signaling agent that
receives/sends switched circuit network signaling at the edge of the IP network. An
SG appears to the SS7 network as an SS7 Signaling Point.
M3UA Routing Key
Use this object to configure associate a routing key with an application server.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New ASs -> New AS -> New RK
ClientView Pane
Field Descriptions
Routing Key ID
The range of values is 0-9.
100
ClientView
AS
The application server ID. An application server is a logical entity serving a specific
routing key. An example is a virtual switch element handling call processing for a
unique range of PSTN trunks.
Routing Key Type
Read-only field.
M3UA Signaling Gateway
Use this object to configure a signaling gateway (SG).
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New SGs-> New SGs
ClientView Pane
Field Descriptions
SG ID
The range of values is: 0-9.
SGP
Signaling gateway Process. In general it is recommended to configure all the SGPs in
the system and then the SGs.
Traffic Mode
The options for this field are:
1 Over-ride
101
MSP
2 Loadshare
3 Broadcast
Service State
This indicates the status of this M3UA object — whether it is in-service or out-ofservice.
Configured State
This indicates the state that you configured this M3UA object to be — in-service or
out-of-service.
M3UA Signaling Gateway Process
Use this object to configure a signaling gateway process (SGP).
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New SGPs-> New SGP
ClientView Pane
Field Descriptions
SGP ID
The range of values is: 0-19 You can configure a maximum of 20 SGPs.
Name
Name your SGP so that you can differentiate it from other SGPs.
Primary IP Address
This is the primary IP address of a configured signaling gateway process (SGP).
Secondary IP Address
102
ClientView
When present, this enables Stream Control Transmission Protocol (SCTP) multihoming. This IP address is the same as the Primary IP address but is accessible from
another network. The primary IP address and the secondary IP address must be on
physically and logically separate subnets.
Port Number
The port number is 2905.
Service State
This indicates the status of this M3UA object — whether it is in-service or out-ofservice.
Configured State
This indicates the state that you configured this M3UA object to be — in-service or
out-of-service.
M3UA Signaling Gateway Processes
Use this object to configure a signaling gateway process. See Signaling Gateway
Process.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7 -> New MTP3 User Adaptation Layer -> New SGPs
Media DSP
This pane configures functions on a DSP chip. After a media DSP chip on the media
module has been configured and committed, you have the option of taking it out-ofservice and bringing it in-service using the buttons in ClientView.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Media -> New
Media Module -> New Media DSP
Maximum Media DSP Objects
2
ClientView Pane
103
MSP
Field Descriptions
DSP Id
Indicates the DSP chip.
Receive 0 Configuration
Indicates the function configured for the Receive 0 DSP.
Transmit 0 Configuration
Indicates the function configured for the Transmit 0 DSP.
Receive 1 Configuration
Indicates the function configured for the Receive 1 DSP.
Transmit 1 Configuration
Indicates the function configured for the Transmit 1 DSP.
Media Module
This pane configures a DSP module on the MSP.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Media -> New
Media Module
Maximum Media Module Objects
1
ClientView Pane
104
ClientView
Field Descriptions
Module Interface Id
Media Module 0
Media Module 1
Module Name
On-Board
Media Module
Media
Use this object to configure media resources. The available media resource options
are:

Conference Parameters

PVD-Answering Machine



Echo Cancellation
T.30 Fax Parameters
DSP Alarm Thresholds
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Media
ClientView Pane
105
MSP
Monitoring Object
This is a container object used to set up monitoring SS7 traffic.
Accessing this Pane
Cantata MSP EMS -> New Signaling -> Signaling -> New Monitoring
Menu Options
The menu options shown here are available for configuration:
See Example Configuration for SS7 Monitoring.
Monitor Application
Use this object to specify a type of monitoring application.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Monitoring
Application
ClientView Pane
106
ClientView
Steps
1. Select an option for the Application Type:

SigView

ISUP

SCCP-TCAP
2. Enter an Application ID.
3. Enter a Logical Socket ID.
Monitoring Application Map
Use this object to map an SS7 monitoring application to a socket. In order to receive
SS7 monitoring traffic, MA(s) must be configured and mapped to one or more logical
Socket IDs. There can be multiple MA(s) associated to the same socket.
Before You Begin
You must have a socket configured for multiple hosts. See Sockets for Multiple Hosts.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New Monitoring -> New Application Map
ClientView Pane
107
MSP
Steps
1. Select an Application ID.
2. The Logical Socket ID is automatically populated after you have created a
socket for multiple hosts. If there is more than one configured, select one.
Link
Use this to configure monitoring of an SS7 link.
To monitor SS7 links you must select previously-configured high impedance
spans.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New Monitoring -> Monitoring -> Link Configuration -> New
Link
ClientView Pane
108
ClientView
The fields in the Link pane populate automatically since your physical spans
already configured.
The Application ID by default is configured as None. If you select an application
ID, then the host will receive reports on a high volume of MTP2 traffic.
Links
Use this object to apply filter rules to a monitored SS7 link. Traffic can be filtered
based on the SS7 Monitoring Link ID.
Up to 64 bi-directional SS7 links can be monitored, or 128 Rx channels.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New Monitoring -> Monitoring -> New Filter Rules -> Filter
Rules -> New Link
ClientView Pane
109
MSP
Steps
1. Select a minimum Link ID (0-63).
2. Select a maximum Link ID (0-63)
Point Code
Use this to filter a point code or range of point codes when monitoring SS7 signaling.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New Monitoring -> Monitoring -> New Filter Rules -> Filter
Rules -> Filter Rules -> New Point Code.
ClientView Pane
110
ClientView
Additional Applications
Use this to filter applications when monitoring SS7 signaling.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New Monitoring -> Monitoring -> New Filter Rules -> New
Additional Applications.
ClientView Pane
Service Indicator
MTP3 traffic can be filtered based on User Part Data. Use this filter to restrict the
flow of traffic to a monitoring application.
111
MSP
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New Monitoring -> Monitoring -> New Filter Rules -> Filter
Rules -> New Service Indicator.
ClientView Pane
Multi-Host Socket
Up to five logical socket IDs (1-5) may be mapped to TCP ports (i.e. 0x3143,
0x3144, 0x3145, 0x3146, or 0x3147) for routing traffic to SS7 monitor applications.
Ports can range from 1-65534 with the exception being port 12610 (0x3142), which
is reserved for LLC/MSP communication.
After a multi-host port is mapped to a Logical Socket ID, the MSP will transmit NGA
Poll (0x0170) messages to the application(s) listening on that socket. For example,
if you mapped multi-host port 126111 to Logical Socket ID 1, the MSP would then
transmit NGA Poll messages to both the default Logical Socket ID 0 (port 12610), as
well as, Logical Socket ID 1 (port 126111).
ClientView Pane
112
ClientView
Steps
To configure sockets for multiple hosts do the following:
1. Add a Network Interfaces object.
2. Right-click the Network Interfaces object in the left pane and select New
Multi-Host Socket.
3. Select a Logical Socket ID.
4. Enter a Port Number.
Network DPC and SSN
Use this to configure the Destination Point Code (DPC) and remote subsystem
number.
Accessing This Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New SS7 -> New SS7 Stack
-> New SCCP/TCAP -> New Sub-System Number -> Sub-System Number
-> New Network DPC and SSN.
ClientView Pane
113
MSP
Steps
1. Right-click the Sub-System Number object.
2. Select New Network DPC and SSN.
3. Select a point code from the drop-down list which is populated with the
already configured destinations in the Route() object.
4. For Remote SSN, select from the drop-down list which shows a range 2-255.
Note
When configuring DPC and SSN as a network DPC/SSN of a local SSN, the local SSN
will be informed about any status changes of that network DPC/SSN.
Network Indicator
Use this to set filter rules when monitoring SS7 signaling. MTP3 traffic can be filtered
based on the Network Indicator encoding of Message Signal Units.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling -> New Monitoring -> Monitoring -> New Filter Rules -> Filter
Rules -> New Network Indicator.
ClientView Pane
114
ClientView
Network Interface
Allows you to configure a network interface such as, a Network File System (NFS)
client, on a control, data, or signaling port. This object is also used on the MSP for
assigning IP Address and Gateway to VoIP Modules. See VoIP Network Interface.
Accessing This Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Network
Interfaces-> New Network Interface
ClientView Pane
115
MSP
Field Descriptions
Physical Interface
This interface allows you to configure a CPU and VoIP modules if present. Use the
drop down menu, to choose between CPU and VoIP modules if present.
Logical Interface
Choices:
Redundant Control
Redundant Data
Address Type
The only address type used is IP V4.
IP Address
If the CPU profile’s IP address is on the same subnet as an existing profile, it must
use the same logical interface.
Please note that the IP address assigned using BootP is automatically bound to
the Redundant Control interface.
If the CPU profile’s IP address in on its own subnet, any of the logical interfaces can
be used.
Subnet
Default Gateway
Network Interfaces
This object is used to create a network interface. See Network Interface.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Network Interface
116
ClientView
NFS Servers
Use this object to configure a Network File System (NFS) server. To configure an NFS
Server, see NFS Server.
Accessing this Pane
Cantata MSP EMS-> New External Network Elements-> NFS Servers
Node Object
The node object is used to create a physical MSP. See also, Options Available in Node
Configuration.
Accessing this Pane
Cantata MSP EMS -> New Node Group -> Logical MSP -> New Node ->
Physical MSP
1. Right-click Excel MSP EMS in the left pane and from the drop-down menu
select New Node Group.
2. Enter the Filename. A logical MSP is created.
3. In the left pane, right-click the Logical MSP... and from the drop-down menu
select New Node.
117
MSP
4. Enter the MSP Name.
5. Enter the IP Address of the MSP you are configuring by using this window:
After this IP address is committed, it cannot be edited. If you need to change the IP
address, you must delete the node object and create another one. Then, you can
enter a new IP address.
6. Click OK.
7. If you want to change the Resend Logic, select another option from the
drop-down list.
NFS Server
This pane configures an Network File System (NFS) Server from which the MSP 1010
will retrieve media files.
Accessing this Pane
Cantata MSP EMS-> New External Network Elements-> NFS Servers-> NFS Server
Maximum NFS Server Objects
8
ClientView Pane
118
ClientView
Field Descriptions
NFS Server Id
This is a logical number (1-8) that identifies each NFS server configured. It is
automatically populated with the next available number, but can be changed.
NFS Server Enabled
This field indicates if the server is enabled or disabled
Choices:
Disabled: Do not allow this server to be used.
Enabled: Allow this server to be used.
NFS Server Name
A label used to identify the NFS server.
NFS Server IP Address
IP Address of the NFS server.
NFS Mount Directory
This is the location of the directory that is to be mounted. The directory must start
with “/” or “\\”.
NFS Server Display Table
This pane displays all of the NFS Servers configured.
Other Concerned Point Codes
For an SSP or SCP, point codes which must be informed about local subsystem (MSP
1010) status changes are referred to as concerned point codes.
Accessing This Pane
119
MSP
Cantata MSP EMS -> Logical MSP->Physical MSP -> New Signaling ->
Signaling -> New SS7 -> New SS7 Stack
-> New SCCP/TCAP -> New Sub-System Number -> Sub-System Number
-> New Other Concerned Point Codes.
ClientView Pane
Steps
1. Right-click the Sub-System Number object.
2. Select New Other Concerned Point Codes.
.
3. Select a point code from the drop-down list which is populated with the
already configured destinations in the Route() object.
Notes
If you configure an OPC as an Other Concerned Point Code of a local SSN, then any
local SSN status change will be reported to that point code.
The Adjacent Translator will by default, be considered as a concerned point code and
will be informed about a local SSN status change.
Physical MSP
This object creates a physical MSP 1010 node. Use the User-Specified column for
configuration. Click or double-click in a cell (blue or beige) to edit or enter a value.
These buttons can be used to change your node configuration. See Options Available
in Node Configuration for more details.

Reset Node

Download Raw File

Clear Software
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> New Node -> Logical MSP Name
120
ClientView
Steps
Do the following to create a physical MSP.
1. Right-click the logical MSP created in the left pane and select New Node. The
right panes shows the configuration options for the physical MSP.
Automatically Populated Field: Logical MSP ID = Next Available Number
2. In the MSP Name field, enter a name.
3. In the IP Address field, enter the IP Address of this physical MSP.
Automatically Populated Field: MSP Type = 1010
4. If you want to change the Resend Logic, select another option for the dropdown list.
If you see a STOP sign icon beside the physical node, this means that the
license file failed. See License Information
Physical Port Configuration
This object allows you to configure the connection speed of a physical port for a
network interface.
Accessing This Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Network
Interfaces-> New Network Interface-> New Physical Port Configuration
121
MSP
ClientView Pane
Field Descriptions
CTRL 0 Port Interface
Auto - The MSP 1010 detects the connection speed of the network side.
This should not be changed.
CTRL 1 Port Interface
Auto - The MSP 1010 detects the connection speed of the network side.
This should not be changed.
DATA 0 Port Interface
Auto - The MSP 1010 detects the connection speed of the network side.
100 Full - A speed of 100 Mbps full duplex is maintained
DATA 1 Port Interface
Auto - The MSP 1010 detects the connection speed of the network side.
100 Full - A speed of 100 Mbps full duplex is maintained
SIG 0 Port Interface
Auto - The MSP 1010 detects the connection speed of the network side.
100 Full - A speed of 100 Mbps full duplex is maintained
SIG 1 Port Interface
Auto - The MSP 1010 detects the connection speed of the network side.
100 Full - A speed of 100 Mbps full duplex is maintained
PVD and AMD Parameters
Use this object to change the PVD (Positive Voice Detection) and AMD (Answering
Machine Detection) parameters on a DSP chip.
122
ClientView
Accessing this Dialog Box
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Media -> New PVD
Answering Machine
ClientView Pane
Raw API Command
The file format used for sending raw API commands is *.hex.
The file should contain hexadecimal only, it should not include comments or
backslashes.
Accessing This Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Raw API Cmds ->
New Raw API Cmd
Raw API Commands
This is a container object for creating a new raw API command file. Before you create
a new Raw API Command object, you must create a *.hex file in your installation
directory which by default is:
Windows:
C:\Program Files\Cantata\common\config
UNIX:
/opt/cantata/common/config
123
MSP
To create a new Raw API Command, see Raw API Command.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Raw API Cmds
Configuring a Range of Signaling Spans
You configure a range of signaling spans with the Facility Wizard.
To configure individual spans, see Configuration for a E1 Physical Span, and T1
Physical Span.
Prerequisites
Creating a Physical MSP
Configurating a facility
Steps
1. Right-click Facility.
2. Click the Facility Wizard button.
3. Complete the fields. Be sure to select Signaling for the Component ID.
4. Click OK.
5. The next pane depends on whether you are configuring a T1 span or E1 span.
Complete the fields as required.
Remote User Part
To configure a remote user part you must have already configured an SS7 stack. See
SS7 Stack.
Accessing This Pane
Physical MSP -> New Signaling -> Signaling -> New SS7 -> New SS7 Stack > New Remote User Part
ClientView Pane
124
ClientView
Steps
1. Right-click the SS7 stack.
2. Select New Remote User Part from the drop-down menu.
3. Select the type of user part that you want to reside on a remote host.
4. Select the appropriate Logical Socket ID.
Replicated SSN
Use this to configure the replicated destination point code and subsystem number.
Accessing This Pane
Physical MSP -> New Signaling -> Signaling -> New SS7 -> New SS7 Stack > New SCCP/TCAP -> New Sub-System Number -> Sub-System Number ->
New Replicated DPC and SSN.
ClientView Pane
Steps
1. Right-click the Sub-System Number object.
2. Select New Replicated SSN and DPC.
3. For Replicated DPC, select a point code from the drop-down list which is
populated with the already configured destinations in the Route() object.
125
MSP
4. Select a Replicated SSN from the drop-down list.
5. Select a Priority from the drop-down list.
Routing Configuration
This is a container object used to configure channel groups and application routing
groups.
Accessing This Pane
Cantata MSP EMS -> New Routing Config
SCCP/TCAP
Do the following to configure SCCP/TCAP.
Accessing This Pane
Cantata MSP EMS -> Logical ->Physical MSP -> New Signaling -> Signaling > New SS7 -> New SS7 Stack -> New SCCP/TCAP.
Before You Begin
You must have the SS7 stack, link sets, links and routes already configured. You
must have at least two stacks configured.
Steps
1. To configure SCCP/TCAP you must first have enabled the relevant ANSI or ITU
specification on the SS7 stack.
2. Right-click the stack for which SCCP/TCAP will be configured and select New
SCCP/TCAP. The SCCP/TCAP object is created.
126
ClientView
Now you can configure the sub-system number.
SCCP-TCAP Default Parameter Table
This table contains the default parameters used by SCCP and TCAP for all subsystems associated with a stack.
Accessing This Pane
Cantata MSP EMS -> Logical ->MSPPhysical MSP -> New Signaling ->
Signaling -> New SS7 -> New SS7 Stack
-> New SCCP/TCAP -> New SCCP/TCAP Default Parameter Table.
ClientView Pane
127
MSP
Steps
1. Right-click the SCCP/TCAP object.
2. Select New SCCP/TCAP Default Parameter Table.
3. Enter the Parameter Type (16 Bits).
.
4.
Enter Parameter Value.
Signaling Object
The signaling object is used to configure SS7 and ISDN and to monitor SS7 traffic.
See Example Configuration for SS7 Voice Circuits, Example ISDN Configuration, and
Example Configuration for SS7 Monitoring.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling ->
Signaling
Configuring a Range of Signaling Spans
You configure a range of signaling spans with the Facility Wizard.
To configure individual spans, see Configuration for a E1 Physical Span, and T1
Physical Span.
Prerequisites
Creating a Physical MSP
Configurating a facility
Steps
1. Right-click Facility.
2. Click the Facility Wizard button.
3. Complete the fields. Be sure to select Signaling for the Component ID.
4. Click OK.
128
ClientView
5. The next pane depends on whether you are configuring a T1 span or E1 span.
Complete the fields as required.
Signaling Variant
You can create a signaling variant based on ISUP variants. It is also used to import a
pre-packaged SS7 variant file provided by Cantata Technology. SS7 Signaling
variants are used to modify the base variants that are specific to certain countries or
based on regulatory needs.
NOTE: Once a custom variant is assigned to a stack, you cannot modify or
delete an existing entry in the variant. You can add new entries, however.
Maximum Signaling Variant Objects
10
Technical Notes
When configuring a Signaling Variant, the following happens:
A new variant is created; the user can then configure an SS7 stack based on that
variant. The appropriate messages will be sent to the physical MSP at the
appropriate time in the configuration automatically. For example, if you create an
SS7 variant and under that variant the SS7 Route components are modified, those
modifications are sent to the physical MSP only when an SS7 route is configured
under an SS7 stack based on the created variant.
Accessing this Pane
Cantata MSP EMS -> New Signaling Variants -> New Signaling Variant
ClientView Pane
129
MSP
Steps
1. Right-click Excel MSP EMS in the left pane and select New Signaling
Variants from the menu.
2. Right-click the Signaling Variants object in the left pane, and select New
Signaling Variant.
3. Enter the Variant Name.
4. Select the Base Variant.
5. Right-click and Commit.
Field Descriptions
Variant Name
This field specifies the name of the SS7 variant to be created.
Variant Type
This field specifies the type of protocol for this variant.
Choices:
SS7
Base Variant
This field specifies the base variant that this SS7 Signaling variant is based on.
Choices:
ANSI 97
ANSI 95
ANSI 92
ITU 97
ITU 93
CCITT 88
ETSI V1
ETSI V2
ETSI V3
Variant Id
This field specifies the ID of the Signaling variant. Allowable values are 1 to 10.
130
ClientView
Signaling Variants Object
This is a container for creating custom SS7 variants.
Accessing this Pane
Cantata MSP EMS -> New Signaling Variants
Signalless Channel Group
Use this object to create a signalless channel group. Next, you can create a
Signalless Circuit Group.
Accessing this Pane
Cantata MSP EMS -> New Routing Configuration -> New Channel
Configuration Groups-> New Signalless Group
ClientView Pane
Field Descriptions
Group Name
Enter a name for your signalless channel group.
Answer Supervisor Mode
Select one of the following:
0x01 Notify Host of Answer
0x03 No Answer Supervision – No propagation of answer or notification
PCM Encoding Format
131
MSP
Select one of the following:
0x01 µ-law encoded PCM (North America & Japan)
0x02 A-law encoded PCM (Europe)
Signalless Circuit Group
Use this object to create a signalless circuit group.
Accessing this Pane
Cantata MSP EMS -> New Routing Configuration -> New Channel
Configuration Groups-> New Signalless Group-> New Signalless Circuit
Group
ClientView Pane
Field Descriptions
MSP Name
The name of the MSP on which the group resides.
Start Span
Start Channel
Number of the first channel in the group.
End Span
End Channel
Multi-Host Socket
Up to five logical socket IDs (1-5) may be mapped to TCP ports (i.e. 0x3143,
0x3144, 0x3145, 0x3146, or 0x3147) for routing traffic to SS7 monitor applications.
132
ClientView
Ports can range from 1-65534 with the exception being port 12610 (0x3142), which
is reserved for LLC/MSP communication.
After a multi-host port is mapped to a Logical Socket ID, the MSP will transmit NGA
Poll (0x0170) messages to the application(s) listening on that socket. For example,
if you mapped multi-host port 126111 to Logical Socket ID 1, the MSP would then
transmit NGA Poll messages to both the default Logical Socket ID 0 (port 12610), as
well as, Logical Socket ID 1 (port 126111).
ClientView Pane
Steps
To configure sockets for multiple hosts do the following:
1. Add a Network Interfaces object.
2. Right-click the Network Interfaces object in the left pane and select New
Multi-Host Socket.
3. Select a Logical Socket ID.
4. Enter a Port Number.
SS7
The SS7 object is the high-level parent object for all SS7 configuration. This object
also specifies the SS7 redundancy state. See Procedure for Redundant SS7 Objects.
An SS7 object can be either StandAlone or Primary. There can be only one SS7
object per logical MSP. To configure a non-SS7 redundant MSP 1010, select
StandAlone in the Redundancy Configuration Property of the SS7 object. After
StandAlone is selected for the Redundancy Configuration Property, you can no
longer configure the Peer Logical Node ID Property. The Peer Logical Node ID
Property is only required when configuring an SS7 redundant system. If there is
more than one node in the logical MSP, nodes other than the node that has been
configured as StandAlone will be configured as remote SS7 nodes.
Accessing this Pane
133
MSP
Cantata MSP EMS-> Logical MSP-> Physical MSP -> New Signaling-> New
SS7
Maximum SS7 Objects
Only one SS7 object is allowed per logical MSP (node group). A maximum of four
SS7 stacks are allowed per configuration.
Technical Notes
If StandAlone is selected, all the other nodes in the same Node Group can be
configured as SS7 remote nodes. If Primary is selected, the node that is identified
in the Peer Logical Node ID field is configured as the SS7 redundant Secondary. Any
additional nodes in that Node Group can be configured as SS7 remote nodes.
SS7 ClientView Pane
Field Descriptions
Redundancy Configuration
This field specifies the state of the SS7 state machine
Choices:
StandAlone: A single physical MSP with no redundancy or the SS7 server node in a
multi-node logical MSP.
Primary: Primary physical MSP, which will support SS7 links ID: 0 – 63. It has to be
informed about its Secondary node ID.
Peer Logical Node ID
134
ClientView
This field is left blank in the case of a Stand Alone SS7 node. In the case of
redundancy, the field will be populated with the logical node ID of the secondary
physical MSP.
Host Link Failure (HLF)
This field allows you to enable or disable the host link failure detection and handling
feature. This is disabled by default.
HLF Timeout
This field allows you to set the number of seconds before the host link failure
detection and handling logic starts.
HLF SCCP Behavior
This field allows you to set how SCCP will respond to a host link failure.
Component State
This monitoring field displays the state of the SS7 state machine.
Button Descriptions
Switch Over
This button forces an SS7 state machine switchover (only applies to redundant SS7
configuration).
SS7 Display Table
The table is not used for this object.
SS7 CIC
Accessing this Pane
Cantata MSP EMS -> New Routing Config -> Routing Configuration -> New
Channel Configuration Groups -> New ISUP Config Group -> New Circuit
Group -> Circuits:Start CIC
ClientView Pane
135
MSP
Steps
1. Right-click Excel MSP EMS and select New Routing Config. A Routing
Configuration object is created.
2. Right-click the Routing Configuration object and select New Channel
Configuration Groups. A New Channel Configuration Groups object is
created.
3. Right-click the New Channel Configuration Groups object and select New
ISUP Config Group. The following displays in the right pane.
4. Enter a Group Name.
SS7 Link
This object identifies an SS7 link within an SS7 link set to an adjacent point code
(APC). A signaling link is a point-to-point connection between two SS7 point codes —
in this case, an MSP and an Signal Transfer Point (STP). The place holder assigns a
physical location in the MSP (timeslot) and a previously configured signaling link set
to a signaling link.
When you configure multiple stacks on the MSP, the Link IDs assigned to each
signaling stack must be different. For example, if Link ID is assigned to Stack 1, it
cannot also be assigned to Stack 2.
If you have configured redundant MSPs, see Redundancy Procedure for SS7 Links
Object.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP-> SS7 -> SS7 Stack -> SS7
Link set -> SS7 link
Maximum SS7 Link Objects
A maximum of 64 links are allowed per physical MSP, adding up to 128 links for a
redundant pair.
Technical Notes
136
ClientView
When configuring an SS7 Link, the following happens:
An SS7 link is assigned on a specific channel/offset. The link will go into the
alignment procedure trying to align and come in service.
ClientView Pane
Field Descriptions
Primary/Secondary
This field specifies whether the SS7 link is supported by the primary or secondary
physical MSP. If you are configuring links on a secondary MSP for redundancy, select
Secondary
Choices:
Primary
Secondary
Link ID
This field specifies the SS7 link ID. Link ID 0 – 63 are allowed for the primary
physical MSP, while link ID 64 – 127 are allowed for the secondary physical MSP.
Logical Span ID
This field specifies the logical span ID that the SS7 link will reside on.
Channel
This field specifies the channel from the physical offset (span) chosen in the previous
field on which the SS7 link will be configured.
Signaling Link Code
This field specifies the SLC of the SS7 link. SLC is unique across any SS7 link set
with a range of values of 0 – 15.
137
MSP
Data Rate
This field specifies the data rate of the SS7 signaling link
Choices:
64 Kbps
56 Kbps mask LSB (The Least significant bit is masked resulting in 56
kbps)
56 Kbps mask MSB (The Most significant bit is masked resulting in 56
kbps)
48 Kbps mask LSB and MSB (The Least and Most significant bits are
masked resulting in 48 kbps)
48 Kbps mask 2 MSBs (The 2 Most significant bits are masked
resulting in 48 kbps)
Electrical Interface
Choices:
DS1 Channel
DS1 Channel Data
Link Status
This monitoring field displays the status of the SS7 link.
Button Descriptions
In Service
This buttons brings the SS7 link in service
Out Of Service
This buttons brings the SS7 link out of service
Inhibit
This buttons inhibits the SS7 link
Uninhibit
This buttons uninhibits the SS7 link
SS7 Link Display Table
138
ClientView
This table displays a list of the configured SS7 links under a specific SS7 Link set.
SS7 Link Set
This object identifies a link set that is used to connect an SS7 stack on the physical
MSP to an adjacent point code.
The same signaling stack must be assigned to all links in a link set. A typical
configuration consists of two link sets.
Signaling links in a link set are “load sharing” that is, signaling traffic is distributed
equally on the links to optimize efficiency.
When you configure multiple stacks, the Link Set IDs assigned to each signaling
stack must be different. For example, if a Link Set ID is assigned to Stack 1, it
cannot also be assigned to Stack 2.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP-> SS7 -> SS7 Stack -> SS7
Link Set
Maximum SS7 Link Set Objects
A maximum of 128 link sets are allowed per physical MSP.
Technical Notes
When configuring a SS7 Link Set, the following happens:
An adjacent point code is configured for that physical MSP.
ClientView Pane
Field Descriptions
Link Set ID
This field specifies the ID of the SS7 link set.
APC
This field specifies the point code of the adjacent node that this link set will be
connected to. The format of the APC will follow the same rules in the SS7 stack. For
139
MSP
example if the OPC is ITU 97, which follows the format of 3-8-3, the APC should also
be running ITU 97 and should follow the format of 3-8-3.
Comments
You can enter information about the Link Set such as location and type of SS7 far
side (for example, New York STP).
SS7 Link Set Display Table
This table displays a list of the SS7 link sets configured under a specific stack.
SS7 Route
This pane defines a route to an SS7 destination (DPC).
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> Signaling -> SS7 ->
SS7 Route
Maximum SS7 Routes
512 routes to 128 destinations
Technical Notes
When configuring an SS7 Route, the following happens:
A path is configured to reach a specific DPC by going through a configured Link set
(The Link set that is the parent object of this SS7 Route).
ClientView Pane
Field Descriptions
Route ID
140
ClientView
This field identifies the ID of the SS7 Route. Allowable values are 0 to 511.
Route Type
This field identifies whether the route to the specified DPC is the first one configured
or whether there are already existing routes to that DPC.
Choices:
New Route
Existing Route (Combined Link Set Disabled)
Existing Route (Combined Link Set Enabled)
Linkset ID
This field will be enabled only if the Route type is set to ‘Existing Route (Combined
Link Set Enabled)’. This field is a pull-down menu of the already-configured linksets
New DPC
This field will be enabled only if the Route type is set to ‘New Route’. This field
identifies the Point Code of the Destination.
Existing DPC
This field will be enabled only if the Route type is set to ‘Existing Route (Combined
Link Set Disabled)’ or ‘Existing Route (Combined Link Set Enabled) This field is a
pull-down menu of the already-configured Destinations.
Priority
This field identifies the priority of the route when there are multiple routes to the
same destination. Allowable values are 0 to 35.
This field will be disabled when the route type is set to ‘Existing Route (Combined
Link Set Enabled)’ because all the routes within the combined link set will have the
same priority.
Comments
A meaningful description of this route, such as the location and type of the SS7 far
side (for example Chicago 5ESS.)
SS7 Route Display Table
This table shows a list of the configured SS7 Routes under a specific Link Set
141
MSP
SS7 Stack
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP-> SS7 -> SS7 Stack
Maximum SS7 Stack Objects
The MSP supports up to four signaling stacks, identified by a Stack ID ranging from
0x00 to 0x03. There is no limitation on how you can allocate SS7 stacks among
MSPs. For example, you can configure multiple signaling stacks on a MSP or you can
configure one signaling stack on each SS7 card, up to a maximum of four stacks per
MSP or multi-node system.
Technical Notes
When configuring an SS7 Stack, the following happens:
The SS7 stack is configured on the physical MSP. A point code will be configured and
a stack ID will be assigned to it. In the case of redundancy the SS7 information is
shared between the redundant pair.
ClientView Pane
Field Descriptions
Stack ID
This field specifies the ID of the stack. The values are in the range 0 – 3. ClientView
ensures that the Stack ID is unique across multiple physical MSPs.
142
ClientView
SS7 Variant
This field specifies the variant used for the stack.
Choices:
Base Only
The drop-down list is populated with any custom variants that have been created.
NOTE: Once a custom variant is assigned to a stack, you cannot modify or delete an
existing entry in the variant. You can add new entries, however.
ISUP
This field specifies the ISUP variant.
Choices:
ANSI 97: The point code format is 8-8-8
ANSI 95: The point code format is 8-8-8
ANSI 92: The point code format is 8-8-8
ITU 97: The point code format is 3-8-3
ITU 93: The point code format is 3-8-3
CCITT 88: The point code format is 3-8-3
ETSI V1: The point code format is 3-8-3
ETSI V2: The point code format is 3-8-3
ETSI V3: The point code format is 3-8-3
China
JTISUP
Remote ANSI
Remote ITU
Remote JTISUP
OPC
This field specifies the point code value of stack. The format is as specified above.
MTP Pause
This field determines whether resuming traffic to a paused DPC will be immediate or
delayed.
Choices:
Immediate
Delayed
143
MSP
Cause Location
This field specifies the location used while releasing the call.
Choices:
User
Local private network
Local public network
Transit network
Remote public network
Remote private network
Local interface
International network
Network beyond interworking point
Exchange Type
Choices:
Type A
Type B
Message Compatibility Pass On
This field specifies whether or not to pass unrecognized messages when they are
received.
Choices:
On
Off
Network Indicator
This field specifies whether the network indicator of ISUP messages sent is set to
national or international.
Choices:
National
International
SCCP
144
ClientView
This field is used to configure SCCP/TCAP. It is Disabled by default. Select Enabled,
if you want to configure SCCP TCAP.
TCAP
This field is used to configure SCCP/TCAP. It is Disabled by default. Select Enabled,
if you want to configure SCCP TCAP.
M3UA
Use this field to enable the MTP3 User Adaptation Layer. You must have an M3UA
license to enable this feature.
Choices:
ITU
ANSI
CFN Status
Choices:
Enabled
Disabled
Japanese MTP Variant
To enable this field you must have previously selected JTISUP or Remote JTISUP
for the ISUP variant field.
Choices:
Enabled
Disabled
A/B Plane Bit Insertion and Validation
Not Used.
SSN
Use this object to configure the sub-system number (SSN).
Accessing This Pane
Cantata MSP EMS-> Logical MSP->Physical MSP -> New Signaling ->
Signaling -> New SS7 -> New SS7 Stack -> New SCCP/TCAP -> New Subsystem Number.
145
MSP
Before You Begin
In the SS7 Stack object, you must have the SCCP property enabled by selecting
ANSI, ITU, Remote ANSI or Remote ITU, to access the Sub-System Number
object. See SS7 Stack.
ClientView Pane
Steps
1. Right-click the SCCP-TCAP object and select New Sub-system Number.
2. Select the SubSystem Number (valid range: 2-255), the Routing Flag and
whether to enable or disable Local GTT (Global Title Translation) Allowed.
The SSN Status field is not configurable.
Buttons
The buttons shown below are available for use with the SSN object:
Allow - The SSN Status field will show the SSN state as in-service.
Prohibit - The SSN Status field will show the SSN state as out-of-service.
Field Descriptions
Subsystem Number
Options for this field:
0 SSN not known/not used
1 SCCP management
2 reserved for ITU-T allocation
3 ISDN user part
146
ClientView
4 OMAP (Operation, Maintenance and Administration Part)
5 MAP (Mobile Application Part)
6 HLR (Home Location Register)
7 VLR (Visitor Location Register)
8 MSC (Mobile Switching Centre)
9 EIC (Equipment Identifier Centre)
10 AUC (Authentication Centre)
11 ISDN supplementary services
12 reserved for international use
13 broadband ISDN edge-to-edge applications
14 TC test responder
15 - 31 reserved for international use
32 - 254 reserved for national networks
Routing Flag
Route SCCP coming from the network to the TCAP on the MSP 1010. For Class 2 Use
Route SCCP messages to the Host.
Local GTT Allowed
Allow Global Title Translation to be performed on the local node.
Multi-Host Socket ID
Select a value.
Sub-system Number Default Parameter
Configure the default parameter table for a particular sub-system.
Accessing This Pane
Cantata MSP EMS-> Logical MSP->Physical MSP -> New Signaling ->
Signaling -> New SS7 -> New SS7 Stack
-> New SCCP/TCAP -> New Sub-System Number -> Sub-System Number
-> New SSN Default Parameter.
Steps
1. Right-click the Sub-System Number object.
2. Select New SSN Default Parameter.
147
MSP
3. Select the Parameter Type from these options:
Default Calling Party Address
Default Quality of Service
Default MTP DPC
4. Enter the Parameter Value using the next window. Enter a byte sequence in
either hexadecimal or decimal format.
Table
To be determined.
T.30 Parameters
Use this object to change the T.30 Fax parameters on a DSP chip.
Accessing this Dialog Box
Cantata MSP EMS -> Logical MSP -> MSP Name -> New Media -> New T.30
ClientView Pane
148
ClientView
TCAP Route
This object is used for monitoring TCAP routes.
Accessing this Pane
Cantata MSP EMS -> New Routing Configuration -> New Application
Instance Routing->New TCAP Route
ClientView Pane
Information about a TCAP Route is shown in the bottom right pane.
149
MSP
T1 Physical Span
To configure a T1 physical span, you must already have a facility object created and
a bearer span (TDM DS1) object configured with the selected trunk type: T1. See
Configuring TDM DS1.
Accessing This Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> Facility -> TDM DS1 ->
T1 Physical Span
ClientView Pane
150
ClientView
Field Descriptions
Logical Span ID
The range of values is 0-4095. It defaults to the lowest available span.
Loop Timing Type
Specifies whether that specific span is used for primary loop timing, secondary loop
timing or not.
Options:
Primary
Secondary
Not Timing Source
Framing
Options:
D4 (Default)
ESF
151
MSP
Signalless
Signaling
The default is Clear Change.
Line Length
Options:
000–133 ft. (Default)
134–166 ft.
0167–299 ft.
300–533 ft.
534–655 ft.
G.703 ITU-T
Line Coding
Options:
Bit 7 zero suppressing (Default)
B8ZS zero suppression
Impedance
Options:
100 Ohm. (Default)
High Impendance
Span Status
The Span Status is a monitoring field showing the status of the T1 span.
Use the In Service button to bring a span into service.
Use the Out-of-Service button to take a span out-of-service.
TDM-DS1
152
ClientView
The TDM-DS1 object is used to configure T1 physical spans or E1 physical spans.
The option to select an E1 or T1 interface is determined in a flag value during the
Bootstrap Protocol (BOOTP) configuration which is required when downloading your
system software. See Downloading System Software to the MSP.
Do the following to start configuring spans:
Accessing this Pane
Cantata MSP EMS -> New Facility -> New TDM-DS1
ClientView Pane
Field Descriptions
Trunk Type
This field is automatically set to T1 or E1 depending on the type of MSP you have.
Component ID
This field specifies whether the TDM DS1 objects to be configured through the wizard
are part of the Signaling spans or the Bearer spans.
Choices:
Signaling
Bearer
Interface ID
This field specifies the starting interface to configure. Allowable values will be 0 to 3,
if the Component ID is set to ‘Signaling’ and will be 0 –27, if the Component ID is set
to ‘Bearer’.
Choices:
0–3
(If Component ID is set to Signaling)
0 – 27 (If Component ID is set to Bearer)
Comments
153
MSP
Enter any comments you wish to add about this TDM-DS1.
TDM DS3
Use this object to configure a DS3 signaling span.
Accessing this Pane
Cantata MSP EMS -> Logical MSP-> Physical MSP-> Facility->New TDM DS3
ClientView Pane
Steps
1. Right-click Facility and select New TDM DS3.
2. The TDM DS3 pane appears. The Component ID and Interface ID default
in.
3. In the DS3 Framing Type field, leave the default (M13) or select CBIT.
4. Select the Line Length: 0-225 or 266-450 feet.
5. You can enable or disable DS3 and DS1 FEAC Response (FEAC is Far End
Alarm Control).
6. For DS3 Loopback Mode, if you want to perform loopback testing, indicate
Local Loopback or Remote Loopback. Otherwise select No Loopback.
7. For All DS1s Loopback Mode, if you want to perform loopback testing,
indicate Local Loopback or Remote Loopback. Otherwise select No
Loopback. See note below.
Now you can configure a DS3 physical span. See DS3 Physical Span.
To configure multiple DS3 spans, see Example Configurations for DS3 Spans.
There is a specific Far End Alarm Control (FEAC) code to request ALL DS1's be
put in loopback. There are also specific FEAC codes for each span offset.
Therefore, you can request that the far end put all DS1's in loopback (you do
not send 27 FEAC codes, just one, the ALL DS1's code). If I want to request
that just one DS1 offset (for example offset 14) be put in loopback then you
send the code value that corresponds to offset 14.
154
ClientView
Following the request to put DS1 offset 14 in loopback, you CANNOT make
another request for loopback on another span. You first must request span 14
be taken out of loopback and then request loopback on another span.
Related Topics
DS3 Overview
Loopback Diagnostics
Telnet Client
This pane is used to enable a Telnet Client.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP-> Telnet Client
Technical Notes
When configuring a Telnet Client, the following happens:
The client information is sent to this particular “Physical MSP”, also every server that
the client is configured to use will also be configured on this particular “Physical
MSP”. Once the client and the servers have been configured the client will
continuously try connect to the servers it has been configured for.
Telnet Client Pane
Field Descriptions
Telnet Client
This field sets the Telnet Client to Enable or Disable.
Telnet Connection Status
This field is informational only.
Remote IP Address
155
MSP
This field is informational only.
Timing Synchronization Priority List
This object defines the timing sources for a specific physical MSP and the priority of
these sources.
Accessing this Pane
Cantata MSP EMS-> Logical MSP-> Physical MSP -> Timing Sync Priority
List
Maximum Timing Synchronization Priority List Objects
Only one Timing Sync Priority List object is allowed per Physical MSP object.
Technical Notes
When configuring a Timing Synchronization Priority List, the following happens:
The order of the timing sources is configured. Primary Reference and Secondary
Reference is automatically set to Signaling/Timing spans offsets 0 and 1. Primary
and Secondary Loop timing has to be manually assigned to Signaling/Timing spans
offsets 2 and 3 or on any of the offsets of the Bearer spans. Free Running let the
Physical MSP free run on its internal Stratum 3 clock.
ClientView Pane
Field Descriptions
First
This field specifies the first-priority timing source
Choices:
Primary Reference
Secondary Reference
Primary Loop
Secondary Loop
156
ClientView
Free Running
Second
This field specifies the second-priority timing source
Choices:
Primary Reference
Secondary Reference
Primary Loop
Secondary Loop
Free Running
Third
This field specifies the third-priority timing source
Choices:
Primary Reference
Secondary Reference
Primary Loop
Secondary Loop
Free Running
Fourth
This field specifies the fourth-priority timing source
Choices:
Primary Reference
Secondary Reference
Primary Loop
Secondary Loop
Free Running
Fifth
This field specifies the fifth-priority timing source
Choices:
Primary Reference
157
MSP
Secondary Reference
Primary Loop
Secondary Loop
Free Running
Timing Synchronization Priority List Display Table
The table is not used for this object.
Variant Entry
This object is used to add entries to a custom signaling variant.
Once a custom variant is assigned to a stack, you cannot delete an existing
entry in the variant.
Accessing this Pane
Cantata MSP EMS -> New Signaling Variants -> New Signaling Variant ->
New Variant Entry
Technical Notes
PPL components are used to create custom SS7 signaling variants. Detailed
information about the different PPL components and their function is available in the
CCS Developers Guide
ClientView Pane
Field Descriptions
Base Variant
This field indicates the base variant to be used. It is automatically populated based
on the value in the Signaling Variant this entry is being added to.
PPL Component ID
158
ClientView
The PPL component to be configured. See PPL Component IDs for descriptions.
PPL Entity Type
The PPL Entity to be configured.
PPL Timers
PPL Tables
PPL Config Bytes
PPL Entity ID
The PPL Entity ID to be configured.
PPL Entity Value
The Value for the PPL Entity to be configured.
PPL Entity File
The PPL Entity File field is used to select the .cfg file containing the PPL configuration
messages to download for that component. This field is available when the PPL Entity
type selected is PPL Tables or when The PPL Component ID is 0xFF – Generic File.
All the .cfg files should be in the installation folder/directory which by default is (Note
the Variant Name is the name entered in the Signaling Variant pane:
Windows
C:\Program Files\Cantata\common\config\variant\variantname\filename
Linux or Solaris
/opt/cantata/common/config/variant/variantname\filename
PPL Table
When the Component ID is 0xFF – Generic File, the PPL Entity Type field controls at
which point in the configuration the file set by the PPL Entity File field is sent to the
node. The choices for the PPL Entity Type field are:
Stack
Link
Route
Destination
Virtual Channel Groups
159
MSP
Use this object to configure a virtual channel group. Once this object has been
created you have access to the menu options to create a voice circuit on a virtual
Circuit Identification Code (CIC).
Accessing This Pane
Cantata MSP EMS -> New Routing Config > New Virtual Channel
Configuration Groups
ClientView Pane
Virtual Facility
Use this object to configure virtual spans. See Virtual Spans.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Virtual Facility
Virtual Span
Virtual spans are managed by the MSP but terminated outside of MSP.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Virtual Facility ->
New Virtual Span
ClientView Pane
160
ClientView
Vocabulary Index Entry
This pane is used to add voice recorded files to a Vocabulary Index File.
Accessing this Pane
Cantata MSP EMS-> Routing Configuration-> New Vocabulary Index Files->
New Vocabulary Index File -> New Vocabulary Index File Entry
ClientView Pane
Field Descriptions
File Id
This field is automatically populated with the next available number.
File Description
Precise description of the file which will be used to identify it in other panes.
Primary Server Id
The Primary NFS Server that the announcement is stored on.
161
MSP
Secondary Server Id
The Secondary NFS Server that the announcement is stored on.
File Name
The filename of the announcement.
File Format
Raw Data Format:
Wav Format
File Encoding
G711 Alaw
G711 ulaw
G726 32 Kbps ADPCM
32 Kbps OKI ADPCM
24 Kbps OKI ADPCM
G711 Alaw
16 bit linear (11025 Khz mono)
8 bit linear (11025 Khz mono)
Start Offset for File
The offset in bytes where the file is to play from. This is a four-byte data field.
If the Length plus the Offset is greater then the actual file size, the file plays
until the end. If the Offset is greater then the actual file size, a File Open error
occurs.
File Length to be played
The number of bytes to be played.
Vocabulary Index File
This pane creates a new Vocabulary Index File, which is used to identify voice
recorded announcements stored on the Network File System (NFS) server and used
in the playing of treatments.
Accessing this Pane
Cantata MSP EMS-> Routing Configuration-> New Vocabulary Index Files->
New Vocabulary Index File
162
ClientView
Maximum Vocabulary Index File Objects
1
ClientView Pane
Field Descriptions
Vocabulary Index (Index) File Id
This field is automatically populated with the next available number.
Vocabulary Index Filename
This field is automatically populated with (msp_vocab.dat).
Vocabulary Index Files
This is a container object used for setting up an individual Vocabulary Index File
(VIF). For more information about VIFs see File Storage.
Accessing this Pane
Cantata MSP EMS-> Routing Configuration-> New Vocabulary Index Files
VoIP Module
This object configures the Voice over IP spans that correspond to the IP ports on the
VoIP modules that are used to carry the RTP traffic.
If the MSP has two VoIP modules in it, the software will automatically spread all the
licenses evenly across the two modules. This process is done in groups of 32
channels, so if there is an odd number of blocks, module 0 will have the extra
channels.
For example, if you have a 96-channel VoIP license and two VoIP modules, then one
module is allocated 64 channels and the other gets 32 channels.
Steps
Configure the following in the order shown:
1. Network Interface for VoIP Modules
163
MSP
2. IP Bearer Profiles
3. Facility
Accessing this Pane
Configuration -> Cantata MSP EMS -> Facility -> Bearer-IP
ClientView Pane
Maximum VoIP Module Objects
One object is allowed for each module.
Technical Notes
When configuring a VoIP Module, the following happens:
Up to 12 spans (32 channels each) are configured per module depending on how
many IP channels are licensed on the MSP 1010 and depending on the profile
configured.
Field Descriptions
Module ID
This field identifies the ID of the VoIP module to be configured, 0 or 1. The user can
find out the VoIP modules configured by looking into the physical MSP object.
Network Interface
The user has no control on this field. It automatically shows the name of the module
being configured.
Choices:
VoIP Module 0: Port 0
VoIP Module 1: Port 0
164
ClientView
Network IP address
This field is automatically populated with the IP address configured for that VoIP
module under the Network interfaces. If the user attempts to configure the VoIP
module before configuring the Network Interface an error message will be displayed
and the user will have to go back and configure the network interface first.
Module Configuration Profile
The only supported option is Any Vocoder:
G.711
ILBC
Wireless
Start Span
This field specifies the starting span for VoIP configuration. The remainder of the
spans that you licensed will follow this span. For example, if you license three spans
and configure the Start Span to be 24, the VoIP spans are 24, 25, and 26.
Profile Name
This field specifies the IP Bearer Profile that you want to associate with this VoIP
module.
Answer Supervision Mode
Specify of of the following answer supervision modes for the channel:

Propagate Answer to Distant End

Propagate Answer to Distant End and Notify Host of Answer


Notify Host of Answer
No Answer Supervision
Local End Release Mode
Specify whether the local end channel is released or parked when the other end of a
connection releases.
Distant End Release Mode
Specify whether the distant end channel is released or parked when the other end of
a connection releases:
Number of Channels configured
This monitoring field shows how many VoIP channels have been successfully
configured for the module profile.
165
MSP
VoIPModule Display Table
This table displays the status of the IP address /port numbers corresponding to the
configured VoIP channels.
Network Interface For VoIP Modules
Allows you to configure a VoIP module by assigning IP-related parameters, namely,
IP address, Subnet and Gateway, to the module. For configuring a second VoIP
module repeat the steps on this page.
Accessing This Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Network
Interfaces-> New Network Interface
ClientView Pane
Steps
1. Enter the IP Address.
2. Enter the Subnet, if needed.
3. Enter the Default Gateway.
Field Descriptions
Physical Interface
166
ClientView
Use the drop down menu to choose the VoIP module being configured. In case two
VoIP modules are present, a new object for the second VoIP module must be
created.
Logical Interface
Choices:
Redundant Control
Redundant Data
Address Type
The only address type used is IP V4.
IP Address
Assigns an IP address, to the VoIP module.
Subnet
This field is populated using the parameters, given while configuring the MSP.
Default Gateway
Enter the Gateway address so that the VoIP module can be seen outside the local
network.
167
EventView
Introduction to EventView
EventView is a companion product of ClientView that displays system alarms, filters
alarms related to severity and various entities, and logs alarms to files.
EventView Main Window
Getting Help in EventView
You can view the online help for EventView in a web browser from the EventView
application. The HTML-based Help format is designed to run on a wide variety of
browsers and platforms. To access, select Open Help from the Help Menu. The
Monitoring the MSP with EventView book is at the bottom of the MSP help topics.
Next Topic
Restarting a Socket Connection
Exporting Alarms to a Text File
After you have filtered the alarms being displayed in the EventView, you may want
to export these alarms to a text file. Do the following to export the alarm information
that is currently on display in the EventView to a text file.
1. In the EventView select the menu option File-Export Alarms to a Text File.
2. Navigate to the desired location and type in a file name.
168
EventView
Next Topic
Forcing a Log File to Roll-Over
Filtering Alarm Views
To filter the display of alarms according to entities and severity in EventView, do the
following:
1. Click on the Filtered Alarms tab.
2. From the left pane, select the Severity of the alarms that you want to show.
3. Select each Entity for which you want to show alarms.
The right pane becomes re-populated after you press the button, Re-Filter.
Sorting Alarm Fields
To re-order the columns, select the desired column heading and drag it to the
position you want.
Next Topic
Exporting Alarms
169
MSP
Forcing a Log File to Roll-over
To force an EventView log file to roll-over do the following:
1. In the EventView, go to the menu File Force Log File Roll-Over.
2. In the folder where you have installed EventView, you will see that your alarms
file has been saved at the time you forced the log file rollover. By default the
installation folder is:
C:\Program Files\Cantata\MSPUserInterface\EventView, .
A new log file is then automatically created. For more information, see Log Files.
170
AdminView
An Overview of AdminView
The AdminView utility provides for the administration of user privileges (roles) and
authentication. Two areas of control exist in AdminView and a user is granted
permission for each of these areas individually:


User Management Access
Controls the assignment of user access and privileges.
ClientView Access
Includes three levels of access to ClientView actions performed on the MSP.
User Management Access
The user management access controls user authentication and roles. There are two
levels:

Administrator
A user assigned this role is allowed to perform all User Management functions
of the following operations:

add users

assign roles





Basic

remove users
change passwords
self reset password
list one or all users
display current user information
A user assigned this role is only allowed to view his own role and change his
own password. Every user is assigned with this role by default.
ClientView Access
The roles assigned for ClientView determine the actions a user is allowed on the MSP
using ClientView.

Monitor

Provision

Configuration
Allowed to view configuration attributes and system events (alarms, and
traps). Every user is assigned with this role by default.
Allowed to bring components in and out of service.
Allowed to modify configuration on the MSP.
Default Administrator Information
By default there is one user, admin, with the following roles assigned:
171
MSP

User Management Domain

Equipment Management Domain
Administrator
- Monitor
- Provisioning
- Configuration
The default password is admin
Linux Users
After installing the MSP and MSP EMS software, you must edit your /etc/hosts file
(one time only).
There is an existing entry for localhost mapped to 127.0.0.1. You need to add an
entry for the specific IP address of your Linux machine, and it needs to be before the
existing 127.0.0.1 entry.
For example:
135.119.36.142 localhost.localdomain
127.0.0.1
localhost.localdomain
localhost
localhost
ClientView Log In
When a user launches ClientView, they are prompted for a Username and Password.
The default is admin/admin.
See Admin Commands
Re-installation of Software
User account information remains through a re-installation of the MSP system
software.
Assigning Users in AdminView
Unless you specifically assign user privileges, anyone can access the MSP Element
Management System (EMS) in ClientView with full administrative privileges using:
UserName: admin
172
AdminView
Password: admin
Procedure
If you want to assign passwords and roles to individual users who may have access
to the ClientView, do the following.
1. Run AdminManager, which by default is located in:
Windows
C:\Program Files\Cantata\MSPSwitchKit\switchkit\bin
Linux or Solaris
/opt/cantata/MSP/switchkit/bin
2. Open AdminView, which by default is located in:
Windows
C:\Program Files\Cantata\MSPSwitchKit\switchkit\bin
Linux or Solaris
/opt/cantata/MSP/switchkit/bin
3. Login as Administrator
User ID: admin
Password: admin
2. Change the Admin Password
To limit access to the Admin functions, perform the following steps.
a. Type chpwd and press ENTER.
b. Enter the Admin user ID, admin, and press ENTER.
c. Enter a new password and press ENTER.
d. Re-enter the new password and press ENTER.
3. Add a User and assign roles
a. Type adusr and click ENTER.
b. Enter a user ID and click ENTER.
c. Enter a password for the user and press ENTER.
d. Confirm the password and press ENTER.
e. Enter values for the roles to assign to the user (use a comma between the
values). Monitor is a required role for all users.
1 - Administrator
2 - Basic
173
MSP
3 - Configuration
4 - Provisioning
f.
5 - Monitor
Repeat steps a-e for each user.
g. Quit
This text confirms the user was added:
User (name) is added successfully.
Help
For a list of commands, type help
More Information
For more detailed information on Administering User Privileges, see Administering
User Privileges
Next Task
Open ClientView.
Administering User Privileges
Before You Begin
To run AdminView, the AdminManager process must be running.
Start AdminManager
Before you can perform any administrative functions, start the AdminManager.
The default location of AdminManager is:
Linux or Solaris: /opt/cantata/MSP/switchkit/bin
Windows: C:\Program Files\Cantata\MSPSwitchKit\switchkit\bin
Start AdminView
To start AdminView do the following:
1. For Solaris or Linux:
From the following directory: /opt/cantata/MSP/switchkit/bin
type ./AdminView
For Windows:
Click the AdminView icon on your Desktop, or
Click on the AdminView.exe file located at:
174
AdminView
2.
C:\Program Files\Cantata\MSPSwitchKit\switchkit\bin
Login as Administrator
User ID: admin
Password: admin
Admin Tasks
Changing the Admin Password
Adding a User
Changing a Password
Changing a User's Roles
Resetting Your Own Password
Removing a User
Changing the Admin Password
For a more secure system, change the admin user password:
1. Type chpwd and press ENTER.
2. Enter the Admin user ID, admin, and press ENTER.
3. Enter a new password and press ENTER.
4. Re-enter the new password and press ENTER.
Adding a User
To add a user:
1. Type adusr and press ENTER.
3. Enter a user ID and press ENTER.
4. Enter a password for the user and press ENTER.
5. Confirm the password and press ENTER.
6. Enter values for the roles to assign to the user.
Changing a Password
To change a password:
1. Type chpwd and press ENTER.
2. Enter a user ID and press ENTER.
3. Enter a new password and press ENTER.
4. Re-enter the new password and press ENTER.
Changing a User's Roles
To change a user's roles:
175
MSP
1. Type asnrole and press ENTER.
2. Enter the user ID and press ENTER.
3. Enter the values for the roles to assign to the user and press Enter. You must
enter values for all of the roles you want the user to have, even if they are
already assigned.
Resetting Your Own Password
To reset your own password:
1. Type rstpwd and press ENTER.
2. Enter your user ID and press ENTER.
3. Enter a new password and press ENTER.
4. Re-enter the new password and press ENTER.
Removing a User
To remove a user:
1. Type rmusr and press ENTER.
2. Enter the user ID and press ENTER.
Also see Viewing User Information
Viewing User Information
If you are logged into AdminView as the Administrator, you can perform the
following tasks:
Displaying all User Information
1. Type lusrs and press Enter.
A list of all users and their assigned roles are displayed, as shown below:
176
AdminView
Display a Specific User's Information
1. Type lusr and press Enter.
2. Enter the user ID and press Enter.
The user ID and their assigned roles are displayed, as shown below:
Displaying Your Own Information
1. Type id and press Enter.
Your user ID and your assigned roles are displayed, as shown below:
List All Commands
177
MSP
To display a list of all commands:
1. Type lcmd and press Enter.
A list of all available commands is displayed, as shown below:
Displaying Help
To display all available commands with descriptions:
1. Type help and press Enter.
Starting AdminManager on an Alternate RMI port
AdminManager listens for ClientView connections on port 1099, which is the default
port for Java Remote Method Invocation (RMI) applications.
If this port is already in use by another application, you can configure AdminManager
to listen on an alternate port.
To do so, AdminManager must be launched manually from the command line.
Windows
1. Open the file client.properties located by default at:
C:\Program Files\Cantata\MSP\MSPUserInterface\ClientView
The contents of the file should look like:
<?xml version="1.0" encoding="UTF-8"?>
178
AdminView
<properties version="1" reserved="">
<property key="help.0" value="MSP Help:..\WebHelp\MSP.htm" />
<property key="help.1" value="API Help:..\WebHelp_API\API_REF.htm"
/>
<property key="host.0" value="localhost" />
<property key="host.max" value="5" />
<property key="launch_eventviewer" value="false" />
<property key="logfiles" value="C:\Program Files\Cantata/common/log"
/>
<property key="product" value="MSP" />
<property key="rmi_port" value="1099" />
<property key="username.0" value="admin" />
<property key="username.max" value="5" />
</properties>
2. In client.properties file, change the property rmi_port to the desired port
number by editing the line:
<property key="rmi_port" value="Port_Number" />
3. Save the file.
4. Start the AdminManager from the command line and specify the desired port
number, as specifed in the client.properties file, using the -p argument.
\AdminManager -p Port_Number
Example
1. If the desired port number is 1100, change the rmi_port in the
client.properties file to:
<property key="rmi_port" value="1100" />
2. Start the AdminManager as:
\AdminManager -p 1100
179
MSP
UNIX
1. Open the file client.properties located by default at:
/opt/cantata/MSP/MSPUserInterface/ClientView
2. In client.properties file, change the property “ rmi_port “ to the desired port
number by editing the line
<property key="rmi_port" value="Port_Number" />
3. Save the file
4. Start the AdminManager and specify the desired port number, as specifed in
the client.properties file, using the -p argument.
./AdminManager -p Port_Number
180
Hardware Guide
Product Overview
Product Description
The MSP 1010 is an open programmable telecommunications platform. This
telecommunications-grade platform allows the user to develop different applications
such as signaling, voice, and data in a wireless or wireline environment. The MSP
1010 can operate either as a stand alone unit or in a 1+1 redundancy configuration.
The MSP 1010 supports Central Office locations where –48 V DC power is used or in
the enterprise market where AC is the only power source option.
Processor
 IBM 750GX RISC Processor running at 1GHz
 512MBx64 DDRAM @ 200MHz/400MHz (default), up to 1GB
 1MB L2 Cache @1GHz
 32MB Flash
 SDCard
Features
The MSP 1010 provides the following features:
General

Low profile (1U)

Centralized and distributed architecture


Rack mounted or surface mounted
Scalable configurations
CPU


750 MHz CPU
100 MHz SDRAM
Input Power

Rear input power module (AC or DC)

-48 V DC

120/240 V AC, 60/50 Hz
Front Panel
181
MSP
The front panel consists of a PCB that houses 43 bi-color LEDs, an LCD display and
five LCD push button switches used to control the display. You can only retrieve and
monitor information via the front panel.
Rear I/O Panel

Rear I/O interface connectors (signaling and timing, host control, network
interfaces, and redundancy)
Redundancy

1+1 bearer redundancy
Physical Description
The MSP 1010 consists of two mated assemblies: a non field-replaceable docking
station and field-replaceable tray. The tray and docking station mate together to
form a single unit. This unit can either be mounted in a 19-inch rack or set on a
secure, level surface.
Tray
The tray contains the front panel, main board, and either an AC-to-DC or DC-to-DC
power supply. The front panel provides the user with a LCD display and associated
pushbutton switches used to access menus that verify and monitor MSP 1010
operation. The front panel also provides span and alarm status LED indicators and a
power LED indicator.
Docking Station
The docking station rear panel provides AC or DC input power modules and network
I/O interface connectors. Depending on user requirements, various network I/O
interfaces are supported.
Diagram: Front View
182
Hardware Guide
Dimensions
The MSP 1010 is a low-profile unit that consists of two mated assemblies: a docking
station and field-replaceable tray which mates to the docking station to form a single
unit.
It has the following dimensions and weight.
Physical
Specification
Height
4.36 cm (1.72
in.) (1U)
Width
Depth
Weight
43.89 cm
(17.28 in.)
48.26 cm
(19.0 in.)
9 kg (20 lbs.)
183
MSP
Specifications
The MSP 1010 is designed to the following electrical and environmental
specifications.
Electrical Specifications
Electrical
Specification
Range
DC Power
-48 V DC (nominal), 7A
-40 to 60 V DC
AC Power
Range 120-240 V AC,
60-50 Hz, 3A-1.5A
90 to
240 V AC
Environmental Specifications
The temperature, humidity, and altitude of the site must fall within the specifications
listed below. In general, a typical office environment satisfies these conditions. A
temperature-controlled environment is preferable.
Environmental
Temperature,
Operating
Temperature,
Operating (Short
Term)
Specification
0° C to 50° C
-5° C to 50° C
Temperature, Storage
-40° C to 70° C
Shock, Storage
-40° C to 23° C @ 10° C/min
Shock, Operational
184
30° C/hr
70° C to 23° C @ 13° C/min
Hardware Guide
23° C to -40° C @ 30° C/hr
Humidity, Operational
Humidity, Operating
(Short Term)
Humidity, Packaging
Altitude
23° C to 70° C @ 30° C/hr
5% to 85%
5% to 90% but not to exceed
0.24kg water/kg of dry air
90% to 95% relative humidity @
40° C
Up to 1800 m (5905 ft)
Installation Task Summary
MSP Hardware Installation Task Summary
Perform the following steps to install the MSP.
1. Prepare Site
2. Unpack the MSP
3. Mount the MSP
Rack Mounting the MSP
Surface Mounting the MSP
4. Connect Power
Connecting AC Power
Connecting DC Power
5. Connect Ethernet and TDM Cables
After making the I/O interconnections, the MSP 1010 is ready for system setup and
operation. See Operating the MSP 1010.
Cabling for Redundancy
The following topics show recommended cabling for various redundancy scenarios.
185
MSP
Redundant Control
Redundant Data
Redundant Signaling
Redundant SS7
Timing
Reference Timing
Any 2 of the 4 SIGNAL/TIMING ports can be used for Reference Timing, as shown
below. For reference timing pinouts see RJ 48 Connector Pinouts.
Loop Timing
Any of the SIGNAL/TIMING ports or Bearer ports can be used for Loop Timing, as
shown below.
MSP Back Panel
Operation
Front Panel Controls and Indicators
The MSP 1010 front panel consists of a PCB that houses 43 bi-color LEDs, a LCD
display and five LCD pushbutton switches used to control the display. A cable
interfaces the front panel components with the main board.
Controls and Indicators
186
Hardware Guide
Status and Alarm LEDs
Each LED consists of two separate LEDs (red and green). The bi-colored LEDs can be
selected to be red, green, orange (both red and green on) or blinking of any of the
colors. All LEDs are under software control.
The LEDs are grouped as follows:
POWER
This LED that indicates power status. The green LED is hardwired to 3.3V while the
orange LED is under software control.
LED
Color
Off
Description
No 3.3V power
187
MSP
Green
Orange
3.3V power
available
Power warning
ALARM
This LED indicates alarm conditions.
LED
Off
Green
Orange
Red
Color
Description
Not
applicable
No alarms
Minor alarm
Major alarm
SIG/TIMING
These four LEDs indicate T1/E1 spans statuses for the SIGNAL/TIMING 0, 1, 2, 3
connectors.
LED
Color Description
Green
Span is in service and is receiving valid data.
Off
Orange
Red
Span is out of service.
Receiving an orange alarm RAI
Span is in service and is receiving a red alarm
or no span is connected.
TIMING
This LED indicates whether the system timing is free running, locked on an external
timing source or in hold over (lost lock on external timing source, but still synched to
it).
LED
Color Description
Green
Locked on external timing source
Off
Orange
188
Free running
Hold over (lost lock on external timing
source, but still synched to it)
Hardware Guide
ENET CTRL
These two LEDs indicate link and master control of the Ethernet control plane via the
CTRL 0 and CTRL 1 connectors. The mastership is controlled via software while the
link is under hardware control.
ENET DATA
These two LEDs indicate link and master control of the Ethernet data plane via the
DATA 0 and DATA 1 connectors. The mastership is controlled via software while the
link is under hardware control.
ENET SIG
These two LEDs indicate link and master control of the Ethernet signaling plane via
the SIG 0 and SIG 1 connectors. The mastership is controlled via software while the
link is under hardware control.
LED
Color Description
Green
Link established and
active port
Off
Orange
Red
No link established
Link established and
standby port
No link established,
error
AUX
These LEDs are reserved for future use.
SPAN STATUS
These 28 LEDs indicate the E1/T1 bearer span (0 - 27) statuses.
LED
Color
Description
Green
Span is in service and is receiving valid data.
Off
Span is out of service.
Orange
Receiving an orange alarm RAI
Red
Span is in service and is receiving a red alarm
or no span is connected.
189
MSP
LCD Display
The LCD display unit consists of a hierarchical LCD display menu system controlled
by the five push button switches and default menu items. The display allows the user
the capability to retrieve and monitor information.
The LCD display is a standard two line times 24 (2x24) character display with a
backlight. The default display is initially set to show the Product name and unique
chassis ID. The user may optionally set any displayed item as the default by viewing
the item and depressing and holding the Select push button then the Right push
button.
If the host configures a Node Name and ID, the Product Name, Node Name and ID
will become the new default item to be displayed. The default display is displayed
after all the pushbuttons are in the released state for a period for approximately one
minute. The LCD is typically updated when interrupted by a pushbutton input from
the user.
Any item displayed by the front panel can be queried by the Host controlling the MSP
1010.
LCD Push Button Switches
The five push button switches allow the user to select and display information on the
LCD display that are specific to an active MSP 1010 configuration. Each switch is
interfaced to the main board for control and monitoring. Depressing and holding any
of the switches for 500ms (0.5 seconds) will cause that keystroke to be reprocessed,
in a typeomatic fashion.
The push buttons are as follows:
Up


Used to scroll up to a different line of text.
When pressed simultaneously with the Down push button, a hard reset of the
MSP 1010 occurs.
Down

Used to scroll down to a different line of text.

When pressed simultaneously with the Up push button, a hard reset of the
MSP 1010 occurs.

Used to display contents of a menu item if no additional menu items exist to
the bottom of this item.
Left


Right
190
Used to scroll left to a different line of text.
When pressed simultaneously with the Right push button, a soft reset of the
MSP 1010 occurs.
Hardware Guide

Used to scroll right to a different line of text.

When pressed simultaneously with the Left push button, a soft reset of the
MSP 1010 occurs.

Used to display contents of a menu item if no additional menu items exist to
the right of this item.
Select


Used to display the contents of a menu item.
Used to enter and exit the scroll mode, when an item contains scrollable text.
This will allow a menu item to display multiple lines of text by scrolling up and
down and read the entire line by scrolling right and left.
Hard and Soft Resets
The push button switches also allow the user to initiate hard and soft unit resets as
described below.
Hard Reset
Pressing the Up and Down switches simultaneously for 2.5 seconds causes a hard
reset of the CPU. A hard reset reloads the processor configuration registers and the
FPGA configuration data.
Soft Reset
Pressing the Left and Right switches simultaneously for 2.5 seconds causes a soft
reset of the CPU. A soft reset will not reload the processor configuration registers
and the FPGA configuration data.
LCD Menus
The LCD main menus provide the user with means to access, verify, and monitor the
information listed below:

System Info

IP Info


Physical Span Info
Hardware Info
Menu Display/Control
To enter a main menu, the user can either use the Select or Right push button to
select the desired menu.



The items in the selected main menu will be displayed on the first line (item
name line).
The second line will be blank.
When the item is selected, its text will be displayed in one of three ways:
191
MSP
o
o
o
If the text data to be displayed is within 24 characters, the first line
will remain and the data will be displayed on the second line.
If the data is greater than 24 characters, the data will over right the
first line and continue on the second line. In either of these two styles
of presentation the text will be updated every second.
In the third method, the text data may be scrolled left/right and
up/down to a different line of text. When an item contains scrollable
text the user must enable scroll mode by depressing the Select
pushbutton. To end scrolling mode, depress the Select pushbutton
again.
Important! While in the scroll mode the text data will not be updated.
Rear Panel I/O Card Signal and Timing Connectors
The following rear panel I/O card connectors provide the required interfacing so that
the MSP 1010 can operate as a SS7 signaling server.
CTRL 0, CTRL 1 - 10/100 (Ethernet Control Connectors)
These two redundant 10/100BaseT Ethernet connectors provide communication with
an external host or any other device that needs to be secure from the public
network. The connectors do not interface with the internal Ethernet switch and are
physically isolated from any network internal to the MSP 1010. These autonegotiating, full duplex connectors support MDIX (cable cross-over) which eliminates
the need for crossover cables for point-to-point connections.
DATA 0, DATA 1 - 10/100/1000 (Ethernet Data Connectors)
These two redundant 10/100/1000BaseT connectors interface to the internal
Ethernet switch. These connectors are used to communicate to all devices in the MSP
1010 that need to communicate over the public network. All internal connections are
10/100BaseT and are aggregated to 1000BaseT, if required. These auto-negotiating,
full duplex connectors support MDIX (cable cross-over) which eliminates the need for
crossover cables for point-to-point connections.
SIG 0, SIG 1 - 10/100 (Ethernet Signaling Connectors)
These two redundant 10/100BaseT Ethernet connectors interface to the internal
Ethernet switch. These connectors can be logically isolated from the data network or
can be used as connections to the data network via software configuration. The
connectors bring in signaling over IP. These auto-negotiating, full duplex connectors
support MDIX (cable cross-over) which eliminates the need for crossover cables for
point-to-point connections.
SIGNAL/TIMING - 0, 1, 2, 3
(T1/E1 Signaling and Timing Span Connectors)
These four RJ-45 connectors are dedicated for timing and signaling and support
T1/E1 interfaces. Any of the four spans can be used to provide reference timing or
192
Hardware Guide
signaling to the system. These connectors cannot provide bearer traffic to the
system.
REDUNDANCY (1+1 Bearer Redundancy Connector)
A dual stacked SCSI connector provides the interface for 1+1 redundancy between
MSP 1010s. Redundant MSP 1010s are connected by using two cables.
BEARER 0 - 27 (T1/E1 Bearer Span Connectors)
The 28 T1 and 21 E1 bearer spans are accessed through the RJ-45 interface
connectors. The connectors provide T1 with 100 ohm impedance and E1 with 120
ohm impedance.
BEARER TX, RX (DS3 Bearer Span Connectors)
The DS3 bearer spans are accessed through the BNC interface connectors. The
connectors provide DS3 with 75 ohm impedance.
Rear Panel AC and DC Input Power Modules
The MSP 1010 provides AC or DC power options. The type of power depends on the
input power module installed on the docking station and the power supply installed
on the tray.
193
MSP
AC Power Module
The AC power docking station provides an AC input power module with an integrated
fuse, a power switch, and a standard three position female AC input connector. This
connector allows the docking station to connect with all variations of AC outlets using
a standard power cable with a compatible outlet plug. The AC power module
operates on both 120 V AC, 60 Hz and 240 V AC, 50 Hz voltages to support domestic
and international customers.
DC Power Module
The DC power docking station provides a DC terminal module with dual input power
terminals and dual on/off circuit breakers. The DC power module operates on -48 V
DC to support both domestic and international customers.
The user may opt to use dual, redundant -48 V DC feeds or a single, non-redundant
-48 V DC feed. Dual, redundant power is diode protected on the DC power supply on
the tray.
Power, Alarm and Status LEDs
Each LED consists of two separate LEDs (red and green). The bi-colored LEDs can be
selected to be red, green, orange (both red and green on) or blinking of any of the
colors. All LEDs are under software control. Except the green POWER LED which is
hardwired to 3.3V. The LEDs are grouped as follows:
POWER
194
Hardware Guide
This LED indicates power status. The green LED is hardwired to 3.3V while the
orange LED is under software control.
ALARM
This LED under software control used to indicate alarm conditions.
SIG/TIMING
These four LEDs indicate T1/E1 spans statuses for the SIGNAL/TIMING 0, 1, 2, 3
connectors.
TIMING
This LED indicates whether the system timing is free running, locked on an external
timing source or in hold over (lost lock on external timing source, but still synched to
it).
ENET CTRL
These two LEDs indicate link and master control of the Ethernet control plane via the
CTRL 0 and CTRL 1 connectors. The mastership is controlled via software while the
link is under hardware control.
ENET DATA
These two LEDs indicate link and master control of the Ethernet data plane via the
DATA 0 and DATA 1 connectors. The mastership is controlled via software while the
link is under hardware control.
ENET SIG
These two LEDs indicate link and master control of the Ethernet signaling plane via
the SIG 0 and SIG 1 connectors. The mastership is controlled via software while the
link is under hardware control.
AUX
These two LEDs are reserved for future use.
SPAN STATUS
These 28 LEDs indicate the E1/T1 bearer span (0 - 27) statuses via the BEARER 0 27 connectors.
195
MSP
Maintenance
Troubleshooting
This section contains information on troubleshooting issues about power, cooling and
alarm LED indicators.
This section addresses only the most common issues. If you are unable to solve a
problem, record all the information pertaining to your system configuration,
including:

A description of the symptoms and any corrective action already taken

The grounding method




Whether you are using a single power source or redundant power
sources
LAN topology
The version of System Software used with the MSP 1010
A trace of messaging between the host and the MSP 1010
After you record this information, please contact Cantata Technology Technical
Support.
Power
Problem or Symptom
The DC 1010 does not
power up.
196
Cause or Description
Corrective Action
The -48 V DC power
source is not plugged in
Check the power source
for proper output. Replace
The circuit breaker(s) at
the rear of the chassis are
switched to OFF (O).
Switch the circuit
breaker(s) to ON (1).
Hardware Guide
or is not operating.
it if necessary.
Tray not properly seated
in docking station.
Remove tray and reinstall
to ensure the tray is
properly seated. See Tray
Removal and
Replacement.
The –48 V DC power
source is not connected
properly to the DC power
module at the rear of the
chassis.
One of the voltages is
out-of-tolerance on the
low side. Main board
shuts down.
The AC 1010 does not
power up.
If 120/240 V AC power is
used the switch at the
rear of the chassis is
switched to O (Off).
The 120/240 V AC power
source (outlet) is not
plugged in or is not
operating.
The AC power cable is
faulty.
Tray not properly seated
in docking station.
One of the voltages is
out-of-tolerance on the
low side. Main board
shuts down.
The DC 1010 powers up,
but then shuts down.
A circuit breaker has
tripped.
Make sure that the power
source is connected
properly. If necessary,
rewire the connections.
See Connecting DC
Power.
Restart the MSP 1010.
Remove tray and reinstall
to ensure the tray is
properly seated. See Tray
Removal and
Replacement.
Set the switch to 1 (On)
Check the power source
(outlet) for power or
proper output. Check for
tripped circuit breaker.
Reset circuit breaker or
repair as necessary.
Replace cable. See
Connecting AC Power.
Remove tray and reinstall
to ensure the tray is
properly seated. See Tray
Removal and
Replacement.
Restart MSP 1010
Remove tray and reinstall
to ensure the tray is
properly seated. See Tray
Removal and
Replacement.
Reset circuit breaker.
Check the wiring.
See Connecting DC
Power.
197
MSP
The AC 1010 powers up,
but then shuts down.
Cooling
Problem or Symptom
The 1010 is operating, but
the tray over heats.
ALARM LED on front panel
lights red (major) or
orange (minor)
The power source failed or
does not provide the
required level of voltage
and current (–48 V
DC/7A).
Ensure external power
source is functioning at
the required levels. If the
power source is faulty,
repair or replace it.
The fuse in the AC power
module has blown.
Replace fuse. See
Connecting AC Power.
Cause or Description
Corrective Action
An external circuit breaker
has tripped.
Refer to the Hardware
Alarm Module section in
this chapter to access Fan
and Temperature Sensor
alarm descriptions.
Reset circuit breaker.
For Fan and Temperature
Sensor corrective action
information, see Hardware
Alarm Module .
See LCD Display for the
LCD display, Hardware
Info Menu to access Fan
and Temperature Sensor
information.
If ALARM LED remains on,
call Cantata Technical
Support. See Tray
Removal and
Replacement.
Front Panel LED Indicators
Problem or Symptom
The 1010 powers up, but
the ALARM LED lights red
(major) or orange (minor)
The SIG/TIMING 0, 1, 2,
or 3 LED lights red (timing
error) or orange
(reference clock present
but not timing system)
The TIMING LED lights
orange (hold over)
198
Cause or Description
Corrective Action
The E1/T1
SIGNAL/TIMING port 0, 1,
2, or 3 at the rear I/O
panel is not connected to
an external reference
clock.
Refer to the MSP 1010
Developer's Guide to
configure reference
timing.
An alarm condition exists.
Lost lock on external
timing source, but still
synched to it.
The LCD display will
indicate source of alarm
condition. See Refer to
Controls and Indicators. If
ALARM LED is still red, call
Cantata Technical
Support.
Refer to the MSP 1010
Developer’s Guide to
reconfigure external
timing.
Hardware Guide
The ENET CTRL, ENET
DATA, or ENET SIG LED
lights red (no link
established, error)
The SIGNAL SPAN LEDs,
for licensed E1/T1 spans,
light red (major alarm) or
orange (minor alarm)
The Ethernet link has not
been established or has
been lost
Not used in this release.
timing.
Refer to the MSP 1010
Developer’s Guide to
establish or re-establish
link.
Not used in this release.
Hardware Alarm Module
The hardware alarm module supports the 1010 platform by configuring the fans and
temperature senors for optimal cooling and temperature control. It also monitors for
fan and temperature sensor alarm conditions. The four fans are located on the front
panel and the six temperature sensors are located on the main board.
The hardware alarm module monitors the following fan and temperature sensor
parameters:


Fan status: Revolutions per minute (RPM)
Temperature sensor status: degrees Celsius (° C)
API Alarm Messages
The hardware alarms will generate one of the following API alarm messages:


Fan Failure Alarm Message
Temperature Failure Alarm Message
Alarm Status Levels
The hardware alarm module supports three levels of alarm reporting:

Status of a single fan or temperature sensor

Status of all fans and temperature sensors

Status of all fans or all temperature sensors
Fan Alarms
Single Fan


Minor - speed is 10% or -5% than the normal speed (8400 RMP).
Major - speed is less then the lower threshold (1200 RPM).
Multiple Fans

Minor - if two or more of the fans are set to the minor alarm state.

Normal- if a fans exists an alarm state (returns to normal).

Major - if one or more fans are set to the major alarm state.
199
MSP
Important! It is possible to get a Normal Alarm without a corresponding Minor
Alarm. For example, a single minor alarm followed by a return to normal will
generate only a Normal Alarm.
Temperature Sensor Alarms
Single Temperature Sensor

Minor - temperature reading is more than 50° C (alarm clears at 55° C).

Critical - temperature reading is more than 80° C (alarm goes back to Major
at 75° C).

Major - temperature reading is more than 70° C (alarm goes back to Minor at
65° C).
Multiple Temperature Sensors

Indicates the highest alarm on all temperature sensors.
Fan and Temperature Sensor Alarms



Minor - if either the sum of the fans or sum of the temperature sensors is in a
minor alarm state.
Major - if the sum of the temperature sensors is in major alarm state or the
sum of the fans is in a major alarm state.
Critical - only if the sum of the temperature sensors is in a critical alarm
state.
The consequential actions for the above alarm conditions are as follows:


Major - fans increase speed to full on.
Critical - system resets.
Tray Removal and Replacement
The tray is the only field replaceable unit of the MSP 1010.
The power supply is part of the tray, therefore, you do not have to remove the
docking station from the rack and uncable everything.
Procedures
To remove the tray from the docking station and then replace it, do the following:
Removal of a Tray with an AC Power Module
1. Set power to OFF (O) at rear of docking station.
2. Loosen the two ejector captive fasteners located on each side of the front
panel.
3. Lift the ejectors upward and pull to unseat tray from docking station.
4. Slide tray completely out. If returning the tray to Cantata, contact Cantata
Technical Support.
200
Hardware Guide
Removal of a Tray with a DC Power Module
The DC tray is hot-swappable, so there is no on/off switch on the rear panel.
1. Loosen the two ejector captive fasteners located on each side of the front
panel.
2. Lift the ejectors upward and pull to unseat tray from docking station.
3. Slide tray completely out. If returning the tray to Cantata, contact Cantata
Technical Support.
Replacement
1. Align rail on each side of the tray with the guides on the inside of the docking
station.
2. Ensure the ejectors are in the up position.
3. Slide the tray in until the power connectors and signal connectors initially
mate. The ejectors will start to move down.
Important! The guides only provide gross alignment to the power and signal
connectors. The guide pins on the main board and I/O card are self aligning and
provide exact alignment for the connectors.
Important! The tray guides also acts as the conduit for any Electrostatic Discharge
(ESD) as the tray initially mates with the docking station.
Do not force the tray if
any resistance occurs
when mating with the
docking station. Using
undue force could
damage the unit.
4. When the tray is seated and the connectors are mated, push the ejectors
down and tighten captive fasteners.
5. For the AC tray, set power to ON (1) at rear of docking station.
Diagram: Tray Removal and Replacement
201
MSP
Installing a VoIP or Media Module
Follow this procedure to install a second VoIP module on the MSP motherboard.
Required Tools and Parts
Follow this procedure to add a VoIP or Media module on the MSP.
Caution: Electrostatic Discharge Protection (EDP) must always be used.
Electrostatic Discharge (ESD) protective straps, shoes, or mats must be used
when working with electronic components. Electrostatic discharge from your
body can damage integrated circuits during installation.
Required Tools and Parts

#1 Phillips head screwdriver (customer supplied)

VoIP module or Media module.

4 Phillips pan head screws
Steps
1. Set power to OFF (O) at rear of docking station.
2. Remove Motherboard Tray. See Diagram:Removing_the_Tray.
c. Loosen the two ejector captive fasteners located on each side of the
front panel.
d. Lift the ejectors upward and pull to unseat the tray from the docking
station.
202
Hardware Guide
e. Slide the tray out.
3. Install the module. See Diagram: Locating VoIP Module Position
a. Align the rail on each side of the tray with the guides on the inside of
the docking station.
b. Ensure the ejectors are in the up position.
c. Slide the tray in until the power connectors and signal connectors
initially mate (the ejectors will start to move down).
d. When the tray is seated and the connectors are mated, push the
ejectors down and tighten captive fasteners.
4. Install the module on motherboard
Caution: When pressing the module onto the motherboard do not press on the
components installed on the module, but rather press on an open area on the
edge of the Printed Circuit Board itself.
a. Position the module over the four standoffs.
b. Align the connectors on the module with the connectors on the
motherboard and press together. Caution: The connectors must be
properly aligned and fully seated, to ensure a trouble-free installation.
c.
Attach the module with the four (4) Phillips pan head screws. Caution:
Do not over tighten the screws.
5. Re-insert Motherboard Tray
Do not force the tray if any resistance occurs when mating with the docking
station. Using undue force could damage the unit.
The guides only provide gross alignment to the power and signal connectors.
The guide pins on the main board and I/O card are self-aligning and provide
exact alignment for the connectors.
The tray guides also act as the conduit for any Electrostatic Discharge (ESD) as
the tray initially mates with the docking station.
a. Align the rail on each side of the tray with the guides on the inside of the
docking station.
b. Ensure the ejectors are in the up position.
c. Slide the tray in until the power connectors and signal connectors initially
mate (the ejectors will start to move down).
d. When the tray is seated and the connectors are mated, push the ejectors
down and tighten captive fasteners.
6. Set power to ON (1) at rear of docking station.
Diagram: Removing the Tray
203
MSP
Diagram: VoIP Module Positions
Important: If only one VoIP module is to be installed, it must be at Position 0.
204
Hardware Guide
Replacing a Fuse
Complete the following steps to remove and replace the fuse.
Important Notes


Replace the fuse with only a Cantata-supplied fuse or equivalent: 3 Amp Slo-Blo
fuse, type 3AG.
For safety, the integrated fuse can only be replaced when the power cord is
removed.
Procedure
1. Ensure the power switch on the AC power module is set to O (Off).
2. Unplug AC power cord.
3. Using a small flat bladed screwdriver, open the hinged fuse cover.
4. Remove the fuse holder using the screwdriver and replace fuse in holder. The
fuse only mounts on one side of the cartridge.
5. Install the fuse holder into the AC power module with the fuse facing down.
Industry Compliance
Compliance Overview
The MSP 1010 meets the following national and international standards.
To view the China Restriction of Hazardous Substances (RoHS) for Model 1010, click
here.
To view Cantata compliance to China Restriction of Hazardous Substances (RoHS),
click here.
To view the Cantata Declaration of Conformity, click here.
FCC Regulatory Compliance Notices
This section identifies the United States Federal Communications Commission
compliance notices. See also Electromagnetic Interference Statement.
Federal Communications Commission Part 68 Requirements
This equipment complies with FCC rules, Part 68. On the back of this equipment is a
label that contains, among other things, the FCC Registration Number. When you are
205
MSP
ready to install this unit, contact your local telephone company and supply them with
the following information:
Standard Jack(s) for connection to the network: RJ48
Service Order Code(s): NA
Facility Interface Code(s) (FIC): NA
FCC ID#: US: 1RHXDNAN XL1010
Should this equipment cause harm to the telephone network, the telephone company
shall, where practicable, notify the customer that temporary discontinuance of
service may be required; however, where prior or written notice is not practicable,
the telephone company may discontinue service forthwith, if such action is
reasonable in the circumstances. You will be informed of your right to file a complaint
with the FCC.
The telephone company may make changes in its communications facilities,
equipment, operation procedures, where such action is reasonable, required in the
operation of its business, and is not inconsistent with the rules and regulations of the
Federal Communications Commission. If they do, you will be notified in advance to
give you an opportunity to maintain uninterrupted telephone service.
Do not attempt to repair or modify this equipment. If defective, return it to the
person from whom it was purchased who will in turn arrange to return it or to have it
repaired by the manufacturer of his authorized agent. The telephone company may
ask that you disconnect this equipment from the network until the problem has been
corrected or until you are sure that the equipment is not malfunctioning. If trouble is
experienced, disconnect this equipment from the telephone line to determine if it is
causing the malfunction. If equipment is determined to be malfunctioning, its use
shall be discontinued until the problem has been corrected.
Affidavit Requirements for Connection to Digital Services




An affidavit is required to be given the telephone company whenever digital
terminal equipment without encoded analog content and billing protection is
used to transmit digital signals containing encoded analog content which are
intended for eventual conversion into voice band analog signals and
retransmitted on the network.
The affidavit shall affirm that either no encoded analog content or billing
information is being transmitted or that the output of the device meets Part
68 encoded analog content or billing protection specifications.
End user/customer will be responsible to file an affidavit with the CPE to a
1.544 Mbps or subrate digital services.
Until such time as subrate digital terminal equipment is registered for voice
applications, the affidavit requirement for subrate services is waived.
Affidavit for Connection of Customer Premises Equipment to 1.544 MBPS and/or
Subrate Digital Services
For the work to be performed in the certified territory of
_______________________________ (Telco Name)
State of _________________________
County of _______________________
206
Hardware Guide
I, ______________________________ (name)
________________________________ (business address)
___________________ (telephone number) being duly sworn, state:
I have responsibility for the operation and maintenance of the terminal equipment to
be connected to 1.544 Mbps and/or ____________ subrate digital services. The
terminal equipment to be connected complies with Part 68 of the FCC rules except
for the encoded analog content and billing protection specifications. With respect to
encoded analog content and billing protection:
( ) I attest that all operations associated with the establishment, maintenance, and
adjustment of the digital CPE with respect to analog content and encoded billing
protection information continuously complies with Part 68 of the FCC Rules and
Regulations.
( ) The digital CPE does not transmit digital signals containing encoded analog
content or billing information which is intended to be decoded within the
telecommunications network.
( ) The encoded analog content and billing protection is factory set and is not under
the control of the customer.
I attest that the operator(s)/maintainer(s) of the digital CPE responsible for the
establishment, maintenance, and adjustment of the encoded analog content and
billing information has (have) been trained to perform these functions by successfully
having completed one of the following: (Check appropriate blocks)
( ) A. A training course provided by the manufacturer/grantee of the equipment
used to encode analog signals; or
( ) B. A training course provided by the customer or authorized representative,
using training materials and instructions provided by the manufacturer/grantee of
the equipment used to encode analog singles; or
( ) C. An independent training course (e.g., trade school or technical institution)
recognized by the manufacturer/grantee of the equipment used to encode analog
signals; or
( ) D. In lieu of the preceding training requirements, the operator(s)/maintainer(s)
is (are) under the control of a supervisor trained in accordance with
___________________ (circle one) above.
I agree to provide _________________________________ (Telco’s name) with
proper documentation to demonstrate compliance with the information as provided
in the preceding paragraph, is so requested.
______________________________________________ Signature
______________________________________________ Title
______________________________________________ Date
Subscribed and sworn to before me
This day of _________________, 20___
________________________________
Notary Public
My commission expires: ____________________________
207
MSP
Electromagnetic Interference Statement
Click here to view the United States Federal Communications Commission and the
Canadian Department of Communications statements on Electromagnetic
Interference (EMI.)
Declaration of Conformity
To get more information on the United States European Declarations of Conformity,
contact a Cantata salesperson for the latest copies.
208
Hardware Guide
Restriction of Hazardous Substances Directive (RoHS) Declaration of Compliance
Click here to view the European Union Restriction of the Use of Certain Hazardous
Substances in
Electrical and Electronic Equipment, Directive 2002/95/EC (RoHS).
209
Intelligent Network & Wireless Protocols Overview
Introduction
As software developers create more applications that are being deployed and
maintained in mobile and intelligent networks, Cantata Technology is keeping pace
by introducing support for intelligent network (IN) and wireless protocols in the MSP
1010. Cantata’s Excel API supports IN application development enabling Excel API
customers to create sophisticated IN applications for deployment on the MSP 1010.
For customers who prefer to use SwitchKit as their application development tool, the
IN protocols that Cantata supports can communicate with a MSP 1010 using
SwitchKit API and the SwitchKit component, Low-Level Communicator (LLC). Using
SwitchKit to create IN applications can significantly reduce the development cycle,
especially with the availability of two new components that perform abstraction from
the signaling foundation technologies.
The MSP 1010 currently operates effectively as a Service Node (SN) in many
production networks. The addition of IN protocols allows the MSP 1010 to also serve
effectively as:


A Service Control Point (SCP)
An Intelligent Peripheral in emerging Intelligent Networks.
IN and Wireless Protocols
Cantata’s MSP 1010 initially supports five protocols, developed by IntelliNet
Technologies, to access IN and wireless networks. Additional capabilities will be
included in future releases.
ITU/ETSI standard

Customized Application for Mobile network Enhanced Logic (CAMEL)

Intelligent Network Application Protocol (INAP)

Universal Mobile Telecommunications System- Mobile Application Part (UMTSMAP) which includes Global System for Mobile communication - Mobile
Application Part (GSM-MAP)
TIA/ANSI standard

ANSI - 41

AIN (planned for future availability)

Wireless Intelligent Network (WIN)
Advanced Intelligent Network (AIN) conforms to BELLCORE Generic Requirements
AIN0.2 GR 1299 (Issue 4, 09/97).
For more details on IntelliNet’s IN protocols see, the following documents (Available
from Cantata Technology):

CAMEL User’s Guide, document part number P_EXCL_CAMEL_UG_2.0

WIN User’s Guide, document part number P_EXCL_WIN_UG_2.0

UMTS MAP User’s Guide, document part number P_EXCL_UMTS_MAP_UG_2.0
210
Intelligent Network & Wireless Protocols Overview


ANSI 41D User’s Guide, document part number P_EXCL_AS41D_UG_2.0
INAP User’s Guide, document part number P_EXCL_INAP_UG_2.0
The IN protocols are implemented on the MSP 1010 through the offering of
IntelliNet’s protocol-specific encoder/decoder software (codecs). See Codecs for a
description of the codecs used with each IN protocol.
SwitchKit IN and Wireless Components
Cantata offers two optional SwitchKit layers that perform abstraction/adaptation
from the signaling foundation technologies:


SwitchKit TCAP Abstraction Layer (SKTAL)
SwitchKit Interface Module (SKIM)
Use of the SwitchKit TCAP Abstraction Layer and the SwitchKit Interface Module is
intended to simplify the work required for the application developer. Use of these
components is optional; however, SKIM requires the use of SKTAL.
SwitchKit TCAP Abstraction Layer
The SwitchKit TCAP Abstraction Layer is used to create a generic view of the MSP
1010 platform’s TCAP layer.
SwitchKit Interface Module
The Switchkit Interface Module provides an API interface to abstract services from
the TCAP and SCCP layers to a transaction-based application.
The IN application, codecs, and SwitchKit reside on the host computer, using the SS7
services of the MSP 1010.
The next two diagrams show where the IntelliNet IN and wireless protocols and
abstraction layers fit into the MSP 1010 architecture.
SwitchKit Users
In addition to implementing the required service logic, the application developer
must handle the message flow between the IntelliNet codecs and the SS7 protocol
stack on the MSP 1010, using SKIM and SKTAL (as desired) and the SwitchKit API
and LLC components.
Threadsafe
All elements of this offering support threadsafe operations.
Scenario for SwitchKit Users with SKIM and SKTAL
211
MSP
Scenario for SwitchKit Users with SKTAL Only
Excel API Users
Application developers who do not use the SwitchKit Interface Module and or the
SwitchKit TCAP Abstraction Layer must implement equivalent functionality to manage
communication with the MSP 1010, handle the TCAP dialogues, and format messages
to and from the codec APIs.
The IN and wireless application and codecs reside on the host computer using the
SS7 services of the MSP 1010.
212
Intelligent Network & Wireless Protocols Overview
Scenario for Excel API Users
In addition to implementing the required service logic, the application developer
must handle the message flow between the IntelliNet codecs and the SS7 protocol
stack on the MSP 1010, using Excel API.
Codecs
The IntelliNet IN and wireless codecs are provided to developers as application layer
APIs in the form of header files and software libraries of protocol-specific ASN.1
encoders/decoders. The encoders/decoders are delivered to customers in binary
format, available for linking with the application developer’s software and
(optionally) SwitchKit to form an executable image. These libraries execute on a host
computer, not the MSP 1010.
Performance & Reliability
The IN and wireless protocols are capable of operating in redundant, partially
redundant, and non-redundant MSP 1010 environments. This includes optional
redundancy for each of the following components:

Host machine

SS7

LLC
Supported Operating Environments and Compatibility
This section describes the operating environments that are supported by Intelligent
Network (IN) and wireless protocols.
Compatibility
Each of the IN and wireless codecs is supported in the following host
hardware/operating system environments:
213
MSP
Hardware/Operating System Requirements
Operating
System
IN & Wireless Protocols are
supported on...
Linux
Red Hat Linux version 8.0 for INTEL
platform
Solaris
HP-UX
Version 8.0 for the SPARC platform
Version 11.0
The next table shows the compilers supported by IN and wireless protocols in a
development environment.
Compiler Requirements
Operating
System
Applications must be built using...
Linux
GNU gcc complier packaged with Red Hat Linux
8.0 (gcc 3.2)
Solaris
Sun Forte (Sun Workshop 6, update 2 C++ 5.3)
HP-UX
HP aC++ compiler 3.3
Versions of the IN and wireless protocols are independent of SwitchKit and MSP 1010
system software versions, so that updates to the IN and wireless protocols will not
require updates to either SwitchKit or the MSP 1010 system software to support the
same level of functionality. Similarly, updates to SwitchKit and MSP 1010 system
software versions will not require updates to the IN and wireless protocols to support
the same level of functionality.
Benefits of using SwitchKit to develop an IN/Wireless Application
SwitchKit provides a comprehensive, high-level and open programming environment
for the application development and maintenance of the MSP 1010. SwitchKit
includes a feature-rich operation, administration, maintenance, and provisioning
(OAM&P) system and a high-level API suite, freeing developers to concentrate on
revenue-generating applications and services.
SwitchKit greatly reduces the time and cost of deploying and maintaining switchbased solutions - providing a quantitative edge in markets that are increasingly
competitive, dynamic, global, and deregulated. SwitchKit enables the development
and implementation of custom, highly-differentiated services, providing a qualitative
edge in response to the demands of the telecommunications marketplace.
Application Development
IN/wireless application developers can use either the SwitchKit Interface Module and
or the SwitchKit TCAP Abstraction Layer, in conjunction with the SwitchKit API.
Without these layers, developers must create applications that can process PPL Event
messages to and from the MSP 1010. The application would use normal SwitchKit
API procedures to connect to the LLC and register for messages. Then, through the
214
Intelligent Network & Wireless Protocols Overview
initialization of the SwitchKit Interface Module, the application would register a
default handler for all incoming IN Messages and notifications.
SwitchKit API
The SwitchKit API is a library of function calls used to communicate to both the LLC
and the MSP 1010. Both the SwitchKit TCAP Abstraction Layer and the application
will use the SwitchKit API to communicate to LLC.
The Role of LLC
The LLC is responsible for connection to the MSP 1010, application redundancy,
channel and channel group management, as well as message routing to multiple
applications. See Scenario for SwitchKit Users with SKIM and SKTAL for additional
information. For IN applications the LLC is responsible for routing TCAP messages
(PPL Events) to the proper application based on Stack ID (local PC) and subsystem
number (SSN).
OAM&P
Operation, administration, maintenance, and provisioning (OAM&P) for all aspects of
all components required for the IN and wireless protocols is handled by SwitchKit.
Intelligent Network and Wireless Protocols
This section describes Cantata Technology’s software support for mobile and wireline
communications networks. The Intelligent Network (IN) and wireless protocols
offered by Cantata were developed by IntelliNet Technologies, a leading provider of
IN infrastructure software. See IntelliNet Codec Installation Guide. The MSP 1010
supports five IntelliNet protocols to access IN and wireless networks:
Codecs
Codec Name
Description
Standard
Universal Mobile Telecommunications
System - Mobile Application Part
(UMTS-MAP) which includes Global
System for Mobile communication Mobile Application Part (GSM-MAP)
See Documentation.
Phase
1,2,2+, & 3
UMTS MAP - 3GPP TS
29.002 V4.2.1 (2000-12)
Wireless Intelligent Network (WIN)
See Documentation.
Phase I & II
TIA/EIA/IS 771
ANSI - 41 See Documentation.
ANSI - 41D
Intelligent Network Application
Protocol (INAP) CS-1
CS-1
TIA/EIA-41.(1-6) D Dec
1997
Customized Application for Mobile
network Enhanced Logic (CAMEL) See
Documentation.
See Documentation.
Phase 2, 3,
&4
CS-2
3GPP TS 29.078 (v5.1.0
Release 5)
3G TS 29 002 v3.4.0
(2000-3)
TIA/EIA/IS 826
ITU-T Q.1218, release
1095
ITU-T Q.1228, release
997
215
MSP
Matrix
The matrix below shows the IN wireline and wireless protocols supported by
telecommunications standards.
CAMEL
A European Telecommunications Standards Institute (ETSI) standard messaging
protocol for including IN functions into GSM mobile networks. CAMEL is used when
roaming between networks, allowing the home network to monitor and control calls
made by its subscribers. CAMEL API allows roaming subscribers access to their full
portfolio of Intelligent Network (IN) services. CAMEL is a relatively inexpensive
method of allowing telecom operators to add new services to the existing network
infrastructure.
A few typical applications include:

Pre-Paid Calling

Location dependent services

Personal Numbering
UMTS/GSM-MAP
An ETSI standard messaging protocol used in UMTS/GSM wireless networks to
communicate among network elements to support user authentication, equipment
identification, and roaming:
Mobile Switching Center (MSC)
Home Location Register (HLR)
Visitor Location Register (VLR)
Equipment Identity Register (EIR)
Short Message Service Center (SMSC)
Authentication Center (AuC)
216
Intelligent Network & Wireless Protocols Overview
Typical applications include:

Intelligent Peripheral (IP)

Enhanced Services Platform

Service Control Point (SCP)
The IntelliNet MAP protocol layer provides an easy to use library of C++ classes that
can be utilized to develop GSM Mobility Applications.
WIN
A Telecommunications Industry Association/American National Standards Institute
(TIA/ANSI) standard messaging protocol that enables subscribers in ANSI-41 based
wireless networks to use intelligent network services. WIN also supports the network
capabilities to provide wireless activities such as automatic roaming, incoming call
screening, and voice-controlled services.
Intellinet’s WIN protocol facilitates the development of platform-independent,
transport-independent and vendor-independent WIN services such as:

Hands-Free

Voice-Controlled Dialing (VCD)







Voice-Controlled Services
Voice-Controlled Feature Control (VCFC)
Voice-Based User Identification (VUI)
Incoming Call-Restriction/Control
Calling Name Presentation (CNAP)
Password Call Acceptance (PCA)
Selective Call Acceptance (SCA)
ANSI - 41
A TIA/ANSI standard messaging protocol used in Code-Division Multiple Access
(CDMA) and Time Division Multiple Access (TDMA) wireless networks primarily in the
Americas and parts of Asia to communicate among network elements (MSC, HLR,
VLR, EIR, SMSC) to support inter-system hand-off, automatic roaming,
authentication, and supplementary call features. The ANSI 41D specification
(formerly known as IS-41) is primarily used in the wireless network to provide
services such as automatic roaming, authentication, intersystem hand-off, and short
message service. All wireless network elements use this messaging protocol to
communicate.
Typical applications include:

Intelligent Peripheral (IP)

Enhanced Services Platform

Service Control Point (SCP)
INAP
Intelligent Network Application Protocol (INAP), an ITU-T specification, allows
applications to communicate between various nodes/functional entities of a wireline
217
MSP
Intelligent Network. The protocol defines the operations required to be performed
between nodes/functional entities for providing Intelligent Network services.
A few typical applications include:






Call Center solutions requiring handling of special service numbers (800 &
900 services)
Local Number Portability
Calling Card registration and authentication including charging and fraud
management capabilities
Interactive Voice Response (IVR) systems for small and large business
segments
Calling Name delivery
Service Management systems for study of traffic patterns as well as
generating call reports and billing records at central administration and billing
center.
Future availability of AIN protocol
Cantata plans to offer the Advanced Intelligent Network (AIN) protocol to support
ANSI-based, wireline Intelligent Networks in future releases.
Some examples of applications using AIN include:

Toll-free dialing and FreePhone facilities for subscribers

Universal Access Number (UAN)





Virtual Private Network Services for closed user groups operating over
geographically distributed facilities
Split Charging capability enabling the subscriber to separately charge
personal and business calls made from the same instrument
Call Rerouting and Redistribution based on traffic volume and/or time of day
suitable for telemarketing businesses and reservation centers with multiple
locations.
Prepaid and Calling Card services
Tele-voting, whereby franchisees may cast their choice over secure voice
response systems, preserving privacy, possible travel time as well as avoiding
human tampering of results and other malpractices.
Licensing of Intelligent Network and Wireless Protocols
Operation of the Intelligent Network (IN) protocols on the MSP 1010 requires two
separate license keys:


SS7 Product License SCCP/TCAP
IntelliNet Codec License
These license keys can be ordered through Cantata Technology Sales, and are based
on the following customer-supplied information:

218
Chassis ID
Intelligent Network & Wireless Protocols Overview


Unique serial number of the specific MSP 1010 chassis running the SCCP/TCAP
stack. In a redundant configuration both platform's serial numbers are
required.
Host ID
Manufacturer's unique identification number for the customer-supplied host
computer
Codecs
Required IN protocol stacks. Valid values are UMTS MAP, CAMEL, WIN, and
ANSI-41 and INAP. Future values will include AIN.
These license keys are independent from the codec version, host operating system,
and MSP 1010 System Software release.
Upgrades
Upgrades for additional Codecs will result in new license keys for both the SS7
Product License SCCP/TCAP and the IntelliNet codec license, superseding the
previous license keys for the specified Chassis ID and Host ID.
Pricing
Pricing for these license keys is available from Cantata Technology Sales.
SwitchKit Intelligent Network and Wireless Components
To integrate the IntelliNet Intelligent Network (IN) and wireless protocol stacks with
the MSP 1010, application developers can make use of two basic layers to reduce
their development cycle when using SwitchKit as their application development tool.
These abstraction layers are:


SwitchKit TCAP Abstraction Layer (SKTAL):
Formats data for the IntelliNet codecs interfacing with the MSP 1010 TCAP
stack.
SwitchKit Interface Module (SKIM):
Hides the TCAP stack from the application developer.
These abstraction layers are supported for both ANSI and ITU TCAP standards.
SwitchKit TCAP Abstraction Layer
The SwitchKit TCAP Abstraction Layer presents a generic view of the MSP 1010 TCAP
layer by translating between PPL Events and TCAP messages. This is a modular layer
that is directed to applications that require explicit control over TCAP operations.
With the SwitchKit TCAP Abstraction Layer the following is provided:

A consistent programming paradigm to an existing SwitchKit user

Dialogue ID allocation and management capabilities



A simple API to handle TCAP operations
Error handling and detection capability for transaction level protocol errors
that can be handled transparently
Notification and alarm generation mechanism to the application
219
MSP
The SwitchKit TCAP Abstraction Layer is delivered in binary format. To form an
executable image using the defined functionality this layer is required to be linked
with:

The application developer’s software

SwitchKit


The required codecs
SKIM (optional)
SKTAL APIs
The following is a list of APIs used with the SwitchKit TCAP Abstraction Layer.
sktal_initializeTCAP()
sktal_terminateTCAP()
sktal_registerTCAPSSNHandler()
sktal_unregisterTCAPSSNHandler()
sktal_allocateTCAPDialogID()
sktal_setTCAPDialogueHandler()
sktal_clearTCAPDialogHandler()
sktal_sendTCAPDialog()
sktal_recvTCAPDialog()
sktal_sendTCAPComponent()
sktal_recvTCAPComponent()
The SwitchKit TCAP Abstraction Layer employs the handler function SwitchKit model
for event handling.
SwitchKit Interface Module
The SwitchKit Interface Module differs from the SwitchKit TCAP Abstraction Layer
primarily in its ability to abstract details of the TCAP protocol for an application.
The SwitchKit Interface Module provides a consistent programming paradigm to
existing SwitchKit users. This module’s APIs abstract details of the SS7 TCAP
protocol. This interface can be used by application developers to reduce their
development cycle. The SwitchKit Interface Module has a default class for each type
of operation and knows which operations have linked operations. If the module is
unable to handle a certain message flow, the application can use the SwitchKit TCAP
Abstraction Layer. The capabilities of the SwitchKit Interface Module are summarized
as follows:

Abstracts details of the TCAP protocol for an application.

Keeps track of active TCAP dialogs





220
Formats the TCAP messages into a message list
Invokes entities, such as, IDs, operation types, and operation codes.
Provides error handling and detection capability for transaction level protocol
errors transparently.
Provides notification and alarm generation mechanism to the application.
Tracing
Intelligent Network & Wireless Protocols Overview
The SwitchKit Interface Module is delivered in binary format. To form an executable
image using the defined functionality this module is required to be linked with:

The application developer’s software

SwitchKit API


The required codecs
SKTAL
SKIM APIs
The following is a list of APIs used with the SwitchKit Interface Module. These APIs
employ the handler function SwitchKit model for event handling.

SKIM_Api::Initialize()

SKIM_Api::Send()










SKIM_Api::Terminate()
SKIM_Api::SendSSNInService()
SKIM_Api::SendSSNOutOfService()
SKIM_Api::SendReject()
SKIM_Api::CancelOperation()
SKIM_Api::SendPreArrangedEnd()
SKIM_Api::SetTransHandler()
SKIM_Api::ClearTransHandler()
SKIM_Api::EnableTracing()
SKIM_Api::DisableTracing()
Wireless Call Flow
The next call flow provides an example of an SMSC application sending and receiving
SMS.
221
MSP
222
SwitchKit Installation & Maintenance
Introduction
SwitchKit
SwitchKit provides a comprehensive, high-level and open programming environment
for the application development and maintenance of the MSP 1010. SwitchKit
includes a feature-rich OA&M (operations, administration and maintenance) system
and a high-level API suite, freeing developers to concentrate on revenue-generating
applications and services. Because it facilitates the development and integration of
Cantata Technology switch-based telephony applications, it delivers important
benefits to both system integrators and service providers.
SwitchKit greatly reduces the time and cost in the deploying and maintaining switchbased solutions - providing a quantitative edge in markets that are increasingly
competitive, dynamic, global, and deregulated. SwitchKit enables the development
and implementation of custom, highly-differentiated services, providing a qualitative
edge in response to the demands of the telecommunications marketplace.
SwitchKit is implemented in a modular manner. It segregates administration and
configuration functions from the application, enabling multiple services to utilize a
single, consistent OA&M system. Since an application developed using SwitchKit does
not need to concern itself with OA&M overhead, it can be simpler, modular, more
efficient, and easily maintained. Furthermore, applications are portable and scalable
because they operate independently of the switch utilities. The result is that
developers can implement applications and services with better price performance
and superior flexibility over a wide range of market needs and sizes.
SwitchKit supports resource sharing and redundancy. It lets multiple independent
applications efficiently share a single switch by handling the channel sharing and
message routing automatically. Resources such as cards, lines and nodes can be
added to the environment while an application is running, and configured
automatically. Thus, multiple solutions and facilities can be developed and delivered
through a single, open and programmable switch platform — Cantata Technology's
platform — for superior return on investment and reliability in all aspects of the
services creation and provisioning process.
SwitchKit has been developed based on the C++ programming language and
industry-standard communications protocols, and is available on a variety of
platforms. It is designed to be easily scalable and upgradable, so that modules can
be added and or extended, enabling easy growth of existing services and addition of
new ones - without redesign.
SwitchKit features include




modules that administer, configure, and automatically manage the operation
of switches.
redundant low-level communicators that eliminate any single point of failure.
a C and C++ API suite for the MSP 1010, based on an industry-standard call
processing model.
ClientView, a graphical user interface for configuring, monitoring and
maintaining the MSP 1010.
SwitchKit has been designed to support the performance of Cantata hardware. As a
result, applications can make better and more efficient use of MSP 1010 resources.
223
MSP
Running on either Windows® or UNIX® platforms, SwitchKit provides a
comprehensive suite of tools.
Application Checklist
SwitchKit provides the following core functional areas needed for your application to
work effectively with the Multi-Services Platform.

Host Connection

Message Management






Communications
Configuration
Alarm Manager
Real-time Logging
Real-time MSP Management
User Interface
After all the above functional areas have been addressed in your application, you
may now add call processing to your application.
SwitchKit Features and Components
Description
SwitchKit is a software package that consists primarily of eight modular components
that function on an external host computer. SwitchKit acts as an application server,
communicating with all applications and the Multi-Services Platform (MSP) through a
Transmission Control Protocol/Internet Protocol (TCP/IP) interface.
SwitchKit also provides a comprehensive, high-level and open programming
environment for the application development and maintenance of the MSP. SwitchKit
includes a feature-rich OA&M (operations, administration, and maintenance) system
and a high-level API suite, freeing developers to concentrate on revenue-generating
applications and services. Because it facilitates the development and integration of
Excel switch-based telephony applications, it delivers important benefits to both
system integrators and service providers.
In supporting multi-node MSP systems, SwitchKit connects to each node.
Main Components
SwitchKit contains the following components:

Low-Level Communicator (LLC)

DataManager




224
SwitchManager
Application Programming Interface (API)
AdminManager
ClientView
SwitchKit Installation & Maintenance


EventView
AdminView
For more information on each component see the SwitchKit Introduction and
Installation Guide and for SwitchKit API information see the API Reference.
SwitchKit Components Diagram
The following diagram provides an overview of the SwitchKit components. All
components communicate using
TCP/IP.
LLC - The Low-Level Communicator
The Low-Level Communicator (LLC) coordinates and intelligently routes all
communication, for example messages, between applications and the switch. It is
the only module that communicates directly with the switch over an Ethernet
connection, and that can distribute and collect messages to and from all the
application modules.
The LLC coordinates many low-level communication tasks that otherwise would be
the application’s responsibility, such as:

Message formatting, queuing, sequencing and acknowledgment

Handling special characters


Calculating checksums
Message and error logging
225
MSP

Intelligent channel allocation

Connections to multiple switches

Socket management
Because the LLC serves as a layer above the platform, it can handle multiple
application modules running on any machine in the network. Messages can be routed
intelligently among all of the application modules. When a message arrives on a
channel, LLC routes that message to whatever application is responsible for that
channel. By using this mechanism, two independent applications can share a single
MSP 1010. Also, you can structure an application system to contain multiple
application modules, to provide redundancy, load sharing, and separation of
functionality.
The SwitchManager
The SwitchManager
The SwitchManager is a process that helps maintain the MSP 1010 configuration
environments in a state of readiness. It implements switch and switch resource
configuration with a user-defined configuration file. It reads the configuration files
and sends configuration messages to the switch, and supports automatic query of
the switch to determine its current hardware setup and configuration. Configuration
files are comprised of easily-used text names and fields. The switch can also be
dynamically reconfigured. For example, even while running traffic, SwitchManager
can reconfigure the platform automatically if the switch or any of its individual cards
lose configuration, such as, when a card is pulled.
You can use the SwitchManager to configure resources — cards, spans, DSPs and
channels — by providing default values.You can also define inseize and outseize
rules, call progress analysis parameters, hierarchical groups of channels, custom
tones, and filters and timers. PPL tables can be specified so that they are
downloaded automatically. Voice Recorded Announcement System (VRAS) prompts
can be downloaded dynamically. SwitchManager enhances reliability with extensive
fault detection and notification features. It monitors alarms, tracks the Matrix
Controller Series 3 MSP1010 heartbeat and switchover recovery, and automates N+1
line card redundancy.
SwitchManager works in conjunction with the ClientView to provide graphical
configuration and provision in the MSP 1010.
SwitchKit Application Programming Interface
Description
The SwitchKit Application Programming Interface (API) is a high-level interface
between the application and the LLC that facilitates rapid switch-to-application
integration. The API extracts Cantata Technology's Excel EXS API suite in C/C++
Library format. This interface enables the application developer to support EXS
messaging as well as administrative messages (between the application and the low
level communicator) with all the benefits of a high-level language API.
226
SwitchKit Installation & Maintenance
In short, SwitchKit lets developers address the call processing aspects of their
solutions as they see fit — giving them the power to implement new services easily,
quickly, and profitably.
For the UNIX operating environments, SwitchKit API is available in two sets of
libraries: standard SK API and threadsafe SK API. Both APIs offer the same basic
functionality to the application developer, with one major difference. The standard
SK API allows single- threaded applications to be developed to connect to the LLC.
The threadsafe SK API allows multi-threaded applications to be developed to
connect to LLC. For maximum flexibility in application functionality today and in the
future, it is recommended that all new development occur on the threadsafe SK API.
Highlights of the ClientView
The ClientView is a graphical user interface that helps you with the administration
and configuration of your Multi-Services Platform (MSP). The ClientView provides a
simple, data-driven environment that you can customize and extend at run-time
without recompiling. The communication between ClientView and the DataManager
server is based on XML messaging. The ClientView provides context-sensitive Help
for easy access to information when using the tool. The ClientView accompanies
SwitchKit (see SwitchKit Features and Components.
Features
The ClientView is a real-time node configuration, maintenance, and administration
application. It also lets you monitor the current state of your system in real-time.
You can apply changes to the connected nodes with simple point-and-click
operations. Through the ClientView, system developers avoid low level, codeintensive channel and trunk group assignments and maintenance. Instead you can
create and maintain trunk groups through the interface. You can examine detailed
alarms and statistics without decoding log files.
This user guide describes the ClientView interface and procedures that can be
performed and includes screen shots of the application’s configuration dialog boxes
that graphically show tasks that can be completed. In some cases, it may be
necessary to consult the API developer’s guides for more information on the various
options available in the fields shown in the dialog boxes. The ClientView user’s guide
explains the administrative steps you can perform using the application. It contains
all the information you need to get your ClientView started. It also outlines and
demonstrates all the features provided.
ClientView Functionality Defined
The ClientView provides easy access to configure, monitor, and provision
functionality on the MSP. The functionality is defined as follows:


Configuration
Ability to graphically configure an MSP 1010 from initial setup to channel
configuration.
Monitoring
Real-time view of a MSP 1010 used to monitor hardware status, application
status, alarm status, and calls in progress.
227
MSP

Provisioning
Allows real-time changes required to maintain optimal processing on the MSP
1010. This includes bringing components in or out of service, busying out
components, and managing channel groups.
DataManager
ClientView was designed using a client-server software architecture. ClientView is the
client. DataManager is the database server. DataManager: manages the data model
to a configured specification, provides configuration and provisioning data to
ClientView, and generates log files: maintenance_datamanager.xxxx.log. It is
required that DataManager be running for ClientView to run.
AdminManager
AdminManager is the server for the AdminView client, which is also a component of
SwitchKit. AdminManager manages access levels in AdminView. AdminManager
validates users and passwords created in AdminView and used by ClientView. If
AdminView is not running, the log-in to ClientView will fail.
Installation
SwitchKit Supported Operating Environments
This information provides the Operating Environments supported on SwitchKit and its
companion products with this release.
SwitchKit Run-time Environment
The next table shows the operating systems and versions supported by SwitchKit in
a run-time environment.
Operating System Requirements
Operating
System
SwitchKit is supported on...
Linux
Red Hat Enterprise Linux ES 4.0.
Solaris
Version 10.0 for the SPARC platform
Linux
Red Hat Enterprise Linux ES 3.0
Windows/2000
Windows/XP
Service pack 2 or greater
Service pack 2 or greater
SwitchKit Development Environment
228
SwitchKit Installation & Maintenance
The next table shows the compilers supported by SwitchKit in a development
environment.
Compiler Requirements
Operating
System
SwitchKit applications must be built
using...
Linux
Red Hat Enterprise Linux ES 4.0.
Solaris
Forte 6.2 or GNU gcc 3.4.3
Click here for more details.
Linux
RedHat ES 3 w/ gcc 3.2.3 20030502
Windows/2000
Windows/XP
Kernel: 2.4.21-27.0.2.EL #1
MS Visual Studio C++ 6.0
MS Visual Studio C++ 6.0
ClientView
The ClientView works in conjunction with SwitchKit. The ClientView is available on all
SwitchKit-supported platforms.
Downloading Or Upgrading System Software
This procedure explains the process for downloading system software to the MSP
1010 either as an upgrade to existing software or installing the software for the first
time. The MSP 1010 system software must be installed before you can start the
SwitchKit components: Low-Level Communicator (LLC) or SwitchManager.
Before you begin
BOOTP and FTP servers must be configured and their services started. If you have
redundant hosts you can have BOOTP and FTP running on both hosts.
Upgrading System Software Download
The following step is recommended for upgrading the MSP 1010 system software
using SwitchKit.
1. Open ClientView.
2. In ClientView, select the node you want to clear the system software on.
3. Click the button, Reset Node.
4. Click the button: Clear Software.
5.
Power cycle the MSP 1010.
System Software Download for a new system
229
MSP
The following procedure is recommended for installing the System Software using
SwitchKit on a new MSP 1010 that has no system software.
1. Power ON the switch. The BOOTP request is sent automatically and finds an
IP address for the switch. The BOOTP response must contain the FTP
configuration settings. The MSP 1010 then requests the FTP software loads.
2. Start SwitchKit. If FTP is still in progress while the matrixMSP1010 is getting
binaries, LLC reports the FTP download is still in progress. LLC waits for the
MSP 1010 to become active.
SwitchKit Software Licensing
The SwitchKit license is packaged with the license of your MSP 1010. The MSP
license file name contains a unique serial number of the MSP 1010. The format of the
file includes the eight digit serial number followed by the timestamp:
NNNNNNNN_YYYYMMDDHHSS.cfg
If you rename or alter the license file in any way, it becomes unusable.
Each license is matched to the chassis ID of each node in the Excel platform.
SwitchKit applications can connect to any LLC that is running with a valid software
license. Independent software licenses are not required for SwitchKit applications.
Licensing Procedure
To license your product, copy your license file into the license directory indicated by
SK_LICENSE_DIR. By default this is:
Windows:
C:\Program Files\Cantata\common\license
UNIX:
/opt/cantata/common/license
Installing SwitchKit on UNIX
This procedure describes the installation of SwitchKit on a UNIX system.
Before you begin
If you are installing SwitchKit in a directory other than the default, replace all path
names in this procedure with the appropriate path. All file names are case-sensitive
and should be in lower case in UNIX. All linkable libraries in SwitchKit are in ELF
format.
Installing SwitchKit on UNIX
230
SwitchKit Installation & Maintenance
Follow this procedure to install SwitchKit on UNIX systems.
1. Log on to the target machine: login:<user name> password:<your password>
2. Insert the SwitchKit installation CD.
3. Copy the SwitchKit zip file from the CD in the directory /SwKit/<UNIX
Operating System>. The name of the SwitchKit installation zip file is as
follows: Solaris: solsparc.bin Linux: linux.bin
4. Type the following exactly:
./solsparc.bin
./linux.bin
for Solaris
for Linux
5. Select the installation directory. (The user doing the installation must have
write access to this directory.) The default directory is:
/opt/cantata
This will be referred to as $INSTALL_DIR.
Important! When following the last instruction replace $INSTALL_DIR with
your actual installation directory.
6. Follow the instructions on the screen to complete the installation.
After installing SwitchKit, you must set up the profiles for your installation. See
Installing Profiles on UNIX Hosts.
Directory Summary
The default directories listed in the following table are created automatically during
installation.
Directory
Contents and Use
$INSTALL_DIR/msp/switchkit/lib*
SwitchKit development libraries
$INSTALL_DIR/msp/switchkit/bin*
$INSTALL_DIR/msp/switchkit/include*
$INSTALL_DIR/msp/switchkit/samples*
$INSTALL_DIR/common/reports
$INSTALL_DIR/common/treatment
$INSTALL_DIR/common/stats
$INSTALL_DIR/common/config
$INSTALL_DIR/common/license
$INSTALL_DIR/common/backup
SwitchKit executable files
SwitchKit development header
files
Contains sample configuration
files
Stores report output files
Contains vocabulary index files
Stores the statistics files
collected per object
Holds configuration files
Folder where MSP 1010 looks
for current licenses
Stores backup log and
configuration files
231
MSP
configuration files
$INSTALL_DIR/common/log
Stores current log files
* The contents of switchkit folder are links to the actual files which are installed
under /opt/cantata/installs/MSPSwitchKit_Build_No/switchkit/.
IP address mapping for UNIX/ Linux/ Solaris Users
Customers running MSP SwitchKit software on Unix platforms must edit the
/etc/hosts to reflect the IP address mapping of that machine.
The DataManager, looks at the /etc/hosts file for the IP address. If the /etc/hosts
file does not contain the actual IP address of the machine, it is not possible for the
DataManager and hence the ClientView to manage the MSP.
The contents of the /etc/hosts file should look like:
127.0.0.1
IP_Address
localhost.localdomain
localhost
hostname
Where IP_Address is the IP address of the UNIX machine: hostname is the hostname
of UNIX machine.
NOTE: do not remove or edit the 127.0.0.1 entry in the /etc/hosts file
Installing Profiles on UNIX Hosts
For SwitchKit to function properly on Linux or Solaris you must source this file:
$INSTALL_DIR/MSP/excel_profile
For this file to function properly, all old variables (those from previous SwitchKit
installations) must be removed and the new file must be sourced in your shell startup scripts.
To Remove All Previously Set Environment Variables
For each user of the MSP 1010, you must do the following. (If all users are to use the
MSP 1010, your administrator may have already set this.)
Execute this command to confirm whether any variables are set:
Linux
env | grep SK_
Other Operating Systems
set | grep SK_
If nothing is displayed, then you know the environment variables have been
removed. If any variables are listed, you have to find them and delete them. To do
this:
1. Go to your home directory.
2. Execute the following command:
All Operating Systems
232
grep SK_ .*
SwitchKit Installation & Maintenance
Find the shell start-up file that has variables set and delete them. You may see SK_
set in files that are not important, for example, .bash_history. These can stay.
Sourcing excel_profile
The type of shell you are using impacts where you need to source the excel_profile.
To determine what shell you are using, execute the following command:
All Operating Systems
echo $SHELL
To source the Excel profile, edit your shell startup script by executing the following
commands:
1. Change to your home directory by typing the following:
All Operating Systems
cd
2. Edit your shell startup script. Choose the correct file for your shell from the
list below:
Bash Shell
.bashrc
Bourne Shell
.profile
C Shell
Korn Shell
TC Shell
.cshrc
.kshrc
.tcshrc
3. Source the excel_profile. If you installed SwitchKit in the default location, the
command will look as follows:
.<space>/opt/cantata/MSP/excel_profile
4. Log out and log back in.
5. Execute this command to find where the Environment variables are set to
Linux
env | grep SK_
Other Operating Systems
set | grep SK_
Ensure that the environment variables are set correctly.
Example
When installing in the default location, the $SK_LIB_DIR would be set to:
/opt/cantata/MSP/switchkit
Installing SwitchKit on Windows
Purpose
This procedure guides you through the SwitchKit installation.
Default directory
The SwitchKit default installation directory is:
233
MSP
C:\Program Files\Cantata\MSP\switchkit
For the ClientView the default installation directory is:
C:\Program Files\Cantata\MSP\MSPUserInterface\ClientView
See Installing ClientView and EventView for more details.
Before you begin
Other installations of SwitchKit components must not be running on the system when
reinstalling or installing a new version. LLC and/or SwitchManager must be stopped if
they are running as automatic services at startup.
If you previously saved customized files in your installation directory, move the files
to a temporary location of your choice. After you have completed your SwitchKit
installation you need to move the files to your installation directory.
Installation Steps
Follow the steps below to install SwitchKit on Windows systems. If you are installing
SwitchKit in a directory other than the default, replace all path names in this
procedure with the appropriate path.
1. Log on using an administrative account. If you are installing SwitchKit on a
system for the first time, start with Step 3.
2. Remove your current SwitchKit installation from your system. Use the Add
Remove Programs feature under the Windows Control Panel to remove the
program.
3. Insert the SwitchKit Installation CD.
4. Double-click skit.exe located in the Windows folder on the CD. This is a selfextracting executable.
5. While you are installing SwitchKit, the switch configuration dialog box is
invoked. See the next screen shot.
This dialog box allows you to set up a redundant LLC and a SwitchManager
configuration file to be used when SwitchKit components are to be run
automatically as Windows services. Select Redundant Mode under LLC
Configuration and enter the Primary host name (See also SwitchKit
Redundancy.) Use the browse button to set up the SwitchManager
Configuration File. Click OK.
234
SwitchKit Installation & Maintenance
If you do not intend to run these as Windows services, click Cancel. For further
information, see the Running SwitchKit Components Automatically at Startup.
NOTE: By default, the LLC and SwitchManager are not set up in Windows
Services to be started manually.
6. Follow the instructions on the screen to complete the installation.
7. Reboot your machine if prompted.
SwitchKit is now installed with all of its components:

LLC

DataManager


SwitchManager
AdminManager
Running SwitchKit Components Automatically at Startup
This procedure describes how to make the Low-Level Communicator (LLC) and
SwitchManager run automatically as services on a Windows computer at startup. By
default, when you install SwitchKit, the LLC and SwitchManager are installed as
services but must be started manually.
To ensure maximum system up-time in production environments, we recommend
setting up both the LLC and SwitchManager to run automatically as Windows
Services.
Before you begin
You must have SwitchKit installed.
235
MSP
Auto-start is not suitable for a development
environment where resources are shared. Configuring
LLC and SwitchManager as auto-start services is
recommended only if your host computer will have
continuous connectivity to the switch. If a host computer
does not have full time access to a switch, configuring LLC
and SwitchManager as auto-start services may cause
problems during initialization. Also, if a host computer
shares access to a switch, this could cause thrashing
between multiple LLCs and their connections to the switch.
Enabling SwitchKit to Run as a Service
To make LLC and SwitchManager run as automatic Services at startup do the
following. If you are using Windows NT start at Step 4:
For Windows XP
1. From the Start button, go to Settings Control Panel Administrative Tools
Services.
2. Select the service EXS LLC and right-click Properties from the menu. The
EXS LLC Properties (Local Computer) dialog box opens. See the next
screen shot.
3. Go to the General Tab, Startup type field and select Automatic from the
drop-down list. Click Apply, then OK. Repeat the previous steps for
SwitchManager. Then, go to Step 1.
4. From the Start button, go to Settings>Control Panel>Services.
5. Select the service EXS LLC and click the Startup button.
6. Select Automatic under Startup type. Click OK. Repeat the previous steps for
SwitchManager. Then, go to Step 1.
For Windows NT
1. From the Start menu, select Programs SwitchKit SwitchConfig. The
Switch Config dialog box opens. See the next screen shot.
2. Specify the LLC Configuration: If the host is going to run as the redundant
controller, check the box for Redundant Mode to enable redundancy and
provide the Primary host name.
3. Specify the SwitchManager Configuration: In the Configuration File text
box, enter the full path to the configuration file.
4. Select the connection method by selecting one of the following
SwitchManager options (For more information about this options see
SwitchManager Arguments:

236
Configure and maintain: Each time it connects to the LLC, SwitchManager
sends the entire configuration file to the switch. This results in a complete
system configuration.
SwitchKit Installation & Maintenance


Maintain Only: Each time an initial SwitchManager connects to the LLC,
SwitchManager reads the configuration file and does no initial configuration. If
an active SwitchManager reconnects to an LLC, SwitchManager will behave as
if it were Smart Mode.
Smart Mode: Each time it connects to the LLC, SwitchManager reads a
configuration file and reconfigures anything that is configured differently than
specified in the configuration file. SwitchManager determines this by checking
the Configuration Tag of all cards in the system. Any card with a
Configuration Tag of zero (0) is reconfigured.
Important! This option only applies to the initial startup of the
SwitchManager. A system running in a production environment should be run in
Smart Mode.
5. Click OK to save your settings and exit.
6. Invoke the Control Panel by selecting Start/Settings Control Panel.
7. On Windows NT systems double-click the Services icon. On Windows XP
systems double-click the Administrative Tools icon and then double-click
the Services icon. This opens the services dialog.
8. Select “EXS LLC,” change the StartUp type to Automatic, and click OK.
9. Select “EXS SwitchMgr,” change the StartUp type to Automatic, and click OK.
10. Apply the changes and close the Control Panel.
SwitchKit Tray Icons
Description
When running SwitchKit on Windows NT as a service, tray icons give a visual
indication of the LLC and SwitchManager status within the icon tray bar.
LLC Icons
The icon for the LLC shows an "LLC" at the bottom. The "LLC" icon is complemented
with one of the following:

a green A above the LLC indicates the LLC on this machine is the primary LLC.

a red I above the LLC indicates the LLC on this machine is initializing.

a yellow S above the LLC indicates the LLC on this machine is the redundant
LLC.
SwitchManager Icons
The icon for the SwitchManager shows an "SM" at the top. The "SM" icon is
complemented with one of the following:


a transparent bar under the SM indicates that SwitchManager is idle.
a yellow bar under the SM indicates that SwitchManager on this machine is
the redundant SwitchManager.
237
MSP


a red bar under the SM indicates that SwitchManager is currently handling a
message.
a red ! over the SM indicates that SwitchManager is unable to talk to the LLC.
Viewing SwitchKit log files
You can view log files using the default file viewer (Notepad) or with different viewer.
To override the default file viewer, set the environment variable SK_VIEW_SPEC or
add VIEW_SPEC to the defaults file. Use the full path to the viewer. The "%s" MUST
be enclosed in quotes(") so that file paths with spaces works.
LLC Logs
To open the messages.log file double-click the LLC icon. If you right-click the LLC
icon, the following options are presented:

View messages.log

View maintenance.log


View messages.log with Notepad
View maintenance.log with Notepad
SwitchManager Logs
To open the alarm.log file double-click on the SM icon. If you right-click the SM icon,
the following options are presented:


View alarm.log
View alarm.log with Notepad
Configuring SwitchKit to Run from the Start Menu on Windows
This procedure describes how to configure the LLC and SwitchManager to run from
the Start Menu.
Before you begin
Determine whether your connection parameters for starting the LLC and
SwitchManager are constant and do not change frequently.
Configuring the Shortcuts
To run SwitchKit in a development environment where resources are shared, set up
the shortcuts to ease the process for starting LLC and SwitchManager. Use shortcuts
only if the connection parameters for starting LLC and SwitchManager do not change
frequently. If setup information changes frequently, start these processes from the
command line.
1. Right-click the Windows Start button then click Explore All Users.
2. Double-click Programs then double-click SwitchKit.
3. In the SwitchKit folder, right-click LLC.
238
SwitchKit Installation & Maintenance
4. Go to Properties, then click the Shortcut tab. The next dialog box opens:
5. In the input field Target specify the start-up argument by typing them
outside the quotation marks following llc.exe. For possible arguments refer to
the Running the LLC procedure.
6. Click Apply to apply your specification.
7. Click OK to close the dialog.
8. In the Explore All Users window right-click SwitchManager.
9. Go to Properties then click the Shortcut tab. You see the following dialog:
10. Go to the Target field. At the end of the line outside the quotation marks,
type your configuration file name, for example: mysystem.cfg. The input
would read:
“C:\Program Files\Cantata\MSP\switchkit\bin\SwitchManager.exe” mysystem.cfg
If there is no configuration file specified, SwitchManager uses the system.cfg
file provided with the installation in the SwitchKit folder.
11. In the Target field add the start-up argument by typing it outside the
quotation marks, but before your specified configuration file. For possible
arguments refer to SwitchManager Arguments. For example, the input could
read:
“C:\Program Files\Cantata\MSP\switchkit\bin\SwitchManager.exe” switchmgr -n
mysystem.cfg
11. Click Apply and then OK.
Environment Variables Modify SwitchKit Default Behavior
You can modify SwitchKit component behavior through environment variables or by
changing the values in the SwitchKit Defaults file. Environment variables take
precedence over the variables in the Defaults file.
Modifying Default Behavior on Windows
SwitchKit environment variables can be set in three ways on Windows:

Use the Command Line. Here is an example of the syntax:
set SK_ENV_VAR=x
Important! Environment variables set on the command line only apply to the
Switchkit process (LLC, SwitchManager or a user application) running in that
command shell.


Use the Control Panel in Windows. Please refer to the procedures Setting
Environment Variables on Windows NT 4.0 or Setting Environment Variables
on Windows 2000.
Use the defaults file. You need to create this in the following directory:
SK_LIB_DIR.
Modifying Default Behavior on UNIX
SwitchKit environment variables can be set in three ways on UNIX:
239
MSP

Use the @ Shell Prompt. Here is an example of the syntax:
SK_ENV_VAR=x
export SK_ENV_VAR
Important! Environment variables set on the @ Shell Prompt only apply to the
Switchkit process (LLC, SwitchManager or a user application) running in that
command shell.


Use .Profile for user.
Use the defaults file. You need to create this in the SK_LIB_DIR directory.
Variable Rules
These are the rules regarding environment variables and defaults files.





Environment Variable names are case-sensitive and must be entered as all
capital letters. For example, SK_VARIABLE.
The Defaults file name is case-sensitive and must be entered exactly as
shown below for each operating environment. /SK_LIB_DIR
All Defaults file variable names are entered in lower case and do not use the
prefix, sk.
In the Defaults file, if the first character in a line is a pound symbol (#),
subsequent text is considered a comment.
Blank lines are allowed.
Format
The format for default values in both UNIX and Windows is as follows:
<fieldname> : value
Example
LLC_Host : localhost
LLC_Port : 1312
RLLC_Host : localhost
RLLC_Port : 1312
Logging Environment Variables
In maintenance.llc.log, LLC will log all environment variables used, where that
variable was set and what the value is. The next example shows details logged by
LLC:
Jan 11 2005 11:48:45: Variables read from environment:
Jan 11 2005 11:48:45: Environment var SK_APP_DISABLED_TIMEOUT -> "99999"
Jan 11 2005 11:48:45: Environment var SK_FILE_LIFETIME -> "1"
Jan 11 2005 11:48:45: Environment var SK_LIB_DIR -> "C:\Program Files\Cantata\SwitchKit"
Jan 11 2005 11:48:45: Environment var SK_LOG_DIR -> "C:\Program Files\Cantata\Log"
Jan 11 2005 11:48:45:
240
SwitchKit Installation & Maintenance
Jan 11 2005 11:48:45: Variables read from file "C:\Program Files\Cantata\SwitchKit\Defaults":
Jan 11 2005 11:48:45: In defaults file, key of SK_DISABLE_CSM has value "0"
Jan 11 2005 11:48:45: In defaults file, key of SK_LLC_HOST has value "135.119.52.4"
Jan 11 2005 11:48:45: In defaults file, key of SK_LLC_PORT has value "1312"
Jan 11 2005 11:48:45: In defaults file, key of SK_LOG_LEVEL has value "6"
Jan 11 2005 11:48:45:
Jan 11 2005 11:48:45: Variables set at runtime
Jan 11 2005 11:48:45:
Jan 11 2005 11:48:45: Blanked Variables
Jan 11 2005 11:48:45:
Jan 11 2005 11:48:45: Variables as seen at runtime
Jan 11 2005 11:48:45: key of SK_APP_DISABLED_TIMEOUT has value "99999"
Jan 11 2005 11:48:45: key of SK_DISABLE_CSM has value "0"
Jan 11 2005 11:48:45: key of SK_FILE_LIFETIME has value "1"
Jan 11 2005 11:48:45: key of SK_LIB_DIR has value "C:\Program Files\Cantata\SwitchKit"
Jan 11 2005 11:48:45: key of SK_LLC_HOST has value "135.119.52.4"
Jan 11 2005 11:48:45: key of SK_LLC_PORT has value "1312"
Jan 11 2005 11:48:45: key of SK_LOG_DIR has value "C:\Program Files\Cantata\Log"
Jan 11 2005 11:48:45: key of SK_LOG_LEVEL has value "6"
List of Environment Variables
This section provides the names of all of the environment variables available with
SwitchKit. The environment variables are listed in alphabetical order and each is
described indicating what it is used for. The variable name in the Defaults file is
provided, along with the valid values for each variable.
Important! Environment variables should be set within the value ranges specified
for each variable listed. Setting a variable outside this range will result in
unexpected behavior.
The environment variables and the Defaults file are read at start-up by LLC and
SwitchKit applications. To modify settings at run-time, you can use ClientView. See
the ClientView User’s Guide.
SK_APP_ DISABLED_TIMEOUT
SK_APP_ DISABLED_TIMEOUT specifies the number of seconds that an application
must be silent and fail to respond to pings before the LLC considers it
unavailable.This value applies to all applications connected to the LLC.
Defaults file variable name
app_disabled_timeout
Valid Values
SK_APP_DISABLE_TIMEOUT = 15
241
MSP
Disconnect applications after 15 seconds (default)
SK_APP_DISABLE_TIMEOUT = 1 to 65535
Valid range for timeout
SK_AUTO_RETURN_CHANNELS
SK_AUTO_RETURN_CHANNELS specifies whether a ChannelReleased message from
the switch should trigger an automatic sk_returnChannel. The use of
SK_AUTO_RETURN_CHANNELS is recommended because it simplifies application
development. It also prevents a possible race condition, if an XL_ChannelReleased
message is immediately followed by an XL_RequestForService, before the application
has been able to return the channel. It defaults to 0 for backward compatibility.
Defaults file variable name
auto_return_channels
Valid Values
SK_AUTO_RETURN_CHANNELS = 0
Disable (default)
SK_AUTO_RETURN_CHANNELS = 1
Enable
SK_BACKUP_WHEN_CLEARLOG
SK_BACKUP_WHEN_CLEARLOG controls whether a backup of log files will be saved
when the clear log command is sent to the LLC.
Defaults file variable name
backup_when_clearlog
Valid Values
SK_BACKUP_WHEN_CLEARLOG = 0
Disabled
SK_BACKUP_WHEN_CLEARLOG = 1
Enabled (default)
SK_CHANNEL_RECOVERY_METHOD
SK_CHANNEL_RECOVERY_METHOD allows LLC control of the channel in case of an
abrupt disconnect from an application that is controlling the channel.
242
SwitchKit Installation & Maintenance
Defaults file variable name
channel_recovery_method
Valid Values
SK_CHANNEL_RECOVERY_METHOD = 0
OFF (default) channels owned by the application are left in their current state
SK_CHANNEL_RECOVERY_METHOD = 1
Release the non-idle channels owned by the application
SK_CHANNEL_RECOVERY_METHOD = 2
Take non-idle channels owned by the application out of service
SK_CHANNEL_RECOVERY_METHOD = 3
Take all channels out-of-service within the watched channel group(s)
Note:
Methods 1 and 2 only affect non-idle channels (channels that are in active calls).
For Method 2 and 3, after you restart the application to watch the channel groups,
you must bring the channels back in-service using the ForceGroupState message.
Method 3, will affect channels:



in an entire group being watched using the sk_watchChannelGroup()
function;
that are not watched by any other applications;
that are currently active only after they are released prior to being brought
out-of-service.
SK_DIALOGUE_MONITOR
SK_DIALOGUE_MONITOR is used to activate the LLC's dialogue monitor.
Defaults file variable name
dialogue_monitor
Valid Values
SK_DIALOGUE_MONITOR=0
-disables the LLC’s dialogue monitor (default)
SK_DIALOGUE_MONITOR=1
- enables the LLC’s dialogue monitor
See LLC: Application Load Balancing for TCAP for more information on how to use
the LLC’s dialogue monitoring capabilities.
243
MSP
SK_DISABLE_CSM
SK_DISABLE_CSM enables or disables LLC from sending the
SK_ConnectionStatusMsg to all connected application.
Defaults file variable name
disable_CSM
Valid Values
SK_DISABLE_CSM = 0
LLC sends ConnectionStatusMsg to all applications (default)
SK_DISABLE_CSM = 1
LLC does not send ConnectionStatusMsg to any application
SK_DISABLE_FILE_ ROLLOVER_LOGGING
SK_DISABLE_FILE_ROLLOVER_LOGGING disables the printing of the switch midplane query information banner and the connected SwitchKit application banners
within the maintenance_llc.log.
Defaults file variable name
disable_file_rollover_logging
Valid Values
SK_DISABLE_FILE_ROLLOVER_LOGGING = 0
Enables printing of information about each connected process when the log file rolls
over (default)
SK_DISABLE_FILE_ROLLOVER_LOGGING = 1
Disables printing of information about each connected process when the log file
rolls over
SK_DISABLE_PPL_EVENT_LOGGING
Set SK_DISABLE_PPL_EVENT_LOGGING to stop the SwitchManager from printing
identified PPL events to an alarm.log file.
Defaults file variable name
disable_ppl_event_logging
244
SwitchKit Installation & Maintenance
Valid Values
SK_DISABLE_PPL_EVENT_LOGGING = 0
Enables logging of all identified PPL events (default)
SK_DISABLE_PPL_EVENT_LOGGING = 1
Disables logging of all identified PPL events
SK_DISABLE_UNKNOWN_PPL_EVENT_LOGGING
Set SK_DISABLE_UNKNOWN_PPL_EVENT_LOGGING to stop the SwitchManager from
printing unknown PPL events to an alarm.log file.
Defaults file variable name
disable_unknown_ppl_event_logging
Valid Values
SK_DISABLE_UNKNOWN_PPL_EVENT_LOGGING = 0
Enables logging of all unknown PPL events (default)
SK_DISABLE_UNKNOWN_PPL_EVENT_LOGGING = 1
Disables logging of all unknown PPL events
SK_ENABLE_CHANNEL_ OWNERSHIP_LOGGING
Use this environment variable to enable logging of the channel ownership changes
which are then logged in messages.log. The logs include the channel state
information as well as information about the application gaining/losing
ownership.Channel ownership by an application can change for many reasons. Here
are some examples:

Gain of ownership
AllocateChannel (and AllocateChannelGroup)
RFS via the watchChannelGroup method
RequestChannel
requestOutseizedChannel
requestRouteControlledChannel)
TransferChannel (from another application)
Redundant Application Pool (RAP) switchover to new primary

Outsieze or routeControl on an unclaimed channel
Loss of ownership
Transfer channel (to another application)
245
MSP
sk_returnChannel
ChannelReleased (withdata) message recieved from switch
DS0 of purge or out of service
Termination of application
Redundant Application Pool (RAP) switchover to new primary
Defaults file variable name
enable_channel_ownership_logging
Valid Values
SK_ENABLE_CHANNEL_OWNERSHIP_LOGGING = 1
Enables logging of channel ownership
SK_ENABLE_CHANNEL_OWNERSHIP_LOGGING = 0
Disables logging of channel ownership (default)
SK_DISPLAY_CONNECTION_COUNT
SK_DISPLAY_CONNECTION_COUNT is used to enable the logging of the total number
of applications connected to LLC any time an applications connects or disconnects.
Defaults file variable name
display_connection_count
Valid Values
SK_DISPLAY_CONNECTION_COUNT = 0
No additional information will be logged (default).
SK_DISPLAY_CONNECTION_COUNT = 1
Text similar to the following will be printed in the maintenance.llc.log each time
a connection to an application or node is created or destroyed.
Example
Jun 19 2002 16:33:49: New Link - total created: 69 - active count: 5
Jun 19 2002 16:33:49: Destroyed Link - total created: 69 - active count: 4
If this enviroment variable is not defined, the usual text will be displayed when
connections are created or destroyed.
SK_FILE_CLOSEOUT_HOUR
246
SwitchKit Installation & Maintenance
SK_FILE_CLOSEOUT_HOUR specifies the hour on which to cycle all managed log
files. Specifying SK_FILE_CLOSEOUT_HOUR supercedes any setting of
SK_FILE_LIFETIME setting the file lifetime to 24 hours.
Defaults file variable name
file_closeout_hour
Valid Values
SK_FILE_CLOSEOUT_HOUR = 0
File close-out midnight, local time (Default)
Valid values are integers 0-23. If SK_FILE_CLOSEOUT_HOUR = 7, all managed logs
files will cycle at 7:00 AM local time. Be aware, the longer the log files remain open,
the larger they grow. Large files can consume all available disk space and cause
system errors. It is recommended that log files never remain open longer than 24
hours.
SK_FILE_LIFETIME
SK_FILE_LIFETIME specifies in hours the length of time log files are open. There is
no maximum length of time. If you set SK_FILE_LIFETIME to less than 1, the file life
time becomes 24. Setting SK_FILE_CLOSEOUT_HOUR will supercede any value you
set for SK_FILE_LIFETIME and act as if you set SK_FILE_LIFETIME to 24 hours.
Defaults file variable name
file_lifetime
Valid Values
SK_FILE_LIFETIME = 24
Close logs every 24 hours (Default)
The valid range is 1-24
Any whole number of hours can be specified. Be aware, the longer the log files
remain open, the larger they grow. Large files can consume all available disk space
and cause system errors. It is recommend that log files never remain open longer
than 24 hours.
SK_FILE_MAX_SIZE
SK_FILE_MAX_SIZE specifies the size, in megabytes, to which the log file is allowed
to grow before rolling over. Each process controls its own log files. When a log file
exceeds the size specified by SK_FILE_MAX_SIZE, all log files controlled by that
process are rolled over.
Independent of file size-related roll-overs, all time based roll-overs will continue as
scheduled.
247
MSP
For example, assuming SK_FILE_LIFETIME = 1 and SK_FILE_MAX_SIZE = 1; if it is
now 3:45 p.m. and the log file reaches one megabyte, the log will cycle at 3:45 p.m.
The log will cycle again at 4:00 pm.
Defaults file variable name
file_max_size
Valid Values
SK_FILE_MAX_SIZE can be set to any positive integer value. There is no default
value.
Important! Any log will close on a host machine when the socket.log on that same
machine reaches its size limit. All logs on that machine will roll over. This is
done to keep all the log files synchronized.
SK_HANDLER_BEHAVIOR
SK_HANDLER_BEHAVIOR allows you to customize the behavior of handlers within an
application. The default handler or handler stack acts as a safety net if all other
handlers invoked return SK_NOT_HANDLED. Currently, the default handler stack is
used, if no other handlers are defined.
For example:



If a channel handler is defined by an application and then a call processing
message arrives, the message will be handed to the channel handler(s) or
stack of channel handlers.
If all the channel handlers return SK_NOT_HANDLED, then the message will
be returned in the original call to sk_rcvAndDispatch().
If a channel handler is not defined but a default handler is defined, then the
message is handed to the default handler or stack of default handlers.
If SK_HANDLER_BEHAVIOR is set to SK_HDLR_BHVR_SAFETY_NET(1), a default
handler will be used when the appropriate non-default handlers have returned
SK_NOT_HANDLED.
In effect, the default handler stack acts as a safety net for all messages. In the
above example, if a channel handler or handler stack is defined, and all handlers
return SK_NOT_HANDLED, then the default handler or handler stack will be
presented the message if defined and the SK_HANDLER_BEHAVIOR is enabled.
Important! The default handler or handler stack cannot act as a safety net to itself.
Defaults file variable name
handler_behavior
Valid Values
Use the following to set the bitmask:
SK_HDLR_BHVR_SAFETY_NET(1)
248
SwitchKit Installation & Maintenance
SK_LIB_DIR
SK_LIB_DIR specifies the location of the base directory of the SwitchKit installation.
Must be set to the base directory of SwitchKit. If this variable is not set, LLC will
terminate. Variable is automatically created for the default installation directory.
Important! When reinstalling SwitchKit on Windows NT, SK_LIB_DIR gets
overwritten.
Defaults file variable name
There is no default setting for SK_LIB_DIR.
SK_LLC_HOST
SK_LLC_HOST specifies what machine the LLC is running on.This environment
variable should be set similarly on both the primary host and the redundant host.
SK_LLC_HOST affects all client modules of the LLC. The value may be either a host
name or an IP address.
Defaults file variable name
llc_host
Valid Values
SK_LLC_HOST = localhost
local host (Default)
SK_LLC_PORT
SK_LLC_PORT specifies the port number of the host the LLC resides on. This
environment variable should be set similarly on both the primary host and the
redundant host. Each LLC and all applications that intend to connect to the LLC must
have SK_LLC_PORT set to the same value in their environment.
Defaults file variable name
llc_port
Valid Values
SK_LLC_PORT = 1312
Port 1312 (Default)
Valid values are 1024-32767
249
MSP
SK_LLC_RETRY_DELAY
SK_LLC_RETRY_DELAY specifies the delay between each LLC connection retry. This
variable only applies to connections between the LLC and SwitchKit applications, not
connections between the LLC and the MSP 1010. For example, this variable can be
used for connections between LLC and RLLC, LLC and SwitchManager, and between
LLC and SwitchKit user applications.
Defaults file variable name
llc_retry_delay
Valid Value
SK_LLC_RETRY_DELAY = 2
Retry connection every two seconds (Default)
Valid values include any integer.
Important! Cantata recommends that this value not be changed from the default.
SK_LLC_SWITCHBACK_ MODE
SK_LLC_SWITCHBACK_MODE can be used by the LLC to determine whether to
automatically switchback an LLC to its original Primary/Secondary configuration; or
remain in its current fail-over configuration until told to do otherwise by the
SK_LLC_CONTROL_START_SYNC_TLV in LLCControl.
Defaults file variable name
llc_switchback_mode
Valid Values
Value
Option
Description
1
SB_MANUAL_MODE
Whichever LLC is currently active will
remain active until told to
0
default
250
SB_PRIMARY_PREFERED_MODE
The LLC designated as Primary (no r) will always attempt to gain control
and become active. In the event that
the primary active LLC receives a
GO_STANDBY request, a switch-over
will occur. Once synchronization is
complete between the two LLCs a
switchback will occur and the primary
will regain control from the
secondary.
SwitchKit Installation & Maintenance
GO_STANDBY manually by an
LLCControl message. In the event
that two LLCs are concurrently in the
active state, and have been
configured by an AddLLCNode
message, the one that has been
configured the longest will win
arbitration. If the configuration times
are equal then the Primary (no -r)
will win arbitration.
SK_LOG_LEVEL
SK_LOG_LEVEL specifies the EXS API message logging to be done by LLC. The
possible options are to log to:

socket.log

and/or the screen output

messages.log
Socket.log is the preferred log level.
Defaults file variable name
log_level
Valid Values
Use the following to set the bitmask:
SK_LOG_NONE (0)
LLC will perform no EXS API message logging
SK_LOG_SOCKET (0x01)
LLC will log EXS API messages to socket.log (default)
SK_LOG_MESSAGE (0x02)
LLC will log EXS API messages to message.log
SK_LOG_SCREEN_OFF (0x04)
LLC screen output is disabled
SK_LOG_DIR
SK_LOG_DIR specifies the directory where all SwitchKit log files that are generated
on this host computer will be stored. If this variable is not set, log files will be stored
251
MSP
in the directory from which the process was started. See Setting Environment
Variables on Windows NT 4.0 or Setting Environment Variables on Windows 2000 ).
Defaults file variable name
log_dir
Valid Values
Default = None
Any network path that is read/write accessible.
SK_NO_DEFAULT_CONNECTION
By default, LLC connections are established using the SK_LLC_HOST, SK_LLC_PORT,
SK_RLLC_HOST and SK_RLLC_PORT definitions. When a connection is made, these
values determine what LLC is connected to if sk_createConnection has never been
called. Enabling SK_NO_DEFAULT_CONNECTION stops an application from using the
environment settings to determine the LLC location. To establish the LLC
connection, the application must call sk_createConnection. After the inital call, any
time the LLC connection must be re-established, the data provided in the original
sk_createConnection is used.
Defaults file variable name
no_default_connection
Valid Values
SK_NO_DEFAULT_CONNECTION = 0
Establish connections based on environment definitions. Default.
SK_NO_DEFAULT_CONNECTION = 1
Require sk_createConnection to establish connection to LLC.
SK_NUM_RETRIES_TO _LLC
SK_NUM_RETRIES_TO_LLC specifies the number of times an application will retry
the connection to LLC before NACKing the request. This value applies to all
applications, including Redundant LLC. It does not apply to the SwitchMgr.
Defaults file variable name
num_retries_to_llc
Valid Value
252
SwitchKit Installation & Maintenance
SK_NUM_RETRIES_TO_LLC = 0
Retry connection to LLC once (Default)
SK_NUM_RETRIES_TO_LLC = 1
Channel can only be released by application that initially requested the
channel.
This variable may be set to any number of retries, but retries take time. The
application will be waiting for a response the entire time. SK API is retrying to send
the message.
SK_RETURN_CHANNEL_BY_OWNER_ONLY
SK_RETURN_CHANNEL_BY_OWNER_ONLY controls the channel release behavior
related to the application that initially sent the channel request. When this
environment variable is disabled, any application can return any channel.
Defaults file variable name
return_channel_by_owner_only
Valid Values
SK_RETURN_CHANNEL_BY_OWNER_ONLY = 0
Feature disabled. Any application can return any channel. (Default)
SK_RETURN_CHANNEL_BY_OWNER_ONLY = 1
Channel can only be released by application that initially requested the
channel.
SK_RLLC_HOST
SK_RLLC_HOST specifies the IP Address of the host the redundant LLC resides on.
This environment variable should be set similarly on both the primary host and the
redundant host.
Defaults file variable name
rllc_host
Valid Values
SK_RLLC_HOST = localhost
local host (Default)
SK_RLLC_PORT
SK_RLLC_PORT specifies the port number of the host the redundant LLC resides on.
This environment variable should be set similarly on both the primary host and the
253
MSP
redundant host. Each LLC and all applications that intend to connect to the RLLC
must have SK_RLLC_PORT set to the same value in their environment.
Defaults file variable name
rllc_port
Valid Values
SK_RLLC_PORT = 1312
Port 1312 (Default)
Valid values are 1024-32767
SK_SIP_UA_APPSELECT _OPTION
SK_SIP_UA_APPSELECT_OPTION allows load sharing of SIP user agent (UA) Accept
Registration Requests. SIP UA load sharing can be enabled from a user application by
sending a sk_pplComponentRegister(0xA7) and then setting the environment
variable, with the appropriate option, on the host.
When enabled this load sharing feature will cause only one PPL event indication to be
sent to a user application (ClientView and Switchmanager will be excluded from the
list). Because only a single PPLEventIndication is expected for each of these SIP
transactions, it is not required that the LLC keep track of applications load. It will
simply select the next registered application by using a round robin or randomizing
algorithm.
Defaults file variable name
sip_ua_appselect_option
Valid Values
Value
Option
Description
1
SIP_UA_RANDOMIZE
Sends to one randomly selected application.
0
default
2
SIP_UA_BROADCAST
SIP_UA_ROUNDROBIN
SK_SOCKET_VALIDATE_WAIT
254
No load sharing. Sends to all registered
applications.
Sends to one application, which is selected in
a round robin manner. The first available
application is selected; the selection process
then proceeds through the applications,
always choosing the next one available
starting from the application it last selected.
SwitchKit Installation & Maintenance
When an application connects to LLC, a handshaking occurs through which critical
information regarding the connection is exchanged. SK_SOCKET_VALIDATE_WAIT
allows the time allocated to validate a client connection to the LLC to be changed.
Defaults file variable name
socket_validate_wait
Valid Values
SK_SOCKET_VALIDATE_WAIT = 3
Allow three seconds for socket validation (Default)
This variable may be set to any number of seconds.
SK_STATS_DIR
The full path to the directory where statistics are stored.
Defaults file variable name
stats_dir
Valid Values
SK_STATS_DIR= <full path to the directory in which stats are stored>
The default is:
Windows
C:/Programs/Canata/common/stats
UNIX
/opt/cantata/common/stats
SK_TRANSFERCHAN_ OPTION
SK_TRANSFERCHAN_OPTION allows you to decide when the LLC will transfer channel
ownership for a particular application. The default, option 0, is to transfer the
ownership when the LLC receives a TransferChanMsg. When option 1 has been
selected, the transfer will not take place until the LLC receives the
TransferChanMsgAck and has successfully sent it to the requesting application.
Defaults file variable name
transferchan_option
Valid Values
255
MSP
SK_TRANSFERCHAN_OPTION = 0
transfer application ownership on transferChan request (Default if not defined).
SK_TRANSFERCHAN_OPTION = 1
transfer application ownership on transferChanAck
SK_WARN_ORPHAN_RFS
SK_WARN_ORPHAN_RFS specifies that when the switch sends a Request For Service
or Request for Service with Data on a channel that is not associated with an
application, a warning message is logged in the maintenence.log file The warning
message states: “Message RFS received on channel n that was not associated with
any app” .
Defaults file variable name
warn_orphan_rfs
Valid Values
SK_WARN_ORPHAN_RFS = 0
No Warning (Default)
SK_WARN_ORPHAN_RFS = 1
Log Warning
Setting Environment Variables on Windows 2000
This procedure explains how to set an environment variable using the System
Variables option on Windows 2000. The environment variable, SK_LOG_DIR, is
used as an example in this procedure.
Before you begin
The following directory is created to store the log files:
C:\Program Files\Cantata\common\log
The log files are written into the directory based on the environment variable
SK_LOG_DIR.
Setting SK_LOG _DIR
Follow this procedure to set the SK_LOG_DIR Environment Variable.
If you are updating or reinstalling your SwitchKit installation, this environment
variable should already be set on your system.
Do not define environment variables as User variables. You
need to set environment variables in the Control Panel
System variables to run SwitchKit successfully as Windows
Services.
256
SwitchKit Installation & Maintenance
1. Log on using an administrative account.
2. Go to Control Panel -> System.
3. Select the tab, Advanced.
4. Select the button, Environment Variables.
5. If this is your initial setup, click New below the System variables field and
continue with Step 7. Otherwise, refer to Step 6.
6. If you want to change the variable settings, click Edit below the System
variables field.
7. In the field Variable Name type SK_LOG_DIR.
8. In the field Variable Value type:
C:\Program Files\Cantata\common\log
9. Click OK to close the New System Variable or Edit System Variable dialog
box.
10. Click OK to close the Environment Variables dialog box.
11. Click OK to close the System Properties dialog box.
12. Then close the Control Panel.
Setting Environment Variables on Windows XP
This procedure explains how to set an environment variable using the System
Variables option on Windows XP. The environment variable, SK_LOG_DIR, is used as
an example in this procedure.
Before you begin
The following directory is created to store the log files:
C:\Program Files\Cantata\common\log
The log files are written into the directory based on the environment variable
SK_LOG_DIR.
Setting SK_LOG _DIR
Follow this procedure to set the SK_LOG_DIR Environment Variable.
If you are updating or reinstalling your SwitchKit installation, this environment
variable should already be set on your system.
Do not define environment variables as User variables. You
need to set environment variables in the Control Panel
System variables to run SwitchKit successfully as Windows
NT Services.
1. Log on using an administrative account.
2. Go to Control Panel ->System.
257
MSP
3. Select the tab, Advanced.
4. Select the button, Environment Variables.
5. If this is your initial setup, click New below the System variables field and
continue with Step 7. Otherwise, refer to Step 6.
6. If you want to change the variable settings, click Edit below the System
variables field.
7. In the field Variable Name type SK_LOG_DIR.
8. In the field Variable Value type the installation folder:
C:\Program Files\Cantata\common\log.
9. Click OK to close the New System Variable or Edit System Variable dialog
box.
10. Click OK to close the Environment Variables dialog box.
11. Click OK to close the System Properties dialog box.
12. Then close the Control Panel.
Running SwitchKit Components and Companion Products
Running SwitchKit Components and Companion Products
Now that you have installed SwitchKit, it is time to connect to the MSP 1010 and
perform configuration. This chapter guides you through running each
component/companion product, explaining the proper order of execution, and all
available startup arguments. Excel provides you with a sample configuration file to
get you started using SwitchKit.
You can run both the LLC and SwitchManager automatically or manually in both UNIX
and Windows NT. The recommended method depends on the environment in which it
is running, as follows:



Dedicated - Single-user development environment with a dedicated MSP
1010. If you are running SwitchKit in a dedicated environment, you may run
it automatically or manually.
Shared - Multi-user development environment, or one without a dedicated
MSP 1010. If you are running SwitchKit in a shared environment, run it
manually to avoid thrashing over MSP 1010 resources.
Production - Run-time environment. If you are running SwitchKit in a
production environment, run it automatically.
System Start-up Behavior
Two modes are available to run SwitchManager:


Development Mode
Production Mode
If SwitchManager is run without a configuration file, the system is being run in
development mode. If SwitchManager is run with a configuration file, the system is
being run in production mode.
258
SwitchKit Installation & Maintenance
When running SwitchKit in development mode, it is assumed no configuration file is
present and one will be created. If a system.cfg file exists in the SK_CONFIG_DIR, it
will be renamed to system.old.cfg.
When running SwitchKit in production mode, it is assumed a configuration file named
system.cfg exists in the SK_CONFIG_DIR. This configuration file will be used to
configure the system. If this file does not exist, SwitchManager will terminate
indicating no system.cfg file is found.
When running SwitchKit in a redundant configuration, it must be run in production
mode. If it is run in development mode, redundancy will fail and the system will
become configured in an unknown state.
After SwitchManager is running it will connect to LLC. The configuration file specified
when starting SwitchManager must include at least one AddLLCNode () command.
LLC will initiate connections to all nodes specified in these commands and continue to
configure according to the configuration file.
Important! When the Switch Manager reconnects to the LLC, AddLLCNode
messages are sent from the Switch Manager to the LLC. This causes the LLC
to open a socket (connection) to the MSP 1010 and the AssignNode message
(which is the switch-level equivalent of AddLLCNode) is sent to the MSP 1010.
Running the LLC in Windows
This procedure describes the available parameters for running the Low-Level
Communicator (LLC) and how to run the LLC with or without any parameter
specification. If you want to run redundant LLCs, see Running Redundant LLCs.
Before you begin
The MSP 1010 system software must be installed before you can start the LLC.
SwitchKit must also be installed on your host. The LLC parameters must not be
already specified through the shortcut settings in the Start menu, refer to
Configuring SwitchKit to Run from the Start Menu.
Steps to start the LLC from the Start Button
Do the following to start the LLC:
1. Go to the Start button, select All Programs->Cantata-> LLC.
2. The LLC.exe window opens, indicates that it is ready to accept connections,
and then minimizes.
3. Now you are ready to start SwitchManager.
Steps to start the LLC from Windows Explorer
Do the following to start the LLC:
1. Open a Command Prompt window.
2. Specify the path to your installation directory. For the default location:
C:\Program Files\Cantata\MSP\switchkit\bin
1. Type llc and specify the start-up argument, if desired. You can use multiple
arguments together. See the LLC Arguments.
259
MSP
LLC start-up behavior
When the LLC connects to the MSP 1010, Poll messages from the MSP 1010 indicate
the presence of system software on the MSP 1010. If no system software is found,
the LLC will wait until the system software is downloaded by the FTP server. If an
FTP download is already in progress, LLC does not interfere and waits for the
download to complete.
After the download is complete socket.log records all messages (such as polls)
arriving from the switch. The maintenance_llc.pid.log file records administrative
details.
When the LLC is running, all downloading has been completed, and the “**Ready to
accept connections” message appears, SwitchManager can be started.
When LLC is running, it automatically sends the host system time to all the MSP
1010s in the system.
LLC Arguments
Purpose
Use the arguments listed in this section when in a Windows Command Prompt to
change the default behavior of LLC at startup.
Argument -p
Change LLC Port
By default, the LLC accepts TCP/IP connections from SwitchKit applications on Port
1312. If you want the LLC to bind to a different port, use the -p portNumber
argument. All applications must be informed of any non-default port bindings for
them to connect to the LLC.
Syntax
-p <Port Number>
Example
llc -p 2000
Argument -r
Run LLC in Redundant Mode
To run the LLC in redundant mode as a hot standby, use the -r argument. Use this
argument when starting the redundant LLC. The primary LLC should not use this
argument. To use LLC redundancy, the SK_LLC_HOST, SK_LLC_PORT,
SK_RLLC_HOST, SK_RLLC_PORT environment variables must be set.
Syntax
260
SwitchKit Installation & Maintenance
-r <Internet Address of the Primary LLC>
Example
llc -r 150.10.22.100
Argument -v
Query LLC Version
Displays the version of LLC that is running.
Syntax
-v <no value>
Example
llc -v
Argument -h
Help
Displays a list all of the available arguments for the LLC.
Syntax
-h <no value>
Example
llc -h
Basics of SwitchManager
Description
SwitchManager establishes a connection to the LLC, configures the switch as
specified in the configuration file and begins to monitor the switch. SwitchManager
generates an alarm.log file that logs all API messages sent to and from the switch,
and a maintenance_switchmgr.pid.log file. Use the alarm.log file to debug
configuration issues and to diagnose run-time problems that may occur.
Important! In some cases, the sequence number of an API message in an alarm.log
is different from the sequence number shown in a socket.log.
You will see many messages displayed in the SwitchManager windows. These API
messages are also viewable in the alarm.log file. Messages to cards referenced in the
sample configuration file that you do not have in your system are rejected by the
switch with a negative acknowledgment (NACK). When debugging a configuration,
begin by analyzing the first NACK in the alarm.log file. Many times, multiple alarms
261
MSP
are propagated from one initial problem. By fixing the initial problem, subsequent
alarms may be eliminated as well
Running SwitchManager
This procedure explains how to start SwitchManager for the first time when you plan
to use the ClientView to create your MSP 1010 configuration. If you are not using
ClientView, see SwitchManager Arguments for information on how to start
SwitchManager with an example configuration.
Before you begin
The MSP 1010 system software must be installed before you can start the
SwitchManager. SwitchKit must be installed on your host. You must have a license in
your license directory, indicated by the SK_LICENSE_DIR. For example, using the
default directory, you would install the license file in:
Windows
C:\Program Files\Cantata\common\license
Linux or Solaris
/opt/cantata/common/license
SwitchManager arguments must not be already specified through the shortcut
settings in the Start menu. See SwitchManager Arguments.
Steps
Do the following to start SwitchManager for the first time when using ClientView:
1. Open a Command Prompt window.
2. Specify the path to your installation directory. The default location is:
Windows
C:\Program Files\Cantata\MSP\switchkit\bin
Linux or Solaris
/opt/cantata/MSP/switchkit/bin
1. Type in:
switchmgr -i
262
SwitchKit Installation & Maintenance
4. SwitchManager will start and become active.
5. Minimize the Command Prompt window when you see the message:
fopen:No such file or directory.
SwitchManager Arguments
Purpose
Use the arguments listed in this section when in a Command Prompt to change the
default behavior of SwitchManager.
Argument -i
This argument allows SwitchManager to be started without any configuration file
being specified, usually during initial configuration. It will scan for an existing
system.cfg file and, if present, will copy the configuration to a backup. This option is
used when building a new configuration or loading an existing configuration using a
Cantata Technology graphical user interface. Be advised if loading an existing
configuration, the MSP 1010 will be reconfigured without regard to the tags. Cantata
recommends that the -i argument should not be used on a live system.
Syntax
-i
Example
switchmgr -i
Argument -n
Maintain Only
263
MSP
SwitchManager does not do any configuration on start-up. It does, however, assume
that the contents of the configuration file as already been loaded onto the switch.
Should any cards fail, it reconfigures them according to the configuration file. This is
useful if you know that the switch is already configured correctly, and you want to
avoid taking everything out of service.
Important! This option only applies to the initial startup of the first SwitchManager
to connect to the LLC. In redundant SwitchManager instances, the redundant
LLC will start in Smart Mode since it is actually a continuation of the first
instance of SwitchManager. Also, if the active SwitchManager were to
disconnect and reconnect to LLC it would behave as in Smart Mode.
Syntax
-n <filename>
Example
switchmgr -n tandem.cfg
Argument -s
Smart Mode
SwitchManager examines the configuration tags of all cards in the system that are
taggable. If any cards contain tags different from what is expected, SwitchManager
configures that card. If all the tags are the same, SwitchManager does nothing.
Important! Cantata recommends the -s argument be used when running
SwitchManager in a live environment.
Syntax
-s <filename>
Example
switchmgr -s tandem.cfg
Running DataManager
This procedure explains how to start DataManager for the first time when you plan to
use the ClientView to create your MSP 1010 configuration.
Before you begin
The MSP 1010 system software must be installed before you can start the
DataManager. SwitchKit must be installed on your host. You must have a license in
your license directory, indicated by the SK_LICENSE_DIR. For example, using the
default directory, you would install the license file in:
Windows
264
SwitchKit Installation & Maintenance
C:\Program Files\Cantata\MSPSwitchKit\license
Linux or Solaris
/opt/excel/MSP/license
Steps
While there are several ways to start DataManager, you can also use the following
commands:
1. Open a Command Prompt window.
2. Specify the path to your installation directory.
The default location is:
Windows
C:\Program Files\Cantata\MSPSwitchKit\switchkit\bin
Linux or Solaris
/opt/excel/MSP/switchkit/bin
3. Type in:
datamanager
Running AdminManager
This procedure explains how to start AdminManager for the first time when you plan
to use the ClientView to create your MSP 1010 configuration.
Before you begin
265
MSP
The MSP 1010 system software must be installed before you can start the
AdminManager. SwitchKit must be installed on your host. You must have a license in
your \license directory, indicated by the SK_LICENSE_DIR. For example, using the
default directory, you would install the license file in:
Windows
C:\Program Files\Cantata\MSPSwitchKit\license
Linux or Solaris
/opt/excel/MSP/license
Steps
While there are several ways to start AdminManager, you can also use the following
commands:
1. Open a Command Prompt window.
2. Specify the path to your installation directory.
The default location is:
Windows
C:\Program Files\Cantata\MSPSwitchKit\switchkit\bin
Linux or Solaris
/opt/excel/MSP/switchkit/bin
3. Type in:
adminmanager
Redundancy Setup
SwitchKit Redundancy
266
SwitchKit Installation & Maintenance
Overview
In the basic SwitchKit architecture, all call processing and OAM functions are
performed through the LLC. All applications require the LLC for communicating with
the switch. If the LLC stops running, no further call processing can take place. To
eliminate the LLC as a single point of failure, run a redundant LLC. Ensure that a
copy of the license is in the corresponding license folder, of the redundant SwitchKit.
This potentially avoids a situation, where the RLLC is active and the MSP 1010
resets, leading to a license failure.
Description
The Redundant LLC (RLLC) is a hot standby for the Primary LLC (PLLC). The RLLC
mirrors the state of the PLLC, and, if the PLLC goes down, RLLC becomes the active
LLC. All applications connect to the RLLC automatically.
Running LLC in Redundant Mode
To run the LLC in redundant mode, use the -r argument. The -r flag tells the RLLC
where to find the PLLC. This can consist of just a host name, or optionally a host
name followed by a colon followed by a TCP port where the primary LLC is waiting for
connections. By default, it assumes the default port of 1312. See Running Redundant
LLCs.
You cannot run two LLCs on the same host computer accepting socket connections
on the same port.
Running SwitchManager in Redundant Mode
For redundancy, SwitchManager uses the LLC and Application Redundancy. See
Redundancy in the SwitchKit Programmer’s Guide. When running redundant
SwitchManagers, both must be started in smart mode (using the -s argument).
When When multiple SwitchManagers connect to LLC, the first one connected
becomes Primary. This SwitchManager remains primary unless there is an LLC
switchover. In this case, the new active LLC selects the first SwitchManager that
connects as primary. In some cases, this induces a switchover of SwitchManagers,
which is transparent to the system.
Specifying the location of the RLLC for Applications
Once you are running an RLLC, all applications that connect to the PLLC, including
SwitchManager, must know the location of the RLLC so they can automatically
reconnect to the RLLC in case of a PLLC failure. This is done through setting the
following environment variables:


SK_RLLC_HOST (see the environment variables list)
SK_RLLC_PORT (see the environment variables list)
These values must be set before the applications are run. They are only examined on
start-up. You cannot dynamically configure SwitchKit Redundancy. Please refer to
Environment Variables Modify SwitchKit Default Behavior
Example
267
MSP
For example, in the default file, you could have:
rllc_host: pc2
rllc_port:1200
This would specify to all applications starting up that there is a redundant LLC
running on host pc2, on the TCP port of 1200. Environmental variables must be set
the same on both the Primary host and the Redundant host.
Note: Do not use 'LocalHost" for any of the SK_xLLC_HOST variables. Always
use Host Name (Host ID) or Host IP address.
Running Redundant LLCs
This procedure describes the available parameters for running a redundant Low-Level
Communicator (LLC) on Windows or UNIX.
Before you begin
The MSP 1010 system software must be installed before you can start an LLC.
SwitchKit must also be installed on your system. The LLC parameters must not be
already specified through the shortcut settings in the Start menu, refer to
Configuring SwitchKit to Run from the Start Menu.
Steps to start LLCs without ClientView
Do the following to start redundant LLCs:


Open a Command Prompt window.
Specify the path to your installation directory. For the default locations:
o
o
o
Windows C:\Program Files\Cantata\MSPSwitchKit\switchkit\bin
UNIX /opt/cantata/MSP/switchkit/bin
On the primary Host (Host 1) set the following system variables:
SK_LLC_HOST=localhost
SK_LLC_PORT=1312
SK_RLLC_HOST=<IP Address> (IP Address of Host 2)
SK_RLLC_PORT=1312

On the Secondary Host ( Host 2 ) set the following system variables :
SK_LLC_HOST=<IP Address> (IP Address of Host 1)
SK_LLC_PORT=1312
SK_RLLC_HOST= localhost
SK_RLLC_PORT=1312


268
Start Primary LLC on Host 1:
Windows Syntax llc
UNIX Syntax ./llc
Start redundant LLC on Host 2
SwitchKit Installation & Maintenance
Windows Syntax llc -r <IP Address of Host 1>



UNIX Syntax ./llc -r <IP Address of Host 1>
Start SwitchManager on either Host 1 or Host 2. For redundant
SwitchManagers start the process on both hosts using the -s option for both.
See that the primary LLC shares data sending multiple messages to the "new
LLC'. "Done sharing data with new llc...."
Verify that the LLC on Host 2 is in a standby state. The example below shows
the type of messages your would expect to see in your console window:
Jul 22 2004 11:38:22: using /usr/local/switchkit for SK_LIB_DIR
Jul 22 2004 11:38:22: **Running with ExcelLLC
Jul 22 2004 11:38:22: Waiting for connections on port 1312
Jul 22 2004 11:38:22: Connecting to 135.119.52.167 (135.119.52.167) on port 1312
Jul 22 2004 11:38:22: Connected to 135.119.52.167 as 2
Jul 22 2004 11:38:22: Found another llc running, receiving sync info...
Jul 22 2004 11:38:22: Received LogLevel Message and set log level to 1
Jul 22 2004 11:38:22: This LLC is Synchronized
Jul 22 2004 11:38:22: ** Standing by in redundant configuration
Failure Scenarios Resolved with Redundancy
Description
You can configure LLC Redundancy to avoid disruption of service in a production
environment. Avoid as many single points of failure as possible in your configuration.
The following diagrams illustrate a redundant configuration using two host
computers.
Host 1 is acting as the primary host and is running the following:

LLC (PLLC) connected to the MSP 1010s in the Excel platform.

Any custom application, such as call processing applications and SNMP
connected to the PLLC.

The primary SwitchManager, connected to the PLLC manages the node.
Host 2 is acting as the Secondary Host and is running the following:

The RLLC, which is connected to the PLLC (rather than the MSP 1010).

A second copy of the custom application. The LLC shares traffic between the
two applications.

A secondary SwitchManager, which takes over management of the node
should the primary SwitchManager fail.
Line Key
In the following diagrams we use different lines to illustrate different states of the
connection.

Solid Line
269
MSP
A solid line illustrates an established connection.

Bold Solid Line

Dotted Line
A bold solid line illustrates a new established connection.
A dotted line illustrates a lost connection.
SwitchKit Redundancy Setup
Primary Host Failure
Should the Primary Host fail, RLLC recognizes the failure by the lack of Poll message
responses from the PLLC and it becomes the active LLC.
If the primary host fails, SwitchManager, the ClientView, and custom applications,
continue processing as before. When the applications attempt to connect to the LLC
again, they first attempt to connect to the PLLC, which fails, and will then connect to
the RLLC. This is done automatically and only requires that the IP addresses for the
primary & redundant host are defined. There are no additional application
requirements for this.
Primary SwitchManager Failure
If the primary SwitchManager fails, the secondary SwitchManager receives an
application disconnect message. It then takes over control of the configuration and
management of the switch.
270
SwitchKit Installation & Maintenance
Important! When SwitchManager starts, it configures the entire MSP 1010 unless
an alternative option is used. It is recommended that both the primary and
redundant SwitchManagers in a production environment are configured to use
Smart Mode.
Primary LLC Failure
Should the primary LLC fail, the RLLC recognizes the failure by the lack of response
to Poll messages between them.The RLLC becomes the active LLC. It takes over the
connections to all matrices in the MSP 1010 and accepts connections from all
applications.
Logging
Log File Management
SwitchKit manages the logs files so they are not overwritten and not allowed to
continue to grow indefinitely. When attempting to open a log file for the first time, if
a file of that name already exists, it is renamed, using a random three-digit number.
For example, whenever the LLC starts, if there is already a messages.log file, it is
renamed to messages.nnn.log, where <nnn> is a random three-digit number.
All log files used by SwitchKit are automatically closed after a specified amount of
time. By default, this is every 24 hours. The first time that logfile is closed, it is
renamed to logfile_date.001.suffix. The suffix of the closed file is preserved. The
logfile will once again contain current information. Once the closeout period has
passed again, logfile is moved to logfile_date_002.suffix. Closed files can be archived
or deleted, without affecting the current logging.
Log Directory
By default, the log files are written to the current directory of the program.
Alternatively, you can specify SK_LOG_DIR as the directory in which to write these
log files.
Important! Remove log files often to avoid filling your disk space and causing
erratic system behavior. If you do not move your log files regularly, lack of
disk space may cause a system outage.
Close Time
You can specify the time the file is closed by modifying the default behavior. By
default, each file is closed every day at midnight local time. The environment
variable SK_FILE_CLOSEOUT_HOUR can be used to modify the time to close the
files. The default is 0 (midnight). See SK_FILE_CLOSEOUT_ HOUR for more
information.
Close Duration
Alternatively, the environment variable SK_FILE_LIFETIME can specify in hours how
frequently the files are closed. For example, if SK_FILE_LIFETIME is specified to be
6, then the log files will be closed 4 times a day, at midnight, 6a.m., noon, and
6p.m. See SK_FILE_LIFETIME (2-36) for more information.
271
MSP
SK_FILE_CLOSEOUT_HOUR and SK_FILE_LIFETIME should not both be used on a
system.
Maximum Size
SK_FILE_MAX_SIZE specifies the size, in megabytes, to which the log file is allowed
to grow before cycling. When a log cycles because the size is too big, the existing
timer is not reset. The log will still cycle at the proper time. See SK_FILE_MAX_SIZE
for more information.When logs roll because of size, optionally, they can all roll
using SK_FILE_EXPIRE_ALL_AT_ONCE.
SK_FILE_MAX_SIZE can be used with all other log file management environment
variables.
Debugging Channel Management Issues
There is additional logging available to debug channel management issues. As this is
CPU-intensive logging, it should only be done with the help of an Excel support
engineer. Please contact Excel technical support for assistance.
Log Files
All modules within SwitchKit generate log files. You can also generate your own log
files, and have them managed by SwitchKit. Log file entries can also be displayed on
the screen. By default, SwitchManager and LLC send their output to the screen as
well as to the log file, while the applications write it only to the log file. The behavior
of the LLC and SwitchManager can be changed through the environment variables.
The following logs are created by the SwitchKit processes at run-time:
Log
created by...
Maintenance
LLC, SwitchManager, DataManager and each
SwitchKit application
Alarm
Messages
Socket
XMLClient
EventLog
Statmgr
Userdefined
SwitchManager
LLC (optional)
LLC (optional)
DataManager
DataManager
DataManager
LLC (optional)
Alarm Log
File name: alarm.log
272
SwitchKit Installation & Maintenance
SwitchManager generates this file. It logs all actions taken by the SwitchManager in
configuring the switch, and the text of any alarm conditions that occur on the switch.
If a switch software fault occurs, it is written to the alarm.log.
Maintenance Log
File name: maintenance.xxx.log
This type of log is generated by the LLC, the SwitchManager, and all applications
linked with the SwitchKit API library. The actual file names are:

maintenance_lc.PID.log

maintenance_DataManager.PID.log



maintenance_switchmgr.PID.log
maintenance_appName.PID.log
maintenance_app.PID.log
where PID is the process ID of that application.
Important! For the maintenance_app.PID.log, the outstanding message limit is
6552 per application. A warning is printed by the API when the key wrapping
occurs: "App has more than 6553 outstanding messages, message
collision may occur!".
Messages Log
File name: message.log
This file is generated by the LLC and shows all messages sent between the LLC and
the MSP 1010 switch, using the EXS API. The EXS API uses a hexadecimal
numbering scheme. To interpret EXS API message formats, see the EXS API
hexadecimal format information for each message.
The message.log includes the following abbreviations:
Abbreviation
Description
->
outbound or inbound message
=>
H REQ
H LLC
H ART
H21
X2001
H
UNKNN
ACK (acknowledgement) message
LLC internal request manager
LLC internal module
LLC internal artificial ACK, likely generated due to ACK timer
expiration
External Host Application Number 21
External Device with logical link value 2001 (200 = NodeType
Call Server 1=node ID)
LLC Host
Unknown, the LLC was unable to resolve the sender. This should
not happen.
273
MSP
Examples
Jan 29 2004 19:57:58 X2001 ->H : 00 ab 00 4d 01 00 10 01 00 03 02 09 00 05 00 00
Jan 29 2004 19:57:58 H LLC =>H REQ : 00 9e 00 00 01 00 10 01 00 03 02 08 00 05 00 00 (orig msg was
00 9e 00 00 01 )
Jan 29 2004 19:57:58 H REQ ->X2001 : 00 b5 00 00 01 01 1d 04 13 39 3a
Jan 29 2004 19:57:58 H LLC =>H REQ : 00 9f 00 01 01 00 10 (orig msg was 00 9f 00 01 01 14 )
Jan 29 2004 19:57:58 H REQ ->X2001 : 00 83 00 01 01 00 01 01 01 01
Jan 29 2004 19:26:17 H ART =>H REQ : 00 9f 00 04 01 f0 09 (orig msg was 00 9f 00 04 01 14 )
Jan 29 2004 19:06:31 UNKNN=>H1 : 00 83 00 1b 01 00 10 00 01 01 01 14 f3 00 00 43
04 01 04 00 00 01 79 02 00 00 01 01 01 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 f3 00 00 00 00 00 (orig msg was 00 83 00 1b 01 00 01 01 01 14 )
Socket Log
SwitchKit LLC can create and maintain a log file named, socket.log, which logs all the
messages going from the MSP 1010 to the host and from the host to the MSP 1010.
This log is different from messages.log, because it logs everything that goes across
the socket, prior to processing, including the length of the message.
The socket log file includes the following abbreviations:
Abbreviation
Description
1
Logical Node
ID
X
[10.10.156.24]
H
MSP 1010
Socket IP
address
Host
Example Socket.log
The following example socket log shows an inbound and outbound message:
Jan 11 2002 12:59:57 X1[10.10.156.24]->H : 00 ab 00 38 01 00 10 01 00 05 00 01 01 01 00 00
Jan 11 2002 12:59:57 H->X1[10.10.156.24] : 00 ab 00 38 01
XMLClient Log
File name: XMLClient_xxx_DMPIDyyy_CIDzzz.log
274
SwitchKit Installation & Maintenance
This file is generated by DataManager to record all interactions between
DataManager and its clients (ClientView and EventView). These interactions come in
the form of messages which are sent in XML format. The file names are:


XMLClient_Internal_DMpid00404_CID001.log – logs internal messages sent
by DataManager to itself for processing.
XMLClient_JAVA_DMpid03848_CID005.log – logs messages sent from
ClientView or EventView to DataManager for processing along with any
responses from DataManager and indication of state change by DataManager
or the clients.
The 5 digits after DMpid reflect the process ID of the DataManager that the client is
connected to.
The 3 digits after CID is a unique client identifier assigned to each client of a
particular instance of DataManager.
EventLog
File name: EventLog_xxx.csv
This file is generated by DataManager to record all events that are worthy of
reporting to an EventView client. Events that would be logged to an EventView client
will be logged in this file independent of whether an EventView client is running or
not. The file name is (where PID is the process ID of the DataManager):

EventLog_PID.log
The events are stored in a comma-separated format, one line per event. The file can
be opened using Microsoft Excel®.
When imported to Microsoft Excel, a typical entry may appear as follows:
Time
Entity
Severity
Node
Description
3/8/2006
12:01
Node
Info
1
Link is Up
3/8/2006
12:01
Node
Info
0
3/8/2006
12:01
Node
Info
1
HostAlarm(Software
License Verified)
3/8/2006
12:01
Node
Info
0
3/8/2006
12:01
Node
Info
1
3/8/2006
12:01
Node
Info
0
Link is Up
HostAlarm(Software
License Verified)
HostAlarm(Software
Version Matched)
HostAlarm(Software
Version Matched)
Statmgr Log
275
MSP
File name: statmgr.log
This file is generated by the DataManager to record all statistics file creation
activities. Statistics Information is written to comma separated value files which are
generated in the default folder or to another folder as set in SK_STATS_DIR. The
default folders are:
Windows
C:\Program Files\Cantata\common\stats
UNIX
/opt/cantata/common/stats
User-specified log files
By using the function sk_getManagedFile, you can create your own log files, to be
managed by SwitchKit. The format and contents of the logs are under the control
and discretion of the application developer.
Server Status Change
Server Status Change Feature
The Server Status Change feature informs all registered client applications about any
change in the switch status. The feature is enabled with the message
SK_ServerStatusChange, managed by the LLC to inform the clients of a node’s status
at all times.
This feature removes the requirement for SwitchKit applications to monitor the poll
messages and respond accordingly. Applications can register for the
SK_ServerStatusChange message and base decisions on it.
For the SK_ServerStatusChange message, the MSP 1010 status is reflected in the
matrix parameters.
Server Status Change Events
The SK_ServerStatusChange message is created within LLC, and responds to all
registered applications for any one of the following events:






The data contained within two consecutive poll message changes
(SK_PM_CHANGE).
A socket connection is closed (SK_LINK_DOWN).
A socket connection is opened, and the MSP 1010 indicates that is is ready to
communicate. (SK_LINK_UP).
An application connects to the LLC (SK_SSC_UPDATE).
The LLC receives a NodeStatusReport message.
The LLC receives a response to a NodeStatusQuery.
ServerStatusChange
Type
276
SwitchKit Installation & Maintenance
SwitchKit API message
Description
The LLC sends the ServerStatusChange message containing all the information
needed by an application to determine the current status of a node. The message is
sent when the LLC discovers a change in MSP 1010 status.
C Structure
typedef struct {
unsigned short Status;
UBYTE SystemType;
UBYTE MatrixSide;
UBYTE MatrixState;
UBYTE AdjMatrixState;
UBYTE StatusBits;
UBYTE Reserved1;
UBYTE Reserved2;
unsigned short ExcelPort;
int PhysicalNode;
UBYTE LogicalNode;
UBYTE HostNode;
UBYTE NodeStatus;
UBYTE MessageTrigger;
UBYTE FromPrimary;
UBYTE SocketStatus;
unsigned short UpdatedFieldBits;
UBYTE reserved40[1];
} SK_ServerStatusChange;
C++ Class
class SKC_ServerStatusChange : public SKC_DummyMessage {
public:
unsigned short getStatus() const;
void setStatus(unsigned short x);
UBYTE getSystemType() const;
void setSystemType(UBYTE x);
UBYTE getMatrixSide() const;
void setMatrixSide(UBYTE x);
UBYTE getMatrixState() const;
void setMatrixState(UBYTE x);
UBYTE getAdjMatrixState() const;
277
MSP
void setAdjMatrixState(UBYTE x);
UBYTE getStatusBits() const;
void setStatusBits(UBYTE x);
UBYTE getReserved1() const;
void setReserved1(UBYTE x);
UBYTE getReserved2() const;
void setReserved2(UBYTE x);
unsigned short getExcelPort() const;
void setExcelPort(unsigned short x);
int getPhysicalNode() const;
void setPhysicalNode(int x);
UBYTE getLogicalNode() const;
void setLogicalNode(UBYTE x);
UBYTE getHostNode() const;
void setHostNode(UBYTE x);
UBYTE getNodeStatus() const;
void setNodeStatus(UBYTE x);
UBYTE getMessageTrigger() const;
void setMessageTrigger(UBYTE x);
UBYTE getFromPrimary() const;
void setFromPrimary(UBYTE x);
UBYTE getSocketStatus() const;
void setSocketStatus(UBYTE x;
unsigned short getUpdatedFieldBits();
void setUpdatedFieldBits(unsigned short x);
};
Conditions for Sending the ServerStatusChange Message
The following list shows the conditions that will cause the LLC to send a
ServerStatusChange message:



278
SK_PM_CHANGE - sent when the first poll is received by the LLC for a Matrix
ControllerMSP 1010. Also sent any time a value changes in the Poll. The
UpdatedFieldBits field indicates which fields have changed since the last poll.
SK_SSC_UPDATE - sent under the following conditions: When an application
registers for the ServerStatusChange notification via sk_msgRegister(), an
SSC_UPDATE is sent for each node the LLC is currently connected to which
has a Matrix ControllerMSP1010 in the active state.
When an
application issues an AddLLCNode, an SSC_UPDATE may be generated if the
LLC already knew about the node and the LLC is currently connected to the
active Matrix ControllerMSP 1010 for that node. In other words, if the Link is
considered to be up.
SK_LINK_UP - sent under the following conditions:
SwitchKit Installation & Maintenance
1. This message is sent to indicate that there is a connection to the active
Matrix ControllerMSP 1010 for this node and the Matrix ControllerMSP
1010 is ready to be configured. This will be sent if this is a new
condition (i.e. we were not previously connected to the active Matrix
ControllerMSP1010).
2. Sent if an application has performed an AddLLCNode, the LLC is
currently connected to the specified node, and the LLC is connected to
the active Matrix ControllerMSP 1010 of that node.

3. When an application registers for the ServerStatusChange notification
via sk_msgRegister(), and the LLC is connected to the active Matrix
ControllerMSP 1010 of a node.
SK_LINK_DOWN - sent under the following conditions:
1. This message is sent to indicate that there is NO connection to the
active Matrix ControllerMSP 1010 for a node. This will be sent if this is
a new condition (that is, we were previously connected to the active
Matrix ControllerMSP 1010).
2. Sent if an application has performed an AddLLCNode, and the LLC is
not currently connected to the specified node’s active Matrix
ControllerMSP1010.
3. When an application registers for the ServerStatusChange notification
via sk_msgRegister(), and the LLC is supposed to be connected to a
node but is not connected to the node's active Matrix ControllerMSP
1010.
More on SK_LINK_UP and SK_LINK_DOWN




Registering for ServerStatusChange will result in an SK_LINK_UP or
SK_LINK_DOWN for each node controlled by the LLC. If an SK_LINK_UP is
sent, it will be followed by an SK_SSC_UPDATE with the last poll from the
active Matrix ControllerMSP 1010.
Performing an AddLLCNode will result in an SK_LINK_UP or SK_LINK_DOWN
for the specified node if the LLC is already controlling the node. If an
SK_LINK_UP is sent, it will be followed by an SK_SSC_UPDATE with the last
poll from the active Matrix ControllerMSP 1010, if the LLC is currently
connected to the Matrix ControllerMSP 1010 in the active state.
SK_PM_CHANGE, SK_SOCKET_CHANGE, SK_LINK_UP and SK_LINK_DOWN
are generated to indicate a change in state.
SK_NSQ_CHANGE or SK_NSR_CHANGE are generated upon arrival of
NodeStatusQueryAck or NodeStatusReport from the MSP 1010.
Arguments
The following table indicates what arguments are valid for a specific message trigger:
MessageTrigger
Argument
PhysicalNode
Description
Represents the requested Node ID
279
MSP
LogicalNode
Represents the current Node ID as
reported by the MSP 1010 in PollMessage
SocketStatus
1 always. Socket must be connected for
this indication to occur.
Status
Status from PollMessage
SystemType
SK_PM_CHANGE
or
SK_SSC_UPDATE
System Type(Poll Source) from
PollMessage
MatrixSide
Matrix Controller ID from PollMessage
MatrixState
Matrix State(Card State) from
PollMessage
AdjMatrixState
Adjacent Card State from PollMessage
ExcelPort
Double Byte after Multi Host Connection
Status Byte 2 in PollMessage
StatusBits
UpdatedFieldBits
SK_LINK_UP
or
SK_LINK_DOWN
PhysicalNode
LogicalNode
Card Status from PollMessage
Bit mask indicating which fields in the poll
were updated. See table below for details
of the meaning of the bits. Only set for
SK_PM_CHANGE
Requested Node ID
Requested Node ID
Constants
The following table contains information for the field UpdatedFieldBits. You can
combine any number of settings in this bit mask:
Constants
SK_STATUS_CHANGE
SK_SYSTEMTYPE_CHANGE
SK_MATRIXSIDE_CHANGE
SK_MATRIXSTATE_CHANGE
SK_ADJMATRIXSTATE_CHANGE
SK_STATUSBITS_CHANGE
SK_LOGICALNODE_CHANGE
280
Changed Argument in Server
StatusChange message
Status
SystemType
MatrixSide
MatrixState
AdjMatrixState
StatusBits
LogicalNode
SwitchKit Programmer's Information
Addressing Functions
Addressing Functions
Address Information Block (AIB) helper functions are available in SwitchKit. A
description of what the function does, the syntax and the type of AIB used with a
given function, are provided. See AIB Manipulation Functions and SS7 Addressing
Functions.
With addressing functions, "sk_get..." functions return values that are being
retrieved. Values are not returned for "sk_set..." functions.
These functions are designed to provide assistance to the application developer in
initializing the information contained in various AIBs as described in the API
Reference.
How Applications Use AIB Functions
You must use the appropriate functions for initializing the AIBs. Using the wrong
functions or not using all the functions necessary to completely initialize an AIB may
result in an improperly defined AIB. See AIB Manipulation Functions and SS7
Addressing Functions for a mapping of the functions and AIBs.
When attempting to initialize a Range of Channels (0x0D) AIB, you must call all of
the following functions:

setAIBStartSpan()

setAIBEndSpan()


setAIBStartChannel()
setAIBEndChannel()
AIB Manipulation Functions
To assist with the standard state machines, the SwitchKit API allows for incoming
messages to be automatically dispatched to an application.
Name
getAIBSize
setAIBRange
Syntax
int sk_getAIBSize(UBYTE
*AIBBlock);
void sk_setAIBRange( UBYTE
*AIBBlock,
XBYTE aStartSpan,
UBYTE aStartChannel, XBYTE
anEndSpan,
UBYTE anEndChan);
setAIBChannel
void
sk_setAIBChannelEntity(UBYTE
*AIBBlock, XBYTE aSpan,
Threadsafe Syntax
AIB used
int skts_getAIBSIze
All
(UBYTE *AIBBlock)
void skts_setAIBRange( UBYTE
*AIBBlock,
XBYTE aStartSpan,
UBYTE aStartChannel,
0x0D
Range of
Channels
XBYTE anEndSpan,
UBYTE anEndChan )
void skts_setAIBChannelEntity
281
0x0D
Channel
MSP
*AIBBlock, XBYTE aSpan,
UBYTE aChannel);
getAIBStartSpan
XBYTE sk_getAIBStartSpan
setAIBStartSpan
getAIBStartChannel
setAIBStartChannel
getAIBEndSpan
setAIBEndSpan
getAIBEndChannel
setAIBEndChannel
getAIBSpanA
setAIBSpanA
282
XBYTE aSpan,
UBYTE aChannel)
XBYTE
skts_getAIBStartSpan(const
UBYTE *AIBBlock)
0x0D
void sk_setAIBStartSpan(
UBYTE *AIBBlock,
void skts_setAIBStartSpan(
UBYTE *AIBBlock,
0x0D
UBYTE
sk_getAIBStartChannel( const
UBYTE *AIBBlock )
UBYTE
skts_getAIBStartChannel(
const UBYTE *AIBBlock )
(const UBYTE *AIBBlock)
XBYTE aStartSpan)
XBYTE aStartSpan)
void sk_setAIBStartChannel(
UBYTE *AIBBlock,
void skts_setAIBStartChannel(
UBYTE *AIBBlock,
XBYTE sk_getAIBEndSpan(
const UBYTE *AIBBlock )
XBYTE skts_getAIBEndSpan(
const UBYTE *AIBBlock )
UBYTE aStartChannel )
UBYTE aStartChannel )
void sk_setAIBEndSpan(
UBYTE *AIBBlock,
void skts_setAIBEndSpan(
UBYTE *AIBBlock,
UBYTE sk_getAIBEndChannel(
const UBYTE *AIBBlock )
UBYTE
skts_getAIBEndChannel( const
UBYTE *AIBBlock )
XBYTE anEndSpan )
XBYTE anEndSpan )
void sk_setAIBEndChannel(
UBYTE *AIBBlock,
void skts_setAIBEndChannel(
UBYTE *AIBBlock,
XBYTE sk_getAIBSpanA(const
UBYTE *AIBBlock )
XBYTE
skts_getAIBSpanA(const
UBYTE *AIBBlock )
UBYTE anEndChannel)
UBYTE anEndChannel)
void sk_setAIBSpanA( UBYTE
*AIBBlock,
void skts_setAIBSpanA( UBYTE
*AIBBlock,
UBYTE sk_getAIBChannelA(
const UBYTE *AIBBlock )
UBYTE skts_getAIBChannelA(
const UBYTE *AIBBlock )
XBYTE aSpanA )
getAIBChannelA
(UBYTE *AIBBlock,
XBYTE aSpanA )
Range of
Channels
Range of
Channels
0x0D
Range of
Channels
0x0D
Range of
Channels
0x0D
Range of
Channels
0x0D
Range of
Channels
0x0D
Range of
Channels
0x0D
Range of
Channels
0x0D
Channels
with two
AEs
0x0D
Channels
with two
AEs
0x0D
Channels
with two
AEs
SwitchKit Programmer's Information
setAIBChannelA
void sk_setAIBChannelA(
UBYTE *AIBBlock
void skts_setAIBChannelA(
UBYTE *AIBBlock,
0x0D
getAIBSpanB
XBYTE sk_getAIBSpanB( const
UBYTE *AIBBlock )
XBYTE skts_getAIBSpanB(
const UBYTE *AIBBlock )
0x0D
setAIBSpanB
void sk_setAIBSpanB( UBYTE
*AIBBlock,
void skts_setAIBSpanB( UBYTE
*AIBBlock,
getAIBChannelB
UBYTE sk_getAIBChannelB(
const UBYTE *AIBBlock )
UBYTE skts_getAIBChannelB(
const UBYTE *AIBBlock)
setAIBChannelB
void sk_setAIBChannelB(
UBYTE *AIBBlock,
void skts_setAIBChannelB(
UBYTE *AIBBlock,
XBYTE sk_getAIBSpan( const
UBYTE *AIBBlock )
XBYTE skts_getAIBSpan( const
UBYTE *AIBBlock )
UBYTE aChannelA)
XBYTE aSpanB)
UBYTE aChannelB )
getAIBSpan
UBYTE aChannelA )
XBYTE aSpanB)
UBYTE aChannelB )
Channels
with two
AEs
Channels
with two
AEs
0x0D
Channels
with two
AEs
0x0D
Channels
with two
AEs
0x0D
Channels
with two
AEs
0x0C
Logical
Span
OR
0x0D
Channel
OR
0x3C
setAIBSpan
void sk_setAIBSpan( UBYTE
*AIBBlock,
XBYTE aSpan )
void skts_setAIBSpan( UBYTE
*AIBBlock, XBYTE aSpan)
Number of
CICs
0x0C
Logical
Span
OR
0x0D
Channel
OR
0x3C
Number of
283
MSP
getAIBChannel
UBYTE sk_getAIBChannel(
const UBYTE *AIBBlock )
UBYTE skts_getAIBChannel(
const UBYTE *AIBBlock)
CICs
0x0D
ChannelOR
0x3C
setAIBChannel
void sk_setAIBChannel( UBYTE
*AIBBlock," UBYTE aChannel)
void skts_setAIBChannel(
UBYTE *AIBBlock,
UBYTE aChannel)
getAIBNumChannels
UBYTE
sk_getAIBNumChannels( const
UBYTE *AIBBlock )
UBYTE
skts_getAIBNumChannels(
const UBYTE *AIBBlock )
setAIBNumChannels
void sk_setAIBNumChannels(
UBYTE *AIBBlock,
void
skts_setAIBNumChannels(
UBYTE *AIBBlock,
UBYTE aNumChannels)
getAIBSlot
UBYTE sk_getAIBSlot( const
UBYTE *AIBBlock )
setAIBSlot
setAIBDSPChip
getAIBDSPSlot
setAIBDSPSlot
getAIBDSPSIMM
setAIBDSPSIMM
getAIBSIMM
284
UBYTE aNumChannels)
Number of
CICs
0x0D
ChannelOR
0x3C
Number of
CICs
0x3C
Number of
CICs
0x3C
Number of
CICs
UBYTE skts_getAIBSlot( const
UBYTE *AIBBlock )
0x01
void sk_setAIBSlot( UBYTE
*AIBBlock, UBYTE aSlot )
void skts_setAIBSlot( UBYTE
*AIBBlock, UBYTE aSlot )
0x01
void sk_setAIBDSPChip(
UBYTE *AIBBlock,
void skts_setAIBDSPChip(
UBYTE *AIBBlock,
UBYTE sk_getAIBDSPSlot(
const UBYTE *AIBBlock )
UBYTE skts_getAIBDSPSlot(
const UBYTE *AIBBlock )
0x12
void sk_setAIBDSPSlot( UBYTE
*AIBBlock,
void skts_setAIBDSPSlot(
UBYTE *AIBBlock,
0x12
UBYTE sk_getAIBDSPSIMM(
const UBYTE *AIBBlock )
UBYTE skts_getAIBDSPSIMM(
const UBYTE *AIBBlock )
0x12
void sk_setAIBDSPSIMM(
UBYTE *AIBBlock,
void skts_setAIBDSPSIMM(
UBYTE *AIBBlock,
0x12
UBYTE sk_getAIBSIMM( const
UBYTE *AIBBlock )
UBYTE skts_getAIBSIMM(
const UBYTE *AIBBlock )
UBYTE x)
UBYTE aDSPSlot )
UBYTE aDSPSIMM )
UBYTE x)
UBYTE aDSPSlot )
UBYTE aDSPSIMM )
Slot
Slot
0x22
DSP Chip
DSP SIMM
DSP SIMM
DSP SIMM
DSP SIMM
0x12
DSP SIMM
SwitchKit Programmer's Information
setAIBSIMM
void sk_setAIBSIMM( UBYTE
*AIBBlock, UBYTE aSIMM )
void skts_setAIBSIMM( UBYTE
*AIBBlock, UBYTE aSIMM )
x12
getAIBDS3
UBYTE sk_getAIBDS3( const
UBYTE *AIBBlock )
UBYTE skts_getAIBDS3( const
UBYTE *AIBBlock )
0x32
setAIBDS3
void sk_setAIBDS3( UBYTE
*AIBBlock,
void skts_setAIBDS3( UBYTE
*AIBBlock, UBYTE aDS3 )
XBYTE sk_getAIBV5ID( const
UBYTE *AIBBlock )
XBYTE skts_getAIBV5ID( const
UBYTE *AIBBlock )
0x2C
void sk_setAIBV5ID( UBYTE
*AIBBlock,
void skts_setAIBV5ID( UBYTE
*AIBBlock, XBYTE aV5ID )
0x2C
XBYTE
sk_getAIBRouterHandle( const
UBYTE *AIBBlock )
XBYTE
skts_getAIBRouterHandle(
const UBYTE *AIBBlock )
XBYTE aRouterHandle )
XBYTE aRouterHandle )
getAIBV5ID
setAIBV5ID
getAIBRouterHandle
setAIBRouterHandle
getAIBChannelSlot
setAIBChannelSlot
getAIBSlotB
setAIBSlotB
UBYTE aDS3 )
XBYTE aV5ID )
void sk_setAIBRouterHandle(
UBYTE *AIBBlock,
UBYTE
sk_getAIBChannelSlot(const
UBYTE *AIBBlock)
void
sk_setAIBChannelSlot(UBYTE
*addrInfo,
UBYTE x)
XBYTE sk_getAIBSlotB(const
UBYTE *AIBBlock)
void sk_setAIBSlotB(UBYTE
*addrInfo, XBYTE x)
0x32
DS3 Offset
V5 ID
V5 ID
0x29
Router
0x29
UBYTE
skts_getAIBChannelSlot(const
UBYTE *AIBBlock)
0x01
Router
Slot
void
skts_setAIBChannelSlot(UBYTE
*addrInfo,
0x01
XBYTE skts_getAIBSlotB(const
UBYTE *AIBBlock)
0x01
void skts_setAIBSlotB(UBYTE
*addrInfo, XBYTE x)
0x01
UBYTE x)
To assist with the standard state machines, the SwitchKit API allows for incoming
messages to be automatically dispatched to an application.
Syntax
DS3 Offset
void skts_setAIBRouterHandle(
UBYTE *AIBBlock,
SS7 Addressing Functions
Name
DSP SIMM
Threadsafe Syntax
285
Slot
Slot
Slot
MSP
getAIBBaseVariantID
UBYTE
sk_getAIBBaseVariantID(const
UBYTE *AIBBlock);
N/A
setAIBBaseVariantID
void
sk_setAIBBaseVariantID(UBYTE
*AIBBlock,XBYTE
aBaseVariantID);
N/A
getAIBSubrate
UBYTE sk_getAIBSubrate( const
UBYTE *AIBBlock )
UBYTE skts_getAIBSubrate( const
UBYTE *AIBBlock )
UBYTE aSubrate )
UBYTE aSubrate )
setAIBSubrate
setAIBSubrateEntity
void sk_setAIBSubrate( UBYTE
*AIBBlock,
void sk_setAIBSubrateEntity(
UBYTE *AIBBlock, XBYTE aSpan,
UBYTE aChannel,
getAIBTerminal
286
UBYTE aSubrate )
UBYTE sk_getAIBTerminal( const
UBYTE *AIBBlock )
void skts_setAIBSubrate( UBYTE
*AIBBlock,
void skts_setAIBSubrateEntity(
UBYTE *AIBBlock, XBYTE aSpan,
UBYTE aChannel,
UBYTE aSubrate )
*/ UBYTE skts_getAIBTerminal(
const UBYTE *AIBBlock );*/
SwitchKit Programmer's Information
setAIBTerminal
setAIBTerminalEntity
UBYTE *AIBBlock )
const UBYTE *AIBBlock );*/
UBYTE aTerminal)
UBYTE aTerminal)
void sk_setAIBTerminal( UBYTE
*AIBBlock,
void
sk_setAIBTerminalEntity(UBYTE
*AIBBlock, XBYTE aSpan,
UBYTE aChannel,
UBYTE aSubrate,
getAIBProfile
setAIBProfile
getAIBCallReference
setAIBCallReference
setAIBCallReferenceEntity
UBYTE aTerminal)
UBYTE sk_getAIBProfile( const
UBYTE *AIBBlock)
void skts_setAIBTerminal( UBYTE
*AIBBlock,
void
skts_setAIBTerminalEntity(UBYTE
*AIBBlock, XBYTE aSpan,
UBYTE aChannel,
UBYTE aSubrate,
UBYTE aTerminal)
UBYTE skts_getAIBProfile( const
UBYTE *AIBBlock)
void sk_setAIBProfile( UBYTE
*AIBBlock,
void skts_setAIBProfile( UBYTE
*AIBBlock,
UBYTE sk_getAIBCallReference(
const UBYTE *AIBBlock )
UBYTE
skts_getAIBCallReference(const
UBYTE *AIBBlock )
UBYTE aProfile )
void
sk_setAIBCallReference(UBYTE
*AIBBlock, UBYTE
aCallReference)
UBYTE aProfile )
void
skts_setAIBCallReference(UBYTE
*AIBBlock, UBYTE aCallReference)
void
sk_setAIBCallReferenceEntity
void
skts_setAIBCallReferenceEntity
UBYTE aProfile,
UBYTE aSlot,
(UBYTE *AIBBlock, UBYTE aSlot,
UBYTE aSubrate,
UBYTE aCallReference)
(UBYTE *AIBBlock,
UBYTE aProfile,
UBYTE aSubrate,
UBYTE aCallReference)
getAIBBaseCICNumber
int sk_getAIBBaseCICNumber(
const UBYTE *AIBBlock )
setAIBBaseCICNumber
void
sk_setAIBBaseCICNumber(UBYTE
*AIBBlock,
void
skts_setAIBBaseCICNumber(UBYTE
*AIBBlock,int aBaseCICNumber)
XBYTE sk_getAIBBaseCICSpan(
const UBYTE *AIBBlock)
XBYTE skts_getAIBBaseCICSpan(
const UBYTE *AIBBlock)
void sk_setAIBBaseCICSpan
void
skts_setAIBBaseCICSpan(UBYTE
getAIBBaseCICSpan
setAIBBaseCICSpan
int aBaseCICNumber)
int skts_getAIBBaseCICNumber(
const UBYTE *AIBBlock )
287
MSP
getAIBBaseCICChannel
setAIBBaseCICChannel
getAIBNumCICs
(UBYTE *AIBBlock,
*AIBBlock, XBYTE aCICSpan)
UBYTE
sk_getAIBBaseCICChannel(const
UBYTE *AIBBlock)
UBYTE
skts_getAIBBaseCICChannel(const
UBYTE *AIBBlock)
UBYTE sk_getAIBNumCICs( const
UBYTE *AIBBlock )
UBYTE skts_getAIBNumCICs( const
UBYTE *AIBBlock )
XBYTE aCICSpan)
void
sk_setAIBBaseCICChannel(UBYTE
*AIBBlock, UBYTE aCICChannel)
void
skts_setAIBBaseCICChannel(UBYTE
*AIBBlock, UBYTE aCICChannel)
setAIBNumCICs
void sk_setAIBNumCICs( UBYTE
*AIBBlock, UBYTE aNumCICs)
void skts_setAIBNumCICs( UBYTE
*AIBBlock, UBYTE aNumCICs)
setAIBCICGroupEntity
void
sk_setAIBCICGroupEntity(UBYTE
*AIBBlock, UBYTE
aBaseCICNumber, UBYTE
aBaseCICSpan, UBYTE
aBaseCICChannel, UBYTE
aNumCICs )
void
skts_setAIBCICGroupEntity(UBYTE
*AIBBlock, UBYTE
aBaseCICNumber, UBYTE
aBaseCICSpan, UBYTE
aBaseCICChannel, UBYTE
aNumCICs )
void sk_setAIBV5IDAndUserPort(
UBYTE *AIBBlock, unsigned short
aV5ID, unsigned short aUserPort)
void skts_setAIBV5IDAndUserPort(
UBYTE *AIBBlock, unsigned short
aV5ID, unsigned short aUserPort)
setAIBV5ID
setAIBV5IDAndUserPort
getAIBStackID
setAIBStackID
void sk_setAIBV5IDAndLink(
UBYTE *AIBBlock, unsigned short
aV5ID, UBYTE aLinkID )
UBYTE sk_getAIBStackID
(const UBYTE *AIBBlock )
void skts_setAIBV5IDAndLink(
UBYTE *AIBBlock, unsigned short
aV5ID, UBYTE aLinkID )
UBYTE skts_getAIBStackID
(const UBYTE *AIBBlock)
void sk_setAIBStackID( UBYTE
*AIBBlock,
void skts_setAIBStackID( UBYTE
*AIBBlock,
getAIBLinkID
UBYTE sk_getAIBLinkID( const
UBYTE *AIBBlock )
UBYTE skts_getAIBLinkID( const
UBYTE *AIBBlock )
setAIBLinkID
void sk_setAIBLinkID( UBYTE
*AIBBlock,
void skts_setAIBLinkID( UBYTE
*AIBBlock,
void sk_setAIBStackEntity(
UBYTE *AIBBlock,
void skts_setAIBStackEntity(UBYTE
*AIBBlock,
UBYTE aStackID)
setAIBStackEntity
UBYTE aLinkID)
UBYTE aStackID,
288
UBYTE aStackID)
UBYTE aLinkID)
UBYTE aStackID,
SwitchKit Programmer's Information
getAIBObjectInstanceID
setAIBObjectInstanceID
getAIBObjectType
setAIBObjectType
getAIBModule
setAIBModule
getAIBAssignSpanSlot
setAIBAssignSpanSlot
getAIBAssignSpanOffset
setAIBAssignSpanOffset
getAIBExpandedNode
setAIBExpandedNode
getAIBConferenceID
setAIBConferenceID
UBYTE aLinkID)
UBYTE aLinkID)
void sk_setAIBObjectInstanceID(
UBYTE *AIBBlock, XBYTE
anObjectInstanceID)
void skts_setAIBObjectInstanceID(
UBYTE *AIBBlock, XBYTE
anObjectInstanceID)
XBYTE
sk_getAIBObjectInstanceID(const
UBYTE *AIBBlock)
XBYTE sk_getAIBObjectType(
const UBYTE *AIBBlock )
XBYTE
skts_getAIBObjectInstanceID(const
UBYTE *AIBBlock)
XBYTE skts_getAIBObjectType(
const UBYTE *AIBBlock )
void sk_setAIBObjectType(
UBYTE *AIBBlock,
void skts_setAIBObjectType(
UBYTE *AIBBlock,
UBYTE sk_getAIBModule( const
UBYTE *AIBBlock )
UBYTE skts_getAIBModule( const
UBYTE *AIBBlock )
XBYTE anObjectType)
XBYTE anObjectType)
void sk_setAIBModule( UBYTE
*AIBBlock,
void skts_setAIBModule( UBYTE
*AIBBlock,
UBYTE sk_getAIBAssignSpanSlot(
const UBYTE *AIBBlock )
UBYTE skts_getAIBAssignSpanSlot(
const UBYTE *AIBBlock )
UBYTE aModule)
UBYTE aModule)
void
sk_setAIBAssignSpanSlot(UBYTE
*AIBBlock, UBYTE
anAssignSpanSlot )
void
skts_setAIBAssignSpanSlot(UBYTE
*AIBBlock, UBYTE
anAssignSpanSlot )
void sk_setAIBAssignSpanOffset(
UBYTE *AIBBlock, UBYTE
anAssignSpanOffset)
void skts_setAIBAssignSpanOffset(
UBYTE *AIBBlock, UBYTE
anAssignSpanOffset)
UBYTE
sk_getAIBAssignSpanOffset(
const UBYTE *AIBBlock )
XBYTE sk_getAIBExpandedNode(
const UBYTE *AIBBlock )
void sk_setAIBExpandedNode(
UBYTE *AIBBlock,
XBYTE anExpandedNode)
XBYTE sk_getAIBConferenceID(
const UBYTE *AIBBlock )
void sk_setAIBConferenceID(
UBYTE *AIBBlock,
XBYTE aConferenceID)
UBYTE
skts_getAIBAssignSpanOffset(
const UBYTE *AIBBlock )
XBYTE skts_getAIBExpandedNode(
const UBYTE *AIBBlock )
void skts_setAIBExpandedNode(
UBYTE *AIBBlock,
XBYTE anExpandedNode)
XBYTE skts_getAIBConferenceID(
const UBYTE *AIBBlock )
void skts_setAIBConferenceID(
UBYTE *AIBBlock, XBYTE
aConferenceID)
289
MSP
Connection Management Functions
Applications Connecting to Multiple LLCs
This model is for an SwitchKit environment with multiple LLCs. Use this model if you
are writing a new application that must connect to multipe LLCs.
In this model, your application specifies the connection information in the create
connection function call and assigns a connection ID and an application name to that
connection. From then on, all references to the connection are made using the
connection ID. This eliminates any ambiguity about the LLC connection. The
connection ID is returned with each event, which makes it simple to determine which
LLC should receive subsequent action.
Functions in this Model
The following is a list of functions that are to be used in this model:
SK_Connection *sk_createConnectionWithID();
sk_*OnConnection();
int sk_closeNamedConnection();
int sk_getLLCSocketDescriptorForConnection();
int sk_getConnectionNameForConnection();
int sk_getConnectionForID;
int sk_destroyConnectionForced();
int sk_appDescriptionData();
SK_Connection*
SK_Connection is an opaque object which is returned by several
sk_createConnection*() functions that can be used to refer to a specific connection in
other SwitchKit connection management functions such as,
sk_getSpecificConnectionName().
How to use the Connection Model with ID
To connect to multiple LLCs and to manage those connections, your application must
call SK_Connection *sk_createConnectionWithID(). With that function call, an integer
connection ID is assigned to the connection between the application and that
particular LLC.
When the connection ID is assigned, your application must call one of the
sk_*OnConnection() functions to interact with a particular LLC. The
sk_*OnConnection() function takes the assigned connection ID as a parameter.
Applications Connecting to One LLC
290
SwitchKit Programmer's Information
If you are working in an environment with only one LLC and if you are not going to
change to an environment with multiple LLCs, you can use this model.
Functions in this Model
int sk_initializeConnection();
int sk_initializeForcedConnection();
int sk_closeConnection();
int sk_getLLCSocketDescriptor();
int sk_getConnectionName();
How to use the Simplified Connection Model
To connect to just one LLC in the system, your application can call
sk_initializeConnection() or sk_initializeForcedConnection(). These function calls
initialize a socket to the LLC with a number named connectionName.
Calling these functions does not open the socket. The socket must be opened by
sending a message with the specific connectionName to the LLC.
How sk_initializeConnection() works
If your application calls sk_initializeConnection(), any previous connection to the LLC
is terminated, and a new one is initialized with the specified connection name.
If a requested connection name is already in use, the first available integer greater
than connectionName is assigned automatically to the application. To ensure that
your application receives an unused connection name, call the function with an
argument of -1.
How sk_initializeForcedConnection() works
The function sk_initializeForcedConnection() behaves exactly as
sk_intializeConnection() does, except when connectionName is already in use by
another application to the LLC. Instead of receiving a new, unused connection name,
your application insisting on the specified name causes the first connection to
terminate.
Connecting Legacy Applications to Multiple LLCs
Do not use this model if you intend to write a new application. This model is only to
be used by existing appliactions, written to run on SwitchKit versions before 5.7.
Functions in this category rely heavily on the SK_Connection pointer to determine or
provide information and context. SK_Connection is returned when the connection to
the LLC is first established. If your application must make a request to the LLC or
291
MSP
needs to receive a message, if would first have to send function calls to get or set
the current connection to the specific SK_Connection pointer.
How to use the Connection Model without ID
To connect to multiple LLCs and to manage those connections, your application must
call SK_Connection *sk_createConnection(). Every call creates a separate
SK_Connection pointer for each connection. To send a message to a specific LLC,
your application must call the function sk_setCurrentConnection() with the
SK_Connection pointer at the desired LLC. Without that function call and specifying
pointer, there is no way to direct a message to an LLC other than the one for which
SwitchKit is processing the current message.
Functions in this Model
SK_Connection *sk_createConnection();
int sk_getLLCSocketDescriptor();
int sk_getSpecificConnectionName();
const char *sk_getSpecificConnectionLabel();
SK_Connection *sk_getCurrentConnection();
void sk_setCurrentConnection();
int sk_destroyConnection();
int sk_appDescriptionData();
Introduction to Connection Management
In a SwitchKit environment, an application communicates with one or multiple LLCs.
SwitchKit provides a set of functions that help you create and manage connections
between your application module and any LLC your application needs to
communicate with.
There are three models of connecting applications to the LLC:



Applications Connecting to Multiple LLCs. Use this model if you are writing a
new application that connects to multiple LLCs. In this context, a redundant
pair of LLCs is considered a single LLC.
Connecting Legacy Applications to Multiple LLCs. This model is for legacy
applications (before SwitchKit version 5.7) connecting to multiple LLCs. Do
not use this model if you are writing a new application.
Applications Connecting to One LLC. Use this model if you are writing a new
application that connects to one LLC, or if you have an existing application
connecting to one LLC. In this context, a redundant pair of LLCs is considered
a single LLC.
Consider your system’s current and future needs when deciding to use the functions
offered either under Applications Connecting to Multiple LLCs, or under Applications
Connecting to One LLC, for your new application development.
List of SwitchKit Connection Management APIs
The API messaged listed below are used in connection models. These API messages
are found in the web-based API Reference.
292
SwitchKit Programmer's Information
AppConnectionQuery
AppPopulationQuery
Connect 0x0000
Card Population Query 0x0007
sk_appDescriptionData()
To provide additional information uniquely identifying your application, use the
sk_appDescriptionData() function. This function should be called after your
application has established a connection to the LLC. This function is also available as
skts_appDescriptionData().
Syntax
void sk_appDescriptionData(char *anAppName,char *aShortName, char
*anAppVersion, char *aUserData)
void skts_appDescriptionData(char *anAppName,char *aShortName, char
*anAppVersion, char *aUserData);
Parameters
These are the function parameters.
Arguments
Description
aShortName
This is used to name the maintenance.log log file. It is not
passed to the LLC.
anAppName
AnAppVersion
aUserData
This is meant to be a descriptive name for the application.
This string should describe the version of the application
software.
This is stored by the SwitchKit API, but it is used only by the
application.
APIs used in all Connection Models
sk_closeConnection()
The function closes the current connection between the application and the LLC.
Syntax
int sk_closeConnection();
How closeConnection works
The LLC no longer has a socket open to this application. However, the
ConnectionManager object remains and causes the connection to re-establish in case
of subsequent calls to sk_rcvAndDispatch() or attempts to send a message.
293
MSP
sk_closeNamedConnection()
This function closes the connection with the specified connection ID between the
application and the LLC.
Syntax
int sk_closeNamedConnection( int aConID);
How sk_closeNamedConnection() works
The LLC no longer has a socket open to this application. However, the
ConnectionManager object remains and causes the connection to re-establish in case
of subsequent calls to sk_rcvAndDispatch() or attempts to send a message.
*sk_createConnection()
Use the SK_Connection *sk_createConnection() function to create a connection
between your application module and a specific LLC.
Syntax
SK_Connection *sk_createConnection(int aConID, const char *aLabel, int anAppID, int
isForcedFlag, const char *aPriHost, int aPriPort, const char *aBackupHost, int
aBackupPort);
SK_Connection *skts_createConnection(int aConID, const char *aLabel, int anAppID, int
isForcedFlag, const char *aPriHost, int aPriPort, const char *aBackupHost, int
aBackupPort);
int skts_createConnection( int aConID, );
Parameters
The function parameters are shown in the next table.
Arguments
Description
aLabel
aLabel is is a text string used by the application to identify the
connection. The value has no meaning to the SwitchKit API and is
available for query via sk_getSpecificConnectionLabel() and
skts_getSpecificConnectionLabel().
aConID
anAppID
294
aConID is a connection identifier specified by the application and
used to refer to an application’s connection to a specific LLC. The
connection identifier is used by the SwitchKit API to route
messages from the application to a specific LLC. The connection
identifier is initially defined for the API when the application calls
sk_createConnectionWithID() or skts_createConnection() and
should be used for any sk_*OnConnection() and skts_*()
functions where required.
anAppID is the application identifier used by the LLC to route
messages to the application and to log any events of interest
regarding the application. If the caller of the function does not
SwitchKit Programmer's Information
isForcedFlag
aPriHost
aPriPort
aBackupHost
aBackup
care which application identifier it receives, it can specify -1. This
allows LLC to select the next available application identifier
beginning at 10. If the specified application identifier is already
used, the LLC will assign the next available identifier beginning at
the requested identifier, unless the isForcedFlag is set to 1 or
sk_initializeConnectionForced() was used to establish the
connection with LLC.
If isForcedFlag equals 1, then the application identifier for this
application will be set to the value specified in anAppID even if
that application identifier is being used by another application.
The IP address of the primary LLC with the following format, for
example: "10.10.55.10"
The IP port number the primary LLC the primary LLC is listening
to.
The IP address of the secondary LLC, in the following format, for
example: "10.10.55.10". If there is no secondary LLC, this field
should be set to "". That is, the 0-length string.
Port The IP port for the secondary LLC is listening to.
Return Values
This is one of the functions that returns an integer value instead of a pointer. A NULL
pointer indicates an error condition.
Useful Related Functions
int sk_getLLCSocketDescriptor();
int sk_getSpecificConnectionName();
const char *sk_getSpecificConnectionLabel();
SK_Connection *sk_getCurrentConnection();
void sk_setCurrentConnection();
int sk_destroyConnection();
int sk_appDescriptionData();
sk_createConnectionWithID()
Use the sk_createConnectionWithID() function to create a connection between
your application module and a specific LLC.
Syntax
SK_Connection *sk_createConnectionWithID(int aConid, const char *aLabel, int anAppID,
int isForcedFlag, const char *aPriHost, int aPriPort, const char *aBackupHost, int
aBackupPort);
Parameters
295
MSP
The function parameters are shown in the table below.
Argument
Description
aLabel
aLabel is is a text string used by the application to identify
theconnection. The value has no meaning to the SwitchKit API
and is available for query via sk_getSpecificConnectionLabel()
and skts_getSpecificConnectionLabel().
aConID
anAppID
isForcedFlag
aPriHost:
aPriPort:
aBackupHost:
aBackup
aConID is a connection identifier specified by the application and
used to refer to an applications connection to a specific LLC. The
connection identifier is used by the SwitchKit API to route
messages from the application to a specific LLC. The connection
identifier is initially defined for the API when the application calls
sk_createConnectionWithID() or skts_createConnection() and
should be used for any sk_*OnConnection() and skts_*()
functions where required.
anAppID is the application identifier used by the LLC to route
messages to the application and to log any events of interest
regarding the application. If the caller of the function does not
care which application identifier it receives, it can specify -1. This
allows LLC to select the next available application identifier
beginning at 10. If the specified application identifier is already
used, the LLC will assign the next available identifier beginning at
the requested identifier, unless the isForcedFlag is set to 1 or
sk_initializeConnectionForced() was used to establish the
connection with LLC.
If isForcedFlag equals 1, then the application identifier for this
application will be set to the value specified in anAppID even if
that application identifier is being used by another application.
The IP address of the primary LLC with the following format, for
example:
"10.10.55.10"
The IP port number the primary LLC the primary LLC is listening
to.
The IP address of the secondary LLC, in the following format, for
example: "10.10.55.10". If there is no secondary LLC, this field
should be set to "". That is, the 0-length string.
Port The IP port for the secondary LLC is listening to.
Return Values
This is one of the functions that returns an integer value pointer of an integer. A
NULL pointer indicates an error condition.
Useful Related Functions
sk_*OnConnection();
296
SwitchKit Programmer's Information
int sk_closeNamedConnection();
int sk_getLLCSocketDescriptorForConnection();
int sk_getConnectionNameForConnection();
int sk_getConnectionForID;
int sk_destroyConnectionForced();
int sk_appDescriptionData();
sk_destroyConnection()
Your application should use the function sk_destroyConnection() to destroy a
connection to the LLC. You cannot use this function on your current connection.
Therefore, this function can destroy all connections between applications and the
LLC, except the last connection left. This function call frees up all the memory
allocated in sk_createConnection().
Syntax
int sk_destroyConnection(SK_Connection *aConnection);
Threadsafe Syntax
int skts_destroyConnection( int aConID );
Return Values
SK_CONNECT_IN_USE This return value indicates that you called the function on the
current connection.
sk_destroyConnectionForced()
Your application should use the function sk_destroyConnectionForced() to destroy a
connection to the LLC with the specified connection ID. If the specified connection is
the last connection opened, it will be destroyed but cause a return value
SK_NO_CONNECT_AVAIL. As the name implies, this return indicates that no
connections remain. However, should your application call sk_rcvAndDispatch(), the
system attempts to establish a connection to an LLC using the default connection
arguments specified in the SK_LLC_Host/Port environment variables, or at local
host:1312.
This function call frees up all the memory allocated in sk_createConnectionWithID().
Syntax
int sk_destroyConnectionForced(int aConID);
Threadsafe Syntax
int skts_destroyConnectionForced(int aConID);
Return Values
297
MSP
SK_NO_CONNECT_AVAIL
This return indicates that all connections have been destroyed.
sk_getConnectionForID()
The function call sk_getConnectionForID() retrieves the SK_Connection object for the
specified connection ID.
Syntax
SK_Connection *sk_getConnectionForID(int aConID);
sk_getConnectionName()
The function call sk_getConnectionName() retrieves the name registered to the
applications current connection between the application and the LLC.
Syntax
int sk_getConnectionName();
How getConnectionName works
You can call this function only after opening a socket to the LLC. To open the socket,
you should send a harmless message through that connection.
sk_getConnectionNameForConnection()
The function call sk_getConnectionNameForConnection() uses the connection ID to
retrieve the connection name of the connection between the applications and the
LLC.
Syntax
int sk_getConnectionNameForConnection( int aConID);
How getConnectionName works
You can call this function only after opening a socket to the LLC. To open the socket,
send a harmless message through that connection.
sk_getCurrentConnection()
If your application is connected to more than one LLC, the LLC receiving a message
or function call makes that connection current. Unless otherwise specified, the LLC
communicates with your application through that current connection.
The function SK_Connection *sk_getCurrentConnection() enables another process of
your application to get the current connection.
Syntax
int SK_Connection *sk_getCurrentConnection();
sk_getLLCSocketDescriptor()
298
SwitchKit Programmer's Information
The function sk_getLLCSocketDescriptor() returns the socket descriptor associated
with the current application. You need this function if your application is connected to
the LLC, to a database, or to another server.
Syntax
int sk_getLLCSocketDescriptor();
How getLLCSocketDescriptor works
By calling sk_getLLCSocketDescriptor(), your application retrieves the socket
descriptor from the LLC, which enables your application to issue an OS-specific call,
for example select(). This indicates when there is activity on the LLC socket and only
then calls the function sk_rcvAndDispatch().
The sk_getLLCSocketDescriptor() function should be called each time select() is
called, because the socket descriptor can change without the knowledge of the
application.
For example, if the PLLC fails and the RLLC becomes active, the socket of the PLLC
will no longer be valid. A subsequent call to the function provides the socket
descriptor for the now active RLLC.
sk_getLLCSocketDescriptorForConnection()
The function sk_getLLCSocketDescriptorForConnection() returns the socket
descriptor associated with the current application. You need this function if your
application is connected to the LLC, to a database, or to another server.
Syntax
int sk_getLLCSocketDescriptorForConnection( int aConID);
Threadsafe Syntax
int skts_getLLCSocketDescriptor(int aConID);
How getLLCSocketDescriptor works
By calling sk_getLLCSocketDescriptorForConnection() your application retrieves the
socket descriptor associated with the specified connection ID from the LLC. This
enables your application to issue an OS-specific call, for example select(). This
indicates when there is activity on the LLC socket and then the application must call
the function sk_rcvAndDispatch() to begin processing of all messages on the LLC
socket.
The sk_getLLCSocketDescriptorForConnection() function should be called each time
select() is called, because the socket descriptor can change without the application
being aware of it.
For example, if the PLLC fails and the RLLC becomes active, the socket of the PLLC
will no longer be valid. A subsequent call to the function provides the socket
descriptor for the now active RLLC.
299
MSP
sk_getSpecificConnectionLabel()
The function sk_getSpecificConnectionLable() returns the label associated with a
connection that was created with sk_createConnection().
Syntax
int sk_getSpecificConnectionLabel(SK_Connection *aConnection);
sk_getSpecificConnectionName()
With the function sk_getSpecificConnectionName() your application can retrieve the
numeric name of that connection. This function does not change the current
connection.
Syntax
int sk_getSpecificConnectionName(SK_Connection *aConnection);
sk_initializeConnection() / sk_initializeForcedConnection()
Description
Use a function call to sk_initializeConnection() or sk_initializedForcedConnection()
function to establish a socket between your application and the LLC. The connection
will be established with the IP and port numbers specified in the environment
variables SK_LLC_HOST/PORT and SK_RLLC_HOST/PORT.
Syntax
int sk_initializeConnection(int anAppID);
int sk_initializeForcedConnection(int anAppID);
Parameters
The function parameters are shown in the table below.
Arguments
anAppID
Return Values
300
Description
anAppID is the application identifier used by the LLC to route
messages to the application and to log any events of interest
regarding the application. If the caller of the function does not care
which application identifier it receives, it can specify -1. This allows
LLC to select the next available application identifier beginning at
10. If the specified application identifier is already used, the LLC
will assign the next available identifier beginning at the requested
identifier, unless the isForcedFlag is set to 1 or
sk_initializeConnectionForced() was used to establish the
connection with LLC.
SwitchKit Programmer's Information
Possible return values for this function:
SK_CONNECT_IN_USE This return value indicates that the specified connection name
is already in use and that the connection opened with another name, which can be
requested with the function call sk_getConnectionName.
Useful Related Functions
int sk_getConnectionName();
int sk_closeConnection();
int sk_getLLCSocketDescriptor();
sk_*OnConnection()
Functions using OnConnection
Some SwitchKit functions are duplicated as "OnConnection" functions. For example,
sk_watchChannelGroup() is also available as sk_watchChannelGroupOnConnection().
The difference with the sk_*OnConnection() functions is the integer connection
parameter:
int aConID
However, if sk_createConnectionWithID() was used to establish a connection
between the LLC and the application, the functions with OnConnection must be used
to create interaction between the LLC and the application. The following is a list of
functions used that have with .
On Connection Functions
Register Functions
For more information on these functions, see Register Functions.
sk_appGroupRegisterOnConnection
sk_msgRegisterOnConnection
sk_msgUnRegisterOnConnection
sk_pplComponentRegisterOnConnection
sk_pplComponentUnRegisterOnConnection
sk_pplTCAPRegisterOnConnection
sk_pplTCAPUnRegisterOnConnection
Logging Functions
For more information on these functions, see Logging Functions.
sk_logLevelOnConnection
sk_logMessageOnConnection
301
MSP
Message Functions
For more information on these functions, see Message Functions.
sk_rcvAndDispatchOnConnection
sk_rcvAndDispatchAutoStorageOnConnection
sk_rcvMessageOnConnection
sk_sendMessageOnConnection
sk_sendMessageWithHandlerOnConnection
sk_sendMessageWithTagOnConnection
sk_sendMsgStructOnConnection
Redundancy Functions
For more information on these functions, see Redundancy.
sk_activateExnetMatrixOnConnection
sk_deregisterAsRedundantAppOnConnection
sk_registerAsRedundantAppOnConnection
Additional Functions to Connect to Multiple LLCs
sk_setCurrentConnection()
Your application should issue the function call sk_setCurrentConnection() to make
that connection current. Any future communication goes through that connection
Syntax
int sk_setCurrentConnection(SK_connection *aConnection);
Channel Management
Channel Management
Channel management functions are available in SwitchKit. Prototype information,
possible error return values, and a description of what each function does is
provided.
302
SwitchKit Programmer's Information
Most functions return an integer value. Upon successful completion, that return value
is OK (0). Non-zero return values indicate some error conditions. Each function lists
the associated error conditions.
Some functions return pointers; those functions do not have a status value indicating
success or failure.
Your application modules will notify the LLC of which channels to use, using the
Channel Management functions. Most of these functions are based on channel
groups. A channel group is a text string that is associated with a set of channels. The
association between the group name and channels is specified in the configuration.
Inbound and outbound channel groups are managed differently.
Functions Used for Channel Management
sk_associateChannelGroup()
sk_broadcastLoad()
sk_clearChannelGroup()
sk_configChannelGroup()
sk_getAssignedChannelGroup()
sk_ignoreChannelGroup()
sk_monitorChannel() / sk_unMonitorChannel()
sk_removeChannelsFromGroup()
sk_requestChannel()
sk_requestOutseizedChannel()
sk_requestRouteControlledChannel()
sk_returnChannel()
sk_setChannelData() / sk_getChannelData()
sk_setChannelHandler()
sk_setGroupHandler()
sk_watchChannelGroup()
API messages used for Channel Management
The API messages listed below are used for channel management. The API messages
are found in the API Reference .
AllocateChannel
AllocateChannelGroup
BroadcastLoad
ChannelGroupContentsQuery
ChannelGroupPopulationQuery
303
MSP
ClearChanGroup
ClearAllChanGroups
ConfigChanGroup
IgnoreChanGroup
Remove Channels From Group
TransferChanMsg
WatchChanGroup
Channels
Inbound Channels
In order to receive inbound calls, your application must notify the LLC that it is
willing to handle messages that arrive on inbound channels. You do not need to send
messages to those channels until the application is notified of an inbound call. When
a call arrives on an inbound channel, the LLC can route it to any application willing to
handle that channel.
Thereafter, the application is able to send messages to that channel and to receive
all messages concerning that channel. Through the sk_watchChannelGroup()
function, the application notifies the LLC that it is willing to handle a channel group.
If multiple applications watch the same channel group, load sharing occurs.
For example, if you create a channel group “All_Inbound” in your configuration file to
receive incoming calls, your application must issue the following function call:
sk_watchChannelGroup(“All_Inbound”);
This function call tells the LLC that any calls on the channels associated with the
group “All_Inbound” can be routed to your application.
The messages that are sent to your application include information about the channel
they arrive on. Your application does not need to keep track of specific channels in
the group it is watching. However, it is possible for the application to obtain specific
information about the channels through other API messages.
Outbound Channels
Unlike inbound channels, your application must initiate the communication with
outbound channels, rather than waiting for a message to arrive. Therefore, to obtain
access to an outbound channel, your application must explicitly request a channel
from an outbound channel group, which is usually done simultaneously with an
outseizure. To do this use sk_requestOutseizedChannel().
Syntax for sk_requestOutseizedChannel()
int sk_requestOutseizedChannel (char *aChannelGroup, int aNumRetries,
XL_OutseizeControl *anOutseizeMsg, void *aTag, HandlerFunc *aHandlerFunc);
Intelligent Channel Allocation
When your application requests a channel from a channel group, the LLC determines
which channel to allocate, based on an intelligent channel allocation algorithm. The
304
SwitchKit Programmer's Information
allocation is based on which subgroup of the requested channel group is most
available.
If the switch has outbound trunks to multiple inter-exchange carriers, you can define
one overall outbound channel group, called “outbound” that incorporates all
outbound trunks. You can then define specific groups to Carrier A and Carrier B,
called “outboundA” and “outboundB.” The “outboundA” and “outboundB” groups are
subgroups of the “outbound” group.
If an application requests an outseize on a port to a specific carrier, LLC finds an
unused channel in the subgroup for that specific carrier that it can successfully
outseize on, and provides the outseized channel to the application module.
However, if an application does not care which specific carrier it is outseized to, and
requests a channel from group “outbound,” the LLC determines which of
“outboundA” or “outboundB” is less loaded, and returns a successfully outseized
channel from that subgroup. The LLC always attempts to preserve the most limited
channel group for the applications that require it.
Channels can only be managed by either the CSP or SwitchKit. Do not attempt
to use LLC channel management when using CSP routing.
Application Disconnection Functionality
When an application terminates, you can specify how the LLC handles the non-idle
channels using the environment variable: SK_CHANNEL_RECOVERY_METHOD. If this
variable is set to 0x01, channels will be released. If this variable is set to 0x02,
channels will be taken out-of-service. If this variable is set to 0x00, no action is
taken. If this variable is set to 0x03, all channels will be taken out-of-service within a
group.
Channel Groups
In channel management, if an application specifies a channel group that was not
configured in LLC using an AssociateChannelGroup API message, the LLC will create
that group and assign no channels to the channel group. When
AssociateChannelGroup is sent to the LLC, LLC will add the specified channels to that
group. You can also configure a channel group using ClientView, see Application
Routing Group.
If LLC receives a reference to a channel group that does not currently exist, it will
make note of that fact in the maintenance.llc.log file. LLC also sets up this invalid
channel group with a group name and zero channels. If an AssociateChannelGroup is
sent later, that invalid channel group will get populated.
Device Connectivity Functions
Add LLC Node Feature
A node is connected to the Low-Level Controller (LLC) through a TCP/IP socket. That
socket is opened by the LLC when the node is connected.
For the LLC to connect to a node, SwitchManager needs an AddLLCNode message in
the configuration file. The message includes a logical node ID and either one or two
IP addresses, depending on the setup.
305
MSP
The IP address(es) for the node are the addresses of the primary Matrix Controller
and, if applicable, the secondary Matrix Controller.
Functionality
To connect a node, you must do the following:
Start LLC without specifying any nodes on the command line. (The -i option is not
valid anymore.)
Start SwitchManager with a configuration file that specifies the nodes the LLC will
connect to.
With the introduction of the SK_AddLLCNode message, the IP addresses in the
Config Switch window are obsolete. Also, Node ID 0xff (255) is no longer allowed.
Each Node must be assigned a number even if in a single node configuration.
When the LLC is requested to connect to a node via the AddLLCNode() command,
LLC will maintain that connection until told to disconnect. If the specified IP address
is not reachable, LLC will continue attempting the connection forever. This condition
will be logged in the LLC maintenance log file.
Example
The following is an example of how to set up the message in the configuration file:
AddLLCNode(matrix1="10.10.55.10", matrix2="10.10.55.11",
RequestedNode=0x08);
Return Values
The Status field in the acknowledgment can contain the following values:
If the return value is then...
SK_SUCCESS (0x10) node was added successfully.
SK_DUP_IP_ADDR (-29) one or both IP addresses are already in use by the LLC for
another logical node ID.
SK_INTERNAL_LIMIT_REACHED (-30) no more nodes can be added to the LLC.
Current limit is 128 nodes.
SK_BAD_IP_ADDRESS (-27) no response from that IP address was received after 15
seconds.
SK_BAD_LICENSE (-28) no valid license exists for the new node.
SK_INTERNAL_ERROR (-21) an unexpected error occurred. Refer to the LLC
maintenance.log for more details.
SK_NODE_DOESNT_EXIST (-35) a delete command was sent for a nonexisting node.
AddLLCNode
Use SK_AddLLCNode at the initial configuration of your system and to dynamically
add a node while LLC is running.
Description
306
SwitchKit Programmer's Information
The node must already have software downloaded through TFTP. Sending
SK_AddLLCNode for a node that needs software will fail.
If you are using the floating IP address functionality for the Matrix Controller cards,
you should use the fixed IP addresses for the Matrix Controller cards in the
AddLLCNode() message. If you don't, the LLC will inaccurately reflect the state of the
switch.
Sent by
SwitchManager
Type
SwitchKit API message
Add the Node
To add a node, you must send a configuration file with SwitchManager. The
configuration file should contain at least the following information:
AddLLCNode (matrix1=”10.10.55.10”, matrix2=”10.10.55.11”,
RequestedNode=0x08);
If you are adding a node with a single Matrix Controller and you use the Matrix2
argument in your message, be sure to enter the 0-length string as its value.
Arguments
The following table shows the arguments you can change:
Argument
Description
Matrix1
A text field corresponding to the IP address of the primary
Matrix Controller.
Action
Matrix2
NodeType
RequestedNode
Specifies if a node gets added (0 = default), updated (1), or
deleted (2).
A text field corresponding to the IP address of the secondary
Matrix Controller, if it exists. If there is only one Matrix
Controller in the node, this field must be set to “”, that is, the
0-length string.
Needs to be specified only for ISDN and H.323 device server
nodes. In those cases, NodeType should be:
SK_LSS_DS_SYSTEM or 0x10. Otherwise, it will default to the
appropriate NodeType.
RequestedNode is the logical node ID requested to be assigned
to the new node. The API will attempt to assign this node:
If there is no node ID currently on the node;
If it is currently assigned a different node ID.
307
MSP
It is not a guarantee that this node will be assigned. In particular, the node ID might
already be in use on the ring. If so, AddLLCNode will fail, and no connection will be
established with the node. If the LLC is already connected to a node with the
specified logical node ID, the AddLLCNode is considered an update, if treated
accordingly.
Configuration
AddLLCNode (
Node = integer,
ConnectionID = integer,
Matrix1 = string,
Matrix2 = string,
RequestedNode = integer,
Action = integer);
C Structure
typedef struct {
char Matrix1[30];
char Matrix2[30];
int RequestedNode;
//int PhysicalNode; reserved for internal use only
//unsigned short NodeType; reserved
//unsigned short CallControlNode; reserved
UBYTE Action;
} SK_AddLLCNode;
C Structure Response
typedef struct {
int Status;
int ActualNode;
UBYTE DownloadStatus;
} SK_AddLLCNodeAck;
C++ Class
class SKC_AddLLCNode : public SKC_ToolkitMessage {
public:
const char *getMatrix1() const;
308
SwitchKit Programmer's Information
void setMatrix1(const char *x);
const char *getMatrix2() const;
void setMatrix2(const char *x);
int getRequestedNode() const;
void setRequestedNode(int x);
//int getPhysicalNode() const; reserved
//void setPhysicalNode(int x); reserved
//unsigned short getNodeType() const; reserved
//void setNodeType(unsigned short x); reserved
//unsigned short getCallControlNode() const; res.
//void setCallControlNode(unsigned short x); res.
UBYTE getAction() const;
void setAction(UBYTE x);
};
C++ Class Response
class SKC_AddLLCNodeAck : public SKC_ToolkitAck {
public:
int getStatus() const;
void setStatus(int x);
int getActualNode() const;
void setActualNode(int x);
UBYTE getDownloadStatus() const;
void setDownloadStatus(UBYTE x);
};
LLC: Application Load Balancing for TCAP
This feature facilitates routing between the LLC and applications, based on the
number of Inbound Initial dialog Primitives (IDP) each registered SwitchKit
application has. The LLC is capable of performing the following:

Monitoring dialog states

Routing TCAP-related PPLEventIndication messages to the registered
application with the lowest number of active dialogues

Providing a registration mechanism for SwitchKit applications to receive TCAPrelated PPLEventIndication messages based on a combination of stack and
Sub System Number (SSN).
How to Keep Track of dialog States
309
MSP
Once dialog monitoring has been enabled, the LLC automatically keeps track of
dialog states. Each state can be derived from any one of the multiple TCAP primitives
listed in the next table. TCAP Primitives are extracted from TCAP-related PPLEvent
messages received by the LLC.
The following terms represent the three possible states the LLC can derive within its
dialog management sytem for a given dialog ID:

NOT_ALLOCATED - dialog ID is not allocated.

ALLOCATED_B_SIDE - dialog ID has been allocated by the MSP 1010 using a
PPLEventIndication message. The next table shows the type of primitive for
each LLC state. Primitives are both requests and indications, unless shown
otherwise.

ALLOCATED_A_SIDE - dialog ID has been allocated by an application using a
PPLEventRequest message.
Important! The next table contains the following notation.
** If a TCAP_RESTART Event is received, all Dialogues on that stack should end
(enter the NOT_ALLOCATED state).
*** Detection of a dialog Termination TLV always results in the LLC putting that
dialog into the NOT_ALLOCATED state. The LLC does not check these events for the
dialog termination TLVs.
Event Criteria (TCAP Primitives)
APP
Initiated
Network
Initiated
TC-BEGIN
X
X
TC_QUERY_WITHOUT_PERMISSION
X
A Side
TC_QUERY_WITH_PERMISSION
TC_BEGIN_PRIMITIVE_SET
TC_QUERY_WITH_PERMISSION_PRIMITIVE_SET
TC_QUERY_WITHOUT_PERMISSION_PRIMITIVE_SET
TC_END
TC_RESPONSE
TC_RESULT_L
TC_RESULT_NL
TC_U_ERROR
TC_L_CANCEL
TC_INVOKE_L
TC_INVOKE_NL
TC_U_REJECT
310
X
X
X
X
B Side
Event
Receive
dialog
B Side
Event
X
Allocate
X
Allocate
X
Allocate
X
X
X
X
X
X
X
X
X
X
X
Allocate
Allocate
X
X
LLC
Action
X
X
X
X
X
X
X
Allocate
Deallocate
Deallocate
Deallocate
Deallocate
Deallocate
Deallocate
Deallocate
Deallocate
Deallocate
SwitchKit Programmer's Information
TC_L_REJECT
X
X
Deallocate
TC_INVOKE
X
X
Deallocate
TC_R_REJECT
X
TC_RESPONSE
X
TCAP_RESTART**
X
TC_END
TC_RESPONSE_PRIMITIVE_SET***
X
TC_END_PRIMITIVE_SET***
X
TC_NOTICE***
X
TC_TCAP_INITIATED_ABORT***
TC_U_ABORT***
Deallocate
Deallocate
Deallocate
Deallocate
Deallocate
X
X
Deallocate
Deallocate
X
TC_P_ABORT***
TC_DIALOGUE_TIMEOUT***
X
Deallocate
Deallocate
X
Deallocate
X
Deallocate
As TCAP-related PPL events are passed in and out of the LLC, a dialog monitor
parses each PPL event and derives the current state of each dialog using the state
machine outlined in the next figure.
Diagram of Transitional States
In Figure Finite State Machine Used by the LLC’s dialog Monitoring System, each
number represents a group of transitional events (TCAP primitives) that result in a
particular finite state (dialog State). The events (TCAP Primitives) represented by
each number are listed in the table and correspond to the transition arrows in the
state diagram
Finite State Machine Used by the LLC’s dialog Monitoring System
.
dialog state and application data are then stored for maximum retrieval efficiency
using a series of C++ STL containers. Application statistics can then be queried to
provide load balancing information such as the number of active dialogues given an
application number, or the number of active dialogues given a RoutingID. These
311
MSP
statistics are then used by the LLC to determine Best Response Transaction
Allocation.
How the LLC Determines Best Response Transaction Allocation
When a PPL event indication with component ID 0x70 (TCAP TUSI) is received by the
LLC, it determines whether or not this message is an Initial dialog Primitive (IDP). If
this is an IDP, then the stack, SSN, and dialog are extracted from the message and
are queried to determine which registered application has the least number of active
dialogues. If the numbers are equal, a random application number is chosen.
Otherwise, the application number with the lowest number of active dialogues is
chosen and the PPL event indication is sent to that application. If the dialog was
activated by the A side (activated by a PPL event request) then the remaining
dialogues are sent to the application that activated it.
Limitations/Assumptions/Dependencies
The LLC must be configured for TCAP Routing. In addition to this configuration, to
enable TCAP Application Load Balancing you must do the following:
//set the following environment variable to activate the
//LLC's dialog Monitor
SK_DIALOGUE_MONITOR=1
//call this SK function from your app
sk_pplTCAPRegister(int what, UBYTE registerType);
//derive the function parameters from the following macros and constants
int what = getSS7TCAP_MultiCard_RoutingID(stackID, ssn);
UBYTE registerType = SK_TCAP_REG_STACK_SSN = 0x02;
SS7 SCCP/TCAP Configure 0x0077
SwitchKit Name
SS7SCCPTCAPConfig
Type
EXS API and SwitchKit API message
Description
This message is sent to configure options for SS7 SCCP/TCAP.
For SwitchKit
Those options include:

312
Local SSN
SwitchKit Programmer's Information

Adjacent Translator

SCCP Default Parameter Table




Other Concerned Point Code
SSN Default Parameter Table
Network DPC/SSN
SCCP/TCAP host configuration
In a SwitchKit environment, this message must be sent by an application or by
SwitchManager with ConfigType = 1, Data = [2:1] specifying “SCCP route message
to TCAP”. Without sending this message first and receiving a positive
acknowledgment it is impossible to add or specify a node as a TCAP node.
Sent by
Host (SwitchManager for SwitchKit)
Overview of message
The following table provides an overview of this message. The table following it
provides the detail for each byte.
MESSAGE (White)
RESPONSE (Gray)
0
0
Byte
Field Description
1, 2
Length (0xNNNN)
3, 4
5
6
7
8
Frame (0xFE)
Message Type (0x0077)
Reserved (0x00)
Sequence Number
Logical Node ID
AIB
Address Method
Number of AEs to follow
9
10
11
:
:
:
AEs
Byte
Field Description
1, 2
Length (0x0007)
3, 4
5
6
7
8, 9
10
Frame (0xFE)
Message Type (0x0077)
Reserved (0x00)
Same Sequence Number
Logical Node ID
Status MSB, LSB
Checksum
Config Type
Number of TLVs
TLVs
Data[0]
:
Checksum
313
MSP
Configuration
SS7SCCPTCAPConfig (
Node = integer,
StackID = integer,
ConfigType = integer,
Data = byte array);
C Structure
typedef struct {
UBYTE StackID;
UBYTE ConfigType;
UBYTE Data[222];
} XL_SS7SCCPTCAPConfig;
C++ Class
class XLC_SS7SCCPTCAPConfig : public XLC_OutboundMessage {
public:
UBYTE getStackID() const;
void setStackID(UBYTE x);
UBYTE getConfigType() const;
void setConfigType(UBYTE x);
const UBYTE *getData() const;
UBYTE *getData();
void setData(UBYTE *x);
};
EXS API Hex Format - Detailed
Message (White)
Response (Grey)
0
0
Byte
Field Description
1, 2
Length (0xNNNN)
3, 4
5
6
314
Frame (0xFE)
Message Type (0x0077)
Reserved (0x00)
Sequence Number
Byte
Field Description
1, 2
Length (0x0007)
3, 4
5
6
Frame (0xFE)
Message Type (0x0077)
Reserved (0x00)
Same Sequence Number
SwitchKit Programmer's Information
7
8
Logical Node ID
AIB
Address Method
0x00 - Individual AEs
7
8, 9
Logical Node ID
Status
MSB - 0x55
LSB - As follows:
01 - Invalid CFG Type
02 - Subsystem Configured
03 - Subsystem Not Configured
04 - Subsystem Allowed
05 - Subsystem Not Allowed
06 - Invalid Option
07 - Exceed Max SSN Host
08 - Invalid Parameter
09 - Invalid Parameter Length
0A - Parameter Configured
0B - Parameter Not Configured
0C - Invalid SCCP Upper Layer
0D - Exceed Max Active
Subsystem
0E - DPC Not Configured
0F - Exceed Max Replicates
10 - Invalid Number of Replicates
11 - Replicate Not Configured
12 - Exceed Max Active SSN
13 - Exceed Max SSN PPC
14 - ESSG Subsystem Not
Configured
15 - ESSG SSN PPC Exist
16 - OPR Not Perm for ESSG SSN
DPC SSN
17 - Local Host Not Allowed
19 - Invalid Tag Type
1A - SCCP not configured for this
stack
1B - GTAI length is out of the
range configured for the group
1D - GT Group hasn’t been
315
MSP
configured
1E - GT Group ID is already
occupied
1F - GT Group with the same
stack ID and selector already
exists
20 - Group ID exceed maximum
group ID
21 - The group parameters are
not matched with parameters
stored in the MSP 1010.
22 - The minimum/maximum
digits number in GT group is
illegal.
23 - GT Entry already in Pending
DEL state
24 - GT already exists in the
group.
25 - GT does not exist.
26 - The memory storing
translation result with global title
has been used up.
27 - GT Entries have been used
up.
28 - GT Entry is found in standby
index table.
29 - GT Entry is found in active
index table.
2A - GT Group is configured but
not for this stack.
2B - Configuration is
unreasonable.
1. Translation result is route on
GT but DPC is equal to OPC.
2C - CPU load is not suitable to
configuration.
:
:
316
Number of AEs to follow
AE
0x08 SS7 Stack
10
2D - Index table needs to be
built.
Checksum
SwitchKit Programmer's Information
: Config Type
0x01 Local SSN
0x02 Adjacent Translator
0x03 Other Concerned Point Code
0x04 SCCP Default Parameter Table
0x05 SSN Default Parameter Table
0x07 Network DPC/SSN
0x08 SCCP/TCAP host configuration
0x09 SCCP Replicated SSN
:
:
0x0C TLV Format Configuration Contents
Number of TLVs
TLVs
0x0690 Frequency Shift Keying (FSK) Data0x09CA Add Global Title Group
0x09CB Delete Global Title Group
0x09CC Add Global Title Entry
0x09CD Delete Global Title Entry
0x09CE Build Index Table
Refer to Chapter 4, Tag Length Blocks in the API Reference.
:
See also, Global Title Translation (GTT) Configuration Samples in the
Developer’s Guide: Common Channel Signaling.
Data[0]
The Data is dependent on the Config Type field (0x01 - 0x09)
0x01 Local SSN
Data[0] Subsystem Number
Data[1] Option
0x01 Add SSN
0x02 Delete SSN
0x03 Modify SSN
Data[2] Routing Flag
Bit 0 - Specify the direct upper layer of the SCCP (TCAP or host
application.)
0 - SCCP Route network message directly to host
1 - SCCP Route network message to TCAP
Bits 1 and 3-7 - Reserved for SASSI and ESSG use. Not used in current
317
MSP
release. Default is 0.
Bit 2 - Specify whether local GTT function is allowed to use when
the message is originated from this SSN. (See note below.)
0 - Disable GTT when message is originated from the local SSN.
1 - Enable GTT when message is originated from the local SSN.
Data[3] Reserved
Note: Bit 2 only enables/disables GTT when the message is originated from
the local SSN. When a message is received from the network and it needs
GTT, the GTT function is always triggered. This bit provides backward
compatibility to those host applications that do not support GTT.
0x02 Adjacent Translator
Data[0] Subsystem Number
Data[1] Option
0x01 Add Adjacent Translator
0x02 Delete Adjacent Translator
Data[2–5] Adjacent Translator
0x03 Other Concerned Point Code
Data[0] Subsystem Number
Data[1] Option
0x01 Add Other Concerned Point Code
0x02 Delete Other Concerned Point
Data[2-5] Other Concerned Point Code
Code
0x04 SCCP/TCAP Default Parameter Table
Data[0] Option
0x01 Add/Modify SCCP/TCAP Default Parameter
0x02 Delete SCCP/TCAP Default
Data[1-2] Parameter Type
Parameter
Data[3-4] Parameter Length
Data[5+] Parameter Value
0x05 SSN Default Parameter Table
Data[0] Subsystem Number
Data[1] Option
0x01 Add/Modify SSN Default Parameter
0x02 Delete SSN Default Parameter
Data[2-3] Parameter Type
0x0066 Default Calling Party Address
318
SwitchKit Programmer's Information
0x006A Default Quality of Service
0x0074 Default MTP dpc (used when DPC is not in CDPA)
Data[4-5] Parameter Length
Data[6+]
Parameter Value
0x06 TCAP OSD
Data[0] Option
0x03 Modify an existing TCAP object.
Data[1-2] TCAP object parameter ID
(See the Developer’s Guide: Common
Parameter Information.
Channel Signaling for SCCP/TCAP
Data[3-4] TCAP identifier
Data[5] Syntax update flag/Object data type (always 0x00)
0x00 Do not update the object syntax /other Object data type
Data[6+] Object syntax description follows if Data[5] is not 0x00.
0x07 Network DPC/SSN
Data[0] Local Subsystem Number
Data[1] Option
0x01 Add Network DPC/SSN
0x02 Delete Network DPC/SSN
Data[2-5] DPC
Data[6]
Remote SSN Number
0x08 SCCP/TCAP host configuration
Data[0] Subsystem Number
Data[1] Option
0x01 Add a host
0x02 Delete a host
Data[2] Local/Matrix host
0xFE Local host
0xFF Matrix host
Data[3] Host Port ID (0-5)
Port IDs 0-5 correspond to Ports 0x3142-0x3147.
NOTE: Only one host can be configured for each stack/subsystem. The
default host is the matrix primary host.
0x09 SS7 SCAP CFG Replicated SSN
Data[0] Subsystem Number
319
MSP
Data[1] Option
0x01 Add Replicated SSN
0x02 Delete Replicated SSN
Data[2]
Number of Replicates
Data[3-6] DPC
Data[7] Subsystem Number
Data[8...] Next DPC and Subsystem Number
0x0C TLV Format Configuration Contents
0x0690 Frequency Shift Keying (FSK) Data
0x09CB Delete Global Title Group
0x09CC Add Global Title Entry
0x09CD Delete Global Title Entry
:
0x09CE Build Index Table
Checksum
TCAPMessageRegister
Use this message to register an application for all TCAP-related PPL Event Indications
given a specific Origination Point Code (OPC), Subsytem Number(SSN) or stack and
SSN.
Important! Only events of Component Type 0x70 (TCAP TUSI) and 0x67 (SCCP
SUSI) will be sent to the registered application.
Sent By:
Function sk_pplTCAPRegister()
Arguments
The following table shows the arguments you can change:
Argument
Description
Stack
Stack value
OPC
Stack_SSN
RegisterType
The Origination Point Code (Stack ID) of the SS7 TCAP stack
generating the PPL Event Indications.
a combination of Stack and SSN created by using the
getSS7TCAP_MultiCard_RoutingID(Stack, SSN)macro
Registration type. Use the following constants to specify either
OPC, SSN or Stack/SSN combination:
SK_TCAP_REG_OPC (0x00) - OPC Registration
SK_TCAP_REG_SSN (0x01) - SSN Registration
SK_TCAP_REG_STACK_SSN 0x02 - Registers a combination of
320
SwitchKit Programmer's Information
RegisterFlag
stack and subsystem number using the
getSS7TCAP_MultiCard_RoutingID(stack,SSN) macro.
Indicates a registration or de-registration using the following
constants:
SK_TCAP_ACTIVATE_REGISTER (0x01) -Register
SK_TCAP_DEACTIVATE_REGISTER (0x00) -Deregister
C Structure
typedef struct {
int OPC;
int STACK_SSN;
int SSN;
UBYTE RegisterType;
UBYTE RegisterFlag;
UBYTE reserved31[2];
} SK_TCAPMessageRegister;
C Structure Response
typedef struct {
int Status;
} SK_TCAPMessageRegisterAck;
C++ Class
class SKC_TCAPMessageRegister : public SKC_ToolkitMessage {
public:
int getOPC() const;
void setOPC(int x);
int getSTACK_SSN() const ;
void setSTACK_SSN(int x) ;
int getSSN() const ;
void setSSN(int x) ;
UBYTE getRegisterType() const ;
void setRegisterType(UBYTE x) ;
UBYTE getRegisterFlag() const ;
321
MSP
void setRegisterFlag(UBYTE x)
};
C++ Class Response
class SKC_TCAPMessageRegisterAck : public SKC_ToolkitAck {
public:
int getStatus() const;
void setStatus(int x);
};
TCAP Routing Feature
TCAP Routing Supports SwitchKit Applications
TCAP Routing provides support for SwitchKit applications connected to the LLC to
register for TCAP messages based on an originating point code (OPC), sub-system
number (SSN) or Stack/SSN pair. When a PPL Event Indication message enters the
LLC from the network, and the component ID is TCAP-specific (0x70), the message
is routed to the "least busy" of the registered applications. For more information on
how inbound TCAP routing is accomplished, see LLC: Application Load Balancing for
TCAP . For more information on registering your applications, see
sk_pplTCAPRegister() / sk_pplTCAPUnRegister() / ...OnConnection() functions in the
SwitchKit Programmer’s Guide, Register Functions n .
Operating System Requirements

Microsoft Windows NT/2000

Solaris SPARC, version 8

Red Hat Linux, version 8.0
Options supported



Routes messages at the card level without the logical node being specified by
the application, based on a defined routing tag that is unique to the system
(such as SS7 stack ID).
Supports redundant MSP nodes.
Provides a means for registering applications for TCAP specific messages.
Sub-component Router
The sub-component router is a module within the LLC process that allows messages
to be routed from an LLCs client application to a card-level device contained within a
node. That card is controlled by a Matrix Controller that has an assigned node ID. In
other words, the card is controlled by that node. The generic requirements for subcomponent routing are as follows:
The device must have a defined type which will be referred to as CardType.
322
SwitchKit Programmer's Information
The SS7 card must be controlled by a Matrix Controller that has been previously
assigned a logical node and is already known by the LLC. This logical node is referred
to as the ControlNode.

RoutingIDs are used to address a pair of card-level devices to ensure
uniqueness across the system. Application developers should obtain
RoutingIDs by using the defined macros provided through the SwitchKit API.
See RoutingID Macros in the AddLLCCard message.
A logical node can contain several devices of a particular CardType, but can only
contain one logical link for each set of devices addressed by a particular RoutingID.
Additional routing IDs can be added to an individual logical link by sending additional
AddLLCCard messages.
Routing Outbound TCAP Messages
When sending an outbound message to a particular sub-component device, there is a
subset of the SwitchKit API messages that the LLC routes or attempts to route. This
subset is distinguished from other message by the CardType. The key concept here
is: for the LLC to extrapolate the correct socket address, it must walk through the
OutboundMessage and retrieve the predetermined unique RoutingID. It does this
when the node ID of the message is set to 0xff (unassigned)and a TCAP socket has
been added to the LLC for that CardType using an AddLLCCard message. For
Outbound routing to be setup within the LLC the following are required:
The node must be added to the LLC using the AddLLCNode message.
The AddLLCCard message must be sent, one per RoutingID.
The SS7 card must be properly configured using the SS7 SCCP TCAP Configure
messages. The LLC requires that the stack be assigned and the Local Host (0xFE) or
Matrix Host (0xFF) option be specified. Although the SS7 card defaults to the Matrix
Host (0xFF) option, the LLC does not. You must specify one or the other. It is
recommended that you delete the opposing option before adding the new.
Routing Inbound TCAP Messages
The following is required when attempting to register a SwitchKit application for
TCAP specific messages:
The application must register for TCAP messages using one of two SwitchKit API
functions:
sk_pplTCAPRegister
sk_pplTCAPRegisterOnConnection
Using SwitchManager
When using SwitchManager for configuration, you should use the AddSS7TCAPCard
message instead of the AddLLCCard message.
Using ClientView
323
MSP
TCAP Routing can be enabled in ClientView from the SS7 Configuration view. When
TCAP is enabled ClientView will add an AddSS7TCAPCard message for each SS7
stack configured on the SS7 node. The remaining TCAP configuration should be done
using the SS7 SCCP/TCAP configuration menu item. This configuration should be
done for each stack. See the ClientView User’s Guide for configuring SS7 TCAP
Routing.
Handler Functions
Handler Functions
Handler functions are available in SwitchKit. It provides prototype information,
possible error return values, and a description of what the function does.
Most functions return an integer value. Upon successful completion, that return value
is OK (0). Non-zero return values indicate some error conditions. Each function lists
the associated error conditions.
Some functions return pointers; those functions do not have a status value indicating
success or failure.
To assist with the standard state machines, the SwitchKit API allows for incoming
messages to be automatically dispatched to an application that has assigned handler
functions. Using these functions, you can install functions to handle state transitions.
In this way, you can avoid using multiple threads to manage different ports, because
SwitchKit handles that automatically.
Important! When you write you handler functions, make sure that you register for
the right sk_rcvAndDispatch() function.
Definition of Handler Functions
typedef struct {
MsgStruct *IncomingMsg;
MsgStruct *AckedMsg;
void *UserData;
} SK_Event;
Syntax
int HandlerFunc(SK_Event *evt, void *tag);
How Applications use Handler Functions
There are four ways that an application can specify the handler function that is
dispatched. Three of them deal with switch-initiated messages, and the fourth deals
with acknowledgments to host-initiated messages.
By using the following handler functions, SwitchKit can take care of the bookkeeping
associated with a state machine. Context associated with a call is passed from one
state to the next through the tag, and all acknowledgments are augmented by a
pointer to the original message.
Switch-Initiated
324
SwitchKit Programmer's Information
sk_setChannelHandler();
sk_pushChannelHandler();
sk_setGroupHandler();
Acknowledgment to Host-Initiated
sk_sendMessageWithHandler();
Default Handler Functions
The default handler functions can be used to set up default handlers, to be called if
no other handler is appropriate. For example, if sk_rcvAndDispatch() returned
SK_NOT_HANDLED, you can add a default handler. This function can be used to set
up handlers for Inter Application messages, switch-initiated messages such as polls
and alarms, or as acknowledgments to any message that was sent without an
explicitly-specified handler for its acknowledgment.
Default Handlers
sk_setDefaultHandler();
sk_pushDefaultHandler();
sk_popDefaultHandler();
sk_removeDefaultHandler();
If the SK_HANDLER_BEHAVIOR bit mask has the SK_HDLR_BHVR_SAFETY_NET bit
set, the default handler can also be invoked if the appropriate handler is found but
returns SK_NOT_HANDLED.
Handler Function Stacks
For simple applications, it is usually sufficient to have just a single handler function
associated with any channel. For more complicated applications, more power is often
needed. SwitchKit allows a stack of handlers to be associated with a channel. These
facilities are demonstrated in the callcard.c application included in the distribution.
Multiple handler functions can be added onto a channel’s handler function stack.
When a switch-initiated message arrives on that channel, the most recently added
handler is called first. That handler can choose to not handle the message by
returning SK_NOT_HANDLED, in which case the next handler on the stack is called.
The SK_Event that is passed to the handler function contains a UserData field. This
field can be used to pass information within the stack of handler functions that are
called for a single event. It is initialized to NULL.
By using a stack of handlers, a series of specialized handlers can be added that only
handle a small set of messages. The first handler that is added should be a generic
handler, to handle all messages that haven’t been handled at a lower level. Lower
level handlers can set some state information in the UserData field of the SK_Event
in order to communicate that part of an otherwise unhandled message has been
processed.
Example
325
MSP
The sk_pushChannelHandler()function pushes the handler function, aHandlerFunc,
onto the handler stack for the specified span and channel.
The sk_popChannelHandler() function removes the top of the Handler Stack for this
span, channel and sets aHandlerFunc to point to this function.
The sk_removeChannelHandler() function removes the specific Handler Function,
aHandlerFunc from the stack for this span, channel.
sk_pushHandler(span,chan,genericHandler);
sk_pushHandler(span,chan,h);
int genericHandler(SK_Event *e, void *tag)
{
MsgStruct *m = e->IncomingMsg;
bool beenPrinted = (bool)e->UserData;
if (!beenPrinted) {
e->UserData = (void *)1;
printMessage(m);
}
printf (“Unhandled message %s\n”,sk_getMsgName(m));
}
int h(SK_Event *e, void *tag)
{
MsgStruct *m = e->IncomingMsg;
bool beenPrinted = (bool)e->UserData;
if (!beenPrinted) {
e->UserData = (void *)1;
printMessage(m);
}
SK_MSG_SWITCH(m)
{
CASE_RequestForService(rfs)
{
handleRFS(rfs);
return OK;
}
} SK_END_SWITCH;
return SK_NOT_HANDLED;
}
sk_popChannelHandler()
326
SwitchKit Programmer's Information
The sk_popChannelHandler() function removes the top of the handler stack for the
specified span and channel and sets aHandlerFunc to point to this function.
Syntax
int sk_popChannelHandler(int aSpan, int aChannel, void **aRtndTag, HandlerFunc
**aRtndHanderFunc);
Threadsafe Syntax
int skts_popChannelHandler(int aSpan, int aChannel, void **aRtndTag, HandlerFunc
**aRtndHanderFunc
Parameters
The function parameters are shown in the table below.
Arguments
Description
aChannel
Specifies the channel.
aSpan
aRtndTag
aRtndHandlerFunc
Specifies the span.
Output parameter that will contain the tag value that was
originally specified when the handler was pushed on the
handler stack.
Output parameter that will contain the message handler
function that was originally specified when the handler was
pushed on the handler stack.
Return Values
Possible return values for this function:
SK_EMPTY The handler stack is empty.
sk_popDefaultHandler()
The sk_popDefaultHandler() function removes the top-most handler function from
the default handler function stack. This function is also available as
skts_popDefaultHandler().
Syntax
int sk_popDefaultHandler(void *aTag, HandlerFunc* aHandlerFunc);
Threadsafe Syntax
int skts_popDefaultHandler( void *aTag, HandlerFunc* aHandlerFunc );
Parameters
327
MSP
The function parameters are shown in the table below.
Arguments
Description
aHandlerFunc
A pointer to a function that is designed to handle messages.
aTag
An application defined pointer which will be returned to the
application when a handler is invoked.
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_popDefaultTCAPHandler()
Use the sk_popDefaultTCAPHandler() function to remove the top-most handler
function from the default TCAP handler function stack. This function is also available
as skts_popDefaultTCAPHandler().
Syntax
int sk_popDefaultTCAPHandler( void **aRtndTag, HandlerFunc
**aRtndHandlerFunc);
Threadsafe Syntax
int skts_popDefaultTCAPHandler( void **aRtndTag, HandlerFunc
**aRtndHandlerFunc);
Parameters
The function parameters are shown in the table below.
Argument
Description
aRtndHandlerFunc
Output parameter that will contain the message handler
function that was originally specified when the handler was
pushed on the handler stack.
aTag
Output parameter that will contain the tag value that was
originally specified when the handler was pushed on the
handler stack.
Return Values
Possible return values for this function:
OK TCAP handler functionality was successfully popped.
SK_EMPTY Unable to pop handler.
sk_popTCAPHandler()
328
SwitchKit Programmer's Information
Use the sk_popTCAPHandler() function to remove the top of the TCAP handler stack
for the specified stack and subsystem number and set aRtndHandlerFunc to point to
this function. This function is also available as skts_popTCAPHandler().
Syntax
int sk_popTCAPHandler(int aStackID, int anSSN, void **aRtndTag, HandlerFunc
**aRtndHandlerFunc);
Threadsafe Syntax
int skts_popTCAPHandler(int aStackID, int anSSN, void **aRtndTag, HandlerFunc
**aRtndHandlerFunc);
Parameters
The function parameters are shown in the table below.
Argument
Description
anSSN
Sub-system number
aStackID
aRtndTag
aRtndHandlerFunc
Stack ID
Output parameter that will contain the tag value that was
originally specified when the handler was pushed on the
handler stack.
Output parameter that will contain the message handler
function that was originally specified when the handler was
pushed on the handler stack.
Return Values
Possible return values for this function:
OK TCAP handler functionality was successfully popped.
SK_EMPTY Unable to pop handler.
sk_pushChannelHandler()
The sk_pushChannelHandler() function pushes the handler function aHandlerFunc
onto the handler stack for the specified span and channel. This function is also
available as skts_pushChannelHandler().
Syntax
int sk_pushChannelHandler(int aSpan, int aChannel, void *aTag, HandlerFunc*
aHanderFunc);
Threadsafe Syntax
int skts_pushChannelHandler( int aSpan, int aChannel, void *aTag, HandlerFunc*
aHanderFunc);
329
MSP
Parameters
The function parameters are shown in the table below.
Arguments
Description
aChannel
Specifies the channel.
aSpan
aTag
aHandlerFunc
Secifies the span
An application defined pointer which will be returned to the
application when a handler is invoked.
A pointer to a function that is designed to handle messages.
Return Values
Always returns OK.
sk_pushDefaultHandler()
The sk_pushDefaultHandler() function pushes aHandlerFunc onto the stack of default
handler functions. It is called before any existing handler functions on the stack. If
no other handler functions apply, then the next highest function on the stack is
called. This function is also available as skts_pushDefaultHandler().
Syntax
int sk_pushDefaultHandler(void *aTag, HandlerFunc* aHandlerFunc);
Threadsafe Syntax
int skts_pushDefaultHandler( void *aTag, HandlerFunc* aHandlerFunc );
Parameters
The function parameters are shown in the table below.
Argument
Description
aHandlerFunc
A pointer to a function that is designed to handle messages.
aTag
An application defined pointer which will be returned to the
application when a handler is invoked.
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_pushDefaultTCAPHandler()
Use the sk_pushDefaultTCAPHandler() function to push aHandlerFunc onto the stack
of default TCAP handler functions. It is called before any existing handler functions
330
SwitchKit Programmer's Information
on the stack. If no other handler functions apply, then the next highest function on
the stack is called. This function is also available as skts_pushDefaultTCAPHandler().
Syntax
int sk_pushDefaultTCAPHandler( void *aTag, HandlerFunc* aHandlerFunc);
Threadsafe Syntax
int skts_pushDefaultTCAPHandler( void *aTag, HandlerFunc* aHandlerFunc);
Parameters
The function parameters are shown in the table below.
Arguments
Description
aHandlerFunc
A pointer to a function that is designed to handle messages.
aTag
An application defined pointer which will be returned to the
application when a handler is invoked.
Return Values
Possible return values for this function:
OK TCAP handler functionality was successfully pushed.
SK_BAD_LICENSE TCAP handler functionality was not successfully unlocked.
sk_pushTCAPHandler()
Use the sk_pushTCAPHandler() function to push the handler function, aHandlerFunc,
onto the TCAP handler stack for the specified stack and subsystem number. This
function is also available as skts_pushTCAPHandler().
Syntax
int sk_pushTCAPHandler(int aStackID, int anSSN, void *aTag, HandlerFunc*
aHandlerFunc);
Threadsafe Syntax
int skts_pushTCAPHandler(int aStackID, int anSSN, void *aTag, HandlerFunc*
aHandlerFunc);
Parameters
The function parameters are shown in the table below.
Arguments
aStackID
Description
Stack ID
331
MSP
anSSN
Sub-system number
aHandlerFunc
A pointer to a function that is designed to handle messages.
aTag
An application defined pointer which will be returned to the
application when a handler is invoked.
Return Values
Possible return values for this function:
OK TCAP handler functionality was successfully pushed.
SK_BAD_LICENSE TCAP handler functionality was not successfully unlocked.
sk_removeChannelHandler()
The sk_removeChannelHandler() function removes the handler function
aHandlerFunc from the stack for the specified span and channel. This function is also
available as skts_removeChannelHandler().
Syntax
int sk_removeChannelHandler(int aSpan, int aChannel, void *aTag, HandlerFunc*
aHandlerFunc);
Threadsafe Syntax
int skts_removeChannelHandler(int aSpan, int aChannel, void *aTag, HandlerFunc*
aHandlerFunc);
Parameters
The function parameters are shown in the table below.
Arguments
Description
aChannel
ch specifies the channel.
aSpan
aTag
aHandlerFunc
sp specifies the span.
An application defined pointer which will be returned to the
application when a handler is invoked.
A pointer to a function that is designed to handle messages.
Return Values
Possible return values for this function:
SK_NOT_PRESENT The specified handler function is not in the handler stack of the
channel.
sk_removeDefaultHandler()
332
SwitchKit Programmer's Information
The sk_removeDefaultHandler() function removes the specified handler
aHandlerFunc from the handler function stack wherever it is. This function is also
available as skts_removeDefaultHandler().
Syntax
int sk_removeDefaultHandler(void *aTag, HandlerFunc* aHandlerFunc);
Threadsafe Syntax
int skts_removeDefaultHandler( void *aTag, HandlerFunc* aHandlerFunc );
Parameters
The function parameters are shown in the table below.
Arguments
Description
aHandlerFunc
A pointer to a function that is designed to handle messages.
aTag
An application defined pointer which will be returned to the
application when a handler is invoked.
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_removeDefaultTCAPHandler()
Use the sk_removeDefaultTCAPHandler() function to remove the specified handler,
aHandlerFunc, from the Default TCAP handler function stack wherever it is. This
function is also available as skts_removeDefaultTCAPHandler().
Syntax
int sk_removeDefaultTCAPHandler(void *aTag, HandlerFunc* aHandlerFunc);
Threadsafe Syntax
int skts_removeDefaultTCAPHandler(void *aTag, HandlerFunc* aHandlerFunc);
Parameters
The function parameters are shown in the table below.
Arguments
Description
aHandlerFunc
A pointer to a function that is designed to handle messages.
aTag
An application defined pointer which will be returned to the
application when a handler is invoked.
333
MSP
Return Values
Possible return values for this function:
TRUE Always returns TRUE (1)
sk_removeLLCConnectionHandler()
The sk_removeLLCConnectionHandler() function removes the LLC connection handler
associated with the specified tag value. This function is also available as
skts_removeLLCConnectionHandler().
Syntax
int sk_removeLLCConnectionHandler( void *aTag, LLCHandlerFunc
*anLLCHandlerFunc);
Threadsafe Syntax
int skts_removeLLCConnectionHandler( void *aTag, LLCHandlerFunc
*anLLCHandlerFunc);
Parameters
The function parameters are shown in the table below.
Argument
Description
aHandlerFunc
A pointer to a function that is designed to handle messages.
aTag
The value used when the LLC connection handler was originally
defined using sk_setLLCConnectionHandler(). If the same value is
not used, the LLC connection handler will not be removed.
Return Values
Possible return values for this function:
SK_HANDLER_NOT_FOUND A connection handler with the specified tag was not
found. No connection handler was removed.
SK_UNABLE_TO_OBTAIN_LOCK Error occurred obtaining a Mutex. (Threadsafe
library only.)
OK - A handler was successfully removed.
OK Success
sk_removeTCAPHandler()
Use the sk_removeTCAPHandler() function to remove the handler function,
aHandlerFunc, from the TCAP handler stack for the specified stack and subsystem
number. This function is also available as skts_removeTCAPHandler().
Syntax
334
SwitchKit Programmer's Information
int sk_removeTCAPHandler(int aStackID, int anSSN, void *aTag, HandlerFunc*
aHandlerFunc);
Threadsafe Syntax
int skts_removeTCAPHandler(int aStackID, int anSSN, void *aTag, HandlerFunc*
aHandlerFunc);
Parameters
The function parameters are shown in the table below.
Arguments
Description
anSSN
Subsystem number
aStackID
aTag
aHandlerFunc
Stack ID
An application defined pointer which will be returned to the
application when a handler is invoked.
A pointer to a function that is designed to handle messages.
Return Values
Possible return values for this function:
TRUE Always returns TRUE (1)
sk_setChannelHandler()
The sk_setChannelHandler() function installs aHandlerFunc as the handler. If there is
currently a stack of handler functions, it is cleared first. This function is also available
as skts_setChannelHandler().
Syntax
int sk_setChannelHandler(int aSpan, int aChannel, void *aTag, HandlerFunc*
aHandlerFunc);
Threadsafe Syntax
int skts_setChannelHandler(int aSpan, int aChannel, void *aTag, HandlerFunc*
aHandlerFunc);
Parameters
The function parameters are shown in the table below.
Arguments
Description
aChannel
Specifies the channel.
aSpan
Specifies the span.
335
MSP
aTag
aHandlerFunc
An application defined pointer which will be returned to the
application when a handler is invoked.
A pointer to a function that is designed to handle messages.
Return Values
Always returns OK.
sk_setDefaultHandler()
The sk_setDefaultHandler() function installs aHandlerFunc as the default handler. If
there is currently a stack of handler functions, it is cleared first. This function is also
available as skts_setDefaultHandler().
Syntax
int sk_setDefaultHandler(void *aTag, HandlerFunc* aHandlerFunc );
Threadsafe Syntax
int skts_setDefaultHandler(void *aTag, HandlerFunc* aHandlerFunc );
Parameters
The function parameters are shown in the table below.
Argument
Description
aHandlerFunc
A pointer to a function that is designed to handle messages.
aTag
An application defined pointer which will be returned to the
application when a handler is invoked.
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_setDefaultTCAPHandler()
Use the sk_setDefaultTCAPHandler() function to install aHandlerFunc as the default
TCAP handler. If there is currently a stack of default TCAP handler functions, it is
cleared first.. This function is also available as skts_setDefaultTCAPHandler().
Syntax
int sk_setDefaultTCAPHandler( void *aTag, HandlerFunc* aHandlerFunc);
Threadsafe Syntax
int skts_setDefaultTCAPHandler( void *aTag, HandlerFunc* aHandlerFunc);
336
SwitchKit Programmer's Information
Parameters
The function parameters are shown in the table below.
Arguments
Description
aHandlerFunc
A pointer to a function that is designed to handle messages.
aTag
An application defined pointer which will be returned to the
application when a handler is invoked.
Return Values
Possible return values for this function:
OK TCAP handler functionality was successfully set.
SK_BAD_LICENSE TCAP handler functionality was not successfully unlocked.\
sk_setGroupHandler()
The sk_setGroupHandler() function installs HandlerFunc as the group handler. If
there is currently a stack of handler functions, it is cleared first. This function is also
available as skts_setGroupHandler().
Syntax
int sk_setGroupHandler(char *aChannelGroupName, void *aTag, aHandlerFunc*);
Threadsafe Syntax
int skts_setGroupHandler( char *aChannelGroupName, void *aTag, HandlerFunc*
aHandlerFunc );
Parameters
The function parameters are shown in the table below.
Argument
Description
aTag
An application defined pointer which will be returned to the
application when a handler is invoked.
aGroupName
aHandlerFunc
Specifies the group.
A pointer to a function that is designed to handle messages.
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_setLLCConnectionHandler()
337
MSP
The sk_setLLCConnectionHandler() function installs a handler function that will be
called any time the application's connection with the LLC is created or destroyed by
the SwitchKit API. The connection is created each time the application successfully
connects to the LLC. The connection is destroyed each time the application is
disconnected from the LLC. Disconnection may occur for any number of reasons
including, termination of the LLC, network problems, or failure of the application to
call rcvAndDispatch() on a regular basis.
When an LLC switchover occurs, the LLC connection handler will be called twice:
When the connection to the LLC is initially lost indicating that a connection has been
destroyed
(state = SK_LLC_CONN_DESTROYED)
When the connection to an LLC is established indicating that a connection has been
created
(state = SK_LLC_CONN_CREATED).
This function is also available as skts_removeLLCConnectionHandler().
Syntax
int sk_setLLCConnectionHandler( void *aTag, LLCHandlerFunc *anLLCHandlerFunc);
Threadsafe Syntax
int skts_setLLCConnectionHandler( void *aTag,
LLCHandlerFunc *anLLCHandlerFunc);
Definition of LLC Connection Handler Functions
Syntax
void LLCHandlerFunc(int aConId, int aConState, void *aTag);
Parameters
The function parameters are shown in the table below.
Arguments
Description
aConState
The new state of the LLC connection. Possible values are:
aConId
aTag
338
aConID is a connection identifier specified at connection creation
time and used to indicate which LLC an application wishes to
communicate with.
SK_LLC_CONN_CREATED Application connection to LLC has just
been established.
SK_LLC_CONN_DESTROYED Application connection to LLC has just
been lost.
A value to be passed into the LLC connection handler each time
the LLC connection handler is called. This value is also used to
SwitchKit Programmer's Information
reference the handler when attempting to remove a handler
usingsk_removeLLCConnectionHandler().
Parameters
The function parameters are shown in the table below.
Arguments
Description
aHandlerFunc
A pointer to a function that is designed to handle messages.
aTag
A value to be passed into the LLC connection handler each time
the LLC connection handler is called. This value is also used to
reference the handler when attempting to remove a handler
using sk_removeLLCConnectionHandler().
Return Values
Possible return values for this function:
SK_HANDLER_ALREADY_EXISTS A connection handler for this tag already exists.
Please remove the old connection handler before setting new handler.
SK_UNABLE_TO_OBTAIN_LOCK Error occurred obtaining a Mutex (Threadsafe
library only.)
OK - Handler successfully set.
OK Success
sk_setTCAPHandler()
Use the sk_setTCAPHandler() function to organize the flow of TUSI and SUSI
messages for your application. Once a stack and subsystem number have been
assigned to an application, the sk_setTCAPHandler() function causes the specified
handler function to be called whenever a Excel platform-initiated message arrives on
a stack and subsystem number. This function does not affect the routing of any
acknowledgment messages. This function is also available as skts_setTCAPHandler().
Syntax
int sk_setTCAPHandler(int aStackID, int anSSN, void *aTag, HandlerFunc*
aHandlerFunc);
Threadsafe Syntax
int skts_setTCAPHandler(int aStackID, int anSSN, void *aTag, HandlerFunc*
aHandlerFunc);
Parameters
The function parameters are shown in the table below.
Arguments
Description
339
MSP
aStackID
Identifies Stack ID
aTag
An application defined pointer which will be returned to the
application when a handler is invoked.
anSSN
aHandlerFunc
Identified Subsystem number
A pointer to a function that is designed to handle messages.
Return Values
Possible return values for this function:
OK Always returns OK.
sk_unlockTCAPHandlers()
Use the sk_unlockTCAPHandlers() function to specify an Excel-defined value that will
make the TCAP handlers accessible to Switchkit applications..This function is also
available as skts_unlockTCAPHandlers().
Syntax
sk_unlockTCAPHandlers(char *aKey);
Threadsafe Syntax
skts_unlockTCAPHandlers(char *aKey)
Parameters
The function parameters are shown in the table below.
Argument
aKey
Description
Excel-defined value used to unlock TCAP handlers.
Return Values
Possible return values for this function:
OK TCAP handler functionality was successfully unlocked.
SK_NOT_PRESENT This return value indicates an invalid key.
Logging Functions
Logging Functions
This chapter describes the logging functions available in SwitchKit. It provides
prototype information, possible error return values, and a description of what the
function does.
340
SwitchKit Programmer's Information
Most functions return an integer value. Upon successful completion, that return value
is OK (0). Non-zero return values indicate some error conditions. Each function lists
the associated error conditions.
Some functions return pointers; those functions do not have a status value indicating
success or failure.
All modules within SwitchKit generate log files. You can also generate your own log
files, and have them managed by SwitchKit. Log file entries can also be displayed on
the screen. By default, SwitchManager and the LLC send their output to the screen
as well as to the log file, while the applications only write it to the log file. The
behavior of the LLC and SwitchManager can be changed through the environment
variable SK_SCREEN_OUTPUT, while the behavior of the applications can be changed
by using the function sk_setSilentMode(
sk_getMsgName()
Use the sk_getMsgName() function to return the name of the given message to your
application. This function is also available as skts_getMsgName().
Description
This function call returns the name of a message to the application.
Syntax
int sk_getMsgName(MsgStruct *);
Threadsafe Syntax
int skts_getMsgName(MsgStruct *);
Parameters
The function parameters are shown in the table below.
Arguments
MsgStruct
Description
* Pointer to a generic C Structure representing a message.
Return Values
Possible return values for this function:
SK_LOST_LLC
“Message”
Unknown TK
Tag
Unknown Tag
This return value indicates that your application lost contact
with the LLC.
If the message is a known Toolkit message or EXS API
message, the function returns the message name.
The message is an unknown Toolkit message, returned with
the message tag.
The message is an unknown EXS API message, returned with
the message tag.
341
MSP
AdminMessage
DummyMessage
The message is an AdminMessage.
If the message is a DummyMessage.
sk_logLevel()
Use the sk_logLevel() function to manipulate the level of logging in your system.
This function is also available as sk_logLevelOnConnection() and skts_logLevel.
Description
This function changes the level of logging based on different settings.
Syntax
int sk_logLevel(int aLogLevel);
int sk_logLevelOnConnection(int aLogLevel, int aConID);
Threadsafe Syntax
int skts_logLevel(int aLogLevel, int aConID);
Parameters
The function parameters are shown in the table below.
Pay close attention to Bit 4 behavior. By default the screen
output is enabled, although the bit is cleared. The screen
output is disabled only if you set the bit.
Arguments
aLogLevel
Description
what is a bit mask represented by the following bits:

Bit 1 is set - socket.log is turned on.

Both bits cleared - logging is turned off.

aConID

Bit 2 is set - messages.log is turned on.
Bit 4 is set - screen output is turned off.
aConID is a connection identifier specified at connection creation
time and used to indicate which LLC an application wishes to
communicate with..
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
342
SwitchKit Programmer's Information
sk_logMessage()
Use the sk_logMessage() function to log a specific message to a specified log level.
This function is also available as sk_logMessageOnConnection() and
skts_logMessage.
Description
This function logs a specified message to a specified log level. This function writes to
the Switchmgr Alarm.log.
Syntax
int sk_logMessage(char *aTextMessage, int aLogLevel);
int sk_logMessageOnConnection(char *aTextMessage,int aLogLevel, int aConID);
Threadsafe Syntax
int skts_logMessage(char *aTextMessage,int aLogLevel, int aConID);
Parameters
The function parameters are shown in the table below.
Arguments
Description
aLogLevel
This can be specified as follows:
aTextMessage
Points to the message you want to log.
SK_LVL_INFORM = 0
SK_LVL_MAJOR = 1
SK_LVL_MINOR = 2
SK_LVL_INFORM - simply log the message, no error reported
SK_LVL_MAJOR - log the message as a major error
aConID
SK_LVL_MINOR - log the message as a minor error
aConID is a connection identifier specified at connection creation
time and used to indicate which LLC an application wishes to
communicate with..
Return Values
Possible return values for this function:
OK Successfully executed.
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_setSilentMode()
343
MSP
Use the sk_setSilentMode() function to cause or prevent log output from appearing
on the screen. This function is also available as sk_setSilentMode().
Description
This function controls the log out put on the screen. By default, log output from the
application appears only in the log files.
Syntax
int sk_setSilentMode(int isSilentModeFlag);
Threadsafe Syntax
void skts_setSilentMode(int isSilentModeFlag);
Parameters
The function parameters are shown in the table below.
Argument
isSilentModeFlag
Description
A non-zero value disables the output of logs to the screen.
Setting it to 0 causes all output to log files to also appear on
the screen.
Return Values
This function does not have a return value.
Message Functions
Base Classes
The following are the Base Classes for C++.
SKC_Message
The SKC_Message class is the base class for all messages. An object of this class
knows how to send itself to the switch, and can be asked for its message tag,
message type, and message name. Furthermore, a pointer to the MsgStruct that
serves as its underlying representation can be returned with a call to getStructPtr().
SKC_ToolkitMessage
This class is the base class for all messages that are defined for SwitchKit specific
functions.
SKC_DummyMessage
This is the base class for the dummy messages. Dummy messages are specific to
SwitchManager configuration files and are for internal SwitchKit use only. Do not use
dummy messages for your application development.
344
SwitchKit Programmer's Information
SKC_AdminMessage
This is the base class for messages that perform LLC administrative tasks. Do not
use these administrative messages for your application development.
SKC_ToolkitAck
This class is the base class for all Toolkit messages that are acknowledgments to a
previously sent message.
SKC_TollkitInbound
This is the base class for unsolicited messages from the LLC. These are messages
that are generated inside the LLC for the benefit of application developers. An
example of an SKC_ToolkitInbound message would be SKC_ConnectionStatusMsg.
XLC_SwitchMessage
All message classes that correspond to EXS-defined messages are derived from this
class. This class defines a notion of message size, which corresponds to the size of
an EXS variably-sized message.
XLC_OutboundMessage
An XLC_OutboundMessage is an XLC_SwitchMessage that is going out to the switch
(that is, a host-initiated message).
XLC_InboundMessage
An XLC_InboundMessage is an XLC_SwitchMessage that is coming in from the switch
(that is, an Excel platform-initiated message). It is not an acknowledgment.
XLC_Acknowledge
Message
An XLC_AcknowledgeMessage is an XLC_SwitchMessage that is coming in from the
switch in response to a previously sent outbound message.
XLC_ExpandedNode
Inbound
An XLC_ExpandedNodeInbound is an XLC_Message that includes the Expanded
Logical Node ID AIB.
XLC_OneChannelMessage
An XLC_OneChannelMessage is an XLC_InboundMessage that is occurring on a
specific channel. It defines functions for getting the message’s relevant span and
channel. An example of this would be a Request For Service message.
345
MSP
XLC_SpanRangeMessage
An XLC_SpanRangeMessage is an XLC_OutboundMessage that applies to a range of
spans. It defines functions for getting and setting the starting and ending message
span. The only current XLC_SpanRangeMessage is XLC_J1SpanConfig.
XLC_ChanRangeMessage
An XLC_ChanRangeMessage is an XLC_SpanRangeMessage that not only has a
starting and ending span, but also has a starting and ending channel. The message
applies to all of the channels between the starting span channel pair and the ending
span channel pair. Most configuration messages are XLC_ChanRangeMessages.
XLC_SlotMessage
An XLC_SlotMessage is an XLC_OutboundMessage that acts on a specific slot. It
defines functions for getting and setting the target slot.
XLC_SpanMessage
An XLC_SpanMessage is an XLC_OutboundMessage that acts on a specific span. It
defines functions for getting and setting the target span.
XLC_OneChannel
Outbound
An XLC_OneChannelOutbound is an XLC_OutboundMessage that acts on a specific
channel. It is equivalent to XLC_OneChannelMessage, except that it applies to hostinitiated messages instead of switch-initiated messages. An example of an
XLC_OneChannelMessage is XLC_ChannelParameterQuery.
Derived Leaf Message Objects
All leaf message objects are derived from the base classes described above. The
definitions of these objects are found in CMessages.api.h. CMessages.api.CPP
contains the implementation of these objects. Their constructors all automatically
initialize the underlying C structure, so you don’t need to call sk_initMsg.
For example, to send a CardStatusQuery to the card in Slot 3 through the C++ API,
you would enter:
XLC_CardStatusQuery csq;
csq.setSlot(3);
csq.send(tag, handlerFunction);
Instantiating a Large SwitchKit Message
This section describes how to instantiate a SwitchKit message larger than the default
size. The methods outlined in this section apply to all SwitchKit messages. When
instantiating, the size of the message is defined as the size of the header plus data;
346
SwitchKit Programmer's Information
not just the size of the message data. For example, if the header is eight bytes and
data is 20 bytes, the total message size is 28 bytes.
The two methods for instantiating a message are:


Accept the default size
Customize the message size.
C SwitchKit programmers:
To accept the default size of a message, do one of the following:
XL_SampleMessage *sampleMessagePtr = (XL_SampleMessage *)malloc(sizeof
XL_SampleMessage);
Or:
XL_SampleMessage sampleMessage;
To instantiate a custom-sized message, do the following:
XL_SampleMessage *sampleMessagePtr = (XL_SampleMessage *)malloc(1000);
Then copy the data into the message (size is the actual size of the data for the
message):
memcpy (sampleMessagePtr->Data, buf, size);
C++ SwitchKit programmers:
To accept the default size of a message, do one of the following:
XLC_SampleMessage *sampleMessagePtr =new XLC_SampleMessage;
Or
XLC_SampleMessage sampleMessage;
To instantiate a custom-sized message, do the following:
XLC_SampleMessage *sampleMessagePtr =new XLC_SampleMessage(1000);
Or
XLC_SampleMessage sampleMessage(1000);
Then copy the data into the message (where size is the actual size of the data for
the message)
memcpy (sampleMessagePtr->getDataPtr(), buf, size);
Message Class Macros
For C++ programmers, SwitchKit provides macros that work with message classes
instead of structures.
Syntax
The C++ syntax for a basic message is:
SKC_Message *SK_msg(const MsgStruct *, bool fromSwitch, int bufSz = 0);
347
MSP
Switch Statement
The received message class includes information describing what kind of message it
is. You handle this information with the SKC_MSG_SWITCH macros. These macros
mimic a switch statement, and allow different branches of code to be executed,
depending on the type of message. Within the branch, a cast is automatically
performed for you, allowing you to operate on a variable of the correct type. The
switch statement must end with SKC_END_SWITCH.
Example for C++ with Predefined Macros
SK_Event *incomingEvent = getEvent();
SKC_Message *msg = incomingEvent->IncomingCMsg;
SKC_MSG_SWITCH(msg)
{
CASEC_ConnectAck(ca)
return processStatus(ca->getStatus());
CASEC_ChannelReleased(cr)
{
CleanUpChan(cr->getSpan(), cr->getChannel());
break;
}
CASEC_default
{
/*Unexpected msg!*/
break;
}
} SKC_END_SWITCH
In the SKC_MSG_SWITCH statement, “break” can be used normally, and the lack of
a break statement causes execution to fall through to the next branch, just as a
normal switch statement would. However, the default branch must be labeled with
CASEC_default, as in the above example. The other important syntax difference from
a normal switch statement is the lack of colons after the case label. The macro
inserts the colons for you.
You can find the definitions of the marcros in the included file API_Funcs.h. Those
macros are defined in terms of more primitive operations, which you can use instead
of an SKC_MSG_SWITCH statement.
Steps to Translate Example to Straight C++ Code
1. Copy the message class.
2. Do the switch statement on the tag of the message.
348
SwitchKit Programmer's Information
3. For the first case, use TAG_ConnectAck for the tag of the acknowledgment to
the connect message. There is no XLC_ConnectAck class because its
acknowledgement is generic, so the message is cast to an
XLC_AcknowledgeMessage. It is then stored in the ca variable, which is used
in the body of the case clause.
4. Use the next case for the XLC_ChannelReleased message. This time, the
message is cast to a class that is put in cr.
5. You don’t use the default clause for anything in this example.
Example for C without Predefined macros
SKC_Message *sk_saved_msg = msg;
switch(sk_saved_msg -> getMsgTag())
{
case(TAG_ConnectAck):
{
XLC_AcknowledgeMessage *ca =
(XLC_AcknowledgeMessage *)sk_saved_msg;
return processStatus(ca->getStatus());
}
case(TAG_ChannelReleased):
{
XLC_ChannelReleased *cr =
(XLC_ChannelReleased *)sk_saved_msg;
cleanUpChan(cr->getSpan, cr->getChannel);
break;
}
default:
break;
Message Functions
This chapter provides information about message structures and macros, as well as
information on sending and receiving message functions that are available in
SwitchKit. It provides prototype information, possible error return values, and a
description of what the function does.
Most functions return an integer value. Upon successful completion, that return value
is OK (0). Non-zero return values indicate some error conditions. Each function lists
the associated error conditions.
Some functions return pointers; those functions do not have a status value indicating
success or failure.
349
MSP
Message Headers in C
To process all of the basic message handling required by the EXS API, SwitchKit
presents each message with a header and supplies the appropriate fields for the EXS
Message Type, Size, Sequence numbers, and Node ID.
The data portion of the message can be an SwitchKit Message, an outbound (for
example host to switch) or inbound (for example switch to host) EXS API message,
or an acknowledgment message. In all cases, the manipulation of these messages is
accomplished through the macros described later in this section.
Syntax of Basic C Message Header
typedef struct {
XBYTE Size;
int Tag;
XBYTE SeqNum;
UBYTE NodeID;
int EngineName;
} BaseFields;
Message Structure
To communicate with the LLC, sequences of bytes must be passed through
interprocess communication. To hide the underlying byte representation, SwitchKit
provides a set of message structures to represent the data more intelligently. These
message structures are all defined in the Messages.api.h API file. The structures are
hierarchical, so that a simple cast can convert one to another.
Example
typedef struct {
unsigned short Span;
UBYTE Channel;
UBYTE ResendFlag;
} XL_RequestForService;
MsgStruct msg;
if (sk_getMsgTag(&msg) == TAG_RequestForService)
{
XL_RequestForService *rfs;
rfs = (XL_RequestForService *)&msg;
}
Message Macros for C Programmers
350
SwitchKit Programmer's Information
The following macros are provided to assist in setting up the message. Some macros
have a threadsafe version which is indicated by the skts prefix. Macros do not have
return values; they evaluate. The listed parameters are to show expected types.
sk_initMsg
This macro initializes the structure by zeroing the sequence number and size, and by
setting the tag. This macro must be called on every message structure.
Syntax
void sk_initMsg(MsgStruct *m, int tag);
Threadsafe Syntax
void skts_initMsg(MsgStruct *m, int tag);
Proper Initialization
If the application should fail to call sk_initMsg() before sending the message, the
following text will appear on the console and in the application's maintenance log:
"**Error:Aug 12 2003 09:30:30: Received message with unknown engine type205 is the sender of this message incorrectly using a pre-3.0 version of SwitchKit? This
version of SwitchKit will not work with any pre-3.0versions."
This message incorrectly identifies the source of the problem but indicates that the
message was not properly initialized.
sk_setMsgSize
This macro sets the size of the message. In general, this macro should not be called.
For all fixed-size messages, and almost all variably-sized messages, SwitchKit
computes the size of the message automatically. If you don't set the size, and
SwitchKit cannot compute it, you get this error code returned: SK_NO_MSG_SIZE. In
this case, the size should be set to the length field that would appear in the EXS
message, as described by the API Reference. (Note that the actual value set in the
MsgStruct.Size field will not necessarily be this exact value.)
Syntax
void sk_setMsgSize(MsgStruct *m, aBufSize);
Threadsafe Syntax
XBYTE skts_setMsgSize(MsgStruct *m);
sk_getMsgSize
This macro retrieves the size of the message that was previously set via
sk_setMsgSize. This function will not cause SwitchKit to recompute the size of the
351
MSP
message and therefore should only be called if you are calling sk_setMsgSize(). See
sk_setMsgSize() for more details.
Syntax
XBYTE sk_getMsgSize(MsgStruct *m);
Threadsafe Syntax
XBYTE skts_getMsgSize(MsgStruct *m);
sk_setRange
This macro sets the range of spans and channels for a ChanRangeMsgStruct
message. The macro is equivalent to:
crmsg.StartSpan = startSpan;
crmsg.StartChan = startChan;
crmsg.EndSpan = endSpan;
crmsg.EndChan = endChan;
Syntax
void sk_setRange (ChanRangeMsgStruct* crMsg, int startSpan, int startChan, int
endSpan, int endChan);
Threadsafe Syntax
void skts_setRange (ChanRangeMsgStruct* crMsg, int startSpan, int startChan, int
endSpan, int endChan);
sk_getMsgType
This macro evaluates the following cases:

SK_TYPE_INBOUND: for messages arriving from the switch.

SK_TYPE_TOOLKIT: for SwitchKit-specific messages, for example Add
LLCNode.



SK_TYPE_OUTBOUND: for messages destined for the switch.
SK_TYPE_ADMIN: for SwitchKit administrative messages, for example
AssociateChannelGroup.
SK_TYPE_DUMMY: for SwitchManager-specific messages, for example
PPLTool, AllInService.
Syntax
int sk_getMsgType(MsgStruct *m);
Threadsafe Syntax
int skts_getMsgType(MsgStruct *m);
352
SwitchKit Programmer's Information
isInboundMsg
This macro evaluates TRUE if m points to an inbound message.
Syntax
bool isInboundMsg(MsgStruct *m);
isOutboundMsg
This macro evaluates TRUE if m points to an outbound message.
Syntax
bool isOutboundMsg(MsgStruct *m);
isToolkit
This macro evaluates TRUE if m points to a toolkit message.
Syntax
bool isToolkit(MsgStruct *m);
sk_getXLTag
This macro evaluates to the UBYTE message tag as received by the LLC from the
switch.
Syntax
UBYTE sk_getXLTag(MsgStruct *m);
Threadsafe Syntax
UBYTE skts_getXLTag(MsgStruct *m);
sk_getMsgTag
This macro evaluates to the SK tag and will be offset by 10000 if m points to an
acknowledgement.
Syntax
int sk_getMsgTag(MsgStruct *m);
Threadsafe Syntax
int skts_getMsgTag(MsgStruct *m);
353
MSP
sk_getSeqNum
This macro evaluates to the sequence number for the message m is pointing to.
Syntax
XBYTE sk_getSegNum(MsgStruct *m);
Threadsafe Syntax
XBYTE skts_getSegNum(MsgStruct *m);
sk_setSeqNum
This macro is a convienience macro that sets the sequence number of m to seqNum.
Syntax
void sk_setSeqNum(MsgStruct *m, XBYTE seqNum);
Threadsafe Syntax
void skts_setSeqNum(MsgStruct *m, XBYTE seqNum);
sk_is_positive_ack
This macro evaluates to TRUE if ack is an inbound message and
ack->Status == 0x10.
Syntax
bool sk_is_positive_ack(MsgStruct *m);
Message Structure Macros
To send a message, you must first create a message structure macro.
There are two ways of creating message structure macros. You can choose to use
predefined macros included in SwitchKit, or you can write you own macros. Either
way, you must use a switch statement to go through the message.
Switch Statement with Predefined Macros
The received message structure includes information describing what kind of
message it is. You handle this information with the SK_MSG_SWITCH macros. These
macros mimic a switch statement and allow different branches of code to be
executed, depending on the kind of message. Within the branch, a cast is performed
for you automatically, allowing you to operate on a variable that has the correct
type. The switch statement must end with SK_END_SWITCH.
Example for C with Predefined Macros
354
SwitchKit Programmer's Information
MsgStruct *msg
SK_MSG_SWITCH(msg)
{
CASE_ConnectAck(ca)
return processStatus(ca->Status);
CASE_ChannelReleased(cr)
{
CleanUpChan(cr->Span, cr->Channel);
break;
}
CASE_default
{
/*Unexpected msg!*/
break;
}
} SK_END_SWITCH
In the SK_MSG_SWITCH statement, “break” can be used normally, and the lack of a
break statement causes execution to fall through to the next branch, just as it would
in a normal switch statement. However, the default branch must be labeled with
CASE_default, as in the above example. The other important syntax difference from
a normal switch statement is the lack of colons after the case label. The macro
inserts the colons for you.
In the body of the first two cases, the programmer has referenced structure
elements, Status, Span, and Channel that are only accessed through a correctly-cast
MsgStruct. For example, in the first case ca has been defined by the
CASE_ConnectAck macro to be a pointer to a ConnectAck structure, and is initialized
with msg.
You can find the definitions of the marcros in the included file API_Funcs.h. Those
macros are defined in terms of more primitive operations, which you can use instead
of an SK_MSG_SWITCH statement.
Switch Statement without Predefined Macros
These are the steps to translate the example to straight C code.
1. Copy the message structure.
2. Do the switch statement on the tag of the message.
3. For the first case, use TAG_ConnectAck for the tag of the acknowledgment to
the connect message. There is no XL_ConnectAck structure because its
acknowledgement is generic, so the message is cast to an
XL_AcknowledgeMessage. It is then stored in the ca variable, which is used in
the body of the case clause.
355
MSP
4. Use the next case for the XL_ChannelReleased message. This time, the
message is cast to a structure that is put in cr.
5. CASE_default is not used for anything in this example.
Example for C without Predefined macros
SK_Message *sk_saved_msg = msg;
switch(sk_saved_msg -> getMsgTag())
{
case(TAG_ConnectAck):
{
XL_AcknowledgeMessage *ca =
(XL_AcknowledgeMessage *)sk_saved_msg;
return processStatus(ca->Status);
}
case(TAG_ChannelReleased):
{
XL_ChannelReleased *cr =
(XL_ChannelReleased *)sk_saved_msg;
cleanUpChan(cr->Span, cr->Channel);
break;
}
default:
break;
}
Messages in C++
The C++ API is a rich class hierarchy that corresponds to the set of EXS and
SwitchKit messages that can be sent to the MSP 1010. The class hierarchy lends
structure and organization to these messages, as shown in the C++ Class Hierarchy
diagram. Macros corresponding to the C macros are provided for the C++ message
classes. These macros allow easy branching, based on the type of message received.
SKC_BaseObject
This class is the base of the class hierarchy tree. As delivered in the API, it does not
derive from any other class. SKC_BaseObject implements a basic mechanism for
determining if a given object is derived from a particular class. The desc() virtual
function returns a static object pointer that is different for each class. By calling
isKindOf(), the SKC_ClassDesc of a given class is compared against the desc() of the
given object and all of its base classes. If isKindOf() returns true, then the type cast
to the given type is safe.
Example
356
SwitchKit Programmer's Information
SKC_BaseObject *obj = getObject();
if (obj->isKindOf(&SKC_ToolkitMessage:desc())) {
SKC_ToolkitMessage *tkitMsg = (SKC_ToolkitMessage *) obj;
processToolkitMessage(tkitMsg);
}
Class Definition Macros
Every class defined in the SwitchKit C++ API contains an invocation of a macro both
in its class declaration (the .h file) and in its class definition (the C file). As
distributed, these macros complete the implementation of the class derivation testing
mechanism.
The macro invoked in the header file is SK_DECLARE_CLASS(cls, base). The first
argument is the name of the class that the macro invocation appears in, and the
second argument is its base class. SK_DEFINE_CLASS(cls) is invoked in the
implementation file of the class—once for each class defined by the API with an
argument of that class name.
For example, if you want to add a trivial print() function so that all of the classes
know how to print themselves, SK_DECLARE_CLASS could be appended with the
following:
#define SK_DECLARE_CLASS(cls,base) \
virtual void print() {cout << “Object of type” << #cls; } \
...
In the above example, it is assumed that #cls is interpreted by the processor to
substitute in the value of the cls argument, enclosed in quotes.
sk_packAutoStorage()
The sk_packAutoStorage() function converts the message into a sequence of bytes
suitable for sending to the LLC. This function is equivalent to sk_packMessage(),
except that instead of requiring you to pass in a pre-allocated buffer, it automatically
allocates an appropriate buffer with sufficient storage for the given message.
Syntax
int sk_packAutoStorage(MsgStruct *aMsgStruct, char **BufferPtr, int *aBufSize);
Parameters
The function parameters are shown in the table below.
Argument
Description
aBufferPtr
Pointer to a packed message pointing to memory allocated and
owned by SwitchKit API. Application wishing to retain this
information beyond the next call to a SwitchKit API function should
copy the data to memory allocated and controlled by the application
MsgStruct
**m Pointer to a generic C Structure representing a message.
357
MSP
aBufSize
as the memory may be reused the next time a SwitchKit API
function is called.
Size of the packed message.
Return Values
Possible return values for this function:
SK_LOST_LLC
SK_UNKNOWN_MSG_TYPE
SK_BAD_MSG_SIZE
SK_NO_MSG_SIZE
This return value indicates that your application lost
contact with the LLC.
The tag field of this MsgStruct is invalid. Did you call
sk_initMsg()?
The size field computed by SwitchKit does not match
the size field set through sk_setMsgSize(). For this
message, you should not set the message size, and
instead should let SwitchKit compute it
automatically.
For this MsgStruct, no size was set in with
sk_setMsgSize(), and its size couldn’t be computed.
sk_packMessage()
The sk_packMessage() function converts the message into a sequence of bytes
suitable for sending to the LLC. This sequence of bytes is suitable for
sk_sendMessage(), sk_sendMessageWithTag(), or sk_sendMessageWithHandler().
Syntax
int sk_packMessage(MsgStruct *aMsgStruct, char *aBuffer, int *aBufSize);
Parameters
The function parameters are shown in the table below.
Argument
I/O
Description
aBuffer
O
Pointer to a packed message.
MsgStruct
aBufSize
I
I
O
358
**m I Pointer to a generic C Structure representing a
message.
The size of aBuffer. This tells the SwitchKit API how large the
user-provided buffer is and allows the API to stay within the
provided buffer.
The number of bytes of aBuffer that were actually used to
store the packed message.
SwitchKit Programmer's Information
Return Values
Possible return values for this function:
SK_LOST_LLC
SK_UNKNOWN_MSG_TYPE
SK_BAD_MSG_SIZE
SK_NO_MSG_SIZE
This return value indicates that your application lost
contact with the LLC.
The tag field of this MsgStruct is invalid. Did you call
sk_initMsg()?
The size field computed by SwitchKit does not match
the size field set through sk_setMsgSize(). For this
message, you should not set the message size, and
instead should let SwitchKit compute it
automatically.
For this MsgStruct, no size was set in with
sk_setMsgSize(), and its size couldn’t be computed.
sk_rcvAndDispatch()
The sk_rcvAndDispatch() is a replacement for sk_rcvMessage() that knows about
handler functions. If you are using handler functions anywhere in your code, always
call sk_rcvAndDispatch(), or the messages will not be dispatched correctly. When a
message arrives, sk_rcvAndDispatch() determines whether there is any handler
function associated with that message. If so, it calls the handler with the appropriate
arguments.
sk_rcvAndDispatch() calls the handler function with any tag received and, if this
message is an acknowledgment, it also passes in a pointer to the original MsgStruct
that triggered this acknowledgment. Notice that all messages passed to the handler
function are already unpacked. sk_rcvAndDispatch() returns whatever integer the
handler function returns. Because the main sk_rcvAndDispatch() loop checks the
return values, it is important that all of the handler functions return a valid integer.
Any integer may be returned. Since many SwitchKit #defines use negative integers
for many error codes, for example SK_LOST_LLC is -3, you should restrict yourself to
returning non-negative integers only.
If there is no associated handler function, rcvAndDispatch returns
SK_NOT_HANDLED, and its buffer and size are indicated, just as though
sk_rcvMessage() had been called. The application module can then unpack and
handle the undispatched message.
This message is also available as sk_rcvAndDispatchOnConnection() and
skts_rcvAndDispatch().
Syntax
int sk_rcvAndDispatch(char *aBuffer, int *aBufSize, double aTimeout, void **aTag);
int sk_rcvAndDispatchOnConnection(char *aBuffer, int *aBufSize, double aTimeout,
void **aTag, int *aConIDPtr);
Parameters
The function parameters are shown in the table below.
Argument
Description
359
MSP
aBuffer
Pointer to a packed message.
aTimeout
The maximum time the function should wait for a message before
returning. The timeout value is a floating point number allow the
application to specify a fractional portion to the timeout. For
example, a timeout value of 1.5 seconds would be interpreted as a
one and one-half second timeout. If no message arrives which is
destined for the application in the specified time, the function
should return SK_NO_MESSAGE.
aBufSize
aTag
aConIDPtr
Size of the packed message.
The application-defined pointer that is only valid if the function
returns SK_NOT_HANDLED. The value was set in either the original
message send operation if the message is an acknowledgement or
was set when the handler was defined if the message is switchinitiated.
This is used to identify from which LLC connection the message was
received.
Return Values
Possible return values for this function:
SK_LOST_LLC
SK_NO_MESSAGE
SK_BAD_MESSAGE
SK_FRAMING_FAILURE
SK_SOCKET_WRITE_ERROR
SK_NODE_NOT_FOUND
SK_INVALID_LINK
SK_NOT_HANDLED
360
This return value indicates that your application
lost contact with the LLC.
No message was received. The time-out expired
before any messages (other then Poll messages)
were received by the LLC.
An improperly formatted message was received.
Message being sent to an MSP 1010 has a
mismatched length between the actual length and
the calculated length Reformat the message and
send again.
LLC encountered an issue writing a message to a
socket. This could be the result of a full socket
(the distant end not reading from the socket
appropriately) or a severed connection.
A message was directed to an MSP 1010 that LLC
is not connected to. This could happen when an
application specifies a node ID that has not been
added to this configuration.
A message was directed to a MSP 1010 that LLC
was no longer connected to. This could happen
when a connection to an MSP 1010 is unexpectedly
severed.
Message was not handled by handler function, no
results available.
SwitchKit Programmer's Information
SK_MSG_TOO_BIG
This value is returned because the buffer for a
message was too small, or because the message
was larger than the limit (64 KB). The size integer
value that you pass in is an input/output variable
that indicates the size of the message that it
unpacked, regardless of what you passed it.
Example
Code sample demonstrating the use of sk_rcvAndDispatch().
#define MSG_SIZE=1024
main(int argc, char *argv[])
{
char buf[MSG_SIZE];
int sz, ret;
void *dta;
char * AppName;
SKC_Message * msg;
...
/*Initialize connection to LLC with name*/
sk_initializeConnection(TANDEM_APP);
...
while (1) {
sz = MSG_SIZE;
/*Initialize maximum size of message to receive*/
if (debug > 5)
printf("\nWaiting for an Inseize at %s for 600 secs...\n", argv[1]);
/* Wait up to 600 seconds for a message. If a message is received that has handler
function(s), rcvAndDispatch will automatically call the handler function(s) and return
the result of the last handler function called. If there are no handler functions, then
SK_NOT_HANDLED is returned, and we just print some info about the message.*/
ret = sk_rcvAndDispatch(buf, &sz, 600, &dta);
....
} /* (ret == SK_NOT_HANDLED)
*/
361
MSP
...
} /* while (1) */
} /* main */
sk_rcvAndDispatchAutoStorage()
The sk_rcvAndDispatchAutoStorage() is identical to sk_rcvAndDispatch(), except that
instead of passing in a pre-allocated buffer, this function automatically allocates
enough memory to receive whatever message comes from the switch. This message
is also available as sk_rcvAndDispatchAutoStorageOnConnection() and
skts_rcvAndDispatchAutoStorage().
Syntax
int sk_rcvAndDispatchAutoStorage(char **aBufferPtr, int *aBufSize, double
aTimeout, void **notCurrentlyUsed);
int sk_rcvAndDispatchAutoStorageOnConnection(char **aBufferPtr, int *aBufSize,
double aTimeout, void **notCurrentlyUsed, int *aConIDPtr);
Parameters
The function parameters are shown in the table below.
Argument
Description
aBufSize
Size of the packed message.
aBufferPtr
aTimeout
NotCurrentlyUsed
aConIDPtr
Pointer to a packed message pointing to memory allocated
and owned by SwitchKit API. Application wishing to retain this
information beyond the next call to a SwitchKit API function
should copy the data to memory allocated and controlled by
the application as the memory may be reused the next time a
SwitchKit API function is called.
The maximum time the function should wait for a message
before returning. The timeout value is a floating point
number allow the application to specify a fractional portion to
the timeout. For example, a timeout value of 1.5 seconds
would be interpreted as a one and one-half second timeout.
If no message arrives which is destined for the application in
the specified time, the function should return
SK_NO_MESSAGE.
The field is no longer used by the SwitchKit API and still
exists for backward compatibility. This value should be set to
NULL(0).
This is used to identify from which LLC connection the
message was received.
The storage of this buffer is managed automatically by SwitchKit.
Return Values
362
SwitchKit Programmer's Information
Possible return values for this function:
SK_INVALID_LINK
SK_FRAMING_FAILURE
SK_SOCKET_WRITE_ERROR
SK_NODE_NOT_FOUND
SK_LOST_LLC
SK_NO_MESSAGE
SK_BAD_MESSAGE
SK_NOT_HANDLED
A message was directed to an MSP 1010 that LLC
was no longer connected to. This could happen
when a connection to an MSP 1010 is unexpectedly
severed.
Message being sent to an MSP 1010 has a
mismatched length between the actual length and
the calculated length Reformat the message and
send again.
LLC encountered an issue writing a message to a
socket. This could be the result of a full socket
(the distant end not reading from the socket
appropriately) or a severed connection.
A message was directed to an MSP 1010 that LLC
is not connected to. This could happen when an
application specifies an MSP 1010 ID that has not
been added to this configuration.
This return value indicates that your application
lost contact with the LLC.
No message was received. The time-out expired
before a message was received or the LLC received
a poll message from the MSP 1010.
An improperly formatted message was received
Message was not handled by handler function, and
no results are available.
sk_rcvMessage()
The sk_rcvMessage() function tries to receive a message from the switch. The buffer
argument must be at least 256 bytes long. The buf argument gets filled in with the
message, and the size argument is set to its size. The timeout argument specifies
how long to wait for a message, in seconds. A value less than 0 means to wait
indefinitely. A value of 0 specifies a polling behavior, returning immediately whether
or not there is a message. A value greater than 0 will wait for a maximum of that
many seconds, or until a message arrives. The actual accuracy of the timeout timer
varies across machines.
Setting your timeout argument to a value of zero (0) or smaller might cause a
significant increase in CPU usage.
363
MSP
The sk_rcvMessage() function also looks for any tag data. If the received message is
an acknowledgment to a previously sent message, then *dta is set to whatever tag
was sent with the original message. If no tag was sent, or if the message was a
switch-originated message instead of an acknowledgment, then *dta is assigned 0.
This message is also available as sk_rcvMessageOnConnection().
Syntax
int sk_rcvMessage(char *aBuffer, int *aBufSize, double aTimeout, void **aDataPtr);
int sk_rcvMessageOnConnection(char *aBuffer, int *aBufSize, double aTimeout, void
**aDataPtr, int *aConID);
Parameters
The function parameters are shown in the next table.
Argument
Description
aBufSize
Size of the packed message.
aBuffer
aTimeout
aDataPtr
aConID
Pointer to a packed message.
The maximum time the function should wait for a message before
returning. The timeout value is a floating point number allow the
application to specify a fractional portion to the timeout. For
example, a timeout value of 1.5 seconds would be interpreted as a
one and one-half second timeout. If no message arrives which is
destined for the application in the specified time, the function
should return SK_NO_MESSAGE.
This argument is not currently used.
aConID is a connection identifier specified at connection creation
time and used to indicate which LLC an application wishes to
communicate with.
Return Values
Possible return values for this function:
SK_INVALID_LINK
364
A message was directed to an MSP 1010 that LLC
was no longer connected to. This could happen
when a connection to a node is unexpectedly
severed.
SwitchKit Programmer's Information
SK_FRAMING_FAILURE
SK_SOCKET_WRITE_ERROR
SK_NODE_NOT_FOUND
SK_LOST_LLC
SK_NO_MESSAGE
SK_BAD_MESSAGE
Message being sent to an MSP 1010 has a
mismatched length between the actual length and
the calculated length Reformat the message and
send again.
LLC encountered an issue writing a message to a
socket. This could be the result of a full socket
(the distant end not reading from the socket
appropriately) or a severed connection.
A message was directed to an MSP 1010 that LLC
is not connected to. This could happen when an
application specifies a MSP 1010 node ID that has
not been added to this configuration.
This return value indicates that your application
lost contact with the LLC.
No message was received. The time-out expired
before a message was received or the LLC received
a poll message from the switch.
An improperly formatted message was received
sk_sendMessage()
The sk_sendMessage() function takes the results of sk_packMessage() and sends a
character buffer with a size to the switch. If no appropriate message structure is
available to pass to sk_packMessage(), the character buffer can be filled in manually.
This message is also available as sk_sendMessageOnConnection() and
skts_sendMessage().
Syntax
int sk_sendMessage(char *aBuffer, aBufSize);
int sk_sendMessageOnConnection(char *aBuffer, aBufSize,
int aConID);
Parameters
The function parameters are shown in the table below
Argument
Description
aBufSize
Size of the packed message.
aBuffer
aTag
aHandlerFunc
aConID
Pointer to a packed message.
An application defined pointer which will be returned to the
application when a handler is invoked.
A pointer to a function that is designed to handle messages.
aConID is a connection identifier specified at connection creation
time and used to indicate which LLC an application wishes to
365
MSP
communicate with.
Return Values
Possible return values for this function:
SK_LOST_LLC
SK_UNKNOWN_MSG_BUF
SK_NO_CONNECT_AVAIL
This return value indicates that your application lost
contact with the LLC.
Buffer and Size pointers do not point to a valid
message.
The specified connection from OnConnection() is not
available or valid.
sk_sendMessageWithHandler()
The sk_sendMessageWithHander() function takes the results of sk_packMessage()
and sends a character buffer indicating the size to the switch. If no appropriate
message structure is available to pass to sk_packMessage(), the character buffer can
be filled in manually.
This function takes a void pointer called tag as an argument. It can be an arbitrary
value and is not used or change by SwitchKit. Upon receipt of an acknowledgment,
the value is passed to the HandlerFunc to provide some context associated with the
sent message.
The sk_sendMessageWithHandler() function also takes a pointer to HandlerFunc as
an argument. The function HandlerFunc points to is called to handle the receipt of
any acknowledgment, when or if it arrives.
This message is also available as sk_sendMessageWithHandlerOnConnection().
Syntax
int sk_sendMessageWithHandler(char *aBuffer, aBufSize,
void *aTag, HandlerFunc *);
int sk_sendMessageWithHandlerOnConnection(char *aBuffer,
int sz, void *aTag, HandlerFunc *aHandlerFunc, int aConID);
Parameters
The function parameters are shown in the table below.
Argument
Description
aBufSize
Size of the packed message.
aBuffer
aTag
366
Pointer to a packed message.
An application defined pointer which will be returned to the
application when a handler is invoked.
SwitchKit Programmer's Information
aHandlerFunc
A pointer to a function that is designed to handle messages.
aConID
aConID is a connection identifier specified at connection creation
time and used to indicate which LLC an application wishes to
communicate with.
Return Values
Possible return values for this function:
SK_LOST_LLC
SK_UNKNOWN_MSG_BUF
SK_NO_CONNECT_AVAIL
This return value indicates that your application lost
contact with the LLC.
Buffer and Size pointers do not point to a valid
message.
The specified connection from OnConnection() is not
available or valid.
sk_sendMessageWithTag()
The sk_sendMessageWithTag() function takes the results of sk_packMessage() and
sends a character buffer with a size to the switch. If no appropriate message
structure is available to pass to sk_packMessage(), the character buffer can be filled
in manually with the bytes that need to be sent.
This function takes a void pointer called tag as an argument. It can be an arbitrary
value and is not used or change by SwitchKit. Upon receipt of an acknowledgment,
the value is passed to the HandlerFunc to provide some context associated with the
sent message.
This message is also available as sk_sendMessageWithTagOnConnection().
Syntax
int sk_sendMessageWithTag(char *aBuffer, aBufSize,
void *aTag);
int sk_sendMessageWithTagOnConnection(char *aBuffer, aBufSize, void *aTag, int
aConID);
Parameters
The function parameters are shown in the table below.
Argument
Description
aBufSize
Size of the packed message.
aBuffer
aTag
aConID
Pointer to a packed message.
An application defined pointer which will be returned to the
application when a handler is invoked.
aConID is a connection identifier specified at connection creation
time and used to indicate which LLC an application wishes to
367
MSP
communicate with.
Return Values
Possible return values for this function:
SK_LOST_LLC
SK_UNKNOWN_MSG_BUF
SK_NO_CONNECT_AVAIL
This return value indicates that your application lost
contact with the LLC.
Buffer and Size pointers do not point to a valid
message.
The specified connection from OnConnection() is not
available or valid.
sk_sendMsgStruct()
The sk_sendMsgStruct() function is a convenience function that first packs a
message, and then calls sk_sendMessageWithHandler(). This message is also
available as sk_sendMsgStructOnConnection() and skts_sendMsgStruct().
Syntax
int sk_sendMsgStruct(MsgStruct *aMsgStruct, void *aTag, HandlerFunc
*aHandlerFunc);
int sk_sendMsgStructOnConnection(MsgStruct *aMsgStruct, void *aTag, HandlerFunc
*aHandlerFunc, int aConID);
int skts_sendMsgStructOnConnection(MsgStruct *aMsgStruct, void *aTag,
HandlerFunc *aHandlerFunc, int aConID);
Parameters
The function parameters are shown in the table below.
Argument
Description
aTag
An application defined pointer which will be returned to the
application when a handler is invoked.
*aMsgStruct
aHandlerFunc
aConID
Pointer to a generic C Structure representing a message.
A pointer to a function that is designed to handle messages.
aConID is a connection identifier specified at connection creation
time and used to indicate which LLC an application wishes to
communicate with.
Return Values
Possible return values for this function:
SK_LOST_LLC
368
This return value indicates that your application lost
contact with the LLC.
SwitchKit Programmer's Information
SK_UNKNOWN_MSG_TYPE
SK_UNKNOWN_MSG_BUF
SK_NO_CONNECT_AVAIL
The tag field of this MsgStruct is invalid. Did you call
sk_initMsg()?
Buffer and Size pointers do not point to a valid
message.
The specified connection from OnConnection() is not
available or valid.
sk_unpackAutoStorage()
The sk_unpackAutoStorage() function takes the character buffer and size returned
by sk_rcvMessage() and unpacks it into a MsgStruct. This function is equivalent to
sk_unpackMessage(), except that instead of requiring you to pass in a pre-allocated
buffer, it automatically allocates an appropriate buffer with sufficient storage for the
given message.
Syntax
int sk_unpackAutoStorage(char *aBuffer, int aBufSize,
MsgStruct *aMsgStructPtr);
Parameters
The function parameters are shown in the table below.
Argument
Description
aBufSize
Size of the packed message.
aBuffer
*aMsgStructPtr
Pointer to a packed message.
Pointer to a generic C Structure representing a message
pointing to memory allocated and owned by SwitchKit API.
The storage of this buffer is managed automatically by SwitchKit.
Return Values
Possible return values for this function:
SK_LOST_LLC
SK__MSG_TOO_BIG
SK_INTERNAL_ERROR
This return value indicates that your application lost
contact with the LLC.
The amount of memory needid to be allocated is greater
than 65536 bytes.
Message could not be unpacked.
sk_unpackMessage()
The sk_unpackMessage() function takes the character buffer and size returned by
sk_rcvMessage() and unpacks it into a message structure.
369
MSP
Syntax
int sk_unpackMessage(char *aBuffer, int aBufSize, MsgStruct *aMsgStruct);
Parameters
The function parameters are shown in the table below.
Argument
Description
aBufSize
Size of the packed message.
aBuffer
aMsgStruct
Pointer to a packed message.
ointer to a generic C Structure representing a message.
Return Values
Possible return values for this function:
SK_LOST_LLC
SK_INTERNAL_ERROR
This return value indicates that your
application lost contact with the LLC.
The message could not be unpacked.
Redundancy
Redundancy
Redundancy functions and redundant application functions are available in SwitchKit,
along with SK API messages for application redundancy and LLC redundancy.
Most functions return an integer value. Upon successful completion, that return value
is OK (0). Non-zero return values indicate some error conditions. Each function lists
the associated error conditions.
Some functions return pointers; those functions do not have a status value indicating
success or failure.
sk_activateExnetMatrix()
sk_registerAsRedundantApp()
LLC and Application Redundancy
API Messages used for Redundancy
sk_activateExnetMatrix()
The sk_activateExnetMatrix() function activates the standby EX/CPU. This message is
also available as sk_activateExnetMatrixOnConnection() and
skts_activateExnetMatrix().
Syntax
370
SwitchKit Programmer's Information
int sk_activateExnetMatrix(int isLeftFlag, int aNodeID);
int sk_activateExnetMatrixOnConnection(int isLeftFlag, int aNodeID, int aConID);
Threadsafe Syntax
int skts_activateExnetMatrix(int isLeftFlag, int aNodeID, int aConID);
Parameters
The function parameters are shown in the table below.
Argument
isLeftFlag
aNodeID
aConID
Description
isLeftFlag!= 0 indicates that the left EX/CPU is activated.
isLeftFlag = 0 indicates that the right EX/CPU is activated.
If the EX/CPU to be activated is already active, then no action will
occur.
Specifies the node the function is sent to.This argument must be
set.
aConID is a connection identifier specified at connection creation
time and used to indicate which LLC an application wishes to
communicate with
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_registerAsRedundantApp() / sk_deregisterAsRedundantApp()
Use the function sk_registerAsRedundantApp() when an application wants to register
as a member of a RAP. The function then uses the SK_RegisterAsRedundantApp
message to process the request. An application can also use this function for
parameter changes of a previous registration.
Registering by calling the function instead of directly sending the API message
guarantees that the message is resent if the application should lose its connection
with the LLC.
This message is also available as sk_registerAsRedundantAppOnConnection() and
skts_registerAsRedundantApp().
To de-register, the application must issue sk_deregisterAsRedundantApp(). This
function also uses the SK_RegisterAsRedundantApp message for the de-registration,
but the RedundantAppPriority argument is hard coded to -1 in order to remove the
application from the RAP. This message is also available as
sk_deregisterAsRedundantAppOnConnection() and
skts_deregisterAsRedundantApp().
The application must be able to handle the acknowledgments for a registration and
de-registration.
371
MSP
Syntax
int sk_registerAsRedundantApp(int anAppID, const char *aRedundantAppPoolID, int
aRedundantAppPriority, int aDataSize, const UBYTE *aDataBuf, void *aTag,
HandlerFunc *aHandlerFunc);
int sk_deregisterAsRedundantApp(int anAppID, const char *aRedundantAppPoolID,
void *aTag, HandlerFunc *aHandlerFunc);
int sk_registerAsRedundantAppOnConnection(int anAppID, const char
*aRedundantAppPoolID, int aRedundantAppPriority, int aDataSize, const UBYTE
*aDataBuf, void *aTag, HandlerFunc *aHandlerFunc, int conID);
int sk_deregisterAsRedundantAppOnConnection(int anAppID, const char
*aRedundantAppPoolID,void *aTag, HandlerFunc *aHandlerFunc, int conID);
Threadsafe Syntax
int skts_registerAsRedundantApp( int anAppID, const char *aRedundantAppPoolID,
int aRedundantAppPriority, int aDataSize, const UBYTE *aDataBuf, void *aTag,
HandlerFunc *aHandlerFunc, int aConID );
int skts_deregisterAsRedundantApp( int anAppID, const char
*aRedundantAppPoolID, void *aTag, HandlerFunc *aHandlerFunc, int aConID );
Parameters
The function parameters are shown in the table below.
Parameter
Description
aRedundantAppPoolID
A string that uniquely identifies the
class of application wishing to be
treated as redundant applications.
anAppID
aRedundantAppPriority
The application identifier assigned by
the LLC to the application. The name
can be obtained by calling
sk_getConnectionName().
Note: The ID is case sensitive.
RedundantAppPriority is a value
indicating the current priority of the
application. The higher the value, the
more likely it is that the LLC will select
the application as primary. Special
values are:
SK_RED_APP_PRI_MONITOR (0)
Used by an application wishing to
monitor the activity of this
RedundantAppClass. An application
selecting this priority cannot be
considered either primary or
secondary.
372
SwitchKit Programmer's Information
SK_RED_APP_PRI_REMOVED (-1)
aDataSize
aDataBuf
aTag
aHandlerFunc
aConID
Used when an application needs to be
removed from an RedundantAppClass
for which it has previously registered.
DataSize
aData can be used by the application to
store information useful to this
application. The value specified in the
request is returned when the RAP is
queried via the
SK_RedundantAppQuery message.
An application defined pointer which
will be returned to the application when
a handler is invoked.
A pointer to a function that is designed
to handle messages.
aConID is a connection identifier
specified at connection creation time
and used to indicate which LLC an
application wishes to communicate with
LLC and Application Redundancy
Applications developed using SwitchKit must often be deployed in a redundant
fashion, to allow for application and host computer failures. You can accomplish
application redundancy by starting multiple, identical copies of an application,
preferably on separate host computers. Each of these applications must be capable
of independently carrying out the other applications functions.
The LLC supports redundant applications by allowing distinct processes to register as
redundant applications. This construct is named the Redundant Application Pool
(RAP). The LLC assists redundant applications by designating one process to be the
primary application for a particular RAP.
The LLC monitors all applications that are members of a RAP, so that one and only
one of these applications is the primary application. If the primary application should
fail, the LLC designates another of these applications to be the primary application.
Rules of RAP
The following table shows the general rules of SwitchKit Application Redundancy.
Rule
Definition
2
If the primary application fails or terminates, the application loses its
primary status.
1
3
The first member of a RAP is primary. All subsequent members are
secondary.
A member of a RAP becomes primary based upon the priority settings
specified at registration time.
373
MSP
Tasks of the LLC
The following list explains the tasks of the LLC regarding redundant application
settings. The LLC
maintains RAPs.

maintains at most one primary app within each RAP.

determines which application is primary in the RAP.






adds applications to a RAP as specified in the sk_registerAsRedundantApp()
call from the application.
notifies the application of its redundancy status upon entering the RAP.
notifies all members of a RAP about any status change of member
applications.
removes an application from all RAPs if disconnected or not responding.
allows an application to force itself to be primary in a RAP.
allows an application to remove itself from a RAP.
Tasks of the Redundant Application
The following list explains the responsibility of applications that are members of a
RAP.



Upon indication that an application is the primary application, it must take
control of all resources belonging to the application.
Upon indication that an application is a secondary application, it must
relinquish control of all resources belonging to the application.
The primary and secondary applications are responsible for sharing
information among themselves, so that the state of the application is
maintained and known across all members of the RAP. This means that if the
primary application of a RAP receives resources (such as a channel or active
call) it should notify all secondary applications. This is necessary because if
something should happen to the primary application, the secondary
application that takes over must have sufficient information to continue
processing all active calls, without any loss of service or resources.
RAPs and Redundant LLCs
In a system setup with redundant LLCs, the redundant RAP information is not shared
between the active and standby LLCs. All registration messages and calls are saved
within the SwitchKit API in the application's process space. When the connection to
the active LLC is lost, the SwitchKit API attempts to connect to the redundant LLC.
Upon successful connection, the SwitchKit API resends any previously sent redundant
application registration messages. This approach keeps the time where no primary
application is selected to a minimum.
When an LLC switchover occurs, it is possible that the primary application can
become secondary, based on the order of the applications re-registration as initiated
374
SwitchKit Programmer's Information
by the SwitchKit API. If this occurs, the previously secondary application will also be
told that it is now primary.
If the application wishes to correct this situation, the new primary application must
send a ReselectPrimaryApp message to the LLC indicating that it wishes to be made
secondary. The LLC then selects another primary application from the registered
applications (if another application exists).
Response Values
The following table shows the Status field values for the redundant application
support:
If the return value is
then...
SK_RED_APP_MEM_ERROR (0xf00d)
an error occurred under the members
of a RAP.
SK_RED_APP_POOL_DOESNT_EXIST
(0Xf00c)
SK_RED_APP_NOT_A_MEMBER
(0xf00e)
SK_RED_APP_NOT_CONNECTED
(0xf00f)
the queried RAP does not exist.
the application is not a registered
member of the RAP.
the registered application lost its
connection to the LLC.
API Messages used for Redundancy
The API messages listed below are used for redundancy. These API messages are
found in the API Reference.

Redundant App Pool Members Query

RedundantAppQuery





RedundantAppQuery
RedundantAppStatusMsg
Redundant LLC Register
RegisterAsRedundantApp
Reselect Primary App
Utility Functions
sk_extractExtendedICBFromChannelReleasedWithData()
The sk_extractExtendedICBFromChannelReleasedWithData() function is used to
extract ICBSubType, ICBLength & ICBData from an SK_ChannelReleasedWithData
message independent of the ICBType (Data Type or Extended Data Type). This
function compensates for the fact that the ICBSubType and ICBLength fields may be
two bytes each for messages with the Extended Data Type ICB or one byte each for
all other ICB’s. All developers extracting information from an
SK_ChannelReleaseWithData message should use this function rather than using the
fields defined in the C Structure. Using this function prevents any future
375
MSP
incompatibilities with other types of ICB data stored in this message. This function is
also available as skts_extractExtendedICBFromChannelReleasedWithData().
Syntax
sk_extractExtendedICBFromChannelReleasedWithData(int* xtICBSubtype,int*
xtICBLength,UBYTE** xtICBData, XL_ChannelReleasedWithData* crwdMsg)
Threadsafe Syntax
int skts_extractExtendedICBFromChannelReleasedWithData( int* xtICBSubtype, int*
xtICBLength, UBYTE** xtICBData, XL_ChannelReleasedWithData* crwdMsg);
Parameters
The function parameters are shown in the table below.
Argument
Description
xtICBLength
ICBLength will be returned in this output argument.
xtICBSubtype
xtICBData
crwdMsg
ICBSubtype value will be returned in this output argument.
A pointer to the ICBData will be returned in this output
argument.
The ChannelReleasedWith Data message from which the abovementioned output is to be extracted.
Return Value
The return value for this function is always:
TRUE(1)
sk_getManagedFile()
This function allows you to access the internal file management capabilities. It
returns a pointer to a FILE structure of an opened file that is ready for writing. You
can write any data to this file.
The benefits of using managed files are:
the location of the file is determined by SK_LOG_DIR.
the file is rotated based on the same criteria as other SwitchKit logs, for example
hourly, daily and so on.
This function is also available as skts_getManagedFile().
Syntax
FILE *sk_getManagedFile(const char *aFileName);
Threadsafe Syntax
376
SwitchKit Programmer's Information
FILE* skts_getManagedFile(const char *aFileName );
Parameters
The function parameters are shown in the table below.
Argument
aFileName
Return Values
Description
Pointer to
specified file.
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_getMessageText()
This function converts any MsgStruct into a text string. This function is also available
as skts_getMessageText().
Syntax
int sk_getMessageText(MsgStruct *aMsgStruct, char *aBuffer);
The char *aBuffer must be previously allocated and at least 5000 bytes long.
Threadsafe Syntax
int skts_getMessageText( MsgStruct *aMsgStruct, char *aBuffer );
Parameters
The function parameters are shown in the table below.
Argument
Description
aBuffer
Pointer to a packed message.
aMsgStruct
Return Values
Pointer to a generic C Structure representing a message.
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_getMsgName()
Returns the name of the given message.This function is also available as
skts_getMsgName().
Syntax
377
MSP
char* sk_getMsgName(MsgStruct *aMsgStruct);
Threadsafe syntax
char* skts_getMsgName(MsgStruct *aMsgStruct);
Parameters
The function parameters are shown in the table below.
Argument
aMsgStruct
Description
Pointer to a generic C Structure
representing a message.
Return Values
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_getMsgSizeFromTag()
Returns the size, in bytes, of the C structure associated with a message of type tag.
For example, sk_getMsgSizeFromTag(0xa8) would return the size of XL_AssignSpan
structure. This function is also available as skts_getMsgSizeFromTag().
Syntax
int sk_getMsgSizeFromTag(int aMessageTag);
Threadsafe Syntax
int skts_getMsgSizeFromTag( int aMessageTag);
Parameters
The function parameters are shown in the table below.
Argument
aMessageTag
Description
Uniquely identifies the message. Valid message tags are defined
in Messages.api.h and begin TAG_. Each message has a message
tag. For example the the RequestForService message, the
message tag is TAG_RequestForService.
Return Values
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
378
SwitchKit Programmer's Information
sk_getVersionMajor() / sk_getVersionMinor() / sk_getVersionBuild()/
sk_getVersionRelease()
Use the sk_getVersion...() function to retrieve SwitchKit version information.
Description
The SwitchKit API version information is divided into several fields that are
retrievable using these functions. The SwitchKit API version follows the format:
AA.BB.CC.DD.
AA represents the SwitchKit API major version number.
BB represents the SwitchKit API minor version number.
CC represents the SwitchKit API release number.
DD represents the SwitchKit API build number.
An example of a SwitchKit API version is 8.02.02.35.
Syntax
int sk_getVersionMajor();
int sk_getVersionMinor();
int sk_getVersionRelease();
int sk_getVersionBuild();
Threadsafe Syntax
int skts_getVersionMajor();
int skts_getVersionMinor();
int skts_getVersionRelease();
int skts_getVersionBuild();
sk_statusText()
Returns a text string associated with status values. This status value can be either
the status returned in an EXS message, or the status returned from a SwitchKit
function call. This function is also available as skts_statusText().
Syntax
char *sk_statusText(int anError)
Threadsafe Syntax
char *skts_statusText(int anError)
Parameters
379
MSP
The function parameters are shown in the table below.
Argument
anError
Description
The status number to convert
Return Values
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_unparseAlarm()
This function converts an XL_Alarm message into a text string, suitable for display.
This function is also available as skts_unparseAlarm().
Syntax
int sk_unparseAlarm(char *aBuffer, XL_Alarm *anAlarmMsg);
Threadsafe Syntax
int skts_unparseAlarm( char *aBuffer, XL_Alarm *anAlarmMsg);
Parameters
The function parameters are shown in the table below.
Argument
Description
anAlarmMsg
The Alarm that is to be unparsed.
aBuffer
Pointer to a packed message.
Return Values
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_unparseAlarmCleared()
This function converts an XL_AlarmCleared message into a text string, suitable for
display. This function is also available as skts_unparseAlarm().
Syntax
int sk_unparseAlarmCleared(char *aBuffer, XL_AlarmCleared *anAlarmClearedMsg);
380
SwitchKit Programmer's Information
Threadsafe Syntax
int skts_unparseAlarmCleared( char *aBuffer, XL_AlarmCleared
*anAlarmClearedMsg);
Parameters
The function parameters are shown in the table below.
Argument
Description
anAlarmClearedMsg
The AlarmCleared message that is to
be unparsed.
aBuffer
Pointer to a packed message.
Return Values
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_unparsePPLEventIndication()
This function converts an XL_PPLEventIndication message into a text string, suitable
for display. This function is also available as skts_unparsePPLEventIndication().
Syntax
int sk_unparseEventIndication(char *aBuffer, XL_PPLEventIndication *aPPLEIMsg);
Threadsafe Syntax
int skts_unparsePPLEventIndication( char *aBuffer, XL_PPLEventIndication
*aPPLEIMsg);
Parameters
The function parameters are shown in the table below.
Argument
Description
aPPLEIMsg
The PPLEventIndication message that is to be unparsed.
aBuffer
Pointer to a packed message.
Return Values
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
381
MSP
Register Functions
Register Functions
This chapter describes the register functions available in SwitchKit. It provides
prototype information, possible error return values, and a description of what the
function does.
Most functions return an integer value. Upon successful completion, that return value
is OK (0). Non-zero return values indicate some error conditions. Each function lists
the associated error conditions.
Some functions return pointers; those functions do not have a status value indicating
success or failure.
The register functions allow your application to monitor different areas of the
communication in your system. The registration lets the LLC route messages,
specified through the function call, to your application, so that your application can
handle them.
sk_appGroupRegister()
The sk_appGroupRegister() function allows a process register to receive messages
directed to the specified application group. This application group is a text name. The
application group name can be used in both InterAppMsg and TransferChanMsg.
Whenever a message is sent to an application group, the LLC routes that message to
the least loaded application (as specified through sk_broadcastLoad()) that has
registered for that application group. This function can be used to allow client
applications to refer to servers by a text name instead of by a number. Furthermore,
there can be multiple servers set up to load share application requests.
For example, you could build a database server that receives SwitchKit messages,
does database queries, and replies. Instead of defining a single application number
of the database server, you can instead use the string “databaseServer” in all
InterAppMsg database requests. Whenever you run a database server, it registers for
that application group and is available to receive database requests. If it is feasible
to run multiple database servers, the requests are load shared among the available
servers.
This message is also available as sk_appGroupRegisterOnConnection() and
skts_appGroupRegister().
Syntax
int sk_appGroupRegister(const char *virtualName);
int sk_appGroupRegisterOnConnection(const char *virtualName, int conID);
Threadsafe Syntax
int skts_appGroupRegister( const char * aVirtualName, int aConID);
Parameters
The function parameters are shown in the table below.
Arguments
382
Description
SwitchKit Programmer's Information
aVirturalName
aConID
A string identifier for an application group which can be targets
for an InterAppMsg or TransChanMsg.
aConID is a connection identifier specified at connection creation
time and used to indicate which LLC an application wishes to
communicate with.
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
Useful Related Functions
SK_Connection *sk_createConnectionWithID();
sk_msgRegister() / sk_msgUnRegister()
The sk_msgRegister() function allows your application to receive switch or LLC
initiated messages that are not associated with a channel. Registering for these
messages does not affect the flow of messages to SwitchManager or to any other
process. This message is also available as sk_msgRegisterOnConnection() and
skts_msgRegister().
The sk_msgUnRegister() function cancels the sk_msgRegister() call. This message is
also available as sk_msgUnRegisterOnConnection() and skts_msgUnRegister().
Syntax
int sk_msgRegister(int aMsgRegisterMask);
int sk_msgUnRegister(int aMsgRegisterMask);
int sk_msgRegisterOnConnection(int aMsgRegisterMask, int aConID);
int sk_msgUnRegisterOnConnection(int aMsgRegisterMask, int aConID);
Threadsafe Syntax
int skts_msgRegister( int aMsgRegisterMask, int aConID );
int skts_msgUnRegister( int aMsgRegisterMask, int aConID);
Parameters
The function parameters are shown in the table below.
Important! All of the bit mask values are defined in SK_API.h. All of the message
structures are defined in Messages.api.h. The C++ Classes are defined in
CMessages.api.h. All of the messages are documented in the API Reference.
Argument - Bit Mask Value
defined in SK_API.h
Message
Originator
383
MSP
defined in SK_API.h
SK_ALL_MSGS
All messages
Switch/LLC
SK_ALARMS
Alarm, AlarmCleared
Switch
SK_POLLS
SK_CSRS
PollMessage
CardStatusReport
SK_NSRS
NodeStatusReport
SK_RSRS
RingStatusReport
SK_DS0S
DS0StatusChange
SK_PPLEIS
SK_CONFERENCE_DELETED
Host
PPLEventIndication
ConferenceDeleted
ConferenceDeleteRequest
Switch
Switch
Switch
Switch
Switch
Switch
Switch
SK_CONFIGMSGS(Internal
Use Only)
All configuration
messages
Client
SK_CHAN_PROBLEM
ChannelProblem
LLC
SK_CONNECT_STATUS
SK_CONFIG_STATUS
SK_CPE_ON_CONFERENCE
SK_RESOURCE_UTIL_
REPORT
SK_D_SERVER_REPORT
SK_HOSTALARM
SK_SERVER_STATUS_REPORT
SK_SERVER_HOST_POLL
SK_SERVER_STATUS_CHANGE
SK_ARP_CACHE_REPORT
SK_CCS_REP
Argument
aConID
384
Description
ConnectionStatusMsg
LLC
ConfigStatusMsg
SwitchManager
CallProcessingEvent
messages which contain
a conference AIB.
Switch
GenericReport (Resource
utilization report)
LLC
DeviceServerStatus
Report
Switch
ServerStatusReport
Switch
HostAlarm
LLC
ServerHostPoll
Switch
ServerStatusChange
ARPCacheReport
CCSRedundancy Report
LLC
Switch
Switch
aConID is a connection identifier specified at connection creation
time and used to indicate which LLC an application wishes to
communicate with.
SwitchKit Programmer's Information
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_pplComponentRegister() / sk_pplComponentUnRegister()
Use the sk_pplComponentRegister() function to receive PPLEventIndication messages
for a particular component. This message is also available as
sk_pplComponentRegisterOnConnection() and skts_pplComponentRegister().
Use the sk_pplComponentUnRegister() function to unregister to receive
PPLEventIndication messages for a particular component. This message is also
available as sk_pplComponentUnRegisterOnConnection() and
skts_pplComponentUnRegister().
Syntax
int sk_pplComponentRegister(int aComponentID);
int sk_pplComponentUnRegister(int aComponentID);
int sk_pplComponentRegisterOnConnection(int aComponentID, int aConID);
int sk_pplComponentUnRegisterOnConnection(int aComponentID, int aConID);
Threadsafe Syntax
int skts_pplComponentRegister( int aComponentID, int aConID );
int skts_pplComponentUnRegister( int aComponentID, int aConID );
Parameters
The function parameters are shown in the table below.
Arguments
Description
aConID
aConID is a connection identifier specified at connection
creation time and used to indicate which LLC an application
wishes to communicate with.
aComponentID
Specifies the PPL component number.
Return Values
The possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the
LLC.
sk_pplTCAPRegister() / sk_pplTCAPUnRegister()
385
MSP
Use the function sk_pplTCAPRegister() to enable an application to register for TCAP
traffic by Sub-System Number (SSN) or Origination Point Code(OPC). This message
is also available as sk_pplTCAPRegisterOnConnection() and skts_pplTCAPRegister().
Use sk_pplTCAPUnRegister() to unregister. This message is also available as
sk_pplTCAPUnRegisterOnConnection() and skts_pplTCAPUnRegister().
Syntax
int sk_pplTCAPRegister(int aRegisterVal, UBYTE aRegisterType);
int sk_pplTCAPUnRegister(int aRegisterVal, UBYTE aRegisterType);
int sk_pplTCAPRegisterOnConnection(int aRegisterVal, UBYTE aRegisterType, int
aConID);
int sk_pplTCAPUnRegisterOnConnection(int aRegisterVal, UBYTE aRegisterType, int
aConID)
Threadsafe Syntax
int skts_pplTCAPRegister( int aRegisterVal, UBYTE aRegisterType, int aConID );
int skts_pplTCAPUnRegister( int aRegisterVal, UBYTE aRegisterType, int aConID );
Parameters
The function parameters are shown in the table below.
Arguments
Description
aRegisterType
Registration type. Use the following constants to
specify either OPC or SSN:
aRegisterVal
SK_TCAP_REG_OPC
SK_TCAP_REG_SSN
SK_TCAP_REG_STACK_SSN
aConID
OPC or Sub-System Number
(0x00) - OPC Registration
(0x01) - SSN Registration
0x02 - Registers a combination of stack and
subsystem number.
aConID is a connection identifier specified at
connection creation time and used to indicate
which LLC an application wishes to communicate
with.
SwitchKit API
API Messages Used for Call Control Programming
This section outlines the messages used for developing call control applications.
Call Control
BusyOut
386
SwitchKit Programmer's Information
CallProcessingEvent
CPAResult
ChannelReleased
ChannelReleasedWithData
ChannelReleaseRequest
CollectDigitString
ConferenceCreate
ConferenceDeleted
ConferenceDeleteRequest
Connect
ConnectOneWayForced
ConnectOneWayToConference
ConnectToConference
ConnectTonePattern
ConnectWait
ConnectWithData
ConnectWithPad
CPCDetection
CrossConnectChannel
CrossConnectSpan
CrossDisconnectChannel
CrossDisconnectSpan
DisconnectTonePattern
DS0StatusChange
DSPCacheModify
DSPServiceCancel
DSPServiceRequest
GenerateCallProcessingEvent
InseizeControl
OutpulseDigits
OutseizeControl
ParkChannel
PlayFileModify
PlayFileStart
PlayFileStop
PPLEventIndication
387
MSP
PPLEventRequest
RecAnnConnect
RecAnnDelete
RecAnnDisconnect
RecAnnDownload
RecAnnDownloadInit
RecordFileModify
RecAnnFSConvert
RecAnnFSDefrag
RecAnnSingleDelete
RecordFileModify
RecordFileStart
RecordFileStop
ReleaseChannel
ReleaseWithData
Remove Channels From Group
Request For Service
ResourceConnect
Resource Create
ResourceDelete
Resource Modify
RFSWithData
Route Control
SwitchKit Application Programming Interface
The SwitchKit Application Programming Interface (API) provides a high-level
interface between the application and the EXS API, to facilitate rapid switch-toapplication integration. This straightforward C/C++ language API is based on
industry standards, and provides automatic configuration and redundancy control,
descriptive logs, and error messages. It extracts the EXS API suite into a C/C++
Library format. This feature enables you to support EXS messaging as well as
administrative messages (between the application and the Low-Level Communicator
(LLC) with all the benefits of a high-level language API.
The power of SwitchKit allows you to concentrate your efforts on building your
telephony applications, without dealing with complex configuration requirements or
administrative tasks. It enhances applications by providing increased reliability and
seamless integration of multiple applications and multiple hosts. The flexibility of
SwitchKit allows you to have control over low-level administrative tasks. In short,
SwitchKit lets you address the call processing aspects of your solutions as you see
fit, giving you the power to implement new services easily, quickly, and profitably.
388
SwitchKit Programmer's Information
Reduced Development Time
SwitchKit significantly reduces development time. You do not have to be concerned
with management APIs and can focus on only the messages that relate to call
control.
SwitchKit not only eliminates the need to develop switch management services, but
it is simple to modify and it also provides a robust, feature-rich management system
with real-time monitoring and system set-up. Providing switch management separate
from the switching platform and applications allows the system to remain modular.
Therefore, upgrades, modifications, and customizations to any single module can be
implemented without affecting the other modules, or requiring subsequent changes.
Openness and Programmability
SwitchKit API adds considerable openness and programmability to the MSP 1010. It
provides access to the EXS API through C structures or C++ classes. Programming
through the SwitchKit API allows the you to focus on functional parts of the code
without concern for system-level details such as checksums and message length.
This translation reduces the overall amount of code necessary to program an
application and simplifies commands from an internal hex format into English-like
statements.
Asynchronous Call Model
SwitchKit’s asynchronous call-processing model uses common state machine call
flows to allow you to easily modify call programming. SwitchKit’s call processing
model uses stacks of event handlers, which allow events associated with the call to
“trickle down” the stack until finding an applicable command. This stacking allows
the code to remain modular, enabling new handlers to be added for new features and
enhancements, and/or to handle unique protocols in different countries or systems.
Inter-Application Messaging
Another feature of SwitchKit API that significantly reduces programming time is
Inter-Application Messaging (IAM). IAM allows applications, and components within
them, to communicate using SwitchKit API messages. Without SwitchKit, you would
need to write your own interfaces for communications between your applications,
and from applications to other components such as a billing system. However,
SwitchKit allows you to use the same messaging interface for all communication,
which reduces complexity, development time, and training.
Because SwitchKit supports a wide variety of operating systems, IAM facilitates
communication between applications running on different computers and operating
systems. SwitchKit also provides programmability for intelligent channel allocations,
which allow applications to select appropriate outgoing ports. Typically, an
application must manage channel idle/busy states and implement intelligence to
route them. SwitchKit manages this process across all applications, allowing you to
choose from a number of selection schemes, including the following:

Round Robin

Most Recently Used

Least Recently Used
389
MSP

Ascending/Descending
Intelligent Channel Allocation
Channels are allocated to applications upon demand, based on the most available
resource in the requested group or set of groups. Intelligent channel allocations can
be used between and across applications, because they may be sharing the same
trunks. SwitchKit also load shares messaging and channel allotments across
applications, based on a programmable load factor that is under application control.
Conversely, you can program the system not to load share if another scheme is more
appropriate.
Internal Messages
Some functions shown in the API function header files are for internal use only.
Among those functions are:

sk_openFile()

sk_downloadFile()


sk_getSwitchmgrId()
sk_newConfig()
Using SwitchKit API
SwitchKit application developers require the SwitchKit API to allow their application
to connect to the LLC. Sample applications are provided for guidance and review.
Additionally, UNIX makefiles and Microsoft Visual Studio project workspaces are
provided. These examples provide information on necessary libraries that are
required for all SwitchKit applications.
For the UNIX operating environments, SwitchKit API is available in two sets of
libraries: standard SK API and threadsafe SK API. Both APIs offer the same basic
functionality to the application developer, with one major difference. The standard
SK API allows single- threaded applications to be developed to connect to the LLC.
The threadsafe SK API allows multi-threaded applications to be developed to
connect to LLC. For maximum flexibility in application functionality today and in the
future, it is recommended that all new development occur on the threadsafe SK API.
All SK API libraries are found in the SK_LIB_DIR\lib directory.
Solaris
If you are using Solaris operating systems, you have the option of using the Forte
compiler available through Sun Microsystems, or GNU gcc version 3.1, as well as the
option of using the threadsafe version of the SK API. SwitchKit API is available to
support these situations. If you wish to use the Forte compiler and the standard SK
API, use libskapi.a and libskcapi.a for your development. If you wish to use the Forte
compiler and the threadsafe SK API, use libskapi_ts.a, libskcapi.a, and
libAce.so.5.3.3 for your development. If you wish to use the GNU compiler, use
libskapiGCC.a and libskcapiGCC.a for your development.
390
SwitchKit Programmer's Information
Linux
If you are using Red Hat Linux operating systems, you have the option of using the
threadsafe library or not. SwitchKit API is available to support both. If you want to
use the standard libraries, use libskap.a and libskcapi.a for your development. If you
want to use the threadsafe libraries, use libskapi_ts.so, libskcapi.so, and
libAce.so.5.3.3 for your development.
Microsoft Windows
All Microsoft Windows-based developers should follow the example in Sample.dsw for
included libraries and classes.
Threadsafe SwitchKit API
Dos and Don’ts of the ThreadSafe SwitchKit Library
Behavior of the API
As part of implementing a threadsafe API on top of the existing API, there was a
layer of code that was developed to restrict access to the thread unsafe portions of
the code. As a result, there are certain behaviors or peculiarities that the application
developer should be aware of. Some of the issues are described below.
Sending Messages
Messages that are sent as a result of calling skts_sendMessage(),
SKC_Message::tsSend() or any functions which result in messages being sent are
actually queued for sending. They are sent by the thread which call
skts_rcvAndDispatch()/skts_rcvAndDispatchAutoStorage() (from here on, I will only
mention skts_rcvAndDispatch() by name as the functions are nearly identical). The
actual send happens quickly. If the thread calling skts_rcvAndDispatch() is blocked
on a socket waiting for a message from LLC, the blocking thread will wake up to send
any queued up messages and then continue waiting for messages).
SwitchKit Handlers
All SwitchKit handlers defined by the application are called within the context of the
thread that called skts_rcvAndDispatch(). This thread should normally be blocked
waiting for a message from the LLC. When a message arrives, the SwitchKit API code
running in that thread will receive the message and determine which handler should
receive the message. The SwitchKit API code will call the handler passing in the
message just received. Applications wishing to have messages processed by other
"worker" threads must arrange to get the message to the worker threads by any
means at the application developer’s disposal. The exact mechanism used to get the
message to the worker thread is outside the scope of SwitchKit API.
No Mixing of Threadsafe and Non-threadsafe Functions
391
MSP
Applications cannot mix threadsafe and standard SwitchKit functions in a single
application. The thread calling skts_rcvAndDispatch() spends some portion of it’s
execution path in the non-threadsafe portion of the code. If another thread attempts
to access the non-threadsafe portion of the code at the same time, SwitchKit internal
data will be corrupted causing your application to behave incorrectly. Therefore,
multi-threaded applications must use functions beginning with "skts" or the
SKC_Message::tsSend() method and no two threads may call skts_rcvAndDispatch()
simultaneously.
Preferred Application Model
Multi-threaded applications developed by Excel customers should use the Threadsafe
SwitchKit API as has been described in this chapter. The Threadsafe SwitchKit API
was designed with an application model consisting of two main components:


The main thread
One or more worker threads.
The Main Thread
The main thread or initial thread of the process is where the application starts
execution. Here, all process level initialization takes place. SwitchKit initialization
should also take place within the main thread.
Steps of a Main Thread Process
The main thread should minimally include:
Step
Description
2
Establish connections to all LLCs.
1
3
4
392
Initialize the Threadsafe SwitchKit API by calling
skts_enableThreadSafeAPI().
Typical applications connect to only one pair of redundant LLCs, however,
in a large distributed environment, the application may be required to
connection multiple LLCs. There should be one skts_createConnection()
call for each LLC redundant pair in the system and each pair should be
assigned a unique connection ID.
Setting the main handlers for the application.
This includes the LLC connection handler
(skts_setLLCConnectionHandler()), at least one default handler
(skts_setDefaultHandler() or skts_pushDefaultHander()) and optionally a
group handler (skts_setGroupHandler()) if performing call processing
using LLC channel groups.
Register for SwitchKit messages.
These messages are switch initiated messages which can present the
current state of the switch or the current state of resources and devices
on the switch. This registration is performed using skts_msgRegister(),
skts_pplComponentRegister(), skts_pplTCAPRegister() or several other
SwitchKit Programmer's Information
5
6
7
function.
Optionally, register for inbound calls being presented to LLC channel
groups.
This is done using the skts_watchChannelGroup()
Spawn worker threads.
More details on worker threads will be provided in the next part of this
discussion.
Call skts_rcvAndDispatch() or skts_rcvAndDispatchAutoStorage() in a
loop.
It is important that one of these two functions be called continuously and
often in order to guarantee timely delivery of messages between the
application and the LLC in both directions. Failure to call this function
often may adversely impact the performance of the application resulting
in symptoms including, but not limited to, processing lower than expected
call volumes and infrequent to frequent loss of connection to LLC.
All messages sent by the LLC to the application will initially be presented
to a handler or will be returned from skts_rcvAndDispatch() or
skts_rcvAndDispatchAutoStorage() within the context of the thread calling
the aforementioned function (in this case, the main thread). In order for
the worker threads to process the message, the message itself or relevant
information contained within the message, should be presented to the
worker threads so that the bulk of the processing may occur within the
context of the worker thread. Failure to do so will result in an application
that is more complicated than a single threaded application, and less
efficient since it will be unable to leverage the multi-processor platforms
commonly used in application deployments.
Worker Threads
Worker threads contain the bulk of the business logic. They must receive
work in the form of a message or information extracted from messages,
process the work, and possibly send the next message to the MSP 1010
that is required to continue processing the transaction. These threads can
be designed to perform tasks which are time-consuming and that will
otherwise impact the throughput of your application. This may include
performing database lookups as part of validating a caller’s right to use
the services provided by your application or the level and types of
services offered to a caller, ASN.1 encoding and decoding of TCAP
message, or any other function which cannot be performed in a very short
period of time.
Initialization Sequence for Worker Threads
The next table shows the general structure of a worker thread:
Step
Description
393
MSP
1
Receive work from the main thread. This work can come in the form of a
copy of the message received from the main thread or the relevant data
from the message received.
2
Process the work.
3
Send any follow-up messages to the switch using skts_sendMessage() or
SKC_Message::tsSend() or any other API that results in a message being
sent.
Other Changes Developers Must Make When Using Threadsafe SK API
Message Registration
In the standard SwitchKit library, several functions that resulted in messages being
sent to the LLC had to be issued only once during the life of the application. If the
LLC were to be disconnected from the application or the LLC were restarted, the
SwitchKit API took care of resending the messages to the LLC. The following
functions are automatically resent (effectively, the SwitchKit API calls the function
internally for the application) whenever a connection to an LLC is re-established:

sk_appGroupRegister()

sk_ignoreChannelGroup()










sk_watchChannelGroup()
sk_clearChannelGroup()
sk_msgRegister()
sk_pplComponentRegister()
sk_pplTCAPRegister()
sk_monitorChannel()
sk_unmonitorChannel()
sk_broadcastLoad()
sk_registerAsRedundantApp()
sk_deregisterAsRedundantApp()
Automatic Resending of Messages Disabled
When using the optional Threadsafe SwitchKit library, the automatic resending of
messages feature is disabled. Instead, an application should register an LLC
connection handler using the skts_setLLCConnectionHandler(). This connection
handler is called any time the connection to the LLC is lost or re-established. When
the handler is called, there is an indication of why the handler is called
(SK_LLC_CONN_CREATED or SK_LLC_CONN_DESTROYED). When the indication is
SK_LLC_CONN_CREATED, all initialization functions should be called, with the
exception of skts_enableThreadSafeLib(), skts_setLLCConnectionHandler(),
skts_createConnection() and any of the functions which establish handlers. A
modified version of threadsafe example program (Modified Threadsafe Sample Code)
is presented below. You will notice the following changes:
394
SwitchKit Programmer's Information
Writing of a new handler function (llcConnectionHandler()) that is called
whenever the connection state of an application to an LLC changes.

The relocation of calls to registration functions, skts_msgRegister()
(previously identified as step 3) and skts_watchChannelGroup() ( previously
identified as step 4) from the main() function to the LLC connection handler.
This way, the functions will be called each time the application establishes a
connection with the LLC.

In the main() function, code was added to define the LLC connection handler
using the skts_setLLCConnectionHandler() function.

All other registrations for messages should take place in the LLC connection handler
including registration for PPL component specific notification and registration for
TCAP messages.
Modified Threadsafe Sample Code
The sample code follows. The changes are highlighted in bold.
// This is the LLC Connection handler which will be called any
// time the state of a connection to an LLC changes.
void llcConnectionHandler(int aConID, // conn ID of LLC
int aConState, // new connection state for LLC
void *aTag) { // tag specified when hdlr defined
if (aConState == SK_LLC_CONN_CREATED) {
// This handler will be called with this state
// any time a connection is established to an LLC.
// This includes the first time we establish a
// connection to the LLC, LLC switchover, recovery
// from temporary loss of connection, etc.
...
// (3) Register for unsolicited messages
status = skts_msgRegister(
SK_PPLEIS | SK_DS0S, // registration mask
aConID); // connection ID
if (status != OK) {
cout << "Error registering for messages from LLC"
<< endl;
}
// Continue to initialize. No point returning.
// (4) Register for new calls from a the specified
// channel group
status = skts_watchChannelGroupOnConnection(
"inboundChannelGroup", / / group name
aConID); // connection ID
395
MSP
}
if (status != OK) {
cout << "Error registering for messages from LLC"
<< endl;
// Continue to initialize. No point returning.
}
...
}
else if (aConState == SK_LLC_CONN_DESTROYED) {
// This handler will be called with this state
// any time a connection to an LLC is lost.
// This includes the temporary loss which occurs
// as part of LLC switchover in a redundant system
// Here you may want disable the sending of messages
// to the LLC the application just disconnected from.
// all attempts to send will fail until the connection
...
// is reestablished.
}
main(int argc, int argv) {
...
// (0) Initialize the threadsafe library.
// This function will initialize some global process level data and
// enable the detection of the mixing of Threadsafe with non Thread// safe functions. This function MUST be called first. Failure to call
// this function first or at all will result in unexpected behavior.
skts_enableThreadSafeAPI();
// (0.5) Set up the LLC connection handler
(void)sk_setLLCConnectionHandler(
NULL, // a user-defined value passed to hdlr func.
llcConnectionHandler); // LLC connection hdlr func.
// (1) Establish connections to LLC’s
int status = skts_createConnection(
1, // connection ID
-1, // application ID (allow LLC to select one)
0, // isForcedFlag (set to 0)
"host1", // primary LLC host name
1312, // primary LLC port number (1312 is default)
"host2", // redundant LLC hostname
1312); // redundant LLC port number (1312 is default)
396
SwitchKit Programmer's Information
if (status != 1)
{
}
cout << "Error has occurred creating connection to LLC" << endl;
return (-1);
...
// (2) Define Handler Functions – returns OK always
// (2a) Default Handler
(void)skts_setDefaultHandler(someTag, // tag for hdlr
someDefaultHandlerFunc); // handler func
// (2b) Group Handler to register for inbound calls
(void)skts_setGroupHandler("inboundChannelGroup", // group name
NULL, // tag
someGroupHandlerFunc); // handler func
...
...
// (5) SwitchKit receive loop
while(1) {
char *buffer; // where msg will be return if not handled
int size; // size of msg returned
void *data; // needed for function call. Not used by API.
int retConID; // conn ID of LLC the message was received from
status = skts_rcvAndDispatchAutoStorage(
&buffer, // contains packed msg if msg not handled
&size, // size of message returned
-1, // timeout - wait forever
&data, // Not currently used.
&retConID); // connection ID on which msg was rcvd
if (status != OK) {
// The code here is exactly the same as in
// Sample Code 1 and is excluded for brevity.
...
} // end if
...
} // end while
}
Linking a Multi-threaded Application
The ThreadSafe SwitchKit API library makes use of the Adaptive Communication
Environment (ACE) library from the University of Washington, St. Louis
(http://www.cs.wustl.edu/˜schmidt/ACE.html) to provide the event dispatching and
397
MSP
synchronization constructs. Any application using the threadsafe library must link
with the ACE library provided as part of the distribution. In addition, the location of
the ACE shared library must be reflected in the LD_LIBRARY_PATH so that the
operating system can find the ACE library when the application is invoked.
Sample Applications
This section presents a comparison of a sample threadsafe application and a sample
of non-threadsafe application, both written in a SwitchKit API development
environment.
Sample Non-Threadsafe Application
The following shows a simple application both using the standard SwitchKit library.
What the application does:
1. Connects with an LLC
2. Sets up handlers: A default handler that will receive all messages should
other handlers not be enabled to catch a message. A group handler for
receiving all inbound call notifications via the RequestForService or
RFSWithData messages
3. Registers for PPLEventIndication and DS0StatusChange messages
4. Loops forever waiting for a message from the LLC.
Sample Non-Threadsafe Code
main(int argc, int argv)
{
...
// (1) Establish connections to LLC’s
int status = skts_createConnection(
1, // connection ID
-1, // application ID (allow LLC to select one)
0, //isForced (set to 0)
"host1", // primary LLC host name
1312, // primary LLC port number (1312 is default)
"host2", // redundant LLC hostname
1312); // redundant LLC port number 1312
if (status == NULL)
{
}
...
cout << ìError has occurred creating connection to LLCî << endl;
return (-1);
// (2) Define Handler Functions – returns OK always
398
SwitchKit Programmer's Information
// (2a) Default Handler
(void)skts_setDefaultHandler(someTag,
handler func
// tag for hdlr someDefaultHandlerFunc); //
// (2b) Set Group Handler for inbound calls
(void)sk_setGroupHandler("inboundChannelGroup", // group name
NULL, // tag for hdlr someGroupHandlerFunc); // handler func
...
// (3) Register for unsolicited messages
status = sk_msgRegisterOnConnection(
SK_PPLEIS | SK_DS0S, // registration mask
1); //connection ID
if (status != OK) {
cout << "Error has occurred registering for message with LLC"
<< endl;
}
return (-1);
(4) Register for new calls from the specified channel group
status = sk_watchChannelGroupOnConnection(
"inboundChannelGroup", // group name
1); //connection ID
if status !=OK {
cout << Error requesting watch of channel group"
<< endl;
}
return (-1);
...
...
// (5) SwitchKit receives loop
while(1) {
char *buffer; //where msg will be returned if not handled
int size;
void *data;
// size of msg returned
//needed for function call. Not used by API
status = sk_rcvAndDispatchAutoStorage(
&buffer,
&size,
-1,
// contains packed msg if msg not handled
// size of message returned
// timeout - wait forever
&data);
// Not currently used.
if (status != OK) {
switch(status) {
399
MSP
case SK_NO_MESSAGE:
// This is a normal return and indicates that
// an internal message was returned.
break;
case SK_BAD_MESSAGE:
cout << " Bad Message rcvd from SwitchKit "
<< endl;
break;
case SK_LOST_LLC:
cout << " Lost Contact With LLC "
<< endl;
break
case SK_NOT_HANDLED:
{
// Message was not processed by any
// application defined handlers
SKC_Message *inboundMsg;
int retval = skc_unpackMessage(
buffer,
size,
&inboundMsg);
if (retval != OK)
{
cout << "Error unpacking message"
<< endl;
break;
}
cout << "Received message "
<< inboundMsg->getMsgName()
<< endl;
}
break;
}
// end switch
}
// end while
}
...
// end if
}
Sample ThreadSafe Application
400
SwitchKit Programmer's Information
In order to convert the simple application presented above into a threadsafe
application, you must make the following changes (the text in the right column show
how to update the previous application’s code to make the application threadsafe.
What the nonthreadsafe
application does...
What to do to make the previous application threadsafe....
(1) Connects with
an LLC
Convert sk_createConnectionWithID() to the threadsafe version of
the function, skts_createConnection(). The arguments to both
functions are the same. The only difference is the
sk_createConnectionWithID() returns SK_Connection * while the
threadsafe version returns a connection ID (aConID), if the
connection is successful or previously created. If
skts_createConnection() fails the following error is returned:
SK_ERROR_CREATING_CONNECTION with a negative integer
value.
(0) Not applicable
The skts_enableThreadSafeLib() function initializes some global
process level data and enables detection of the mixing of
threadsafe and non threadsafe functions. This function must be
called first in a multi-threaded environment before any other
SwitchKit calls. Failure to call this function first will result in
unexpected behavior.
Your application may currently use one of several other ways to
establish a connection including sk_initializeConnection(),
sk_initializeConnectionForced() and sk_createConnection(). Or, it
may not even explicitly connect to the LLC (in which case, the
environment variables are used to determine the location of
primary and redundant LLC). These functions are not supported
for threadsafe applications. The only way to connect to the LLC for
threadsafe applications is using skts_createConnection().
(2) Sets up
handlers:
(a) A default
handler that will
receive all
messages should
other handlers not
be enabled to
catch a message
The connection ID concept allows an application to connect to
multiple redundant LLC pairs for scalability. Specifying a
connection ID dictates which LLC the SK API will use as the target
of a function or message. All threadsafe functions that result in
messages being sent to an LLC require a connection ID as the
last argument.
(a) Convert sk_setDefaultHandler() to the threadsafe version
of the function, skts_setDefaultHandler(). The arguments to
both functions are the same.
(b) Convert sk_setGroupHandler() to the threadsafe version of
the function, skts_setGroupHandler().The arguments to both
functions are the same.
(b) A group
handler for
receiving all
inbound call
401
MSP
notifications via
the
RequestForService
or RFSWithData
messages
(3) Registers for
PPLEventIndication
and
DS0StatusChange
messages
Convert sk_msgRegisterOnConnection() to the threadsafe
version of the function, skts_msgRegister(). The arguments to
both functions are the same.
(4) Registers with
the LLC for new
calls arriving on
channels within
the specified
group.
Convert sk_watchChannelGroupOnConnection() to the
threadsafe version of the function, skts_watchChannelGroup().
The arguments are identical. Your application may use a slightly
different watch channel group function,
sk_watchChannelGroup().As mentioned in (1) above, all
threadsafe functions require the use of a connection ID to indicate
which LLC to target. Note: If your application previously used
sk_watchChannelGroup(), use the same connection ID value
specified in a previous skts_createConnection() function.
(5) Loops forever
waiting for a
message from the
LLC.
Your application may use a slightly different registration function
sk_msgRegister(). As mentioned in (1) above, all threadsafe
functions require the use of a connection ID to indicate which LLC
to target. Note: If your application previously used
sk_msgRegister(), use the same connection ID value specified
in a previous skts_createConnection() function.
Convert sk_rcvAndDispatchAutoStorage() to the threadsafe
version of the function, skts_rcvAndDispatchAutoStorage().
The arguments are nearly identical with the exception of the last
argument, a connection ID. For
skts_rcvAndDispatchAutoStorage() and
skts_rcvAndDispatch(), the connection ID argument is an
output argument and is used to indicate which LLC connection
generated the message should the message be returned in
skts_rcvAndDispatch()/skts_rcvAndDispatchAutoStorage().
This would only happen if skts_rcvAndDispatch()/
skts_rcvAndDispatchAutoStorage() returns
SK_NOT_HANDLED.
Sample Threadsafe Code
The modified code is shown below. Any changes that are necessary are noted in bold
text.
main(int argc, int argv)
{
...
// (0) Initialize the threadsafe library.
// This function will initialize some global process level data and
// enable the detection of the mixing of Threadsafe with non Threadsafe
function MUST be called first. Failure to call
402
//
//functions. This
SwitchKit Programmer's Information
// this function first or at all will result in unexpected behavior.
skts_enableThreadSafeLib();
// (1) Establish connections to LLC’s
int status = skts_createConnection(
1, // connection ID
example, // a const char * to label the connection
-1, // application ID (allow LLC to select one)
0, // isForcedFlag (set to 0)
"host1",// primary LLC host name
1312, // primary LLC port number (1312 is default)
"host2", // redundant LLC hostname
1312); // redundant LLC port number (1312)
if (status <0)
{
}
cout << "Error has occurred creating connection to LLC" <<
sk_statusText(status)<<"("<<status<<")"<<end1;
return (-1);
...
// (2) Define Handler Functions – returns OK always
// (2a) Default Handler
(void)skts_setDefaultHandler(someTag,// tag for hdlr
someDefaultHandlerFunc);
// (2b) Group Handler to register for inbound calls
(void)skts_setGroupHandler("inboundChannelGroup", // group name
NULL, // tag for hdlr
someGroupHandlerFunc); // handler func
...
// (3) Register for unsolicited messages
status = skts_msgRegister(
SK_PPLEIS | SK_DS0S, //registration mask
1);
// connection ID
if (status != OK) {
cout << "Error has occurred registering for message with LLC"
<< endl;
}
return (-1);
...
// (4) Register for new calls from a specified group
status = skts_watchChannelGroup (
"inboundChannelGroup", // group name
403
MSP
1); // connection ID
if (status != OK) {
cout << "Error requesting watch of channel group"
<< endl;
return (-1);
(5) SwitchKit receive loop
while(1) {
char *buffer; // where msg will be return if not handled
int size;
void *data;
// size of msg returned
// needed for function call. Not used by API.
int retConID;
// conn ID of LLC the message was received from
status = skts_rcvAndDispatchAutoStorage(
&buffer, // contains packed msg if msg not handled
&size, // size of message returned
-1, // timeout - wait forever
&data, // Not currently used.
&retConID); // connection ID on which msg was rcvd
if (status != OK) {
// The code here is exactly the same as in
// Sample Non-Threadsafe Code and is excluded for brevity
} // end if
} // end while
...
}
Threadsafe Introduction
The SwitchKit Threadsafe library is an optional replacement for the standard library
provided with the SwitchKit development package. It contains the standard SK API
for non multi-threaded applications as well as threadsafe versions of each C function
and C++ method as necessary. These new functions and methods are the only
functions and methods that should be used by the application developer wishing to
use the SwitchKit threadsafe library.
Important! The SwitchKit Threadsafe library for Linux is a shared not a static
library.
Notational Conventions
All new functions in the threadsafe library begin with the skts_ prefix instead of the
customary sk_ of the standard SwitchKit library. There is one additional method in
the SKC_Message class, tsSend(), that all message classes inherit from, which allows
messages to be sent safely in a multi-threaded environment. Failure to use the
appropriate functions once thread safety has been enabled will result in the following
error being logged in the application’s maintenance log:
Where someFunctionName() is the actual function that was improperly called:
"Function call made to unsafe API(someFunctionName()) when Thread Safety enabled."
404
SwitchKit Programmer's Information
Applications should not mix threadsafe function calls with
non-threadsafe SwitchKit function calls. Failure to heed this
warning will cause unexpected and potentially hazardous
results.
Programming Tips and Examples
Advanced Programming Technique in UNIX
In UNIX, an application can split into two or more processes after opening a
connection with the LLC. The processes, parent and child have a copy of the
connection. All processes can write to the connection with no problem, but if they all
try to read, a race condition occurs and only one process receives the message.
How to Solve the Race Condition
In case parent and child need to communicate with the LLC, the child should call
sk_initializeConnection() or one of the sk_createConnection() functions after
the split to get its own connection.
It is important to understand that in such a case, the processes have a completely
different connection. An acknowledgment of a message sent by one process cannot
be received by the other process. Use the message SK_InterAppMsg to pass on
acknowledgments or other important messages.
Channels are also associated with connection names. Even after a split of processes,
the channels stay with the parent. To delegate a channel assignment to a child, use
the message SK_TransferChanMsg.
Example
The following example demonstrates the connection management calls in action. In
this example, a UNIX process forks a child that connects to the LLC socket.
sk_broadcastLoad(1);// This makes the (parent) open its socket
child = fork(); // Spawn a child process
if (child==0)
{ // CHILD PROCESS CODE
SK_Connection *parentConnect;
SK_Connection *newConnect;
// save the parent's socket
parentConnect = sk_getCurrentConnection();
newConnect = sk_createConnection("Child",-1,0,NULL,
-1,NULL,-1);
// set the child's socket to the new one
sk_setCurrentConnection(newConnect);
// close the parent's socket in the child
405
MSP
sk_destroyConnection(parentConnect);
};
List of Related Connection Management Functions
Depending on your application, you have to issue a function call to one or more of
the following functions after splitting a process:

SK_Connction *sk_createConnection();

sk_*OnConnection();



SK_Connction *sk_createConnectionWithID();
sk_initializeConnection();
sk_initializeForcedConnection();
List of Related API Messages
Depending on your application, you need to send one or more of the following API
messages:


SK_InterAppMsg
SK_TransferChanMsg
Building a SwitchKit Application
All path names are relative to the directory entered during the SwitchKit installation
process.
UNIX
The Makefile included in the samples/src directory assumes the use of GNU make
3.74 or higher. It automatically compiles and links CallSim and simpleTandem as
well as all of the other sample applications in the samples directory. The Makefile
automatically determines which of the recommended platforms and compilers is
being used. Executing the make command automatically builds all samples.
UNIX Troubleshooting
Syntax errors in Makefile on any UNIX platform:
Compilation or link errors:
Building with Linux Red Hat 6.0 - 6.2
1) Install all compat-egcs*.rpm files from the distribution disk
(/mnt/cdrom/RedHat/RPMS)

rpm -Uvh compat-egcs*.rpm
Important! You must have root access to complete this step!
2) cd to /samples/src and edit the Makefile. The following code appear near line 22:
ifeq ($(shell uname -s),Linux)
406
SwitchKit Programmer's Information
CCC = g++
CC = gcc
EXTRALIBS =-Ipthread
endif
Change the path name for the location of the 5.2 compatible compiler tools so
that it is in CCC.
3) Make sure that you are not the root user when you start the build.
Windows NT
The directory, samples/NTBuild contains a Visual C++ version 5.0 workspace, named
samples.dsw. This workspace contains projects for each sample application included
with the SwitchKit installation. After opening the workspace, right-click the project
you want to build in the File View tab, then choose Build (selection only). The
executables appears in samples/NTBuild/Debug/SimpleTandem or
samples/NTBuild/Debug/CallSim. If the release version of the applications are built,
the executables appears in samples/NTBuild/Release/SimpleTandem or
samples/NTBuild/Release/CallSim.
Windows Troubleshooting
Follow these instruction for problems, if you attempt to start a new project or if you
want to change the workspace.

If you get the following error message:
o
Go to Project Settings,
o
o
Link Error:
CallSim.obj : error LNK2001: unresolved external symbol "public: virtual
__thiscall SKC_UserTimer::˜SKC_UserTimer(void)"
(??1SKC_UserTimer@@UAE@XZ)
Select the C/C++ tab,
Under Category, select Preprocessor,
o
Make sure that the field "Additional include directories" shows:

If you get the following error message:
o
Make sure that include/BaseClasses.cpp and include/Messages.api.cpp are
members of the project.

If a run time error occurs:
o
Compilation error: fatal
error C1083: Cannot open include file: 'SKC_API.h': No such file or
directory../../include
Go to Project Settings,
407
MSP
o
o
o
Select the C/C++ tab,
Under Category, select Code Generation
Set the field “Use run-time library” to Multithreaded DLL.
Linking to the SwitchKit API Library file
When you write an application you must link your application to the SwitchKit API
library file: skapi.lib.
To link to the library file, for example, using Microsoft Visual C++ 6.0, you would do
the following steps.
1. On the menu select ProjectÆSettings. The Project Settings dialog box opens.
2. Select the Link tab.
3. Type after the existing text in the text box for Object/library modules:
skapi.lib.
4. Add the path to the library file in the text box for Project Options:
/libpath:"C:\Program
Files\Cantata\installs\MSPSwitchkit_10.2.1.xxx\MSPSwitchkit\switchkit\lib"
5. Click OK.
Proper Initialization
An error message will result, as described further on, when a message is sent before
being properly initialized. You must call sk_initMsg() before sending the message. If
the application should fail to call sk_initMsg() before sending the message, the
following text will appear on the console and in the application's maintenance log:
"**Error:Aug 12 2003 09:30
:30: Received message with unknown engine type205 - is the sender of this message incorrectly using a
pre-3.0 version of SwitchKit? This version of SwitchKit will not work with any pre-3.0versions."


Make sure that the paths to lib and include directories are correct.
Make sure that the make utility you are using is at least GNU make 3.74 or
higher. If you don't have access to this utility, then remove all platform
definitions that are not relevant for the platform you wish to develop on.
Parsing of AIBs
Upon receiving a message that contains an AIB, such as XL_DS0StatusChange, it is
possible to get the Span and Channel by using the sk_getAIB* routines.
Code Example
int genericHandler(SK_Event *evt, void *tag) {
MsgStruct *msg = evt->IncomingMsg;
SK_MSG_SWITCH(msg) {
/* Print info about any DS0 status change */
408
SwitchKit Programmer's Information
CASE_DS0StatusChange(ds0) {
printf("DS0 Stat Change, Span:%d, Chan:%d,
Stat:%d, Purge:%X\n",
sk_getAIBSpan(ds0->AddrInfo),
sk_getAIBChannel(ds0->AddrInfo),
ds0->ChannelStatus,
ds0->PurgeStatus);
}
return OK;
CASE_default {
printf("Unknown message\n");
}
}
return OK;
} SK_END_SWITCH;
Programming Tips & Examples
Use the links below to get information about parsing address information blocks and
advanced programming technique in UNIX. Explanation is also provided about calls
to the SwitchKit API which are necessary for a call processing application. The
examples provide a template for building your own call processing application.
Important! The object the examples is not to provide a complete call processing
solution.
The actual code for the sample applications can be found in the installation directory
in samples and the configuration file can be found in samples/cfg. The demonstration
contains two processes, SimpleTandem and CallSim that run in conjunction with each
other, whereby SimpleTandem answers calls that have been initiated by CallSim.
Parsing of AIBs
Advanced Programming Technique in UNIX
Simple Tandem and CallSim
Building the Application
Running the Application
Running the Application
You can run your call control application described below.
Running the Applications
409
MSP
To run the applications, perform the following steps:

Start the LLC.

Start SimpleTandem at the command line: SimpleTandem


Start SwitchManager and send the tandem.cfg file with the defined inbound
and outbound channel groups.
Start CallSim at the command line: CallSim
To see usage information for either of the applications, provide an -h argument at
the command line.
Simple Tandem and CallSim
The following information provides insight into a simple tandem call control
application included with the samples on the EXS SwitchKit installation CD.
Simple Tandem
The SimpleTandem application waits after initialization for a Request For Service
With Data (RFSD) message. When an RFSD comes in, it outseizes and connects two
channels based on a simple, hard-coded routing algorithm. It performs this function
each time a new RFSD is received. It can be used in conjunction with CallSim.
To run SimpleTandem, the switch must be configured with the provided tandem.cfg
configuration file.
Please refer to the comments in SimpleTandem.h and SimpleTandem.cpp. These files
are provided in PDF format, and you can use the established links to access them.
Process Overview






Initialize a connection to the LLC and inform it of the groups being watched by
the application.
Wait for RFSD in <orig> group.
Call the Route Class to get the number from RFSD and check the AreaCode
Class to determine the <dest> group to be used.
Create an Outseize Control message and outseize to <dest>.
Upon successful outseizure, connect the inbound and outbound channels.
Upon release of the inbound or outbound channel, release the connected
channel and return both channels to the channel manager.
Call Simulator
The CallSim application simulates the endpoints of a tandem call and manages two
channel groups, the originating channel group and the destination channel group.
Using the SwitchKit UserTimer message, a timer is set up to outseize a channel from
the <orig> group on a regular interval. You can define this interval by passing in the
CallDelay argument. Upon succesful outseizure, this channel is parked for a
predetermined length of time. You can define the length of time by passing in the
CallDuration argument. After CallDuration number of seconds, the channel is
released.
410
SwitchKit Programmer's Information
To run CallSim, the switch must be configured with the provided tandem.cfg
configuration file.
Process Overview

Initialize a Connection with the LLC.

Set up a UserTimer message to trigger a certain number of outseizures. This
is set by the NumberOfCalls parameter every CallDelay seconds.




Set the group handler.
Construct the Outseize Control message and outseize.
On receiving positive acknowledgement, park the channel for the CallDuration
period of time, and then release the channel.
When the application receives a 'ChannelReleased' message (at
genericHandler), the channel is returned.
Illustration Diagram
Call Flow
411
SwitchKit TCAP Interface
Introduction
SwitchKit TCAP API Architecture
The SwitchKit TCAP application resides on the host and communicates over TCP/IP
with the MSP 1010. SwitchKit TCAP application components include the following:

SwitchKit Interface Module (SKIM) TCAP API

SwitchKit API library

SwitchKit TCAP Abstraction Layer (SKTAL)
SKIM API
Application developers can use the SwitchKit Interface Module (SKIM) to speed up
development. SKIM provides an API to abstract services from the TCAP and SCCP
layers to a transaction-based application. The SKIM API abstracts details of the SS7
TCAP protocol. The SKIM provides some error handling, abstracting TCAP from the
error handling. The SKIM must keep track of active dialogues, invoke IDs, operation
types, and operation codes.
SKTAL API
The SwitchKit TCAP Abstraction Layer ( is used to create a generic view of the TCAP
layer, so that the underlying stack can be used with the TCAP C++ API. The SKTAL
API allows the SwitchKit TCAP user to easily interface with Intelligent Network (IN)
application layer protocol APIs (GSM-MAP, ANSI-41, WIN, and CAMEL) provided by
IntelliNet Technologies Inc.
SwitchKit API Library
The Switchkit API is a library of function calls used to communicate to both the LLC
and the MSP 1010. In the next diagramm both the TCAP Abstraction Layer and the
application must communicate with the SwitchKit API. Although the MSP 1010 can be
used as a signaling-only platform, its strength is in using it for IN and ISUP signaling
and for media resources. An application must communicate with the SwitchKit API in
order to handle ISUP traffic and to control DSP resources in the MSP 1010.
Key Features of SwitchKit TCAP APIs
SwitchKit TCAP API provides a simple C++ interface to EXS TCAP. SwitchKit TCAP
APIs hide details of PPL messages from the user application.



SwitchKit TCAP API allows the user application to communicate with multiple
stack instances.
SwitchKit TCAP API provides message sanity checking and error handling at
the host.
SwitchKit TCAP API enables user applications to easily integrate with
IntelliNet's user part APIs such as GSM-MAP, CAMEL, WIN, ANSI-41, AIN, and
INAP.
412
SwitchKit TCAP Interface

The SwitchKit TCAP API provides interface functions that take ASN.1 encoded
information from IntelliNet user part APIs for populating TCAP operation
parameters. TCAP operation parameters received using SwitchKit TCAP API
can be decoded using user part APIs.
Diagram of SKIM and SKTAL Architecture
SKIM and SKTAL API
The SwitchKit SKIM and SKTAL APIs interface with the SwitchKit library. The SKIM
APIs utilize services of the SKTAL layer to communication with the LLC and the MSP
1010.
SKIM APIs
413
MSP
The next table describes the SKIM API classes available to applications.
Name
Description
SKIM_Api::Terminate()
Terminates the SKIM API object and performs
cleanup functions. This method terminates
SKTAL and deregisters a TCAP SSN with the
MSP 1010. All pending dialogs associated with
SKIM_Api object are cleared by sending a prearranged end message to the MSP 1010.
SKIM_Api::Initialize()
SKIM_Api::Send
SKIM_Api::SSNInService
SKIM_Api::SSNOutOfService
SKIM_Api::SendReject
SKIM_Api::CancelOperation
SKIM_Api::SendPreArrangedEnd
SKIM_Api::SetTransHandler
SKIM_Api::ClearTransHandler
SKIM_Api::EnableTracing
SKIM_Api::DisableTracing
Initializes a SKIM API object. This method also
initializes SKTAL and registers a TCAP SSN
with the MSP 1010.
Sends TCAP transaction message along with a
list of operations. A given transaction message
can contain zero or more operations (TCAP
Components).
Sends N-State request to bring the local
subsystem network (SSN) in service.
Sends N-State request to take the local SSN
out of service.
Allows the user to send TCAP Reject message
for a given invoke ID and call reference ID.
This method also terminates the transaction
by sending TCAP End.
Allows the user to cancel a previously invoked
operation for a given call reference ID and
invoke ID.
Sends a pre-arranged end message for a given
call reference ID.
Sets a transaction handler for a given call
reference ID.
Clears a transaction handler for a given call
reference ID.
Enables SKIM library tracing for a given trace
type.
Disables SKIM library tracing for a given trace
type.
SKTAL APIs
The following are some of the SKTAL API messages available to the application:
Name
414
Despcription
SwitchKit TCAP Interface
sktal_initializeTCAP
sktal_terminateTCAP
sktal_registerTCAPSSNHandler
sktal_unregisterTCAPSSNHandler
sktal_allocateTCAPDialogID
sktal_setTCAPDialogHandler
sktal_clearTCAPDialogHandler
sktal_sendTCAPDialog
sktal_recvTCAPDialog
sktal_sendTCAPComponent
sktal_recv_TCAPComponent
A one-time call for global initialization of the
TCAP Abstraction layer.
A one-time call for global termination of the
TCAP Abstraction layer.
Registers the application with a given
node/stack/subsystem. A generic handler will
be added to the handler stack that will filter
messages for the given subsystem. When a
new TCAP transaction is seen, or when
sk_TCAP_AllocateDialogueID is called, the
NewDialogueHandler function argument will
be invoked. This function is expected to
register a per dialog handler (via
sktal_setTCAPSSNHandler) for the new dialog.
All incoming messages within that dialog
sequence will be passed to that handler.
Removes (and terminates) the subsystem
identified during registration. All ongoing
transactions are terminated and the
subsystem is marked out-of-service.
Allocates the TCAP dialog ID.
Specifies a function to be invoked for
incoming messages within a given transaction
(identified by the dialog ID). The incoming
event and the dialog ID invoke the handler;
the handler should examine the event and
invoke either sktal_recvTCAPDialogue or
sktal_recvTCAPComponent.
The user removes the transaction handler
once the transaction has been completed (by
receiving) TC-U-ABORT, TC-P-ABORT, TCEND, or TC-UNI, or sending TC-U-ABORT, TCEND, or TC-UNI). It is imperative to not take
this step until the last message has been
sent.
Sends a TCAP dialog message.
Receives a TCAP dialog info from a
SKTAL_EVENT.
Sends a TCAP component message.
Receives TCAP component information from a
SKTAL_EVENT.
Diagram
415
MSP
The next diagram shows how SKIM and SKTAL APIs interface with the SwitchKit
library.
416
SwitchKit TCAP Interface
417
MSP
SKIM and SKTAL API Call Flow
This section provides an example call flow with a description of the steps in the call
flow.
Diagram
The next diagram shows messaging of a call from intialization to termination. See
the description of the steps in the next
diagram.
418
SwitchKit TCAP Interface
Description of Initialization
1. Create a connection with LLC using SwitchKit API sktsCreateConnection ().
2. Initialize the SKIM_Api object.
3. SKIM initializes the SKTAL API layer.
419
MSP
4. SKIM registers a TCAP SSN with SKTAL layer.
5. SKTAL registers a TCAP message handler with SwitchKit.
6. SKTAL registers a TCAP SSN with SwitchKit. This is done for receiving
messages for a given TCAP SSN.
7. SKTAL registers SCCP User Interface component with SwitchKit. This is done
to receive SCCP management messages.
Description of Sending Begin + Invoke
1. SKIM application sends a TCAP transaction with a Begin dialogue and Invoke
Component.
2. SKIM allocates a TCAP doalogue ID for the new transaction.
3. SKIM registers a dialog handler for receiving incoming messages for the new
TCAP dialogue.
4. SKIM sends the TCAP invoke component to the SKTAL layer.
5. SKTAL sends the TCAP invoke component to the EXS using SwitchKit API.
6. SKIM sends the TCAP Begin dialogue to the SKTAL layer.
7. SKTAL sends the TCAP Begin dialogue to the EXS using SwitchKit API.
Description of Receiving Begin + Invoke
1. SwitchKit library invokes SKTAL TCAP message handler to give TCAP Begin
message to SKTAL.
2. SKTAL receives TCAP Begin dialogue message and invokes SKIM new dialogue
handler.
3. SKIM registers a per dialogue message handler as part of new dialog handler.
4. SKTAL invokes the SKIM dialogue message handler to pass TCAP Begin dialog
to SKIM.
5. SwitchKit library invokes SKTAL TCAP message handler to give TCAP Invoke
message to SKTAL.
6. SKTAL invokes the SKIM dialogue message handler to pass TCAP invoke
component to SKIM.
7. SKIM invokes application transaction handler to pass TCAP Begin and Invoke
to the application.
Description of Termination
1. Application calls SKIM Terminate API to terminate the SKIM API object.
2. SKIM deregisters TCAP SSN with SKTAL.
3. SKTAL deregisters TCAP SNN with SwitchKit.
4. SKTAL deregisters SCCP User Interface component with SwitchKit.
5. SKTAL removes TCAP message handler
420
SwitchKit TCAP Interface
6. SKIM terminates the SKTAL API layer.
7. Application destroys the connection with LLC.
TCAP Concepts
Overview
TCAP protocol functionality is divided into two main functional blocks: Component
Sub-layer and Transaction Sub-layer. Services provided by these two functional
blocks are described in the following sections.
Component Sub-layer Services
A component is the means by which TCAP conveys a request to perform an operation
or reply. An operation is an action performed by the remote end and may have
associated parameters. An Invoke ID identifies the invocation of an operation,
allowing several invocations of the same or different operations to be active
simultaneously. Only one reply may be sent to an operation, indicating success or
failure of the operation.
Components are passed individually between a TC-user (or application) and the
component sub-layer. The originating TC-user may send several components to the
component sub-layer before the message is transmitted to the destination TC-user.
When several components are received in a single message, each one is delivered
individually to the destination TC-user. Components in a message are delivered to
the remote TC-user in the same order they are provided at the originating interface.
The importance of the order is established by prior agreement between the TC-users.
Component Correlation
The component sub-layer provides two facilities:
1. Association of operations and replies
2. Abnormal situations handling
Association of Operations and Replies
The value of the Invoke ID, which identifies an operation invocation without
ambiguity, is returned in a response to that operation invocation. A TC-user may
have a number of operations active simultaneously; the maximum number depends
on the unique Invoke IDs available to a TC-user. If the response to this operation
invocation is another operation invocation from the responding end, the original
Invoke ID is returned as a Linked ID indicating that this responding operation
invocation is linked to the original operation. Four classes of operations are
considered:

Class 1 Both success and failure are reported

Class 3 Only success is reported


Class 2 Only failure is reported
Class 4 Neither success, nor failure is reported
421
MSP
Where necessary, the TC-user provides segmentation of a successful response. In
addition, any number of linked operations may be sent prior to the reply. The reply
may be:

Return result indicating success

Reject indicating inability to perform the operation

Return error indicating operation failure
The application protocol designer decides what constitutes success or failure in
performing the operation. Any component, except a reject component, may be
rejected. Rejection of a result causes termination of the corresponding operation;
rejection of a linked operation does not affect the linked-to operation. Rejection of a
result segment (that is, rejection of a Return Result — Not Last component) implies
the rejection of all subsequent segments and the entire result. A TC-user may cancel
an invoked operation; any reply received for this invocation will be rejected.
Abnormal Situations Handling
The Component sub-layer covers a number of abnormal situations in relation to a
component:



Component reject: When the component sub-layer receives a malformed
component, or a component that violates the rules of exchange, it informs the
TC-user(s)
Operation expiration: When the component sub-layer detects that a Class 1,
2, or 3 operation has not received a final reply after a certain amount of time
(which is specified by the application and depends on the operation), it
releases the corresponding Invoke ID and informs the TC-user. Note that this
situation is abnormal only in the case of a Class 1 operation. Application of
this error to Class 4 operations is a local matter.
Invocation cancel: A TC-user may decide to release a given Invoke ID and
ignore any responses using this identifier
Error Handling
In a situation where the component sub-layer is prevented from providing the
expected services, it notifies the TC-user and may terminate pending operations. In
addition, a TC-user may decide to abort a dialogue, which ends any pending
operations.
Transaction Sub-Layer Services
The Transaction (TR) sub-layer provides capabilities for the exchange of components
and dialogue between TR-users. The TR sub-layer also provides the capability to
send transaction messages between peer TR sub-layer entities by means of the lower
layer network services.
Dialogue
When successive components are exchanged between two TC-users in order to
perform an application, this is called a dialogue. The component sub-layer provides
422
SwitchKit TCAP Interface
dialogue facilities, allowing several dialogues to run concurrently between two TCusers. In addition, dialogue handling allows for the transfer and negotiation of the
application context and the transparent transfer of user information (that is, data
that are not components) between two TC-users. The component sub-layer provides
two dialogue facilities: Unstructured and structured.
Unstructured dialogue infers that TC-users can send components that do not require
replies without forming an explicit association. Implicit association always exists
between communicating TC-users. An unstructured dialogue is supported by the unidirectional message within the protocol. Use of the unstructured dialogue facility is
indicated when one TC-user sends a uni-directional message to its peers. When a
TC-user receives a uni-directional message, if a protocol error is reported, it is
returned in a uni-directional message.
Structured dialogue infers that TC-users indicate the beginning or the formation of a
dialogue, the continuation, and the end of a dialogue. Structured dialogue allows two
TC-users to run several dialogues concurrently, each identified by a particular
Dialogue ID. Each Dialogue ID has a separate Invoke ID name space, allowing
duplication of Invoke IDs in different dialogues. Sequenced delivery of messages is
provided by means of application protocols outside the scope of TCAP, or by use of
the appropriate SCCP class of service. When using the structured dialogue service,
the TC-user indicates one of four possibilities upon sending a component to a peer
TC-user:
1. Dialogue begin
2. Dialogue confirmation
3. Dialogue continue - Full-duplex exchange of components is possible
4. Dialogue end - The sending TC-user will not send more components, nor will
it accept any more components from the remote TC-user
As an option, in the context of options 1 and 2, an exchange of application context
information and user information is possible. When this option is chosen, user
information can also be sent during options 3 and 4.
SKIM Parameter Classes
SKIM_Trans Class
The SKIM_Trans class provides an interface to the SKIM user for populating and
retrieving TCAP dialogue and components (operations). The SKIM user can populate
or retrieve a single TCAP dialogue and list of associated TCAP components
(operations) using a single SKIM_Trans object instance. SKIM_Trans object supports
the public methods that are explained in the following sections.
Important! Users are expected to know what methods from the SKIM_Trans public
interface need to be invoked for a given transaction type. If you invoke a set
method for an invalid transaction type, set method returns without changing
underlying interface data.
Summary of Methods
The following lists the methods available with the SKIM_Trans class.
Class SKIM_Trans
423
MSP
{
public:
SKIM_Trans();
void SetTransType(SKIM_OCTET type);
void GetTransType(SKIM_OCTET &type);
SKIM_UINT GetCallReferenceId();
void SetCallReferenceId(SKIM_UINT id);
void AddOperation(SKIM_Operation &op);
int RemoveOperation(SKIM_Operation &op);
int GetNumOfOperation();
void SetSourceAddress(SKIM_CallingPartyAddr &addr);
void GetSourceAddress(SKIM_CallingPartyAddr &addr);
void SetDestAddress(SKIM_CalledPartyAddr &addr);
void GetDestAddress(SKIM_CalledPartyAddr &addr);
void GetAbortReason(SKIM_OCTET &reason);
void SetAbortReason(SKIM_OCTET reason);
void GetAbortInfo(SKIM_OCTET *buf, int &len);
void SetAbortInfo(SKIM_OCTET *buf, int len);
void
SetQualityOfService(const SKIM_OCTET flags,
void
const SKIM_OCTET priority = 0);
GetQualityOfService(SKIM_OCTET& flags,
SKIM_OCTET& priority);
void SetPreArrangedEnd();
SKIM_OCTET GetReportCause () const;
void GetApplicationContext(SKIM_OCTET* buf, int& len) const;
void SetApplicationContext(const SKIM_OCTET* buf, const int len);
void SetUserInfo(const SKIM_OCTET* buf, const int len);
};
void GetUserInfo(SKIM_OCTET* buf, int& len) const;
SKIM_Trans Class Methods
This section provides details about the methods available for the SKIM_Trans class.
SKIM_Trans()
Description
SKIM_Trans is the default constructor.
Syntax
424
SwitchKit TCAP Interface
SKIM_Trans();
Input Parameters, Input/Output Parameters, & Output Parameters
None
SetTransType()
Description
Sets SKIM transaction type.
Syntax
void SetTransType(SKIM_OCTET type);
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Values
Possible values for ITU TCAP:

SKIM_TC_UNI

SKIM_TC_CONTINUE




SKIM_TC_BEGIN
SKIM_TC_END
SKIM_TC_P_ABORT
SKIM_TC_U_ABORT
Possible values for ANSI TCAP:

SKIM_TC_UNI

SKIM_TC_CONTINUE (Same as Conversation With Permission)





SKIM_TC_BEGIN (Same as Query with Permission)
SKIM_TC_END
SKIM_TC_ABORT
SKIM_TC_QUERY_WO_PERM
SKIM_TC_CONV_WO_PERM
GetTransType()
Description
Gets SKIM transaction type.
Syntax
void GetTransType(SKIM_OCTET &type);
Input Parameters
425
MSP
type
Return Values
Possible values for ITU TCAP:
Possible values for ITU TCAP:

SKIM_TC_UNI, SKIM_TC_BEGIN

SKIM_TC_END




SKIM_TC_CONTINUE
SKIM_TC_P_ABORT
SKIM_TC_U_ABORT
SKIM_TC_NOTICE:
This message is received in case of network problem at SCCP layer while sending a
TCAP transaction message.
Possible values for ANSI TCAP:

SKIM_TC_UNI

SKIM_TC_CONTINUE (Same as Conversation With Permission)






SKIM_TC_BEGIN (Same as Qurey With Permission)
SKIM_TC_END
SKIM_TC_ABORT
SKIM_TC_QUERY_WO_PERM
SKIM_TC_CONV_WO_PERM
SKIM_TC_NOTICE
GetCallReferenceId()
Description
This method returns the call reference ID. A call reference ID has one to one
mapping with a TCAP dialogue ID.
Syntax
SKIM_UINT GetCallReferenceId();
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
Call reference ID.
SetCallReferenceId()
426
SwitchKit TCAP Interface
Description
Sets the call reference ID. The call reference ID is not set when initiating a
transaction.
Syntax
void SetCallReferenceId(SKIM_UINT id);
Input Parameters
id: Call Reference ID
Input/Output Parameters, Output Parameters
None
AddOperation()
Description
Adds an operation to the given transaction object.
Syntax
void AddOperation(SKIM_Operation &op);
Input Parameters
op: SKIM_Operation object
Input/Output Parameters, Output Parameters
None
RemoveOperation()
Description
Removes an operation from a transaction object.
Syntax
void RemoveOperation(SKIM_Operation &op);
Input Parameters, Input/Output Parameters
None
Output Parameters
op: SKIM_Operation object
Return Value


SKIM_SUCCESS:
An operation removal is successful.
SKIM_ENOMSG:
No operation is available.
427
MSP
GetNumOfOperation()
Description
Gets the number of operations associated with a SKIM_Trans object at any given
time.
Syntax
int GetNumOfOperation();
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
Number of operations
SetSourceAddress()
Description
Sets the SCCP source address for a given transaction object. See Also:
SKIM_CallingPartyAddress API.
Syntax
void SetSourceAddress(SKIM_CallingPartyAddr &addr);
Input Parameters
addr: SCCP Calling Party Address object.
Input/Output Parameters, Output Parameters
None
GetSourceAddress()
Description
Gets the SCCP source address for a given transaction object. See Also:
SKIM_CallingPartyAddress API.
Syntax
void GetSourceAddress(SKIM_CallingPartyAddr &addr);
Input Parameters, Input/Output Parameters
None
Output Parameters
addr: SCCP Calling Party Address object.
428
SwitchKit TCAP Interface
SetDestAddress()
Description
Sets the SCCP destination address for a given transaction object. See also:
SKIM_CalledPartyAddress API.
Syntax
void SetDestAddress(SKIM_CalledPartyAddr &addr);
Input Parameters
addr: SCCP Called Party Address object.
Input/Output Parameters, Output Parameters
None
GetDestAddress()
Description
Gets the SCCP destination address for a given transaction object. See also:
SKIM_CalledPartyAddress API.
Syntax
void GetDestAddress(SKIM_CalledPartyAddr &addr);
Input Parameters, Input/Output Parameters
None
Output Parameters
addr: SCCP Called Party Address object.
GetAbortReason() (For ITU)
Description
Gets the abort reason for SKIM_TC_U_ABORT/SKIM_TC_P_ABORT ( ITU).
Syntax
void GetAbortReason(SKIM_OCTET &reason);
Input Parameters
reason: Abort reason. Possible values of abort reason are defined in Appendix A.
Input/Output Parameters, Output Parameters
None
SetAbortReason (For ITU)
429
MSP
Description
Sets the abort reason for SKIM_TC_U_ABORT.
Note: The MSP 1010 sends SKIM_TC_P_ABORT automatically.
Syntax
void SetAbortReason(SKIM_OCTET reason);
Input Parameters
reason: Abort reason. Possible values of abort reason are defined in Appendix A.
Input/Output Parameters and Output Parameters
None
GetAbortInfo() (For ANSI)
Description
Gets the abort information for SKIM_TC_ABORT (ANSI transaction type.)
Syntax
void GetAbortInfo(SKIM_OCTET *buf, int &len);
Input Parameters
buf : Abort rinformation.
len: Abort information length.
Input/Output Parameters, Output Parameters
None
SetAbortInfo (For ANSI)
Description
Sets the abort information for SKIM_TC_ABORT (ANSI transaction type.)
Syntax
void SetAbortInfo(SKIM_OCTET *buf, int &len);
Input Parameters
info: Abort information.
length: Abort information length.
Input/Output Parameters and Output Parameters
None
SetQualityOfService()
430
SwitchKit TCAP Interface
Description
Sets the quality of service.
Syntax
void SetQualityOfService(const SKIM_OCTET flags,
const SKIM_OCTET priority = 0);
Input Parameters
flags: Flags can be combination of the following types (for ITU):

0 : specifies SCCP Class 0 with no return option

SKIM_QOSI_SEQ_CTRL: specifies SCCP) Class 1 with no return option.


SKIM_QOSI_RET_OPT: specifies SCCP Class 0 with return option
SKIM_QOSI_SEQ_CTRL | SKIM_QOSI_RET_OPT: specifies SCCP Class 1 with
return option set
flags: Flags can be combination of the following types (for ANSI)

8: specifies SCCP Class 0 with no return option.

SKIM_QOSI_SEQ_CTRL | |SKIM_QOSI_PRIORITY: specifies SCCP Class 1 with
no return option


SKIM_QOSI_RET_OPT | |SKIM_QOSI_PRIORITY: specifies SCCP Class 0 with
return option set.
SKIM_QOSI_SEQ_CTRL | SKIM_QOSI_RET_OPT | |SKIM_QOSI_PRIORITY:
specifies SCCP Class 1 with return option set.
Input/Output Parameters, Output Parameters
None
GetQualityOfService()
Description
Gets the quality of service.
Syntax
void GetQualityOfService(SKIM_OCTET& flags, SKIM_OCTET& priority);
Input Parameters, Input/Output Parameters
None
Output Parameters
flags: Flags can be combination of the following types (for ITU):

0 : specifies SCCP Class 0 with no return option

SKIM_QOSI_SEQ_CTRL: specifies SCCP) Class 1 with no return option.

SKIM_QOSI_RET_OPT: specifies SCCP Class 0 with return option
431
MSP


SKIM_QOSI_SEQ_CTRL | SKIM_QOSI_RET_OPT: specifies SCCP Class 1 with
return option set
flags: Flags can be combination of the following types (for ANSI)
8: specifies SCCP Class 0 with no return option.




SKIM_QOSI_RET_OPT | |SKIM_QOSI_PRIORITY: specifies SCCP Class 0 with
return option set.
SKIM_QOSI_SEQ_CTRL | |SKIM_QOSI_PRIORITY: specifies SCCP Class 1 with
no return option
SKIM_QOSI_SEQ_CTRL | SKIM_QOSI_RET_OPT | |SKIM_QOSI_PRIORITY:
specifies SCCP Class 1 with return option set.
priority: message priority.
SetPreArrangedEnd()
Description
Sets the pre-arranged end for the SKIM_TC_END transaction type. By default the
end type is set to basic.
Syntax
void SetPreArrangedEnd();
Input Parameters, Input/Output Parameters & Output Parameters
None
GetReportCause()
Description
Gets the reported cause for SKIM_TC_NOTICE transaction type.
Syntax
SKIM_OCTET GetReportCause() const;
#if defined(CCITT) || defined(PRC)
Input Parameters, Input/Output Parameters & Output Parameters
None
Return Value:
Report cause value.

SCCP_RET_NO_TRANS_ADDR_NAT

SCCP_RET_SUBSYS_CONG


432
SCCP_RET_NO_TRANS_THIS_ADDR
SCCP_RET_SUBSYS_FAIL
SwitchKit TCAP Interface

SCCP_RET_UNEQUIPPED_USER

SCCP_RET_NETWORK_CONG













SCCP_RET_NETWORK_FAIL
SCCP_RET_UNQUAL
SCCP_RET_ERR_IN_TRANSPORT
SCCP_RET_ERR_IN_LOCAL_PROCESS
SCCP_RET_ERR_DEST_CANNOT_PERF_REASSEMBLY
SCCP_RET_ERR_SCCP_FAILURE (ITU Only)
SCCP_RET_ERR_HOP_COUNT_VIOLATION (ANSI only)
SCCP_RET_ERR_INV_ISNI_ROUT_REQ (ANSI only)
SCCP_RET_ERR_UNAUTH_MSG (ANSI only)
SCCP_RET_ERR_MSG_INCOMPATIBILITY (ANSI only)
SCCP_RET_ERR_CANNOT_PERFORM_ISNI_ROUTING (ANSI only)
SCCP_RET_ERR_REDUNDANT_ISNI_ROUTING_INFO (ANSI only)
SCCP_RET_ERR_UNABLE_TO_IDENTIFY_ISNI_INFO (ANSI only)
GetApplicationContext() (ITU only)
Description
Allows the user to get the application context for a transaction.
Syntax
void GetApplicationContext(SKIM_OCTET* buf, int& len) const;
Input Parameters, Input/Output Parameters
None
Output Parameters:
buf: Buffer to copy application context infornation.
len: Number of bytes copied in application context information.
SetApplicationContext() (ITU only)
Description
Allows the user to set the application context for a transaction.
Syntax
void SetApplicationContext(const SKIM_OCTET* buf, const int len);
Input Parameters
buf: Buffer to copy application context infornation.
433
MSP
len: Number of bytes copied in application context information.
Input/Output and Output Parameters:
None
SetUserInfo() (ITU only)
Description
Allows the user to set the user information for a transaction.
Syntax
void SetUserInfo(const SKIM_OCTET* buf, const int len);
Input Parameters
buf: Buffer containing user infornation.
len: Number of bytes in user information.
Input/Output and Output Parameters:
None
GetUserInfo() (ITU only)
Description
Allows the user to get the user information for a transaction.
Syntax
void GetUserInfo(SKIM_OCTET* buf, int& len) const;
Input Parameters, Input/Output Parameters
None
Output Parameters:
buf: Buffer containing user infornation.
len: Number of bytes in user information.
SKIM_Operation Class
Description
The SKIM_Operation object supports the public methods that are explained in the
following sections. A user is expected to know what methods from SKIM_Operation
public interface need to be invoked for a given operation type. If you invoke a set
method for an invalid operation type, the set method will simply return without
changing the underlying interface data.
Summary of Methods
434
SwitchKit TCAP Interface
The following lists the methods available with the SKIM_Operation class.
Class SKIM_Operation
{
public:
int SetType(SKIM_USHORT type);
SKIM_USHORT GetType();
int SetInvokeId(SKIM_OCTET invokeId);
SKIM_OCTET GetInvokeId();
int SetLinkedId(SKIM_OCTET id);
SKIM_OCTET GetLinkedId();
void SetClass(SKIM_USHORT cl);
SKIM_USHORT GetClass();
voidint SetInvokeTimeout(SKIM_UINT timeout);
voidint SetParameter(vector <byte> &param);
voidint GetParameter(vector <byte> &param);
bool IsLastOperation();
voidint SetOpCode(const SKIM_LONG code);
voidint GetOpCode(SKIM _LONG & code);
voidint SetOpCode(const bool isNational, const SKIM_OCTET family,
const SKIM_OCTET code);
voidint GetOpCode(bool& isNational, SKIM_OCTET& family,
SKIM_OCTET& code);
voidint SetErrorCode(SKIM_OCTET errorCode);
voidint GetErrorCode(SKIM_OCTET &errorCode);
voidint SetErrorCode(SKIM_BOOLEAN isNational, SKIM_OCTET errorCode);
voidint GetErrorCode(SKIM_BOOLEAN &isNational, SKIM_OCTET &errorCode);
voidint SetRejectCause(const SKIM_OCTET type, const SKIM_OCTET code);
voidint GetRejectCause(SKIM_OCTET& type, SKIM_OCTET& code);
};
Operation Types
You are expected to know what methods from the SKIM_Operation public interface
need to be invoked for a given operation type. If you invoke a set method for an
invalid operation type, set method will simply return without changing underlying
interface data.
Refer to the following table for applicable methods for operation types.
Method
Operation Types
GetType ()
All
SetType ()
All
435
MSP
SetInvokeId ()
All
SetLinkedId ()
SKIM_TC_INVOKE SKIM_TC_INVOKE_NLl
GetInvokeId ()
HasLinkedId ()
GetLinkedId ()
SetInvokeTimeout
()
Set Parameter ()
Get Parameter ()
IsLastOperation
()
SetOpCode ()
GetOpCode ()
SetClass ()
GetClass ()
SetErrorCode ()
GetErrorCode ()
SetRejectCause ()
GetRejectCause
()
All
SKIM_TC_INVOKE
SKIM_TC_INVOKE_NL
SKIM_TC_INVOKE
SKIM_TC_INVOKE_NL
SKIM_TC_INVOKE
SKIM_TC_INVOKE, SKIM_TC_INVOKE_NL,
SKIM_TC_RESULT_L, SKIM_TC_RESULT_NL,
SKIM_TC_U_ERROR, SKIM_TC_ERROR, and
SKIM_TC_REJECT
SKIM_TC_INVOKE, SKIM_TC_INVOKE_NL,
SKIM_TC_RESULT_L, SKIM_TC_RESULT_NL,
SKIM_TC_U_ERROR, SKIM_TC_ERROR SKIM_TC_REJECT
All
SKIM_TC_INVOKE, SKIM_TC_INVOKE_NL,
SKIM_TC_RESULT_L (ITU) SKIM_TC_RESULT_NL (ITU)
SKIM_TC_INVOKE, SKIM_TC_INVOKE_NL,
SKIM_TC_RESULT_L (ITU) SKIM_TC_RESULT_NL (ITU)
SKIM_TC_INVOKE (ITU)
SKIM_TC_INVOKE (ITU)
SKIM_TC_U_ERROR SKIM_TC_ERROR
SKIM_TC_U_ERROR SKIM_TC_ERROR
SKIM_TC_U_REJECT SKIM_TC_R_REJECT
SKIM_TC_L_REJECT SKIM_TC_REJECT
SKIM_TC_U_REJECT SKIM_TC_R_REJECT
SKIM_TC_L_REJECT SKIM_TC_REJECT
SKIM_Operation Class Methods
This section provides details about the methods available for the SKIM_Operation
class.
SetType()
Description
Sets the type of this operation
436
SwitchKit TCAP Interface
Syntax
int SetType(SKIM_USHORT type);
Input Parameters
type: the operation type is one of the following:

SKIM_TC_INVOKE (Same as Invoke Last for ANSI)

SKIM_TC_RESULT






SKIM_TC_INVOKE_NL
SKIM_TC_RESULT_L
SKIM_TC_ERROR
SKIM_TC_REJECT (For ANSI)
SKIM_TC_U_REJECT (For ITU)
SKIM_TC_CANCEL
Input/Output Parameters, Output Parameters
None
GetType()
Description
Returns the type of this operation.
Syntax
SKIM_USHORT GetType();
Input Parameters, Input/Output Parameters & Output Parameters:
None
Return Values
The type of this component is one of the following:

SKIM_TC_INVOKE

SKIM_TC_RESULT








SKIM_TC_INVOKE_NL (Same as Invoke Last for ANSI)
SKIM_TC_RESULT_L
SKIM_TC_ERROR
SKIM_TC_REJECT
SKIM_TC_U_REFJECT (For ITU)
SKIM_TC_R_REFJECT (For ITU)
SKIM_TC_L_REFJECT (For ITU)
SKIM_TC_CANCEL
437
MSP
SetInvokeId()
Description
Populates the invoke ID for this operation. Invoke IDs are common to all operation
types. For ANSI TCAP, use this API to set the correlation ID for
RESULT/ERROR/REJECT operations.
Syntax
void SetInvokeId(SKIM_OCTET invokeId);
Input Parameters
value: The invoke ID value. The valid range is 0-255.
Input/Output Parameters
None
Output Parameters
None
GetInvokeId()
Description
Returns the invoke ID of an operation. Invoke IDs are common to all operation
types. For ANSI TCAP, use this API to get the correlation ID for RESULT, ERROR, and
REJECT operations.
Syntax
SKIM_OCTET GetInvokeId();
Input Parameters, Input/Output Parameters & Output Parameters
None
Return Value
The invoke ID as an unsigned character.
SetLinkedId()
Description
Sets the linked ID (ITU) or correlation ID (ANSI) to the value supplied. This is valid
only when the operation type is SKIM_TC_INVOKE or SKIM_TC_INVOKE_NL. For any
other operation type this method simply returns and nothing is set. You do not need
to call this method if the linked ID is not relevant. It is assumed that no linked ID is
present unless this method is called.
Syntax
void SetLinkedId(SKIM_OCTET id);
Input Parameters, Input/Output Parameters, & Output Parameters
438
SwitchKit TCAP Interface
None
HasLinkedId()
Description
Returns SKIM_TRUE if the linked ID (ITU) or correlation ID (ANSI) is present in
Invoke operation. This is valid only when the operation type is SKIM_TC_INVOKE.
Syntax
SKIM_BOOLEAN HasLinkedId();
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
SKIM_TRUE: Linked ID present.
SKIM_FALSE: Linked ID not present.
GetLinkedId()
Description
Gets the linked ID (ITU) or correlation ID (ANSI) of an invoke, if supplied. This is
valid only when the operation type is SKIM_TC_INVOKE or SKIM_TC_INVOKE_NL.
Syntax
SKIM_OCTET GetLinkedId();
Return Value
The linked ID is returned as an unsigned character.
SetClass()
Description
Sets the operation class for TCAP components. The SetClass() method is used for
ITU TCAP only.
Syntax
void SetClass(const SKIM_USHORT val);
Input Parameters
val: A number from 1 to 4 indicating the operation class:

Class 1: Both success and failure are reported

Class 3: Only success is reported

Class 2: Only failure is reported
439
MSP

Class 4: Neither success, or failure is reported
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
None
GetClass()
Description
Retrieves the operation class for TCAP invokes. The GetClass method is used for ITU
TCAP only.
Syntax
SKIM_USHORT GetClass() const;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Values
A number from 1 to 4 indicating the operation class:

Class 1: Both success and failure are reported

Class 3: Only success is reported


Class 2: Only failure is reported
Class 4: Neither success, nor failure is reported
SetInvokeTimeout()
Description
Sets the timeout value for TCAP invokes. This is valid only when the operation type is
SKIM_TC_INVOKE (used for ITU only).
Syntax
void SetInvokeTimeout(SKIM_UINT timeout);
Input Parameters
val: the timeout value in seconds. Range is 1-500.
Input/Output Parameters and Output Parameters
None
SetParameter()
Description
440
SwitchKit TCAP Interface
Copies a user-defined parameter into the given operation. If an operation does not
have a parameter, you do not need to call this method. The parameter is assumed
to be not present unless this method is called with a non-zero vector.
Syntax
void SetParameter(vector <byte> &param);
Input Parameters,
buf: A vector containing the parameter to copy into this operation.
Input/Output Parameters and Output Parameters:
None
GetParameter()
Description
Copies the parameter in a given operation into a user-supplied vector. Returning a
vector.size () of zero indicates that no parameter is present.
Syntax
void GetParameter(vector <byte> &param);
Input Parameters and Input/Output Parameters
None
Output Parameters:
buf: A vector for the parameter to copy.
IsLastOperation()
Description
Specifies whether the given operation is the last incoming operation associated with
a TCAP transaction.
Syntax
bool IsLastOperation();
Input Parameters, Input/Output Parameters & Output Parameters
None
Return Value
SKIM_TRUE: If given operation is the last operation.
SKIM_False: If given operation is not the last operation.
SetOpCode() (For ITU)
441
MSP
Description
Sets the operation field of a given operation. This is valid only when operation type
is:

SKIM_TC_INVOKE

SKIM_TC_RESULT_NL

SKIM_TC_RESULT_L
Syntax
void SetOpCode(const SKIM_LONG code);
Input Parameters, Input/Output Parameters & Output Parameters
None
GetOpCode()(For ITU)
Description
Gets the operation field of a given operation. This is valid only when the operation
type is:

SKIM_TC_INVOKE

SKIM_TC_RESULT_NL

SKIM_TC_RESULT_L
Syntax
void GetOpCode(SKIM _LONG & code);
Input Parameters, Input/Output Parameters
None
Output Parameters
code: The operation code.
SetOpCode() (For ANSI)
Description
Sets the operation field of a given operation. This is valid only when operation type
is:

SKIM_TC_INVOKE

SKIM_TC_RESULT_NL

SKIM_TC_RESULT_L
Syntax
void SetOpCode(const bool isNational, const SKIM_OCTET family, const SKIM_OCTET
code);
442
SwitchKit TCAP Interface
Input Parameters,
IsNational: True if National, false if private
family: Operation family. Possible values are provided in Appendix A Table A-1, ANSI
TCAP Operation Family (A-2).
code: The operation code specifier.
Input/Output Parameters and Output Parameters:
None
GetOpCode()(For ANSI)
Description
Gets the operation field of a given operation.This is valid only when operation type
is:

SKIM_TC_INVOKE

SKIM_TC_RESULT_NL

SKIM_TC_RESULT_L
Syntax
GetOpCode(bool& isNational, SKIM_OCTET& family,
SKIM_OCTET& code);
Input Parameters and Input/Output Parameters
None
Output Parameters
IsNational: True if National, false if private
family: Operation family. Possible values are provided in Appendix A Table A-1, ANSI
TCAP Operation Family (A-2).
code: the operation code.
SetErrorCode() (For ITU)
Description
Sets the error code in an error operation.
Syntax
void SetErrorCode(SKIM_OCTET errorCode);
Input Parameters
code: the error code.
Input/Output Parameters and Output Parameters:
None
443
MSP
GetErrorCode() (For ITU)
Description
Gets the error code in an error operation.
Syntax
void GetErrorCode(SKIM_OCTET &errorCode);
Input Parameters and Input/Output Parameters
None
Output Parameters
code: the error code.
SetErrorCode() (For ANSI)
Description
Sets the error code in an error operation.
Syntax
void SetErrorCode(SKIM_BOOLEAN isNational, SKIM_OCTET errorCode);
Input Parameters
IsNational: True if National, false if private.
code: The error code. Possible values are provided in Appendix - TCAP Codes (A-1).
Input/Output Parameters and Output Parameters
None
GetErrorCode() (For ANSI)
Description
Gets the error code in an error operation.
Syntax
void GetErrorCode(SKIM_BOOLEAN &isNational, SKIM_OCTET &errorCode);
Input Parameters, Input/Output Parameters
None
Output Parameters
IsNational: True if National, false if private.
code: The error code. Possible value provided in Appendix - TCAP Codes (A-1).
444
SwitchKit TCAP Interface
SetRejectCause()
Description
Sets the problem code for a reject operation.
Syntax
void SetRejectCause(const SKIM_OCTET type, const SKIM_OCTET code);
Input Parameters
type: The problem family. As specified in Appendix A.
code: The problem code. As specified in Appendix A.
Input/Output Parameters and Output Parameters
None
GetRejectCause()
Description
Gets the problem code for a reject operation.
Syntax
void GetRejectCause(SKIM_OCTET& type, SKIM_OCTET& code);
Input Parameters and Input/Output Parameters
None
Output Parameters
type: The problem family
code: The problem code
SKIM_Notify Class
Description
This section describes the SKIM_Notify public methods. The SKIM_Notify class
provides a public interface for retrieving SKIM notification information.
Summary of Methods
The following lists the methods available with the SKIM_Notify class.
Class SKIM_Notify{
public:
int GetType();
int GetCallReferenceId(SKIM_UINT &id);
int GetCause();
445
MSP
SKIM_OCTET GetCauseType();
SKIM_OCTET GetSSN();
SKIM_UINT GetPC();
SKIM_GetInvokeID();
};
SKIM_Notify Class Methods
This section provides details about the methods available for the SKIM_Notify class.
GetType()
Description
Gets the notification type.
When the user receives a notification, the user should use appropriate get methods
based on notification object. The default value returned by all GetXX methods is 0.
Zero means that the parameter is not set for the notification.
For the SKIM_NOTIFY_NACK_IND, GetCauseType() provides a transaction type /
operation type for the NACK that is received.
The GetCallReferenceId() method is relevant for SKIM_NOTIFY_OP_TIMEOUT
notifications. This method returns the call reference ID of the transaction for which a
SKIM_NOTIFY_OP_TIMEOUT is received.
The SKIM_NOTIFY_OP_TIMEOUT corresponds to TC-L-CANCEL when an outgoing
Invoke operation timeout occurs in the TCAP stack.
For the SKIM_NOTIFY_SCCP_MGMT_IND notification, GetCause() provides the type
of SCCP N-State indication received. GetSSN() and GetPC() methods provide the
affected PC and SSN.
For the SKIM_NOTIFY_MTP3_MGMT_IND notification, GetCause() provides the type
of SCCP N-PCState indication received. GetPC() method provides the affected point
code.
Syntax
int GetType();
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value:
Notification type. Possible values are:
Value
SKIM_NOTIFY_SCCP_MGMT_IND
446
Description
SCCP management
indication.
SwitchKit TCAP Interface
SKIM_NOTIFY_MTP3_MGMT_IND
SKIM_NOTIFY_OP_TIMEOUT
SKIM_NOTIFY_INTERNAL_ERROR
SKIM_NOTIFY_NACK_IND
N-PC State
management
indication.
Operation timeout.
For ITU only.
SKIM internal error.
PPL NACK Indication
form EXS.
GetCallReferenceId()
Description
Gets the call reference ID for a given notification.
Syntax
SKIM_UINT GetCallReferenceId;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
id: Call reference ID
GetCause()
Description
Returns the notification cause corresponding to a given notification type. For the
SKIM_NOTIFY_NACK_IND notification type, GetCause () returns a PPL event NACK
cause value (ack status) received from the MSP 1010.
The SKIM_NOTIFY_INTERNAL_ERROR notification is received for the following
causes:
SKIM_TRANS_RECORD_ERROR -Transaction record error
SKIM_INVALID_COMP_ERROR - Invalid component received
SKIM_COMP_RECV_ERROR - Receive error/failed
SKIM_DUP_INVID_ERROR - Duplicate invoke ID
SKIM_UNK_INVID_ERROR - Unknown invoke ID
SKIM_INV_MSG_TYPE_ERROR - Invalid message type
SKIM_RES_LIMT_ERROR - Resource limitation.
Syntax
int GetCause();
Input Parameters, Input/Output Parameters, & Output Parameters
447
MSP
None
Return Value
Notification cause value.
GetCauseType()
Description
Returns cause type values associated with the SKIM_NOTIFY_NACK_IND notification.
For the SKIM_NOTIFY_NACK_IND notification, the cause type value indicates the
transaction type or operation type for which the NACK is received from the MSP
1010.
Syntax
SKIM_OCTET GetCauseType();
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
Cause Type.
GetSSN()
Description
Gets affected subsystem number associated with SKIM_NOTIFY_SCCP_MGMT_IND
notification
Syntax
SKIM_OCTET GetSSN();
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
Subsystem number.
GetPC()
Description
Gets affected point code associated with SKIM_NOTIFY_SCCP_MGMT_IND and
SKIM_NOTIFY_MTP3_MGMT_IND notification.
Syntax
SKIM_UINT GetPC();
Input Parameters, Input/Output Parameters & Output Parameters
448
SwitchKit TCAP Interface
None
Return Value
Point code value.
GetInvokeId()
Description
Returns the invoke ID of an operation. Invoke IDs are common to all operation
types.
Syntax
SKIM_OCTET GetInvokeId();
Input Parameters, Input/Output Parameters & Output Parameters
None
Return Value
The invoke ID as an unsigned char.
SKIM_CallingPartyAddress / SKIM_CalledPartyAddress Class
Description
SKIM_ CallingPartyAddress / SKIM_CalledPartyAddress object supports the public
methods that are explained in the following sections.
Summary of Methods
The following lists the methods available with the SKIM_ CallingPartyAddress /
SKIM_CalledPartyAddress class.
Class SKIM_ CallingPartyAddress / SKIM_CalledPartyAddress
{
public:
Bool HasPointCode() const
SKIM_UINT GetPointCode() const
void
SetPointCode(const SKIM_UINT pc)
{
}
hasPC = true;
pointCode = pc;
Bool HasSSN() const
SKIM _OCTET GetSSN() const
449
MSP
Void SetSSN(const SKIM_OCTET sn)
Bool IsRoutedByPCSSN() const
Void SetRouteByPCSSN(const bool which)
Bool IsInternationalRouting() const
void
SetInternationalRouting(const bool which)
bool
int
int
HasGlobalTitle() const
SetGlobalTitle(const SKIM_OCTET type,
const SKIM_OCTET* gttInfo, const SKIM_USHORT gttLength)
GetGlobalTitle(SKIM_OCTET& type,
};
SKIM_OCTET* gttInfo, SKIM_USHORT& gttLength) const
SKIM_CallingPartyAddress/SKIM_CalledParty Address Class Methods
This section provides details about the methods available for the SKIM_
CallingPartyAddress / SKIM_CalledPartyAddress class.
HasPointCode()
Description
Determines whether an SCCP_Address object has a point code.
Syntax
Bool HasPointCode() const
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
A Boolean value, true if the point code was set, false otherwise.
GetPointCode()
Description
Retrieves the point code value from an SCCP_Address object.
Syntax
SKIM_UINT GetPointCode() const
450
SwitchKit TCAP Interface
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
Returns the point code value as an unsigned integer.
SetPointCode()
Description
Sets the point code value for an SCCP_Address object.
Syntax
void
SetPointCode(const SKIM_UINT pc)
{
hasPC = true;
pointCode = pc;
Input Parameters
pc: The value to store for the point code.
Input/Output Parameters and Output Parameters
None
Return Value
None
HasSSN ()
Description
Determines whether an SCCP_Address object has a subsystem number (SSN).
Syntax
Bool HasSSN() const
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
A boolean value, true if the SSN was set, false otherwise.
GetSSN ()
Description
451
MSP
Retrieves the subsystem number value from an SCCP_Address object.
Syntax
void
Input Parameters, Input/Output Parameters, & Output Parameters
None
SKIM _OCTET GetSSN() const
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
Returns the subsystem number value as an unsigned char.
SetSSN ()
Description
Sets the subsystem number value for an SCCP_Address object.
Syntax
Void SetSSN(const SKIM_OCTET sn)
Input Parameters:
ssn: The value to store for subsystem number (SSN).
Input/Output Parameters and Output Parameters
Return Value
None
IsRoutedByPCSSN()
Description
Determines whether the "routed by" flag value for an SCCP_Address object has been
set. Setting this to false implies routing by global title translation (GTT). To send this
message properly with the false setting, you must use the SetGlobalTitle() method.
Syntax
Bool IsRoutedByPCSSN() const
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
True if the value has been set, otherwise False.
452
SwitchKit TCAP Interface
SetRouteByPCSSN()
Description
Sets the "routed by" flag value for an SCCP_Address object. Setting this to false
implies routing by global title translation (GTT).
Syntax
Void SetRouteByPCSSN(const bool which)
Input Parameters
which: the value to store for the "routed by" flag.
Input/Output Parameters and Output Parameters
None
Return Value
None
IsInternationalRouting()
Description
Determines whether an SCCP_Address object had the international routing flag set.
Syntax
Bool IsInternationalRouting() const
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
A boolean value, true if the flag was set, false otherwise.
SetInternationalRouting ()
Description
Sets the international routing flag value for an SCCP_Address object.
Syntax
void SetInternationalRouting(const bool which)
// Global title
Input Parameters
which: The value to store for the international routing flag.
Input/Output Parameters and Output Parameters
None
453
MSP
HasGlobalTitle()
Description
Determines whether an SCCP_Address object has global title information.
Syntax
bool
HasGlobalTitle() const
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
A boolean value, true if the global title was set, false otherwise.
SetGlobalTitle()
Description
Sets global title information for this address.
Syntax
int
SetGlobalTitle(const SKIM_OCTET type,
const SKIM_OCTET* gttInfo, const SKIM_USHORT gttLength)
Input Parameters
which: The value to store for the international routing flag
Input/Output Parameters and Output Parameters
None
type: The address indicator flag for this global title translation (GTT) type.
Possible values for ITU SCCP are:
Value
Description
SCCP_CPA_GTTI_TRANS
Global Title contains translation type.
SCCP_CPA_GTTI_NATURE
SCCP_CPA_GTTI_TNE
SCCP_CPA_GTTI_ALL
Global title contains nature of address.
Global Title contains translation type, numbering plan
and encoding cheme.
Global title contains translation type, nayure of
address, numbering plan, and encoding scheme
Possible values for ANSI SCCP are:
454
SwitchKit TCAP Interface
Value
Description
SCCP_CPA_GTTI_TNE
Global Title contains translation type, numbering plan
and encoding scheme.
SCCP_CPA_GTTI_TRANS
Global Title contains translation type.
gttInfo: The global title information. Global title information should be encoded in
accordance with GTT type, as specified in ITU / ANSI SCCP specification.
gttLength: the size of the GTT information.
Return Value
None
GetGlobalTitle
Description
Gets the global title information for this address.
Syntax
int
GetGlobalTitle(SKIM_OCTET& type,
SKIM_OCTET* gttInfo, SKIM_USHORT& gttLength) const
Input Parameters and Input/Output Parameters
None
Output Parameters
type: The address indicator flag for this GTT type.
Possible values for ITU SCCP are:
Value
Description
SCCP_CPA_GTTI_TRANS
Global Title contains translation type.
SCCP_CPA_GTTI_NATURE
SCCP_CPA_GTTI_TNE
SCCP_CPA_GTTI_ALL
Global title contains nature of address.
Global Title contains translation type, numbering
plan, and encoding scheme.
Global title contains translation type, nayure of
address, numbering plan and encoding scheme.
Possible values for ANSI SCCP are:
Value
Description
SCCP_CPA_GTTI_TNE
Global Title contains translation type, numbering plan
and encoding scheme.
SCCP_CPA_GTTI_TRANS
Global Title contains translation type.
455
MSP
and encoding scheme.
gttInfo: The global title translation information. Global title information should be
encoded in accordance with GT type, as specified in ITU / ANSI SCCP specification.
gttLength: The size of the GTT information.
Return Value
None
SKIM Sample Application
Step One: Creating a connection with LLC using SwitchKit
The API function described in this section allows you to create a connection with LLC
using SwitchKit.
Application Code
{
int ret;
/* create the connection */
ret = skts_createConnection(CONN_ID, CONN_LABEL, CONN_NAME,
SKIM_FALSE,
PRI_IP, PRI_PORT,
if (ret == 0)
{
}
}
BACK_IP, BACK_PORT);
fprintf(stderr, "Error connecting to switch\n");
return (SKIM_EINVALIDARGS);
return (SKIM_SUCCESS);
Step Two: Creating an Instance of SKIM API Class
The API function described in this section allows you to create an instance of a SKIM
API class.
Application Code
SKIM_Api api_classptr;
// LOCAL_NODE - value created during configuration
// STACK_ID - Stack Id for the stack instance created during
// configuration.
// CONN_ID - Same as created in step one.
// LOCAL_PC - Local Point Code for stack instance.
456
SwitchKit TCAP Interface
// LOCAL_SSN - local subsystem number for stack instance.
// APP_TransHandler - Default Handler for handling incoming
// TCAP Transaction messages.
// APP_NotifyHandler - Default Handler for handling incoming
// SKIM notifications.
// tag - Tag to be returned with handler functions.
res = api_classptr.Initialize(LOCAL_NODE, STACK_ID, CONN_ID, LOCAL_PC,
LOCAL_SSN,
APP_TransHandler,
APP_NotifyHandler, NULL);
if (res != SKIM_SUCCESS)
{
printf("\n Initialization FAILED !!!!!!!!!");
api_classptr.Terminate();
}
exit(0);
else
{
}
printf("\n SUCCESS FROM INITIALIZATION API !!\n");
Step Three: Sending a TCAP Transaction
The API function described in this section allows you to send a TCAP transaction.
Application Code
// Create SKIM_Trans object of type SKIM_TC_BEGIN
SKIM_Trans trans (SKIM_TC_BEGIN);
// Create objects for calling party and called party
// address.
SKIM_CallingPartyAddr origAddr;
SKIM_CalledPartyAddr destAddr;
// Populate OPC and DPC
trans.SetOPC(LOCAL_PC);
trans.SetOPC(REMOTE_PC);
// populate calling party address
origAddr.SetSSN(LOCAL_SSN);
origAddr.SetPointCode(LOCAL_PC);
origAddr.SetRouteByPCSSN(true);
#if defined(CCITT)
origAddr.SetInternationalRouting(true);
#elif defined (ANSI)
origAddr.SetInternationalRouting(false);
457
MSP
#endif
// Set calling party address for begin transaction.
trans.SetSourceAddress(origAddr);
//Set Called Party Address
destAddr.SetSSN(REMOTE_SSN);
destAddr.SetPointCode(REMOTE_PC);
destAddr.SetRouteByPCSSN(true);
#if defined(CCITT)
destAddr.SetInternationalRouting(true);
#elif defined (ANSI)
destAddr.SetInternationalRouting(false);
#endif
// Set called party address for begin transaction.
trans.SetDestAddress(destAddr);
// Set quality of service for the transaction message.
SKIM_OCTET priority;
priority = 0;
trans.SetQualityOfService(QOSI_RET_OPT|SKIM_QOSI_RET_OPT, priority);
// Adding a operation to transaction object.
// Create operation of type SKIM_TC_INVOKE
SKIM_Operation op(SKIM_TC_INVOKE);
// Set Invoke Id.
op.SetInvokeId(1 + i);
// Set Operation Code
#if defined(CCITT)
op.SetOpCode(100);
// Set Operation Class for invoke operation.
op.SetClass(1);
// Set Invoke operation timeout
op.SetInvokeTimeout(10);
#else defined(ANSI)
op.SetOpCode(true, 1, 1);
#endif
// Set ASN.1 encoded TCAP User parameters
op.SetParameter(SKIM_Encode());
// Add operation to the transaction object.
trans.AddOperation(op);
// Send transaction to EXS
ret = api_classptr.Send(trans);
if (ret != SKIM_SUCCESS)
{
458
printf("Send transaction failed ret = %d", ret);
SwitchKit TCAP Interface
}
return ret;
// Get the call reference id allocated for this transaction.
SKIM_UINT callrefid = ;
trans.GetCallReferenceId();
Step Four: Receiving a TCAP Transaction
The API function described in this section allows you to receive a TCAP transaction.
Transactions are received via transaction handler and registered during initialization.
Sample implementation for transaction handler is shown in the following code
excerpt.
Application Code
int APP_TransHandler( SKIM_Trans &trans, void *tag)
{
SKIM_OCTET type;
printf("APP_TransHandler Called\n");
SKIM_UINT id;
trans.GetCallReferenceId(id);
trans.GetTransType(type);
switch(type)
{
case SKIM_TC_UNI:
rcvd_callrefid = id;
printf ("Received TCAP UNI call reference id is %x\n", id);
AppReceiveOperation(trans);
break;
case SKIM_TC_BEGIN :
rcvd_callrefid = id;
printf ("Received TCAP Begin call reference id is %x\n", id);
AppReceiveOperation(trans);
break;
case SKIM_TC_CONTINUE :
rcvd_callrefid = id;
printf ("Received TCAP Continue call reference id is %x\n", id);
AppReceiveOperation (trans);
break;
case SKIM_TC_END :
rcvd_callrefid = id;
printf ("Received TCAP End call reference id is %x\n", id);
AppReceiveOperation (trans);
break;
459
MSP
#if defined(ANSI)
case SKIM_TC_ABORT :
rcvd_callrefid = id;
printf ("Received TCAP Abort call reference id is %x\n", id);
break;
#endif
#if defined(CCITT)
case SKIM_TC_U_ABORT :
rcvd_callrefid = id;
printf ("Received TCAP Abort call reference id is %x\n", id);
break;
case SKIM_TC_P_ABORT :
rcvd_callrefid = id;
printf ("Received TCAP Abort call reference id is %x\n", id);
break;
case SKIM_TC_P_ABORT :
rcvd_callrefid = id;
printf ("Received TCAP Abort call reference id is %x\n", id);
break;
#endif
default :
printf("Unknown transaction received\n");
};
}
break;
return SKIM_SUCCESS;
AppReceiveOperation(SKIM_Trans &trans)
{
SKIM_Operation op;
while (trans.RemoveOperation(op) == SKIM_SUCCESS)
{
if (op.GetType() == SKIM_TC_INVOKE)
{
rcvd_invoke_id = op.GetInvokeId();
printf("Received Invoke with Invoke id = %d\n",
op.GetInvokeId());
vector<byte> paramData;
op.GetParameter(paramData);
}
SKIM_Decode(paramData);
else if (op.GetType() == SKIM_TC_RESULT_L)
460
SwitchKit TCAP Interface
{
printf("Received Return Result Last with Invoke id = %d\n",
op.GetInvokeId());
vector<byte> paramData;
op.GetParameter(paramData);
}
SKIM_DecodeResponse(paramData);
#if defined(ANSI)
else if (op.GetType() == SKIM_TC_ERROR)
{
printf("Received Return Error with Invoke id = %d\n",
op.GetInvokeId());
}
#endif
#if defined(CCITT)
else if (op.GetType() == SKIM_TC_U_ERROR)
{
printf("Received Return Error Last with Invoke id = %d\n",
op.GetInvokeId());
}
#endif
#if defined(ANSI)
else if (op.GetType() == SKIM_TC_REJECT)
{
printf("Received Return Reject with Invoke id = %d\n",
op.GetInvokeId());
}
#endif
#if defined(CCITT)
else if (op.GetType() == SKIM_TC_U_REJECT ||
op.GetType() == SKIM_TC_L_REJECT ||
{
op.GetType() == SKIM_TC_R_REJECT)
printf("Received Return Error Last with Invoke id = %d\n",
op.GetInvokeId());
}
#endif
else
{
}
printf("Unknown operation type received\n");
461
MSP
}
}
Step Five: Receiving Notifications
Notifications are received via notification handler, registered during initialization. A
sample implementation for the notification handler is shown in the following code
excerpt.
Application Code
int APP_NotifyHandler( SKIM_Notify &notify, void *tag)
{
printf("APP_NotifyHandler Invoked\n");
int type = notify.GetType();
switch(type)
{
case SKIM_NOTIFY_OP_TIMEOUT :
printf ("Operation Timeout Notification Message Received\n");
break;
case SKIM_NOTIFY_SCCP_MGMT_IND :
printf ("SCCP Management Notification Message Received\n");
break;
case SKIM_NOTIFY_MTP3_MGMT_IND :
printf ("MTP3 Management Notification Message Received\n");
break;
case SKIM_NOTIFY_INTERNAL_ERROR :
printf ("SKIM Internal Error Notification Message Received\n");
break;
default :
printf("Unknown Notification Received \n");
};
}
break;
return SKIM_SUCCESS;
Step Six: Terminating SKIM API Object Disconnection
The API function described in this section is used to terminate a SwitchKit Interface
Module API object and disconnect from the LLC.
Application Code
api_classptr.Terminate();
if (CONN_ID)
{
462
SwitchKit TCAP Interface
skts_destroyConnection(connection);
}
connection = NULL;
classc
SwitchKit TCAP Abstraction Level
sktal_allocateTCAPDialogID()
Description
This function allocates TCAP dialogue ID.
Syntax
int sktal_allocateTCAPDialogID(int instanceId, unsigned *did);
Input Parameters
Argument
instanceID
Description
Instance for given node/stack/SNN
combination
*did Pointer to the TCAP dialogue.
Input/Output Parameters
None
Output Parameters
Argument
dialogueId
Description
TCAP
dialogue ID
Return Value
SKTAL_SUCCESS: If method is successful.
SKTAL return code as defined in Appendix C, Table C-2, SKTAL Return Codes.
sktal_clearTCAPDialogHandler()
Description
The user must remove the transaction handler once the transaction has been
completed (by receiving TC-U-ABORT, TC-P-ABORT, TC-END, or TC-UNI, or sending
463
MSP
TC-U-ABORT, TC-END, or TC-UNI). It is imperative to NOT take this step until the
last message for a transaction has been sent or received.
Syntax
int sktal_clearTCAPDialogueHandler(int instanceId,
unsigned dialogueId);
Input Parameters
Argument
Description
dialogueId
TCAP dialogue ID
instanceID
Instance for given node/stack/SNN
combination
Input/Output Parameters and Output Parameters
None.
Return Value
SKTAL_SUCCESS: If method is successful.
SKTAL return code as defined in Appendix C, Table C-2, SKTAL Return Codes.
sktal_getTCAPHandle()
Description
This function returns a handle for a given instance ID (node/stack/SSN). The handle
is a pointer to a control block for the given instance ID.
Syntax
SKTAL_HANDLE sk_getTCAPHandle(int instanceId);
Input Parameters
Argument
instance id
Description
Instance corresponding to node
ID/stack ID/SSN.
Parameters
There are no input/ouput parameters, or output parameters.
464
SwitchKit TCAP Interface
Return Value
Returns a handle to control block.
sktal_initializeTCAP()
Description
This method is one time call for global initialization of TCAP Abstraction layer.
Syntax
int sktal_initializeTCAP();
Parameters
There are no input parameters, input/ouput parameters, or output parameters.
Return Value
SKTAL_SUCCESS: If method is successful.
SKTAL return code as defined in Appendix C Table C-2, SKTAL Return Codes.
sktal_recvTCAPComponent()
Description
This method receives a TCAP component information from a SKTAL_EVENT.
Syntax
int sktal_recvTCAPComponent(int instanceId, SKTAL_EVENT *ev,
unsigned *dialogueId, SKTAL_CPT *cpt);
Input Parameters
Argument
Description
ev
Event containing dialogue
information
instanceID
Instance for given node/stack/SNN
combination
Input/Output Parameters
None
Output Parameters
465
MSP
Argument
Description
cpt
Pointer to the structure containing component information
dialogueId
TCAP dialogue ID
For definition see Appendix D, SKTAL_DLG and SKTAL_CPT Structure Definitions.
Return Value
SKTAL_SUCCESS: If method is successful.
SKTAL return code as defined in Appendix C, Table C-2, SKTAL Return Codes.
sktal_recvTCAPDialog()
Description
This method receives TCAP dialogue information from a SKTAL_EVENT.
Syntax
int sktal_recvTCAPDialog(int instanceId, SKTAL_EVENT *ev,
unsigned *dialogueId, SKTAL_DLG *dlg);
Input Parameters
instanceId: instance for registered node/stack/snn combination.
ev: event containing dialogue information.
The SKTAL_EVENT is defined in Appendix C.
Input/Output Parameters
None
Output Parameters
Argument
Description
dlg
Pointer to the structure containing TCAP
dialogue information
dialogueId
TCAP dialogue ID
For definition see Appendix D, SKTAL_DLG and SKTAL_CPT Structure Definitions.
Return Value
466
SwitchKit TCAP Interface
SKTAL_SUCCESS: If method is successful.
SKTAL return code as defined in Appendix C, Table C-2, SKTAL Return Codes.
sktal_registerTCAPSSNHandler()
Description
This function registers the application with a given node/stack/subsystem. A generic
handler will be added to the handler stack that will filter messages for the given
subsystem. When a new TCAP transaction is seen, or when
sk_TCAP_AllocateDialogueID is called, the NewDialogueHandler function argument
will be invoked. This function is expected to register a per dialogue handler (via
sktal_setTCAPDialogHandler) for the new dialogue. All incoming messages within
that dialogue sequence will be passed to that handler.
When using multiple running applications on the same subsystem number, the
startRange and endRange arguments should be modified to divide the dialogue IDs
between them. For example, when using two applications the values are:
Application
1
Application 2
endRange =
4095
endRange =
8191
startRange =
0
startRange =
4096
Syntax
int sktal_registerTCAPSSNHandler (int localNodeId, int stackId, int pc, int pc, int ssn,
SK_TCAP_NewDialogHandler h,int *instanceId int connID, int startRange=0, int
endRange=SK_MAX_TCAP_DIALOGS-1);
Input Parameters
Argument
Description
stackId
stack ID
localNodeId
pc
ssn
h
local node ID
point code
Subsystem Number
Handler function for new TCAP
dialogues.
The prototype for new dialogue
handler is:
typedef int
(*SKTAL_NewDialogHandler)(int
instanceId, unsigned
467
MSP
connId
startRange
endRange
newDialogId);
connection ID
Starting dialogue ID allocated to
this application (For the specific
SSN)
Ending dialogue ID allocated to
this application (For the specifc
SSN)
Input/Output Parameters
None
Output Parameters
Argument
instanceId
Description
Instance for given node/stack/SNN
combination
Return Value
SKTAL_SUCCESS: If method is successful.
SKTAL return code as defined in Appendix C, Table C-2, SKTAL Return Codes.
sktal_sendTCAPComponent()
Description
This method sends a TCAP component message.
Syntax
int sktal_sendTCAPComponent(int instanceId, unsigned dialogueId, SKTAL_CPT
*cpt);
Input Parameters
Argument
Description
dialogueId
TCAP dialogue ID
instanceID
468
Instance for given node/stack/SNN
combination
SwitchKit TCAP Interface
cpt
Pointer to the structure containing
component information
For definition see Appendix D, SKTAL_DLG and SKTAL_CPT Structure Definitions.
Input/Output Parameters and Output Parameters
None.
Return Value
SKTAL_SUCCESS: If method is successful.
SKTAL return code as defined in Appendix C, Table C-2, SKTAL Return Codes.
sktal_sendTCAPDialog()
Description
This method sends a TCAP dialogue message.
Syntax
int sktal_sendTCAPDialog(int instanceId, unsigned dialogueId, SKTAL_DLG *dlg);
Input Parameters
Argument
Description
dialogueId
TCAP dialogue ID
instanceID
dlg
Instance for given node/stack/SNN combination
Pointer to the structure containing TCAP dialogue information
For definition See Appendix D, Table , SKTAL_DLG and SKTAL_CPT Structure
Definitions
Input/Output Parameters and Output Parameters
None.
Return Value
SKTAL_SUCCESS: If method is successful.
SKTAL return code as defined in Appendix C, Table C-2, SKTAL Return Codes.
sktal_setTCAPDialogueHandler ()
Description
469
MSP
Specifies a function to be invoked for incoming messages within a given transaction
(identified by the Dialogue ID). The incoming event and the Dialogue ID invoke the
handler; the handler should examine the event and invoke either
sk_recvTCAPDialogue or sk_recvTCAPComponent.
Syntax
int sktal_setTCAPDialogueHandler(int instanceId, unsigned dialogueId,
SKTAL_TCAP_DialogueHandler handler, void *tag);
Input Parameters
Argument
Description
dialogueId
TCAP dialogue ID
instanceID
handler
Instance for given node/stack/SNN
combination
TCAP dialogue handler function.
The prototype for new dialogue
handler is:
typedef int
(*SKTAL_DialogHandler)(int
instanceId, SKTAL_EVENT *ev,
void *tag);
Input/Output Parameters and Output Parameters
None
Return Value
SKTAL_SUCCESS: If method is successful.
SKTAL return code as defined in Appendix C, Table C-2, SKTAL Return Codes.
sktal_terminateTCAP()
Description
This method is a one time call for global termination of TCAP Abstraction layer.
Syntax
void sktal_terminateTCAP();
Parameters
There are no input parameters, input/ouput parameters, or output parameters.
470
SwitchKit TCAP Interface
Return Value
None.
sktal_unregisterTCAPSSNHandler ()
Description
This function removes (and terminates) the subsystem identified during registration.
All active transactions are terminated by the PreArrangedEnd() method.
Syntax
int sktal_unregisterTCAPSSNHandler (int instanceId);
Input Parameters
Argument
Description
instanceId
Instance for given node/stack/SSN
combination
Input/Output Parameters and Output Parameters
None.
Return Value
SKTAL_SUCCESS: If method is successful.
SKTAL return code as defined in Appendix C, Table C-2, SKTAL Return Code.
SwitchKit TCAP Abstraction Layer Messaging API
SwitchKit TCAP Abstraction Layer (SKTAL) provides various methods to develop an
application.
Summary of Methods
This section describes the interface methods that are provided with the SwitchKit
TCAP Abstraction Layer (SKTAL). Further on, you will see details of each method.
int sktal_initializeTCAP();
SKTAL_HANDLE sktal_getTCAPHandle(int instanceId);
int sktal_registerTCAPSSNHandler (int localNodeId,
int stackId,
int connId,
int pc,
471
MSP
int ssn,
SK_TCAP_NewDialogueHandler h,
int *instanceId);
int sktal_unregisterTCAPSSNHandler (int instanceId);
int sktal_setTCAPDialogueHandler(int instanceId,
unsigned dialogueId,
SKTAL_TCAP_DialogueHandler handler,
void *tag);
int sktal_clearTCAPDialogueHandler(int instanceId,
unsigned dialogueId);
int sktal_allocateTCAPDialogueID(int instanceId, unsigned *did);
int sktal_sendTCAPDialog(int instanceId, unsigned dialogueId, SKTAL_DLG *dlg);
int sktal_recvTCAPDialog(int instanceId, SKTAL_EVENT *ev,
unsigned *dialogueId, SKTAL_DLG *dlg);
int sktal_sendTCAPComponent(int instanceId, unsigned dialogueId, SKTAL_CPT *cpt);
int sktal_recvTCAPComponent(int instanceId, SKTAL_EVENT *ev,
unsigned *dialogueId, SKTAL_CPT *cpt);
SKTAL Parameter Classes
SKTAL Parameter Classes
Overview
From an end-user point of view, transaction capabilities are above the network layer
of the OSI seven layer reference model. The provision of network layer services to
end-users requires communication between TCAP-users at various network nodes;
these intra-network communications may in turn be modeled using the OSI Model.
As illustrated in the next diagram, the TCAP is structured in two interfaces for the
TCAP components and TCAP dialogs.
Diagram of Structure of TCAP Classes
472
SwitchKit TCAP Interface
This section describes the two main classes, TCAP_Component and TCAP_Dialogue,
their subclasses, and the methods of each.
Important! SKTAL C++ interface is defined under namespace sktal.
Class TCAP_Component
Purpose
The purpose of the TCAP_Component interface is to define the base class for all TCAP
components. The class, while not abstract, should be considered as such, it is not
intended that a user ever create a TCAP_Component class object.
Summary of Methods
The following methods are used within the TCAP_Component
// Type
SKTAL_USHORT GetComponentType() const;
// Last component
SKTAL_USHORT GetLast() const;
// Invoke ID
void SetInvokeID(const SKTAL_OCTET val);
SKTAL_OCTET GetInvokeID() const;
// Send
static int Send(SKTAL_HANDLE handle,
TCAP_Dialogue* dlg,
// Receive
TCAP_Component* cpt);
static int Receive(SKTAL_HANDLE handle,
473
MSP
SKTAL_Event& ev,
TCAP_Dialogue* dlg,
// Print
TCAP_Component** cpt);
virtual void Print(std::ostream& os) const;
GetComponentType()
Description
Returns the type of this component.
Syntax
SKTAL_USHORT GetComponentType() const;
Input Parameters, Input/Output Parameters & Output Parameters
None
Return Value
The type of this component is an unsigned short:
If defined ITU:
TCPPT_TC_INVOKE
TCPPT_TC_RESULT_L (where L means last)
TCPPT_TC_RESULT_NL (where NL means not last)
TCPPT_TC_U_ERROR
TCPPT_TC_L_REJECT
TCPPT_TC_U_REJECT
TCPPT_TC_R_REJECT
TCPPT_TC_L_CANCEL
TCPPT_TC_U_CANCEL
TCAP_PT-TC_TIMER_RESET
If defined ANSI:
TCPPT_TC_INVOKE_NL
TCPPT_TC_INVOKE (Same as invoke last)
TCPPT_TC-RESULT-L
TCPPT_TC_RESULT_NL
TCPPT_TC_ERROR
TCPPT_TC_REJECT
TCPPT_TC_CANCEL
474
SwitchKit TCAP Interface
GetLast()
Description
Returns a Boolean indicating if this is the last component in this PDU
Syntax
SKTAL_USHORT GetLast() const;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
true: True if this instance is the last component in this PDU.
false: If this instance is not the last component in this PDU
SetInvokeID()
Description
This method takes an invoke ID from user and converts it into the form expected by
TCAP. As invoke IDs are common to all TCAP components, the SetInvokeID method
is defined in the TCAP_Component base class.
Syntax
void SetInvokeID(const SKTAL_OCTET val);
Input Parameters
val: The invoke ID value. Range is 0-255
Input/Output Parameters and Output Parameters
None
Return Value
None
GetInvokeID()
Description
475
MSP
This method returns the invoke ID of a component. Since invoke IDs are common to
all TCAP components, the GetInvokeID method is defined in the TCAP_Component
base class. If no invoke ID has been received then the invoke ID is set to zero.
Syntax
SKTAL_OCTET GetInvokeID() const;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
The invoke ID as an unsigned character.
Send()
Description
This method sends a TCAP message and returns a Boolean indication if the message
is successfully sent. This send method is static. The value of SKTAL_SUCCESS is 0.
Syntax
static int Send(SKTAL_HANDLE handle,
TCAP_Dialogue* dlg,
TCAP_Component* cpt);
Input Parameters
handle: The transport being sent. For getting the handle use sktal_getTCAPHandle()
API
dlg: The TCAP dialogue primitive of which this component is part.
cpt: The TCAP component primitive of which this component is part.
Input/Output Parameters and Output Parameters
None
Return Value
If the message is successfully sent, SKTAL_SUCCESS is returned. Any other return
value indicates an error.
Receive()
476
SwitchKit TCAP Interface
Description
This method receives a TCAP message and returns a Boolean indication if the
message is successfully received. This Receive method is static.
Syntax
static int Receive(SKTAL_HANDLE handle,
SKTAL_Event& ev,
TCAP_Dialogue* dlg,
TCAP_Component** cpt);
Input Parameters
handle: The transport that received this event. For getting the handle use
sktal_getTCAPHandle() API
ev: The event primitive this component is associated with.
dlg: The dialogue primitive this component is associated with.
cpt: The component primitive this component is associated with.
Input/Output Parameters
None
Output Parameters
cpt: The constructed component
Return Value
SKTAL_SUCCESS: If the component is successfully received. Any other return code
indicates an error.
Print()
Description
This method prints the contents of the component to the output stream that is
passed in to the method. This print method is virtual.
Syntax
virtual void Print (std::ostream& os) const;
Input Parameters
477
MSP
os: The output stream to print the contents to
Input/Output Parameters and Output Parameters
None
Return Value
None
Class TCAP_Abort : public TCAP_Dialogue
Purpose
The purpose of the TCAP_Abort message class is to define the basic interface for
aborting TCAP transactions. Note that this class can be user-generated for ITU
TCAP, but is stack-generated only with ANSI TCAP.
Summary of Methods
The TCAP_Abort message class includes the following methods:
// Component present
virtual bool IsComponentPresent() const;
virtual void SetComponentPresent(bool);
// Abort reason
SKTAL_OCTET GetAbortReason() const;
void SetAbortReason(SKTAL_OCTET reason);
void GetAbortInfo(SKTAL_OCTET *buf, int &len);
void SetAbortInfo(SKTAL_OCTET *buf, int &len);
IsComponentPresent()
Syntax
See class TCAP_Dialogue
virtual bool IsComponentPresent() const;
SetComponentPresent()
Description
This method can be used to set the components associated with the dialogue. The
SetComponentPresent method is a virtual method.
478
SwitchKit TCAP Interface
Syntax
virtual void SetComponentPresent(bool);
Input Parameters and Output Parameters
None
Input/Output Parameters
True: present the component
False: do not present the component
Return Value
None
SetAbortReason()
Description
This method can be used to set the abort reason of a dialogue
Syntax
void SetAbortReason(SKTAL_OCTET reason);
Input Parameters
reason: The abort reason
Input/Output Parameters and Output Parameters
None
Return Value
None
GetAbortReason()
Description
This method returns the abort reason of a dialogue
Syntax
SKTAL_OCTET GetAbortReason() const;
479
MSP
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
The abort reason as an unsigned character.
GetAbortInfo()
Description
This method gets the abort information for SKIM_TC_ABORT for an ANSI transaction
type.
Syntax
void GetAbortInfo(SKTAL_OCTET *buf, int &len);
Input Parameters, Input/Output Parameters
None
Output Parameters
buf: Abort information
len: Information length
SetAbortInfo()
Description
This method sets the abort information for SKIM_TC_ABORT for an ANSI transaction
type.
Syntax
void SetAbortInfo(SKTAL_OCTET *buf, int &len);
Input Parameters
buf: Abort information
len: Information length
Input/Output Parameters, & Output Parameters
480
SwitchKit TCAP Interface
None
Class TCAP_Begin : public TCAP_Dialogue
Purpose
The purpose of the TCAP_Begin message class is to define the interface for beginning
TCAP transactions. The class implements TCPPT_TC_BEGIN (ITU) and
TCPPT_TC_QUERY_W_PERM/TCPPT_TC_QUERY_WO_PERM (ANSI) dialogues.
This message begins a communication session for remote operations. In ANSI, a
Boolean may be passed to this Class Constructor. If this Boolean is true (default
value), TC_QUERY_WITH_PERM is sent out, else TC_QUERY_WO_PERM.
Summary of Methods
The TCAP_Begin message class includes the following methods:
// Xcvr checks
virtual bool SendCheck() const;
virtual bool ReceiveCheck();
// Point code (orig)
void GetOPC(SKTAL_UINT& pointCode) const;
// Point code (dest)
void SetDPC(const SKTAL_UINT pointCode);
// Full SCCP Address (orig)
void SetOrigAddr(const bool isNational,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn);
void SetOrigAddr(const SKTAL_OCTET addrInd,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn,
const SKTAL_OCTET* gttInfo,
const SKTAL_USHORT gttLen);
void SetOrigAddr(const SCCP_Address& addr);
void GetOrigAddr(bool& isNational,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn) const;
void GetOrigAddr(SKTAL_OCTET& addrInd,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn,
SKTAL_OCTET* gttInfo,
SKTAL_USHORT* gttLen) const;
void GetOrigAddr(SCCP_Address& addr) const;
481
MSP
// Full SCCP Address (dest)
void SetDestAddr(const bool isNational,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn);
void SetDestAddr(const SKTAL_OCTET addrInd,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn,
const SKTAL_OCTET* gttInfo,
const SKTAL_USHORT gttLen);
void SetDestAddr(const SCCP_Address& addr);
void GetDestAddr(bool& isNational,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn) const;
void GetDestAddr(SKTAL_OCTET& addrInd,
GetDestAddr(SCCP_Address& addr) const;
SendCheck()
Syntax
See class TCAP_Dialogue
virtual bool SendCheck() const;
ReceiveCheck()
See class TCAP_Dialogue
Syntax
virtual bool ReceiveCheck();
GetOPC()
Description
This method gets the OPC for this dialogue primitive from discrete information. OPC
contained in MTP routing label is received from the MSP 1010 for TCAP
BEGIN/QWP/QWOP messages as a optional parameter. OPC is included by the MSP
1010, only if SCCP CGPA does not contain a point code.
Syntax
void GetOPC(SKTAL_UINT& pointCode) const;
void GetOPC(MTP3_POINT_CODE& pc) const;
void GetOPC(MTP3_PointCode& pc) const;
Input Parameters and Input/Output Parameters
None
482
SwitchKit TCAP Interface
Output Parameters
pointCode: the point code of this address
Return Value
None
SetDPC()
Description
Sets the DPC for this dialogue primitive. This method sets the DPC in the routing
label of outgoing TCAP BEGIN/QWP/QWOP messages. A DPC set using the SetDPC
method will come into effect only if SCCP CDPA does not contain a point code.
Syntax
void SetDPC( const SKTAL_UINT pointCode);
Input Parameters
pointCode - the point code of this address
Input/Output Parameters and Output Parameters
None
SetOrigAddr()
See class TCAP_Unidirectional
Syntax
void SetOrigAddr(const bool isNational,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn);
void SetOrigAddr(const SKTAL_OCTET addrInd,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn,
const SKTAL_OCTET* gttInfo,
const SKTAL_USHORT gttLen);
void SetOrigAddr(const SCCP_Address& addr);
483
MSP
GetOrigAddr()
Syntax
See class TCAP_Unidirectional
void GetOrigAddr(bool& isNational,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn) const;
void GetOrigAddr(SKTAL_OCTET& addrInd,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn,
SKTAL_OCTET* gttInfo,
SKTAL_USHORT* gttLen) const;
void GetOrigAddr(SCCP_Address& addr) const;
SetDestAddr()
See class TCAP_Unidirectional
Syntax
void SetDestAddr(const bool isNational,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn);
void SetDestAddr(const SKTAL_OCTET addrInd,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn,
const SKTAL_OCTET* gttInfo,
const SKTAL_USHORT gttLen);
void SetDestAddr(const SCCP_Address& addr);
GetDestAddr()
Syntax
See class TCAP_Unidirectional
void GetDestAddr(bool& isNational,
484
SwitchKit TCAP Interface
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn) const;
void GetDestAddr(SKTAL_OCTET& addrInd,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn,
SKTAL_OCTET* gttInfo,
SKTAL_USHORT* gttLen) const;
void GetDestAddr(SCCP_Address& addr) const;
Class TCAP_Cancel : public TCAP_Component
Purpose
The purpose of the TCAP_Cancel component is an artificial (at least for ANSI)
component that is generated when an invoke operation times out. The ANSI version
of TCAP does not have this component; instead, IntelliNet generates this component
for the user. The TCAP_Cancel component includes the following methods:
GetDialogueID()
Description
This method returns the context information for a dialogue (that is, its "Dialogue
ID"). This information should be copied from the Begin primitive when constructing
continue or end dialogues. The user must obtain a Dialogue ID from the stack when
initiating a transaction. This is done by calling TCAP_AllocateDialogueID().
Syntax
SKTAL_USHORT GetDialogueID() const;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
The Dialogue ID as an unsigned short.
Class TCAP_Continue : public TCAP_Dialogue
Purpose
The purpose of the TCAP_Continue message class is to define the basic interface for
continuing TCAP transactions. The class implements both TCPPT_TC_CONTINUE
(ITU), and TCPPT_TC_CONV_W_PERM/TCPPT_TC_CONV_WO_PERM (ANSI)
dialogues. In ANSI, a Boolean may be passed to this Class Constructor. If this
485
MSP
Boolean is true (default value), TC_QUERY_WITH_PERM is sent out, else
TC_QUERY_WO_PERM. When the user does not wish to use simple request/response
transactions, the TCAP_Continue dialogue is used to exchange components without
terminating the transaction.
Summary of Methods
The TCAP_Continue message class includes the following methods:
// Xcvr checks
virtual bool SendCheck() const;
virtual bool ReceiveCheck();
// Full SCCP Address (orig)
void SetOrigAddr(const bool isNational,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn);
void SetOrigAddr(const SKTAL_OCTET addrInd,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn,
const SKTAL_OCTET* gttInfo,
const SKTAL_USHORT gttLen);
void SetOrigAddr(const SCCP_Address& addr);
void GetOrigAddr(bool& isNational,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn) const;
void GetOrigAddr(SKTAL_OCTET& addrInd,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn,
SKTAL_OCTET* gttInfo,
SKTAL_USHORT* gttLen) const;
void GetOrigAddr(SCCP_Address& addr) const;
SendCheck()
See class TCAP_Dialogue
Syntax
virtual bool SendCheck() const;
ReceiveCheck()
See class TCAP_Dialogue
486
SwitchKit TCAP Interface
Syntax
virtual bool ReceiveCheck();
SetOrigAddr()
See class TCAP_Unidirectional
Syntax
void SetOrigAddr(const bool isNational,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn);
void SetOrigAddr(const SKTAL_OCTET addrInd,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn,
const SKTAL_OCTET* gttInfo,
const SKTAL_USHORT gttLen);
void SetOrigAddr(const SKTAL_OCTET addrInd,
const MTP3_PointCode& pointCode,
const SKTAL_OCTET ssn,
const SKTAL_ByteArray& gttInfo);
void SetOrigAddr(const SCCP_ADDR& addr);
void SetOrigAddr(const SCCP_Address& addr);
GetOrigAddr()
See class TCAP_Unidirectional
Syntax
void GetOrigAddr(bool& isNational,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn) const;
void GetOrigAddr(SKTAL_OCTET& addrInd,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn,
SKTAL_OCTET* gttInfo,
SKTAL_USHORT* gttLen) const;
487
MSP
void GetOrigAddr(SCCP_Address& addr) const;
Class TCAP_Dialogue
Purpose
The purpose of the TCAP_Dialogue interface is to define the base class for all TCAP
dialogues. The class, while not abstract, should be considered as such. It is not
intended that a user ever create a naked object.
Summary of Methods
The TCAP_Dialogue interface includes the following methods:
// Dialogue type
SKTAL_USHORT GetDialogueType() const;
// Dialogue ID
void SetDialogueID(const SKTAL_USHORT did);
SKTAL_USHORT GetDialogueID() const;
// Component present
virtual bool IsComponentPresent() const;
// Quality of service
virtual void SetQualityOfService(const SKTAL_OCTET flags,
const SKTAL_OCTET priority = 0);
virtual void GetQualityOfService(SKTAL_OCTET& flags,
SKTAL_OCTET& priority) const;
// Application context
virtual void SetApplicationContext(const SKTAL_OCTET* buf, const int len);
virtual void GetApplicationContext(SKTAL_OCTET* buf, int& len) const;
virtual void SetApplicationContext(const SKTAL_ByteArray& buf);
virtual void GetApplicationContext(SKTAL_ByteArray& buf) const;
// User info
virtual void SetUserInfo(const SKTAL_OCTET* buf, const int len);
virtual void GetUserInfo(SKTAL_OCTET* buf, int& len) const;
virtual void SetUserInfo(const SKTAL_ByteArray& buf);
virtual void GetUserInfo(SKTAL_ByteArray& buf) const;
// Xcvr checks
virtual bool SendCheck() const;
virtual bool ReceiveCheck();
// Send
static int Send(SKTAL_HANDLE handle, TCAP_Dialogue*dlg);
// Receive
static int Receive(SKTAL_HANDLE handle,
SKTAL_Event&ev,
488
SwitchKit TCAP Interface
TCAP_Dialogue**dlg);
// Expose the header
const SKTAL_HDR& GetHeader() const;
// Print
virtual void Print(std::ostream& os) const;
SetDialogueID()
Description
This method is used to set the transaction context (or "Dialogue ID") of a
transaction.
Syntax
void SetDialogueID(const SKTAL_USHORT did);
Input Parameters
did: The Dialogue ID of this transaction is an unsigned short
Input/Output Parameters and Output Parameters
None
Return Value
None
GetDialogueType()
Description
Returns the type of this dialogue.
Syntax
SKTAL_USHORT GetDialogueType() const;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
The type of this dialogue is an unsigned short:
489
MSP
If defined as ANSI:
TCPPT_TC_UNI
TCPPT_TC_QUERY_W-PERM
TCPPT_TC_QUERY_WO_PERM
TCPPT_TC_RESP
TCPPT_TC_CONV_W_PERM
TCPPT_TC_CONV_WO_PERM
TCPPT_TC_ABOUT
TCPPT_TC_NOTICE
If defined as ITU:
TCPPT_TC_UNI
TCPPT_TC_BEGIN
TCPPT_TC_END
TCPPT_TC_CONTINUE
TCPPT_TC_P_ABORT
TCPPT_TC_U_ABORT
TCPPT_TC_NOTICE
GetDialogueID()
Syntax
See class TCAP_Cancel
SKTAL_USHORT GetDialogueID() const;
IsComponentPresent()
Description
This method is a predicate for determining if an inbound dialogue has components
associated with it. This predicate is meaningless for outbound dialogues. The
IsComponentPresent method is virtual.
Syntax
virtual bool IsComponentPresent() const;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
490
SwitchKit TCAP Interface
true: If a dialogue primitive has associated components
false: If a dialogue primitive has no associated components
SetQualityOfService()
Description
This method allows the user to set the quality of service (QoS) parameters for a
transaction
Syntax
virtual void SetQualityOfService(const SKTAL_OCTET flags,
const SKTAL_OCTET priority = 0);
Input Parameters
flags: Quality of service indicators (See Appendix D for a list of flags)
priority: If QOS_PRIORITY is set in the flags, this indicates the priority value
Input/Output Parameters and Output Parameters
None
Return Value
None
Altering the QoS parameters is not normally done. ANSI does not support all QoS
parameters. This method is virtual.
GetQualityOfService()
Description
This method allows the user to get the quality of service (QoS) parameters for a
transaction. The GetQualityOfService method is a virtual method.
Syntax
virtual void GetQualityOfService(SKTAL_OCTET& flags,
SKTAL_OCTET& priority)
Input Parameters and Input/Output Parameters
None
491
MSP
Output Parameters
flags: Quality of service indicators
Return Option: QOSI_RET_OPT
Sequence Control: QOSI_SEQ_CTRL
SLS key present: QOSI_SLS_KEY
Message priority octet present: QOSI_PRIORITY
priority: If QOS_PRIORITY is set in the flags, this indicates the priority value
Return Value
None
SetApplicationContext()
Description
This method allows the user to set the application context for a transaction. Older
versions of ANSI TCAP do not support application context. This method is a virtual
method.
Syntax
virtual void SetApplicationContext(const SKTAL_OCTET* buf,
const int len);
SetApplicationContext(const SKTAL_ByteArray& buf);
Input Parameters
buf: A buffer to copy the application context into
len: The number of bytes copied
Input/Output Parameters and Output Parameters
None
Return Value
None
Older versions of ANSI TCAP do not support application context. This method is
virtual.
GetApplicationContext()
492
SwitchKit TCAP Interface
Description
This method allows the user to get the application context for a transaction. The len
parameter will become an in/out parameter and should be set to the maximum size
of the buffer to copy to. Users should therefore set the length now to avoid problems
in the future.
Returning a length of zero indicates that no context is present. Older versions of
ANSI TCAP do not support application context. The GetApplicationContext method is
a virtual method.
Syntax
virtual void GetApplicationContext(SKTAL_OCTET* buf, int& len) const;
Input Parameters
buf: A buffer to copy the application context into
Input/Output Parameters
None
Output Parameters
len: the number of bytes copied
Return Value
None
void GetApplicationContext(SKTAL_ByteArray& buf) const;
Description
This method allows the user to get the application context for a transaction.
Input Parameters and Input/Output Parameters
None
Output Parameters
buf: a buffer to copy the application context into
Return Value
None
493
MSP
Older versions of ANSI TCAP do not support application context. This method is
virtual.
SetUserInfo()
Description
This method can be used to set the user information for a transaction. Older versions
of ANSI TCAP do not support user information. This method is virtual.
Syntax
virtual void SetUserInfo(const SKTAL_OCTET* buf,
const int len);
virtual void SetUserInfo(const SKTAL_ByteArray& buf);
Input Parameters
buf: A pointer to a buffer to copy the user information into
len: The number of bytes copied
Input/Output Parameters and Output Parameters
None
Return Value
None
GetUserInfo()
Description
This method allows the user to get the user information for a transaction. Older
versions of ANSI TCAP do not support user information. This method is virtual. The
len parameter will become an in/out parameter and should be set to the maximum
size of the buffer to copy to. Users should set the length now to avoid problems.
Returning a length of zero indicates that no information is present.
Syntax
virtual void GetUserInfo(SKTAL_OCTET* buf, int& len) const;
Input Parameters
buf: A pointer to a buffer to copy the user information into
494
SwitchKit TCAP Interface
Input/Output Parameters
None
Output Parameters
len: The number of bytes copied
Return Value
None
GetUserInfo()
Description
This method allows the user to get the user information for a transaction. Older
versions of ANSI TCAP do not support user information. This method is a virtual
method.
Syntax
virtual void GetUserInfo(SKTAL_ByteArray& buf) const;
Input Parameters and Input/Output Parameters
None
Output Parameters
buf: A buffer to copy the user information into
Return Value
None
SendCheck()
Description
This method allows the user to check if the transaction is proceeding. This method is
virtual.
Syntax
virtual bool SendCheck() const;
495
MSP
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
true: If the transaction is proceeding
false: If the transaction is not proceeding
ReceiveCheck()
Description
This method allows the user to check if the information is received. This method is
virtual.
Syntax
virtual bool ReceiveCheck();
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
true: If the information is received
false: If the information is not received
Send()
Description
This method is provided for the user to send TCAP dialogues to the stack. This is the
preferred method of dialogue transmission. The Send method is static.
Syntax
static int Send(SKTAL_HANDLE handle, TCAP_Dialogue* dlg);
Input Parameters
handle - The transport this dialogue is sent. For getting the handle use
sktal_getTCAPHandle() API
dlg - A pointer to the dialogue to send
496
SwitchKit TCAP Interface
Input/Output Parameters and Output Parameters
None
Return Value
If the message is successfully sent, SKTAL_SUCCESS is returned. Any other return
value indicates an error.
Receive()
Description
This method is provided for the user to receive TCAP dialogues from the stack. This
is the preferred method of dialogue reception.The Receive method is static. This
method acts as a constructor for received dialogues.
Syntax
static int Receive(SKTAL_HANDLE handle,
SKTAL_Event& ev,
TCAP_Dialogue** dlg);
Input Parameters
handle: the transport this dialogue is sent. For getting the handle use
sktal_getTCAPHandle().
ev: the event to receive the dialogue from
Input/Output Parameters
None
Output Parameters
dlg - the address of a pointer that is populated with the received dialogue
Return Value
If the message is successfully sent, SKTAL_SUCCESS is returned. Any other return
value indicates an error.
GetHeader()
Description
497
MSP
This method exposes the SKTAL_HDR part of the received dialogue.
Syntax
const SKTAL_HDR& GetHeader() const;
Input Parameters and Input/Output Parameters
None
Output Parameters
hdr: the header present with the received dialogue
Return Value
None
Print()
Description
This method prints the contents of the dialogue to the output stream that is passed
in to the method.
Syntax
virtual void Print(std::ostream& os) const;
Input Parameters
os: the output stream to print the contents to.
Input/Output Parameters and Output Parameters
None
Return Value
None
Class TCAP_End: public TCAP_Dialogue
Purpose
The purpose of the TCAP_End message class is to define the basic interface for
terminating TCAP transactions. The class implements both TCPPT_TC_END (ITU),
and TCPPT_TC_RESP (ANSI) dialogues. The user terminates a TCAP transaction
through the TCAP_End message.
498
SwitchKit TCAP Interface
Summary of Methods
The TCAP_End message class includes the following methods:
// Prearranged end
bool IsPreArrangedEnd() const;
void SetPreArrangedEnd(bool onOff);
IsPreArrangedEnd()
Description
This method returns a Boolean indicating if this is the prearranged end.
Syntax
bool IsPreArrangeEnd() const;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
true: if this is the prearranged end
false: if this is not the prearranged end
SetPreArrangedEnd()
Description
This method allows the user to set the end message for this dialogue primitive with
prearranged end or basic end.
Syntax
void SetPreArrangedEnd(bool onOff);
Input Parameters
onOff (true false)
Input/Output Parameters and Output Parameters
None
Return Value
499
MSP
None
Class TCAP_Error : public TCAP_Component
Purpose
The purpose of the TCAP_Error component is to define the basic interface to the
remote operation error codes. This class is used to reply to unsuccessful invoke
operations
Summary of Methods
TCAP_Error component includes the following methods:
// Error
// If defined(CCITT)
void SetError(const SKTAL_OCTET code);
void GetError(SKTAL_OCTET& code) const;
//If defined(ANSI)
void SetError(const bool isNational, const SKTAL_OCTET code);
void GetError(bool& isNational, SKTAL_OCTET& code) const;
// Parameter
void SetParameter(const SKTAL_OCTET* buf, const int len);
void GetParameter(SKTAL_OCTET* buf, int& len) const;
void SetParameter(const SKTAL_ByteArray& buf);
void GetParameter(SKTAL_ByteArray& buf) const;
SetError()
Description
This method sets the error code in an error component. The signature of this
method varies depending on the standard used.
Syntax
If defined ITU:
void SetError(const SKTAL_OCTET code);
If defined ANSI:
void SetError(const bool isNational, const SKTAL_OCTET code);
Input Parameters (ITU)
code: The error code
Input Parameters (ANSI)
500
SwitchKit TCAP Interface
isNational: an indicator that this code is national or private
code: The error code
Input/Output Parameters and Output Parameters
None
Return Value
None
GetError()
Description
This method gets the error code in an error component. The signature of this method
varies depending on the standard used.
Syntax
If defined ITU:
void GetError(SKTAL_OCTET& code) const;
If defined ANSI:
void GetError(bool& isNational, SKTAL_OCTET& code) const;
Input Parameters and Input/Output Parameters
None
Output Parameters (ITU)
code: The error code
Output Parameters (ANSI)
isNational: an indicator that this code is national or private
code: the error code
Return Value
None
SetParameter()
Syntax
501
MSP
See class TCAP_Invoke
void SetParameter(const SKTAL_OCTET* buf, const int len);
void SetParameter(const SKTAL_ByteArray& buf);
GetParameter()
Syntax
See class TCAP_Invoke
void GetParameter(SKTAL_OCTET* buf, int& len) const;
void GetParameter(SKTAL_ByteArray& buf) const;
Class TCAP_Invoke : public TCAP_Component
Purpose
The purpose of the TCAP_Invoke component is to define the basic interface for
applications wishing to invoke remote operations.
Summary of Methods
The following methods are used within the TCAP_Invoke component:
// Operation
// If defined(CCITT)
void SetOperation(const SKTAL_LONG code);
void GetOperation(SKTAL_LONG& code) const;
// If defined(ANSI)
void SetOperation(const bool isNational,
const SKTAL_OCTET family,
const SKTAL_OCTET code);
void GetOperation(bool& isNational,
SKTAL_OCTET& family,
// Parameter
SKTAL_OCTET& code) const;
void SetParameter(const SKTAL_OCTET* buf, const int len);
void GetParameter(SKTAL_OCTET* buf, int& len) const;
void SetParameter(const SKTAL_ByteArray& buf);
void GetParameter(SKTAL_ByteArray& buf) const;
// Timeout
void SetTimeOut(const SKTAL_USHORT val);
SKTAL_USHORT GetTimeOut() const;
// Operation class
502
SwitchKit TCAP Interface
// If defined(CCITT)
void SetClass(const SKTAL_USHORT val);
SKTAL_USHORT GetClass() const;
// Linked id (aka "correlation id")
void SetLinkedID(const SKTAL_OCTET val);
SKTAL_OCTET GetLinkedID() const;
void LinkInvoke(const TCAP_Invoke linkTo);
SetOperation()
Description
This method sets the operation field of an invoke component. The signature and
behavior of this method is different depending on the standard used. For national
use, the values of the operation family are defined in Appendix C.
Syntax
If defined ITU:
void SetOperation (const SKTAL_LONG code);
If defined ANSI:
void SetOperation (const bool isNational,
const SKTAL_OCTET family,
const SKTAL_OCTET code);
Input Parameters (ITU)
code: The operation code
Input Parameters (ANSI)
isNational: indicates whether this operation is national or private
family: the operation family
Input/Output Parameters and Output Parameters
None
Return Value
None
GetOperation()
Description
503
MSP
This method gets the operation field of an invoke component. The signature and
behavior of this method is different depending on the standard used. If the operation
is not present, an error code is returned.
Syntax
If defined ITU:
void GetOperation(SKTAL_LONG& code) const;
If defined ANSI:
void GetOperation(bool& isNational,
SKTAL_OCTET& family,
SKTAL_OCTET& code) const;
Input Parameters and Input/Output Parameters
None
Output Parameters (ITU)
code: The operation code
Output Parameters (ANSI):
isNational: indicates whether this operation is national or private
family: the operation family
code: the operation code
Return Value
None
SetParameter()
Description
This method copies a user-defined parameter into the invoke component. If an
invoke does not have User Payload, the user need not call this method; the
parameter is assumed to not be present unless this method is called with a non-zero
length. The default space for the "parameter". Parameter is 256 bytes.
Syntax
void SetParameter(const SKTAL_OCTET* buf, const int len);
void SetParameter(const SKTAL_ByteArray& buf);
Input Parameters
504
SwitchKit TCAP Interface
buf: a buffer containing the parameter to copy into this component
len: the length of the parameter in the buffer
Input/Output Parameters
None
Output Parameters
None
Return Value
None
GetParameter()
Description
This method copies the parameter in an invoke component into a user supplied
buffer. The len parameter will become an in/out parameter and should be set to the
maximum size of the buffer to copy to; this method will then check to make sure the
parameter to copy is smaller than the buffer supplied. Users should therefore set the
length now to avoid problems in the future.Returning a length of zero indicates that
no parameter is present.
Syntax
void GetParameter(SKTAL_OCTET* buf, int& len) const;
void GetParameter (SKTAL_ByteArray& buf) const;
Input Parameters
buf: a buffer to copy the parameter into
Input/Output Parameters
None
Output Parameters
len: The length of the parameter in the buffer
Return Value
None
505
MSP
SetTimeOut()
Description
Sets the timeout value for TCAP invokes. (ITU only.)
Syntax
void SetTimeOut(const SKTAL_USHORT val);
Input Parameters
val: The timeout value. Range is 1-500 seconds
Input/Output Parameters and Output Parameters
None
Return Value
None
GetTimeOut()
Description
Retrieves the timeout value for TCAP invokes. (ITU only.)
Syntax
SKTAL_USHORT GetTimeOut() const;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
The timeout value. Range is 1-500 seconds
SetClass()
Description
This method sets the operation class for TCAP components. The SetClass method is
for ITU TCAP only.
506
SwitchKit TCAP Interface
Syntax
void SetClass(const SKTAL_USHORT val);
Input Parameters
val: a number from 1 to 4 indicating the operation class:
Class 1 - Both success and failure are reported
Class 2 - Only failure is reported
Class 3 - Only success is reported
Class 4 - Neither success, nor failure is reported
Input/Output Parameters and Output Parameters
None
Return Value
None
GetClass()
Description
This method retrieves the operation class for TCAP invokes. The GetClass method is
for ITU TCAP only.
Syntax
SKTAL_USHORT GetClass() const;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
A number from 1 to 4 indicating the operation class:
Class 1 - Both success and failure are reported
Class 2 - Only failure is reported
Class 3 - Only success is reported
Class 4 - Neither success, nor failure is reported
SetLinkedID()
507
MSP
Description
This method sets the Linked ID (ITU) or Correlation ID (ANSI) to the value supplied.
The SetLinkedID method is not called if the Linked ID is not relevant. It is assumed
that no Linked ID is present unless this method is called.
Syntax
void SetLinkedID(const SKTAL_OCTET val);
Input Parameters
val: The linked ID value. Range is 0-255
Input/Output Parameters and Output Parameters
None
Return Value
None
HasLinkedID()
Description
HasLinkedId method returns true if linked ID (ITU) or correlation ID (ANSI).is
present in invoke operation.
Syntax
bool HasLinkedID();
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
true - Linked ID present.
false - Linked ID not present
GetLinkedID()
Description
508
SwitchKit TCAP Interface
This method gets the Linked ID (ITU) or Correlation ID (ANSI) of an invoke, if
supplied. If the invoke does not have a Linked ID, a Link ID of zero is returned.
Syntax
SKTAL_OCTET GetLinkedID() const;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
The linked ID as an unsigned character. Range is 0-255
LinkInvoke()
Description
This method sets the Linked ID (ITU) or Correlation ID (ANSI) to the Invoke ID from
the invoke component supplied. The LinkInvoke method is not called if the Linked ID
is not relevant. It is assumed that no Linked ID is present unless this method is
called.
Syntax
void LinkInvoke(const TCAP_Invoke* linkTo);
Input Parameters
linkTo: the invoke component to correlate to
Input/Output Parameters and Output Parameters
None
Return Value
None
Class TCAP_Reject : public TCAP_Component
Purpose
The purpose of the TCAP_Reject component is to define the basic interface to invalid
remote operation invokes. The remote stack responds with a TCAP_Reject when an
application sends a malformed component.
Summary of Methods
509
MSP
The TCAP_Reject component includes the following methods:
// Problem
// If defined(CCITT)
void SetProblem(const SKTAL_OCTET type, const SKTAL_OCTET code);
void GetProblem(SKTAL_OCTET& type, SKTAL_OCTET& code) const;
// If defined(ANSI)
void SetProblem(const SKTAL_OCTET family, const SKTAL_OCTET code);
void GetProblem(SKTAL_OCTET& family, SKTAL_OCTET& code) const;
// Parameter
// If defined(ANSI)
void GetParameter(SKTAL_OCTET* buf, int& len) const;
void SetParameter(const SKTAL_OCTET* buf, const int len);
void GetParameter(SKTAL_ByteArray& buf) const;
void SetParameter(const SKTAL_ByteArray& buf);
SetProblem()
Description
This method sets the problem code for a reject component. The signature of this
method depends on the standard used. Based on the reject code, it is the
responsibility of the application to take the appropriate action. Each reject type has
its own set of codes, or reasons for the component being rejected. The reject values
and codes are defined Appendix A.
Syntax
If defined as ITU:
void SetProblem(const SKTAL_OCTET type, const SKTAL_OCTET code);
Type: the reject type. Possible reject types are defined in Appendix A.
Code: the reject code
If defined as ANSI:
void SetProblem(const SKTAL_OCTET family,
const SKTAL_OCTET code);
family: the problem types. Problem types are defined in Appendix A.
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
None
510
SwitchKit TCAP Interface
GetProblem()
Description
This method gets the problem code for a reject component. The signature of this
method depends on the standard used. Based on the reject code, it is the
responsibility of the application to take the appropriate action. Each reject type has
its own set of codes, or reasons for the component being rejected. The reject values
and codes are defined in Appendix A.
Syntax
If defined ITU:
void GetProblem(SKTAL_OCTET& type, SKTAL_OCTET& code) const;
Type = the reject type. Possible reject types are defined in Appendix A.
Code = the reject code as defined in Appendix A.
If defined ANSI:
void GetProblem(SKTAL_OCTET& family, SKTAL_OCTET& code) const;
Input Parameters, Input/Output Parameters
None
Output Parameters
family: the problem types. Problem types are defined in Appendix A.
Return Value
None
Each reject type has its own set of codes or reasons for the component being
rejected. The reject values and codes are defined in the Appendix sections.
SetParameter()
Description
This method is applicable for ANSI TCAP. See Class TCAP_Invoke.
Syntax
See class TCAP_Invoke
void SetParameter(const SKTAL_OCTET* buf, const int len);
511
MSP
void SetParameter(const SKTAL_ByteArray& buf);
GetParameter()
Description
This method is applicable for ANSI TCAP. See Class TCAP_Invoke.
Syntax
See class TCAP_Invoke
void GetParameter(SKTAL_OCTET* buf, int& len) const;
void GetParameter(SKTAL_ByteArray& buf) const;
Class TCAP_ResetTimer : public TCAP_Component
The purpose of the TCAP_ResetTimer component defines the basic interface to reset
the timer of an invoked operation. This component is only valid with ITU White Book
97. The TCAP_ResetTimer component includes the following methods:
GetDialogueID()
Syntax
See class TCAP_Cancel
SKTAL_USHORT GetDialogueID() const;
Class TCAP_Result : public TCAP_Component
Purpose
The purpose of the TCAP_Result component is to define the basic interface to remote
operation results. This class is used to reply to successful invoke operations.
Summary of Methods
The TCAP_Result component includes the following methods:
// Operation
//If defined(CCITT)
void SetOperation(const SKTAL_LONG code);
void GetOperation(SKTAL_LONG& code) const;
// parameter
void SetParameter(const SKTAL_OCTET* buf, const int len);
void GetParameter(SKTAL_OCTET* buf, int& len) const;
void SetParameter(const SKTAL_ByteArray& buf);
void GetParameter(SKTAL_ByteArray& buf) const;
512
SwitchKit TCAP Interface
SetOperation()
Description
This method sets the operation field of a result component. The SetOperation
method is relevant only to ITU TCAP.
Syntax
void Set Operation(const SKTAL_LONG code);
Input Parameters
code: The operation code.
Input/Output Parameters and Output Parameters
None
Return Value
None
GetOperation()
Description
This method gets the operation field of an invoke component. The GetOperation
method is relevant only to ITU TCAP.
Syntax
void GetOperation(SKTAL_LONG& code) const;
Input Parameters and Input/Output Parameters
None
Output Parameters
code - The operation code
Return Value
None
SetParameter()
513
MSP
Description
Copies a user-defined parameter into the invoke component.
Syntax
See class TCAP_Invoke
void SetParameter(const SKTAL_OCTET* buf, const int len);
void SetParameter(const SKTAL_ByteArray& buf);
Input Parameters
buf - A buffer containing the parameter to copy into this component
len - The length of the parameter in the buffer.
Input/Output Parameters & Output Parameters
None
Return Value
None
GetParameter()
Description
Copies a user-defined parameter from the invoke component to a user supplied
buffer.
Syntax
void GetParameter(SKTAL_OCTET* buf, int& len) const;
void GetParameter(SKTAL_ByteArray& buf) const;
Input Parameters
buf: a buffer containing the parameter to copy into this component
Input/Output Parameters
None
Output Parameters
len - The length of the parameter in the buffer.
514
SwitchKit TCAP Interface
Return Value
None
ClassTCAP_Notice : public TCAP_Dialogue
Purpose
The purpose of the TCAP_Notice message class is to define the basic interface by
which TCAP can deliver quality-of-service messages to the user. At the present time,
this is implemented only for ITU TCAP, and is never generated by the user.
Summary of Methods
The TCAP_Notice message class includes the following methods:
// Component present
virtual bool IsComponentPresent() const
virtual void SetComponentPresent(bool)
// Report cause
void SetReportCause(SKTAL_OCTET reason);
SKTAL_OCTET GetReportCause() const;
// Quality of service
virtual void SetQualityOfService(const SKTAL_OCTET flags,
const SKTAL_OCTET priority = 0)
virtual void GetQualityOfService(SKTAL_OCTET& flags,
SKTAL_OCTET& priority) const;
// Application context
virtual void SetApplicationContext(const SKTAL_OCTET* buf, const int len);
virtual void GetApplicationContext(SKTAL_OCTET* buf, int& len) const;
virtual void SetApplicationContext(const SKTAL_ByteArray& buf);
virtual void GetApplicationContext(SKTAL_ByteArray& buf) const;
// User info
virtual void SetUserInfo(const SKTAL_OCTET* buf, const int len);
virtual void GetUserInfo(SKTAL_OCTET* buf, int& len) const;
virtual void SetUserInfo(const SKTAL_ByteArray& buf);
virtual void GetUserInfo(SKTAL_ByteArray& buf) const;
IsComponentPresent()
See class TCAP_Dialogue
Syntax
virtual bool IsComponentPresent() const;
515
MSP
SetComponentPresent()
See class TCAP_Abort
Syntax
virtual void SetComponentPresent(bool);
SetReportCause()
Description
This method can be used to set the report cause of a dialogue
Syntax
void SetReportCause(SKTAL_OCTET reason);
Input Parameters
reason: the report cause reason
Input/Output Parameters and Output Parameters
None
Return Value
None
GetReportCause()
Description
This method returns the report cause of a dialogue
Syntax
SKTAL_OCTET GetReportCause() const;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
516
SwitchKit TCAP Interface
The report cause as an unsigned character. The following are the report cause
values:
SCCP_RET_NO_TRANS_ADDR_NAT
SCCP_RET_NO_TRANS_THIS_ADDR
SCCP_RET_SUBSYS_CONG
SCCP_RET_SUBSYS_FAIL
SCCP_RET_UNEQUIPPED_USER
SCCP_RET_NETWORK_FAIL
SCCP_RET_NETWORK_CONG
SCCP_RET_UNQUAL
SCCP_RET_ERR_IN_TRANSPORT
SCCP_RET_ERR_IN_LOCAL_PROCESS
SCCP_RET_ERR_DEST_CANNOT_PERF_REASSEMBLY
SCCP_RET_ERR_SCCP_FAILURE (ITU Only)
SCCP_RET_ERR_HOP_COUNT_VIOLATION (ANSI only)
SCCP_RET_ERR_INV_ISNI_ROUT_REQ (ANSI only)
SCCP_RET_ERR_UNAUTH_MSG (ANSI only)
SCCP_RET_ERR_MSG_INCOMPATIBILITY (ANSI only)
SCCP_RET_ERR_CANNOT_PERFORM_ISNI_ROUTING (ANSI only)
SCCP_RET_ERR_REDUNDANT_ISNI_ROUTING_INFO (ANSI only)
SCCP_RET_ERR_UNABLE_TO_IDENTIFY_ISNI_INFO (ANSI only)
SetQualityOfService()
See class TCAP_Dialogue
Syntax
virtual void SetQualityOfService(const SKTAL_OCTET flags,
const SKTAL_OCTET priority = 0);
GetQualityOfService()
See class TCAP_Dialogue
Syntax
virtual void GetQualityOfService(SKTAL_OCTET& flags,
517
MSP
SKTAL_OCTET& priority) const;
SetApplicationContext()
See class TCAP_Dialogue
Syntax
virtual void SetApplicationContext(const SKTAL_OCTET* buf, const int len);
virtual void SetApplicationContext(const SKTAL_ByteArray& buf);
GetApplicationContext()
See class TCAP_Dialogue
Syntax
virtual void GetApplicationContext(SKTAL_OCTET* buf, int& len) const;
virtual void GetApplicationContext(SKTAL_ByteArray& buf) const;
SetUserInfo()
See class TCAP_Dialogue
Syntax
virtual void SetUserInfo(const SKTAL_OCTET* buf, const int len);
virtual void SetUserInfo(const SKTAL_ByteArray& buf);
GetUserInfo()
See class TCAP_Dialogue
Syntax
virtual void GetUserInfo(SKTAL_OCTET* buf, int& len) const;
virtual void GetUserInfo(SKTAL_ByteArray& buf) const;
TCAP_Unidirectional : public TCAP_Dialogue class
Purpose
518
SwitchKit TCAP Interface
The purpose of the TCAP_Unidirectional message class is to define the interface for
one-way transactions. Unidirectional messages are never replied to. This message
represents the TCPPT_TC_UNI dialogue type.
Summary of Methods
The TCAP_Unidirectional message class includes the following methods:
// Xcvr checks
virtual bool SendCheck() const;
virtual bool ReceiveCheck();
// Full SCCP Address (orig)
void SetOrigAddr(const bool isNational,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn);
void SetOrigAddr(const SCCP_Adddress& addr);
void GetOrigAddr(bool& isNational,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn) const;
void GetOrigAddr(SCCP_Address& addr) const;
// Full SCCP Address (des)
void SetDestAddr(const bool isNational,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn);
void GetDestAddr(SCCP_Address& addr) const;
SendCheck()
Syntax
See class TCAP_Dialogue
virtual bool SendCheck() const;
ReceiveCheck()
Syntax
See class TCAP_Dialogue
virtual bool ReceiveCheck();
SetOrigAddr()
Description
519
MSP
This method sets the origination address for this dialogue primitive from discrete
information.
Syntax
void SetOrigAddr(const bool isNational,
const SKTAL_UINT pointCode,
const SKTAL_OCTET ssn);
void SetOrigAddr(SKTAL_OCTET& addrInd,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn,
SKTAL_OCTET* gttInfo,
SKTAL_USHORT* gttLen) const;
void SetOrigAddr(const SCCP_Address& addr);
Input Parameters
isNational: A Boolean flag indicating if this address uses national or international
routing
pointCode: The Point Code of this address
ssn: The Subsystem Number of this address
gttInfo: The information of the address
gttLen: The length of the address
(SCCP_ADDR&)
addr: The SCCP_ADDR structure to copy into
(SCCP_Address&) addr: The SCCP_Address object to copy into
Input/Output Parameters and Output Parameters
None
Return Value
None
GetOrigAddr()
Description
This method decodes the origination address for this dialogue primitive into discrete
information.
520
SwitchKit TCAP Interface
Syntax
void GetOrigAddr(bool& isNational,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn) const;
void GetOrigAddr(SKTAL_OCTET& addrInd,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn,
SKTAL_OCTET* gttInfo,
SKTAL_USHORT* gttLen) const;
void GetOrigAddr(SCCP_Address& addr) const;
Input Parameters and Input/Output Parameters
None
Output Parameters
isNational: a Boolean flag indicating if this address uses national or international
routing
pointCode: the Point Code of this address
ssn: the Subsystem Number of this address
gttInfo: the information of the address
gttLen: the length of the address
(SCCP_ADDR&)
addr: the SCCP_ADDR structure to copy into
(SCCP_Address&) addr: the SCCP_Address object to copy into
Return Value
None
SetDestAddr()
Description
This method sets the destination address for this dialogue primitive from discrete
information
Syntax
void SetDestAddr(const bool isNational,
const SKTAL_UINT pointCode,
521
MSP
const SKTAL_OCTET ssn);
void SetDestAddr(SKTAL_OCTET addrInd,
SKTAL_UINT pointCode,
SKTAL_OCTT ssn,
SKTAL_OCTET* gttInfo,
SKTAL_USHORT* gttLen) const;
void SetDestAddr(const SCCP_Address& addr);
Input Parameters
isNational: a Boolean flag indicating if this address uses national or international
routing
pointCode: the Point Code of this address
ssn: the Subsystem Number of this address
gttInfo: the information of the address
gttLen: the length of the address
(SCCP_ADDR&)
addr: the SCCP_ADDR structure to copy into
(SCCP_Address&) addr: the SCCP_Address object to copy into
Input/Output Parameters and Output Parameters
None
Return Value
None
GetDestAddr()
Description
This method decodes the destination address for this dialogue primitive into discrete
information.
Syntax
void GetDestAddr(bool& isNational,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn) const;
void GetDestAddr(SKTAL_OCTET& addrInd,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn,
522
SwitchKit TCAP Interface
SKTAL_OCTET* gttInfo,
SKTAL_USHORT* gttLen) const;
void GetDestAddr(SCCP_Address& addr) const;
Input Parameters and Input/Output Parameters
None
Output Parameters
isNational: a Boolean flag indicating if this address uses national or international
routing
pointCode: the Point Code of this address
ssn: the Subsystem Number of this address
gttInfo: the information of the address
gttLen: the length of the address
(SCCP_ADDR&)
addr: the SCCP_ADDR structure to copy into
(SCCP_Address&) addr: the SCCP_Address object to copy into
Return Value
None
SKTAL Sample Application
Step One - Creating a connection with LLC using SwitchKit APIs
The API function described in this section allows you to create a connection with the
LLC using SwitchKit APIs.
Application Code
connect()
{
int ret;
/* create the connection */
connection = skts_createConnectionWithID(CONN_ID, CONN_LABEL, CONN_NAME,
SKTAL_FALSE,
PRI_IP, PRI_PORT,
if (ret == 0)
{
}
BACK_IP, BACK_PORT);
fprintf(stderr, "Error connecting to switch\n");
return (SKTAL_EINVALIDARGS);
523
MSP
}
return (SKTAL_SUCCESS);
Step Two - Initializing SKTAL and registering SSN
The API function described in this section initalizes TAL and registers with LLC for use
of a particular stack/SSN.
Application Code
// Initialize TAL layer. TAL initialization is done once
// at application startup.
ret = sktal_initializeTCAP()
if (ret != SK_OK)
{
fprintf(stderr, "Error initializing TCAP: %s\n", sk_errorText(ret));
skts_destroyConnection(CONN_ID);
}
return (SKTAL_EINVALIDARGS);
// register SSN with TCAP
// LOCAL_NODE - value created during configuration
// STACK_ID - Stack Id for the stack instance created during
//
configuration.
// CONN_ID - Same as created in step one.
// LOCAL_PC - Local Point Code for stack instance.
// LOCAL_SSN - local subsyatem number for stack instance.
// newDialogue - Deafult Handler for handling new
//
TCAP Transaction messages.
// instance - instance value returned after registeration is successful.
//
//
This instance value is used while sending and receiving TCAP
dialogues and components.
ret = sktal_registerTCAPSSNHandler (LOCAL_NODE, STACK_ID,
LOCAL_PC, LOCAL_SSN,
if (ret != SK_OK)
{
newDialogue, &instance, CONN_ID);
fprintf(stderr, "Error registering handler: %s\n", sk_errorText(ret));
skts_destroyConnection(CONN_ID);
Step Three - Sending a TCAP Dialogue and Component
The API function described in this section allows you to send a dialog and component
through SwitchKit to the SS7 network.
Application Code
// allocate dialogue id. instance value is returned during
524
SwitchKit TCAP Interface
// registration.
ret = sk_allocateTCAPDialogueID(instance, &did);
if (ret != SK_OK)
{
}
printf("Failed to allocate dialog id: %d\n", ret);
// Create TCAP Begin dialogue object
sktal::TCAP_Begin begin;
// populate orignating and destination
// point codes.
begin.SetOPC(LOCAL_PC);
begin.SetDPC(REMOTE_PC);
// populate orignating SCCP address
begin.SetOrigAddr(true, LOCAL_PC, LOCAL_SSN);
// Populate destination SCCP address.
begin.SetOrigAddr(true, LOCAL_PC, LOCAL_SSN);
// Populate destination SCCP address.
begin.SetDestAddr(true, REMOTE_PC, REMOTE_SSN);
// Set dialogue id allocated.
begin.SetDialogueID(did);
// Create TCAP invoke component instance.
sktal::TCAP_Invoke invoke;
invoke.SetOperation(true, 1, 1);
// Set invoke id.
invoke.SetInvokeID(1);
// set invoke timeout.
invoke.SetTimeOut(20);
// Set encoded parameters of TCAP User part
// API's like ANSI-41, MAP, CAMEL etc.
invoke.SetParameter(encodedParam);
// Send TCAP Component
ret = sktal::TCAP_Component::Send(sktal_getTCAPHandle(instance),
&begin, &invoke);
if (ret != SKTAL_SUCCESS)
{
}
printf("Failed to send component: %d\n", ret);
else
{
// Send TCAP dialogue.
ret = sktal::TCAP_Dialogue::Send(sktal_getTCAPHandle(instance),
525
MSP
&begin);
if (ret != SKTAL_SUCCESS)
{
}
}
printf("Failed to send dialogue: %d\n", ret);
Step Four - Receiving a TCAP Transaction
The API function described in this section allows you to receive a TCAP transaction
from the SS7 network via SwitchKit.
Application Code
Transactions are received via dialogue handler and registered with SKTAL. Sample
implementation for dialogue handler is shown in the following code excerpt.
i/*
* new dialogue handler
*/
extern "C" int
newDialogue(int instance, unsigned newDID)
{
printf("NEW DIALOGUE: %08x\n", newDID);
// register a message handler for new dialogue.
return sktal_setTCAPDialogHandler(instance, newDID,
onMessage, NULL);
}
/*
* Message handler.
*/
extern "C" int
onMessage(int instance, SKTAL_EVENT *ev, void *tag)
{
static sktal::TCAP_Dialogue *dlg = NULL;
SKTAL_CPT cpt;
sktal::Event event;
unsigned did;
printf("ON MESSAGE\n");
if (TCAP_MSG_TYPE(ev) == SKTAL_TCAP_DLG)
{
event = ev;
sktal::TCAP_Dialogue::Receive(sktal_getTCAPHandle(instance),
event, &dlg);
526
SwitchKit TCAP Interface
if (dlg)
{
}
}
dlg->Print(std::cout);
else if (TCAP_MSG_TYPE(ev) == SKTAL_TCAP_CPT)
{
printf("Got component\n");
sktal::TCAP_Component *result;
event = ev;
sktal::TCAP_Component::Receive(sktal_getTCAPHandle(instance),
event, dlg, &result);
result->Print(std::cout);
delete result;
delete dlg;
}
dlg = NULL;
else
{
}
fprintf(stderr, "Unknown message type: %d\n", TCAP_MSG_TYPE(ev));
printf("RETURN FROM USER HANDLER\n");
}
return (SK_OK);
}
Step Five - Terminating SKTAL and Disconnection
The API function described in this section is used to terminate a SwitchKit TCAP
Abstraction Layer and disconnect from the LLC.
Application Code
// Unregister SSN instance.
if (instance >= 0)
{
}
sktal_unregisterTCAPSSNHandler (instance);
instance = -1;
// Terminate SKTAL
stalk_terminateTCAP();
// disconnect
if (connection)
{
527
MSP
skts_destroyConnection(CONN_ID);
}
connection = NULL;
Appendix A TCAP Codes
ANSI TCAP Codes
Purpose
Refer to the following tables for the ANSI TCAP codes.
Table A-1> ANSI TCAP Operation Family
Name
Value
Description
TCPPN_OF_REPLY_REQUIRED
0x80
Operation family reply
required.
TCPPN_OF_NOT_USED
0x0
TCPPN_OF_PARAMETER
0x01
TCPPN_OF_CHARGING
0x02
TCPPN_OF_PROV_INST
0x03
TCPPN_OF_CONN_CTRL
0x04
TCPPN_OF_CALLER_INT
0x05
TCPPN_OF_SEND_NOT
0x06
TCPPN_OF_NET_MAN
0x07
TCPPN_OF_PROCEDURAL
0x08
TCPPN_OF_IS41
0x09
TCPPN_OF_RESERVED
0xFF
TCPPN_OF_MISC
0xFE
Operation family
parameter.
Operation family
charging.
Operation family
provisioning instruction.
Operation family
connection control.
Operation family caller
inter.
Operation family send
notification.
Operation family
network management.
Operation family
procedural.
Operation family IS41.
Operation family Misc.
Table A-2> ANSI TCAP Operation Specifier
Name
TCPPN_OS_PROV_VAL
528
Value
0x01
Description
Operation specifier
provision value.
SwitchKit TCAP Interface
TCPPN_OS_SET_VAL
0x02
TCPPN_OS_BILL_CALL
0x01
TCPPN_OS_START
0x01
TCPPN_OS_CONN
0x01
TCPPN_OS_ASSIST
0x02
TCPPN_OS_TEMP_CONN
0x02
TCPPN_OS_DISCONN
0x03
TCPPN_OS_FWD_DISCONN
0x04
TCPPN_OS_PLAY_A
0x01
TCPPN_OS_PLAY_A_CD
0x02
TCPPN_OS_AUTO_CALL_GAP
0x01
TCPPN_OS_TEMP_HO
0x01
provision value.
Operation specifier set
value.
Operation specifier bill
call.
Operation specifier start.
Operation specifier start.
Operation specifier
connection.
Operation specifier
temporary connection.
Operation specifier
dsconnect.
Operation specifier
forward disconnect.
Operation specifier play
announcement.
Operation specifier play
announcement.
Operation specifier
automatic call gap.
Table A-3> ANSI TCAP P-Abort Reason
Name
Value
Description
TCPABT_REASON_INCORRECT_TRANS_PORT
0x02
TCPABT_REASON_BADLY_STRUCT_TRANS_PORT
0x03
Incorrect
Transaction
portion.
TCPABT_REASON_UNREC_TRANS_ID
0x04
TCPABT_REASON_PERM_TO_RELEASE
0x05
TCPABT_REASON_RES_UNAVAIL
0x06
TCPABT_REASON_UNREC_PACK_TYPE
0x01
Unrecognized
package type.
Badly structured
transaction
portion.
Unrecognised
transaction Id.
Permission To
release.
Resource
unavailable.
529
MSP
Table A-4> ANSI TCAP Error Codes
Name
Value
Description
TCPERR_UNEX_DATA_VAL
0x02
Unexpected data value
TCPERR_MISSING_REC
0x04
TCPERR_UNEX_COMP_SEQ
TCPERR_UNAV_RESOURCE
TCPERR_REPLY_OVERDUE
TCPERR_DATA_UNAV
TCPERR_TSK_RE
TCPERR_Q_FULL
TCPERR_NO_Q
TCPERR_TMR_EX
TCPERR_DAT_EX
TCPERR_UNAUTH
TCPERR_NOT_QD
TCPERR_UAS_DN
TCPERR_SPARE
TCPERR_NOT_AV
TCPERR_VMSR_E
0x01
0x03
0x05
0x06
0x07
Unexpected component
sequence
Unavailable resource
Missing record
Reply overdue
Data unavailable
0x08
Queue full
0x0A
Timer expiry
0x09
0x0B
0x0C
0x0D
0x0E
0x0F
0x10
0x11
No queue
Data already exists
Unauthorised Request
Not queued
Unassigned DN
Spare
Not Available
VMSR error
Table A-5> ANSI TCAP Problem Code Specifier
Name
Value
Description
TCPPROB_INVOKE
0x02
TCPPROB_RETURN_RES
0x03
Invoke
Problem.
TCPPROB_RETURN_ERR
0x04
TCPPROB_TRANS_PORTION
0x05
TCPPROB_GENERAL
530
0x01
General
Problem.
Return Result
Problem.
Return Error
Problem.
Transaction
Portion
Problem.
SwitchKit TCAP Interface
Table A-6> ANSI TCAP Problem Codes
Name
Value
Description
TCPPROB_SPEC_GEN_INCORRECT_COMP
0x02
TCPPROB_SPEC_GEN_BADLY_STRUCT_COMP
0x03
General
problem
incorrect
component
TCPPROB_SPEC_INV_DUPLICATE_INV_ID
0x01
TCPPROB_SPEC_INV_UNREC_OP_CODE
0x02
TCPPROB_SPEC_INV_INCORRECT_PARAM
0x03
TCPPROB_SPEC_INV_UNREC_COREL_ID
0x04
TCPPROB_SPEC_RES_UNREC_COREL_ID
0x01
TCPPROB_SPEC_RES_UNEXPECTED_RET_RES
0x02
TCPPROB_SPEC_RES_INCORRECT_PARAM
0x03
TCPPROB_SPEC_ERR_UNREC_COREL_ID
0x01
TCPPROB_SPEC_GEN_UNREC_COMP
0x01
General
problem
unrecognised
component
General
problem badly
structured
component
Invoke
problem
duplicate
invoke id
Invoke
problem
unrecognized
operation code
Invoke
problem
incorrect
parameter
Invoke
problem
unknown
correlation id.
Result
problem
unrecognized
correlation id.
Result
problem
unexpected
return result
Result
problem
incorrect
parameter
Error problem
unrecognized
correlation id
531
MSP
TCPPROB_SPEC_ERR_UNEXPECTED_RET_ERROR
0x02
TCPPROB_SPEC_ERR_UNREC_ERROR
0x03
TCPPROB_SPEC_ERR_UNEXPECTED_ERROR
0x04
TCPPROB_SPEC_ERR_INCORRECT_PARAM
0x05
TCPPROB_SPEC_TRANS_UNREC_PACK_TYPE
0x01
TCPPROB_SPEC_TRANS_INCORRECT_TRANS_PORT
0x02
TCPPROB_SPEC_TRANS_BADLY_STRUCT_TRANS_PORT
0x03
TCPPROB_SPEC_TRANS_UNREC_TRANS_ID
0x04
TCPPROB_SPEC_TRANS_PERM_TO_RELEASE
0x05
TCPPROB_SPEC_TRANS_RES_UNAVAIL
0x06
ITU TCAP Codes
Purpose
Refer to the following tables for the CCITT TCAP codes.
Table A-7> ITU TCAP User Abort Reason
Name
Value
Description
TCPUABT_USER_DEFINED
0x02
TCPUABT_DLG_REFUSED
0x03
Reason user
defined.
TCPUABT_AC_NOT_SUP
0x01
Application context
not supported.
Dialogue refused.
Table A-8> TU TCAP P-Abort Reason
532
Error problem
unexpected
return error
Error problem
unrecognized
error
Error problem
unexpected
error
Error incorrect
parameter
Unrecognised
package type
Incorrect
transaction
Portion
Badly
structured
transaction
Unrecognised
transaction ID
Permission To
release
Resource
unavailable
SwitchKit TCAP Interface
Name
Value
Description
TCPPABT_NO_COMMON_DLG
127
TCPABT_REASON_UNREC_MSG_TYPE
0x00
No common
dialog.
TCPABT_REASON_UNREC_TRANS_ID
0x01
TCPABT_REASON_BADLY_STRUCT_TRANS_PORT
0x02
TCPABT_REASON_INCORRECT_TRANS_PORT
0x03
TCPABT_REASON_RES_UNAVAIL
0x04
TCPPABT_ABNORMAL_DLG
126
Abnormal
dialogue.
Unrecognized
message type.
Unrecognized
transaction Id.
Badly structured
transaction
portion.
Incorrect
trnsaction
portion.
Resource
unavailable.
Table A-9> ITU TCAP Reject Problem Types
Name
Value
Description
TCPPROB_INVOKE
0x01
TCPPROB_RETURN_RES
0x02
Invoke
problem.
TCPPROB_RETURN_ERR
0x03
TCPPROB_GENERAL
0x00
General
problem.
Return
Result
problem.
Return Error
problem
Table A-10> ITU TCAP Reject Problem Codes
Name
Value
Description
TCPPROB_SPEC_GEN_MISTYPED_COMP
0x01
General problem
mistyped
component.
TCPPROB_SPEC_GEN_UNREC_COMP
0x00
General problem
unrecognized
component.
533
MSP
TCPPROB_SPEC_GEN_BADLY_STRUCT_COMP
0x02
TCPPROB_SPEC_INV_DUPLICATE_INV_ID
0x00
TCPPROB_SPEC_INV_UNREC_OP_CODE
0x01
TCPPROB_SPEC_INV_MISTYPED_PARAM
0x02
TCPPROB_SPEC_INV_RESOURCE_LIMIT
0x03
TCPPROB_SPEC_INV_INITIATE_RELEASE
0x04
TCPPROB_SPEC_INV_UNREC_LINKED_ID
0x05
TCPPROB_SPEC_INV_UNEXPECTED_LINK_RESP
0x06
TCPPROB_SPEC_INV_UNEXPECTED_LINKED_OP
0x07
TCPPROB_SPEC_RES_UNREC_INVOKE_ID
0x00
TCPPROB_SPEC_RES_UNEXPECTED_RET_RES
0x01
TCPPROB_SPEC_RES_MISTYPED_PARAM
0x02
TCPPROB_SPEC_ERR_UNREC_INVOKE_ID
0x00
TCPPROB_SPEC_ERR_UNEXPECTED_RET_ERROR
0x01
TCPPROB_SPEC_ERR_UNREC_ERROR
0x02
TCPPROB_SPEC_ERR_UNEXPECTED_ERROR
0x03
TCPPROB_SPEC_ERR_MISTYPED_PARAM
0x04
534
General problem
badly structured
component.
Invoke problem
duplicate invoke id.
Invoke problemunrecognized
operation code.
Invoke problem
mistyped parameter.
Invoke problem
resource limitation.
Invoke problem
initiate release.
Invoke problemunrecognized linked
id.
Invoke problem
unexpected linked
response.
Invoke problem
unexpected linked
operation.
Result problem
unrecognized invoke
id.
Result problem
unexpected return
result.
Result problem
mistyped parameter.
Error problem
unrecognized invoke
id.
Error problem
unexpected return
error.
Error problem
unrecognized error.
Error problem
unexpected error.
Error problem
mistyped parameter.
SwitchKit TCAP Interface
mistyped parameter.
Appendix B- SKIM Data Types and Codes
This appendix provides information on SKIM data types and error codes.
SKIM Data Types and Codes
Purpose
This section provides information on SKIM data types and error codes.
Table B-1> SKIM Data Types
Data Types
SKIM_BOOLEAN
SKIM_OCTET
SKIM_USHORT
SKIM_UINT
SKIM_ULONG
SKIM_CHAR
SKIM_SHORT
SKIM_INT
SKIM_LONG
System
Data Type
unsigned
int.
unsigned
char.
unsigned
short.
unsigned
int.
unsigned
long.
char
short
int
long
Table B-2> SKIM Return Codes
Error Codes
Values
SKIM_FALSE
0
SKIM_SUCCESS
SKIM_TRUE
SKIM_ENOMEM
SKIM_ERCVFAIL
SKIM_ENOMSG
0
0x1
-1
-6
-8
535
MSP
SKIM_ESENDFAIL
-9
SKIM_BADTCAPMESSAGE
-16
SKIM_ETCAPMSGSENDFAIL
SKIM_ETOOMANYDIALOGS
SKIM_ENOINVID
SKIM_ENOMUTEX
SKIM_EBADMUTEX
SKIM_EINVALIDARGS
SKIM_ENOLICENSE
SKIM_EPROTERR
SKIM_EOVERFLOW
SKIM_EINITFAIL
SKIM_EINUSE
SKIM_EDESTPROHIBIT
SKIM_EINVPTYPE
SKIM_EINVOPFAM
SKIM_EINVOPSPEC
SKIM_EINVLEN
SKIM_ENULLPTR
SKIM_EBADSTATE
SKIM_ENOTFOUND
SKIM_EASNENCODE
SKIM_EASNDECODE
SKIM_EINVOPC
SKIM_EINVDPC
SKIM_EINVINITSTATE
-13
-18
-20
-24
-25
-39
-45
-46
-49
-52
-55
-56
-57
-58
-59
-60
-61
-64
-65
-66
-67
-72
-73
-86
Appendix C - SKTAL Data Types and Codes
This appendix provides information on SKTAL data types and error codes.
SKTAL Data Types
Purpose
This section provides information on SKTAL data types and error codes.
536
SwitchKit TCAP Interface
Table C-1> SKTAL Data Types
Data Types
Description
SKTAL_OCTET
unsigned char.
SKTAL_BOOLEAN
SKTAL_USHORT
SKTAL_UINT
SKTAL_ULONG
SKTAL_CHAR
SKTAL_SHORT
SKTAL_INT
SKTAL_LONG
SKTAL_HANDLE
SKTAL_POINTER
SKTAL_ByteArray
unsigned int.
unsigned short.
unsigned int.
unsigned long.
char
short
int
long
void
char
vector
<SKTAL_OCTET>
SKTAL Event
typedef struct
{
SKTAL_USHORT len; /* length of event data */
SKTAL_USHORT src; /* not Used */
ITS_OCTET* data; /* Event data containing TCAP dialog or Component
}
* Information */
To distinguish between TCAP dialog events and TCAP Component Events use the
following macros:

#define TCAP_MSG_TYPE(ev)

#define SKTAL_TCAP_CPT

#define SKTAL_TCAP_DLG
Table C-2 SKTAL Return Codes
1
((ev)->data[0])
2
Code
Value
SKTAL_FALSE
0
SKTAL_SUCCESS
0
537
MSP
SKTAL_TRUE
0x1
SKTAL_ENOMEM
-1
SKTAL_BITS_PER_BYTE
SKTAL_ERCVFAIL
SKTAL_ENOMSG
SKTAL_ESENDFAIL
SKTAL_ETCAPMSGSENDFAIL
SKTAL_BADTCAPMESSAGE
SKTAL_ETOOMANYDIALOGS
SKTAL_ENOINVID
SKTAL_ENOMUTEX
SKTAL_EBADMUTEX
SKTAL_EINVALIDARGS
SKTAL_ENOLICENSE
SKTAL_EPROTERR
SKTAL_EOVERFLOW
SKTAL_EINITFAIL
SKTAL_EINUSE
SKTAL_EDESTPROHIBIT
SKTAL_EINVPTYPE
SKTAL_EINVOPFAM
SKTAL_EINVOPSPEC
SKTAL_EINVLEN
SKTAL_ENULLPTR
SKTAL_EBADSTATE
SKTAL_ENOTFOUND
SKTAL_EASNENCODE
SKTAL_EASNDECODE
SKTAL_EINVOPC
SKTAL_EINVDPC
SKTAL_EINVINITSTATE
SKTAL_ALREADY_REGISTERED
538
8
-6
-8
-9
-13
-16
-18
-20
-24
-25
-39
-45
-46
-49
-52
-55
-56
-57
-58
-59
-60
-61
-64
-65
-66
-67
-72
-73
-86
-121
SwitchKit TCAP Interface
SKTAL_STACK_IN_USE
-122
SKTAL_NO_MORE_DIDS
-124
SKTAL_NO_MORE_STACKS
-123
SKTAL_INVALID_ARG
-125
SKTAL_BAD_MUTEX
-126
Appendix D - SKTAL Dialog and Component Structure Definitions
This appendix provides information on SKTAL dialog and component structure
definitions.
SKTAL_DLG and SKTAL_CPT Structure Definitions
/*
* Quality of service indicator octet definitions:
* (To select more than one option OR together options)
*/
#define QOSI_RET_OPT (0x01) /* Return Option */
#define QOSI_SEQ_CTRL (0x02) /* Sequence Control */
#define QOSI_SLS_KEY (0x04) /* SLS key present */
#define QOSI_PRIORITY (0x08) /* Message priority octet present */
#define QOSI_NETWK_IND (0x10) /* Use provided network indicator */
#define QOSI_PROT_VER (0x20) /* Force inclusion of the TCAP ver */
/*
* TCAP_PN_TERMINATION Values:
*/
#define TCAP_END_BASIC (0) /* Basic end */
#define TCAP_END_PREARRANGED (1) /* Pre-arranged end */
/*
* TCAP_PN_CPT_PRESENT Values:
*/
#define TCAP_NO_CPT (0) /* No component(s) present */
#define TCAP_CPT_PRESENT (1) /* Component(s) present */
/*
* TCAP_PN_LAST_CPT Values:
*/
#define TCAP_MORE_CPTS (0) /* More component(s) to follow */
#define TCAP_LAST_CPT (1) /* This is the last component */
#define TCPEND_BASIC TCAP_END_BASIC
#define TCPEND_PREARRANGED
#define TCP_NO_CPT
TCAP_END_PREARRANGED
TCAP_NO_CPT
539
MSP
#define TCP_CPT_PRESENT
#define TCP_MORE_CPTS
#define TCP_LAST_CPT
TCAP_CPT_PRESENT
TCAP_MORE_CPTS
TCAP_LAST_CPT
/* Size values for Manual TCAP Parser */
#define MAX_TCAP_CPT_SIZE (304)
#define MAX_NO_OF_TCAP_CPTS (4)
#define MAX_TCAP_DLG_SIZE (336)
#define MAX_TCAP_TRANS_SIZE \
(MAX_TCAP_DLG_SIZE + (MAX_TCAP_CPT_SIZE * MAX_NO_OF_TCAP_CPTS))
/********************************************************************
*
*
*
Structure definitions for Component Primitives
*
*
*
********************************************************************/
/*
* Definitions for buffer sizes in the 'C' structured
* representation of TCAP protocol primitives.
*
* Each value must allow space for the tag, length and associated data to be stored.
* The user may need to change the values given in
* order to support larger parameters or to reduce
* the size of the structures if it is known that
* certain parameters lengths will never be exceeded.
*/
#define IV_SIZE (4) /* space for 'invoke_id' parameter */
#define OP_SIZE (32) /* space for 'operation' parameter */
#define PR_SIZE (256) /* space for 'parameter' parameter */
#define ER_SIZE (32) /* space for 'error' parameter */
#define PB_SIZE (16) /* space for 'problem' parameter */
#define AC_SIZE (64)/* space for 'ac_name' parameter */
#define UI_SIZE (256) /* space for 'user_info' parameter */
#define AB_SIZE (256) /* space for 'abt_info' parameter */
/*
* Substructures for Components
*/
typedef struct cpt_inv_id
{
}
SKTAL_USHORT len;
SKTAL_OCTET data [IV_SIZE];
540
SwitchKit TCAP Interface
CPT_INV_ID;
typedef struct cpt_op
{
}
SKTAL_USHORT len;
SKTAL_OCTET data [OP_SIZE];
CPT_OP;
typedef struct cpt_param
{
}
SKTAL_USHORT len;
SKTAL_OCTET data [PR_SIZE];
CPT_PARAM;
typedef struct cpt_error_code
{
}
SKTAL_USHORT len;
SKTAL_OCTET data [ER_SIZE];
CPT_ERROR_CODE;
typedef struct cpt_problem
{
}
SKTAL_USHORT len;
SKTAL_OCTET data [PB_SIZE];
CPT_PROBLEM;
/*
* Invoke primitive. REQ and IND
* Invoke not last primitive. REQ and IND
*/
typedef struct cpt_invoke
{
CPT_INV_ID invoke_id;
CPT_OP operation;
CPT_PARAM param;
#if defined(CCITT)
SKTAL_USHORT opClass; /* 1, 2, 3 or 4 */
#dendif
SKTAL_USHORT timeout; /* 0 .. 409 */
CPT_INV_ID linked_id;
#define correlation_id linked_id /* FOR ANSI */
}
541
MSP
CPT_INVOKE;
/*
* Return result last primitive. REQ and IND
* Return result not last primitive. REQ and IND
*/
typedef struct cpt_result
{
CPT_INV_ID invoke_id;
#if defined(CCITT)
CPT_OP operation;
#endif
}
CPT_PARAM param;
CPT_RESULT;
/*
* User error primitive. REQ and IND
*/
typedef struct cpt_error
{
CPT_INV_ID invoke_id;
CPT_ERROR_CODE error;
}
CPT_PARAM param;
CPT_ERROR;
/*
* User reject primitive. REQ and IND
* Local reject primitive. IND only.
* Remote reject primitive. IND only.
*/
typedef struct cpt_reject
{
CPT_INV_ID invoke_id;
CPT_PROBLEM problem;
#if defined(ANSI)
CPT_PARAM param;
#endif
}
CPT_REJECT;
/*
* User cancel primitive. REQ only.
* Local cancel primitive. IND only.
542
SwitchKit TCAP Interface
*/
typedef struct cpt_cancel
{
}
CPT_INV_ID invoke_id;
CPT_CANCEL;
/*
* Timer Reset primitive (ITU White Book 97 only). REQ only.
*/
#if defined(CCITT)
typedef struct cpt_timerReset
{
}
CPT_INV_ID invoke_id;
CPT_TIMER_RESET;
#endif
/*
* Union of all of the above
*/
typedef struct tcap_cpt
{
SKTAL_USHORT last_component; /* either 0 or non-zero */
SKTAL_USHORT ptype; /* prim type (TCPPT_xxx values) */
Union
{
CPT_INVOKE invoke;
CPT_RESULT result;
CPT_ERROR error;
CPT_REJECT reject;
CPT_CANCEL cancel;
#if defined(CCITT)
CPT_TIMER_RESET timerReset;
#endif
}
}
u;
TCAP_CPT;
/********************************************************************
*
*
*
*
Structure definitions for Dialogue Primitives
*
*
543
MSP
********************************************************************/
/*
* Dialog substructures
*/
typedef struct dlg_qos
{
SKTAL_OCTET indicator;
SKTAL_OCTET sls_key;
SKTAL_OCTET priority;
}
SKTAL_OCTET networkInd;
DLG_QOS;
typedef struct ac_name
{
}
SKTAL_USHORT len;
SKTAL_OCTET data [AC_SIZE];
DLG_AC_NAME;
typedef struct usr_inf
{
}
SKTAL_USHORT len;
SKTAL_OCTET data [UI_SIZE];
DLG_USR_INF;
typedef struct abt_inf
{
}
SKTAL_USHORT len;
SKTAL_OCTET data[AB_SIZE];
DLG_ABT_INF;
/*
* ITU and ANSI UNI. REQ and IND.
*/
typedef struct dlg_uni
{
SKTAL_USHORT cpt_present; /* 0 or 1 */
DLG_QOS qos;
DLG_AC_NAME ac_name;
DLG_USR_INF user_info;
SCCP_ADDR orig_addr;
SCCP_ADDR dest_addr;
544
SwitchKit TCAP Interface
MTP3_POINT_CODE opc; /* for use when address doesn't include */
}
MTP3_POINT_CODE dpc; /* for use when address doesn't include */
DLG_UNI;
/*
* ITU BEGIN, ANSI QUERY W/PERM and WO/PERM. REQ and IND.
*/
typedef struct dlg_begin
{
SKTAL_USHORT cpt_present; /* 0 or 1 */
DLG_QOS qos;
DLG_AC_NAME ac_name;
DLG_USR_INF user_info;
SCCP_ADDR orig_addr;
SCCP_ADDR dest_addr;
MTP3_POINT_CODE opc; /* for use when address doesn't include */
}
MTP3_POINT_CODE dpc; /* for use when address doesn't include */
DLG_BEGIN;
/*
* ITU CONTINUE, ANSI CONV W/PERM and WO/PERM. REQ and IND.
*/
typedef struct dlg_continue
{
SKTAL_USHORT cpt_present; /* 0 or 1 */
DLG_QOS qos; /* Indication only. Ignore for request */
DLG_AC_NAME ac_name;
DLG_USR_INF user_info;
SCCP_ADDR orig_addr;
}
MTP3_POINT_CODE opc; /* for use when address doesn't include */
DLG_CONTINUE;
/*
* ITU END, ANSI RESP. REQ and IND.
*/
typedef struct dlg_end
{
SKTAL_USHORT cpt_present; /* 0 or 1 */
DLG_QOS qos; /* Indication only. Ignore for request */
DLG_AC_NAME ac_name;
DLG_USR_INF user_info;
545
MSP
}
SKTAL_OCTET termination; /* 0 or 1 */
DLG_END;
/*
* ITU U-ABORT. REQ only.
* ITU P-ABORT. IND only.
* ANSI ABORT, IND only.
*/
typedef struct dlg_abort
{
SKTAL_USHORT abort_reason;
DLG_QOS qos; /* Indication only. Ignore for request */
DLG_AC_NAME ac_name; /* P-ABORT does not include this */
DLG_USR_INF user_info; /* P-ABORT does not include this */
}
DLG_ABT_INF abort_info; /* ANSI only */
DLG_ABORT;
/*
* ITU NOTICE and ANSI NOTICE. IND only (based on QOS return option).
*/
typedef struct dlg_notice
{
SKTAL_OCTET report_cause;
SKTAL_OCTET user_data_len; /* Presence depends on manufacturer */
SCCP_ADDR orig_addr; /* Presence depends on manufacturer */
SCCP_ADDR dest_addr; /* Presence depends on manufacturer */
}
SCCP_DATA user_data; /* Presence depends on manufacturer */
DLG_NOTICE;
/*
* Union of above types
*/
typedef struct tcap_dlg
{
SKTAL_USHORT
Union
{
ptype; /* primitive type (TCPPT_xxx values) */
DLG_UNI uni;
DLG_BEGIN begin;
DLG_CONTINUE cont;
546
SwitchKit TCAP Interface
DLG_END end;
DLG_ABORT abort;
}
}
DLG_NOTICE notice;
u;
SKTAL_DLG;
Appendix E - SKIM and SKTAL API Integration with IntelliNet Codecs
This appendix describes the integration of SKIM and SKTAL API with IntelliNet
Technologies’ codecs. A step-by-step sequence is provided to facilitate the
integration.
Use these documents as required:
Intellinet Codec Installation Guide
WIN User's Guide
CAMEL User's Guide
INAP User's Guide
UMTS MAP User's Guide
ANSI 41D User's Guide
Integrating SKIM and SKTAL API with IntelliNet Codecs
Steps
Follow these steps to integrate SKIM and SKTAL API with IntelliNet codecs.
1. Install the SKIM and SKTAL API.
uncompress <Filename>
tar -xvf <Filename>
2. Install a codec.
The codecs available from Cantata Technology are:

Customized Application for Mobile network Enhanced Logic (CAMEL)

ANSI - 41


Universal Mobile Telecommunications System- Mobile Application Part (UMTSMAP) which includes Global System for Mobile communication - Mobile
Application Part (GSM-MAP)
Wireless Intelligent Network (WIN)
For installation instructions on these codecs see, the following documents (available
from Cantata Technology):

CAMEL User’s Guide, document part number P_EXCL_CAMEL_UG_2.0
547
MSP

UMTS MAP User’s Guide, document part number P_EXCL_UMTS_MAP_UG_2.0

ANSI 41D User’s Guide, document part number P_EXCL_AS41D_UG_2.0

WIN User’s Guide, document part number P_EXCL_WIN_UG_2.0
The default directory for a codec is: /opt/Intellinet/<CODEC>/
Note



If you have installed the CCITT based codec, the codec header files get
installed under /opt/IntelliNet/<CODEC>/include/itu/ directory.
If you have installed the ANSI based codec, the codec header files get
installed under /opt/IntelliNet/<CODEC>/include/ansi/ directory.
The Codec library files get installed under /opt/IntelliNet/<CODEC>/lib/
directory
3. Build a provided sample application.
Open the relevant makefile. For a sample SKIM application, use the steps described
in Chapter 4. The SKIM sample application files, test1.cpp and test2.cpp, can be
found in the directory:
$ITS_ROOT/SKIM/TEST
For a sample SKTAL sample application, use the steps described in Chapter 7. The
SKTAL sample application files, test1.cpp and test2.cpp, can be found in the
directory:
$ITS_ROOT/TAL/TEST
For the sample application to use the installed codec, modify the makefile to link the
codec header files and codec library files pointing to the directory chosen in Step 2.
4. Compile
Compile the sample application using the makefile.
5. IntelliNet Codec
Before running the sample application, which uses one of the IntelliNet codecs,
download the IntelliNet codec license file its.lic to the directory where the sample
application executable is started.
548
Developer Information
Developer Licensing
General Licensing Information
Scalability
Product licensing lets you start with a more affordable set of core features. As your
revenues and requirements grow, you can purchase licenses for additional hardware
and software modules.
What You Can License
You can license features per Excel MSP or in smaller units. Some licenses are
installed on the host computer and remain on the host computer. Other licenses are
downloaded from the host computer to the MSP using the Excel API.
Licenses Installed on the Host Computer


SwitchKit
Refer SwitchKit Software Licensing in the SwitchKit Installation and
Maintenance Guide.
IN and Wireless protocol stacks
Refer to Licensing of Intelligent Network and Wireless Protocols in the IN
Wireless Protocols Overview.
Licenses Downloaded to the MSP

System Software per MSP (includes four signaling spans)

Base SS7 MTP2/MTP3 License per MSP










SCCP/TCAP per MSP
SS7 Monitoring
Number of SS7 links
ISUP licensed per CIC
Call Control licensed by channel manager license
DSP Resource Points
E1/T1 spans - per 96 DS0 channels (same license applied for DS3 I/O)
SwitchKit
IN and Wireless protocol stacks
VoIP
Related Topics
System Software Licensing
549
MSP
Software Modules Licensing
SS7 Links Licensing
Licensing Information (ClientView)
Introduction to SS7 Monitoring
Resource Points
Configuring Licensing
VoIP Licensing
System Software Licensing
The System Software License is based on a combination of the MSP I/O card serial
number and the System Software release number. For future releases, you must
download a new license.
System Software Licensing is an evolution from existing Excel licensing models. Excel
already licenses software functions, such as SS7 User Parts. Excel’s licensing has
always provided flexibility by allowing you to pay for only as much capacity as you
currently need (such as SS7 links) with the ability to buy more capacity as your
needs grow.
The System Software License applies to your base System Software load and to
System Software upgrades.
Software Modules Licensing
Overview
For software modules, you must provide the serial number from the MSP I/O card.
After the software module is enabled, it is available to all system hardware.
You can license the following software modules:
SS7 User Part Licenses
SCCP/TCAP
To enable SCCP/TCAP, you must purchase a license for each active MSP. SCCP/TCAP
are licensed in increments of 250 transactions per second (TPS). The license also
includes a hysteresis mechanism which averages traffic over a period of time to allow
exceptional TCAP traffic peaks (TPS) in the network.
Intelligent Network (IN) and Wireless Licenses
Excel licenses IN and Wireless protocol stacks on the host. You cannot use IN
without TCAP, so you must also purchase a TCAP license to enable SCCP/TCAP.
550
Developer Information
As mentioned above, to enable SCCP/TCAP, you must download a license, even if the
MSP was previously licensed for SCCP/TCAP. The IN/Wireless Codec license keys and
the SCCP/TCAP licenses are generated together and must be used together.
Wireless keys and SCCP/TCAP licenses require the following information:

Host ID

Specific IN and Wireless protocols

MSP I/O card ID
Specific IN and Wireless protocols are listed below. For each MSP, if the SCCP/TCAP
stack exceeds the TPS number licensed, the SS7 Signaling Stack Configure message
(0x005C) is NACKed with the response status value Software Module Still Locked
(0x007F).
IN Protocols
Specific IN protocols listed below are licensed per MSP and limited to 1250
transactions per second (TSP).

Customized Applications for Network Enhanced Logic (CAMEL)

Intelligent Network Application Part (INAP)

Wireless Intelligent Network (WIN)
Wireless Licenses
Specific wireless protocols listed below are licensed per MSP and limited to 1250
transactions per second (TSP).


Mobile Application Part for GSM Networks (GSM-MAP)
Mobile Application Part for ANSI Networks (ANSI-41)
SwitchKit
SwitchKit licenses are available for single-node and multi-node MSP configurations.
Both types of licenses are matched to the MSP IDs of each node in the MSP.
SwitchKit applications can connect to any LLC that is running with a valid software
license. Independent software licenses are not required for SwitchKit applications.
Refer to SwitchKit Software Licensing.
SS7 Links Licensing
You must provide the serial number on the MSP I/O card and the number of SS7
links you want to license.

SS7 links can be purchased in 2-link increments up to 64 links maximum.
All links that you buy originally and that ship with the MSP remain available at all
times. For example, if an SS7 configuration is lost, or if the system is upgraded, the
licensed links that shipped with the MSP are immediately available when the system
is brought back up. However, for links that you buy licenses for later, this is not the
case. You must re-download these added licenses to re-instate those upgrades. You
can upgrade a MSP that is on-line, without interrupting service.
551
MSP
Licenses for Redundant SS7 Links
A Product License Key is invalid for redundant SS7 links.
Introduction to Resource Points
The DSP Media module comes standard with 2,048 Resource Points. You can
purchase additional Resource Points in increments of 1,024. The required Resource
Points are added to the resource pool. Resource Points requirements are as follows:



If your DSP requirements exceed two chips (2048 Resource Points), you need
to add a DSP Media module.
The DSP Media module provides six additional chips and 2048 additional
Resource Points.
If you need to add more Resource Points through licensing, the Resource
Points are purchased in 1024 point increments.
Refer to Resource Points for a full explanation.
VoIP Licensing
Each VoIP module includes 96 default channels that you can upgrade in increments
of 96 channels. The maximum number of channels depends on the codecs licensed.
Refer to VoIP Resource Profiles for a description of each profile including the codecs
and maximum number of VoIP channels supported.
Downloading Licenses
Use the Product License Download (0x0079) message to download the 14 byte
encoded alphanumeric string which enables additional resources.
Pool Resources
The VoIP channels are licensing as pooled resources. If the MSP has two VoIP
modules in it, the software will automatically spread all the licenses evenly across
the two modules. This process is done in groups of 32 channels, so if there is an odd
number of blocks, module 0 will have the extra channels.
Software Overview
Application Requirements (Non-SwitchKit)
This section explains what non SwitchKit users should include in an application so
that it will work effectively with the MSP. The next diagram shows the application
modules required.
Application Modules
552
Developer Information
Host Connection
The host, as the client in the client/server model, maintains the connection. The host
application can issue any number of requests to connect and disconnect. The MSP
services each connection request instantaneously. Because each MSP supports only
one connection to one host, each additional connect request issued overrides the
previous connection.
Important! The MSP connection port is 12610 (0x3142).
Communication Module
Overview
The Communication Module reads and writes bytes to the hardware link that
connects the host to the MSP. This module can frame and queue messages, calculate
checksums, process special characters, and queue host messages for MSP
acknowledgment.
Sequence Number Logic
You should include in your Communication Module a mechanism to assign sequence
numbers to messages as they are sent out the communications port, and for
matching these sequence numbers to MSP responses, using the message type.
The Communication Module must monitor the Poll message constantly. The Poll
message also relays the states of the active and the standby MSPs.
MSP Active/Standby State
553
MSP
In a redundant MSP, the Communication Module recognizes when the active MSP is
no longer active because:

The MSP is no longer sending Poll messages.

The standby MSP sends Poll messages that indicate that its state has switched
from standby to switchover, and then to active.

The standby MSP sends Poll messages that indicate that no adjacent MSP is
detected.
The Communication Module must also recognize the need to re-route messages
intended for the original active MSP to the standby MSP (the new active MSP). When
the Poll message indicates that the new active MSP is ready for configuration, the
Communication Module should inform the Configuration Module.
System Software Downloaded
The Poll message informs the host application that the MSP needs software
downloaded, and the Communication Module performs the download.
Important! The fastest way to download software to the MSP is to use the binary
downloading logic. In a redundant MSP, the Communication Module must also
download the standby MSP, and then the standby MSP downloads the active
MSP. This method causes the least amount of downtime for a MSP in the field.
During the development phase, you may be downloading different loads, but
downloading on top of an existing download can be time-consuming. It is usually
faster to clear the existing software load and then reset the MSP to download to the
ROM code. The Clear System Software message is useful for this process.
Message Timeout Logic
You should include message timeout logic in the Communication Module. Timeout
values can vary considerably, because with one configuration message, you can
configure one channel or many channels.
Timer Logic
The host determines whether to use multiple timers or a single, global timer. A
global timer must be long enough so that a configuration message sent to the MSP
would have enough time to complete. If the host uses multiple timers, some
experimentation with the configuration messages is required.
Message Distribution Logic
The Communication Module should also distribute messages from the MSP to the
modules that need them. The module may need to send a message to more than one
other module.
Include the following basic functionality in your application:

Framing

Handling special characters

554
Calculating checksums
Developer Information

Downloading System Software
Message Management Module
Overview
Implement a mechanism to manage messages to:



Assign sequence numbers to messages as they are sent out of the
communications port.
Match MSP responses to these messages using the sequence number and the
message type.
Support message traffic to both active and standby MSPs. Design your
Message Management module so the host knows when to send messages
intended for the formerly active MSP to the now active MSP. Make this
module inform the Configuration module when the Poll message indicates that
the active MSP is ready for configuration.
Sequence Number Logic
You should include in your Message Management Module a mechanism to assign
sequence numbers to messages as they are sent out the communications port, and
for matching these sequence numbers to MSP responses, using the message type.
Timeout Logic
You should include message timeout logic in the Communication Module. Timeout
values can vary considerably, because with one configuration message, you can
configure one channel or many channels.
Timer Logic
The host determines whether to use multiple timers or a single, global timer. A
global timer must be long enough so that a configuration message sent to the MSP
would have enough time to complete. If the host uses multiple timers, some
experimentation with the configuration messages is required.
Message Distribution Logic
The Message Management module should distribute the messages from the MSP to
the modules that need them. You may want to design your modules so that a
message can be sent to more than one other module.
Configuration Module
The Configuration Module configures the MSP. You should design your Configuration
Module with enough flexibility to reconfigure the entire MSP. The module should also
be able to take groups of channels in and out of service. The configuration script file
contains ideas on how to organize a MSP configuration.
555
MSP
Your Configuration Module should be designed to receive information about the state
of the MSP from the Communication Module. If the MSP has just been turned on,
your Configuration Module must configure the entire MSP. The Configuration Module
does not need to do anything if the MSP resets and sends a NGA State Notify
message indicating that the battery-backed configuration is valid (see the MSP
Status field).
After it configures the MSP, the Configuration Module can use the Tag Configuration
message to tag a configuration with a number. The NGA State Notify message also
returns a configuration tag. Design your host application to detect the presence of
previously-configured tags. If previously configured tags are present, the host does
not need to reconfigure the MSP.
Important! Always send the Tag Configuration message last. For a list of messages
that reset the tag configuration, see the Tag Configuration message in the API
Reference. Any configuration message (other than the Tag Configuration
message) sent to an MSP initializes the MSP’s configuration tag to 0 (zero).
When you need to clear the configuration, use the Reset Configuration message in
your Configuration Module. This message allows the host to initialize configuration of
the entire MSP. In a redundant MSP, sending a Reset Configuration message to
initialize the entire MSP causes a switchover to occur.
You should design your application for dynamic deconfiguration and reconfiguration.
Provide for such changes as the following:

Incremental configuration

Changing the existing configuration

Adding facilities
Host Connection Configuration
As the client in the client/server model, the host must maintain the connection. The
host can issue any number of requests to connect and disconnect. The MSP services
each connection request instantaneously. But because each MSP supports only one
connection to one host, each additional connect request overrides the previous
connection. To establish the connection, the host sends a Connect message that
specifies a port number, along with the IP address that was configured when the MSP
was turned on. You can encounter the following scenarios when disconnections occur
both gracefully and ungracefully:
Graceful Disconnection
In the MSP, a server task runs continuously so that, it is always ready to send an
Accept message as soon as it receives a connect request. If the host crashes and is
unable to issue a Close message, it must issue a new connect request when it
returns to service. The MSP instantly accepts this connect request.
Ungraceful Disconnection
The MSP software issues a Close message on a socket only if it detects that the
socket has been closed by the host. The host software must have a strategy for
handling connections that are broken by the MSP. Before sending the Receive
message, the host should send a Select message on the receive socket descriptor,
556
Developer Information
with a time-out value that is slightly greater than the poll rate. If the host is alerted
of a timeout, it assumes that the MSP has broken the connection. The host must
adjust the socket descriptors and issue a new Connect request.
Alarm Manager Module
The host must manage Alarm messages sent from the MSP.
Alarm Message
The Alarm message includes the following fields:
Severity
Excel has assigned the following severity levels to alarms, but you should become
familiar with each alarm and determine how your application should treat them:

Informative

Major

Minor
Alarm Type
Alarms are identified by the following types:

General

Channel


Span
MSP Node
Alarm Number
Each alarm within a type has a unique number. See the Alarm message in the API
Reference for alarm numbers.
Data Length
Some alarms have unique data associated with them. The Data Length field
preceding the data indicates the length of the data to follow. If there is no data, the
length is 0x00.
Data
Please refer to the specific Alarm message in the API Reference to see the data
associated with that alarm, if any.
Real-Time Logging Module
557
MSP
It is important for the host to enable a logging feature to capture host-to-MSP and
MSP-to-host messages. If a fault occurs, you should immediately retrieve a fault log
with the Fault Log Query message, and send this information to Excel Technical
Support for analysis.
The two types of fault logs are as follows:


Fault Log (0x01). This is a NULL terminated ASCII string.
Fault Log and Stack Trace (0x03). This is a NULL terminated ASCII string,
followed by the stack pointer of when the fault occurred, followed by a trace
of the stack.
An Alarm message is often accompanied by a NGA State Notify message. Pay special
attention to the NGA State Notify message. It contains information such as the MSP’s
serial number and configuration. It could also contain other important information.
For example, in the message’s MSP Status field, the “faults logged” bit could indicate
that a software fault has occurred. In a case such as this, it is important for your
host application to immediately send a Fault Log Query message to the MSP. The
Fault Log Query message retrieves the fault information from the MSP. Send this
information to Excel Technical Support for analysis.
User Interface Module
The User Interface module is able to perform many functions, such as downloading
system software to the MSP, sending interactive configuration and query messages,
and sending a configuration script file to configure the MSP. The module should be
able to send a string of hex bytes to the MSP so that at any time you can send any
message to the MSP and receive a response.
Create your User Interface Module so that you can disable the features of a message
but still send the message and receive a response. That way, when Excel provides
you with new messages as part of a software update, you can test the messages
before you embed them in your applications.
Excel provides many messages that allow the host to query the MSP. Be sure to
include all of the query messages that could apply to your application. Queries are
important for debugging, because they retrieve a great deal of helpful information
from the MSP. Queries are also important to ensure that new configurations are
correct.
Query messages include the following:

E1 Span Query

NGA Configure Query


PPL Audit Query
Fault Log Query
For a complete listing of query messages, see the API Reference.
Host Communication Module
The host, as the client in the client/server model, maintains the connection to a MSP.
The host application can issue any number of requests to connect and disconnect.
558
Developer Information
The MSP services each connection request instantaneously. Each subsequent connect
request issued “steals” the previous connection.
All API messages should be sent directly to the active MSP’s IP address. Messages
should not be sent to the MSP’s shared IP address.
Before you can establish a connection link from the host, you must obtain an
Internet Protocol (IP) address.
Acquire an IP Address
The IP address is a 32-bit address used in IP routing.
IP Addressing on MSP
IP addresses and subnet masks can be assigned to an MSP through Bootstrap
Protocol (BOOTP).
When a MSP resets and finds an invalid IP address, subnet mask, or gateway
address stored in the EEPROM, it issues five BOOTP requests. If there still is no
reply, it repeats BOOTP indefinitely until it gets an IP address. The MSP has to have
an IP address before the host connects.
Default Gateway Required
In a configuration that includes a router between a host and an MSP 1010, you must
configure a default gateway on both MSP 1010 ports. In this scenario, the MSP 1010
and host could be on separate subnets which makes this step necessary.
Changing System Software Version
To download a new version of system software, you must define the new MSP binary
filename.
Important! When entering the MSP1010 binary filename for this release, the file
name can be renamed, except that the end characters (_id0101) of the
filename must not be changed. For example, the filename
msp1010_ver100088_id0101.bin can be renamed to msp1010_id0101. Note
that the filename is linked to the main board processor. If a different processor
is used, the end characters need to be changed.
BOOTP Server
To change a system software load using a BOOTP server, perform the following:
1. Configure the BOOTP server to issue the new FTP or TFTP Configuration File
name for both the active and standby MSP in the BOOTP Response.
2. Send Clear System Software (0x0C) API message.
3. Send Reset Configuration (0x0B) API message.
The above sequence clears the system software load and initiates a FTP or TFTP
transfer of the new load to the standby MSP.
Downloading System Software to the MSP
559
MSP
To download system software to the MSP, you must use the FTP or TFTP download
method.
Important! Cantata recommends the FTP download method because it is faster than
the TFTP download method.
A download is initiated by the MSP sending a BOOTP Request to the host BOOTP
Server with the host flag set from the options shown in the next diagram.
Host Flag Tag Values
The following host flags dictate:
 The software download method to use - (FTP/TFTP/ SD Card)
 Codecs to use
 Protocol - ITU or ANSI
Remember to convert these values from hexadecimal or binary to decimal before
entering them in the BOOTP server.
Bit Mapping
For example, if you wanted to use FTP (0), E1 (1) and Profile 7 (11), the conversion
would look like this:
Binary
Bit 7
560
Bit 6
Bit 5
Bit 4
Bit 3
Bit 2
Bit 1
Bit 0
Decimal
Equivalent
Developer Information
0
0
0
1
1
0
1
0
26
See the following procedures depending on the operating system and tools you are
using to configure the appropriate host flag.

Configuring a Host Flag Using BOOTP Server

Configuring a Host Flag Using Solaris


Configuring a Host Flag Using Linux
Configuring a Host Flag on HP-UX
See the following topics regarding the codecs above.
IP Bearer Profile (ClientView)
VoIP Resource Profiles
FTP Download
With the FTP Download method, the MSP binary file is stored on the FTP server.
To implement FTP downloading, follow the steps below.
1) Install and configure a FTP Server (see Installing and Configuring an FTP Server).
2) Set up your FTP profile as follows:
Username: excelsw
Password: excelsw
3) Copy the software .bin file you require to the FTP Server.
TFTP Download
With the TFTP Downloading method, the MSP binary file is stored on the TFTP server.
To implement TFTP downloading, follow the steps below.
1) Install and configure a TFTP Server (see Installing and Configuring a TFTP
Server).
2) Copy the software .bin file you require to the TFTP Server.
Initiating a Download
Once you set the host flag, you can initiate a download using a BOOTP server.
BOOTP Server Download
561
MSP
The FTP downloading method figure shows the sequence for downloading system
software files to the MSP using the FTP downloading method and a BOOTP server.
The TFTP downloading method figure shows the sequence for downloading system
software files to the MSP using the TFTP downloading method and a BOOTP server.
FTP Downloading Using BOOTP Response Message
TFTP Downloading Using BOOTP Response Message
Fault Diagnostics
562
Developer Information
The Fault Diagnostics feature is designed to aid Excel Technical Support to resolve
MSP platform performance issues, including software defects. When a fault occurs,
several types of diagnostic information will be collected:

Basic system information (software version, etc.)

Performance information (CPU utilization, task/memory information)



Fault information
Logs (Generic Event Logger (GEL), Host Communication)
Last 100 API messages provided by the MSP 1010
After the fault and subsequent reset occurs, all of the above information will be
automatically uploaded to the host and stored in a single text file.
Important! Cantata recommends that the user send the data to Excel Technical
Support for analysis. The user is not expected to know the details of the
information that is collected and uploaded to the host.
Fault Data Uploading
Important! To ensure successful automatic upload of the fault data, verify the FTP
or TFTP server has upload privileges.
After the MSP resets and reestablishes communication with the host, the fault log is
automatically uploaded to the host. Fault log uploading is done in the same manner
in which the MSP receives a software download. For example, if the host defined FTP,
E1 (Host Flag = 2) for the software download, the fault log will be uploaded to the
FTP server with the same Host Flag set.
The fault data will be uploaded to a file in the same directory as the boot file. The
filename format is:
ChassisID_yyyymmddhhmmss.flt.
This ensures that each uploaded file has a unique name on the host, and that MSPs
that fault will not overwrite the previous fault data file.
Important! The host must set the correct date and time, because the MSP uses that
information to generate the filename on the host.
Using Telnet to Connect to the MSP 1010
Do the following to telnet to your MSP 1010. (If you also want to reset the MSP 1010
using Telnet, see Resetting a Node.
1. Open the Command Prompt.
563
MSP
2. Enter the IP address.
3. Enter the following:
User: excel <Enter>
Password: excel2004 <Enter>
564
Developer Information
4. Now you can enter commands that you want to send your MSP
1010.
Ethernet Network Analyzers
If a log file cannot be captured or if additional Ethernet information is required,
Cantata recommends using the following Ethernet network analyzers to capture data
going to and coming from the MSP:

Surveyor from Shomiti Software

Ethereal

Sniffer Pro from Network Associates
Overload Logic
The Overload Logic feature provides overload condition detection of the MSP.
The overload logic checks two system parameters:


CPU utilization
Memory consumption
A set of thresholds exist for each parameter and once the value meets a threshold,
the MSP sends an alarm message to the host.
CPU Utilization
The Overload Logic monitors CPU utilization in one second intervals and checks
against the following thresholds.

Minor threshold on - 85 percent

Major threshold off - 85 percent


Major threshold on - 90 percent
Minor threshold off - 80 percent
565
MSP
Memory Consumption

Minor threshold on - 90 percent

Major threshold off - 93 percent


Major threshold on - 95 percent
Minor threshold off - 88 percent
Each condition listed above will be detected for the CPU usage and memory usage.
As long as one of the resources is going into a BUSY state, for example
APPROACHING BUSY, the system will be considered to be in that corresponding
state. When a resource is going into a CLEAR state, for example APPROACHING
BUSY CLEAR, the system will be considered to be in that corresponding state.
Call Processing Filter Facility
In order for the overload logic to maintain a stable state for a period of time and
avoid frequent changes among the four conditions to be detected, a filter facility is
provided.
The filter facility uses five APPROACHING BUSY levels to indicate the busy conditions.
The higher the level, the busier the condition. Busy level 0 indicates a not busy
condition and busy level 4 indicates the busiest condition.
Every time an APPROCHING BUSY condition is detected, the busy level is increased
by one. TCAP will reject any new TCAP Transaction Requests by sending an ABORT
message to the network to abort a portion of new TCAP transactions (Begin
[ITU/ETSI] or Query [ANSI]) and send a NACK to the host for new transaction
requests (TC-Begin/TC-Query) according to the busy level. Based on the increase of
the busy level, more traffic will be discarded and NACKED. For example, when the
busy level is 1, one of every four calls will be discarded and NACKED, and if the busy
level increases to 2, then two of every four calls will be discarded and NACKED.
Conversely, a decrease in the busy level will result in more calls being processed by
TCAP. When the busy level is zero, all of the TCAP calls will be processed.
TCAP provides a timer interrupt to detect and find the BUSY or CLEAR conditions by
monitoring CPU usage and memory usage.
Busy and Clear Conditions
The following describes the process of handling BUSY or CLEAR conditions.
Approaching Busy
When an APPROACHING BUSY condition is detected for incoming new transaction
requests, TCAP will abort a portion of the new TCAP transactions (Begin/Query).
TCAP will send an ABORT message to the remote SS7 node that is running TCAP on
the network.
For the outgoing new transaction requests, TCAP will reject a portion of the new
requests based on the APPROACHING BUSY level and the filter facility busy level.
TCAP will send a NACK to the host for those rejected requests. TCAP will also send an
ALARM message to the host. The MSP will still process the TCAP messages for active
566
Developer Information
TCAP transactions (transactions in the active state) normally, regardless of the busy
level.
Approaching Busy Clear
When an APPROACHING BUSY CLEAR condition is detected, it is sent to SCCP/TCAP.
At this point TCAP will resume call processing for the incoming direction, and
ACKnowledge the host’s request for the outgoing direction based on the filter facility
busy level.
TCAP will also send an ALARM CLEAR message to the host to indicate a busy clear
condition.
Real Busy
When TCAP detects a REAL BUSY condition, TCAP will instruct the Message Transfer
Part level 3 (MTP3) to discard incoming MTP messages for TCAP Begin/Query. TCAP
will also send a NACK message and an ALARM message to the host. TCAP will
resume processing TCAP traffic when the resource busy condition clears.
Real Busy Clear
When TCAP detects a REAL BUSY CLEAR condition, it will send an ALARM message to
the host, and resume the TCAP call processing. TCAP will still reject new transactions
requests based on the busy level as described above.
Busy Condition Alarm Levels to Host
There are two different levels of busy alarms that will be sent to the host when a
BUSY condition is present or clears.
Card Level Alarm
The card level alarm is sent to the host by TCAP and indicates the MSP is busy. The
following alarm types are used:
ALARMbrdCARD_APPROACHING_BUSY and ALARMbrdCARD_REAL_BUSY,
Stack and Application Level Alarm
The stack and application level alarm is sent to the host by the SCCP and indicates
the SCCP/TCAP stack is busy. The following alarm type is used:
ALARMgenSS7_SIGNALING_STACK_BUSY.
SwitchKit
SwitchKit provides the following core functional areas needed for your application to
work effectively with the Multi-Services Platform.

Host Connection

Message Management

Communications
567
MSP

Configuration

Real-time Logging



Alarm Manager
Real-time MSP Management
User Interface
After you have addressed these functional areas in your application, you may now
add call processing to your application.
For more information about SwitchKit refer to the following:
SwitchKit Product Introduction in the SwitchKit Installation and Maintenance Guide.
If you do not use SwitchKit, you have to meet these requirements yourself. Each
requirement is described in the following:
Application Requirements (Non-SwitchKit).
SwitchKit API
The SwitchKit API provides a high-level interface between the application and the
EXS API, to facilitate rapid Multi-Services Platform (MSP)-to-application integration.
This straightforward C/C++ language API is based on industry standards. It provides
automatic configuration and redundancy control, as well as descriptive logs and error
messages. It extracts the EXS API suite in C/C++ Library format. This feature
enables you to support MSP messaging as well as administrative messages (between
the application and the Low Level Communicator (LLC) with all the benefits of a highlevel language API.
The power of SwitchKit allows you to concentrate your efforts on building your
telephony applications, without dealing with complex configuration requirements or
administrative tasks. It enhances applications by providing increased reliability and
seamless integration of multiple applications and multiple hosts. The flexibility of
SwitchKit allows you to have control over low-level administrative tasks. In short,
SwitchKit lets you address the call processing aspects of your solutions as you see
fit, giving you the power to implement new services easily, quickly, and profitably.
Multi-Host
Introduction to Multi-Host
Prior to this feature
Previously the MSP provided a single TCP server socket on TCP ID 0x3142. The MSP
and SwitchKit communicate over TCP port 12610 (0x3142) using the existing API
methodology. Any host could connect to this socket to transfer and receive API
messages. There can be only one connection per Host ID.
The TCP socket was open in “socket stealing” mode which means that if there was an
existing connection established, another host trying to connect could steal the
socket. This scenario was intended to handle MSPs in unmanned locations.
With this feature
568
Developer Information
This feature allows the host to configure the MSP to “listen” on multiple host sockets
which allows multiple API TCP connections to the MSP.
With this release, five ports are supported. The host can configure the TCP ID to
listen on (for example 0x3142, 0x3143, 0x3144, 0x3145 and 0x3146.)
Once you add Host Links, the following MSP applications can use them by per Host
Link ID.

TCAP

MTP3 To Host

SS7 Monitoring
Benefits
The multi-host features provides the following benefits:

Host redundancy

Greater bandwidth for the host port


Greater control of the MSP
Faster response to time-critical messages such as PPL Event Request.
Related Topics
Multi-Host Applications
Configuring Multi-Host
Querying Multi-Host
Multi-Host Redundancy
Multi-Host Applications
Regardless of the application, all host initiated messages are ACKED back to the
Host Link that they came in on.
Applications need to be configured to support multi-host to accommodate MSPinitiated messages.
By default, all MSP-initiated messages are sent to the default Host ID 0, TCP ID
0x3142
The following applications can use multi-hosts:
SCCP/TCAP
You can configure different SSN/Stack independently. That is, you can have a
particular SSN use Host Link ID 1 and a different SSN use Host Link ID 2.
In addition, you can configure the default port to use. to do this, you use either
ClientView, the SS7 SCCP TCAP Configure message (0x0077, config type 0x08,) or
the NGA Configure (0x0130) message (SCCP/TCAP AIB).
See the API Reference or the Multi-Host Socket in the ClientView section.
569
MSP
By default SCCP/TCAP uses Host Link ID 0. You can change it to be any Host Link ID.
All SSNs that are not configured to use a specific host link will transmit over this
default host link.
Refer to Introduction to SCCP/TCAP.
MTP3-To-Host
Refer to Introduction to MTP3-to-Host.
SS7 Monitoring
Refer to Introduction to SS7 Monitoring.
Call Control and OAMP generate messages to Host Link ID 0, TCP ID 0x3142
only.
Configuring Multi-Host
By default Host Link ID 0 is enabled and corresponds to TCP ID 0x3142. All
other Host Links are disabled by default.
Configuration involves two steps:


Add the hosts links using ClientView or the Multi-Link Configure (0x0130)
message. Refer to Multi-Host Socket to configure through ClientView.
Configure the applications (such as TCAP, Monitoring, and MTP-to-Host) to
use the host links using ClientView or the appropriate API message such as
the SCCP/TCAP Configure (0x0077) message for TCAP, SigView App Manager
Cfg for SS7 Monitoring or PPL Configure (0x00D7), (component 0x002B,
config bytes 0x1D-0x33).
Adding host links
In either way, you add a Host Link ID and map it to a Local Socket ID. You can also
modify or delete a Local Socket. You can choose any Local Socket ID (0x00000xFFFF) that you want. For example you can map Host Link ID 2 to TCP ID 0x4012.

We recommend that you do not modify or delete Host Link ID 0.

The Multi-Link Configure message includes a Local Socket Address which is
currently not supported.

The Host Link ID range from 0-4.
Configure Applications
After you add the host links and map them to local socket IDs, you configure the
applications to use them.
570
Developer Information
Refer to Multi-Host Applications.
Multi-Host Redundancy Considerations
The MSP has redundancy at the component level. SS7 is the redundant component
supported.
The port configuration is not redundant. The host must configure all MSPs
individually. The multi-host configuration is always sent to the active SS7 component
(whether standalone or redundant).
Since redundant SS7 components share their configuration, they both are configured
to use the same Host Link IDs (0-4). The host can assigned different Local Socket
ID numbers if they want, but they have to have the same Host Link IDs added.
Refer to Example Configuration for SS7 Redundancy.
Querying Multi-Host
You can query the multihost Host Links configured using NGA Configuration Query
(0x131) message. The MSP supports Query All.
When you add additional Host Links, the MSP notifies the host whenever a host
connects/disconnects on the default port. The host can also query the state of each
port using the NGA State Notify (0x163) and NGA State Query (0x161) messages.
Setting Up an SNTP Server
Setting Up an SNTP Server
The MSP 1010 runs an SNTP (Simple Network Time Protocol) client that sends an
SNTP request every 16 seconds and adjusts its time if it receives a valid response.
See Example ntp.conf File
Note: Verify that the host time and timezone are correct and in the expected
format. Universal Coordinated Time, UTC, is most commonly used. The factory
default timezone is set as Eastern Standard Time, EST.
The MSP uses the IP address of the FTP server as the location of the NTP server.
SNTP is a subset of the NTP protocol; therefore, the server is referenced as an NTP
server. Linux Redhat ES 3.0 includes an NTP server that is part of the basic
installation. For windows users, XP includes an NTP service that can be configured
easily. However, Cantata recommends using an NTP pool in the event the NTP
server goes offline. Under such a scenario, the next available NTP server in the pool
would be used. Refer to http://www.pool.ntp.org/ for NTP time servers within your
geographic region.
571
MSP
Steps for Setting Up a Linux NTP Server
Follow this sequence to configure an NTP server on Linux. This procedure assumes
that your MSP 1010 has been configured to FTP transfer the software from a Linux
machine. It is also assumed a DNS server is configured on the Linux server. If not,
static IP addresses must be used in place of 0.us.pool.ntp.org, 1.us.pool.ntp.org, and
2.us.pool.ntp.org in both the example below as well as the sample ntp.conf file.
1. Edit the ntp.conf to configure the NTP server. Click the link to get more
details for this step.
2. Restart the NTP server (service ntpd restart)
OUTPUT
Shutting down ntpd:
[ OK ]
ntpd: Synchronizing with time server:
Starting ntpd:
[ OK ]
[ OK ]
3. Verify the Linux machine is synchronized with an NTP server (ntpstat)
OUTPUT
synchronized to NTP server (66.187.224.4) at stratum 2 time correct to within 939 ms
polling server every 16 s
4. Verify the correct time on the MSP 1010 via the front panel.
5. Type the following to see the NTP packets for debug:
572
Developer Information
tethereal port 123
(add –V to get more details)
OUTPUT
Capturing on eth0
0.000000 10.129.45.132 -> 66.187.224.4 NTP
0.051050 66.187.224.4 -> 10.129.45.132 NTP
Configuring the MSP - Getting Started
Overview of MSP Configuration
ClientView or Excel API
The specific configuration steps in the Developer's Information focuses on configuring
the MSP using the Excel API. To configure with ClientView, see the alphabetic listing
of topics under Configuring the MSP under the ClientView book. The sequences of
steps below is the same regardless of the configuration method that you choose.
Host Application
You should design your host application to guide the MSP through the configuration
process as described below. You should also design the host application to
dynamically configure, deconfigure, and query all entities within the MSP. Examples
of these dynamic functions include adding facilities, changing span formats,
deconfiguring stack entities, and querying configuration entities.
Basic Configuration Sequence
The configuration sequence is from general to specific as follows:
System


Node Configuration
Configuration that affects the entire platform including network
synchronization, system time, poll interval, and loop timing.
Common Resources


External servers
Media configuration (DSP)
Span


Span assignment/format
Common channel signaling configuration
Channel
573
MSP


PPL component configuration
Answer supervision and release modes
VoIP

IP Address

Logical Spans

Resource Attributes
You can query any of the entities above after configuring.
Related Topics
This Developer Information contains extensive supporting information that will help
you when configuring the MSP. Refer to the sections on SS7, DS3, VoIP, Monitoring
SS7, SCCP TCAP, DSP, and ISDN.
Below are the introductory topics for each section:
Basics of SS7
DS3 Overview
VoIP Overview
Introduction to SS7 Monitoring
Introduction to SCCP/TCAP
DSP Media Module
Introduction to ISDN
System Configuration
Configuring Nodes
You configure Local and Remote Nodes as follows:
Local
Use the Local Node Configure message to assign a logical node ID and name the
node.
AIB
Local Node (System, Communications, Node, Local)
574
Developer Information
TLVs
Use the following TLVs:

Physical Node ID TLV (0x8102) - 8 bytes for the I/O serial number

Node Name TLV (0x8103) - name of the node, limited to one line on the LCD
display. Up to 12 bytes.

Logical Node ID TLV (0x8100) - range of 0-63, 255 (default)
Remote
Use the Remote Node Configure message to identify the logical node ID, IP address
and transport method to the local node.
AIB
Remote Node (System, Communications, Node, Remote)
TLVs
Use the following TLVs:

Logical Node ID TLV (0x8100) range of 0-63, 255 (default)

Remote Node Transport Method TLV (0x8105) - transport type Ethernet or
UDP/IP (default).

Remote Node Address TLV (0x8104) - address type IPV4 (default) or IPV6
Configuring Host Communications
Use the Host Communications Configure message to configure the node resend
logical and the name of the host controlling the node.
When the node sends a message, the node waits five seconds for an acknowledge
message from the host. If the acknowledgement is not received, the message resend logic is implemented.
AIB
Host (System, Communications, Host)
TLVs
Use the following TLVs:


Resend Logic TLV (0x8140)
Host Controller Name TLV (0x8101) - Name of the host controlling the node,
limited to one line on the LCD display - up to 12 bytes.
575
MSP
Configuring Multi-Link
You can configure additional host links for TCAP transactions, SS7 monitoring, or
remote SS7 user parts.
Use the Multi-Host Configure message to map a Host Link ID to an IP Address/TCP
port.
AIB
Multi-link (System, Communication, Host, Multi-link)
TLVs
Use the following TLVs:

Host Link ID TLV (0x8142)

Local Port ID TLV (0x8146)

Local Address TLV (0x8144) - IPV4 (default) or IPV6
Configuring Port Manager
Use the Port Manager Configure message to configure the Ethernet parameters for
an IP interface port.
AIB
Port Manager (System, Communications, Network, Port Manager)
TLVs
Use the following TLVs:

IP Interface Port TLV (0x8005)

Port Speed TLV (0xE051)


Port Mode TLV (0xE050)
Port Duplex (0xE052)
Configuring Licensing
576
Developer Information
Software keys allow you to use MSP and SwitchKit. Use the License Configure
message to download the licenses which enable the system software, features, and
capacities.
AIB
License (System, General, License)
TLVs:
Use the following TLVs:


Product License Type (0xE046)
Product License Encrypted Data (0xE047)
Related Topics
General Licensing Information
System Software Licensing
Software Modules Licensing
SS7 Links Licensing
Licensing Information (ClientView)
Introduction to SS7 Monitoring
Resource Points
Network Synchronization
Before running the MSP, synchronize T1 and E1 spans to the network. Use the
Synchronization Priority List Configure message to configure a prioritized list of clock
sources. The MSP uses this list when it selects a synchronization clock source.
The default priority for synchronization resources is as follows:
1. External Reference Clock 1 (Primary)
2. External Reference Clock 2 (Secondary)
3. Loop Timing 1 (Primary)
4. Loop Timing 2 (Secondary)
5. Free Running clock (Internal)
The MSP continuously monitors all synchronization clock sources and uses the
highest priority clock source currently available. For example, if you use the default
configuration above, the MSP first determines if the Primary External Reference Clock
is available. If it is not available, the MSP determines if the Secondary reference
Clock is available. The MSP continues to check each source, in succession, until it
finds an available source. When a higher priority source becomes available, the MSP
automatically changes to the higher priority clock source.
577
MSP
Descriptions of the synchronization sources are as followS:
External Reference Clock
Reference Timing is generated by an external clock source to the MSP through the
I/O card at the SIGNAL/TIMING 0 and 1 ports. The I/O card function is to take in a
external reference clock and provide that timing to the main board which in turns
uses that clock for system timing. The I/O card can sync to the following reference
clocks 1.544 Mbps or 2.048 Mbps.
Loop Timing
Configure Loop Timing to derive time from a T1 or E1 span. Loop Timing
synchronizes the system to an incoming T1 and E1 span through the I/O card at the
SIGNAL/TIMING 2 and 3 ports or any bearer offset.
You cannot configure SIGNAL/TIMING port 0 and 1 for loop timing.
You must first designate which span you want to use to extrapolate the clock. Use
the Loop Timing Configure message after you assign spans.
Free Running Clock
Free running timing is based on the internal clock source of 2.048 Mbps. Free
running timing is for test environments only. Do not use this timing method for
network operations. You can determine the current active timing by performing a
synchronization priority list query.
System Time
You must use the Time Set message to set the system time. The MSP uses the
system time to timestamp fault log entries.
Initiating PPL Table Download
Use the PPL Table Download Initiate message to download the primitive table or a
state/event table.
This message causes the MSP to allocate space for the table which is then
downloaded using the PPL Table Download message.
Use the PPL Create message to create a PPL protocol from the primitive and
state/event tables.
Network Interfaces
Network Interface Scenarios
When you configure the Network Interfaces, you provide physical and logical
interface data which helps configure how the network traffic is organized over the
subnets. To configure network interfaces using ClientView see Network Interfaces.
Scenarios
578
Developer Information
The four scenarios listed below can help you configure network interfaces. Each
scenario contains sample information and a diagram. The port on the back plane is
also included to tie configuration to the actual I/O connections.
One Subnet
Two Subnets (Control/Signaling and Data)
Two Subnets (Data/Signaling and Control)
Three Subnets
Common Resources - DSP
Overview of DSP Configuration
This section provides an overview of the DSP Configuration in the context of the
overall MSP configuration.
For additional topics regarding DSP Resources, refer to the DSP section starting with
Overview of Configuring and Using DSP Resources.
Configuring the DSP Service State
Each MSP comes with two DSP chips and the Channel Manager license provides 2048
resource points.
You can install an optional plug-in module that contains six DSP chips. You can
enable additional resource points through DSP Resource Points license in 1024
increments. All resouce points are pooled among the DSPs in the MSP chassis.
Taking DSP Out of Service State
Use the Service State Configure message to take each DSP out of service in order to
configure the DSP resources.
Use the DSP Chip AIB (0x22).
Bringing DSP Back into Service
After you configure DSP resources, use the Service State Configure message to bring
each DSP back into service.
579
MSP
Configuring the DSP SIMM
There are four streams per DSP and 2 or eight DSPs per MSP. Use the DSP SIMM
Configure API message to assign the functions to the four streams on a DSP.
This message uses the DSP Chip AIB (0x22).
The host sends a separate API message for each DSP in the MSP.
Record/Playback
The record/playback function requires DTMF reception and tone generation on the
MSP. Refer to File, Record and Playback Overview.
Configuring Access to the NFS Server
Use the Generic Card Configure (0x0122) message to do the following:

Select NFS server

Identifies location of Vocabulary Index File





Configure server ID, IP address, server name, and mount name
Sets NFS, DSP overload, main board memory, and temporary memory alarm
thresholds
Sets statistics update timer
Configures NFS group ID and poll retries
Sets temporary record file timer.
TLVs in Initial Configuration

Card Object

Server Address


File Management
Vocabulary Index File
TLVs in Optional Message


580
NFS Alarm
DSP-2 Main Board Memory Alarm
Developer Information

DSP-2 Temporary Memory/Alarm Threshold

NFS User Group ID TLV



Statistics Update Timer TLV
NFS Poll Retries
Temporary Record File Timer
Configuring Advanced Conferencing
Use the Generic Card Configure (0x0122) message to configure parameters for
advanced conferencing feature:
Mandatory TLV

Card Object (0x05FA)
Optional TLVs

Output Gain Control

Nose Gate Parameters






Noise Gating Enable
Echo Suppression Enable
Echo Suppression Paramters
AGC Enable AGC Input Level
AGC Parameters
Conference Failure Behavior
Configuring T.30 Fax
Feature Description
See T.30 Fax Overview.
Configuration
1. Use the DSP SIMM Configure (0x00C0) message to assign T.30 Fax Function
Type to the DSP.
2. Configure T.30 FAX parameters using FAX TLVs in the Generic Card Configure
(0x0122) message.
581
MSP
Mandatory TLV: Card Object (0x05FA)
Optional TLVs: 25 TLVs (0x0641-0x066C)
3. Use the Resource Connect (0x0127) message to initiate a fax.
Resource Type TLV: Send FAX (0x0105) or Receive FAX (0x106)
Page Range in TIFF File
This feature allows the user of the DSP Media module's Fax transmission capability to
select a range of pages for transmission out of a single TIFF file. This allows you to
incorporate selective page transmissions into your application for such reasons as
removal of cover pages for fax store and forward applications or fax back services
which send selective sections of repair manuals.
To use this feature, send the Resource Connect 0x0127 message with the 0x068C
FAX Page Range TLV.
Query
To Query T.30 FAX settings, send the Generic Card Query 0x0123 message with one
or more of the T.30 FAX TLVs.
Use the Generic Card Configure (0x0122) message to configure the T.30 fax
parameters:
Related Topics
T.30 Fax Overview
Configuring T.30 Fax
Configuring Echo Cancel
1. Configure DSP for Echo Cancel function using the DSP SIMM Configure
0x00C0 message.
DSP Function Type
Echo Cancel (0x33)
2. Set module-level Echo Cancel parameters using the Generic Card Configure
0x0122 message.
Mandatory TLV
0x05FA Card Object
Object ID: Echo Cancel Parameters (0x0005)
Optional TLVs
0x0673 Echo Cancel Tap Length
0x0674 Echo Cancel NLP Type
582
Developer Information
0x0675 Echo Cancel ADAPT
0x0676 Echo Cancel Bypass
0x0677 Echo Cancel G.176 Modem Answer Detection
0x0678 Echo Cancel NLP Threshold
0x0679 Echo Cancel CNG Noise Threshold
Related Topic
Overview of Echo Canceller
Configuring Voice Detection/Answering Machine Detection
You can configure the MSP 1010 to analyze incoming PCM data and detect voice or
an answering machine. You can set PVD/AMD parameters for a DSP Media module
and for an individual channel. When a signal is detected, the host is notified with a
Call Processing Event 0x002E message.
Configuration
1) Configure DSP for PVD/AMD function using the DSP SIMM Configure 0x00C0
message.
DSP Function Type
PVD/AMD (0x34)
2) Set card-level PVD/AMD parameters using the Generic Card Configure 0x0122
message.
Mandatory TLV
0x05FA Card Object
Object ID: PVD/AMD Parameters (0x0006)
Implementation
1)
Attach PVD/AMD receiver to channel using the Resource Connect 0x0127
message
AIBs
Resource A: Span/Channel
Resource B: Slot
Mandatory TLV
0x0602 Resource Type
Resource Type = PVD and AMD (0x0109)
Optional TLVs (to override default module parameters)
0x0619 PVD Parameters
0x061A AMD Parameters
583
MSP
0x061B PVD/AMD Reports
2)
To disconnect the channel from the DSP resource, use the Resource Disconnect
0x0128 message.
AIBs
Resource A: Span/Channel
Mandatory TLV
0x0602 Resource Type
Resource Type = PVD and AMD (0x0109)
Optional TLVs)
None
Query
Use the Generic Card Query 0x0123 message to query the module-level defaults for
PVD/AMD.
Span Configuration
Assigning Logical Span IDs
Use the Assign Logical Span ID (0x00A8) message to map a logical span ID to a
physical location. The following are the physical locations:


Signaling spans: slot 1, offsets 0-3
Bearer spans: slot 2, offsets 0-27 (T1) or 0-20 (E1)
You must assign a unique logical span ID to each span in the MSP (0-6685).
You also use the Assign Logical Span ID message to de-assign spans.
Next Task
Configuring T1 Spans
Configuring T1 Spans
Use the T1 Span Configure (0x00A9) message to define the characteristics of a T1
span including:

framing (D4, ESF)

signaling method


584
line coding method
line length
Developer Information
For SS7 signaling, you must configure the signaling method to Clear Channel
for the T1 spans carrying the signaling links and CICs. This step prevents the
MSP from attempting to extract Channel Associated Signaling from the spans.
Next Task
Configuring E1 Spans
Configuring E1 Spans
Use the E1 Span Configure (0x00D8) message to define the characteristics of an E1
span including

line coding method

signaling method


error checking
line length
For SS7 signaling, you must configure the signaling method to Clear Channel
for the E1 spans carrying the signaling links and CICs. This step prevents the
MSP from attempting to extract Channel Associated Signaling from the spans.
Next Task
Configuring the Span Filter
Configuring the Span Filter
Use the Span Filter Configure (0x00CD) message to configure the filter timers to
detect carrier group alarms.
Next Task
Configuring SS7 State Machine
Configuring Host Link Failure
Use the NGA SCCP_TCAP Configure (0x0130) message to configure host link failure
(HLF) behavior for SS7 as follows:
AIB
Signaling, SS7. SCCP
TLVs

HLF Configuration (0xE035)


HLF disable (default) or enable
HLF declaration timer range
585
MSP


Local Port ID (0x8146)
SCCP HLF Failure Behavior (0x9080) - do nothing or take subsystem out of
service
Related Topic
Host Link Failure
Next Task
Mapping SS7 Subsystem to Application ID
Channel Configuration
Answer Supervision Mode
Use the Answser Supervision Mode (0x00BB) message to configure the answer
superviosn mode for a channel which includes the following:

propogate answer to the distant end

propagate answer to distant end and notify host of answer


notify host of answer
no answer supervision
The answer supervision mode for DPO and DPT trunk types is NONE by default. Do
not change it.
Configuring Local and Distant End Release Mode
Use the Local End Release Mode (0x0021) message to determine whether a channel
is released or parked when the other end of a connection releases.
Release mode options include:

park

release with host notify (E&M)


release
park with host notify (E&M)
Use the Distant End Release Mode (0x00B8) to determine when the distant end is
released or parked when the connection is terminated.
Configuring the PCM Encoding Format
586
Developer Information
Use the PCM Encoding Format Configure (0x00D9) message to change the default
PCM encoding format for a channel.
When the MSP makes a connection between two channels with different PCM format,
the MSP performs automatic conversion.
The MSP sends the message to one of the channels to disable automatic PCM
conversion. The format options include A-law and u-law.
The message configures the encoding format regardless of the type of calls on the
specified channel including both voice and data (static configuration).
If you require dyanmic per-call control, use the Companding Conversion Mode
(0x0118) TLV in the Connect with Data (0x0005) or Route Control (0x00E8)
messages.
Configuring the DSP Service State
Each MSP comes with two DSP chips and the Channel Manager license provides 2048
resource points.
You can install an optional plug-in module that contains six DSP chips. You can
enable additional resource points through DSP Resource Points license in 1024
increments. All resouce points are pooled among the DSPs in the MSP chassis.
Taking DSP Out of Service State
Use the Service State Configure message to take each DSP out of service in order to
configure the DSP resources.
Use the DSP Chip AIB (0x22).
Bringing DSP Back into Service
After you configure DSP resources, use the Service State Configure message to bring
each DSP back into service.
DS0 Status Change
587
MSP
Use the DS0 Status Change (0x0042) message reports a change in channel status to
the host. These changes include:

in service

parked


out of service
purged
Enabling group messages with the System Configuration messages reduces the
message congestion when all spans and channels are brought into service.
Tagging the Configuration
You can have the host assign a tag to the MSP's configuration after it is configured.
If the configuration is modified, the tag is reset to 0. The MSP restores the default
values.
The MSP reports the tag to the host in the Card Status Report (0x00A6) message.
SS7 Configuration
Configuring SS7
The table below outlines the sequence that should be followed to configure SS7
entities. Click on the links to see more detailed information about SS7 entities. For
more details about SS7 see Basics of SS7
Before You Begin
Acquire the Originating Point Code (OPC) and Adjacent Point Code (APC) before
configuring the SS7 stack.
Steps
Use the following configuration sequence to bring SS7 signaling links and voice
circuits in service.
Step
Action
API Message(s)
2
Assign and configure spans on
the primary and secondary
nodes.
0x00A8 Assign Logical Span ID
1
3
588
Configure SS7 license
Configure SS7 redundancy (if
applicable)
0x0130 Licensing Configure
0x00A9 T1 Span Configure
0x00D8 E1 Span Configure
0x00D8 SS7 State Machine
Configure
Developer Information
0x0130 Remote Node Configure
4
Configure Signaling Stacks
5
Configure Signaling Link Sets
6
Configure Signaling Links
7
Configure Signaling Route(s)
8
Assign Voice Circuits (CICs)
9
The following entities must be
brought in service in this order
and messages must sent
separately for each:
1. Spans
For more API information see
these log files.
0x005C SS7 Signaling Stack
Configure
0x005D SS7 Signaling Link Set
Configure
0x005E SS7 Signaling Link
Configure
0x005F SS7 Signaling Route
Configure
0x006A SS7 CIC Configure
0x000A Service State Configure
(This message must be sent for
each entity specifying the
correct AIB.)
2. Signaling links
3. CICs
Configuring the SS7 State Machine
Use the SS7 State Machine Configure (0x0171) message to control the behavior of
the SS7 state machine.
AIB
SS7 (Signaling)
TLVs
Use the TLVs to configure the MSP as follows:

State Change Request (0xE00F) - changes the state machine state to go
either:

go offline

go active




go reset
go standby
Redundancy Entity TL (0xE009) - configures the node as the primary (default)
or secondary SS7 signaling node.
Logical Node ID TLV (0x8100) - indentifies the logical node ID
589
MSP


Initial Stop State (0xE00B) - configures the state machine initial stop state to
offline stop state (default) or active stop state without host control.
Component Failure Behavior (0xE00D) - configures what actions the
component will take in case of failure. Options include:

wait for host control

restart SSM (default)

restart component
Configuring SS7 Signaling Stack
Use the SS7 Signaling Stack Configure (0x005C) message to define a signaling stack
and assign it an Originating Point Code (OPC).
You can define four stacks per MSP consisting of the following layers:

MTP

L3P




ISUP
TUP
SCCP
TCAP
You assign each layer a variant:

ANSI

BT IUP



ITU-TS
SSUTR2
JT
The multiple stacks allow the MSP to communicate with multiple networks.
Next Task
Configuring SS7 Link Set
Configuring SS7 Signaling Link Set
Use the SS7 Signaling Link Set Configure (0x005D) message to define the load
sharing collection of signaling links connected to an adjacent signaling node.
590
Developer Information
The link set is an abstract path between the MSP and an adjacent point code (APC)
to which you will add signaling links.
You must assign the same signaling stack to all links in a link set. A typical
configuration consists of two link sets.
When you configure multiple stacks, the Link Set IDs assigned to each signaling
stack must be different. For example, if a Link Set ID is assigned to Stack 1, it
cannot also be assigned to Stack 2.
You can configure up to:


64 links per node
128 link sets per node
Example
The following example uses the SS7 Signaling Link Set Configure message to define
Link Set 0 going to APC 0x00 0x22 0x33 0x44.
FE 00 0F 00 5D 00 SN FF 00 01 1E 02 00 00 00 22 33 44
Next Task
Configuring SS7 Signaling Links
Configuring SS7 Signaling Link
A signaling link is a point-to-point connection between two SS7 point codes (in this
case, a MSP and an STP). The SS7 Signaling Link Configure message assigns a
physical location in the MSP (timeslot) and a previously configured Signaling Link Set
to a signaling link. The message includes the following:

stack ID

link ID




link set
signaling link code (SLC)
data rate
electrical interface
The signaling link code is unique to a link set and must be the same on both ends of
the link. There can be 16 links per link set.
When you configure multiple stacks on the MSP, the Link IDs assigned to each
signaling stack must be different. For example, if a Link ID is assigned to Stack 1, it
cannot also be assigned to Stack 2.
When configuring redundant MSPs, you must assign SS7 Signaling Links 0-63 to the
primary MSP, and Signaling Links 64-128 to the secondary MSP. Note that you send
all SS7 configuration to the primary MSP.
Example
591
MSP
The following example of the SS7 Signaling Link Configure defines span 1/channel 23
as a signaling link on Link Set 0, using a data rate of 64 Kbps.
FE 00 14 00 5E 00 SN FF 00 02 1F 03 00 00 00 0D 03 00 01 00 00 00 00
Next Task
Configuring SS7 Signaling Routes
Configuring SS7 Signaling Routes
A signaling route defines a path between a signaling stack and a Destination Point
Code (DPC). The MSP supports up to:


128 destinations
512 routes
Use the SS7 Signaling Route Configure message to assign the Route IDs. The
message contains:

Stack ID

Route ID





Destination ID - defines the relationship of a signaling stack and a specific
DPC.
DPC
Link Set ID
Priority
Combined Link Set
You assign each signaling route to a DPC. You give each signaling route to a DPC a
priority. Link sets with the same priority to a destination will load-share traffic as a
combined link set.
When you configure multiple SS7 stacks, the Route IDs assigned to each signaling
stack must be different. For example, if Route ID is assigned to Stack 1, it cannot
also be assigned to Stack 2.
Example
The following example of the SS7 Signaling Route Configure assigns a route to DPC
0x00 0x33 0x44 0x55. See the API Reference for the format of SS7 Signaling Route
Configure.
FE 00 14 00 5F 00 SN FF 00 01 20 05 00 00 00 00 01 00 33 44 55 00 09
SS7 CIC Configuration
Use the SS7 CIC Configure (0x006A) message to assign circuit identification codes
(CICs) to SS7 controlled voice circuits. This process creates an association between
the channels on a logical span and SS7 CICs. The message data includes the
following:
592
Developer Information

Stack ID

Base CIC span





Base CIC number
Base CIC channel
Number of CICs in group
DPC
Call Control User Part
You assign CICs as a CIC Group and must reside on the same span.
E1 spans with a signaling link on timeslot 16 requires two messages to configure the
CICs:

Channels 1-15 and channels 17-31
CIC Start Up Procedure
The MSP supports the Exchange Type A start-up procedure as defined by Q.767,
Section 4.4.1. Type A does not send any messages at start-up, but responds to a
GRS with a GRA, or an RSC with an RLC. As the default exchange type for the MSP is
Type B, you must perform configuration steps to enable Type A.
Configuring Exchange Type
The exchange type is configurable with PPL Config Byte 60 of the SS7 ISUP SPRC
component (0x13).
If the exchange type is set to Type B (0x01, the default), GRS/RSC is sent at startup. If the Exchange Type is set to Type A (0x00), GRS/RSC is not sent at start-up.
Type B Procedure (Default)
The default exchange type for the MSP is Type B, which requires sending a GRS/RSC
at start-up. The MSP waits for a remote GRA/RLC before bringing the CICs in service.
Type A Procedure
If the exchange type is set to Type A, GRS/RSC is not sent at start-up. Timer 4 of
the L3P CIC component is initiated to wait for a remote GRS/RSC indication. The
default timer value is 500 ms (5 s).
If the timer expires before GRS/RSC is received, the CICs are placed in service and a
PPL event of 0x17 (No GRS/RSC Received, CICs In Service) is sent to the host. You
can disable the sending of the PPL event to the host by changing PPL Config Byte 14
of the SS7 L3P CIC component (0x0F) to 0x00. (0x00 - Do Not Send PPL Event to
Host; 0x01 - Send PPL Event to Host).
Configuring SCCP TCAP
593
MSP
This section describes the SCCP TCAP options that can be configured for a variant of
an ANSI or ITU protocol.
Use the SS7 SCCP/TCAP Configure (0x0077) message to configure up to ten different
attributes for each local subsystem. Send a separate message to configure the
attributes for each local subsystem.
Before you begin
Before you can configure other options, you must add a local subsystem and
configure how it routes network messages (either to TCAP or to the host). You must
use the SS7 SCCP/TCAP Configure message to set the byte for Config Type to 0x01
Local SSN.
Configuring SCCP/TCAP
1. Configure the local subsystem number using the SS7 SCCP/TCAP Configure
message.
2. Next you can configure SCCP/TCAP options described in the next section.
Procedures for configuring options
You can configure the following SCCP/TCAP options.
Option
Adjacent
Translator
Other
Concerned
Point Code
SCCP/TCAP
Default
Parameter
Table
Use the SS7 SCCP/TCAP Configure message to...
Set the Config Type byte to 0x02 and configure all Adjacent
Translators for a given subsystem. By default, all Adjacent
Translators are Concerned Point Codes.
See Adjacent Translators Configuration .
Set the Config Type byte to 0x03. For an SSP or SCP, Point
Codes which must be informed about local (MSP 1010)
subsystem status changes are referred to as Concerned Point
Codes.
Set the Config Type byte to 0x04. This table contains the
default parameters used by SCCP and TCAP for all subsystems
associated with a stack. These values are used for Mandatory
parameters if not included in a primitive.
The following parameters are stored by default, according to the
ITU white book.

TCAP Dialog_As_ID

TCAP Protocol Version

Subsystem
(Based on
594
TCAP Unidialog_As_ID
You do not need to configure this table unless you require
modifications.
Configure the default parameter table for a particular subsystem. Set the Config Type byte to 0x05.
Developer Information
default
parameter
table)
Configure
Local SSN
Set the Config Type byte to 0x01. You may route messages to
TCAP or the host by configuring the SSN Routing Flag.
SCCP/TCAP
host
configuration
Set the Config Type byte to 0x08 to configure the SCCP/TCAP
host that is used to receive messages from the SCCP/TCAP
layer.
Network
DPC/SSN
Replicated
SSN
Global Title
Translation
Set the Config Type byte to 0x07 to configure the Destination
Point Code (DPC) and remote subsystem number.
Set the Config Type byte to 0x09 to configure the replicated
SSN.
Set the Config Type byte to 0x0C to configure Global Title
Translation using the TLV Format Configuration Contents. See
Global Title Translation (GTT) Configuration Samples.
Querying
Use the SS7 SCCP/TCAP Query message to query the following:

Local Subsystem Table

Subsystem Default Parameter Table



SCCP Default Parameter Table
TCAP Active Transactions
TCAP Active Operations
Related Topics
Deconfiguring SCCP/TCAP
GTT Configuration Samples
Deconfiguring SCCP/TCAP
To deconfigure an SS7 stack with SCCP/TCAP, do the following:
1. Put all SSNs out of service using the N-STATE request. This will abort any active
TCAP transactions for the SSN if TCAP TUSI Config Byte 3 is set to Yes (default
value).
The host MUST take the SSN out of service. If not, any attempt to delete the
SSN will fail. This differs from normal deconfiguration where the link does not
have to be marked OSS before it can be deconfigured.
2. Delete the SSN using the SS7 SCCP/TCAP Configure message.
595
MSP
3. Deconfigure MTP for the stack (links, link sets, route) using the following
messages:

SS7 Signaling Link Configure

SS7 Signaling Route Configure

SS7 Signaling Link Set Configure
4. Deconfigure the stack using the SS7 Stack Configure message.
Configuring SS7 Components
You can use the following PPL messages to configure SS7 Components which allows
you to customize the SS7 stack in the MSP.
PPL Assign (0x00D1)
Assigns protocol variants to SS7 components and includes:


PPL Component ID
PPL Protocol ID, 0x01-0x0A for user created protocols.
PPL Configure (0x00D7)
Sets PPL Configuration Byte values and includes:

PPL Component ID

Configuration data including the number of data locations, byte number, and
data

PPL Entity which is always PPL Configuration Bytes
PPL Timer Configure (0x00CF)
Sets and adjusts PPL generic timers and address signaling timers. There are 200
generic timers available. The developer must specify which timers are used and how
they are used. The message includes:


PPL Component ID
PPL Timer Type
PPL Event Request (0x0044)
Contains an N-State primintive for the SCCP component. The primitive contains the
following:


Subsystem Number
Subsystem Status Parameters
Next Task
Bringing SS7 Spans Into Service
596
Developer Information
Bringing Spans Into Service
Once you completed configuring SS7, use the Service State Configure (0x000A)
message to bring spans and signaling links into service.
ISDN Configuration
Configuring ISDN
This section describes the procedures for configuring primary rate ISDN and National
ISDN PRI NI 2. For more information on ISDN see Introduction to ISDN. The first
four steps of the basic ISDN configuration are described in more detail in other parts
of this documentation:

Span Configuration

B Channel Configuration


D Channel Configuration
Optional Configuration
More details about bringing spans and channels in service, reconfiguration, and
querying information are provided following the configuration sequences in this
section.
Before you begin
The basic ISDN configuration assumes a 23+D (Primary Rate Interface) in North
America and 30B+D outside of North America.
ISDN PRI Configuration Sequence
The next table below shows the basic ISDN configuration sequence.
Step
Action
Description
1
Configure Spans
-Assign Logical Span IDs
- Configure span formats
API
Message
Assign
Logical
Span ID
T1 Span
Configure
E1 Span
Configure
597
MSP
2
Configure the D
channels
- Assign D channels
- Configure D channels
- Add NFAS Facilities
3
4
5
Configure the B
channel
Optional
Configuration
Bring spans and
channels in service
Configure B channel
options
- PPL Customization
- Features
Bring spans, D channels,
and B Channels in service
D Channel
Assign
ISDN
Interface
Configure
D Channel
Facility List
Configure
B Channel
Configure
Service
State
Configure
National ISDN User Side Configuration
The next table provides a sample procedure for configuring the User Side endpoint
variant of National ISDN PRI NI 2:
Step
Action
2
Assign logical span IDs to spans and channels. Use the Assign Logical
Span ID (0xA8) message.
1
3
4
5
6
De-assign the Logical Span ID of the ISDN card by setting the slot and
spans (logical and physical) to 0xFF. Use the Assign Logical Span ID
(0xA8) message.
Configure the T1 Span. Use the T1 Span Configure (0xA9) message.
Assign a channel as an ISDN PRI D channel. Use the D Channel Assign
(0xC4) message.
Define the connection type for National ISDN PRI NI 2 user side as 0x09.
Use the ISDN Interface Configure (0x60) message.
Define the spans that are controlled by a D channel (including any spans
in NFAS mode). Use the D Channel Facility List Configure (0xC6)
message.
For the Action field, select 0x01 (Add Facility)
7
598
For Facility Number, select 0x01-0x1E, depending on the number of spans
being added.
Define the network type for the B channels. Use the B Channel Configure
(0xC8) message.
Developer Information
(0xC8) message.
8
For the Network Type (0x01) field, select 0x01 (Do Not Include NetworkSpecific Facilities IE)
Bring spans, B channels and D channels in-service. Use the Service State
Configure (0x0A) message with appropriate AIBs. Send the message for
each configuration.
Bringing Spans and Channels In Service
When all of the configuration is complete, bring up the D channel to establish a
connection with the network and then begin call processing.
After establishing a connection to the network, the MSP 1010 sends the DS0 Status
Change message to the host with the status of in-service. The DS0 Status Change
messages follow for the B channels (voice/data channels).
If there is a link failure, the MSP 1010 sends the DS0 Status Change message to the
host for the D channel, as well as all of the associated B channels. All channels have
a status of out-of-service.
Reconfiguration
Before performing reconfiguration, the MSP 1010 must be in a known state
regardless of system events such as the removal or reset of cards or a host restart.
Depending upon the event, the MSP 1010 determines which steps to take to get the
interface operational. Click here for Reconfiguration details.
The simplest approach is to send a Reset Configuration message indicating 0xFF for
the Matrix Controller slot number. The configuration of all cards resets. The
application must wait for the Card Status Report messages to be sent to the host
before configuration begins. Sending this message clears all host-configured options,
including downloaded PPL tables.
Another approach is to use Reset Configuration for the ISDN slot number, which
defaults configuration for all D channels assigned to the card. Use this approach for
an application that reconfigures certain features in the MSP 1010 during a live
installation.
To remove a single D channel’s assignment and configuration, send the Assign
Logical Span ID message (indicating de-assignment) for the D channel span.Type
your drop-down text here.
Querying Information
Use the ISDN Query message to get parameters configurable with the ISDN Terminal
Configure and ISDN Interface Configure messages, as well as assigned protocols.
See Example: ISDN Query
599
MSP
ISDN D Channel Configuration
This section describes the second step in the basic ISDN configuration sequence. See
Configuring ISDN.

Assigning D channels

Adding facilities (for NFAS)

Configuring D Channel options
Assigning D Channels
The D Channel Assign message allocates a D channel at the timeslot you specify. The
physical span MUST be assigned. You must specify the slot number of the ISDN card,
as well as the ISDN type (primary and secondary).
The D Channel Assign message sets all B channel configuration parameters
back to their defaults.
The MSP 1010 software selects the actual D channel resource. If the host attempts
to assign more than 32 D channels, the host receives a Response Status of “ISDN D
Channel Exceeds Max” (0xA4).
All subsequent references to the D channel timeslot use the Logical Span ID and
channel specified in the message. The facility number of 0 (zero) is defaulted to the
span with the D channel assignment. When assigning the secondary type, the host
selects the facility number.
Requirements for Assigning a D Channel
The following are requirements for assigning D channels:


Span must be assigned.
Span and channel must not be assigned to an ISDN D or B channel location.
For most applications, the D channel resides on the 24th channel of the T1
span, and timeslot 16 over E1.
Click here to see an example message: D Channel Assign
Configuring D channels
The ISDN Interface Configure message configures attributes required for ISDN
connections to the public network. To configure the connection endpoint variant,
determine the type of switch from which the D channel will originate. This requires
consultation with the provider. The default switch type is the Lucent 4ESS.
Normally, you do not need to configure Layer 2 and Layer 3 timers and counters.
600
Developer Information
However, if it is necessary to change these, refer to ITU-T Q.921 and Q.931 for
details on what they do and represent.
The next table below lists the ISDN interface entities and their defaults. Use the
ISDN Interface Configure message to change the default configuration.
Option
Default
D Channel Physical Medium
64 kbps
Connection Type
HDLC Bit Polarity
Lucent 4ESS
Normal
Network Side Layer 2
User Side
Location
User
B Channel Selection Mode
Layer 4 Channel Release
Request on ISDN
DISCONNECT
Protocol Discriminator Value
for Maintenance Messages
B Channel Encoding for
Transmission
Linear Clockwise
Disabled
3
Channel Number
Requirements for Configuring D Channel Options
The following are requirements for configuring D channel options:


The D channel must be assigned.
The D channel parameters will only be initiated when the transition from outof-service to in-service occurs.
Reconfiguring D Channels
Follow the steps below to reconfigure a D channel:
1. Take the B Channels out of service with the Service State Configure (0x000A)
message.
2. Take the D Channels out of service with the Service State Configure (0x000A)
message.
3. De-assign the D Channel with the D Channel De-assign (0x00C5) message.
4. Reconfigure the D channel with the D Channel Assign (0x00C4) message.
5. Reconfigure general options to an ISDN interface with the ISDN Interface
Configuration (0x0060) message.
6. Reconfigure B channel information with the B Channel Configure (0x00C8)
message
601
MSP
7. Bring span(s), B Channels and D channel(s) back into service with the Service
State Configure (0x000A) message.
L3 Default Settings per Connection Type
Click the supported connection type for which you would like to view the default L3
configuration values:

Lucent 4ESS and Lucent 5ESS

AUSTEL





DMS100 and DMS 250
JATE
EURO User Side
EURO Network Side
N12
Click here to see an example message : ISDN Interface Configure
Adding Facilities
The D Channel Facility List Configure message adds or deletes facilities controlled by
a D channel. For FAS arrangements, facility 0 is assumed for the span with the D
channel. By sending the D Channel Facility List Configure message, NFAS is
automatically assumed.
NFAS is only supported over T1, not E1.
Specify the span and channel for D and assign the facility number (1 - 19 for NFAS)
and the span ID for the facility being assigned. Each Primary D channel assumes it is
located on facility 0. You can add up to 19 facilities with the D Channel Facility List
Configure message.
The facility number is the span offset for the controlling D channel. For example, for
NFAS the span on which the D channel is located is facility number 0. The next span
controlled by that D channel is facility # 1, the next is facility # 2, and so on.
Requirements for Adding Facilities
The following are requirements for adding facilities to a D channel:

D channel must be assigned (use the D Channel Assign message).

Facility must be assigned (use the Assign Logical Span ID message).


602
Facility Number must be from 1-19 (0 is the D channel facility number).
Span and channel must not currently be assigned to an ISDN D or B channel
location. For most applications, the D channel resides on the 24th channel of
the T1 span.
Developer Information
Click here to see an example message: D Channel Facility List Configure
B Channel Configuration
This section describes the third step in the basic ISDN configuration sequence. See
Configuring ISDN.
Requirement
Before you configure B channels, the D channel must be assigned.
B Channel Configure API message
Use the B Channel Configure message to configure B channels. Use care when
configuring network-specific elements for the network. Check with your carrier if you
need to include network-specific Information Elements.
Trunk-provisioned calls
If placing trunk-provisioned calls (options specific to a group of B channels), the host
uses the parameters (configured with this message) in the outgoing ISDN SETUP
message to the network. This data is used to encode the correct Information
Elements for the called and calling party IEs when using trunk-provisioned
parameters for the call type, bearer capability, numbering types, and plans.
Default Configuration
The next table lists the B channel configuration entities and their defaults. Use the B
Channel Configuration message to change the default configuration.
Option
Default
Outgoing Information
Transfer Capability
Voice
Network Type
Calling Number Type
Calling Number Plan
ID
Calling Presentation
Indicator
Calling Screening
Indicator
AT&T Megacom
National
Number
ISDN
Numbering Plan
Presentation
Allowed
User Provided,
Not Screened
603
MSP
Called Number Type
Called Number Plan
ID
Subscriber
Number
Unknown
Numbering Plan
Configuring the Backup D Channel
This section describes configuration for the optional ISDN backup D channel.
Before you begin
Download and assign custom PPL protocols and modify timers and configuration
bytes as required.
D channel backup supported
The ISDN component supports the D Channel backup procedure as defined by Lucent
TR 41459. This procedure provides a standby D channel when using NFAS. When an
active D channel fails, or if there is a span alarm, the MSP 1010 converts to the
standby D channel and maintains active calls. This is a provisioned option and is
applicable only when using NFAS. D Channel backup is supported on the T1
component only.
Both D channels must be assigned to the same ISDN component. When a span fails,
or a D channel fails, a D channel switchover occurs (not a component switchover).
As both D channels must be assigned on the same ISDN component, there are no
extra hardware requirements to enable D Channel Backup. You can logically assign
spans on both T1 components (bearer and signaling) in the system.
Configuring D channel backup
To configure the backup D Channel, do the following:
Step
1
604
Action
Use the D Channel Assign message to configure the type and location
of the D channel. After the primary D channel is configured, configure
Developer Information
2
3
4
5
the backup D channel (using the D Channel Assign message again).
Include the span, channel, and facility number on which it resides.
Send the D Channel Facility List Configure message to all other
facilities you want to include in the NFAS arrangement. You can also
send this message for the same facility that was assigned in the
backup D channel assignment. The backup D channel cannot be deassigned; it becomes de-assigned when the primary D channel is deassigned.
Use the second facility (1) to configure the backup D channel;
(however, 1-19 are permissible).
Bring spans and channels into service. It is not necessary to bring the
backup D channel into service. It automatically comes into service
when the primary D channel is brought into service.
When the D channels align and process the SERVICE/SERVICE ACK
exchange, the host receives a DS0 Status Change message
(indicating “In-Service”) for the primary D channel.
Call Processing
When one of the D channels becomes active, both incoming and outgoing call
processing can begin. Only the active D channel allows information frames to
progress to the Layer 3 Channel Released component 8 (where calls are managed).
On a D channel switchover, only calls in the Active State (10) are preserved; all
other calls are cleared. Messages are dropped in the Wait State when the switchover
occurs. The host receives Channel Released messages for calls in transit.
Manual D Channel Switchover
You can initiate the switchover of D channels manually by sending a PPL Event
Request message to the L3 D Channel Control component and the D channel to
which you want to be switched.
You cannot initiate a switchover by taking the primary D channel out-of-service
or the span on which it resides.
Click here to see details about Compliance
VoIP Configuration
Overview of VoIP Configuration
You can configure the VoIP Module using ClientView or the Excel API.
Refer to the following topics if you are using ClientView:
IP Bearer Profile
605
MSP
VoIP Module MSP
Example Configuration for VoIP Modules
To configure VoIP using the Excel API do the following in the order shown:
1. Configure the IP Address
2. Configure the Resource Attributes
3. Assign Logical Spans
Related topics
VoIP Overview
VoIP Resource Profiles
Codec Overview
Codec Payload Sizes
Dynamic Payload Type
Configuring the IP Address
Use the IP Address Configure (0x00E7) message to configure the following for the
VoIP module.

IP Address

Gateway Address

Subnet Mask
You can assign multiple IP addresses in a single API message. When an address is
assigned, the TCP/IP stack must be re-initialized.
Next task
Configuring Resource Attributes
Configuring Resource Attributes
Initial Configuration
For initial configuration, use the Resource Attribute Configure (0x00E3) message to
assign an IP resource profile to the VoIP modules. Use the IP Address AIB in the
Address Element Bock TLV (0x0009) to configure all channels on the VoIP module.
Modify During Established Call
You can use the Extended Span/Channel AIB in the Address Element Block TLV
(0x0009) in the Route Control (0x00E8) or Outseize Control (0x000C) messages to
606
Developer Information
modify these attributes during call setup. Use the Generic PPL ICB (0x1E) to include
the TLVs listed below.
Refer to VoIP Resource Profiles for a description of each profile including the codecs
and maximum number of VoIP channels supported.
Types of Attributes
There are three types of attributes to configure:

General

Fax

Voice
General Attributes
Use the following TLVs to set the general attributes for the VoIP module:



Type of Service (0x01D4) - Cost, reliability, throughput, delay, precedence
(Can be dynamically changed after call set up using the Resource Attribute
Configure message.)
Initial Media Inactivity Detection Timeout (0x01EB) - sets MID timer to
monitor channel for first valid UDP packet. Default is 0x0000 - Disabled. The
timer value is rounded to nearest second.
Media Inactivity Detection Timer (0x01EC) - Sets MID timer to monitor
channel for subsequent valid UDP packets. The timer value is rounded to
nearest second.
You can send the following four TLVs in the NPDI TLV ICB (0x0033).

Source IP Address (0x2792)

Destination IP Address (0x2794)


RTP Source Port (0x2793) - Can be even or odd port number.
RTP Destination Port (0x2795)
Voice Attributes
Use the following TLVs to set the voice attributes for the VoIP module:

RTP Payload Type (0x0100) - Specifies the algorithm used to compress
payload.

Payload Size - (0x0101) - Multiplication factor of basic packet rate

RTP Echo Cancellation (0x0103) - Eliminates echo introduced by impedance
mismatched hybrids.


RTP Silence Suppression (0x0102) - Enables RTP packets with silenceencoded compressed payloads
RTP Payload Redundancy (0x01D1) - Enables the re-transmission of previous
packet(s) payload with current packet payload.
607
MSP







Minimum Jitter Buffer Delay (0x01C2) - Sets minimum delay between 0-150
ms.
Maximum Jitter Buffer Delay (0x01C3) - Sets Maximum delay between 150200 ms.
Adaptation Rate (0x01C4) - Sets the sensitivity of the algorithm to latency
changes in the network.
Connection Mode - (0x01DB) - Specifies the voice path direction for a call
RFC 2833 Enable (0x01E2) - Enables DTMF signals to be relayed in the media
stream using a special RTP payload format.
RFC2833 Dynamic Payload Type (0x01F1) - Configures the RFC2833 dynamic
payload type number.
RFC 2198 Dynamic Payload Type (0x01F2) - Configures RFC 2198 dynamic
payload type number. You must first enable RFC 2198 using the RTP Payload
Redundancy TLV above.
Fax Attributes

Fax Type Enable (0x01C5) - Specifies fax relay or fax bypass modes

Fax Payload Redundancy (0x01D2) - Enables the re-transmission of previous
packet payload with current packet payload.

Fax Bypass Coder Type (0x01C7) - Specifies the high speed codec used in fax
bypass mode. Only G.711 allowed in current release.
The following four TLVs must be sent by the Route Control or Outseize Control
message - not the Resource Attribute Control message:




Source T.38 Port (0x01E6) - Specifies local T.38 port for fax relay. Cannot be
set on a module default level. Can be same as RTP Source Port.
Destination T.38 Port (0x01E7) - Specifies remote T.38 port for fax relay.
Cannot be set on a module default level.
Source RTCP Port (0x01E8) - Specifies the local RTCP port number for fax
relay. Defaults to RTP Source + 1. Can be even or odd.
Destination RTCP Port (0x01E9) - Specifies the remote RTCP port number for
fax relay. Defaults to RTP Source + 1.
Next task
Assigning Logical Spans
Assigning Logical Spans
608
Developer Information
Use the Assign Logical Span ID (0x00A8) message to assign all VoIP channels as
logical spans.
The number of logical spans is dependent on the resource profile. Refer to VoIP
Resource Profiles.
Use the Service State Configure (0x000A) message to bring the spans and channels
into service.
Reconfiguring the MSP
Reconfiguring the MSP
You should design your host application to ensure correct reconfiguration after
resets.
MSP Power-up
When you return power to the MSP, the software load must be reloaded and the
system must be reconfigured. The host must restore the customizations (such as
custom protocols) but it must wait until the Poll message indicates that the MSP is
ready to take configuration. Review all fields in the NGA System State Machine Notify
message to verify the contents of the MSP.
Single MSP Reset
Use the Poll message to detect an MSP reset. The MSP state changes from initialize
to startup, to offline, to active. If the MSP has a valid system software load, it retains
the load.
The MSP retains the configuration that was last sent by the host (except when the
MSP is being powered down).
When an MSP is reset, all calls that were previously connected are torn down and the
information on all of the in-service channels reports to the host. The host determines
the cause of the reset.
Software faults are automatically logged when a reset occurs. If a software fault
caused the reset, please send the Fault Log to Excel Technical Support. To obtain
Fault Logs, send the Fault Log Query message to the MSP.
Standby MSP Reset
The host is notified of a standby MSP reset two ways:


The Poll message from the standby MSP indicates that the MSP state has
changed from Standby or Standby Sync to Reset.
The Poll message from the active MSP indicates that the standby MSP has
reset.
The system software load is retained. The Poll messages of the standby MSP indicate
the return to the standby state. Any information shared by the active and standby
MSP is sent to the standby from the active MSP.
609
MSP
The active MSP sends a NGA System State Machine Notify message to the host
reporting on the standby MSP.
Active MSP Reset
The active MSP sends Poll messages to the host to report a reset. The host initiates
the MSP state changes. The Poll messages report the MSP state changes as it
transitions from Active to Initialize, to Offline to Standby to Standby Sync to Active
with Peer. The standby MSP sends Poll messages that report the MSP state changes
from Standby, to Switchover, to Active.
When the standby MSP changes to the active state, the MSP sends a NGA State
Notify message to the host. The MSP retains the configuration. We recommend
creating your host application so that it verifies that the MSP has retained the
configuration. You can use the configuration tags that are returned in the NGA
System State Machine Notify message.
SS7
Basics of SS7
Signaling System 7 (SS7) is a network protocol that provides control for
telecommunications networks. SS7 achieves this control by creating and transferring
the following tasks to various network components:

Call Processing

Maintenance

Network management
The MSP can act as an Service Control Point (SCP) in an SS7 network.
The MSP supports the following two architectures:


International Telecommunications Union - Technology Sector (ITU)
American National Standards Institute (ANSI)
Associated Mode Signaling
Associated Mode Signaling, shown in the next figure, is the typical international (ITUTS) architecture.
SS7 signaling between the MSP and the DPC is over a signaling link directly
connecting the MSP to the SP/SSP. There can be multiple signaling links between an
MSP and an SP.
Associated Mode Signaling
610
Developer Information
Quasi-associated Mode Signaling
Quasi-associated Mode Signaling is the typical North American (ANSI) architecture.
SS7 signaling between the MSP and SP/SSP is over a signaling link through one or
more STPs.
Quasi-associated Mode Signaling
SS7 Point Codes
The following discussion of point codes applies to any point codes:

Originating Point Code (OPC)

Destination Point Code (DPC)

Adjacent Point Code (APC)
See also point code information in the SS7 Route Configure message in the MSP
1010 API Reference.
ANSI Point Codes
An ANSI point code is assigned as DPC through Excel’s SS7 Route Configure
message (0x5F). Right after the AIB there are four bytes for DPC. The most
significant byte (MSB) byte is always 00 unless the DPC is being used to deconfigure
a DPC, in which case all bytes are FF. The other three bytes receive the three
elements of the point code, with Member portion of the point code in the least
significant byte (LSB) position.
Meaning
Network
Cluster
Member
611
MSP
Binary
8 Bits
8 Bits
8 Bits
Decimal
255
255
255
Hex
FF
FF
FF
ANSI Example:
Decimal Point Code = 158-077-099
1) First, convert each part of the point code into hex as follows:
9E-4D-63
2) Convert each byte to a 32-bit Excel format and use this as the last two bytes of
the point code in a Excel message. Zero-fill the first byte of the point code field:
Excel bytes = 0x00 0x9E 0x4D 0x63
ITU Point Codes
An ITU point code is assigned as DPC through Excel’s SS7 Route Configure message
(0x5F).
ITU Example:
Decimal Point Code = 2-2-2
1) First, convert each part of the point code into binary, padding it with zeroes to
conform to a 3-8-3 bit format (totaling 14 bits) as follows:
010-00000010-010
Note that the center part (country) has been padded out with zeros to make up the
full 8 bits required for the country part of the point code.
2) Concatenate the whole thing into a single string, as follows:
01000000010010
3) The string should be 14 bits long.
Counting from the right, form two groups of bits, the Least Significant Bits and the
Most Significant Bits:
010000 00010010
4) Pad the 6-bit group with zeros to make two full bytes:
00010000 00010010
5) Convert each byte to hex and use this as the last two bytes of the point code in a
Excel message. Zero-fill the first two bytes of the point code field:
612
Developer Information
Excel bytes = 0x00 0x00 0x10 0x12
JT Example:
Decimal Point Code = 2-2-2
1) First, convert each part of the point code into binary, padding it with zeroes to
conform to a 7-4-5 bit format (totaling 16 bits) as follows:
0000010-0010-00010
Note that the center part (country) has been padded out with zeros to make up the
full eight bits required for the country part of the point code.
2) Concatenate the whole thing into a single string, as follows:
0000010001000010
The string should be 16 bits long.
3) Counting from the right, form two groups of eight bits, the Least Significant Bits
and the Most Significant Bits:
00000100 01000010
4) Convert each byte to hex and use this as the last two bytes of the point code in a
Excel message. Zero-fill the first two bytes of the point code field:
Excel bytes = 0x00 0x00 0x04 0x42
SS7 in the MSP
Signaling End Point
The MSP implements the signaling end point function within an SS7 network.
The MSP generates and receives SS7 messages to manage voice circuits (ISUP) and
provide a transport mechanism for advanced intelligent network applications
(SCCP/TCAP).
The MSP can act as either of the following with an SS7 network architecture:

Service Switching Point (SSP)

Intelligent Peripheral (IP)

Service Control Point (SCP)
Multiple Stacks
The MSP can have up to four signaling stacks/point codes for simultaneous variants
or networks.
Signaling Links and Routes
The MSP supports the following:

up to 64 signaling links
613
MSP

redundant configurations - up to 128 links in two link increments

128 destinations


64/128 link sets
512 routes
Parts of SS7 Architecture
The MSP implements the following parts of the SS7 architecture:

Message Transfer Part (MTP) - Levels 1-3

Signaling Connection Control Part (SCCP)


Integrated Services Digital Network User Part (ISUP)
Transaction Capability Application Part (TCAP)
SS7 Protocol Support
SS7 functionality is determined by product license keys in addition to normal
configuration. The MSP supports the following SS7 protocols:

MTP Compliance:
ANSI T1.111.3 & T1.111.4 (1992), Telcordia GR-246 Issue 7 (Release 8.3.0)
ITU Q.703 & Q.704 (1993)
Japan TTC JT-Q.702 (1991), JT-Q.703 (1989), JT-Q.704 (1991); DDI; NTT

China YDN038 (1997), GF001-9001-MTP Part (1990)
ISUP Compliance:
ANSI T1.113 (1997), Telcordia GR-317 & GR-394
ITU Q.761-764 (1997)

ETSI 300-356-1 V3.2.2 (1998)
SCCP/TCAP compliance:
ANSI SCCP T1.112 (1996), TCAP T1.114 (2000)
ITU SCCP Q.711-714 (1996), TCAP Q.771-Q.774 (1997)
Related Topics
SS7 Capacity
Configuring SS7
Introduction to SCCP/TCAP
Introduction to ISUP
SS7 Software Architecture
614
Developer Information
Excel uses the PPL environment to implement the Excel SS7 stack. This feature
makes the stack modular and easy to customize. The SS7 software consists of the
following modules:

MTP

SCCP

TCAP
Each signaling stack must include MTP, L3P, and at least one user part. Selection of a
specific module automatically uses the associated default PPL components.
MTP
Message Transfer Part (MTP) is responsible for end-to-end reliable delivery of
messages generated by its local user part. The MTP module comprises the MTP2 and
MTP3 layers. MTP includes protocols and procedures to handle network failures and
to dynamically reconfigure signaling resources to prevent message loss or duplication
and out-of-sequence delivery.
MTP includes the following PPL components:
AERM
RCAT
TCRC
HMDT
RTAC
TPRC
CC
RSRT
HMRT
RTCC
IAC
RTPC
LLSC
RTRC
LSAC
SLTC
LSC
RC SUERM
TCBC
TLAC
TRCC
TSFC
TSRC
TXC
TCOC
SCCP/TCAP
Signaling Connection Control Part (SCCP) provides both connectionless and
connection-oriented network services above MTP Level 3. Transaction Capabilities
Application Part (TCAP) provides transaction and remote operation capabilities to a
large variety of applications distributed over the MSP and service centers in the
network. Excel’s SCCP/TCAP development supports the following connectionless
services:

Specialized Routing

Management Control

Data Transfer
Refer to SCCP/TCAP for a complete explanation of the SCCP/TCAP implementation in
the MSP.
615
MSP
SCCP Components
The following list contains the SS7 SCCP PPL components and their IDs:
0x65 SCLC - SCCP Connectionless Control
0x66 SCRC - SCCP Routing Control
0x67 SUSI - SCCP User Interface
0x68 SPPC - Signaling Point Prohibited Control
0x69 SPAC - Signaling Point Allowed Control
0x6A SPCC - Signaling Point Congestion Control
0x6B SSPC - Subsystem Prohibited Control
0x6C SSAC - Subsystem Allowed Control
0x6D SSTC - Subsystem Status Test Control
0x6E BCST - Broadcast
0x6F LBCS - Local Broadcast
TCAP Components
The following list contains the SS7 TCAP PPL components and their IDs:
0x70 TUSI - TCAP User Interface
0x71 CCO - Component Portion Control
0x72 ISM - Component Portion
0x73 TCO - Transaction Coordinator
0x74 TSM - Transaction State Machine
Causes of SS7 Signaling Link Problems
This section describes common causes that prevent SS7 signaling links from coming
into service or alignment.
Point code mismatch
The OPC (Originating Point Code) as defined in the SS7 Signaling Stack Configure
message must match the value that the distant end signaling point expects. Also, the
distant end's point code must match the APC (Adjacent Point Code) and DPC
(Destination Point Code) values defined in the SS7 Signaling Link Set Configure
message and SS7 Signaling Route Configure message.
Signaling link code mismatch
The Signaling Link Code (SLC) is a number (0-15) which is assigned by both ends to
identify a specific link within a link set. The SLC defined in the SS7 Signaling Link
Configure message must match the SLC value assigned to the link by the distant
end.
616
Developer Information
Network indicator mismatch
The Network Indicator (NI) value is defined by two bits (therefore values 0-3 are
possible). The default value of the Network Indicator is set to National (0x02) for
both ANSI and ITU. Some networks may require the Network Indicator to be set to
International (0x00) or one of the spare values (0x01 or 0x03). To change the NI
value, PPL Configure Messages need to be sent to components MTP3 HMRT and MTP3
HMDT. See the API Reference for complete information on configuration byte
locations and values.
Link status signaling unit size mismatch
By default, the MSPs transmit a Link Status Signaling Unit (LSSU) with a 2-octet
status field. Some signaling points may require a LSSU size of 1-octet. To change the
LSSU size, a PPL Configure Message needs to be sent to component MTP2 TXC.
Consult the MSP 1010 API Reference for complete information on configuration byte
locations and values.
Path and rate problem
A span carrying the signaling link must be configured for clear channel operation, in
service, and not experiencing slips. Both parties must agree upon the timeslots used
to carry the signaling link. Additionally, the data rate of the signaling link must be
the same on both sides. The Service State Configure message for signaling links is
different than the Service State Configure message used for channels. The signaling
link timeslot and data rate are defined in the SS7 Signaling Link Configure message.
No route defined
A valid SS7 route must be defined to the destination to enable the MSP to send
messages. This is typically indicated by received Signaling Link Testing Message
(SLTM) with no SLTMs being sent by the MSP.
SS7 Redundancy Overview
SS7 Redundancy is managed by the SS7 component state machines on redundant
MSPs communicating via a RCOMM connection. After configuring Logical Spans on
each MSP, you designate one MSP/SS7 as Primary/Active and the other as
Secondary/Standby.
The host is sent a notification whenever there is a state change involving the SS7
components. When the Active component fails, the host must activate the secondary
component.
In addition to the SS7 component, there is a System Controller component that
manages the entire system. The host is sent a System State Machine Notify message
any time a component changes state.
SS7 Redundancy
617
MSP
Host Communication
The following messages are used between the host and the SS7 component:
SS7 State Machine Configure
Use this message to configure the SS7 component for redundancy and other
attributes. To determine which attributes are supported for a specific component, use
the SS7 State Machine Query message:
0xE029 - SM Stop State Possibilities
0xE02B - SM Failure Behaviour Possibilities
0xE02D - SM (State Change) Requests Possibilities
S7 State Machine Query
Use this message with the SS7 Component AIB to query the status of the SS7
component as well as the configuration attributes supported for the component.
SS7 State Machine Notify
This message is sent to the host any time the SS7 component’s state changes.
States
618
Developer Information
All components have the following states:

Initial

Offline




Startup
Reset
Fail
Active
All redundant components have these additional states:

Active Sync

Active Lost Peer




Active W/ Peer
Standby Sync
Standby
Standby Lost Peer
Related Topics
Example Configuration for SS7 Redundancy (ClientView)
Configuring Redundancy on the SS7
SS7 Redundancy Process
Configuring Redundancy on the SS7 Component
You configure the SS7 component for redundancy using the SS7 State Machine
Configure message.
You can configure the redundancy attributes of a component when it is in one of the
following states:

Offline

Active_with_Peer

Active
If you attempt to configure a node’s redundancy when it is in any other state, you
will receive the following error:
Invalid State To Perform Operation (0xE061)
The SS7 configuration for the Standby node must be sent to the Active component
when it is in the Active_with_Peer State.
Steps
1) Assign Logical Node ID to MSP 1 (Local Node Configure)
2) Assign Logical Span IDs to MSP 1.
619
MSP
3) Configure SS7 Redundancy on MSP 1 by using the SS7 State Machine Configure
message and associated TLVs to do the following:

Establish MSP 1 communications link with MSP 2 (remote node).

Command (0xE001) TLV, Add (0x00) (Default)

Remote Node Address (0x8104) TLV, Links 64-127 for MSP 2


Logical Node ID (0x8100) TLV, Links 64-127 for MSP 2
Configure MSP 1’s redundant entity.


Logical Node ID (0x8100) TLV, Links 64-127 for MSP 2
Redundant Entity (0xE009) TLV, Primary Entity (0x01) (Default)
4) Make MSP 1 State Active.

State Change Request (0xE00F) TLV, Go Active (0x10) (Default)
Important! You must assign SS7 Signaling Links 0-63 to the Active MSP, and
Signaling Links 64-127 to the Standby MSP.
5) Assign Logical Node ID to MSP 2.
6) Assign Logical Span IDs to MSP 2.
7) Configure SS7 Redundancy on MSP 2 by using the SS7 State Machine Configure
message and associated TLVs to do the following:

Establish MSP 2 communications link with MSP 1 (remote node).

Command (0xE001) TLV, Add (0x00) (Default)

Remote Node Address (0x8104) TLV, Links 0-63 for MSP 1


Logical Node ID (0x8100) TLV, Links 0-63 for MSP 1
Configure MSP 2’s redundant entity.


Logical Node ID (0x8100) TLV, Links 0-63 for MSP 1
Redundant Entity (0xE009) TLV, Secondary Entity (0x02) (Default)
8) Make MSP 2 State Standby.

State Change Request (0xE00F) TLV, Go Standby (0x20)
9) Send all SS7 configuration (such as stack, link set, link ID, route) to Active MSP.
Important! Even when you are assigning Link IDs that physically reside on the
Standby MSP, you send the message to the Active MSP.
SS7 Redundancy Process
The figure below show the messaging and state changes associated with a basic SS7
redundancy scenario.
620
Developer Information
Configurable SS7 Component Attributes
The following are attributes configurable for the SS7 component.
User Defined Message Identifier
State Change Request
The following state change commands are supported:

Go Offline

Go Active


Go Reset
Go Standby
See SS7 State Transitions for more information.
621
MSP
Initial Stop State
This specifies which state the component should stop in without host control (Active
or Offline).
Component Failure Behavior
If any service within a component experiences a fatal error (generates an exception,
faults, or stops responding) the component transitions to the Failed state. There may
be a few exceptions where a service can be restarted, but generally, this is not the
case.
There are three configurable attributes for Component Failure Behavior:

Component Failure Behavior

Component Failure Restart State

Component Failure Count
Component Failure Behavior
The host can configure the appropriate behavior in the event of a component failure.
Options include:

Wait for Host Control

Restart SSM (Default)

Restart the component
If the configuration is to wait for host action, the component stays in the FAILED
State. In this state, the host can send down commands to perform diagnostics,
queries, and to restart. Currently, all component failures cause the system to restart.
Component Failure Count
If the failure behavior was to restart the component; this attribute indicates the
number of times it would reset before resetting the system.
Component Failure Restart State
This is usually the Initial Stop state. Alternatively, the host may want a component
to restart into the last valid stop state. The intent here is that you may want a
component to boot into the OFFLINE state, and restart into the ACTIVE state.
This would not be recommended for redundant components, but, for example, you
are running SS7 in a non-redundant configuration and the system resets, you may
want SS7 to automatically go back active.
Redundancy Entity
This attribute specifies if the component is configured as the Primary or Secondary
component.
Logical Node ID
622
Developer Information
This attribute specifies a component’s redundant peer. The peer Logical Node ID
must be configured on both nodes in a redundant system. It can be configured in the
Offline and Active state. If a component is in the Active state and receives a
synchronization request from another node, that node’s Logical Node ID must match
the configured Redundant Peer or else it will not transition to the Active Sync State.
Initial Stop State
The default Initial Stop State is Offline. Currently, this is not configurable.
Component Failure Behavior
The default Component Failure Behavior is Restart SSM. Currently, this is not
configurable.
SS7 State Transitions
Offline to Active
While Offline, no calls/transactions will be processed and the links will remain out of
service. Transitioning the component to the Active state (Go Active) will cause all of
the configuration data to be processed, allocating resources for each stack and
bringing the links into service. In the Active state, calls/transactions are processed.
A host request to “Go Active” requires an RCOMM link with its mate to be active. If
not, an error status of COMM LINK TO PEER DOWN (0x8180) is sent. If the
Redundancy Entity or Logical Node ID attributes are not configured, an error of
CRITERIA FOR STATE CHANGE NOT MET (0xE062) is sent.
Offline to Standby
Transitioning a component to the Standby State causes the SS7 configuration to be
cleared before entering the Standby Sync State. The component makes contact with
the Active node and attempts to synchronize with it.
After the components synch up, the active component transfers the Standby
component’s SS7 configuration, and the Standby verifies that its configuration is
valid (for example; links are assigned to valid span/channels).
If the Standby component’s configuration is invalid, it NACKS the configuration,
causing the Active component to clear the Standby component’s configuration and
notify the host. The Standby component will remain in Standby and the peers will
sync up.
Active to Active With Peer
Once a component is in the Active state and its redundant attributes are configured,
it will listen for a “Synchronization Request” for its mate. If the mate’s attributes are
valid (Logical Node ID matches the Redundant Peer and its Redundant Entity is
opposite ours), the component transitions to the Active_Synchronize state to start its
synchronization process. After synchronization, the Active component transitions to
the Active_With_Peer state. If contact is lost during synchronization, the component
transitions back to the Active State.
623
MSP
The host has no control in transitioning the component from Active to Active w/ Peer.
Note: A host request to “Go Active” does not require an active RCOMM link with its
mate.
Active With Peer to Active
While the component is in the Active_With_Peer state, it can get a request from the
host or its mate to go back to the Active state. If the event to go active is by the
host, the component will notify its mate that its severing the redundant link and that
it should go Offline. If the event was generated by its mate, it will ACK the
notification prior to going back to the Active State. Once back in the Active state, it
will continue to listen for a “Synchronization Request”.
Standby to Active
If communication is still possible between the two nodes, the Standby will inform the
Active that it is taking over, after which, it severs the link and transitions to the
Active State. The Active Component transitions Offline.
Standby or Active Lost Peer
If either component looses contact with its peer, it transitions to this holdover state.
In this state, it is waiting for the host to tell it what to do. The host has to
acknowledge the SS7 State Machine Notify message within 2 seconds. After
acknowledging the SS7 State Machine Notify message, the host has seconds to bring
the component into the Active state or the component transitions to the Offline state.
While in the Active_Lost_Peer state, calls are being processed as normal and the
component is not listening for the Standby. To re-synchronize, the host must first
bring one component Active and then the other Offline and then back to Standby.
Active/Standby to Offline
From any Active or Standby State, the host can transition the component to the
Offline state by issuing a Go Offline command. In this state, all resources are taken
out of service and the configuration data remains intact. Additionally, a component’s
mate can also issue a Go Offline command. This is done when the host tells the
Standby/Active component to Go Active.
NOTE: Currently, the SS7 component cannot transition to Offline. The host must
send down a Go Reset command instead.
SS7 State Machine Diagrams
Standalone
The next figure illustrates the state transitions and host interaction in the SS7
component for non-redundant SS7 configurations.
Non-Redundant SS7 State Machine
624
Developer Information
Redundant
The next figure illustrates the state transitions and host interaction in the SS7
component for redundant SS7 configurations.
Redundant SS7 State Machine
625
MSP
Host Link Failure
The Host Link Failure feature in the MSP detects the link between the SS7 tasks and
the host handling TCAP messages. If the link becomes unresponsive to messages,
the MSP determines that the link is down.
You can configure the SS7 task to alert the network that the subsystem is out-ofservice.
Configuring
626
Developer Information
Send the SCCP_TCAP Configure message to the MSP with the following two TLVs to
configure this feature. Each field in the TLV are explained below. Refer to the Excel
1010 API Reference for the format of the message and TLVs.
HLF Configuration (0xE035)


HLF Enable: enable or disable the host link failure feature.
HLF Declaration Timer - Set the amount of time from the inactivity set event
until the component declares an HLF action. You can set this value in 10
millisecond increments with the following minimum and maximum values.

Default - 600 (0x0258)

Maximum - 6000 (0x1770)

Minimum - 0
SCCP HLF Failure Behavior (0x9080)

SCCP HLF Behavior: you can report to the network that the HLF subsystem is
out of service (OOS).


0 - HLF Do Nothing
1 - HLF Subsystem OOS (default)
Example of Configuration Message
00 00 01 30 00 00 ff
NGA Configure
64 02 10 00
SS7
03 03 67 02 00 01
64 02 10 30
00 03 e0 01 00 02 00
02
e0 35 00 05 01 00 00
17 70
90 80 00 01 01
Signaling FA
SCCP
Command (0-add, 1-del, 2mod)
hlf cfg - enable, timer 60
seconds.
hlf behavior (SSN OOS)
H-X)
[00 29 01 30 00 00 ff 03 03 67 02 00 01 64 02 10 00 64
02 10 30 00 03 e0 01 00 02 00 02 e0 35 00 05 01 00 00
17 70 90 80 00 01 01]
X-H)
[00 17 01 30 00 00 01 00 10 03 03 67 02 00 01 64 02 10
00 64 02 10 30 00 00]
627
MSP
Querying
Send the NGA Configure Query message to the MSP to query the host link
configuration. Include the Query Select TLV (0xE011) to query all TLVs on the MSP.
Example of Query Message
In the following query, host link failure is enables and the failure behavior is to do
nothing.
00 2c 01 31 00 00 01 00 10
NGA Configure Query
64 02 10 00
SS7
03 03 67 02 00 01
64 02 10 30
00 03
e0 21 00 03 03 00 00
e0 35 00 05 01 00 00 17 70
90 80 00 01 00
Signalling FA
SCCP
# TLV's
Query Response Message Info
HLF
SSCP HLF Failure Behavior
Message Transfer Part (MTP)
This section includes information on the following MTP features:

Preventive Cyclic Retransmission (PCR)

ANSI Activation Link Test




Craft Alerting
Periodic Link Test
National Variant Support for China
Link set Configuration
Preventive Cyclic Retransmission (PCR)
Preventive Cyclic Retransmission (PCR) is an alternative method for SS7 signaling
link error correction. PCR should be used in situations with large propagation delays,
such as satellite circuits.
MSUs are stored by the transmitting terminal until a positive acknowledgment (ACK)
is received. When no new MSUs are to be sent, unacknowledged MSUs are
retransmitted cyclically until positively acknowledged.
PCR is enabled and configured with the PPL Config Bytes of the MTP2 Transmission
Control (TXC) component (0x26.)
Configuration
To implement PCR, you must modify the Config Bytes of the MTP2 TXC component
(0x26) with the PPL Configure message as follows:
628
Developer Information

Change the value of Config Byte 2 to 0x01 (PCR) using the PPL Configure
message.
MTP PPL Config Byte values are listed in the PPL Information.

Set the N2 Parameter Value (Config Bytes 4 and 5) to an appropriate value
for the signaling link loop delay using the following formula:
N2 = Tloop (in microseconds)/125 microseconds +1
For example, the typical satellite loop delay is approximately 500 milliseconds,
therefore:
N2 = (500000/125) +1 = 4001 bytes
The default value for Config Bytes 4 and 5 is 0xFFFF, which is for Basic mode error
checking.
Important! To initiate configuration changes, take the link out of service and then
bring it back in service with the Service State Configure message. Configuration
changes will also take affect if the link fails and realigns.
Example
This example PPL Configure message shows the typical PPL Configuration required to
implement PCR. The following configuration is performed:


Config Byte 2 (Mode) is set to 0x01 (PCR)
Config Bytes 4 and 5 (N2 Parameter Value) are set to 0x0FA1 (4,001 bytes)
Trace
H->X FE 00 15 00 D7 00 00 FF 00 01 09 02 03 00 26 01 03 02 01 04 0F 05 A1 CS
BYTE
Field Description
Value
1
Length, MSB
0x00
0
2
3
4
5
6
7
8
9
10
Frame
Length, LSB
Message Type, MSB
Message Type, LSB
Reserved
Sequence Number
Logical Node ID
AIB (starting with Byte
0):
Address Method
Number of Address
Elements
Address Element 1:
Originating Channel
0xFE
0x15
0x00
0xD7
0x00
0x00
0xFF
0x00 (Single Entity)
0x01
0x09 (SS7 Signaling
Link)
629
MSP
11
12
13
14
15
Originating Channel
Address Type
Link)
Data[0] Stack ID
0x00
Data Length
0x02
Data[1] Link ID
0x01
PPL Component ID,
MSB
0x00
PPL Component ID,
LSB
0x26 (SS7 MTP2
TXC)
17
Configuration Data
0x03
18
Location 1: Byte
Number
0x02
Location 2: Byte
Number
0x04
16
19
20
21
22
23
24
PPL Entity
Number of Data
Locations
0x01 (PPL Config
Bytes)
Location 1: Data
0x01 (PCR)
Location 2: Data
0x0F
Location 3: Data
0xA1 (with byte 4:
4,001)
Location 3: Byte
Number
Checksum
0x05
0xCS
Craft Alerting
If Craft Alerting is enabled, the host is sent a PPL Event Indication message with an
event of Link Activation Failure (0x02) if the MSP experiences persistent problems
while attempting to align SS7 signaling links.
By default, Craft Alerting is enabled for ANSI and disabled for ITU. Craft Alerting is
enabled (0) or disabled (1) with PPL Config Byte 1 of the MTP3 LSAC component
(0x002E.) The persistent timer (TA) is specified by PPL Timer 1 of the LSAC
component. The default is 60 s.
Craft Alerting is not supported by the Japanese variants.
MTP3 Signaling Link Tests
630
Developer Information
The testing of signaling links is provided through the LSAC (Signaling Link Activity
Control) PPL component (0x002E). See ANSI T1.111 for more information about
MTP3.
Activation Link Test
If the Activation Link Test is enabled, an SS7 link is not brought in service until the
point codes on either end of the link are verified by the MSP. If the point codes are
not verified, the host is sent a PPL Event Indication of Signaling Link Test Failure
(0x03).
The Activation Link Test is enabled by default for all variants. It can be disabled with
PPL Config Byte 2 of the MTP3 LSAC component.
The Activation Link Test cannot be disabled for the Japanese variants.
Periodic Link Test
If the Periodic Link Test is enabled, the MSP periodically verifies the point codes and
the Signaling Link Test on the link. If the point codes and the Signaling Link Code
(SLC) do not verify, the link fails and the host is sent a PPL Event Indication of
Signaling Link Test Failure (0x03).
The Periodic Link Test is enabled by default for all variants. It can be disabled with
PPL Config Byte 3 of the MTP3 LSAC component. The default period of the test is 60
seconds. This is configured with PPL Timer 3 of the MTP3 LSAC component.
National Variant Support for China
To enable MTP support for the China variant, perform the following:


Configure the signaling stack for the ITU variant
With the SS7 Signaling Stack Configure message, configure the Module Variant
for ITU (0x01)
Modify PPL Config Bytes with the PPL Configure message, as follows:

HMDT component (0x002B)

HMRT component (0x002C)
Set Config Byte 1 (Variant) to 0x03 (China)
Set Config Byte 1 (Variant) to 0x03 (China)
Important! MTP PPL configuration byte values are listed in the chapter, PPL
Information. National variants may require additional User Part and protocol
modifications.
Link Set Configuration
“A” link sets must be configured with even numbered Link Set IDs (for example; 0,
2, 4.) “B” links must be configured with odd Link Set IDs (for example; 1, 3, 5.) An
A/B link set pair configured to an adjacent signaling point must be configured with
consecutive Link Set IDs (for example; 0/1, 2/3, 4/5.)
631
MSP
Combined Link Set
The Combined Link Set feature is part of the MSP architecture’s MTP3 layer and
supports ANSI and ITU applications. This feature provides the following options:



The host can configure a combined link set as part of the route configuration,
using the SS7 Signaling Route Configure (0x5F) message.
Load sharing of traffic is possible within the combined link set.
The 5-bit Signaling Link Selection (SLS) is the default value for the
configuration byte (0x0E) in the MTP3 HMRT PPL component (0x2C):
The 5-bit SLS is the default for hierarchical routing to enable backward compatibility
with traffic using 32 SLS values to assign to links in a network.
The 8-bit SLS option is not supported in this release.
Combined Link Set
A route is the combination of one or more link sets used to reach a specific
destination. Each link set can belong to more than one route, and contains from 1 to
16 links. A primary route exists for every destination, and represents the fastest
path, and least cost, to that destination.
A combined link set establishes the availability of alternate routing configurations
that can each serve as a primary path, providing load sharing across the network.
Within a combined link set, which can maintain up to a total of 32 links in any
combination of link sets, every link is given an equal priority in the routing
assignments to the same destination. This means that the more paths that exist to a
specific destination in a network, the more reliably messages can be transmitted,
even when one or more configured routes fail or experience power outage for any
reason.
In the combined link set feature, a routing table tracks the links that have been
configured, lists the links that are currently available, and indicates when an update
to the network topology is required.
The combined link set will contain links to both Signal Transfer Points (STPs) in an
SS7 network that are paired for redundancy and connected to each other by cross
links).
632
Developer Information
The SLS is the Least Significant Byte (LSB) of the CIC Number, which is found in the
routing label of the user part assigned.
If there is only one link set, the LSB serves to identify the link, but the Most
Significant Byte (MSB) is not used.
See SS7 Signaling Route Configure (0x5F) in the MSP 1010 API Reference for
selection of the MSB or LSB values which allow the route to be configured as part of
a combined link set.
Routing Label
SS7 addressing for nodes, networks, and groups of signaling points in a specific area
is done through the use of a point code. A unique 24-bit (three-octet) point code or
numeric address is part of the routing label used in the ANSI SS7 MTP3 layer to
route the signaling information for a call. This label, which is part of the Signaling
Information Field (SIF) of a Message Signal Unity (MSU), contains:

An 8-bit Destination Point Code (DPC) identifying the termination point

A Signaling Link Selection field (SLS) that is used to distribute message traffic
over all possible redundant links and routes.

An 8-bit Originating Point Code (OPC) identifying point of origin for the
message.
Other information about the call, which can include data such as the connection type
(bearer capability), carrier identification, and the identification of an unlisted calling
number, is also sent as part of the routing label. For the purposes of this document,
only the 3-octet point code is relevant.
Destination Point Code
When the routing function is activated, the DPC is used by a node to select and
determine the link set or combined link set for an outgoing message. The network
identifier (Network ID) in the DPC directs the message to a particular SS7 network.
The DPC may contain the point code of the next node involved in the transmission
route or it can be the final node for the entire route.
Signaling Link Selection
Signaling Link Selection (SLS) is used for load sharing when two or more links
connect adjacent signaling points. Its function is to distribute the traffic evenly. Each
signaling link is assigned an SLS value. This SLS value never changes and identifies
the link that the message is routed over. The SLS value must match at both ends of
the signaling link.
The SLS is used to select the link within a selected link set to:

Ensure the sequencing of messages. Any two messages that are sent with the
same SLS will always arrive at the destination in the same order in which they
were originally sent. That is, if messages are intended to be kept in sequence,
the same SLS code will be used so that all such messages take the same path
633
MSP
to the destination. For example: a signaling link with ISUP will have the same
SLS code used for all messages related to that particular link.
The purpose of the above functionality is to provide the option to reconfigure the
signaling network if there are signaling link or signaling point failures, and to control
traffic in the event of congestion, blocks or bottlenecks. When a failure occurs, the
reconfigurations are carried out so that messages are not lost, duplicated, or placed
out of sequence, and excessive message delays are avoided.
The figures below display the SLS values both for a single link set containing four
individual links and a combined link set containing two link sets:
Load Sharing within a Single Link Set
Load Sharing in a Combined Link Set
Implementing Combined Link Set
To implement the Combined link set with the 5-bit SLS routing table, the following
MTP3 PPL components apply:
TSRC
634
Developer Information
TSRC handles the traffic management route control of MTP3; currently it maintains a
routing table per destination, and the routing data is kept in the SLS table. This table
is updated when a route is added or removed, or when the first MSU is routed for
that route.
HMRT
The SLS table is updated in HMRT to include new routes and all the links of the
combined link set, in order to distribute the traffic evenly.
TCOC and TCBC
These components are used for the routing functions of changeover and changeback.
It is in these components that all necessary changes are made to distribute the
traffic based on the normal SLS table. The TSRC component marks the SLS table
whenever a new route is added or deleted. This means the table must be updated.
Then when an MSU is routed to that destination and the SLS table is already marked
with the addition or deletion action, the table will be updated.
All three components--TCBC, TCOC and TSRC--will update the list of available links
when required.
Changeover
When changeover to another route begins, traffic is buffered for that link. All
destinations will be marked when that is complete. Then traffic will be sent on
alternate links once the changeover ends, and the SLS table will be updated to
indicate the new links that are now carrying traffic. Again, this update will only take
place when the first MSU is routed.
Changeover diverts traffic from an unavailable link to one or more available links,
without message loss, mis-sequencing or duplication.
Important! Traffic is load shared between the two links from the SP to the mated pair
of STPs. The STP monitors the error rate. If a link’s functionality deteriorates, the
STP will initiate a changeover, thus routing all traffic on to one link. When the faulty
link is repaired, the STP will then order a changeback request and traffic is routed
back to that link and load sharing is restored.
Changeback
All destinations are marked when changeback begins, and traffic is re-distributed
from alternate links to the link coming up. The SLS table is updated immediately and
the alternate links start to buffer traffic. This update occurs, however, only if there is
an MSU to be routed to the destination.
Once Changeback is acknowledged by the link coming up, it will buffer the traffic for
that alternate link, according to the updated SLS table.
Changeback diverts traffic back to the original route once it becomes available.
Important! A changeover order is always sent over an alternate link, while a
changeback order can be routed over any available link.
Custom SS7 Variants
635
MSP
SS7 variants typically consist of protocol tables along with configuration byte
settings, PPL (Programmable Protocol Language)timer settings, modifications to the
format of existing ISUP messages, and/or the creation of an entirely new ISUP
message. Prior to applying a custom variant to the MSP using ClientView, the
protocol tables and changes to the ISUP Message Configuration Template (MCT), if
any, are to be copied to a folder specific to the variant, which by default the folder
is:
C:\Program Files\Cantata\common\config\variant\variantname\filename
After the variant file is copied to this folder, ClientView can link to this file during the
creation of the signaling variant. The configuration byte and/or PPL timer settings
specific to the variant are explicitly created using ClientView. That is to say, unlike
the protocol tables or MCT file, there is no flat file pertaining to these settings.
Steps
1. Create a sub-folder in ...\common\config\variant. For example:
C:\Program Files\Cantata\common\config\variant\RISUP
2. Copy the protocol tables to ...\common\config\variant\<variant name>. For
example:
C:\Program Files\Cantata\common\config\variant\RISUP\rus_cpc12.cfg
C:\Program Files\Cantata\common\config\variant\RISUP\rus_l3pcic13.cfg
Protocol tables are available on request, contact Cantata Technical Support.
3. Changes to the ISUP Message Configuration Template are encapsulated in
raw hex files which are to be copied to ...\common\config\variant\<variant
name>. For example:
C:\Program Files\Cantata\common\config\variant\RISUP\MCT.cfg
See contents of the example: MCT.cfg.
4. Launch ClientView and open the “New Signaling Variant” pane:
Variant
636
Cantata MSP EMS -> New Signaling Variants -> New Signaling
Developer Information
Variant Name must match the name given to the C:\Program
Files\Cantata\common\config\variant\<variant name> folder.
Variant ID must match the protocol Table Id defined in the protocol tables (raw
hex files)
5. In ClientView, create a New Variant Entry for protocol tables, MCT.cfg file,
configuration byte settings, and PPL timer settings:
5. Configure an SS7 stack with the new variant by selecting the variant from the
drop-down list for the field, SS7 Variant. See configuring an SS7 Stack.
MTP3 to Host
637
MSP
Introduction to MTP3-to-Host
The MTP3-to-Host feature allows any of the SS7 User Parts to be resident in the
host. It forwards the User Part information to a host but MTP traffic is still channeled
through the MSP.
The host destination can be one of many destinations. You configure it using the
appropriate PPL command. The MTP3 layer checks if a remote User Part is active and
sends the message to the appropriate remote destination.
Based on Remote User Part configuration, the signaling message will bypass the MSP
internal User Part and deliver to the remote host.
Prerequisites


This feature assumes that there is a workable User Part available in a selected
remote host.
You first configure a stack and then redirect the User Part information to the
remote host.
Data User Part
The Data User Part (DUP) is a call control user part designated for switched data
services.
Message Structure
The task of sending resident user parts to a remote host is basically performed
through MTP3 detecting user parts in SS7 messages and forwarding those user parts
to the appropriate host in a PPL Event Indication (0x0043) message. See the next
diagram.
638
Developer Information
MTP3-to-Host Functionality
MTP3 Components
Most of the changes required to support the MTP3-to-Host functionality reside on the
MSP itself. This functionality is made possible with the following MTP3 components:



HMDT - Message Distribution
HMDT module is a component of MTP3 layer. This component routes the
TRANSFER indications from MTP2 to the appropriate User Part.
HMRT - Message Routing
HMRT is a component of the MTP3 layer. This component routes messages
coming from layer 4 and selects the signaling link over which it is routed. It
handles TRANSFER requests from layer 4.
TSFC - Traffic Signaling Flow Control
TSFC Module is a component of the MTP3 layer. This component controls the
signaling traffic flow in the case when the signaling network is not capable of
transferring all signaling traffic because of network failure or congestion.
When an SS7 user part is activated for a remote host then the destination of the
message can be any one of several remote hosts. This option is configurable using
the PPL Configure message.
Data Flow
The figure below shows the data flow between MTP3 components and the remote
host. The dashed line represent MTP3 components in the MSP.
639
MSP
The HMDT component of MTP3 will use new configuration bytes to allow you to
program which SS7 user parts will remain local to the MSP and which user parts will
reside in a remote host. The default is that all the user parts reside on the MSP.
MTP3 HMDT (0x2B) configuration bytes 0x27-0x33 are used to indicate the port
number of the remote host for the corresponding user part. For example, if user part
in configuration byte 0x19 is set to 0x02 (ISUP remote host), then configuration byte
0x29 will give the port number of the ISUP remote host. The default value of these
bytes is 0xFF.
The new PPL event indication from the HMDT component to the host reports
TRANSFER IND and sends the corresponding data to the host.
The new PPL event indications from the component TSFC to Host report the STATUS
of a DPC or PAUSE and RESUME indications for an affected DPC.
The new PPL event request from the host to HMRT component is a TRANSFER
Request from the Host to the HMRT component.
The default sequence of these events is from the corresponding MTP3 component to
a specific SS7 user part on the MSP. However, if you configure the HMDT
configuration bytes then the events flow to a remote User Part resident in a remote
host. This may be achieved on a per User Part basis. Also, there may be multiple
remote hosts. In this case, the port number of the remote host is stored in a specific
HMDT configuration byte.
Software Modifications
The following summarizes the changes to the software to support this feature. The
detailed formats are below this summary.
HMDT PPL Information
640
Developer Information
Configuration Bytes
The HMDT (Message Distribution) component of MTP3 uses configuration bytes to
allow you to program which SS7 user parts will remain local to the MSP and which
user parts will reside in a remote host. The default is to have all the user parts in the
MSP.
PPL Event Indications
There is a PPL Event Indication from the HMDT component to the host. The events
reports TRANSFER IND and sends the corresponding data to the host.
TSFC PPL Information
PPL Event Indications
There are three PPL event indication from the component TSFC (Traffic Signaling
Flow Control) to the host. These events report the STATUS of a DPC or Pause and
RESUME indications for an affected DPC.
HRMT PPL Information
PPL Event Request
There is a PPL event request, TRANSFER, from the host to the HMRT (Message
Routing) component.
The default sequence of these events is from the corresponding MTP3 component to
a specific SS7 user part of the MSP. However, if you configure the HMDT
configuration bytes, then the events flow to a remote user part resident in a remote
host. You can achieve this process on a per user part basis. Also, there might be
multiple remote hosts. In this case, the port number of the remote hot is stored in a
specific HMDT configuration byte.
ICB
There is a ICB for MTP to remote UP. It is MTP3 UP Parameters (0x002B).
Detailed PPL and API Information
PPL Event Request for MTP HMRT Component (0x002C)
AIB: SS7 Stack (0x08)
Event ID
0x0A
Event
TRANSFER REQ
Used to send MSU data.
Parameter IDs - 0x0424, 0x0425,
0x0426
641
MSP
PPL Event Indication for the HMDT Component (0x002B)
Event ID
0x14
Event
TRANSFER IND
Used to send MSU data.
Parameter IDs - 0x0424, 0x0425,
0x0426
PPL Event Indication for the TSFC Component (0x003F)
Event ID
0x15
0x16
0x17
Event
PAUSE IND
Parameter ID - 0x0427
RESUME IND
Parameter ID - 0x0427
STATUS IND
Parameter ID - 0x0427
PPL Event Parameters
ICBType
0x03 (Extended Data)
Data Length
0x000D
ICB ID
2 bytes
0x0424
Data[0-3]
DPC - Destination Point Code
Data[8-9]
CIC - Circuit ID Code
Data[4-7]
Data[10]
Data[11]
Data[12]
ICBType
642
OPC - Originating Point Code
SI - Service Indicator
MP - Message Priority
NI - Network Indicator
0x03 (Extended Data)
Developer Information
ICB ID
Data Length
2 bytes
0x0425
0x000C
Data[0-3]
DPC - Destination Point Code
Data[8]
SI - Service Indicator
Data[4-7]
Data[9]
Data[10]
Data[11]
OPC - Originating Point Code
MP - Message Priority
NI - Network Indicator
SLS - Signaling Link Set
ICBType
0x03 (Extended Data)
Data Length
Up to 0x010E
ICB ID
2 bytes
Data[0-1]
Data[2-n]
0x0426
Length - Length of MSU Data
MSU Data -
Length up to 0x010C
ICBType
0x03 (Extended Data)
Data Length
Up to 0x0006
ICB ID
2 bytes
Data[0-3]
Data[4]
0x0427
Affected DPC
Cause Value
Value 0 - congestion level 0
Value 1 - congestion level 1
Value 2 - congestion level 2
Value 3 - congestion level 3
Value 4 - User Part Unavailable
Value 5 - User Part Unequipped
Data[5]
Value 6 - User Part Inaccessible
User Part
643
MSP
PPL Configuration Bytes for HMDT Component (0x002B)
AIB: SS7 Stack (0x08)
Byte
0x17
0x18
0x19
0x1A-0x23
Description
SCCP User Part
TUP User Part
ISUP User Part
Other User Part
Value
0x00-unavailable
0x01-available locally
(default)
0x02-available
remotely
0x00 -unavailable
0x01-available locally
(default)
0x02-available
remotely
0x00-unavailable
0x01-available locally
(default)
0x02-available
remotely
0x00unavailable(default)
0x01-available locally
0x27
Remote host port
number for SCCP
UP
0x02-available
remotely
0x00-forces routing to
port 0x3142
0x01-forces routing to
port 0x3143
0x02-forces routing to
port 0x3144
0x03-forces routing to
port 0x3145
0x04-forces routing to
port 0x3146
0x05-forces routing to
port 0x3147
0x28
644
Remote host port
number for TUP UP
0xFF-(Default) force
routing disabled
0x00 - forces routing
to port 0x3142
Developer Information
number for TUP UP
to port 0x3142
0x01 - forces routing
to port 0x3143
0x02 - forces routing
to port 0x3144
0x03 - forces routing
to port 0x3145
0x04 - forces routing
to port 0x3146
0x05 - forces routing
to port 0x3147
0x29
Remote host port
number for ISUP UP
0xFF - (Default) force
routing disabled
0x00 - forces routing
to port 0x3142
0x01 - forces routing
to port 0x3143
0x02 - forces routing
to port 0x3144
0x03 - forces routing
to port 0x3145
0x04 - forces routing
to port 0x3146
0x05 - forces routing
to port 0x3147
0xFF - (Default) force
routing disabled
MTP3 UP Parameters (0x002B)
ICB Type
0x03
Extended Data
ICB Length
MSB, LSB
Length of Parameters
in bytes
ICB Subtype
0x002B
Parameter 1:
Type
2 bytes
Parameter 1:
Value
Variable size
Parameter 1:
Length
2 bytes
MTP3 UP Parameters
Identifies parameter
Length of parameter
data in bytes
Size in bytes
645
MSP
:
:
:
Parameter n:
Length
2 bytes
Length of parameter
data in bytes
Parameter n:
Type
Parameter n:
Value
2 bytes
Variable size
Identifies parameter
Size in bytes
Configuring MTP3-to-Host
This feature can be configured using the SwitchKit user interface, ClientView. See
Multi-Host Socket. For non-SwitchKit users, the MTP3-to-Host feature can be
configured using Excel API. Follow the steps below to use Excel API.
1. Ensure that the SS7 stack is configured with local ISUP.
2. Send the PPL Configure (0x00D7) message to the MSP 1010 with
configuration byte 0x19 set to 0x02 (Remote Host) on component 0x002B
(MTP3 HMDT). Refer to MPT3 HMDT PPL Configuration Bytes in Summary of
Software Modifications.
3. (Optional Step). You can force the routing of the messages to a particular
port by configuring config bytes 0x27-0x33 of HMDT component (0x002B)
accordingly.
For example, setting config byte 0x29 to a value of 0x02 forces the <ISUP>
PPL Transfer Indication message to be sent to port 0x3144 (no indication
received on any other port). The host can still send the Transfer Request
messages from any port.
MTP3-to-Host Example
The next example illustrates the message flow from an ISUP call where two stacks
on the same MSP 1010 are configured for remote ISUP. Each step in the call flow is
described below. This call flow would also be the same if you were to use two
separate MSP 1010s and two separate hosts.
The call flow for the call release follows the call flow below.
646
Developer Information
Call Flow Steps
The following steps break down the call flow. The OPCs of the stacks are as follows:
Stack 0: OPC is 0-0-3
Stack 1: OPC is 0-0-6
1. The host sends the Transfer Request (0x0A) for IAM to the MSP 1010 for
Component MTP3 HMRT (0x002C) on stack 1.
H->X
00 44 00 44 00 28 04 00 01 08 01 01 00 2c 00 0a 01 03 00 2b 00 30 04 25 00 0c 00
00 00 03 00 00 00 06 05 00 02 00 04 26 00 1c 01 01 01 00 20 00 0a 00 02 09 07
03 10 05 88 26 53 00 0a 07 03 11 05 88 26 03 00 00
2. The MTP3 transmits an IAM on the SS7 link.
3. The MTP3 on Stack 0 receives an IAM and sends a Transfer Indication (0x14)
for IAM from component HMDT (0x002B) to the host.
X->H
00 44 00 43 00 25 04 00 01 08 01 00 00 2b 00 14 01 03 00 2b 00 30 04 25 00 0c
00 00 00 03 00 00 00 06 05 00 02 00 04 26 00 1c 01 01 01 00 20 00 0a 00 02 09
07 03 10 05 88 26 53 00 0a 07 03 11 05 88 26 03 00 00
4. The host sends a Transfer Request (0x0A) for ACM to the MSP 1010 for
Component MTP3 HMRT (0x002C) on stack 0.
647
MSP
H->X
00 2e 00 44 00 29 04 00 01 08 01 00 00 2c 00 0a 01 03 00 2b 00 1a 04 25 00 0c 00
00 00 06 00 00 00 03 05 00 02 00 04 26 00 06 01 01 06 10 00 00
5. MTP3 transmits ACM on the SS7 link.
6. MTP3 on Stack 1 receives an ACM and sends a transfer indication (0x14) for
ACM from component HMDT (0x002B) to the host.
X->H
00 2e 00 43 00 26 04 00 01 08 01 01 00 2b 00 14 01 03 00 2b 00 1a 04 25 00 0c
00 00 00 06 00 00 00 03 05 00 02 00 04 26 00 06 01 01 06 10 00 00
7. The host sends a Transfer Request (0x0A) for ANM to the MSP 1010 for
Component MTP3 HMRT (0x002C) on stack 0.
H-X
00 2c 00 44 00 2a 04 00 01 08 01 00 00 2c 00 0a 01 03 00 2b 00 18 04 25 00 0c
00 00 00 06 00 00 00 03 05 00 02 00 04 26 00 04 01 01 09 00
8. MTP3 transmits an ANM on the SS7 link.
9. MTP3 on Stack 1 receives an ANM and sends a Transfer Indication (0x14) for
ANM from component HMDT (0x002B) to the host.
X-H
00 2c 00 43 00 27 04 00 01 08 01 01 00 2b 00 14 01 03 00 2b 00 18 04 25 00 0c
00 00 00 06 00 00 00 03 05 00 02 00 04 26 00 04 01 01 09 00
10. The call is established.
Transfer Request
The following decribes in more detail the transfer request for an IAM:
00 44 'length
00 44 'message type
00 28 'seq
04 'node id
00 01 08 01 01 'stack aib
00 2c 00 0a 'mtp transfer request See API Reference
01 'number of icbs
03 'icb type - extended
00 2b 'icb subtype - raw_msu_data
00 30 'length
04 25 'parameter name
00 0c 'length
00 00 00 03 'dpc
00 00 00 06 'opc
648
Developer Information
05 'service indicator
00 'message priority See MTP3 to Host SDS
02 'network indicator
00 'signaling link set
04 26 'parameter name
00 1c 'length
01 01 'CIC
01 'msg id (IAM)
00 'MF parameter 1 - Nature of Connection
20 00 'MF parameter 2 - Fwd Call Indicator
0a 'MF parameter 3 - Calling Party's Category
00 'MF parameter 4 - Transmission Medium Requirement
02 'pointer to MV parameter
09 'pointer to optional parameter
07 'length of MV parameter
03 10 05 88 26 53 00 'MV parameter - Called Party Number
0a 'optional parameter 1 name - Calling party number
07 'optional parameter 1 length
03 11 05 88 26 03 00
'optional parameter 1 value
00 'end of optional parameters.
Transfer Indication
The following decribes in more detail the transfer indication for an IAM:
00 44 'msg length
00 43 'msg type
00 25 'seq
04 'node id
00 01 08 01 00 'stack aib See Excel Reference Manuals
00 2b 00 14 'transfer indication
01 'number of icbs
03 'icb type - extended
00 2b 'icb subtype - raw_msu_data
00 30 'length
04 25 'parameter name
00 0c 'length
00 00 00 03 'dpc
00 00 00 06 'opc
649
MSP
05 'service indicator See MTP3 to Host SDS
00 'message priority
02 'network indicator
00 'signaling link set
04 26 'parameter name
00 1c 'length
01 01 'CIC
01 'msg id
00 'MF parameter 1 - Nature of Connection
20 00 'MF parameter 2 - Fwd Call Indicator
0a 'MF parameter 3 - Calling Party's Category
00 'MF parameter 4 - Transmission Medium Requirement
02 'pointer to MV parameter
09 'pointer to optional parameter
07 'length of MV parameter
03 10 05 88 26 53 00 'MV parameter - Called Party Number
0a 'optional parameter 1 name - Calling party number
07 'optional parameter 1 length
03 11 05 88 26 03 00
'optional parameter 1 value
00 'end of optional parameters.
Call Release
650
Developer Information
Send transfer request (0x0a) for REL to matrix for Component MTP3 HMRT (0x2c) on
stack 1.
H-X
00 2c 00 44 00 00 04 00 01 08 01 01 00 2c 00 0a 01 03 00 2b 00 18 04 25 00 0c 00
00 00 03 00 00 00 06 05 00 02 00 04 26 00 04 01 01 12 00
MTP3 on Stack 0 receives REL and sends a transfer indication (0x14) for REL from
component HMDT (0x2b) to the host.
X-H
00 2c 00 43 00 1a 04 00 01 08 01 00 00 2b 00 14 01 03 00 2b 00 18 04 25 00 0c 00
00 00 03 00 00 00 06 05 00 02 00 04 26 00 04 01 01 12 00
Send transfer request (0x0a) for RLC to matrix for Component MTP3 HMRT (0x2c) on
stack 0.
H-X
00 2c 00 44 00 00 04 00 01 08 01 00 00 2c 00 0a 01 03 00 2b 00 18 04 25 00 0c 00
00 00 06 00 00 00 03 05 00 02 00 04 26 00 04 01 01 10 00
MTP3 on Stack 1 receives RLC and sends a transfer indication (0x14) for RLC from
component HMDT (0x002B) to the host.
X-H
00 2c 00 43 00 1b 04 00 01 08 01 01 00 2b 00 14 01 03 00 2b 00 18 04 25 00 0c
00 00 00 06 00 00 00 03 05 00 02 00 04 26 00 04 01 01 10 00
Virtual Circuit Identification Codes (CICs)
Virtual Circuit Identification Codes (CICs) OverView
The virtual SS7 Circuit Identification Codes feature enhances an MSP's ability as a
signaling platform. This feature allows configuration of virtual T1 and E1/J1 spans,
not physically present on the MSP 1010 itself. The MSP terminates the corresponding
control channels for SS7 signaling links, and provides management functionality to
the voice circuits.
The MSP is oblivious to any differences between the physical spans on it and the
virtual spans configured. Configuring virtual CICs on the MSP, allows physical links or
voice circuits with their voice and data traffic to be terminated on another MSP
outside the MSP platform. The MSP simply terminates control channels for the SS7
signaling links, ISDN channels, and provides management of SS7 CICS and ISDN B
Channels.
The MSP 1010 supports ISUP signaling regardless of the presence and termination of
the voice traffic. The MSP supports ISUP signaling (of virtual CICs) over M3UA and or
MTP3.
Diagram
This diagram shows the software components related to the SS7 Virtual CIC feature.
651
MSP
Related Topics
Configuring SS7 Virtual CICs using API
Call Flows for Virtual Spans
Example Configuration for Virtual Circuit Identification Codes (CICs) using ClientView
Licensing
Each virtual CIC requires a license. The licenses are available in increments of 960
virtual CICs.
This license activates the feature only with the presence of base SS7 protocol or
SCTP/M3UA license.
Performance
The same level of performance is provided for normal calls using virtual spans as
using real spans.
Capacity
The MSP supports 9600 virtual CICs, which would corresponds to 400 T1s or 300
E1s. These virtual CICs are supported on an SS7 server node only.
Network Interaction
SS7 network interaction follows the SS7 ISUP protocol.
SS7 Redundancy
652
Developer Information
SS7 redundancy is supported using virtual CICs.
API Messages
A set of API messages allow a host application to configure, control and query the
MSP 1010 virtual span entities. Call processing API messages utilizing virtual
span/channels are backward compatible. The virtual spans/channels in the call
processing API messages have the same format as the MSP real span/channels.
Configuring SS7 Virtual Circuit Identification Codes (CICs)
Use this information to configure virtual Circuit Identification Codes (CICs) using
Cantata's API. If you want to configure this feature using ClientView, see Example
Configuration for Virtual Circuit Identification Codes (CICs).
Note: A call processing application using virtual channels will be connected to
the physical bearer channels independent of SwitchKit and the MSP. The
application must bring virtual channels in-service after bearer channels are inservice. The virtual channels cannot come in-service, unless the bearer
channels are in-service. The application has knowledge of the bearer channel's
status and therefore it needs to manage the virtual span's service state
accordingly. In other words, SwitchKit will not bring virtual spans in-service
automatically. It relies on an associated SwitchKit application to bring the
virtual spans in-service at the appropriate time.
Configure Virtual CIC and Bring In-service
1. Configure the Virtual Span using the Virtual Span Configure NGA message.
2. Configure the SS7 Virtual CICs using SS7 CIC Configure API (0x006a)
3. Bring Virtual Span in service using Service State Configure API message
(0x000a).
4. Bring virtual span/channel in service using Service State Configure API
message (0x000a).
Bring Virtual CIC Out-Of-Service and De-configure Virtual CIC
1. Bring Virtual Span out of service using Service State Configure API message
(0x000a).
2. De-configure the SS7 Virtual CICs using SS7 CIC Configure API (0x006a)
3. De-configure the Virtual Span using the Virtual Span Configure NGA message.
Querying SS7 Virtual CICs
1. Use the Virtual Span Query NGA message to query the configured virtual
span.
2. Use the Span Status Query API message (0x0084) to query the virtual span
status.
653
MSP
Call Flows for Virtual Spans
For more information on Virtual Circuit Identification Codes (CICs)
Perform COT testing for an incoming call through a VCIC
This call flow shows host-controlled continuity (COT) testing being performed for an
incoming call through a virtual Circuit Identification Code (CIC).
Perform COT testing for an outgoing call through a VCIC
This call flow shows host-controlled continuity (COT) testing being performed for an
outgoing call through a virtual Circuit Identification Code (CIC).
654
Developer Information
Perform COT testing using CRM for an outgoing call through a VCIC
This call flow shows host-controlled continuity (COT) testing being performed using a
Circuit Reservation Message (CRM) for an outgoing call through a virtual Circuit
Identification Code (CIC).
655
MSP
Perform COT testing using CRM for an incoming call through a VCIC
This call flow shows host-controlled continuity (COT) testing being performed using a
Circuit Reservation Message (CRM) for an incoming call through a virtual Circuit
Identification Code (CIC).
656
Developer Information
Generating COT failure for an outgoing call
This call flow shows a continuity (COT) test failure being generated for an outgoing
call and the virtual Circuit Identification Code (CIC) being released.
657
MSP
Generating COT failure for an incoming call
This call flow shows a continuity (COT) test failure being generated for an incoming
call and the virtual Circuit Identification Code (CIC) being released.
658
Developer Information
Monitoring SS7
Introduction to SS7 Monitoring
The MSP 1010 has the ability to monitor SS7 links allowing an application to
intercept SS7 traffic. The MSP 1010 interprets the signaling data being monitored in
real time and forwards the Message Signal Units (MSUs) directly to monitoring
application(s) with no intervention by an operator or intrusion into communications.
Since there is no transmission allowed on the monitoring links, these links do not
interfere with the "live" SS7 links — the links that are being monitored. The SS7
monitoring software module supports ITU, ANSI, China, or Japan MTP and is capable
of monitoring E1 or T1 links.
To configure SS7 monitoring using SwitchKit see Example Configuration for SS7
Monitoring.
To configure SS7 monitoring using Excel API see SS7 Monitoring Using Excel API.
659
MSP
Licensing
SS7 monitoring links are licensed in increments of 16 links up to 64.This license is
available to enable the monitoring feature only if the MSP 1010 includes the base
SS7 protocol license.
Performance and Capacity
The MSP1010 may allocate up to five multi-host sockets to forward monitored traffic
to the monitor application (MA).
The MSP1010 may configure the Bearer spans assigned to the monitor links as either
high or low impedance facilities.
The MSP1010 may forward traffic up to 16 monitor applications.
The MSP 1010 supports passive monitoring of up to 64 bi-directional signaling links
or 128 Rx channels.
The MSP1010 may apply up to 16 filter rules.
Supportability
Next Generation API:
 SigView Signaling Notify (0x012B) indications used to present the monitored
traffic (LSSU, FISU, and/or MSU) to the monitoring application(s).
 Multi-Link State Notify (0x0163) indications used to report changes in an MA
socket accessibility or MA socket congestion.
 NGA Poll (0x0170) messages exchanged between the MSP and the MA(s)
You can query the following elements:
 Multi-Host Socket configuration (i.e. 0x3143, 0x3144, 0x3145, 0x3146, or
0x3147) and link state information.
 Facility configuration (whether it’s high or low impedance) and service state
information.
 Monitoring application configuration and service state information.
 SS7 monitoring link configuration and service state information.
 Filter configuration and service state information.
Applications
Various applications can make use of the MSP 1010 SS7 monitoring feature. Click on
the links below to see more details of these example applications:


660
Network Performance Monitoring This application gives continuous realtime measurements on SS7 traffic across the network, providing immediate
warning of abnormal activity that threatens network performance. This allows
immediate action to be taken to avoid catastrophic failure. An immediate alert
is produced when any of the operator-set thresholds are breached.
Welcome Message The welcome message feature allows service providers
to detect and hence provide functionality to roaming cell phones/ devices in
Developer Information





their network. It may be used by service providers to provision useful
information such as weather forecasts, currency exchange and local favorites,
to be sent periodically to the roaming device. The application helps service
providers enhance their services, by reaching inbound and outbound roamers,
providing them with customized information, which in turn increases the
mobile roamers' loyalty towards their service providers.
Missed call alert By monitoring the signaling links between Mobile Switching
Centers, an application is capable of detecting a missed call and alerting the
subscriber by sending an SMS. By offering this application, operators can
increase the minutes per subscriber and increase the revenue per subscriber.
Location Based Services With this service, mobile operators can offer
enterprises a chance to promote their company's presence to mobile
subscribers who are in the same area. Whenever a mobile subscriber moves
between two different areas of the mobile network, the Mobile Station (MS)
would send a Location Update to the network. When the application detects
this, it will search in the database for any advertisement to promote to this
customer.
Interconnections Arbitration This application provides a tool for
interconnection arbitration for telecommunication operators. This application
can be used for arbitration for Voice Traffic or SMS traffic. Some operators
use it as an "Auditing" tool of existing billing or call detail records generated
from a network's switches.
Fraud Detection and Control via Real-Time Call Detail Records This
application can substantially reduce telecommunication fraud losses by
detecting fraud as it takes place. After a call detail record is created, it is
analyzed and matches against a table of user configurable threshold and
scenarios. Fraud alerts are generated when matches are detected. These
trigger the fraud management system to take action in real-time and shut
down any fraudulent acts.
Optimal Routing This application is an innovative mobile service that
encourages roaming subscriber from any foreign country to stay in the
Roamed Mobile Operator's network. The application offers a more costeffective way to make calls to an Inbound Roamer by bypassing the
International Direct Dialing paths via the roamer's home network. It provides
extra incentives for inbound roamers to stay with an operator's mobile
network, increases revenue to operators arising from more calls to roamers,
reduces costs and higher margins for calls to roamers and better quality calls
for roamers. The Mobile Operator can then make the network their preferred
choice and generate more revenue from the inbound roamers with the
Optimal Routing Services.
SwitchKit Support
MSP SwitchKit supports the SS7 monitoring capability on the MSP 1010. If you do
not use SwitchKit as the OAM&P sub-system, you can deploy your own
implementation.
The MSP and SwitchKit communicate over TCP port 12610 (0x3142) using the
existing API methodology. Due to a restriction in SwitchKit, SS7 traffic cannot be
monitored over the same TCP socket as the control traffic (OAM&P). To
661
MSP
accommodate this restriction, up to four additional TCP sockets may be enabled for
routing SS7 traffic to the monitor applications (i.e. 0x3143, 0x3144, 0x3145, or
0x3146). Monitoring applications (MAs) will serve network sockets for receiving data
without utilizing LLC. In other words, the MSP forwards the SS7 traffic to the
application servers through a separate TCP socket without passing the LLC layer.
The MSP will initiate client connections to MAs as directed through OAM&P
instructions. You can co-locate or distribute MAs as their individual requirements
dictate. Some MAs will require precision time stamps of monitored events.
Connectivity to an NTP server would be necessary for those applications.
The SS7 monitoring feature can be configured and maintained using the SwitchKit
graphical user interface, ClientView. See Example Configuration for SS7 Monitoring.
The next diagram demonstrates the relationship of monitoring applications, SwitchKit
components, the MSP 1010 and the external SS7 signaling network elements.
Hardware Specifications
In order to monitor an SS7 link, two facilities (spans) must be configured; one for
the Tx-side and one for the Rx-side. The 21 E1/28 T1 bearer facilities on the MSP
may be configured for high or low impedance for monitoring SS7 traffic. This setting
is on a per-monitoring link basis — meaning high impedance facilities and low
impedance facilities may co-exist. The only requirement is, for a given SS7
monitoring link, the facilities associated with both the Tx and Rx sides of the link
share the same high or low impedance setting.
662
Developer Information
The four signaling/timing spans may not be configured for high impedance.
The clock module allows recovering the clock from high-impedance spans as well as
low-impedance spans.
The cable requirements for SS7 monitoring depend on the physical connection
properties of the MSP 1010. The MSP has RJ-48 connectors located on the rear of the
unit (See RJ 48 Connector Pinouts). To monitor an SS7 link, two monitoring spans
must be provisioned. Each of the monitoring spans only use the Receive signal from
the SS7 link:
 Pin 1 - Rx, Ring
 Pin 2 - Rx, Tip
Monitoring span 1 is connected to the receive side of the link while monitoring span 2
is connected to the transmit side of the ss7 link.
The Structure of SS7 Messages
The task of monitoring SS7 signaling is basically performed through detecting MTP2
messages and forwarding part of those messages to the host. Each forwarded
message is time-stamped in millisecond accuracy. Each message contains the
identity of the signaling channel being monitored. This ID is required for the
application in order to match messages with their replies.
There are three types of signal units in the SS7 MTP protocol, differentiated by
means of the length indicator contained in all signals:

Message Signal Unit (MSU)

Fill-in Signal Unit (FISU)

Link Status Signal Unit (LSSU)
Message Signal Unit (MSU)
The Message Signal Unit (MSU) is used to carry the signaling information between
user parts.
This signal unit is distinguished by the value of the length indicator (LI). All signal
units with LI > 2 are MSUs. The MSU is forwarded to the application without the
following fields:

Flag (F) marking the beginning and the end of the MSU
663
MSP

Check bits (CK)
The rest of the fields: BSN, BIB, FSN, FIB, LI (including the 2 empty bits), SIO and
SIF are passed to the application. The MSP software enables the user to apply
various filters. See SS7 Monitoring Entities.
Link Status Signal Unit (LSSU)
The LSSU is used for link alignment, and also carries link status information. The
presence of LSSUs at any time other than during the alignment procedures indicates
an outage at the MTP2 layer. The LI value in an LSSU is either 1 or 2. Users have
the option to forward LSSU information to the monitoring application. See SS7
Monitoring Entities.
Fill-in Signal Unit (FISU)
The FISU serves as the links heartbeat and is used when there are no LSSUs or
MSUs to be sent. The transmission of FISUs ensures 100 percent link occupancy by
signal units at all times. The LI value of a FISU signaling unit is zero. Users have the
option to forward FISU information to the monitoring application. See SS7 Monitoring
Entities.
SS7 Monitoring Entities
There are three entities directly associated with SS7 Monitoring on the MSP:
 Monitoring Application (MA)
MAs are the external applications receiving the SS7 traffic intercepted by the
MSP. In order to forward the traffic to the MA(s), the host must first configure
an MA and map it to a logical Socket ID representing the TCP port over which
the traffic will traverse. While a monitoring application cannot be associated to
more than one TCP socket, one TCP socket may serve multiple MA(s).
Click on either link for detailed information about MA configuration:
SwitchKit Users: Configuring Monitoring Applications using ClientView
Non-SwitchKit Users: Configuring Monitoring Applications using Excel API
 SS7 Monitoring Link
664
Developer Information
The configuration of monitoring links is the means in which the host
determines which SS7 links are being monitored. The host defines the timeslot
being monitored along with various MTP link characteristics associated with the
live SS7 link.
Click on either link for detailed information about monitoring link allocation:
SwitchKit Users: Configuring SS7 Monitoring Links using ClientView
Non-SwitchKit Users: Configuring SS7 Monitoring Links using Excel API
 Filter Rules
To prevent forwarding irrelevant MSUs to Monitoring Application(s), the MSP
1010 provides a filtering module enabling the host to restrict the flow of MTP3
traffic to the MAs. There are four types of filters comprising a rule that can be
applied to the MSP, in any combination:
Link ID:
Service
Indicator:
Network
Indicator:
Point Code:
MTP3 traffic filtering based on the SS7 Monitoring Link ID
intercepting the signal units
MTP3 traffic filtering based on User Part data
MTP3 traffic filtering based on Network Indicator type
MTP3 traffic filtering based on a specific point code, or a range of
point codes
Click on either link for detailed information about each filter:
SwitchKit Users: Configuring Rules using ClientView
Non-SwitchKit Users: configuring Rules using Cantata API
SS7 Monitoring Configuration Sequence
Use the links below to access the configuration sequences that should be followed
when configuring the SS7 Monitoring feature on the MSP 1010.
SwitchKit Users: Example Configuration for SS7 Monitoring
Non-SwitchKit Users: SS7 Monitoring Configuration Using Excel API
MSU Presentation
Once the MSP has been provisioned to send MTP traffic to the monitor applications,
and all monitor applications, SS7 monitoring links, and filter rules have been brought
in service, the MSP will begin to forward traffic to the monitoring applications in the
form of SigView MTP3 Signaling Notify and SigView Link Signaling Notify
notifications.
As with all NGAPI messaging on the MSP, the API encoding of the NGA Notify
messages (0x012B) take the following format:
Header:
length - 7
bytes
665
MSP
bytes
AIB:
length variable
Data
Type:
length - 1
byte
Number
of TLVs:
length - 1
byte
TLV
Data:
length variable
Two TLVs encapsulate MTP traffic:
 SigView Raw MSU TLV (0x900E)
 SigView MTP2 FISU-LSSU TLV (0x900F)
Click on the links below capturing the output from an MSP configured for SS7
Monitoring:
MTP3 output
MTP2 output
DS3
DS3 Overview
DS3 Technology
A DS3 has a bandwidth of 44.736 Mbps, which is the capacity of 28 T1 spans. Every
85th bit in a DS3 bit sequence is used for overhead functions such as frame
alignment, error detection, and terminal-to-terminal data communication. All other
bits are payload bits.
The DS3 signal format typically transports 672 channels at 64 Kbps per channel. The
DS3 signaling interface is bipolar with Bit 3 Zero Substitution (B3ZS).
DS3 in the MSP



666
The MSP supports loop timing for DS1's residing on the DS3.
The DS3 uses the M-Frame format and supports the following framing modes:


M13
C-bit (default)
The DS3 framer is automatically brought into service when the DS3 card is
brought into service. Once in service, DS3 status changes are reported to the
host in the Alarm messages (0x00B9). If the DS3 circuit is not ready for
operation, the host can disable DS3 alarms by placing the DS3 framer out of
service. To do this, have the host send a Service State Configure message
with the DS3 Offset AIB (0x32) and an action of 0x0F (Take Out of Service).
Developer Information



If the host does take the DS3 Framer Out of Service, it is the host’s
responsibility to bring it back in service. If the host does not bring the DS3
Framer back in service, the MSP will send a NACK 0x005A (DS3 Out of
Service) when it receives the Service State Configure message to Brings Span
In Service.
The MSP supports the following type of loopbacks diagnostics:


local loop back
request a remote loop back from the far-end switch
Far End Alarm Control (FEAC) responses
When enabled the MSP will automatically grant the requests of incoming FEAC
messages. When disabled the MSP will ignore all incoming FEAC messages.
Bit Error Rate Test (BERT)
You can query the MSP to determine if a local or remote loop back is
enabled/disabled. Refer to DS3 Loop Back Diagnostics.
Related Topics
Loop Back Diagnostics
BERT Test
Overview of Loopback Testing
With loopback testing, the host enables the DS3 inbound stream to loopback to the
outbound steam in order to test Layer 1 signal integrity. The host can enable local
loopback and issue remote loopback requests for the DS3, all DS1s or a single DS1.
ClientView users
To configure loopback on a DS3 or all DS1s see Configuring a DS3 Span (TDM DS3).
To configure loopback on a single DS1 see Configuring a DS1 Span (TDM DS1).
Non-ClientView users refer to Enabling Loopback Diagnostics using the EXS API.
Following the request to put a remote DS1 offset in loopback, you CANNOT
make another request for loopback on another remote span until the first
request is canceled.
Enabling Loopback Diagnostics using the EXS API
DS3 Configure/Query message (0x000F) loops the inbound DS3 stream back to the
outbound DS3 stream. This message can also request the far end to go into loopback
mode. This message can be used to enable/disable local or remote loopback mode
667
MSP
on the DS3, all DS1s or a single DS1. It can also be used to query the current
loopback state of the DS3, all DS1s or a single DS1.
There is a specific FEAC code to request ALL DS1's be put in loopback. There
are also specific FEAC codes for each span offset. Therefore, you can request
that the far end put all DS1's in loopback (you do not send 27 FEAC codes, just
one, the ALL DS1's code). If I want to request that just one DS1 offset (for
example offset 14) be put in loopback then you send the code value that
corresponds to offset 14.
Following the request to put DS1 offset 14 in loopback, you CANNOT make
another request for loopback on another span. You first must request span 14
be taken out of loopback and then request loopback on another span.
DS3 Local Loopback
Use the DS3 Configure/Query (0x000F) message as follows:

Entity 0x01 – loopback configure


Data 0x00 – Disable
Data 0x01 – Enable
DS3 Remote Loopback
Use the DS3 Configure/Query (0x000F) message as follows:

Entity 0x01 – loopback configure


Data 0x02 - Cancel Remote loopback
Data 0x03 - Request Remote loopback Request distant end to loopback
its received stream to the transmit stream
DS1 Local Loopback- All 28 DS1s on DS3
Use the DS3 Configure/Query (0x000F) message as follows:

Entity 0x03 – DS1 loopback configure – all spans


Data 0x00 – Disable
Data 0x01 – Enable
DS1 Remote Loopback– All 28 DS1s on DS3
Use the DS3 Configure/Query (0x000F) message as follows:

Entity 0x03 - DS1 loopback configure – all spans


Data 0x02 – Cancel Remote loopback
Data 0x03 - Request Remote loopback Request distant end to loopback
its received stream to the transmit stream
DS1 Local Loopback On Single DS1
668
Developer Information
Use the DS3 Configure/Query (0x000F) message as follows:

Entity 0x08 – DS1 loopback configure – all spans


Data 0x00 – Disable
Data 0x01 – Enable
DS1 Remote Loopback On Single DS1
Use the DS3 Configure/Query (0x000F) message as follows:

Entity 0x08 – DS1 loopback configure – all spans


Data 0x02 – Cancel Remote loopback
Data 0x03 – Enable
DS3/DS1 Loopback Based on Far End loopback Request
The MSP responds to three loopback requests, a DS3 loopback and a specific DS1
loopback. If FEAC is enabled, the MSP loops whatever the far end tell us to loop:
DS3, all 28 DS1’s, or a specific DS1.
Use the DS3 Configure/Query (0x000F) message as follows:

Entity 0x07 – DS3/DS1 FEAC Response Enable


Data 0x00 – Disable
Data 0x01 - Enable
DS1 Loopback Query - All 28 DS1s on DS3
Query the MSP for DS1 status (local loop, remote loop) on the whole group of DS1
spans.
Use the DS3 Configure/Query (0x000F) message as follows:
· Entity 0x09
DS3 Loopback Query
Query the loopback status of DS3 (local, remote or no loopback.)

Entity 0x02

Data [0]
0x00 – Local Loop Disabled
0x01 – Local Loop Enabled

Data [1]
0x00 – Cancelled
0x01 – Requested
DS1 Loopback Query on Single DS1
669
MSP
Query the loopback status of a single DS1 (local, remote or no loopback.)

Entity 0x0A
BERT Test
You can configure the MSP to run a Bit Error Rate Test (BERT). With this feature,
your MSP 1010 allows you to do the following:






Generate and monitor a test pattern depending on your hardware
configuration.
Generate a test pattern to be verified by a piece of external test equipment or
another MSP.
Monitor a test pattern when configuring both the transmit and receive.
Insert bit errors.
Select from multiple bit patterns
Framing for DS1 available in framed or unframed mode.
You can run BERT tests on a per DS1 basis or on the entire DS3. Only one test can
be performed at a time. That is, you cannot run a DS3 BERT test and a DS1 BERT
test simultaneously.
Either use ClientView or the NG API to configure the MSP to run the BERT tests.
Refer to the following:
Configuring BERT Test in the ClientView documentation.
Configuring BERT Test with the NG API
API Information
The following API are used for querying BERT:
NGA Info Query (0x0140)
The BERT-related TLVs in this message are:
0xE063 BERT Monitor Status
0xE064 BERT Monitor Bits Received
0xE065 BERT Error Bits Received
NGA Configuration Query (0x0140)
The BERT-related TLVs in this message are:
0xE05D BERT Direction
0xE05E BERT Pattern
0xE05F BERT Test Framing
670
Developer Information
0xE060 User-defined Test Pattern
0xE068 BERT Error Mode
Configuring BERT Test Using the NG API
The NG API is as follows:
NG API
Facility Interface Configure (0x0130)
TLVs
Facility BERT Configure
Facility BERT Query
VoIP
VoIP Overview
The VoIP module performs two-way conversion between circuit-switched data and
packet-switched data. This conversion is required by packetized voice applications,
such as the Voice over Internet Protocol (VoIP). The module also integrates media
resources over IP technology.
Circuit-switched voice is converted to IP packets, using compression algorithms that
can increase capacity toward the IP network side. You can have parameters modified
for an individual call, often while the call is active, changing the quality of service, as
needed.
Media Resources
Integrating media resources using IP technology provides many advantages.
Typically, media resources are connected by T1, E1, or J1 interfaces that consume
one 64 Kbps port per call, limiting the capacity of the system. The VoIP module
integrates media resources over IP using the standards-based Real-Time Protocol
(RTP).
Integrating media resources using standards-based technology also allows media
resources to be shared between the MSP and other network infrastructure. Packet
switching to media resources allows the application to benefit from voice
compression, increasing capacity on the application. This flexibility allows the MSP
and the applications to scale independently and incrementally, as needed,
eliminating excess hardware.
Related Topics
VoIP Module
VoIP Resource Profiles
Codec Overview
671
MSP
Codec Payload Sizes
Dynamic Payload Type
VoIP Configuration Options
Overview of VoIP Configuration
VoIP Resource & Wireless Profiles
VoIP resource and wireless profiles are available for the VoIP Module as follows. The
MSP supports two VoIP modules each with four DSP chips.
Profile
ID
4
5
Profile
Name
G.711
only -for
VoIP
LBR (Low
Bit Rate) for VoIP
CODEC
Supported
Channels/DSP
Channels/Module
G.711
168
672
G.711
128
512
84
336
No fax relay no T.38
G.723
G.726
(100 for T.38)
(400 for T.38)
G.729
7
Wireless
T.38
G.711
G.723
G.726
G.729
T.38
iLBC, GSMAMR
EVRC
Additional Notes


Resource profiles must be configured by the Host Flag attribute in the BOOTP
server. Refer to Downloading System Software to the MSP.
ARP services are not contained within the scope of the VoIP module - system
infastructure controls these services.
Related Topic
IP Bearer Profile (ClientView)
Codec Overview
672
Developer Information
This topic provides an overview of the additional codecs in the MSP. For more
information, refer to the corresponding RFCs.
Refer to VoIP Resources Profiles for a description of the profiles and the codecs they
include.
Refer to Downloading System Software to the MSP for the host flags tag value to set
for each codec.
See also Codec Payload Sizes.
G.711

International standard for encoding telephone audio on an 64 kbps channel.

Two different variants: A-law and mu-law. A-law is the standard for
international circuits.

It is a pulse code modulation (PCM) scheme.
G.723


Designed for video conferencing / telephony over standard phone lines, and is
optimized for realtime encode and decode.
Part of the H.323 standards for video conferencing.
G.726


Conforms to ITU-T G.726 recommendation that specifies speech compression
and decompression at rates of 16, 24, 32 and 40 Kbps based on Adaptive
Differential Pulse Code Modulation (ADPCM).
Both encoder and decoder components are available in two configurations mono (single) and stereo (two audio channels working in parallel).
G.729


8 Kbps encoded bit stream rate.
Discontinuous transmission support (DTX) using Voice Activity Detection
(VAD) and Comfort Noise Generation (CNG).
iLBC (internet Low Bitrate Codec)

Defined by RFC 3591 and RFC 3592.

Uses dynamic payload types (96-127 range), which must be agreed on by
both endpoints of a call.


Available in 13.3 kbps (30 ms encoding frame length) or 15.2 kbps (20 ms
encoding frame length) versions.
Designed for narrow band speech (64kbps).
673
MSP





Decoding algorithm does not depend on previous packets, therefore it is
excellent at handling packet loss.
Mandatory codec required for the released CableLabs PacketCableTM 1.1
audio/video codec specification for multimedia terminal adapters (MTAs) and
media gateways.
Fax/Modem switchover is supported.
Silence suppression is not supported.
RTP redundancy is not supported.
EVRC (Enhanced Variable Rate Codec)

Requires Excel licensing.

Used in millions of CDMA handsets.









A CDMA codec defined by RFC 3558. CDMA codec defined by 3GPP2.
Sent in 20 ms output frames of 3 different sizes: Rate 1, Rate ½ or Rate 1/8.
Output frame rate is chosen based on analysis of input frames (dynamically).
Two payload modes: header-free and interleaved (only header-free in this
release).
Fax/Modem switchovers are not supported.
Silence suppression is not supported.
RTP redundancy is not supported.
Uses dynamic payload types (96-127 range)
Digit Relay
GSM-AMR (Global System for Mobile - Adaptive Multi-Rate)

Requires Excel licensing.

AMR-NB in current MSP release.








674
AMR codecs (narrow and wide band) originally defined by ETSI for GSM.
Mandatory codec for 3G cellular systems.
Uses dynamic payload types (96-127 range)
Supports eight narrow-band speech encoding modes with bit rates between
4.75 and 12.2 kbps. These rates can be adjusted dynamically during a
session.
Speech encoding performed in 20 ms frames.
Multiple 20 ms frames can be encapsulated into a packet (maxptime in SDP
defines max frames per packet).
Mindspeed’s GSM-AMR solution allows reception of multiple frames in a
packet, but only one frame per packet will be transmitted.
12.2 kbps version of AMR-NB is defined by the GSM-EFR standard.
Developer Information

7.4 kbps version of AMR-NB is defined by the IS-641 codec in TDMA.

Fax/Modem switchover is not supported.



6.7 kbps version of AMR-NB is defined by the PDC-EFR standard.
Silence suppression is not supported.
RTP redundancy is not supported.
Codecs Controlled by Licensing
Codecs AMR and EVRC require a license. The MSP checks for the the licenses and if
they exist, MSP configures a module to the maximum number of licenses between
those two codecs.
Example:
Profile is set to wireless (7)
AMR Codecs: 96 Channels
EVRC Codecs: 128 Channels
VoIP Channels: 192 Channels
The module is configured with 128 Channels.
Host Flags
Use in the BOOTP Host Flags Parameters to select the profiles to load.
Once you load the profile, all codecs defined for that profile are available to use for
as many calls as are defined by the channel density for that profile.
See also Codec Payload Sizes.
Codec Payload Size
The following table includes the payload sizes of the codecs supported by the MSP.
All codec types and payload sizes can be sent in the NPDI TLV (0x2A08, 0x2A09 and
0x2A0A).
While they could be sent in NPDI format, for backward compatibility it is preferred
that codecs that do not require a dynamic payload type (G.711, G.729, G.723) be
sent in non-NPDI TLVs (0x0100 for codec type and 0x0101 for payload size).
The four versions of G.726 codec types are unique, in that they can use dynamic
payload types in the 96-127 range, but for backward compatibility they will default
to use static payload types if a dynamic payload type is not provided using NPDI
TLVs.
Please refer to the MSP API Reference documentation at
http://www.cantata.com/support, which defines the codec payload type values that
must be used in the NPDI (0x2A08/0x2A09) or non-NPDI (0x0100) TLVs.
675
MSP
Note: When you insert the value into the Payload Size TLV (0x0101) it must be
a multiplier of the base rate. That is, for 20 ms G.711, enter a value of 4.
Codec
G.711 uLaw
G.711 Alaw
G.723 53k
G.723 63k
G.729 A/B
G.726 - 16
Kbps
Payload
Sizes (ms)
Profile
Used
Payload
Type
Base Rate
(ms)
10, 20, 30,
40, 50, 60
4,5,7
0x00
5
10, 20, 30,
40, 50, 60
4,5,7
0x08
5
30, 60, 90
30, 60, 90
4,7
30
10, 20, 30,
40, 50, 60
5,7
0x04
5,7
0x12
10
default in bold
0x04
30
10, 20, 30,
40, 50, 60
5,7
0x60-0x7F
5
G.726 - 24
Kbps
10, 20, 30,
40, 50, 60
5,7
0x60-0x7F
5
G.726 - 32
Kbps
10, 20, 30,
40, 50, 60
5,7
0x02 or
5
G.726 - 40
Kbps
10, 20, 30,
40, 50, 60
5,7
0x60-0x7F
5
iLBC13kbps**
30
7
0x60-0x7F
20
iLBC15kbps
20
7
0x60-0x7F
20
GSM-AMR
**
20
7
0x60-0x7F
20
CDMA
EVRC **#
20
7
0x60-0x7F
20
0x23*
0x24*
0x60-0x7F
0x26*
* These static values are used to provide backward compatibility with CSP's VDACONE and IPN-2 cards. These values are not within the allowed payload type ranges
specified by RFC 3551, so they may not work with other vendor's versions of these
particular codecs. G.726-32kbps does have a well-defined static payload type (this
codec is the same as G.721). While these static payload types are available for
backward compatibility, use the dynamic range of 96-127.
** These codecs MUST use NPDI TLV format to associate a dynamic payload type
with them. Payload size NPDI TLV ()x2A0A) not required when using these codecs.
676
Developer Information
# “Header Free” mode of EVRC is supported, and is defined in SIP SDP using the
“EVRC0” string. “Packet Interleaved” mode of EVRC is not supported at this time
(SIP SDP defines this mode with the “EVRC” string).
Dynamic Payload Type
If a codec requires a dynamic payload type, you must use the NPDI TLVs in the
Route Control or Outseize Control messages as follows:
Each TLV is described below the diagram. Following that are byte-by-byte examples.
See also the MSP API Reference for specific API information.
TLV
Notes
Per Codec Info TLV
(0x2A02)
For call control messages for the host, this TLV
encapulates the TLVs below. The Universal NPDI TLV
is not required.
Universal NPDI TLV
Container for NPDI TLVs.
677
MSP
NPDI Media Payload Type
TLV (0x2A08)
Usually paired with the NPDI Media Payload
Description TLV (0x2A09).
How you use this TLV depends on if the codec has a
static or dynamic payload type. See below.
A static payload type is permatnently associated with
a codec. A dynamic payload type has a value of 96127 and is negotiated by the IP signaling layer the
bound to a codec for a single call.
Static: G.711, G.729, and G.723 codecs have static
payload types. When byte[0] of this TLV indicates a
static codec is used, then byte[1] will contain the
codec type, which must be G.711, G.729 or G.723.
It is invalid for byte[1] to contain a codec value for a
codec that requires a dynamic payload type.
NPDI Media Payload
Description (0x2A09)
Dynamic: When byte[0] is set to dynamic, byte[1]
will contain the dynamic payload type to be used for
the codec. In this case, the codec itself must be
defined in the NPDI Media Payload Description
0x2A09 TLV. The valid range of values for byte[1]
will be 0x60-0x7F.
Paired with the NPDI Media Payload Type TLV above.
When byte[0] of the NPDI Media Payload Type
(0x2A08)TLV is set to dynamic, the codec to use for
the call will be defined in this TLV. Codecs that
would be defined here are iLBC-13k, iLBC-15k, GSMAMR, EVRC, G.726-16kbps, G.726-24kbps and
G.726-32kbps.
Example - Static Payload Type
G.729 codec with static payload type, having 30 ms payload size (requires only
0x2A08 TLV to support static payload type)
00 33 00 10
2a 02 00 0c
2a 08 00 02 00 12
2a 0b 00 02 00 1e
Example - Dynamic Payload Type
EVRC codec with dynamic payload type of 97, having 20 millisecond payload size
(required 0x2A08 and 0x2A09 TLVs to support dynamic payload type.
02 2A 00 15
2a 02 00 11
2a 08 00 02 01 61
678
Developer Information
2a 09 00 01 2e
2a 0b 00 02 00 14
Priority
The following rules apply for the priority of NPDI to non-NPDI codec usage:
1. NPDI codec TLV has a higher priority over non-NPDI codec TLV (0x0100).
2. NPDI payload size TLV has a higher priority over non-NPDI payload size TLV
(0x0101).
3. NPDI codec TLV group is not required to have payload size TLV present.
Payload size can still be provided using the 0x0101 TLV, even if the codec is
defined using NPDI TLVs.
4. For a Resource Attribute Query message, if no TLVs are sent in the query
(meaning that all attributes must be returned), then both the NPDI and nonNPDI TLVs will be sent to show the codec and payload size information. In
the case of using the non-NPDI TLVs to show a codec in use that requires a
dynamic payload type, the codec will be defined in the 0x0100 Payload Type
TLV, but there is no way to see the dynamic payload type associated with it.
It is still useful to use this format though, for backward compatibility. The
NPDI TLVs will still be included and will show the group of codec, dynamic
payload type and payload size.
Host-Based SIP Overview
Host-Based Session-Initiation Protocol (SIP)
This feature provides a framework that will allow developers to integrate the
RADVISION SIP Toolkit with the Cantata CSP/MSP platforms and Switchkit API. See
Framework for Integration.
The SIP can be used for SK or non-SK users.
The RADVISION SIP Toolkit consists of the following for developers who wish to build
SIP applications:
• SIP, SDP and RTP/RTCP stacks
(RTP/RTCP libraries not packaged.)
• suite of APIs
• sample code
• test application
• user documentation
679
MSP
The following diagram shows the how the RADVISION stack is associated with the
MSP/CSP and the IP Network. Note that there is no direct interface between the
RADVISION stack and MSP/CSP.
Terminology
ACE – Adaptive Communication Environment
RV – RADVISION
TK – Toolkit
SK – Switchkit
ASP – Application Server Proxy
CFA – Call Flow Adapter
SIP – Session Initiated Protocol
RTP – Real-time Transport Protocol
API – Application Programming Interface
UAC – User Agent Client
UAS – User Agent Server
UI – User InterfaceType your drop-down text here.
Pertinent Specification
The current RADVISION Toolkit conforms to RFC 3261 and numerous SIP extensions.
Operating Systems
680
Developer Information
This toolkit release is available on the following operating systems:
o
o
o
Solaris
Windows
Linux
Packaging
Cantata packages the following with this RADVISION Sip Toolkit:
 RADVISION libraries for Windows, Solaris, and Linux. No source code is
delivered.
 The Projects, makefiles, and code required for integration of RADVISION with
the Cantata products. This framework is called the Application Server Proxy
(ASP). This is an unsupported sample application used solely for educational
purposes only.
 The projects, makefiles, and code required to build and test a sample
application that depicts the integration of RADVISION with the Cantata
products. This is an unsupported sample application to be used solely for
educational purposes only.
RADVISION SIP Licensing
To enable the licensing for the RADVISION SIP stack on an MSP, you must call the
RvSipStackEncodeKey() function to obtain an encrypted key from the RADVISION
stack. This key must then be decrypted by the MSP hardware by utilizing the
Encrypted Data TLV. See Example API. The response data from this query can then
be passed to the RvSipStackConstruct() function to initialize the RADVISION SIP
Stack.
RvSipStackEncodeKey()
RvSipStackConstruct() is documented in the RADVISION SIP TK Reference Guide. As
part of the licensing requirements for Cantata a new RADVISION function was added
called RvSipStackEncodeKey(). Developers are required to call this function before
utilizing the aforementioned RADVISION stack initialization function. If successful
validation of the key is not done with this function prior to stack initialization, the
RvSipStackConstruct() call will return error code (RV_ERROR_INVALID_LICENSE)
and the stack will not be initialized. Failure to validate the key renders the
RADVISION API useless.
An example of the usage of this function is outlined below. For additional details on
usage see the RVCallFlow files within the ApplicationServerProxy sample application
which is located in:
Linux and Solaris
$SK_LIB_DIR/CantataSIP/samples/ApplicationServerProxy/CFA
Wiindows
$SK_LIB_DIR\CantataSIP\samples\ApplicationServerProxy\CFA
Call Flow
681
MSP
An example of the message call flow is outlined below. For additional details on
usage see the RVCallFlow files within the ApplicationServerProxy sample application.
SYNTAX
RVAPI RvStatus RVCALLCONV RvSipStackEncodeKey( INOUT RvSipStackCfg *pStackCfg
);
PARAMETERS
pStackCfg
The configuration structure contains the following SIP Stack variables:
Variables
cantataKeyType
Values
RvSipLicenseKeyType:
 RVSIP_CANTATA_MSP
 RVSIP_CANTATA_CSP
cantataSerialNumber
Chassis Serial Number
cantataDecryptSize
Number of TLVs in the Data returned in
the Product License Query.
cantataDecryptData
RETURN VALUES
Returns RvStatus.
682
Data returned from the Product License
Query.
Developer Information
RvSTATUS Status Code
Value
RV_ERROR_INVALID_LICENSE
Description
Cantata License
Key was not
validated.
Framework for SIP Integration
A framework is required to enable communication between the RADVISION SIP API,
the Switchkit API, and EXS API. See Components of the ASP Framework. Enabling
this communication in a straightforward manner that does not alter the behavior of
each of the APIs comprises the bulk of the work required for integration. To minimize
this effort a sample application was created that can be used directly or used to
model a possible integration method. This sample application is called the Application
Server Proxy and can be located in the Sample directory of the installation CD.
The multi-threading and messaging capabilities of this software can leveraged to
allow each of the aforementioned libraries to run in its own thread and communicate
via thread safe buffers thereby decoupling each behavior and each messaging
scheme. Each of the API libraries is a separate task, or endpoint, and is connected by
a proxy that will facilitate message passing.
Each Application Server task is capable of sending directly to a particular endpoint or
to the Application Server Proxy connecting them. The messages can then be parsed
either from the user interface from a registered callback function or from the
endpoint itself.
The object oriented model used for thread safe messaging is the producer consumer
model. Each application server task is a producer thread. The Application Server
Proxy task is a single thread encapsulated within a singleton object. This singleton
object then becomes the consumer portion of the model. The architecture is
represented in the next diagram.
683
MSP
Components of the ASP Framework
The following components make up the ASP Framework. See also Call Flow.
User Interface
The User Interface (UI) is the main run loop. This is where the developer spawn and
start each of the tasks and its respective thread(s). This code is written by the
developer and determines which, when, and the type of application server tasks to
create.This is the only module that allows the developer direct access to the ASP
task. All other modules must communicate via the respective task’s threadsafe
buffer.
EXS Task
684
Developer Information
The EXS task is used to communicate directly with Cantata hardware by utilizing the
EXS API. This task will contain an option such that it may be run with or without
socket support. When enabled the developer need only to specify an IP and port and
the task automatically maintains a TCP connection to the EXS hardware. The option
also does the required framing and checksum verification. By utilizing this code, the
developer can send and receive messages via the respective send and receive
methods encapsulated in this task. Since some EXS developers will want to use their
own code to handle the sockets this task can be disabled.
SK_Task
The Switchkit (SK) task is used to communicate indirectly with Cantata hardware by
utilizing the Switchkit API in conjunction with the LLC.
RVSIP_Task
The RADVISION SIP (RVSIP) task is used to communicate indirectly with Cantata
hardware by utilizing the SK_Task or EXS_Task via the Application Server Proxy. It
can also be used to communicate directly with a SIP UAC or SIP UAS by utilizing the
RADVISION API and its underlying SIP protocol stack.
CFA
The Call Flow Adapter (CFA) is a dynamically linked library that allows the customer
to define and plug-in their own call flows for each of the Application Server tasks. By
using dynamic linking the customer can simply swap out the CFA library file and the
application will re-link at runtime. Thereby avoiding the need for an entire compile
and re-link and the need to shutdown the entire system.
ASP
The Applications Server Proxy (ASP) is a task that is responsible for routing user
defined messages to a specified endpoint. For example a customer may want to
receive an INVITE from a SIP UAC that triggers an OutsiezeControl being sent to an
MSP or Converged Services Platform (CSP). To do this a CFA would be developed for
an RV_Task. This INVITE could then be received by an RV_Task that would then send
a pre-defined message to a SK_Task or EXS_Task that caused an OutsiezeControl to
be sent to the hardware. The ASP is responsible for routing this message from the
RV_Task to the SK_ or EXS_ tasks..
SCCP TCAP
Introduction to SCCP/TCAP
Overview
SCCP and TCAP support offers advanced routing, data transfer, and management
control features. Signaling Connection Control Part (SCCP) provides both
connectionless and connection-oriented network services above MTP Level 3.
Transaction Capabilities Application Part (TCAP) provides transaction and remote
685
MSP
operation capabilities to a large variety of applications distributed over the MSP 1010
and service centers in the network. The Excel SCCP/TCAP implementation supports
the following connectionless services:

Specialized Routing

Management Control

Data Transfer
The SCCP layer and TCAP layer services are directly accessible through the SCCP and
TCAP primitives. The option of using SCCP services only or using both SCCP and
TCAP services is configurable for each subsystem. This allows users to choose the
appropriate protocol interface for customized applications.
SCCP
Together SCCP and MTP are used as the network layer for TCAP-based services. For
each component of an SS7 network, SCCP provides a different service to its user
which is referred to as the subsystem.
In a Service Control Point (SCP), the sub-system of the SCCP is a database.
For an SSP, the sub-system of the SCCP is an application software package.
For a Signal Transfer Point (STP), the SCCP also provides Global Title Translation.
TCAP
TCAP enables the deployment of advanced intelligent network services by supporting
non-circuit related information exchange between signaling points using the SCCP
connectionless service. TCAP provides the framework to retrieve information or
invoke remote operations.
TCAP offers the means for end users in the SS7 network to query another end office
and acts as the software interface between an SS7 office and database services in
order to obtain data from the SS7 network.
Mapping SS7 stack to OSI layers
686
Developer Information
SCCP/TCAP in the Excel Architecture
SCCP and TCAP provide the services to the host by a set of SCCP primitives and a set
of TCAP primitives which are carried in the PPL Event Request and PPL Event
Indication API messages.
Host Connection - MSP
ITU and ASNI/Telecordia Standards - Versions Supported
The following are the standards versions that the SCCP/TCAP implementation
supports:

ITU Q.771-Q.774 TCAP 1997

ANSI T1.112 SCCP 2000 and Telecordia GR-246 issue 7

ANSI T1.114 TCAP 2000 and Telecordia GR-246 issue 7
SCCP/TCAP in the Excel Architecture
Primitives
SCCP and TCAP provide the services to the host by a set of SCCP primitives and a set
of TCAP primitives which are carried in the PPL Event Request and PPL Event
Indication API messages.
687
MSP
See SCCP TCAP Primitives.
Capability
The MSP supports the following per stack:


32,000 simultaneous TCAP transactions
96,000 simulataneous TCAP invocations
Host Connection - MSP
ITU and ASNI/Telecordia Standards - Versions Supported
The following are the standards versions that the SCCP/TCAP implementation
supports:

ITU Q.771-Q.774 TCAP 1997

ANSI T1.112 SCCP 2000 and Telecordia GR-246 issue 7

ANSI T1.114 TCAP 2000 and Telecordia GR-246 issue 7
SCCP/TCAP Supports Many Services and Applications
Overview
This section provides examples of the kinds of services and applications that the
SCCP/TCAP feature supports.
Assumptions and Dependencies
SCCP software assumes services from SS7 Message Transfer Part (MTP). TCAP
software assumes connectionless services from SCCP and services from MTP.
Services enabled by TCAP
The following are some examples of the services enabled by TCAP:
Special Service Number Translation
An SSP uses TCAP to query an SCP to determine the routing number(s) associated
with a dialed 800, 888, or 900 number. The SCP uses TCAP to return a response
containing the routing number(s) back to the SSP.
Line Interface Database (LIDB) application
Calling card calls are validated and billed using TCAP query and response messages.
Wireless Application
TCAP provides the ability for automatic roaming service by transferring signaling
information to remote nodes. When a mobile subscriber roams into a new mobile
switching center (MSC) area, the integrated visitor location register (VLR) requests
688
Developer Information
information such as the service profile from the subscribers home location register
(HLR). In this case, mobile application part (MAP) information is carried within TCAP
messages.
TCAP messages are contained within the SCCP portion of a mobile subscriber unit
(MSU). An ANSI TCAP message is comprised of a transaction portion and a
component portion. In addition, an ITU TCAP (White Book) message contains a
dialog portion.
Supported Applications
The addition of the SCCP and TCAP layers being integrated into the SS7 solution
allows users to provide enhanced calling features, AIN, and wireless applications. The
MSP 1010 supports ANSI-41 (formerly IS-41) the mobile phone protocol in U.S.
networks, which allows wireless roaming. In international networks, the MSP 1010
supports the SS7 mobile application part of the Global System for Mobile
Communications standard (GSM MAP). GSM MAP supports wireless applications such
as Short Message Services (SMS).
The Personal Communications Service (PCS) market specifies the need for the
capability to map a hybrid of variants in one stack. The architecture is designed to
support this type of hybrid configuration of variants. For example, the ITU TCAP over
ANSI SCCP is used for database management in the reallocation of calling traffic.
The MSP 1010 can be an integral part of an MSC in a PCS Network Architecture,
supplying MTP, SCCP and TCAP in order to support an ANSI-41 (formerly IS-41)
application. There can be other applications. The MSC, in a mobile switching center,
provides services to the mobile subscriber based on information, such as profile
information requested by the integrated VLR from the subscribers HLR.
Two examples of applications for SCCP/TCAP are shown next.
SCCP/TCAP Application Scenarios:
Intelligent Network Architecture with SCCP/TCAP
689
MSP
Personal Communication Service (PCS) Network
User Interface Requirements
The host has access to the TCAP and SCCP layers through the use of the PPL Event
Request and PPL Event Indication API messages. Both ITU and ANSI variants of
SCCP and TCAP primitives are provided.
The ITU primitives are consistent with the ITU White Book Q.771 SCCP and TCAP
specifications.
690
Developer Information
The ANSI primitives are consistent with ANSI T1.1.114-1992 (TCAP) and ANSI
T1.112-1996 (SCCP).
Global Title Translation
Overview
As networks grow and become more complex and cross international boundaries,
routing between different nodes becomes more complex. One way to simplify this
routing requirement is to implement Global Title Translation (GTT), which routes
according to a digit analysis rather than Point Code (PC) and Subsystem Number
(SSN).
Supports Advanced Features
Excel's Global Title Translation (GTT) feature integrated on the MSP provides the
routing functionality required to offer services with advanced features such as local
number portability (LNP), toll-free, calling card, calling name delivery, and roaming
support, as well as other advanced network services.
Capacity Information
The GTT feature supports the following:

128 GT groups

maximum of 24 digits

100,000 entries
How Invoked
The GTT functionality enables the Signaling Connection Control Part (SCCP) to
translate and route the SCCP message in cases where the Called Party Address
contains a Global Title and the routing indicator is set to Route on GT. GTT
functionality also enables the SCCP to have relay functionality. The GTT function is
invoked within the SCCP Routing Control (SCRC) under the routing procedures. The
Global Title Addressing and GTT feature will allow diverse groups of SCCP
addressable entities associated with different applications to establish their own
addressing schemes.
Redundancy
The GTT feature supports the same level of redundancy as all other levels of SS7
functionality implemented on the MSP 1010.
Requirements
This GTT implementation on the MSP 1010 requires the SS7 functionality.
Configuring Global Title Translation
691
MSP
Refer to the following sections for information to configure Global Title Translation.


Procedures for configuring options in Configuring SCCP/TCAP.
Global Title Translation (GTT) Configuration Samples
API Messages
The following API messages support Global Title Translation. They are documented in
the API Reference.


SS7 SCCP/TCAP Configure (0x0077)
SS7 SCCP/TCAP Query (0x0078)
TLVs
The following Tag Length Values (TLVs) support Global Title Translation. They are
documented in the API Reference.

0x09CA Add Global Title Group

0x09CC Add Global Title Entry







0x09CB Delete Global Title Group
0x09CD Delete Global Title Entry
0x09CE Build Index Table
0x09CF Global Title Group Query
0x09D0 Global Title Entry Query
0x09D1 Global Title Group Query Response
0x09D2 Global Title Entry Query Response
Global Title Translation (GTT) Configuration Samples
Purpose
This section contains sample messages for configuring Global Title Translation (GTT).
Using these sample messages
The description for the TLVs precede each group of samples. The different options
that you can select with each Tag Length Value (TLV) are included in the sample
messages.
API Messages
Refer to the following two EXS API messages in the API Reference for for details on
configuring GTT.


SS7 SCCP/TCAP Configure (0x0077)
SS7 SCCP/TCAP Query (0x0078)
Adding Groups
692
Developer Information
Use the following TLV to add Global Title Groups.
Add Global Title Group TLV 0x09CA
Byte
Description
2
Length 0x0009
0, 1
3
4
5
6
7
8
9
10
Tag 0x09CA Add Global Title Group
Value[0] 0-127 Group ID (GID)
Value[1] Global Title Indicator (GTI)
1-4 for ITU
1-2 for ANSI
Value [2] Translation Type (TT)
0-255 ( 0 = Default)
Value [3] Numbering Plan (NP)
0-15 ( 0 = Default)
Value [4] Nature of Address Indicator (NAI)
1-127 ( 0 = Default)
Value [5] Minimum Digits ( 1-24) (MIN)
The minimum number of digits that the GT entry of this group will
contain. Must be greater than 0 and less than or equal to the Maximum
Digits field.
Value [6] Maximum Digits ( 1-24) (MAX)
The maximum number of digits that the GT entry of this group will
contain. Must be less than 24 and greater than or equal to the Minimum
Digits field.
Value [7] Group Attribute (ATT)
Bit 0 Maximum match
0 = Use minimum match rule for this group
1 = Use maximum match rule (also known as best match rule) for
this group.
Bit 1 Calling Party Address (CGPA) treatment
0 = Calling Party address will not be changed when the Global
Title Global Title translation results in Route on GT.
1 = Calling Party address is changed when GT translation results in
Route on GT. The new calling party address is stored in SSN default
parameter table.
The CGPA bit will not take effect for connection oriented messages.
Bit 2 ANSI TT4 (Translation Type 4)
0 = Not TT4 type
693
MSP
1 = TT4 type
If this bit is set, no GT entry can be added into this group.
Bit 3 Remove GT
0 = Do not remove GT after a successful translation.
11
1 = Remove GT after a successful translation.
Reserved for future use. (REV)
Sample 1
The Group Attribute 08 indicates use the Minimum Match Rule and Remove the GT
after Translation.
Sample 2
The Group Attribute 00 indicates use the Minimum Match Rule and Do Not Remove
GT after Translation.
Sample 3
The Group Attribute 09 indicates use the Maximum Match rule and Remove GT after
Translation.
Sample 4
The Group Attribute 01 indicates use the Maximum Match Rule and Do Not Remove
GT after Translation.
The index table is rebuilt automatically for the GT Group operation (Add/Delete).
Deleting Groups
Use the following TLV to delete groups identified by the Global Title Indicator,
Translation Tile, Numbering Plan, and Nature of Address Indicator.
Delete Global Title Group TLV 0x09CB
Byte
0, 1
694
Description
Tag 0x09CB Delete Global Title Group
Developer Information
2
3
4
5
6
7
8
Length 0x0006
Value[0] Group ID (GID)
1-127
Value [1] Global Title Indicator (GTI)
1-15
Value [2]
Translation Type (TT)
0-255 ( 0- Default)
Value [3] Numbering Plan (NP)
0-15 ( 0 - Default)
Value [4] Nature of Address Indicator (NAI)
1-127 ( 0 - Default)
Reserved for future use. (REV)
The sample below deletes four groups: 00 to 03.
Important! The index table is rebuilt automatically.
Adding GT Entries
Use the following TLV to add Global Title Entries.
Add Global Title Entry TLV 0x09CC
Byte
Description
2, 3
Length Variable
0, 1
4
5
Tag 0x09CC Add Global Title Entry
Value[0] Group ID (GID)
1-127
Value [1] Entry Attribute
Bit 0 - Wild Card bit
0 - Non Wild Card GT
695
MSP
1 - Wild Card GT
Bits 1-7 Not Used.
6
Reserved for future use.
7
Value [2] Global Title Address Information
Length (LEN)
1-24 digits
:
Value [3-n] Global Title Address Information
(GTAI)
See API Reference for format.
:
Value [n] Translation Result Option
00 - Single translation result
01 - Double translation results, working in
Active
Standby Mode
02 - Double translation results, working in
Load
Sharing Mode
:
Value [n] Translation Result 1
See in the API Reference for format.
Sample 1
The following values apply to the sample below:

Entry Attribute: Non wild card entry

RI= Route on DPC/SSN

Translation result format: RI+PC+SSN (RI=Routing Indicator, PC=Point Code,
SSN=Subsystem Number)
Sample 2
The following values apply to the sample below:

Entry Attribute: Wild card entry

RI= Route on DPC/SSN

696
Translation result format: RI+PC+SSN
Developer Information
Sample 3
The following values apply to the sample below:



Entry Attribute: Non wild card entry
Translation result format: RI+PC+GT
RI= Route on GT
Sample 4
The following values apply to the sample below:

Entry Attribute: Non wild card entry

RI= Route on GT

Translation result format: RI+PC
Sample 5
The following values apply to the sample below:

Entry Attribute: Non wild card entry

RI= Route on DPC/SSN

Translation result format: RI+PC+SSN+GT
Deleting GT Entries
Use the following TLV to delete the GT entries indicated by the Group ID, GT
Attribute, Global Title Address Information (GTAI) Length, and GTAI.
Delete Global Title Entry TLV 0x09CD
Byte
Description
2, 3
Length Variable
0, 1
4
Tag 0x09CD Delete Global Title Entry
Value[0] Group ID
1-127
697
MSP
5
Already configured.
Value [1] Entry Attribute
Bit 0 - Wild Card bit
0 = Non Wild Card GT
1 = Wild Card GT
6
7
:
Bits 1-7 Not Used.
Reserved for future use.
Value [2] Global Title Address
Information Length (LEN)
1-16 digits
Value [n] Global Title Address
Information (GTAI)
The sample below deletes five GT entries in GT Group 2.
Building the Index Table
Use this TLV to build the index table which brings the new GT entries into service and
takes the deleted GT entries out of service.
Build Index Table TLV 0x09CE
Byte
Description
2, 3
Length 0x0001
0, 1
4
Tag 0x09CE Build Index Table
Value[0] Bit 1 - 1=Build Index
Message Flow of TCAP Components
Overview
This section contains the SS7 SCCP and TCAP PPL components and their IDs. Also,
you will find diagrams showing the message flow for SCCP and TCAP components.
698
Developer Information
SCCP PPL Components
The following list contains the SS7 SCCP PPL Components and their IDs:
Component
ID
Component Name
0x66
SCRC - SCCP Routing Control
0x65
0x67
0x68
0x69
0x6A
0x6B
0x6C
0x6D
0x6E
0x6F
SCLC - SCCP Connectionless
Control
SUSI - SCCP User Interface
SPPC - Signaling Point Prohibited
Control
SPAC - Signaling Point Allowed
Control
SPCC - Signaling Point
Congestion Control
SSPC - Subsystem Prohibited
Control
SSAC - Subsystem Allowed
Control
SSTC - Subsystem Status Test
Control
BCST - Broadcast
LBCS - Local Broadcast
TCAP PPL Components
Component ID
Component Name
0x71
CCO - Component Portion Control
0x70
0x72
0x73
0x74
0x75
TUSI - TCAP User Interface
ISM - Component Portion
TCO - Transaction Coordinator
TSM - Transaction State Machine
DHA - dialog Handling
Message flow for SCCP and TCAP components
SCCP Components and Message Flow
699
MSP
Note: SCMG = SCCP Management
TCAP Components and Message Flow
SCCP/TCAP Call Flows
Overview
This section shows examples of normal and abnormal SCCP/TCAP message flows.
These diagrams are intended to show the protocol aspect of the flow correlating with
the host messages. It is not a complete list to cover all the cases. More complete
SCCP and TCAP call flows can be found in ITU SCCP and TCAP test specifications.
Host Using SCCP Connectionless Service Directly
700
Developer Information
These call flows show the normal and abnormal cases when the host uses the SCCP
service directly (TCAP service is not used). Only the SCCP peer level service is shown
here.
Success
SCCP successfully sends the UNIT-DATA message to the network and informs the
host about SCCP receiving the Unitdata message from the network.
SCCP Connectionless Service Direct - Success
Message Returned
SCCP sends the UNIT-DATA message to the network and sets the return option in
the Quality of Service parameter. In this case, the message cannot be delivered to
the destination due to failures on the network (such as, a Global Title is translated to
an unavailable DPC). The message is returned and the host is informed by an
N_NOTICE Indication primitive in a PPL Event Indication message.
SCCP Connectionless Service Direct - Message Returned
701
MSP
Host Using ITU TCAP Service
The following diagrams show examples of the host using TCAP services. Note that
using TCAP service implies the use of SCCP service in the current implementation.
One Transaction/ One Invocation
The services of each SS7 protocol level is used when the host initiates a single
transaction with a single remote invocation. In this case, the transaction is
successfully completed and the remote operation is successfully invoked.
Host Using TCAP Service - 1 Transaction, 1 Invocation (ITU)
702
Developer Information
One Transaction, Two Invocations
The host uses ANSI SCCP/ TCAP services, while one transaction is created and
completed successfully, two remote operations are successfully invoked. Only TCAP
peer-level services are shown. The SCCP and MTP services are similar to the
previous example.
Host Using TCAP Service - 1 Transaction, 2 Invocations (ANSI)
703
MSP
Configuring SCCP TCAP
This section describes the SCCP TCAP options that can be configured for a variant of
an ANSI or ITU protocol.
Use the SS7 SCCP/TCAP Configure (0x0077) message to configure up to ten different
attributes for each local subsystem. Send a separate message to configure the
attributes for each local subsystem.
Before you begin
Before you can configure other options, you must add a local subsystem and
configure how it routes network messages (either to TCAP or to the host). You must
use the SS7 SCCP/TCAP Configure message to set the byte for Config Type to 0x01
Local SSN.
Configuring SCCP/TCAP
1. Configure the local subsystem number using the SS7 SCCP/TCAP Configure
message.
2. Next you can configure SCCP/TCAP options described in the next section.
Procedures for configuring options
You can configure the following SCCP/TCAP options.
Option
704
Use the SS7 SCCP/TCAP Configure message to...
Developer Information
Adjacent
Translator
Other
Concerned
Point Code
SCCP/TCAP
Default
Parameter
Table
Set the Config Type byte to 0x02 and configure all Adjacent
Translators for a given subsystem. By default, all Adjacent
Translators are Concerned Point Codes.
See Adjacent Translators Configuration .
Set the Config Type byte to 0x03. For an SSP or SCP, Point
Codes which must be informed about local (MSP 1010)
subsystem status changes are referred to as Concerned Point
Codes.
Set the Config Type byte to 0x04. This table contains the
default parameters used by SCCP and TCAP for all subsystems
associated with a stack. These values are used for Mandatory
parameters if not included in a primitive.
The following parameters are stored by default, according to the
ITU white book.

TCAP Dialog_As_ID

TCAP Protocol Version

Subsystem
(Based on
default
parameter
table)
TCAP Unidialog_As_ID
You do not need to configure this table unless you require
modifications.
Configure the default parameter table for a particular subsystem. Set the Config Type byte to 0x05.
Configure
Local SSN
Set the Config Type byte to 0x01. You may route messages to
TCAP or the host by configuring the SSN Routing Flag.
SCCP/TCAP
host
configuration
Set the Config Type byte to 0x08 to configure the SCCP/TCAP
host that is used to receive messages from the SCCP/TCAP
layer.
Network
DPC/SSN
Replicated
SSN
Global Title
Translation
Set the Config Type byte to 0x07 to configure the Destination
Point Code (DPC) and remote subsystem number.
Set the Config Type byte to 0x09 to configure the replicated
SSN.
Set the Config Type byte to 0x0C to configure Global Title
Translation using the TLV Format Configuration Contents. See
Global Title Translation (GTT) Configuration Samples.
Querying
Use the SS7 SCCP/TCAP Query message to query the following:


Local Subsystem Table
SCCP Default Parameter Table
705
MSP

Subsystem Default Parameter Table

TCAP Active Operations

TCAP Active Transactions
Related Topics
Deconfiguring SCCP/TCAP
GTT Configuration Samples
Deconfiguring SCCP/TCAP
To deconfigure an SS7 stack with SCCP/TCAP, do the following:
1. Put all SSNs out of service using the N-STATE request. This will abort any active
TCAP transactions for the SSN if TCAP TUSI Config Byte 3 is set to Yes (default
value).
The host MUST take the SSN out of service. If not, any attempt to delete the
SSN will fail. This differs from normal deconfiguration where the link does not
have to be marked OSS before it can be deconfigured.
2. Delete the SSN using the SS7 SCCP/TCAP Configure message.
3. Deconfigure MTP for the stack (links, link sets, route) using the following
messages:

SS7 Signaling Link Configure

SS7 Signaling Route Configure

SS7 Signaling Link Set Configure
4. Deconfigure the stack using the SS7 Stack Configure message.
China National Variant Configuration
Overview
This section describes a configuration sequence to enable MTP/ SCCP/TCAP support
for the China variant. Note that the MTP PPL Config Byte values are listed in the SS7
PPL Information, Chapter 6.
Important! National variants may require additional User Part and protocol
modifications.
Configuration sequence
The following software configuration sequence (which does not have to be followed in
the order presented) should be used to support the SS7 stack for SCCP/TCAP:
 Modify PPL Config Bytes with the PPL Configure message:
MTP3 HMDT component (0x002B)
 Set Config Byte 1 (Variant) to 0x03 (China)
706
Developer Information
MTP3 HMRT component (0x002C)
 Set Config Byte 1 (Variant) to 0x03 (China)
SCCP SCLC component (0x0065)
 Set Config Byte 1 (Variant) to 0x02 (China)
Example
In a configuration with two SS7 stacks (Stack 00 and Stack 01), the following PPL
Configure messages would be sent to the MSP 1010. The shaded columns (asterisk*
for html documents) indicate modifications. Abbreviations used in the table are:

Seq. No. - Sequence Number

PPL Comp. ID - PPL Component ID

Length
(MSB,
LSB)
00 10
00 10
00 10
00 10
00 10
00 10
LNI - Logical Node ID
Message
Type
(MSB,
LSB)
00 D7
00 D7
00 D7
00 D7
00 D7
00 D7
Reserve
Byte
00
00
00
00
00
00
Seq.
No.
00
00
00
00
00
00
LNI
AIB
Stack*
PPL
Comp.
ID*
FF
FF
FF
FF
FF
FF
PPL
#Data
Byte
Data
01
01
Entity
Location
00
01
00
00 2B
00
01
00
00 2C
01
00
01
00
00 65
01
00
01
01
00 2B
01
00
01
01
00 2C
01
00
01
01
00 65
01
18
01
18
01
18
01
18
01
18
01
18
01
01
01
01
01
01
01
01
01
01
01
01
707
03
03
02
03
03
02
MSP
Adjacent Translators Configuration
Overview
In SCCP, a Global Title Translator is the node that performs the global title
translation (GTT). The result of the GTT could be the DPC/SSN or another global
title, in which case another node is used to perform further GTT. Therefore, there
may be more than a translator involved before an SCCP message reaches its
destination.
Adjacent Translator
The Adjacent Translator is the first node that performs the GTT from the point of
view of the SSP (adjacent is a logical term). For example, Node A is adjacent to Node
B if any SS7 path exists between them without a GTT in the path.
Alternatively, the physically adjacent STP could be the Adjacent Translator and be
responsible for routing to the next GTT. Excels SCCP implementation places no
limitation on the network configuration.
If an Adjacent Translator needs to be defined for a subsystem, the route to the Point
Code must be defined first. If it is not, a NACK of DPC Not Configured (0x550E) is
returned. To delete a route, you must first delete the Adjacent Translator, otherwise,
a NACK of SCCP/TCAP Related Configuration Parameter Error (0x55).
If you delete an SSN, all of its associated configuration, including Adjacent
Translators, is automatically deleted.
Routing with a Global Title
For any local SSN, you can define Adjacent Translators and Network destination
point codes and subsystem numbers. If the adjacent translator is defined, you may
route the message to the translator node for global title translation
Example Configurations and TCAP API Messaging
Overview
Four sample configuration files are included with the release software showing the
steps required for basic and SCCP/TCAP-specific configuration. These files are shown
further on in this section.
Descriptions of Sample *.cfg Files
The sample configuration is for one node with two SS7 stacks in loop-back mode.
Each stack simulates an SS7 node. The sample configuration files are summarized
below:

itumtp.cfg includes the configuration for the two SS7 stacks (including the
SCCP/TCAP module) and MTP configuration. The following configuration is
performed:


708
SS7 spans
signaling stacks, link sets, links, and routes
Developer Information


bring spans, channels, and links in service

SCCP local SSN

Other Concerned Point Codes (optional)
sccp.cfg includes SCCP-related configuration information. There are two
subsystems configured for each stack. The following configuration is
performed:





Adjacent translators
Bring SSNs in service with N_STATE Request in PPL Event Request
message.
Network DPC/SSN (for direct routing to a network SSN)
unitdata.cfg is an example of using SCCP N-UNITDATA service.
begin.cfg is an example of using TCAP service by invoking the ITU
TC_INVOKE and TC_BEGIN primitives. ITUMTP.CFG -- Sample Configuration
File
itumtp.cfg
' de-assign all spans and assign logical spans
00 0d 00 a8 00 00 ff 00 01 11 04 ff ff ff ff
00 0d 00 a8 00 00 ff 00 01 11 04 00 00 04 00
00 0d 00 a8 00 00 ff 00 01 11 04 00 01 04 01
00 0d 00 a8 00 00 ff 00 01 11 04 00 02 04 02
00 0d 00 a8 00 00 ff 00 01 11 04 00 03 04 03
00 0d 00 a8 00 00 ff 00 01 11 04 00 04 04 04
00 0d 00 a8 00 00 ff 00 01 11 04 00 05 04 05
00 0d 00 a8 00 00 ff 00 01 11 04 00 06 04 06
00 0d 00 a8 00 00 ff 00 01 11 04 00 07 04 07
' Configure SS7 Spans (T1)
00 0d 00 a9 00 00 01 00 01 0c 02 00 00 52 06
00 0d 00 a9 00 00 01 00 01 0c 02 00 01 52 06
00 0d 00 a9 00 00 01 00 01 0c 02 00 02 52 06
00 0d 00 a9 00 00 01 00 01 0c 02 00 03 52 06
00 0d 00 a9 00 00 01 00 01 0c 02 00 04 52 06
00 0d 00 a9 00 00 01 00 01 0c 02 00 05 52 06
00 0d 00 a9 00 00 01 00 01 0c 02 00 06 52 06
00 0d 00 a9 00 00 01 00 01 0c 02 00 07 52 06
' Configure First SS7 Stack (A)
' Set Single Redundancy on Board 2
00 0d 00 5b 00 00 ff 00 02 01 01 02 01 01 ff
'Set Signaling Stack Configure A
' Set our OPC to 00000111 and set the 5 modules to ITU (MTP,ISUP,L3P,SCCP,TCAP)
709
MSP
00 1a 00 5c 00 00 ff 00 01 21 02 02 00 00 00 01 11 05 01 01 02 01 03 01 06 01 07 01
' Set the Signaling Link Set Config. A
' Define a Link Set going to 00000222 ID 0
00 0f 00 5d 00 00 ff 00 01 1e 02 00 00 00 00 02 22
' Set the Signaling Link Config. A
' Define a link ID 0 for Set-0 SLC-0 Using Span/Channel (0,0) 64k
' Define a link ID 1 for Set-0 SLC-1 Using Span/Channel (2,0) 64k
00 14 00 5e 00 00 ff 00 02 1f 03 00 00 01 0d 03 00 00 00 00 00 00
00 14 00 5e 00 00 ff 00 02 1f 03 00 00 02 0d 03 00 01 00 01 00 00
Set the Signaling Route Configure for A '
' Configure Second SS7 Stack (B)
'Set Signaling Stack Configure B
' Set our OPC to 00000222 and set the 5 modules to ITU(MTP,ISUP,L3P,SCCP,TCAP)
'
brd
00 1a 00 5c 00 00 ff 00 01 21 02 02 01 00 00 02 22 05 01 01 02 01 03 01 06 01 07 01
' Set the Signaling Link Set Config. B
' Define a Link Set going to 00000111 ID 1
00 0f 00 5d 00 00 ff 00 01 1e 02 01 01 00 00 01 11
' Set the Signaling Link Config. B
' Define a link ID 1 for Set-1 SLC-0 Using logical Span (63,0) 64k
00 14 00 5e 00 00 ff 00 02 1f 03 01 01 02 0d 03 00 01 00 00 00 00
00 14 00 5e 00 00 ff 00 02 1f 03 01 01 03 0d 03 00 03 00 01 00 00
' Set the Signaling Route Configure
' Define a Route to 00 00 01 11 using only Link Set 1
710
Developer Information
' Service State Configure
Place All Spans and Channels In service.
' 00 0d 0a 00 00 ff <ENTITY> <ACTION> <ID0> <ID1> <ID2> <ID3> <FORCE>
00 0d 00 0a 00 00 ff 00 01 0c 02 00 00 F0 00
00 0d 00 0a 00 00 ff 00 01 0c 02 00 01 F0 00
00 0d 00 0a 00 00 ff 00 01 0c 02 00 02 F0 00
00 0d 00 0a 00 00 ff 00 01 0c 02 00 03 F0 00
'Bring links Into Service
' Bring the Links in Service
00 0d 00 0a 00 00 ff 00 01 09 02 00 00 f0 00
00 0d 00 0a 00 00 ff 00 01 09 02 00 01 f0 00
00 0d 00 0a 00 00 ff 00 01 09 02 01 02 f0 00
00 0d 00 0a 00 00 ff 00 01 09 02 01 03 f0 00
sccp.cfg
'configure SCCP local SSN
711
MSP
unitdata.cfg
begin.cfg
'directhost.cfg
712
Developer Information
'matrixhost.cfg
TCAP primitive #1
This example along with the next one, TCAP Primitive #2, show how to map the
TCAP Primitive Interface to the TCAP Primitive Set Interface.
-- TC_INVOKE request
TCAP primitive #2
713
MSP
TCAP Primitive Set
It may be helpful to compare this example to the previous examples, TCAP Primitive
#1 and TCAP Primitive #2.
TC_BEGIN primitive set request (with TC_Invoke component)
714
Developer Information
SCCP TCAP Primitives
Overview
The communication that takes place between the MTP, SCCP, and TCAP layers of the
SS7 stack is achieved with the use of primitives. Interfaces between the functional
elements of SS7 are specified using interface primitives. Primitive interface definition
does not assume any specific implementation of a service The host uses SCCP/TCAP
services by invoking the SCCP N- or TCAP TC- primitives with the PPL Event Request
message. A response status of Positive ACK (0x10) indicates that the primitive is
validated and processed. A NACK of 0x54 indicates Error Detected in Primitive. The
LSB of the Status byte gives more detail on the error. TC-USER can re-send the
corrected primitive. See Response Status Values in the API Reference for details on
LSB status.
Peer-to-Peer Messages
715
MSP
TCAP Primitive Types
There are two types of TCAP primitives:


Dialog
Component
Dialog Primitives
Dialog primitives request or indicate facilities of transaction sub-layer, in relation
with message translation or dialog handling. dialog primitives may contain a TCAP
ICB or a TCAP ICB and an SCCP ICB.
Component Primitive
Component primitives are used in the handling of operations and replies. They do not
require facilities form the underlying sub-layer. Component primitives contain a TCAP
ICB.
Dialogs
Simultaneous Transactions
The maximum number of simultaneous transactions is 32,000 per stack. If number is
exceeded, any TC-USER request which may result in a new transaction to be created
is returned with a NACK of Resource Limitation (0x5409).
You can use the SS7 SCCP/TCAP Query message (0x0078) to query the number of
active dialog/transaction/operations.
The following may result in a larger number of active dialogs at one time:


716
Average life time of a dialog is long.
Messages that never get a response back (hanging dialog) - these dialogs use
the TCAP dialog resources and do not release them.
Developer Information
The maximum number of simultaneous invocations is 96,000. There is no limit on
the number of invocations per transaction. If you include multiple components within
one TCAP message, you should ensure that it fits in one MSU, otherwise; you may
receive a NACK for the message. (If you use the SCCP Segmentation feature of
SCCP/TCAP, this limitation does not apply. The maximum length of a TCAP message
can be 3092 (ANSI) or 2048 (ITU).)
Important! In this context, incoming dialog means the new dialog is initialized,
caused by receiving a network TCAP message (BEGIN[ITU], or
QUERY[ANSI]). Outgoing dialog means the new dialog is initialized, caused by
the host sending a TCAP primitive (TC_BEGIN[ITU], or TC_QUERY_
with/without_PERMISSION[ANSI]).
Beginning a dialog
A TC_USER begins a new dialog by issuing a TC-BEGIN (ITU) or TC-QUERY-WITHPERMISSION/TC-QUERY-WITHOUT-PERMISSION (ANSI) request primitive to:


indicate to the Component sub-layer that a new dialog starts, identified by
the dialog ID parameter.
request transmission of any component(s) previously passed to the
Component sub-layer by means of component handling primitives of the
Request type with the same dialog ID.
Continuing a dialog
A TC-USER indicates that it wants to continue a dialog by issuing a TC-CONTINUE
(ITU) or TC-CONVERSATION-WITH-PERMISSION/TC-QUERY-WITHOUT-PERMISSION
(ANSI) request primitive.
Ending a dialog
There are three methods for ending a dialog:

Pre-arranged End

Basic End

Abort by TC-USER
The end of the dialog has been decided by prior arrangement of the TC-USERs. The
effect of the TC-END (ITU) or TC-RESPONSE (ANSI) request primitive is local only;
no TC-END or TC-RESPONSE indication is generated.
The ending causes transmission of any pending components at the side which
initiates it.
The TC-U-ABORT request and indication primitives are used to indicate abort by the
TC-USER.
Dialog ID Usage
The incoming Dialog ID space is a set including 32,000 continuous dialog IDs (per
stack). This is because incoming dialog IDs are allocated by TCAP and the maximum
TCAP support is 32,000 simultaneous transactions per stack. The beginning of the
717
MSP
incoming dialog ID is defined by the TCAP PPL component TCO Config Byte 1-4 (see
TCAP TCO (0x0073). This can be reconfigured, if necessary. The outgoing dialog ID,
however, is specified by the TC user. Even though TCAP software does support any
4-byte dialog ID, as long as it does not collide with the incoming ID set, we
recommend the use of the range from 0 - 32767 for performance reasons. The dialog
ID, which must be four bytes, is also used in the SS7 TCAP Parameters (0x21) ICB
which is used with the PPL Event Indication and PPL Event Request API messages.
Exception Reporting and Message Return
TC-USERs are notified of non-delivery of components by the TC-NOTICE indication
primitive. A TC-NOTICE indication primitive is only passed to the TC-USER if the
requested service cannot be provided and the TC-USER requested the Return Option
in the Quality of Service parameter of the dialog handling request primitive.
Invoke a Remote Operation
The TC-INVOKE (ITU), TC-INVOKE-L (ANSI) and TC-INVOKE-NL (ANSI) primitives
are used to invoke a remote operation.


TC-INVOKE-LAST (ANSI)
Indicates the only or last segment of the invocation.
TC-INVOKE-NOT LAST (ANSI)
Indicates a segment of an invocation (with more segments to follow).
Report of Success
The TC-RESULT-L and TC-RESULT-NL primitives are used to indicate that an
operation has been executed by the remote TC-USER.


TC-RESULT-L
Indicates the only or last segment of a result.
TC-RESULT-NL
Indicates a segment of a result (with more segments to follow).
Report of Failure
A TC-USER receiving an operation which it cannot execute, though it understands it,
will issue a TC-U-ERROR request primitive, indicating the reason of the failure (Error
parameter). The TC-USER which invoked the operation is informed by a TC-U-ERROR
indication primitive.
Reject by TC-USER
A TC-USER rejects a component with the TC-U-REJECT request primitive, and is
informed of rejection by the remote TC_User with the TC-U-REJECT indication
primitive.
Cancel of an Operation: The TC-USER informs the local Component sub-layer of a
cancel decision with the TC-U-CANCEL request primitive. No component is sent.
718
Developer Information
Reject of a Component by the Component Sub-Layer
While detecting that a received component is invalid, the Component sub-layer
notifies the local TC-USER with the TC-L-REJECT indication primitive. The reject
information is passed to the TC-USER and also retained in the Component sub-layer
which uses it to form a Reject component.
The remote TC-USER is informed of the received Reject component through a TC-RREJECT indication primitive.
Dialog Abort
TCAP may abort the association between users due to an abnormal situation. The
structured dialog must then also be aborted. All associated operations are terminated
and the TC-USERs are notified with the TC-P-ABORT indication primitive.
Closing a Transaction
A transaction is closed if TC-USER:
Issues:


TC-END (ITU) or TC-RESPONSE (ANSI)
TC-U-ABORT
Receives:

TC-END (ITU) or TC-RESPONSE (ANSI)

TC-P-ABORT

TC-U-ABORT
Incoming Reject Components
An incoming reject component received with a TCAP Problem Code causes a TC-RREJECT indication to be sent to the TC-USER. This indicates that the remote TCAP
detected a problem with a previously sent component.
An incoming reject component received with a TC-USER Problem Code causes a TCU-REJECT indication to be sent to the TC-USER. This indicates that the remote TCUSER detected a problem with a previously sent component and issued a TC-UREJECT request.
A TC-L- REJECT indication is used when a local TCAP detects a problem with an
incoming component. TCAP sends a TC-L- REJECT indication to the host and a Reject
component to the remote TCAP.
When a component is rejected by TCAP, all subsequent components within the same
TCAP message are discarded. Any components before the invalid component are sent
to the host by the proper primitives.
Host Link Failure Handling
When host link failure is detected by the MSP 1010:
719
MSP


TCAP Restart procedures apply for all active subsystems, if the TCAP PPL
Component TUSI Config Byte 3 is set as 1.
All local subsystems are set as Prohibited.
When the host link is recovered, it is the hosts responsibility to set all subsystems in
service using the N_STATE primitive as allowed.
TCAP Restart
A system reset or switchover will result in a TCAP Restart. All active TCAP dialogs will
return to the IDLE state. You can initiate a manual TCAP restart by sending a PPL
Event Request message to the TCAP TUSI component with the event of TCAP Restart
(0x1E).
Do not reuse the dialog ID immediately after a TCAP Restart as there may be some
network messages remaining in queue for the old dialog.
PPL Config Byte 2 of the TCAP TUSI component indicates the Abort Reason sent in
the TCAP Abort message following a TCAP Restart.
Notes on TCAP Primitives
For primitives in TCAP (e.g., for TCAP TUSI: TC-BEGIN, TC-CONTINUE, TC-UNI) the
following applies:


The maximum ICB length in the PPL Event Indication has a default value of
240.
When any TC-Primitive exceeds 240, then a TCAP TUSI PPL Event Indication
(event=0x1F) is sent to the host prior to the actual PPL Event Indication,
which means that the following actual PPL Event Indication is truncated. You
can increase this value by using TCAP TUSI Config Bytes 4 and 5. See SS7
PPL Information for the config byte message description.
For the definition and usage of TCAP primitives, refer to the ITU White Book Q.711
Functional Description of Transaction Capabilities and Q.775 Guideline for using
TCAP.
Supported Primitives
This section lists the SCCP and TCAP primitives supported by Excels SCCP/TCAP
feature. Primitives are sent to and received from the Excel platform in the PPL Event
Request and PPL Event Indication messages in ICBs.
Important! SCCP/TCAP primitives should not be confused with Excel PPL primitives.
TCAP Components should not be confused with Excel PPL components. See PPL
Information for PPL event values and ICB formats.
The required ICBs with mandatory (M) and optional (O) parameters are shown with
each primitive. See SCCP/TCAP Parameter Information for the data required for each
parameter.
The ANSI specification does not define TCAP primitives to TC_User. Where common
primitives are used, Excel followed the ITU Q.771 definitions.
ITU Primitives
720
Developer Information
The following ITU SCCP and TCAP primitives are supported by the PPL Event Request
and PPL Event Indication messages. The primitive is supported by both messages
unless noted otherwise.
TCAP

TC-BEGIN 0x01

TC-END 0x03















SCCP
TC-CONTINUE 0x02
TC-UNI 0x04
TC-U-ABORT 0x05
TC-P-ABORT 0x06 (Indication only)
TC-RESULT-L 0x0C
TC-RESULT-NL 0x0D
TC-U-ERROR 0x0E
TC-L-CANCEL 0x0F (Indication only)
TC-U-REJECT (0x12)
TC-L-REJECT 0x13 (Indication only)
TC-R-REJECT 0x14 (Indication only)
TC-INVOKE 0x15
TC-U-CANCEL 0x16 (Request only)
TC-NOTICE 0x17 (Indication only)
TC_RESET_TIMER 0x19 (Request only)

N-UNIT-DATA 0x01

N-STATE 0x03


N-NOTICE 0x02 (Indication only)
N-PC-STATE 0x04 (Indication only)
SCCP CSCC


N-COORD 0x05
N-COORD 0x08
SCCP SCOC

N-CONNECT 0x15

N-DATA 0x17


N-CONNECT 0x16 (Response/Confirmation)
N-DISCONNECT Ox1B
ANSI Primitives
721
MSP
The ANSI primitives are supported by both the PPL Event Request and PPL Event
Indication message unless noted otherwise.
TCAP

TC-UNI 0x04

TC-P-ABORT 0x06 (Indication only)
















SCCP
TC-U-ABORT 0x05
TC-QUERY-WITH-PERMISSION 0x07
TC-QUERY-WITHOUT-PERMISSION 0x08
TC-CONVERSATION-WITH-PERMISSION 0x09
TC-CONVERSATION-WITHOUT-PERMISSION 0x0A
TC-RESPONSE 0x0B
TC-RESULT-L 0x0C
TC-RESULT-NL 0x0D
TC-U-ERROR 0x0E
TC-INVOKE-L 0x10
TC-INVOKE-NL 0x11
TC-U-REJECT 0x12
TC-L-REJECT 0x13 (Indication only)
TC-R-REJECT 0x14 (Indication only)
TC-U-CANCEL 0x16 (Request only)
TC-NOTICE 0x17 (Indication only)

N-UNIT-DATA 0x01

N-STATE 0x03


N-NOTICE 0x02 (Indication only)
N-PC-STATE 0x04 (Indication only)
SCCP CSCC


N-COORD 0x05
N-COORD 0x08
SCCP SCOC

N-CONNECT 0x15

N-DATA 0x17


N-CONNECT 0x16 (Response/Confirmation)
N-DISCONNECT Ox1B
ANSI TCAP Primitives
Overview
722
Developer Information
This section lists the ANSI TCAP primitives supported by the SCCP/TCAP feature.
Primitives are sent to and received from the MSP 1010 in the PPL Event Request and
PPL Event Indication messages in ICBs:

SS7 TCAP Parameters (0x21).
Important! The TCAP ICB always includes a dialog ID which is four bytes.
ANSI Primitives
The ANSI primitives are supported by both the PPL Event Request and PPL Event
Indication message unless noted otherwise.

TC-UNI

TC-QUERY-WITHOUT-PERMISSION




















TC-QUERY-WITH-PERMISSION
TC-CONVERSATION-WITH-PERMISSION
TC-CONVERSATION-WITHOUT-PERMISSION
TC-RESPONSE
TC-U-ABORT
TC-P-ABORT (Indication only)
TC-NOTICE (Indication only)
TC-INVOKE-L
TC-INVOKE-NL
TC-RESULT-L
TC-RESULT-NL
TC-U-ERROR
TC-U-REJECT
TC-L-REJECT (Indication only)
TC-R-REJECT (Indication only)
TC-U-Cancel (Request only)
N-UNIT-DATA
N-NOTICE (Indication only)
N-STATE
N-PC-STATE (Indication only)
ANSI TCAP TUSI PPL Events
The TCAP User Interface is responsible for host API message validation. This section
lists the PPL Events used to send ANSI TCAP primitives in the PPL Event Request and
PPL Event Indication messages.The required ICBs with mandatory (M) and optional
(O) parameters are shown with each primitive. See SCCP/TCAP Parameter
Information for the data required for each parameter.
723
MSP
The following events are used to send and receive ANSI primitives for the PPL
component, TCAP TUSI (0x70). The primitive IDs correspond to the PPL Event IDs
for this component. The ANSI specification does not define TCAP primitives to
TC_User. Where common primitives are used, Excel followed the ITU Q.771
definitions.
Note: An asterisk beside an event indicates that you should see SCCP/TCAP
Parameter Information for the format.
0x04 TC-UNI
This dialog primitive requests/indicates an Unstructured dialog. It corresponds to an
Unidirectional TCAP package. Note that the TCAP ICB always includes a dialog ID.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
0x05 TC-U-ABORT
This dialog primitive allows a TC-USER to terminate a dialog abruptly without
transmitting any pending components.
Request
Indication
- User Abort Info (M)
- User Abort Info (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
0x06
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
TC-P-ABORT
This dialog primitive informs TC-USER that the dialog has been terminated by the
TCAP because a protocol error has been detected. No pending components will be
sent.
Request
724
Indication
TCAP Parameter ICB (M)
Developer Information
- P-Abort Cause (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
0x07
TC-QUERY-WITH-PERMISSION
This dialog primitive is similar to the ITU TC-BEGIN primitive. Under normal
circumstances, it will cause a TCAP Query with Permission package to be sent to the
network. An Indication indicates an incoming Query with Permission package, which
starts a dialog.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
0x08
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
TC-QUERY-WITHOUT-PERMISSION
This dialog primitive is the same as the TC-QUERY-WITH-PERMISSION except that it
indicates to the peer that the transaction cannot be released. See the ANSI
specification for more information (this primitive corresponds to the Query Without
Permission package). This primitive starts a dialog.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
0x09 TC-CONVERSATION-WITH-PERMISSION
725
MSP
This dialog primitive is similar to the ITU TC-CONTINUE. It corresponds to the TCAP
Conversation package. It indicates the continuation of a dialog.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O) 1
- Called Party Address (CDPA) or CDPA
Elements (O)1
- Quality of Service (O)
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O) 2
- Called Party Address (CDPA) or CDPA
Elements (O) 2
- Quality of Service (O)
1 CGPA and CDPA are stored for the dialog when it is initialed. TC-USER provides
CGPA and CDPA only if they are changed.
2 CGPA and CDPA are sent to the host only if they differ from the stored values.
0x0A
TC-CONVERSATION-WITHOUT-PERMISSION
This primitive is similar to the TC-CONVERSATION-WITH-PERMISSION, except that
the peer does not have permission. It corresponds to the ITU Conversation Without
Permission package. It is the continuation of a dialog.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O) 1
- Called Party Address (CDPA) or CDPA
Elements (O)1
- Quality of Service (O)
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)2
- Called Party Address (CDPA) or CDPA
Elements (O)2
- Quality of Service (O)
1 CGPA and CDPA are stored for the dialog when it is initialed. TC-USER provides
CGPA and CDPA only if they are changed.
2 CGPA and CDPA are sent to the host only if they differ from the stored values.
0x0B
TC-RESPONSE
This dialog primitive is similar to the ITU TC-END primitive. It corresponds to the ITU
Response package when the termination option is set to Basic End. When the
termination option is set to
Pre-arranged End, this primitive ends the dialog locally.
Request
726
Indication
Developer Information
TCAP Parameter ICB (M)
TCAP Parameter ICB (M)
- Termination Option
- Component Present (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)
SCCP Parameter ICB (O)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
0x0C
SCCP Parameter ICB (O)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
TC-RESULT-L
This component primitive corresponds to the ITU Return Result Last Component. It is
the only result or the last part of the segmented result of a successfully executed
operation.
Request
Indication
- Correlation ID (O)
- Correlation ID (O)
TCAP Parameter ICB (M)
- Parameter (O) *
0x0D
TCAP Parameter ICB (M)
- Parameter (O) *
TC-RESULT-NL
This component primitive corresponds to the ITU Return Result Not Last Component.
It is a non-final part of a segmented result of a successfully executed operation.
Request
Indication
- Correlation ID (O)
- Correlation ID (O)
TCAP Parameter ICB (M)
- Parameter (O) *
0x0E
TCAP Parameter ICB (M)
- Parameter (O) *
- Last Component (M)
TC-U-ERROR
This component primitive corresponds to the ITU Return Error component. It
indicates that the operation failed.
Request
Indication
- Correlation ID (O)
- Correlation ID (O)
TCAP Parameter ICB (M)
- Error Code (M) *
- Parameter (O) *
TCAP Parameter ICB (M)
- Error Code (M) *
- Parameter (O) *
- Last Component (M)
727
MSP
0x10
TC-INVOKE-L
This component primitive corresponds to the ITU Invoke Last component. It is the
only part or last part of the segmentation of the invocation of the operation. It may
be the invocation of an operation or an invocation responding to another invoke.
Request
Indication
- Invoke ID (O)
- Invoke ID (O)
TCAP Parameter ICB (M)
- Correlation ID (O)
- Operation (M) *
- Parameter (O) *
0x11
TCAP Parameter ICB (M)
- Correlation ID (O)
- Operation (M) *
- Parameter (O) *
- Last Component (M)
TC-INVOKE-NL
This component primitive corresponds to the ITU Invoke Not Last component. It is
always an invocation responding to another invoke. It is a non-final segment of the
invoke.
Request
Indication
- Invoke ID (M)
- Invoke ID (M)
TCAP Parameter ICB (M)
- Correlation ID (M)
- Operation (M) *
- Parameter (O) *
TCAP Parameter ICB (M)
- Correlation ID (M)
- Operation (M) *
- Parameter (O) *
- Last Component (M)
0x12 TC-U-REJECT
This component primitive corresponds to a Reject component. It is initiated because
of a user decision of Reject an Incoming Component.
Request
Indication
- Correlation ID (O)
- Correlation ID (O)
TCAP Parameter ICB (M)
- Problem Code (M)
- Parameter (O) *
TCAP Parameter ICB (M)
- Problem Code (M)(see SCCP/TCAP
Parameter Information for format)
- Parameter (O) *
- Last Component (M)
0x13
728
TC-L-REJECT
Developer Information
This component primitive indicates the detection of a protocol error in an incoming
component. A Reject component is constructed and stored for this dialog, and is sent
out upon the reception of another transaction layer primitive request.
Request
Indication
TCAP Parameter ICB (M)
- Invoke ID or Correlation ID (O)
- Problem Code (M) (see SCCP/TCAP
Parameter Information for format)
- Last Component (M)
0x14
TC-R-REJECT
This indication informs the TC-USER that the remote TCAP rejected a previously sent
component.
Request
Indication
TCAP Parameter ICB (M)
- Correlation ID (O)
- Problem Code (M) (see SCCP/TCAP
Parameter Information for format)
- Last Component (M)
TCAP Primitive Set Interface
Purpose
The TCAP Primitive Set Interface feature is based on the existing TCAP software
architecture. TCAP and the SS7 layer below it reside on the Excel platform and the
TC-User resides on the host.
TCAP communicates with the TC-User through multiple TC-primitives so that a dialog
can be embedded into a single PPL Event Request or PPL Event Indications API
message.
This feature provides the following:


Reduces the API level transport and processing overhead on various software
components, such as the SS7 host communication and transport layer, and
host application message processing and transport layer.
Reduces message traffic on the internal Ethernet or HDLC depending on the
architecture, thereby improving overall system performance.
TCAP Primitive Set Interface Description
The host application sends and receives messages to and from the TCAP USer
Interface (TUSI) PPL component for the primitive set interface. Each TC-primitive
type is uniquely identified by a PPL Event ID in the PPL Event Request and PPL Event
Indication API messages. These API messages include all of the ICBs for each
729
MSP
individual TC-primitive. A component TC-primitive includes a TCAP parameter ICB. A
dialog TC-primitive includes a TCAP parameter ICB plus an optional SCCP parameter
ICB for SCCP addresses.
TCAP Outgoing Message
The TUSI parses and validates the PPL Event Request API message with TC primitive
set PPL Event ID from the TC-User. After validation, the TUSI sends the component
primitive data and the dialog primitive data to the TCAP PPL components according
to the TCAP protocol.



The TUSI first sends each component primitive data to the TCAP PPL
components in the order presented in the API message.
The TUSI then sends the dialog primitive data to the TCAP PPL components
and sends a Positive Acknowledgement to the TC-User.
Other TCAP PPL components will process each of these primitives individually.
TCAP Incoming Message
When TCAP receives an incoming message with one or more components, the TCAP
PPL components process this message according to the TCAP protocol.



After processing, the dialog primitive data first and then the component
primitive data are sent to the TUSI.
The TUSI packs the dialog primitive ICB(s), followed by all the component
ICBs in the order it receives them.
It then sends all of these ICBs in one PPL Event Indication API message to the
TC-User.
TUSI Negative Acknowledgements (NACK)
The TUSI sends a negative acknowledgement (NACK) to the TC-User if it detects
syntax errors in the PPL Event Request API message. The TC-User may re-send the
API message after receiving a NACK from TCAP.
Important! The TC-User is responsible for the correctness and consistency of the
contents in the PPL Event Request API message. After the TUSI validates the
API message syntax and sends the dialog and component primitives to other
TCAP PPL components, TCAP would consider any detected error as an
unrecoverable error for the dialog primitives, therefore the dialog primitives
will be aborted in this case. The TC-User as well as the network (if needed)
will be informed.
TCAP Primitive Set Interface Call Flow
The following call flow provides an example of the TCAP to TC-User interface using
the TCAP Primitive Set Interface feature.
730
Developer Information
TCAP Primitive Sets PPL Events
The TCAP Primitive Sets PPL Events listed below are provided for the TCAP Primitive
Set Interface. One PPL Event is defined for each dialog TC-primitive type that is
allowed to have attached component(s). The PPL Events listed below are in addition
to the currently supported PPL Events for individual TC-primitives.
ANSI Variant TC Primitive Set PPL Events
TC_UNI Primitive Set (0x31) (PPL Event Indication and PPL Event Request)
TC_QUERY_WITH_PERMISSION Primitive Set (0x35) (PPL Event Indication and PPL
Event Request)
TC_QUERY_WITHOUT_PERMISSION Primitive Set (0x36) (PPL Event Indication and
PPL Event Request)
TC_CONVERSATION_WITH_PERMISSION Primitive Set (0x37) (PPL Event Indication
and PPL Event Request)
TC_CONVERSATION_WITHOUT_PERMISSION Primitive Set (0x38) (PPL Event
Indication and PPL Event Request)
TC_RESPONSE Primitive Set (0x39) (PPL Event Indication and PPL Event Request)
ITU/ETSI Variant TC Primitive Set PPL Events
TC_UNI Primitive Set (0x31) (PPL Event Indication and PPL Event Request)
TC_BEGIN Primitive Set (0x32) (PPL Event Indication and PPL Event Request)
TC_CONTINUE Primitive Set (0x33) (PPL Event Indication and PPL Event Request)
TC_END Primitive Set (0x34) (PPL Event Indication and PPL Event Request)
ANSI/ITU/ETSI Variant TC Primitive PPL Event
PPL_EVENT_TCAP_INITIATED_U_ABORT (0x21) (PPL Event Indication)
This PPL Event Indication is initiated by TCAP due to software internal inconsistency
and unrecoverable errors. These errors can be caused by incorrect data passed from
the TC-User or other software module in the system as well as TCAP internal
software errors.
731
MSP
Important! This event is different from TC_U_ABORT event that indicates the
remote TCAP User aborted the transaction.
TC Primitive Set
To align with the ICBs in individual TC-primitives, a TC Primitive Set includes a TCAP
dialog primitive ICB and zero, one, or more TCAP component ICBs, and an optional
SCCP ICB for SCCP addresses.
A zero-component is allowed to be compliant with the TCAP standard where the
component portion is optional in some TCAP messages. Whether it is mandatory for
each TCAP message to include a component is based on the specific TCAP standard
variants.
When using the TCAP Primitive Set Interface, use the following TC-primitive variants
in addition to the TC primitive set events:
ANSI Variants
TC_U_ABORT (PPL Event Indication and PPL Event Request)
TC_P_ABORT (PPL Event Indication)
TC_NOTICE (PPL Event Indication)
ITU/ETSI Variants
TC_U_ABORT (PPL Event Indication and PPL Event Request)
TC_P_ABORT (PPL Event Indication)
TC_NOTICE (PPL Event Indication)
TC_L_CANCEL (PPL Event Indication)
TCAP Primitive Options
TCAP primitive configuration options, per SS7 stack, are provided to select either the
Individual TCAP Primitive API option or the TCAP Primitive Set Interface option.
The default is the Individual TC Primitive API option for backward compatibility
considerations. The TCAP PPL Component TUSI Configuration Byte is used for this
purpose.
Use the TCAP primitive ICB subtype for TCAP primitive sets.
ICB Subtype - TCAP Primitive ICB
The TCAP primitive ICB subtype (0x65) has two additional bytes for the TCAP TCprimitive ID in the following ICB formats:


Data (bytes 8 and 9)
Extended Data (bytes 10 and 11)
Compared to the existing TCAP parameter ICB, the TCAP TC-primitive ID value is
same as the corresponding PPL Event ID value. The TCAP parameter TLVs for each
TC primitive remain same as in current TCAP parameter ICB.
732
Developer Information
TCAP TUSI PPL Configuration Byte
Byte
0x09
Description
Selects TCAP to TCUser interface
format
Value
0x00 = Use individual TCPrimitive (Default)
0x01 = Use TCAP Primitive Set
Interface
Examples
You can view TCAP Primitive Set API messaging examples in Example Configurations
and TCAP API Messaging.
ITU TCAP Primitives
Overview
This section lists the ITU TCAP primitives supported by the SCCP/TCAP feature.
Primitives are sent to and received from the MSP 1010 in the PPL Event Request and
PPL Event Indication messages in ICBs:

SS7 TCAP Parameters (0x21).
Important! The TCAP ICB always includes a dialog ID which is four bytes.
ITU Primitives
The following ITU TCAP primitives are supported by the PPL Event Request and PPL
Event Indication messages. The primitive is supported by both messages unless
noted otherwise.

TC-UNI

TC-CONTINUE












TC-BEGIN
TC-END
TC-U-ABORT
TC-P-ABORT (Indication only)
TC-NOTICE (Indication only)
TC-INVOKE
TC-RESULT-L
TC-RESULT-NL
TC-U-ERROR
TC-U-REJECT
TC-L-CANCEL (Indication only)
TC-U-CANCEL (Request only)
733
MSP

TC-L-REJECT (Indication only)

N-UNIT-DATA





TC-R-REJECT (Indication only)
N-NOTICE (Indication only)
N-STATE
N-PC-STATE (Indication only)
TC_RESET_TIMER
ITU TCAP TUSI PPL Events
The TCAP User Interface is responsible for host API message validation. This section
lists the PPL Events used to send ITU TCAP primitives in the PPL Event Request and
PPL Event Indication messages. The required ICBs with mandatory (M) and optional
(O) parameters are shown with each primitive. See SCCP/TCAP Parameter
Information for the data required for each parameter.
The following events are used to send and receive ITU primitives for the PPL
component, TCAP TUSI (0x70). The primitive IDs correspond to the PPL Event IDs
for this component.
Note: An asterisk beside an event indicates that you should see SCCP/TCAP
Parameter Information for the format.
0x01 TC-BEGIN
Request
Indication
- Application Context Name (O)
- Application Context Name (O)
TCAP Parameter ICB (M)
- User Information (O)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
- MTP_DPC (0)
0x02 TC-CONTINUE
TCAP Parameter ICB (M)
- User Information (O)
- Component Present (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
- MTP_OPC (0)
Request
Indication
- Application Context Name (O)
- Application Context Name (O)
TCAP Parameter ICB (M)
734
TCAP Parameter ICB (M)
Developer Information
- User Information (O)
- User Information (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)
SCCP Parameter ICB (O)
SCCP Parameter ICB (O)
- Quality of Service (O)
0x03 TC-END
- Component Present (M)
- Quality of Service (O)
Request
Indication
- Application Context Name (O)
- Application Context Name (O)
TCAP Parameter ICB (M)
- User Information (O)
- Termination Option (M)
SCCP Parameter ICB (O)
- Quality of Service (O)
TCAP Parameter ICB (M)
- User Information (O)
- Component Present (M
SCCP Parameter ICB (O)
- Quality of Service (O)
0x04 TC-UNI
This dialog primitive requests/indicates an Unstructured dialog. It corresponds to an
Unidirectional TCAP package.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
0x05 TC-U-ABORT
This dialog primitive allows a TC-USER to terminate a dialog abruptly without
transmitting any pending components.
Request
Indication
- User Abort Info (M)
- User Abort Info (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
735
MSP
Elements (O)
Elements (O)
- Quality of Service (O)
- Quality of Service (O)
- Called Party Address (CDPA) or CDPA
Elements (O)
0x06
- Called Party Address (CDPA) or CDPA
Elements (O)
TC-P-ABORT
This dialog primitive informs TC-USER that the dialog has been terminated by the
TCAP because a protocol error has been detected. No pending components will be
sent.
Request
Indication
TCAP Parameter ICB (M)
- P-Abort Cause (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
0x07
TC-QUERY-WITH-PERMISSION
This dialog primitive is similar to the ITU TC-BEGIN primitive. Under normal
circumstances, it will cause a TCAP Query with Permission package to be sent to the
network. An Indication indicates an incoming Query with Permission package, which
starts a dialog.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
- MTP_DPC (0)
0x08
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
- MTP_OPC (0)
TC-QUERY-WITHOUT-PERMISSION
This dialog primitive is the same as the TC-QUERY-WITH-PERMISSION except that it
indicates to the peer that the transaction cannot be released. See the ANSI
736
Developer Information
specification for more information (this primitive corresponds to the Query Without
Permission package). This primitive starts a dialog.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
- MTP_DPC (0)
TCAP Parameter ICB (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
- MTP_OPC (0)
0x09 TC-CONVERSATION-WITH-PERMISSION
This dialog primitive is similar to the ITU TC-CONTINUE. It corresponds to the TCAP
Conversation package. It indicates the continuation of a dialog.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O) 1
- Called Party Address (CDPA) or CDPA
Elements (O) 1
- Quality of Service (O)
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O) 2
- Called Party Address (CDPA) or CDPA
Elements (O) 2
- Quality of Service (O)
1 CGPA and CDPA are stored for the dialog when it is initialed. TC-USER provides
CGPA and CDPA only if they are changed.
2CGPA and CDPA are sent to the host only if they differ from the stored values.
0x0A
TC-CONVERSATION-WITHOUT-PERMISSION
This primitive is similar to the TC-CONVERSATION-WITH-PERMISSION, except that
the peer does not have permission. It corresponds to the ITU Conversation Without
Permission package. It is the continuation of a dialog.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
737
MSP
Elements (O) 1
Elements (O) 2
- Quality of Service (O)
- Quality of Service (O)
- Called Party Address (CDPA) or CDPA
Elements (O) 1
- Called Party Address (CDPA) or CDPA
Elements (O) 2
1 CGPA and CDPA are stored for the dialog when it is initialed. TC-USER provides
CGPA and CDPA only if they are changed.
2 CGPA and CDPA are sent to the host only if they differ from the stored values.
0x0B
TC-RESPONSE
This dialog primitive is similar to the ITU TC-END primitive. It corresponds to the ITU
Response package when the termination option is set to Basic End. When the
termination option is set to
Pre-arranged End, this primitive ends the dialog locally.
Request
Indication
- Termination Option
- Component Present (M)
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
0x0C
TCAP Parameter ICB (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
TC-RESULT-L
This component primitive corresponds to the ITU Return Result Last Component. It is
the only result or the last part of the segmented result of a successfully executed
operation.
Request
Indication
- Correlation ID (O)
- Correlation ID (O)
TCAP Parameter ICB (M)
- Parameter (O) *
0x0D
TCAP Parameter ICB (M)
- Parameter (O) *
TC-RESULT-NL
This component primitive corresponds to the ITU Return Result Not Last Component.
It is a non-final part of a segmented result of a successfully executed operation.
Request
TCAP Parameter
ICB (M)
738
Indication
TCAP Parameter ICB
(M)
Developer Information
- Correlation ID (O)
- Correlation ID (O)
- Parameter (O) *
0x0E
- Parameter (O) *
- Last Component
(M)
TC-U-ERROR
This component primitive corresponds to the ITU Return Error component. It
indicates that the operation failed.
Request
Indication
- Correlation ID (O)
- Correlation ID (O)
TCAP Parameter
ICB (M)
- Error Code (M) *
- Parameter (O) *
0x10
TCAP Parameter ICB
(M)
- Error Code (M) *
- Parameter (O) *
- Last Component
(M)
TC-INVOKE-L
This component primitive corresponds to the ITU Invoke Last component. It is the
only part or last part of the segmentation of the invocation of the operation. It may
be the invocation of an operation or an invocation responding to another invoke.
Request
Indication
- Invoke ID (O)
- Invoke ID (O)
TCAP Parameter
ICB (M)
- Correlation ID (O)
- Operation (M) *
- Parameter (O) *
0x11
TCAP Parameter
ICB (M)
- Correlation ID (O)
- Operation (M) *
- Parameter (O) *
- Last Component
(M)
TC-INVOKE-NL
This component primitive corresponds to the ITU Invoke Not LAst component. It is
always an invocation responding to another invoke. It is a non-final segment of the
invoke.
Request
Indication
- Invoke ID (M)
- Invoke ID (M)
TCAP Parameter ICB (M)
TCAP Parameter ICB (M)
739
MSP
- Correlation ID (M)
- Correlation ID (M)
- Parameter (O) *
- Parameter (O) *
- Operation (M) *
- Operation (M) *
- Last Component (M)
0x12 TC-U-REJECT
This component primitive corresponds to a Reject component. It is initiated because
of a user decision of Reject an Incoming Component.
Request
Indication
- Correlation ID (O)
- Correlation ID (O)
TCAP Parameter ICB (M)
- Problem Code (M)
- Parameter (O) *
TCAP Parameter ICB (M)
- Problem Code (M) (see SCCP/TCAP
Parameter Information for format)
- Parameter (O) *
- Last Component (M)
0x13
TC-L-REJECT
This component primitive indicates the detection of a protocol error in an incoming
component. A Reject component is constructed and stored for this dialog, and is sent
out upon the reception of another transaction layer primitive request.
Request
Indication
TCAP Parameter ICB (M)
- Invoke ID or Correlation ID (O)
- Problem Code (M) (see SCCP/TCAP
Parameter Information for format)
- Last Component (M)
0x14
TC-R-REJECT
This indication informs the TC-USER that the remote TCAP rejected a previously sent
component.
Request
Indication
TCAP Parameter ICB (M)
- Correlation ID (O)
- Problem Code (M) (see SCCP/TCAP
Parameter Information for format)
- Last Component (M)
740
Developer Information
0x16
TC-U-CANCEL
This is a user request to cancel an operation. No component is sent.
Request
Indication
TCAP Parameter
ICB (M)
- Invoke ID (M)
0x17
TC-NOTICE
This primitive informs the TC-USER that the network service provider is unable to
provide the requested service.
Request
Indication
TCAP Parameter ICB (M)
- Return Cause (M)
Elements (0)
- Called Party Address
(CDPA) or CDPA
0x19
TC-RESET TIMER
This primitive resets the Invoke timer for TC_INVOKE primitive initiated from the
MSP 1010.
Request
Dialog
ID (M)
Indication
Invoke
ID (M)
ITU and ANSI SCCP Primitives
Overview
This section lists the SCCP primitives supported by the SCCP/TCAP feature.
Primitives are sent to and received from the switch in the PPL Event Request and PPL
Event Indication messages in the ICB:


SS7 SCCP Parameters (0x20)
SS7 SCCP CO Parameters (0x42)
Important! SCCP/TCAP primitives should not be confused with Excel PPL primitives.
SCCP Components should not be confused with Excel PPL components. See
the PPL Information for PPL event values and the API Reference ICB formats.
741
MSP
The required ICBs with mandatory (M) and optional (O) parameters are shown with
each primitive. See SCCP/TCAP Parameter Information for the data required for each
parameter.
ITU/ANSI SCCP Events
The SCCP User Interface is responsible for message validation and format
conversion. The following events are used to send and receive primitives for the PPL
component, SCCP SUSI (0x67).
N-UNIT-DATA (0x01)
Request
SCCP Parameter ICB (M)
- User Data (M)
Indication
Same as Request.
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
N-NOTICE (0x02)
Request
Indication
SCCP Parameter ICB (M)
- User Data (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Reason for Return (M)
N-STATE (0x03)
Request
Indication
- Subsystem Number (M)
- Destination Point Code (DPC) (M)
SCCP Parameter ICB (M)
- Subsystem Status (M)
SCCP Parameter ICB (M)
- DPC Status (O)
- Remote SCCP Status (O)
Important! When you use the N_STATE event to set a subsystem prohibit, all of the
active TCAP dialogs associated with the SSN are automatically released.
N-PCSTATE (0x04 )
742
Developer Information
Request
Indication
SCCP Parameter ICB (M)
- Destination Point Code (DPC) (M)
- DPC Status (O)
- Remote SCCP Status (O)
N-COORD (0x05)
Request
Indication
- Affected Subsystem
- Affected Subsystem
SCCP CO Parameters ICB(M)
N-COORD (0x08)
SCCP CO Parameters ICB(M)
- Subsystem Multiplicity Indicator (O)
Response
Confirm
-Affected Subsystem
- Affected Subsystem
SCCP CO Parameter ICB(M)
SCCP CO Parameter ICB(M)
- Subsystem Multiplicity Indicator (O)
ITU/ANSI SCCP CO Events
N-Connect (0x15)
Request
Indication
- Calling Party address (O)
- Calling Party address (O)
- SCCP Parameter ICB (M)
- Calling Party address (M)
- Expedited data selection (O)
- QOS parameter set (M)
- User data (O)
- Connection identification (O)
- Importance (O)
N-Connect (0x16)
Response
- SCCP Parameter ICB (M)
- SCCP Parameter ICB (M)
- Calling Party address (M)
- Expedited data selection (O)
- QOS parameter set (M)
- User data (O)
- Connection identification (O)
- Importance (O)
Confirmation
- SCCP Parameter ICB (M)
743
MSP
- Responding address (O)
- Responding address (O)
- QOS parameter set (M)
- QOS parameter set (M)
- Expedited data selection (O)
- User data (O)
- Connection identification (O)
- Importance (O)
N-Data (0x17)
- Expedited data selection (O)
- User data (O)
- Connection identification (O)
- Importance (O)
Request
Indication
- User data (O)
- User data (O)
- SCCP Parameter ICB (M)
- Connection identification (O)
- Importance (O)
N-Disconnect (0x1B)
- SCCP Parameter ICB (M)
- Connection identification (O)
- Importance (O)
Request
Indication
- Responding address (O)
- Responding address (O)
- Originator
- Reason (M)
- User data (O)
- Connection identification (O)
- Importance (O)
- Originator
- Reason (M)
- User data (O)
- Connection identification (O)
- Importance (O)
ITU TCAP Primitive Sets
Overview
The TCAP Primitive Set feature provides an interface to combine one TCAP dialog,
TC-Primitive, and its multiple associated components into one PPL Event Request or
PPL Event Indication. This section lists the ITU TCAP Primitive Sets supported by
Excels SCCP/TCAP feature. Primitive Sets are sent to and received from the MSP
1010 in the PPL Event Request and PPL Event Indication messages in ICBs:


744
SS7 TCAP Primitive ICB (0x65)
SS7 TCAP Parameters ICB (0x21)
Developer Information
Important! The maximum number of ICBs for the TCAP primitive set is 16. If this
maximum is exceeded, the MSP 1010 sends negative acknowledgement
0x5401.
The TCAP parameter ICBs always include a dialog ID which is four bytes. The TCAP
Primitive ICB includes a four-byte dialog ID and a two-byte Event ID.
ITU Primitive Sets
The following ITU TCAP Primitive Sets are supported by the PPL Event Request and
PPL Event Indication messages. Each primitive set is supported by both messages
unless noted otherwise.

TC-BEGIN Primitive Set

TC-END Primitive Set


TC-CONTINUE Primitive Set
TC-UNI Primitive Set
Needed Primitives
When using the Primitive Set interface you may also need the following primitives.

TC-U-ABORT (Request and Indication)

TC-NOTICE (Indication only)


TC-P-ABORT (Indication only)
TC-L-CANCEL (Indication only)
ITU TCAP TUSI PPL Events
The TCAP User Interface is responsible for host API message validation. This section
lists the PPL Events used to send ITU TCAP primitive sets in the PPL Event Request
and PPL Event Indication messages. The required ICBs with mandatory (M) and
optional (O) parameters are shown with each primitive set. See SCCP/TCAP
Parameter Information for the data required for each parameter.
The following events are used to send and receive ITU primitive sets for the PPL
component, TCAP TUSI (0x70). The primitive set IDs correspond to the PPL Event
IDs for this component.
In the tables below you will see: TCAP Primitive ICB for a component (none or
multiple)*. This refers to the Primitive ID in the SS7 TCAP Primitive ICB 0x65. The
Primitive ID in this ICB has the same ID as the Event ID in the TCAP Primitive
Interface for the same component. The Primitive IDs used for the following TCAP
Primitive Sets are:

TC-RESULT-L 0x0C

TC-U-ERROR 0x0E



TC-RESULT-NL 0x0D
TC-U-REJECT (0x12)
TC-L-REJECT 0x13 (Indication only)
745
MSP

TC-R-REJECT 0x14 (Indication only)

TC-U-CANCEL 0x16 (Request only)

TC-INVOKE 0x15
The Parameter TLV for a particular Primitive ID remains the same as if they were in
the TCAP Primitive Interface for the same Event ID.
0x01 TC-BEGIN Primitive Set
Request
Indication
- Application Context Name (O)
- Application Context Name (O)
TCAP Primitive ICB0x65 (M)
- User Information (O)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
- MTP_DPC (O)
TCAP Primitive ICB for a component
(none or multiple)*
0x02 TC-CONTINUE Primitive Set
TCAP Primitive ICB 0x65 (M)
- User Information (O)
- Component Present (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
- MTP_OPC (O)
TCAP Primitive ICB for a component
(none or multiple)*
Request
Indication
- Application Context Name (O)
- Application Context Name (O)
TCAP Primitive ICB 0x65 (M)
- User Information (O)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Quality of Service (O)
TCAP Primitive ICB for a component
(none or multiple)*
0x03 TC-END Primitive Set
Request
TCAP Primitive ICB 0x65 (M)
746
TCAP Primitive ICB 0x65 (M)
- User Information (O)
- Component Present (M)
SCCP Parameter ICB (O)
- Quality of Service (O)
TCAP Primitive ICB for a component
(none or multiple)*
Indication
TCAP Primitive ICB 0x65 (M)
Developer Information
- Application Context Name (O)
- Application Context Name (O)
- Termination Option (M)
- Component Present (M)
- User Information (O)
SCCP Parameter ICB (O)
- Quality of Service (O)
TCAP Primitive ICB for a component
(none or multiple)*
- User Information (O)
SCCP Parameter ICB (O)
- Quality of Service (O)
TCAP Primitive ICB for a component
(none or multiple)*
0x04 TC-UNI Primitive Set
This dialog primitive set requests/indicates an Unstructured dialog. It corresponds to
an Unidirectional TCAP package.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
TCAP Primitive ICB for a component
(none or multiple)*
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
TCAP Primitive ICB for a component
(none or multiple)*
ANSI TCAP Primitive Sets
Overview
The TCAP Primitive Set feature provides an interface to combine one TCAP dialog,
TC-Primitive, and its multiple associated components into one PPL Event Request or
PPL Event Indication. This section lists the ANSI TCAP Primitive Sets supported by
Excels SCCP/TCAP feature. Primitive Sets are sent to and received from the MSP
1010 in the PPL Event Request and PPL Event Indication messages in ICBs:


SS7 TCAP Primitives ICB (0x65)
SS7 TCAP Parameters ICB (0x21)
Important! The maximum number of ICBs for the TCAP primitive set is 16. If this
maximum is exceeded, the MSP 1010 sends negative acknowledgement
0x5401.
The TCAP ICBs always includes a dialog ID which is four bytes. The TCAP Primitive
ICB includes a four-byte dialog ID and a two-byte Event ID.
ANSI Primitives
747
MSP
The ANSI Primitive Sets are supported by both the PPL Event Request and PPL Event
Indication message unless noted otherwise.

TC-UNI Primitive Set

TC-QUERY-WITHOUT-PERMISSION Primitive Set




TC-QUERY-WITH-PERMISSION Primitive Set
TC-CONVERSATION-WITH-PERMISSION Primitive Set
TC-CONVERSATION-WITHOUT-PERMISSION Primitive Set
TC-RESPONSE Primitive Set
Needed Primitives
When using the Primitive Set interface you may also need the following primitives.

TC-U-ABORT (Request and Indication)

TC-NOTICE (Indication only)

TC-P-ABORT (Indication only)
ANSI TCAP TUSI PPL Events
The TCAP User Interface is responsible for host API message validation. This section
lists the PPL Events used to send ANSI TCAP primitives in the PPL Event Request and
PPL Event Indication messages.The required ICBs with mandatory (M) and optional
(O) parameters are shown with each primitive. See SCCP/TCAP Parameter
Information for the data required for each parameter.
The following events are used to send and receive ANSI primitives for the PPL
component, TCAP TUSI (0x70). The primitive IDs correspond to the PPL Event IDs
for this component. The ANSI specification does not define TCAP primitives to
TC_User. Where common primitives are used, Excel followed the ITU Q.771
definitions.
In the tables below you will see: TCAP Primitive ICB for a component (one or
more)*. This refers to the Primitive ID in the SS7 TCAP Primitive ICB 0x65. The
Primitive ID in this ICB has the same ID as the Event ID in the TCAP Primitive
Interface for the same component. The Primitive IDs used for the following TCAP
Primitive Sets are:

TC-RESULT-L 0x0C

TC-U-ERROR 0x0E







748
TC-RESULT-NL 0x0D
TC-INVOKE-L 0x10
TC-INVOKE-NL 0x11
TC-U-REJECT 0x12
TC-L-REJECT 0x13 (Indication only)
TC-R-REJECT 0x14 (Indication only)
TC-U-CANCEL 0x16 (Request only)
Developer Information
The Parameter TLV for a particular Primitive ID remains the same as if they were in
the TCAP Primitive Interface for the same Event ID.
0x04 TC-UNI Primitive Set
This dialog primitive set requests/indicates an Unstructured dialog. It corresponds to
an Unidirectional TCAP package. Note that the TCAP ICB always includes a dialog ID.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
TCAP Primitive ICB for a component
(one or more)*
0x07
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
TCAP Primitive ICB for a component
(one or more)*
TC-QUERY-WITH-PERMISSION Primitive Set
This dialog primitive set is similar to the ITU TC-BEGIN primitive. Under normal
circumstances, it will cause a TCAP Query with Permission package to be sent to the
network. An Indication indicates an incoming Query with Permission package, which
starts a dialog.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
TCAP Primitive ICB for a component
(one or more)*
0x08
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
TCAP Primitive ICB for a component
(one or more)*
TC-QUERY-WITHOUT-PERMISSION Primitive Set
This dialog primitive set is the same as the TC-QUERY-WITH-PERMISSION except
that it indicates to the peer that the transaction cannot be released. See the ANSI
specification for more information (this primitive corresponds to the Query Without
Permission package). This primitive starts a dialog.
749
MSP
Request
Indication
- No parameters included
- Component Present (M)
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (M)
- Quality of Service (O)
TCAP Primitive ICB for a component
(one or more)*
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA
Elements (M)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
TCAP Primitive ICB for a component
(one or more)*
0x09 TC-CONVERSATION-WITH-PERMISSION Primitive Set
This dialog primitive set is similar to the ITU TC-CONTINUE. It corresponds to the
TCAP Conversation package. It indicates the continuation of a dialog.
Request
Indication
- No parameters included
- Component Present (M)
- Calling Party Address (CGPA) or CGPA
Elements (O) 1
- Calling Party Address (CGPA) or CGPA
Elements (O) 2
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (O)
- Called Party Address (CDPA) or CDPA
Elements (O)1
- Quality of Service (O)
TCAP Primitive ICB for a component (one
or more)*
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (O)
- Called Party Address (CDPA) or CDPA
Elements (O) 2
- Quality of Service (O)
TCAP Primitive ICB for a component (one
or more)*
1 CGPA and CDPA are stored for the dialog when it is initialed. TC-USER provides
CGPA and CDPA only if they are changed.
2 CGPA and CDPA are sent to the host only if they differ from the stored values.
0x0A
TC-CONVERSATION-WITHOUT-PERMISSION Primitive Set
This primitive set is similar to the TC-CONVERSATION-WITH-PERMISSION, except
that the peer does not have permission. It corresponds to the ITU Conversation
Without Permission package. It is the continuation of a dialog.
Request
Indication
- No parameters included
- Component Present (M)
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (O)
750
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (O)
Developer Information
- Calling Party Address (CGPA) or CGPA
Elements (O) 1
- Calling Party Address (CGPA) or CGPA
Elements (O)2
- Quality of Service (O)
- Quality of Service (O)
- Called Party Address (CDPA) or CDPA
Elements (O)1
TCAP Primitive ICB for a component (one
or more)*
- Called Party Address (CDPA) or CDPA
Elements (O)2
TCAP Primitive ICB for a component (one
or more)*
1 CGPA and CDPA are stored for the dialog when it is initialed. TC-USER provides
CGPA and CDPA only if they are changed.
2 CGPA and CDPA are sent to the host only if they differ from the stored values.
0x0B
TC-RESPONSE Primitive Set
This dialog primitive set is similar to the ITU TC-END primitive. It corresponds to the
ITU Response package when the termination option is set to Basic End. When the
termination option is set to
Pre-arranged End, this primitive ends the dialog locally.
Request
Indication
- Termination Option
- Component Present (M)
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
TCAP Primitive ICB for a component
(one or more)*
TCAP Primitive ICB 0x65 (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Elements (O)
- Called Party Address (CDPA) or CDPA
Elements (O)
- Quality of Service (O)
TCAP Primitive ICB for a component
(one or more)*
SCCP/TCAP Parameter Information
Overview
This section contains information on SCCP and TCAP parameters inserted into the
SCCP and TCAP ICBs. Note special instructions for the parameters described below.
Description of Parameters
Called Party Address (CDPA)
The CDPA in the primitive request is used if specified. If DPC is not included in the
CDPA, the MTP DPC or adjacent translator must be provided.
The following sequence is used for deriving the DPC:
751
MSP


Use DPC in CDPA if provided; otherwise,
If CDPA routes on DPC/SSN, then use the MTP DPC in the primitive or in the
SSN default table. If CDPA routes on Global Title, then use the first adjacent
translator as the DPC.
Important! As an SSP, Global Title Translation (GTT) is not provided.
Calling Party Address (CGPA)
The CGPA in the primitive request is used if provided; otherwise,


If a TCAP primitive, the CGPA stored for this dialog is used.
If configured for this SSN, the CGPA in the SSN default table is used.
Component Present
This indicates whether or not components are present. If components are present,
then only syntactically valid and opportune components are delivered to the
destination TC-USER.
Dialog ID
This parameter appears in the dialog handling and component handling primitives. to
associate components with a dialog. The same dialog ID must be used within the
same dialog. In a Unidirectional primitive, the same dialog ID assures that all
components with the identical dialog ID are blocked together in the same
Unidirectional message destined for the same destination address.
For structured dialogs, the dialog ID is used to identify all components belonging to
the same dialog from the beginning of the dialog to its end. The dialog ID maps onto
the transaction IDs exchanged in the messages between a pair of nodes.
Error Code
Use the NATIONAL-ERR-CODE parameter type (0x47) if a national error code is
used, or the PRIVATE-ERR-CODE tag (0x48) if a private error code is used.
Last Component
Used in primitives of the Indication type to designate the last component of a
message. Note that indication of the last part of the result of an operation is via the
name of the primitive.
In the case of multiple components received within a TCAP message, a TCtransaction indication primitive followed by several TC-component indication
primitives are sent to the TC-USER. The Last Component parameter in the TCcomponent primitive specifies if this component is the last component in the
message.
This should not be confused with the Last/Not Last primitive type, which indicates
the last or not last part of an operation or result of an operation.
Operation
752
Developer Information
Use the GLOBAL-OPER-CODE parameter type (0x2C) if a national operation code is
used, or a LOCAL-OPER-CODE tag (0x2D) if a private operation code is used.
Parameter (ITU only)
Use the PARAMETER-SEQ parameter type (0x4A) to send a sequence of parameters
or the PARAMETER-SET tag (0x4B) to send a parameter set.
Problem Code (ITU only)
Use PROBLEM-TYPE-CODE parameter type.
Quality of Service
The QOS in the primitive request is used if specified, otherwise:


The QOS in the SSN default table is used if it is configured for the subsystem,
otherwise;
The following default configuration is used:
Return Option = Do Not Return on Error
Sequence Option = Sequence Not Guaranteed
Message Priority (ANSI)=0x00
Termination
Indicates which scenario is chosen by the TC-USER for the end of the dialog
(prearranged or basic).
Timeout (ITU only)
The timeout value is in 10 ms units.
ITU Parameter Information
This section contains information on ITU SCCP and TCAP parameters inserted into
the SCCP and TCAP ICBs.
ITU SCCP Parameter IDs
0x66
0x67
0x68
0x69
0x6A
CGPA (Calling Party
Address)
CGPA (Calling Party
Address) Element
CDPA (Called Party Address)
CDPA (Called Party Address)
Element
QOS (Quality of Service)
753
MSP
0x6B
User Data
0x6D
Return Reason
0x6C
0x6E
0x6F
0x70
0x71
0x72
0x73
0x74
CDPA (Called Party Address)
DPC
SSN (Subsystem Number)
SPC (Signaling Point Code)
SSN (Subsystem Number)
Status
SCCP Signaling Point Code
Status
Remote SCCP Status
MTP OPC
MTP DPC
ITU TCAP Parameter IDs
0x0F
Abort Reason
0x1F
Invoke ID
0x11
0x20
0x28
0x29
0x2A
0x2E
0x2C
0x2D
0x30
0x37
0x38
0x39
0x3A
0x43
0x44
754
P-Abort Cause
Link ID
Invoke Class
Invoke Timeout
Problem Type Code
Parameter
Global Operation
Code
Local Operation
Code
Last Component
Protocol Version
Application Context
Name
User Info
Termination Option
Dialog_AS_ID
Unidialog_AS_ID
Developer Information
0x45
Component Present
0x48
Local Error Code
0x47
0x6D
Global Error Code
Return Reason
ANSI Parameter Information
This section contains information on ANSI SCCP and TCAP parameters inserted into
the SCCP and TCAP ICBs.
ANSI SCCP Parameter IDs
0x66
CGPA (Calling Party Address)
0x68
CDPA (Called Party Address)
0x67
0x69
0x6A
0x6B
0x6C
0x6D
0x6E
0x6F
0x70
0x71
0x73
0x74
CGPA (Calling Party Address)
Element
CDPA (Called Party Address)
Element
QOS (Quality of Service)
User Data
CDPA (Called Party Address)
DPC
Return Reason
SSN (Subsystem Number)
SPC (Signaling Point Code)
SSN (Subsystem Number)
Status
SPC (Signaling Point Code)
Status
MTP OPC
MTP DPC
ANSI TCAP Parameter IDs
0x0F
User Abort Info
0x1F
Invoke ID
0x11P
Abort Cause
755
MSP
0x20
Correlation ID
0x2C
National
Operation Code
0x2A
0x2D
0x30
0x3A
0x45
0x47
0x48
0x4A
0x4B
0x6D
Problem Type
Code
Local Operation
Code
Last Component
Termination
Option
Component
Present
National Error
Code
Private Error
Code
Parameter
Sequence
Parameter Set
Return Reason
Parameter Format
The following table illustrates the parameter format for parameters inserted into the
SCCP and TCAP ICBs.
Byte
Data[0]
Data[1]
Field
Parameter 1 ID
Data[2]
Parameter Length
Data[4+]
Parameter-specific
Fields
Data[3]
Parameter Data
This section shows the specific data for each parameter.
Abort Reason
756
Developer Information
Byte
Data[4]
Reason
Value(s)
0x00 = User-defined
0x01 = Application Context Name Not
Supported (ITU Only)
0x02 - Dialog Refused
Calling Party Address (CGPA)
Byte
Data[4+] Calling Party
Address
Value(s)
Conforms to ANSI or ITU
specification.
Calling Party Address (CGPA) Element
Byte
Data[4] Routing Indication
Data[5]
National/International Flag
Data[6]
Data[710]
Data[11]
Data[12]
:
Value(s)
0x00 = Route on GT
0x01 = Route on DPC/SSN
0x00 = Coded International
0x01 = Coded National
0x02 = Coded according to China
Specification (same as International
except the point codes are 24 bits)
Subsystem Number
Point Code
Global Title Indicator
Global Title Length Variable
Data[N] Global Title
Note:
1. Subsystem Number is 0x00 if unknown or not provided.
2. The Point Code is 0xFFFFFFFF if unknown or not provided.
3. The Calling Party Address is constructed with the elements provided and
converted to ANSI or ITU format according to the appropriate specification.
4. The National/International flag applies only to indication. In a request, SCCP
codes the CGPA according to the SCCP SCLC Component SCLC Configuration
Byte 1.
5. Global Title Indicator in Data[11] corresponds to the Global Title Indicator in
the SCCP message CGPA.
757
MSP
Called Party Address (CDPA) Element
Byte
Data[4] Routing Indication
Data[5] National/International
Flag
Data[6] Subsystem Number
Value(s)
0x00 = Route on GT
0x01 = Route on DPC/SSN
0x00 = Coded International
0x01 = Coded National
0x02 = Coded according to China
Specification (same as International except
the point codes are 24 bits)
Data[710] Point Code
Data[11] Global Title Indicator
Data[12] Global Title Length
(Variable)
:
Data[N] Global Title
:
Note
1. Subsystem Number is 0x00 if unknown or not provided.
2. The Point Code is 0xFFFFFFFF if unknown or not provided.
3. The Called Party Address is constructed with the elements provided and
converted to ANSI or ITU format according to the appropriate specification.
4. The National/International flag applies only to indication. In a request, SCCP
codes the CDPA according to the SCCP PPL SCLC Component Config Byte 1.
5. Global Title Indicator in Data[11] corresponds to the Global Title Indicator of
the SCCP message CDPA.
Class
Byte
Data[4]
Value(s)
Class Class
Number (14)
Component Present
Byte
Data[4]
Value(s)
0x00 Not
Present
0x01
Present
758
Developer Information
Dialog_AS_ID
The values for the Dialog_AS_ID parameter are automatically stored in the MSP
1010, consistent with ITU TCAP specifications. They cannot be modified by the host if
you use the ITU White Book.
Byte
Value(s)
Data[4]
Status
0x01 = Signaling Point
Inaccessible
0x02 = SPC Congested
0x03 = SPC Accessible
Error Code
Byte
Data[4]
Value(s)
Code Global or Local
Error Code
Last Component
Byte
Data[4]
Value(s)
0x00 Last
Component
0x01 Not Last
Component
Operation
Byte
Data[4]
Code
Value(s)
Global or Local Operation
Code
P Abort Cause (ITU)
Byte
Data[4]
Cause
Value(s)
0x00 = Unrecognized Message Type
0x01 = Unrecognized Transaction ID
0x02 = Badly Formatted Transaction
Portion
0x03 = Incorrect Transaction
Portion
0x04 = Resource Limitation
759
MSP
0x05 = Abnormal dialog
0x06 = No Common dialog Portion
P Abort Cause (ANSI)
Byte
Value(s)
Data[4] Cause
0x01 = Unrecognized Package Type
0x02 = Incorrect Transaction Portion
0x03 = Badly Structured Transaction
Portion
0x04 = Unrecognized Transaction ID
0x05 = Permission to Release Problem
0x06 = Resource Unavailable
0x07 = Unrecognized Dialog Portion ID
0x08 = Bad Structured Dialog Portion
0x09 = Missing Dialog Portion
0x0A = Inconsistent Dialog Portion
Problem Type Code (ITU)
Byte
Data[4] Problem
Value(s)
Type 0x01 = General
0x02 = Invoke
0x03 = Return Result
Data[5] Problem Code
General
0x04 = Return Error
0x00 = Unrecognized Component
0x01 = Mis-typed Component
0x02 = Badly Structured Component
Invoke
0x00 = Duplicate Invoke ID
0x01 = Unrecognized Operation
0x02 = Mis-typed Parameter
0x03 = Resource Limitation
0x04 = Initiating Release
0x05 = Unrecognized Link ID
0x06 = Linked Response Unexpected
0x07 = Unexpected Linked Operation
760
Developer Information
Return Result
0x00 = Unrecognized Invoke ID
0x01 = Return Result Unexpected
0x02 = Mis-typed Parameter Return
Error
0x00 = Unrecognized Invoke ID
0x01 = Return Error Unexpected
0x02 = Unrecognized Error
0x03 = Unexpected Error
0x04 = Mis-typed Parameter
Problem Type Code (ANSI)
Byte
Data[4] Problem
Type
Value(s)
0x01=General
0x02=Invoke
0x03=Return Result
0x04=Return Error
Data[5] Problem
Code
0x05=Transaction Portion
All Types
0x00=Not Used
0xFF=Reserved
General
0x01=Unrecognized Component Type
0x02=Incorrect Component Portion
0x03=Badly Structured Component Portion
Invoke
0x01=Duplicate Invoke ID
0x02=Unrecognized Operation Code
0x03- Incorrect Parameter
0x04=Unrecognized Correlation ID
0x0F=Resource Unavailable
Return Result
0x01=Unrecognized Correlation ID
0x02=Unexpected Return Result
0x03=Incorrect Parameter
761
MSP
Return Error
0x01=Unrecognized Correlation ID
0x02=Incorrect Return Error
0x03=Unrecognized Error
0x04=Unexpected Error
0x05=Incorrect Parameter
Transaction Portion
0x01=Unrecognized Package Type
0x02=Incorrect Transaction Portion
0x03=Badly Structured Transaction Portion
0x04=Unrecognized Transaction ID
0x05=Permission to Release
0x06=Resource Unavailable
Protocol Version
The values for the Protocol Version parameter are automatically stored, consistent
with ITU TCAP specifications. They cannot be modified by the host if you use the ITU
White Book.
Quality of Service (QOS)
Byte
Data[4] Return Option
Data[5]
Data[6] Message Priority*
Value(s)
0x00=Discard on Error
0x01=Return on Error
Sequence Control Parameter
0x00=Sequence not Guaranteed
For other than zero, this value is used
for sequence control.**
(ANSI Only)
*Refer to ANSI MTP Specification T1-111.5 for the information on selecting message
priority.
**For the outgoing messages, the sequence is guaranteed for the messages with the
same sequence control value. They will reach the destination in the same order as
they were sent out. For the incoming messages, this value simply means the
sequence is guaranteed (SCCP class 1 services are used in this case).
Remote SCCP Status
Byte
762
Value(s)
Developer Information
Data[4] Status
0x01=Remote SCCP Available
0x02=Remote SCCP Unavailable
(Reason Unknown)
0x03=Remote SCCP Unequipped
0x04=Remote SCCP Inaccessible
Return Reason (ITU)
Byte
Data[4] Cause
Value(s)
0x00 No Translation for an Address of
Such Nature
0x01 No Translation for this Specific
Address
0x02=Subsystem Congestion
0x03=Subsystem Failure
0x04=Unequipped User
0x05=MTP Failure
0x06=Network Congestion
0x07=Unqualified
0x08=Error in Message Transport *
0x09=Error in Local Processing *
0x0A=Destination Cannot Perform
Reassembly *
0x0B=SCCP Failure
*Only applicable to XUDTS message.
Return Reason (ANSI)
Byte
Data[4]
Cause
Value(s)
0x00 No Translation for an Address of Such Nature
0x01 No Translation for this Specific Address
0x02=Subsystem Congestion
0x03=Subsystem Failure
0x04=Unequipped User
0x05=MTP Failure
0x06=Network Congestion
0x07=Unqualified
0x08=Error in Message Transport *
763
MSP
0x09=Error in Local Processing *
0x0A=Destination Cannot Perform Reassembly *
0x0B=Not Used
0x0C=SCCP Hop Counter Violation *
0x0D F8=Not Used
0xF9=Invalid ISNI Routing Request *
0xFA=Unauthorized Message
0xFB=Message Incompatibility
0xFC=Cannot Perform ISNI Constrained Routing *
0xFD=Redundant ISNI Constrained Routing
Information *
0xFE=Unable to Perform ISNI Identification *
0xFF=Not Used
*=Only applicable to XUDT and XUDTS messages.
SCCP Signaling Point Status
Byte
Data[4]
Status
Value(s)
0x01=SCCP DPC Prohibited
0x02=SCCP DPC Congested
0x03=SCCP DPC Allowed
Subsystem Status
Byte
Data[4]
Status
Value(s)
0x00=Prohibit
0x01=Allow
Termination Option
Byte
Data[4] Option
Value(s)
0x01=Pre-arranged
End
0x02=Basic End
Unidialog_AS_ID
The values for the Unidialog_AS_ID parameter are automatically stored, consistent
with ITU TCAP specifications. They should not be modified by the host if you use the
ITU White Book.
764
Developer Information
ITU and ANSI SCCP Connection Oriented (CO) Parameter Information
This section shows the specific IDs and data for each SCCP CO parameter.
ITU and ANSI SCCP CO Parameter IDs
0x7A
Importance
0x7C
Reason
0x7B
0x7E
Originator
Subsystem Multiplicity
Indictor
ITU and ANSI SCCP CO Parameter Data
Importance
Byte
Data[4]
Importance
Originator
Byte
Data[4]
Originator
Value(s)
As defined by ITU Q.711714, 1996
Value(s)
0x00 Undefined
0x01 Network service user originated
0x02 Network service provider
originated
Reason
Byte
Data[4]
Reason
Value(s)
As detailed in Table C1, C2, and C3
112.3 (ANSI)
As detailed in Table A1, A2, and A3
Q.713 (ITU,1996)
Subsystem Multiplicity Indicator
765
MSP
Byte
Data[4]
Mutiplicity
Indicator
Value(s)
0x00 Affected subsystem multiplicity
unknown
0x01 Affected subsystem is solitary
0x02 Affected subsystem is duplicated
User-Defined Parameters

Application Context Name

Correlation ID











MTP DPC
Invoke ID
Linked ID
Parameters
Parameter Sequence
Parameter Set
Signaling Point Code (SPC)
Subsystem Number
Timeout
User Data
User Information
SCCP Segmentation
Overview
SCCP segmentation provides the capability of breaking down larger packets of data
into smaller ones in order to achieve compatibility with any network protocol that
requires the smaller packet size. This is necessary whenever large blocks of data
need to be transmitted across a network Segmenting the data helps offset problems
with both time delays and error correction that could lead to traffic congestion.
Segmentation in this way conserves critical network resources.
Specifically, the process of SCCP Segmentation gives an SCCP-user the ability to
configure and send user data without having to perform any segmentation at the
user level. SCCP handles all segmentation requirements.
Size of Packetized Data
The size of data sent to the host is currently limited by the ICB length. The ICB
length is a maximum of 255 bytes in API messages. Connectionless transfer of data
using SCCP requires the use of unitdata and the extended unitdata structures. These
message structures provide all the information necessary for data to be transferred
766
Developer Information
to a remote entity and to be processed by that remote entity. The segmentation
parameter is included with these messages in an SCCP connectionless service:


Extended UnitData (XUDT, (maximum of 16)
Extended UnitData Service (XUDTS)
For an SCCP user resident in the host, the size of the total data sent between the
SS7 functionality and the host will be limited by the maximum length of the ICB,
which is 255 bytes, until the system level segmentation has been implemented.
No segmentation occurs at the user level; therefore, an SCCP user is able to send up
to 2048 bytes of data for ITU protocol and up to 3092 bytes of user data for the
ANSI protocol.
Related Specifications


ITU-T Q.711 - Q.714: Signaling Connection Control Part, White Book
ANSI T1.112 - 1996
Managing User Data in SCCP
Data sent by an SCCP user can be limited by the constraints inherent in the MTP
layer, that is, the maximum length of the Message Signal Unit (MSU). Through
segmentation, the user is able to transmit through MTP efficiently because the data
is segmented into manageable units called XUDT messages. When SCCP receives the
XUDT messages, it reassembles all data into an N_UNITDATA primitive and forwards
that to the SCCP user/receiver.
SCLC, SCRC and SUSI Modules
It is the SCCP SCLC module that segments the N_UNITDATA primitive into XUDT
messages and which also performs the reassembly of data. The SCRC module
performs the routing of these connectionless messages. The SCCP SUSI module
receives the reassembled message and sends a larger UNITDATA PPL Event
Indication to the SCCP user (whether on the MSP 1010 or resident on the host).
Error Conditions
If the SCCP cannot process the XUDT message because an error condition has
occurred on the network, and the return option is set, then it gets an XUDTS
message and forwards notification of the error to the SCCP user at the sending end
using an N_ NOTICE primitive. (See the ITU-T Q.711 - Q.714: Signaling Connection
Control Part, White Book and ANSI T1.112 - 1996).
Configuration
Configuration bytes for the TCAP module in the PPL Configure message must be set
for each component ID. With SCCP Segmentation implemented, these config bytes
allow the TCAP layer to send larger blocks of data to the SCCP layer if desired. SCCP
can send or receive messages directly with the host or through the TCAP layer. The
configuration bytes are discussed further in the SS7 PPL Information chapter, and
include the following:
767
MSP

SCCP Component SCLC--Bytes 22 and 26 (a 4-byte value)

TCAP Component CCO--Bytes 1 and 2


SCCP Component SUSI--Byte 20
TCAP Component TUSI--Bytes 4 and 5
Limitations
SS7 Segmentation allows a maximum number of 300 reassembly processes
simultaneously.
Redundancy
SCCP software is redundant.
TCAP Parameter IDs
Any TCAP parameter which is marked internal use indicates that there is NO TCAP
identifier/tag corresponding to it. It is either part of the API parameters or used by
PPL only.
0x00
Reserved
0x02
TCAP Unidirectional message
0x01
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0A
0x0B
0x0C
0x0D
0x0E
0x0F
0x10
768
TCAP Package/message/" internal use "/
TCAP Begin message
TCAP Continue message
TCAP End message
TCAP Query with permission package
TCAP Query without permission package
TCAP Conversation with permission
package
TCAP Conversation without permission
package
TCAP Response package
TCAP Abort package
TCAP Transaction ID (ANSI)
TCAP Originating transaction ID(ITU)
TCAP Destination transaction ID(ITU)
TCAP Abort reason(ITU) / TCAP user
abort info(ANSI)
TCAP Abort cause(ANSI) /" internal use
"/
Developer Information
0x11
TCAP P abort cause
0x13
TCAP Component portion
0x12
0x14
0x15
0x16
0x17
0x18
0x19
0x1A
0x1B
0x1C
0x1D
0x1E
0x1F
0x20
0x21
0x22
0x23
0x24
0x25
0x26
0x27
0x28
0x29
0x2A
0x2B
0x2C
0x2D
0x2E
0x2F
0x30
Not used
TCAP Component /" internal use "/
TCAP INVOKE Component
TCAP INVOKE Last component
TCAP INVOKE Not Last component
TCAP RESULT Last component
TCAP RESULT Not Last component
TCAP RETURN ERROR Component
TCAP REJECT Component
TCAP Component ID(ANSI)
Not used
TCAP Component type /" internal use "/
TCAP Invoke ID
TCAP Link ID(ITU) / correlatio