msp 1010 printed documentation - dialogic
TRANSCRIPT
Multi-Services Platform 1010 Release 10.2.1 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:
iii
Table Of Contents Multi-Services Platform Overview .......................................................................1
Introduction to the Multi-Services Platform (MSP) 1010......................................1
Overview ...................................................................................................1
Applications ...............................................................................................1
Supported Protocols....................................................................................1
Hardware Overview .......................................................................................4
1u Signaling Server ....................................................................................4
SS7 Capacity ................................................................................................5
SS7 Monitoring .............................................................................................6
Overview ...................................................................................................6
Licensing ...................................................................................................6
DS3 .............................................................................................................7
DS3 Technology .........................................................................................7
DS3 in the MSP ..........................................................................................7
DSP Media Module .........................................................................................8
Introduction...............................................................................................8
Benefits.....................................................................................................8
VoIP ............................................................................................................9
Introduction to the NG API ...........................................................................10
Overview .................................................................................................10
Portable ..................................................................................................10
Streamlined .............................................................................................10
Versatile..................................................................................................10
Logical ....................................................................................................10
Configurations.............................................................................................11
Overview .................................................................................................11
Stand alone .............................................................................................11
Redundant...............................................................................................11
Highlights of the ClientView ..........................................................................14
Features ..................................................................................................14
ClientView Functionality Defined .................................................................14
DataManager ...........................................................................................14
AdminManager .........................................................................................15
Licensing....................................................................................................16
MSP
iv
Hardware Installation & Maintenance................................................................17
Overview....................................................................................................17
Installation .................................................................................................18
Pre-Installation Considerations ...................................................................18
Unpacking ...............................................................................................22
Rack Mounting .........................................................................................23
Surface Mounting .....................................................................................25
Ground Connections..................................................................................26
AC Power Connections...............................................................................28
DC Power Connections ..............................................................................30
Power and Fan Control ..............................................................................34
Rear Panel I/O Connectors.........................................................................35
I/O Interconnections .................................................................................38
Operation ...................................................................................................41
Operation Overview ..................................................................................41
Front Panel Controls and Indicators.............................................................42
LCD Display .............................................................................................45
Maintenance ...............................................................................................56
Troubleshooting........................................................................................56
Hardware Alarm Module ............................................................................60
Tray Removal and Replacement..................................................................62
Installing a VoIP or Media Module..................................................................64
Hardware Installation................................................................................64
Diagram - Removing Motherboard Tray .......................................................65
Diagram - Module Positions.......................................................................66
Industry Compliance....................................................................................67
FCC Regulatory Compliance Notices ............................................................67
Declaration of Conformity ..........................................................................70
MSP Hardware Product Description ...................................................................73
Overview....................................................................................................73
Physical Configuration..................................................................................74
Tray........................................................................................................74
Docking Station........................................................................................74
Features.....................................................................................................75
General ...................................................................................................75
CPU ........................................................................................................75
Table Of Contents
v
Input Power .............................................................................................75
Front Panel ..............................................................................................75
Rear I/O Panel .........................................................................................75
Redundancy.............................................................................................75
Configuration Information.............................................................................76
Specifications..............................................................................................77
Compliance.................................................................................................79
Rear Panel I/O Card Signal and Timing Connectors ..........................................80
CTRL 0, CTRL 1 - 10/100 (Ethernet Control Connectors)................................80
DATA 0, DATA 1 - 10/100/1000 (Ethernet Data Connectors) ..........................80
SIG 0, SIG 1 - 10/100 (Ethernet Signaling Connectors).................................80
SIGNAL/TIMING - 0, 1, 2, 3 .......................................................................80
(T1/E1 Signaling and Timing Span Connectors) ............................................80
REDUNDANCY (1+1 Bearer Redundancy Connector) .....................................80
BEARER 0 - 27 (T1/E1 Bearer Span Connectors)...........................................80
Rear Panel AC and DC Input Power Modules ...................................................82
AC Power Module......................................................................................82
DC Power Module......................................................................................82
Front Panel .................................................................................................83
Power, Alarm and Status LEDs ......................................................................84
POWER....................................................................................................84
ALARM ....................................................................................................84
SIG/TIMING.............................................................................................84
TIMING ...................................................................................................84
ENET CTRL...............................................................................................84
ENET DATA ..............................................................................................84
ENET SIG ................................................................................................84
AUX ........................................................................................................84
SPAN STATUS ..........................................................................................84
LCD Display ................................................................................................86
LCD Menus .................................................................................................87
LCD Pushbutton Switches .............................................................................88
Hard Reset...............................................................................................88
Soft Reset................................................................................................88
ClientView .....................................................................................................89
Conventions Used in ClientView Documentation ..............................................89
MSP
vi
Accessing this Pane...................................................................................89
An Overview of ClientView ............................................................................90
Main Window ...........................................................................................90
Panes......................................................................................................91
System Requirements for ClientView..............................................................92
Windows Requirements .............................................................................92
Linux Requirements ..................................................................................92
Solaris Requirements ................................................................................92
HP-UX Requirements.................................................................................92
Installation Process......................................................................................93
Before You Begin ......................................................................................93
Steps ......................................................................................................93
Windows Defaults File ...............................................................................93
UNIX Defaults File.....................................................................................94
Installing ClientView and EventView...............................................................95
On Windows.............................................................................................95
On UNIX..................................................................................................95
./MSPUserInterface.bin ................................................................................95
Open ClientView..........................................................................................96
Opening Multiple Instances of ClientView........................................................98
Using Configuration Files ..............................................................................99
Creating a Configuration File ......................................................................99
Opening a Saved File ................................................................................99
MSP Licensing ........................................................................................... 100
Accessing this Pane................................................................................. 100
Default Location of License ...................................................................... 100
ClientView Pane...................................................................................... 100
Creating a Configuration for the First Time ................................................... 102
Steps .................................................................................................... 102
Downloading a License for Upgraded Capabilities........................................... 104
Steps .................................................................................................... 104
Verifying a license After Failure in ClientView ................................................ 105
ClientView Indicators ................................................................................. 106
Configuration Fields ................................................................................ 106
Progress Indicator .................................................................................. 106
Mandatory fields..................................................................................... 107
Table Of Contents
vii
Icons in Left Pane ................................................................................... 107
ClientView Menus ...................................................................................... 109
Options Available in Node Configuration ....................................................... 112
Validation Report .................................................................................... 112
Help...................................................................................................... 112
Reset Node ............................................................................................ 112
Clear Software ....................................................................................... 112
Download Raw File.................................................................................. 112
Resetting an MSP 1010 .............................................................................. 114
Importing and Exporting a Signaling Variant ................................................. 115
For Importing......................................................................................... 115
For Exporting ......................................................................................... 115
Upgrading ClientView................................................................................. 116
Report Files ........................................................................................... 117
File Changes/Actions............................................................................... 117
Configuration File Missing Mandatory Value................................................ 118
Common Example Configurations ................................................................ 119
Example Configuration for DS3 Spans ....................................................... 119
Example Configuration for SS7 Voice Circuits ............................................. 121
Example Configuration for SS7 Redundancy ............................................... 122
Example Configuration for SS7 Monitoring ................................................. 123
Example Configuration for Media Resources ............................................... 124
Example Configuration for SCCP/TCAP....................................................... 125
Configuring VoIP Modules ........................................................................ 126
Example Configuration for ISDN ............................................................... 127
Alphabetical List of Configurable MSP 1010 Objects ....................................... 128
Adjacent Translator................................................................................. 128
BERT Test.............................................................................................. 129
Circuit Group.......................................................................................... 132
Conference Parameters ........................................................................... 135
Channel Configuration Groups .................................................................. 136
DS3 Physical Span .................................................................................. 137
E1 Physical Span .................................................................................... 140
Echo Cancel Parameters .......................................................................... 143
Cantata MSP EMS ................................................................................... 144
Facility .................................................................................................. 145
MSP
viii
Filter Rules ............................................................................................ 147
Global Title Entry.................................................................................... 148
Global Title Group................................................................................... 149
Global Title Translation............................................................................ 150
IP Bearer Profile ..................................................................................... 151
IP Bearer Profiles.................................................................................... 157
ISDN D Channels.................................................................................... 158
Congestion Threshold.............................................................................. 159
ISDN Circuits: B Channels ....................................................................... 160
ISDN D Channel ..................................................................................... 161
D Channel Entity .................................................................................... 164
ISDN Group ........................................................................................... 166
ISDN Timers .......................................................................................... 171
ISUP Group............................................................................................ 172
License Information ................................................................................ 174
Link Configuration .................................................................................. 176
Node Group ........................................................................................... 177
Logical Spans......................................................................................... 178
Media DSP ............................................................................................. 179
Media Module......................................................................................... 181
Media.................................................................................................... 182
Monitoring Object ................................................................................... 183
Monitor Application ................................................................................. 184
Monitoring Application Map ...................................................................... 185
Link ...................................................................................................... 186
Links..................................................................................................... 187
Point Code ............................................................................................. 188
Additional Applications ............................................................................ 189
Service Indicator .................................................................................... 190
Multi-Host Socket ................................................................................... 191
Network DPC and SSN............................................................................. 192
Network Indicator ................................................................................... 193
Network Interface................................................................................... 194
Network Interfaces ................................................................................. 196
NFS Servers........................................................................................... 197
Node Object........................................................................................... 198
Table Of Contents
ix
NFS Server ............................................................................................ 200
Other Concerned Point Codes ................................................................... 202
Physical MSP.......................................................................................... 203
PVD and AMD Parameters........................................................................ 205
Raw API Command ................................................................................. 206
Raw API Commands................................................................................ 207
Configuring a Range of Signaling Spans..................................................... 208
Remote User Part ................................................................................... 209
Replicated SSN....................................................................................... 210
Routing Configuration ............................................................................. 211
SCCP/TCAP ............................................................................................ 212
SCCP-TCAP Default Parameter Table ......................................................... 214
Signaling Object ..................................................................................... 215
Configuring a Range of Signaling Spans..................................................... 216
Signaling Variant .................................................................................... 217
Signaling Variants Object......................................................................... 219
Multi-Host Socket ................................................................................... 220
SS7 ...................................................................................................... 221
SS7 CIC ................................................................................................ 224
SS7 Link................................................................................................ 225
SS7 Link Set .......................................................................................... 228
SS7 Route ............................................................................................. 229
SS7 Stack.............................................................................................. 231
SSN ...................................................................................................... 234
Sub-system Number Default Parameter..................................................... 236
T.30 Parameters..................................................................................... 237
TCAP Object Syntax Descriptor................................................................. 238
T1 Physical Span .................................................................................... 239
TDM-DS1............................................................................................... 242
TDM DS3 ............................................................................................... 243
Telnet Client .......................................................................................... 245
Timing Synchronization Priority List .......................................................... 246
Variant Entry ......................................................................................... 249
Vocabulary Index Entry ........................................................................... 251
Vocabulary Index File.............................................................................. 253
Vocabulary Index Files ............................................................................ 254
MSP
x
VoIP Module........................................................................................... 255
EventView ................................................................................................... 259
Introduction to EventView .......................................................................... 259
EventView Main Window .......................................................................... 259
Getting Help in EventView........................................................................ 259
Exporting Alarms to a Text File.................................................................... 260
Filtering Alarm Views ................................................................................. 261
Sorting Alarm Fields................................................................................ 261
Forcing a Log File to Roll-over ..................................................................... 262
AdminView .................................................................................................. 263
An Overview of AdminView ......................................................................... 263
User Management Access ........................................................................ 263
ClientView Access ................................................................................... 263
Default Administrator Information............................................................. 264
Linux Users............................................................................................ 264
ClientView Log In.................................................................................... 264
Admin Commands .................................................................................. 264
Re-installation of Software....................................................................... 264
Assigning Users in AdminView..................................................................... 265
Procedure .............................................................................................. 265
User (name) is added successfully. .............................................................. 266
Administering User Privileges ...................................................................... 267
Before You Begin .................................................................................... 267
Start AdminManager ............................................................................... 267
Start AdminView..................................................................................... 267
Admin Tasks .......................................................................................... 267
Changing the Admin Password ................................................................. 267
Adding a User ........................................................................................ 268
Changing a Password .............................................................................. 268
Changing a User's Roles .......................................................................... 268
Resetting Your Own Password .................................................................. 268
Removing a User .................................................................................... 268
Viewing User Information ........................................................................... 270
Displaying all User Information................................................................. 270
Display a Specific User's Information......................................................... 270
Displaying Your Own Information.............................................................. 270
Table Of Contents
xi
List All Commands .................................................................................. 271
Displaying Help ...................................................................................... 271
Starting AdminManager on an Alternate RMI port .......................................... 272
Windows................................................................................................ 272
UNIX..................................................................................................... 273
Intelligent Network & Wireless Protocols Overview ........................................... 275
Introduction.............................................................................................. 275
IN and Wireless Protocols ........................................................................ 275
SwitchKit IN and Wireless Components ..................................................... 276
SwitchKit Users ...................................................................................... 276
Excel API Users ...................................................................................... 277
Codecs .................................................................................................. 278
Performance & Reliability......................................................................... 278
Supported Operating Environments and Compatibility .................................... 279
Compatibility.......................................................................................... 279
Benefits of using SwitchKit to develop an IN/Wireless Application .................... 280
Application Development ......................................................................... 280
SwitchKit API ......................................................................................... 280
The Role of LLC ...................................................................................... 280
OAM&P.................................................................................................. 280
Intelligent Network and Wireless Protocols.................................................... 281
Matrix ................................................................................................... 281
CAMEL .................................................................................................. 281
UMTS/GSM-MAP ..................................................................................... 281
WIN ...................................................................................................... 282
ANSI - 41 .............................................................................................. 282
Future availability of AIN protocol ............................................................. 283
Licensing of Intelligent Network and Wireless Protocols .................................. 284
Upgrades............................................................................................... 284
Pricing................................................................................................... 284
SwitchKit Intelligent Network and Wireless Components................................. 285
SwitchKit TCAP Abstraction Layer ............................................................. 285
SKTAL APIs............................................................................................ 285
SwitchKit Interface Module ...................................................................... 286
SKIM APIs ............................................................................................. 286
Wireless Call Flow...................................................................................... 288
MSP
xii
Purpose................................................................................................. 288
SwitchKit Installation & Maintenance .............................................................. 289
Introduction.............................................................................................. 289
SwitchKit ............................................................................................... 289
SwitchKit Features and Components ......................................................... 291
LLC - The Low-Level Communicator .......................................................... 293
The SwitchManager................................................................................. 294
SwitchKit Application Programming Interface ............................................. 295
Highlights of the ClientView ..................................................................... 296
Installation ............................................................................................... 298
SwitchKit Supported Operating Environments............................................. 298
Downloading Or Upgrading System Software ............................................. 300
SwitchKit Software Licensing.................................................................... 301
Installing SwitchKit on UNIX .................................................................... 302
Installing Profiles on UNIX Hosts............................................................... 304
Installing SwitchKit on Windows ............................................................... 306
Running SwitchKit Components Automatically at Startup ............................. 308
SwitchKit Tray Icons ............................................................................... 310
Configuring SwitchKit to Run from the Start Menu on Windows .................... 312
Environment Variables Modify SwitchKit Default Behavior ............................ 313
List of Environment Variables ................................................................... 315
Setting Environment Variables on Windows 2000........................................ 331
Setting Environment Variables on Windows XP ........................................... 332
Running SwitchKit Components and Companion Products ............................... 333
Running SwitchKit Components and Companion Products ............................ 333
System Start-up Behavior........................................................................ 334
Running the LLC in Windows .................................................................... 335
LLC Arguments....................................................................................... 336
Basics of SwitchManager ......................................................................... 338
Running SwitchManager .......................................................................... 339
SwitchManager Arguments....................................................................... 341
Running DataManager ............................................................................ 343
Running AdminManager........................................................................... 345
Redundancy Setup..................................................................................... 347
SwitchKit Redundancy............................................................................. 347
Running Redundant LLCs ......................................................................... 349
Table Of Contents
xiii
Failure Scenarios Resolved with Redundancy.............................................. 351
Logging.................................................................................................... 354
Log File Management .............................................................................. 354
Log Files................................................................................................ 356
Server Status Change ................................................................................ 360
Server Status Change Feature.................................................................. 360
ServerStatusChange ............................................................................... 361
SwitchKit Programmer's Information............................................................... 367
Addressing Functions ................................................................................. 367
AIB Manipulation Functions ...................................................................... 368
SS7 Addressing Functions........................................................................ 373
Connection Management Functions.............................................................. 377
Applications Connecting to Multiple LLCs.................................................... 377
Applications Connecting to One LLC .......................................................... 378
Connecting Legacy Applications to Multiple LLCs ......................................... 379
Introduction to Connection Management.................................................... 380
List of SwitchKit APIs .............................................................................. 381
sk_closeNamedConnection() .................................................................... 384
sk_createConnection() ............................................................................ 385
sk_createConnectionWithID()................................................................... 387
sk_destroyConnection()........................................................................... 389
sk_destroyConnectionForced() ................................................................. 390
sk_getConnectionForID()......................................................................... 391
sk_getConnectionName() ........................................................................ 392
sk_getConnectionNameForConnection() .................................................... 393
sk_getCurrentConnection() ...................................................................... 394
sk_getLLCSocketDescriptor() ................................................................... 395
sk_getLLCSocketDescriptorForConnection() ............................................... 396
sk_getSpecificConnectionLabel()............................................................... 397
sk_getSpecificConnectionName().............................................................. 398
sk_initializeConnection() / sk_initializeForcedConnection()........................... 399
sk_*OnConnection() ............................................................................... 400
sk_setCurrentConnection() ...................................................................... 402
Device Connectivity Functions ..................................................................... 403
Add LLC Node Feature............................................................................. 403
AddLLCNode .......................................................................................... 405
MSP
xiv
LLC: Application Load Balancing for TCAP .................................................. 408
SS7 SCCP/TCAP Configure 0x0077............................................................ 411
TCAPMessageRegister ............................................................................. 419
TCAP Routing Feature ............................................................................. 421
Handler Functions...................................................................................... 423
Handler Functions................................................................................... 423
Logging Functions...................................................................................... 447
Logging Functions................................................................................... 447
Message Functions..................................................................................... 452
Base Classes .......................................................................................... 452
Instantiating a Large SwitchKit Message.................................................... 455
Message Class Macros ............................................................................. 456
Message Functions.................................................................................. 458
Message Headers in C ............................................................................. 459
Message Macros for C Programmers.......................................................... 461
Message Structure Macros ....................................................................... 465
Messages in C++.................................................................................... 468
sk_packAutoStorage()............................................................................. 469
sk_packMessage() .................................................................................. 470
Redundancy.............................................................................................. 485
LLC and Application Redundancy .............................................................. 489
API Messages used for Redundancy .......................................................... 492
Utility Functions ........................................................................................ 493
sk_extractExtendedICBFromChannelReleasedWithData()............................. 493
Register Functions ..................................................................................... 503
Register Functions .................................................................................. 503
SwitchKit API ............................................................................................ 510
API Messages Used for Call Control Programming ....................................... 510
SwitchKit Application Programming Interface ............................................. 512
Using SwitchKit API................................................................................. 514
Threadsafe SwitchKit API............................................................................ 515
Dos and Don’ts of the ThreadSafe SwitchKit Library .................................... 515
Other Changes Developers Must Make When Using Threadsafe SK API .......... 518
Sample Applications................................................................................ 522
Threadsafe Introduction .......................................................................... 529
Programming Tips and Examples................................................................. 530
Table Of Contents
xv
Advanced Programming Technique in UNIX................................................ 530
Building a SwitchKit Application................................................................ 532
Parsing of AIBs....................................................................................... 535
Programming Tips & Examples ................................................................. 536
Running the Application........................................................................... 537
Simple Tandem and CallSim..................................................................... 538
SwitchKit TCAP Interface............................................................................... 541
Introduction.............................................................................................. 541
SwitchKit TCAP API Architecture ............................................................... 541
SKIM and SKTAL API............................................................................... 543
SKIM and SKTAL API Call Flow ................................................................. 547
TCAP Concepts ....................................................................................... 551
SwitchKit Interface Module ......................................................................... 554
SKIM API Messaging ............................................................................... 554
Initialize().............................................................................................. 557
Terminate() ........................................................................................... 559
SSNInService() ...................................................................................... 560
SSNOutOfService() ................................................................................. 561
Send() .................................................................................................. 562
SendReject().......................................................................................... 563
CancelOperation() .................................................................................. 564
SendPreArrangedEnd()............................................................................ 565
SetTransHandler() .................................................................................. 566
ClearTransHandler()................................................................................ 567
EnableTracing()...................................................................................... 568
DisableTracing() ..................................................................................... 569
SKIM Parameter Classes............................................................................. 570
SKIM_Trans Class................................................................................... 570
SKIM_Operation Class............................................................................. 582
SKIM_Operation Class Methods ................................................................ 584
SKIM_Notify Class .................................................................................. 593
SKIM_CallingPartyAddress / SKIM_CalledPartyAddress Class........................ 597
SKIM Sample Application............................................................................ 604
Step One: Creating a connection with LLC using SwitchKit ........................... 604
Step Two: Creating an Instance of SKIM API Class...................................... 605
Step Three: Sending a TCAP Transaction ................................................... 606
MSP
xvi
Step Four: Receiving a TCAP Transaction................................................... 608
Step Five: Receiving Notifications ............................................................. 611
Step Six: Terminating SKIM API Object Disconnection................................. 612
SwitchKit TCAP Abstraction Level................................................................. 613
sktal_allocateTCAPDialogID() ................................................................... 613
sktal_clearTCAPDialogHandler()................................................................ 614
sktal_getTCAPHandle()............................................................................ 615
sktal_initializeTCAP() .............................................................................. 616
sktal_recvTCAPComponent() .................................................................... 617
sktal_recvTCAPDialog() ........................................................................... 618
sktal_registerTCAPSSNHandler() .............................................................. 619
sktal_sendTCAPComponent() ................................................................... 621
sktal_sendTCAPDialog() .......................................................................... 622
sktal_setTCAPDialogueHandler ().............................................................. 623
sktal_terminateTCAP() ............................................................................ 624
sktal_unregisterTCAPSSNHandler () .......................................................... 625
SwitchKit TCAP Abstraction Layer Messaging API ........................................ 626
SKTAL Parameter Classes ........................................................................... 627
SKTAL Parameter Classes ........................................................................ 627
Class TCAP_Component........................................................................... 628
Class TCAP_Abort : public TCAP_Dialogue.................................................. 633
Class TCAP_Begin : public TCAP_Dialogue ................................................. 636
Class TCAP_Cancel : public TCAP_Component ............................................ 641
Class TCAP_Continue : public TCAP_Dialogue............................................. 642
Class TCAP_Dialogue............................................................................... 645
Class TCAP_End: public TCAP_Dialogue..................................................... 656
Class TCAP_Error : public TCAP_Component .............................................. 658
Class TCAP_Invoke : public TCAP_Component............................................ 661
Class TCAP_Reject : public TCAP_Component............................................. 669
Class TCAP_ResetTimer : public TCAP_Component...................................... 672
Class TCAP_Result : public TCAP_Component............................................. 673
ClassTCAP_Notice : public TCAP_Dialogue ................................................. 676
TCAP_Unidirectional : public TCAP_Dialogue class....................................... 680
SKTAL Sample Application .......................................................................... 685
Step One - Creating a connection with LLC using SwitchKit APIs ................... 685
Step Two - Initializing SKTAL and registering SSN ...................................... 686
Table Of Contents
xvii
Step Three - Sending a TCAP Dialogue and Component ............................... 687
Step Four - Receiving a TCAP Transaction.................................................. 689
Step Five - Terminating SKTAL and Disconnection ...................................... 691
Appendix A TCAP Codes ............................................................................. 692
ANSI TCAP Codes ................................................................................... 692
ITU TCAP Codes ..................................................................................... 697
Appendix B- SKIM Data Types and Codes ..................................................... 700
SKIM Data Types and Codes .................................................................... 700
Appendix C - SKTAL Data Types and Codes .................................................. 702
SKTAL Data Types .................................................................................. 702
Appendix D - SKTAL Dialog and Component Structure Definitions.................... 705
SKTAL_DLG and SKTAL_CPT Structure Definitions ...................................... 705
Appendix E - SKIM and SKTAL API Integration with IntelliNet Codecs............... 713
Integrating SKIM and SKTAL API with IntelliNet Codecs............................... 713
Developer Information .................................................................................. 715
Developer Licensing................................................................................... 715
General Licensing Information.................................................................. 715
System Software Licensing ...................................................................... 717
Software Modules Licensing ..................................................................... 718
SS7 Links Licensing ................................................................................ 720
Introduction to Resource Points ................................................................ 721
VoIP Licensing........................................................................................ 722
Software Overview .................................................................................... 723
Application Requirements (Non-SwitchKit) ................................................. 723
Changing System Software Version........................................................... 730
Downloading System Software to the MSP ................................................. 731
Downloading MSP System Software Using Boot File on an SD Card ............... 743
Downloading MSP System Software From an SD Card ................................. 745
Distributing IMG System Software Using an SD Card................................... 746
Fault Diagnostics .................................................................................... 747
Installing and Configuring a BOOTP Server ................................................ 748
Installing and Configuring a FTP Server ..................................................... 749
Installing and Configuring a TFTP Server ................................................... 750
Using Telnet to Connect to the MSP 1010 .................................................. 751
Ethernet Network Analyzers ..................................................................... 753
Overload Logic ....................................................................................... 754
MSP
xviii
SwitchKit ............................................................................................... 757
Multi-Host.............................................................................................. 758
Configuring the MSP - Getting Started.......................................................... 763
Overview of MSP Configuration................................................................. 763
System Configuration.............................................................................. 765
Common Resources - DSP ....................................................................... 772
Span Configuration ................................................................................. 781
Channel Configuration ............................................................................. 786
SS7 Configuration................................................................................... 792
ISDN Configuration ................................................................................. 804
VoIP Configuration.................................................................................. 820
Reconfiguring the MSP ............................................................................ 826
SS7 ......................................................................................................... 828
Basics of SS7 ......................................................................................... 828
SS7 in the MSP....................................................................................... 832
SS7 Software Architecture ....................................................................... 834
Causes of SS7 Signaling Link Problems...................................................... 836
SS7 Redundancy Overview ...................................................................... 838
Configuring Redundancy on the SS7 Component ........................................ 840
SS7 Redundancy Process......................................................................... 842
Configurable SS7 Component Attributes .................................................... 843
SS7 State Transitions.............................................................................. 845
SS7 State Machine Diagrams ................................................................... 847
Host Link Failure..................................................................................... 849
Message Transfer Part (MTP).................................................................... 851
Combined Link Set.................................................................................. 855
MTP3 to Host ......................................................................................... 859
ISUP ..................................................................................................... 875
Monitoring SS7 ....................................................................................... 1020
Introduction to SS7 Monitoring............................................................... 1020
SwitchKit Support ................................................................................. 1023
Hardware Specifications ........................................................................ 1024
The Structure of SS7 Messages .............................................................. 1025
Filtering............................................................................................... 1027
Host/Application Server Interface ........................................................... 1030
Excel API for SS7 Monitoring.................................................................. 1031
Table Of Contents
xix
DS3 ....................................................................................................... 1034
DS3 Overview ...................................................................................... 1034
Overview of Loopback Testing ................................................................ 1035
Enabling Loopback Diagnostics using the EXS API..................................... 1036
BERT Test............................................................................................ 1039
Configuring BERT Test Using the NG API.................................................. 1041
VoIP ...................................................................................................... 1042
VoIP Overview...................................................................................... 1042
VoIP Resource Profiles........................................................................... 1043
Codec Overview.................................................................................... 1044
Codec Payload Size ............................................................................... 1045
Dynamic Payload Type .......................................................................... 1046
SCCP TCAP ............................................................................................. 1048
Introduction to SCCP/TCAP .................................................................... 1048
SCCP/TCAP in the Excel Architecture....................................................... 1050
SCCP/TCAP Supports Many Services and Applications................................ 1051
Global Title Translation.......................................................................... 1054
Global Title Translation (GTT) Configuration Samples ................................ 1056
Message Flow of TCAP Components ........................................................ 1063
SCCP/TCAP Call Flows ........................................................................... 1065
Configuring SCCP TCAP ......................................................................... 1069
Deconfiguring SCCP/TCAP...................................................................... 1071
China National Variant Configuration....................................................... 1072
TCAP Object Syntax Descriptor (OSD) Configuration ................................. 1074
Adjacent Translators Configuration ......................................................... 1075
Example Configurations and TCAP API Messaging ..................................... 1076
SCCP TCAP Primitives............................................................................ 1083
ANSI TCAP Primitives ............................................................................ 1091
TCAP Primitive Set Interface .................................................................. 1098
ITU TCAP Primitives .............................................................................. 1102
ITU and ANSI SCCP Primitives................................................................ 1111
ITU TCAP Primitive Sets......................................................................... 1114
ANSI TCAP Primitive Sets ...................................................................... 1117
SCCP/TCAP Parameter Information ......................................................... 1122
SCCP Segmentation .............................................................................. 1137
TCAP Parameter IDs.............................................................................. 1139
MSP
xx
SCCP Parameter IDs ............................................................................. 1142
SCCP Connection Oriented Network Services............................................ 1143
SCCP Connection Oriented Call Flows ...................................................... 1147
TCAP Dialog Synchronization.................................................................. 1149
DSP Information...................................................................................... 1164
Overview ............................................................................................. 1165
File Record & Playback .......................................................................... 1184
Conferencing........................................................................................ 1193
Tones.................................................................................................. 1199
T.30 Fax.............................................................................................. 1208
Administration...................................................................................... 1211
Specifications....................................................................................... 1217
Configuring & Using DSP Resources ........................................................... 1240
Overview of Configuring and Using DSP Resources.................................... 1240
Basic DSP Configuration ........................................................................ 1241
Record/Play Files .................................................................................. 1250
Conferencing........................................................................................ 1256
Tones.................................................................................................. 1267
Echo Cancellation ................................................................................. 1280
Media Streaming over RTP ..................................................................... 1288
PVD/AMD............................................................................................. 1295
T.30 Fax.............................................................................................. 1297
ISDN ..................................................................................................... 1298
Introduction to ISDN............................................................................. 1298
ISDN Architecture................................................................................. 1300
Configuring ISDN.................................................................................. 1301
0x01 ................................................................................................... 1303
Network Side Euro-ISDN ....................................................................... 1306
Span Configuration ............................................................................... 1309
ISDN D Channel Configuration................................................................ 1311
B Channel Configuration ........................................................................ 1317
Configuring the Backup D Channel .......................................................... 1318
Optional Information Elements ............................................................... 1321
Optional ISDN Configurations................................................................. 1325
ISDN Call Processing............................................................................. 1330
ISDN Congestion Control ....................................................................... 1336
Table Of Contents
xxi
ISDN Bearer Connection Independent Supplementary Services .................. 1339
PPL Developer's Information........................................................................ 1341
Introduction............................................................................................ 1341
Basics of PPL........................................................................................ 1341
PPL Environment .................................................................................. 1344
PPL Guidelines...................................................................................... 1347
API Messages used for Protocol Modification............................................. 1350
State Machines..................................................................................... 1352
PPL Timers........................................................................................... 1357
PPL Auditing......................................................................................... 1360
Common Atomic Functions ....................................................................... 1363
Atomic Functions .................................................................................. 1363
T1 Atomic Functions ................................................................................ 1374
Atomic Functions .................................................................................. 1374
E1 Atomic Functions ................................................................................ 1388
Atomic Functions .................................................................................. 1388
VDAC IP Network Interface Atomic Functions .............................................. 1426
Atomic Functions .................................................................................. 1426
Layer 4 Atomic Functions ......................................................................... 1431
Call Control Channel Management (0x0061) ............................................ 1431
Layer 4 Call Management (0x0062) ........................................................ 1478
Layer 4 Physical Connection (0x0063)..................................................... 1489
Call Control Router (0x0064) ................................................................. 1491
SS7 Atomic Functions .............................................................................. 1501
BT IUP CPC (0x0052) ............................................................................ 1501
ISUP BLS, HGBS, and MGBS .................................................................. 1518
ISUP CPC (0x0012)............................................................................... 1519
cISUP SPRC (0x0013) ........................................................................... 1535
ISUP SSC (0x0085) .............................................................................. 1550
L3P BT IUP (0x0011)............................................................................. 1553
L3P CIC (0x000F) ................................................................................. 1581
L3P Link (0x0010) ................................................................................ 1595
L3P TUP (0x0011)................................................................................. 1597
SCCP CSCC (0x007F) ............................................................................ 1599
SCCP SCOC (0x007D) .......................................................................... 1602
SCCP SCRC (0x0066)............................................................................ 1609
MSP
xxii
SCCP SRTC (0x007E) ............................................................................ 1613
SCCP SUSI (0x0067)............................................................................. 1615
ISDN Atomic Functions............................................................................. 1618
L3P Call Control (0x0005) Atomic Functions ............................................. 1618
L3P B Channel Control (0x0007) Atomic Functions.................................... 1633
L3 Call Reference (0x0008) Atomic Function ............................................ 1635
L3 Global Call Reference (0x0009) Atomic Function................................... 1638
1
Multi-Services Platform Overview
Introduction to the Multi-Services Platform (MSP) 1010
Overview
The MSP 1010 (hereafter 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 GUI make the MSP 1010 easy to install and maintain.
The MSP simultaneously supports signaling and bearer traffic over circuit and packet switched networks.
Applications
This Telco-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)
Location based services
Intelligent Network (IN) applications
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
Signaling Connection Control Part (SCCP) - China and Japan
Transaction Capabilities Application Part (TCAP)
Integrated Services Digital Network User Parts (ISUP) including the following variants:
ANSI 97, ANSI 95, ANSI 92
ITU 97, ITU 93, CCITT 88
ETSI V1, ETSI V2, ETSI V3
China
IN Protocols
The MSP 1010 supports the following IN protocols on the host:
Customized Applications for Mobile Network Enhanced Logic (CAMEL) - ITU
Wireless Intelligent Network (WIN) for ANSI Wireless Networks - ANSI
MSP
2
Intelligent Network Application Protocol (INAP) mostly for wireline networks - ITU
Wireless Protocols
The MSP 1010 supports the following wireless protocols on the host:
Mobile Application Part for Global System for Mobile communication (GSM-MAP) - 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
32 T1
24 E1/J1
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 Fast Ethernet for VoIP Signaling
2 GIG-E for IP Bearer Traffic
VoIP
The MSP supports two VoIP modules, each supporting the following features:
384 VoIP resources
Codecs: G.711, G.723.1, G.729/A/B, G.726, G.728, iLBC, FR/EFR, AMR, EVRC
G3 Fax Relay that is compliant with the T.38 ASN.1 standard.
Voice/Fax/Data: Automatic Switching
Fax Support: Group 3 2.4 – 14.4 kbps, T.38 compliant fax relay or automatic switch to PCM
Multi-Services Platform Overview
3
Modem Support: Up to V.92 rates
Echo Cancellation: G.168-2000 Compliant; Maximum tail length of 128 milliseconds.
Ping and Trace Route Capabilities
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.
MSP
4
Hardware Overview
1u Signaling Server
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 Description for more information.
Multi-Services Platform Overview
5
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
Related Topics
Basics of SS7
SS7 in the MSP
MSP
6
SS7 Monitoring
Overview
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 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.
Refer to Introduction to SS7 Monitoring
Multi-Services Platform Overview
7
DS3
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.
MSP
8
DSP Media Module
Introduction
Excel’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 easy-to-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.
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.
Multi-Services Platform Overview
9
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
MSP
10
Introduction to the NG API
Overview
The MSP 1010 uses a combination of existing EXS API messages and NG API messages.
This section provides a brief overview of NG API benefits. Refer to the NG API Reference for a complete explanation.
Portable
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. The new API design 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 Excel 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 a 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.
Multi-Services Platform Overview
11
Configurations
Overview
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
Redundant
The following two diagrams depict two types of redundancy:
MSP 1010 Redundancy
Network Redundancy
MSP
12
MSP 1010 Redundancy
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 1010’s, through the Ethernet connection, and only the master MSP 1010 controls the traffic.
Multi-Services Platform Overview
13
Network Redundancy
Network redundancy loadshares the traffic between the two MSP 1010’s . If one of the MSP 1010 malfunctions,the second MSP 1010 handles the traffic.
MSP
14
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, code-intensive 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.
The user guide describes the 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 the ClientView windows. The ClientView section 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.
• 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
Multi-Services Platform Overview
15
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.
MSP
16
Licensing
The following are licensed components in the MSP 1010.
System Software per MSP (includes the four signaling spans)
Number of SS7 links
Base SS7 MTP2/MTP3 License per MSP
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
Refer to General Licensing Information for more information.
17
Hardware Installation & Maintenance
Overview
Description
The MSP 1010, an open programmable telecommunications platform, functions as a SS7 signaling server for multiple Excel switching platforms.
This section and the succeeding sections describe how to install, operate and maintain this unit.
Refer to the MSP 1010 Hardware Product Description (HPD) for general information, physical description, features, configuration information, specifications, and compliance.
MSP 1010
This figure shows the front view of the MSP 1010.
Read and Understand this Technical Publication
Each person who will install, operate, perform service or maintenance or supervise its use must first read and understand the information in this guide and labels on the equipment.
MSP
18
Installation
Pre-Installation Considerations
The installation location for the MSP 1010 is as follows:
The -48 V DC unit must be located in a restricted area, such as a dedicated equipment room or limited access office.
The 120/240 V AC unit does not have to be located in a restricted area. For example, it can be located in a clean and well ventilated office space.
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.
Parameter Specification
Temperature, Operating 0° C to 50° C
Temperature, Operating (Short Term) - 5° C to 50° C
Temperature, Storage -40° C to 70° C
Shock, Operational 30° C/hr
Shock, Storage -40° C to 23° C @ 10° C/min
70° C to 23° C @ 13° C/min
23° C to -40° C @ 30° C/hr
23° C to 70° C @ 30° C/hr
Humidity, Operational 5% to 85%
Humidity, Operating (Short Term) 5% to 90% but not to exceed 0.24kg water/kg of dry air
Humidity, Packaging 90% to 95% relative humidity @ 40° C
Altitude Up to 1800 m (5905 ft)
Physical Description
The MSP 1010, a low profile unit, consists of two 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.
Hardware Installation & Maintenance
19
Parameter Specification
Width
43.89 cm (17.28 in.)
Height
4.36 cm (1.72 in.) (1U)
Depth
48.26 cm (19.0 in.)
Weight
9 kg (20 lbs.)
MSP 1010 Dimensions
Space Requirements
Allow approximately 76 cm (2.5 ft.) of space in front of the MSP 1010, so that the tray can be removed and maneuvered with ease. Leave enough room so that air flow is not obstructed to the four fans at the front or through the side vent holes towards the rear of the unit. Avoid putting the MSP 1010 inside a cabinet with closed doors unless you can provide sufficient ventilation inside the cabinet.
Important! Elevated operating ambient conditions may occur in an enclosed equipment rack. The operating ambient temperature may be greater than the room temperature.
When installing the MSP 1010 do not block the four fans at the front of the chassis. This will cause the unit to overheat.
MSP
20
Rack-Mounting Options
The MSP 1010 can be mounted in a 19-inch rack. The mounting brackets can also be mounted at either the front or the middle of the chassis.
When mounting multiple MSP 1010s in a rack, ensure that a hazardous condition does not exist due to uneven mechanical loading.
AC and DC Power, Wiring and Grounding Requirements
Refer to the Connect Grounding, Connect AC Power and Connect DC Power sections in this section for all power and grounding requirements, surge protection, etc.
Electromagnetic Interference
Electromagnetic Interference (EMI) is a type of radiation that can hinder your system. Keep the following in mind when selecting cables:
Shielded cable prevents outside electrical interference and drains off any induced current.
Twisted wire reduces induction, and thus interference, from one wire to the other. Varying the length of twists reduces the potential for signal interference between pairs.
Twisted pair wiring is available in various thicknesses. Thicker cable covers longer distances and provides better sound quality but it is more expensive.
Channel Service Units
A Channel Service Unit (CSU) connects a digital phone line (T1, E1) from the phone company to a digital communications device. CSUs are required between all telecommunication ports and the network to provide necessary linking capabilities such as:
Line conditioning for long haul transmissions
Remote loopback
Equalization
Regeneration and monitoring of digital signals
Digital circuit testing
Protection from outside lines
Hardware Installation & Maintenance
21
Electrostatic Discharge Protection
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.
DC Surge Suppression
This product has been tested and complies with the Singapore IDA EMC requirements for dc surge suppression, with the use of the EDCO PHC-060 surge suppressor or equivalent.
MSP
22
Unpacking
Overview
The MSP 1010 and supplied items are shipped in a single container. Carefully unpack the MSP 1010 as described below.
Procedure
To unpack the MSP 1010, do the following:
Use caution when moving and lifting the unit. The unit weighs 9 kg (20 lbs.).
1. After the container has been opened, remove the packing list.
2. Remove the protective cover and the MSP 1010 from the container.
3. Carefully remove the static protective bag from the MAP 1010.
4. Carefully inspect the MSP 1010. Should any discrepancies exist, contact your Cantata Technology representative immediately.
Important! Retain all shipping materials in case you need to either relocate or re-ship the unit in the future. Use the Excel packing materials to return the unit to Excel, otherwise you may be charged for any damage that may occur during shipment.
Supplied items
Review the packing list to ensure that the following items have been sent. Should any discrepancies exist, contact your Cantata Technology representative immediately.
AC 1010
AC power cord (AC option)
Software CD ROMs
DC 1010
DC power module plugs (2) (DC option)
DC grounding lug (factory-installed on back of unit) (DC option)
Software CD ROMs
Hardware Installation & Maintenance
23
Rack Mounting
Overview
The MSP 1010 is shipped with the tray and docking station mated together to provide ease in mounting.You can either front-mount or mid-mount the MSP 1010 in a 48.2 cm (19-inch) rack. The unit is shipped with the brackets in the front mounting position. The brackets are movable and reversible to accommodate two mid-mounting positions.
Required Tools and Hardware
The following customer supplied tools and hardware are needed to mount the unit.
Phillips head screwdriver
Rack mounting hardware
Front and Mid-Mounting Bracket Positions
Mounting Guidelines
When mounting the chassis, follow these guidelines:
Mount the MSP 1010 with another person helping you.
Do not obstruct air flow to the four fans at the front or air flow through the side vent holes towards the rear of the unit.
Allow approximately 76 cm (2.5 ft.) to slide the field-replaceable tray out.
Procedure
To mount the MSP 1010, do the following:
MSP
24
Use caution when moving and lifting the unit. The unit weighs 9 kg (20 lbs.). Always use two people to mount the unit.
1. Position the mounting brackets for either front or mid-mounting.
2. Align the holes on the mounting bracket ears to the mounting holes on rack.
3. Secure with mounting hardware.
4. At rear of the unit on each side, a mounting hole with a captive nut is available for attaching mounting ears for extra support. Use 6/32 screws for this application.
Important! The rear mounting ears are not supplied by Cantata Technology.
5. After rack mounting, refer to the following sections on grounding, powering, and interconnecting the MSP 1010.
Hardware Installation & Maintenance
25
Surface Mounting
Overview
The MSP1010 is shipped with the tray and docking station mated together to provide ease in mounting.
Mounting Guidelines
When mounting the chassis, follow these guidelines:
Do not obstruct air flow to the four fans at the front or air flow through the side vent holes towards the rear of the unit.
Allow sufficient room, approximately 76 cm (2.5 ft.), to access the tray.
Optional Mounting Feet
The customer has the option of mounting the supplied four rubber feet to protect the surface finish.
Procedure
To surface mount the MSP 1010, do the following:
Use caution when moving and lifting the unit. The unit weighs 9 kg (20 lbs.). Always use two people to mount the unit.
1. If desired, mount the self-adhesive feet to the bottom of the unit.
2. Set the unit on a clean, secure, and level surface.
3. After surface mounting, refer to the following sections on grounding, powering, and interconnecting the MSP 1010.
MSP
26
Ground Connections
Overview
After mounting the MSP 1010, the user must ground the unit.
AC Grounding
If you have an AC unit grounding is accomplished by plugging the power cable into a grounded outlet. Refer to AC Power Connections in this section for detailed information.
Important! Do not ground the AC unit using the external grounding points located at the rear of the unit. These grounding points are for DC unit grounding only.
DC Grounding
Always connect the DC unit to earth ground as described below before connecting DC power. Refer to DC Power Connections in this section after grounding is complete.
Earth Ground Wiring Specifications
To connect a true earth ground to the chassis, you need the following:
Use 14-16 AWG machine tool wire (MTW)
Green/yellow for earth ground.
Excel supplies a two-hole, # 10 solderless crimp grounding lug that is attached to the grounding screws at the rear of the chassis.
Procedure
Complete the following steps to connect the MSP 1010 chassis to earth ground.
You must connect your chassis to a true earth ground to maintain signaling integrity and to prevent electrical shock.
Do not connect ground to -48 V.
1. At rear of MSP 1010 chassis, remove the two-hole grounding lug by removing the grounding screws.
2. Crimp the grounding wire to the lug. Re-attach the lug to the unit using the grounding screws.
3. Attach the other end of grounding wire to either a grounding point on the mounting rack or a building ground point.
Hardware Installation & Maintenance
27
DC Unit Earth Ground Connection
MSP
28
AC Power Connections
Overview
The MSP 1010 supports an AC power option to support domestic and international customers. The AC power module is located at the rear of the docking station.
Internally, the output of the AC power module connects to a panel-mounted connector via a cable assembly. This connector mates with an AC-to-DC 12 V DC power supply connector on the tray.
Important! Only when the tray is fully seated into the docking station will the power up sequence start. This ensures that the main board does not power up until the system is properly seated.
AC Power Specifications
The AC input power must conform to the following specifications:
120-240 V AC, 60-50 Hz, 3A-1.5A
Range: 90 to 240 V AC
AC Grounding
Ensure the AC power cable is plugged into a grounded outlet.
Important! Do not ground the AC unit using the external grounding points located at the rear of the unit. These grounding points are for DC unit grounding only.
AC Uninterruptible Power Supply Option
If your site has frequent power interruptions, consider using an Uninterruptible Power Supply (UPS) for your MSP 1010. You can prevent downtime by running your system that receives its AC power from batteries during a power failure.
AC Surge Protection
Cantata recommends installing a surge protector between your call processing system and the power outlet. If a high voltage surge occurs on the power line, this device protects your system by sending the overload to ground.
AC Power Cable
An AC power cable is supplied to both United States and international customers.
AC Power Module
The AC power docking station provides an AC input power module with an integrated fuse, power switch, and standard three position female AC input connector. This connector allows the docking station to interface with all variations of AC outlets by simply using a standard power cable with a compatible outlet plug.
Hardware Installation & Maintenance
29
Fuse Removal and Replacement
Complete the following steps to remove and replace the fuse.
Replace the fuse with only an Cantata Technology supplied fuse or equivalent: 3 Amp Slo-Blo fuse, type 3AG.
Procedure
1. Ensure the power switch on the AC power module is set to O (Off).
2. Unplug AC power cord. Important! For safety, the integrated fuse can only be replaced when the power cord is removed.
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. Important! 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.
AC Power Module
Connecting to AC Power Source
Complete the following steps to connect AC power to the chassis.
Procedure
1. Ensure the power switch on the AC power module is set to O (Off).
Ensure the AC power module switch is set to O (Off) prior to connecting the MSP 1010 to the AC power source.
2.
3. Plug AC cable into the receptacle on the AC power module.
4. Insert other end into a grounded wall outlet, Uninterruptible power supply (UPS), or surge protector.
5. Press switch on the AC power module to I (On).
MSP
30
DC Power Connections
Overview
The MSP 1010 supports a DC input power option to support both domestic and international customers. The DC power module is located at the rear of the docking station.
Internally, the output of the DC power module connects to a panel-mounted connector via a cable assembly. This connector mates with an DC-to-DC 12 V DC power supply connector on the tray.
Important! Only when the tray is fully seated into the docking station will the power up sequence start. This ensures that the main board does not power up until the system is properly seated.
DC Grounding
Important! Always connect the DC MSP 1010 to earth ground before connecting DC power. Refer to Ground Connections in this section.
DC Power Specifications
The DC input power must conform to the following specifications:
-48 V DC (nominal), 7A
Range: -40 to -60 V DC
DC Power Module
The DC docking station provides a DC power module with the following:
Two -48 V DC power input terminals (PWR1/PWR2)
Two ON/OFF circuit breakers (CB1/CB2).
The user can use to select either a single non-redundant power source or dual, redundant power sources. The DC-to-DC power supply on the tray provides control for dual, redundant power.
DC Power Module
Hardware Installation & Maintenance
31
-48 V Wiring Specifications
You connect the external DC power source to the chassis at the DC power module terminals.
The DC power module must be wired directly to a –48 V fused power source. To connect an external power source to the DC power module, you need the following:
14-16 AWG machine tool wire (MTW)
Blue for –48
White for –48 V Return
DC power module plug(s) (Excel supplied)
Do not daisy-chain two or more MSP 1010 chassis. Do not wire chassis directly to other equipment or to a common bus bar. Most feeders from the -48 V to frames are limited to about 20 A, whereas load distributions support several hundred amperes. Direct wiring to the fused power source eliminates the coupling mechanism, which appears as impedance in the power distribution system. If impedance is not controlled, transient voltages will cause temporary or permanent malfunctions.
Connecting to an External Single Power Source
Complete the following steps to connect a single power source to the DC power module.
Procedure
1. Ensure both circuit breakers on the DC power module are set to OFF (O).
2. Turn power OFF at power source. Failure to turn power OFF at the power source may result in electrical shock.
3. Route the RET and -48V wires from the external power source to the DC power module plug. Secure the wires to the plug with screws. Ensure that the wires are pushed into the plug far enough, so that none of the copper is visible. Ensure that the RET and -48V wires are connected for the correct polarity.
4. Insert the plug into the DC power module and secure with screws.
5. Turn power ON at power source.
6. Press the required circuit breaker on DC power module to ON (I).
MSP
32
DC Wiring Installation
Connecting to an External Redundant Power Source
You can add a second power source to the chassis for redundancy in case the primary power source fails. Complete the following steps to connect a redundant power source to the chassis.
Important! The MSP 1010 supports a redundant power configuration. The secondary source (battery) serves as backup to the primary source (power supply).
Procedure
1. Ensure both circuit breakers on the DC power module are set to OFF (O).
2. Turn power OFF at redundant power source.
Failure to turn power OFF at the redundant power source may result in electrical shock.
3. Route the RET and -48V wires from the redundant power source to the DC power module plug. Secure the wires to the plug with screws.
Important! Ensure that the wires are pushed into the plug far enough, so that none of the copper is visible.
Hardware Installation & Maintenance
33
Ensure that the RET and -48V wires are connected for the correct polarity.
4. Insert the plug into the DC power module and secure with screws.
5. Turn power ON at redundant power source.
6. Press the required circuit breaker on the DC power module to ON (I).
MSP
34
Power and Fan Control
Power Control
The MSP 1010 power ramp-up is initiated only when the tray (main board) is fully seated into the docking station. This is done when the main board receives a fully seated signal from the docking station
I/O board. This ensures that power on the main board does not come on until the system is properly seated.
All board voltages are then monitored and if any voltage falls out of tolerance on the low-side, a power down of all voltages will occur. In the case where a fault is detected by the CPU and main board shutdown is necessary, a forced shutdown will be initiated. A restart will not be initiated until all voltages are within tolerance.
Fan Control
The MSP 1010 uses four fans for cooling. The fans, located on the front panel, draw air into the unit to cool the main board and I/O board. The air exhausts out vent holes at the rear sides of the docking station.
The fans connect directly to the main board and are individually fused and controlled by a fan controller on the main board. The main board also provides six temperature sensors that monitor ambient temperature at strategic locations on the board. When the fan controller detects an over temperature, the fans will increase speed to full on. For example:
If one of the fans fail, the remaining fans will increase speed to full on to supply the required cooling.
If any of the six temperature sensors detect an over temperature condition, the fans will increase speed to full on to supply the required cooling.
Hardware Installation & Maintenance
35
Rear Panel I/O Connectors
Overview
The MSP 1010 rear panel I/O card connectors provide the required interfacing in 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 auto-negotiating, 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.
SIGNALING/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 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 bearer redundancy between MSPs. Redundant 1010s are connected by using two cables.
MSP
36
BEARER 0 - 27 (T1/E1 Bearer Span Connectors)
The 28 T1 and 21 E1 bearer spans are accessed through the RJ-45 Ethernet connectors. The connectors provide T1 with 100 ohm impedance and E1 with 120 ohm impedance and signaling.
BEARER TX, RX (DS3 Bearer Span Connectors)
The DS3 bearer spans are accessed through the BNC interface connectors. The connectors provide the DS3 with 75 ohm impedence and signaling.
Rear Panel I/O Connectors
Ethernet Control, Signaling and Data Connector LEDs
These Ethernet RJ-45 connectors contain two LEDs that provide the user with Ethernet status.
RJ-45 Ethernet Connector LED Status
Activity Green/Off Blinks on either transmit (TX) or receive (RX)
Hardware Installation & Maintenance
37
activity
Speed
10/100
Yellow/Off On when 100 Mpbs link established. Off when 10 Mpbs link established
Speed 10/100/1000 Yellow/Off On when 1000 Mpbs link established
Off when 10 or 100 Mpbs link established.
RJ-45 Ethernet Connector LEDs
MSP
38
I/O Interconnections
Overview
After mounting the MSP 1010, the 1010 can be interconnected in a single platform configuration or in a redundant platform configuration.
Cable Requirements
Ensure the interconnection cables meet the following requirements:
10/100/1000BaseT Ethernet Cable Specifications
The MSP 1010 communicates with the host and other units in the network through Ethernet connections over 10BaseT, 100BaseT or 1000BaseT (shielded) cables. The table below lists the cable specifications.
Characteristics 10/100Base-T (Shielded) Category 5
Designator Twisted pair
Segment Length Recommended maximum 100 m
Cable Type 24 gauge 100-Ohm shielded twisted pair
Connector 8-pin RJ-45
T1/E1 Span/Timing Cable Specifications
The table below lists the cable specifications.
Characteristics T1 (Shielded) Category 8
Designator Twisted pair
Segment Length Recommended maximum 100 m
Cable Type 24 gauge 100-Ohm shielded twisted pair
Connector 8-pin RJ-48
1+1 Redundancy Cable Specifications
The table below lists the cable specifications. These cables are reserved for future use.
Characteristics VHDCI 8 mm
Designator 28 gauge twisted pair
Hardware Installation & Maintenance
39
Segment Length 12 inches
Cable Type 34 twisted pair, shielded
Connector 68-pin VDCI style
Typical Stand Alone MSP 1010 Configuration
To interconnect the MSP 1010 in this configuration, see Figure below.
Stand Alone MSP 1010 I/O Interconnections
Typical Redundant MSP 1010 Configuration
To interconnect the MSP 1010 in this configuration, see Figure below.
Redundant MSP 1010 I/O Interconnections
MSP
40
Hardware Installation & Maintenance
41
Operation
Operation Overview
Description
After making the I/O interconnections, the MSP 1010 is ready for system setup and operation.
Controls and Indicators
Prior to operating the MSP 1010, the user must become familiar with the front panel controls and indicators. Refer to Controls and Indicators in this section.
MSP
42
Front Panel Controls and Indicators
Overview
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
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 Description
Off No 3.3V power
Green 3.3V power available
Orange Power warning
Hardware Installation & Maintenance
43
ALARM
This LED indicates alarm conditions.
LED Color Description
Off Not applicable
Green No alarms
Orange Minor alarm
Red Major alarm
SIG/TIMING
These four LEDs indicate T1/E1 spans statuses for the SIGNAL/TIMING 0, 1, 2, 3 connectors.
LED Color Description
Off Span is out of service.
Green Span is in service and is receiving valid data.
Orange Receiving an orange alarm RAI
Red 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
Off Free running
Green Locked on external timing source
Orange 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.
MSP
44
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
Off No link established
Green Link established and active port
Orange Link established and standby port
Red 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
Off Span is out of service.
Green Span is in service and is receiving valid data.
Orange Receiving an orange alarm RAI
Red Span is in service and is receiving a red alarm or no span is connected.
Hardware Installation & Maintenance
45
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.
Used to display contents of a menu item if no additional menu items exist to the bottom of this item.
When pressed simultaneously with the Up push button, a hard reset of the MSP 1010 occurs.
Left
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.
Right
MSP
46
Used to scroll right to a different line of text.
Used to display contents of a menu item if no additional menu items exist to the right of this item.
When pressed simultaneously with the Left push button, a soft reset of the MSP 1010 occurs.
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
Physical Span Info
IP 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.
Hardware Installation & Maintenance
47
When the item is selected, its text will be displayed in one of three ways:
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.
o 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.
o 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.
System Info Menu
MSP
48
Hardware Installation & Maintenance
49
Physical Span Info Menu
MSP
50
Hardware Installation & Maintenance
51
Timing Info Menu
MSP
52
IP Info Menu
Hardware Installation & Maintenance
53
MSP
54
Hardware Info Menu
Hardware Installation & Maintenance
55
MSP
56
Maintenance
Troubleshooting
Overview
This section contains a troubleshooting table to help you diagnose and resolve hardware issues that could occur during the MSP 1010 installation and operation.
The table is organized into three sections:
Power
Cooling
Alarm LED Indicators
The information in each section is organized as follows:
Problem or Symptom
Cause or Description
Corrective Action
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
Whether you are using a single power source or redundant power sources
The grounding method
LAN topology
The version of System Software used with the MSP
A trace of messaging between the host and the MSP
After you record this information, please contact Cantata technical Support.
Power
Problem or Symptom Cause or Description Corrective Action
The DC 1010 does not power up.
The circuit breaker(s) at the rear of the chassis are switched to OFF (O).
Switch the circuit breaker(s) to ON (1).
The -48 V DC power source is not plugged in or is not operating.
Check the power source for proper output. Replace it if necessary.
The –48 V DC power source is not connected properly to the DC power module at the rear of the chassis.
Refer to Connect DC Power in Section 2 and make sure that the power source is connected properly. If necessary, rewire the connections.
Tray not properly seated Remove tray and reinstall
Hardware Installation & Maintenance
57
in docking station. to ensure the tray is properly seated. Refer to Tray Removal and Replacement in this section.
One of the voltages is out-of-tolerance on the low side. Main board shuts down.
Restart 1010.
Remove tray and reinstall to ensure the tray is properly seated.
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).
Set the switch to 1 (On)
The 120/240 V AC power source (outlet) is not plugged in or is not operating.
Check the power source (outlet) for power or proper output. Check for tripped circuit breaker. Reset circuit breaker or repair as necessary.
The AC power cable is faulty.
Replace cable. Refer to Connect AC Power in Section 2.
Tray not properly seated in docking station.
Remove tray and reinstall to ensure the tray is properly seated. Refer to Tray Removal and Replacement in this section.
One of the voltages is out-of-tolerance on the low side. Main board shuts down.
Restart 1010
Remove tray and reinstall to ensure the tray is properly seated. Refer to Tray Removal and Replacement in this section..
The DC 1010 powers up, but then shuts down.
A circuit breaker has tripped.
Reset circuit breaker.
Check the wiring.
Refer to Connect DC Power in Section 2.
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 AC 1010 powers up, An external circuit breaker Reset circuit breaker.
MSP
58
but then shuts down. has tripped.
The fuse in the AC power module has blown.
Replace fuse. Refer to Connect AC Power in Section 2.
Cooling
Problem or Symptom Cause or Description Corrective Action
The 1010 is operating, but the tray over heats. ALARM LED on front panel lights red (major) or orange (minor)
Refer to the Hardware Alarm Module section in this section to access Fan and Temperature Sensor alarm descriptions.
Refer to Hardware Alarm Module section in this section to access Fan and Temperature Sensor corrective action information.
Refer to Section 3 for the LCD display, Hardware Info Menu to access Fan and Temperature Sensor information.
If ALARM LED remains on, call Cantata technical Support. To remove tray and replace, refer to Tray Removal and Replacement in this section.
Front Panel LED Indicators
Problem or Symptom Cause or Description Corrective Action
The 1010 powers up, but the ALARM LED lights red (major) or orange (minor)
An alarm condition exists. The LCD display will indicate source of alarm condition. Refer to Controls and Indicators in Section 3. If ALARM LED is still red, call Cantata technical Support.
The SIG/TIMING 0, 1, 2, or 3 LED lights red (timing error) or orange (reference clock present but not timing system)
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.
he TIMING LED lights orange (hold over)
Lost lock on external timing source, but still synched to it.
Refer to the MSP 1010 Developer’s Guide to reconfigure external timing.
Hardware Installation & Maintenance
59
he ENET CTRL, ENET DATA, or ENET SIG LED lights red (no link established, error)
The Ethernet link has not been established or has been lost
Refer to the MSP 1010 Developer’s Guide to establish or re-establish link.
The SIGNAL SPAN LEDs, for licensed E1/T1 spans, light red (major alarm) or orange (minor alarm)
Not used in this release. Not used in this release.
MSP
60
Hardware Alarm Module
Overview
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 or all temperature sensors
Status of all fans and 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.
Major - if one or more fans are set to the major alarm state.
Normal- if a fans exists an alarm state (returns to normal).
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).
Hardware Installation & Maintenance
61
Major - temperature reading is more than 70° C (alarm goes back to Minor at 65° C).
Critical - temperature reading is more than 80° C (alarm goes back to Major at 75° 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.
MSP
62
Tray Removal and Replacement
Description
The tray is the only field replaceable unit of the MSP 1010.
Procedure
To remove the tray from the docking station and then replace it, proceed as follows:
Removal
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 Excel, 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. When ready, set power to ON (1) at rear of docking station.
Hardware Installation & Maintenance
63
Tray Removal and Replacement
MSP
64
Installing a VoIP or Media Module Hardware Installation
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)
4 Phillips pan head screws
VoIP module or Media module.
Steps
1. Set power to OFF (O) at rear of docking station.
2. Remove Motherboard Tray. See Diagram – Removing Motherboard Tray.
a. Loosen the two ejector captive fasteners located on each side of the front panel.
b. Lift the ejectors upward and pull to unseat the tray from the docking station.
c. Slide the tray out.
3. Locate Module Position. See Diagram – Module Position. If you are replacing an existing module, remove the existing module by unscrewing the screws and lifting the module off of the motherboard.
5. Install the module on motherboard
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.
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.
Hardware Installation & Maintenance
65
c. Attach the module with the four (4) Phillips pan head screws. Caution: Do not over tighten the screws.
6. Re-insert Motherboard Tray
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).
Important Notes
- 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.
d. When the tray is seated and the connectors are mated, push the ejectors down and tighten captive fasteners.
7. Set power to ON (1) at rear of docking station.
8. See the procedures for configuring modules in the Alphabetical List of Configurable MSP 1010 Objects section.
Diagram - Removing Motherboard Tray
MSP
66
Diagram - Module Positions
Important: If only one VoIP module is to be installed, it must be at Position 0.
Hardware Installation & Maintenance
67
Industry Compliance
FCC Regulatory Compliance Notices
Overview
This section identifies the United States Federal Communications Commission compliance notices.
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 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.
MSP
68
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 _______________________
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.
Hardware Installation & Maintenance
69
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: ____________________________
MSP
70
Declaration of Conformity
Overview
This section provides the United States European Declarations of Conformity. Refer to the Cantata salesperson for the latest copies.
Hardware Installation & Maintenance
71
73
MSP Hardware Product Description
Overview
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.
MSP
74
Physical Configuration
Physically, the MSP 1010 consists of two parts: 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.
MSP Hardware Product Description
75
Features
The MSP 1010 provides the following features:
General
Low profile (1U)
Rack mounted or surface mounted
Centralized and distributed architecture
Scalable configurations
CPU
750 MHz CPU
100 MHz SDRAM
Input Power
Rear input power module (AC or DC)
120/240 V AC, 60/50 Hz
-48 V DC
Front Panel
Front panel with LCD display, span and alarm status indicators, and pushbuttons
Rear I/O Panel
Rear I/O interface connectors (signaling and timing, host control, network interfaces, and redundancy)
Redundancy
1+1 bearer redundancy
MSP
76
Configuration Information
The MSP 1010 serial numbers and model numbers are located as follows:
Main board: front of unit
I/O: rear of unit
MSP Hardware Product Description
77
Specifications
The MSP 1010 is designed to the following electrical, physical, and environmental specifications.
Electrical Specification Range
AC Power Range 120-240 V AC, 60-50 Hz, 3A-1.5A
90 to 240 V AC
DC Power -48 V DC (nominal), 7A -40 to -60 V DC
Physical Specification
Width 43.89 cm (17.28 in.)
Height 4.36 cm (1.72 in.) (1U)
Depth 48.26 cm (19.0 in.)
Weight 9 kg (20 lbs.)
Environmental Specification
Temperature, Operating 0° C to 50° C
Temperature, Operating (Short Term) -5° C to 50° C
Temperature, Storage -40° C to 70° C
Shock, Operational 30° C/hr
Shock, Storage -40° C to 23° C @ 10° C/min
70° C to 23° C @ 13° C/min
23° C to -40° C @ 30° C/hr
23° C to 70° C @ 30° C/hr
MSP
78
Humidity, Operational 5% to 85%
Humidity, Operating (Short Term) 5% to 90% but not to exceed 0.24kg water/kg of dry air
Humidity, Packaging 90% to 95% relative humidity @ 40° C
Altitude Up to 1800 m (5905 ft)
MSP Hardware Product Description
79
Compliance
The MSP 1010 meets the following national and international standards.
Standard USA/Canada European Union Australia/New Zealand
EMC FCC Part 15
ICES-003
EN55022: 98
EN55024: 98
EN300386: Rev 1.3.1
AS/NZS CISPR 22
Safety CSA-C22.2 No. 60950-1
EN60950-1 AS/NZ 60950
CB Scheme IEC 60950-1
Telecom FCC Part 68/IC CS03
TBR 12, 13 AS/ACIF S-016
MSP
80
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 auto-negotiating, 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 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 MSPs. Redundant MSPs 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 and signaling.
MSP Hardware Product Description
81
MSP
82
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.
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.
MSP Hardware Product Description
83
Front Panel
The front panel consists of a PCB that houses 43 bi-color LEDs, an LCD display and five LCD pushbutton switches used to control the display. The user can only retrieve and monitor information via the front panel.
MSP
84
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
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.
MSP Hardware Product Description
85
MSP
86
LCD Display
The LCD display is a standard two line times 24 (2x24) character display with a back-light. It consists of a hierarchical LCD display menu system controlled by the five push-button switches. The display allows the user the capability to retrieve and monitor information.
The default display is initially set to show the Product name and unique chassis ID, however the user may optionally set any displayed item as the default. The display 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.
MSP Hardware Product Description
87
LCD Menus
The LCD menus provide the user with means to access, verify, and monitor the information listed below.
The main menus are listed below. Refer to the MSP Installation and Maintenance Guide for detailed display and control, and menu information.
System Info
Physical Span Info
IP Info
Hardware Info
MSP
88
LCD Pushbutton Switches
The five pushbutton switches listed below allow the user to select and display the menu information on the LCD display that are specific to the active MSP 1010 configuration. Each pushbutton switch is interfaced to the main board for control and monitoring. Refer to the MSP 1010 Installation and Maintenance Guide for detailed pushbutton switch control information.
Up
Down
Left
Right
Select
The pushbutton switches also allow the user to initiate hard and soft unit resets as described below.
Hard Reset
Pressing the Up and Down switches simultaneously 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 causes a soft reset of the CPU. A soft reset will not reload the processor configuration registers and the FPGA configuration data.
89
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 this book are shown in alphabetical order under ClientView in the table of contents in the web-based documentation.
MSP
90
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
Ability to graphically configure an MSP 1010 from initial setup to channel configuration. You can apply changes to the connected nodes with simple point-and-click operations.
Monitoring
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.
Provisioning
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
ClientView
91
Panes
The following panes appear in the main window.
Configuration Tree (Top-Left)
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).
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.
MSP
92
System Requirements for 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: 1 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: 1 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: 1 GB
• Memory: 512 MB of RAM
HP-UX Requirements
To run ClientView on HP-UX, a host machine with the following minimal specifications is required:
• Display resolution: 1024 x 768 pixels
• Free Disk Space: 1 GB
• Memory: 512 MB of RAM
ClientView
93
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.
Windows:
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:
C:\Program Files\Cantata\installs\MSPUserInterface_version\MSPUserInterface\Uninstall_MSPUserInterface
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, Solaris, HP-UX:
Use this command:
./Uninstall_MSPUserInterface
from:
/opt/cantata/MSP/MSPUserInterface/Uninstall_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 \common. This file defines the directory for the proper running of SwitchKit processes. Here is an example of the contents of the Defaults file:
MSP
94
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:
ClientView
95
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 the second screen, you will be given the option to install EventView as well as ClientView by selecting a checkbox.
On UNIX
To install ClientView and/or EventView on a host running Linux, Solaris or HP-UX 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.
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.
MSP
96
Open ClientView
Before you start ClientView, the following SwitchKit components should be started in the sequence shown:
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, Solaris or HP-UX, type:
./ClientView
2. Close the About ClientView window.
3. 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
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.
ClientView
97
You are now ready to begin configuration. See Creating a Configuration for the First Time.
MSP
98
Opening Multiple Instances of ClientView
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)
Provision (limited-access mode)
Configure (full-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.
ClientView
99
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.
See Also Upgrading ClientView.
MSP
100
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, HP-UX
/opt/cantata/MSP/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.
ClientView
101
MSP
102
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.
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:
ClientView
103
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.
MSP
104
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, Solaris, HP-UX
/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.
ClientView
105
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
C:\Program Files\Cantata\common\license
Linux, Solaris, HP-UX
/opt/cantata/MSP/license
2. Reset the node. See Resetting a Node.
Configuration should proceed and succeed past licensing verification.
MSP
106
ClientView Indicators
Configuration Fields
The following are the color indicators in Configuration pane fields under User-Specified.
Blue
Indicates a field that can be edited by either entering a value or selecting an option from a drop-down list.
Green
Indicates a field that has been committed and is read-only (cannot be changed).
Beige
Indicates a field that has been edited and not yet committed.
Yellow
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
When you send a configuration, the progress indicator flashes yellow/orange and provides text on what process is occurring.
ClientView
107
Gray
When the progress indicator is gray, the configuration was successful.
Red
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.
Here is what the icons indicate:
MSP
108
ClientView
109
ClientView Menus
File
Edit
View
Communication
Tools
MSP
110
Help
- Open a configuration file. The configuration is automatically sent to the MSP
- Save the configuration file you are working on
- Exit 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
ClientView
111
- 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 IMG 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
MSP
112
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 Cantata MSP EMS object pane.
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 Cantata 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
ClientView
113
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:
Network Interfaces
Raw API Commands
Facility
Signaling
Media Object
Timing Synchronization Priority List
License Information
Telnet Client
MSP
114
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.
ClientView
115
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.
For Exporting
Cantata MSP EMS -> Signaling Variants -> Signaling Variant -> Export Variant Entry File
Browse to the file you want to import and Open it.
MSP
116
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:
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.
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
Save with changes but do not configure
ClientView
117
Configure and save with changes
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"
File Changes/Actions
Change Action
Config file has a property that ClientView does not recognize.
Property ignored.
ClientView has a property that the Config File does not contain a value for.
Property is set with the default value.
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.
No report generated.
Invalid XML attribute added to Config file by user.
Added attribute will be ignored.
Added element will be ignored and reported in the log file
Required XML attribute/element removed from Config file by user
Attributes/elements are populated with the default value.
Reports are generated.
Property renamed. Property is ignored.
Config file has an object that is no longer in ClientView
Object and all children ignored
Object changed position in the new ClientView hierarchy
Object ignored.
Log generated.
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
It’s a mandatory attribute; removed attribute will be set with empty string.
MSP
118
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.
ClientView
119
Common Example Configurations
Example Configuration for DS3 Spans
To configure a range of DS3 spans, use the TDM DS3 Wizard.
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.
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.
MSP
120
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
ClientView
121
Example Configuration for SS7 Voice Circuits
Use this procedure as an example of how to configure SS7 voice circuits. For more information see ISUP Introduction.
Before Your Begin
You must have a T1 Physical Span or an E1 Physical Span Configured.
Configure SS7
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.
MSP
122
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 Your 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
ClientView
123
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
It is recommended that you configure high impedance on the logical spans so that the SS7 traffic will not be transmitted to the network side.
2. Sockets
It is recommended that a port number other than 12610 (0x3142) be used.
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.
4. Links
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
From the filter rules menu you must configure these objects:
Links
Service Indicator
Network Indicator
Point Code
MSP
124
Example Configuration for Media Resources
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:
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
ClientView
125
Example Configuration for SCCP/TCAP
Use the following sequence to configure SS7 SCCP/TCAP on your MSP 1010. 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:
TCAP Object Syntax Descriptor
SCCP/TCAP Default Parameter Table
Global Title Translation
You can also configure these options from the sub-system number object:
Adjacent Translator
Other Concerned Point Codes
SSN Default Parameter
Network DPC and SSN
Replicated DPC and SSN
MSP
126
Configuring VoIP Modules
Licensing
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.
Prerequisites (in order)
Network Interface
IP Bearer Profiles
Facility
Steps
1. Right-click Facility and select New Bearer - IP.
2. The VoIP Module pane appears.
Complete the fields as required. For more details see the VoIP Module GUI reference.
Related Topic
VoIP Overview
ClientView
127
Example Configuration for ISDN
Use this procedure as an example of how to configure ISDN on your MSP 1010. 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.
MSP
128
Alphabetical List of Configurable MSP 1010 Objects
Adjacent Translator
By default, all adjacent translators are concerned point codes.
Accessing This Pane
Physical MSP -> New Signaling -> Signaling -> New SS7 -> New SS7 Stack
-> New SCCP/TCAP -> New Sub-System Number -> Sub-System Number
-> New Adjacent Translator.
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.
ClientView
129
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
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.
MSP
130
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.
ClientView
131
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
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.
MSP
132
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.
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.
ClientView
133
Field Descriptions
MSP Name
The name of the MSP on which the group resides.
Trunk Type
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
MSP
134
Updates the status of CICs shown in the Status Pane
ClientView
135
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
Pane
MSP
136
Channel Configuration Groups
You create a new channel group by right-clicking on the Routing Configuration object and selecting New Channel Configuration Groups.
Accessing this Pane
Cantata MSP EMS -> New Routing Configuration -> New Channel Configuration Groups
Pane
ClientView
137
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
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.
MSP
138
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.
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
ClientView
139
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
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.
MSP
140
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 = (32*Logical_Node_ID) + Physical_Offset
Signaling span IDs = (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.
E1 Physical Span ClientView Pane
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
ClientView
141
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
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
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.
MSP
142
Choices:
True
False
Span Status
This monitoring field indicates the current status of the E1 span.
Button Descriptions
In Service
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.
ClientView
143
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 -> MSP Name -> New Media -> New Echo Cancellation
Pane
MSP
144
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 Cantata 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 specified otherwise through environment variable SK_LLC_PORT and SK_RLLC_PORT, respectively.
Right-click Cantata MSP EMS to configure any of the following:
New Node Group
New Routing Config
New Signaling Variants
New External Network Elements
ClientView
145
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.
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.
MSP
146
TDM DS1 Wizard Pane
TDM DS1 Wizard 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
Start Interface
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.
ClientView
147
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.
Pane
Filter Rules Menu
MSP
148
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.
Steps
1. Right-click the Global Title Group.
2. Select values for the properties that you want to change.
ClientView
149
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.
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.
MSP
150
Global Title Translation
This object is 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.
ClientView
151
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
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.
MSP
152
Field Descriptions
IP Bearer Profile Name
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.
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.
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
ClientView
153
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.
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.
MSP
154
Modem Behavior
Choices:
Bypass: Switches to another codec when you are in a modem call. The codec that you switch to is specified in the Fax Bypass Codec field. For example, if you are using a low bit rate codec, such as G.729, a modem or fax call will probably not be successful. So in this case the MSP changes the codec to what is configured in the Fax Bypass Codec field.
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
The range of legitimate values is 0-150 millisecond units.
Maximum Jitter Buffer Delay
The range of legitimate values is 150-300 millisecond units.
Payload Type
This field specifies the desired payload size for the Vocoder entry.
Choices:
G711 alaw
G711 ulaw
G726 16 Kbps
G726 24 Kbps
G726 32 Kbps
G726 40 Kbps
G723 5.3 Kbps
G723 6.3 Kbps
Preferred Payload Size
Choices:
10
20
30
ClientView
155
40
50
60
Type of service Parameters
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
Choices:
Normal Cost
Low Cost
MSP
156
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
ClientView
157
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
MSP
158
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
ClientView
159
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
Pane
MSP
160
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
Pane
ClientView
161
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
Pane for an E1 Span
Pane for an T1 Span
Field Descriptions
Primary Span
MSP
162
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.
Yes
No
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)
National-ISDN User Side
ATT 4ESS Q.931 PRI
ATT 5ESS Q.931 PRI
Northern Tel DMS-100 Q.931 PRI
Northern Tel DMS-250 Q.931 PRI
ClientView
163
HDLC Bit Polarity
Normal (default)
Inverted
Network Side Layer 2 Override
Network (default)
User
Location
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 Private Network (1 - Message generated by private network serving the local user)
Local public network (2 - Message generated by public 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
MSP
164
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
Pane
Field Descriptions
D Channel Physical Medium
64 kbps (T1/E1/J1)
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
ClientView
165
0x0A B Channel Encoding for Transmission
Channel Number
Slot Map
Fill Mask Functionality
Enter a range
MSP
166
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
Pane
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
ClientView
167
ATT Multiquest
Bearer Capabilities Allowed
Voice
3.1 KHz Audio
Unrestricted 56K
Unrestricted 64K
Restricted 64K
384K
7.1 KHz Audio
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
MSP
168
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
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)
ClientView
169
Enable
Send ALERTING INDICATION to host
Disable (Default)
Enable
Send PROGRESS to host
Disable (Default)
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.
MSP
170
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)
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)
ClientView
171
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
MSP
172
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.
Accessing this Pane
Cantata MSP EMS -> New Routing Config -> Routing Configuration -> New Channel Configuration Groups -> New ISUP Config Group
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 displays in the right pane.
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:
Answer Supervisor Mode
0x00 Propagate Answer to Distant End
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
0x00 Park Channel
ClientView
173
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.
MSP
174
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
C:\Program Files\Cantata\MSPSwitchKit\license
Linux, Solaris, HP-UX
/opt/cantata/MSP/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.
ClientView
175
MSP
176
Link Configuration
Use this object to set up monitoring of SS7 links.
Accessing this Pane
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.
ClientView
177
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
You must enter a name in under the User-Specified column.
MSP
178
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.
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:
Cantata MSP EMS -> Logical MSP -> Physical MSP -> Facility -> Bearer -> New E1 Physical Span -> Logical Span ID
Logical Span Pane
Configuration
Select values from the drop-down menus in the User-Specified column for the following:
Logical Span ID (1-4095)
Loop Timing Type
Framing
Signaling
Line Length
Line Coding
Impedance
Span Status
This monitoring field indicates the current status of the E1 or T1 span.
ClientView
179
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-of-service and bringing it in-service using the buttons in ClientView.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> MSP Name -> New Media -> New Media Module -> New Media DSP
Maximum Media DSP Objects
2
Media DSP Pane
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
MSP
180
Indicates the function configured for the Transmit 1 DSP.
ClientView
181
Media Module
This pane configures a DSP module on the MSP.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> MSP Name -> New Media -> New Media Module
Maximum Media Module Objects
1
Media Pane
Field Descriptions
Module Interface Id
Media Module 0
Media Module 1
Module Name
On-Board
Media Module
MSP
182
Media
Use this object to configure media resources. The available media resource options are:
Conference Parameters
Echo Cancellation
PVD-Answering Machine
T.30 Fax Parameters
DSP Alarm Thresholds
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> MSP Name -> New Media
ClientView Pane
ClientView
183
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.
MSP
184
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
Configuration Pane
Steps
1. Select an option for the Application Type:
SigView
SCCP-TCAP
ISUP
2. Enter an Application ID.
3. Enter a Logical Socket ID.
ClientView
185
Monitoring Application Map
Use this object to map a monitoring application to a 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
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.
MSP
186
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
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.
ClientView
187
Links
Use this object to apply filter rules to a monitored SS7 link.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Signaling -> Signaling -> New Monitoring -> Monitoring -> New Filter Rules -> Filter Rules -> New Link
MSP
188
Point Code
Use this to filter originating (OPC) and destination (DPC) 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
189
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.
MSP
190
Service Indicator
Use this to enable or disable signal units and SS7 user parts when monitoring SS7 traffic.
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
191
Multi-Host Socket
The MSP 1010 allows you to configure sockets for up to three hosts. The range of Logical Socket IDs is 0-2. The default Port Number 0 is assigned logical socket ID 12610 (0x3142). Port Number 1 and Port Number 2 can be assigned any logical socket ID: 1-65535.
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.
MSP
192
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.
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.
ClientView
193
Network Indicator
Use this to set filter rules 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 -> New Network Indicator.
MSP
194
Network Interface
Allows you to configure a network interface such as, a Network File System (NFS) client, on a control, data, or signaling port.
Accessing This Pane
Cantata MSP EMS -> Logical MSP -> Physical MSP -> New Network Interfaces-> New Network Interface
ClientView Pane
Field Descriptions
Physical Interface
This interface is the CPU profile.
Logical Interface
Choices:
Redundant Control
Redundant Data
Address Type
The only address type used is IP V4.
ClientView
195
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
MSP
196
Network Interfaces
This object is used to create a network interface. See Network Interface.
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> MSP Name -> New Network Interface
ClientView
197
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
MSP
198
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 Cantata 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.
ClientView
199
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.
MSP
200
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
NFS Server Pane
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 “\\”.
ClientView
201
NFS Server Display Table
This pane displays all of the NFS Servers configured.
MSP
202
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
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.
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.
ClientView
203
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
Clear Software
Download Raw File
Accessing this Pane
Cantata MSP EMS -> Logical MSP -> New Node -> Logical MSP Name
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
MSP
204
4. If you want to change the Resend Logic, select another option for the drop-down list.
If you see a STOP sign icon beside the physical node, this means that the license file failed. See License Information
ClientView
205
PVD and AMD Parameters
Use this object to change the PVD (Positive Voice Detection) and AMD (Answering Machine Detection) parameters on a DSP chip.
Accessing this Dialog Box
Cantata MSP EMS -> Logical MSP -> MSP Name -> New Media -> New PVD Answering Machine
Pane
MSP
206
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
ClientView
207
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
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
MSP
208
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.
ClientView
209
Remote User Part
To configure a remote user part you must have already configured an SS7 stack. See SS7 Stack.
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.
MSP
210
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.
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.
4. Select a Replicated SSN from the drop-down list.
5. Select a Priority from the drop-down list.
ClientView
211
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
MSP
212
SCCP/TCAP
Do the following to configure SCCP/TCAP.
Accessing This Pane
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.
ClientView
213
Now you can configure the sub-system number.
MSP
214
SCCP-TCAP Default Parameter Table
This table contains the default parameters used by SCCP and TCAP for all sub-systems associated with a stack.
Accessing This Pane
Physical MSP -> New Signaling -> Signaling -> New SS7 -> New SS7 Stack
-> New SCCP/TCAP -> New SCCP/TCAP Default Parameter Table.
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.
.
ClientView
215
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
MSP
216
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.
ClientView
217
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
Steps
1. Right-click Cantata 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.
MSP
218
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.
ClientView
219
Signaling Variants Object
This is a container for creating custom SS7 variants.
Accessing this Pane
Cantata MSP EMS -> New Signaling Variants
MSP
220
Multi-Host Socket
The MSP 1010 allows you to configure sockets for up to three hosts. The range of Logical Socket IDs is 0-2. The default Port Number 0 is assigned logical socket ID 12610 (0x3142). Port Number 1 and Port Number 2 can be assigned any logical socket ID: 1-65535.
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.
ClientView
221
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
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
MSP
222
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
This field specifies the primary or secondary physical MSP nodes in the case of a redundant configuration.
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.
SS7 Display Table
The table is not used for this object.
ClientView
223
MSP
224
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
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 displays in the right pane.
4. Enter a Group Name.
ClientView
225
SS7 Link
This object identifies an SS7 link within an SS7 link set to an APC. 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
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.
SS7 Link ClientView Pane
Field Descriptions
Primary/Secondary
This field specifies whether the SS7 link is supported by the primary or secondary physical MSP.
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.
MSP
226
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.
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
ClientView
227
SS7 Link Display Table
This table displays a list of the configured SS7 links under a specific SS7 Link set.
MSP
228
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.
Accessing this Pane
Configuration->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.
SS7 Link Set 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 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.
ClientView
229
SS7 Route
This pane defines a route to an SS7 destination (DPC).
Accessing this Pane
Configuration -> 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).
SS7 Route ClientView Pane
Field Descriptions
Route ID
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:
MSP
230
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
ClientView
231
SS7 Stack
Accessing this Pane
Configuration->Cantata MSP EMS-> Logical MSP-> Physical MSP-> SS7 -> SS7 Stack
Maximum SS7 Stack Objects
A maximum of four SS7 stacks can be configured.
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.
SS7 Stack 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.
SS7 Variant
This field specifies the variant used for the stack.
MSP
232
Choices:
Base Only
(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
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
Cause Location
This field specifies the location used while releasing the call.
Choices:
User
Local private network
Local public network
Transit network
ClientView
233
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
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.
MSP
234
SSN
To configure the sub-system number (SSN), do the following.
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.
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.
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.
Notes on Fields
Subsystem Number
Options for this field:
1 SCCP management
ClientView
235
2 reserved for ITU-T allocation
3 ISDN user part
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
reserved for international use (Choose from a range of values 15-31)
reserved for national networks (Choose from a range of values 32 - 254)
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.
MSP
236
Sub-system Number Default Parameter
Configure the default parameter table for a particular sub-system.
Accessing This Pane
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.
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.
ClientView
237
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
Pane
MSP
238
TCAP Object Syntax Descriptor
You can modify a TCAP object by indicating the TCAP object parameter ID, TCAP identifier, whether or not to update the object syntax and if updated, what the object syntax description is.
Accessing This Pane
Physical MSP -> New Signaling -> Signaling -> New SS7 -> New SS7 Stack
-> New SCCP/TCAP -> New TCAP Object Syntax Descriptor.
Steps
1. Right-click the SCCP/TCAP object.
2. Select New TCAP Object Syntax Descriptor.
3. Enter the Object Parameter ID (16 Bits).
4. Enter TCAP Identifier (16 Bits).
ClientView
239
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
Pane
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.
MSP
240
Options:
Primary
Secondary
Not Timing Source
Framing
Options:
D4 (Default)
ESF
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
The default is 100 Ohm.
Span Status
The Span Status is a monitoring field showing the status of the T1 span.
ClientView
241
Use the In Service button to bring a span into service.
Use the Out-of-Service button to take a span out-of-service.
MSP
242
TDM-DS1
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
243
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.
MSP
244
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
ClientView
245
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
This field is informational only.
MSP
246
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
Free Running
Second
ClientView
247
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
Secondary Reference
Primary Loop
Secondary Loop
MSP
248
Free Running
Timing Synchronization Priority List Display Table
The table is not used for this object.
ClientView
249
Variant Entry
This pane is used to add entries to a custom signaling variant.
NOTE: 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
The PPL component to be configured.
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
MSP
250
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 be default is:
Windows
C:\Program Files\Cantata\MSPSwitchKit\config\Variant\VariantName
Linux, Solaris, HP-UX
/opt/cantata/MSP/config/Variant/VariantName
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
ClientView
251
Vocabulary Index Entry
This pane is used to add announcement entries to a Vocabulary Index File.
Accessing this Dialog Box
Cantata MSP EMS-> Routing Configuration-> New Vocabulary Index Files-> New Vocabulary Index File -> New Vocabulary Index File Entry
Maximum Vocabulary Index Entry Objects
Vocabulary Index Entry Dialog Box
Field Descriptions
File Id
This field is automatically populated with the next available number.
File Description
Precise description of the file which will be sued to identify it in other panes.
Primary Server Id
The Primary NFS Server that the announcement is stored on.
Secondary Server Id
The Secondary NFS Server that the announcement is stored on.
File Name
The filename of the announcement.
File Format
MSP
252
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
File Length to be played
ClientView
253
Vocabulary Index File
This pane creates a new Vocabulary Index File, which is used to identify 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
Maximum Vocabulary Index File Objects
1
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 (msp_vocab.dat).
MSP
254
Vocabulary Index Files
This pane is a container for individual Vocabulary Index Files you create.
Accessing this Dialog Box
Cantata MSP EMS-> Routing Configuration-> New Vocabulary Index Files
Maximum Vocabulary Index Files Objects
ClientView
255
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.
Prerequisites (in order)
Network Interface
IP Bearer Profiles
Facility
Accessing this Pane
Configuration -> Cantata MSP EMS -> Facility -> Bearer-IP
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 the MSP 1010 is licensed for.
VoIP Module Client View Pane
Field Descriptions
Module ID
MSP
256
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 IMG 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
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.
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
Notify Host of Answer
Propagate Answer to Distant End and 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.
VoIPModule Display Table
ClientView
257
This table displays the status of the IP address /port numbers corresponding to the configured VoIP channels.
259
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
MSP
260
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.
Next Topic
Forcing a Log File to Roll-Over
EventView
261
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
MSP
262
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.
263
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
remove users
assign roles
change passwords
self reset password
list one or all users
display current user information
Basic
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
Allowed to view configuration attributes and system events (alarms, and traps). Every user is assigned with this role by default.
Provision
Allowed to bring components in and out of service.
Configuration
MSP
264
Allowed to modify configuration on the MSP.
Default Administrator Information
By default there is one user, admin, with the following roles assigned:
User Management Domain
Administrator
Equipment Management Domain
- 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 localhost
127.0.0.1 localhost.localdomain localhost
ClientView Log In
When a user launches ClientView, they are prompted for a Username and Password. The default is admin/admin.
Admin Commands
Re-installation of Software
User account information remains through a re-installation of the MSP system software.
AdminView
265
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
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, Solaris, HP-UX
/opt/cantata/MSP/switchkit/bin
2. Open AdminView, which by default is located in:
Windows
C:\Program Files\Cantata\MSPSwitchKit\switchkit\bin
Linux, Solaris, HP-UX
/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.
MSP
266
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
3 - Configuration
4 - Provisioning
5 - Monitor
f. 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.
AdminView
267
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, Solaris, and HP-UX: /opt/cantata/MSP/switchkit/bin Windows: C:\Program Files\Cantata\MSPSwitchKit\switchkit\bin
Start AdminView
To start AdminView do the following:
1. For Solaris, Linux, or HP-UX:
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:
C:\Program Files\Cantata\MSPSwitchKit\switchkit\bin
2. 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.
MSP
268
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:
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:
AdminView
269
1. Type rmusr and press ENTER.
2. Enter the user ID and press ENTER.
Also see Viewing User Information
MSP
270
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:
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.
AdminView
271
Your user ID and your assigned roles are displayed, as shown below:
List All Commands
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.
MSP
272
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"?>
<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
AdminView
273
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
275
Intelligent Network & Wireless Protocols Overview
Introduction
As software developers create more applications that are being deployed and maintained in mobile and intelligent networks, Excel is keeping pace by introducing support for intelligent network (IN) and wireless protocols in the MSP 1010. Excel’s 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 Excel 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
MSP 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)
Universal Mobile Telecommunications System- Mobile Application Part (UMTS- MAP) which includes Global System for Mobile communication - Mobile Application Part (GSM-MAP)
Intelligent Network Application Protocol (INAP)
TIA/ANSI standard
ANSI - 41
Wireless Intelligent Network (WIN)
AIN (planned for future availability)
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 Excel Switching Corporation):
CAMEL User’s Guide, document part number P_EXCL_CAMEL_UG_2.0
UMTS MAP User’s Guide, document part number P_EXCL_UMTS_MAP_UG_2.0
WIN User’s Guide, document part number P_EXCL_WIN_UG_2.0
ANSI 41D User’s Guide, document part number P_EXCL_AS41D_UG_2.0
MSP
276
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
Excel 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’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
Intelligent Network & Wireless Protocols Overview
277
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.
MSP
278
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
LLC
SS7
Intelligent Network & Wireless Protocols Overview
279
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:
Hardware/Operating System Requirements
Operating System
IN & Wireless Protocols are supported on...
Solaris Version 8.0 for the SPARC platform
Linux Red Hat Linux version 8.0 for INTEL platform
HP-UX 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...
Solaris Sun Forte (Sun Workshop 6, update 2 C++ 5.3)
Linux GNU gcc complier packaged with Red Hat Linux 8.0 (gcc 3.2)
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.
MSP
280
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. 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 switch-based 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 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 & Wireless Protocols Overview
281
Intelligent Network and Wireless Protocols
This section describes Excel’s software support for mobile and wireline communications networks. The Intelligent Network (IN) and wireless protocols offered by Excel were developed by IntelliNet Technologies, a leading provider of IN infrastructure software. MSP supports five IntelliNet protocols to access IN and wireless networks:
Codecs
Codec Name Description Standard
Customized Application for Mobile network Enhanced Logic (CAMEL)
Phase 2, 3, & 4
3GPP TS 29.078 (v5.1.0 Release 5)
Universal Mobile Telecommunications System - Mobile Application Part (UMTS-MAP) which includes Global System for Mobile communication - Mobile Application Part (GSM-MAP)
Phase 1,2,2+, & 3
UMTS MAP - 3GPP TS 29.002 V4.2.1 (2000-12)
3G TS 29 002 v3.4.0 (2000-3)
Wireless Intelligent Network (WIN) Phase I & II TIA/EIA/IS 771
TIA/EIA/IS 826
ANSI - 41 ANSI - 41D TIA/EIA-41.(1-6) D Dec 1997
Intelligent Network Application Protocol (INAP) CS-1
CS-1
CS-2
ITU-T Q.1218, release 1095
ITU-T Q.1228, release 997
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
Personal Numbering
Location dependent services
UMTS/GSM-MAP
MSP
282
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)
Typical applications include:
Intelligent Peripheral (IP)
Service Control Point (SCP)
Enhanced Services Platform
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 Services
Voice-Controlled Dialing (VCD)
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
Intelligent Network & Wireless Protocols Overview
283
message service. All wireless network elements use this messaging protocol to communicate.
Typical applications include:
Intelligent Peripheral (IP)
Service Control Point (SCP)
Enhanced Services Platform
INAP
Intelligent Network Application Protocol (INAP), an ITU-T specification, allows applications to communicate between various nodes/functional entities of a wireline 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
Excel 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
Virtual Private Network Services for closed user groups operating over geographically distributed facilities
Universal Access Number (UAN)
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.
MSP
284
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 are orderable through Cantata sales, and are based on the following customer-supplied information:
Chassis ID
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 sales.
Intelligent Network & Wireless Protocols Overview
285
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
A simple API to handle TCAP operations
Dialogue ID allocation and management capabilities
Error handling and detection capability for transaction level protocol errors that can be handled transparently
Notification and alarm generation mechanism to the application
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
The required codecs
SwitchKit
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()
MSP
286
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.
Formats the TCAP messages into a message list
Keeps track of active TCAP dialogs
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
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
The required codecs
SwitchKit API
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::Terminate()
SKIM_Api::Send()
SKIM_Api::SendSSNInService()
SKIM_Api::SendSSNOutOfService()
SKIM_Api::SendReject()
SKIM_Api::CancelOperation()
Intelligent Network & Wireless Protocols Overview
287
SKIM_Api::SendPreArrangedEnd()
SKIM_Api::SetTransHandler()
SKIM_Api::ClearTransHandler()
SKIM_Api::EnableTracing()
SKIM_Api::DisableTracing()
MSP
288
Wireless Call Flow
Purpose
The next call flow provides an example of an SMSC application sending and receiving SMS.
289
SwitchKit Installation & Maintenance
Introduction
SwitchKit
SwitchKit 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.
SwitchKit greatly reduces the time and cost in the deploying and maintaining switch-based 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 — MSP — 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 Excel hardware. As a result, applications can make better and more efficient use of Excel resources.
MSP
290
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
Communications
Message Management
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 Installation & Maintenance
291
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)
SwitchManager
DataManager
Application Programming Interface (API)
AdminManager
ClientView
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
MSP
292
TCP/IP.
SwitchKit Installation & Maintenance
293
LLC - The Low-Level Communicator
The LLC
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
Calculating checksums
Handling special characters
Message and error logging
Intelligent channel allocation
Socket management
Connections to multiple switches
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.
MSP
294
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 Installation & Maintenance
295
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 Excel’s 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.
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.
MSP
296
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, code-intensive 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 section 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.
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
SwitchKit Installation & Maintenance
297
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.
MSP
298
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...
Solaris Version 10.0 for the SPARC platform
Linux Red Hat Enterprise Linux ES 3.0
HP-UX Version 11.0 patched as required for development
Windows/2000 Service pack 2 or greater
Windows/XP Service pack 2 or greater
SwitchKit Development Environment
The next table shows the compilers supported by SwitchKit in a development environment.
Compiler Requirements
Operating System
SwitchKit applications must be built using...
Solaris Forte 6.2 or GNU gcc 3.4.3
Linux RedHat ES 3 w/ gcc 3.2.3 20030502
Kernel: 2.4.21-27.0.2.EL #1
HP-UX ACC 3.37 (Shared library w/-AA)
Two versions of SwitchKit API are provided, one to support applications using the –AA flag, and one to support applications not using the –AA flag.
If you are using the –AA compiler flag, the following patch must be installed:
For HP-UX 11.0, install the patch PHSS_26945 1.0 HP aC++ -AA runtime libraries (aCC A.03.37).
If you are using ClientView and EventView, the following
SwitchKit Installation & Maintenance
299
patches are required:
If you have a HP-UX version 11.00 then download and install patch PHCO_29959 from
Location: http://h18012.www1.hp.com/java/patches/g-11.00-1.4-1100.0309.html
If you have a HP-UX version 11.11 then download and install patch PHCO_29959 from
Location : http://h18012.www1.hp.com/java/patches/g-11.11-1.4-1111.0406.html
Windows/2000 MS Visual Studio C++ 6.0
Windows/XP MS Visual Studio C++ 6.0
ClientView
The ClientView works in conjunction with SwitchKit. The ClientView is available on all SwitchKit-supported platforms.
MSP
300
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
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 Installation & Maintenance
301
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 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.
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
MSP
302
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
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 installation script and zip file reside on 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 HP/UX: hpux.bin
4. Type the following exactly:
./solsparc.bin for Solaris
./linux.bin for Linux
./hpux.bin for HP-UX
5. Select the installation directory. The default directory is:
/opt/cantata/MSP
This will be referred to as $INSTALL_DIR.
Important! When following the last instruction replace $INSTALL_DIR with your actual installation directory.
6. Select the install set indicating the version of Switchkit API: Threadsafe or Standard.
7. 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/switchkit/bin SwitchKit executable files
$INSTALL_DIR/switchkit/lib SwitchKit development libraries
SwitchKit Installation & Maintenance
303
$INSTALL_DIR/switchkit/include SwitchKit development header files
$INSTALL_DIR/switchkit/samples Contains sample configuration files
$INSTALL_DIR/switchkit/reports Stores report output files
/opt/cantata/common/treatment Contains vocabulary index files
/opt/cantata/common/stats Stores the statistics files collected per object
/opt/cantata/common/config Holds configuration files
/opt/cantata/common/license Folder where MSP 1010 looks for current licenses
/opt/cantata/common/backup Stores backup log and configuration files
/opt/cantata/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 connect to the LLC.
The contents of the /etc/hosts file should look like:
127.0.0.1 localhost.localdomain localhost
IP_Address hostname
Where IP_Address is the IP address of the UNIX machine: hostname is the hostname of UNIX machine.
NOTE: do not remote or edit the 127.0.0.1 entry in the /etc/hosts file
MSP
304
Installing Profiles on UNIX Hosts
For SwitchKit to function properly on Linux, Solaris and HP-UX you must source this file:
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 start-up 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 grep SK_ .*
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
C Shell .cshrc
Bourne Shell .profile
Korn Shell .kshrc
TC Shell .tcshrc
SwitchKit Installation & Maintenance
305
3. Add the command displayed at the end of the installation of SwitchKit and MSP user interface (ClientView) to the end of the shell startup file. These commands will look something like this:
./opt/cantata/MSP/switchkit/excel_profile
4. Log out and log back in.
If you have properly sourced this startup script, you should see this message displayed each time you open a terminal window on Linux, Solaris or HP-UX:
Running Excel Switching Corporation's shell startup script
If you do not see this message, the excel_profile is not sourced properly and therefore, SwitchKit and the ClientView will not work properly.
MSP
306
Installing SwitchKit on Windows
Purpose
This procedure guides you through the SwitchKit installation.
Default directory
The SwitchKit default installation directory is:
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 self-extracting executable.
5. While you are installing SwitchKit, the switch configuration dialog box is invoked. See the next screen shot.
SwitchKit Installation & Maintenance
307
6. 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. Use the browse button to set up the SwitchManager Configuration File. Click OK.
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.
7. Follow the instructions on the screen to complete the installation.
8. Reboot your machine if prompted.
SwitchKit is now installed with all of its components:
LLC
SwitchManager
DataManager
AdminManager
MSP
308
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.
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
SwitchKit Installation & Maintenance
309
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:
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.
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.
MSP
310
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 yellow S above the LLC indicates the LLC on this machine is the redundant LLC.
a red I above the LLC indicates the LLC on this machine is initializing.
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.
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 messages.log with Notepad
View maintenance.log
View maintenance.log with Notepad
SwitchManager Logs
SwitchKit Installation & Maintenance
311
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
MSP
312
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.
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
12. Click Apply and then OK.
SwitchKit Installation & Maintenance
313
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:
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.
MSP
314
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:
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"
SwitchKit Installation & Maintenance
315
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 section.
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
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
MSP
316
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.
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).
SwitchKit Installation & Maintenance
317
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.
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
MSP
318
SK_DISABLE_FILE_ ROLLOVER_LOGGING
SK_DISABLE_FILE_ROLLOVER_LOGGING disables the printing of the switch mid-plane 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
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
SwitchKit Installation & Maintenance
319
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)
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
MSP
320
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
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.
SwitchKit Installation & Maintenance
321
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.
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
MSP
322
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)
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
SwitchKit Installation & Maintenance
323
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
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)
MSP
324
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
0 default
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.
1 SB_MANUAL_MODE Whichever LLC is currently active will remain active until told to 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
SwitchKit Installation & Maintenance
325
SK_LOG_LEVEL specifies the EXS API message logging to be done by LLC. The possible options are to log to:
socket.log
messages.log
and/or the screen output
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 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
MSP
326
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
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
SwitchKit Installation & Maintenance
327
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 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
MSP
328
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
0 default
SIP_UA_BROADCAST No load sharing. Sends to all registered applications.
1 SIP_UA_RANDOMIZE Sends to one randomly selected application.
2 SIP_UA_ROUNDROBIN 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.
SK_SOCKET_VALIDATE_WAIT
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)
SwitchKit Installation & Maintenance
329
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
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
MSP
330
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
SwitchKit Installation & Maintenance
331
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\MSPSwitchKit\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.
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\MSPSwitchKit\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.
MSP
332
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\MSPSwitchKit\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.
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\MSPSwitchKit\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.
SwitchKit Installation & Maintenance
333
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 section 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.
MSP
334
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.
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.
SwitchKit Installation & Maintenance
335
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.
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 with ClientView
Do the following to start the LLC:
1. Go to the Start button, select All Programs->Excel Switching Corporation
-> SwitchKit -> 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 without ClientView
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\MSPSwitchKit\switchkit\bin
1. Type llc and specify the start-up argument, if desired. You can use multiple arguments together. See the LLC Arguments.
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.
MSP
336
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
-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>
SwitchKit Installation & Maintenance
337
Example
llc -v
Argument -h
Help
Displays a list all of the available arguments for the LLC.
Syntax
-h <no value>
Example
llc -h
MSP
338
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 are propagated from one initial problem. By fixing the initial problem, subsequent alarms may be eliminated as well
SwitchKit Installation & Maintenance
339
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\\Excel Switching Corporation\MSPSwitchKit\license
Linux, Solaris, HP-UX
/opt/excel/MSP/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\MSPSwitchKit\switchkit\bin
Linux, Solaris and HP-UX
/opt/excel/MSP/switchkit/bin
1. Type in:
switchmgr -i
MSP
340
4. SwitchManager will start and become active.
5. Minimize the Command Prompt window when you see the message:
fopen:No such file or directory.
SwitchKit Installation & Maintenance
341
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 an Excel 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
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
MSP
342
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
SwitchKit Installation & Maintenance
343
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
C:\Program Files\Cantata\MSPSwitchKit\license
Linux, Solaris, HP-UX
/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, Solaris and HP-UX
/opt/excel/MSP/switchkit/bin
3. Type in:
datamanager
MSP
344
SwitchKit Installation & Maintenance
345
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
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, Solaris, HP-UX
/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, Solaris and HP-UX
/opt/excel/MSP/switchkit/bin
3. Type in:
adminmanager
MSP
346
SwitchKit Installation & Maintenance
347
Redundancy Setup
SwitchKit Redundancy
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.
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 primary 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 the following environment variables:
SK_RLLC_HOST
SK_RLLC_PORT
These values must be set before the applications are run. They are only examined upon start-up. You cannot dynamically configure SwitchKit Redundancy. Please refer to Environment Variables Modify SwitchKit Default Behavior
MSP
348
Example
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.
SwitchKit Installation & Maintenance
349
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 Windows C:\Program Files\Cantata\MSPSwitchKit\switchkit\bin
o UNIX /opt/excel/MSP/switchkit/bin
o 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
Start Primary LLC on Host 1:
Windows Syntax llc
UNIX Syntax ./llc
Start redundant LLC on Host 2
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
MSP
350
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
SwitchKit Installation & Maintenance
351
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 MSP.
The primary SwitchManager, connected to the PLLC manages the node.
Any custom application, such as call processing applications and SNMP connected to the PLLC.
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 secondary SwitchManager, which takes over management of the node should the primary SwitchManager fail.
A second copy of the custom application. The LLC shares traffic between the two applications.
Line Key
In the following diagrams we use different lines to illustrate different states of the connection.
Solid Line
A solid line illustrates an established connection.
Bold Solid Line
A bold solid line illustrates a new established connection.
Dotted Line
A dotted line illustrates a lost connection.
SwitchKit Redundancy Setup
MSP
352
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.
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
SwitchKit Installation & Maintenance
353
connections to all matrices in the MSP 1010 and accepts connections from all applications.
MSP
354
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. 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.
SwitchKit Installation & Maintenance
355
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 Cantata technical support for assistance.
MSP
356
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...
Alarm SwitchManager
Maintenance LLC, SwitchManager, DataManager and each SwitchKit application
Messages LLC (optional)
Socket LLC (optional)
XMLClient DataManager
EventLog DataManager
Statmgr DataManager
User-defined
LLC (optional)
Alarm Log
File name: alarm.log
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_switchmgr.PID.log
maintenance_DataManager.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
SwitchKit Installation & Maintenance
357
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
=> ACK (acknowledgement) message
-> outbound or inbound message
H REQ LLC internal request manager
H LLC LLC internal module
H ART LLC internal artificial ACK, likely generated due to ACK timer expiration
H21 External Host Application Number 21
X2001 External Device with logical link value 2001 (200 = NodeType Call Server 1=node ID)
H LLC Host
UNKNN Unknown, the LLC was unable to resolve the sender. This should not happen.
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
MSP
358
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
X MSP 1010
1 Logical Node ID
[10.10.156.24] Socket IP address
H 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
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
SwitchKit Installation & Maintenance
359
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 0 Link is Up
3/8/2006 12:01
Node Info 1 Link is Up
3/8/2006 12:01
Node Info 0 HostAlarm(Software License Verified)
3/8/2006 12:01
Node Info 1 HostAlarm(Software License Verified)
3/8/2006 12:01
Node Info 0 HostAlarm(Software Version Matched)
3/8/2006 12:01
Node Info 1 HostAlarm(Software Version Matched)
Statmgr Log
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.
MSP
360
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.
SwitchKit Installation & Maintenance
361
ServerStatusChange
Type
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);
MSP
362
UBYTE getMatrixState() const;
void setMatrixState(UBYTE x);
UBYTE getAdjMatrixState() const;
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:
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
SwitchKit Installation & Maintenance
363
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:
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:
MSP
364
MessageTrigger Argument Description
PhysicalNode Represents the requested Node ID
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 System Type(Poll Source) from PollMessage
MatrixSide Matrix Controller ID from PollMessage
SK_PM_CHANGE or SK_SSC_UPDATE
MatrixState Matrix State(Card State) from PollMessage
AdjMatrixState Adjacent Card State from PollMessage
StatusBits Card Status from PollMessage
ExcelPort Double Byte after Multi Host Connection Status Byte 2 in PollMessage
UpdatedFieldBits 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
SK_LINK_UP PhysicalNode Requested Node ID
or SK_LINK_DOWN
LogicalNode 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 Changed Argument in Server StatusChange message
SK_STATUS_CHANGE Status
SK_SYSTEMTYPE_CHANGE SystemType
SK_MATRIXSIDE_CHANGE MatrixSide
SK_MATRIXSTATE_CHANGE MatrixState
SK_ADJMATRIXSTATE_CHANGE AdjMatrixState
SK_STATUSBITS_CHANGE StatusBits
SwitchKit Installation & Maintenance
365
SK_LOGICALNODE_CHANGE LogicalNode
367
SwitchKit Programmer's Information
Addressing Functions
This section describes the Address Information Block (AIB) helper functions available in SwitchKit. It provides a description of what the function does, the syntax and the type of AIB used with a given function.
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()
setAIBStartChannel()
setAIBEndSpan()
setAIBEndChannel()
MSP
368
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 Syntax Threadsafe Syntax AIB used
getAIBSize int sk_getAIBSize(UBYTE *AIBBlock);
int skts_getAIBSIze
(UBYTE *AIBBlock)
All
setAIBRange void sk_setAIBRange( UBYTE *AIBBlock,
XBYTE aStartSpan,
UBYTE aStartChannel, XBYTE anEndSpan,
UBYTE anEndChan);
void skts_setAIBRange( UBYTE *AIBBlock,
XBYTE aStartSpan,
UBYTE aStartChannel,
XBYTE anEndSpan,
UBYTE anEndChan )
0x0D
Range of Channels
setAIBChannel void sk_setAIBChannelEntity(UBYTE *AIBBlock, XBYTE aSpan,
UBYTE aChannel);
void skts_setAIBChannelEntity
(UBYTE *AIBBlock,
XBYTE aSpan,
UBYTE aChannel)
0x0D Channel
getAIBStartSpan XBYTE sk_getAIBStartSpan
(const UBYTE *AIBBlock)
XBYTE skts_getAIBStartSpan(const UBYTE *AIBBlock)
0x0D
Range of Channels
setAIBStartSpan void sk_setAIBStartSpan( UBYTE *AIBBlock,
XBYTE aStartSpan)
void skts_setAIBStartSpan( UBYTE *AIBBlock,
XBYTE aStartSpan)
0x0D
Range of Channels
getAIBStartChannel UBYTE sk_getAIBStartChannel( const UBYTE *AIBBlock )
UBYTE skts_getAIBStartChannel( const UBYTE *AIBBlock )
0x0D
Range of Channels
setAIBStartChannel void sk_setAIBStartChannel( UBYTE *AIBBlock,
UBYTE aStartChannel )
void skts_setAIBStartChannel( UBYTE *AIBBlock,
UBYTE aStartChannel )
0x0D
Range of Channels
getAIBEndSpan XBYTE sk_getAIBEndSpan( const UBYTE *AIBBlock )
XBYTE skts_getAIBEndSpan( const UBYTE *AIBBlock )
0x0D
Range of Channels
setAIBEndSpan void sk_setAIBEndSpan( UBYTE *AIBBlock,
XBYTE anEndSpan )
void skts_setAIBEndSpan( UBYTE *AIBBlock,
XBYTE anEndSpan )
0x0D
Range of Channels
getAIBEndChannel UBYTE sk_getAIBEndChannel( const UBYTE *AIBBlock )
UBYTE skts_getAIBEndChannel( const UBYTE *AIBBlock )
0x0D
Range of
SwitchKit Programmer's Information
369
Channels
setAIBEndChannel void sk_setAIBEndChannel( UBYTE *AIBBlock,
UBYTE anEndChannel)
void skts_setAIBEndChannel( UBYTE *AIBBlock,
UBYTE anEndChannel)
0x0D
Range of Channels
getAIBSpanA XBYTE sk_getAIBSpanA(const UBYTE *AIBBlock )
XBYTE skts_getAIBSpanA(const UBYTE *AIBBlock )
0x0D
Channels with two AEs
setAIBSpanA void sk_setAIBSpanA( UBYTE *AIBBlock,
XBYTE aSpanA )
void skts_setAIBSpanA( UBYTE *AIBBlock,
XBYTE aSpanA )
0x0D
Channels with two AEs
getAIBChannelA UBYTE sk_getAIBChannelA( const UBYTE *AIBBlock )
UBYTE skts_getAIBChannelA( const UBYTE *AIBBlock )
0x0D
Channels with two AEs
setAIBChannelA void sk_setAIBChannelA( UBYTE *AIBBlock
UBYTE aChannelA)
void skts_setAIBChannelA( UBYTE *AIBBlock,
UBYTE aChannelA )
0x0D
Channels with two AEs
getAIBSpanB XBYTE sk_getAIBSpanB( const UBYTE *AIBBlock )
XBYTE skts_getAIBSpanB( const UBYTE *AIBBlock )
0x0D
Channels with two AEs
setAIBSpanB void sk_setAIBSpanB( UBYTE *AIBBlock,
XBYTE aSpanB)
void skts_setAIBSpanB( UBYTE *AIBBlock,
XBYTE aSpanB)
0x0D
Channels with two AEs
getAIBChannelB UBYTE sk_getAIBChannelB( const UBYTE *AIBBlock )
UBYTE skts_getAIBChannelB( const UBYTE *AIBBlock)
0x0D
Channels with two AEs
setAIBChannelB void sk_setAIBChannelB( UBYTE *AIBBlock,
UBYTE aChannelB )
void skts_setAIBChannelB( UBYTE *AIBBlock,
UBYTE aChannelB )
0x0D
Channels with two AEs
getAIBSpan XBYTE sk_getAIBSpan( const UBYTE *AIBBlock )
XBYTE skts_getAIBSpan( const UBYTE *AIBBlock )
0x0C
Logical Span
OR
MSP
370
0x0D
Channel
OR
0x3C
Number of CICs
setAIBSpan void sk_setAIBSpan( UBYTE *AIBBlock,
XBYTE aSpan )
void skts_setAIBSpan( UBYTE *AIBBlock, XBYTE aSpan)
0x0C
Logical Span
OR
0x0D
Channel
OR
0x3C
Number of CICs
getAIBChannel UBYTE sk_getAIBChannel( const UBYTE *AIBBlock )
UBYTE skts_getAIBChannel( const UBYTE *AIBBlock)
0x0D
ChannelOR
0x3C
Number of CICs
setAIBChannel void sk_setAIBChannel( UBYTE *AIBBlock," UBYTE aChannel)
void skts_setAIBChannel( UBYTE *AIBBlock,
UBYTE aChannel)
0x0D
ChannelOR
0x3C
Number of CICs
getAIBNumChannels UBYTE sk_getAIBNumChannels( const UBYTE *AIBBlock )
UBYTE skts_getAIBNumChannels( const UBYTE *AIBBlock )
0x3C
Number of CICs
setAIBNumChannels void sk_setAIBNumChannels( UBYTE *AIBBlock,
UBYTE aNumChannels)
void skts_setAIBNumChannels( UBYTE *AIBBlock,
UBYTE aNumChannels)
0x3C
Number of CICs
getAIBSlot UBYTE sk_getAIBSlot( const UBYTE *AIBBlock )
UBYTE skts_getAIBSlot( const UBYTE *AIBBlock )
0x01
Slot
setAIBSlot void sk_setAIBSlot( UBYTE *AIBBlock, UBYTE aSlot )
void skts_setAIBSlot( UBYTE *AIBBlock, UBYTE aSlot )
0x01
Slot
SwitchKit Programmer's Information
371
setAIBDSPChip void sk_setAIBDSPChip( UBYTE *AIBBlock,
UBYTE x)
void skts_setAIBDSPChip( UBYTE *AIBBlock,
UBYTE x)
0x22
DSP Chip
getAIBDSPSlot UBYTE sk_getAIBDSPSlot( const UBYTE *AIBBlock )
UBYTE skts_getAIBDSPSlot( const UBYTE *AIBBlock )
0x12
DSP SIMM
setAIBDSPSlot void sk_setAIBDSPSlot( UBYTE *AIBBlock,
UBYTE aDSPSlot )
void skts_setAIBDSPSlot( UBYTE *AIBBlock,
UBYTE aDSPSlot )
0x12
DSP SIMM
getAIBDSPSIMM UBYTE sk_getAIBDSPSIMM( const UBYTE *AIBBlock )
UBYTE skts_getAIBDSPSIMM( const UBYTE *AIBBlock )
0x12
DSP SIMM
setAIBDSPSIMM void sk_setAIBDSPSIMM( UBYTE *AIBBlock,
UBYTE aDSPSIMM )
void skts_setAIBDSPSIMM( UBYTE *AIBBlock,
UBYTE aDSPSIMM )
0x12
DSP SIMM
getAIBSIMM UBYTE sk_getAIBSIMM( const UBYTE *AIBBlock )
UBYTE skts_getAIBSIMM( const UBYTE *AIBBlock )
0x12
DSP SIMM
setAIBSIMM void sk_setAIBSIMM( UBYTE *AIBBlock, UBYTE aSIMM )
void skts_setAIBSIMM( UBYTE *AIBBlock, UBYTE aSIMM )
x12
DSP SIMM
getAIBDS3 UBYTE sk_getAIBDS3( const UBYTE *AIBBlock )
UBYTE skts_getAIBDS3( const UBYTE *AIBBlock )
0x32
DS3 Offset
setAIBDS3 void sk_setAIBDS3( UBYTE *AIBBlock,
UBYTE aDS3 )
void skts_setAIBDS3( UBYTE *AIBBlock, UBYTE aDS3 )
0x32
DS3 Offset
getAIBV5ID XBYTE sk_getAIBV5ID( const UBYTE *AIBBlock )
XBYTE skts_getAIBV5ID( const UBYTE *AIBBlock )
0x2C
V5 ID
setAIBV5ID void sk_setAIBV5ID( UBYTE *AIBBlock,
XBYTE aV5ID )
void skts_setAIBV5ID( UBYTE *AIBBlock, XBYTE aV5ID )
0x2C
V5 ID
getAIBRouterHandle XBYTE sk_getAIBRouterHandle( const UBYTE *AIBBlock )
XBYTE skts_getAIBRouterHandle( const UBYTE *AIBBlock )
0x29
Router
setAIBRouterHandle void sk_setAIBRouterHandle( UBYTE *AIBBlock,
XBYTE aRouterHandle )
void skts_setAIBRouterHandle( UBYTE *AIBBlock,
XBYTE aRouterHandle )
0x29
Router
getAIBChannelSlot UBYTE sk_getAIBChannelSlot(const UBYTE *AIBBlock)
UBYTE skts_getAIBChannelSlot(const UBYTE *AIBBlock)
0x01
Slot
setAIBChannelSlot void sk_setAIBChannelSlot(UBYTE
void skts_setAIBChannelSlot(UBYTE
0x01
MSP
372
*addrInfo,
UBYTE x)
*addrInfo,
UBYTE x)
Slot
getAIBSlotB XBYTE sk_getAIBSlotB(const UBYTE *AIBBlock)
XBYTE skts_getAIBSlotB(const UBYTE *AIBBlock)
0x01
Slot
setAIBSlotB void sk_setAIBSlotB(UBYTE *addrInfo, XBYTE x)
void skts_setAIBSlotB(UBYTE *addrInfo, XBYTE x)
0x01
Slot
SwitchKit Programmer's Information
373
SS7 Addressing Functions
To assist with the standard state machines, the SwitchKit API allows for incoming messages to be automatically dispatched to an application.
Name Syntax Threadsafe Syntax
getAIBSubrate UBYTE sk_getAIBSubrate( const UBYTE *AIBBlock )
UBYTE skts_getAIBSubrate( const UBYTE *AIBBlock )
setAIBSubrate void sk_setAIBSubrate( UBYTE *AIBBlock,
UBYTE aSubrate )
void skts_setAIBSubrate( UBYTE *AIBBlock,
UBYTE aSubrate )
setAIBSubrateEntity void sk_setAIBSubrateEntity( UBYTE *AIBBlock, XBYTE aSpan,
UBYTE aChannel,
UBYTE aSubrate )
void skts_setAIBSubrateEntity( UBYTE *AIBBlock, XBYTE aSpan,
UBYTE aChannel,
UBYTE aSubrate )
getAIBTerminal UBYTE sk_getAIBTerminal( const UBYTE *AIBBlock )
*/ UBYTE skts_getAIBTerminal( const UBYTE *AIBBlock );*/
setAIBTerminal void sk_setAIBTerminal( UBYTE *AIBBlock,
UBYTE aTerminal)
void skts_setAIBTerminal( UBYTE *AIBBlock,
UBYTE aTerminal)
setAIBTerminalEntity void sk_setAIBTerminalEntity(UBYTE *AIBBlock, XBYTE aSpan,
UBYTE aChannel,
UBYTE aSubrate,
UBYTE aTerminal)
void skts_setAIBTerminalEntity(UBYTE *AIBBlock, XBYTE aSpan,
UBYTE aChannel,
UBYTE aSubrate,
UBYTE aTerminal)
getAIBProfile UBYTE sk_getAIBProfile( const UBYTE *AIBBlock)
UBYTE skts_getAIBProfile( const UBYTE *AIBBlock)
setAIBProfile void sk_setAIBProfile( UBYTE *AIBBlock,
UBYTE aProfile )
void skts_setAIBProfile( UBYTE *AIBBlock,
UBYTE aProfile )
getAIBCallReference UBYTE sk_getAIBCallReference( const UBYTE *AIBBlock )
UBYTE skts_getAIBCallReference(const UBYTE *AIBBlock )
setAIBCallReference void sk_setAIBCallReference(UBYTE *AIBBlock, UBYTE aCallReference)
void skts_setAIBCallReference(UBYTE *AIBBlock, UBYTE aCallReference)
setAIBCallReferenceEntity void sk_setAIBCallReferenceEntity
void skts_setAIBCallReferenceEntity
MSP
374
(UBYTE *AIBBlock, UBYTE aSlot,
UBYTE aProfile,
UBYTE aSubrate,
UBYTE aCallReference)
(UBYTE *AIBBlock,
UBYTE aSlot,
UBYTE aProfile,
UBYTE aSubrate,
UBYTE aCallReference)
getAIBBaseCICNumber int sk_getAIBBaseCICNumber( const UBYTE *AIBBlock )
int skts_getAIBBaseCICNumber( const UBYTE *AIBBlock )
setAIBBaseCICNumber void sk_setAIBBaseCICNumber(UBYTE *AIBBlock,
int aBaseCICNumber)
void skts_setAIBBaseCICNumber(UBYTE *AIBBlock,int aBaseCICNumber)
getAIBBaseCICSpan XBYTE sk_getAIBBaseCICSpan( const UBYTE *AIBBlock)
XBYTE skts_getAIBBaseCICSpan( const UBYTE *AIBBlock)
setAIBBaseCICSpan void sk_setAIBBaseCICSpan
(UBYTE *AIBBlock,
XBYTE aCICSpan)
void skts_setAIBBaseCICSpan(UBYTE *AIBBlock, XBYTE aCICSpan)
getAIBBaseCICChannel UBYTE sk_getAIBBaseCICChannel(const UBYTE *AIBBlock)
UBYTE skts_getAIBBaseCICChannel(const UBYTE *AIBBlock)
setAIBBaseCICChannel void sk_setAIBBaseCICChannel(UBYTE *AIBBlock, UBYTE aCICChannel)
void skts_setAIBBaseCICChannel(UBYTE *AIBBlock, UBYTE aCICChannel)
getAIBNumCICs UBYTE sk_getAIBNumCICs( const UBYTE *AIBBlock )
UBYTE skts_getAIBNumCICs( const UBYTE *AIBBlock )
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 )
setAIBV5ID void sk_setAIBV5IDAndLink( UBYTE *AIBBlock, unsigned short aV5ID, UBYTE aLinkID )
void skts_setAIBV5IDAndLink( UBYTE *AIBBlock, unsigned short aV5ID, UBYTE aLinkID )
setAIBV5IDAndUserPort void sk_setAIBV5IDAndUserPort( UBYTE *AIBBlock, unsigned short
void skts_setAIBV5IDAndUserPort( UBYTE *AIBBlock, unsigned short
SwitchKit Programmer's Information
375
aV5ID, unsigned short aUserPort) aV5ID, unsigned short aUserPort)
getAIBStackID UBYTE sk_getAIBStackID
(const UBYTE *AIBBlock )
UBYTE skts_getAIBStackID
(const UBYTE *AIBBlock)
setAIBStackID void sk_setAIBStackID( UBYTE *AIBBlock,
UBYTE aStackID)
void skts_setAIBStackID( UBYTE *AIBBlock,
UBYTE aStackID)
getAIBLinkID UBYTE sk_getAIBLinkID( const UBYTE *AIBBlock )
UBYTE skts_getAIBLinkID( const UBYTE *AIBBlock )
setAIBLinkID void sk_setAIBLinkID( UBYTE *AIBBlock,
UBYTE aLinkID)
void skts_setAIBLinkID( UBYTE *AIBBlock,
UBYTE aLinkID)
setAIBStackEntity void sk_setAIBStackEntity( UBYTE *AIBBlock,
UBYTE aStackID,
UBYTE aLinkID)
void skts_setAIBStackEntity(UBYTE *AIBBlock,
UBYTE aStackID,
UBYTE aLinkID)
getAIBObjectInstanceID XBYTE sk_getAIBObjectInstanceID(const UBYTE *AIBBlock)
XBYTE skts_getAIBObjectInstanceID(const UBYTE *AIBBlock)
setAIBObjectInstanceID void sk_setAIBObjectInstanceID( UBYTE *AIBBlock, XBYTE anObjectInstanceID)
void skts_setAIBObjectInstanceID( UBYTE *AIBBlock, XBYTE anObjectInstanceID)
getAIBObjectType XBYTE sk_getAIBObjectType( const UBYTE *AIBBlock )
XBYTE skts_getAIBObjectType( const UBYTE *AIBBlock )
setAIBObjectType void sk_setAIBObjectType( UBYTE *AIBBlock,
XBYTE anObjectType)
void skts_setAIBObjectType( UBYTE *AIBBlock,
XBYTE anObjectType)
getAIBModule UBYTE sk_getAIBModule( const UBYTE *AIBBlock )
UBYTE skts_getAIBModule( const UBYTE *AIBBlock )
setAIBModule void sk_setAIBModule( UBYTE *AIBBlock,
UBYTE aModule)
void skts_setAIBModule( UBYTE *AIBBlock,
UBYTE aModule)
getAIBAssignSpanSlot UBYTE sk_getAIBAssignSpanSlot( const UBYTE *AIBBlock )
UBYTE skts_getAIBAssignSpanSlot( const UBYTE *AIBBlock )
setAIBAssignSpanSlot void sk_setAIBAssignSpanSlot(UBYTE *AIBBlock, UBYTE
void skts_setAIBAssignSpanSlot(UBYTE *AIBBlock, UBYTE
MSP
376
anAssignSpanSlot ) anAssignSpanSlot )
getAIBAssignSpanOffset UBYTE sk_getAIBAssignSpanOffset( const UBYTE *AIBBlock )
UBYTE skts_getAIBAssignSpanOffset( const UBYTE *AIBBlock )
setAIBAssignSpanOffset void sk_setAIBAssignSpanOffset( UBYTE *AIBBlock, UBYTE anAssignSpanOffset)
void skts_setAIBAssignSpanOffset( UBYTE *AIBBlock, UBYTE anAssignSpanOffset)
getAIBExpandedNode XBYTE sk_getAIBExpandedNode( const UBYTE *AIBBlock )
XBYTE skts_getAIBExpandedNode( const UBYTE *AIBBlock )
setAIBExpandedNode void sk_setAIBExpandedNode( UBYTE *AIBBlock,
XBYTE anExpandedNode)
void skts_setAIBExpandedNode( UBYTE *AIBBlock,
XBYTE anExpandedNode)
getAIBConferenceID XBYTE sk_getAIBConferenceID( const UBYTE *AIBBlock )
XBYTE skts_getAIBConferenceID( const UBYTE *AIBBlock )
setAIBConferenceID void sk_setAIBConferenceID( UBYTE *AIBBlock,
XBYTE aConferenceID)
void skts_setAIBConferenceID( UBYTE *AIBBlock, XBYTE aConferenceID)
SwitchKit Programmer's Information
377
Connection Management Functions
Applications Connecting to Multiple LLCs
Description
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.
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.
Functions in this Model
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().
MSP
378
Applications Connecting to One LLC
Description
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.
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 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 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.
Functions in this Model
int sk_initializeConnection();
int sk_initializeForcedConnection();
int sk_closeConnection();
int sk_getLLCSocketDescriptor();
int sk_getConnectionName();
SwitchKit Programmer's Information
379
Connecting Legacy Applications to Multiple LLCs
Description
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 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();
MSP
380
Introduction to Connection Management
Description
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.
SwitchKit Programmer's Information
381
List of SwitchKit APIs
The API messaged listed below are used in connection models. These API messages are found in the API Reference.
AppConnectionQuery
AppPopulationQuery
Connect 0x0000
Card Population Query 0x0007
MSP
382
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
anAppName This is meant to be a descriptive name for the application.
aShortName This is used to name the maintenance.log log file. It is not passed to the LLC.
AnAppVersion This string should describe the version of the application software.
aUserData This is stored by the SwitchKit API, but it is used only by the application.
APIs used in all Connection Models
SwitchKit Programmer's Information
383
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.
MSP
384
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 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.
SwitchKit Programmer's Information
385
sk_createConnection()
Description
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
aConID 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.
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().
anAppID 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.
isForcedFlag 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.
aPriHost The IP address of the primary LLC with the following format, for
MSP
386
example: "10.10.55.10"
aPriPort The IP port number the primary LLC the primary LLC is listening to.
aBackupHost 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.
aBackup 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();
SwitchKit Programmer's Information
387
sk_createConnectionWithID()
Description
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
The function parameters are shown in the table below.
Argument Description
aConID
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.
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().
anAppID 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.
isForcedFlag 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.
aPriHost: The IP address of the primary LLC with the following format, for example:
"10.10.55.10"
aPriPort: The IP port number the primary LLC the primary LLC is listening to.
MSP
388
aBackupHost: 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.
aBackup 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();
int sk_closeNamedConnection();
int sk_getLLCSocketDescriptorForConnection();
int sk_getConnectionNameForConnection();
int sk_getConnectionForID;
int sk_destroyConnectionForced();
int sk_appDescriptionData();
SwitchKit Programmer's Information
389
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.
MSP
390
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
SK_NO_CONNECT_AVAIL
This return indicates that all connections have been destroyed.
SwitchKit Programmer's Information
391
sk_getConnectionForID()
The function call sk_getConnectionForID() retrieves the SK_Connection object for the specified connection ID.
Syntax
SK_Connection *sk_getConnectionForID(int aConID);
MSP
392
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.
SwitchKit Programmer's Information
393
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.
MSP
394
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();
SwitchKit Programmer's Information
395
sk_getLLCSocketDescriptor()
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.
MSP
396
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.
SwitchKit Programmer's Information
397
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);
MSP
398
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);
SwitchKit Programmer's Information
399
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 Description
anAppID 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.
Return Values
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();
MSP
400
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
Message Functions
For more information on these functions, see Message Functions.
sk_rcvAndDispatchOnConnection
sk_rcvAndDispatchAutoStorageOnConnection
sk_rcvMessageOnConnection
sk_sendMessageOnConnection
sk_sendMessageWithHandlerOnConnection
SwitchKit Programmer's Information
401
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
MSP
402
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);
SwitchKit Programmer's Information
403
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.
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.
MSP
404
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.
SwitchKit Programmer's Information
405
AddLLCNode
Use SK_AddLLCNode at the initial configuration of your system and to dynamically add a node while LLC is running.
Description
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
Action Specifies if a node gets added (0 = default), updated (1), or deleted (2).
Matrix1 A text field corresponding to the IP address of the primary Matrix Controller.
Matrix2 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.
NodeType 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.
MSP
406
RequestedNode 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.
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;
SwitchKit Programmer's Information
407
C++ Class
class SKC_AddLLCNode : public SKC_ToolkitMessage {
public:
const char *getMatrix1() const;
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);
};
MSP
408
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
Providing a registration mechanism for SwitchKit applications to receive TCAP-related PPLEventIndication messages based on a combination of stack and Sub System Number (SSN).
Routing TCAP-related PPLEventIndication messages to the registered application with the lowest number of active dialogues
How to Keep Track of dialog States
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_A_SIDE - dialog ID has been allocated by an application using a PPLEventRequest message.
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.
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
Receive dialog
LLC Action
A Side B Side Event
B Side Event
TC-BEGIN X X Allocate
TC_QUERY_WITH_PERMISSION X X Allocate
TC_QUERY_WITHOUT_PERMISSION X X Allocate
TC_BEGIN_PRIMITIVE_SET X X Allocate
TC_QUERY_WITH_PERMISSION_PRIMITIVE_SET X X Allocate
SwitchKit Programmer's Information
409
TC_QUERY_WITHOUT_PERMISSION_PRIMITIVE_SET X X Allocate
TC_END X X Deallocate
TC_RESPONSE X X Deallocate
TC_RESULT_L X X Deallocate
TC_RESULT_NL X X Deallocate
TC_U_ERROR X X Deallocate
TC_L_CANCEL X X Deallocate
TC_INVOKE_L X X Deallocate
TC_INVOKE_NL X X Deallocate
TC_U_REJECT X X Deallocate
TC_L_REJECT X X Deallocate
TC_R_REJECT X X Deallocate
TC_INVOKE X X Deallocate
TC_RESPONSE X Deallocate
TC_END X Deallocate
TCAP_RESTART** X X Deallocate
TC_RESPONSE_PRIMITIVE_SET*** Deallocate
TC_END_PRIMITIVE_SET*** Deallocate
TC_P_ABORT*** X Deallocate
TC_DIALOGUE_TIMEOUT*** X Deallocate
TC_NOTICE*** X Deallocate
TC_TCAP_INITIATED_ABORT*** X Deallocate
TC_U_ABORT*** X 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
MSP
410
.
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 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;
SwitchKit Programmer's Information
411
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:
Local SSN
Adjacent Translator
Other Concerned Point Code
SCCP Default Parameter Table
SSN Default Parameter Table
TCAP Object Syntax Descriptor (OSD)
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)
Byte Field Description Byte Field Description
0 Frame (0xFE) 0 Frame (0xFE)
1, 2 Length (0xNNNN) 1, 2 Length (0x0007)
3, 4 Message Type (0x0077) 3, 4 Message Type (0x0077)
MSP
412
5 Reserved (0x00) 5 Reserved (0x00)
6 Sequence Number 6 Same Sequence Number
7 Logical Node ID 7 Logical Node ID
AIB
Address Method
8, 9 Status MSB, LSB
Number of AEs to follow 10 Checksum
8
AEs
9 Config Type
10 Number of TLVs
11 TLVs
: Data[0]
: :
: Checksum
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;
SwitchKit Programmer's Information
413
void setConfigType(UBYTE x);
const UBYTE *getData() const;
UBYTE *getData();
void setData(UBYTE *x);
};
EXS API Hex Format - Detailed
Message (White) Response (Grey)
Byte Field Description Byte Field Description
0 Frame (0xFE) 0 Frame (0xFE)
1, 2 Length (0xNNNN) 1, 2 Length (0x0007)
3, 4 Message Type (0x0077) 3, 4 Message Type (0x0077)
5 Reserved (0x00) 5 Reserved (0x00)
6 Sequence Number 6 Same Sequence Number
7 Logical Node ID 7 Logical Node ID
8 AIB
Address Method
0x00 - Individual AEs
8, 9 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
MSP
414
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 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
SwitchKit Programmer's Information
415
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.
2D - Index table needs to be built.
: Number of AEs to follow 10 Checksum
: AE
0x08 SS7 Stack
: Config Type
0x01 Local SSN
0x02 Adjacent Translator
0x03 Other Concerned Point Code
0x04 SCCP Default Parameter Table
0x05 SSN Default Parameter Table
0x06 TCAP Object Syntax Descriptor (OSD)
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 Section 4, Tag Length Blocks in the API Reference.
MSP
416
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
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
SwitchKit Programmer's Information
417
0x01 Add Other Concerned Point Code
0x02 Delete Other Concerned Point Code
Data[2-5] Other Concerned Point Code
0x04 SCCP/TCAP Default Parameter Table
Data[0] Option
0x01 Add/Modify SCCP/TCAP Default Parameter
0x02 Delete SCCP/TCAP Default Parameter
Data[1-2] Parameter Type
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
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 Channel Signaling for SCCP/TCAP Parameter Information.
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
MSP
418
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
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
SwitchKit Programmer's Information
419
TCAPMessageRegister
Description
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
OPC The Origination Point Code (Stack ID) of the SS7 TCAP stack generating the PPL Event Indications.
Stack Stack value
Stack_SSN a combination of Stack and SSN created by using the getSS7TCAP_MultiCard_RoutingID(Stack, SSN)macro
RegisterType 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 stack and subsystem number using the getSS7TCAP_MultiCard_RoutingID(stack,SSN) macro.
RegisterFlag 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;
MSP
420
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 ;
void setRegisterFlag(UBYTE x)
};
C++ Class Response
class SKC_TCAPMessageRegisterAck : public SKC_ToolkitAck {
public:
int getStatus() const;
void setStatus(int x);
};
SwitchKit Programmer's Information
421
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
Red Hat Linux, version 8.0
HP-UX, version 11.0
Solaris SPARC, version 8
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 sub-component routing are as follows:
The device must have a defined type which will be referred to as CardType.
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.
MSP
422
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
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 Section for configuring SS7 TCAP Routing.
SwitchKit Programmer's Information
423
Handler Functions
Handler Functions
This section describes the handler 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.
Handler Functions
Description
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
MSP
424
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
SwitchKit Programmer's Information
425
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;
}
MSP
426
sk_popChannelHandler()
Description
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
aSpan Specifies the span.
aChannel Specifies the channel.
aRtndTag Output parameter that will contain the tag value that was originally specified when the handler was pushed on the handler stack.
aRtndHandlerFunc 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.
SwitchKit Programmer's Information
427
sk_popDefaultHandler()
Description
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
The function parameters are shown in the table below.
Arguments Description
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc 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.
MSP
428
sk_popDefaultTCAPHandler()
Description
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
aTag Output parameter that will contain the tag value that was originally specified when the handler was pushed on the handler stack.
aRtndHandlerFunc 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.
SwitchKit Programmer's Information
429
sk_popTCAPHandler()
Description
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
aStackID Stack ID
anSSN Sub-system number
aRtndTag Output parameter that will contain the tag value that was originally specified when the handler was pushed on the handler stack.
aRtndHandlerFunc 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.
MSP
430
sk_pushChannelHandler()
Description
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);
Parameters
The function parameters are shown in the table below.
Arguments Description
aSpan Secifies the span
aChannel Specifies the channel.
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc A pointer to a function that is designed to handle messages.
Return Values
Always returns OK.
SwitchKit Programmer's Information
431
sk_pushDefaultHandler()
Description
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
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc 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.
MSP
432
sk_pushDefaultTCAPHandler()
Description
Use the sk_pushDefaultTCAPHandler() function to push aHandlerFunc onto the stack of default TCAP 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_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
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc A pointer to a function that is designed to handle messages.
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.
SwitchKit Programmer's Information
433
sk_pushTCAPHandler()
Description
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 Description
aStackID Stack ID
anSSN Sub-system number
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc A pointer to a function that is designed to handle messages.
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.
MSP
434
sk_removeChannelHandler()
Description
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
aSpan sp specifies the span.
aChannel ch specifies the channel.
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc 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.
SwitchKit Programmer's Information
435
sk_removeDefaultHandler()
Description
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
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc 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.
MSP
436
sk_removeDefaultTCAPHandler()
Description
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
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc A pointer to a function that is designed to handle messages.
Return Values
Possible return values for this function:
TRUE Always returns TRUE (1)
SwitchKit Programmer's Information
437
sk_removeLLCConnectionHandler()
Description
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
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.
aHandlerFunc A pointer to a function that is designed to handle messages.
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
MSP
438
sk_removeTCAPHandler()
Description
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
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
aStackID Stack ID
anSSN Subsystem number
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc A pointer to a function that is designed to handle messages.
Return Values
Possible return values for this function:
TRUE Always returns TRUE (1)
SwitchKit Programmer's Information
439
sk_setChannelHandler()
Description
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
aSpan Specifies the span.
aChannel Specifies the channel.
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc A pointer to a function that is designed to handle messages.
Return Values
Always returns OK.
MSP
440
sk_setDefaultHandler()
Description
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
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc 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.
SwitchKit Programmer's Information
441
sk_setDefaultTCAPHandler()
Description
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);
Parameters
The function parameters are shown in the table below.
Arguments Description
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc A pointer to a function that is designed to handle messages.
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.\
MSP
442
sk_setGroupHandler()
Description
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
aGroupName Specifies the group.
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc 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.
SwitchKit Programmer's Information
443
sk_setLLCConnectionHandler()
Description
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
aConId aConID is a connection identifier specified at connection creation time and used to indicate which LLC an application wishes to communicate with.
aConState The new state of the LLC connection. Possible values are:
SK_LLC_CONN_CREATED Application connection to LLC has just been established.
MSP
444
SK_LLC_CONN_DESTROYED Application connection to LLC has just been lost.
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 usingsk_removeLLCConnectionHandler().
Parameters
The function parameters are shown in the table below.
Arguments Description
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().
aHandlerFunc A pointer to a function that is designed to handle messages.
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
SwitchKit Programmer's Information
445
sk_setTCAPHandler()
Description
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 MSP-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
aStackID Identifies Stack ID
anSSN Identified Subsystem number
aTag An application defined pointer which will be returned to the application when a handler is invoked.
aHandlerFunc A pointer to a function that is designed to handle messages.
Return Values
Possible return values for this function:
OK Always returns OK.
MSP
446
sk_unlockTCAPHandlers()
Description
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 Description
aKey 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.
SwitchKit Programmer's Information
447
Logging Functions
Logging Functions
This section describes the logging 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.
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(
MSP
448
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 Description
MsgStruct * Pointer to a generic C Structure representing a message.
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
“Message” If the message is a known Toolkit message or EXS API message, the function returns the message name.
Unknown TK Tag
The message is an unknown Toolkit message, returned with the message tag.
Unknown Tag The message is an unknown EXS API message, returned with the message tag.
AdminMessage The message is an AdminMessage.
DummyMessage If the message is a DummyMessage.
SwitchKit Programmer's Information
449
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 Description
aLogLevel what is a bit mask represented by the following bits:
Bit 1 is set - socket.log is turned on.
Bit 2 is set - messages.log is turned on.
Both bits cleared - logging is turned off.
Bit 4 is set - screen output is turned off.
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 This return value indicates that your application lost contact with the LLC.
MSP
450
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
aTextMessage Points to the message you want to log.
aLogLevel This can be specified as follows:
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
SK_LVL_MINOR - log the message as a minor error
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:
OK Successfully executed.
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
SwitchKit Programmer's Information
451
sk_setSilentMode()
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 Description
isSilentModeFlag 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.
MSP
452
Message Functions
Base Classes
Description
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.
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
SwitchKit Programmer's Information
453
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 MSP-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.
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.
MSP
454
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 host-initiated 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);
SwitchKit Programmer's Information
455
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; 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);
MSP
456
Message Class Macros
Description
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);
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
SwitchKit Programmer's Information
457
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.
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;
MSP
458
Message Functions
Purpose
This section 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.
SwitchKit Programmer's Information
459
Message Headers in C
Description
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;
MSP
460
}
SwitchKit Programmer's Information
461
Message Macros for C Programmers
Description
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
MSP
462
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 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_OUTBOUND: for messages destined for the switch.
SK_TYPE_TOOLKIT: for SwitchKit-specific messages, for example Add LLCNode.
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
SwitchKit Programmer's Information
463
int skts_getMsgType(MsgStruct *m);
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);
MSP
464
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);
SwitchKit Programmer's Information
465
Message Structure Macros
Description
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
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.
MSP
466
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.
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;
}
SwitchKit Programmer's Information
467
default:
break;
}
MSP
468
Messages in C++
Description
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
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.
SwitchKit Programmer's Information
469
sk_packAutoStorage()
Description
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
MsgStruct **m Pointer to a generic C Structure representing a message.
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 as the memory may be reused the next time a SwitchKit API function is called.
aBufSize Size of the packed message.
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
SK_UNKNOWN_MSG_TYPE The tag field of this MsgStruct is invalid. Did you call sk_initMsg()?
SK_BAD_MSG_SIZE 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.
SK_NO_MSG_SIZE For this MsgStruct, no size was set in with sk_setMsgSize(), and its size couldn’t be computed.
MSP
470
sk_packMessage()
Description
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
MsgStruct I **m I Pointer to a generic C Structure representing a message.
aBuffer O Pointer to a packed message.
aBufSize I 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.
O The number of bytes of aBuffer that were actually used to store the packed message.
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
SK_UNKNOWN_MSG_TYPE The tag field of this MsgStruct is invalid. Did you call sk_initMsg()?
SK_BAD_MSG_SIZE 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.
SK_NO_MSG_SIZE For this MsgStruct, no size was set in with sk_setMsgSize(), and its size couldn’t be computed.
SwitchKit Programmer's Information
471
sk_rcvAndDispatch()
Description
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
aBuffer Pointer to a packed message.
aBufSize Size of the 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.
aTag The application-defined pointer that is only valid if the function returns SK_NOT_HANDLED. The value was set in either the original
MSP
472
message send operation if the message is an acknowledgement or was set when the handler was defined if the message is switch-initiated.
aConIDPtr This is used to identify from which LLC connection the message was received.
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
SK_NO_MESSAGE No message was received. The time-out expired before any messages (other then Poll messages) were received by the LLC.
SK_BAD_MESSAGE An improperly formatted message was received.
SK_FRAMING_FAILURE 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.
SK_SOCKET_WRITE_ERROR 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.
SK_NODE_NOT_FOUND 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.
SK_INVALID_LINK 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.
SK_NOT_HANDLED Message was not handled by handler function, no results available.
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.
SwitchKit Programmer's Information
473
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) */
...
} /* while (1) */
} /* main */
MSP
474
sk_rcvAndDispatchAutoStorage()
Description
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
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 as the memory may be reused the next time a SwitchKit API function is called.
aBufSize Size of the 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.
NotCurrentlyUsed The field is no longer used by the SwitchKit API and still exists for backward compatibility. This value should be set to NULL(0).
aConIDPtr 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
SwitchKit Programmer's Information
475
Possible return values for this function:
SK_INVALID_LINK 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.
SK_FRAMING_FAILURE 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.
SK_SOCKET_WRITE_ERROR
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.
SK_NODE_NOT_FOUND 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.
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
SK_NO_MESSAGE No message was received. The time-out expired before a message was received or the LLC received a poll message from the MSP 1010.
SK_BAD_MESSAGE An improperly formatted message was received
SK_NOT_HANDLED Message was not handled by handler function, and no results are available.
MSP
476
sk_rcvMessage()
Description
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.
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
aBuffer Pointer to a packed message.
aBufSize Size of the 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.
aDataPtr This argument is not currently used.
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
SwitchKit Programmer's Information
477
Possible return values for this function:
SK_INVALID_LINK 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.
SK_FRAMING_FAILURE 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.
SK_SOCKET_WRITE_ERROR 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.
SK_NODE_NOT_FOUND 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.
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
SK_NO_MESSAGE No message was received. The time-out expired before a message was received or the LLC received a poll message from the switch.
SK_BAD_MESSAGE An improperly formatted message was received
MSP
478
sk_sendMessage()
Description
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
aBuffer Pointer to a packed message.
aBufSize Size of the packed message.
aTag An application defined pointer which will be returned to the application when a handler is invoked.
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 This return value indicates that your application lost contact with the LLC.
SK_UNKNOWN_MSG_BUF Buffer and Size pointers do not point to a valid message.
SK_NO_CONNECT_AVAIL The specified connection from OnConnection() is not available or valid.
SwitchKit Programmer's Information
479
sk_sendMessageWithHandler()
Description
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
aBuffer Pointer to a packed message.
aBufSize Size of the packed message.
aTag An application defined pointer which will be returned to the application when a handler is invoked.
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 This return value indicates that your application lost
MSP
480
contact with the LLC.
SK_UNKNOWN_MSG_BUF Buffer and Size pointers do not point to a valid message.
SK_NO_CONNECT_AVAIL The specified connection from OnConnection() is not available or valid.
SwitchKit Programmer's Information
481
sk_sendMessageWithTag()
Description
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
aBuffer Pointer to a packed message.
aBufSize Size of the packed message.
aTag An application defined pointer which will be returned to the application when a handler is invoked.
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 This return value indicates that your application lost contact with the LLC.
SK_UNKNOWN_MSG_BUF Buffer and Size pointers do not point to a valid message.
SK_NO_CONNECT_AVAIL The specified connection from OnConnection() is not available or valid.
MSP
482
sk_sendMsgStruct()
Description
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
*aMsgStruct Pointer to a generic C Structure representing a message.
aTag An application defined pointer which will be returned to the application when a handler is invoked.
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 This return value indicates that your application lost contact with the LLC.
SK_UNKNOWN_MSG_TYPE The tag field of this MsgStruct is invalid. Did you call sk_initMsg()?
SK_UNKNOWN_MSG_BUF Buffer and Size pointers do not point to a valid message.
SK_NO_CONNECT_AVAIL The specified connection from OnConnection() is not available or valid.
SwitchKit Programmer's Information
483
sk_unpackAutoStorage()
Description
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
aBuffer Pointer to a packed message.
aBufSize Size of the packed message.
*aMsgStructPtr
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 This return value indicates that your application lost contact with the LLC.
SK__MSG_TOO_BIG The amount of memory needid to be allocated is greater than 65536 bytes.
SK_INTERNAL_ERROR Message could not be unpacked.
MSP
484
sk_unpackMessage()
Description
The sk_unpackMessage() function takes the character buffer and size returned by sk_rcvMessage() and unpacks it into a message structure.
Syntax
int sk_unpackMessage(char *aBuffer, int aBufSize, MsgStruct *aMsgStruct);
Parameters
The function parameters are shown in the table below.
Argument Description
aBuffer Pointer to a packed message.
aBufSize Size of the packed message.
aMsgStruct ointer to a generic C Structure representing a message.
Return Values
Possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
SK_INTERNAL_ERROR The message could not be unpacked.
SwitchKit Programmer's Information
485
Redundancy
This section describes the redundancy functions and redundant application functions, available in SwitchKit. This section also describes the SK API messages for application redundancy and LLC redundancy. The section 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.
MSP
486
sk_activateExnetMatrix()
Description
The sk_activateExnetMatrix() function activates the standby EX/CPU. This message is also available as sk_activateExnetMatrixOnConnection() and skts_activateExnetMatrix().
Syntax
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 Description
isLeftFlag 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.
aNodeID Specifies the node the function is sent to.This argument must be set.
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 This return value indicates that your application lost contact with the LLC.
SwitchKit Programmer's Information
487
sk_registerAsRedundantApp() / sk_deregisterAsRedundantApp()
Description
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.
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
MSP
488
anAppID The application identifier assigned by the LLC to the application. The name can be obtained by calling sk_getConnectionName().
aRedundantAppPoolID A string that uniquely identifies the class of application wishing to be treated as redundant applications.
Note: The ID is case sensitive.
aRedundantAppPriority 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.
SK_RED_APP_PRI_REMOVED (-1)
Used when an application needs to be removed from an RedundantAppClass for which it has previously registered.
aDataSize DataSize
aDataBuf 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.
aTag An application defined pointer which will be returned to the application when a handler is invoked.
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
SwitchKit Programmer's Information
489
LLC and Application Redundancy
Description
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
1 The first member of a RAP is primary. All subsequent members are secondary.
2 If the primary application fails or terminates, the application loses its primary status.
3 A member of a RAP becomes primary based upon the priority settings specified at registration time.
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.
adds applications to a RAP as specified in the sk_registerAsRedundantApp() call from the application.
determines which application is primary in the RAP.
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.
MSP
490
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 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_POOL_DOESNT_EXIST (0Xf00c)
the queried RAP does not exist.
SK_RED_APP_MEM_ERROR (0xf00d) an error occurred under the members of a RAP.
SK_RED_APP_NOT_A_MEMBER (0xf00e)
the application is not a registered member of the RAP.
SK_RED_APP_NOT_CONNECTED the registered application lost its
SwitchKit Programmer's Information
491
(0xf00f) connection to the LLC.
MSP
492
API Messages used for Redundancy
API Messages
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
SwitchKit Programmer's Information
493
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 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
xtICBSubtype ICBSubtype value will be returned in this output argument.
xtICBLength ICBLength will be returned in this output argument.
xtICBData A pointer to the ICBData will be returned in this output argument.
crwdMsg The ChannelReleasedWith Data message from which the above- mentioned output is to be extracted.
Return Value
The return value for this function is always:
TRUE(1)
MSP
494
sk_getManagedFile()
Description
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
FILE* skts_getManagedFile(const char *aFileName );
Parameters
The function parameters are shown in the table below.
Argument Description
aFileName Pointer to specified file.
Return Values
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
SwitchKit Programmer's Information
495
sk_getMessageText()
Description
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
aMsgStruct Pointer to a generic C Structure representing a message.
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.
MSP
496
sk_getMsgName()
Description
Returns the name of the given message.This function is also available as skts_getMsgName().
Syntax
char* sk_getMsgName(MsgStruct *aMsgStruct);
Threadsafe syntax
char* skts_getMsgName(MsgStruct *aMsgStruct);
Parameters
The function parameters are shown in the table below.
Argument Description
aMsgStruct 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.
SwitchKit Programmer's Information
497
sk_getMsgSizeFromTag()
Description
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 Description
aMessageTag 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.
MSP
498
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();
SwitchKit Programmer's Information
499
sk_statusText()
Description
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
The function parameters are shown in the table below.
Argument Description
anError 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.
MSP
500
sk_unparseAlarm()
Description
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
aBuffer Pointer to a packed message.
anAlarmMsg The Alarm that is to be unparsed.
Return Values
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
SwitchKit Programmer's Information
501
sk_unparseAlarmCleared()
Description
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);
Threadsafe Syntax
int skts_unparseAlarmCleared( char *aBuffer, XL_AlarmCleared *anAlarmClearedMsg);
Parameters
The function parameters are shown in the table below.
Argument Description
aBuffer Pointer to a packed message.
anAlarmClearedMsg The AlarmCleared message that is to be unparsed.
Return Values
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
MSP
502
sk_unparsePPLEventIndication()
Description
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
aBuffer Pointer to a packed message.
aPPLEIMsg The PPLEventIndication message that is to be unparsed.
Return Values
Possible return values for this function are:
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
SwitchKit Programmer's Information
503
Register Functions
Register Functions
This section 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.
MSP
504
sk_appGroupRegister()
Description
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 Description
aVirturalName A string identifier for an application group which can be targets for an InterAppMsg or TransChanMsg.
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 This return value indicates that your application lost contact with the LLC.
SwitchKit Programmer's Information
505
Useful Related Functions
SK_Connection *sk_createConnectionWithID();
MSP
506
sk_msgRegister() / sk_msgUnRegister()
Description
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
SK_ALL_MSGS All messages Switch/LLC
SK_POLLS PollMessage Switch
SK_ALARMS Alarm, AlarmCleared Switch
SK_CSRS CardStatusReport Switch
SK_NSRS NodeStatusReport Switch
SK_RSRS RingStatusReport Switch
SK_DS0S DS0StatusChange Switch
SK_PPLEIS PPLEventIndication Switch
SK_CONFERENCE_DELETED ConferenceDeleted
ConferenceDeleteRequest
Switch
SwitchKit Programmer's Information
507
Host
SK_CONFIGMSGS(Internal Use Only)
All configuration messages
Client
SK_CONNECT_STATUS ConnectionStatusMsg LLC
SK_CHAN_PROBLEM ChannelProblem LLC
SK_CONFIG_STATUS ConfigStatusMsg SwitchManager
SK_CPE_ON_CONFERENCE CallProcessingEvent messages which contain a conference AIB.
Switch
SK_RESOURCE_UTIL_
REPORT
GenericReport (Resource utilization report)
LLC
SK_D_SERVER_REPORT DeviceServerStatus Report
Switch
SK_HOSTALARM HostAlarm LLC
SK_SERVER_STATUS_REPORT ServerStatusReport Switch
SK_SERVER_HOST_POLL ServerHostPoll Switch
SK_SERVER_STATUS_CHANGE ServerStatusChange LLC
SK_ARP_CACHE_REPORT ARPCacheReport Switch
SK_CCS_REP CCSRedundancy Report Switch
Argument Description
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 This return value indicates that your application lost contact with the LLC.
MSP
508
sk_pplComponentRegister() / sk_pplComponentUnRegister()
Description
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
aComponentID Specifies the PPL component number.
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
The possible return values for this function:
SK_LOST_LLC This return value indicates that your application lost contact with the LLC.
SwitchKit Programmer's Information
509
sk_pplTCAPRegister() / sk_pplTCAPUnRegister()
Description
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
aRegisterVal OPC or Sub-System Number
aRegisterType Registration type. Use the following constants to specify either OPC or SSN:
SK_TCAP_REG_OPC (0x00) - OPC Registration
SK_TCAP_REG_SSN (0x01) - SSN Registration
SK_TCAP_REG_STACK_SSN 0x02 - Registers a combination of stack and subsystem number.
aConID aConID is a connection identifier specified at connection creation time and used to indicate which LLC an application wishes to communicate with.
MSP
510
SwitchKit API
API Messages Used for Call Control Programming
This section outlines the messages used for developing call control applications.
Call Control
BusyOut
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
SwitchKit Programmer's Information
511
OutpulseDigits
OutseizeControl
ParkChannel
PlayFileModify
PlayFileStart
PlayFileStop
PPLEventIndication
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
MSP
512
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-to-application 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.
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
SwitchKit Programmer's Information
513
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
Least Recently Used
Most Recently Used
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_getSwitchmgrId()
sk_downloadFile()
sk_newConfig()
MSP
514
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.
HP-UX
If you are using the HP-UX operating system, 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 libskapAAi.sl and libskcapiAA.sl for your development. If you want to use the threadsafe libraries, use libskapiAA_ts.sl, libskcapiAA.sl, and libAce.so.5.3.3 for your development.
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.
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.
SwitchKit Programmer's Information
515
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
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 section. The Threadsafe SwitchKit API was designed with an application model consisting of two main components:
MSP
516
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
1 Initialize the Threadsafe SwitchKit API by calling skts_enableThreadSafeAPI().
2 Establish connections to all LLCs.
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.
3 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.
4 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 function.
5 Optionally, register for inbound calls being presented to LLC channel groups.
This is done using the skts_watchChannelGroup()
6 Spawn worker threads.
More details on worker threads will be provided in the next part of this discussion.
7 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
SwitchKit Programmer's Information
517
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
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.
MSP
518
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_watchChannelGroup()
sk_ignoreChannelGroup()
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:
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.
SwitchKit Programmer's Information
519
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
}
if (status != OK) {
cout << "Error registering for messages from LLC"
<< endl;
// Continue to initialize. No point returning.
}
...
}
MSP
520
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)
if (status != 1)
{
cout << "Error has occurred creating connection to LLC" << endl;
return (-1);
}
...
// (2) Define Handler Functions – returns OK always
// (2a) Default Handler
SwitchKit Programmer's Information
521
(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 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.
MSP
522
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
// (2a) Default Handler
(void)skts_setDefaultHandler(someTag, // tag for hdlr someDefaultHandlerFunc); // handler func
SwitchKit Programmer's Information
523
// (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; // size of msg returned
void *data; //needed for function call. Not used by API
status = sk_rcvAndDispatchAutoStorage(
&buffer, // contains packed msg if msg not handled
&size, // size of message returned
-1, // timeout - wait forever
&data); // Not currently used.
if (status != OK) {
switch(status) {
case SK_NO_MESSAGE:
// This is a normal return and indicates that
// an internal message was returned.
MSP
524
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 if
} // end while
...
}
Sample ThreadSafe Application
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.
SwitchKit Programmer's Information
525
What the non- threadsafe application does...
What to do to make the previous application threadsafe....
(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.
(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.
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().
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.
(2) Sets up handlers:
(a) A default handler that will receive all messages should other handlers not be enabled to catch a message
(b) A group handler for receiving all inbound call notifications via the RequestForService or RFSWithData
(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.
MSP
526
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.
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.
(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.
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 // //functions. This function MUST be called first. Failure to call
// this function first or at all will result in unexpected behavior.
skts_enableThreadSafeLib();
// (1) Establish connections to LLC’s
SwitchKit Programmer's Information
527
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
1); // connection ID
if (status != OK) {
cout << "Error requesting watch of channel group"
MSP
528
<< endl;
return (-1);
(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 Non-Threadsafe Code and is excluded for brevity
} // end if
} // end while
...
}
SwitchKit Programmer's Information
529
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."
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.
MSP
530
Programming Tips and Examples
Advanced Programming Technique in UNIX
Description
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
sk_destroyConnection(parentConnect);
};
SwitchKit Programmer's Information
531
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_Connction *sk_createConnectionWithID();
sk_*OnConnection();
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
MSP
532
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)
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
SwitchKit Programmer's Information
533
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: Link Error: CallSim.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall SKC_UserTimer::˜SKC_UserTimer(void)" (??1SKC_UserTimer@@UAE@XZ)
o Go to Project Settings,
o Select the C/C++ tab,
o Under Category, select Preprocessor,
o Make sure that the field "Additional include directories" shows:
If you get the following error message: Compilation error: fatal error C1083: Cannot open include file: 'SKC_API.h': No such file or directory../../include
o Make sure that include/BaseClasses.cpp and include/Messages.api.cpp are members of the project.
If a run time error occurs:
o Go to Project Settings,
o Select the C/C++ tab,
o Under Category, select Code Generation
o 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.
MSP
534
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.
SwitchKit Programmer's Information
535
Parsing of AIBs
Description
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 */
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;
}
MSP
536
Programming Tips & Examples
This section provides information on parsing address information blocks and advanced programming technique in UNIX. This section also explains calls into 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 of the section showing 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.
SwitchKit Programmer's Information
537
Running the Application
Description
You can run your call control application described below.
Running the Applications
To run the applications, perform the following steps:
Start the LLC.
Start SwitchManager and send the tandem.cfg file with the defined inbound and outbound channel groups.
Start SimpleTandem at the command line: SimpleTandem
Start CallSim at the command line: CallSim
To see usage information for either of the applications, provide an -h argument at the command line.
MSP
538
Simple Tandem and CallSim
Description
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.
To run CallSim, the switch must be configured with the provided tandem.cfg configuration file.
Process Overview
Initialize a Connection with the LLC.
Set the group handler.
SwitchKit Programmer's Information
539
Set up a UserTimer message to trigger a certain number of outseizures. This is set by the NumberOfCalls parameter every CallDelay seconds.
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
541
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 TCAP Abstraction Layer (SKTAL)
SwitchKit API library
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.
MSP
542
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
SwitchKit TCAP Interface
543
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
The next table describes the SKIM API classes available to applications.
Name Description
SKIM_Api::Initialize() Initializes a SKIM API object. This method also initializes SKTAL and registers a TCAP SSN with the MSP 1010.
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 pre-arranged end message to the MSP 1010.
SKIM_Api::Send Sends TCAP transaction message along with a list of operations. A given transaction message can contain zero or more operations (TCAP Components).
SKIM_Api::SSNInService Sends N-State request to bring the local subsystem network (SSN) in service.
SKIM_Api::SSNOutOfService Sends N-State request to take the local SSN out of service.
SKIM_Api::SendReject 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.
SKIM_Api::CancelOperation Allows the user to cancel a previously invoked operation for a given call reference ID and invoke ID.
SKIM_Api::SendPreArrangedEnd Sends a pre-arranged end message for a given call reference ID.
SKIM_Api::SetTransHandler Sets a transaction handler for a given call reference ID.
SKIM_Api::ClearTransHandler Clears a transaction handler for a given call reference ID.
SKIM_Api::EnableTracing Enables SKIM library tracing for a given trace type.
SKIM_Api::DisableTracing Disables SKIM library tracing for a given trace type.
MSP
544
SKTAL APIs
The following are some of the SKTAL API messages available to the application:
Name Despcription
sktal_initializeTCAP A one-time call for global initialization of the TCAP Abstraction layer.
sktal_terminateTCAP A one-time call for global termination of the TCAP Abstraction layer.
sktal_registerTCAPSSNHandler 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.
sktal_unregisterTCAPSSNHandler Removes (and terminates) the subsystem identified during registration. All ongoing transactions are terminated and the subsystem is marked out-of-service.
sktal_allocateTCAPDialogID Allocates the TCAP dialog ID.
sktal_setTCAPDialogHandler 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.
sktal_clearTCAPDialogHandler The user removes the transaction handler once the transaction has been completed (by receiving) TC-U-ABORT, TC-P-ABORT, TC-END, or TC-UNI, or sending TC-U-ABORT, TC-END, or TC-UNI). It is imperative to not take this step until the last message has been sent.
sktal_sendTCAPDialog Sends a TCAP dialog message.
sktal_recvTCAPDialog Receives a TCAP dialog info from a SKTAL_EVENT.
sktal_sendTCAPComponent Sends a TCAP component message.
SwitchKit TCAP Interface
545
sktal_recv_TCAPComponent Receives TCAP component information from a SKTAL_EVENT.
Diagram
The next diagram shows how SKIM and SKTAL APIs interface with the SwitchKit library.
MSP
546
SwitchKit TCAP Interface
547
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.
MSP
548
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.
SwitchKit TCAP Interface
549
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
MSP
550
6. SKIM terminates the SKTAL API layer.
7. Application destroys the connection with LLC.
SwitchKit TCAP Interface
551
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 2 Only failure is reported
Class 3 Only success is reported
Class 4 Neither success, nor failure is reported
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:
MSP
552
Return result indicating success
Return error indicating operation failure
Reject indicating inability to perform the operation
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 dialogue facilities, allowing several dialogues to run concurrently between two TC-users. In addition, dialogue handling allows for the transfer and negotiation of the application context and the transparent transfer of user information (that is, data
SwitchKit TCAP Interface
553
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 uni-directional 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.
MSP
554
SwitchKit Interface Module
SKIM API Messaging
The SKIM API layer provides the following functionalities:
Allocation / Deallocation of Call Reference ID
Handler Functions
Handling Multiple Stack/SSN
SKIM Error Handling
Resource Limitation Error
These functionalities are described further in this section.
SKIM data types and return codes are defined in Appendix B Each SKIM transaction is uniquely identified by a call reference ID. The Call Reference ID is allocated by SKIM when a new transaction is initiated or received. The call reference ID is released when a transaction is ended or aborted by the SKIM application.
Memory Management
A SKIM application does not need to do memory management with respect to SKIM API usage. A SKIM application must manage the ongoing transactions and should clear the transaction by sending or receiving prearranged end, basic end, or abort.
SKIM API allocates a transaction context for each active transaction. The transaction context is cleared when transaction is ended / aborted. In error scenarios, sending a prearranged end will clear the transaction.
Allocation / Deallocation of Call Reference ID
Each ongoing TCAP transaction is identified by a call reference ID. The SKIM API layer allocates a call reference ID when a user initiates a transaction or a new transaction is received from the remote end. After initiating a transaction the SKIM API user can retrieve the call reference ID assigned for the new transaction by calling GetCallReferenceId() method of a transaction object.
Call Reference ID and associated resources are deallocated when a transaction is ended/aborted by the SKIM user or remote SS7 entity. The SKIM user can free the call reference ID by calling SendPreArrangedEnd() for a given call reference ID value. TCAP prearranged end terminate transaction locally without sending any TCAP message to remote SS7 entity.
Handler Functions
SKIM API maintains a transaction handler to pass incoming transaction messages to the SKIM user. SKIM API maintains notification handlers to pass incoming notification messages to the SKIM user. SKIM notifications consist of SCCP N-STATE/N-PCSTATE indications, TCAP timeouts, SKIM internal error, and NACK messages from the MSP 1010. The SKIM user must register a transaction handler function and notification handler function as part of SKIM_Api object initialization. The SKIM user can override the default transaction handler function for a given call reference ID.
SwitchKit TCAP Interface
555
Most set or get methods return void. If a set or get method is called on in an invalid transaction type, then the method returns void. The set or get methods will have no affect on invalid transaction or operation types.
Handling Multiple Stack/SSN
The SKIM API user can communicate with multiple stack/SSN combinations configured on the MSP 1010. For each stack/SSN combination the user must create and initialize a SKIM_Api object. Communication to a stack/SSN is controlled using the public interface provided by SKIM_Api object.
SKIM Error Handling
The SKIM API layer maintains a transaction context for each active transaction and provides error handling over and above the TCAP protocol stack. These error conditions are reported to the SKIM user as a notification of type SKIM_NOTIFY_INTERNAL_ERROR. The SKIM user can get the cause of internal error notification by calling the GetCause public method of SKIM_NOTIFY object. Some of the error conditions handled by SKIM API layer are described in the next table:
Error Description
Transaction Record Error
This error message is returned SKIM cannot retrieve a transaction context for an incoming or outgoing transaction message. This occurs when the user tries to send a TCAP Continue or TCAP End message for a non-existent transaction.
Duplicate Invoke ID Error
This error occurs when a TCAP invoke operation with a invoke ID identical to an ongoing TCAP operation is sent or received for a given call reference ID.
Unknown Invoke ID Error
This error occurs when a response to a invoke operation contains an unknown invoke ID.
Invalid Linked ID This error occurs when a TCAP invoke operation containing in valid linked ID (linked ID for which corresponding invoke operation does not exist) is received or sent.
Unknown Message Type Error
This error occurs when an unknown transaction message type is received.
Unknown Component Error
This error occurs when a TCAP operation with unknown type is received.
Resource Limitation Error
This error is returned when user tries to initiate a transaction but maximum simultaneous transaction limit is reached.
Resource Limitation Error
This error is returned when a user tries to initiate a transaction but the maximum simultaneous transaction limit has already been reached.
MSP
556
Code Syntax
Each SKIM transaction is uniquely identified by a call reference ID. The Call reference ID is allocated by SKIM when a new transaction is initiated or received. The Call reference ID is released when a transaction is ended or aborted by the SKIM application. SKIM data types and return codes are defined in Appendix 2.
The SwitchKit Interface Module provides the following methods to the application developer.
class SKIM_Api
{
public:
int Initialize(int localNodeId, int stackId, int connId, int pc, int ssn, SKIM_TransHandler h1, SKIM_NotificationHandler h2, void *tag);
int Terminate();
int SSNInService();
int SSNOutOfService();
int Send(SKIM_Trans &trans);
int SendReject(int callrefid, SKIM_OCTET invokeId, SKIM_OCTET probType, SKIM_OCTET probCode);
int CancelOperation(int callrefid, SKIM_OCTET invokeId);
int SendPreArrangedEnd(int calrefid);
int SetTransHandler(int callrefid, SKIM_TransHandler h, void *tag);
int ClearTransHandler(int callrefid);
static int EnableTracing(int traceType);
static int DisableTracing(int traceType);
};
SwitchKit TCAP Interface
557
Initialize()
Description
SKIM application calls the initialize method to initialize the SKIM API object. This method initializes SKTAL and registers a TCAP subsystem (SSN) with the MSP 1010.
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
startRange = 0
startRange = 4096
endRange = 4095
endRange = 8191
Syntax
int Initialize(int localNodeId, int stackId, int connId, int pc, int ssn, SKIM_TransHandler h1,
SKIM_NotificationHandler h2, void *tag, int startRange=0, int endrange=SK_MAX_TCAP_DIALOGS-1)
Parameters
The input parameters are shown in the next table. There are no input/output parameters.
Argument Description
localNodeId Local node ID
stackId stack ID
connId connection ID
pc point code
ssn subsystem number (SSN)
h1 Default transaction handler callback. The transaction handler is invoked tby SKIM after receiving a TCAP transaction message. The prototype for SKIM transactionhandler is:
typedef int (*SKIM_TransHandler)(SKIM_Trans &trans, void *tag);
h2 Notification handler callback. The notification handler is invoked when notification message is received by SKIM. The prototype for notification handler is:
typedef int (*SKIM_NotificationHandler)(SKIM_Notify ¬ify, void *tag);
MSP
558
tag value Tag to be returned with the callbacks
startRange Starting dialogue ID allocated to this application (For the specific SSN)
endRange Ending dialogue ID allocated to this application (For the specifc SSN)
Return Values
Possible return values for this API are:
SKIM_SUCCESS No failure has occurred.
SKIM return code
As defined in Appendix B, Table B-2, SKIM Return Codes (B-2).
SwitchKit TCAP Interface
559
Terminate()
Description
This API terminates the SKIM API object. This method terminates SKTAL and deregisters a TCAP subsystem (SSN) with the MSP 1010.
Syntax
int Terminate();
Parameters
There are no input, input/output or output parameters.
Return Values
The possible return value for this API is:
SKIM_SUCCESS Always returns SKIM_SUCCESS.
MSP
560
SSNInService()
Description
The SSNInService method sends N-State request to bring the local subsystem (SSN) in service.
Syntax
int SSNInService();
Parameters
There are no input, input/output or output parameters.
Return Values
Possible return values for this API are:
SKIM_SUCCESS No failure has occurred.
SKIM return code As defined in Appendix B, Table B-2, SKIM Return Codes (B-2).
SwitchKit TCAP Interface
561
SSNOutOfService()
Description
The SSNOutOfService method sends N-State request to take the local subsystem (SSN) out-of-service.
Syntax
int SSNOutOfService();
Parameters
There are no input, input/output or output parameters.
Return Values
Possible return values for this API are:
SKIM_SUCCESS No failure has occurred.
SKIM return code
As defined in Appendix B, Table B-2, SKIM Return Codes (B-2).
MSP
562
Send()
Description
This method sends TCAP transaction message along with a list of operations. A given transaction message can contain zero or more operations.
Syntax
int Send(SKIM_Trans &trans);
Parameters
The input parameter is shown in the next table. There are no input/output parameters.
Argument Description
SKIM_Trans Transaction object
For details of SKIM_Trans class interface refer to Section 3, SKIM Parameter Classes.
Return Values
Possible return values for this API are:
SKIM_SUCCESS No failure has occurred.
SKIM return code
As defined in Appendix B, Table B-2, SKIM Return Codes (B-2).
SwitchKit TCAP Interface
563
SendReject()
Description
This method allows the user to send Reject for a given invoke ID and call reference ID. This does not clear the call reference ID therefore, you must send a prearranged end or basic end.
Syntax
int SendReject(int callrefid, SKIM_OCTET invokeId, SKIM_OCTET probType,
SKIM_OCTET probCode);
Parameters
The input parameter is shown in the next table. There are no input/output parameters.
Argument Description
callrefid Call reference ID to identify TCAP transaction for which Reject is being sent..
invokeId Invoke ID identifies TCAP operation being rejected.
probType Problem type as specified in Appendix A.
probCode Reject problem code. As specified in Appendix A.
Return Values
Possible return values for this API are:
SKIM_SUCCESS Method is successful. No failure has occurred.
SKIM return code
As defined in Appendix B Table B-2, SKIM Return Codes (B-2).
MSP
564
CancelOperation()
Description
This method allows the user to cancel a previously invoked operation for a given call reference ID and invoke ID.
Syntax
int CancelOperation(int callrefid, SKIM_OCTET invokeId);
Parameters
The input parameter is shown in the next table. There are no input/output parameters.
Argument Description
callrefid Call reference ID
invokeId Invoke ID
Return Values
Possible return values for this API are:
SKIM_SUCCESS No failure has occurred.
SKIM return code
As defined in Appendix B Table B-2, SKIM Return Codes (B-2).
SwitchKit TCAP Interface
565
SendPreArrangedEnd()
Description
This method sends a Pre-Arranged End message to the MSP 1010 for the given call reference ID. This method releases the call reference ID and associated resources.
Syntax
int SendPreArrangedEnd(int callrefid);
Parameters
The input parameter is shown in the next table. There are no input/output parameters, or output parameters.
Argument Description
callrefid Call reference ID
Return Values
Possible return values for this API are:
SKIM_SUCCESS Method is successful.
SKIM return code
As defined in Appendix B Table B-2, SKIM Return Codes (B-2).
MSP
566
SetTransHandler()
Description
This method sets a transaction handler for a given call reference ID.
Syntax
int SetTransHandler(int callrefid, SKIM_TransHandler h, void *tag);
Parameters
The input parameters are shown in the next table. There are no input/output parameters.
Argument Description
callrefid Call reference ID for which transaction handler is being registered.
h Transaction handler. Protype for transaction handler function is:
typedef int (*SKIM_TransHandler)(SKIM_Trans &trans, void *tag);
tag This tag is returned when transaction handler is invoked.
Return Values
Possible return values for this API are:
SKIM_SUCCESS No failure has occurred.
SKIM_TRANS_RECORD_ERROR No transaction is active for given call reference ID.
SwitchKit TCAP Interface
567
ClearTransHandler()
Description
This method clears a transaction handler for a given call reference ID.
Syntax
int ClearTransHandler(int callrefid);
Parameters
The input parameters are shown in the next table. There are no input/output parameters.
Argument Description
callrefid Call reference ID for which the transaction handler is being cleared.
Return Values
Possible return values for this API are:
SKIM_SUCCESS No failure has occurred.
SKIM_TRANS_RECORD_ERROR No transaction is active for given call reference ID.
MSP
568
EnableTracing()
Description
This method enables SKIM library tracing for a given trace type. Execution traces are generated to a file and standard output. Trace files are created in the current execution directory. If a given trace type is already enabled then this method will not have any effect.
Syntax
static void EnableTracing(int traceType);
Parameters
The input parameters are shown in the next table. There are no input/output parameters.
Argument Description
traceType Possible values:
SKIM_SUCCESS_TRACE
SKIM_ERROR_TRACE
Return Values
None.
SwitchKit TCAP Interface
569
DisableTracing()
Description
This method disables SKIM library tracing for a given trace type. If a given trace type is already disabled then this method will have no effect.
Syntax
static void DisableTracing(int traceType);
Parameters
The input parameters are shown in the next table. There are no input/output parameters.
Argument Description
TraceType Possible values:
SKIM_SUCCESS_TRACE
SKIM_ERROR_TRACE
Return Values
None.
MSP
570
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
{
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,
const SKIM_OCTET priority = 0);
void
GetQualityOfService(SKIM_OCTET& flags,
SKIM_OCTET& priority);
void SetPreArrangedEnd();
SKIM_OCTET GetReportCause () const;
void GetApplicationContext(SKIM_OCTET* buf, int& len) const;
SwitchKit TCAP Interface
571
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
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_BEGIN
SKIM_TC_CONTINUE
SKIM_TC_END
SKIM_TC_P_ABORT
SKIM_TC_U_ABORT
Possible values for ANSI TCAP:
SKIM_TC_UNI
SKIM_TC_BEGIN (Same as Query with Permission)
SKIM_TC_CONTINUE (Same as Conversation With Permission)
MSP
572
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
type
Return Values
Possible values for ITU TCAP:
Possible values for ITU TCAP:
SKIM_TC_UNI, SKIM_TC_BEGIN
SKIM_TC_CONTINUE
SKIM_TC_END
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_BEGIN (Same as Qurey With Permission)
SKIM_TC_CONTINUE (Same as Conversation With Permission)
SKIM_TC_END
SKIM_TC_ABORT
SKIM_TC_QUERY_WO_PERM
SKIM_TC_CONV_WO_PERM
SKIM_TC_NOTICE
GetCallReferenceId()
SwitchKit TCAP Interface
573
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()
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.
MSP
574
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.
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
SwitchKit TCAP Interface
575
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.
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)
MSP
576
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)
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
SwitchKit TCAP Interface
577
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()
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_RET_OPT: specifies SCCP Class 0 with return option
SKIM_QOSI_SEQ_CTRL: specifies SCCP) Class 1 with no 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_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.
Input/Output Parameters, Output Parameters
None
GetQualityOfService()
Description
MSP
578
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_RET_OPT: specifies SCCP Class 0 with return option
SKIM_QOSI_SEQ_CTRL: specifies SCCP) Class 1 with no 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_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
SwitchKit TCAP Interface
579
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_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)
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.
MSP
580
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.
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.
SwitchKit TCAP Interface
581
len: Number of bytes in user information.
MSP
582
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
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> ¶m);
voidint GetParameter(vector <byte> ¶m);
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);
};
SwitchKit TCAP Interface
583
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
SetType () All
GetType () All
SetInvokeId () All
GetInvokeId () All
SetLinkedId () SKIM_TC_INVOKE SKIM_TC_INVOKE_NLl
HasLinkedId () SKIM_TC_INVOKE
SKIM_TC_INVOKE_NL
GetLinkedId () SKIM_TC_INVOKE
SKIM_TC_INVOKE_NL
SetInvokeTimeout ()
SKIM_TC_INVOKE
Set Parameter () 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
Get Parameter () 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
IsLastOperation ()
All
SetOpCode () SKIM_TC_INVOKE, SKIM_TC_INVOKE_NL, SKIM_TC_RESULT_L (ITU) SKIM_TC_RESULT_NL (ITU)
GetOpCode () SKIM_TC_INVOKE, SKIM_TC_INVOKE_NL, SKIM_TC_RESULT_L (ITU) SKIM_TC_RESULT_NL (ITU)
SetClass () SKIM_TC_INVOKE (ITU)
GetClass () SKIM_TC_INVOKE (ITU)
SetErrorCode () SKIM_TC_U_ERROR SKIM_TC_ERROR
GetErrorCode () SKIM_TC_U_ERROR SKIM_TC_ERROR
SetRejectCause () SKIM_TC_U_REJECT SKIM_TC_R_REJECT SKIM_TC_L_REJECT SKIM_TC_REJECT
GetRejectCause SKIM_TC_U_REJECT SKIM_TC_R_REJECT
MSP
584
() 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
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_INVOKE_NL
SKIM_TC_RESULT
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_INVOKE_NL (Same as Invoke Last for ANSI)
SwitchKit TCAP Interface
585
SKIM_TC_RESULT
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
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.
MSP
586
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
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
SwitchKit TCAP Interface
587
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 2: Only failure is reported
Class 3: Only success is reported
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 2: Only failure is reported
Class 3: Only success 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
MSP
588
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
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> ¶m);
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> ¶m);
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
SwitchKit TCAP Interface
589
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)
Description
Sets the operation field of a given operation. This is valid only when operation type is:
SKIM_TC_INVOKE
SKIM_TC_RESULT_L
SKIM_TC_RESULT_NL
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_L
SKIM_TC_RESULT_NL
Syntax
void GetOpCode(SKIM _LONG & code);
Input Parameters, Input/Output Parameters
None
Output Parameters
code: The operation code.
SetOpCode() (For ANSI)
MSP
590
Description
Sets the operation field of a given operation. This is valid only when operation type is:
SKIM_TC_INVOKE
SKIM_TC_RESULT_L
SKIM_TC_RESULT_NL
Syntax
void SetOpCode(const bool isNational, const SKIM_OCTET family, const SKIM_OCTET code);
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_L
SKIM_TC_RESULT_NL
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)
SwitchKit TCAP Interface
591
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
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.
MSP
592
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).
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
SwitchKit TCAP Interface
593
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();
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.
MSP
594
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 Description
SKIM_NOTIFY_SCCP_MGMT_IND SCCP management indication.
SKIM_NOTIFY_MTP3_MGMT_IND N-PC State management indication.
SKIM_NOTIFY_OP_TIMEOUT Operation timeout. For ITU only.
SKIM_NOTIFY_INTERNAL_ERROR SKIM internal error.
SKIM_NOTIFY_NACK_IND 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
SwitchKit TCAP Interface
595
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
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
MSP
596
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
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.
SwitchKit TCAP Interface
597
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
Void SetSSN(const SKIM_OCTET sn)
Bool IsRoutedByPCSSN() const
Void SetRouteByPCSSN(const bool which)
Bool IsInternationalRouting() const
void
SetInternationalRouting(const bool which)
bool
HasGlobalTitle() const
int
SetGlobalTitle(const SKIM_OCTET type,
const SKIM_OCTET* gttInfo, const SKIM_USHORT gttLength)
int
GetGlobalTitle(SKIM_OCTET& type,
SKIM_OCTET* gttInfo, SKIM_USHORT& gttLength) const
};
SKIM_CallingPartyAddress/SKIM_CalledParty Address Class Methods
MSP
598
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
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
SwitchKit TCAP Interface
599
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
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
MSP
600
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.
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
SwitchKit TCAP Interface
601
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
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
MSP
602
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_NATURE Global title contains nature of address.
SCCP_CPA_GTTI_TRANS Global Title contains translation type.
SCCP_CPA_GTTI_TNE Global Title contains translation type, numbering plan and encoding cheme.
SCCP_CPA_GTTI_ALL Global title contains translation type, nayure of address, numbering plan, and encoding scheme
Possible values for ANSI SCCP are:
Value Description
SCCP_CPA_GTTI_TRANS Global Title contains translation type.
SCCP_CPA_GTTI_TNE Global Title contains translation type, numbering plan and encoding scheme.
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
SwitchKit TCAP Interface
603
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_NATURE Global title contains nature of address.
SCCP_CPA_GTTI_TRANS Global Title contains translation type.
SCCP_CPA_GTTI_TNE Global Title contains translation type, numbering plan, and encoding scheme.
SCCP_CPA_GTTI_ALL Global title contains translation type, nayure of address, numbering plan and encoding scheme.
Possible values for ANSI SCCP are:
Value Description
SCCP_CPA_GTTI_TRANS Global Title contains translation type.
SCCP_CPA_GTTI_TNE Global Title contains translation type, numbering plan 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
MSP
604
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,
BACK_IP, BACK_PORT);
if (ret == 0)
{
fprintf(stderr, "Error connecting to switch\n");
return (SKIM_EINVALIDARGS);
}
return (SKIM_SUCCESS);
}
SwitchKit TCAP Interface
605
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.
// 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");
}
MSP
606
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);
#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
SwitchKit TCAP Interface
607
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)
{
printf("Send transaction failed ret = %d", ret);
return ret;
}
// Get the call reference id allocated for this transaction.
SKIM_UINT callrefid = ;
trans.GetCallReferenceId();
MSP
608
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;
#if defined(ANSI)
case SKIM_TC_ABORT :
rcvd_callrefid = id;
printf ("Received TCAP Abort call reference id is %x\n", id);
break;
SwitchKit TCAP Interface
609
#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)
{
printf("Received Return Result Last with Invoke id = %d\n",
op.GetInvokeId());
vector<byte> paramData;
op.GetParameter(paramData);
MSP
610
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");
}
}
}
SwitchKit TCAP Interface
611
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 ¬ify, 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;
}
MSP
612
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)
{
skts_destroyConnection(connection);
connection = NULL;
}
classc
SwitchKit TCAP Interface
613
SwitchKit TCAP Abstraction Level
sktal_allocateTCAPDialogID()
Description
This function allocates TCAP dialogue ID.
Syntax
int sktal_allocateTCAPDialogID(int instanceId, unsigned *did);
Input Parameters
Argument Description
instanceID Instance for given node/stack/SNN combination
*did Pointer to the TCAP dialogue.
Input/Output Parameters
None
Output Parameters
Argument Description
dialogueId 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.
MSP
614
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 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
instanceID Instance for given node/stack/SNN combination
dialogueId TCAP dialogue ID
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.
SwitchKit TCAP Interface
615
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 Description
instance id Instance corresponding to node ID/stack ID/SSN.
Parameters
There are no input/ouput parameters, or output parameters.
Return Value
Returns a handle to control block.
MSP
616
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.
SwitchKit TCAP Interface
617
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
instanceID Instance for given node/stack/SNN combination
ev Event containing dialogue information
Input/Output Parameters
None
Output Parameters
Argument Description
dialogueId TCAP dialogue ID
cpt Pointer to the structure containing component information
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.
MSP
618
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
dialogueId TCAP dialogue ID
dlg Pointer to the structure containing TCAP dialogue information
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.
SwitchKit TCAP Interface
619
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
startRange = 0
startRange = 4096
endRange = 4095
endRange = 8191
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
localNodeId local node ID
stackId stack ID
pc point code
ssn Subsystem Number
h Handler function for new TCAP dialogues.
The prototype for new dialogue handler is:
typedef int (*SKTAL_NewDialogHandler)(int instanceId, unsigned newDialogId);
connId connection ID
MSP
620
startRange Starting dialogue ID allocated to this application (For the specific SSN)
endRange Ending dialogue ID allocated to this application (For the specifc SSN)
Input/Output Parameters
None
Output Parameters
Argument Description
instanceId 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.
SwitchKit TCAP Interface
621
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
instanceID Instance for given node/stack/SNN combination
dialogueId TCAP dialogue ID
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.
MSP
622
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
instanceID Instance for given node/stack/SNN combination
dialogueId TCAP dialogue ID
dlg 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.
SwitchKit TCAP Interface
623
sktal_setTCAPDialogueHandler ()
Description
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
instanceID Instance for given node/stack/SNN combination
dialogueId TCAP dialogue ID
handler 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.
MSP
624
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.
Return Value
None.
SwitchKit TCAP Interface
625
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.
MSP
626
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,
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);
SwitchKit TCAP Interface
627
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
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.
MSP
628
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,
TCAP_Component* cpt);
// Receive
static int Receive(SKTAL_HANDLE handle,
SKTAL_Event& ev,
TCAP_Dialogue* dlg,
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
SwitchKit TCAP Interface
629
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
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()
MSP
630
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
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
SwitchKit TCAP Interface
631
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()
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.
MSP
632
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
os: The output stream to print the contents to
Input/Output Parameters and Output Parameters
None
Return Value
None
SwitchKit TCAP Interface
633
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.
Syntax
virtual void SetComponentPresent(bool);
Input Parameters and Output Parameters
None
Input/Output Parameters
MSP
634
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;
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
The abort reason as an unsigned character.
SwitchKit TCAP Interface
635
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
None
MSP
636
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;
// Full SCCP Address (dest)
void SetDestAddr(const bool isNational,
const SKTAL_UINT pointCode,
SwitchKit TCAP Interface
637
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
Output Parameters
pointCode: the point code of this address
MSP
638
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);
GetOrigAddr()
SwitchKit TCAP Interface
639
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,
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn) const;
void GetDestAddr(SKTAL_OCTET& addrInd,
MSP
640
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn,
SKTAL_OCTET* gttInfo,
SKTAL_USHORT* gttLen) const;
void GetDestAddr(SCCP_Address& addr) const;
SwitchKit TCAP Interface
641
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.
MSP
642
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 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
SwitchKit TCAP Interface
643
virtual bool SendCheck() const;
ReceiveCheck()
See class TCAP_Dialogue
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,
MSP
644
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;
SwitchKit TCAP Interface
645
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,
TCAP_Dialogue**dlg);
// Expose the header
MSP
646
const SKTAL_HDR& GetHeader() const;
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:
If defined as ANSI:
TCPPT_TC_UNI
SwitchKit TCAP Interface
647
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
true: If a dialogue primitive has associated components
false: If a dialogue primitive has no associated components
MSP
648
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
Output Parameters
SwitchKit TCAP Interface
649
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()
Description
MSP
650
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
Older versions of ANSI TCAP do not support application context. This method is virtual.
SwitchKit TCAP Interface
651
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
Input/Output Parameters
MSP
652
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;
Input Parameters, Input/Output Parameters, & Output Parameters
SwitchKit TCAP Interface
653
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
Input/Output Parameters and Output Parameters
MSP
654
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
This method exposes the SKTAL_HDR part of the received dialogue.
SwitchKit TCAP Interface
655
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
MSP
656
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.
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);
SwitchKit TCAP Interface
657
Input Parameters
onOff (true false)
Input/Output Parameters and Output Parameters
None
Return Value
None
MSP
658
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)
isNational: an indicator that this code is national or private
SwitchKit TCAP Interface
659
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
MSP
660
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;
SwitchKit TCAP Interface
661
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,
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;
// Timeout
void SetTimeOut(const SKTAL_USHORT val);
SKTAL_USHORT GetTimeOut() const;
// Operation class
// 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
MSP
662
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
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;
SwitchKit TCAP Interface
663
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
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
MSP
664
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
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
SwitchKit TCAP Interface
665
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.
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
MSP
666
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()
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
SwitchKit TCAP Interface
667
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
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
MSP
668
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
SwitchKit TCAP Interface
669
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
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);
MSP
670
family: the problem types. Problem types are defined in Appendix A.
Input Parameters, Input/Output Parameters, & Output Parameters
None
Return Value
None
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()
SwitchKit TCAP Interface
671
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);
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;
MSP
672
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;
SwitchKit TCAP Interface
673
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;
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()
MSP
674
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()
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
SwitchKit TCAP Interface
675
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.
Return Value
None
MSP
676
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;
SetComponentPresent()
SwitchKit TCAP Interface
677
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
The report cause as an unsigned character. The following are the report cause values:
SCCP_RET_NO_TRANS_ADDR_NAT
MSP
678
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,
SKTAL_OCTET& priority) const;
SetApplicationContext()
SwitchKit TCAP Interface
679
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;
MSP
680
TCAP_Unidirectional : public TCAP_Dialogue class
Purpose
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();
SwitchKit TCAP Interface
681
SetOrigAddr()
Description
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
MSP
682
This method decodes the origination address for this dialogue primitive into discrete information.
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
SwitchKit TCAP Interface
683
void SetDestAddr(const bool isNational,
const SKTAL_UINT pointCode,
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,
MSP
684
SKTAL_UINT& pointCode,
SKTAL_OCTET& ssn,
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
SwitchKit TCAP Interface
685
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,
BACK_IP, BACK_PORT);
if (ret == 0)
{
fprintf(stderr, "Error connecting to switch\n");
return (SKTAL_EINVALIDARGS);
}
return (SKTAL_SUCCESS);
}
MSP
686
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,
newDialogue, &instance, CONN_ID);
if (ret != SK_OK)
{
fprintf(stderr, "Error registering handler: %s\n", sk_errorText(ret));
skts_destroyConnection(CONN_ID);
SwitchKit TCAP Interface
687
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
// 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)
{
MSP
688
printf("Failed to send component: %d\n", ret);
}
else
{
// Send TCAP dialogue.
ret = sktal::TCAP_Dialogue::Send(sktal_getTCAPHandle(instance),
&begin);
if (ret != SKTAL_SUCCESS)
{
printf("Failed to send dialogue: %d\n", ret);
}
}
SwitchKit TCAP Interface
689
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);
if (dlg)
{
dlg->Print(std::cout);
}
}
else if (TCAP_MSG_TYPE(ev) == SKTAL_TCAP_CPT)
MSP
690
{
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);
}
}
SwitchKit TCAP Interface
691
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)
{
skts_destroyConnection(CONN_ID);
connection = NULL;
}
MSP
692
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_NOT_USED 0x0
TCPPN_OF_REPLY_REQUIRED 0x80 Operation family reply required.
TCPPN_OF_PARAMETER 0x01 Operation family parameter.
TCPPN_OF_CHARGING 0x02 Operation family charging.
TCPPN_OF_PROV_INST 0x03 Operation family provisioning instruction.
TCPPN_OF_CONN_CTRL 0x04 Operation family connection control.
TCPPN_OF_CALLER_INT 0x05 Operation family caller inter.
TCPPN_OF_SEND_NOT 0x06 Operation family send notification.
TCPPN_OF_NET_MAN 0x07 Operation family network management.
TCPPN_OF_PROCEDURAL 0x08 Operation family procedural.
TCPPN_OF_IS41 0x09 Operation family IS41.
TCPPN_OF_MISC 0xFE Operation family Misc.
TCPPN_OF_RESERVED 0xFF
Table A-2> ANSI TCAP Operation Specifier
Name Value Description
TCPPN_OS_PROV_VAL 0x01 Operation specifier provision value.
TCPPN_OS_SET_VAL 0x02 Operation specifier set value.
SwitchKit TCAP Interface
693
TCPPN_OS_BILL_CALL 0x01 Operation specifier bill call.
TCPPN_OS_START 0x01 Operation specifier start.
TCPPN_OS_ASSIST 0x02 Operation specifier start.
TCPPN_OS_CONN 0x01 Operation specifier connection.
TCPPN_OS_TEMP_CONN 0x02 Operation specifier temporary connection.
TCPPN_OS_DISCONN 0x03 Operation specifier dsconnect.
TCPPN_OS_FWD_DISCONN 0x04 Operation specifier forward disconnect.
TCPPN_OS_PLAY_A 0x01 Operation specifier play announcement.
TCPPN_OS_PLAY_A_CD 0x02 Operation specifier play announcement.
TCPPN_OS_AUTO_CALL_GAP 0x01 Operation specifier automatic call gap.
TCPPN_OS_TEMP_HO 0x01
Table A-3> ANSI TCAP P-Abort Reason
Name Value Description
TCPABT_REASON_UNREC_PACK_TYPE 0x01 Unrecognized package type.
TCPABT_REASON_INCORRECT_TRANS_PORT 0x02 Incorrect Transaction portion.
TCPABT_REASON_BADLY_STRUCT_TRANS_PORT 0x03 Badly structured transaction portion.
TCPABT_REASON_UNREC_TRANS_ID 0x04 Unrecognised transaction Id.
TCPABT_REASON_PERM_TO_RELEASE 0x05 Permission To release.
TCPABT_REASON_RES_UNAVAIL 0x06 Resource unavailable.
Table A-4> ANSI TCAP Error Codes
Name Value Description
MSP
694
TCPERR_UNEX_COMP_SEQ 0x01 Unexpected component sequence
TCPERR_UNEX_DATA_VAL 0x02 Unexpected data value
TCPERR_UNAV_RESOURCE 0x03 Unavailable resource
TCPERR_MISSING_REC 0x04 Missing record
TCPERR_REPLY_OVERDUE 0x05 Reply overdue
TCPERR_DATA_UNAV 0x06 Data unavailable
TCPERR_TSK_RE 0x07
TCPERR_Q_FULL 0x08 Queue full
TCPERR_NO_Q 0x09 No queue
TCPERR_TMR_EX 0x0A Timer expiry
TCPERR_DAT_EX 0x0B Data already exists
TCPERR_UNAUTH 0x0C Unauthorised Request
TCPERR_NOT_QD 0x0D Not queued
TCPERR_UAS_DN 0x0E Unassigned DN
TCPERR_SPARE 0x0F Spare
TCPERR_NOT_AV 0x10 Not Available
TCPERR_VMSR_E 0x11 VMSR error
Table A-5> ANSI TCAP Problem Code Specifier
Name Value Description
TCPPROB_GENERAL 0x01 General Problem.
TCPPROB_INVOKE 0x02 Invoke Problem.
TCPPROB_RETURN_RES 0x03 Return Result Problem.
TCPPROB_RETURN_ERR 0x04 Return Error Problem.
TCPPROB_TRANS_PORTION 0x05 Transaction Portion Problem.
Table A-6> ANSI TCAP Problem Codes
Name Value Description
SwitchKit TCAP Interface
695
TCPPROB_SPEC_GEN_UNREC_COMP 0x01 General problem unrecognised component
TCPPROB_SPEC_GEN_INCORRECT_COMP 0x02 General problem incorrect component
TCPPROB_SPEC_GEN_BADLY_STRUCT_COMP 0x03 General problem badly structured component
TCPPROB_SPEC_INV_DUPLICATE_INV_ID 0x01 Invoke problem duplicate invoke id
TCPPROB_SPEC_INV_UNREC_OP_CODE 0x02 Invoke problem unrecognized operation code
TCPPROB_SPEC_INV_INCORRECT_PARAM 0x03 Invoke problem incorrect parameter
TCPPROB_SPEC_INV_UNREC_COREL_ID 0x04 Invoke problem unknown correlation id.
TCPPROB_SPEC_RES_UNREC_COREL_ID 0x01 Result problem unrecognized correlation id.
TCPPROB_SPEC_RES_UNEXPECTED_RET_RES 0x02 Result problem unexpected return result
TCPPROB_SPEC_RES_INCORRECT_PARAM 0x03 Result problem incorrect parameter
TCPPROB_SPEC_ERR_UNREC_COREL_ID 0x01 Error problem unrecognized correlation id
TCPPROB_SPEC_ERR_UNEXPECTED_RET_ERROR 0x02 Error problem unexpected
MSP
696
return error
TCPPROB_SPEC_ERR_UNREC_ERROR 0x03 Error problem unrecognized error
TCPPROB_SPEC_ERR_UNEXPECTED_ERROR 0x04 Error problem unexpected error
TCPPROB_SPEC_ERR_INCORRECT_PARAM 0x05 Error incorrect parameter
TCPPROB_SPEC_TRANS_UNREC_PACK_TYPE 0x01 Unrecognised package type
TCPPROB_SPEC_TRANS_INCORRECT_TRANS_PORT 0x02 Incorrect transaction Portion
TCPPROB_SPEC_TRANS_BADLY_STRUCT_TRANS_PORT 0x03 Badly structured transaction
TCPPROB_SPEC_TRANS_UNREC_TRANS_ID 0x04 Unrecognised transaction ID
TCPPROB_SPEC_TRANS_PERM_TO_RELEASE 0x05 Permission To release
TCPPROB_SPEC_TRANS_RES_UNAVAIL 0x06 Resource unavailable
SwitchKit TCAP Interface
697
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_AC_NOT_SUP 0x01 Application context not supported.
TCPUABT_USER_DEFINED 0x02 Reason user defined.
TCPUABT_DLG_REFUSED 0x03 Dialogue refused.
Table A-8> TU TCAP P-Abort Reason
Name Value Description
TCPPABT_ABNORMAL_DLG 126 Abnormal dialogue.
TCPPABT_NO_COMMON_DLG 127 No common dialog.
TCPABT_REASON_UNREC_MSG_TYPE 0x00 Unrecognized message type.
TCPABT_REASON_UNREC_TRANS_ID 0x01 Unrecognized transaction Id.
TCPABT_REASON_BADLY_STRUCT_TRANS_PORT 0x02 Badly structured transaction portion.
TCPABT_REASON_INCORRECT_TRANS_PORT 0x03 Incorrect trnsaction portion.
TCPABT_REASON_RES_UNAVAIL 0x04 Resource unavailable.
Table A-9> ITU TCAP Reject Problem Types
Name Value Description
TCPPROB_GENERAL 0x00 General problem.
MSP
698
TCPPROB_INVOKE 0x01 Invoke problem.
TCPPROB_RETURN_RES 0x02 Return Result problem.
TCPPROB_RETURN_ERR 0x03 Return Error problem
Table A-10> ITU TCAP Reject Problem Codes
Name Value Description
TCPPROB_SPEC_GEN_UNREC_COMP 0x00 General problem unrecognized component.
TCPPROB_SPEC_GEN_MISTYPED_COMP 0x01 General problem mistyped component.
TCPPROB_SPEC_GEN_BADLY_STRUCT_COMP 0x02 General problem badly structured component.
TCPPROB_SPEC_INV_DUPLICATE_INV_ID 0x00 Invoke problem duplicate invoke id.
TCPPROB_SPEC_INV_UNREC_OP_CODE 0x01 Invoke problem-unrecognized operation code.
TCPPROB_SPEC_INV_MISTYPED_PARAM 0x02 Invoke problem mistyped parameter.
TCPPROB_SPEC_INV_RESOURCE_LIMIT 0x03 Invoke problem resource limitation.
TCPPROB_SPEC_INV_INITIATE_RELEASE 0x04 Invoke problem initiate release.
TCPPROB_SPEC_INV_UNREC_LINKED_ID 0x05 Invoke problem-unrecognized linked id.
TCPPROB_SPEC_INV_UNEXPECTED_LINK_RESP 0x06 Invoke problem unexpected linked response.
TCPPROB_SPEC_INV_UNEXPECTED_LINKED_OP 0x07 Invoke problem unexpected linked operation.
TCPPROB_SPEC_RES_UNREC_INVOKE_ID 0x00 Result problem unrecognized invoke id.
SwitchKit TCAP Interface
699
TCPPROB_SPEC_RES_UNEXPECTED_RET_RES 0x01 Result problem unexpected return result.
TCPPROB_SPEC_RES_MISTYPED_PARAM 0x02 Result problem mistyped parameter.
TCPPROB_SPEC_ERR_UNREC_INVOKE_ID 0x00 Error problem unrecognized invoke id.
TCPPROB_SPEC_ERR_UNEXPECTED_RET_ERROR 0x01 Error problem unexpected return error.
TCPPROB_SPEC_ERR_UNREC_ERROR 0x02 Error problem unrecognized error.
TCPPROB_SPEC_ERR_UNEXPECTED_ERROR 0x03 Error problem unexpected error.
TCPPROB_SPEC_ERR_MISTYPED_PARAM 0x04 Error problem mistyped parameter.
MSP
700
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 System Data Type
SKIM_BOOLEAN unsigned int.
SKIM_OCTET unsigned char.
SKIM_USHORT unsigned short.
SKIM_UINT unsigned int.
SKIM_ULONG unsigned long.
SKIM_CHAR char
SKIM_SHORT short
SKIM_INT int
SKIM_LONG long
Table B-2> SKIM Return Codes
Error Codes Values
SKIM_SUCCESS 0
SKIM_FALSE 0
SKIM_TRUE 0x1
SKIM_ENOMEM -1
SKIM_ERCVFAIL -6
SKIM_ENOMSG -8
SKIM_ESENDFAIL -9
SKIM_ETCAPMSGSENDFAIL -13
SKIM_BADTCAPMESSAGE -16
SwitchKit TCAP Interface
701
SKIM_ETOOMANYDIALOGS -18
SKIM_ENOINVID -20
SKIM_ENOMUTEX -24
SKIM_EBADMUTEX -25
SKIM_EINVALIDARGS -39
SKIM_ENOLICENSE -45
SKIM_EPROTERR -46
SKIM_EOVERFLOW -49
SKIM_EINITFAIL -52
SKIM_EINUSE -55
SKIM_EDESTPROHIBIT -56
SKIM_EINVPTYPE -57
SKIM_EINVOPFAM -58
SKIM_EINVOPSPEC -59
SKIM_EINVLEN -60
SKIM_ENULLPTR -61
SKIM_EBADSTATE -64
SKIM_ENOTFOUND -65
SKIM_EASNENCODE -66
SKIM_EASNDECODE -67
SKIM_EINVOPC -72
SKIM_EINVDPC -73
SKIM_EINVINITSTATE -86
MSP
702
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.
Table C-1> SKTAL Data Types
Data Types Description
SKTAL_BOOLEAN unsigned int.
SKTAL_OCTET unsigned char.
SKTAL_USHORT unsigned short.
SKTAL_UINT unsigned int.
SKTAL_ULONG unsigned long.
SKTAL_CHAR char
SKTAL_SHORT short
SKTAL_INT int
SKTAL_LONG long
SKTAL_HANDLE void
SKTAL_POINTER char
SKTAL_ByteArray 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) ((ev)->data[0])
#define SKTAL_TCAP_DLG 1
#define SKTAL_TCAP_CPT 2
SwitchKit TCAP Interface
703
Table C-2 SKTAL Return Codes
Code Value
SKTAL_SUCCESS 0
SKTAL_FALSE 0
SKTAL_TRUE 0x1
SKTAL_BITS_PER_BYTE 8
SKTAL_ENOMEM -1
SKTAL_ERCVFAIL -6
SKTAL_ENOMSG -8
SKTAL_ESENDFAIL -9
SKTAL_ETCAPMSGSENDFAIL -13
SKTAL_BADTCAPMESSAGE -16
SKTAL_ETOOMANYDIALOGS -18
SKTAL_ENOINVID -20
SKTAL_ENOMUTEX -24
SKTAL_EBADMUTEX -25
SKTAL_EINVALIDARGS -39
SKTAL_ENOLICENSE -45
SKTAL_EPROTERR -46
SKTAL_EOVERFLOW -49
SKTAL_EINITFAIL -52
SKTAL_EINUSE -55
SKTAL_EDESTPROHIBIT -56
SKTAL_EINVPTYPE -57
SKTAL_EINVOPFAM -58
SKTAL_EINVOPSPEC -59
SKTAL_EINVLEN -60
SKTAL_ENULLPTR -61
SKTAL_EBADSTATE -64
SKTAL_ENOTFOUND -65
SKTAL_EASNENCODE -66
SKTAL_EASNDECODE -67
MSP
704
SKTAL_EINVOPC -72
SKTAL_EINVDPC -73
SKTAL_EINVINITSTATE -86
SKTAL_ALREADY_REGISTERED -121
SKTAL_STACK_IN_USE -122
SKTAL_NO_MORE_STACKS -123
SKTAL_NO_MORE_DIDS -124
SKTAL_INVALID_ARG -125
SKTAL_BAD_MUTEX -126
SwitchKit TCAP Interface
705
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 TCAP_END_PREARRANGED
#define TCP_NO_CPT TCAP_NO_CPT
#define TCP_CPT_PRESENT TCAP_CPT_PRESENT
#define TCP_MORE_CPTS TCAP_MORE_CPTS
#define TCP_LAST_CPT 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))
MSP
706
/********************************************************************
* *
* 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];
}
CPT_INV_ID;
typedef struct cpt_op
{
SKTAL_USHORT len;
SKTAL_OCTET data [OP_SIZE];
}
CPT_OP;
typedef struct cpt_param
{
SwitchKit TCAP Interface
707
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 */
}
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)
MSP
708
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.
*/
typedef struct cpt_cancel
{
CPT_INV_ID invoke_id;
}
CPT_CANCEL;
/*
* Timer Reset primitive (ITU White Book 97 only). REQ only.
*/
SwitchKit TCAP Interface
709
#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 *
* *
********************************************************************/
/*
* Dialog substructures
*/
typedef struct dlg_qos
{
SKTAL_OCTET indicator;
SKTAL_OCTET sls_key;
SKTAL_OCTET priority;
MSP
710
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;
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
{
SwitchKit TCAP Interface
711
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;
SKTAL_OCTET termination; /* 0 or 1 */
}
DLG_END;
/*
* ITU U-ABORT. REQ only.
* ITU P-ABORT. IND only.
* ANSI ABORT, IND only.
*/
MSP
712
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 ptype; /* primitive type (TCPPT_xxx values) */
Union
{
DLG_UNI uni;
DLG_BEGIN begin;
DLG_CONTINUE cont;
DLG_END end;
DLG_ABORT abort;
DLG_NOTICE notice;
}
u;
}
SKTAL_DLG;
SwitchKit TCAP Interface
713
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
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 Excel Switching Corporation are:
Customized Application for Mobile network Enhanced Logic (CAMEL)
Universal Mobile Telecommunications System- Mobile Application Part (UMTS- MAP) which includes Global System for Mobile communication - Mobile Application Part (GSM-MAP)
ANSI - 41
Wireless Intelligent Network (WIN)
For installation instructions on these codecs see, the following documents (available from Excel Switching Corporation):
CAMEL User’s Guide, document part number P_EXCL_CAMEL_UG_2.0
UMTS MAP User’s Guide, document part number P_EXCL_UMTS_MAP_UG_2.0
WIN User’s Guide, document part number P_EXCL_WIN_UG_2.0
ANSI 41D User’s Guide, document part number P_EXCL_AS41D_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.
MSP
714
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 Section 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 Section 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.
715
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)
SCCP/TCAP per MSP
Base SS7 MTP2/MTP3 License 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
MSP
716
Software Modules Licensing
SS7 Links Licensing
Licensing Information (ClientView)
Introduction to SS7 Monitoring
Resource Points
Configuring Licensing
VoIP Licensing
Developer Information
717
System Software Licensing
Overview
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.
MSP
718
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.
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
MSP I/O card ID
Specific IN and Wireless protocols
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)
Wireless Intelligent Network (WIN)
Intelligent Network Application Part (INAP)
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)
Developer Information
719
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.
MSP
720
SS7 Links Licensing
Licenses for SS7 Links
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.
Licenses for Redundant SS7 Links
A Product License Key is invalid for redundant SS7 links.
Developer Information
721
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.
MSP
722
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.
Developer Information
723
Software Overview
Application Requirements (Non-SwitchKit)
Overview
This section explains what you should include in your application so that it will work effectively with the MSP if you do not use SwitchKit. The diagram below shows the application modules required.
Application Modules
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.
MSP
724
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
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 no adjacent MSP is detected.
The standby MSP sends Poll messages that indicate that its state has switched from standby to switchover, and then to active.
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.
Developer Information
725
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
Calculating checksums
Handling special characters
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
MSP
726
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
Overview
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.
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
Adding facilities
Changing the existing configuration
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:
Developer Information
727
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, 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
Minor
Major
Alarm Type
Alarms are identified by the following types:
General
Span
Channel
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
MSP
728
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
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 Cantata 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 Cantata 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
Developer Information
729
PPL Audit Query
NGA Configure 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. 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.
MSP
730
Changing System Software Version
Overview
To download a new version of system software, you must define the new MSP binary filename.
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.
Developer Information
731
Downloading System Software to the MSP
Overview
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 listed below.
Host Flag Tag Values
The following host flags dictate which software download method to use and which codecs to download. Remember to convert these values from hex to decimal before entering them in the BOOTP server sofware described below.
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 Linux
Configuring a Host Flag Using Solaris
MSP
732
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.
Configuring a Host Flag Using BOOTP Server
TFTP
This procedure explains how to set up downloading software to the MSP 1010 via TFTP. The host flag dictates which software download method to use.
This procedure uses Weird Solutions BOOTP Server NT running on Windows NT but you can use any BOOTP server running on any platform.
1) Double-click BOOTP Server NT from the Control Panel to display the Weird Solutions BOOTP Server NT dialog box.
2) Select the Options tab.
3) Complete this information as follows:
Type Host Flag in the Name box.
Type 134 in the Tag box.
Select 32 bit number in the Type box. Click Add.
4) Scroll down the list of names on the Options page to verify that your entry appears with the correct information.
Developer Information
733
5) Select the Clients tab. Select the hardware address that requires the host flag in the Hardware Address box.
Click New and enter the MAC address of the MSP 1010. To obtain the MAC address of the MSP 1010, power up the unit and record the MAC address printout on the front panel’s LCD display.
6) Select Host Flag in Available options box and click >> button.
MSP
734
7) Select Host Flag in the Configured options box and click Edit button.
8) Enter 3 in the Value box and click OK button.
9) Click OK button to exit the Host Flag Tag configuration.
10) If you had set the Host Flag to 3 the corresponding bootptab file generated from Weird Solution’s BOOTP Server entries would read as follows.
[Options]
Host Flag=134, int
[00-20-1C-04-03-09]
Template=<no template>
Bootfile=msp1010_id0100.bin
IP Address=135.119.51.9
Subnet mask=255.255.255.0
Host Flag=3
11) Restart the Weird Solutions BOOTP Service. Follow the next three steps if you are using Weird Solutions TFTP Turbo.
12) Double-click the TFTP Turbo from the Control Panel to display the Weird Solutions TFTP Turbo properties box.
13) Under the General tab, increase the Timeout (seconds) from 3 to 5
14) Restart the Weird Solutions TFTP Turbo service.
FTP
Developer Information
735
This procedure explains how to set up downloading software to the MSP 1010 via FTP.
This procedure uses Weird Solutions BOOTP Server NT and 3CDaemon running on Windows NT but you can use any FTP server running on any platform.
1) Double-click BOOTP Server NT from the Control Panel to display the Weird Solutions BOOTP Server NT dialog box.
2) Select the Options tab.
3) Complete this information as follows:
Type Host Flag in the Name box.
Type 134 in the Tag box.
Select 32 bit number in the Type box. Click Add.
4) Scroll down the list of names on the Options page to verify that your entry appears with the correct information.
5) Select the Clients tab. Select the hardware address that requires the host flag in the Hardware Address box.
Click New and enter the MAC address of the MSP 1010. To obtain the MAC address of the MSP 1010, power up the unit and record the MAC address printout on the front panel’s LCD display.
6) Select Host Flag in Available options box and click >> button.
7) Select Host Flag in the Configured options box and click Edit button.
8) Enter 2 in the Value box and click OK button.
9) Click OK button to exit the Host Flag Tag configuration.
MSP
736
10) If you had set the Host Flag to 2 the corresponding bootptab file generated from Weird Solution’s BOOTP Server entries would read as follows.
[Options]
Host Flag=134, int
[00-20-1C-04-03-09]
Template=<no template>
Bootfile=msp1010_id0100.bin
IP Address=135.119.51.9
Subnet mask=255.255.255.0
Host Flag=2
11) Restart the Weird Solutions BOOTP Service.
12) Configure the FTP server as follows:
Username: excelsw
Password: excelsw
User Directory: <define the path where the binary files are located>
13) Start the FTP server.
14) Power up the MSP 1010.
Configuring a Host Flag Using Linux
Developer Information
737
This procedure explains how to load software on the MSP 1010 using TFTP or FTP by configuring a host flag using the Linux operating system.
TFTP
1) Install DHCP and TFTP if necessary.
2) Extend the TFTP timeout in /etc/xinetd.d/tftp by adding the -T option in the server_args:
service tftp
{
disable = no
socket_type=dgram
protocol=udp
wait=yes
user=root
server=/usr/sbin/in.tftpd
server_args=-t 5000000 -v -c -s/tftpboot
per_source=11
cps=100 2
flags=IPV4
}
3) Define the Host Flag option by modifying the /etc/dhcp.comf as follows:
ddns-update-style ad-hoc;
ddns-update-style ad-hoc;
# Which logfile group... log to /var/log/messages
LogFile = messages;
allow bootp;
# declare global vender options
option Host_Flag code 134 = signed integer 32;
########################################################
subnet 10.10.138.0 netmask 255.255.255.0 {
host MSP1010 {
hardware ethernet 00:20:1C:04:03:09;
fixed-address 10.10.138.90;
next-server 10.10.138.13; # tftp server name
filename "msp1010_id0100.bin"; # tftp path
relative to -s server_args in /etc/xinetd.d/tftp
option Host_Flag 3; #TFTP, E1
4) Restart DHCP/TFTP service.
5) Power up the MSP 1010.
MSP
738
FTP
1) Install DHCP if necessary.
2) Define the Host Flag option by modifying the /etc/dhcpd.com as follows:
ddns-update-style ad-hoc;
# Which logfile group... log to /var/log/messages
LogFile = messages;
allow bootp;
# declare global vender options
option Host_Flag code 134 = signed integer 32;
########################################################
subnet 10.10.138.0 netmask 255.255.255.0 {
host MSP1010 {
hardware ethernet 00:20:1C:04:03:09;
fixed-address 10.10.138.90;
next-server 10.10.138.13; # ftp server name
filename "/tftpboot/msp1010_id0100.bin";
option Host_Flag 2; #FTP, E1
}
3) Create an FTP profile on a host with FTP access.
User: excelsw
Password: excelsw
4) Restart the DHCP/FTP service.
5) Power up the MSP 1010.
Configuring a Host Flag Using Solaris
This procedure explains how to load software on the MSP 1010 using TFTP or FTP by configuring a host flag using the Solaris operating system.
The host flag dictates which software download method to use. Refer to Host Flag Tag Values (3-13) for the list of the eight options.
TFTP or FTP
This procedure is very similar for TFTP users and FTP users. The differences are noted in procedure.
There are three phases to this overall procedure. You should perform the entire procedure as root.
Phase 1 uninstalls the BOOTP patch that was installed in Solaris-8 before the DHCP patch was available.
Phase 2 installs the DHCP patch supplied by SUN Microsystems.
Phase 3 configures the DHCP service.
Developer Information
739
Important! For Solaris 9, the DHCP patch is not required.
Phase 1
1) Open the /etc/inetd.conf file and delete the following line
bootps dgram udp wait root /etc/bootpd bootpd
2) Refresh the inetd daemon process. First get the inetd process ID
ps –ef|grep inetd
3) Then send a refresh signal to that process ID:
Kill -HUP psid
Phase 2
1) Make a temporary directory under /export/home, called patch
mkdir /export/home/patch
2) Change the current directory to be /export/home/patch.
cd /export/home/patch
3) Get the recommended patch (109077-07) from the FTP server (135.119.36.254) at the following location. The login and password are ftpuser/ftp1.
˜/LSS32/System_Patches/109077-07.jar
4) Extract the patch bundle:
/usr/java1.2/bin/jar xvf 109077-07.jar
This step creates create two folders, 109077-07 and META-INF,and put respective files in them.
5) Run the patchadd utility with the proper location
patchadd /export/home/patch/109077-07
6) The patchadd utility will apply the needed patches and will inform what packages were installed.
7) After the patches are installed, reboot the system.
Phase 3
1) Ensure that the DISPLAY variable is set to your local X-Server.
2) Start the DHCP Deamon.
/etc/init.d/dhcp start
3) Run DHCMGR from the following directory:
/usr/sadm/admin/bin/dhcpmgr
4) Define the Host Flag option as indicated on the screen below:
MSP
740
5) TFTP users create the macro and set the Host Flag value to 3 as indicated on the screen below:
FTP users create the macro and set the Host Flag value to 2.
6) Create the address entry for MSP 1010. You must enter 01 before the MAC address. The 01 represents the Ethernet address and is needed for the DHCP configuration files. Alpha characters in the MAC address have to be in uppercase.
Select the Services>Modify menu. Deselect the duplicate IP addresses option as indicated below:
Developer Information
741
8) Restart the DHCP service.
9) FTP Only: Create the FTP profile on a host with FTP access as follows:
User: excelsw
Password: excelsw
10) Power up the MSP 1010.
Initiating a Download
Once you set the host flag, you can initiate a download using a BOOTP server.
BOOTP Server Download
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
MSP
742
TFTP Downloading Using BOOTP Response Message
Developer Information
743
Downloading MSP System Software Using Boot File on an SD Card
A BootP server is used to configure the following:
· MSP CTRL IP address
· subnet mask
· gateway address
· FTP server address
· FTP file name of the MSP system software
If a BootP server is not available but the remote FTP Server is available, you can use the SD card to configure these parameters.
Steps
1. Insert the SD Card into an SD Writer connected to a PC.
2. Open the bootup.cfg file.
3. Change the Host Flag in the bootup.cfg file to "Retrieve boot from server".
Host Flag Values (Hex/Dec)
0x00/0 = Boot from FTP, T1 system
0x02/2 = Boot from FTP, E1 system
4. Edit the Server Address to the address of your FTP server where the MSP .bin file is located.
5. Make sure the Boot Filename is the same as the actual file you want to transfer.
6. Save the bootup.cfg file.
7. Insert the SD card into the slot on the Front Panel of the MSP.
8. Power-up the MSP.
MSP
744
Developer Information
745
Downloading MSP System Software From an SD Card
If an FTP server is not available to transfer the MSP System Software, the file can be loaded from the SD Card.
Steps
1. Insert the SD Card into an SD Writer.
2. Open the bootup.cfg file.
3. Change the Host Flag to "Retrieve boot from SD Card".
Host Flag Values (Hex/Dec)
0x20/32 = Boot from SD Card, T1 system
0x22/34 = Boot from SD Card, E1 system
4. Make sure the System Software Filename in the bootup.cfg file matches the .bin file on the card.
5. Save the bootup.cfg file.
6. Remove the SD card from the SD Writer.
7. Insert the SD card into the SD slot on the Front Panel of the MSP.
8. Power-up the MSP.
MSP
746
Distributing IMG System Software Using an SD Card
If you have remote MSPs that cannot obtain an MSP System Software upgrade using FTP or BootP, you can transfer the file to SD cards and distribute the SD cards to remote sites. You can edit the Bootup.cfg file on each card with the Boot configuration information for the IMG to which it will be shipped.
Developer Information
747
Fault Diagnostics
Overview
The Fault Diagnostics feature is designed to aid Cantata 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.)
Fault information
Performance information (CPU utilization, task/memory 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 Cantata 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.
MSP
748
Installing and Configuring a BOOTP Server
Overview
To have system software downloaded automatically upon start-up, you must install a BOOTP Server. UNIX systems have an embedded BOOTP Server. If you are using an NT system, you must acquire third party BOOTP server software.
You must configure the BOOTP Server with the following:
MAC address
IP address of the MSP1010
Subnet
Default gateway
Host Flag
Boot File (which is the MSP1010 binary file)
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.
UNIX
To configure the FTP or TFTP server on a UNIX system, you must modify the following files:
ethers
bootptab
Important! If you are using a Solaris OS, you must create these two files.
Modifying the ethers file
You must enter the hardware address of the MSP to which the software is to be downloaded. A sample entry to the ethers file is shown below.
00:20:1C:01:14:3C rack1
Developer Information
749
Installing and Configuring a FTP Server
Overview
You must install and configure a FTP server to download system software files. The FTP binary file to download is stored on the FTP Server.
UNIX systems have an embedded FTP Server. If you are using a Windows NT system, you must acquire third-party FTP server software.
UNIX
To enable the FTP server, you must edit the inetd.conf file.
1) Open the file and locate the line shown below:
#ftp strean tcp6 nowait root /usr/sbin/in.ftpd
2) Remove the pound symbol (#) to enable the FTP Server.
ftp strean tcp6 nowait root /usr/sbin/in.ftpd
3) Restart the in.inetd process by rebooting the host.
4) On a Sun Microsystems Operating System, you can use the KILL command to start the process by entering the following:
kill -process_id of the in.inetd -HUP
5) To locate the process ID, enter the following:
ps -axe | grep in.inetd
MSP
750
Installing and Configuring a TFTP Server
Overview
You must install and configure a TFTP server to download system software files. The TFTP binary file to download is stored on the TFTP Server.
UNIX systems have an embedded TFTP Server. If you are using a Windows NT system, you must acquire third-party TFTP server software.
UNIX
To enable the TFTP server, you must edit the inetd.conf file.
1) Open the file and locate the line shown below:
#tftp dgram udp wait root /usr/etc/in.tftpd in.tftpd -s /tftpboot
2) Remove the pound symbol (#) to enable the TFTP Server.
tftp dgram udp wait root /usr/etc/in.tftpd in.tftpd -s /tftpboot
3) Restart the in.inetd process by rebooting the host.
4) On a Sun Microsystems Operating System, you can use the KILL command to start the process by entering the following:
kill -process_id of the in.inetd -HUP
5) To locate the process ID, enter the following:
ps -axe | grep in.inetd
Developer Information
751
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.
2. Enter the IP address.
3. Enter the following:
User: excel <Enter>
Password: excel2004 <Enter>
MSP
752
4. Now you can enter commands that you want to send your MSP 1010.
Developer Information
753
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
Sniffer Pro from Network Associates
Ethereal
MSP
754
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 on - 90 percent
Major threshold off - 85 percent
Minor threshold off - 80 percent
Memory Consumption
Minor threshold on - 90 percent
Major threshold on - 95 percent
Major threshold off - 93 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.
Developer Information
755
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 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.
MSP
756
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.
Developer Information
757
SwitchKit
SwitchKit provides the following core functional areas needed for your application to work effectively with the Multi-Services Platform.
Host Connection
Communications
Message Management
Configuration
Alarm Manager
Real-time Logging
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 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.
MSP
758
Multi-Host
Introduction to Multi-Host
Prior to this feature
The MSP opened a TCP server socket on TCP ID 0x3142. Any host could connect to this socket to transfer and receive API messages. There could be only one connection per Host ID.
The TCP socket was in 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 intented to handle MSPs in unmanned locations.
With this feature
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, up to three ports are supported. The host can configure what TCP ID to listen on (for example 0x3142, 0x3143, and 0x3144.)
Once you add Host Links, the following MSP applications can use them by per Host Link ID.
TCAP
SS7 Monitoring
MTP3 To Host
Benefits
The multi-host features provides the following benefits:
Host redundancy
Greater control of the MSP
Greater bandwidth for the host port
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
Developer Information
759
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 MSP initiated 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. 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.
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.
MSP
760
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 (0x0000-0xFFFF) 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 Host Link ID range from 0-2.
The Multi-Link Configure message includes a Local Socket Address which is currently not supported.
Configure Applications
Once you add the host links and map them to local socket IDs, you configure the applications to use them.
Refer to Multi-Host Applications.
Developer Information
761
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-2). 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.
MSP
762
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.
Developer Information
763
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
PPL component configuration
Answer supervision and release modes
VoIP
IP Address
Resource Attributes
MSP
764
Logical Spans
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
Developer Information
765
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)
TLVs
Use the following TLVs:
Physical Node ID TLV (0x8102) - 8 bytes for the I/O serial number
Logical Node ID TLV (0x8100) - range of 0-63, 255 (default)
Node Name TLV (0x8103) - name of the node, limited to one line on the LCD display. Up to 12 bytes.
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 Address TLV (0x8104) - address type IPV4 (default) or IPV6
Remote Node Transport Method TLV (0x8105) - transport type Ethernet or UDP/IP (default).
MSP
766
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 re-send 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.
Developer Information
767
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 Address TLV (0x8144) - IPV4 (default) or IPV6
Local Port ID TLV (0x8146)
MSP
768
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 Mode TLV (0xE050)
Port Speed TLV (0xE051)
Port Duplex (0xE052)
Developer Information
769
Configuring Licensing
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
MSP
770
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.
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.
Developer Information
771
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.
MSP
772
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.
Developer Information
773
Configuring the DSP Service State
Overview
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.
MSP
774
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.
Developer Information
775
Configuring Access to the NFS Server
Use the Generic Card Configure (0x0122) message to do the following:
Select NFS server
Configure server ID, IP address, server name, and mount name
Identifies location of Vocabulary Index File
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
File Management
Server Address
Vocabulary Index File
TLVs in Optional Message
NFS Alarm
DSP-2 Main Board Memory Alarm
DSP-2 Temporary Memory/Alarm Threshold
Statistics Update Timer TLV
NFS User Group ID TLV
NFS Poll Retries
Temporary Record File Timer
MSP
776
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
Noise Gating Enable
Nose Gate Parameters
Echo Suppression Enable
Echo Suppression Paramters
AGC Enable AGC Input Level
AGC Parameters
Conference Failure Behavior
Developer Information
777
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. 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
MSP
778
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
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
Developer Information
779
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
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)
MSP
780
Optional TLVs)
None
Query
Use the Generic Card Query 0x0123 message to query the module-level defaults for PVD/AMD.
Developer Information
781
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
MSP
782
Configuring T1 Spans
Use the T1 Span Configure (0x00A9) message to define the characteristics of a T1 span including:
framing (D4, ESF)
line coding method
signaling method
line length
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
Developer Information
783
Configuring E1 Spans
Use the E1 Span Configure (0x00D8) message to define the characteristics of an E1 span including
line coding method
error checking
signaling method
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
MSP
784
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
Developer Information
785
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
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
MSP
786
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
notify host of answer
propagate answer to distant end and 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.
Developer Information
787
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
release with host notify (E&M)
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.
MSP
788
Configuring the PCM Encoding Format
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.
Developer Information
789
Configuring the DSP Service State
Overview
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.
MSP
790
DS0 Status Change
Use the DS0 Status Change (0x0042) message reports a change in channel status to the host. These changes include:
in service
out of service
parked
purged
Enabling group messages with the System Configuration messages reduces the message congestion when all spans and channels are brought into service.
Developer Information
791
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.
MSP
792
SS7 Configuration
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 reset
go active
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
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 component
restart SSM (default)
Developer Information
793
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
ISUP
L3P
TUP
SCCP
TCAP
You assign each layer a variant:
ANSI
ITU-TS
BT IUP
SSUTR2
JT
The multiple stacks allow the MSP to communicate with multiple networks.
Next Task
Configuring SS7 Link Set
MSP
794
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.
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
Developer Information
795
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 set
link ID
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
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
MSP
796
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
Destination ID - defines the relationship of a signaling stack and a specific DPC.
Route ID
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
Developer Information
797
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:
Stack ID
Base CIC number
Base CIC span
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
MSP
798
CIC Start Up Procedure
Overview
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 start-up. 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).
Developer Information
799
Configuring SCCP TCAP
Overview
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 Use the SS7 SCCP/TCAP Configure message to...
Adjacent Translator
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 .
Other Concerned Point Code
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.
SCCP/TCAP Default Parameter Table
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 Unidialog_As_ID
TCAP Protocol Version
You do not need to configure this table unless you require
MSP
800
modifications.
Subsystem
(Based on default parameter table)
Configure the default parameter table for a particular sub-system. Set the Config Type byte to 0x05.
TCAP Object Syntax Descriptor (OSD)
Set the Config Type byte to 0x06. You can modify a TCAP object by indicating the TCAP object parameter ID, TCAP identifier, whether or not to update the object syntax and if updated, what the object syntax description is.
See TCAP Object Syntax Descriptor (OSD) Configuration.
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.
Network DPC/SSN
Set the Config Type byte to 0x07 to configure the Destination Point Code (DPC) and remote subsystem number.
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.
Replicated SSN
Set the Config Type byte to 0x09 to configure the replicated SSN.
Global Title Translation
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
Subsystem Default Parameter Table
TCAP Active Transactions
TCAP Active Operations
Related Topics
Deconfiguring SCCP/TCAP
GTT Configuration Samples
Developer Information
801
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 Link Set Configure
SS7 Signaling Route Configure
4. Deconfigure the stack using the SS7 Stack Configure message.
MSP
802
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
PPL Entity which is always PPL Configuration Bytes
Configuration data including the number of data locations, byte number, and data
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
Developer Information
803
Bringing Spans Into Service
Once you completed configuring SS7, use the Service State Configure (0x000A) message to bring spans and signaling links into service.
MSP
804
ISDN Configuration
Configuring ISDN
This section describes the procedures for configuring primary rate ISDN and National ISDN PRI NI 2. The first four steps of the basic ISDN configuration are described in more detail in other parts of this documentation:
Span Configuration
D Channel Configuration
B 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 API Message
1 Configure Spans -Assign Logical Span IDs
- Configure span formats
Assign Logical Span ID
T1 Span Configure
E1 Span Configure
2 Configure the D channels
- Assign D channels
- Configure D channels
- Add NFAS Facilities
D Channel Assign
ISDN Interface Configure
D Channel Facility List Configure
3 Configure the B channel
Configure B channel options
B Channel Configure
4 Optional Configuration
- PPL Customization
Developer Information
805
- Features
5 Bring spans and channels in service
Bring spans, D channels, and B Channels in service
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
1 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.
2 Assign logical span IDs to spans and channels. Use the Assign Logical Span ID (0xA8) message.
3 Configure the T1 Span. Use the T1 Span Configure (0xA9) message.
4 Assign a channel as an ISDN PRI D channel. Use the D Channel Assign (0xC4) message.
5 Define the connection type for National ISDN PRI NI 2 user side as 0x09. Use the ISDN Interface Configure (0x60) message.
6 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)
For Facility Number, select 0x01-0x1E, depending on the number of spans being added.
7 Define the network type for the B channels. Use the B Channel Configure (0xC8) message.
For the Network Type (0x01) field, select 0x01 (Do Not Include Network-Specific Facilities IE)
8 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.
MSP
806
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.
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.
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.
Example
The following is an example of the ISDN Query message to query the General Interface Options and the response from the MSP 1010.
API Message
Trace H->X FE 00 0E 00 63 00 00 01 00 01 0D 03 00 01 17 01 00
Byte Field Description Value and Indication
0 Frame 0xFE
1, 2 Length 0x000E
3, 4 Message Type 0x0063
5 Reserved 0x00
6 Sequence Number 0x00
Developer Information
807
7 Logical Node ID 0x01
8 AIB Address Method 0x00 (Single Entity)
9 Number of Address Elements
0x01
10 Address Element Type
0x0D (Channel)
11 Data Length 0x03
12, 13
Data[0,1] Logical Span ID
0x0001
14 Data[2] Channel 0x17 (Channel 23)
15 Query Type 0x01 (General Interface Options)
16 Query Subtype 0x00 (None)
17 Checksum 0xCS (not shown in trace)
API Response
Trace X->H FE 00 1B 00 63 00 00 01 00 10 00 01 00 00 00 01 00 00 00 01 00 01 00 01 00 01 00 03 00 00
Byte Field Description Value and Indication
0 Frame 0xFE
1, 2 Length 0x001B
3, 4 Message Type 0x0063
5 Reserved 0x00
6 Sequence Number 0x00
7 Logical Node ID 0x01
10, 11 Data[0,1] Connection Type 0x0001 (Lucent 4ESS)
12, 13 Data[2,3] Options 0x0000 (No options)
14, 15 Data[4,5] D Channel Physical Medium 0x0001 (64 Kbps)
16, 17 Data[6,7] HDLC Bit Polarity 0x0000 (Normal)
18, 19 Data[8,9] Network Side Layer 2 0x0001 (Network Side (C/R Bit Inverted))
20, 21 Data[10,11] B Channel Selection Mode 0x0001 (Linear Clockwise)
22, 23 Data[12,13] Location 0x0001 (Private Network/Local User)
MSP
808
24, 25 Data[14,15] Channel Release Request on ISDN Disconnect
0x0001 (Send Host Channel Release Request on ISDN Disconnect)
26 Data[16,17] Protocol Discriminator Value for Maintenance Messages
0x0003 (Default)
28 Data[18,19] B Channel Encoding for Transmission 0
x0000 (Channel Number)
30 Checksum 0xCS (not shown in trace)
Developer Information
809
ISDN D Channel Configuration
This section describes the second step in the basic ISDN configuration sequence. See Configuring ISDN.
Assigning D channels
Configuring D Channel options
Adding facilities (for NFAS)
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.
Example
The following is an example of the D Channel Assign message. The example assumes the ISDN component is assigned to Slot 8 for backward compatibility.
Trace H->X FE 00 0E 00 C4 00 00 01 00 01 15 04 08 00 00 17 00
Byte Field Description Value and indication
0 Frame 0xFE
1, 2 Length 0x000E
3, 4 Message Type 0x00C4
5 Reserved 0x00
MSP
810
6 Sequence Number 0x00
7 Logical Node ID 0x01
8 AIB - Address Method 0x00 (Single Entity)
9 Number of Address Elements
0x01
10 Address Type 0x15 (Primary D Channel)
11 Data Length 0x04
12 Data[0] Slot Number 0x04
13, 14 Data[1] Logical Span ID
0x0000
15 Data[3] Channel 0x17 (Channel 23)
16 Secondary D Channel Facility Number
0x00
17 Checksum 0xCS (not shown in trace)
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. 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
Connection Type Lucent 4ESS
D Channel Physical Medium 64 kbps
HDLC Bit Polarity Normal
Network Side Layer 2 User Side
B Channel Selection Mode Linear Clockwise
Location User
Developer Information
811
Layer 4 Channel Release Request on ISDN DISCONNECT
Disabled
Protocol Discriminator Value for Maintenance Messages
3
B Channel Encoding for Transmission
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 out-of-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
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
DMS100 and DMS 250
AUSTEL
JATE
EURO User Side
EURO Network Side
MSP
812
N12
Example ISDN Interface Configure Message
The following is an example of the ISDN Interface Configure message.
Trace H->X FE 00 0F 00 60 00 00 01 00 01 0D 03 00 00 17 01 00 01
Byte Field Description
Value and Indication
0 Frame 0xFE
1, 2 Length 0x000F
3, 4 Message Type 0x0060
5 Reserved 0x00
6 Sequence Number 0x00
7 Logical Node ID 0x01
8 AIB - Address Method
0x00 (Single Entity)
9 Number of Address Elements
0x01
10 Address Element Type
0x0D (Channel)
11
Data Length 0x03
12, 13
Data[0,1] Logical Span ID
0x0000 (Span 0)
14 Data[2] Channel 0x17 (Channel 23)
15 Entity 0x01 (Connection Type)
16, 17
Data[0,1] Value x0001 (Lucent 4ESS)
18 Checksum 0xCS (not shown in trace)
Adding Facilities
Developer Information
813
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 Number must be from 1-19 (0 is the D channel facility number).
Facility must be assigned (use the Assign Logical Span ID message).
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.
D Channel Facility List Configure Message Example
The next example shows the D Channel Facility List Configure message adding Logical Span ID #2, and assigning it to facility #1 for D channel 00,17.
Trace H->X FE [00 12] [00 C6] 00 04 01 00 02 0D 03 00 00 17 0C 02 00 02 01 01]
Byte Field Description
Value and Indication
0 Frame 0xFE
1, 2 Length 0x0012
3, 4 Message Type 0x00C6
5 Reserved 0x00
6 Sequence Number 0x04
7 Logical Node ID 0x01
8 AIB - Address Method
0x00 (Single Entity)
9 Number of Address Elements
0x02
10 Address Element 0x0D (Channel)
MSP
814
Type
11
Data Length 0x03
12, 13
Data[0,1] Logical Span ID
0x0000 (Span 0)
14 Data[2] Channel 0x17 (Channel 23)
15 Address Element 2
Address Type 0x0C (Span)
16 Data Length 0x02
17, 18
Data[0,1] Logical Span ID
0x0002
19 Action 0x01
20 Facility Number 0x01
21 Checksum 0xCS (not shown in trace)
Developer Information
815
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
Network Type AT&T Megacom
Outgoing Information Transfer Capability
Voice
Calling Number Type National Number
Calling Number Plan ID
ISDN Numbering Plan
Calling Presentation Indicator
Presentation Allowed
Calling Screening Indicator
User Provided, Not Screened
Called Number Type Subscriber Number
Called Number Plan ID
Unknown Numbering Plan
MSP
816
Developer Information
817
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 Action
1 Use the D Channel Assign message to configure the type and location of the D channel. After the primary D channel is configured, configure the backup D channel (using the D Channel Assign message again). Include the span, channel, and facility number on which it resides.
2 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 de-assigned; it becomes de-assigned when the primary D channel is de-assigned.
3 Use the second facility (1) to configure the backup D channel; (however, 1-19 are permissible).
4 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.
5 When the D channels align and process the SERVICE/SERVICE ACK exchange, the host receives a DS0 Status Change message
MSP
818
(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.
Compliance
The MSP 1010 software is compliant with the Primary Rate Interface guidelines defined in Lucent TR 41459 specification, as follows:
Layer 2
Layer 2 provides information frames to Layer 3. For both D channels, all unnumbered, supervisor, and information frames are processed as described in the Lucent specification. Since the protocol is run over primary rate, the SAPI and TEI are both 0. Data links do not know if the D Channel Backup is enabled or disabled.
Layer 2 is managed by the following Layer 3 D Channel Control messages (primitives):
DL Establishes Request
DL Remove Request
DL DM Remove Request
DL Data Request
Layer 3
Layer 3 complies with Lucent specification TR41459. The L3 D Channel Control component (0x0A) handles the D channel backup logic. Each state represents both D channel states. The L3 DSM manages the following:
Distribution of incoming and outgoing information frames to the other components in Layer 3
The switchover procedure (sending SERVICE and SERVICE ACK messages on the D channel)
Developer Information
819
Distribution of the indication to appropriate component to preserve active calls
Reporting of D channel failure
Reporting status to the L3P D Channel Control component (0x06)
Reporting status to the host using the PPL Event Indication message
When a D channel changes state, the host receives one of the following events in the PPL Event Indication message:
D is Active (0x00001)
D is Standby (0x0002)
D is not aligned (0x0003)
The D channel failure event is sent from L3 D Channel Control component to the L3P D Channel Control component only when both D channels are not aligned. L3P does not know the state of both D channels; it only knows that at least one D channel is accessible, or that both D channels are not.
Any call not in Active State gets cleared on a switchover. The host receives a Channel Released message for the bearer channel to which the call was in transition.
Layer 3 Plus
L3P automatically requests a switchover when either span goes into an alarm condition. The L3P B Channel Control component informs the host about channel service states. When both D channels are not established, it resends the Alarm message to the host to indicate the establishment of a D channel.
MSP
820
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
VoIP Module MSP
Example Configuration for VoIP Modules
Refer to the following topics to configure VoIP using the Excel API:
Configuring the IP Address
Configuring Resource Attributes
Assigning Logical Spans
Related topics
VoIP Overview
VoIP Resource Profiles
Codec Overview
Codec Payload Sizes
Dynamic Payload Type
Developer Information
821
Configuring the IP Address
Use the IP Address Configure (0x00E7) message to configure the following for the VoIP module.
IP Address
Subnet Mask
Gateway Address
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
MSP
822
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 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
Voice
Fax
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)
RTP Source Port (0x2793) - Can be even or odd port number.
Destination IP Address (0x2794)
RTP Destination Port (0x2795)
Voice Attributes
Use the following TLVs to set the voice attributes for the VoIP module:
Developer Information
823
RTP Payload Type (0x0100) - Specifies the algorithm used to compress payload.
Payload Size - (0x0101) - Multiplication factor of basic packet rate
RTP Silence Suppression (0x0102) - Enables RTP packets with silence-encoded compressed payloads
RTP Echo Cancellation (0x0103) - Eliminates echo introduced by impedance mismatched hybrids.
RTP Payload Redundancy (0x01D1) - Enables the re-transmission of previous packet(s) payload with current packet payload.
Minimum Jitter Buffer Delay (0x01C2) - Sets minimum delay between 0-150 ms.
Maximum Jitter Buffer Delay (0x01C3) - Sets Maximum delay between 150-200 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 Bypass Coder Type (0x01C7) - Specifies the high speed codec used in fax bypass mode. Only G.711 allowed in current release.
Fax Payload Redundancy (0x01D2) - Enables the re-transmission of previous packet payload with current packet payload.
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.
MSP
824
Next task
Assigning Logical Spans
Developer Information
825
Assigning Logical Spans
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.
MSP
826
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 Cantata 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.
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
Developer Information
827
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.
MSP
828
SS7
Basics of SS7
Overview
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
Network management
Maintenance
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 (ITU-TS) 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
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
Developer Information
829
SS7 Point Codes
The following discussion of point codes applies to any point codes:
Originating Point Code (OPC)
Adjacent Point Code (APC)
Destination Point Code (DPC)
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
Binary 8 Bits 8 Bits 8 Bits
Hex FF FF FF
Decimal 255 255 255
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
MSP
830
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:
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:
Developer Information
831
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
MSP
832
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)
Service Control Point (SCP)
Intelligent Peripheral (IP)
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
redundant configurations - up to 128 links in two link increments
64/128 link sets
128 destinations
512 routes
Parts of SS7 Architecture
The MSP implements the following parts of the SS7 architecture:
Message Transfer Part (MTP) - Levels 1-3
Integrated Services Digital Network User Part (ISUP)
Signaling Connection Control Part (SCCP)
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)
Developer Information
833
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
MSP
834
SS7 Software Architecture
Overview
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
TCAP
SCCP
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
CC RSRT TLAC
HMDT RTAC TPRC
HMRT RTCC TRCC
IAC RTPC TSFC
LLSC RTRC TSRC
LSAC SLTC TXC
LSC TCBC
RC SUERM 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
Data Transfer
Developer Information
835
Management Control
Refer to SCCP/TCAP for a complete explanation of the SCCP/TCAP implementation in the 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
MSP
836
Causes of SS7 Signaling Link Problems
Purpose
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.
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
Developer Information
837
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.
MSP
838
SS7 Redundancy Overview
Introduction
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
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:
Developer Information
839
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
All components have the following states:
Initial
Startup
Offline
Reset
Fail
Active
All redundant components have these additional states:
Active Sync
Active W/ Peer
Active Lost Peer
Standby Sync
Standby
Standby Lost Peer
Related Topics
Example Configuration for SS7 Redundancy (ClientView)
Configuring Redundancy on the SS7
SS7 Redundancy Process
MSP
840
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
Active_with_Peer
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.
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)
Logical Node ID (0x8100) TLV, Links 64-127 for MSP 2
Remote Node Address (0x8104) 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)
Logical Node ID (0x8100) TLV, Links 0-63 for MSP 1
Remote Node Address (0x8104) TLV, Links 0-63 for MSP 1
Developer Information
841
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.
MSP
842
SS7 Redundancy Process
The figure below show the messaging and state changes associated with a basic SS7 redundancy scenario.
Developer Information
843
Configurable SS7 Component Attributes
Introduction
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 Reset
Go Active
Go Standby
See SS7 State Transitions for more information.
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 Count
Component Failure Restart State
Component Failure Behavior
The host can configure the appropriate behavior in the event of a component failure. Options include:
Wait for Host Control
Restart the component
Restart SSM (Default)
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.
MSP
844
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
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.
Developer Information
845
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.
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
MSP
846
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.
Developer Information
847
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
Redundant
The next figure illustrates the state transitions and host interaction in the SS7 component for redundant SS7 configurations.
Redundant SS7 State Machine
MSP
848
Developer Information
849
Host Link Failure
Purpose
The Host Link Failure 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 of service.
Configuring
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 MSP 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)
Minimum - 0
Maximum - 6000 (0x1770)
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
03 03 67 02 00 01 Signaling FA
64 02 10 00 SS7
64 02 10 30 SCCP
00 03 e0 01 00 02 00 02
Command (0-add, 1-del, 2-mod)
e0 35 00 05 01 00 00 17 70
hlf cfg - enable, timer 60 seconds.
90 80 00 01 01 hlf behavior (SSN OOS)
H-X)
[00 29 01 30 00 00 ff 03 03 67 02 00 01 64 02 10 00 64
MSP
850
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]
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
03 03 67 02 00 01 Signalling FA
64 02 10 00 SS7
64 02 10 30 SCCP
00 03 # TLV's
e0 21 00 03 03 00 00 Query Response Message Info
e0 35 00 05 01 00 00 17 70 HLF
90 80 00 01 00 SSCP HLF Failure Behavior
Developer Information
851
Message Transfer Part (MTP)
Overview
This section includes information on the following MTP features:
Preventive Cyclic Retransmission (PCR)
Craft Alerting
ANSI Activation Link Test
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:
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
MSP
852
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
0 Frame 0xFE
1 Length, MSB 0x00
2 Length, LSB 0x15
3 Message Type, MSB 0x00
4 Message Type, LSB 0xD7
5 Reserved 0x00
6 Sequence Number 0x00
7 Logical Node ID 0xFF
8 AIB (starting with Byte 0):
Address Method
0x00 (Single Entity)
9 Number of Address Elements
0x01
10 Address Element 1: Originating Channel Address Type
0x09 (SS7 Signaling Link)
11 Data Length 0x02
12 Data[0] Stack ID 0x00
13 Data[1] Link ID 0x01
14 PPL Component ID, MSB
0x00
15 PPL Component ID, LSB
0x26 (SS7 MTP2 TXC)
16 PPL Entity 0x01 (PPL Config Bytes)
17 Configuration Data
Number of Data Locations
0x03
18 Location 1: Byte 0x02
Developer Information
853
Number
19 Location 1: Data 0x01 (PCR)
20 Location 2: Byte Number
0x04
21 Location 2: Data 0x0F
22 Location 3: Byte Number
0x05
23 Location 3: Data 0xA1 (with byte 4: 4,001)
24 Checksum 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
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).
MSP
854
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)
Set Config Byte 1 (Variant) to 0x03 (China)
HMRT component (0x002C)
Set Config Byte 1 (Variant) to 0x03 (China)
Important! MTP PPL configuration byte values are listed in the section, 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.)
Developer Information
855
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).
MSP
856
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
An 8-bit Originating Point Code (OPC) identifying point of origin for the message.
A Signaling Link Selection field (SLS) that is used to distribute message traffic over all possible redundant links and routes.
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
Developer Information
857
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
MSP
858
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.
Developer Information
859
MTP3 to Host
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.
MSP
860
Developer Information
861
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.
MSP
862
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.
Developer Information
863
Software Modifications
The following summarizes the changes to the software to support this feature. The detailed formats are below this summary.
HMDT PPL 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)
MSP
864
Event ID Event
0x0A TRANSFER REQ
Used to send MSU data.
Parameter IDs - 0x0424, 0x0425, 0x0426
PPL Event Indication for the HMDT Component (0x002B)
Event ID Event
0x14 TRANSFER IND
Used to send MSU data.
Parameter IDs - 0x0424, 0x0425, 0x0426
PPL Event Indication for the TSFC Component (0x003F)
Event ID Event
0x15 PAUSE IND
Parameter ID - 0x0427
0x16 RESUME IND
Parameter ID - 0x0427
0x17 STATUS IND
Parameter ID - 0x0427
PPL Event Parameters
ICBType 0x03 (Extended Data)
ICB ID 0x0424
Data Length
2 bytes
0x000D
Data[0-3] DPC - Destination Point Code
Data[4-7] OPC - Originating Point Code
Data[8-9] CIC - Circuit ID Code
Developer Information
865
Data[10] SI - Service Indicator
Data[11] MP - Message Priority
Data[12] NI - Network Indicator
ICBType 0x03 (Extended Data)
ICB ID 0x0425
Data Length
2 bytes
0x000C
Data[0-3] DPC - Destination Point Code
Data[4-7] OPC - Originating Point Code
Data[8] SI - Service Indicator
Data[9] MP - Message Priority
Data[10] NI - Network Indicator
Data[11] SLS - Signaling Link Set
ICBType 0x03 (Extended Data)
ICB ID 0x0426
Data Length
2 bytes
Up to 0x010E
Data[0-1] Length - Length of MSU Data
Data[2-n] MSU Data -
Length up to 0x010C
ICBType 0x03 (Extended Data)
ICB ID 0x0427
Data Length
2 bytes
Up to 0x0006
Data[0-3] Affected DPC
Data[4] Cause Value
Value 0 - congestion level 0
Value 1 - congestion level 1
MSP
866
Value 2 - congestion level 2
Value 3 - congestion level 3
Value 4 - User Part Unavailable
Value 5 - User Part Unequipped
Value 6 - User Part Inaccessible
Data[5] User Part
PPL Configuration Bytes for HMDT Component (0x002B)
AIB: SS7 Stack (0x08)
Byte Description Value
0x17 SCCP User Part 0x00-unavailable
0x01-available locally (default)
0x02-available remotely
0x18 TUP User Part 0x00 -unavailable
0x01-available locally (default)
0x02-available remotely
0x19 ISUP User Part 0x00-unavailable
0x01-available locally (default)
0x02-available remotely
0x1A-0x23 Other User Part 0x00-unavailable(default)
0x01-available locally
0x02-available remotely
0x27 Remote host port number for SCCP UP
0x00-forces routing to port 0x3142
0x01-forces routing to port 0x3143
0x02-forces routing to port 0x3144
0x03-forces routing to
Developer Information
867
port 0x3145
0x04-forces routing to port 0x3146
0x05-forces routing to port 0x3147
0xFF-(Default) force routing disabled
0x28 Remote host port number for TUP UP
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
0x29 Remote host port number for ISUP UP
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 Subtype 0x002B MTP3 UP Parameters
ICB Length MSB, LSB Length of Parameters
MSP
868
in bytes
Parameter 1: Type
2 bytes Identifies parameter
Parameter 1: Length
2 bytes Length of parameter data in bytes
Parameter 1: Value
Variable size Size in bytes
: : :
Parameter n: Type
2 bytes Identifies parameter
Parameter n: Length
2 bytes Length of parameter data in bytes
Parameter n: Value
Variable size Size in bytes
Developer Information
869
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.
MSP
870
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.
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
Developer Information
871
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.
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
MSP
872
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
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
Developer Information
873
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
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
MSP
874
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
Developer Information
875
ISUP
Introduction to ISUP
Overview
The Integrated Services Digital Network User Part (ISUP) is used for establishment of wired connections between exchanges. It includes messages associated with the connection and disconnection of calls. ISUP is the protocol used to support the signaling necessary to provide voice and non-voice services in telephone communications. It is an extension of SS7, used as the interface protocol for voice and data within, and for ingression or egression to/from the Public Switched Telephone Network (PSTN.)
Advantages of ISUP
There are numerous advantages to using ISUP for call processing and trunk group maintenance/management functions. These advantages include the following:
Faster call setup
Conservation of network resources
Improved customer feature support as well as enhanced features
Improved/Automated trunk management procedures
ISUP requires that the exchange be digital and support SS7. This does not mean that the exchange cannot interface with non-SS7 capable devices or exchanges. All that is required is that the exchange be able to interwork with other signaling types such as TUP, R2, R1, DTMF and/or SS7.
Definition
The ISDN User Part defines the protocol which is used to support the signaling functions required for both a) Non-ISDN voice/data communications and b) ISDN voice/data communications in North America, and for ISDN functionalities throughout the rest of the world. ISUP can also be used to support dedicated/private telecommunications systems consisting of either digital or analog or mixed networks. The data from ISDN messages is transferred to ISUP messages for call processing or data transfer. They are two separate protocols that function together. ISDN can be thought of as a user-side and network-side protocol while ISUP is strictly network side. ISDN may also be used between exchanges, but that is not the primary intent of the protocol. There is enough flexibility and spare capacity within the protocol to support present application requirements as well as, any foreseeable future requirements.
Currently the ISDN User Part is designed to use the services of the SS7 Message Transfer Part (MTP). The use of the SS7 Signaling Communication Control Part Network has been provided for in the specification but, at present, no procedures exist that require the use of the SCCP for ISUP. ISUP connects to the SS7 MTP as User Part 5. Because ISUP exists as a User Part, all Layer 4, 5, 6, and 7 functions are handled within the software that comprises ISUP.
Inter-Exchange Signaling
MSP
876
ISUP is used for the exchange of data between exchanges. Data is passed in messages between exchanges for call processing, maintenance, and circuit management. These messages are in the standard SS7 format of the MSU. The actual ISUP data is carried within the SIF.
An understanding of these messages is important as it allows you to know what type of data is being transferred between exchanges at any given moment in time. There are many messages defined in the ITU and ANSI standards. However, very few exchanges, if any, support all of them. It is a good idea to be familiar with the various messages even if they are not supported by your exchange. It is possible that one of these unsupported messages may be received at your exchange, and it is important to know how to deal with it.
ISUP Call Control and Circuit Management API
The host manages ISUP call control and circuit management through the following mechanisms:
Common Call Control API message (for example Outseize Control, Request for Service with Data), using SS7 Parameter (ISUP) to pass data.
Channel State
DS0 Status Change messages notify the host of service state changes and channel purges. The Service State Configure message allows the host to bring channels in and out-of-service.
The PPL Event Indication and PPL Event Request messages allow the host to send and receive messages to and from PPL components.
The MSP 1010 sends PPL Event Indication (0x0043) messages to the host in response to various SS7-related call processing events, such as reception of an ACM, ANM, or CON (for ITU only) for ISUP.
Data is included in the SS7 Parameter ICB (ISUP). If you do not require this information, ACK the message and then ignore it.
The host can generate SS7-related call processing or management events using the PPL Event Request (0x0043) message.
You can modify the default call model to have the Called and Calling Party Numbers passed to the host as BCD encoded digits.
Related Topic
Example Configuration for SS7 Voice Circuits.
Developer Information
877
ISUP Incoming Call Setup
Overview
This section includes call flow examples for ISUP incoming call control.
Diagram of Incoming SS7 Call Handling
The figure below illustrates the default interaction between the host and the SS7 PPL components during an incoming SS7 call. Shading identifies the software components involved in the call.
Sequence of Default Incoming Call
The default incoming call sequence shown in the diagram above is described in the table below.
Stage Description
1 Raw ISUP messages are received by MTP and passed to ISUP.
2 ISUP SPRC is responsible for routing the data to the appropriate component. Assuming the data is for a valid CIC, it is routed to ISUP CPC for processing. If the data is maintenance related, it is routed to MPC. In the event of an unrecognized message type or invalid CIC, a CFN or UCIC is sent to the network (for ANSI only).
3 Assuming no error conditions occur, ISUP consults the ISUP Message Configuration Template to identify the message and translate the raw data into the format of an SS7 Parameters ICB to pass to L3P.
To modify the ISUP message formats, the host issues the ISUP Msg Config (0x006B) message. The host can configure which parameters are included and can also customize messages for ISUP variants.
4 L3P passes generic setup indication messages to Layer 4, which drive Layer 4 into an inseized state and generate a Request For Service With Data message to include an SS7 parameters ICB with all received parameters to the host.
You can modify this format to specify the parameters passed or to have the Called and Calling Party passed to the host as BCD encoded digits.
Call Flows
The call flows in this section include more details about the numbered messages. The numbered messages are described following each call flow.
Basic Incoming Call Setup
MSP
878
The following call flow uses a Voice Response Unit (VRU) as the outgoing leg of a tandem connection. The VRU is a T1 E&M wink start channel. More details about the numbered messages are provided following the call flow.
1) When using the default L3P, all SS7 parameters in the IAM pass to the host in the Request For Service With Data message in the following format (see Information Control Blocks section in the API Reference for information on ICB formats):
Parameter Name
Parameter Length
Parameter Value
You can also configure L3P to send the called and calling party digits as BCD-encoded digit strings by modifying the PPL Configuration Bytes for component 0x000F, byte 0x08, to set 0x00 or 0x01. (See Request for Service message format.)
2) The host must acknowledge the Request For Service With Data message or the MSP 1010 resends the message once after 5 seconds.
3) The host must provide mandatory SS7 parameters within the PPL Event Request (0x0044) message for the ACM and ANM as determined by the following:
Connect With Data message with SS7 Parameters ICBs (the parameters for each must be sent in separate ICBs). For ANM and ACM, this condition allows the host to dynamically overwrite any pre-stored parameters in the L3P CIC Configuration Bytes.
Connect message using preprogrammed parameter values in the L3P CIC PPL Configuration Bytes.
Generate Call Processing Event of Answer using pre-programmed ACM and ANM message in PPL Event Request (0x0044) message with parameters included.
Propagate answer from VRU using pre-programmed parameters.
Developer Information
879
4) Because the Voice Response Unit (VRU) is running asynchronously to the MSP 1010, Answer can return anytime after the Wink.
Incoming Call Setup Using CON (Instead of ACM/ANM - for ITU Only)
The following call flow shows a VRU as the outgoing leg of a tandem connection using CON. The VRU is a T1 E&M wink start channel.
1) When using the default L3P, all SS7 parameters included in the IAM pass to the host in the Request For Service With Data message in the following format (see the Information Control Blocks section in the API Reference for information on ICB formats):
Parameter Name
Parameter Length
Parameter Value
You can configure the L3P to send the called and calling party digits as BCD-encoded digit strings by modifying the PPL Configuration Bytes (see Request for Service Message format.)
2) The host must ACK the Request For Service With Data message or the MSP 1010 will resend the message once after 5 seconds.
3) The host must provide the mandatory SS7 parameters for CON as determined by the following:
Connect With Data message with SS7 Parameters ICBs (the parameters for each must be sent in separate ICBs).
Connect message using preprogrammed parameter values in the L3P CIC PPL Configuration Bytes.
MSP
880
Generate Call Processing Event of Answer using defaults stored in CON parameter.
Propagate Answer event from the VRU using pre-programmed CON parameters.
4) Because the VRU is running asynchronously to the MSP 1010, Answer returns anytime after the Wink.
5) Connect is set based on the specified setting in L3P CIC Configuration Byte 9.
Incoming Call Setup with Host-initiated Release
Developer Information
881
1) The host must provide at least the mandatory parameters for the forward REL, either of the following:
Release With Data message
Release message using preprogrammed parameter values in the L3P CIC PPL Configuration bytes
2) The Channel Released With Data message contains an SS7 parameter ICB with the parameters from the incoming RLC (Release Complete).
3) A Channel Released message indicates that the VRU channel is idle and ready for a new call.
Incoming Call Rejection by Host
1) The Channel Release With Data message contains an SS7 Parameter ICB with the REL parameters.
Incoming Call with Answer Supervision Mode of “Notify Only”
MSP
882
1) With Answer Supervision set to Notify Only, answer is not propagated to the SS7 channel. A Call Processing Event of Answer is sent to the host for the VRU.
2) To answer an SS7 call, the host may use the Generate Call Processing Event of Answer. The parameters for the ANM will be retrieved from the PPL Configuration Bytes. To control parameters within the ANM message, send L3 PPL Event Request (0x0044) of Answer with Parameters followed by Generate Call Processing Event of Answer to satisfy Layer 4.
Developer Information
883
ISUP Outgoing Call Setup
Overview
This section includes call flow examples for ISUP outgoing call control.
Outgoing SS7 Call Setup Diagram
This diagram illustrates the interaction between the host and the SS7 PPL components in the handling of an outgoing SS7 call. Shading identifies the software components involved in the call.
Default Call Sequence
The table below describes the default outgoing call sequence.
Stage Description
1 An outgoing call is initiated by the host to the Outseize Control message. The MSP 1010 will accept address data as either BCD-encoded digits or in
MSP
884
an SS7 Parameters ICB. The Outseize Control message drives L4 into an outseize state and an outseize request is sent to L3P.
NOTE: The Outseize Instruction List Configure message is not supported for SS7. All outseize instructions must be included in the Outseize Control message.
2
L3P CIC translates the L4/L5 event into an ISUP event. Any parameters sent from L4/L5 are concatenated with pre-stored parameter data in the PPL Configuration Bytes.
3 The parameters and events are sent to the appropriate ISUP Component. If parameter validation is successful, the parameters are formatted into a raw SS7 message and sent to ISUP SPRC. If validation fails, a PPL Event Indication message of Protocol Violation is sent to the host.
4 ISUP SPRC routes the message to MTP for transmission.
Call Flows
The call flows in this section include more details about the numbered messages. The numbered messages are described following each call flow.
Basic Outgoing Call Setup
Any mandatory SS7 parameters not supplied by the host in an Outseize Control message are retrieved from the L3P CIC PPL Configuration Bytes.
1) An Outseize Control message ACK does not report to the host until a backward signal is received from the network.
2) The PPL Event Indication message to the host indicates the backward signal type (ACM, ANM, CPG, or CON) and an SS7 Parameters ICB with parameter data. If the host application does not require parameter data, the MSP 1010 acknowledges and ignores the PPL Event Indication message.
Outgoing Call Rejection by Network
Developer Information
885
1) The host receives a Negative Acknowledgment (NACK) to the Outseize Control message.
2) The Channel Released With Data message contains an SS7 Parameters ICB with the REL parameter data including the cause code.
BLO Received in Response to IAM
1) The Outseize Control message generates an outgoing IAM to the network.
2) The MSP 1010 receives BLO in response to IAM.
3) The MSP 1010 generates a PPL Event Indication message to the host, indicating receipt of BLO. The MSP 1010 automatically generates BLA to the network.
4) The MSP 1010 generates an Outseize Control message NACK to the host.
5) The MSP 1010 automatically generates REL to the network.
6) Upon receipt of the RLC from the network, the MSP 1010 generates Channel Released with Data message to the host.
UCIC Received in Response to IAM (ANSI only)
MSP
886
1) Outseize Control message generates outgoing IAM to the network.
2) UCIC is received in response to the IAM.
3) PPL Event Indication is generated to the host indicating UCIC.
4) RSC is generated and purge is initiated by the MSP 1010.
5) Upon receipt of RLC or UCIC from the network, DS0 status of In-Service is reported to the host.
*Generation of RSC in this call flow is the default behavior. However, PPL Configuration Byte (0x2A) in L3P CIC can suppress this message. The RLC/UCIC response to the RSC would not be received. The MSP-to-host messages will be the same regardless of the configuration byte value.
RSC Received in Response to IAM
1) Outseize Control message generates IAM to the network.
Developer Information
887
2) RSC is received in response to IAM.
3) Outseize Control message ACK is generated to the host with response status of Outseize Failure No Acknowledgment (0x1B).
4) RLC is generated automatically to the network.
5) A Channel Released with Data message is sent, notifying the host that the channel is now idle.
No Acknowledgment of IAM (Expiration of T7)
1) The Outseize Control message generates an IAM to the network.
2) T7 expires. REL is generated automatically to the network.
3) An Outseize Control ACK is reported to the host with response status 0x1B (Outseize Failure No Acknowledge).
4) Upon receipt of RLC, a Channel Released with Data message is reported to the host.
No Acknowledgment of IAM or REL (Expiration of T7)
MSP
888
1) The Outseize Control message generates outgoing IAM to the network. Front End Machine FEM Outseize ACK Timer is initiated (29 seconds). T7 is initiated upon sending of the IAM.
2) T7 expires. REL is automatically generated to the network and Outseize Control ACK is reported to the host with a response of 0x1B (Outseize Failure No Acknowledgment).
3) FEM Outseize ACK Timer expires and initiates a channel purge. An RSC is generated to the network.
4) Upon receipt of the RLC, A DS0 Status Change indicating In-Service is reported to the host.
Network-Initiated Release
An SS7 network-initiated REL may occur at any time during call setup. The call flow is the same regardless of when the REL is received.
Developer Information
889
1) Parameters in the REL are sent to the host in the Channel Released With Data message.
2) The Channel Released With Data message must be acknowledged by the host, after which the channel is in an idle state and can be used for further call processing.
Host-Initiated Release
1) The host may provide parameters for the REL message in the Release With Data message.
2) The Channel Released with Data message must be acknowledged by the host within five seconds or the MSP resends the message.
VRU-Initiated Release
MSP
890
1) The Channel Released message must be acknowledged by the host within five seconds or the MSP 1010 resends the message.
2) If the Distant End Release Mode for the VRU and the Local End Release Mode of the SS7 channel is set to Release, the SS7 channel is not automatically released. The MSP 1010 sends a Channel Release Request, indicating that it intends to release the channel. If either mode is set to park, the SS7 channel parks and a DS0 Status Change message informs the host.
Developer Information
891
ISUP Segmentation
Overview
ISUP is associated with SS7-specific voice and data call processing. It is used to set up circuit connections and to maintain those connections between end-point subscribers for the duration of a call, using SS7-controlled Circuit Identification Codes (CICs). Segmentation is used to enable faster and more efficient transfer of ISUP messages across a network using the Segmentation Message (SGM). This feature is associated with the ITU White Book, 1993 (Q.761 - Q.764)
Definition
The ISDN User Part (ISUP) 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 process is necessary whenever large blocks of data need to be transmitted across a network, to offset problems with both time delays and error correction that could lead to traffic congestion. ISUP Segmentation in this way conserves critical network resources.
Using the Segmentation Message (SGM)
The Message Transfer Part (MTP) functions as the lowest layer in the SS7 protocol stack, and it is this layer that communicates with the rest of the network. But MTP cannot send more than 272 bytes in a single message. With ISUP there is a need to transfer larger amounts of data, so the SGM message was introduced to segment any ISUP message over 272 bytes into two parts. This process allows the MTP to transfer it successfully. The two parts include the primary ISUP message and the SGM, which contains the segmented portion over 272 bytes. The SGM is sent immediately after the primary ISUP message to the MTP layer.
Each message can only be segmented once. If the information in the message is so large that even an SGM becomes insufficient, then that information will be discarded.
At the receiving end, the primary ISUP message and the Segmented portion are concatenated before processing.
PPL Information
Simple Segmentation Control (SSC) Component ID (0x85)
This is the ITU ISUP PPL component created to support the SGM message in the MSP 1010. This component takes care of the segmentation process at the transmission end and the re-assembly of the ISUP message at the receiving end.
CPC Component ID (0x12)
The ISUP CPC PPL component communicates through the SGM to the PPL SSC component.
ISUP Messages Used with SGM
MSP
892
The following messages are the only ones that can be sent or received using the SGM: IAM, ACM, ANM, CPG, and CON.
All other ISUP messages are transparent and are therefore passed through the SSC component without modifications or segmentation.
Size and Capacity
The host-to-MSP and MSP-to-host TCP message packet size is limited to 260 bytes and 492 bytes, respectively. Therefore, the ISUP message sent in a PPL Event Request from the host to the MSP 1010 cannot exceed 260 bytes.
When an ISUP message and its associated SGM are received by the PPL ITU SSC component, it will be divided into packets of 220 bytes each and then sent on to the L3P CIC PPL component.
Configuration
The outgoing SGM can be enabled or disabled based on a configuration byte setting. The CPC Configuration Byte for SGM control is “0x04”.
Configuration Bytes 0x01-0x05 are used for ISUP SCLC Component ID (0x85).
Protocol Timers
Each PPL component has multi-purpose timers, which you can activate at any time. Each component using timers has a table that contains information on specific timers (name, value). When a protocol requires a timer, an atomic function is initiated to activate one of the PPL timers and to point to an index in the component’s timer table, which contains the value for the required timer.
One timer exists for the SSC PPL Component: 0x01
PPL Events
The PPL Indication “0x32” exists for the L3P CIC PPL Component (0x0F), for sending a Segmentation indication to the host.
Atomic Functions
SSC contains the atomic functions (51-63) that manage the segmentation and re-assembly of messages.
CPC contains the atomic functions (134-138) that communicate with the SSC component.
Redundancy
Redundancy for ISUP Segmentation is available.
ISUP Segmentation Call Flows
Outgoing Call with Segmentation in IAM
Developer Information
893
The following call flow describes an outgoing call with Segmentation in IAM. After the host sends an Outseize Control message to L3P CIC, it then sends a PPL Event Request (0x60) to this component. After a setup request has been sent to CPC, and an IAM has been received by the network, an SGM message is sent to the network.
Outgoing Call with Segmentation in IAM when COT is enabled
Segmentation in ACM/ANM
The following call flow describes segmentation in an ACM/ANM message.
MSP
894
Incoming Segmentation with COT Enabled - COT Success
The following call flow describes an incoming call with segmentation and Continuity Check enabled.
Incoming Call with Segmentation
The following call flow describes an incoming call with Segmentation. The SGM message is received after the IAM at the SSC component. Once the SGM is received, the RFS and the SGM message are sent to the host. (Alternatively, the SGM message and IAM can be concatenated and a single RFS can be sent to the host if the Configuration Byte 0x02 in the SSC component 0x85 is changed to 0x00.)
Developer Information
895
Outgoing Call with Segmentation in IAM and Backward Messages
When sending a large Outseize (> 272) bytes, the message is segmented by the SSC component. The following call flow shows a typical scenario for this process.
Incoming Segmentation Timeout
This call flow describes a scenario wherein the ACM message indicates that an SGM is to follow. However, if the SGM is not received until the expiry of T34 (typically 2 s), the ACM is forwarded to the Host. Any SGM message that follows is discarded.
MSP
896
Segmentation with Continuity Failure
Developer Information
897
ISUP Continuity Check
Overview
This feature provides the Excel ANSI and ITU SS7 variants with a means to perform a continuity check to verify the integrity of the voice circuit between two exchanges before use of the circuit.
Specifications
The requirements for the Continuity Check on the outgoing circuit are provided in the following recommendations for the International Telecommunication Union (ITU):
ITU-T Q.724
ITU-T Q.761 Functional Description of the ISDN User Part of Signalling System No. 7
ITU-T Q.762 General Function of Messages and Signals of the ISDN User Part of Signalling System No. 7
ITU-T Q.763 Formats and Codes of the ISDN User Part of Signalling System No. 7
ITU-T Q.764 Signalling System No. 7 - ISDN User Part Signalling Procedures
The requirements for the Continuity Check on the outgoing circuit for the North American variant are provided in the following recommendations:
ANSI T1.113-1995 Signalling System No. 7 (SS7) - Integrated Services Digital Network (ISDN) User Part.
Required DSP Equipment
A Call Progress Tone (CPT) transmitter, and a Call Progress Analysis (CPA) receiver of appropriate PCM encoding are required in order to perform outgoing continuity checks.
Implementation
The ISUP part of the SS7 stack (ANSI and ITU-T) has provisions for a continuity check on the outgoing side of the circuit. A continuity check is initiated with either the Continuity Check Request message to the network side, or the setting of the continuity check indicator bits in the Nature of Connection Indicators mandatory parameter field within the IAM message.
These initial messages allow the network side of the circuit to loop back the chosen circuit, so that continuity testing can be done on that circuit. The CCO component within ISUP executes a continuity test to determine if the circuit to be used has continuity before it is used.
A COT message containing the Continuity Indication is sent to the network side when testing is complete. This indication determines whether continuity exists on the circuit or whether more continuity testing is required.
MSP
898
If a Continuity Recheck procedure is running (CRO for ANSI, CRCS for ITU), outgoing calls on the circuit are rejected with an error code of 0x0A.
Configuration
This section describes configuration required for the Continuity Check procedure.
Continuity Check
The Continuity Check feature is disabled by default. To enable it, change the following L3P CIC PPL Configuration Byte to 0x04 using the PPL Configure message:
ITU - Configuration Byte 135
ANSI - Configuration Byte 125
See SS7 PPL Information (7-1) for a list of PPL events that may be sent to the host from the MSP 1010 in the PPL Event Indication message.
Continuity Recheck
The Continuity Recheck procedure is enabled by default. The default number of retries is 2. These are configurable by modifying the following PPL Configuration Bytes using the PPL Configure message:
ITU - ISUP CRCS component (0x81)
Change Configuration Byte 10 to 0x00 to disable
Change Configuration Byte 11 for number of retries
ANSI - ISUP CR0 component (0x83)
Change Configuration Byte 10 to 0x00 to disable
Change Configuration Byte 11 for number of retries
To send a CCR message to the MSP 1010, send the PPL Event Request message with an event value of 0x65. To stop the sending of the CCR message, send event value 0x64.
Call Flows
CCR
The call flow for a CCR test on a circuit.
Developer Information
899
IAM with a Continuity Request
IAM with a Continuity Request and a PPL Event Indications sent to the host
If the COT test fails, it is retried until it passes or the number of retries (indicated by Configuration Byte 11 of the ISUP CRCS component (0x81)) is reached.
MSP
900
CCR Sent to Active Channel
The call flow for an error condition where a CCR is sent on an active channel.
Developer Information
901
Circuit Status Query
Overview
The Circuit Query feature allows the host to query the status of a single circuit or a range of circuits using the PPL Event Request message. A Circuit Query Message (CQM) is sent to the remote MSP 1010 (SS7 SP), which returns a Circuit Query Response (CQR) message containing the status of all the circuits. The local and remote circuit status for each circuit is sent to the host in a PPL Event Indication message.
Recovery Action for ANSI Only
For ANSI only, if the circuit is found in the invalid state by the CQM, a recovery action is taken by CQS. The host can configure the recovery action taken by the MSP 1010 using the PPL Configuration Bytes of the CQS component. Recovery actions taken by the MSP 1010 are as defined by the ANSI-ISUP T1.113 specification.
Implementation
When a CQM request is received from the host, the MSP 1010 sends a CQM message to the network. When a CQR is received from the network, the MSP 1010 sends a PPL Event Indication message to the host with an SS7 Data Parameters ICB (0x22) containing the status of the local and remote circuits. If the CQR indicates a maintenance state, the MSP 1010 takes appropriate action based on Table 2 in ANSI T1.113.4.
If a CQR is not received before the expiration of T28 (default =10 seconds), a PPL Event Indication of 0x01 is sent to the host indicating the error.
Call Flows
This call flow shows a CQM request from the host and a CQR response from the network.
Status Values
Local and Remote Status
The local and remote status are reported to the host in an SS7 Data Parameters ICB (0x22) in a PPL Event Indication message, where:
MSP
902
Data[0] Local Status
Data[1] Remote Status
One of the following values is reported for both Data[0] and Data[1].
0x00 Transient
Maintenance States
0x01 Spare (no interpretation)
0x02 Spare (no interpretation)
0x03 Unequipped
0x04 Incoming Circuit Busy, Active
0x05 Incoming Circuit Busy, Locally Blocked
0x06 Incoming Circuit Busy, Remotely Blocked
0x07 Incoming Circuit Busy, Locally and Remotely Blocked
0x08 Outgoing Circuit Busy, Active
Call Processing States
0x09 Outgoing Circuit Busy, Locally Blocked
0x0A Outgoing Circuit Busy, Remotely Blocked
0x0B Outgoing Circuit Busy, Locally and Remotely Blocked
0x0C Idle
0x0D Idle, Locally Blocked
0x0E Idle, Remotely Blocked
0x0F Idle, Locally and Remotely Blocked
0x10 to 0xFF
Spare
Developer Information
903
Circuit Validation Test and Response
Overview
This feature provides a method by which the host can request the MSP to send a Circuit Validation Test (CVT) message to the far end and process the Circuit Validation Response (CVR). The circuit validation test procedures follow the recommendations of ANSI-ISUP T1.113.
The CVT and CVR messages are used to test and ascertain the consistency in circuit translation data on both the ends of a circuit, typically during circuit turn-up procedures to make sure that the circuit characteristics match. Maintenance personnel may also execute these tests on a routine basis.
The CVT/CVR procedure may also be invoked when a User Part Unavailable message with a cause value of Remote User Part Inaccessible is received by MTP.
Implementation
To initiate a Circuit Validation Test, send a PPL Event Request of CVT (0x002F) to the L3P CIC component (0x000F). After formatting the CVT message, ISUP passes the message on to the CVT component, which passes it to MTP3, which passes it on to the destination.
The destination node collects the required circuit information and returns a CVR message to the originating CVS component, which sends a PPL event to the host. The table below shows the PPL event sent to the host depending on the CVR contents.
CVR Indicator
Circuit Group Characteristics
CIN
Parameters
CLLI
Parameters
Indication to
Host
PPL
Event
Success Match Match Don’t Care CVT Successful
0x01
Success Match No CIN Don’t Care CVT Successful
0x01
Success No Match Match Don’t Care CVT Successful
0x03*
Success Don’t Care CIN Mismatch
Don’t Care CIN Mismatch Indication
(near-end and far-end CIN sent to host)
0x02*
Success Don’t Care CIN Not Don’t Care CVT 0x01
MSP
904
Supported successful
Failure Don’t Care Don’t Care CLLI Exists CVT Failure indication with CLLI
0x05*
Failure Don’t Care Don’t Care CLLI Does Not Exist
CVT Failure indication with no CLLI
0x04
Failure Don’t Care Don’t Care CLLI Not Supported
CVT Failure indication with no CLLI
0x04
Local Circuit Translation Unavailable 0x07
Received CVR Not Processed – Pass Through to Host 0x08**
CVR Not Received After Maximum CVT Retry 0x06
* Data passed in Raw SS7 Data Parameters ICB (0x22)
** Data passed in SS7 Unformatted Raw Parameters ICB (0x1F)
PPL Events
The PPL events are sent to the host in the PPL Event Indication message. Event data, if any, is sent in an ICB. The ICB subtype and data for those events that include data are shown below. Events 1, 4, 6, and 7 do not include data.
0x02 CVT Successful - CIN Mismatch
ICB Subtype: SS7 Raw Data Parameters (0x22)
Data[0–25] - Local CIN
Data[26–51] - Remote CIN
0x03 CVT Successful - CGC Data Inconsistent
ICB Subtype: SS7 Raw Data Parameters (0x22)
Data[0] - Remote CGC Parameter
Data[1–26] - Local CIN
0x05 CVT Failure - CLLI Received
ICB Subtype: SS7 Raw Data Parameters (0x22)
Developer Information
905
Data[0–10] - Remote CLLI
0x08 CVR Received - CVR in TLV Format
ICB Subtype: Formatted SS7 Parameters (0x12)
Data [0] - Message Type [CVR]
Data [1] - Number of Parameters
Data [2] - CVR Indicator Parameters Code
Data [3] - CVR Indicator Length
Data [4] - CVR Indicator Value
Data [5] - CGC Parameters Code
Data [6] - CGC Parameters Length
Data [7] - CGC Parameters Value
Data [8-n] - Optional Parameters [TLV]
User Part Unavailable Message Handling
A CVT may also be initiated when a User Part Unavailable (UPU) indication is received from the far-end. This is configurable with PPL Configuration Byte 14 of the L3P CIC component.
When a UPU message with an appropriate cause value is received from the far end, a CVT message is sent and timer T37 (typically 30 s) is started. On receipt of a CVR or any other ISUP message, the timer is stopped and normalcy is restored. On expiry of T37 without the receipt of any response from the remote end, the CVT procedure is restarted.
The CVR received from the far end will contain the mandatory Circuit Validation Response indicator and Circuit Group characteristic indicator parameters and may also contain other optional parameters (CLLI and CIN code). CLLI/CIN can be enabled/disabled as required and the CLLI/CIN code parameters are configurable.
On receiving a CVT, a CVR with an appropriate CVR indicator of Pass or Fail is sent, depending on the state of the CIC. The CVR contains the configured Circuit Group Characteristics (CGC) parameter and may also contain the optional CLLI if the test fails or CIN if the test passes. For undefined CICs, no optional parameters are sent.
On receipt of an MTP Status primitive with a cause of User part unavailability – Remote user inaccessible, depending on the configuration, the CVT may be generated automatically. On receipt of a CVR or any other ISUP message, the CVT/CVR procedures are stopped and a PPL Event Indication of 0x04 is sent from SPRC to the host.
Error Condition
MSP
906
When the CVT component sends a CVT message to SPRC it starts a TCVT timer. If a CVR is not received before the expiration of the timer, a second CVT is sent. If the timer expires a second time, the CVT attempt is cancelled and a PPL Event Indication (0x06 - CVR Receive Failed after Re-attempt) is sent to the host.
If a CVT procedure is started with Remote User Part Unavailable, the number of CVT re-attempts is determined by the value in Configuration Byte 8 of the CVS component. The default value is 8. The maximum value is 255.
Customization
Use the PPL Configuration Bytes (using the PPL Configure message) of the CVT and CVR components to modify CVT/CVR configuration. The CIN, CLLI, and circuit group characteristics configuration should be same for a given circuit for both the CVT and CVR components. See SS7 PPL Information (7-1) for the Configuration Byte values.
Circuit Validation Test Call Flows
CVT to Network/CVR Received from Far-end
CVT to Network/No CVR from Far-end
CVT to Network during Active Call
Developer Information
907
Remote User Part Unavailable
This call flow shows a CVT sent to the network as a result of a Remote User Part Unavailable indication received from the far-end.
MSP
908
Developer Information
909
Call Modification Messages
Overview
This section includes information about messages that involve requesting, rejecting, and completing call modifications.
CMR: Call Modification Request/Call Modification Reject
Message sent in either direction to indicate that the call modification request has been rejected.
CMC: Call Modification Complete
Message sent in either direction to indicate that the call modification request has been accepted
Call Flows
CMR from Host -- CMC from Network
MR from Host -- CMRJ from Network
MSP
910
CMR from Network
MR from Network -- In-Call Modification Disabled
CMR from Host -- Local In-Call Modification Disabled
Developer Information
911
MSP
912
SS7 CIC Blocking Procedures
Overview
When a CIC changes between the out of service (OOS) and in service (INS) states, the SS7 functionality automatically initiates either a Circuit Blocking/Unblocking or a Circuit Reset for the circuit (or a Group Blocking/Unblocking or Reset if multiple circuits in the same circuit group transition at the same time). The two procedures for changing states are shown below and are controlled by PPL configuration.
Whenever an OOS to INS or the OOS is caused by a non-host initiated request (for example, a purge, or remote ISUP unavailable indication) the SS7 functionality attempts to send a Circuit Reset (RSC) or a Group Circuit Reset (GRS) (if multiple circuits are in transition at the same time). Also, if the host configures the CIC to send reset upon host-initiated OOS to INS transition, the SS7 functionality attempts to send a RSC or GRS.
Important! The procedure for initial CIC In Service procedures is consistent with Type B operations as defined in ITU-TS Q.767 Section 4.4.1.
If the host configures the CIC to send blocking upon host initiated INS to OOS transition, the SS7 card attempts to send a Blocking (BLO) or Circuit Group Blocking (CGB) before taking the CIC out of service (this is the default).
When the host brings the CICs back into service, the SS7 functionality attempts to send an Unblocking (UBL) or Circuit Group Unblocking (CGU) before declaring the circuits as in-service.
For a CIC to start the OOS to INS process, the following three conditions must be met:
The span on which the CIC resides must be in proper span alignment.
MTP must consider the DPC as accessible.
The host must send a Service State Configure message of in-service for the CIC.
When all the conditions are met, the SS7 card attempts to bring the CICs in-service. Upon successful completion of the ISUP Unblocking or Reset procedure, the MSP 1010 notifies the host by sending a DS0 Status Change message for each CIC, declaring it in-service. You can now use the CICs for calls.
A CIC purge is considered a non host-initiated OOS to INS transition. Because of this, any purge of a CIC initiates an outgoing Circuit Reset.
If the host wants to initiate a Circuit Group Reset (GRS) or Circuit Reset (RSC) it may do so by setting the L3P CIC PPL configuration byte 10 to 0x01 and then cycling the CICs OOS first and next INS through the use of the Service State Configure message. The host-initiated OOS to INS transition forces an outgoing GRS or RSC. This action is taken to force a reset of the entire MSP 1010 call processing stack, not just the ISUP portion of it.
You can generate a Reset Circuit (RSC) by sending L3P PPL Event Request (0x0044) message with Component 0x000F, Event 0x09. You can also Generate Reset (GRS) with Component 0x000F, Event 0x09.
If a CIC is taken OOS from the host through the use of the Service State Configure message, the CIC is blocked if configured to do so and marked as Unequipped by
Developer Information
913
ISUP. Any messages from the DPC are treated as messages for an Unequipped Circuit.
If a CIC circuit group is in service and a span alarm is detected, a Circuit Group Blocking message is automatically sent (or Circuit Group Hardware Blocking for ITU) for the concerned circuit group. The host receives a DS0 Status Change message indicating that all of the channels in the circuit group are OOS.
If a call was active, the CIC purges with the reason Span Status Dead (0x03). Upon return of proper span framing, a Circuit Group Unblocking is automatically sent (or Circuit Group Hardware Unblocking for ITU) for the concerned circuit group. Upon successful unblocking of the circuit group, the host receives DS0 Status Change messages of INS.
Important! The circuits that purged because of span failure do not send Circuit Resets in this case because they are included in the Circuit Group Unblocking from the span alarm.
All CICs related to the DPC in question are taken OOS and no blocking messages are sent if the MTP declares one of the following:
DPC Inaccessible
Remote ISUP Unavailable
MTP Pause
In either case, a General alarm of SS7 Remote ISUP Unavailable (0x0F) is sent to the host.
Circuit Maintenance and Management Call Flows
Some messages in these call flows are numbered. The numbered messages are described in more detail beside the corresponding number following each call flow.
Incoming Maintenance Blocking
1. The MSP 1010 automatically sends the DPC the proper CGBA or BLA.
2. The MSP 1010 alerts the host when an incoming Maintenance Blocking Request is made by sending a PPL Event Indication message for every channel blocked by the DPC. The PPL Event Indication has an SS7 parameters ICB that contains the data of either the incoming CGB or BLO.
MSP
914
3. Upon receiving this message, the host should not send outgoing calls on this channel until the blocking is cleared by the DPC. The DPC may send an incoming call on the blocked channel, however. In this event, the host receives a PPL Event Indication of Maintenance Unblocking (without an SS7 parameters ICB) followed by a Request for Service message for the incoming call. The host must acknowledge the PPL Event Indication message.
4. The host must acknowledge the PPL Event Indication message.
Incoming Maintenance Unblocking
1. The MSP 1010 automatically sends the proper CGUA or UBL to the DPC.
2. The MSP 1010 alerts the host when an incoming Maintenance Unblocking Request with a PPL Event Indication message for every channel unblocked by the DPC. The PPL Event Indication has an SS7 parameters ICB containing the data of either the incoming CGU or UBL.
3. Upon receiving this message, the host can make the channel available for outgoing calls. There may be instances in which no SS7 Parameter ICB is included in the PPL Event Indication message.
4. The host must acknowledge the PPL Event Indication.
Incoming Hardware Failure Oriented Blocking (ITU only)
1. The MSP 1010 automatically sends the DPC the proper CGBA.
Developer Information
915
2. The MSP 1010 alerts the host when an incoming Hardware Failure Oriented Blocking Request with a PPL Event Indication message for every channel blocked by the DPC. The PPL Event Indication message includes an SS7 parameters ICB containing the data of the incoming CGB.
3. Upon receiving this message, the host should not send outgoing calls on these channels until the blocking is cleared by the DPC. The DPC may send an incoming call on the blocked channels, however, upon which, the host will receive a Maintenance Unblocking PPL Event Indication (without an SS7 parameters ICB) followed by a Request for Service message for the incoming call.
4. The host must acknowledge the PPL Event Indication message.
Incoming Hardware Failure Oriented Unblocking (ITU only)
1. The MSP 1010 automatically sends the DPC the proper CGUA.
2. The MSP 1010 alerts the host when an incoming Hardware Failure Oriented Unblocking Request is made with a PPL Event Indication message for every channel blocked by the DPC. The PPL Event Indication will include an SS7 parameters ICB containing the data of the incoming CGU.
3. Upon receiving this, the host can now make the channels available for outgoing calls. There may be instances in which no SS7 Parameter ICB is attached to the PPL Event Indication. See Incoming Hardware Failure Oriented Blocking (ITU only) (5-47).
4. The host must acknowledge the PPL Event Indication message.
Outgoing Maintenance Blocking Request
MSP
916
By default, the host cannot generate Hardware Failure Oriented Blocking with the PPL Event Request message. Hardware Failure Blocking is automatically generated in the event of a loss of signal on the span that carries the CIC. Unblocking is automatic when spans align.
1. The host sends a PPL Event Request message to request Local Maintenance Blocking for a CIC. The message can contain an SS7 parameter ICB with parameters for the outgoing BLO message.
2. The MSP 1010 will acknowledge the PPL Event Request.
3. Upon successful completion of the maintenance blocking procedure, the MSP 1010 alerts the host by sending a PPL Event Indication message. The PPL Event Indication will include an SS7 Parameters ICB containing parameters from the BLA. The host should not initiate any outgoing call without first sending a PPL Event Request message of Maintenance Unblock.
4. The host must ACK the PPL Event Indication.
Outgoing Maintenance Unblocking Request
1. The host sends a PPL Event Request message to request Local Maintenance Unblocking for a CIC. The event request can contain an SS7 Parameter ICB with parameters for the outgoing UBL message.
2. The MSP 1010 acknowledges the PPL Event Request.
Developer Information
917
3. Upon successful completion of the Maintenance Unblocking procedure, the MSP 1010 alerts the host by sending a PPL Event Indication message, which contains an SS7 Parameters ICB containing the parameters from the UBA. The host can now initiate outgoing calls.
4. The host must ACK the PPL Event Indication message.
Outgoing Maintenance Group Blocking Request
1. The host sends a PPL Event Request message to request Local Maintenance Group Blocking for a CIC circuit group. The event request can contain an SS7 Parameter ICB with parameters for the outgoing CGB message.
2. The MSP 1010 acknowledges the PPL Event Request message.
3. Upon successful completion of the Maintenance Group Blocking procedure, the MSP 1010 alerts the host by sending a PPL Event Indication message for each CIC. The PPL Event Indication contains an SS7 Parameters ICB, which contains the parameters from the CGBA. The host should not initiate any non-test outgoing call without first sending a Maintenance Unblock PPL Event Request message for the channel(s).
4. The host must ACK each PPL Event Indication message.
Important! By default, the host cannot generate hardware failure oriented blocking with the PPL Event Request message. Hardware Failure Oriented Blocking is automatically generated in the event of a loss of signal on the span that carries the CIC. Unblocking is automatic when the span aligns.
Outgoing Maintenance Group Unblocking Request
MSP
918
1. The host sends a PPL Event Request message to request Local Maintenance Group Unblocking for a CIC circuit group. The event request can contain an SS7 Parameter ICB with parameters for the outgoing CGU message.
2. The MSP 1010 acknowledges the PPL Event Request message.
3. Upon successful completion of the Maintenance Group Unblocking procedure, the MSP 1010 alerts the host by sending a PPL Event Indication message for each CIC. The PPL Event Indication contains an SS7 Parameters ICB containing the parameters from the CGU. The host can now initiate outgoing calls.
4. The host must ACK each PPL Event Indication message.
Local Circuit Maintenance Unblocking Indication
1. The MSP 1010 alerts the host when the Local Maintenance Blocking state is cleared. This is typically done when an ISUP component has requested that the CIC be reset (for example, receipt of Unreasonable Signaling to an idle ISUP CPC). The host now considers the channel as not Locally Maintenance Blocked. The host can re-establish blocking. See Outgoing Maintenance Blocking Request (5-49).
2. The host must ACK each PPL Event Indication message.
Developer Information
919
CRM/CRA (ANSI)
Definitions
The messages related to circuit reservation are defined in this section.
CRM
Circuit Reservation Message: This message is used to perform continuity procedures on an outgoing SS7 circuit before collecting address digits from the incoming MF circuit. On receiving a seize from the incoming MF agency, a CRM with the required NOC is sent to the succeeding exchange and the timer TCRM (typically 15 seconds) is started. Based on the NOC, a continuity check may or may not be performed.
CRA
Circuit Reservation Acknowledgment: On receipt of a CRA message, the timer TCRM is stopped and further processing continues. If TCRM expires before the receipt of CRA, the CRM is re-attempted on a different CIC. Circuit Reservation Timer
After sending a CRA in response to the CRM, a Timer TCRA (typically 15 seconds) is started by the terminating node while waiting for an IAM (or COT if a continuity check is to be performed). If neither of the messages is received and the timer expires, an REL message is sent from the terminating node with a cause value of Temporary Call Flows.
Call Flows
TCRM Timeout
MSP
920
TCRM Expiry
Dual Seizure during CRM Processing
Developer Information
921
MSP
922
MCP/PCP (ITU)
Overview
MCP and PCP messages provide support for unrecognized signaling as defined by ISUP 1992 (ITU-T White Book). This support becomes necessary, for example, if the exchange receives unrecognized signaling information from a later version of ISUP. With MCP/PCP, the exchange can take the appropriate action and ensure its compatibility with new signaling messages, no matter what version they may be.
MCP
Message Compatibility Procedure (MCP, Section 2.9.5, Q.764)
It may happen that an exchange receives an unrecognized message. The message compatibility procedures are invoked in this case to ensure predictable network behavior. Message compatibility information is received in the unrecognized message and following actions can be taken based on the compatibility information contained in the message.
Procedures include:
Send Notification to the exchange sending unrecognized message (Confusion).
Do not send notification.
Initiate release procedure.
Discard message.
Pass on unrecognized message transparently.
PCP
Parameter Compatibility Procedure
PCP defines a set of procedures executed when a message containing unrecognized optional parameters is received by the exchange. Parameter compatibility information is contained in the received message. Receipt of unrecognized parameters only refers to optional parameters and unexpected parameters for that particular message. Based on the instruction indicator contained in the parameter compatibility information for the unrecognized parameter, the following actions can be taken.
Send Notification to the exchange sending unrecognized parameter (Confusion).
Do not send notification.
Initiate release procedure.
Discard message.
Discard unrecognized parameter.
Pass on unrecognized parameters transparently.
Developer Information
923
Unrecognized Message Handling—for Message without MCP
Unrecognized Message Handling---for Message with MCP Discard Indicator
Unrecognized Message—with MCP Containing Release Indicator
Unrecognized Message—with MCP Containing Discard and Send Notification Indicator
Unrecognized Message--with MCP Containing Pass On Indicator
MSP
924
Message with Unrecognized Optional Parameters and no PCP
.
Message with Unrecognized Parameter—with PCP Containing Discard Message and Send Notification Indicator for that Parameter
Message with Unrecognized Parameter—with PCP Containing Release Call Indicator
Developer Information
925
Message with Unrecognized Optional Parameter—with PCP Containing Discard Parameter and Send Notification Indicator
Release with Unrecognized Parameter with PCP
Message with Unrecognized Parameter and PCP Having Pass On Indicator
MSP
926
MPM/CCL/OPR
Overview
This section includes information and call flows related to MPM/CCL/OPR. MPM, CCL and OPR messages are implemented as defined by CHINA ISUP specifications.
Definitions
MPM
Meter Pulse Message: A message is sent in the backward direction after Answer at equal intervals (usually every one minute).
CCL
Calling Party Clear Message: This message is sent in the forward direction when the calling party, which has called the special service node, wants to release the call.
OPR
Operator Message: This message is sent in the backward direction from the special service node if the calling party needs to be provided with a ring after hanging up.
Call Flows
MPM - Normal
Calling Party Clear—Normal Release Sequence
Developer Information
927
The normal release sequence for Calling Party Clear (ITU). The call flow starts with the call in the answered state:
Host 1 = Calling Party
Host 2 = Called Party
Calling Party Clear—Operator Callback—Subscriber Re-answers
Shows the normal release sequence for Calling Party Clear (ITU) with an operator callback. The call flow starts with the call in the answered state:
Host 1 = Calling Party
Host 2 = Called Party
MSP
928
Calling Party Clear—Operator Callback—Re-Answer Timeout
This call flow shows the normal release sequence for Calling Party Clear (ITU) with an operator callback and a re-answer timeout. The call flow starts with the call in the answered state:
Host 1 = Calling Party
Host 2 = Called Party
Developer Information
929
Suspend/Resume
Overview
This section includes information and call flows about the ISUP Suspend and Resume messages.
Definitions
Suspend
The Suspend (SUS) message indicates a temporary cessation of communication without releasing the call. SUS can only be accepted in an answered state (ICC answered/OGC answered).
Resume
A Resume (RES) message indicates a request to recommence communication. If the RES is not sent within timer T6 or T2 (T2 applies to ITU only), the controlling exchange will initiate a release procedure.
PPL Information
The SUS and RES messages are passed in the PPL Event Request and PPL Event Indication messages, with the following Event ID values:
L3P CIC (0x000F)
0x2D SUS
0x2E RES
For ANSI, only network-initiated SUS/RES are allowed. Only called party can send SUS. For ITU, both user and network-initiated SUS/RES are supported. Both calling and called party can initiate SUS.
Atomic function (104) in the ISUP CPC component checks for network- or user-initiated SUS/RES.
Host-Initiated
L3P CIC passes the SUS request from the host to CPC, upon which CPC enters the suspended state and waits for a RES request to recommence the communication. L3P CIC forwards the RES request from the host to CPC and CPC returns to the answered state. If the RES is not received within the resume wait timer, the call is released.
Network-Initiated
When an SUS is received from the network, CPC enters the suspended state and waits for a RES. When an RES is received from the network, CPC returns to the answered state. If the timer initiated at the controlling exchange expires before RES is received, REL is initiated.
MSP
930
PPL event indications include data in SS7 Raw ICB format. If the SUS/RES is not received with the valid indicator, a PPL Event Indication message indicating the error is sent to the host.
Customization
Use the PPL configuration bytes in the L3P CIC component to modify the handling of the SUS and RES messages.
SUS (ITU)
The table below shows the L3P CIC PPL Configuration Bytes used to configure the SUS message for ITU.
Byte Description Value
485 Information Length
0x05
486 Message ID 0x0D
487 Number Of Parameters
0x01
488 Parameter1 ID 0x22 (Suspend/Resume indicator)
489 Parameter Data Length
0x01
490 Parameter value 0x01 (Network Initiated)
SUS (ANSI)
The table below shows the L3P CIC PPL Configuration Bytes used to configure the SUS message for ANSI.
Byte Description Value
480 Information Length
0x05
481 Message ID 0x0D
482 Number Of Parameters
0x01
483 Parameter1 ID 0x22 (Suspend/Resume indicator)
484 Parameter Data Length
0x01
485 Parameter value 0x01 (Network Initiated)
Developer Information
931
RES (ITU)
The table below shows the L3P CIC PPL Configuration Bytes used to configure the RES message for ITU.
Byte Description Value
492 Information Length
0x05
493 Message ID 0x0E
494 Number Of Parameters
0x01
495 Parameter1 ID 0x22 (Suspend/Resume indicator)
496 Parameter Data Length
0x01
497 Parameter value 0x01 (Network Initiated)
RES (ANSI)
The table below shows the L3P CIC PPL Configuration Bytes used to configure the RES message for ANSI.
BYTE Description Value
490 Information Length
0x05
491 Message ID 0x0E
492 Number Of Parameters
0x01
493 Parameter1 ID 0x22 (Suspend/Resume indicator)
494 Parameter Data Length
0x01
495 Parameter value 0x01 (Network Initiated)
Suspend and Resume Call Flows
This section includes call flows showing the Suspend and Resume messages
Suspend Followed by Resume
Suspend Followed by Release
MSP
932
Developer Information
933
UPT/UPA (ITU)
Overview
This section defines UPT/UPA and includes call flows related to these messages.
Definitions
UPT
User Part Test Message: The User Part Test (UPT) message is used to test whether a user part is available on a signaling point, which has been marked inaccessible. The test procedure is initiated when the ISUP receives an MTP STATUS Primitive with cause – “user part unavailability – inaccessible remote user”. The ISDN User Part shall send a User Part Test message and start timer that supervises the receipt of a response to the user part test message. All MTP STATUS Primitives with cause – “user part unavailability – inaccessible remote user” are ignored when the timer T4 is running. The timer T4 is stopped when a User Part Available (UPA) or any other ISUP message is received.
UPA
User Part Available: When a User Part Test acknowledgment message is received by ISUP, the ISUP sends a User Part Available message in response to the message.
UPT and UPA messages are implemented for ITU/CHINA ISUP, with procedures as recommended by ITU ISUP (Q.764).
Call Flows
Normal Call Flow for UPT/UPA
MSP
934
Call Flow for UPA Timeout
UPT Procedure: Remote User Unavailable
The call flow shows the UPT procedure that is initiated when ‘MTP-UPU — Remote user unavailable’ is received.
UPT Procedure—No Response from Far End
This shows the UPT procedure that is initiated when ‘MTP-UPU – Remote user unavailable’ received, and there is no response from the far end.
Developer Information
935
MSP
936
SS7 Customization with ISUP Messages
Overview
You can customize the following to meet your application requirements:
ISUP Message Configuration
User-defined ISUP Messages
ISUP MTP Pause Logic Options
Request For Service Message Format
SS7 Parameter Presentation
PPL Configuration Bytes
Protocol Timers
Other Customization
ISUP Message Configuration
The ISUP Message Configuration Template is a table against which outgoing ISUP messages are formatted and incoming message parameters are extracted and verified. The default configurations for ANSI are described in the ANSI T1.113 specification, and the default configurations for ITU are described in ITU Q.767 specification.
The SS7 ISUP Message Format Configure message allows the host to customize the following ISUP message contents:
Message type
Priority
Number, order, and length of all parameters
You can also customize messages for ISUP variants. There is one ISUP Message Configuration Template for each protocol stack. All SS7 channels assigned to a stack are affected by modifications to the corresponding table. See the SS7 ISUP Message Format Configure message for an example, as well as generic sections on downloading and assigning modified PPL components and their relationship to stack configuration.
As shown in the figure below, the raw ISUP data from MTP is compared against the template to identify the ISUP message type and convert the raw data into the format of an SS7 Parameters ICB to send to L3P.
Incoming and outgoing messages that do not match the template, cause the host to be notified of a protocol violation and the MSP 1010 discards the message.
For outgoing calls, the parameter data is converted from an SS7 Parameters ICB format into the raw data format to go out to the network.
You can modify the defaults to include (or to exclude) optional parameters and customize messages for ISUP variants. Changing the format of a message affects the formatting of every incoming and outgoing instance of that message.
ISUP Message Configuration Template
Developer Information
937
User-defined ISUP Messages
SS7 allows the host to configure up to 32 user-defined ISUP messages per stack. The host can create PPLs to send and receive user-defined ISUP messages.
The L3P CIC and ISUP CPC components must be modified to create the Transport Event User-defined Messages. The Figure User-defined ISUP Message Mode illustrates the model for sending and receiving user-defined ISUP messages.
User-defined ISUP Message Mode
MSP
938
To facilitate the passing of user-defined ISUP messages, add events and atomic functions to ISUP CPC and L3P CIC. L3P CIC Atomic Function (AF) 99 allows L3P to send a user-defined ISUP message to ISUP. ISUP CPC AF 64 sends an incoming user-defined ISUP message to L3P. AF 65 sends an outgoing user-defined ISUP message to SPRC. For an example of L3P CIC customization.
Example Using User-defined ISUP Message Procedure
The following example shows how to use the User-defined ISUP message procedure.
1) Use the PPL Event Request / Indication messages to send or to receive User-defined Message (UDM).
For event values of UDMs, use any value larger than 30 (0x1E). For example, use the following to handle the receiving of INR /INF and the sending of INF/INR:
32(0x20) INR Indicator Event ID
33 INF Indicator Event ID
Then, they are used for L3PCIC Host-side Event Request ID:
INR (532)PPLevL5_EVENT_REQ_32
INF (533)PPLev:5_EVENT_REQ_33
Developer Information
939
For the L3PCIC network side:
INR (81) L3PCICevISUP_User_Defined_Msg1_IND
INF (82) L3PCICevISUP_User_Defined_Msg2_IND
For ISUP CPC, you do not need to assign an event ID. When you define the UDM in the ISUP Message Format Configuration template (MCT), the PPL automatically assigns the event ID. For example, you define:
INR User-defined message #1 0x2F(47) (ISUP MCT index)
INF User-defined message #2 0x30(48) (ISUP MCT index)
Then, the ISUP CPC creates:
Events (101)CPCevSPRC_USER_DEFINED_MSG1 —>INR
(102)CPCevSPRC_USER_DEFINED_MSG2 —>INF
(151)CPCevL3P_USER_DEFINED_MSG1_REQ —> Outgoing INR
(152)CPCevL3P_USER_DEFINED_MSG2 —- >Outgoing INF
2) Modify ISUP Message Configuration Table (MCT).
To modify the ISUP Message Configuration Table, create the message templates for the new messages according to the related specification. Use the SS7 ISUP Message Format Configure API message (0x6B) to assign the UDM number. For example:
INR —>2F(47)
INF —>30(48)
3) Modify the PPL State Machine.
To modify the PPL State Machine, decide which state to modify or add. Decide which state will receive or send the UDMs. For example, you will receive an INR after an IAM, which means the L3P CIC is in the Inseize state (State 2).
For L3P CIC - You can see the following DS0 file for example, but you have to pay attention to sending UMD and receiving UDM.
AF 76 adds prestored ISUP parameter entities into the L3P CIC configuration bytes. The following examples uses configuration bytes 150-152 and 160-162. If no parameters are prestored, use 0 as the number of parameters.
150 Information Length
0x02 (INR)
151 Message ID 0x03
152 Number of Parameters
0x00 (no per-stored)
160 Information Length
0x02 (INF)
161 Message Id 0x04
162 Number of Parameters
0x00 (no per-stored)
MSP
940
Next, fill the AF76(160) for INF message.
AF76(150) for INR in order to use these PPL configuration byte entities
AF71 Fill in the ISUP MSG Index, for example AF71(48), where 48 is the ISUP MSCT index 48(0x30) is the MCT.
For receiving UDM, the event IDs include the following:
(101)L3PCICevISUP_User_defined_MSG1_IND —->INR
(102)L3PCICevISUP_User_Defined_MSF2_IND —->INF
For CPC - For the EVENT ID and ISUP MCT index, refer to the DSD file.
4) Create PPL report file and download to the MSP 1010.
Use the PPL tool to create state table function to generate the PPL REP file. Then, use the tool REP2CFG.EXE to create the CFG files.
Finally, define the user protocol ID and download the report to the MSP 1010.
ISUP MTP Pause Logic Options
By default, ISUP processes MTP Pause Indications immediately. ISUP forces all CICs for the paused destination (DPC) out-of-service. Any active calls are listed as the CICs are brought out-of-service. The CICs remain out-of-service until the DPC receives an MTP Resume Indication.
The host can configure the ISUP to delay the processing of the MTP Pause Indication. The host can enable the MTP Pause Logic by setting PPL Configuration Byte 3 in ISUP SPRC. If this flag is set, an MTP Pause Indication is delayed for a period of time determined by an ISUP SPRC PPL Timer. The actual time before a Pause is processed is 10 times the timer value (so setting the timer for 5 seconds causes the Pause expiration in 50 seconds).
During the delay period, all outgoing messages for the DPC are queued in ISUP. If an MTP Resume Indication is received before the timer expiration, the queued messages are sent and the Pause is discarded. If the Pause Timer expires, the queued messages are discarded and the pause is processed as previously described.
Request For Service Message Format
The Called and Calling Party number can be passed to the host as BCD encoded digits, allowing an application to use a generic Feature Group D call model.
To enable the sending of BCD Encoded digits, the value in Byte 8 must be changed to “BCD Encoded Digits” (0x01) using the PPL Configure message. This invokes AF 78, which transfers address data to the ISUP Outgoing buffer as BCD encoded digits.
BYTE Description Value
8 Request For Service Format
0 = Raw ISUP (default)
1 = BCD digits
Developer Information
941
SS7 Parameter Presentation
For incoming calls, the default is to pass all parameters to the host in an SS7 Data ICB message. The host can configure the MSP 1010 to pass specific parameters, or no parameters, by modifying the L3P CIC state machine using the PPL Tool.
1. Upon reception of an ISUP Setup Indication, AF 96 stores the SS7 parameters into the ISUP Incoming Buffer.
2. AF 11 tests the L3P CIC Configuration Bytes to determine the Request For Service format (Raw ISUP or BCD Encoded Digits).
3. As the default format is Raw ISUP (0), AF 77 is invoked, which transfers all network ISUP parameters into the L4/L5 Outgoing buffer. (To change the Request For Service format to BCD-encoded digits, See Request For Service Message Format (5-80).
4. AF 69 sends a Q.931 Setup to L4, including all parameters in the buffer.
Specified Parameters
The host can configure L3P CIC to send specific parameters using AF 93, which transfers the parameter data in the incoming buffer to the L4/L5 Outgoing Buffer. Argument 1 indicates the Parameter ID. The function must be invoked for each parameter to be sent.
No Parameters
For the host to receive a Request For Service With Data with no SS7 parameters, L3P CIC should be modified. Upon reception of the ISUP Setup Indication, AF 69 sends a Q.931 Setup to L4. By removing AF 96, no parameters are stored or sent. Because no digits are to be sent, the test for the Request For Service format is removed.
MSP
942
Modifying the Format of an ISUP Message
Overview
You modify the format of an ISUP message using the SS7 ISUP Message Format Configure message. ISUP messages can be modified by removing or adding optional parameters that are supported in the applicable ANSI or ITU specification. You must include all of the mandatory parameters that are included in the format of an ISUP message.
To find the format of an ISUP message supported by Excel, use the SS7 ISUP Message Query message.
Finding Parameter IDs
Depending on the telecommunications standard being used, you find the IDs for optional parameters listed in the specifications issued by ITU or ANSI.
Example
The example script file below shows the SS7 ISUP Message Format Configure message being used to change the format of the RELEASE message. The Release message format includes 13 optional parameters:
User-to-User Information
Automatic Congestion Level
Parameter Capability Information
Access Delivery Information
Redirection Number
Remote Operations
Network Specific Facilities
Redirection Information
Access Transport
Signaling Point Code
User-to-User Indicators
Display Information
Redirection Number Restriction
Example Configuration Script File
This script file, sent by the host, configures the Release message format to include only four optional parameters. This example uses the optional parameter IDs in the ITU-T Q.763 specification.
00 20 00 6B 00 00 FF 00 01 08 01 00 04 0C 01 00 01 12 02 00 01 04 03 01 00 27 01 01 0C 03 0A 20 01 81
Example Message Format Table with Values
Developer Information
943
The table below interprets the information provided in the script file shown earlier in this section. The Release message has only one mandatory fixed parameter: Message ID. Because the ISUP Message Index and ISUP Message ID fields indicate this parameter ID, the parameter ID does not need to be repeated in the MFP 1: ID field.
Note:
Maximum Length of 0x00 means infinity.
Byte Field Description Value
0 Frame 0xFE
1 Length, MSB 0x00
2 Length, LSB 0x2C
3 Message Type, MSB 0x00
4 Message Type, LSB 0x6B
5 Reserved 0x00
6 Sequence Number 0x00
7 Logical Node ID 0xFF
8 Address Method 0x00
9 Number of Address Elements 0x01
10 Address Type 0x08 (SS7 Stack)
11 Data Length 0x01
12 Data[0] SS7 Stack ID 0x00
13 ISUP Message Index 0x04
14 ISUP Message ID 0x0C
15 ISUP Message Priority 0x01
16 Number of Mandatory Fixed Parameters (MFP)
0x00
17 Number of Mandatory Variable Parameters (MVP)
0x01
18 MVP 1: ID 0x12 (Cause Indicators)
19 MVP 1: Minimum Length 0x02
20 MVP 1: Maximum Length 0x00
21 Optional Parameters Allowed 0x01 (Yes)
22 Number of Optional Parameters 0x04
23 OP 1: ID 0x03 (Access Transport)
24 OP 1: Minimum Length 0x01
MSP
944
25 OP 1: Maximum Length 0x00
26 OP 2: ID 0x27 (Auto. Congestion Level)
27 OP 2: Minimum Length 0x01
28 OP 2: Maximum Length 0x01
29 OP 3: ID 0x0C (Redirection Number)
30 OP 3: Minimum Length 0x03
31 OP 3: Maximum Length 0x0A
32 OP 4: ID 0x20 (User to User Information)
33 OP 4: Minimum Length 0x01
34 OP 4: Maximum Length 0x81
35 Checksum 0x2A
Developer Information
945
Important ISUP PPL Information
Overview
This section highlights some of the more important ISUP PPL components information related to SS7 customization. Complete Configuration Byte values, and PPL timers and events are documented in the SS7 PPL Information in the API Reference.
Configuration Bytes
This section identifies important PPL Configuration Bytes for each component, and their default values.
ITU L3P CIC
The L3P CIC PPL Configuration Bytes configure the following:
Bytes 1-3 - CGB, CGU, GRS
Point to the byte locations of the Circuit Group Block (CGB), Circuit Group Unblock (CGU), and Circuit Group Reset (GRS) parameters, which are used when generating group messages. Other functions in the system access these parameters. You can move the location of the parameter values within the L3P CIC Configuration Bytes; however, you must update Bytes 1-3 to point to their location.
Bytes 4-7 - SS7 Parameter Information For Outgoing Calls
Required when the host sends BCD-encoded digits.
Byte 8 - Request For Service With Data message format
For incoming calls. Address information can be passed as SS7 parameter data or as BCD-encoded digits.
Byte 9
Determines if an incoming SS7 call requires a response with the ACM/ANM or CON messages.
Byte 10 - Host Out-of-service and In-service Operation Flag
This flag determines if a reset or block/unblock sequence is used for host initiated out-of-service and in-service transitions.
Bytes 15-145 - Values For SS7 Parameters In Outgoing Messages
These values are used unless the host overrides them in an SS7 Parameters ICB. Values are included for the following messages:
Message Value
ACM Address Complete Message
ANM Answer Message
MSP
946
BLO Blocking
CGB Circuit Group Blocking
CGU Circuit Group Unblocking
CON Connect Message
CPG Call Progress
GRS Circuit Group Reset
IAM Initial Address Message
REL Release
UBL Unblocking
ITU ISUP CPC
The ISUP CPC Configuration Bytes contain values for the Dual-seizure Control Flag and CPC-initiated REL parameters.
Byte 1 - Dual-seizure Control Flag
Upon detection of a dual-seizure condition (collision between incoming and outgoing IAMs); this flag determines which side is dropped.
Bytes 10–16, 25–31, and 40–46 - parameter values for CPC-initiated Releases, depending on the failure reason
Under certain circumstances, ISUP CPC must initiate a release to the network. For example, expiration of the T8 timer results in a forward REL with a Cause Value of “Temporary Failure” ITU ISUP SPRC.
ITU ISUP SPRC
Byte 1 - Range & Status Parameter ID
This ID is required for logic in ISUP, which identifies group messages and routes them to the correct group state machine based on the value of the range field.
Byte 2 - Byte Offset of the Range Field
The range field of the Range and Status parameter is assumed to be one octet. However, its placement in the Range and Status parameter is not assumed. This Configuration Byte entry contains the byte offset into the parameter for the range field (this is 0 for ITU). This is done, along with the Range and Status parameter name, in order to allow ISUP to be able to handle ISUP message and parameter variants.
Byte 3 - ITU Service Indicator
This field is placed in to every outgoing ISUP message as a field in the MSU Service Information Octet.
Developer Information
947
Byte 4 - ITU Subservice Field
This field is placed into every outgoing ISUP message as a field in the MSU Service Information Octet.
Byte 5 - MTP Pause Logic Flag
After an MTP Pause indication is received, the SPRC can either process the pause immediately, or it can delay the pause processing and queue any outgoing messages to MTP. If an MTP Resume indication is received before timer expiration, the queued messages are sent to MTP. If the timer expires, the queued messages are discarded and the pause is processed. (For a description of ISUP MTP Pause Logic, see ISUP MTP Pause Logic Options (5-80)
ANSI L3P CIC
Bytes 1 and 3 - CGB, CGU, and GRS
Point to the byte locations of the Circuit Group Block (CGB), Circuit Group Unblock (CGU), and Circuit Group Reset (GRS) parameters, which are used when generating group messages. These parameters are accessed by other functions in the system. The location of the parameter values can be moved within the L3P CIC Configuration Bytes, however, Bytes 1 and 3 must be updated to point to their location.
Bytes 4-7 - SS7 parameter information
Required for outgoing calls when the host sends BCD-encoded digits in an Outseize Control message.
Byte 8 - Request For Service With Data message format
For incoming calls. Address information can be passed as SS7 parameter data or as BCD-encoded digits.
Byte 10 - Host Out-of-service And In-service Operation Flag
This flag determines if a reset or block/unblock sequence is used for host initiated out-of-service and in-service transitions.
Bytes 15-137 - SS7 Parameter Values For Outgoing Messages
These values are used unless overridden by the host in an SS7 parameters ICB.
ANSI ISUP CPC
The ISUP CPC Configuration Bytes control the Dual-Seizure Control Flag and CPC-initiated REL parameters.
Byte 1 - Dual-Seizure Control Flag
Upon detection of a dual-seizure condition (collision between incoming and outgoing IAMs); this flag determines which side is dropped.
Bytes 10–16, 25–31, 40–46, and 51–61 - parameter values for CPC-initiated Releases, depending on the failure reason.
Under certain circumstances, ISUP CPC must initiate a release to the network. For example, expiration of the T8 timer results in a forward REL with a Cause Value of “Temporary Failure.”
MSP
948
ANSI ISUP SPRC
ISUP SPRC PPL Configuration Bytes control configuration flags, messages, and other important values, as follows:
Byte 1 - Range & Status Parameter ID
This ID is required for logic in ISUP which identifies group messages and routes them to the correct group state machine based on the value of the range field.
Byte 2 - Byte Offset of the Range Field.
The range field of the Range and Status parameter is assumed to be one octet. However, its placement in the Range and Status parameter is not assumed. This Configuration Byte entry contains the byte offset into the parameter for the range field (this is 0 for ANSI). This is done, along with the Range and Status parameter name, in order to allow ISUP to be able to handle ISUP message and parameter variants.
Byte 3 - ANSI Service Indicator
This field is placed in to every outgoing ISUP message as a field in the MSU Service Information Octet.
Byte 4 - ANSI Subservice Field
This field is placed into every outgoing ISUP message as a field in the MSU Service Information Octet.
Byte 5 - MTP Pause Logic Flag
Upon reception of an MTP Pause indication, the SPRC can either process the pause immediately, or it can delay the pause processing and queue any outgoing messages to MTP. If an MTP Resume indication is received before timer expiration, the queued messages are sent to MTP. If the timer expires, the queued messages are discarded ISUP MTP Pause Logic Options (5-80).
Bytes 6-26 - SPRC-initiated Confusion
CFN messages to the network in response to an unrecognized or corrupt message.
Bytes 30-32 - parameter values for an Unequipped CIC
UCIC message to the network in response to a network message that pertains to an unknown or out-of-service CIC.
L3P CIC PPL Configuration Bytes
The mapping of the PPL Configuration Bytes for the L3P CIC component allows you to move Configuration Bytes for a message without modifying the PPL protocol.
Existing atomic functions point to specific Configuration Bytes for the format information on a specific message. If this information was moved to a new Configuration Byte location, the DSD would have to be updated to reflect the new location of the Configuration Bytes.
There are three blocks of 200 Configuration Bytes each, for a total of 600 Configuration Bytes. Bytes 501–600 are used as the Configuration Byte Offset Table, which contains an index pointing to the location of the Configuration Bytes with the format information for each message.
Developer Information
949
Atomic Function 122 in the L3P CIC state machine points to the index in the Configuration Byte Offset Table, which indicates the location of the Configuration Bytes for a specific message. If you move the location of the Configuration Bytes for a message, you only need to update the Configuration Byte Offset Table, using the PPL Configure message, to reflect the new location.
The next figure shows the usage of the Configuration Byte Offset Table by the L3P CIC state machine to access Configuration Bytes for a specific message. See SS7 PPL Information for ITU and ANSI Configuration Byte offset values.
Protocol Timers
Each PPL component has multi-purpose timers, which you can activate at any time. Each component using timers has a table that contains information on specific timers (name, value). When a protocol requires a timer, an atomic function is initiated to activate one of the PPL timers and to point to an index in the components timer table, which contains the value for the required timer. See SS7 PPL Information (7-1) in this manual for default timer values.
Other Customization
The table below lists other common SS7 customization which is implemented through modification of PPL Configuration Bytes with the PPL Configure message.
To modify... Use...
Component Configuration Bytes
Host-initiated Out-of-Service Logic Flag
L3P CIC 10
Dual-seizure (Glare) Control Flag
ISUP CPC 1
Default Outgoing SS7 Parameters
L3P CIC All
Service Indicators ISUP SPRC 3
Subservice Field ISUP SPRC 4
Range and Status ISUP SPRC 1
MSP
950
Parameter ID
CFN Parameters- ANSI only
ISUP SPRC All
ISUP CPC Initiated Release Parameters
ISUP CPC All
ITU CON/ANM/ACM Control ITU
L3P CIC 9
Transmitted LSSU Status Field
MTP2 TXC All
Network Indicators MTP3 HMDT and
MTP3 HMRT
All
Developer Information
951
ISUP Signaling Information
Overview
This section includes definitions of ISUP messages.
Definitions
The following messages can be modified using the SS7 ISUP Message Format Configure API message. Some messages are marked with a number which indicates the following:
1 Specified for ANSI network
2 Specified for ITU network
3 ITU – for National use
Messages that are not marked with a number indicate use for an ANSI or ITU network.
Signaling Information
Definition
Access Delivery Indicator 2
Information sent in the backward direction indicating that a SETUP message was generated at the destination access.
Access Transport Information generated on the access side of a call and transferred transparently in either direction between the originating and terminating local exchanges. The information is of significance to both users and local exchanges.
Address Presentation Restricted Indicator
Information sent in either direction to indicate that the address information is not to be presented to a public network user, but can be passed to another public network.
Address Signal An element of information in a network address. The address signal may indicate digit values 0 to 9, code 11 or code 12. One address signal value is reserved to indicate end of pulsing of the called party number (ST) and is not used.
Alarm Carrier Indicator 1
Information sent in either direction indicating the type of carrier alarm handling.
Attendant Status 1 An indication sent within the business group parameter signifying whether or not the business group information pertains to an attendant line.
Automatic Congestion Level
Information optionally included in a Release Message and sent to the exchange at the other end of a circuit to indicate that a particular level of congestion exists at the
MSP
952
sending exchange.
Backward Call Indicators
Information sent in the backward direction consisting of the charge indicator, called party's status indicator, called party's category indicator, end-to-end method indicator, interworking indicator, end-to-end information indicator, ISDN User Part indicator, holding indicator, ISDN access indicator, echo control device indicator, and SCCP method indication.
Business Group 1 Information sent in either direction to indicate the identity of the Multi-Location Business Group associated with a number (e.g. the Calling Party Number), the identity of a Subgroup within that Multilocation Business Group and the Line Privileges allocated to the number.
Business Group Identifier 1
Sent within the business group parameter to indicate the identity of the corresponding Multi-location Business Group.
Business Group Identifier Type 1
Information sent within the business group parameter to indicate the type of business group identification used, e.g. multi-location business group identifier or interworking with private networks identifier.
Call Diversion Information 2
Information sent in the backward direction indicating the redirection reason and the notification subscription option of the redirecting user.
Call Diversion May Occur Indicator 2
Information sent in the backward direction indicating that call diversion may occur, depending on the response received (or lack thereof) from the called party.
Call History Information 2
Information sent in the backward direction to indicate the accumulated propagation delay of a connection.
Call Identity 3 Information sent in the call reference parameter indicating the identity of a call in a signaling point.
Call Reference 3 Circuit independent information identifying a particular call.
Called Party Number Information sent in the forward direction to identify the called party and consisting of the odd/even indicator, nature of address indicator, numbering plan indicator, and address signals.
Called Party’s Category Indicator
Information sent in the backward direction indicating the category of the called party, e.g. ordinary subscriber or pay phone.
Called Party’s Status Indicator
Information sent in the backward direction indicating the status of the called party, e.g. subscriber free.
Calling Party Address Request Indicator 2/3
Information sent in the backward direction indicating a request for the calling party address to be returned.
Developer Information
953
Calling Party Address Response Indicator 2/3
Information sent in response to a request for the calling party address, indicating whether the requested address is included, not included, not available or incomplete.
Calling Party Number Information sent in the forward direction to identify the calling party and consisting of the odd/even indictor, nature of address indicator, numbering plan indicator, address presentation restriction indicator, screening indicator, and address signals.
Calling Party Number Incomplete Indicator 2/3
Information sent in the forward direction indicating that the complete calling party number is not included.
Calling Party’s Category
Information sent in the forward direction indicating the category of the calling party, e.g. ordinary subscriber, test call.
Calling Party’s Category Request Indicator 2/3
Information sent in the backward direction indicating a request for the calling party’s category to be returned.
Calling Party’s Category Response Indicator 2/3
Information sent in response to a request for the calling party’s category, indicating whether or not the requested information is included in the response.
Carrier Identification Code 1
Information sent in the forward direction to the transit network indicating the transit network selected by the originating subscriber.
Carrier Selection Information 1
Sent in the forward direction to indicate whether the calling user selected the transit network by pre-subscription or dialed input and if pre-subscribed whether or not the carrier identification code was also dialed.
Cause Indicators 1 Information sent in either direction consisting of the coding standard, location, cause value and diagnostics. It indicates the reason for sending the message in which it is contained, e.g. the Release, Address complete or Confusion messages, and identifies the network in which the message originated, e.g. local network, transit network, remote local network.
Cause Value 2 Information sent in either direction consisting of the coding standard, location, cause value and diagnostics. It indicates the reason for sending the message in which it is contained, e.g. the Release, Address complete or Confusion messages, and identifies the network in which the message originated, e.g. local network, transit network, remote local network.
Charge Indicator Information sent in the backward direction indicating whether or not the call is chargeable.
Charge Information Information sent in either direction requesting charge
MSP
954
Request Indicator 2/3 information to be returned.
Charge Information Response Indicator 2/3
Information sent in response to a request for charge information indicating whether or not the requested information is included.
Charge Number 1 Information sent in either direction indicating the chargeable number for the call and consisting of the odd/even indicator, nature of address indicator, numbering plan indicator, and address signals.
Circuit Assignment Map
Information identifying the map format and the circuits in a multi-rate connection. For the DS 1 map format it identifies the DS0 circuits constituting a NxDS0 connection. The circuit assignment map is used only for NxDS0 calls when non-contiguous time slot allocation is used.
Circuit Group Blocking Type Indicator 1
Information sent in a Circuit Group Blocking (Unblocking) (Acknowledgment) Message indicating the blocking procedure used.
Circuit Group Carrier Indicator 1
Information sent in either direction indicating if the circuit group carrier is analog, digital, or analog and digital.
Circuit Group Characteristics Indicator 1
Information sent in response to a request for circuit validation, indicating the characteristics of the concerned circuit group in terms of carrier type, double seizing control, alarm handling and continuity check requirements.
Circuit Group Supervision Message Type Indicator
Information sent in either direction in a circuit group supervision message and consisting of the circuit group blocking type indicator.
Circuit Identification Code
Information identifying the physical path between a pair of exchanges.
Circuit Identification Name 1
Information identifying the exchanges on which a circuit group terminates and the number of each trunk within that group.
Circuit State Indicator 3
Information indicating the state of a circuit according to the sending exchange.
Circuit Validation Response Indicator
Information indicating the far-end results of a circuit validation test.
Closed User Group Call Indicator 2
Information indicating whether or not the concerned call can be set up as a closed user group call and, if a closed user group call, whether or not outgoing access is allowed.
Closed User Group Interlock Code 2
Information uniquely identifying a closed user group within a network.
Coding Standard Information sent in association with a parameter (e.g.
Developer Information
955
cause indicators) identifying the standard in which the parameter format is defined.
Common Language Location Identification (CLLI) 1
Information used for circuit validation to identify a switching office by town, state, and building subdivision. (COMMON LANGUAGE is a registered trademark and CLLI is a trademark of Bell Communications Research, Inc.)
Component Type 2/3 There are four types of components that may be present in the Remote Operations parameter. The four Protocol Data Units (PDU) defined in Recommendation X.229 are used. (Invoke, Return Result, Return Error, Reject).
Connected Line Identity Request Indicator 2
Information sent in the forward direction indicating a request for the connected party number to be returned.
Connected Number 2 Information sent in the backward direction to identify the connected party.
Connection Request Information sent in the forward direction on behalf of the Signaling Connection Control Part requesting the establishment of an end-to-end connection and consisting of the local reference, point code, protocol class, and credit.
Continuity Check Indicator
Information sent in the forward direction indicating whether or not a continuity check will be performed on the circuit(s) concerned or is being (has been) performed on a previous circuit in the connection.
Continuity Check Requirement Indicator 1
Information sent in either direction indicating if and how often a continuity check is required for the circuit group.
Continuity Indicator Information sent in the forward direction indicating whether or not the continuity check on the outgoing circuit was successful. A continuity check successful indication also implies continuity of the preceding circuits and successful verification of the path across the exchange with the specified degree of reliability.
Credit Information sent in a connection request, indicating the window size requested by the signaling connection control part for an end-to-end connection.
Diagnostic Information sent in association with a cause value and which provides supplementary information about the reason for sending the message.
Discard Message Indicator 2
Information sent to inform another node to discard the related message, due to compatibility reasons.
Discard Parameter Indicator 2
Information sent to inform another node to discard the related parameter, due to compatibility reasons.
Double Seizing Information sent in either direction indicating the type of
MSP
956
Control Indicator 1 double seizing control applied to the circuit group.
Echo Control Device Indicator
Information sent in the forward direction indicating whether or not an outgoing half echo control device is included in the connection.
Egress Service 1 Information sent in the forward direction by the first incoming exchange in the terminating exchange area, to indicate network specific attributes associated with the terminating exchange, e.g. the interexchange carrier, the point of interconnection, and type of terminating access service.
Encoding Scheme 2 Information sent to indicate the coding type for the digit information, e.g. BCD-coded.
End of Optional Parameters 2
The end of optional parameters field indicates that there are no more optional parameters in the message.
End-to-End Information Indicator
Information sent in either direction indicating whether or not the sending exchange has further call information available for end-to-end transmission.
End-to-End Method Indicator
Information sent in either direction indicating the available methods, if any, for end-to-end transfer of information.
Error Code 2/3 The error code element contains the reason why an operation cannot be completed successfully. It is present only in a Return Error component. As with operations, errors may be local or global. These errors and associated parameters are defined in relevant supplementary service specifications.
Event Indicator Information sent in either direction to indicate the type of event that caused a Call Progress message to be sent. Event Information. Information sent in either direction consisting of the event indicator and event presentation restricted indicator that should be relayed to the access. Event Presentation Restricted Indicator. Information sent in either direction to indicate that the occurrence of the concerned event should not be reported to the user.
Event Information 1 Information sent in either direction consisting of the event indicator and event presentation restriction indicator.
Event Presentation Restricted Indication 3
Information sent in either direction to indicate that the occurrence of the concerned event should not be reported to the user.
Extension Indicator Information indicating whether or not the associated octet has been extended.
Facility Indicator 2 Information sent in facility related messages identifying the facility or facilities with which the message is concerned.
Developer Information
957
Feature Code 2/3 Information sent in either direction to invoke, accept, or reject a specific action for a supplementary service.
Feature Code Indicator 1
Information sent in either direction to invoke a specific feature operation at the terminating or originating MSP 1010.
Filler 2 A number of bits used to complete a partially used octet to full octet length.
Forward Call Indicators
Information sent in the forward direction consisting of the incoming international call indicator, end-to-end method indicator, interworking indicator, end-to-end information indicator, ISDN User Part indicator, ISDN User Part preference indicator, ISDN access indicator, and SCCP method indicator.
Generic Address 1 Information in the form of an address pertaining to a supplementary service (e.g., dialed number, destination number) and including type of address, nature of address and numbering plan indications.
Generic Digits 3 Information in the form of digits pertaining to a supplementary service, (e.g. account code, authorization code, private network class mark) and including type of digits and encoding method indicators.
Generic Name Information sent in the forward direction containing specific name-related information.
Generic Notification 2 Information sent in either direction intended to provide supplementary service notification to a user.
Generic Number 2 A number information sent in either direction to enhance network operation or for supplementary services.
Generic Reference (reserved) 2
For further study.
Hold Provided Indicator 2/3
Information sent in the forward direction indicating that the connection will be held after the calling or called party has attempted release.
Holding Indicator 2/3 Information sent in the backward direction indicating that holding of the connection is requested.
Hop Counter (ITU reserved for further study)
Information sent in the forward direction to minimize the impact of lAM looping. The initial count determines the maximum number of contiguous SS7 interexchange circuits that are allowed to complete the call, assuming all subsequent intermediate exchanges decrement the hop counter.
In-band Information Indicator
Information sent in the backward direction to indicate that in-band information, e.g. a tone or announcement, is present on the circuit path.
Incoming Half Echo Information sent to request the activation or
MSP
958
Control Device Request Indicator 2
deactivation of an incoming half echo control device.
Incoming Half Echo Control Device Response Indicator 2
Information sent to inform whether an incoming half echo control device has been included or not.
Incoming International Call Indicator 1
Information sent in the forward direction indicating whether the call is an incoming international or an incoming national call.
Information Indicators
Information sent in either direction consisting of the calling party address response indicator, connected address response indicator, calling party's category response indicator, charge information response indicator, and solicited information indicator.
Information Request Indicators
Information sent in either direction consisting of the calling party address request indicator, connected address request indicator, calling party's category request indicator, charge information request indicator, malicious call identification request indicator, and holding indicator.
Information Transfer Capability 1
Information sent in the forward direction indicating the type of transmission medium required for the connection.
Information Transfer Rate 1
Information sent in the forward direction indicating the information transfer rate
Instruction Indicator 2
Information indicating the reactions to be taken if an unrecognized message or unrecognized parameter is received.
Internal Network Number 2
Information sent to the destination exchange for specific numbers, e.g. roaming numbers indicating whether or not the network generates the number contained in the parameter.
Interworking Indicator
Information sent in either direction indicating whether or not Signaling System No. 7 is used in all parts of the network connection.
Invoke Identification 2/3
An Invoke ID is used as a reference number to identify uniquely an operation invocation. It is present in the invoke component and in any reply to the invoke enabling the reply to be correlated with the Invoke.
ISDN Access Indicator
Information sent in either direction indicating whether or not the access signaling protocol is ISDN.
ISDN User Part Indicator
Information sent in either direction to indicate that the ISDN User Part is used in all parts of the network connection.
ISDN User Part Information sent in the forward direction indicating whether or not the ISDN User Part is required or
Developer Information
959
Preference Indicator preferred in all parts of the network connection. Jurisdiction Information sent in the forward direction indicating the geographic origination of the call.
Jurisdiction Information 1
Information sent in the forward direction indicating the geographic origination of the call.
Length of Network Identification 2/3)
Information sent in the network specific facility parameter, to indicate the length in octets of the network identification.
Length of Reference Indicator 2 (for further study)
Information sent in the generic reference parameter, to indicate the length in octets of the reference.
Line Privileges 1 Information sent within the business group parameter to indicate the privileges of the user identified by the corresponding number,
Line Privileges Information Indicator 1
Information sent within the business group parameter signifying whether the indicated line privileges are standard or customer defined.
Linked Identification 2/3
A linked ID is included in an Invoke component by a node when it responds to an operation invocation with a linked operation invocation. The node receiving the linked ID uses it for correlation purposes in the same way that it uses the invoke ID in a Return Result, Return Error, or Reject.
Local Reference Information sent in the connection request, indicating the local reference allocated by the signaling connection control part to an end-to-end connection.
Location 2 Information sent in either direction indicating where an event was generated.
Location Number 2 Information sent to indicate the location of a user in the term of an E.164 number.
Look Ahead For Busy 1
Information sent within the precedence parameter indicating whether the look-ahead for busy option is allowed or whether the path has been reserved.
Look For Busy (LFB) 2
Information sent in the forward direction to indicate whether LFB option is allowed or if the path for the call is reserved.
Malicious Call Identification Response Indicator 2/3
Information sent in the forward direction indicating whether the malicious call identification has been provided or not.
MCID Request Indicator 2
Information sent in the backward direction to request the identity of the calling party for the purpose of malicious call identification.
MCID Response Information sent in the forward direction to respond to a
MSP
960
Indicator 2 MCID request and indicating whether or not the MCID information is available.
Message Compatibility Information Parameter 2
Information sent in either direction indicating how an exchange should react in case this message is unrecognized.
MLPP Service Domain Information sent in the precedence parameter identifying the network resources to which the Multi-level Precedence and Preemption supplementary service is applicable for the call.
MLPP User Indicator 2 Information sent in the backward direction to indicate that the called user is an MLPP user.
National/International Call Indicator 2
Information sent in the forward direction indicating in the destination national network whether the call has to be treated as an international call or as a national call.
Nature of Address Indicator
Information sent in association with an address indicating the nature of that address, e.g. ISDN international number, ISDN national significant number, or ISDN subscriber number.
Nature of Connection Indicators 1
Information sent in the forward direction consisting of the satellite indicator, continuity check indicator, and echo control device indicator.
Network Discard Indicator 2
This indicator indicates that the network has discarded user-to-user information included in the call control message.
Network Identification 1
Information sent in the forward direction indicating the identity of the transit network.
Network Identification 2/3
Information sent to identify a network.
Network Identification Plan 1
Information sent in association with the transit network selection information to identify the type of network identification used.
Network Transport A parameter sent in either direction for the purpose of transporting other ISDN User Part parameters transparently across transit exchanges.
Network Identification Plan 2/3
Information sent to indicate the identification plan for identifying the network, e.g. X.121 or E.212, (DNIC or MNIC).
Network Identity 2/3 Information sent to identify the network that administrates the supplementary service.
Network Specific Facilities 2/3
Service related information transparently transferred in either direction between the local exchange and the identified network, which contracts the service. The information is significant to both user and the identified
Developer Information
961
network.
Network Transport A Parameter sent in either direction for the purpose of transporting other ISDN User Part parameters transparently across transit exchanges.
Notification Indicator 1
Information Sent in either direction intended to provide supplementary service related notification to a user.
Notification Subscription Option 2
Information sent in the backward direction indicating that the diversion with or without redirection number can be presented to the calling user.
Number Incomplete Indicator 2
Information sent in the generic number parameter to indicate whether the delivered number is complete or incomplete.
Numbering Plan Indicator
Information sent in association with an address indicating the numbering plan used for that address (e.g., ISDN numbering plan).
Odd/Even Indicator Information sent in association with an address, indicating whether the number of address signals contained in the address is even or odd.
Operation Code 2/3 The operation code element indicates the precise operation to be invoked, and is present in an Invoke component type. It is also present in the Return Result component if the result contains parameters. The operation may be a local or global operation. A local operation can be used in one ASE only. The same global operation can be used in several different ASEs. The actual operation codes, the definition of the operations and their associated parameters, are defined in relevant supplementary service specifications.
Operator Services Information 1 Information sent in the forward direction between operator services entities primarily identifying charging and service type options.
Optional Backward Call Indicator 1
Information sent in the backward direction consisting of the in-band information indicator, the call forwarding may occur indicator and the user-network interaction indicator.
Original Called Number
Information sent in the forward direction to indicate, in the case of call redirection (e.g., call forwarding), the number of the user who initiated the initial redirection.
Original Redirecting Reason 1
Information sent in the forward direction indicating the forwarding condition for the original redirection.
Original Redirection Reason 2
Information sent in either direction indicating the reason why the call was originally redirected.
Originating Line Information 1
Information sent in the forward direction, indicating a toll class of service for the call.
MSP
962
Origination ISC Point Code 2
Information sent in the initial address message of an international call, indicating the point code of the originating ISC.
Outgoing Half Echo Control Device Request Indicator 2
Information sent to request the activation or deactivation of an outgoing half echo control device.
Outgoing Half Echo Control Device Response Indicator 2
Information sent to inform whether an outgoing half echo control device has been included or not.
Outgoing Trunk Group Number 1
Information sent in the backward direction indicating the trunk group selected at an outgoing gateway. For intra-network use only.
Parameter Compatibility Information 2
Information sent in either direction indicating how an exchange should react in case the parameter is unrecognized.
Party Selector 1 Information sent within a business group parameter to indicate the type of number to which the business group information applies.
Pass On Not Possible indicator 2
Information sent to inform another node on what action to take if “pass on” was requested due to compatibility reason but “pass on” was not possible due to interworking with pre-ISUP 1992 signaling.
Point Code Information sent in the call reference parameter indicating the code of the signaling point in which the call identity allocated to the call reference is relevant.
Precedence 1 Information sent in the forward direction in association with the invocation of the Multi-Level Precedence and Preemption (MIYP) supplementary service, consisting of the look-ahead for busy indication, the precedence level, network identity, and the MI2P service domain.
Precedence Level 1 Information sent in the precedence parameter indicating the precedence level of the call.
Precedence Level 2 Information sent in the forward direction to indicate the priority of the call.
Problem Code 2 The problem code element contains the reason for the rejection of a component and one such element is present in a Reject component. Four problem code elements are defined (General Problem, Invoke Problem, Return Result Problem, and Return Error Problem.)
Propagation Delay Counter 2
Information sent in the forward direction to indicate the propagation delay of a connection. This information is accumulated while the parameter is transferred through the network. The propagation delay information is represented by a counter counting in integer multiples of 1 ms.
Developer Information
963
Protocol Class Information sent in the connection request parameter indicating the protocol class requested by the signaling connection control part for the end-to-end connection
Protocol Control Indicator 1
Information consisting of the end-to-end method indicator, the interworking indicator, the end-to-end information indicator and the ISDN User Part indicator. The protocol control indicator is contained in both the forward and backward call indicators parameter fields and describes the signaling capabilities within the network connection.
Protocol Control Indicator 2
Information consisting of the end-to-end method indicator, the interworking indicator, the SCCP Method indicator and the ISDN User Part indicator. The protocol control indicator is contained in both the forward and backward call indicators parameter fields and describes the signaling capabilities within the network connection.
Protocol Profile 2/3 Information sent in either direction to indicate the protocol used in the Remote Operations parameter.
Range Information sent in a circuit group supervision message (e.g. Circuit Group Blocking) to indicate the range of circuits affected by the action in the message.
Range and Status 1 Information sent in either direction in circuit group supervision messages consisting of the range and status.
Redirecting Indicator 2
Information sent in either direction indicating whether the call has been diverted or rerouted and whether or not presentation of redirection information to the calling party is restricted.
Redirecting Number Information sent in the forward direction indicating the number from which the call was last redirected and consisting of the nature of address indicator, numbering plan indicator, address presentation restriction indicator, and address information (signals).
Redirecting Reason Information sent in the forward direction indicating the forwarding condition for the last redirection.
Redirection Counter Information sent in the forward direction indicating the number of forwardings undergone.
Redirection Indicator 2
Information sent to indicate whether the call has undergone diversion or rerouting. It also contains information about presentation restrictions.
Redirection Information
Information sent in the forward direction consisting of the original redirecting reason redirection counter and redirecting reason.
Redirection Number 2 Information sent in the backward direction indicating the number towards which the call must be rerouted or has
MSP
964
been forwarded.
Redirection Number Restriction Indicator 2
Information sent in the backward direction indicating whether the diverted-to user allows the presentation of his number.
Redirection Reason 2 Information sent in the call diversion information parameter and the redirection information parameter to indicate the reason for the redirection.
Reference nth Octet 2 (for further study)
Information sent in the generic reference parameter, expressing the reference number of the context given by the entity, which handles and provides the service.
Reference Qualifier Indicator 2 (for further study)
Information sent in the generic reference parameter, identifying the context that handles and provides service.
Release Call Indicator 2
Information sent to inform another node to release the call or not, by compatibility reasons, if the related message or parameter is unrecognized.
Remote Operations 3 The remote operations parameter is used to indicate the invocation of a supplementary service identified by an operation value and also carry the result or error indications depending on the outcome of the operation.
Routing Label Information provided to the message transfer part for the purpose of message routing.
Satellite Indicator Information sent in the forward direction indicating the number of satellite circuits in the connection.
SCCP Method Indicator
Information sent in the forward direction indicating the available SCCP methods, if any, for end-to-end transfer of information.
Screening Indicator Information sent in association with a number indicating whether the number was network or user provided, and if user provided, whether the network views the number as correctly identifying the user.
Send Notification Indicator 2
Information sent to inform another node to send notification, due to compatibility reason, if the related message or parameter is unrecognized.
Sequence 2/3 The sequence is an ordered set.
Service Activation 1 Information sent in either direction to indicate the invocation of one or more supplementary services.
Service Activation Parameter 2/3
Information sent in either direction to indicate the invocation, acceptance or rejection of supplementary services, when no service associated parameter is to be sent.
Service Code Information sent in the forward direction indicating a service code provided by the calling party.
Developer Information
965
Set 2/3 The Set element is used to contain a set of information elements accompanying a component. It is required in the case of more than one information element being included in a component. The information elements themselves are defined in relevant supplementary service specifications.
Signaling Point Code 2/3
Information sent in a release message to identify the signaling point in which the call failed.
Simple Segmentation Indicator 2
Information sent in either direction to indicate that additional information will be forwarded in an information message (unsolicited).
Solicited Information Indicator
Information sent in an information message to indicate whether or not the message is a response to an information request message
Special Processing Request 1
Information sent in the forward direction from a private network access node to service node in the public switched network to indicate that the call requires special processing at that node e.g. private network number translation or verification of authorization codes.
Status Information sent in a circuit group supervision message (e.g. Circuit Group Blocking) to indicate the specific circuits, within the range of circuits stated in the message, that are affected by the action specified in the message.
Sub-Group Identifier 1
Information sent within a business group parameter to indicate the identity of the subgroup of which the user identified by the corresponding number is a member.
Suspend/Resume Indicator
Information sent in the Suspend and Resume Messages to indicate whether suspend/resume was initiated by an ISDN subscriber or by the network.
Suspend/Resume Indicators 1
Information sent in either direction consisting of the suspend/resume indicator
Temporary Trunk Blocking After Release 2/3
Information sent to the exchange at the other end of a circuit (trunk) to indicate low level of congestion at the sending exchange and that the circuit (trunk) should not be re-occupied by the receiving exchange for a short period of time after release.
Transaction Request 1
Information sent in the Initial Address Message (lAM) to help continue call processing, using Transaction Capabilities (TC), associated with a given call during an assist or hand-off procedure.
Transfer Mode 1 Information sent in the forward direction indicating circuit or packet transfer mode.
Transit at Intermediate
Information sent to inform a transit node (Type B), whether it shall react on the rest of the instruction
MSP
966
Exchange Indicator 2 indicators or not, if the related message or parameter is unrecognized.
Transit Network Selection 3
Information sent in the forward direction indicating the transit network(s) requested for the routing of the call and consisting of the type of network identification, network identification plan, and network identification.
Transmission Medium Requirement 2
Information sent in the forward direction indicating the type of transmission medium required for the connection (e.g. 64Kbps unrestricted speech).
Transmission Medium Requirement Prime 2
Information sent in the forward direction indicating the fallback connection type in case of fallback.
Transmission Medium Used
Information sent in the backward direction indicating the resulting fallback connection type used for a call after the fallback has occurred.
Trunk Number 1 Information used for circuit validation to identify the trunk number of the Common Language circuit identification.
Type Indicator 2 Information sent to indicate the initiator for a circuit group supervision message, e.g., maintenance-oriented or hardware failure-oriented.
Type of Address 1 Information that specifies the type of address digits contained in a Generic Address parameter.
Type of Digits 3 Information that specifies the type of digits contained in a Generic Digits parameter.
Type of Network Identification 1
Information sent in the forward direction indicating the format of the transit network identification.
Type of Network Identification 2/3
Information sent to inform whether the identification of a network is by CCITT (ITU) standardization identification or by national network identification.
User Service Information
Information sent in the forward direction indicating the bearer capability requested by the calling party and including as a minimum, the coding standard and information transfer capability, transfer mode, and information transfer rate.
User Service Information Prime
Information sent in the forward direction indicating the preferred bearer capability requested by the calling party.
User Teleservice Information 2
Information sent in the initial address message indicating the Higher Layer Compatibility information requested by the calling party.
User-Network Interaction Indicator 1
Information sent in the backward direction to indicate that the sending exchange is collecting additional information from the calling party before routing the call further.
Developer Information
967
User-to-User Indicators
Information sent in association with the response to a request for user-to-user signaling supplementary service(s).
User-to-User Information
Information generated by a user and transferred transparently through the intermediate exchanges between the originating and terminating local exchanges.
MSP
968
ISUP Signaling Messages
Message Code
ID Description Purpose
ACM 0x06 Address Complete Message
Sent in the backward direction indicating that all required data has been received and the call set-up is progressing
ANM 0x09 Answer Message Sent in the backward direction to indicate that the called party has answered the call, may be used to trigger billing and call
BLA 0x15 Blocking Acknowledgment
Sent as a response to a BLO message indicating the identified circuit has
BLO 1 0x13 Blocking Sent for maintenance purposes to the exchange at the other end of the circuit to cause an engaged condition of that circuit (receive only)
CCL Calling Party Clear
CCR 0x11 Continuity Check Request
Sent to request a non-call-related continuity check on the identified circuit
CFN 0x2F Confusion Sent in response to any message (other than a confusion message) to indicate that all or part of a received message was unrecognized
CGB 0x18 Circuit Group Blocking
Sent for maintenance purposes to the exchange at the far end of a group of circuits to cause the engaged condition of those circuits
CGBA 0x1A Circuit Group Blocking Acknowledgment
Sent as a response to a CGB indicating that the identified group of circuits has been blocked to outgoing traffic
CGU 0x19 Circuit Group Unblocking
Sent to cancel the engaged condition of a group of circuits caused by a previously sent CGB message.
CGUA 0x1B Circuit Group Unblocking
Sent in response to a CGU indicating the identified group of
Developer Information
969
Acknowledgment circuits are now in the idle state
CMC 3 0x1D Call Modification Complete
Message sent in either direction to indicate that the call modification request has been accepted
CMR3 0x1C Call Modification Request
Message sent in either direction to request a change in the call characteristics
CMRJ 3 0x1E Call Modification Reject
Message sent in either direction to indicate that the call modification request has been rejected
CON 2 0x0F Connect Sent in the backward direction indicating that all the address signals required for routing the call to the called party have been received and that the call has been answered
COT 0x05 Continuity Sent in the forward direction to indicate the result of the completed continuity test
CPG 0x2C Call Progress Sent in either direction indicating that an event of significance to the originating or terminating access has occurred
CQM 3 0x2A Circuit Query Message
Sent on a routine or demand basis to request the exchange at the other end of a group of circuits give the state of the circuits within the specified range
CQR 3 0x2B Circuit Query Response
Sent in response to a CQM indicating the state of the previously identified group of circuits.
CRA 1 0xE9 Circuit Reservation Acknowledgment
Sent in the backward direction in response to a CRM indicating that the circuit has been reserved for an incoming call
CRG 2 0x31 Charge Information
Information sent in either direction for accounting and/or call charging purposes. national use only
CRM 1 0xEA Circuit Reservation
Message Sent in the forward direction only when interworking with exchange access MF signaling to reserve a circuit and
MSP
970
initiate any required continuity check
CVR 1 0xEB Circuit Validation Response Sent in response to a CVT to convey translation information for the indicated circuit
CVT 1 0xEC Circuit Validation Test
Sent on a routine or demand basis to request translation information for the identified circuit
DRS 2/3 0x27 Delayed Release Sent in either direction to indicate that the called or calling party has disconnected while the network is still holding the connection
En-block calls
Address digits are transmitted in one or more blocks.
In this form of signaling, address digits are transmitted in one or more blocks, and each block contains enough address information to enable the MSP 1010 to carry out forward routing.
EXM 1 0xED Exit Message Sent in the backward direction from an outgoing gateway exchange to indicate that the call has successfully progressed to the adjacent network
FAA 2 0x20 Facility Accept Sent in response to a facility request message indicating that the requested facility has been invoked
FAC 3 0x33 Facility Message Sent in either direction at any phase of a call to request an action at another exchange. Also used to carry the results, error or rejection of a previously requested action
FAR 2 0x1F Facility Request Sent from one exchange to another to request activation of a facility
FOT 0x08 Forward Transfer
Sent in the forward direction on semi-automatic calls when the operator wants the help of an operator at a distant exchange
FRJ 2 0x21 Facility Reject Sent in response to a facility request message indicating that the facility request has been rejected
Developer Information
971
GRA 0x29 Circuit Group Reset Acknowledgment
Sent in response to a GRS message to indicate the group of circuits have been realigned
GRS 0x17 Circuit Group Reset
Sent to align the state of a group of circuits, release any calls in progress remove any remotely blocked state.
IAM 0x01 Initial Address Message
Sent in the forward direction to initiate seizure of an outgoing circuit.
May also request continuity test on identified circuit
IDR 2 0x36 Identification Request
Sent in either direction to request an action regarding the malicious call identification supplementary service
IDS 2 0x37 Identification Response
Sent in response to the identification request message
INF 3 0x04 Information Sent to convey additional call-related information which may have been requested in the inr message
INR 3 0x03 Information Request
Sent by an exchange to request additional call related information
IRS Identification
LPA 3 Loopback Acknowledge
MCP Message Compatibility Procedure
MPM Meter Pulse Message
NRM 2 Network Resource Management
Sent in order to modify network resources associated with a certain call, sent along an established path in any direction in any phase of a call
OLM 2/3 Overload Message
Sent in the backward direction, on non-priority calls in response to an iam, to invoke temporary trunk blocking of the circuit concerned when the exchange generating the message is subject to load control
MSP
972
OPR Operator
PAM 3 0x28 Pass Along Message Sent in either direction to transfer information between two signaling points along the same signaling path as that used to establish a physical connection.
PCP Parameter Compatibility procedure
PDC Propagation Delay Counter
REL 0x0C Release Sent in either direction indicating that the circuit identified in the message is being released and the cause for the release
RES 0x0E Resume Sent in the backward direction to indicate re-answer from an interworking node or that a non-ISDN called party has gone off hook
RLC 0x10 Release Complete
Sent in either direction as a response to a release message or a reset circuit message to indicate that the circuit has been brought into the idle state
RSC 0x12 Reset Circuit Sent when an exchange does not know the state of a particular circuit and wants to release any call in progress, remove any remotely blocked state and align states
SAM 2 0x02 Subsequent Address Message
Sent in the forward direction to convey an additional segment of an overlength message after the IAM and before the ACM.
SGM 2 0x38 Segmentation Message
Sent in either direction to convey an additional segment of an overlength message
SUS 0x0D Suspend Sent in the backward direction to indicate clear back from an interworking exchange or a non-ISDN called party has gone on hook
TTB Temporary
Developer Information
973
Trunk Blocking
UBA 0x16 Unblocking Acknowledgment
Sent in response to a UBL indicating the identified circuit is now in the idle state
UBL 0x14 Unblocking Sent to cancel the engaged condition of a circuit caused by a previously sent BLO message
UCIC 3 0x2E Unequipped CIC Sent from one exchange to another when it receives a message that contains an unequipped circuit identification code
UPA 2 0x35 User Part Available
Sent in either direction as a response to a user part test message, to indicate that the user part is available
UPT 2 0x34 User Part Test Sent in either direction to test the status of a user part marked as independent of call control messages
USR 2 0x2D User-Defined Used for transport of user-to-user signaling independent of call control messages
1 Messages supported in ANSI only
2 Messages supported in ITU only
3 ITU - National use
MSP
974
Message Parameters
Overview
The ISUP parameters in this section are used in the SS7 ISUP Message Format Configure API message.
Definitions
The table below indicates the IDs and descriptions for ISUP parameters. Some parameters are marked with a number indicating the telecommunications standard supported by a parameter:
1ANSI
2ITU
The parameters that are not marked by a number are supported in both ANSI and ITU standards.
Parameter Name
ID Description
Access Delivery Information 2
0x2E Information sent in the backward direction indicating that a SETUP message was generated at the destination access.
Access Transport 0x03 Information generated on the access side of a call and transferred transparently in either direction between the originating and terminating local exchanges. The information is of significance to both users and local exchanges.
Automatic Congestion Level
0x27 Information optionally included in a Release Message and sent to the exchange at the other end of a circuit to indicate that a particular level of congestion exists at the sending exchange.
Backward Call Indicator (BCI)
0x11 Information sent in the backward direction consisting of the charge indicator, called party's status indicator, called party's category indicator, end-to-end method indicator, interworking indicator, end-to-end information indicator, ISDN User Part indicator, holding indicator, ISDN access indicator, echo control device indicator, and SCCP method indication.
Business Group 1
0xC6 Information sent in either direction to indicate the identity of the Multi-Location Business Group associated with a number (e.g. the Calling Party Number), the identity of a Subgroup within that Multilocation Business Group and the Line Privileges allocated to the number.
Call Diversion Information 2
0x36 Information sent in the backward direction indicating the redirection reason and the notification
Developer Information
975
subscription option of the redirecting user.
Call History Information 2
0x2D Information sent in the backward direction to indicate the accumulated propagation delay of a connection.
Call Reference 0x45 Circuit independent information identifying a particular call.
Called Party Number (CDPN)
0x04 Information sent in the forward direction to identify the called party and consisting of the odd/even indicator, nature of address indicator, numbering plan indicator, and address signals.
Calling Party Number (CGPN)
0x0A Information sent in the forward direction to identify the calling party and consisting of the odd/even indictor, nature of address indicator, numbering plan indicator, address presentation restriction indicator, screening indicator, and address signals.
Calling Party's Category (CPC)
0x09 Information sent in the forward direction indicating the category of the calling party, e.g. ordinary subscriber, test call.
Cause Indicators 0x12 Information sent in either direction consisting of the coding standard, location, cause value and diagnostics. It indicates the reason for sending the message in which it is contained, e.g. the Release, Address complete or Confusion messages, and identifies the network in which the message originated, e.g. local network, transit network, remote local network.
Charge Number 1
0xEB Information sent in either direction indicating the chargeable number for the call and consisting of the odd/even indicator, nature of address indicator, numbering plan indicator, and address signals.
Circuit Assignment Map 1
0x25 Information identifying the map format and the circuits in a multi-rate connection. For the DS 1 map format it identifies the DS0 circuits constituting a NxDS0 connection. The circuit assignment map is used only for NxDS0 calls when non-contiguous time slot allocation is used.
Circuit Group Characteristics Indicator 1
0xE5 Information sent in response to a request for circuit validation, indicating the characteristics of the concerned circuit group in terms of carrier type, double seizing control, alarm handling and continuity check requirements.
Circuit Group Message Supervision Message Type Indicator
0x15 Information sent in either direction in a circuit group supervision message and consisting of the circuit group blocking type indicator.
MSP
976
Circuit Identification Name 1
0xE8 Information identifying the exchanges on which a circuit group terminates and the number of each trunk within that group.
Circuit State Indicator
0x26 Information indicating the state of a circuit according to the sending exchange.
Circuit Validation Response Indicator
0xE6 Information indicating the far-end results of a circuit validation test.
Closed User Group Interlock Code 2
0x1A Information uniquely identifying a closed user group within a network.
Common Language Location Information Code (CLLI) 1
0xE9 Information used for circuit validation to identify a switching office by town, state, and building subdivision. (COMMON LANGUAGE is a registered trademark and CLLI is a trademark of Bell Communications Research, Inc.)
Connected Number 2
0x21 Information sent in the backward direction to identify the connected party.
Connection Request
0x0D Information sent in the forward direction on behalf of the Signaling Connection Control Part requesting the establishment of an end-to-end connection and consisting of the local reference, point code, protocol class, and credit.
Continuity Indicators
0x10 Information sent in the forward direction indicating whether or not the continuity check on the outgoing circuit was successful. A continuity check successful indication also implies continuity of the preceding circuits and successful verification of the path across the exchange with the specified degree of reliability.
Echo Control Information 2
0x37 Information sent in the forward direction indicating whether or not an outgoing half echo control device is included in the connection.
Egress 1 0xC3 Information sent in the forward direction by the first incoming exchange in the terminating exchange area, to indicate network specific attributes associated with the terminating exchange, e.g. the interexchange carrier, the point of interconnection, and type of terminating access service.
End of Optional Parameters
0x00 The end of optional parameters field indicates that there are no more optional parameters in the message.
Event Information
0x24 Information sent in either direction consisting of the event indicator and event presentation restriction indicator.
Facility 0x18 Information sent in facility related messages
Developer Information
977
Indicators 2 identifying the facility or facilities with which the message is concerned.
Forward Call Indicator
0x07 Information sent in the forward direction consisting of the incoming international call indicator, end-to-end method indicator, interworking indicator, end-to-end information indicator, ISDN User Part indicator, ISDN User Part preference indicator, ISDN access indicator, and SCCP method indicator.
Freephone Indicators 2
0x41 No description available.
Generic Address 1
0xC0 Information in the form of an address pertaining to a supplementary service (e.g., dialed number, destination number) and including type of address, nature of address and numbering plan indications.
Generic Digits 1 0xC1 Information in the form of digits pertaining to a supplementary service, (e.g. account code, authorization code, private network class mark) and including type of digits and encoding method indicators.
Generic Name 1 0xC7 Information sent in the forward direction containing specific name related information.
Generic Notification 2
0x2C Information sent in either direction intended to provide supplementary service notification to a user.
Generic Number 2
0xC0 A number information sent in either direction to enhance network operation or for supplementary services.
Generic Reference 2
(reserved) For further study.
Hop Counter (ITU – reserved)
0x3D Information sent in the forward direction to minimize the impact of lAM looping. The initial count determines the maximum number of contiguous SS7 interexchange circuits that are allowed to complete the call, assuming all subsequent intermediate exchanges decrement the hop counter.
Information Indicators
0x0F Information sent in either direction consisting of the calling party address response indicator, connected address response indicator, calling party's category response indicator, charge information response indicator, and solicited information indicator.
Information Request Indicators
0x0E Information sent in either direction consisting of the calling party address request indicator, connected address request indicator, calling party's category request indicator, charge information request indicator, malicious call identification request indicator, and holding indicator.
MSP
978
Jurisdiction 1 0xC4 Information sent in the forward direction indicating the geographic origination of the call.
Location Number 2
0x3F Information sent to indicate the location of a user in the term of an E.164 number.
MCID Request Indicator 2
0x3B Information sent in the backward direction to request the identity of the calling party for the purpose of malicious call identification.
MCID Response Indicator 2
0x3C Information sent in the forward direction to respond to a MCID request and indicating whether or not the MCID information is available.
Message Compatibility Information 2
0x38 Information sent in either direction indicating how an exchange should react in case this message is unrecognized.
MLPP Precedence 2
0x3A Information sent in the precedence parameter identifying the network resources to which the Multi-level Precedence and Preemption supplementary service is applicable for the call.
Nature of Connection Indicator
0x06 Information sent in the forward direction consisting of the satellite indicator, continuity check indicator, and echo control device indicator.
Network Specific Facilities 2
0x2F Service related information transparently transferred in either direction between the local exchange and the identified network, which contracts the service. The information is significant to both user and the identified network.
Network Transport 1
0xEF A Parameter sent in either direction for the purpose of transporting other ISDN User Part parameters transparently across transit exchanges.
Notification Indicator 1
0xE1 Information Sent in either direction intended to provide supplementary service related notification to a user.
Operator Services Information 1
0xC2 Information sent in the forward direction between operator services entities primarily identifying charging and service type options.
Optional Backward Call Indicators
0x29 Information sent in the backward direction consisting of the in-band information indicator, the call forwarding may occur indicator and the user-network interaction indicator.
Optional Forward Call Indicators 2
0x08 Information sent in the forward direction consisting of CUG, segmentation, and connected line identity request information.
Original Called Number
0x28 Information sent in the forward direction to indicate, in the case of call redirection (e.g., call forwarding), the number of the user who initiated the initial
Developer Information
979
redirection.
Originating Line Information (OLI) 1
0xEA Information sent in the forward direction, indicating a toll class of service for the call.
Origination ISC Point Code 2
0x2B Information sent in the initial address message of an international call, indicating the point code of the originating ISC.
Outgoing Trunk Group Number (OTGN)
Information sent in the backward direction indicating the trunk group selected at an outgoing gateway. For intra-network use only.
Parameter Compatibility Information 2
0x39 Information sent in either direction indicating how an exchange should react in case the parameter is unrecognized.
Precedence 1 0x3A Information sent in the forward direction in association with the invocation of the Multi-Level Precedence and Preemption (MIYP) supplementary service, consisting of the look-ahead for busy indication, the precedence level, network identity, and the MI2P service domain.
Propagation Delay Counter 2
0x31 Information sent in the forward direction to indicate the propagation delay of a connection. This information is accumulated while the parameter is transferred through the network. The propagation delay information is represented by a counter counting in integer multiples of 1 ms.
Range and Status (R&S)
0x16 Information sent in either direction in circuit group supervision messages consisting of the range and status.
Redirecting Number
0x0B Information sent in the forward direction indicating the number from which the call was last redirected and consisting of the nature of address indicator, numbering plan indicator, address presentation restriction indicator, and address information (signals).
Redirection Information
0x13 Information sent in the forward direction consisting of the original redirecting reason redirection counter and redirecting reason.
Redirection Number 2
0x0C Information sent in the backward direction indicating the number towards which the call must be rerouted or has been forwarded.
Redirection Number Restriction 2
0x40 Information sent in the backward direction indicating whether the diverted-to user allows the presentation of his number.
Remote Operations
0x32 The remote operations parameter is used to indicate the invocation of a supplementary service identified
MSP
980
by an operation value and also carry the result or error indications depending on the outcome of the operation.
Service Activation
0x33 Information sent in either direction to indicate the invocation, acceptance or rejection of supplementary services, when no service associated parameter is to be sent.
Signaling Point Code 2
0x1E Information sent in a release message to identify the signaling point in which the call failed.
Special Processing Request 1
0xE5 Information sent in the forward direction from a private network access node to service node in the public switched network to indicate that the call requires special processing at that node e.g. private network number translation or verification of authorization codes.
Subsequent Number 2
0x05 Information sent which includes E/O indicator, address signals and filler.
Suspend/Resume Indicators
0x22 Information sent in either direction consisting of the suspend/resume indicator
Transaction Request 1
0xE3 Information sent in the Initial Address Message (lAM) to help continue call processing, using Transaction Capabilities (TC), associated with a given call during an assist or hand-off procedure.
Transit Network Selection (TNS)
0x23 Information sent in the forward direction indicating the transit network(s) requested for the routing of the call and consisting of the type of network identification, network identification plan, and network identification.
Transmission Medium Requirement 2
0x02 Information sent in the forward direction indicating the type of transmission medium required for the connection (e.g. 64Kbps unrestricted speech).
Transmission Medium Requirement Prime 2
0x3E Information sent in the forward direction indicating the fallback connection type in case of fallback.
Transmission Medium Used
0x35 Information sent in the backward direction indicating the resulting fallback connection type used for a call after the fallback has occurred.
User Service Information (USI)
0x75 Information sent in the forward direction indicating the bearer capability requested by the calling party and including as a minimum the coding standard, information transfer capability, transfer mode, and information transfer rate.
User Service Information
0x30 Information sent in the forward direction indicating the preferred bearer capability requested by the
Developer Information
981
Prime calling party.
User Teleservice Information 2
0x34 Information sent in the initial address message indicating the Higher Layer Compatibility information requested by the calling party.
User-to-User Indicators
0x2A Information sent in association with the response to a request for user-to-user signaling supplementary service(s).
User-to-User Information
0x20 Information generated by a user and transferred transparently through the intermediate exchanges between the originating and terminating local exchanges.
MSP
982
Overlap Call Digit Collection
Overview
Overlap Call Digit Collection provides the capability for overlap calls to collect digits from multiple messages before forwarding them to the host, a capability normally reserved for En-bloc calls.
This feature supports the collection of digits received in a Subsequent Address Messages (SAM) and the inclusion of those digits in a single Request for Service (RFS) message sent to the host. Using this method, the RFS with Address Data is not sent to the host until the SETUP Initial Address Message (IAM) and all the SAMs have been received. Thus, the host is able to process an overlap call as though it were actually En-bloc.
The existing default method of digit collection, by contrast, sends an RFS with Address Digits and a partial Called Party number, followed by SAMs, which are represented as PPL Event Indications. The host has to wait for the additional digits to be processed before continuing its call setup.
This ITU-T variant provides the following expanded functionality:
The call setup process is made more efficient.
The number of API messages that must be exchanged between the switch and the host to set up a call are considerably reduced, which improves flow where there are large volumes of traffic.
This ISUP enhancement is backward compatible with previous versions of ISUP.
See the call flows on the following pages for descriptions of existing and new digit collection and for inter-digit timer events.
Configuration
The following configuration applies to the PPL information found in SS7 PPL Information (7-1):
The host configures the maximum number of digits the switch must receive before it sends the RFS message to the host.
The host uses a configuration byte to enable or disable this feature.
The host configures the PPL Timer.
Call Flows
Successful Handling of SAM in the Existing Implementation
Developer Information
983
1. A SETUP request is received with an insufficient number of digits.
2. The host sends a PPL Request to L3P CIC to enable the SAM Timer (T33) and wait for SAM.
3. When SAM is received, the SAM Timer (T33) is stopped and a SAM PPL Event Indication is sent to the host.
Expiry of SAM Timer in the Existing Implementation
1. A SETUP request is received with an insufficient number of digits.
2. The host sends a PPL Request to L3P CIC to enable the SAM Timer (T33) and wait for SAM.
3. If SAM is not received and the SAM Timer (T33) expires, a Call Failure PPL Event Indication is sent to L3P CIC, which then sends a Clear message to the host.
Successful Handling of SAM in the New Implementation
MSP
984
This call flow shows how the collection of digits is handled in SAM after the new functionality has been added.
1. A SETUP request is received with an insufficient number of digits for successful call translation.
2. The InterDigit Timer (T5) is started to wait for a SAM message.
3. If a SAM message is received before the expiry of the InterDigit Timer (T5), the timer is stopped. The digits collected are checked for the presence of the “End of dialing/digits” signal [i.e., the Signal Terminator (ST) default, set to 0x0F] which indicates that no more digits need to be received.
4. If the ST signal is not present in the digits of the SAM message received, or if the maximum number of digits is not received, the InterDigit Timer (T5) is started again.
5. Only on receipt of a SAM message containing the ST signal, an RFS containing the complete set of digits is sent to the host.
Important! While the SAM digit collection is occurring, if the host attempts to seize the circuit to make an outgoing call, the message will be NACKed.
Expiry of SAM Timer in the New Implementation
Developer Information
985
1. A SETUP request is received with an insufficient number of digits for successful call translation.
2. The InterDigit Timer (T5) is started to wait for a SAM message.
3. If a SAM message is received before the expiry of the InterDigit Timer (T5), the timer is stopped. The digits collected are checked for the presence of the ST signal, which indicates that no more digits need to be received.
4. If the ST signal is not present in the digits of the SAM message received, the InterDigit Timer (T5) is started again.
5. But if repeated SAMs do not contain the ST signal, or the number of digits received does not equal the maximum number of digits, the InterDigit Timer (T5) expires and an RFS is sent to the host containing the number of digits received in the IAM and SAM messages.
MSP
986
Automatic Congestion Control
Overview
Automatic Congestion Control (ACC) allows the MSP 1010 to handle the following:
local overloads
remote overloads
Local overload is the condition where the local SS7 stack on the MSP is overloaded. All incoming calls from the network and all Outseize Control requests from Layer 4 are throttled (rejected) and the MSP 1010 comes back to a load level to process steady call traffic.
Remote overload is the condition where a remote node is overloaded or there is a network congestion to the remote node. All Outseize Control requests from Layer 4 get throttled which brings that node to a lower load level.
In either case, for Outseize Control requests, Layer 4 receives an Access Denied Reason of 0x51 when the SS7 is overloaded locally or there is a remote overload at the destination of the call. Layer 4 releases the incoming side with the cause code of Congestion with ACL2.
Configuration
PPL Components
You use the following PPL Components to implement this feature:
ACC 0xA8 - Configuration Bytes and PPL Timers
SPRC 0x13 - Configuration Bytes and PPL Timers
In most cases, the parameter’s default value is appropriate but depending on the network, you might have to change some parameters.
Acceptance Rate and Automatic Congestion Level Values
The Automatic Congestion Level (ACL) values define the two overload levels that you can assign to a destination. For example you would assign a destination to have ACL Level 1 or ACL Level 2 overload.
The Acceptance Rate defines how many calls per second each ACL can handle before the calls are throttled.
You include the Acceptance Rate TLV (0x4E24) in the PPL Event Request (0x0044) API message to change the Acceptance Rate for each destination for either ACL levels. The Acceptance Rate is the number of call per second associated with the ACL.
Alarms
Developer Information
987
Refer to the Alarm (0x00B9) API message for information on four general alarms associated with this feature:
SS7 Signaling Network Congestion (0x0E)
ISDN/SS7 Signaling Stack Congestion (0x16)
Signaling Destination Congestion (0x3A)
Signaling Link Congestion (0x3B)
MSP
988
ISUP Remote Control
Overview
The ISDN User Part (ISUP) Remote Control feature provides the software architecture and configuration necessary for the host to provision all remote MSP 1010 nodes.
ISUP is the protocol used to support the signaling necessary to provide voice and non-voice services in telephone communications. It is an extension of SS7, used as the interface protocol for voice and data within, and for ingression or egression to/from the Public Switched Telephone Network (PSTN).
For example, when the MSP node server is provisioned, the host provisions the remote MSP nodes that communicate with it. This allows multiple MSPs to act as a logical switch in order to share resource information. An MSP, for example, with the SS7 component configured, can assign Circuit Identification Codes (CICs) to any span/channel of a remote MSP.
The actual voice channels or CICs, being controlled by the signaling links, must originate and terminate on the same remote node within the domain controlled by the host via the Server Node in the MSP.
Providing SS7 signaling within an MSP system essentially means that a local or remote SS7 stack can control voice circuits located within any node. This is accomplished by providing Ethernet connectivity between the host and remote MSPs in order to support messaging between L4 and the TDM to provide bearer traffic.
An MSP system with an SS7 stack is viewed by the network as a single Origination Point Code (OPC). The OPC is the address of the SS7 stack (network).
Host to Multi-Node Configuration
The following diagram illustrates a host controlled multi-node MSP system. Located in the Server Node, the SS7 stack is capable of controlling local as well as remote voice circuits. The SS7 signaling links terminate in the Server Node and the actual voice circuits can terminate within any node. The Ethernet connectivity enables the SS7 stack to layer L4 on remote nodes where the CICs reside.
Developer Information
989
Configuring the SS7 Stack
Purpose
This section describes the procedure for bringing the SS7 stack into service. It assumes that all hardware configuration and cabling is complete, that all nodes are powered up, and that a host-to-node communication link has been established.
This developer’s guide also provides detailed setup procedures for downloading system software, for establishing socket connections and for configuring nodes.
Before you begin
To ensure that the SS7 stack is operational before beginning the configuration procedure, do the following:
1. Modify the application, as required, to support SS7 control of CICs in multiple nodes that have a single Originating Point Code (OPC) in the Server Node.
2. Move the SS7 signaling links to the Server Node. Change the configuration as required.
MSP
990
3. When you configure the SS7 stack, perform the steps below, and use these steps as a guideline to your initial configuration.
Configuration Procedure
To configure the SS7 stack using ClientView, refer to Remote User, or follow the procedure below.
1. Assign the logical node IDs to MSPs.
Send the NGA Configure message (0x0130), Local Node Configure.
2. Download software licenses.
Send the NGA Configure message (0x0130), License Configure.
3. Provision remote node database.
Send the NGA Configure message (0x0130), Remote Node Configure.
4. Assign logical spans throughout the MSP.
Send the Assign Logical Span ID message (0x00A8) to assign spans to physical span offsets.
5. Configure the spans and channels corresponding to SS7 signaling links for clear channel.
Send either the E1 Span Configure message (0x00D8) or the T1 Span Configure message (0x00A9), depending on the protocol you use, to establish clear channel signaling.
6. Configure the SS7 Signaling Stacks with a stack ID, an Originating Point Code (OPC), and the variant to be used.
Send the SS7 Signaling Stack Configure message (0x005C) to assign the stack ID, OPC, and variant.
7. Configure the signaling link sets with a signaling link set ID to a given adjacent point code.
Send the SS7 Signaling Link Set Configure message (0x005D) to configure the link sets.
8. Configure the signaling links with the logical span/channel.
Send the SS7 Signaling Link Configure message (0x005E) to configure the links. The timeslot is provided off the local bus.
9. Configure the signaling routes and specify the relationship between a remote Destination Point Code (DPC) and the signaling links capable of reaching DPC.
Send the SS7 Signaling Route Configure message (0x005F) to configure the routes.
10. Assign the voice circuits and associate a set of span/channels with a set of Circuit Identification Codes (CICs) for a particular stack ID.
Send the SS7 CIC Configure message (0x006A) to configure CICs.
Based on the logical span ID, the node that owns the logical span is informed that the stack ID controlling the voice circuits is the stack assigned to control the CICs in the message.
Developer Information
991
11. Send Service State Configure for each of the following:
To bring: the spans into service.
To bring the SS7 links into service.
To bring the channels (CICs) into service.
Communication between SS7 stack and MSP Call Control components
The remote nodes sense that the stack is controlling their local voice channels by the SS7 Signaling Stack Configure message.
With this information, MSP Call Control can communicate with the stack controlling the voice channels, and the SS7 stack can communicate with any remote MSP Call Control components, based on the fact that every node knows the global span assignments, which determine local and remote connections. To make connections all nodes must have information about the spans on all other nodes. Since each span is given a unique ID, and all call connections occur via the combined information of channel and span IDs, global span assignment information is essential to every node.
MSP
992
Configuring ISUP Remote Control When Configuring SS7
Purpose
This section describes the procedure for bringing the SS7 stack into service including ISUP Remote Control. It assumes that all hardware configuration and cabling is complete, that all nodes are powered up, and that a host-to-node communication link has been established.
This developer’s guide also provides detailed setup procedures for downloading system software, for establishing socket connections and for configuring nodes.
Before you begin
To ensure that the SS7 stack is operational before beginning the configuration procedure, do the following:
1. Modify the application, as required, to support SS7 control of CICs in multiple nodes that have a single Originating Point Code (OPC) in the Server Node.
2. Move the SS7 signaling links to the Server Node. Change the configuration as required.
3. When you configure the SS7 stack, perform the steps below, and use these steps as a guideline to your initial configuration.
To configure a ISUP Remote User Part with ClientView, refer to Remote User.
To configure with the Excel API, follow the procedure below.
Configuration Procedure
1. Assign the logical node IDs to MSPs.
Send the NGA Configure message (0x0130), Local Node Configure.
2. Download software licenses.
Send the NGA Configure message (0x0130), License Configure.
3. Provision remote node database.
Send the NGA Configure message (0x0130), Remote Node Configure.
4. Assign logical spans throughout the MSP.
Send the Assign Logical Span ID message (0x00A8) to assign spans to physical span offsets.
5. Configure the spans and channels corresponding to SS7 signaling links for clear channel.
Send either the E1 Span Configure message (0x00D8) or the T1 Span Configure message (0x00A9), depending on the protocol you use, to establish clear channel signaling.
6. Configure the SS7 Signaling Stacks with a stack ID, an Originating Point Code (OPC), and the variant to be used.
Developer Information
993
Send the SS7 Signaling Stack Configure message (0x005C) to assign the stack ID, OPC, and variant.
7. Configure the signaling link sets with a signaling link set ID to a given adjacent point code.
Send the SS7 Signaling Link Set Configure message (0x005D) to configure the link sets.
8. Configure the signaling links with the logical span/channel.
Send the SS7 Signaling Link Configure message (0x005E) to configure the links. The timeslot is provided off the local bus.
9. Configure the signaling routes and specify the relationship between a remote Destination Point Code (DPC) and the signaling links capable of reaching DPC.
Send the SS7 Signaling Route Configure message (0x005F) to configure the routes.
10. Assign the voice circuits and associate a set of span/channels with a set of Circuit Identification Codes (CICs) for a particular stack ID.
Send the SS7 CIC Configure message (0x006A) to configure CICs.
Based on the logical span ID, the node that owns the logical span is informed that the stack ID controlling the voice circuits is the stack assigned to control the CICs in the message.
11. Send Service State Configure for each of the following:
To bring: the spans into service.
To bring the SS7 links into service.
To bring the channels (CICs) into service.
MSP
994
ISUP Continuity
Developer Information
995
ITU
ITU ISUP Continuity
Overview
This feature provides the MSP ITU SS7 variants with a means to perform a continuity check to verify the integrity of the voice circuit between two exchanges before use of the circuit.
Specifications
The requirements for the Continuity Check on the outgoing circuit are provided in the following recommendations for the International Telecommunication Union (ITU):
ITU-T Q.724
ITU-T Q.761 Functional Description of the ISDN User Part of Signalling System No. 7
ITU-T Q.762 General Function of Messages and Signals of the ISDN User Part of Signalling System No. 7
ITU-T Q.763 Formats and Codes of the ISDN User Part of Signalling System No. 7
ITU-T Q.764 Signalling System No. 7 - ISDN User Part Signalling Procedures
Required DSP Equipment
A Call Progress Tone (CPT) transmitter, and a Call Progress Analysis (CPA) receiver of appropriate PCM encoding are required in order to perform outgoing continuity checks.
Implementation
The ISUP part of the SS7 stack has provisions for a continuity check on the outgoing side of the circuit. A continuity check is initiated with either the Continuity Check Request message to the network side, or the setting of the continuity check indicator bits in the Nature of Connection Indicators mandatory parameter field within the IAM message.
These initial messages allow the network side of the circuit to loop back the chosen circuit, so that continuity testing can be done on that circuit. The CCO component within ISUP executes a continuity test to determine if the circuit to be used has continuity before it is used.
A COT message containing the Continuity Indication is sent to the network side when testing is complete. This indication determines whether continuity exists on the circuit or whether more continuity testing is required.
If a Continuity Recheck procedure is running (CRCS for ITU), outgoing calls on the circuit are rejected with an error code of 0x0A.
Next Topic
Configuring ITU ISUP Continuity
MSP
996
Configuring ITU ISUP Continuity
Continuity Check
The Continuity Check feature is disabled by default. To enable it, use the PPL Configure (0x00D7) message to set configuration byte 0x87 for component L3P CIC (0x000F) as follows:
0x04 - enables continuity on the outgoing side
0x08 - enables continuity of the previous circuit
Continuity Recheck
The Continuity Recheck feature is enabled by default. The default number of retries is 2.
Use the PPL Configure (0x00D7) message to modify the configuration bytes for component ISUP CRCS (0x81) as follows:
Change configuration byte 0x0A to 0x00 to disable
Change configuration byte 0x0B to change the number of retries
Developer Information
997
ANSI
ANSI ISUP Continuity
Introduction
This section explains the various aspects of ISUP continuity procedure for ANSI as implemented in the MSP. It includes:
message flows between exchanges
the involvement of host application in each scenario
the timer involved and various configurable parameters
The ANSI specification T1.113.4, (section 2.1.6) is a reference for this information.
ISUP Continuity Check
Continuity check is performed to verify the integrity of the voice circuit between two exchanges before use of the circuit. An exchange can initiate a continuity check on a circuit intended to be used for a call by one of the following ways:
1. Sending an IAM (Initial Address Message) message with a Nature of Connection parameter having continuity check indicator bits set to "required on this circuit".
2. Sending a CCR (Continuity Check Request) on the circuit which fails the initial continuity test mentioned in 1.
3. Sending a CRM (Circuit Reservation Message) with the Nature of Connection parameter having continuity check indicator set to “required on this circuit”
The exchange does the following when it receives these messages:
1. Does a “loopback” on the circuit under test.
2. Starts timer T8 (15 s). Expiration of T8 timer causes the connection to be cleared with cause 41.
The originating Exchange tests the continuity of the circuit by, attaching a transceiver on the circuit under test, sending a tone and verifying that the same tone is received via the loop back.
The continuity test result is propagated to the destination exchange by an ISUP message called COT with the continuity indicator mandatory parameter set to "failed" or "passed".
Next Topic
Example - COT Success
MSP
998
Example - COT Success
The call flow below shows IAM from Exchange A with nature of connection parameter set to continuity required on this circuit followed by a COT (successful) message. Exchange A’s CPC component (0x12) sends a PPL event indication of Continuity Check Outgoing Success (0x07) to the host.
At the receiving side, the host receives a PPL event indication of COT indication in IAM (event 0x02) followed by a DS0 Status Change of 0x07 (Maintenance Loopback), Exchange B’s CPC component (0x12) starts timer T8 and goes into wait for COT state after receiving IAM with nature of connection parameter set to continuity required on this circuit. On receiving the COT (Success) message, the timer T8 is stopped, and the host is informed by sending a PPL event indication of COT success (event 0x02) followed by a DS0 Status Change of 0x02 (In-service) and subsequently the RFS with Data.
Components Involved
CPC (0x12)
Timers Involved:
T8: Wait for COT message
Next Topic
COT Failure
Developer Information
999
Example - COT Failure
The call flow below shows the IAM from Exchange A with nature of connection parameter set to continuity required on this circuit followed by a COT (fail) message.
Exchange A’s CPC component (0x12) sends a PPL event indication of Continuity Check Outgoing Failure (0x08) to the host and starts the CRO (Continuity Recheck Outgoing) procedure. The host will receive an Outseize Control NACK of 0x1b to its Outseize Control message, and subsequently a Channel Released message (0x49).
The host should not consider this channel idle. Attempts to send subsequent Outseize Control messages will result in a 0x0a NACK (Continuity Recheck Running)
The CRO component (0x83) takes over from this point and automatically sends a CCR (Continuity Check Required) message to Exchange B.
This time the continuity test passed and the CCR is followed by REL message. The host (Host A) is informed of this by a PPL event indication of 1st Continuity Recheck attempt successful (0x05) from the CRO component (0x83).
On the inbound leg, Exchange B’s CPC component sends a PPL event indication of COT failure (0x03) to the host on receiving the COT (failed) message and starts the CRI (Continuity Recheck Incoming) procedure. The CRI component (0x15) takes over from this point. The CRI component, upon receiving the CCR message, applies a loopback on the circuit sends LPA (Loopback Acknowledgement) and waits for REL or COT message. A REL message implies that the continuity check was successful and the circuit is put in idle state. A COT message implies that the COT failed. This causes the CRI component to go in wait for CCR state and the whole procedure is repeated.
MSP
1000
Components involved:
CPC(0x12)
CRI(0x15)
CRO(0x83)
Timers involved:
CRI:
T-CCR: Wait for CCR message
T-34: Wait for COT report or REL message
T-27: Wait for continuity Recheck (second CCR message)
CPC:
T8: Wait for COT message
CRO:
T25: Wait before starting the repeat continuity check after continuity failed
Notes:
Upon a successful continuity test after CCR message, the originating exchange does not send a COT (pass) message but a release message.
Developer Information
1001
A Call Progress Tone (CPT) transmitter and a Call Progress Analysis (CPA) receiver of appropriate PCM encoding are required in order to perform outgoing continuity checks.
Host B is intimated about the incoming call before or after the COT result depending upon the value of config byte 0x09 of the CPC component 0x12. See Continuity check on previous circuit for more information.
Next Topic
Example - T8 Expiration
MSP
1002
Example - T8 Expiration
When, due to some reason, Exchange A fails to send a COT report to Exchange B within T8 seconds (default value 15 seconds), Exchange B sends a REL message to Exchange A with a cause of temporary failure as shown in the call flow below.
Developer Information
1003
Continutiy Check Request (CCR)
A COT fail message followed by CCR messages (after T25 of the COT-fail) is sent to Exchange B in case the continuity test fails after the first CCR message. CCR message is sent repeatedly in such cases (repeated COT failures) after every T26 seconds (timer value).
The Repeated continuity check will only be finished when continuity is detected (that is, continuity test passes) or manual intervention occurs.
Next Topic
Example - Repeated COT Failure
MSP
1004
Example - Repeated COT Failure
As shown in the call flow below, in the case of repeated failures the CRO component repeatedly sends CCR to the destination exchange. The first recheck result is indicated to the host by the PPL event indication of “1st Continuity Recheck attempt failure” (0x03) from the CRO component (0x83) and the subsequent failures are indicated by “Continuity Recheck attempt failure” (0x04).
At Exchange A, the host will receive an Outseize Control NACK of 0x1b to its Outseize Control message (0x002C), and subsequently a Channel Released (0x0049) message .
The host should not consider this channel idle. Attempts to send subsequent Outseize Control messages will result in a 0x0a NACK (Continuity Recheck Running). Upon reception of “Continuity Recheck attempt failure” (0x04) indication, the host may choose to stop the Recheck procedures by sending a “Manual Stop” PPL Event Request of 0x40 to component L3PCIC (0x000f).
Exchange A will send a REL message to clear the circuit, and the host will receive a PPL Event Request of 0x01 “Subsequent Continuity Recheck attempt successful” (0x01) from component 0x0083 (CRO). This request is slightly misleading since the recheck was technically not successful in terms of a check tone. The host must recognize that this event is in response to its request to stop the proceedings.
At Exchange B, a success in one of the subsequent attempts is informed by a PPL event indication of “Subsequent Continuity Recheck attempt successful” (0x01). During this time, the inbound circuit will be placed in a Maintenance Loopback state indicated by a DS0 Status Change of 0x07. A DS0 Status Change of 0x02 will notify the host at Exchange B of the completion of continuity checks.
To avoid getting into an infinite loop in case of repeated failures, the MSP gives an option of limiting the continuity checks.
The default behavior of the MSP is to initiate a CCR message after a failed COT and try it four times in case the subsequent continuity checks fail. You can modify the default of 4 retries on the MSP by changing the CRO configuration byte 0x0b value from 2 (two mandatory + 2 default configuration byte = 2 total default) and retaining the default value of configuration byte 0x0a as 1 (which means that stopping of repeated continuity checks is enabled).
Changing configuration byte 0x0a to 0x00 means that the continuity check retries will only stop when continuity is detected (that is continuity test passes) or manual intervention occurs. In this case configuration byte 0x0b is not considered.
Developer Information
1005
Components involved:
CPC(0x12)
CRI(0x15)
CRO(0x83)
Timers involved:
CRI:
T-CCR: Wait for CCR message
T-34: Wait for COT report or REL message
T-27: Wait for continuity Recheck ( second CCR message)
CPC:
T8: Wait for COT message
CRO:
T25: Wait before starting the repeat continuity check after continuity failed
T26: Wait before doing repeated continuity check after subsequent continuity failures
Configuration Bytes
CRO: Continuity Recheck Outgoing (0x83)
Byte Usage Description Options (* default)
MSP
1006
0x0A Stop Continuous Continuity Recheck 0x00 = No
0x-1 = Yes (default)
0x0B Number of Times to Recheck 2 (default)
Continuity Recheck
In case of continuity recheck, the MSP, as recommended by ANSI, sends a COT success report to the destination exchange (and to the CRO component) only when the continuity test is stopped by the CRO component (this is typically done by manual intervention).
At the destination exchange the COT-pass message is misleading in such cases (since the continuity has not actually passed). In view of this, the MSP does not wait for a COT pass message in the CRI component. It just waits for REL which implicitly conveys a successful COT report. Any COT report (fail or pass) coming from the originating exchange is considered as fail at the destination exchange CRI and the MSP keeps waiting for release or timer expiration.
Next Topic
Example - COT Check on Previous Circuit
Developer Information
1007
Continuity on Previous Circuit
When an exchange receives an IAM-continuity check required message, it can do the following:
Choose to wait for the COT-success result before propagating the IAM.
Choose to propagate an incoming "IAM with continuity required", without waiting for the COT result. The outgoing IAM in this case will have the NOC parameter set to continuity check on a previous circuit.
The MSP makes this decision based on the configuration byte 0x09 in the CPC component (0x12). Setting this configuration byte to 0x01 allows the MSP to send the RFS to the host upon receiving an IAM with continuity request. The host can then propagate this IAM with NoC set to continuity check on a previous circuit. If the configuration byte is set to 0x00, the RFS is sent to the host only after a COT- success is received.
Both these cases are shown in the call flows in corresponding example.
Notes
When changing the configuration byte 0x09 in component 0x12 to 0x01, configuration byte 0x2b in component 0x0f must also be set to 0x01.
The host should not try to send any call processing API on the circuit where incoming Continuity Check is being performed, until continuity check results (of pass) are received in the form of a PPL Event Indication.
Exchange B will propagate the COT coming from Exchange A only if it is COT –passed. In case, Exchange B receives COT-fail from Exchange A, it is not propagated to Exchange C and Exchange C clears the call upon the expiration of timer T8.
Next Topic
Example - Continuity Check on Previous Circuit
MSP
1008
Example - Continuity Check on Previous Circuit
In the call flow below, Exchange B waits for COT results before propagating the IAM.
On component 0x12, configuration byte 0x09 is set to 0x00, send RFS after continuity is perfomed.
On component 0x0F, configuration byte 0x2B is set to 0x00, send DS0 status change of Channel Out of Service (Loopback) to the host.
Call Outs
1. The IAM with continuity check is required on this circuit.
2. The PPL Event Indication of 0x01 from component 0x12 (IAM received with the Continuity Check indicator set.)
3. The DS0 status change of OOS (maintenance loopback) is sent only if configuration byte 0x2B of component 0x0F is set to 0x00.
4. The ISUO message of COT success is sent.
5. The PPL Event Indication 0x02 from component 0x12 (COT success from CPC).
6. DS0 status change of in-service.
7. RFS (Request For Service) from L4 to host.
8. Outseize Control message from host to L4.
9. IAM (continuity check not required).
Developer Information
1009
Call Outs
1. IAM (continuity check on this circuit)
2. PPL Event Indication of 0x01 from component 0x12 (IAM received with Continuity Check indicator set.)
3. RFS (Request for Service) from L4 to host. This is sent without waiting for a COT success message as configuration byte 0x09 is set to 0x01
4. Outseize Control message.
5. IAM (continuity check on previous circuit).
6. COT success.
7. PPL Event Indication of 0x02 from component 0x12 (COT success).
8. PPL Event Request 0x0D from component 0x0F (COT success).
9. COT success propagated.
In the following call flow, Exchange B propagates IAM with continuity test on previous circuit. COT failure is not propagated to the destination exchange.
MSP
1010
Call Outs
1. IAM (continuity check on this circuit).
2. PPL Event Indication of 0x01 from component 0x12 (IAM received with Continuity Check indicator set).
3. RFS (Request for Service) from L4 to host. This message is sent without waiting for a COT success message as configuration byte 0x09 is set to 0x01.
4. Outseize Control message.
5. IAM (continuity check on previous circuit).
6. COT failure.
7. PPL Event Indication of COT fail.
8. Channel release (0x0049).
9. RSC (Reset Circuit).
10. RLC (Release Complete).
11. REL (temp failure) on T8 expiration on Exchange C.
12. RLC (Release Complete).
Components involved:
CPC (0x12)
L3P CIC (0x0F)
Timers Involved
CPC
T8: Wait for COT message
Configuration Bytes Involved
Developer Information
1011
CPC: Call Processing Control (0x12)
Byte Usage Description Options (* default)
0x09 Send RFS to the host after incoming continuity result is received. When setting this byte to 0x01, the host should not try to send any call processing API messages on the circuit where incoming Continuity Check is performed - until the continuity check results are received in the form of a PPL Event Indication.
0x00* = Send RFS after continuity has been performed (default)
0x01 = Send RFS before continuity has been performed.
L3P CIC (0x0F)
Byte Usage Description Options (* default)
0x2B Send RFS to host before incoming continuity result is received and connect the loopback without OOS. In this case, the host should not try to send any other call processing messages on the circuit where an incoming continuity check is being performed - until the continuity check results are received in the form of PPL Event Indication.
0x00* = Send DS0 status change of Channel Out of Service (Loopback) to the host.
0x01 = Do not send DS0 status change of Channel Out of Service (Loopback) to the host.
MSP
1012
Incoming and Outgoing Continuity
In some cases, both the incoming and outgoing legs of a call have continuity required on the circuit as shown in the call flow in the example. See Example - Incoming and Outgoing Continuity.
In such cases Exchange B can determine if it wants to wait for a COT success message from Exchange A before sending a COT success message to Exchange C.
In case Exchange B wants to wait for incoming COT report before sending an outgoing COT success, Exchange C will get a combined COT success for the continuity check required for this circuit and the previous circuit.
1. Exchange C receives a COT success message: Means that the continuity of this circuit (between B and C) AND all the preceding circuits for which the continuity test was in progress (like between A and B) has been verified.
2. Exchange C receives a COT failure message: Means that continuity on this circuit (between B and C) has failed
3. Exchange C does not receive a COT message: Means that a previous circuit (like between A and B) might have failed the continuity test. Exchange C does not need to know which circuit failed as long as it is not its own (in which case it is required to start a continuity recheck loop back)
If the Exchange B chooses not to wait for the continuity success message, Exchange B will send a COT success or failed message as soon as the continuity test between B and C is done and the call will proceed beyond Exchange C (in case the COT was successful). There can be two cases here:
1. If Continuity test passes between Exchanges B and C but fails between Exchanges A and B, then Exchange B incoming side will release the call and sends a PPL Event Indication of COT failure to the host. On the outgoing side (between B and C), the onus lies with the host to release the call and free the outgoing circuit.
2. If Continuity test passes between Exchanges B and C and between Exchanges A and B, Exchange B should not propagate the COT message received to the outgoing side and should let the call complete.
Next Topic
Example - Incoming and Outgoing Continuity
Developer Information
1013
Example - Incoming and Outgoing Continuity
The host sends a PPL event request of 0x0C to component L3P CIC component (0x0F) to make the MSP (Exchange B) wait for the incoming COT report (from Exchange A) before sending COT success to Exchange C.
At Exchange B the host passes information of the incoming COT report to the outgoing L3P (and hence CPC) component by sending a PPL event request of 0x0d to the L3P component. This request conveys an incoming COT success.
Exchange B propagates COT success only when both inbound and outbound continuity tests pass.
1. IAM (continuity check on this circuit)
2. PPL event indication of 0x01 from component 0x12 (IAM received with Continuity Check indicator set)
3. RFS (Request For Service) from the MSP to the host. This is sent without waiting for a COT success message as config byte 0x09 is set to 0x01
4. Outseize Control message
5. PPL Event Request 0x0c from component 0x0f to indicate CPC to wait for incoming COT report when continuity check is being performed on previous circuit AND this circuit (i.e. both incoming and outgoing continuity are being performed).
6. IAM (continuity check on this circuit)
7. COT success
8. PPL event indication of 0x02 from component 0x12 (COT success)
9. PPL event request 0x0d from component 0x0f (COT success).
10. COT success propagated. This is sent only after a successful continuity test is done on circuits between Exchanges B & C and between A & B.
MSP
1014
Exchange B does not propagate COT when the inbound COT fails.
1. IAM (continuity check on this circuit)
2. PPL event indication of 0x01 from component 0x12 ( IAM received with Continuity Check indicator set )
3. RFS (Request For Service) from L4 to host. This is sent without waiting for a COT success message as config byte 0x09 is set to 0x01
4. Outseize control message
5. PPL event Request 0x0c from component 0x0f to indicate CPC to wait for incoming COT report when continuity check is being performed on previous circuit AND this circuit (i.e. both incoming and outgoing continuity are being performed).
6. IAM (continuity check on this circuit)
7. COT Failure
8. PPL event indication of 0x03 from component 0x12 (COT failure)
9. Channel released (0x0049)
10. RSC (Reset Circuit)
11. RLC (Release Complete)
12. REL (temp failure) on T8 expiration on Exchange C
13. RLC (Release Complete)
Components Involved
CPC (0x0012)
L3P CIC (0x000F)
Timers Involved
Developer Information
1015
CPC
T8 Wait for COT message
MSP
1016
PPL Information for Continuity
This topic summarizes the PPL information used for continuity:
Event Requests
Event Indications
Configuration Bytes
Timers
PPL Event Requests
From: Host
To: L3PCIC (0x000F)
Event ID Event Description
0x0C Indicate CPC to wait for incoming COT report when continuity check is being performed on a previous circuit.
0x0D Send incoming continuity check report if continuity check was performed on previous circuit.
PPL Event Indications
From: Call Processing Control (0x12)
To: Host
Event ID Event Description
0x01 Continuity indication in IAM. (Note: The host will also receive a DS0 status change as the channel is automatically brought OOS to perform the continuity test.)
0x02 COT success (incoming)
0x03 COT failure (incoming)
0x04 T8 expiration
0x05 REL received while waiting for Continuity Check
0x07 Continuity Check Outgoing Success
0x08 Continuity Check Outgoing Failure
FROM: Continuity Recheck Outgoing (0x83)
TO: Host
Event ID Event Description
Developer Information
1017
0x01 Subsequent Continuity Recheck attempt successful
0x03 First Continuity Recheck attempt failure
0x04 Continuity Recheck attempt failure
0x05 First Continuity Recheck attempt successful.
PPL Configuration Bytes
Call Processing Control 0x12
Byte Usage Description
Options (*default)
0x09 Send RFS to host after incoming continuity result is received. When setting this byte to 0x01, the host should not try to send any call processing API on the circuit where incoming Continuity Check is being performed, until continuity check results are received in the form of PPL Event Indication.
0x00* = Send RFS after Continuity (default) has been performed0x01 = Send RFS beforeContinuity has been performed
L3PCIC (0x000F)
Byte Usage Description Options (*default)
0x2B Send RFS to host before incoming continuity result is received and connect loopback without OOS. In this case, the host should not try to send any other call processing API on the circuit where an incoming continuity check is being performed, until the continuity check results are received in the form of PPL Event Indication
0x00* = Send DS0 status change of Channel Out of Service (Loopback) to the host (default)
0x01 = Do not send DS0 status change of Channel Out of Service (Loopback) to the host
Continuity Recheck Outgoing (0x83)
Byte Usage Description Options (*default)
0x0A Stop Continuous Continuity Recheck 0x00=Enables unlimited repeated continuity checks
0x01= Limits the repeated continuity checks to n+2 times where N is the value of config byte
MSP
1018
0x0B.
(default)
0x0B Number of Times to Recheck 2 (default)
PPL Timers
Call Processing Control (0x12)
Timer ID Default Value Description
0x01 (T8) 15 s Wait for COT message
Continuity Check Outgoing (0x14)
Timer ID Default Value Description
0x18 (T24)
2 s
Continuity Recheck Incoming (0x15)
Timer ID Default Value Description
0x01 (TCCR)
20s Wait for CCR message
0x02 (T27) 180s Wait for COT report (repeated recheck)
0x03 15s Wait for COT report
Continuity Recheck Outgoing (0x83)
Timer ID Default Value Description
0x01 (T1) 15s
0x19 (T25)
10s Wait before sending CCR after first COT fail
0x0A (T26)
180s Wait before sending subsequent CCR after subsequent COT fail
Developer Information
1019
Host Controlled Continuity
The continuity feature as implemented on the MSP may prove ineffective when the host wants to specifically take control of the continuity procedure. A typical example where this may be required is in situations where the Voice circuits and Signaling links do not reside on the same MSP or where the voice circuits being used for the call are virtual circuits. This section mentions the changes made in the ISUP layer to implement Host controlled Continuity Check procedure.
Host controlled continuity has been implemented in a way that it does not impact the existing COT procedure. A configuration byte 0xCC has been introduced in the CPC components of ISUP, which when left to its default value of 00 will leave the existing continuity procedure as it is. When this configuration byte is changed to 01, the following changes in functionality take place:
All COT processing in CPC is bypassed.
All COT related inter-component messaging is bypassed.
The COT, CCR and LPA (ANSI) messages received by SPRC are directly propagated to the Host via the CPC. This introduces new PPL event indications to the Host.
The host will now be able to send PPL event requests for COT, CCR and LPA.
The onus of performing the continuity test and sending the COT (success/failure) to the MSP is on the host application. MSP has no control and no involvement in the continuity test procedure.
MSP
1020
Monitoring SS7
Introduction to SS7 Monitoring
Overview
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 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.
Performance & Capacity
The MSP 1010 supports passive monitoring of up to 64 bi-directional signaling links or 128 Rx channels.
Supportability
You can use one query to provide information about the following elements:
Spans' configuration (whether it is high impedance or low impedance) for all the spans.
SS7 links' configuration (whether it is a bi-directional link or monitoring link) for all the links.
Applications
Various applications can make use of the MSP 1010 SS7 monitoring feature. Among them are the following:
Traffic Engineering & Network Planning
Welcome Message
Missed call alert
Location Based Services
Interconnections Arbitration
Fraud Detection and Control via Real-Time Call Detail Records
Optimal Routing
Developer Information
1021
SS7 Message Analysis
Traffic Engineering & Network Planning
This application gives continuous real-time 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 is an attractive family of services, which service provider looking forward to capture the roamer to log on into their network. The Welcome message may be implemented for useful information such as weather forecasts currency exchange rates and local favorites to be sent periodically to the roamer during his/her stay in the visiting country. The application provides means for service provider to reach out to both the inbound and outbound roamers, providing them with customized information, thereby improving service experience for the mobile roamer and increases their loyalty towards the service provider.
Missed call alert
By monitoring the signaling links between the MSCs, the application is capable to detect missed call and to alert the subscriber by sending an SMS. By offering this application, operators can increase the minutes per subscriber and to 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.
MSP
1022
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 cost-effective 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.
Developer Information
1023
SwitchKit Support
Excel’s SwitchKit supports the SS7 monitoring capability on the MSP 1010. Connectivity between SwitchKit and the MSP 1010 use the existing operations, administration and maintenance (OA&M) host link and API methodology (i.e. MSP1010 server sockets: 0x3142, 0x3143 or 0x3144). The SS7 monitoring feature can be configured and maintained using the SwitchKit graphical user interface, ClientView. See Example Configuration for SS7 Monitoring. If you do not use SwitchKit as the OA&M sub-system, you can deploy your own implementation. Monitor applications (MAs) will serve network sockets for receiving data without utilizing LLC. The MSP 1010 will initiate client connections to MAs as directed through OA&M directive. The customer is free to co-locate or distribute MAs as their individual requirements dictate. Some MAs will require precision time stamps of monitored events. Connectivity to a customer provided NTP server would be necessary for those applications.
The next diagram demonstrates the relationship of monitoring applications, SwitchKit components, the MSP1010 and the external SS7 signaling network elements.
MSP
1024
Hardware Specifications
The 21 E1/28 T1 spans on the MSP can be configured to high impedance for monitoring SS7 traffic, or low impedance for live SS7 links. It also supports combined configuration: high and low impedance for applications that monitor and transmit SS7 traffic. The flexible MSP architecture allows configuring the span's impedance per single span. The clock module allows recovering the clock from high-impedance spans as well as low-impedance spans. The monitoring product uses the same existing clock mechanism as the MSP-1010.
Developer Information
1025
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. Here are the three types (ITU only):
Message Signal Unit (MSU)
Link Status Signal Unit (LSSU)
Fill-in Signal Unit (FISU)
Message Signal Unit (MSU)
The Message Signal Unit (MSU) is used to carry the signaling information between user parts. The MSU is re-transmitted when an error is detected. There are also MSUs that are used for signaling network management and signaling network testing and maintenance.
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) - In the beginning and the end of the MSU.
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 software enables the user to filter retransmitted MSUs (See Filtering for Relevant Messages).
Link Status Signal Unit (LSSU)
The LSSU is used for starting up the link and carries the information about the link status. The LI value in LSSU is 1 or 2. The user can filter the LSSU signal units, if these messages are not of the interest of the application (See Filtering for Relevant Messages.).
Fill-in Signal Unit (FISU)
MSP
1026
Fill In Signal Unit (FISU) is used for error supervision of the link and for keeping the link running when there are no MSUs to be sent. The LI value of FISU signaling unit is zero. The user can filter the LSSU signal units, if these messages are not of the interest of the application (See Filtering for Relevant Messages).
Developer Information
1027
Filtering
To prevent host overload, a filtering module removes irrelevant messages and forwards only the messages of interest to the host application. The filtering module allows maintaining four different filter profiles. Filters can be set to filter the following:
Non-acknowledged MSUs
FISU messages
LSSU messages
User Part types
Specific OPC and / or specific DPC
Combined point code and user part type
Filtering Non-acknowledged MSUs
To ensure proper delivery of MSUs, the MTP2 protocol retransmits any MSU received with error (LSSU are not retransmitted). The acknowledgement is sent in the response message, in the BIB (Backward Indicator Bit) and BSN (Backward Sequence Number) fields in MTP2 header, as specified in ITU Q.703. Two retransmission mechanisms are specified in ITU Q.703. The filter complies with both mechanisms:
Basic Error Correction Method (Q.703, clause 5)
This mechanism obligates the filtering module to retain the transmitted MSU until it receives the acknowledgement in the response message. It also has to know the link ID of the Rx and Tx of the monitored SS7 link, in order to capture the response. In order to avoid retaining messages endlessly, a timer is triggered for each message (the same value as T7 in Q.703 is recommended). The timer value is configurable, and allows proper functioning of different SS7 links (different propagation delays).
Preventive Cyclic Retransmission (Q.703, clause 6)
The Preventive Cyclic Retransmission (PCR) mechanism re-transmits MSUs already sent, though not yet acknowledged. PCR takes place whenever there are no new MSUs or LSSUs available to be sent.
Filtering FISU messages
The filtering module allows the user to discard FISU messages.
Filtering LSSU messages
The filtering module allows the user to discard LSSU messages.
Filtering User Part types
MSP
1028
The filtering module allows the user to select only the desired MSUs and to forward them to the application. The rest of the MSUs are discarded. The filtering criteria are set in the "Service Indicator (SI)" in the SIO field. The following options are available to the user:
Forward all user parts without filtering.
Forward only Signaling Network Management Messages (SI=0)
Forward only SCCP messages (SI=3)
Forward only TUP messages (SI=4)
Forward only ISUP messages (SI=5)
A bit mask that allows a combination of User Parts).
The next diagram shows the Service Indicator Field:
Filtering Specific OPC and / or specific DPC
The filtering module selects MSUs according to the OPC and/or DPC as follows:
Forward only messages from a specific or a range of OPCs
Forward only messages from a specific or a range of DPCs
Forward only messages from a specific range of OPCs to a specific range of DPCs.
The next diagram shows the location of the point codes in the MSU, regardless the user part type.
Developer Information
1029
Filtering for a Combination of Point Code and User Part Type
The filtering module enables an "AND" function between the point code filter and the user part filter. That is, the filter shall enable filtering messages from any combination of Point Codes (OPC & DPC) with a specific user part.
MSP
1030
Host/Application Server Interface
Configuration
MSP-1010 forwards the monitored traffic to the application servers through a separate port (a separate port for each application server) directly to the application without passing the LLC layer. See Example Configuration for SS7 Monitoring.
The operations and maintenance traffic is routed through the current O&M socket (the dotted line in the next diagram).
Routing
MSP-1010 supports 16 different application servers. MSP-1010 routes the traffic between different application servers based on the following criteria:
Link Id.
Filter profile
Link ID and filter profile
Developer Information
1031
Excel API for SS7 Monitoring
API Messages Used
To provision the characteristics of physical spans prior to logical span assignment, use NGA Configure/ NGA Query API messages. The facility impedance TLV (0xE04F) indicates that the designated physical span operates in a high impedance/transmit disabled mode only.
Note: The LIU high impedance capability is currently only possible on the 28 SuperMapper physically terminated spans. The management logic validates that this capability is only requested where physically possible.
To provision the external NTP server set, use NGA Configure/ NGA Query API messages. Logical arguments include: NTP server IP Address
To report changes in NTP server accessibility and indications concerning timekeeping accuracy, use NGA Notify and/or NGA Alarm API messages.
To provision a set of two DS0s as a monitored link, use NGA Configure/ NGA Query API messages. Logical arguments include:
monitored link identifier.
two logical span/channels
DS0 data rate bit-mask
inversion flag
MTP method (basic vs. PCR)
MTP variant (ANSI, ITU, China, Japan)
To report changes in monitored link status (L1 state, L2 state, HDLC errors) the MSP 1010 uses NGA Notify and/or NGA Alarm API messages.
To provision filter specifications for traffic destined for monitor applications (MA), use NGA Configure/ NGA Query API messages. Logical arguments shall include:
Filter identifier
filter type
filter action
filter specification
MA socket specification (IP Address, port)
To report changes in MA socket accessibility or MA socket data flow congestion the MSP 1010 uses NGA Notify and/or NGA Alarm API messages.
To report changes in the MSP resident application to handle the offered traffic load, the MSP 1010 uses NGA Notify and/or NGA Alarm API messages.
Message presentation
You can configure and select the fields in the SS7 messages that will be forwarded to the application. You can configure whether to send the MTP2 header (with the SS7
MSP
1032
message) to the application or only the MTP2 payload (without the header). This option is enabled per Application Server. Based on the filtering options selected, the following may be reported.
Example
SigView Link Signaling Notify - Information
00:06:29.820 ALOG(X-H) (067)1 [00 41 01 2b 00 ea 00 03 04 67 02 00 01 64 02 15 00 64 02 10 00 64 02 10 03 00 02 e0 21 00 03 03 00 00 e0 00 00 1d 00 02 90 0d 00 0b 00 05 e3 ec 00 01 00 00 00 00 01 90 0f 00 08 00 00 9c 00 8a 8a 00 00]
00:06:29.820 ALOG(X-H) (067)1
00 41 ' Message Length
01 2b ' Message Type
00 ea ' Sequence Number
00 ' Logical Node ID
03 ' Address Method = NGAPI Item
04 ' Number of Address Elements
67 02 00 01 ' Functional Area - Signaling
64 02 15 00 ' Object Type - SigView
64 02 10 00 ' Object Type - SS7
64 02 10 03 ' Object Type - Link
00 ' Data Type
02 ' Number of TLVs
e0 21 ' TLV - Query Response Message Info
00 03 ' Length
03 ' Message position
00 00 ' Message Response Count
e0 00 ' TLV - Container
00 1d ' Length
00 02 ' Number of TLVs in the container
90 0d ' TLV - SigView Indication Header
00 0b ' Length
00 05 e3 ec ' Timestamp
00 01 ' Application ID
00 00 ' Layer Rule ID
00 00 ' Monitoring Link ID
01 ' Monitoring Link Direction
90 0f ' SigView FISU or LSSU Data
Developer Information
1033
00 08 ' Length
00 00 9c 00 ' Count
8a ' BIB
8a ' FIB
00 ' LI
00] ' Status
MSP
1034
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
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)
Slot non-sk host must define to configure DS3 (Brian, what slot is it? Is there more I should say?)
Use the DS3 AIB (0x32) for .... (Brian, for call processing, config, taking in/out of service. Not sure what you were getting at?)
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
Developer Information
1035
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.
MSP
1036
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 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
Developer Information
1037
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
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
MSP
1038
Data [1]
0x00 – Cancelled
0x01 – Requested
DS1 Loopback Query on Single DS1
Query the loopback status of a single DS1 (local, remote or no loopback.)
Entity 0x0A
Developer Information
1039
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
0xE060 User-defined Test Pattern
0xE068 BERT Error Mode
MSP
1040
Developer Information
1041
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
MSP
1042
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
Codec Payload Sizes
Dynamic Payload Type
VoIP Configuration Options
Overview of VoIP Configuration
Developer Information
1043
VoIP Resource Profiles
Resource profiles 4-7 are available for the VoIP Module as follows. The MSP supports two VoIP modules each with four DSP chips.
Profile Number
Profile Name
CODEC Supported
Channels/DSP Channels/Module
4 G.711 only
G.711
No fax relay - no T.38
168 672
5 (default)
LBR (Low Bit Rate)
G.711
G.723
G.726
G.729,T.38
128
(100 for T.38)
512
(400 for T.38)
Additional Notes
Resource profiles must be configured by the Host Flag attribute in the BOOTP server.
ARP services are not contained within the scope of the VoIP module - system infastructure controls these services.
Related Topic
IP Bearer Profile (ClientView)
MSP
1044
Codec Overview
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.
G.711
International standard for encoding telephone audio on an 64 kbps channel.
It is a pulse code modulation (PCM) scheme.
Two different variants: A-law and mu-law. A-law is the standard for international circuits.
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).
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.
Developer Information
1045
Codec Payload Size
The following table includes the payload sizes of the codecs supported by the MSP.
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 Payload Sizes (ms) Payload Type Base Rate (ms)
G.711 u-Law 10,20,30,40,50,60 0x00 5
G.711 A-law 10,20,30,40,50,60 0x08 5
G.723 30,60 0x04 30
G.726 10,20,30,40,50,60 0x12 or
0x60-0x7F
5
G.729 A/B 10,20,30,40,50,60 0x12 10
* Payload size TLV not required when using this Codec.
MSP
1046
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 is a byte-by-byte example.
TLV Notes
Universal NPDI TLV Container for NPDI TLVs.
Per Codec Info TLV (0x2A02)
For call control messages fro the host, this TLV encapulates the TLVs below. The Universal NPDI TLV is not required.
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 96-127 and is negotiated by the IP signaling layer the bound to a codec for a single call.
NPDI Media Payload Type TLV (0x2A08)
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.
Developer Information
1047
Dynamic: When byte[0] is set to dynamic, then we are expecting that 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 96-127.
NPDI Media Payload Description (0x2A09)
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, GSM-AMR, EVRC, G.726-16kbps, G.726-24kbps and G.726-32kbps.
Example
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
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 non-NPDI 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.
MSP
1048
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 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
Data Transfer
Management Control
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
Developer Information
1049
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.114 TCAP 2000 and Telecordia GR-246 issue 7
ANSI T1.112 SCCP 2000 and Telecordia GR-246 issue 7
MSP
1050
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.
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.114 TCAP 2000 and Telecordia GR-246 issue 7
ANSI T1.112 SCCP 2000 and Telecordia GR-246 issue 7
Developer Information
1051
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 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
MSP
1052
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
Personal Communication Service (PCS) Network
Developer Information
1053
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.
The ANSI primitives are consistent with ANSI T1.1.114-1992 (TCAP) and ANSI T1.112-1996 (SCCP).
MSP
1054
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
100,000 entries
maximum of 24 digits
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
Refer to the following sections for information to configure Global Title Translation.
Developer Information
1055
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
0x09CB Delete Global Title Group
0x09CC Add Global Title Entry
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
MSP
1056
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
Use the following TLV to add Global Title Groups.
Add Global Title Group TLV 0x09CA
Byte Description
0, 1 Tag 0x09CA Add Global Title Group
2 Length 0x0009
3 Value[0] 0-127 Group ID (GID)
4 Value[1] Global Title Indicator (GTI)
1-4 for ITU
1-2 for ANSI
5 Value [2] Translation Type (TT)
0-255 ( 0 = Default)
6 Value [3] Numbering Plan (NP)
0-15 ( 0 = Default)
7 Value [4] Nature of Address Indicator (NAI)
1-127 ( 0 = Default)
8 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.
Developer Information
1057
9 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.
10 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
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.
1 = Remove GT after a successful translation.
11 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
MSP
1058
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 Description
0, 1 Tag 0x09CB Delete Global Title Group
2 Length 0x0006
3 Value[0] Group ID (GID)
1-127
4 Value [1] Global Title Indicator (GTI)
1-15
5 Value [2] Translation Type (TT)
0-255 ( 0- Default)
6 Value [3] Numbering Plan (NP)
0-15 ( 0 - Default)
7 Value [4] Nature of Address Indicator (NAI)
1-127 ( 0 - Default)
8 Reserved for future use. (REV)
The sample below deletes four groups: 00 to 03.
Developer Information
1059
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
0, 1 Tag 0x09CC Add Global Title Entry
2, 3 Length Variable
4 Value[0] Group ID (GID)
1-127
5 Value [1] Entry Attribute
Bit 0 - Wild Card bit
0 - Non Wild Card GT
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
MSP
1060
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
Translation result format: RI+PC+SSN (RI=Routing Indicator, PC=Point Code, SSN=Subsystem Number)
RI= Route on DPC/SSN
Sample 2
The following values apply to the sample below:
Entry Attribute: Wild card entry
Translation result format: RI+PC+SSN
RI= Route on DPC/SSN
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
Translation result format: RI+PC
RI= Route on GT
Developer Information
1061
Sample 5
The following values apply to the sample below:
Entry Attribute: Non wild card entry
Translation result format: RI+PC+SSN+GT
RI= Route on DPC/SSN
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
0, 1 Tag 0x09CD Delete Global Title Entry
2, 3 Length Variable
4 Value[0] Group ID
1-127
Already configured.
5 Value [1] Entry Attribute
Bit 0 - Wild Card bit
0 = Non Wild Card GT
1 = Wild Card GT
Bits 1-7 Not Used.
6 Reserved for future use.
7 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.
MSP
1062
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
0, 1 Tag 0x09CE Build Index Table
2, 3 Length 0x0001
4 Value[0] Bit 1 - 1=Build Index
Developer Information
1063
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.
SCCP PPL Components
The following list contains the SS7 SCCP PPL Components and their IDs:
Component ID
Component Name
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 PPL Components
Component ID Component Name
0x70 TUSI - TCAP User Interface
0x71 CCO - Component Portion Control
0x72 ISM - Component Portion
0x73 TCO - Transaction Coordinator
0x74 TSM - Transaction State Machine
MSP
1064
0x75 DHA - dialog Handling
Message flow for SCCP and TCAP components
SCCP Components and Message Flow
Note: SCMG = SCCP Management
TCAP Components and Message Flow
Developer Information
1065
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
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
MSP
1066
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)
Developer Information
1067
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)
MSP
1068
Developer Information
1069
Configuring SCCP TCAP
Overview
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 Use the SS7 SCCP/TCAP Configure message to...
Adjacent Translator
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 .
Other Concerned Point Code
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.
SCCP/TCAP Default Parameter Table
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 Unidialog_As_ID
TCAP Protocol Version
You do not need to configure this table unless you require
MSP
1070
modifications.
Subsystem
(Based on default parameter table)
Configure the default parameter table for a particular sub-system. Set the Config Type byte to 0x05.
TCAP Object Syntax Descriptor (OSD)
Set the Config Type byte to 0x06. You can modify a TCAP object by indicating the TCAP object parameter ID, TCAP identifier, whether or not to update the object syntax and if updated, what the object syntax description is.
See TCAP Object Syntax Descriptor (OSD) Configuration.
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.
Network DPC/SSN
Set the Config Type byte to 0x07 to configure the Destination Point Code (DPC) and remote subsystem number.
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.
Replicated SSN
Set the Config Type byte to 0x09 to configure the replicated SSN.
Global Title Translation
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
Subsystem Default Parameter Table
TCAP Active Transactions
TCAP Active Operations
Related Topics
Deconfiguring SCCP/TCAP
GTT Configuration Samples
Developer Information
1071
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 Link Set Configure
SS7 Signaling Route Configure
4. Deconfigure the stack using the SS7 Stack Configure message.
MSP
1072
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, Section 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)
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
LNI - Logical Node ID
PPL Comp. ID - PPL Component ID
Length (MSB, LSB)
Message
Type (MSB, LSB)
Reserve
Byte
Seq.
No.
LNI AIB Stack* PPL
Comp.
ID*
PPL #Data
Entity Location
Byte Data
00 10 00 D7 00 00 FF 00 01
18 01
00 00 2B 01 01
01 03
00 10 00 D7 00 00 FF 00 01
18 01
00 00 2C 01 01
01 03
Developer Information
1073
00 10 00 D7 00 00 FF 00 01
18 01
00 00 65 01 01
01 02
00 10 00 D7 00 00 FF 00 01
18 01
01 00 2B 01 01
01 03
00 10 00 D7 00 00 FF 00 01
18 01
01 00 2C 01 01
01 03
00 10 00 D7 00 00 FF 00 01
18 01
01 00 65 01 01
01 02
MSP
1074
TCAP Object Syntax Descriptor (OSD) Configuration
Overview
This feature is provided to allow configuration of the ASN.1-based syntax of the TCAP objects.
The TCAP objects include the TCAP Information Elements (IE) as defined in the ITU/ANSI TCAP specification, as well as objects for internal use that are dependent on implementation. Each TCAP object is uniquely defined by a parameter ID. Parameter IDs can be used to address the TCAP objects through the TC-user via the API ICB, or within the MSP 1010 using PPL.
See TCAP Parameter IDs. You can only modify the identifier/tags for the non-internal use parameters.
Only the modification of the TCAP IE identifier/tag is allowed. See the SS7 SCCP/TCAP Configure 0x0077 and SS7 SCCP/TCAP Query 0x0078 messages.
Developer Information
1075
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
MSP
1076
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:
SS7 spans
signaling stacks, link sets, links, and routes
bring spans, channels, and links in service
sccp.cfg includes SCCP-related configuration information. There are two subsystems configured for each stack. The following configuration is performed:
SCCP local SSN
Adjacent translators
Other Concerned Point Codes (optional)
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
Developer Information
1077
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)
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
MSP
1078
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
' 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
Developer Information
1079
unitdata.cfg
MSP
1080
begin.cfg
'directhost.cfg
'matrixhost.cfg
TCAP primitive #1
Developer Information
1081
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
TCAP Primitive Set
MSP
1082
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)
Developer Information
1083
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
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
MSP
1084
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:
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.
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-WITH-PERMISSION/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:
Developer Information
1085
Pre-arranged End
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.
Basic End
The ending causes transmission of any pending components at the side which initiates it.
Abort by TC-USER
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 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.
MSP
1086
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.
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-R-REJECT 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-U-ABORT
TC-P-ABORT
Incoming Reject Components
Developer Information
1087
An incoming reject component received with a TCAP Problem Code causes a TC-R-REJECT 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 TC-U-REJECT indication to be sent to the TC-USER. This indicates that the remote TC-USER detected a problem with a previously sent component and issued a TC-U-REJECT 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:
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.
MSP
1088
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 MSP 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
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-CONTINUE 0x02
TC-END 0x03
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)
SCCP
Developer Information
1089
N-UNIT-DATA 0x01
N-NOTICE 0x02 (Indication only)
N-STATE 0x03
N-PC-STATE 0x04 (Indication only)
SCCP CSCC
N-COORD 0x05
N-COORD 0x08
SCCP SCOC
N-CONNECT 0x15
N-CONNECT 0x16 (Response/Confirmation)
N-DATA 0x17
N-DISCONNECT Ox1B
ANSI Primitives
The ANSI primitives are supported by both the PPL Event Request and PPL Event Indication message unless noted otherwise.
TCAP
TC-UNI 0x04
TC-U-ABORT 0x05
TC-P-ABORT 0x06 (Indication only)
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)
SCCP
MSP
1090
N-UNIT-DATA 0x01
N-NOTICE 0x02 (Indication only)
N-STATE 0x03
N-PC-STATE 0x04 (Indication only)
SCCP CSCC
N-COORD 0x05
N-COORD 0x08
SCCP SCOC
N-CONNECT 0x15
N-CONNECT 0x16 (Response/Confirmation)
N-DATA 0x17
N-DISCONNECT Ox1B
Developer Information
1091
ANSI TCAP Primitives
Overview
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-WITH-PERMISSION
TC-QUERY-WITHOUT-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
MSP
1092
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.
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
TCAP Parameter ICB (M)
- No parameters included
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)
- 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)
0x05 TC-U-ABORT
This dialog primitive allows a TC-USER to terminate a dialog abruptly without transmitting any pending components.
Request Indication
TCAP Parameter ICB (M)
- User Abort Info (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 Parameter ICB (M)
- User Abort Info (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 TC-P-ABORT
Developer Information
1093
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
TCAP Parameter ICB (M)
- No parameters included
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)
- 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)
0x08 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
TCAP Parameter ICB (M)
- No parameters included
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA Elements (O)
TCAP Parameter ICB (M)
- Component Present (M)
SCCP Parameter ICB (M)
- Calling Party Address (CGPA) or CGPA Elements (M)
MSP
1094
- Called Party Address (CDPA) or CDPA Elements (M)
- Quality of Service (O)
- Called Party Address (CDPA) or CDPA Elements (O)
- Quality of Service (O)
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
TCAP Parameter ICB (M)
- No parameters included
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)
- Component Present (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
TCAP Parameter ICB (M)
- No parameters included
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)
- Component Present (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
Developer Information
1095
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
TCAP Parameter ICB (M)
- Termination Option
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 Parameter ICB (M)
- Component Present (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 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
TCAP Parameter ICB (M)
- Correlation ID (O)
- Parameter (O) *
TCAP Parameter ICB (M)
- Correlation ID (O)
- Parameter (O) *
0x0D 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
TCAP Parameter ICB (M)
- Correlation ID (O)
- Parameter (O) *
TCAP Parameter ICB (M)
- Correlation ID (O)
- Parameter (O) *
- Last Component (M)
0x0E TC-U-ERROR
This component primitive corresponds to the ITU Return Error component. It indicates that the operation failed.
Request Indication
TCAP Parameter ICB (M) TCAP Parameter ICB (M)
MSP
1096
- Correlation ID (O)
- Error Code (M) *
- Parameter (O) *
- Correlation ID (O)
- Error Code (M) *
- Parameter (O) *
- Last Component (M)
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
TCAP Parameter ICB (M)
- Invoke ID (O)
- Correlation ID (O)
- Operation (M) *
- Parameter (O) *
TCAP Parameter ICB (M)
- Invoke ID (O)
- Correlation ID (O)
- Operation (M) *
- Parameter (O) *
- Last Component (M)
0x11 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
TCAP Parameter ICB (M)
- Invoke ID (M)
- Correlation ID (M)
- Operation (M) *
- Parameter (O) *
TCAP Parameter ICB (M)
- Invoke ID (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
TCAP Parameter ICB (M)
- Correlation ID (O)
- Problem Code (M)
TCAP Parameter ICB (M)
- Correlation ID (O)
- Problem Code (M)(see SCCP/TCAP
Developer Information
1097
- Parameter (O) * 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)
MSP
1098
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 MSP 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 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.
Developer Information
1099
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.
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)
MSP
1100
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.
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)
Developer Information
1101
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 TC-primitive 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.
TCAP TUSI PPL Configuration Byte
Byte Description Value
0x09 Selects TCAP to TC-User interface format
0x00 = Use individual TC-Primitive (Default)
0x01 = Use TCAP Primitive Set Interface
Examples
You can view TCAP Primitive Set API messaging examples in Example Configurations and TCAP API Messaging.
MSP
1102
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-BEGIN
TC-CONTINUE
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)
TC-L-REJECT (Indication only)
TC-R-REJECT (Indication only)
N-UNIT-DATA
N-NOTICE (Indication only)
N-STATE
N-PC-STATE (Indication only)
TC_RESET_TIMER
ITU TCAP TUSI PPL Events
Developer Information
1103
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
TCAP Parameter ICB (M)
- Application Context Name (O)
- 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)
TCAP Parameter ICB (M)
- Application Context Name (O)
- 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)
0x02 TC-CONTINUE
Request Indication
TCAP Parameter ICB (M)
- Application Context Name (O)
- User Information (O)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA Elements (O)
- Quality of Service (O)
TCAP Parameter ICB (M)
- Application Context Name (O)
- User Information (O)
- Component Present (M)
SCCP Parameter ICB (O)
- Quality of Service (O)
0x03 TC-END
Request Indication
TCAP Parameter ICB (M) TCAP Parameter ICB (M)
MSP
1104
- Application Context Name (O)
- User Information (O)
- Termination Option (M)
SCCP Parameter ICB (O)
- Quality of Service (O)
- Application Context Name (O)
- 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
TCAP Parameter ICB (M)
- No parameters included
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)
- 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)
0x05 TC-U-ABORT
This dialog primitive allows a TC-USER to terminate a dialog abruptly without transmitting any pending components.
Request Indication
TCAP Parameter ICB (M)
- User Abort Info (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 Parameter ICB (M)
- User Abort Info (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 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
Developer Information
1105
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
TCAP Parameter ICB (M)
- No parameters included
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)
- 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)
0x08 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
TCAP Parameter ICB (M)
- No parameters included
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)
- 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)
MSP
1106
- MTP_DPC (0) - 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
TCAP Parameter ICB (M)
- No parameters included
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)
- Component Present (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
TCAP Parameter ICB (M)
- No parameters included
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)
- Component Present (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
Developer Information
1107
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
TCAP Parameter ICB (M)
- Termination Option
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 Parameter ICB (M)
- Component Present (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 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
TCAP Parameter ICB (M)
- Correlation ID (O)
- Parameter (O) *
TCAP Parameter ICB (M)
- Correlation ID (O)
- Parameter (O) *
0x0D 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
TCAP Parameter ICB (M)
- Correlation ID (O)
- Parameter (O) *
TCAP Parameter ICB (M)
- Correlation ID (O)
- Parameter (O) *
- Last Component (M)
0x0E TC-U-ERROR
This component primitive corresponds to the ITU Return Error component. It indicates that the operation failed.
Request Indication
MSP
1108
TCAP Parameter ICB (M)
- Correlation ID (O)
- Error Code (M) *
- Parameter (O) *
TCAP Parameter ICB (M)
- Correlation ID (O)
- Error Code (M) *
- Parameter (O) *
- Last Component (M)
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
TCAP Parameter ICB (M)
- Invoke ID (O)
- Correlation ID (O)
- Operation (M) *
- Parameter (O) *
TCAP Parameter ICB (M)
- Invoke ID (O)
- Correlation ID (O)
- Operation (M) *
- Parameter (O) *
- Last Component (M)
0x11 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
TCAP Parameter ICB (M)
- Invoke ID (M)
- Correlation ID (M)
- Operation (M) *
- Parameter (O) *
TCAP Parameter ICB (M)
- Invoke ID (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.
Developer Information
1109
Request Indication
TCAP Parameter ICB (M)
- Correlation ID (O)
- Problem Code (M)
- Parameter (O) *
TCAP Parameter ICB (M)
- Correlation ID (O)
- 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)
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
MSP
1110
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 Indication
Dialog ID (M)
Invoke ID (M)
Developer Information
1111
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.
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 Indication
SCCP Parameter ICB (M)
- User Data (M)
- Calling Party Address (CGPA) or CGPA Elements (O)
- Called Party Address (CDPA) or CDPA Elements (M)
- Quality of Service (O)
Same as Request.
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)
MSP
1112
N-STATE (0x03)
Request Indication
SCCP Parameter ICB (M)
- Subsystem Number (M)
- Subsystem Status (M)
SCCP Parameter ICB (M)
- Destination Point Code (DPC) (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 )
Request Indication
SCCP Parameter ICB (M)
- Destination Point Code (DPC) (M)
- DPC Status (O)
- Remote SCCP Status (O)
N-COORD (0x05)
Request Indication
SCCP CO Parameters ICB(M)
- Affected Subsystem
SCCP CO Parameters ICB(M)
- Affected Subsystem
- Subsystem Multiplicity Indicator (O)
N-COORD (0x08)
Response Confirm
SCCP CO Parameter ICB(M)
-Affected Subsystem
SCCP CO Parameter ICB(M)
- Affected Subsystem
- Subsystem Multiplicity Indicator (O)
ITU/ANSI SCCP CO Events
N-Connect (0x15)
Request Indication
- SCCP Parameter ICB (M)
- Calling Party address (O)
- Calling Party address (M)
- SCCP Parameter ICB (M)
- Calling Party address (O)
- Calling Party address (M)
Developer Information
1113
- Expedited data selection (O)
- QOS parameter set (M)
- User data (O)
- Connection identification (O)
- Importance (O)
- Expedited data selection (O)
- QOS parameter set (M)
- User data (O)
- Connection identification (O)
- Importance (O)
N-Connect (0x16)
Response Confirmation
- SCCP Parameter ICB (M)
- Responding address (O)
- Expedited data selection (O)
- QOS parameter set (M)
- User data (O)
- Connection identification (O)
- Importance (O)
- SCCP Parameter ICB (M)
- Responding address (O)
- Expedited data selection (O)
- QOS parameter set (M)
- User data (O)
- Connection identification (O)
- Importance (O)
N-Data (0x17)
Request Indication
- SCCP Parameter ICB (M)
- User data (O)
- Connection identification (O)
- Importance (O)
- SCCP Parameter ICB (M)
- User data (O)
- Connection identification (O)
- Importance (O)
N-Disconnect (0x1B)
Request Indication
- Originator
- Responding address (O)
- Reason (M)
- User data (O)
- Connection identification (O)
- Importance (O)
- Originator
- Responding address (O)
- Reason (M)
- User data (O)
- Connection identification (O)
- Importance (O)
MSP
1114
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:
SS7 TCAP Primitive 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 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-CONTINUE Primitive Set
TC-END 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-P-ABORT (Indication only)
TC-NOTICE (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.
Developer Information
1115
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-RESULT-NL 0x0D
TC-U-ERROR 0x0E
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)
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
TCAP Primitive ICB0x65 (M)
- Application Context Name (O)
- 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)*
TCAP Primitive ICB 0x65 (M)
- Application Context Name (O)
- 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)*
0x02 TC-CONTINUE Primitive Set
Request Indication
TCAP Primitive ICB 0x65 (M)
- Application Context Name (O)
TCAP Primitive ICB 0x65 (M)
- Application Context Name (O)
MSP
1116
- 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)*
- User Information (O)
- Component Present (M)
SCCP Parameter ICB (O)
- Quality of Service (O)
TCAP Primitive ICB for a component (none or multiple)*
0x03 TC-END Primitive Set
Request Indication
TCAP Primitive ICB 0x65 (M)
- Application Context Name (O)
- User Information (O)
- Termination Option (M)
SCCP Parameter ICB (O)
- Quality of Service (O)
TCAP Primitive ICB for a component (none or multiple)*
TCAP Primitive ICB 0x65 (M)
- Application Context Name (O)
- User Information (O)
- Component Present (M)
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
TCAP Primitive ICB 0x65 (M)
- No parameters included
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)
- 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)
TCAP Primitive ICB for a component (none or multiple)*
Developer Information
1117
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
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-WITH-PERMISSION Primitive Set
TC-QUERY-WITHOUT-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-P-ABORT (Indication only)
TC-NOTICE (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
MSP
1118
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-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)
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
TCAP Primitive ICB 0x65 (M)
- No parameters included
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)
- 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)
TCAP Primitive ICB for a component (one or more)*
0x07 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.
Developer Information
1119
Request Indication
TCAP Primitive ICB 0x65 (M)
- No parameters included
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)
- 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)
TCAP Primitive ICB for a component (one or more)*
0x08 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.
Request Indication
TCAP Primitive ICB 0x65 (M)
- No parameters included
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)
- 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)
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
TCAP Primitive ICB 0x65 (M)
- No parameters included
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA Elements (O) 1
TCAP Primitive ICB 0x65 (M)
- Component Present (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA Elements (O) 2
MSP
1120
- Called Party Address (CDPA) or CDPA Elements (O)1
- Quality of Service (O)
TCAP Primitive ICB for a component (one or more)*
- 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
TCAP Primitive ICB 0x65 (M)
- No parameters included
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 Primitive ICB for a component (one or more)*
TCAP Primitive ICB 0x65 (M)
- Component Present (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)
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
TCAP Primitive ICB 0x65 (M)
- Termination Option
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
TCAP Primitive ICB 0x65 (M)
- Component Present (M)
SCCP Parameter ICB (O)
- Calling Party Address (CGPA) or CGPA
Developer Information
1121
Elements (O)
- Called Party Address (CDPA) or CDPA Elements (O)
- Quality of Service (O)
TCAP Primitive ICB for a component (one or more)*
Elements (O)
- Called Party Address (CDPA) or CDPA Elements (O)
- Quality of Service (O)
TCAP Primitive ICB for a component (one or more)*
MSP
1122
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:
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.
Developer Information
1123
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 TC-transaction indication primitive followed by several TC-component indication primitives are sent to the TC-USER. The Last Component parameter in the TC-component 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
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
MSP
1124
This section contains information on ITU SCCP and TCAP parameters inserted into the SCCP and TCAP ICBs.
ITU SCCP Parameter IDs
0x66 CGPA (Calling Party Address)
0x67 CGPA (Calling Party Address) Element
0x68 CDPA (Called Party Address)
0x69 CDPA (Called Party Address) Element
0x6A QOS (Quality of Service)
0x6B User Data
0x6C CDPA (Called Party Address) DPC
0x6D Return Reason
0x6E SSN (Subsystem Number)
0x6F SPC (Signaling Point Code)
0x70 SSN (Subsystem Number) Status
0x71 SCCP Signaling Point Code Status
0x72 Remote SCCP Status
0x73 MTP OPC
0x74 MTP DPC
ITU TCAP Parameter IDs
0x0F Abort Reason
0x11 P-Abort Cause
0x1F Invoke ID
0x20 Link ID
0x28 Invoke Class
0x29 Invoke Timeout
0x2A Problem Type Code
0x2E Parameter
0x2C Global Operation Code
Developer Information
1125
0x2D Local Operation Code
0x30 Last Component
0x37 Protocol Version
0x38 Application Context Name
0x39 User Info
0x3A Termination Option
0x43 Dialog_AS_ID
0x44 Unidialog_AS_ID
0x45 Component Present
0x47 Global Error Code
0x48 Local Error Code
0x6D 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)
0x67 CGPA (Calling Party Address) Element
0x68 CDPA (Called Party Address)
0x69 CDPA (Called Party Address) Element
0x6A QOS (Quality of Service)
0x6B User Data
0x6C CDPA (Called Party Address) DPC
0x6D Return Reason
0x6E SSN (Subsystem Number)
0x6F SPC (Signaling Point Code)
0x70 SSN (Subsystem Number) Status
0x71 SPC (Signaling Point Code)
MSP
1126
Status
0x73 MTP OPC
0x74 MTP DPC
ANSI TCAP Parameter IDs
0x0F User Abort Info
0x11P Abort Cause
0x1F Invoke ID
0x20 Correlation ID
0x2A Problem Type Code
0x2C National Operation Code
0x2D Local Operation Code
0x30 Last Component
0x3A Termination Option
0x45 Component Present
0x47 National Error Code
0x48 Private Error Code
0x4A Parameter Sequence
0x4B Parameter Set
0x6D Return Reason
Parameter Format
The following table illustrates the parameter format for parameters inserted into the SCCP and TCAP ICBs.
Byte Field
Data[0] Parameter 1 ID
Data[1]
Developer Information
1127
Data[2] Parameter Length
Data[3]
Data[4+] Parameter-specific Fields
Parameter Data
This section shows the specific data for each parameter.
Abort Reason
Byte Value(s)
Data[4] Reason
0x00 = User-defined
0x01 = Application Context Name Not Supported (ITU Only)
0x02 - Dialog Refused
Calling Party Address (CGPA)
Byte Value(s)
Data[4+] Calling Party Address
Conforms to ANSI or ITU specification.
Calling Party Address (CGPA) Element
Byte Value(s)
Data[4] Routing Indication 0x00 = Route on GT
0x01 = Route on DPC/SSN
Data[5] National/International Flag
0x00 = Coded International
0x01 = Coded National
0x02 = Coded according to China Specification (same as International except the point codes are 24 bits)
Data[6] Subsystem Number
Data[710] Point Code
Data[11] Global Title Indicator
Data[12] Global Title Length Variable
:
Data[N] Global Title
MSP
1128
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.
Called Party Address (CDPA) Element
Byte Value(s)
Data[4] Routing Indication 0x00 = Route on GT
0x01 = Route on DPC/SSN
Data[5] National/International Flag
0x00 = Coded International
0x01 = Coded National
0x02 = Coded according to China Specification (same as International except the point codes are 24 bits)
Data[6] Subsystem Number
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 Value(s)
Developer Information
1129
Data[4] Class Class Number (14)
Component Present
Byte Value(s)
Data[4] 0x00 Not Present
0x01 Present
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 Value(s)
Data[4] Code Global or Local Error Code
Last Component
Byte Value(s)
Data[4] 0x00 Last Component
0x01 Not Last Component
Operation
Byte Value(s)
Data[4] Code
Global or Local Operation Code
MSP
1130
P Abort Cause (ITU)
Byte Value(s)
Data[4] Cause
0x00 = Unrecognized Message Type
0x01 = Unrecognized Transaction ID
0x02 = Badly Formatted Transaction Portion
0x03 = Incorrect Transaction Portion
0x04 = Resource Limitation
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 Value(s)
Data[4] Problem Type 0x01 = General
0x02 = Invoke
0x03 = Return Result
0x04 = Return Error
Data[5] Problem Code General
0x00 = Unrecognized Component
0x01 = Mis-typed Component
0x02 = Badly Structured Component Invoke
Developer Information
1131
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 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 Value(s)
Data[4] Problem Type
0x01=General
0x02=Invoke
0x03=Return Result
0x04=Return Error
0x05=Transaction Portion
Data[5] Problem Code
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
MSP
1132
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
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 Value(s)
Data[4] Return Option 0x00=Discard on Error
0x01=Return on Error
Data[5] Sequence Control Parameter 0x00=Sequence not Guaranteed
For other than zero, this value is used for sequence control.**
Data[6] Message Priority* (ANSI Only)
Developer Information
1133
*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 Value(s)
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 Value(s)
Data[4] Cause 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 Value(s)
Data[4] 0x00 No Translation for an Address of Such Nature
MSP
1134
Cause 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=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 Value(s)
Data[4] Status
0x01=SCCP DPC Prohibited
0x02=SCCP DPC Congested
0x03=SCCP DPC Allowed
Subsystem Status
Byte Value(s)
Data[4] Status
0x00=Prohibit
0x01=Allow
Termination Option
Developer Information
1135
Byte Value(s)
Data[4] Option 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.
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
0x7B Originator
0x7C Reason
0x7E Subsystem Multiplicity Indictor
ITU and ANSI SCCP CO Parameter Data
Importance
Byte Value(s)
Data[4] Importance
As defined by ITU Q.711-714, 1996
Originator
Byte Value(s)
Data[4] Originator
0x00 Undefined
0x01 Network service user originated
0x02 Network service provider originated
MSP
1136
Reason
Byte Value(s)
Data[4] Reason
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
Byte Value(s)
Data[4] Mutiplicity Indicator
0x00 Affected subsystem multiplicity unknown
0x01 Affected subsystem is solitary
0x02 Affected subsystem is duplicated
User-Defined Parameters
Application Context Name
MTP DPC
Correlation ID
Invoke ID
Linked ID
Parameters
Parameter Sequence
Parameter Set
Signaling Point Code (SPC)
Subsystem Number
Timeout
User Data
User Information
Developer Information
1137
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 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
MSP
1138
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 section, and include the following:
SCCP Component SCLC--Bytes 22 and 26 (a 4-byte value)
SCCP Component SUSI--Byte 20
TCAP Component CCO--Bytes 1 and 2
TCAP Component TUSI--Bytes 4 and 5
Limitations
SS7 Segmentation allows a maximum number of 300 reassembly processes simultaneously.
Redundancy
SCCP software is redundant.
Developer Information
1139
TCAP Parameter IDs
TCAP Parameter IDs for TCAP OSD
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.
TCAP Parameter IDs for TCAP OSD
0x00 Reserved
0x01 TCAP Package/message/" internal use "/
0x02 TCAP Unidirectional message
0x03 TCAP Begin message
0x04 TCAP Continue message
0x05 TCAP End message
0x06 TCAP Query with permission package
0x07 TCAP Query without permission package
0x08 TCAP Conversation with permission package
0x09 TCAP Conversation without permission package
0x0A TCAP Response package
0x0B TCAP Abort package
0x0C TCAP Transaction ID (ANSI)
0x0D TCAP Originating transaction ID(ITU)
0x0E TCAP Destination transaction ID(ITU)
0x0F TCAP Abort reason(ITU) / TCAP user abort info(ANSI)
0x10 TCAP Abort cause(ANSI) /" internal use "/
0x11 TCAP P abort cause
0x12 Not used
0x13 TCAP Component portion
0x14 TCAP Component /" internal use "/
0x15 TCAP INVOKE Component
0x16 TCAP INVOKE Last component
0x17 TCAP INVOKE Not Last component
0x18 TCAP RESULT Last component
0x19 TCAP RESULT Not Last component
0x1A TCAP RETURN ERROR Component
MSP
1140
0x1B TCAP REJECT Component
0x1C TCAP Component ID(ANSI)
0x1D Not used
0x1E TCAP Component type /" internal use "/
0x1F TCAP Invoke ID
0x20 TCAP Link ID(ITU) / correlation ID(ANSI)
0x21 TCAP REJECT Invoke ID /" internal use "/
0x22 TCAP Problem /" internal use "/
0x23 TCAP Problem type /" internal use "/
0x24 TCAP General problem
0x25 TCAP Invoke problem
0x26 TCAP Return result problem
0x27 TCAP Return error problem
0x28 TCAP Invoke class /" internal use "/
0x29 TCAP Invoke timeout /" internal use "/
0x2A TCAP Problem type-code(ANSI)
0x2B TCAP Operation code /" internal use "/
0x2C TCAP Global/National operation code
0x2D TCAP Local/Private operation code
0x2E TCAP Parameter (ITU)
0x2F TCAP Result in return result component (ITU)
0x30 TCAP Last component /" internal use "/
0x31 TCAP dialog Portion
0x32 TCAP dialog PDU /" internal use "/
0x33 TCAP AARQ apdu
0x34 TCAP AARE apdu
0x35 TCAP ABRT apdu
0x36 TCAP AUDT apdu
0x37 TCAP Protocol version
0x38 TCAP AC-name
0x39 TCAP USER INFO
0x3A TCAP Termination option /" internal use "/
Developer Information
1141
0x3B TCAP Package/Message type /" internal use "/
0x3C TCAP APDU type /" internal use "/
0x3D TCAP Abort source
0x3E TCAP dialog portion result
0x3F TCAP Result source diagnostic
0x40 TCAP dialog service user diagnostic
0x41 TCAP dialog service provider diagnostic
0x42 TCAP What as ID (structure/unstructured dialog) /" internal use "/
0x43 TCAP dialog-as-ID, structure dialog /" internal use "/
0x44 TCAP Unidialog-as-ID, unstructured dialog /" internal use "/
0x45 TCAP Component present /" internal use "/
0x46 TCAP Error code /" internal use "/
0x47 TCAP Global/National error code
0x48 TCAP Local/Private error code
0x49 TCAP dialog ID /" internal use "/
0x4A TCAP Parameter seq (ANSI)
0x4B TCAP Parameter set (ANSI)
0x4C TCAP Error package /" internal use "/
0x4D TCAP Error component /" internal use "/
0x4E TCAP ISM ID /" internal use "/
0x4F TCAP Associate source diagnostic /" internal use "/
0x50 TCAP What diagnostic (User provider or user diagnostic /" internal use "/
0x6D Return Reason
0x55 TCAP Security context parameter
0x58 TCAP Confidentiality parameter
MSP
1142
SCCP Parameter IDs
SCCP Parameter IDs
SCCP Parameter IDs for TCAP OSD
0x65 SCCP Parameter Set
0x66 SCCP Calling Party Address
0x67 SCCP Calling Party Address Element
0x68 SCCP Called Party Address
0x69 SCCP Called Party Address Element
0x6A SCCP Quality of Service
0x6B SCCP SCCP User Data
0x6C SCCP Called Party Address DPC
0x6D SCCP SCCP Return Reason
0x6E SCCP SCCP Subsystem Number
0x6F SCCP Signaling Point Code
0x70 SCCP Subsystem Status
0x71 SCCP Signaling Point Status
0x72 SCCP Remote SCCP Status
0x73 MTP OPC from routing table
0x74 MTP OPC from routing table
0x75 SCCP message (Internal Use)
0xFF Reserved (Internal Use)
Developer Information
1143
SCCP Connection Oriented Network Services
Overview
The Signaling Connection Control Part (SCCP) Connection Oriented (CO) Network Services protocol provides for sending and receiving SCCP Class II messages between originating and terminating MSP 1010s through a specific, fixed logical network path.
This feature enables SCCPs residing at different MSP 1010s throughout the network, using connection oriented messages, to do the following:
Establish connections with other MSPs
Transfer data over these connections
Release the connections after data transfer
The host controls the establishment of a connection, the two-way message transfer between the originating and terminating MSPs, and the release of the connection after the transfer.
The SCCP provides this service to the SCCP user using the primitives as defined in ITU-T Q.711 and ANSI T1.112.
API Messages, PPL Components and ICB
To support the above functionality the following API messages and PPL components and ICB are used.
API Messages
PPL Event Indication (0x0043)
PPL Event Request (0x0044)
SCCP/TCAP Configure (0x0077)
SCCP/TCAP Query (0x0078)
PPL Components and Primitives
SCCP User Interface (SUSI 0x0067)
SCCP Connection Oriented Control (SCOC 0x007D)
SCCP Restart Control (SRTC 0x007E)
SCCP Coordinated State Change Control (CSCC 0x007F)
ICB
SS7 SCCP CO Parameters (0x42)
This ICB is used with the PPL Event Indication (0x0043) and PPL Event Request (0x0044) messages.
SCCP User Interface (SUSI 0x67)
MSP
1144
This PPL component provides the following connection-oriented primitives from the host/SUSI. This component is responsible for setting up a connection depending upon the parameters in the N_CONNECT Request/Indication primitive. Once a connection is established, the N_DATA Request/Indication primitive is used to transfer the data to the connected node. The connection is released using the N_DISCONNECT Request primitive.
Primitives
N_CONNECT Request/Indication (0x15)
N_CONNECT Response/Confirmation (0x16)
N_DATA Request/Indication (0x17)
N_DISCONNECT Request/Indication (0x1B)
SCCP Connection Oriented Control (SCOC 0x7D)
This PPL component provides the following PPL timers
PPL Timers
0x01 - Connection Establishment - 60 secs. T (conn est)
0x02 - Inactivity Send - 5 mins. T (ias)
0x03 - Inactivity Receive - 11 mins. T (iar)
0x04 - Release - 10 secs. T (rel)
0x05 - Repeat Release - 10 secs. T (repeat rel)
0x06 - Interval - 60 secs. T (int)
0x07 - Reset - 10 secs. T (reset)
0x08 - Guard - 23 mins. T (guard)
0x09 - Incoming Connection Establishment - 3 mins. T (incoming conn est)
SCCP Restart Control (SRTC 0x7E)
This PPL component provides SCCP restart functionality.
Coordinated State Change Control (CSCC 0x7F)
The CSCC component is responsible for handling the N_COORD primitive from the host/SUSI. It supports state change requests for duplicated subsystems. These requests are sent as SCCP Management (SCMG) messages to the SCCP Connectionless Control (SCLC), which is sent as a Unit Data message to the designated SCCP.
Primitives
N_COORD Request/Indication (0x05)
Developer Information
1145
N_COORD Response/Confirmation (0x08)
PPL Timers
0x01 - Tcoord Change - 1.5 mins.
0x02 - Tignore SST - 2 mins.
Connection Oriented Services
The SCCP user communicates to SCCP User Interface (SUSI) using the PPL Event Request and PPL Event Indication messages. The SUSI converts the PPL Event Requests into the appropriate SCCP primitives and sends them to the SCCP Connection Oriented Control (SCOC) and Coordinated State Change Control (CSCC) PPL components. The SCCP Restart Control (SRTC) PPL component has no interaction with the SUSI.
This feature consists of the following three phases.
Connection Establishment
During this phase, the SCCP sets up the logical, fixed path the data packets will follow. This path may involve two or more intermediate (STPs) that exist between the origination and/or termination SCCP node.
Data Transfer
After the connection is established, the data to be transferred is converted into a Unit Data (UDT) message. Message segmenting occurs whenever a given message exceeds the maximum allowed SCCP message length. This oversized message will be broken into a maximum of 16 separate segments by the originating MSP 1010. The the UDT message segments are then sent to their destination following the previously established path.
After receipt of all segments, the SCCP of the terminating node reassembles the segments into the original message before sending it to the required user application. Each Unit Data (UDT) message is uniquely identified as belonging to a specific signaling connection. In this way, it is possible for the SCCP to handle independent signaling connections simultaneously.
Connection Release
After all the Unit Data (UDT) messages are transmitted and confirmed, the logical path is released by either or both of the User Applications that initiated the process. A release may also occur if the connections fails. These connection-oriented services may be on a temporary (per process basis), or permanently setup between two User Applications. The type of connection established for a given message may be determined by the value found in the protocol class field of the message.
MSP
1146
Developer Information
1147
SCCP Connection Oriented Call Flows
Overview
The following SCCP Connection Oriented (CO) Network Services call flows provide examples for sending and receiving SCCP Class II messages between originating and terminating SCCP users.
Connection Setup by SCCP User
Connection Refusal from Destination SCCP User
Data Transfer by SCCP User
MSP
1148
Connection Release by SCCP User
Coordinated State Change Control
Developer Information
1149
TCAP Dialog Synchronization
Introduction to TCAP Dialog Synchronization
Overview
Prior to this feature, three components maintained the TCAP dialog ID and status:
Application
Low-Level Communicator (LLC)
TCAP
Synchronizing the dialogs was a potential problem. With this feature, the LLC and Application update TCAP with the application instance information. TCAP maintains the application instance status and routes the messages based on it.
Once TCAP decides the appropriate application instance, TCAP includes the instance information in the message. The LLC then sends the messages to the application instance based on the information in the message.
Load Sharing
This TCAP application instance based routing allows the multiple TCAP application instances on the host to load share the TCAP traffic. TCAP routes the TCAP messages to the appropriate TCAP application instances based on the host configured application instance status.
MSP
1150
Application ID Based Routing
There can be multiple TCAP application IDs corresponding to a TCAP application (TCAP application is identified by stack/SSN).
There can also be multiple stack/SSNs corresponding to an application ID. For TCAP-to-host message routing point of view, a stack/SSN/ApplicationID "triplet" uniquely identifies a routing destination on the host.
TCAP maintains the stack/SSN/Application ID status and routes the messages based on this status. The stack ID, SSN, and Application ID are carried in each TCAP-to-host message. The LLC and Application instances can further route the messages based on these IDs.
TCAP updates the Stack/SSN/Application ID status based on the application ID and SSN status host messages sent by the LLC. The application ID is carried in the dialog ID within each TCAP-to-TC user primitive.
You can configure this feature to be enabled or disabled.
The diagram below shows this feature in a SwitchKit environment. Environments that do not include SwitchKit do not have LCC and the data flows directly from SS7 to the TCAP Application Instance.
Registering and De-Registering Applications
The following summarizes information about registering and de-registering applications.
Developer Information
1151
When there are applications registered but none of them are available in accepting mode, the MSP rejects new begins messages from the network by sending an abort message to the network.
When there are no applications registered, the MSP sends messages to the default application ID 0.
When the last TCAP application instance for a particular SSN requests a de-register, the LLC sends a PPL Event Request of SSN OOS and then the NGA message to deregister the triplet.
Only after the last TCAP Application de-registers can the SSN be taken out of service.
If an SSN TCAP restart is in progress, the NACK value is change from 0x540A to 0x5411 for that case.
Related Topic
TCAP Dialog Synchronication
MSP
1152
API Messages
Use the following API messages to maintain TCAP Dialog Synchronization.
Message Purpose in this feature
Application Manager Configure (0x0130)
Add or delete stack/SSN/App ID association.
App Manager State Configure (0x0160)
Bring stack/SSN/App ID in or out of service.
App Manager Signaling Request (0x012A)
Abort active dialogs for stack/SSN/App ID
App Manager Info Query (0x0140)
Query stack/SSN/App ID association information including configuration and status
App Manager Signaling Query (0x012C)
Query associated dialogs for a stack/SSN/App ID.
App Manager State Query (0x0161)
Query stack/SSN/App ID status
App Manager Query (0x0131)
Query configured stack/SSN/App ID information.
Developer Information
1153
Stack/SSN/Application ID State Transitions
When TCAP receives an Application ID service state change (in-service, out-of-service) or congestion level change, it will update the Application ID service state and congestion level in the Application ID table. It will also inform all of the Stack/SSN/AppID state machines related to this Application ID.
When TCAP receives a local sub-system service (SSN) state change (in-service or out-of-service), it will update the Local SSN table as in current implementation. It will also inform all the Stack/SSN/AppID state machine related to this Stack/SSN.
Not Registered State
The next diagram shows a TCAP view of a state transition for a Stack/SSN/applicationID state machine that is in a Not Registered state.
To add Stack/SSN association, see Add a Stack/SSN/AppID.
Not Processing New Traffic State
The next diagram shows a TCAP view of a state transition for a Stack/SSN/applicationID state machine that is in a Not Processing New Traffic state.
MSP
1154
To Remove an entry from the Stack/SSN/AppID table, see Remove a Stack/SSN/AppID.
To bring a Stack/SSN/AppID in-service or take it out-of-service, see Local SSN In-Service and Out-Of-Service.
See also, Application Instance Failure and Recovery, Backward Compatibility.
Processing Traffic State
The next diagram shows a TCAP view of a state transition for a Stack/SSN/applicationID state machine that is in a Processing Traffic state.
Developer Information
1155
To Remove an entry from the Stack/SSN/AppID table, see Remove a Stack/SSN/AppID.
Related Topic
TCAP Dialog Synchronization
MSP
1156
TCAP traffic message processing
TCAP Application ID-based routing is based on the maintained Stack/SSN/ApplicationID status.
Normal AppID-based message routing scenarios
When a host application instance initiates a new dialog, it should include its Application ID in the dialog ID. TCAP stores this AppID-DID in its dialog table.
When there is a new network-initiated dialog, TCAP is responsible for allocating a dialog ID for it and store this dialog ID in the dialog table. TCAP will allocate the dialog ID based on the following,
Application ID Selection
TCAP will load share among all the Stack/SSN/AppIDs for the Stack/SSN that are in “Processing Traffic” state. When there is no Stack/SSN/AppID in congestion, the round robin load sharing algorithm will be used to load share the traffic among all available application instances.
dialog ID Selection
You can select an available dialog ID from the 3-byte dialog ID space for the selected application ID.
For a TCAP message from the network for an existing dialog, TCAP will send the message with AppID-DID.
For a TCAP message from the host for an existing dialog, or a TCAP Unidirectional request from the host, TCAP simply processes the message as usual, with no change.
For a Unidirectional message without a transaction ID coming from network, TCAP will allocate it a dialog ID.
Abnormal message routing scenarios
In general, when TCAP routing function can not find a valid TCAP application instance to route to by following the normal scenarios, TCAP will initiate a dialog abort for this dialog. There are two situations when this could be involved:
There is no application instance available to route to for a new dialog.
The application instance for an existing dialog is not available any more.
In this case, TCAP will send a U_ABORT message to the network when necessary. A U_ABORT indication is also sent.
Message routing scenarios – Application ID 0
When the TCAP Application ID based routing is disabled by the configuration, a TCAP message routing will be based on Application ID 0. In other words, Application ID 0 will be only AppID for a configured Stack/SSN. And the AppID 0 status will determine the TCAP message routing.
Developer Information
1157
If the AppID 0 state is in the “Processing Traffic”, then TCAP messages destined to this Stack/SSN will be routed to that AppID 0. AppID value 0 will be included in the dialog ID.
If the AppID 0 for a Stack/SSN is “Not Registered” or “Not Processing New Traffic”, then a TCAP Abort procedure will apply.
Related Topic
TCAP Dialog Synchronization
MSP
1158
SCCP N- Primitive Routing
For SCCP management N- primitive indications, such as N_STATE, N_PCSTATE indications, will be broadcasted to all registered TCAP application instances for the stack/SSN.
Related Topic
TCAP Dialog Synchronication
Developer Information
1159
Message Routing under TCAP Overload Condition
On switch resources (CPU, memory, MCB)reaching limitations, the TCAP overload logic will apply. When TCAP application instance routing reaches an overload condition, TCAP will start throttling back some dialogues, whether they are host-initiated or network-initiated.
For new network-initiated TCAP dialogues, the TCAP overload logic only allows partial new dialog messages to be routed to the application instances. These reduced new dialog messages will be distributed among the available application instances.
For new host-initiated new dialogues, the TCAP overload logic will also reject the new TCAP dialog requests on a even basis from all active application instances.
Related Topic
TCAP Dialog Synchronization
MSP
1160
Application ID-related Abort
A new message to abort all TCAP dialogues for an application ID. should include:
Application ID,
A new message to abort all TCAP dialogues for a Stack/SSN/AppID. should include:
Stack_ID, SSN, Application ID,
Related Topic
TCAP Dialog Synchronization
Developer Information
1161
Host Link Failure and Recovery
When an SS7 host link failure (HLF) occurs, no traffic is routed to the host application instances. The local sub-system out-of-service (OOS) and TCAP Restart logic may apply depending on the configuration. When a sub-system becomes OOS, the relevant Stack/SSN/AppIDs state will become “Not processing traffic”.
With a host link failure condition recovery, the host brings the SSN in-service. Therefore if an AppID status was in-service, the Stack/SSN/AppID status changes to “Processing Traffic”. TCAP will resume routing messages to the available application instances based on the applications instances status before the host link failure.
Related Topic
TCAP Dialog Synchronization
MSP
1162
Local SSN In-Service and Out-Of-Service
When the host brings a local SSN in-service or takes it out-of-service, all the Stack/SSN/AppIDs for this SSN will be informed. The API message used to perform this is App Manager State Configure (0x0160).
Only after the last TCAP Application de-registers can the SSN be taken out of service.
If the SSN INS request results with both SSN and AppID being in-service, and the Stack/SSN/AppID was in “Not Processing New Traffic” state, the state will change to “Processing Traffic”.
If the SSN OOS is received and the Stack/SSN/AppID was in a “Processing Traffic” state, the state will change to “Not Processing New Traffic”.
Note: By default Local SSNs are out service. The host has to bring Local SSNs in service. This way you prevent the MSP from getting flooded with TCAP dialogs as soon as it is deployed on the network.
The dialogs are not be flushed out when SSN, is taken out of service. The only time dialogs are flushed out is when the last application de-registers.
Related Topic
TCAP Dialog Synchronization
Developer Information
1163
Backward Compatibility
Application ID 0 is reserved for backward compatibility purposes.
At the initialization stage, when the host configures a local sub-system, TCAP will set the default application instance ID 0 for routing purpose. When you bring the local SSN in-service, the default Application instance ID 0 will be changed to the Processing Traffic state. The application ID 0 will remain in the Processing Traffic state as long as the sub-system is in-service. It will be taken out-of-service when the local sub-system is taken out-of-service.
The next diagram shows the Application ID 0 state transition for a Stack/SSN.
Related Topic
TCAP Dialog Synchronization
MSP
1164
DSP Information
Developer Information
1165
Overview
DSP Media Module
Introduction
Excel’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 easy-to-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.
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 8 NFS servers.
Stream Capability
The DSP Media module comes with six DSP chips. The main board also supports two DSP chips for a maximum of eight DSP chips.
Each DSP supports four one-way (simplex) paths: two transmit and two receive. Each path is called a "stream." You assign function types on a per stream basis (up to four per DSP). Each stream can support a maximum of 256 channels depending on the licensing and function type.
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.
Related Topics
Features
Resource Points
MSP
1166
Architecture Overview
Hardware
Developer Information
1167
DSP Media Module Features
Introduction
The DSP Media module offers a comprehensive set of features to support media processing and management for MSP-based solutions. Highlights include:
Announcement Processing
The system supports NFS based announcements, with on-board cache for voice file storage. Multiple NFS servers can be supported; the system manages the location of files through an ASCII file.
Dynamic Voice Recording and Playback
The DSP Media module supports on-board temporary recording storage as well as external disk-based long term storage.
High Density Tone Receivers
Depending on the receiver type, the system supports up to 366 tone receivers per DSP.
Large Conferencing Capability
The system supports up to 256 conferees per DSP, and 128 conferees per conference bridge.
The user can adjust gain and speed, and skip forward and backward. The DSP Media module supports configurable beep tones, configurable silence parameters, and two-way call recording without using conference ports.
Echo Cancellation
The DSP Media module Echo Canceller removes echoes caused by signal leakage at hybrid telephone line interfaces. You may want to implement an Echo Canceller for tandem calls on trunks with echo, or to clean an incoming signal before connecting to a media resource, such as a Voice Response Unit or Answering Machine Detection.
Positive 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.
Media Streaming over RTP
RTP, the real-time transport protocol, provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address
MSP
1168
resource reservation and does not guarantee quality-of- service for real-time services.
Developer Information
1169
DSP Resource Points
The DSP Media module uses a pooling scheme for dynamically allocating resources through Resource Points. Resource Point licensing provides the DSP Media module with flexibility, scalability, and redundancy. Each function type has associated licensing per channel, measured in Resource Points. The total available Resource Points used for Tone Reception, conferencing, and File Playback/Record are managed as a resource pool.
Standard 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.
Resource Points Model Numbers
Model Number Description
SLM-DSP-0001 One module with 2,048 default Resource Points
SLM-LDP-1000 An additional 1,024 Resource Points
Benefits
Flexibility
Resource Points are allocated only when they are used. This results in better utilization of resources and improved performance.
Scalability
Licensing DSP resources through Resource Points, you can buy only as much functionality and capacity as you need, and upgrade incrementally as your needs increase.
Resource Point Checking
When a DSP function is requested, the CPU checks that there are enough total Resource Points available to provide the function and that a DSP chip with sufficient channels is available for that function type. If there are no more Resource Points available, or if an appropriate DSP chip is not available, the CPU returns a NACK.
DSP Streams
MSP
1170
The concept of DSP streams is integral to DSP licensing on the DSP Media module. Each DSP chip on the DSP Media module supports four one-way (simplex) paths: two for transmitting and two for receiving. Each of these paths is called a DSP stream.
Based on these four streams, each DSP chip can be assigned up to four function types. Each stream can support a maximum of 256 channels, depending on available licensed resources and on the function type assigned. Note that Conferencing and File Playback/Record requires two streams (one for transmit and one for receive).
Resource Points on Module Failure
If a DSP Media module fails, the standard Resource Points are removed from the resource pool. However, all Resource Points purchased through additional licenses remain available in the pool.
Developer Information
1171
Determining your DSP Resource Point Needs
Introduction
Use the following steps to determine how may Resource Points you need to license, based on your resource and hardware needs.
1. Determine how many resources you need
2. Determine how much hardware you need
3. Determine how many Resource Points you need
Determine how many DSP Resources you Need
How many resources for each of the following do you want to use:
Tone receivers
Tone transmitters
Conferences
File Playback/Record
Fax
Echo Canceling
Typically, you determine the amount of resources you need by calculating the Busy Hour Call Attempts (BHCA) and percentage of each call that a particular resource type is used.
Because Resource Points are pooled and dynamically allocated, the DSP Media module provides a new flexibility in distributing resources at any given moment.
Resource Points may be used for any configured function type, and are removed from the pool for only the length of time that the given function type is in use.
Your hardware may have more bandwidth available than you calculated for per stream, for each function type. So the actual allocation of functions is dictated by demand from the host application. Cantata recommends that you license enough resources for the highest likely demand.
To help you determine how many resources you need, Excel has added statistics functionality to the system software. You can receive statistics on many aspects of DSP resource usage and allocation, including the following:
Fixed memory for all individual DSP chips (total blocks used, average blocks used, and maximum blocks used)
Cache for all individual DSP chips (accesses, misses, hits, and average free blocks)
DSP Functions for individual DSP chips (total requests for a function, average and minimum free channels)
MSP
1172
NFS statistics on all individual DSP chips, including NFS for all individual DSP chips (total number and size of NFS reads, writes, and records) as well as read and write time delays (minimum, maximum, and average)
Determine how Much Hardware you Need
When you have determined how many resources of each type that you need, you must determine the number of modules you need to supply the above resources, by doing the following:
1. Determine the total number of streams you need by dividing the number of resources you need by the maximum number of channels per stream, then rounding up.
2. Determine the number of DSP chips required by dividing the total number of streams by two. You must perform separate calculations for functions that require two streams (File Playback/Record and Conferencing) and functions that require only one stream (transmit or receive).
3. Determine the number of modules needed by dividing the number of chips by four.
Other Hardware Considerations
Other things you must consider when determining the amount of hardware you need:
Conferencing must reside on its own DSP chip (no other functions are allowed on a DSP chip with the Conferencing function type)
File Playback/Record must reside on its own DSP chip (no other functions are allowed on a DSP chip with File Playback/Record function type)
Determine how many Resource Points you Need to Purchase
To determine the Resource Points per channel required for each function, refer to the DSP Resource Specifications table. For example, if you want the maximum MFR1 receivers for a stream, you would need to license 256 x 5 Resource Points (1,280).
When you know the total Resource Points you need, subtract the Resource Points that come with the card. You are then left with the number of Resource Points that you need to license.
The Resource Points and maximum channels per DSP stream are shown in DSP Resource Specifications table (each module with four DSP chips, each DSP chip with four streams).
Developer Information
1173
Architecture Overview
In keeping with Excel’s commitment to open, programmable services, the DSP Media module delivers the following key architectural advantages:
Modular Design
Scalability
High Performance and Reliability
Modular Design
The DSP Media module supports an on-board Ethernet switch, with eight internal and three external ports. External ports can be aggregated supporting up to three 100 mbps streams.
The system supports one module per board (that is, the motherboard). The on-board module includes two DSPs. In the event the DSP requirements exceed two chips, you can add a DSP Media module with six additional DSPs.
The product is supported by a variety of message and query statistics, including cache statistics and function usage statistics, so that developers and service providers can monitor their services and optimize their DSP configurations.
Scalability
The DSP Media module is offered in a six chip configuration. Note that the main board also provides two DSP chips. 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.
Excel offers a configuration tool for developers and service providers to analyze your specific operating environments in order to configure the appropriate amount of resources.
High Performance and Reliability
The DSP Media module is supported by a pooling scheme for dynamic resource allocation. Resource points are allocated only when they are used. This provides flexibility in the way that resources are allocated at any given point in time, and results in better utilization of resources and improved performance.
To achieve high reliability, the DSP Media module supports module-level hardware redundancy coupled with dynamic resource allocation. If the DSP Media module fails, the system CPU will remove the resource points that are included in the base modules from the resource pool, but will reallocate licensed capacities to the remaining in-service hardware in order to preserve the maximum resources possible.
MSP
1174
Every port in the MSP platform has direct access to every DSP resource (except for channels in Gateway Mode. See the Developer’s Guide: IP for more information on Gateway Mode). A bi-directional PCM bus allows simultaneous incoming and outgoing operations, such as tone reception and tone generation.
Developer Information
1175
Hardware for DSP Modules and DSP Chips
The DSP Media module comes with six DSP chips. The main board also supports two DSP chips for a maximum of eight DSP chips.
DSP Media Module
MSP
1176
DSP Resource Specifications
The table below shows the number of DSP resources available per DSP chip, channels per stream, and resource points used for each function on the DSP Media module.
DSP Resource Specifications
Number Function Resources
(assuming sufficient Resource Points)
Maximum Channels per DSP Stream
Resource Points Used per Channel
Tone Reception
0x35 Universal µ-law 183 5
0x36 Universal A-law 183 5
Tone Generation*
0x30 Universal µ-law 256 0
0x31 Universal A-law 256 0
Conferencing
0x21 Monitor 256 Resources (128 + broadcast per conference)
128 8
0x22 Unified 256 Resources (128 + broadcast per conference)
128 8
0x23 DTMF Clamped 256 Resources (128 + broadcast per conference)
128 8
File Record/Playback (requires 2 streams)
0x1D File Record/Playback
128** 64 12
Miscellaneous
0x32 T.30 FAX 12 6 12
0x33 Echo Cancellation
64 32 12
Developer Information
1177
0x34 Positive Voice Detection/ Answering Machine Detection
384 192 5
MSP
1178
Default DSP Function Type Configuration
Module Number
DSP Number
Rcv 0 Txmt 0 Rcv 1 Txmt 1
0 0 DTMF µ-law (0x01)
Universal µ-law (0x30)
DTMF µ-law (0x01)
Universal µ-law
(0x30)
0 1 DTMF µ-law (0x01)
Universal µ-law (0x30)
DTMF µ-law (0x01)
Universal µ-law (0x30)
0 2 CPA µ-law (0x08)
Universal µ-law (0x30)
CPA µ-law (0x08)
Universal µ-law (0x30)
0 3 File Record/Playback (0x1D)
Not allowed (0x00)
File Record/Playback (0x1D)
Not allowed (0x00)
1 0 DTMF µ-law (0x01)
Universal µ-law (0x30)
DTMF µ-law (0x01)
Universal µ-law (0x30)
1 1 DTMF µ-law (0x01)
Universal µ-law (0x30)
DTMF µ-law (0x01)
Universal µ-law (0x30)
1 2 MFR1 µ-law (0x02)
Universal µ-law (0x30)
MFR1 µ-law (0x02)
Universal µ-law (0x30)
1 3 MFR1 µ-law (0x02)
Universal µ-law (0x30)
MFR1 µ-law (0x02)
Universal µ-law (0x30)
Developer Information
1179
DSP Redundancy
To achieve high reliability, DSP Media modules support module-level hardware redundancy coupled with dynamic resource allocation.
The DSP Media module offers redundancy in several forms, on several levels:
DSP resources are pooled, so you can have extra licensed Resource Points available for backup.
You can store voice files on remote Network File System servers, so the files are not lost if a card fails.
You can distribute functions types across two or more cards.
You can use redundant servers with RAID to mirror the content among multiple drives on a server.
Redundancy Through Pooling
The DSP resources on the DSP Media module are pooled. That is, all resources licensed through Resource Points are available to the entire system and are shared over both DSP Media modules. The 2048 DSP Resource Points that come with a DSP Media module are also pooled. However, if a DSP Media module fails, its default Resource Points are subtracted from the pool. The resources attached to a call must be reconfigured by the host application to another DSP Media module.
Because licensed Resource Points are made available to other DSP Media modules in other MSP platforms, having a surplus of available licensed Resource Points provides another method of redundancy.
Redundancy through Distributed Function Types
Cantata recommends that you assign the same functions across two or more DSP chips, so that if one chip fails, the function is still available on another chip.
Redundancy through Network File System servers
If a DSP Media module fails, the voice files stored on it are lost from volatile memory. But you can restore those files from a Network File System server. For redundancy and bandwidth considerations, Cantata recommends using a machine for NFS that is separate from your application host computer.
Redundancy through Multiple Network Files Servers
The media subsystem supports multiple NFS servers. This capability enables redundancy in two different places. Load sharing exists between the servers.
Redundancy Between Server Drives
Each server must be configured to provide internal redundancy on each server. This allows data to be mirrored among multiple drives using RAID 5.
MSP
1180
Developer Information
1181
Administration and Statistics Monitoring
Use the Statistics Query 0x0121 message to retrieve the following information:
Network File System (NFS) statistics per DSP Media module, including total number and size of NFS reads, writes, and records, as well as read and write time delays (minimum, maximum, and average)
Function statistics on individual DSP chips, including total requests for a function, average free channels, and minimum free channels
Cache statistics on all individual DSP chips, including accesses, misses, hits, and average free blocks
Fixed memory statistics on all individual DSP chips, including total, average, and maximum blocks used.
MSP
1182
Media Streaming over RTP
RTP, the real-time transport protocol, provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.
The DSP Media module supports the direct termination of G.711 u-law RTP streams (payload size: 20 milliseconds) from any third party media server or speech server, required for Automatic Speech Recognition (ASR), Text To Speech (TTS), or any CTI applications using voice recognition.
Configuration
See Media Streaming over RTP.
Definitions
The following definitions are taken from RFC 1889, RTP: A Transport Protocol for Real-Time Applications.
RTP Payload
The data transported by RTP in a packet, for example audio samples or compressed video data.
RTP Packet
Developer Information
1183
A data packet consisting of the fixed RTP header, a possibly empty list of contributing sources, and the payload data. Some underlying protocols may require an encapsulation of the RTP packet to be defined. Typically one packet of the underlying protocol contains a single RTP packet, but several RTP packets may be contained if permitted by the encapsulation method.
Port
The abstraction that transport protocols use to distinguish among multiple destinations within a given host computer. TCP/IP protocols identify ports using small positive integers. RTP depends upon the lower-layer protocol to provide some mechanism such as ports to multiplex the RTP and RTCP packets of a session.
Transport Address
The combination of a network address and port that identifies a transport-level endpoint, for example an IP address and a UDP port. Packets are transmitted from a source transport address to a destination transport address.
RTP session
The association among a set of participants communicating with RTP. For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP).
MSP
1184
File Record & Playback
File, Record and Payback Overview
The DSP Media module has the following File Record/Playback functionality:
Large Vocabulary/Disk Based Files
Permanent File Recording (stored on an NFS server)
Temporary Recording (stored on the on-board DSP module and/or the DSP Media module)
Configurable Beep Tone (notifies parties that they can begin recording their voice)
Gain/Speed Modification
Skip Forward/Backward (in 100 ms increments)
Silence Threshold Modification
Conference Recording
Pause and Resume
Dual channel recording
Moving temporary recordings from the DSP Media module’s cache into permanent storage on a server
Supported Encoding Formats
See Encoding Formats for more information.
Configuration
See Recording Files and Playing a File.
Developer Information
1185
File Storage
Introduction
Recorded voice files are stored remotely on one or more separate Network File System servers and in volatile memory. The DSP Media module can store up to three hours of files in a local cache. This cache holds files to be played as well as temporary recordings. Files are stored in cache blocks of one second, longer messages link multiple blocks together.
The File Record/Playback function supports the playing of pre-recorded voice files referenced by a universal, 32-bit file ID. Although it is not necessary to use a unique file ID for each file, having a unique ID allows you to track the status of individual files in alarms and status messages.
Vocabulary Index File
MSP
1186
You can use an ASCII Vocabulary Index File (VIF) to track File IDs below 0x00100000 (4,096) required for chaining. You can modify the VIF using any ASCII text editor. Make sure that the File IDs you use for temporary, internal recordings are always different from the File IDs you use for Playback Files. Consider designating one range for the first type and another range for the second type.
Each line of the file corresponds to a valid File ID that can be played. The information elements on each line must be separated by white space, and each line must end in a carriage return and a line feed.
When the VIF is updated, all caches are cleared.
See VIF Format.
Vocabulary Index File (VIF) Bypass (Preferred Method)
You can indicate a cached file’s location, format, and encoding type in the Play File Start message (0x011B) instead of using the VIF.
NFS File Failure
If an NFS file fails and is not covered by redundancy, the MSP 1010 retries the file a number of times (you can configure this number). If the file fails to play after the configured number of retries, the file is designated as "bad" and there will be no more attempts to play the file. This way, other files from other servers are not delayed.
Permanent Recordings
You should use higher File IDs for longer files and for files you want to keep for a significant period. File IDs of 0x00100000 or higher are not stored on the card. They are stored on a separate NFS server, accessed through the MSP I/O. These files are not stored in cache, but as they are being played, they temporarily use a small amount of cache, so you should consider this when designing your cache management.
If the file ID is 0x00100000 or higher and the DSP Media module is configured for Network File System (NFS) the DSP Media module automatically starts retrieving this file from the NFS server. The location of the file and any other information that is needed about this file such as encoding, offset, and length, is sent in either the Play File Start or Record File Start message. Files with these high IDs cannot be chained.
Temporary Recordings
Temporary recordings, such as those used for directory assistance requests, should use File IDs below 0x00100000. Temporary recordings cannot be erased until they have been played once. Then they are subject to erasure by the Least Recently Used (LRU) method.
These temporary files are erased after being played to clear space for newer files. However, because you can't replicate temporary recordings such as directory assistance requests once they are erased, they are always erased last.
Files below 0x00100000 originate on the NFS server but they are cached on the DSP Media module. Make sure that the File IDs you use for temporary recordings are
Developer Information
1187
always different from the File IDs you use for permanent files. Consider designating one range for the first type and another range for the second type.
If the DSP Media module is configured to use NFS and the File ID is below 0x00100000, the DSP Media module first checks its cache. If the File ID is not found in cache, the DSP Media module checks the NFS server.
File Chaining
Using the Play File Start message, you can transmit up to 32 chained voice files stored on the card. Only file IDs below 0x00100000 can be chained. File IDs below 4096 support existing RAN messages, and up to 64 of these can be chained.
Summary of File IDs
0x00100000 and higher
4096-FFFFF File IDs 0-4095
Storage Stored on an external network server, accessed via MSP I/O
Cached on the DSP Media module after being downloaded once
Cached on the DSP Media module
Chaining Cannot be chained
Up to 32 can be chained, using the Play File Start message
Up to 32 can be chained using the Play File Start message
Up to 64 can be chained using the Recorded Announcement Connect message
Tracking Use the File Location TLV or VIF Bypass feature
Use the Vocabulary Index File or VIF Bypass feature
Use the Vocabulary Index File or VIF Bypass feature
Compatible with RAN messages
No No Yes
Queueing Yes Yes Yes, using the Play File Start message
MSP
1188
Encoding Formats
Supported Formats
The DSP Media module supports both the Raw and .wav file formats for the following encoding formats:
A-law (0x00)
µ-law (0x01)
G.726 32 Kbps (0x02)
32 Kbps OKI ADPCM (0x03)
24 Kbps OKI ADPCM (0x04)
16-bit linear, 11025 Khz (0x05)
µ-law, 11025 Khz (0x06)
A-law, 11025 Khz (0x07)
8-bit linear, 11025 Khz (0x08)
8-bit linear, 8000 Khz (0x09)
16-bit linear, 8000 Khz (0x0A)
* Note that 16 bit uncompressed data requires twice the processor and DSP bandwidth, and will adversly affect channel densities accordingly.
ADPCM
Excel supports Adaptive Differential Pulse Code Modulation (ADPCM) for Playback files. ADPCM is a compression algorithm for voice that records only the difference between samples, and dynamically adjusts the coding scale to accommodate large and small differences.
Because OKI requires fewer resources than G.726, OKI is more suitable for resource-intensive applications, such as speeding up or slowing down voice files. And OKI provides voice quality comparable to G.726.
When you choose either OKI or G.726, the caches on both the DSP and the 8260 chip store the data in that encoding format only. Both the Skip Ahead / Skip Back feature and the Speed Up / Slow Down feature take this file format choice into consideration.
Compression Benefits
Compared to standard PCM, ADPCM effectively doubles your cache capacity. For two seconds of voice with standard PCM, 16 KB are required. For two seconds of voice with ADPCM, only 8KB are required. Because only half the data is read or written compared to standard PCM, ADPCM also increases performance over the Network File System (NFS) server link.
Compression is performed as the voice is initially recorded, and decompression is performed just before the file is played out. ADPCM does not degrade the performance of the playback or record functionality.
Developer Information
1189
Vocabulary Index File Format
Element Number
Element Name Description
1 File ID A unique number that is used when playing a file out. Valid Range: 0 <= file ID < 0x00100000
2 Primary Server ID The Primary server where the file is stored
3 Secondary Server ID The Secondary server where the file is stored
4 File Name The File Name including the full path (up to 128 Chars)
5 File Type See the 0x05E1 File Format TLV for values.
6 File Encoding See the 0x05E1 File Format TLV for values.
7 Timestamp Date/Time: mm/dd/yyyy hr:min
8 Offset The offset in bytes where the file is to play from
9 Length The number of bytes to be played
Example
The following is an example of a Vocabulary Index File. Note that some, but not all, of the files include the last two fields (Offset and Length)
100 1 2 /F-0289_Playback_by_File_Offset/count1-30.raw.ulaw 0 1 10/09/2003 15:52 1473 9330
101 1 2 /F-0289_Playback_by_File_Offset/count1-30.raw.ulaw 0 1 10/09/2003 15:52 10803 7856
102 1 2 /F-0289_Playback_by_File_Offset/count1-30.raw.ulaw 0 1 10/09/2003 15:52 18659 7856
103 1 2 /F-0289_Playback_by_File_Offset/count1-30.raw.ulaw 0 1 10/09/2003 15:52 26515 8348
104 1 2 /F-0289_Playback_by_File_Offset/count1-30.raw.ulaw 0 1 10/09/2003 15:52
105 1 2 /F-0289_Playback_by_File_Offset/count1-30.raw.ulaw 0 1 10/09/2003 15:52 44192 9330
106 1 2 /F-0289_Playback_by_File_Offset/count1-30.raw.ulaw 0 1 10/09/2003 15:52
107 1 2 /F-0289_Playback_by_File_Offset/count1-30.raw.ulaw 0 1 10/09/2003 15:52 61869 9329
108 1 2 /F-0289_Playback_by_File_Offset/count1-30.raw.ulaw 0 1 10/09/2003 15:52 71198 8348
109 1 2 /F-0289_Playback_by_File_Offset/count1-30.raw.ulaw 0 1 10/09/2003 15:52 79546 7365
MSP
1190
File Retrieval Process
The decision tree below shows the process for retrieving a file.
File Retrieval Process
File ID
The File ID represents not only the file name and location, but also the Offset and Length. A change in any of the parameters requires a new File ID to be generated.
Two File IDs can overlap. For example, if one file has an Offset of 8000 and a Length of 16000, another file can have an Offset of 12000 and a Length of 8000.
When the File ID is requested to be played, the DSP Media module checks to see if the File ID is already in cache. DSP Media module has one set of options for files already in cache, and another set for files that are not found in cache.
Developer Information
1191
File IDs Already in Cache
If the File ID is already in cache, the DSP compares the Offset and Length in cache either to the VIF or, if using the VIF Bypass feature, to the Offset and Length TLV (see VIF Bypass). If the Offset and Length are different in cache, then the file is cleared from the cache and a new cache entry is added from either the VIF or, if using the VIF Bypass feature, from the TLV.
File IDs Not in Cache
If a file is not already in cache, the Offset and Length are specified as follows:
If you are using a VIF, and the Offset and Length are specified there, then that Offset and Length are used.
If you are using a VIF, but the Offset and Length are not specified there, then the File Offset and Length TLV is used instead.
If you are using the VIF Bypass feature, the File Offset and Length TLV is the only way to specify the Offset and Length.
Dynamic File Management
Using NFS, recorded voice files are handled dynamically through a Least Recently Used algorithm. Voice files are downloaded to the DSP Media module’s memory one at a time, and as the memory on the card is consumed, a Least Recently Used (LRU) algorithm keeps track of the order in which the files are played. When the memory is completely consumed, the following takes place:
1. The LRU algorithm identifies the Least Recently Used File ID.
2. This File ID is then deleted.
3. The memory blocks are freed for further use.
When the host application sends an instruction to play a specific file on a specific DSP chip, it then:
1. Checks the main board’s three hour cache for the announcement file.
2. Checks the Network File System server (if used) for the announcement file.
MSP
1192
Playback Features
Playback by File Offset and Length
This feature provides two benefits:
an application can play from a particular location within a file by providing an offset, in bytes, from the beginning of the file
a user can specify how long the file should play, so it does not have to play to the end
Use the Offset and Length (0x0614) TLV in the Play File Start (0x011B) message to begin playing a file at an offset from the beginning of the file. You also specify how long into the file to play so you do not have to play to the end.
The offset for playback should be on an even boundary.
When only part of a file is requested to be played, only the requested bytes are cached (not the entire file) on both the chip and the DSP. Because the Offset and Length are in bytes, and because they represent bytes in a file, the application is responsible for managing the different encoding formats, and for how bytes should represent time.
Handling Inconsistent File Sizes
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.
Developer Information
1193
Conferencing
Conferencing Overview
The DSP Media module provides the following conferencing capabilities:
256 conferences available per DSP stream
128 legs/conferees available per conference (all conference types)
256 legs/conferees available per DSP chip (you can use half of a chip’s legs in any one conference)
Direct Media Service Access to Conferences
Manual Volume Control
Features
The robust suite of Conferencing Features includes:
Automatic Gain Control
Output Gain Control
Noise Gating
Echo Suppression
Conference Tracking
Conference Failure Handling
Conferencing Options
You can configure a conference with the following options:
Barge In
DTMF Clamping/Filtering
Conferencing Encoding Type
Conference Failure Behavior
0x05E5 Barge In
0x0604 DTMF Clamping/Filtering Enable
0x0605 EXS Conferencing Encoding Type
0x0606 Monitor Conference Enable
0x060F Conference Failure Behavior
Supported Conference Types
The DSP Media module supports the following conference types:
Unified (DTMF Clamped)
Monitor
MSP
1194
Manual Input Volume Control
This feature enables a manual volume control on a parties inbound leg to a conference. The Automatic Gain Control for that party is automatically disabled, and the requested gain is added to the conferee’s speech prior to being added to the conference.
An example application of this feature would be where an individual wants to ensure that his contributions to the conference are heard by the other participants so adds a few dB of gain to their voice, in effect, raising the volume of their voice without additional effort.
Related Topics
Unified Conference
Monitor Conference
Conferencing Features
Configuring Conference Features
Developer Information
1195
Unified Conference
The Unified Conference type provides the following functionality:
Conferees can be µ-Law, A-Law, or mixed. There is no need to specify the encoding when creating the conference.
Unlimited Broadcast or “listen only” capability (µ-Law and A-Law)
Dynamically increase conference size
Dynamic Sizing
You can connect channels to a conference even if the number of conferees exceeds the configured conference size, as long as the DSP chip hosting the conference has available resources.
When the MSP 1010 creates a Unified conference, it places the conference on whichever DSP chip has the largest number of free channels at that moment, maximizing the opportunity for that conference to grow dynamically.
Child Conference (Conference in a Conference)
You can create a private sub-conference (child conference) within a larger conference (parent conference). When a smaller group of participants within a larger conference want to talk privately, they can do so while still hearing the audio from the larger conference. The sub-conference parties participate with one another in full duplex, while becoming listen-only parties in the larger conference.
The feature allows users to create a child conference, move parties from the parent conference to the child conference and back, and delete the child conference.
No Resource Points are used for a child conference unless a leg is added to the child conference. If a leg is added to the child conference, Resource Points are consumed the same way they are consumed in parent conference.
DTMF Clamping
You can enable DTMF Clamping on a Unified conference to prevent DTMF echo. DTMF echo causes false DTMF indications on conference legs. This feature enables users to provide DTMF digit receivers on each conference leg without one conference participant inadvertently controlling another participant’s conference parameters.
MSP
1196
Monitor Conference
Overview
A Monitor conference allows one or more monitor channels to listen to as many as nine conversations in a single monitor conference. The source channels do not need to be associated with each other in any way. This feature is useful for applications requiring supervisory monitoring, such as in Automatic Call Distributor (ACD) systems.
Each DSP chip that is configured for the Monitor Conference function type can support source channels of A-law and µ-law encoding, and output either A-law or µ-law according to the configuration of the monitor and source channel(s). At least one DSP chip must be configured this way to enable the Monitor Conference feature.
Configuration
See Creating a Monitor Conference.
Developer Information
1197
Conferencing Features
Overview
The robust suite of Conferencing Features includes:
Automatic Gain Control
Output Gain Control
Noise Gating
Echo Suppression
Conference Tracking
Conference Failure Handling
You can configure these features to handle such things as network and signal problems (background noise, echo, and speakers who are too loud or too quiet), conference failure, and conference tracking.
These parameters are especially important for large conferences because as conferences grow, so does the likelihood of impaired signals and networks, and so does the number of users affected. These settings apply to up to two streams of 128 participants.
There are default settings for these features at the DSP Media module level, and these should work well in most environments. However, you can change the defaults for an entire conference when the conference is created, and for individual conferees (conference legs).
Automatic Gain Control
Automatic Gain Control (AGC) automatically detects variations in volume input and adjusts the input level to be within a decibel range that you can specify, in 1 dB increments. So if a conferee’s voice input (one conference leg) is either too quiet or too loud, AGC adjusts the input so that it falls within your specified acceptable range. You can specify the duration (time constant) of the sample used to determine the volume of the conferee’s voice, in increments of 5 ms.
Output Gain Control
When output gain (volume) is too low or too high, you can control it using the Output Gain Control feature. You can adjust gain from –40 dB to 0 dB, in increments of 1dB. The MSP 1010 acts upon the most recent command. For example, if a change is made at the conference leg level and then at the conference level, the conference level setting overrides the leg level setting because that was the last change made.
Noise Gating
During natural breaks in conversation (when the speaker on a channel is not speaking) if significant ambient noise is coming into a conference from the speaker’s
MSP
1198
line, that noise can be gated using the Noise Gating feature. As a conference grows in size, ambient noise is more likely to become a problem.
You can customize the time span (time constant) over which noise is measured, in increments of 5 ms. You can also specify a maximum allowable estimated noise level in 1 dBm increments, from
–54 dBm to –10 dBm.
Echo Suppression
If a conference leg is generating echoed signal, you can mute that echoed signal using the Echo Suppression feature. Note how this differs from echo cancellation. Echo Suppression adaptively measures the reflected signal input, and adapts its echo estimate up to a maximum noise value, which you can select in 1 dBm increments, from
–54 dBm to –10 dBm.
Conference Tracking
You can query the channel IDs of the three active (loudest) parties that are being summed together and the time they have been active. The report is returned in the Generic Report message (0x0046).
Conference Failure Handling
If the DSP Media module or DSP chip that is hosting a conference fails, all the channels in the failed conferences can now be parked instead of purged, although the default is still to purge. You can override this default for all conferences created, individual conferences, or individual conference legs. The application is responsible for rebuilding the conference on another DSP resource or for releasing the conference legs.
Configuration
See Configuring Conference Features.
Developer Information
1199
Tones
Tone Overview
Tone Reception
The DSP Media module supports the following tone reception functions:
DTMF Digit Reception (µ-law and A-law)
Call Progress Generation and Analysis (µ-law and A-law)
MFR1/R2 Tone Reception
A single receive stream can suport 183 channels - 366 per DSP
Tone Generation
The DSP Media module uses a Unified Tone Transmitter. The Unified Tone Transmitter supports the following:
up to 512 channels per DSP chip of mixed DTMF/MFR1/R2
Bong Tone and Call Progress tone generation for either µ-law or A-law.
A single transmit stream can support 256 channels - 512 per DSP.
MSP
1200
Tone-Related Terms
Call Progress Tone Patterns
Call progress tone patterns are audible signals that indicate the progress or disposition of a telephone call. Examples of call progress tone patterns include the busy signal, ringback, and dial tone.
Call Progress Analysis (CPA)
The act of receiving and interpreting call progress tone patterns is called Call Progress Analysis (CPA).
For call progress analysis, the MSP 1010 groups patterns into classes to facilitate management of CPA receivers. These CPA classes help assign call progress tone patterns to CPA receivers. When the host assigns a DSP resource to scan for call progress tones, the host specifies a class of patterns. The DSP resource then scans for the patterns defined in that class.
For example, you could place all progress tones used in a single country into one class. You could then assign this class to a DSP chip for call progress analysis for that country. The host can modify and create classes, using the CPA Pattern Configure message.
When a Call Processing receiver activates, it detects call progress patterns that are part of a Call Progress Analysis (CPA) Class. The receiver ignores any tones that are not part of a pattern in this CPA Class. This scenario allows the receiver to skip over tones that are not of interest, reducing the chance of receiving false Call Progress Analysis Result API messages.
By default, the MSP 1010 uses the following four CPA classes:
0x00 Standard North America
0x01 Dial Tone
0x02 CPC Detection
0x03 Energy Detection
Frequency
A frequency is the most basic building block of a call progress tone pattern.
Tone
A tone is a combination of frequencies, or it is a single frequency that has been designated as a tone. The frequency or frequencies in a tone have specified dBm levels.
Tone Pattern
A tone pattern is a single tone or a sequence of tones, divided at precise intervals by silence. A tone pattern is formed when tones are combined, with specific intervals of silence between them.
Developer Information
1201
For example, the industry-standard “call waiting tone” is actually a pattern, in which Tone 1 is on for 300 milliseconds, off for 9700 milliseconds, and on again for 300 milliseconds. You can think of a call progress tone pattern as being at the top of a hierarchy, with tone in the middle and frequency at the bottom. That is, one or more frequencies make up a tone, and one or more tones make up a pattern.
Composition of a Call Progress Tone Pattern
MSP
1202
Types of Tones
The MSP 1010 lets you transmit address signaling and call progress tones. Each tone type is available for both µ-law and A-law. You can generate the following tones:
Dual Tone Multi-frequency (DTMF)
Multi-frequency R1 (MFR1)
Multi-frequency R2 (MFR2 – backward and forward)
Call Progress Tone Patterns (CPT4)
Calling Card Prompt (Bong Tone)
Developer Information
1203
Call Setup
Digit Collection During Call Setup
During call setup, the MSP platform can collect DTMF, MFR1, and MFR2 (Forward and Backward) digits.
DNIS and ANI Identification
You can program the MSP platform to automatically collect the inpulsing address data that typically accompany an incoming call. This information identifies the Dialed Number Identification Service (DNIS) and/or the Automatic Number Identification (ANI). A service application can use this data to validate and authenticate subscribers, and to identify service.
International Call Progress Analysis
The MSP 1010 can transmit and receive international tones, including a 400 Hz tone used outside of North America.
Reporting Call Progress Tones
Detected call progress tones can be reported to the host in the following two ways:
During call setup, with the outseize instruction of Do Call Progress Analysis
Interactively, by assigning a CPA Receiver with the DSP Service Request message.
The table below lists the maximum quantities for call progress tone detection in the MSP 1010.
System Maximum for call progress tone detection
Tone Specification System Maximum
Patterns 30
Classes 15
Patterns per class 15
Frequencies per tone 2
Receiving Call Progress Tone Patterns
The algorithm for detecting call progress tones has the following two phases:
1. Pattern Detection – The first phase recognizes the pattern, based on the tones and cadences received.
2. Pattern Match – The second phase counts tone intervals, to confirm the presence of a pattern. The number of intervals to match is specified by the pattern’s Interval Cycles to Match parameter.
MSP
1204
The algorithm does not move to the second phase until the pattern is identified. Configurable timers determine the maximum time to remain in each phase.
The MSP 1010 scans for call progress tones in the specified class, and reports them in the CPA Result message. CPA terminates upon reporting a result.
Developer Information
1205
Energy Detection
The Energy Detection feature detects energy on a channel. You can use this feature for CPA when there is not a pattern to match available, or to report energy detection to the host application. To compensate for background noise and to filter out short energy bursts, you can set the sensitivity level and the scan duration (defined below).
You can determine these settings based upon the type of energy to be detected, and to some extent, by trial and error. After setting both levels, test to see if the desired energy is being detected, then adjust the settings as necessary.
For CPA, the Energy Detection feature determines only that a pattern has occurred. It does not distinguish tones. The Energy Detection class (Class 3) is composed of the most common call setup tones: Ringback, Double Ringback, Busy, and Reorder. You can add any pattern to this class, or use any other class for Energy Detection, with the following restrictions:
The pattern must consist of alternating periods of tones and silence. Energy Detection recognizes a pattern by periods with energy (tone) and no energy (silence). Because Energy Detection must detect both tone and silence, it cannot detect a “pattern” that has tone but no silent interval.
The Energy Detection DSP function can detect only tones from the default patterns defined for the Energy Detection class (Tone IDs 0, 1, 2, and 5). You can still use a pattern for Energy Detection that does not use one of these tones. To do so, you must change the Tone IDs in the pattern to one of those allowed, using the CPA Pattern Configure message.
Parameters
The following parameters configure energy detection:
Sensitivity Level
Scan Duration
Completion Timer
Sensitivity Level
The Sensitivity Level is the amplitude above which the energy detector perceives a signal. Set the sensitivity level to detect and report energy that is greater than the prevailing background noise. When you expect a significant background noise, use the least sensitive setting (0 dBm). When you expect little background noise, use the most sensitive setting (-30 dBm).
Scan Duration
The Scan Duration is the repeating time interval over which the energy detector determines that energy is either Present or Not Present. Set the scan duration to be longer than expected energy bursts. You must use 20 millisecond intervals to set the scan duration, so energy is sampled for each 20 millisecond block within the specified duration.
MSP
1206
The scan cycles repeat until the completion timer expires. The calculated energy level is the average over all blocks, as shown in Table 7-4. If the calculated energy level exceeds the configured sensitivity level, energy is reported.
Scan Cycle
Completion Timer
The completion timer determines the maximum amount of time to scan for energy. Each scan cycle, as defined by the scan duration, is repeated until either energy is detected, or the completion timer expires. We recommend setting the completion timer for 3 to 4 times the scan duration, depending on the application. If the timer expires before energy is detected, the host receives a Call Processing Event message of “No Energy Detected.”
Detection Methods
You can invoke Energy Detection in the following two ways:
Interactively, with the DSP Service Request message
As part of Call Progress Analysis
Interactive Energy Detection
You can invoke Energy Detection interactively, with the DSP Service Request message. Use the data bytes of the message to configure the sensitivity level, reporting mode, scan duration, and completion timer. The detected energy is reported to the host in a Call Processing Event message in one of two modes:
Report Initial Energy Detection Only
The host receives a Call Processing Event of “Energy Result Report” with Data[0], indicating Energy Detected. Data[1] indicates the duration of the period of no energy. The DSP resource is then automatically released.
Report All Energy Threshold Crossings
All of the following are reported: the initial energy detection, all subsequent changes, and the duration of the previous state’s ON or OFF interval.
When energy (A) is first detected, the host receives a Call Processing Event of “Energy Result Report” with Data[0] indicating “Energy Detected.” Data[1] indicates the duration of the preceding period of no energy (D1).
Developer Information
1207
When energy is no longer detected (B), the host receives a Call Processing Event message of “Energy Result Report” with Data[0] indicating “No Energy Detected.” Data[1] indicates the duration of the preceding period of energy (D2).
Energy Result Report
The DSP resource remains attached and reports energy changes until the completion timer expires, or until the host sends a DSP Service Cancel 0x00BE message, or until the channel returns to an idle state.
Energy Detection as Call Progress Analysis
Energy Detection allows the MSP 1010 to perform Call Progress Analysis for frequencies not supported by the default CPA DSP load. The Energy Detection DSP function matches cadences, based on the reported energy levels. CPA Class 3 is pre-configured for Energy Detection, using the standard CPA tones of ringback, double ringback, busy, and re-order.
To accommodate unique requirements for matching cadences, you can modify these patterns or add new patterns to the class. The host can change the pattern cadence that energy detection scans for, using the CPA Pattern Configure message.
Configuration
See Configuring Energy Detection.
MSP
1208
T.30 Fax
T.30 Fax Overview
T.30 is a fax handshake protocol that describes the overall procedure for establishing and managing communication between two fax devices.
T.30 covers these five phases of a faxing:
1. Setup the Call
2. Select the Communication Mode
3. Transmit the Message
4. Post Message Processing (Including End-of-Message and Confirmation)
5. Release Call / Disconnect
Note: T.30 does not allow for data transmission or processing. T.30 allows only for the transfer of fax image standards T.4 and T.6.
For more information about the Group 3 fax standard, see ITU T30 Fax standard.
Requirements
DSP Media module
One DSP Media module License
12 Resource Points per fax session
Network File System (NFS)
Supported Fax Standards
V.21 (300 bps) for T.30 fax negotiation
V.27 (2,400 / 4,800 bps, required by Group 3)
V.29 (9,600, 7,200 bps)
V.17 (14.4, 12, 9.6, 7.2 kbps) transmit/receive
Supported Image Format Conversion
Image formats conversion, either off-line or while the fax is being sent or received, for MH, MR, (ITUT.4), and MMR (ITUT.6)
Document files must be in TIFF-F or TIFF-S Format
Configuration
See Configuring T.30 Fax.
Developer Information
1209
Supported Features
The Excel T.30 Fax suite supports the following enhanced Group 3 fax features:
Resolutions: normal, fine, very fine
Standard page width formats
Conversion of document formats into different formats, resolutions, or encodings online (on-the-fly) or offline
Encoding: 1D, 2D, and MMR
Fax transmission or reception at rates up to 14,400 bps
12 simultaneous faxes per DSP chip (6 per stream)
ITU Group 3 compliance for worldwide fax machine compatibility
Document fax conversion (shrinking to fit A4, for example) to be supported “on the fly” via TLV
Page format conversions: A3, A4, and B4
Fax session and document status monitoring
Fax queues
FoIP
Error Correction Mode (ECM)
Permanent fax records (stored on the NFS server)
Configurable per-module, per-chip, and per-call
Digital signal processor (DSP)-based flexibility
Transmit Page Range in TIFF File.
NOTE: This release does not support T.30 Polling Mode.
MSP
1210
Fax Applications
The DSP Media module supports a suite of intelligent fax capabilities that are compliant with the ITU T.30 fax protocol, recognized worldwide. You can use the Excel T.30 Fax suite to develop applications that transmit and receive Group 3 facsimiles concurrently on all channels, at rates up to 14,400 bps.
Fax Messaging Applications
Supported Fax Applications include:
LAN Fax
Fax Broadcast
Fax-on-demand
Fax Messaging
Fax Server Products
Fax server products can be key components of large-scale, media server-based fax applications for the enterprise (for example, fax servers) and for large-scale Fax Service Provider systems. Dedicated fax servers serve more users while reducing hardware cost. Fax servers let companies distribute information to large audiences for pennies a page, and to eliminate bottlenecks associated with the limited capacities of traditional fax machines.
Store and Forward
A host application running on the MSP 1010 with the Excel T.30 Fax suite can use ITU T.37 fax store and forward. Although the Excel T.30 Fax suite does not explicitly support ITU T.37 fax store and forward, the suite does support the T.37 page format, which is specified as 1D encoding, LOW resolution, and A4 page width.
Developer Information
1211
Administration
Overload Management
Overview
The Overload Management feature allows the MSP platform to monitor and balance DSP resources on the DSP Media module, based upon how busy the DSP Media module is.
CPU Overload
File Overload
The DSP Media module overload levels are reported to the CPU:
when any level changes
Overload Levels
There are two overload levels to the CPU:
Overload 1
A DSP resource at Overload Level 1 will be used only if no other resources in the MSP 1010 are available.
Overload 2
A DSP resource at Overload Level 2 will not be used for some functions, and queued for others.
Alarms
When the configured process overload thresholds are exceeded, the DSP Media module sends an Alarm message to the Host application. When the thresholds are no longer exceeded, the DSP Media module sends an Alarm Cleared message to the Host application.
CPU Overload
CPU Overload Level 1
When an available DSP Media module resource is at CPU Overload Level 1, the resource will only be used when no other DSP resource is available in the MSP 1010. This applies to all DSP function types.
CPU Overload Level 2
A request for any of the following DSP resources is NACK’d with “No Resources Due to DSP Overload” (0x1707)
Tone Transmitter
Conferencing
Call Progress Analysis
MSP
1212
Energy Detection
File Play/Record
If a request for a DTMF, MFR1, or MFR2 receiver has been queued, the CPU sends an Alarm message of DSP Request Queued Due to DSP Media module CPU Overload Level 2 (0x40). This is a General alarm with a severity of Major.
File Overload
The File Overload Levels are set when any of the following conditions occur:
the CPU idle time is below its threshold setting
the VRA Process time is greater than its threshold setting
the VRA IO Queue process time is greater than its threshold setting
The File Overload Levels are cleared when all of the following conditions are met:
the CPU idle time is no longer below its threshold setting
the VRA Process time is no longer greater than its threshold setting
the VRA IO Queue process time is no longer greater than its threshold setting
File Overload Level 2
Any request for a DSP File Transmitter or Recorder is NACK’d with "No Resources Due to DSP Overload" (0x1707).
Configuration
See Configuring Overload Management.
Overload Alarms
The following Alarm messages are sent to the host when an overload condition occurs. When the condition clears, an Alarm Cleared message is sent.
Condition Alarm
CPU Overload 1 None
CPU Overload 2 Alarm Type: Card
Severity: Major
Alarm: NFS Major Traffic (0x45)
Overload Alarm Type: CPU Idle (0x0A)
Alarm Type: General
Severity: Major
Overload Alarm Type: DSP Request Queued Due to DSP Media module CPU Overload Level 2 (0x40)
File Overload Level 1: VRA Process Alarm Type: Card
Developer Information
1213
Time Severity: Minor
Alarm Number: NFS Minor Traffic (0x44)
Overload Alarm Type: “VRA Process” (0x0B)
File Overload Level 1: VRA IO Queue Process Time
Alarm Type: Card
Severity: Minor
Alarm: NFS Minor Traffic (0x44)
Overload Alarm Type: VRA IO Queue Process (0x0C)
File Overload Level 2 None
File Overload Level 2 for VRA Process Time
Alarm Type: Card
Severity: Major
Alarm: NFS Major Traffic (0x45)
Overload Alarm Type: VRA Process (0x0B)
File Overload Level 2 for VRA IO Queue Process Time
Alarm Type: Card
Severity: Major
Alarm: NFS Major Traffic (0x45)
Overload Alarm Type: VRA IO Queue Process (0x0C)
MSP
1214
Statistics Query
Overview
Use the Statistics Query 0x0121 message to retrieve the following information:
Network File System (NFS) statistics per card:
total number and size of NFS reads, writes, and records
read and write time delays (minimum, maximum, and average)
Function statistics on individual DSP chips:
total requests for a function
average free channels
minimum free channels
Cache statistics on all individual DSP chips:
accesses
misses
hits
average free blocks
Fixed memory statistics on all individual DSP chips, including total, average, and maximum blocks used.
Developer Information
1215
DSP Alarms
The table below shows the alarms reported in the Alarm 0x00B9 message that relate to DSP functionality. See the message for details.
DSP Related Alarms
Alarm Type Severity Alarm Number/Name
0x06 - DSP Resource Blocked
0x07 - DSP Resource Function Type Not Configured
0x08 - DSP Resource Management Inconsistent
0x3F - Insufficient Resource Points for DSP Function
Major
00x40 - DSP Request Queued Due to DSP Media module CPU Overload Level 2
General (0x01)
Informational 0x34 - DSP CPA Configuration Conflict
0x41 - NFS Server Mounting Error
0x43 - DSP Media module File Space Out of Memory
0x45 - NFS Traffic Threshold Major Alarm
0x46 - DSP Media module TFTP Communications Error
0x47 - NFS Read Error
0x48 - NFS Write Error
0x4B - NFS Server Unmount Error
Major
0x4C - NFS Open File Error
0x44 - NFS Traffic Minor Threshold Alarm Minor
0x42 - DSP Media module File Space Low
0x49 - Vocabulary Index File Read
0x4A - NFS Server Unmounted
Card (0x02)
Informational
0x40 - NFS Server Mounted Successfully
Channel (0x04) Major 0x0A - DSP Resource Wait Timeout
0x04 - Recorded Announcement Download Inconsistency
DSP SIMM (0x05)
Major
0x05 - Recorded Announcement ID Inconsistency (on same card)
MSP
1216
0x08 - Recorded Announcement File System Conversion Failure
0x09 - Recorded Announcement File System Timeout
0x0C - Recorded Announcement Defragmentation Failure
0x01 - DSP SIMM Taken Out of Service
0x03 - Recorded Announcement Erase Complete
0x06 - Recorded Announcement Download Ready
0x07 - Recorded Announcement File System Conversion Success
0x0B - Recorded Announcement Defragmentation Success
0x0D - Recorded Announcement Single Deletion Complete
Informational
0x0E - Recorded Announcement Need Defragmentation
0x01 - DSP Out of Service
0x03 - DSP Playback Underrun
0x04 - DSP Record Overrun
0x05 - DSP Temporary Storage Minor Alarm
Major
0x06 - DSP Temporary Storage Full
0x02 - Resources Exceed Limit
DSP (0x06)
Informational
0x07 - DSP Points Exceed Limit
Developer Information
1217
Specifications
DSP Media Module Features
Feature DSP Media Module
File Record/Playback Uses the DSP module for File Record/Playback
Maximum number of DSP chips 8
Configuration API Message DSP SIMM Configure (0x00C0)
Generic Card Configure (0x0122)
Tone Generation and Reception a DSP is assigned to play a universal tone, and that can be any tone type with the same encoding format.
Record/ Play files Record/Play features
Announcement Tracking the host application uses an ASCII Vocabulary Index File (VIF) to track playback files stored on the servers.
Conference Types - Monitor
- Unified
Conference API Messages - Resource Create
- Resource Connect
- Resource Modify
- Resource Delete
Statistics Supported
NFS server file storage Supported
Overload Management Supported
Coin Tone Detection Not Supported
E1 Dial Pulse Address Signaling Not Supported
MSP
1218
DTMF Digit Specifications
DTMF digit specifications
BCD DTMF Digit Frequencies (Hz)
0 0 941 Hz + 1336 Hz
1 1 697 Hz + 1209 Hz
2 2 697 Hz + 1336 Hz
3 3 697 Hz + 1477 Hz
4 4 770 Hz + 1209 Hz
5 5 770 Hz + 1336 Hz
6 6 770 Hz + 1477 Hz
7 7 852 Hz + 1209 Hz
8 8 852 Hz + 1336 Hz
9 9 852 Hz + 1477 Hz
A A 697 Hz + 1633 Hz
B B 770 Hz + 1633 Hz
C C 852 Hz + 1633 Hz
D D 941 Hz + 1633 Hz
E * 941 Hz + 1209 Hz
F # 941 Hz + 1477 Hz
Developer Information
1219
MF Digit Specifications
MFR1, MFR2 digit specifications
BCD MFR1 Digit
MFR1 Frequency (Hz)
MFR2 Digit
MFR2 Forward Frequency (Hz)
MFR2 Backward Frequency (Hz)
0 0 1300 Hz + 1500 Hz
1 1380+1500 1140+1020
1 1 700 Hz + 900 Hz
2 1380+1620 1140+900
2 2 700 Hz + 1100 Hz
3 1500+1620 1020+900
3 3 900 Hz + 1100 Hz
4 1380+1740 1140+780
4 4 700 Hz + 1300 Hz
5 1500+1740 1020+780
5 5 900 Hz + 1300 Hz
6 1620+1740 900+780
6 6 1100 Hz + 1300 Hz
7 1380+1860 1140+660
7 7 700 Hz + 1500 Hz
8 1500+1860 1020+660
8 8 900 Hz + 1500 Hz
9 1620+1860 900+660
9 9 1100 Hz + 1500 Hz
A 1740+1860 780+660
A KP 1100 Hz + 1700 Hz
B 1380+1980 1140+540
B ST 1500 Hz + 1700 Hz
C 1500+1980 1020+540
C STI 900 Hz + 1700 Hz
D 1620+1980 900+540
D STII 1300 Hz + 1700 Hz
E 1740+1980 780+540
E STIII 700 Hz + 1700 Hz
F 1860+1980 660+540
MSP
1220
Default Transmit Call Progress Tones
The table below shows the default tones that the MSP platform uses to generate call progress tone patterns. Each call progress tone is distinguished by an ID. Note that some of the tones are single frequencies, while others are combinations of frequencies, at specific dBm levels.
You can modify any of the default tones shown in the table above, but you cannot create a new Tone ID. The tone that was originally associated with that Tone ID becomes unavailable and the change affects all patterns that use that tone.
Default transmit call progress tones
Tone ID
Specifi-cation
01 02 03 04 05 06 07 08 09 0A 0B 0C
Frequency Count
1 1 2 2 2 4 1 1 1 1 1 1
Frequency 0 (Hz)
44 0
48 0
35 0
44 0
48 0
1,400 91 4
98 5
1,371
1,42 9
1,77 7
40 0
dBm 0 -15
-15
-15
-20 -20 -8 -13 -13 -13 -13 -13 -18
Frequency 1 (Hz)
44 0
48 0
62 0
2,060
dBm 1 -15
-20 -20 -8
Frequency 2 (Hz)
2,450
dBm 2 -8
Frequency 3 (Hz)
2,600
dBm 3 -8
Developer Information
1221
Default Transmit Call Progress Tone Patterns
To form call progress tone patterns, the call progress tones are combined and separated by intervals of silence. The table below shows the default transmit call progress tone patterns and their parameters.
Each pattern is composed of one to three cycle blocks, which include the following components:
Tone ID
ON duration
OFF duration
Number of times to repeat the cycle block
0xFFFF = continuous
Default Transmit Call Progress Tone Patterns
Transmit Cadence Pattern
ID Cycle Blocks
Cycle Block Number
Tone ID
ON Duration
OFF Duration
Cycles
Dial Tone 0x01 1 1 0x03 0xFFFF 0 1
Ringback 0x02 1 1 0x04 2000 4000 1
Line Busy 0x03 1 1 0x05 500 500 1
Reorder 0x04 1 1 0x05 250 250 1
Warning 0x05 1 1 0x06 100 100 1
1 0x01 300 9700 1 Call Waiting 0x06 2
2 0x01 300 10 1
1 0x02 100 100 1 ONI Call (Zip Tone)
0x07 2
2 0x02 100 10 1
ANI Failure (Zip Tone)
0x08 1 1 0x02 80 10 1
Confirmation 0x09 1 1 0x03 100 100 3
1 0x03 100 100 3 Recall Dial Tone
0x0A 2
2 0x03 0xFFFF 10 1
Class of Service Tone 2
0x0B 1 1 0x05 800 10 1
Class of Service Tone 3
0x0C 1 1 0x02 800 10 1
Intercept 0x0D 3 1 0x07 280 10 1
MSP
1222
2 0x09 280 10 1
3 0x0B 380 10 1
1 0x08 380 10 1
2 0x09 280 10 1
Vacant Code 0x0E 3
3 0x0B 380 10 1
1 0x07 280 10 1
2 0x0A 380 10 1
Reorder - LEC
0x0F 3
3 0x0B 380 10 1
1 0x08 380 10 1
2 0x0A 380 10 1
No Circuit - LEC
0x10 3
3 0x0B 380 10 1
1 0x08 280 10 1
2 0x09 380 10 1
Reorder - Carrier
0x11 3
3 0x0B 380 10 1
1 0x07 380 10 1
2 0x09 380 10 1
No Circuit - Carrier
0x12 3
3 0x0B 380 10 1
Continuous 400 Hz
0x13 1 1 0x0C 0xFFFF 10 1
1 0x00 500 10 1 Specialized Tone
0x14 2
2 0x02 800 10 1
Bong Tone 0x15 Reserved, cannot be modified by host
0x16 1 1 0x0D 0xFFFF 0x0000 1
0x17 1 1 0x0B 0xFFF 0x000 1
0x18-0x3F
User-defined
Developer Information
1223
Default Tone Patterns for CPA Detection
All of the tones supported by the MSP platform for are shown in the table below. The group of tone IDs may use up to 16 frequencies. A pattern is formed when the tones below are played at specific intervals.
Tones supported by the MSP
Tone ID Frequency Count
Frequency 0 (Hz)
Frequency 1 (Hz)
0x00 1 0
0x01 2 350 440
0x02 2 440 480
0x03 1 440
0x04 1 480
0x05 2 480 620
0x06 1 620
0x07 1 914
0x08 1 985
0x09 1 1371
0x0A 1 1429
0x0B 1 1777
0x0C 1 2000
0x0D 1 1700
0x0E 1 2100
0x0F 1 425
0x10 1 500
0x11 1 1100
MSP
1224
CPA Tone Patterns
The default tone patterns for call progress analysis appear in the table below. To modify or create new patterns, use the CPA Pattern Configure message. Click on the pattern name to see the default parameters (web-based documentation only).
Default tone patterns for call progress analysis
Value CPA Tone Pattern
0x01 Ringback
0x02 Double Ringback
0x03 Busy
0x04 Reorder
0x05 PBX intercept
0x06 SIT Intercept
0x07 Vacant Code
0x08 Reorder LEC
0x09 No Circuit LED
0x0A Reorder Carrier
0x0B No Circuit Carrier
0x0C PBX Dialtone
0x0D Standard Dial Tone
0x0E CPC Detection
Developer Information
1225
CPA Pattern Parameter Definitions
Pattern ID Description
Configuration Bits
Pattern-specific configuration (see CPA Pattern Configure message)
0x01 = Last Interval Continuous (for pattern ending with continuous tone)
0x02 = Detect Tone After Determination (for reporting Intercept Tones)
0x04 = Use As Internal Dial Tone (to detect dial tone without invoking Call Progress Analysis)
CPA Result on Pattern Loss
Call Progress Analysis Result to report when a pattern has been matched but discontinues before “interval cycles to report”. (CPA Result message).
Interval Cycles to Match
The number of times an Interval Sequence must be repeated before declaring the pattern valid
Interval Cycles to Report
The number of times an Interval Sequence must be repeated before reporting a Call Progress Result to the host
Interval Descriptor Count
The number of Interval Descriptors in the pattern
Interval Descriptor
An Interval Descriptor is a list of the tones and intervals that constitute a pattern. The MSP 1010 uses the Interval Descriptor to confirm that a specific pattern has been detected.
An Interval Descriptor consists of the Tone ID, Min. Filter, and Max. Filter, where:
Tone ID – A valid Tone ID
Minimum/Maximum Filter (MSB, LSB) – Minimum and maximum duration for this tone interval - A tone is determined as valid if the on and off cycles fall within the minimum and maximum times.
MSP
1226
Default CPA Tone Pattern Parameters
Ringback
Ringback
Pattern ID 0x01
Tone Group ID 0x00
Configuration Bits 0x00
CPA Result on Pattern Loss 0x80
Interval Cycles to Match 1
Interval Cycles to Report 2
Interval Descriptor Count 3
Interval Descriptors
Tone Interval 0: Tone ID 0x02
Reserved 0x00
Minimum Filter (ms) 600
Maximum Filter (ms) 2200
Tone Interval 1: Tone ID 0x00
Reserved 0x00
Minimum Filter (ms) 2800
Maximum Filter (ms) 5000
Double Ringback
Double Ringback
Pattern ID 0x02
Tone Group ID 0x00
Configuration Bits 0x00
CPA Result on Pattern Loss 0x80
Interval Cycles to Match 1
Interval Cycles to Report 3
Interval Descriptor Count 4
Tone Interval 0: Tone ID 0x02
Developer Information
1227
Reserved 0x00
Minimum Filter (ms) 420
Maximum Filter (ms) 580
Tone Interval 1: Tone ID 0x00
Reserved 0x00
Minimum Filter (ms) 200
Maximum Filter (ms) 400
Tone Interval 2: Tone ID 0x02
Reserved 0x00
Minimum Filter (ms) 420
Maximum Filter (ms) 580
Tone Interval 3: Tone ID 0x00
Reserved 0
Minimum Filter (ms) 2000
Maximum Filter (ms) 2500
Busy
Busy
Pattern ID 0x03
Tone Group ID 0x00
Configuration Bits 0x00
CPA Result on Pattern Loss 0x03
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 2
Tone Interval 0: Tone ID 0x05
Reserved 0x00
Minimum Filter (ms) 420
Maximum Filter (ms) 580
Tone Interval 1: Tone ID 0x00
Reserved 0x00
Minimum Filter (ms) 420
MSP
1228
Maximum Filter (ms) 580
Tone Interval 2: Tone ID
Reserved
Minimum Filter (ms)
Maximum Filter (ms)
Tone Interval 3: Tone ID
Reserved
Minimum Filter (ms)
Maximum Filter (ms)
Reorder
Reorder
Pattern ID 0x04
Tone Group ID 0x00
Configuration Bits 0x00
CPA Result on Pattern Loss 0x04
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 2
Tone Interval 0: Tone ID 0x05
Reserved 0x00
Minimum Filter (ms) 200
Maximum Filter (ms) 300
Tone Interval 1: Tone ID 0x00
Reserved 0x00
Minimum Filter (ms) 200
Maximum Filter (ms) 300
Tone Interval 2: Tone ID
Reserved
Minimum Filter (ms)
Maximum Filter (ms)
Tone Interval 3: Tone ID
Developer Information
1229
Reserved
Minimum Filter (ms)
Maximum Filter (ms)
PBX intercept
PBX Intercept
Pattern ID 0x05
Tone Group ID 0x00
Configuration Bits 0x02
CPA Result on Pattern Loss 0x05
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 2
Tone Interval 0: Tone ID 0x03
Reserved 0x00
Minimum Filter (ms) 100
Maximum Filter (ms) 300
Tone Interval 1: Tone ID 0x06
Reserved 0x00
Minimum Filter (ms) 100
Maximum Filter (ms) 300
Tone Interval 2: Tone ID
Reserved
Minimum Filter (ms)
Maximum Filter (ms)
Tone Interval 3: Tone ID
Reserved
Minimum Filter (ms)
Maximum Filter (ms)
SIT Intercept
MSP
1230
SIT Intercept
Pattern ID 0x06
Tone Group ID 0x00
Configuration Bits 0x02
CPA Result on Pattern Loss 0x06
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 3
Tone Interval 0: Tone ID 0x07
Reserved 0x00
Minimum Filter (ms) 200
Maximum Filter (ms) 350
Tone Interval 1: Tone ID 0x09
Reserved 0x00
Minimum Filter (ms) 200
Maximum Filter (ms) 350
Tone Interval 2: Tone ID 0x0B
Reserved 0x00
Minimum Filter (ms) 300
Maximum Filter (ms) 460
Tone Interval 3: Tone ID
Reserved
Minimum Filter (ms)
Maximum Filter (ms)
Vacant Code
Vacant Code
Pattern ID 0x07
Tone Group ID 0x00
Configuration Bits 0x02
CPA Result on Pattern Loss 0x07
Interval Cycles to Match 1
Developer Information
1231
Interval Cycles to Report 1
Interval Descriptor Count 3
Tone Interval 0: Tone ID 0x08
Reserved 0x00
Minimum Filter (ms) 300
Maximum Filter (ms) 460
Tone Interval 1: Tone ID 0x09
Reserved 0x00
Minimum Filter (ms) 200
Maximum Filter (ms) 350
Tone Interval 2: Tone ID 0x0B
Reserved 0x00
Minimum Filter (ms) 300
Maximum Filter (ms) 460
Tone Interval 3: Tone ID
Reserved
Minimum Filter (ms)
Maximum Filter (ms)
Reorder LEC
Reorder LEC
Pattern ID 0x08
Tone Group ID 0x00
Configuration Bits 0x02
CPA Result on Pattern Loss 0x08
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 3
Tone Interval 0: Tone ID 0x07
Reserved 0x00
Minimum Filter (ms) 200
Maximum Filter (ms) 350
MSP
1232
Tone Interval 1: Tone ID 0x00
Reserved 0x00
Minimum Filter (ms) 300
Maximum Filter (ms) 460
Tone Interval 2: Tone ID 0x0B
Reserved 0
Minimum Filter (ms) 300
Maximum Filter (ms) 460
No Circuit LED
No Circuit LED
Pattern ID 0x09
Tone Group ID 0x00
Configuration Bits 0x02
CPA Result on Pattern Loss 0x09
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 3
Tone Interval 0: Tone ID 0x08
Reserved 0x00
Minimum Filter (ms) 300
Maximum Filter (ms) 460
Tone Interval 1: Tone ID 0x0A
Reserved 0x00
Minimum Filter (ms) 300
Maximum Filter (ms) 460
Tone Interval 2: Tone ID 0x0B
Reserved 0
Minimum Filter (ms) 300
Maximum Filter (ms) 460
Reorder Carrier
Developer Information
1233
Reorder Carrier
Pattern ID 0x0A
Tone Group ID 0x00
Configuration Bits 0x02
CPA Result on Pattern Loss 0x0A
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 1
Tone Interval 0: Tone ID 0x08
Reserved 0x00
Minimum Filter (ms) 200
Maximum Filter (ms) 350
Tone Interval 1: Tone ID 0x09
Reserved 0x00
Minimum Filter (ms) 300
Maximum Filter (ms) 460
Tone Interval 2: Tone ID 0x0B
Reserved 0
Minimum Filter (ms) 300
Maximum Filter (ms) 460
No Circuit Carrier
No Circuit Carrier
Pattern ID 0x0B
Tone Group ID 0x00
Configuration Bits 0x02
CPA Result on Pattern Loss 0x0B
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 3
Tone Interval 0: Tone ID 0x07
Reserved 0x00
MSP
1234
Minimum Filter (ms) 300
Maximum Filter (ms) 460
Tone Interval 1: Tone ID 0x09
Reserved 0x00
Minimum Filter (ms) 300
Maximum Filter (ms) 460
Tone Interval 2: Tone ID 0x0B
Reserved 0
Minimum Filter (ms) 300
Maximum Filter (ms) 460
PBX Dialtone
PBX Dialtone
Pattern ID 0x0C
Tone Group ID 0x00
Configuration Bits 0x01
CPA Result on Pattern Loss 0x0C
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 7
Tone Interval 0: Tone ID 0x01
Reserved 0x00
Minimum Filter (ms) 80
Maximum Filter (ms) 120
Tone Interval 1: Tone ID 0x00
Reserved 0x00
Minimum Filter (ms) 80
Maximum Filter (ms) 120
Tone Interval 2: Tone ID 0x01
Reserved 0x00
Minimum Filter (ms) 80
Maximum Filter (ms) 120
Developer Information
1235
Tone Interval 3: Tone ID 0x00
Reserved 0x00
Minimum Filter (ms) 80
Maximum Filter (ms) 120
Tone Interval 4: Tone ID 0x01
Reserved 0x00
Minimum Filter (ms) 80
Maximum Filter (ms) 120
Tone Interval 5: Tone ID 0x00
Reserved 0x00
Minimum Filter (ms) 80
Maximum Filter (ms) 120
Tone Interval 6: Tone ID 0x01
Reserved 0x00
Minimum Filter (ms) 500
Maximum Filter (ms) 0
Standard Dial Tone
Standard Dial Tone
Pattern ID 0x0D
Tone Group ID 0x00
Configuration Bits 0x05
CPA Result on Pattern Loss 0x0D
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 1
Tone Interval 0: Tone ID 0x01
Reserved 0x00
Minimum Filter (ms) 500
Maximum Filter (ms) 0
CPC Detection
MSP
1236
CPC Detection
Pattern ID 0x0E
Tone Group ID 0x00
Configuration Bits 0x01
CPA Result on Pattern Loss 0x0E
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 1
Tone Interval 0: Tone ID 0x01
Reserved 0x00
Minimum Filter (ms) 1500
Maximum Filter (ms) 0
Fax
Fax
Pattern ID 0x13
Tone Group ID 0x00
Configuration Bits 0x00
CPA Result on Pattern Loss 0x13
Interval Cycles to Match 1
Interval Cycles to Report 1
Interval Descriptor Count 2
Tone Interval 0: Tone ID 0x11
Reserved 0x00
Minimum Filter (ms) 425
Maximum Filter (ms) 575
Tone Interval 1: Tone ID 0x00
Reserved 0x00
Minimum Filter (ms) 2550
Maximum Filter (ms) 3450
Developer Information
1237
CPA Classes
The parameters associated with a CPA class are defined in the CPA Class Parameter Definitions table below. To modify a class or to add a new class, use the CPA Class Configure message. The MSP 1010 supports up to 15 classes. A class can contain up to 15 pattern members, and 30 patterns are allowed for each MSP 1010. Class elements are given in the table below.
CPA Classes
Class Standard N.A. 0x00
Dial Tone 0x01
CPC Det. 0x02
Energy Det. 0x03
Mode 0x01 (Adv. Ans. Det.)
Energy Detection
Tone Burst Answer Threshold
4/250 ms 4/500 ms
Start Delay 0x00 0x00 0x00 0x00
Continuous Silence Timeout (ms)
25,000 25,000 0xFFFF 25,000
Confirmation (ms)
13,000 25,000 0xFFFF 13,000
Confirmation/No Report (ms)
22,000 15,000 0xFFFF 22,000
Minimum Frequency Glitch Time (ms)
40 20 20 20
Minimum Silence Glitch Time (ms)
60 20 20 60
Maximum On Timer (ms)
2,800 25,000 0xFFFF 2,800
Maximum Off Timer (ms)
5,000 25,000 0xFFFF 5,000
Mode Specific Value 1
0x0000 0x0000 0x0000 0x0005
Mode Specific Value 2
0x0000 0x0000 0x0000 0x0002
Patterns in Class
0x01 Ringback
0x02 Double
0x0C PBX Dial Tone
0x0D
0x0E CPC Detection
0x01 Ringback
0x02 Double
MSP
1238
Ringback
0x03 Busy
0x04 Reorder
0x05 PBX Intercept
0x06 SIT Intercept
0x07 Vacant Code
0x08 Reorder-LEC
0x09 No Circuit LEC
0x0A Reorder Carrier
0x0B No Circuit Carrier
0x0C PBX Dial Tone
0x0D Standard Dial Tone 0x0C PBX Dial Tone
Standard Dial Tone 0x0C PBX Dial Tone
Ringback
0x03 Busy
0x04 Reorder
Developer Information
1239
CPA Class Parameter Definitions
Class Parameter Definition
Mode Call Progress Analysis Mode (for example, Advanced Answer Detect, Energy Detection).
Tone Burst Answer Threshold
The number of frequency bursts in 500ms before answer is declared.
Start Delay Amount of time to wait before analysis begins.
Continuous Silence Timeout
Amount of time after CPA is initiated to wait to hear any tone.
Confirmation Amount of time to wait to detect a pattern.
Confirmation/No Report
Amount of time after detection of a tone to wait for pattern confirmation before terminating CPA.
Minimum Frequency Glitch
Time Amount of time to validate a tone detection.
Minimum Silence Glitch Time
Amount of time to validate a silence detection.
Maximum On Timer The maximum amount of time a tone must be “on” without a pattern match before the “continuous on” result is reported.
Maximum Off Timer The maximum amount of time silence must be detected before the “not determined” result is reported; amount of time to validate a silence detection before declaring it as silence.
Mode Specific Value Values to configure for specific CPA mode.
MSP
1240
Configuring & Using DSP Resources
Overview of Configuring and Using DSP Resources
The topics in this section provide the detailed steps for configuring and using DSP resources.
For just the basic DSP configuration steps in the context of the full MSP configuration (using API messages) refer to Overview of MSP Configuration and Overview of DSP Configuration.
Developer Information
1241
Basic DSP Configuration
DSP Configuration API Message Summary
Introduction
The following table shows the API message used for DSP configuration.
GENERAL DSP CONFIGURATION
Tasks Options/Notes API Message(s)
Assign Function Types See Function Types DSP SIMM Configure
Configure NFS File Management
Server Address
Vocabulary Index File
NFS User Group ID
NFS Poll Retries
Generic Card Configure
Configure Overload Alarm Thresholds
See Configuring Overload Management
Assign IP Address Required for NFS IP Address Configure
Bring DSP In Service Service State Configure
FUNCTION-SPECIFIC CONFIGURATION
Tasks Options/Notes API Message(s)
Conferencing
Configure Module-level Conferencing Parameters
Output Gain Control
Noise Gating
Echo Suppression
Auto. Gain Control
Failure Behavior
Generic Card Configure
Record Files
Record Files Gain
File Event Descriptor
Beep Tone Parameters
Initial Silence Timer
Final Silence Timer
Max. Record Timer
Dual Chan. Rec. Option
Silence Threshold
Record File Start
Record File Stop
MSP
1242
Append or Replace
Modify Recording Modify Gain
Pause
Resume
Record File Modify
Tones
If required, modify default tones and Call Progress Analysis Pattern/Class.
See Customizing Tones. Call Progress Analysis Pattern Configure
Call Progress Analysis Class Configure
Tone Configure
Inseize Instruction List Configure
Implementing DSP Resources
Conferencing See Conferencing. Resource Create
Resource Connect
Resource Modify
Resource Disconnect
Play Files See Playing a File. DSP Service Request
DSP Service Cancel
Play File Start
Play File Modify
Play File Stop
Record Temporary Files See Recording Files. Record File Start
Tones See Tones. DSP Service Request
DSP Service Cancel
Connect Tone Pattern
Disconnect Tone Pattern
Developer Information
1243
Basic DSP Media Module Configuration Sequence
Configuration API Messages
The following API messages are used for general DSP Media module configuration.
Generic Card Configure 0x0122
Use this message to configure the DSP Media module for NFS, alarms, statistics, and module-level defaults.
DSP SIMM Configure 0x00C0
Use this message to configure DSP chips for specific functions.
IP Address Configure 0x00E7
Use this message to assign an IP Address to the DSP Media module for NFS functionality.
Service State Configure 0x000A
Use this message to take DSP chips in and out of service.
Configuration is maintained through warm starts, resets, and faults.
Procedure
The following is a basic configuration sequence for the DSP Media module.
1) Bring the DSP chip out of Service
Use the Service State Configure 0x000A message to bring the DSp chip out of service.
2) Configure DSP Function Types
Use the DSP SIMM Configure 0x00C0 message to assign function types on each SIMM. The default DSP configuration is shown in the message.
3) Download Additional Resource Points if required.
If your DSP resource requirements exceed the standard resources points that come with the main board and DSP Media module, you must download a license for more points.
See Downloading License Keys to the MSP
Also see DSP Resource Points in the DSP Media Module Product Description section for more information.
4) Configure NFS Servers (up to 8)
Use the Generic Card Configure 0x0122 message with the Announcement Configuration TLV (0x05DC).
a.) Server IP Address (for NFS)
The IP Address must be set on initial power up only.
b.) Configure Vocabulary Index File and Announcements
5) Configure Conferencing
MSP
1244
Use the Generic Card Configure 0x0122 message to set conferencing features and options. All conferences established will use these settings unless you override them on a per-conference basis with the Resource Create 0x0124 or Resource Modify 0x0125 message.
See Configuring Conferencing Features.
See Configuring Conferencing Options.
6) Customize Tones
Perform any tone customization required, such as for Call Progress Analysis.
See Digit Collection
7) Bring the DSP chip in Service
Use the Service State Configure 0x000A message to bring the DSP chip back in service.
Related Topic
Developer Information
1245
Call Processing Messages
The table below shows the API messages related to DSP resources.
DSP-Related API Messages
Category Message Description
File Playback Play File Start 0x011B
Play File Stop 0x011D
Play File Modify 0x011C
Use these messages to start, stop, or modify the playing of a file.
Recorded Announcement Connect 0x0055
Use this message to connect to a recorded announcement on the DSP Media module. Announcements must be accessible via NFS.
DSP Services DSP Service Request 0x00BD
DSP Service Cancel 0x00BE
Use these messages to allocate or cancel a DSP service on channel.
Tones Call Progress Analysis Result 0x0034
The MSP platform sends this message to report the result of Call Progress Analysis on a channel. Only one result is reported per message.
Connect Tone Pattern 0x002F
Use this message to transmit a call progress pattern ID to the specified channel. In order for the host to be notified when tone transmission has stopped, it must set the Generate Event Flag field of this message.
Disconnect Tone Pattern 0x001E
Use this message to terminate call progress tone transmission on the specified channel.
Conferencing Resource Create 0x0124
Use this message to create a conference.
Resource Delete 0x0126 Use this message to delete a conference.
Resource Modify 0x0125 Use this message to change the options or
MSP
1246
features of an existing conference.
Resource Delete Indication 0x0129
The MSP platform sends this message to the host after a conference is deleted.
Resource Connect 0x0127
Use this message to add a channel to a conference which has already been created.
Connect One-Way To Conference 0x004F
Use this message to establish a one-way (listen only) connection between the channel specified and the previously created conference specified.
Resource Disconnect 0x0128
Use this message to remove a channel from a conference.
General Alarm 0x00B9 This message is sent by the MSP platform to indicate alarm conditions on the DSP Media module.
See DSP Alarms in the DSP Media Module Product Description section for more information.
Card Status Report 0x00A6
This message is sent by the MSP platform to report the number of DSP modules and their function types configured on the DSP Media module.
Developer Information
1247
Administration API Messages
Feature Description
Overload Management
Statistics Query
DSP Alarms
API Messages
The following messages are used for queries and alarms.
Queries Generic Card Query 0x0123 Use this message to query the configuration of the DSP Media module for NFS, alarms, statistics, and card-level defaults.
Statistics Query 0x0121 Use this message to query cache and function usage statistics on the DSP Media module.
System Configuration Query Use this message to query various configuration settings in the MSP platform, including the following for DSP:
0x04 - Active Conference IDs
0x07 - Resource Threshold
0x09 - Resource Usage Reporting
0x10 - Detailed Conference Information
0x11 - DSP Resource Threshold
0x13 - Conference Speakers
0x14 - Conferencing Features
0x15 - Child Conference Information
0x16 - Child Conference IDs
System Resource Usage Query Use this message to query the following conferencing resource utilization information:
- Timeslots in use
- Timeslots available
MSP
1248
- Percent used
Generic Report This message is generated in response to the following DSP Query Types sent in the System Configuration Query message:
0x04 - Active Conference IDs
0x0A - Resource Usage
0x10 - Detailed Conference Information
0x13 - Conference Speakers
0x14 - Conferencing Features
0x15 - Child Conference Information
0x16 - Child Conference IDs
Tone Query 0x005A Use this message to query the transmit and receive tones assigned to a DSP, as well as the frequency and power levels of the tones.
Call Progress Analysis Configuration Query 0x008A
Use this message to query call progress analysis (CPA) configuration information.
Transmit Cadence Pattern Query 0x0059
Use this message to query any of the configured transmit cadence parameters.
Card Status Query 0x0083 Use this message to query the number of DSP modules and their function types configured on the DSP Media module.
General Alarm 0x00B9 This message is sent by the MSP platform to indicate alarm conditions on the DSP Media module.
See DSP Alarms in the DSP Media Module section for more information.
Card Status Report 0x00A6 This message is sent by the MSP platform to report the number of DSP modules and their function types configured on the DSP Media module.
Developer Information
1249
Configuring Overload Management
Configuration
To configure the overload threshold values, the number of times that the threshold must be exceeded (M), and the size of the sample window (N), use the Generic Card Configure 0x0122 message (0x0122) with the Alarm Threshold TLV (0x05EF) and these Alarm types:
0x0A CPU Idle Time
0x0B VRA Process Time
0x0C VRA IO Queue Time
Query
To query the overload thresholds, use the Generic Card Query 0x0123 message (0x0123) with the 0x05FA Card Object TLV.
To query the overload statistics, use the Statistics Query 0x0121 message (0x0121) with a slot AIB and the DSP Series 2 Overload Statistics (0x0616).
TLVs for DSP Media Module Overload Management
0x0616 DSP Series 2 Overload Statistics
0x0617 Alarm Threshold Query
0x0618 Alarm Threshold Enabled Report
MSP
1250
Record/Play Files
Recording Files
Feature Description
See File Record And Playback Overview.
Procedure
1) Record files using the Record File Start 0x011E and Record File Stop 0x0120 messages.
You should use File IDs above 0x00100000 for longer files and for files you want to keep for a significant period.
For temporary recordings, such as those used for to directory assistance requests, you should use File IDs below 0x00100000. You must play back the temporary file from the same DSP Media module on which they are recorded.
2) Create a Vocabulary Index File (VIF) to track recordings and point to files for playback.
See VIF Format in the DSP Media Module Card Product Description section.
3) Download the VIF to the DSP Media module using the 0x05DF Vocabulary Index File TLV in the Generic Card Configure 0x0122 message.
Recording API Messages
Record File Start 0x011E
Use this message to start recording a file.
Record File Stop 0x0120
Use this message to stop recording a file.
Record File Modify 0x011F
Use this message to modify the gain of a file recording, as well as to pause or resume the recording.
DSP Cache Modify 0x011A
Use this message to delete a file from cache, or copy a file from cache to permanent storage.
Deleting Files
To delete files, send the DSP Cache Modify 0x011A message.
Developer Information
1251
Full Duplex Channel Recording
This feature allows you to record both the inbound and outbound legs of a single channel. You can use this feature to record both channels in a connection within a single node or a multi-node system.
Implementation
To invoke this feature, send a Record File Start 0x011E message that contains a single Channel AIB and the Dual Channel Recording TLV (0x5ED). In the TLV you can select whether the channels are recorded summed or independently.
TLV Format
The format of the Dual Channel Record Option TLV is shown below:
0x05ED Dual Channel Record Option
Use this TLV to record both sides of a connection. This TLV allows you to choose whether you want each channel to be saved to its own file (Independent) or both channels to be saved to the same file (Summed).
This TLV is optional for the Record File Start 0x011E message.
Byte Value Description
0, 1 Tag 0x05ED Dual Channel Record Option
2, 3 Length 0x0001
4 Value[0] 0x00 - Sum Channels Together (Default)
0x01 - Independent Channels (file location is the same, but filename is appended with “_2” )
Example Call Trace
MSP
1252
Record File Start
H->X
00 78 01 1e 00 00 ff 00 02 0d 03 00 00 00 01 01 04
00 04 'Number of TLVs
05 e0 00 04 00 00 00 0a 'File ID
05 e1 00 02 00 01 'File Format
05 E2 00 15 00 01 00 02 5C 52 65 63 6F 72 64 5C 74 65 73 74 2E 75 6C 61 77 'File Location
05 ED 00 01 00 'Dual Channel Record - Summed
Developer Information
1253
Playing a File
You use the Play File Start and Play File Stop messages to control Playback of files.
Play File API Messages
Play File Start 0x011B
Use this message to start playing a file.
Play File Stop 0x011D
Use this message to stop playing a file.
Play File Modify 0x011C
Use this message to modify (gain or speed), pause, resume, skip forward, or skip backward in a file that is currently playing.
File Barge-in Mode
Transmission of a file in barge-in mode is supported. You must use the Play File Start message with the Barge In TLV (0x05E5).
You cannot initiate a another play file start that has barge in enabled, while a play file start is already in progress.
Specifying Offset and Length
You can specify the Offset and Length in one of two ways:
in two fields within the Vocabulary Index File
in the File Offset and Length TLV (0x0614) used in the Play File Start message. You can use the File Offset and Length TLV when queueing files, but you cannot use it when chaining files within a single message.
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.
Queuing Files
You can send multiple Play File Start messages and the files will be queued so that when one ends, the next one starts. This functionality works for all files, cached or un-cached, and with or without using the VIF file. There is no limit to the number of files you can queue, except for the limits imposed by memory.
You can also queue a chain of files using the Play File Start message by entering the number of files in the Number of Files field, and using the Play File Queue TLV.
When the first file in the queue is started, a Call Processing Event 0x002E message of File Started is generated, and when the last file in the queue has been played, a File Complete event is generated.
Failure Conditions
MSP
1254
If a Play File request has more than one file descriptor, the request is NACKed.
If a queued file cannot be opened, a CPE of Play File Queue Failure (0x33) is returned. All current requests in the queue are cleared and the DSP resource is freed.
If queueing causes memory to be used up, a File Queue Failed alarm is returned.
Playing a .wav File
You indicate the WAV format in the File Format TLV (0x05E1) in the following API messages:
Play File Start 0x011B
DSP Cache Modify 0x011A
NOTE: The .wav format is currently not supported for the Record File Start message.
Alarm
If there is an error reading a .wav file, the switch will not NACK the API message, but will send an informational Card Alarm of 0x4E in the Alarm 0x00B9 message:
Example 1: No RIFF Chunk Found (Alarm Subtype 0x00)
X->H
[00 19 00 b9 00 0c ff 01 02 4e 10 00 01 01 01 04 00 01 00 00 17 70 00 42 41 44 20]
Example 2: RIFF type .wav not found (Alarm Subtype 0x01)
X->H
[00 19 00 b9 00 0e ff 01 02 4e 10 00 01 01 01 04 00 01 00 00 17 71 01 42 41 44 20]
Developer Information
1255
Appending or Replacing Recorded Files
To append or replace a file, use the optional Append or Replace TLV (0x0615) in the Record File Start 0x011E message (0x011E).
Call Processing Events
There is a four-byte data field named Offset in the following Call Processing Events:
Play File Started
Play File Completed
Record File Started
Record File Completed
In the Play File Started and Record File Started events, the Offset represents the starting byte. In the Play File Complete and Record File Complete events, the Offset represents the ending byte.
The application is responsible for managing different encoding formats, and for designating how bytes represent time.
The Record File Started event is issued when the first block of data is written. The DSP Media module block size is 1 second, so this event occurs approximately 1 second after the Record File Start message is issued.
MSP
1256
Conferencing
Creating a Conference
Feature Description
See Unified Conference.
Pre-requisites
You must have DSP Chips configured for the conference type you are creating.
Procedure
1) Create the Conference
Use the Resource Create 0x0124 message to create the conference.
- AIB
Use the DSP Chip AIB to indicate the DSP Chip to be used for the conference. The DSP Chip selected must be configured for the Unified Conference (0x22) Function Type.
- Mandatory TLVs
0x0602 Resource Type: 0x0100 - Conference
0x0603 Channel/DSP Pool -select the appropriate pool of available DSP resources for the conference
- Optional TLS
Use optional TLVs to configure conference features and options.
See Conferencing Features TLVs
See Conferencing Options TLVs.
2) Add Conferees
Add Conferees using the Resource Connect 0x0127 message.
Manual Input Volume Control
This feature enables a manual volume control on a parties inbound leg to a conference. The Automatic Gain Control for that party is automatically disabled, and the requested gain is added to the conferee’s speech prior to being added to the conference.
You implement the Manual Volume Control feature using the 0x068B Input Gain Control TLV in the following messages:
Resource Create (0x0124)
Resource Modify (0x0125)
Resource Connect (0x0127)
Querying Active Speakers
Developer Information
1257
To query the active speakers of a conference, use the System Configuration Query message (0xB4) with the Conference ID AIB (0x55) and the Conference Speakers (0x13) query type. The Generic Report (0x46) message is returned with the conference data.
MSP
1258
Creating a Child Conference
Feature Description
See Child Conference in Unified Conferencing.
Dependencies and Considerations
If a party is removed from the parent conference, it will also be removed from the child conference if it is part of any.
A party can be in only one child conference at a time.
Only parties that are connected 2-way in a parent conference can be moved into a child conference.
A child conference inherits its conferencing features configuration from the parent conference at the time of its creation. You can modify the Conferencing Features configuration of the Child Conference with the Resource Modify 0x0125 message.
Play/Record Files into a child conferences is not supported.
Pre-requisites
You must already have a conference created (Parent Conference) from which to create the Child Conference.
Procedure
1) Create Child Conference
Use the Resource Create 0x0124 message to create the Child Conference.
- AIB:
Use the Child Conference AIB. In the AIB you indicate the Parent conference ID. The response to the Resource Create 0x0124 message will indicate the new Child Conference ID, which you then use when adding conferees to the Child Conference using the Resource Connect 0x0127 message.
- Mandatory TLV
0x0602 Resource Type: Child Conference (0x0107)
- Optional TLVs
Use optional TLVs to override default conference parameters if necessary.
See Conferencing Features TLVs
See Conferencing Options TLVs.
2) Add Conferees
Use the Resource Connect 0x0127 message to add conferees to a child conference.
Developer Information
1259
Removing Party from the Child Conference
Use the Resource Disconnect 0x0128 message to move a channel from a child conference back into the parent conference. The Resource Disconnect message uses the Channel AIB (0x0D) and the Child Conference ID AIB (0x45).
Deleting a Child Conference
Use the Resource Delete 0x0126 message (0x0126) to delete a Child Conference. The Resource Delete message uses the Child Conference ID AIB (0x45) to address the child conference to be deleted.
The Resource Delete Indication message (0x0129) indicates that the Child Conference has been deleted.
When a child conference is deleted forcibly, the channels connected to it are connected back to the parent conference and the child conference is immediately deleted.
When a child conference is deleted gracefully, the MSP platform waits until all the parties connected to the child conference are either removed or reconnected back to the parent conference before deleting the child conference. The default behavior is graceful deletion.
When a parent conference is deleted forcibly, all parties connected to the parent and the associated child conferences are removed, and the parent and all its child conferences are immediately deleted.
When a parent conference is deleted gracefully, the MSP platform waits until all parties in the parent and the associated child conferences are removed. When all parties connected to a child conference have been removed or reconnected back to the parent conference, the child conference is deleted. When all the child conferences have been deleted and no parties are left in the parent conference, the parent conference is deleted.
MSP
1260
Creating a Monitor Conference
Feature Description
See Monitor Conference.
Pre-requisites
You must have a DSP Chip configured for Monitor Conference.
Considerations
Channels can be connected to the conference after call setup. It is not necessary to know at setup time all of the callers that will eventually connect to the conference.
The call processing states of the source channels added to a monitor session are irrelevant. A source channel can be added to a monitor session with no effect on its current connection state. Subsequent state transitions of the channel have no effect on its association with the monitor conference.
The source channels connected to a monitor conference do not have to be associated with one another in any way.
Procedure
1) Create the Conference
Use the Resource Create 0x0124 message to create the conference.
- Mandatory TLVs
0x0602 Resource Type: 0x0100 - Conference
0x0603 Channel/DSP Pool: Select desired option.
0x0606 Monitor Conference Enable: 0x0001 - Enable
- Optional TLS
Use optional TLVs to configure conference parameters.
See Conferencing Features TLVs
See Conferencing Options TLVs.
2) Add Conferees
Add Conferees using the Resource Connect 0x0127 message.
When adding the monitor channel, use the 0x0612 Connection Type TLV to indicate a one-way connection (0x01).
Multiple Sessions
To create multiple sessions, you can use the source ports on a DSP resource, in any combination.
Developer Information
1261
For example, a DSP chip that is configured for the Monitor Conference function can provide the following:
Three 9-port sessions and one 7-port session
Six 5-port sessions and one 4-port session
17 two-port sessions
Deleting a Monitor Conference
You can delete a Monitor Conference by sending a Resource Delete 0x0126 message. Deletion can be either Forced or Graceful:
Forced Deletion
To release all channels in the conference and delete the conference using the Resource Delete 0x0126 message with the Forced Flag byte set to 0x01.
Graceful Deletion
To gracefully delete a Monitor Conference, release all monitor channels in the conference using the Release Channel message and then delete the conference using the Resource Delete 0x0126 message with the Forced Flag byte set to 0x00. All source channels are then automatically removed from the conference and the conference is gracefully deleted.
If you remove only the source channels from the Monitor Conference, the conference is not deleted. The conference retains its Conference ID and can be re-used.
Reconfiguring a Monitor Conference
To reconfigure an existing conference with new source channels, park the monitor channels using the Park Channel 0x00BF message. Removing the monitor channels from the conference (either by parking or releasing) automatically removes all of the source channels.
If a Resource Delete 0x0126 message that specifies graceful deletion has been sent, removing the monitor channels from the conference deletes the conference. When the source channels are removed, the monitor channels can then be reconnected to the conference, and new source channels connected using the same Conference ID number.
MSP
1262
Configuring Conference Features
See Conferencing Features.
You set conferencing features using TLVs in the following messages:
Generic Card Configure 0x0122
Resource Create 0x0124
Resource Connect 0x0127
Resource Modify 0x0125
Conferencing Features TLVs
Parameter Notes TLV(s)
Automatic Gain Control (AGC)
Automatic Gain Control (AGC) automatically detects variations in volume input and adjusts the input level to be within a decibel range that you can specify, in 1 dB increments.
If a conferee’s voice input (one conference leg) is either too quiet or too loud, AGC adjusts the input so that it falls within your specified acceptable range.
Default = Disabled
See Automatic Gain Control.
NOTE: You can implement the Manual Volume Control feature to override the dB of a conferee using the 0x068B Input Gain Control TLV.
See Manual Input Volume Control.
0x060C Automatic Gain Control Enable
0x060E Automatic Gain Control Parameters
0x060D Automatic Gain Control Input Level
0x068B Input Gain Control
Noise Gating During natural breaks in conversation (when the speaker on a channel is not speaking) if significant ambient noise is coming into a
Noise Gate Enable TLV (0x0608)
Noise Gate Parameters TLV (0x0609)
Developer Information
1263
conference from the speaker’s line, that noise can be gated using the Noise Gating feature. As a conference grows in size, ambient noise is more likely to become a problem.
You can customize the time span (time constant) over which noise is measured, in increments of 5 ms. You can also specify a maximum allowable estimated noise level in 1 dBm increments, from –54 dBm to –10 dBm.
Defaults
Disabled
Time Constant = 35
Maximum Noise Level = -20 (1 dBm steps)
Noise Gating Sensitivity = 3
See Noise Gating
Output Gain Control You can adjust gain from –40dB to +10dB, in increments of 1dB.
The MSP platform acts upon the most recent command. For example, if a change is made at the conference leg level and then at the conference level, the conference level setting overrides the leg level setting because that was the last change made.
Default = 0db
See Output Gain Control.
Output Gain Control (0x0607)
Echo Suppression If a conference leg is generating echoed signal, you can mute that echoed signal using the
Echo Suppression Enable (0x060A)
Echo Suppression Parameters TLV
MSP
1264
Echo Suppression feature. Note how this differs from echo cancellation. Echo Suppression adaptively measures the reflected signal input, and adapts its echo estimate up to a maximum noise value, which you can select in 1 dBm increments, from –54 dBm to –10 dBm.
Defaults
Disabled
Echo Return Loss (1 db steps) = -10
See Echo Suppression
(0x060B)
Conference Failure Behavior
You can configure a conference so that if the conference fails all the channels are parked.
The application is responsible for rebuilding the conference on another DSP resource or for releasing the conference legs.
Default = Purged
0x060F Conference Failure Behavior
Developer Information
1265
Configuring Conference Options
Conferencing Options TLVs
TLV
(Optional unless Noted)
Notes/Values
* = default
0x05E5 Barge In By default, Barge-In is enabled for conferencing. Include this TLV to disable it.
0x0000 - Disabled
0x0001 - Enabled *
0x0604 DTMF Clamping/Filtering Enable
Use this TLV to enable DTMF filtering.
0x0000 - Disabled*
0x0001 - Enabled
MSP
1266
Playing Files into a Conference
You can play a file into a conference using the Play File Start message.
Modifying a File Being Played
To modify a file that is playing to a conference, use the Conference AIB in the Play File Modify message and, optionally, the File ID TLV. If you use the File ID TLV, all instances of that File ID being played in the specified conference are modified. If the File ID TLV is absent, all the files playing into that conference are modified.
Stopping a File
To stop a file that is playing to a conference, use the Conference AIB and File ID TLV in the Play File Stop message. If the File ID TLV is absent, all the files playing into that conference are stopped.
Playing Multiple Files to a Conference
You can simultaneously play multiple files into a conference. The same File ID can be played multiple times. Any subsequent action on the playing file (such as Modify or Stop) identifies the file using a combination of the Conference ID and the Play File ID. Therefore, if you modify or stop a File ID, you cause the change to happen to all instances of that File ID being played in the specified conference.
File queues are not permitted when playing multiple files into a conference. Multiple file plays are not permitted when queued files are being played.
Resource Points
When playing multiple files into a conference simultaneously, standard Play File resource points are used for each Play File.
Developer Information
1267
Tones
Digit Collection
This section describes the API messages used for digit collection.
DSP Service Request
Use this message to allocate an appropriate digit receiver and attache it to the specified channel. The attached digit receiver uses the Call Processing Event 0x002E message to report digits as they are decoded, one at a time. The receiver remains attached to the channel until the channel is released or until the host cancels digit collection, with the DSP Service Cancel (0x00BE) message.
Collect Digit String
Use this message to allocate and attache a digit receiver to a channel. Unlike the DSP Service Request message, this message causes the MSP platform to collect a group of digits in sequence until termination condition occurs. The termination condition could be the detection of a particular digit from a termination digit set, a fixed number of digits collected, or a timeout.
Digit Collection After Call Setup
After a call is set up, the MSP platform collects DTMF digits interactively. The host collects additional information, either one digit at a time with the DSP Service Request message, or as a sequenced group of digits with the Collect Digit String message.
Collecting Inpulse Data on Specified Channels
Use the Inpulsing Parameters Configure message. Inpulsing parameters define the address signaling type, the number of digit strings, and the collection method used during call setup.
The MSP platform supports four different inpulsing stages, each with one or two digit strings. When the host is instructing the MSP platform to collect address signaling information (that is typically presented with in-band dual frequency tones) it also specifies a preprogrammed inpulsing stage that describes how to perform the digit collection.
The inpulsing stage configuration options include the following:
Address signaling type (DTMF, MFR1, MFR2)
Number of strings (1 or 2)
String collection method (fixed number digits, KP/ST framed, compelled)
Receiving Address Signaling Tones
Use the the Inseize Control message passes inseize instructions to the MSP platform for controlling incoming call setup in real time. The instruction, “Receive Stage N
MSP
1268
Address Data” allocates and attaches a DSP resource to a channel to collect an incoming digit stream.
Up to 100 digits can be collected within a given inpulsing stage. Use the Inseize Instruction List Configure (0x0029) message to preprogram instructions on a channel. See “Digit Collection During Call Setup” for more information. The instruction, Report Incoming Call With Address Digits, sends a Request For Service With Data (0x002D) message to the host, with single- or multiple-stage digit streams collected.
When the termination condition occurs, the MSP platform reports the entire group of digits collected, with the Call Processing Event 0x002E message. The receiver is then returned to the system receiver pool. If the configuration bit 4 is not set (or "by default") when the MSP platform detects the first valid digit, it automatically cancels any prompting tone or recorded announcement being played out to that channel.
Developer Information
1269
Generating Call Progress Tones
Configuration
1. If required, customize tomes using the Transmit Cadence Pattern Configure message.
2. Configure a DSP with one of the following function types using the DSP SIMM Configure 0x00C0 message:
0x30 - Universal Tone Generation µ-Law
0x31 - Universal Tone Generation A-Law
Procedure
1. Connect the tone generator to the channel using the Connect Tone Pattern message.
A call must be active (either incoming or outgoing) for a pattern to be generated.
If you want to be notified with a Call Processing Event 0x002E message (0x21 - Tone Complete) when tone transmission has stopped, set the Generate Event Flag.
MSP
1270
Performing Call Progress Analysis
Configuration
You must have a DSP configured with a Function Type for CPA:
0x07 - CPA A-Law
0x08 - CPA µ-Law
Initiate
You can initiate call progress in the following two ways:
During call setup, with the outseize instruction of Do Call Progress Analysis
Interactively, by assigning a CPA Receiver with the DSP Service Request message using the following values:
Service Type
0x03 - Call Progress Analysis Receiver
CPA Class
0x00 North American Default
0x01 Dialtone
0x02 CPC Detection
0x03 Energy Detection
Host Indications
A Call Progress Analysis Result message is sent to host when a pattern is detected.
A Call Processing Event 0x002E message is sent to host when a CP pattern is detected
Off-hook Detection
When CPA is initiated with the DSP Service Request message, detection of off-hook is reported if the signaling interface supports it.
Developer Information
1271
Outpulsing Tones
Outpulse Address Signaling Tones
For outbound calls, configure the MSP platform to generate DTMF, MFR1, or MFR2 address signaling to the downstream MSP platform or device. To initiate outpulsing, use the Outseize Control (0x002C) message with an action of “Outpulse Stage N Address Data.” Data ICBs in the Outseize Control (0x002C) message indicate the signaling tone type and the source of the digits. Digits can be specified in the Outseize Control (0x002C) message itself, or they can be taken from a list of previously-inpulsed digits. Digit durations are set by the PPL component on the associated line card.
Example
You set the following durations using PPL timers, and you modify them using the PPL Timer Configure message (0x00CF):
delay until the start of the first digit
“on” time of the first digit
“on” time of subsequent digits
"off” time between all digits
For DTMF and MFR1 digits, outpulsing can also be initiated using the Outpulse Digits (0x0020) message. Within the message, you can specify the following durations:
delay until the start of the first digit
“on” time of the first digit
“on” time of subsequent digits
“off” time between all digits
Durations are specified in units of 10 milliseconds. Actual outpulsed durations, however, are truncated to 20 millisecond intervals. So a digit duration specified as a multiple of 20 milliseconds is outpulsed with that duration, while other digit durations are shortened.
For example, digits with a specified duration of 20, 40, or 60 milliseconds are outpulsed with those durations. But a digit with a specified duration of 30 milliseconds is truncated to have a 20 millisecond duration upon outpulsing.
Similarly, 50 milliseconds is outpulsed as 40 milliseconds, 70 milliseconds is outpulsed as 60 milliseconds, and so on. Because of the truncated durations, you should set a minimum outpulse duration for 20 milliseconds or greater.
The host dynamically configures the dBm levels of DTMF, MFR1, and MFR2 transmit tones, using the Tone Configure message (0x0031). Power levels are updated globally for each tone type. For DTMF tones, you must specify the dBm level for both low-band and high-band frequency components. For MFR1 and MFR2 tones, you must specify only one dBm level.
Off-hook Detection
MSP
1272
When CPA is initiated with the DSP Service Request message, detection of off-hook is reported if the signaling interface supports it.
For example, you can configure the CPA receivers to detect a fax machine that the MSP 1010 has called. When the connection is made, the fax machine sends back a pattern containing Tone 0x0E (2100 Hz) continuously for approximately 2.3 seconds.
To configure the CPA receivers to detect this signal:
1. use the CPA Pattern Configure message to create a new pattern, consisting of Tone 0x0E continuously ON for a minimum of 2 seconds.
2. Add this pattern to a CPA Class using the CPA Pattern Configure message (described next). Whenever CPA is performed using that CPA Class, the CPA receiver scans for the fax signal.
Developer Information
1273
Customizing Tones
Feature Description
See Tone Overview.
Overview
Many telephone networks require call progress tones with different patterns of frequencies, at different intervals. For example, the MSP 1010 may need to provide a different cadence of the Ringback Pattern based on the called party address. To ensure network compatibility, you may need to adjust the attributes of the call progress tones.
Interval Durations
Interval durations are specified in units of 10 milliseconds. However, actual transmitted durations are truncated to 20 millisecond intervals. So an interval duration specified as a multiple of 20 milliseconds is transmitted with that duration, while other interval durations are shortened.
For example, intervals with a specified duration of 20, 40, or 60 milliseconds are transmitted with those durations. But an interval with a specified duration of 30 milliseconds is transmitted with a 20 milliseconds duration, an interval with a specified duration of 70 milliseconds is transmitted with a 60 milliseconds duration, and so on. Because durations are handled this way, your shortest interval duration should be 20 milliseconds.
Restoring Default Settings
To restore default settings for the transmit tone parameters, send the Reset Configuration (0x000B) message.
MSP
1274
Customizing Call Progress Tone Detection
The MSP platform allows the host to modify both the tones and the cadence of call progress tone patterns. When you modify a tone or a pattern, you affect all DSP chips that are configured to receive it.
You can modify the default settings for any Tone ID, using the Tone Configure message. Changing the specifications of a Tone ID affects all patterns in the MSP 1010 that are using that Tone ID.
The default parameter values for each call progress analysis tone pattern are shown in the Specifications section in the DSP Media Module Product Description section. To modify these values, use the CPA Pattern Configure message.
Modifying a Call Progress Receive Tone:
You specify only the frequencies in the tone.
For example, to configure a CP Receive tone made up of the frequency 400 Hz, use the Tone Configure message to:
1. Set the number of frequencies making up the tone (Data 2) to 1.
2. Set the first frequency value to 400. You do no need to set any other frequency values
To delete a Call Progress Receive Tone, use the Tone Configure message and set the number of frequencies to 0. No frequency data needs to be sent.
Creating a New Pattern
You can modify patterns and create new patterns, using the Call Progress Analysis Pattern Configure message.
1. Modify the Tone IDs in the pattern if required.
2. Assign a unique Pattern ID, within the range of 0x01 – 0x1F. You must maintain an accurate list of current Pattern IDs and their specifications.
3. Add the pattern to a class with the Call Progress Analysis Class Configure message.
To minimize reconfiguration time, set the Update All Flag in only the last configuration message that you send.
Example
Assume the MSP platform is connecting to a fax machine. When the connection is made, the fax machine continuously sends back a pattern containing Tone 0x0E (2100 Hz) for approximately 2.3 seconds.
To configure the CPA receivers to detect this signal
1. Use the CPA Pattern Configure message to create a new pattern consisting of Tone 0x0E continuously ON for a minimum of 2 seconds.
2. Add this pattern to a CPA Class using the CPA Pattern Configure message.
Developer Information
1275
Whenever CPA is performed using that CPA Class, the CPA receiver scans for the fax signal.
Restoring Default CPA Settings
To restore default settings for the transmit tone parameters, send the Reset Configuration message to the MSP.
MSP
1276
Example: Customizing a Pattern ID
The following example shows how to configure Pattern ID 0x17 to receive a three-second, 400 Hz tone. To perform this task, send three API messages as follows:
1. Send the Tone Configure message to replace the default tone (Tone ID 0x0F, 425 Hz) with the new, 400 Hz tone.
Tone Type: 0x06
Action: 0x01
Data[0] Tone ID being changed: 0x0F
Data[2] Number of frequencies in tone: 0x01
Data[4] Frequency Value[0], Hz, MSB: 0x01
Data[5] Frequency Value[0], Hz, LSB: 0x90
2. Send the CPA Pattern Configure message to create the new Pattern ID 0x17.
Update All Flag: 0x01
Pattern ID: 0x17
Action: Add/Replace Pattern: 0x01
Data[0] Pattern ID to report on detection: 0x17
Data[1] Tone Group ID: 0x00
Data[2] Pattern Configuration: 0x01
Data[3] CPA Report on Pattern Loss: 0x17
Data[4] Interval Cycles to Match: 0x01
Data[5] Interval Cycles to Report: 0x01
Data[7] Interval Descriptor Count: 0x01
Data[8] Tone ID: 0x0F
Data[10] Minimum filter (in 10 ms units) MSB: 0x00
Data[11] Minimum filter (in 10 ms units) LSB: 0x50
Data[12] Maximum filter (in 10 ms units) MSB: 0x00
Data[13] Maximum filter (in 10 ms units) LSB: 0x00
3) Send the CPA Class Configure message to add Pattern 0x17 to the CPA class 0x00.
Update All Flag: 0x01
Class ID: 0x00
Action: 0x01
Data[0] Pattern ID: 0x17
Developer Information
1277
Configuring Energy Detection
Feature Description
See Energy Detection.
Overview
Energy Detection allows the MSP platform to perform Call Progress Analysis for frequencies not supported by default. The Energy Detection DSP function matches cadences, based on the reported energy levels. CPA Class 3 is preconfigured for Energy Detection, using the standard CPA tones of ringback, double ringback, busy, and re-order.
To accommodate unique requirements for matching cadences, you can modify these patterns or add new patterns to the class and change the pattern cadence that energy detection scans for, using the CPA Pattern Configure message.
Procedure
Use the Call Progress Analysis Class Configure 0x00B3 message to configure the parameters for energy detection:
1) Set Sensitivity Level
The Sensitivity Level is the amplitude above which the energy detector perceives a signal. Set the sensitivity level to detect and report energy that is greater than the prevailing background noise. When you expect a significant background noise, use the least sensitive setting (0 dBm). When you expect little background noise, use the most sensitive setting (-30 dBm). See the table below for sensitivity options. This table shows the values you would enter in the Call Progress Analysis Class Configure 0x00B3 message.
Set Sensitivity Level
Message Field Values
Class ID Class to be changed
Action 0x03 (Change Class Parameter)
Data[0] Parameter 0x0B (Mode Specific 1)
Data[1] Reserved 0x00
Data[2] Sensitivity Level See message for values.
2) Set the Scan Duration
The Scan Duration is the repeating time interval over which the energy detector determines that energy is either Present or Not Present. Set the scan duration to be longer than expected energy bursts. You must use 20 millisecond intervals to set the scan duration, so energy is sampled for each 20 millisecond block within the specified duration.
MSP
1278
The table below shows the values you would enter in the Call Progress Analysis Class Configure 0x00B3 message.
Scan Duration Fields
Message Field Values
Class ID Class to be changed
Action 0x03 (Change Class Parameter)
Data[0] Parameter 0x0C (Mode Specific 2)
Data[1,2] Scan Duration 16-bit word defining the scan duration, in 10ms units
3) Set the Completion Timer
The completion timer determines the maximum amount of time to scan for energy. Each scan cycle, as defined by the scan duration, is repeated until either energy is detected, or the completion timer expires. Cantata recommends setting the completion timer for 3 to 4 times the scan duration, depending on the application. If the timer expires before energy is detected, the host receives a Call Processing Event 0x002E message of “No Energy Detected.”
Configure CPA Class for Energy Detection
You can configure the default CPA classes for Energy Detection by enabling it in the Call Progress Analysis Class Configure 0x00B3 message, as shown in the table below.
Changing mode parameters
Message Field Values
CLASS ID Class to be changed
ACTION 0x03 (Change Class Parameter)
DATA[0] Parameter 0x01 (Mode)
DATA[1] Reserved 0x00
DATA[2] Mode 0x02 (Energy Detection enabled)
Developer Information
1279
Invoking Energy Detection
Overview
You can invoke Energy Detection in the following two ways:
Interactively, with the DSP Service Request message
As part of Call Progress Analysis
Interactive Energy Detection
You can invoke Energy Detection interactively, with the DSP Service Request 0x00BD message. Use the data bytes of the message to configure the sensitivity level, reporting mode, scan duration, and completion timer.
You also set how detected energy is reported to the host in a Call Processing Event 0x002E message. There are two modes:
Report Initial Energy Detection Only
The host receives a Call Processing Event of “Energy Result Report” with Data[0], indicating Energy Detected. Data[1] indicates the duration of the period of no energy. The DSP resource is then automatically released.
Report All Energy Threshold Crossings
All of the following are reported: the initial energy detection, all subsequent changes, and the duration of the previous state’s ON or OFF interval.
When energy (A) is first detected, the host receives a Call Processing Event of “Energy Result Report” with Data[0] indicating “Energy Detected.” Data[1] indicates the duration of the preceding period of no energy (D1).
When energy is no longer detected (B), the host receives a Call Processing Event message of “Energy Result Report” with Data[0] indicating “No Energy Detected.” Data[1] indicates the duration of the preceding period of energy (D2).
MSP
1280
Echo Cancellation
Echo Canceller Overview
The DSP Media module Echo Canceller removes echoes caused by signal leakage at hybrid telephone line interfaces. You may want to implement an Echo Canceller for tandem calls on trunks with echo, or to clean an incoming signal before connecting to a media resource, such as a VRU or AMD.
Call Processing Event
The following event is sent in a Call Processing Event 0x002E message when a G.164 tone disabling event occurs on the near or far end.
Event: 0x49 - Echo Canceller Event
Alarm
A General Alarm (0x41) is sent in the Alarm 0x00B9 message when the Host requests to attach a receiver to a channel that already has an Echo Canceller attached but there is no resource available on the same slot as the Echo Canceller resource. This means that the receiver will not receive the output of the Echo Canceller, but will receive the original signal with any echo that may be present.
Resource Modify NACK
The following response status values may be returned for the Resource Modify 0x0125 message:
0x1708 - No Active Echo Canceller
Returned when the switch receives a Resource Modify message with the Resource Type of Echo Canceller and there is no Echo Canceller attached to the Channel.
0x1709 - Invalid Echo Canceller State
Returned when the switch receives a Resource Modify message with the Resource Type of Echo Canceller and there is no Echo Canceller attached to the Channel.
Developer Information
1281
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
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
MSP
1282
Implementing Echo Cancel on a Tandem Call with Positive Voice Detection
The following procedure details the steps for attaching an Echo Canceller to a conference leg, and then recording the output.
Prerequisites
You must have a DSP chip configured with the Echo Cancel function. See Configuring Echo Cancel.
Guidelines
The Echo Cancel function must be on the same DSP chip as the channel(s) to which you are connecting it.
You must attach the Echo Canceller to the channel before you connect the channel to any other DSP receiver.
Procedure
1) Connect Channels using the Connect 0x0000 message.
2) Attach Echo Cancel receiver using the Resource Connect 0x0127 message.
AIBs
A: Span/Channel (channel to attach Echo Cancel function)
B: Slot (of DSP Media module).
If using an additional DSP receiver, it must be on the same card that has Echo Cancel. Otherwise, enter a wild card and the best available card will be used based on resources available.
Mandatory TLV
0x0602 Resource Type
Resource Type = Echo Cancel (0x0108)
Optional TLVs (to override default card parameters)
0x0673 Echo Cancel Tap Length
0x0674 Echo Cancel NLP Type
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
3) Attach Positive Voice Detection receiver to channel using the Resource Connect 0x0127 message.
AIBs
Developer Information
1283
A: Span/Channel (channel to attach PVD function)
B: Slot (same DSP Media module as Echo Cancel receiver).
Mandatory TLV
0x0602 Resource Type
Resource Type = PVD/AMD (0x0109)
4) Optional TLVs (to override default card parameters)
When call is complete, disconnect Echo Canceller using the Resource Disconnect 0x0128 message.
AIBs
Source Channel: Span/Channel
Mandatory TLV
0x0602 Resource Type
Resource Type = Echo Cancel (0x0108)
Optional TLVs
None
5) Disconnect PVD receiver using the Resource Disconnect 0x0128 message.
AIBs
Source Channel: Span/Channel
Mandatory TLV
0x0602 Resource Type
Resource Type = PVD/AMD (0x0109)
Optional TLVs
None
Example Call Trace
X->H
[00 0d 00 40 00 00 ff 00 01 0d 03 00 20 00 00]
H->X
[00 0d 00 ba 00 01 ff 00 01 0d 03 00 20 00 01]
X->H
[00 07 00 ba 00 01 ff 00 10]
Park Channel span/channel 20/00
H->X
[00 12 00 bf 00 02 ff 00 02 0d 03 00 20 00 0d 03 00 20
00 00]
X->H
[00 07 00 bf 00 02 ff 00 10]
X->H
MSP
1284
[00 0d 00 40 00 01 ff 00 01 0d 03 00 20 01 00]
H->X
[00 0d 00 ba 00 03 ff 00 01 0d 03 00 20 01 01]
X->H
[00 07 00 ba 00 03 ff 00 10]
Park Channel span/channel 20/01
H->X
[00 12 00 bf 00 04 ff 00 02 0d 03 00 20 01 0d 03 00 20
01 00]
X->H
[00 07 00 bf 00 04 ff 00 10]
Connect span/channel 20/00 and span/channel 20/01
H->X
[00 11 00 00 00 05 ff 00 02 0d 03 00 20 00 0d 03 00 20
01]
X->H
[00 07 00 00 00 05 ff 00 10]
Resource Connect 20/00- Echo Canceller
H->X
[00 17 01 27 00 00 ff 00 02 0d 03 00 20 00 01 01 ff 00
01 06 02 00 02 01 08]
X->H
[00 19 01 27 00 00 ff 00 10 00 02 0d 03 00 20 00 01 01 04 00
01 06 02 00 02 01 08]
Record File Start 20/00
H->X
[00 46 01 1e 00 06 ff 00 02 0d 03 00 20 00 01 01 ff 00
06 05 e0 00 04 00 dc 5b 17 05 e1 00 02 00 01 05 e2 00
13 00 01 00 02 2f 50 61 74 45 63 68 6f 2f 6d 79 2e 72
61 77 05 e9 00 02 02 26 05 fb 00 01 ca 05 e6 00 01 0c]
X->H
[00 11 01 1e 00 06 ff 00 10 00 02 0d 03 00 20 00 01 01 04]
H->X
[00 0c 01 20 00 07 ff 00 01 0d 03 00 20 00]
X->H
[00 0e 01 20 00 07 ff 00 10 00 01 0d 03 00 20 00]
X->H
[00 19 00 2e 00 00 ff 00 01 0d 03 00 20 00 35 00 dc 5b 17 00
02 00 00 00 04 00 00]
H->X
[00 05 00 2e 00 00 ff]
Developer Information
1285
Implementing Echo Cancel on a Conference Leg
Introduction
The following procedure details the steps for attaching an Echo Canceller to a conference leg, and then recording the output.
Prerequisites
You must have a DSP chip configured with the Echo Cancel function. See Connecting to an ASR (Automatic Speech Recognition) Server.
Guidelines
The Echo Canceller must be attached to the channel before you connect it to the conference or to another DSP receiver.
Procedure
1) Park the channel using the Park Channel 0x00BF message.
2) Create the conference using the Resource Create 0x0124 message.
3) Attach Echo Canceller to channel using the Resource Connect 0x0127 message.
AIBs
Resource A: Channel (Input to Echo Canceller)
Resource B: Slot (of card where conference resides)
Mandatory TLV
0x0602 Resource Type
Resource Type = Echo Cancel (0x0108)
Optional TLVs (to override default card parameters)
0x0673 Echo Cancel Tap Length
0x0674 Echo Cancel NLP Type
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
4) Connect Channel to Conference using Resource Connect 0x0127 message.
5) Attach other DSP Resources as required, such as Record Conference Leg using Record File Start 0x011E message.
6) Disconnect Echo Canceller using the Resource Disconnect 0x0128 message.
MSP
1286
AIBs
Source Channel: Span/Channel
Mandatory TLV
0x0602 Resource Type
Resource Type = Echo Cancel (0x0108)
Optional TLVs
None
Example Call Trace
Park Channel span/channel 20/00
H->X
[00 12 00 bf 00 09 ff 00 02 0d 03 00 20 00 0d 03 00 20
00 00]
X->H
[00 07 00 bf 00 09 ff 00 10]
Resource Create - Conference
H->X
[00 20 01 24 00 0c ff 00 01 22 03 00 ff ff 00 03 06 02
00 02 01 00 06 03 00 02 00 00 06 13 00 02 00 06]
X->H
[00 1e 01 24 00 0c ff 00 10 00 01 22 03 04 06 02 00 02 06 10
00 04 00 00 fd fe 06 02 00 02 01 00]
Resource Connect 20/00- Echo Canceller, use slot 4
H->X
[00 17 01 27 00 00 ff 00 02 0d 03 00 20 00 01 01 04 00
01 06 02 00 02 01 08]
X->H
[00 19 01 27 00 00 ff 00 10 00 02 0d 03 00 20 00 01 01 04 00
01 06 02 00 02 01 08]
Resource Connect 20/00- Connect Leg to Conference
H->X
[00 1e 01 27 00 0e ff 00 02 0d 03 00 20 00 55 02 fd fe
00 02 06 02 00 02 01 00 06 12 00 02 00 00]
X->H
[00 1a 01 27 00 0e ff 00 10 00 02 0d 03 00 20 00 55 02 fd fe
00 01 06 02 00 02 01 00]
Record File Start 20/00
H->X
[00 46 01 1e 00 12 ff 00 02 0d 03 00 20 00 01 01 ff 00
Developer Information
1287
06 05 e0 00 04 00 dc 5b 17 05 e1 00 02 00 01 05 e2 00
13 00 01 00 02 2f 50 61 74 45 63 68 6f 2f 6d 79 2e 72
61 77 05 e9 00 02 02 26 05 fb 00 01 ca 05 e6 00 01 0c]
X->H
[00 11 01 1e 00 12 ff 00 10 00 02 0d 03 00 20 00 01 01 04]
MSP
1288
Media Streaming over RTP
Real-Time Transport Protocol Overview
RTP, the real-time transport protocol, provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multi-cast or uni-cast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.
TLVs Used
The following TLV is used to enable RTP:
0x0687 - Enable RTP for Play/Record File
The following TLVs are used when implementing Positive Voice Detection with RTP.
0x0688 - RTP Record Mode
0x0689 - Start/Stop Sending RTP Packets
0x068A - Calender Time Offset for Sending RTP Packets
Resource Points
No additional DSP Resource Points are used for Play/Record with RTP beyond whatever are required for Play/Record.
Developer Information
1289
Connecting to an ASR (Automatic Speech Recognition) Server
You connect to an Automatic Speech Recognition server over RTP using the Record File Start 0x011E message. If you are also using Positive Voice Detection, you would use the Record File Modify 0x011F message.
Basic Implementation
You would use the Record File Start 0x011E message with the following TLVs:
Mandatory TLVs
0x0687 - Enable RTP for Play/Record File (0x01 - Enable)
0x29FF Media Local End Point Information
0x2A00 Media Remote End Point Information
Nested TLVs (used with 0x29FF and 0x2A00)
0x2A01 Media Per Stream Information
0x2A07 Media Port
0x2A0E Media Connection Address
See About Nested TLVs for Media Streaming
Optional TLVs
0x0688 - RTP Record Mode (to use RTP with Positive Voice Detection)
Example Call Trace
00 78 01 1e 00 00 ff 00 02 0d 03 00 00 00 01 01 04
00 0b 'Number of TLVs
MSP
1290
05 e0 00 04 00 00 00 0a 'File ID Tag
05 e1 00 02 00 01 'File Format
05 e3 00 01 03 'Optional Gain Tag
05 e6 00 01 0c 'Optional File Event Descriptor
05 e8 00 05 00 03 e8 c8 fd 'Optional Beep Tone Parameters
05 e9 00 02 ff ff 'Disable Initial Silence Timer
05 ea 00 02 ff ff 'Optional Final Silence Timer
06 87 00 01 01 'Enable RTP
06 88 00 01 00 'Optional Record Mode Continous Recording
29 ff 00 14 'Local End Media Info
2a 0e 00 04 87 77 2c 3c 'Local Media Connection Address
2a 01 00 08 'Per Media Stream Information
2a 07 00 04 00 00 17 70 'Local Media Port
2a 00 00 14 'Remote End Media Info
2a 0e 00 04 87 77 2c 32 'Remote Media Connection Address
2a 01 00 08 'Per Media Stream Information
2a 07 00 04 00 00 17 72 'Remote Media Port
Developer Information
1291
Connecting to an ASR with Positive Voice Detection
NOTE: This feature is not supported in this release.
If you have enabled RTP with the Positive Voice Detection (in the Record File Start 0x011E message), you would start/stop sending RTP packets using the Record File Modify 0x011F message with the following TLVs:
0x0689 - Start/Stop Sending RTP Packets
0x068A - Calender Time Offset for Sending RTP Packets
Pre-requisite
You must have Positive Voice Detection enabled and implemented. See Implementing Positive Voice Detection/Answering Machine Detection.
Message Sequence
MSP
1292
Connecting to a TTS (Text-to-Speech) Server
You connect to a Text-to-Speech server over RTP using the Play File Start message.
Basic Implementation
You send the Play File Start 0x011B message with the following TLVs:
Mandatory TLVs
0x0687 - Enable RTP for Play/Record File (0x01 - Enable)
0x29FF Media Local End Point Information
0x2A00 Media Remote End Point Information
Nested TLVs (used with 0x29FF and 0x2A00)
0x2A01 Media Per Stream Information
0x2A07 Media Port
0x2A0E Media Connection Address
See About Nested TLVs for Media Streaming
Example Call Trace
00 6b 01 1b 00 0b ff 00 02 0d 03 00 00 00 01 01 ff 01
00 08 'Number of TLVs
05 e0 00 04 00 00 00 0a 'File ID Tag
05 e3 00 01 03 'Optional Gain Tag
05 e6 00 01 03 'Optional File Event Descriptor
06 14 00 08 00 00 00 00 00 04 E2 00 'Optional File Offset/Length
2a 0a 00 02 00 f0 'Optional Payload Size (3rd party tool compatability)
06 87 00 01 01 'Enable RTP
Developer Information
1293
29 ff 00 14 'Local End Media Info
2a 0e 00 04 87 77 2c 3c 'Local Media Connection Address
2a 01 00 08 'Per Media Stream Information
2a 07 00 04 00 00 17 70 'Local Media Port
2a 00 00 14 'Remote End Media Info
2a 0e 00 04 87 77 2c 32 'Remote Media Connection Address
2a 01 00 08 'Per Media Stream Information
2a 07 00 04 00 00 17 72 'Remote Media Port
MSP
1294
About Nested TLVs for Media Streaming
The Media Streaming over RTP feature uses nested TLVs. The following provides an overview and example of nested TLVs. An API message can contain nested TLVs. These TLVs are nested into the value field of another TLV in order to capture multiple properties of a call within one TLV.
The following applies to these nested TLVs.
The TLV Count fields in the API message accounts for parent TLVs but not the nested TLVs. The Length field in any parent TLV counts the bytes in all of its nested TLVs.
The same TLV can be used multiple times within the same message depending on the context of the nested TLVs.
Example
Developer Information
1295
PVD/AMD
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
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
MSP
1296
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.
Developer Information
1297
T.30 Fax
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. 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
MSP
1298
ISDN
Introduction to ISDN
The Cantata Technology Integrated Services Digital Network (ISDN) product provides multiple communications tasking (voice, data, compressed),128 Kbps high-speed and high-bandwidth service. ISDN, non-compressed (512 KBps compressed) also provides on-demand service, connects up to eight devices simultaneously, and can be call managed. The basic configuration is 23+D (Primary Rate Interface) and 30B+D outside of North America.
The ISDN component, in conjunction with the T1 and E1 network interface, interfaces to various equipment types supporting the ISDN PRI protocol. These include tandem (Class 4) switches, end office (Class 5) switches, PBXs, and proprietary implementations, not only in North America but throughout the world. See Supported Features.
Configuration
For information on configuring the ISDN protocol on an MSP 1010, see the following:
Configuring ISDN
ISDN D Channel Configuration
B Channel Configuration
Configuring the Backup D Channel
For information on configuring ISDN using the MSP 1010 graphical user interface, ClientView, see Example Configuration for ISDN.
Implementation
The Excel ISDN PRI implementation is based on ITU-T Q.921 and Q.931 specifications. Each implemented variant references the appropriate interface document supplied by the equipment manufacturer. The interface document is usually a variant of the ITU-T recommendations.
Since each manufacturer supports different services, the host manages the information to send and receive in specific messages. This lets you access many features and services at the host layer and carry them out using PPL-controlled, call control logic.
Each ISDN component supports 32 D channels. Each D channel provides the High Data Link Control (HDLC) communications over T1 or E1 on one timeslot on the span. Each D channel can control up to 19 other spans in addition to the span on which it is located. See Diagram.
National ISDN PRI NI 2
The MSP 1010 system software ISDN stack supports National ISDN PRI NI 2. National ISDN PRI supports Non-Facility Associated Signaling (NFAS), allowing up to 30 DS1 interfaces and the D channel backup procedure, as well as B channel availability and provisioning. Connection endpoint variants are defined for National ISDN User side and Network side.
Developer Information
1299
Customization
Depending upon the provisioning requirements, you can have one D channel per span [Facility Associated Signaling (FAS)], or one D channel managing up to 20 spans [Non-Facility Associated Signaling (NFAS)]. You can control a total of 32 spans using all FAS D channels, or up to 20 spans per NFAS D channel (to a maximum of 32 spans per system, that is 28 bearer and four signaling spans). You can intermix both FAS and NFAS D channels on a card with each supporting a different variant. NFAS spans can be configured dynamically during call processing.
The MSP 1010 has a single ISDN component assigned to slot 8. This has access to all timeslots. Therefore, you can configure any timeslot in the system as a D channel
See NFAS and FAS Examples
MSP
1300
ISDN Architecture
The modules that form the ISDN PRI software architecture are:
Layer 3 Plus
Layer 3
Layer 2
Configuration
Management
Diagram
The next diagram illustrates the functional modules involved in the PRI implementation on an ISDN component.
Developer Information
1301
Configuring ISDN
This section describes the procedures for configuring primary rate ISDN and National ISDN PRI NI 2. The first four steps of the basic ISDN configuration are described in more detail in other parts of this documentation:
Span Configuration
D Channel Configuration
B 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 API Message
1 Configure Spans -Assign Logical Span IDs
- Configure span formats
Assign Logical Span ID
T1 Span Configure
E1 Span Configure
2 Configure the D channels
- Assign D channels
- Configure D channels
- Add NFAS Facilities
D Channel Assign
ISDN Interface Configure
D Channel Facility List Configure
3 Configure the B channel
Configure B channel options
B Channel Configure
4 Optional Configuration
- PPL Customization
- Features
5 Bring spans and channels in service
Bring spans, D channels, and B Channels in service
Service State
MSP
1302
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
1 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.
2 Assign logical span IDs to spans and channels. Use the Assign Logical Span ID (0xA8) message.
3 Configure the T1 Span. Use the T1 Span Configure (0xA9) message.
4 Assign a channel as an ISDN PRI D channel. Use the D Channel Assign (0xC4) message.
5 Define the connection type for National ISDN PRI NI 2 user side as 0x09. Use the ISDN Interface Configure (0x60) message.
6 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)
For Facility Number, select 0x01-0x1E, depending on the number of spans being added.
7 Define the network type for the B channels. Use the B Channel Configure (0xC8) message.
For the Network Type (0x01) field, select 0x01 (Do Not Include Network-Specific Facilities IE)
8 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).
Developer Information
1303
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.
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.
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.
Example
The following is an example of the ISDN Query message to query the General Interface Options and the response from the MSP 1010.
API Message
Trace H->X FE 00 0E 00 63 00 00 01 00 01 0D 03 00 01 17 01 00
Byte Field Description Value and Indication
0 Frame 0xFE
1, 2 Length 0x000E
3, 4 Message Type 0x0063
5 Reserved 0x00
6 Sequence Number 0x00
7 Logical Node ID 0x01
8 AIB Address Method 0x00 (Single Entity)
9 Number of Address 0x01
MSP
1304
Elements
10 Address Element Type
0x0D (Channel)
11 Data Length 0x03
12, 13
Data[0,1] Logical Span ID
0x0001
14 Data[2] Channel 0x17 (Channel 23)
15 Query Type 0x01 (General Interface Options)
16 Query Subtype 0x00 (None)
17 Checksum 0xCS (not shown in trace)
API Response
Trace X->H FE 00 1B 00 63 00 00 01 00 10 00 01 00 00 00 01 00 00 00 01 00 01 00 01 00 01 00 03 00 00
Byte Field Description Value and Indication
0 Frame 0xFE
1, 2 Length 0x001B
3, 4 Message Type 0x0063
5 Reserved 0x00
6 Sequence Number 0x00
7 Logical Node ID 0x01
10, 11 Data[0,1] Connection Type 0x0001 (Lucent 4ESS)
12, 13 Data[2,3] Options 0x0000 (No options)
14, 15 Data[4,5] D Channel Physical Medium 0x0001 (64 Kbps)
16, 17 Data[6,7] HDLC Bit Polarity 0x0000 (Normal)
18, 19 Data[8,9] Network Side Layer 2 0x0001 (Network Side (C/R Bit Inverted))
20, 21 Data[10,11] B Channel Selection Mode 0x0001 (Linear Clockwise)
22, 23 Data[12,13] Location 0x0001 (Private Network/Local User)
24, 25 Data[14,15] Channel Release Request on ISDN Disconnect
0x0001 (Send Host Channel Release Request on ISDN Disconnect)
Developer Information
1305
26 Data[16,17] Protocol Discriminator Value for Maintenance Messages
0x0003 (Default)
28 Data[18,19] B Channel Encoding for Transmission 0
x0000 (Channel Number)
30 Checksum 0xCS (not shown in trace)
MSP
1306
Network Side Euro-ISDN
The ISDN software module supports network side Euro-ISDN PRI variant. This allows an MSP 1010 to handle basic call control, interfacing with a user-side.
ETSI specification support
The following is supported as defined in the applicable ETSI specification:
All procedures, messages, and message content defined as mandatory for network side functionality.
All call states supported in Cantata’s ISDN PRI user side implementation.
All network side call setup and tear-down procedures.
All mandatory, bidirectional (network-to-user and user-to-network), circuit mode connection control messages.
All mandatory network-to-user messages.
All information elements that are designated as mandatory for network-to-user side messages.
All timer values.
All network side error handling procedures.
Supported Q.931 Messages
The following Q.931 messages are supported:
Call establishment
ALERTING
CALL PROCEEDING
CONNECT
CONNECT ACKNOWLEDGE
PROGRESS
SETUP
SETUP ACKNOWLEDGE
Call information phase messages
USER INFORMATION
Call clearing messages
DISCONNECT
RELEASE
RELEASE COMPLETE
Developer Information
1307
Miscellaneous
FACILITY
INFORMATION
NOTIFY
STATUS
STATUS ENQUIRY
Other
REGISTER
Specification Compliance
The ISDN PRI network side implementation complies with the signals and signaling procedures described by the ETSI 300 102-1 and 300 102-2 specifications specific to network side, with the following exceptions:
Excel’s network side Euro-ISDN PRI implementation does not support the following:
Call re-arrangement procedures (SUSPEND and RESUME) (ETSI 300 102-1 section 5.6)
Message segmentation (ETSI 300 102-1 section 5)
Sending the STATUS ENQUIRY message (ETSI 300 102-1 section 5.8.10)
Sending the CONGESTION CONTROL message (ETSI 300 102-1 section 3.1.3)
Sending the Keypad Facility Information Element
Configuration
The network side ISDN PRI configuration procedure is the same as for the user side except that you must configure the D Channel for Network Side using the ISDN Interface Configure 0x0060 message (see the API message formats in the API Reference).
Example Message
The following is an example of the ISDN Interface Configure message, which changes the Connection Type to network side Euro-ISDN.
Trace H->X FE 00 0F 00 60 00 00 01 00 01 0D 03 00 00 17 01 00 17
Byte Field Description Value and Indication
0 Frame 0xFE
1, 2 Length 0x000F
3, 4 Message Type 0x0060
5 Reserved 0x00
MSP
1308
6 Sequence Number 0x00
7 Logical Node ID 0x01
8 AIB - Address Method 0x00 (Single Entity)
9 Number of Address Elements 0x01
10 Address Element Type 0x0D (Channel)
11 Data Length 0x03
12, 13 Data[0,1] Logical Span ID 0x0000 (Span 0)
14 Data[2] Channel 0x17 (Channel 23)
15 Entity 0x01 (Connection Type)
16, 17 Data[0,1] Value 0x0017 (Network Side Euro-ISDN)
18 Checksum 0xCS (not shown in trace)
See Network Side Euro-ISDN Call Flows
Developer Information
1309
Span Configuration
This section describes the first step in the basic ISDN configuration sequence, span configuration.
Span configuration includes:
Assigning Logical Span IDs
Configuring the Span Format and Line Length
Assigning Logical Span IDs
First, de-assign spans you want to use for ISDN with the Assign Logical Span ID message to clear all D channels and facility assignments. De-assigning a logical span ID results in taking the span and all associated channels and facilities that are assigned out-of-service. Then, assign Logical Span IDs to spans to the spans with the Assign Logical Span ID message.
Configuring Span Formats
Set the format of the span on which the ISDN D channel resides using the T1 Span Configure or E1 Span Configure messages
Configure the framing and line coding for all ISDN PRI spans as follows:
T1
Framing - ESF
Line Coding - B8ZS
Signaling - Clear Channel
E1
Coding - HDB3
Signaling - Clear Channel
If an E1 span is not configured for Euro-ISDN, the encoding format for all ISDN E1 channels defaults to u-law. You must change the encoding format with the PCM Encoding Format Configure message prior to bringing channels into service. If the format is not changed, DSP resource requests will result in a NACK of DSP Not Configured For Requested Function (0x27).
Euro-ISDN E1
Coding - HDB3
Error Checking - Enable CRC (bit 1) and FEBE (bit 2)
Signaling - Clear Channel (bit 3)/E1 Layer 1 Management
(bit 5)
Line Length - G.703.
MSP
1310
Austel-ISDN
Coding - HDB3
Error Checking - Enable CRC (bit 1) and FEBE (bit 2)
Signaling - Clear Channel (bit 3)/E1 Layer 1 Management (bit 6)
Line Length - G.703.
Developer Information
1311
ISDN D Channel Configuration
This section describes the second step in the basic ISDN configuration sequence. See Configuring ISDN.
Assigning D channels
Configuring D Channel options
Adding facilities (for NFAS)
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.
Example
The following is an example of the D Channel Assign message. The example assumes the ISDN component is assigned to Slot 8 for backward compatibility.
Trace H->X FE 00 0E 00 C4 00 00 01 00 01 15 04 08 00 00 17 00
Byte Field Description Value and indication
0 Frame 0xFE
1, 2 Length 0x000E
3, 4 Message Type 0x00C4
5 Reserved 0x00
6 Sequence Number 0x00
MSP
1312
7 Logical Node ID 0x01
8 AIB - Address Method 0x00 (Single Entity)
9 Number of Address Elements
0x01
10 Address Type 0x15 (Primary D Channel)
11 Data Length 0x04
12 Data[0] Slot Number 0x04
13, 14 Data[1] Logical Span ID
0x0000
15 Data[3] Channel 0x17 (Channel 23)
16 Secondary D Channel Facility Number
0x00
17 Checksum 0xCS (not shown in trace)
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. 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
Connection Type Lucent 4ESS
D Channel Physical Medium 64 kbps
HDLC Bit Polarity Normal
Network Side Layer 2 User Side
B Channel Selection Mode Linear Clockwise
Location User
Layer 4 Channel Release Disabled
Developer Information
1313
Request on ISDN DISCONNECT
Protocol Discriminator Value for Maintenance Messages
3
B Channel Encoding for Transmission
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 out-of-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
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
DMS100 and DMS 250
AUSTEL
JATE
EURO User Side
EURO Network Side
N12
MSP
1314
Example ISDN Interface Configure Message
The following is an example of the ISDN Interface Configure message.
Trace H->X FE 00 0F 00 60 00 00 01 00 01 0D 03 00 00 17 01 00 01
Byte Field Description
Value and Indication
0 Frame 0xFE
1, 2 Length 0x000F
3, 4 Message Type 0x0060
5 Reserved 0x00
6 Sequence Number 0x00
7 Logical Node ID 0x01
8 AIB - Address Method
0x00 (Single Entity)
9 Number of Address Elements
0x01
10 Address Element Type
0x0D (Channel)
11
Data Length 0x03
12, 13
Data[0,1] Logical Span ID
0x0000 (Span 0)
14 Data[2] Channel 0x17 (Channel 23)
15 Entity 0x01 (Connection Type)
16, 17
Data[0,1] Value x0001 (Lucent 4ESS)
18 Checksum 0xCS (not shown in trace)
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
Developer Information
1315
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 Number must be from 1-19 (0 is the D channel facility number).
Facility must be assigned (use the Assign Logical Span ID message).
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.
D Channel Facility List Configure Message Example
The next example shows the D Channel Facility List Configure message adding Logical Span ID #2, and assigning it to facility #1 for D channel 00,17.
Trace H->X FE [00 12] [00 C6] 00 04 01 00 02 0D 03 00 00 17 0C 02 00 02 01 01]
Byte Field Description
Value and Indication
0 Frame 0xFE
1, 2 Length 0x0012
3, 4 Message Type 0x00C6
5 Reserved 0x00
6 Sequence Number 0x04
7 Logical Node ID 0x01
8 AIB - Address Method
0x00 (Single Entity)
9 Number of Address Elements
0x02
10 Address Element Type
0x0D (Channel)
11 Data Length 0x03
MSP
1316
12, 13
Data[0,1] Logical Span ID
0x0000 (Span 0)
14 Data[2] Channel 0x17 (Channel 23)
15 Address Element 2
Address Type 0x0C (Span)
16 Data Length 0x02
17, 18
Data[0,1] Logical Span ID
0x0002
19 Action 0x01
20 Facility Number 0x01
21 Checksum 0xCS (not shown in trace)
Developer Information
1317
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
Network Type AT&T Megacom
Outgoing Information Transfer Capability
Voice
Calling Number Type National Number
Calling Number Plan ID
ISDN Numbering Plan
Calling Presentation Indicator
Presentation Allowed
Calling Screening Indicator
User Provided, Not Screened
Called Number Type Subscriber Number
Called Number Plan ID
Unknown Numbering Plan
MSP
1318
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 Action
1 Use the D Channel Assign message to configure the type and location of the D channel. After the primary D channel is configured, configure the backup D channel (using the D Channel Assign message again). Include the span, channel, and facility number on which it resides.
2 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 de-assigned; it becomes de-assigned when the primary D channel is de-assigned.
3 Use the second facility (1) to configure the backup D channel; (however, 1-19 are permissible).
4 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.
5 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.
Developer Information
1319
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.
Compliance
The MSP 1010 software is compliant with the Primary Rate Interface guidelines defined in Lucent TR 41459 specification, as follows:
Layer 2
Layer 2 provides information frames to Layer 3. For both D channels, all unnumbered, supervisor, and information frames are processed as described in the Lucent specification. Since the protocol is run over primary rate, the SAPI and TEI are both 0. Data links do not know if the D Channel Backup is enabled or disabled.
Layer 2 is managed by the following Layer 3 D Channel Control messages (primitives):
DL Establishes Request
DL Remove Request
DL DM Remove Request
DL Data Request
Layer 3
Layer 3 complies with Lucent specification TR41459. The L3 D Channel Control component (0x0A) handles the D channel backup logic. Each state represents both D channel states. The L3 DSM manages the following:
Distribution of incoming and outgoing information frames to the other components in Layer 3
The switchover procedure (sending SERVICE and SERVICE ACK messages on the D channel)
Distribution of the indication to appropriate component to preserve active calls
Reporting of D channel failure
MSP
1320
Reporting status to the L3P D Channel Control component (0x06)
Reporting status to the host using the PPL Event Indication message
When a D channel changes state, the host receives one of the following events in the PPL Event Indication message:
D is Active (0x00001)
D is Standby (0x0002)
D is not aligned (0x0003)
The D channel failure event is sent from L3 D Channel Control component to the L3P D Channel Control component only when both D channels are not aligned. L3P does not know the state of both D channels; it only knows that at least one D channel is accessible, or that both D channels are not.
Any call not in Active State gets cleared on a switchover. The host receives a Channel Released message for the bearer channel to which the call was in transition.
Layer 3 Plus
L3P automatically requests a switchover when either span goes into an alarm condition. The L3P B Channel Control component informs the host about channel service states. When both D channels are not established, it resends the Alarm message to the host to indicate the establishment of a D channel.
Developer Information
1321
Optional Information Elements
Excel provides a format to send and receive Information Elements (IEs) per D channel. The data is represented using Information Control Blocks (ICB) with the ICB subtype of “Formatted IEs” (see Information Control Blocks in the API Reference). This allows flexibility when sending a message that has different types of data to transport. Multiple Formatted IEs can be loaded in the data section of the ICB.
APIs support Information Elements
The following API messages support the Formatted IE ICB:
Request For Service with Address Data
Outseize Control
PPL Event Indication
LPPL Event Request
Release with Data
Channel Release Request
Information Elements
The IE data is defined by the IE type. You can load multiple Formatted IEs in the data section of the ICB. Formatting specific IEs makes it easier for host development code to parse and create messages to pass specific data. The Raw IE ICB subtype is formatted similarly, however, it consists of the exact IEs to be sent.The format of the Formatted IEs ICB is shown in the next table.
ICB Count 0x01
ICB Type 0x02 (Data)
ICB Subtype 0x10 (Formatted IE)
ICB Data Length User-defined
ICB Data[0] Number of IEs To Follow
User-defined
ICB Data[1] IE Type User-defined
ICB Data[2] IE Length
User-defined
ICB Data[3] IE Data[0]
User-defined
ICB Data[4] IE Data[1]
User-defined
ICB Data[4] IE Data[2]
User-defined
ICB Data[4] IE DATA[3]
User-defined
MSP
1322
Information Element Library
To implement overlay networks or proprietary applications, the IE library allows you to store commonly used IE data. The library loads specific ISDN messages during call processing to reduce host message traffic.
There is a separate IE library for each active D channel on the ISDN component. The IE library contains a maximum of 30 library entries, and each entry is a maximum of 30 bytes. Each IE library entry can hold multiple IEs including codeset 6 and 7 IEs. IEs can be any type.
IE Restrictions
The following restrictions apply to the contents of an IE library entry
The IE lengths must coincide with total length of data to be stored.
The total length of the entry must be 30 bytes or less.
The length specified internally for the IEs must be consistent.
Configuration
Developer Information
1323
Use PPL AF 70 in the L3P Call Reference component to insert an IE Library into an outgoing ISDN message. The first argument is the IE library entry number to insert in the ISDN message.
Figure 8-6 shows page 1 of the L3P Call Reference State Machine modified to use AF 70 to insert the IE into the outgoing SETUP message to the network. The first argument is the IE Library entry number (3). in the ISDN Interface Configure message example.
Use the ISDN Query message to retrieve the contents of the IE library. The IE library is stored in battery backed RAM.
Figure 8-6 shows page 1 of the L3P Call Reference State Machine (l3p_cc). In the modified insert, AF 70 has been added after AF 77, with Argument 1 indicating IE Number 3. This inserts the IE into the outgoing SETUP message to the network.
L3P Call Reference DSD - Page 1
Example
The following example shows an ISDN Interface Configure message used to load an IE library entry. Use the ISDN Query message to retrieve the contents of the IE library.
Byte Description Value and Indication
0 Frame 0xFE
1, 2 Length 0x0020 (32)
3, 4 Message Type 0x00B2
5 Reserved 0x00
6 Sequence Number
0xSN
7 Logical Node ID 0x01
8 AIB - Address Method
0x00 (Single Entity)
9 Number of Address Elements
0x01
10 Address Element Type
0x0D (Channel)
11 Address Data Length
0x03
12, 13 Address Data[0,1] Logical Span
0x0001 (Span 1)
14 Address Data[2] Channel
0x17 (Channel 23)
MSP
1324
15 Entity 0x0B (Load IE Library Entry)
16 Data[0] Entry Number
0x04
17 Data[1] IE Type 0x01 (Q.931 IE)
18 Data[2] Total IE Length
0x0E (14)
19 Data[3] IE Data 0x70 (Called Party Number IE)
20 Data[4] IE Data 0x0C (Length of Called Party)
21 Data[5] IE Data 0xA1 (National number, ISDN Numbering)
22 Data[6] IE Data 0x31 (Digit 1)
23 Data[7] IE Data 0x35 (Digit 5)
24 Data[8] IE Data 0x30 (Digit 0)
25 Data[9] IE Data 0x38 (Digit 8)
26 Data[10] IE Data 0x38 (Digit 8)
27 Data[11] IE Data 0x36 (Digit 6)
29 Data[12] IE Data 0x32 (Digit 2)
30 Data[13] IE Data 0x33 (Digit 3)
31 Data[14] IE Data 0x30 (Digit 0)
32 Data[15] IE Data 0x30 (Digit 0)
34 Data[16] IE Data 0x30 (Digit 0)
35 Checksum 0xCS (not shown in trace)
Developer Information
1325
Optional ISDN Configurations
Besides D channel backup and Information Elements, there are other optional configurations that are available with ISDN PRI.
This section outlines the configurations for:
B channel negotiation
ANI on demand
Vari-a-bill billing
B Channel Negotiation
ISDN components support B channel negotiation on incoming calls as defined in Lucent TR41459 for both E1 and T1 components. This feature allows the user receiving the incoming call (SETUP) to negotiate for the selection of the B channel. Only B channels controlled by the same D channel are considered for the selection procedure.
Call Flow
The SETUP message indicates the channel as either exclusive (does not accept an alternative) or preferred (any alternative is acceptable). If the channel is specified as preferred, but the user cannot grant the indicated channel, it selects any other B channel associated with the D channel. If the channel was specified as exclusive, no negotiation of the selection of the B channel is permitted and the call is rejected.
ISDN Interface Configure Enables Feature
B channel negotiation is enabled using the ISDN Interface Configure message. The following selection modes are provided:
Linear Clockwise (default)
Linear Counter-Clockwise
Circular Clockwise
Circular Counter-Clockwise
For NFAS, B channels on the same facility are selected before channels on other facilities.
Sample usage of feature
MSP
1326
The following example shows the use of the ISDN interface Configure message to select the B channel negotiation mode.
X->H FE [00 0F] [00 60] 00 00 01 00 01 0D 03 00 00 17 06 00 01]
Byte Field Description
Value and Indication
0 Frame 0xFE
1, 2 Length 0x000F (15)
3, 4 Message Type 0x0060
5 Reserved 0x00
6 Sequence Number
0x00
7 Logical Node ID 0x01
8 AIB - Address Method
0x00 (Single Entity)
9 Number of Address Elements
0x01
10 Address Element Type
0x0D (Channel)
11 Address Data Length
0x03
12, 13 Address Data[0] Logical Span
0x0000 (Span 0)
14 Address Data[1] Channel
0x17 (Channel 23)
15 Entity 0x06 (B Channel Selection Mode)
16 Data[0] Reserved
0x00
17 Data[1] 0x01 (Linear Clockwise)
18 Checksum 0xCS (not shown in trace)
ANI on Demand
ISDN components support the Automatic Number Identification (ANI) on Demand feature as specified in Lucent TR41459. This feature allows the host to request the Calling Party Number from networks that support ANI such as AT&T MultiQuest.
Developer Information
1327
A PPL Event Request message of ANI on Demand (0x21) must be sent from the host immediately after receiving the Request For Service message from the MSP 1010. If the call has already been answered, a NACK of 0xC0 is returned by the MSP 1010.
If successful, a FACILITY message is sent to the network requesting the ANI. A PPL Event Indication message of FACILITY ACKNOWLEDGE is returned containing the ANI information in a Calling Party IE or Network-specific Facility IE. If the ANI is not supported by the network or is not available, a PPL Event Indication message of FACILITY REJECT is returned by the MSP.
See the Lucent TR41459 specification for detailed information.
ANI on Demand Call flow
The NEXTB figure shows a call flow using the PPL Event Request message to implement the ANI On Demand feature.
Vari-A-Bill Billing
ISDN components support the Vari-A-Bill feature as specified in Lucent TR41459. This feature allows the host to request a change in billing for an incoming call. You can use this feature after a call has been answered and only if the SETUP message indicates that the network supports the flexible billing service.
Enabling Vari-a-Bill
To enable Vari-a-Bill, send a PPL Event Request message with a PPL Event of Vari-A-Bill (0x20), specifying the new billing information in a Vari-A-Bill Data ICB (0x12). The MSP 1010 sends a FACILITY message to the network requesting the billing change.
If the call is not in the answered state, then the feature is not supported and a NACK of 0xC0 is returned by the MSP 1010. A PPL Event Indication of FACILITY is returned from the network indicating whether the billing change was successful. See the Lucent TR41459 specification for detailed information.
Call Flow
The following call flow shows the use of the PPL Event Request message to implement the Vari-A-Bill feature.
MSP
1328
Example
The following example shows the PPL Event Request message to implement Vari-A-Bill billing and change the billing rate.
Trace X->H FE [00 1E] [00 44] 00 00 01 00 01 0D 03 00 00 00 [00 05] 00 20 01 02 10 0A 01 12 07 01 90 30 31 32 35 36
BYTE Field Description Value and Indication
0 Frame 0xFE
1, 2 Length 0x001E
3 Message Type 0x0044
5, 4 Reserved 0x00
6 Sequence Number 0x00
7 Logical Node ID 0x01
8 AIB - Address Method 0x00 (Single Entity)
9 Number of Address Elements
0x01
10 Address Element Type 0x0D (Channel)
11 Address Data Length 0x03
12, 13 Address Data[0] Logical Span
0x0000 (Span 0)
14 Address Data[1] Channel
0x00 (Channel 0)
15, 16 PPL Component 0x0005 (L3P Call
Developer Information
1329
Reference)
17, 18 PPL Event 0x0020 (Vari-A-Bill)
19 ICB Count 0x01
20 ICB Type 0x02 (Data)
21 ICB Subtype 0x10 (Formatted IE)
22 ICB Data Length 0x0A
23 ICB Data[0]Number of IEs To Follow
0x01
24 ICB Data[1] IE Type 0x12 (Vari-a-bill Data)
25 ICB Data[2] IE Length 0x07
26 ICB Data[3] Invoke ID 0x01
27 ICB Data[4] Billing Type
0x90 (New Rate)
28 ICB Data[5] Billing Data (Hundreds)
0x30
29 ICB Data[6] Billing Data (Tens)
0x31
30 ICB Data[7] Billing Data (Ones)
0x32
31 ICB Data[8] Billing Data (Tenths)
0x35
32 ICB Data[9] Billing Data (Hundredths)
0x36
33 Checksum 0xCS (not shown in trace)
MSP
1330
ISDN Call Processing
Understanding the various phases of the call makes it easier for you to manage the events and information flow. This section describes the call phases and events and identifies what you must do to use the call processing capabilities. This section also describes the level of control for call processing that you must engineer. The topics in this section include:
Incoming Calls
Outgoing Calls
Releasing Calls
Overlap Receiving
Overlap Sending
Before you begin
Before you continue, make sure the following have occurred:
System configuration is complete
Spans are framed
All D channels are established
All B channels are in-service
The Outseize Instruction List Configure message is not supported for ISDN PRI. All outseize instructions must be sent in the Outseize Control message.
Perform all PPL configuration after you specify the variant with the ISDN Interface Configure message.
Incoming Calls
An incoming call is indicated by a SETUP message containing IEs to describe the span, channel, bearer capability, called and calling party, and services requested. The MSP 1010 validates and verifies the information based upon the ISDN PRI variant and, if successful, returns a CALL PROCEEDING or SETUP ACK. A SETUP ACK returns if the ISDN PRI variant is set to Euro-ISDN (0x07) or Euro-ISDN Network Side (0x17), and the overlap receiving mode is enabled. Otherwise, only the CALL PROCEEDING returns from the MSP.
Normally, only the span, channel, called and calling party are needed for most applications. This is provided in the Request for Service with Data message using the default BCD Encoded Stages format. This is the same message, common across the MSP 1010, that reports the called and calling party address digits.
The Inseize Control and Inseize Instruction List Configure messages are not supported for ISDN PRI.
If access to all IEs is required, configure the Request for Service Format to Formatted ICB. Formatted IEs reformats the most used IEs to a byte-oriented format which is easier to parse. This abstracts the ISDN specifics from the host to provide what is necessary, in a generic form. IEs that are not supported in the formatted mode are sent to the host in the Raw IE ICB.
Developer Information
1331
The Request For Service Format is configured with Config Byte 1 of the L3P Call Control PPL Component (0x05). The following options are configurable:
BCD Encoded Digits (0x01)
Formatted ICB (0x03)
Exact Frame (0x04) - (host must parse)
At this point in the call, the network is waiting for a CONNECT message. Prior to this, an ALERTING or PROGRESS message informs the network that the MSP 1010 is awaiting answer on the B party of the MSP 1010. One method of sending the ALERTING message to the network is to send a Park Channel message for the incoming span/channel. This disables Layer 4 timers for the call.
Normally, the host attempts an outgoing call (Outseize Control) to connect to this incoming call. If a Connect message is sent to the MSP 1010 after a successful seizure, the answer propagates to the incoming side (CONNECT) assuming the Answer Supervision Mode Configure message is set to Propagate Answer To Distant End (default).
To automatically answer an incoming call, send the Generate Call Processing Event of answer, which sends an ALERTING followed by a CONNECT. This puts the call in an answered state and incoming billing is started.
Call Flows for Incoming Calls
Click on the next links to view the call flows. To close the pop up window, click inside it.
Incoming ISDN Call to Outgoing ISDN Call
Incoming ISDN Call to an IVR (Interactive Voice Response)
Incoming ISDN Call Answered and Parked
The host can send a Generate Call Processing Event of “answer” to generate the appropriate ISDN signaling to the network. The MSP 1010 will park the call in this scenario and the incoming caller will hear silence until reconnected or tones/announcements are played.
Outgoing Calls
To send a Setup to the network, use the Outseize Control message. The easiest method to use for inserting called and calling party digits is to use the Stage N Address Data ICB. All other necessary ISDN specific information derives from the configured options of the B Channel Configure message. Information, such as number types and plans, is pre-configured using this message.
For call-by-call service selection, send the Outseize Control message using the ISDN Formatted IEs and ISDN Raw IEs ICBs, which is the recommended method. When doing this, specify the number type and plan for the called party IE and the calling party IE. You can also specify other IEs to be inserted.
Several IEs are inserted in the outgoing SETUP automatically:
MSP
1332
The ISDN header (protocol discriminator, call reference and message type)
The Channel Identification IE
Bearer Capability IE
Any IEs configured and implemented in the PPL
The B channel configuration options are interpreted and inserted automatically if not represented in the Outseize Control message (see the section on B Channel Configuration (8-37) for the table). Inserting IEs in the Outseize Control message override the configured values and are inserted in the SETUP.
Once the SETUP is sent, the MSP 1010 waits for a CALL PROCEEDING ACK, or a SETUP ACK. Once the ALERTING, PROGRESS, or CONNECT occurs, the Outseize Control ACK returns to the host. You can send each of these events to the host with the data included using the PPL Event Indication message. Once the ACK is sent, the host performs any of the Layer 4 specific call processing events.
When the MSP Receives No Response from the Network
If the MSP 1010 does not receive a network response to the SETUP in eight seconds, it responds to the host Outseize Control message with a state of Outseize Failed, No Answer (0x1B). Eight seconds is two full cycles of the Q.931 Timer 305, which is L3 Call Control PPL Timer 5 and has a default value of four seconds. The SETUP is rejected by L3 if any IEs are invalid or missing.
The MSP 1010 responds to the host Outseize Control message with a status of 0x17 (Invalid Data Type). The L3P Call Control PPL sends an ACK to the host for an Outseize Control message. The default PPL does not examine the Send Host ACK ICB (0x08) in the Outseize Control message.
If involved in a tandem connection, reception of the ALERTING, PROGRESS, or CONNECT causes the voice path to get cut through. This is controlled by changing the PPLs.
In the case of distant-end release (as a result of the Outseize Control), if the called party is busy, a DISCONNECT or RELEASE COMPLETE is sent to the MSP 1010 and a PPL Event Indication is sent to the host with the Cause IE indicating the reason.
Outseize options are configurable by modifying the PPL configuration bytes of the L3P Call Control component (ID 0x05). You must modify the config bytes to enable the following options:
Config. Byte 11 (Euro ISDN/Austel only): Send a SETUP ACK and PPL Event Indication of More Info to the host upon receipt of SETUP ACK from the network.
Config. Byte 12: Send a PPL Event Indication of Call Proceeding to the host upon receipt of a CALL PROCEEDING indication from the network.
Config. Byte 13 (Euro ISDN/Austel only): Send an Outseize Control ACK to the host upon receipt of a SETUP ACK from the network.
Config. Byte 14: Send an Outseize Control ACK to the host upon receipt of a CALL PROCEEDING message from the network.
Call Flows for Outgoing Calls
Developer Information
1333
Click on the next links to view the call flows. To close the pop up window, click inside it.
Outgoing ISDN Call with Raw Formatted Data Call Processing Events
Incoming ISDN Call with Host Control of Call Setup and Release
Releasing Calls
You can release a call in the following ways:
Network-Initiated
Release Channel or Release with Data messages
PPL Event Request message
Channel Release Request message
Call Flows for Releasing Calls
ISDN-initiated Release after Connection to an IVR (Interactive Voice Response)
Host-initiated Release after ISDN Connection to an IVR (Interactive Voice Response)
IVR-initiated Release after ISDN Connection
Overlap Receiving
Overlap receiving allows you to provide more information for a call if the SETUP does not contain enough information to route the call.
To use overlap receiving for incoming calls, select the Euro-ISDN PRI variant (0x07) or Euro-ISDN Netside PRI variant (0x17) using the ISDN Interface Configure message. Also, Overlap Receiving must be enabled by using the PPL Configure message to set PPL configuration byte 9 of the L3P Call Control component (0x05) to a value of 0x01. Once the MSP 1010 is configured for overlap receiving, the call setup process is transparent and appears to the host as a normal call setup.
When overlap receiving is enabled, the MSP 1010 validates the IE data in the incoming SETUP message as a usual call setup. The MSP also checks for the following:
A sufficient number of digits in the Called Party IE. This number is determined by configuration byte 10 of the L3P Call Control component (0x05), which defaults to a value of 0x10.
A Sending Complete IE in the SETUP message
If both conditions are false, the MSP 1010 sends a SETUP ACK message to the network and goes into overlap receiving mode to obtain more information. If one of the conditions is true, the MSP 1010 sends a CALL PROCEEDING and continues with normal call setup.
MSP
1334
In overlap receiving mode, the MSP 1010 waits for one or more INFORMATION messages from the network. These INFORMATION messages contain the Called Party digit data. Overlap receiving continues until one of the following conditions occur:
The total number of Called Party digits that the SETUP receives and all the subsequent INFORMATION messages are a sufficient number
An INFORMATION message receives a Sending Complete IE
A timeout condition occurs
In the first two conditions, the MSP 1010 sends a CALL PROCEEDING message to the network and a Request For Service With Data message is sent to the host with all of the Called Party digits. When a timeout condition occurs, a 15 second L3 Q.931 timer (T302) is set after the MSP 1010 sends a SETUP ACK. This timer is reset when each INFORMATION message is received. If this timer expires before the MSP 1010 receives an INFORMATION message, the incoming call is cleared with a DISCONNECT message.
As an option, you can override the L3 timer to allow all calls to complete. To do this, configure timer number 2 (using the PPL Timer Configure message) in the L3P Call Control component (0x05) to a value of less than 15 seconds.
If the L3P timer expires before the network receives an INFORMATION message, the MSP 1010 sends a CALL PROCEEDING message to the network and a Request For Service With Data message, with all of the Called Party digit data collected up to that point, to the host. You can also use the L3P timer when the sufficient number of digits is indeterminate.
Call Flow
Incoming Call from the Network Using Overlap Receiving
Overlap Sending
When you select the Euro-ISDN PRI variant (0x07) using the ISDN Interface Configure message, you can use overlap sending for outgoing calls. To select this option, include a Call Type ICB (0x1A) in the Outseize Control message. This ICB tells the MSP 1010 to use overlap sending and also determines which mode of overlap sending to use. The MSP 1010 uses two methods of overlap sending corresponding to Call Types 1 and 2.
Each Call Type is specified in the first data byte of the Call Type ICB:
Call Type 1 (L3P-Controlled) -- Include all Called Party digit data that is not in the SETUP in the Call Type ICB as ASCII/IA5 digits following the Call Type byte. When the host sends an Outseize Control message, the MSP 1010 indicates a SETUP with whatever Called Party data was included in the Address Data ICB (ASCII/IA5 or ISDN Formatted IEs).
Once the MSP 1010 receives a SETUP ACK message from the network, it sends a barrage of INFORMATION messages, one for each of the Called Party digits included in the Call Type ICB. The last INFORMATION message contains a Sending Complete IE. Use this mode mainly for testing purposes.
Developer Information
1335
Call Type 2 (Host-Controlled) – The Call Type ICB should contain only the Call Type byte 2 as ICB data. In this mode, the MSP 1010 sends a SETUP message and waits for a PPL Event Request message from the host to initiate an outgoing INFORMATION message. Send a PPL Event Request message with an event of INFORMATION (0x0D) to the L3P Call Control component (0x05).
The ICB data should be a subtype of ISDN Formatted IEs (0x10) and must contain a Called Party IE with one or more digits. The host can also include a Sending Complete IE as an ISDN Raw IE ICB if this is the last INFORMATION message to be sent.
As with overlap receiving, there is a Layer 3 Q.931 timer running (T304). It is a 30 second timer and is set when a SETUP ACK is received. It is reset when the host initiates an INFORMATION message using a PPL Event Request message. It is disabled when the MSP 1010 receives a message from the network that terminates overlap receiving, for example, a CALL PROCEEDING, ALERTING, or CONNECT. When the timer expires, the MSP 1010 clears the call by sending a DISCONNECT to the network.
To override this timer, set the L3P Call Control component (0x05) timer number 3 to a value of less than 30 seconds. When the L3P timer expires, the MSP 1010 sends an INFORMATION message to the network with a Sending Complete IE to terminate overlap sending and to continue call setup.
Call Flow: Outgoing Call to the Network Using Overlap Sending
MSP
1336
ISDN Congestion Control
The ISDN PRI Congestion Control feature prevents the ISDN component from failing due to call traffic overload. The Congestion Control scheme will help reduce message processing undertaken by the ISDN component and other tasks within the system should incoming traffic on the D channels become excessive.
The ISDN PRI Congestion Control is enabled by default and Cantata recommends that you do not disable it. The ISDN component measures the number of incoming messages on all supported D channels over set time periods. These congestion control parameters are configurable. If the threshold parameters are set too low, the ISDN component could reject calls that it would be capable of processing. If they are set too high, the MSP 1010 will be ineffective in preventing an excessive load situation.
Implementation
The level of congestion is monitored by three components in the ISDN protocol stack:
L3P Call Control component (0x05)
L3 Call Reference component (0x08)
L3 D Channel component (0x0A)
The congestion control parameters for the above components are configurable with the ISDN Interface Configure message (0x60). Congestion parameters configuration information may be retrieved using the ISDN Query message.
When the congestion thresholds are met, an Alarm message is sent to the host. Where Excel’s default parameter values are used, congestion is cleared when the average message count is less than 300 messages for 5 seconds.
The congestion threshold data fields are common to both ISDN and DASS congestion control schemes. The data fields are formatted to ensure backwards compatibility with the existing DASS congestion control scheme. DASS congestion control used just a single congestion level, this has been changed to Level 2 burst and average thresholds. The default values have also been changed to work with the ISDN scheme, if using DASS then Level 2 burst threshold should be set to 200 and Level 2 average threshold should be set to 1000.
Congested State
When the number of incoming messages reaches a certain pre-defined threshold, the D channels are identified as being in a congested state. A congested state results in any new incoming or outgoing call attempts being either rejected or ignored. The D channels will remain in the congested state until the incoming message rate falls below a pre-defined abatement threshold.
The two pre-defined levels of congestion exist with thresholds defined for each are:
Congestion Level 1 defines the threshold at which calls are rejected.
Congestion Level 2, for the higher level, defines the threshold at which point calls are completely ignored.
Developer Information
1337
The congested state is removed once the incoming message rate slows down to a pre-defined, lower threshold known as the abatement level, and stays below this level for a period of time. At this time, processing of the incoming and outgoing calls resumes.
Congestion Default Values
The next table below shows the default settings for congestion control on an ISDN component
Description Default values
Level 2 burst threshold 2700 messages
Level 2 average threshold
4500 messages
Abatement threshold 900 messages
Burst time window 1 second
Number of samples in average
10 bursts
Abatement window 5 seconds
Level 1 burst threshold 1600 messages
Level 1 average threshold
4300 messages
The ISDN congestion control scheme continuously counts the number of incoming messages on an ISDN component. Samples are taken in fixed units of time and are used to determine the congestion level of the component’s associated D channels.
Individual samples are used to determine the ‘burst’ rate. A burst is a count of all incoming messages in a single sample. This enables short excessive peaks in traffic to be accounted for.
A combination of samples is used to determine a moving average. This moving average is a count of all incoming messages over a number of samples. This enables consistent excessive traffic to be accounted for.
Diagram
The figure below shows an example of congestion occurring at various levels using the default settings.
MSP
1338
Configuration
Congestion control on the ISDN component is configurable through the ISDN Interface Configure message. The Single Channel format AIB, (0x0D) is used in this message to specify any one of the individual D Channels but it will apply to all. The AIB should be used to address any individual D channels that have been previously configured using D Channel Assign (0xC4). A new entity, Congestion Threshold (0x0C) has been added to this message to provide congestion threshold values. These values can be changed.
Congestion Levels During Call Processing
No Congestion
Calls are processed normally.
Congestion Level 1
Congestion Level 2
Developer Information
1339
ISDN Bearer Connection Independent Supplementary Services
Provision for ISDN Bearer Connection Independent Supplementary Services is implemented using the FACILITY message through the ISDN GCR component (0x09) with optional facility information element (IE) contents. All that is required for these services is the ability to transmit and receive FACILITY messages with a dummy call reference IE.
Existing support for FACILITY messages and both normal and global Call Reference IEs are not affected. ISDN FACILITY messages are sent from the host using the PPL Event Request (0x44). The host is notified of the receipt of the incoming ISDN FACILITY message using PPL Event Indication (0x43).
Implementing Calls
Incoming
Outgoing
1341
PPL Developer's Information
Introduction
Basics of PPL
Benefits of PPL and the PPL Composer
Excel’s Programmable Protocol Language (PPL) provides the ability to easily access and modify software operations on a per PPL component basis, giving the user full control over call processing. The PPL software load resides on the MSP and consists of a state machine engine, default protocol state machines (*.ppl files) and atomic function/event libraries (*.exl files).
A PPL protocol is an association of a state/event table and a primitive table. The state machine engine uses the tables to drive PPL objects through various states in response to internal or external events.
You can customize protocols using the PPL Composer application, which provides a graphical representation of PPL state machines. Protocol variants can be developed easily by modifying default protocols that can be obtained from the Excel protocol library.
PPL protocols are independent of switch system software, allowing for the creation of new protocols without upgrading system software. This allows for quick changes required to manage network signaling variants. Protocols are created with high-level Atomic Functions (AF), abstracting the user from detailed implementation logic.
Multiple protocols can be defined for each PPL component and selectively assigned to each object being managed.
Terms and Acronyms
You should familiarize yourself with the following terms and acronyms used throughout this manual. Each is discussed in more detail within the manual.
AF Atomic Function. A state machine software routine which normally performs one independent task.
*.ppl File extension for PPL protocol data file used by the PPL Composer application.
Event A condition that, when met, drives a state machine from one state to another.
*.exl File extension for files containing the atomic function/event library for a PPL component.
INS In Service
L3 Layer 3 (Network Signaling Protocol Layer)
L3P Layer 3 Plus (interface between L3 and L4)
L4 Layer 4 (Call Processing Layer)
L5 Layer 5 (Host Application Layer)
OOS Out of Service
MSP
1342
PPL Programmable Protocol Language. An Environment which allows for different software components within Excel’s switching platforms to be externally programmed and downloaded by the host application.
PPL Component
A programmable software component that uses PPL state machines that can be modified with the PPL Composer.
PPL Object A system object that is controlled by a PPL state machine such as a channel, an ISDN D channel, or an SS7 link.
Primitive A list of atomic functions invoked by a particular event.
Primitive Table
A list of all primitives used in a particular state machine.
Protocol A state machine comprised of a state/event table and a primitive table.
State The current “context” of a PPL object, such as Idle, Seizing, Answered.
State/Event Table
A table of all states used in a state machine and their associated events/primitives.
Symbols
PPL state machines use symbols to represent states, atomic functions, and events. These correspond to standard Specification and Description Language (SDL) symbols as shown in the figure below The PPL symbol for a state that is internal is denoted with an "I" in front of the "S".
State Machine Symbols
Index
1343
MSP Software Architecture
MSP
1344
PPL Environment
Overview
The PPL environment is designed into the switch system software, integrating custom PPL-generated state tables with system software residing on PPL-controlled components on each card. The developer has the ability to determine which call processing events are processed by the switch and how the switch responds to the events.
API messages manage PPL components
PPL components are configured and managed using the Excel PPL API messages. The API messages allow you to modify PPL timers, Config Bytes, transmit signaling (E1), event indications and requests, and more.
PPL Composer
All components are configurable with the PPL Composer, allowing you to modify protocol state machines to conform to variants. The default *.ppl and *.exl files for components that are released for custom programming with the MSP 1010 system software. If you require modification of unreleased PPLs, contact Excel Systems Support.
In addition to the default protocols, up to 10 custom protocols can be stored per component and assigned on a per object basis. The default protocols can be modified using the PPL Composer.
Each PPL component has a default protocol (or protocols), timers, Config Bytes, and EXL (atomic function/event library). The timers and Config Bytes are programmable using API messages.
Example
The next diagram uses the ISDN PRI card to illustrate the PPL environment. The Layer 3 Plus Call Control component (5) has three default protocol variants for the three connection types supported by the ISDN PRI card (Protocol IDs 11, 12, and 13). All three variants use the same timers, Config Bytes, and EXL. Using the PPL Composer, another protocol could be created (Protocol ID 1-10) and downloaded to the switch, and selectively assigned to objects.
PPL Environment
Index
1345
Switching between protocols
The ability to switch between several PPL protocols is provided by AF 2, which invokes a primitive resulting in the channel using a new set of protocol tables. It is the responsibility of the “secondary” protocol to return to the primary protocol (protocol assigned to the channel).
Switching Between Protocols
MSP
1346
Index
1347
PPL Guidelines
Overview
This section gives general guidelines to follow when developing protocols. For more detailed information on using PPL for specific protocols, consult the API Reference.
Idle State
The Idle state must be consistent with the default protocol for a component. A protocol must transition to the primary protocol without having any knowledge of the primary protocol's state/event and primitive table data.
T1 and E1
Since the E1 OOS protocol has no knowledge of the primary T1 and E1 protocol, the transmit IDLE line signaling ABCD bit values must be configured by sending a PPL Transmit Signal Configure message. This should be done prior to bringing the channel In Service. The Out of Service line signaling value is transmitted when a channel is being controlled by the OOS protocol (channel ID out of service).
Internal States
A given Internal State (test state) must accept all possible Internal PPL Events (test results) from a test AF that is invoked. The description of all test Atomic Functions indicate the possible Internal PPL Events that may be returned.
Multi-Purpose PPL Timers
Each component has 3 multi-purpose timers available for use within a protocol. These timers can be activated through an “Enable Timer” AF passing the timer number (1-3) in Arg1 and the preconfigured PPL timer setting ID (1-100) in Arg2. See the Overview section for more details on PPL Timers.
The preconfigured timer settings can be changed by the host using the PPL Timer Configure message. As timer adjustments are independent from the protocol tables you can modify a timer value without having to create new protocol tables.
When a timer expires, an event is generated into the PPL state machine for the associated channel. The timer events are numbers 191, 192, and 193.
Multiple Resident Protocols
The MSP 1010 allows for up to 10 custom protocols per component to be resident in the system at one time. Custom protocols can be given Protocol IDs from 1 to 10. Excel default protocols begin at Protocol ID 11.
Call Processing
The MSP 1010 software architecture shown in the figure below is similar to the OSI Layered Model. Inter-Layer communications between Layer 3 and Layer 4 must take place for call management. Specific events and AFs are provided for each PPL
MSP
1348
component to manage call processing. This section describes the required Layer 3 to Layer 4 messaging for incoming and outgoing calls.
Excel Software Architecture
Incoming Call
Condition L3 to L4 Message
Incoming Call Setup Completed L3 ? L4 Setup Indication by L3
Terminating Party being Alerted L4 ? L3 Alerting
Terminating Party Answered L4 ? L3 Connect
Outgoing Call
Condition L3 to L4 Message
Initiation of Outgoing Call L4 ? L3 Call Request or
L4 ? L3 Outseize Control
Outseizure Acknowledgment L3 ? L4 Alerting
Index
1349
Successfully Detected by L3
Answer Detected by L3 L3 ? L4 Connect
Network-initiated Call Release
Condition L3 to L4 Message
Network Release Detected L3 ? L4 Disconnect by L3
L4 Acknowledgment of L3 Disconnect Request
L4 ? L3 Clear
L3 Network Release Completed (L3 in Idle state)
L3 ? L4 Clear
Host/Associated Party-initiated Call Release
Condition L3 to L4 Message
L4-initiated Release L4 ? L3 Clear
L3 Network Release Completed
(L3 in Idle state) L3 ? L4 Clear
MSP
1350
API Messages used for Protocol Modification
Overview
PPL Protocols can be modified in two ways:
PPL Composer
Default PPLs can be modified using the PPL Composer to create protocol variants. See the PPL Composer User’s Guide.
API Messages
Excel PPL API messages can be used to modify a number of PPL configurations without modifying the protocol state machines.
API Messages
PPL Table Download Initiate and PPL Download
PPL Table Download Initiate and PPL Download messages are used to download protocol tables to the switch.
Downloading and Assigning a Protocol
Download the protocol to the switch. See the developer’s guides for downloading methods. Assign the protocol to channels or other objects (such as SS7 links) using the PPL Assign message.
Perform any required PPL configuration such as:
• Timers (PPL Timer Configure)
• Config Bytes (PPL Configure)
• Signaling (PPL Transmit Signal Configure, E1 only).
Bring the channels or other objects in service using the Service State Configure message. The following API messages are used for PPL configuration. See the API Reference for complete information on each message.
PPL Create and PPL Assign
These messages are used to create a protocol using the downloaded tables and to assign the protocol to PPL-controlled objects.
PPL Configure
This message is used to modify a component’s PPL Config Bytes. The default Config Bytes are documented in the API Reference.
PPL Data Query
This message is used to retrieve information on Config Bytes, PPL Timers, and the state of a component.
Index
1351
PPL Event Indication and PPL Event Request
These messages are used to generate PPL events between the host and the switch.
PPL Audit Configure and PPL Audit Query
These messages are used to configure and retrieve audit data on a card. See the PPL Auditing in this section for more information.
PPL Timer Configure
This message is used to modify a protocols timer values. See PPL Timers for more information.
PPL Transmit Signal Configure
This message is used to configure transmit line signaling on E1 channels.
PPL Protocol Query
This message is used to generate a report on the custom protocols downloaded to a PPL component.
MSP
1352
State Machines
Overview
The next diagram shows an example of a state machine. The state machine engine drives each channel through its protocol tables based on the occurrence of an event. When a normal state is reached, processing of the event is complete. The dynamic generation of internal blocking states is also supported for service resource requests such as digit receiver allocation.
State Machine Example
State
The current “context” of a component. There are three types of states:
Normal
Blocking
Internal
Index
1353
Normal State
A normal state can be a wait state (i.e., waiting for a line signaling event, or host input), or a stable state (i.e., conversation state).
Blocking State
A blocking wait state is automatically generated by the PPL when a “blocking” AF is invoked. A blocking AF is used for allocation of any off-board service resource required by the PPL. Upon the receipt of a positive result of the resource request, the channel “unblocks” and resumes the remainder of the primitive. Blocking is performed on a per object basis without affecting other objects.
Blocking States are transparent to the PPL designer, but they can be tracked in a PPL audit. A blocking state is indicated by 0xFF in the State Status field of PPL Audit Data (see PPL Auditing). This isolates the protocol developer from the details of the internal service management provided by the MSP 1010 when creating new PPL protocols. Only normal and internal states can be programmed by the host.
An example of a Blocking state is shown below.
Blocking State
Internal State
Internal States are used to take a decision branch based upon performing a logical test. An Internal State is initiated by a Test AF, which will result in an internal event being returned based upon the result of the test. Internal states only accept internal
MSP
1354
events. The documentation for test AFs shows the internal events generated for each result.
The format of an internal state can be represented in standard logic flow chart form, as shown in the next diagram. The PPL representation of the flow chart as an internal state is shown in the figure on the next page.
Logic Flow Chart Decision Branch
The next section shows a PPL state machine representation of the logic flow chart decision branch above.
PPL State Machine Representation of Logic Flow Chart Decision Branch
Index
1355
Event
A condition that drives a component out of its current state by invoking an associated primitive, such as:
Receive Line Signaling Change
Dialtone Detected
Alerting Message
Atomic Function (AF)
A predefined, two-argument function that performs a simple protocol action, such as:
Transmit Line Signaling
Send Layer 4 Disconnect
Allocate Digit Buffer
The AFs for all default protocols that can be modified using the PPL Composer are documented in the section for each card. They include a description, argument values and ranges, internal events returned for tests, and the minimum software version.
MSP
1356
Primitive
A grouping of one or more AFs and their arguments that allows multiple actions and tests to be initiated in response to a PPL event.
Index
1357
PPL Timers
Overview
There are two types of timers available to a protocol state machine:
Generic Protocol Timers
Protocol-specific Timers
Generic PPL Timers
Each component has access to a list of 100 timer values that are enabled in a protocol using AFs 46, 47, and 48. Up to three timers can be enabled at any one time. Each component using timers has a table that contains the value of specific timers. Argument 2 of the Generic PPL Timer AFs is an index into the component’s timer table where the value for the required timer is located.
Example
The next figure shows the use of a timer AF in the MTP3_LSAC state machine. AF 46 initiates one of the PPL timers (in this case, Timer 2, as defined by Argument 1 of the AF). Argument 2 is the index into the component’s timer table. In this case, Argument 2 indicates Index 2 in the timer table, which is the MTP3_ANSI_T17 timer with a default value of 1s.
See the API Reference for the default values of each component’s Generic PPL Timers.
Generic Protocol Timers
Protocol-Specific Timers
The E1 component uses various timers when transmitting and receiving signaling tones or dial pulses. They are as follows:
R2 Signaling
DTMF Signaling
MSP
1358
MFR1 Signaling
Dial Pulse
The default timer values are documented in the PPL Timer Configure message, which is used to modify any of the timer values. See the API Reference for more information.
Modifying Protocol Timers
You can modify all of the timers and values in the PPL Timer tables using the PPL Timer Configure message. This allows the timer values to be modified without modifying the component state machine. To modify a components Generic Protocol Timer list, indicate a Timer Type of Generic Protocol Timer (0x01), the Timer ID (index into the components timer table), and the new Timer Value. To modify an E1-specific Signaling Timer, indicate the Timer Type, Timer ID (see message), and new Timer Value.
Example API format
The following example shows how to modify the MTP3_ANSI_T17 timer from one second (default) to two seconds.
Byte Field Description Value and Indication
0 Frame Character 0xFF
1 Length (MSB, LSB) 0x0011
2
3 Message Type (MSB, LSB) 0x00CF (PPL Timer Configure)
4
5 Reserved 0x00
6 Sequence Number 0xSN
7 Logical Node ID 0xFF
8 AIB Address Method 0x00 (Single Entity)
9 Number of Address Elements
0x01
10 Address Type 0x09 (SS7 Link)
11 Data Length 0x02
12 Data[0] Stack ID 0x01
13 Data[1] Link ID 0x01
14 PPL Component ID (MSB, LSB)
0x002E (MTP3_LSAC)
15
16 PPL Timer Type 0x01 (Generic Protocol Timer)
Index
1359
17 PPL Timer ID 0x02 (MTP3_ANSI_T17)
18 PPL Timer Value (MSB, LSB)
0x00C8 (2 s)
19
20 Checksum 0xCS
MSP
1360
PPL Auditing
Overview
When PPL Auditing is enabled on a card, all state machine activity on the card is recorded in an audit log on either a per-PPL component basis or an individual entity basis. A log consists of a number of audit entries, each representing a state transition on a specific entity (channel). The length of the audit entries varies per PPL component.
Under busy call conditions, the user has the option initiating PPL Auditing on an Entity Basis instead of PPL Auditing on a Component Basis. This option provides the user with more accurate error auditing. Enabling the auditing function on an entity basis allows the auditing buffer to store only the information pertaining to user-selected entities. When auditing on a component basis, the ability to determine the cause of a problem can be lost. This is because the multi-entities that overload the auditing buffer can be overwritten due to a large volume of incoming voice traffic.
IMPORTANT: Before initiating the PPL Audit function, contact Cantata technical Support for information on selecting the Audit Type options in the PPL Audit Configure and PPL Audit Query messages.
PPL Audit Configure
PPL Auditing is enabled on a per-card basis using the PPL Audit Configure message. This message accepts and validates all AIBs that correspond to the provided component ID. A message received with a Slot AIB will be processed as in previous releases. A message received with an AIB, other than a Slot AIB, will be processed as an Individual Entity Audit configuration message. The Audit Type field is a bit mask that provides bits 0 through 3 to enable or disable PPL Auditing features on a component or entity basis. For example, setting bit 0 enables PPL auditing. See the PPL Audit Configure message for the Audit Type information.
There are two new bit options in the Audit Type field. Bit 3 allows configuration of individual entities, and bit 2 enables the configuration. Both bits can be set at the same time or bit 2 can be enabled or disabled at any time to activate or deactivate individual auditing.
To support PPL Auditing on an Entity basis, the PPL Audit Configure message supports AIBs that are associated with the following PPL components:
E1 (0x0001)
T1 (0x0003)
ISDN L3P Call Control (0x0005)
ISDN L3 Call Reference (0x0008)
SS7 L3P CIC (0x000F)
SS7 ISUP CPC (0x0012)
Channel Management (0x0061)
Call Management (0x0062)
PPL Audit Query
Index
1361
The PPL Audit Query message supports Slot AIB, and all AIBs that are associated with the PPL components. This message supports the querying of all PPL Audit configurations. For example, when this occurs a single byte of Audit configuration data will be returned. This byte will contain the current settings for board level PPL Auditing, board level PPL Error Alarm settings, and Individual PPL Auditing.
If the AIB specifies an entity other than a Slot AIB, the byte will also contain entity level PPL Auditing and entity level Error Alarm settings. For example, this information will be queried by setting the Audit Type to 0x02 in the PPL Audit Query message. The PPL Audit Query message Audit Types are as follows:
An Audit Type of (0x00) requests the PPL Audit information for the specified entity.
An Audit Type of (0x01) requests a PPL ERROR audit on a per card basis.
An Audit Type of (0x02) requests the current PPL Audit configuration. It will return a PPL Audit Query response containing the status, the AIB, the component ID, the Audit Type, and an Audit Configure byte containing the current Audit Configuration setting. The slot AIB will be supported when the Audit Type is Audit Configuration (0x02). The bits (0 through 4) of the Audit Configuration byte are listed in the PPL Audit Query message.
Audit Data
The exact data in an audit log varies per audit type and PPL component. See the PPL Audit Query message for the exact data returned. The following information is included in all audit entries:
Protocol ID
State Status
Protocol-specific Information
PPL Event
Initial State
Next State
Error Status
Timestamp
Retrieving an Audit Log
An audit log can be retrieved by sending a PPL Audit Query message. There are two audit query types: PPL State Transitions and PPL Errors. PPL State Transitions are queried on a per-PPL component/entity basis. All state transitions for a specified PPL component on a specified entity are reported. PPL Errors are queried on a per PPL component/card basis. All PPL errors for the specified PPL component on the specified card are reported.
An entire log cannot always be retrieved with one message. Audit entries are grouped into audit blocks. When you query a log, you specify audit block 0 in the first message, audit block 1 in the second message, and so on until all audit entries have been returned. When there are no audit entries remaining, the response status to the PPL Audit Query message will indicate 0x00D7 (End of PPL Audit Data).
MSP
1362
PPL Error Alarm
By enabling the PPL Error Alarm, the host will be notified with an Alarm message when a PPL Error occurs on an entity. The PPL Error Alarm is enabled by setting bit 1 of the Audit Type field in the PPL Audit Configure message. The Alarm message will indicate Entity - 0x04 (Channel) and Alarm # - 0x03 (PPL Error). The Alarm Information fields contain the audit entry data from the PPL Audit log.
Index
1363
Common Atomic Functions
Atomic Functions
AF 1- AF 50 are common to all PPL components. See the relevant section for protocol-specific *.exl files.
Links
Click below to jump directly to an Atomic Function:
Create New State Machine Context
Jump to State Machine
Return to State Machine
Generates a PPL Internal Event
Compare PPL Configuration Byte To Value
Generates a PPL Internal Event
Compare PPL Configuration Byte to Value
Compare PPL Configuration Byte In GPR to Byte Offset Value
Clear General Purpose Register
Clear Range of General Purpose Registers
Save Value in General Purpose Register
Increment General Purpose Register
Compare GPR to Value
Compare PPL General Purpose Registers
Test Value in GPR to Configuration Byte
PPL Test GPR for Any Value
Decrement General Purpose Register
Move GPR to GPR
PPL General Purpose Register
PPL General Purpose Register Number1
PPL General Purpose Register (High 16)
PPL General Purpose Register (Low 16)
PPL General Purpose Register
PPL General Purpose Register Number1
PPL General Purpose Register (High 16)
PPL General Purpose Register (Low 16)
PPL Shift Right Logical Gen. Purpose Register
Block Event
MSP
1364
PPL Shift Left Logical GPR
PPL Load GPR with Contents of 4 or 8 Config Bytes
PPL Load GPR with Contents of Config Byte
Set PPL Timer
Disable PPL Timer
Set PPL Timer in 10ms Units
Set PPL Timer in 100ms Units
Set PPL Timer in 1000ms Units
Other:
Events
Downloading and Assigning a Protocol
Atomic Functions
AF Number: 1
Name: Create New State Machine Context
Description: Creates a new state machine context for the protocol being transferred into. This function must be invoked prior to AF_002 (Jump To State Machine). The Protocol ID can be the currently active protocol or a non-active protocol.
Arg1: <Protocol ID>
Arg2: <Not Used>
AF Number: 2
Name: Jump to State Machine
Description: Transfers from the current state machine to the internal state machine indicated by Arg1, which becomes the current state, and the Internal PPL Event indicated by Arg2 is processed.
Arg1: <Internal State ID>
Arg2: <Internal PPL Event>
AF Number: 3
Name: Return to State Machine
Description: Returns to the calling PPL state machine. Both AF_001 (Create New State Machine Context) and AF_002 (Jump To State Machine) must be invoked prior to AF_003. The current state machine context will be freed up and the calling state machine's context will be restored.
Index
1365
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 11
Name: Generates a PPL Internal Event (Indicated by Config Byte)
Description: Generates a PPL Event indicating the value of the configuration byte indicated by Arg1.
Arg1: <Configuration Byte Offset> 1-200
Arg2: <Not Used>
AF Number: 12
Name: Compare PPL Configuration Byte To Value
Description: Tests the value of the configuration byte indicated by Arg1 against the value indicated by Arg2.
Arg1: <Configuration Byte Offset> 1-200
Arg2: <Value>
Test Result
PPL Internal Event
< 0
> 1
= 2
AF Number: 13
Name: Generates a PPL Internal Event (Indicated by GPR)
Description: Generates a PPL Event equal to the value of the configuration byte given by the GPR indicated by Arg1.
Arg1: <GPR #> 1-25
Arg2: <Not Used>
AF Number: 14
Name: Compare PPL Configuration Byte to Value
Description: Compares the value of the configuration byte given by the GPR indicated by Arg1 against the value indicated by Arg2.
Arg1: <GPR #> 1-25
Arg2: <Value>
Result PPL
Internal Event
MSP
1366
< 0
> 1
= 2
AF Number: 15
Name: Compare PPL Configuration Byte In GPR to Byte Offset Value
Description: Tests the value of the configuration byte given by the GPR indicated by Arg1 against the value of the configuration byte indicated by Arg2.
Arg1: <GPR #> 1-25
Arg2: <Configuration Byte Offset> 1-200
Test Result
PPL Internal Event
< 0
> 1
= 2
AF Number: 21
Name: Clear General Purpose Register
Description: Clears the GPR indicated by Arg1.
Arg1: <GPR #> 1-25
Arg2: <Not Used>
AF Number: 22
Name: Clear Range of General Purpose Registers
Description: Clears a range of PPL GPRs beginning with the GPR # indicated by Arg1 and including the number of registers indicated by Arg2.
Arg1: <Beginning GPR #> 1-25
Arg2: <# of Registers to Clear>
AF Number: 23
Name: Save Value in General Purpose Register
Description: Saves the value indicated by Arg2 in the GPR indicated by Arg1.
Arg1: <GPR #> 1-25
Arg2: <Value> 0-255
AF Number: 24
Index
1367
Name: Increment General Purpose Register
Description: Increments the GPR indicated by Arg1 by the value indicated by Arg2.
Arg1: <GPR #> 1-25
Arg2: <Increment Value>
AF Number: 25
Name: Compare GPR to Value
Description: Compares the value in the GPR indicated by Arg1 against the value indicated by Arg2, and returns a decision event to drive the PPL state machine out of an internal decision state.
Arg1: <GPR #> 1-25
Arg2: <Value>
Test Result
PPL Internal Event
= 1
other 0
AF Number: 26
Name: Compare PPL General Purpose Registers
Description: Tests the value in the GPR indicated by Arg1 against the value in the GPR indicated by Arg2.
Arg1: <GPR #> 1-25
Arg2: <GPR #> 1-25
Test Result
PPL Internal Event
< 0
> 1
= 2
AF Number: 27
Name: Test Value in GPR to Configuration Byte
Description: Tests the value in the GPR indicated by Arg1 against the value of the configuration byte in the GPR indicated by Arg2.
Arg1: <GPR #> 1-25
Arg2: <GPR #> 1-25
Test Result
PPL Internal Event
MSP
1368
< 0
> 1
= 2
AF Number: 28
Name: PPL Test GPR for Any Value
Description: Function which generates a decision event based on the value in the GPR indicated by Arg1.
Arg1: <GPR #> 1-25
Arg2: <Not Used>
Test Result
PPL Internal Event
GPR # N N
for example: if GPR = 45, then PPL Internal Event = 45
AF Number: 29
Name: Decrement General Purpose Register
Description: Decrements the GPR indicated by Arg1 by the value indicated by Arg2. A GPR cannot be decremented below 0. If the decrement value in Arg2 is greater than the value of the GPR in Arg1, the GPR will be set to 0.
Arg1: <GPR #> 1-25
Arg2: <Decrement Value>
AF Number: 30
Name: Move GPR to GPR
Description: Moves the value stored in the GPR indicated by Arg1 to the GPR indicated by Arg2.
Arg1: <GPR #> 1-25
Arg2: <GPR #> 1-25
AF Number: 31
Name: PPL General Purpose Register <- General Purpose Register Logical AND Config Bytes
Description: Performs logical AND statement between Arg 1 and Arg 2
Arg1: <Register Number> (1:53)
Arg2: <Config Byte Offset> 1:100
Index
1369
AF Number: 32
Name: PPL General Purpose Register Number1 <- General Purpose Register Number1 Logical AND General Purpose Register Number2
Description: Performs logical AND statement between Arg 1 and Arg 2. The result is placed into Arg 1
Arg1: <Register 1 Number> (1:53)
Arg2: <Register 2 Number> (1:53)
AF Number: 33
Name: PPL General Purpose Register (High 16) < General Purpose Register (High 16) Logical AND Immediate Value
Description: Perform a logical AND statement between MSB of register stored in Arg 1, and the MSBs of register stored in Arg 2. The result is placed in the MSB of Arg 1.
Arg1: <Register Number> 1:25
Arg2: <Value> 0:65535
AF Number: 34
Name: PPL General Purpose Register (Low 16) < General Purpose Register (Low 16) Logical AND Immediate Value
Description: Performs a logical AND statement between LSB of
Arg1: <Register Number> 1:25
Arg2: <Value> 0 - 65535
AF Number: 35
Name: PPL General Purpose Register <- General Purpose Register Logical OR Config Bytes
Description: Performs logical OR statement between Arg 1 and Arg 2
Arg1: <Register Number> 1:53
Arg2: <Config Byte Offset> 1:100
AF Number: 36
Name: PPL General Purpose Register Number1 <- General Purpose Register Number1 Logical OR General Purpose Register Number2
Description: Performs logical OR statement between Arg 1 and Arg 2. Places result into Arg 1 register.
Arg1: <Register 1 Number> 1:53
Arg2: <Register 2 Number> 1:53
MSP
1370
AF Number: 37
Name: PPL General Purpose Register (High 16) <- General Purpose Register (High 16) Logical OR Immediate Value
Description: Performs logical OR statement between MSB of register stored in Arg 1 and Arg 2. The result is placed in the MSB or Arg 1 register.
Arg1: <Register Number> 1:25
Arg2: <Value> 0:65535
AF Number: 38
Name: PPL General Purpose Register (Low 16) <- General Purpose Register (Low 16) Logical OR Immediate Value
Description: Performs a logical OR statement between the LSB of register in Arg 1 and Arg 2. The result is placed in the LSB of Arg 1.
Arg1: <Register Number> 1:25
Arg2: <Value> 0:65535
AF Number: 39
Name: PPL Shift Right Logical Gen. Purpose Register
Description: Performs a bit shift right, on the register indicated by Arg 1. The number of bits to shift is indicated by Arg 2.
Arg1: <Register #> 1:53
Arg2: <# bits> 1:64
AF Number: 40
Name: Block Event
Description: Blocks an event for later processing in the next normal state.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 41
Name: PPL Shift Left Logical GPR
Description: Shifts the value in the GPR indicated by argument 1 left by the number of bits indicated by argument 2.
Arg1: <Register #>
Arg2: <# of Bits>
AF Number: 42
Name: PPL Load GPR with Contents of 4 or 8 Config Bytes
Index
1371
Description: Loads the value of the PPL Config Bytes beginning with the byte indicated by argument 2 into the GPR indicated by argument 1.
Arg1: <Register #>
Arg2: <Starting Config Byte>
AF Number: 43
Name: PPL Load GPR with Contents of Config Byte
Description: Loads the value of the PPL Config Byte indicated by argument 2 into the GPR indicated by argument 1.
Arg1: <Register #>
Arg2: <Config Byte Offset>
AF Number: 46
Name: Set PPL Timer
Description: Sets the PPL timer indicated by Arg1 to the value of the Timer ID indicated by Arg2, configured with the PPL Timer Configure message.
The Timer Number refers to the three internal PPL multi-purpose timers available per channel. The Timer ID refers to the 100 Generic Protocol Timer IDs that can be configured with the PPL Timer Configure message. A PPL Timer’s value can be adjusted by changing the Timer ID value with the PPL Timer Configure message, without modifying the PPL State/Event or Primitive tables.
Arg1: <Timer Number> 1-3
Arg2: <Timer ID> 1-100
The expiration of PPL timers results in the generation of the following PPL events:
Expiration of:
PPL Internal Event
Timer 1 PPLevTIMER1
Timer 2 PPLevTIMER2
Timer 3 PPLevTIMER3
AF Number: 47
Name: Disable PPL Timer
Description: Disables the timer indicated by Arg1.
Arg1: <Timer Number> 1-3
Arg2: <Not Used>
AF Number: 48
Name: Set PPL Timer in 10ms Units
MSP
1372
Description: Activates the PPL timer indicated by Arg1 with the value indicated by Arg2 in 10ms units.
Arg1: <Timer Number> 1-3
Arg2: <Timer Value>
AF Number: 49
Name: Set PPL Timer in 100ms Units
Description: Activates the PPL timer indicated by Arg1 with the value indicated by Arg2 in 100ms units.
Arg1: <Timer Number> 1-3
Arg2: <Timer Value>
AF Number: 50
Name: Set PPL Timer in 1000ms Units
Description: Activates the PPL timer indicated by Arg1 with the value indicated by Arg2 in 1000ms units.
Arg1: <Timer Number> 1-3
Arg2: <Timer Value>
EVENTS
The following events are common to all PPL components.
191 PPLevTIMER 1 PPL Timer 1 has expired.
192 PPLevTIMER 2 PPL Timer 2 has expired.
193 PPLevTIMER 3 PPL Timer 3 has expired.
Events 200 - 455
Internal Event N generated by a test AF to drive the state machine out of a decision type state, where:
Event N = Event # - 200.
For example:
EVENT 200 = Internal Event 0
EVENT 321 = Internal Event 121
EVENT 455 = Internal Event 255
Events 500 - 755
Internal Event N from Layer 5 generated by a PPL Event Request message, where:
Index
1373
Event N = Event # - 500.
Downloading and Assigning a Protocol
Download the protocol to the switch. See the Developer’s Guides for downloading methods. Assign the protocol to channels or other objects (such as SS7 links) using the PPL Assign message.
Perform any required PPL configuration such as:
Timers (PPL Timer Configure)
Config Bytes (PPL Configure)
Signaling (PPL Transmit Signal Configure, E1 only).
Bring the channels or other objects in service using the Service State Configure message.
MSP
1374
T1 Atomic Functions
Atomic Functions
The PPL state machine, *.ppl, for each protocol is available on CD ROM
Links
Click below to go directly to an Atomic Function.
Send L4 a Q.931 Alerting
L3PPL Send L4 a Q.931 Alerting with Cut Thru
L3PPL Send L4 a Setup Indication
L3PPL Send L5 INSZ/OUTZ Ctrl Resp with Status in GPR <GPR #>
L3PPL Test for Outstanding L5 Msg
T1PPLXMIT AB Line Signaling <CFG Byte Offset>
L3PPL XMIT ABCD Line Signaling <CFG Byte Offset>
T1PPL XMIT Line Signaling <AB bits>
L3PPL Store Outseize Ctrl Data ICBs
L3PPL Test Current Outseize Ctrl Instr Data
L3PPL Compare Next Outseize Ctrl Instr Addr Sig Type <Addr Sig Type>
L3PPL INIT a Channel Purge with Purge Reason in GPR <GPR #>
Send PPL Event Indication Message to the Host with GPR Value
L3 PPL Send L5 Event Indication with General Purpose Register Value <Event ID>
L3PPL Test Previous Outseize Ctrl Instr Data
L3PPL Test Previous Outseize Ctrl Instr
L3PPL Outpulse MFR1 KP Digit using compelled KP Mode
L3PPL Continue Outpulse MFR1 Digits using Compelled KP Mode
PPL Enable Multi Purpose Timer <Timer #> <GPR #>
L3PPL Test CP Event Bit of Onhook <Boolean>
L3PPL Setup Host CP Event of Wink
L3PPL Setup Host CP Event of Offhook <Boolean>
L3PPL Test Outseize Ctrl for any Action ICB
L3PPL Test Outseize Ctrl for all Data ICB
L3PPL Load Current Outseize Ctrl Instr Data [0], Data [1] into GPR <GPR #>
T1PPL Test for Flash Timing
T1PPL Outpulse MFR1 Digits
T1PPL Outpulse DTMF Digits
Index
1375
L3PPL Test Next Inseize Ctrl Instr for Inpulsing Digit Str Cnt
L3PPL Test Next Inseize Ctrl Instr for Collection Method
T1PPL Attach DTMF Digit Receiver
T1PPL Attach MFR1 Digit Receiver
T1PPL Attach MFR1 Digit Receiver (Get Stage # From Next Instr)
L3PPL Test Inseize Ctrl for any Action ICB
L3PPL Test Current Inseize Ctrl Instr for Addr Signaling Type
L3PPL Load GPR with Stage Complete Timer for Current Inseize Ctrl Instr <GPR #>
L3PPL Test Current Inseize Ctrl Instr for Collection Method
L3PPL Test Current Inseize Ctrl Instr for Inpulsing Digit Str Cnt
L3PPL Load Current Inseize Ctrl Instr Data[0], Data [1] into GPR <GPR #>
L3PPL Test Previous Inseize Ctrl Instr Data
L3PPL Test Previous Inseize Ctrl Instr
L3PPL Test Wink Number in Host Generate CP Event
L3PPL Do CPA without Line Signaling
PPL Events
Atomic Functions
AF Number: 59
Name: Send L4 a Q.931 Alerting
Description: 13ppl_af_59() sends a Q.931 L3 - L4 Alerting message.
Input Arg1: NA
Input Arg2: NA
Outputs: NA
AF Number: 72
Name: L3PPL Send L4 a Q.931 Alerting with Cut Thru
*Changed from L3PPL Send L4 a Q.931 Alerting.
Description: Sends a Q.931 L3 - L4 Alerting with Cut Thru message.
Input Arg1: NA
Input Arg2: NA
Outputs: NA
AF Number: 74
Name: L3PPL Send L4 a Setup Indication
MSP
1376
Description: Sends a Setup Indication to Layer 4
Input Arg1: <Config Byte Offset>
Input Arg2: NA
Outputs: NA
AF Number: 76
Name: L3PPL Send L5 INSZ/OUTZ Ctrl Resp with Status in GPR <GPR #>
Description: Sends a INSEIZE_CTRL or OUTSEIZE_CTRL response should an outstanding L5 Inseize/Outseize Control request exist. Response status is stored in the GPR specified in arg1.
Input Arg1: GPR # (1 - 25)
Input Arg2: NA
Outputs: NA
AF Number: 83
Name: L3PPL Test for Outstanding L5 Msg
Description: Tests for any outstanding L5 messages.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0: outstanding L5 messages does not exist.
PPLevINT_EVENT_1: outstanding L5 messages exist.
AF Number: 118
Name: T1PPLXMIT AB Line Signaling <CFG Byte Offset>
Description: Transmits line signaling which is stored in the CFG Byte offset. The value stored in the CFG Byte offset is expected to contain only AB signaling bit combination.
Input Arg1: Config byte offset that contains line signaling.
Range (0 - 3)
Input Arg2: NA
Outputs: NA
AF Number: 119
Name: L3PPL XMIT ABCD Line Signaling <CFG Byte Offset>
Description: Transmits line signaling which is stored in the CFG Byte offset. The value stored in the CFG Byte offset is expected to contain ABCD signaling bit combination.
Input Arg1: CFG Byte offset that contains line signaling.
Index
1377
Range (0 - 15)
Input Arg2: NA
Outputs: NA
AF Number: 120
Name: T1PPL XMIT Line Signaling <AB bits>
Description: Transmits line signaling which is stored in arg1.
Input Arg1: AB signaling bit combination. (0 - 3)
Input Arg2: NA
Outputs: NA
AF Number: 177
Name: L3PPL Store Outseize Ctrl Data ICBs
Description: Stores outseize control instructions data ICBs.
Input Arg1: NA
Input Arg2: NA
Outputs: NA
AF Number: 192
Name: L3PPL Test Current Outseize Ctrl Instr Data
Description: Sets up an internal decision event based on the current outseize ctrl instruction data
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0 + outseize ctrl instruction data
AF Number: 193
Name: L3PPL Compare Next Outseize Ctrl Instr Addr Sig Type <Addr Sig Type>
Description: Compares the next outseize control instruction data outpulsing address signaling type with the address signaling type passed in arg1 and sets up an internal decision event accordingly.
Input Arg1: Address Signaling Type
01 DTMF
02 MFR1 (host does not include KP or ST)
03 MFR2
04 MFR1 (host includes KP and any ST signal)
05 Dial Pulse
MSP
1378
06 MFR1, Transmit Compelled (MF-MDR1)
Input Arg2: NA
Outputs: PPLevINT_EVENT_0: address signaling type does not equal to arg1.
PPLevINT_EVENT_1: address signaling type equal to arg1.
AF Number: 212
Name: L3PPL INIT a Channel Purge with Purge Reason in GPR <GPR #>
Description: Initiates a purge passing the purge reason to L4. Purge reason is stored in the GPR.
Input Arg1: <GPR #> 1 - 25
Input Arg2: NA
Outputs: NA
AF Number: 226
Name: Send PPL Event Indication Message to the Host with GPR Value
Description: Sends a PPL Event Indication message to the host with the event indicated by Arg1. |
The value of the GPR indicated by Arg2 is returned to the host in a PPL GPR Data ICB
(Subtype, 0xFF, Data Length = 4).
Arg1: <PPL Event> See message “PPL Event Indication 0x0043” in the API Reference.
Arg2: <GPR #> 1-25
AF Number: 229
Name: L3 PPL Send L5 Event Indication with General Purpose Register Value <Event ID>
Description: Sends an Event Indication to Layer 5 with GPR value of Event ID
Arg1: <GPR #> 1-25
Arg2: <Not Used>
AF Number: 265
Name: L3PPL Test Previous Outseize Ctrl Instr Data
Description: Tests for previous outseize ctrl instruction data and sets up an internal decision event according.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0 +previous outs ctrl instr data
Index
1379
PPLevINT_EVENT_255: previous outs ctrl instr does not exist
AF Number: 266
Name: L3PPL Test Previous Outseize Ctrl Instr
Description: Tests for previous outseize ctrl instruction and sets up an internal decision event accordingly.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0 + previous outs ctrl instr
PPLevINT_EVENT_225: previous outs ctrl instr does not exist
AF Number: 270
Name: L3PPL Outpulse MFR1 KP Digit using compelled KP Mode
Description: Sends a request to DSP to outpulse digits using compelled KP mode.
Input Arg1: NA
Input Arg2: NA
Outputs: NA
AF Number: 271
Name: L3PPL Continue Outpulse MFR1 Digits using Compelled KP Mode
Description: Sends a request to DSP to remove KP and continue outpulsing digits using compelled KP mode.
Input Arg1: NA
Input Arg2: NA
Outputs: NA
AF Number: 276
Name: PPL Enable Multi Purpose Timer <Timer #> <GPR #>
Description: Enables 1 of 3 multi-purpose timers for use by the PPL. The timer value is stored in GPR indicated in arg2.
Input Arg1: Timer # (1 - 3)
Input Arg2: GPR # (1 - 25)
Outputs: NA
AF Number: 279
Name: L3PPL Test CP Event Bit of Onhook <Boolean>
MSP
1380
Description: Compares call processing event bit of onhook with the value specified in arg1 and sets up an internal decision event accordingly.
Input Arg1: Boolean (0 -1)
Input Arg2: NA
Outputs: PPLevINT_EVENT_0: False
PPLevINT_EVENT_1: True
AF Number: 280
Name: L3PPL Setup Host CP Event of Wink
Description: Sets up a Call Processing event of Wink for possible later reporting to L5. Wink number is extracted from the outseize control message.
Input Arg1: NA
Input Arg2: NA
Outputs: NA
AF Number: 281
Name: L3PPL Setup Host CP Event of Offhook <Boolean>
Description: Sets up a call processing event of offhook for possible later reporting to L5.
Input Arg1: Boolean (0 - 1)
Input Arg2: NA
Outputs: NA
AF Number: 282
Name: L3PPL Setup Host CP Event of Onhook <Boolean>
Description: Sets up a call processing event of onhook for possible later reporting to L5. Also used for onhook host notify.
Input Arg1: Boolean (0 - 1)
Input Arg2: NA
Outputs: NA
AF Number: 285
Name: L3PPL Test Outseize Ctrl for any Action ICB
Description: Checks for the outseize ctrl instructions for an Action ICB and sets up an internal decision event accordingly.
Input Arg1: NA
Input Arg2: NA
Index
1381
Outputs: PPLevINT_EVENT_0: Null
PPLevINT_EVENT_1: Exist
AF Number: 286
Name: L3PPL Test Outseize Ctrl for all Data ICB
Description: Checks for the outseize ctrl instruction for data ICB and sets up an internal decision event accordingly. No action ICB is allowed in the outseize control message.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0: Null
PPLevINT_EVENT_1: Exist
AF Number: 287
Name: L3PPL Load Current Outseize Ctrl Instr Data [0], Data [1] into GPR <GPR #>
Description: Loads current outseize ctrl instruction Data [0], Data [1] into GPR.
Input Arg1: GPR # (1 - 25)
Input Arg2: NA
Outputs: NA
AF Number: 290
Name: T1PPL Test for Flash Timing
Description: Tests if flash timing is enabled.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0: Flash timing not enabled
PPLevINT_EVENT_1: Flash timing enabled
AF Number: 295
Name: T1PPL Outpulse MFR1 Digits
Description: Sends a request to DSP to outpulse MFR1 digits for the stage indicated by the current instruction data.
Input Arg1: NA
Input Arg2: NA
Outputs: NA
AF Number: 300
MSP
1382
Name: T1PPL Outpulse DTMF Digits
Description: Sends a request to DSP to outpulse DTMF digits for the stage indicated by the current instruction data.
Input Arg1: NA
Input Arg2: NA
Outputs: NA
AF Number: 305
Name: L3PPL Test Next Inseize Ctrl Instr for Inpulsing Digit Str Cnt
Description: Tests the inpulsing parameter digit string count for the next inseize ctrl instruction. It is assumed that the next instruction will be receive Stage n.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0: 0 digit strings or invalid string count
PPLevINT_EVENT_1: 1 digit string
PPLevINT_EVENT_2: 2 digit strings
AF Number: 306
Name: L3PPL Test Next Inseize Ctrl Instr for Collection Method
Description Sets up an internal decision event based upon the next stage’s impulsing parameter collection method.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_1: USE_FIXED_NUMBER
PPLevINT_EVENT_2: USE_MULTIPLE_TERM_DIGITS
PPLevINT_EVENT_3: USE_KP_ST
PPLevINT_EVENT_4: USE_FIXED_OR_TERM
PPLevINT_EVENT_5: USE_COMPELLED_MODE
PPLevINT_EVENT_6: USE_KP_ST_ALL
PPLevINT_EVENT_7: USE_COMPELLED_KP
PPLevINT_EVENT_20: default
AF Number: 310
Name: T1PPL Attach DTMF Digit Receiver
Description: Request to collect DTMF digits. The stage of digits to be collected is determined by the next instruction in the instruction list.
Input Arg1: NA
Index
1383
Input Arg2: NA
Outputs: NA
AF Number: 315
Name: T1PPL Attach MFR1 Digit Receiver
Description: Request to collect MFR1 digits. The stage of digits to be collected is determined by the next instruction in the instruction list.
Input Arg1: NA
Input Arg2: NA
Outputs: NA
AF Number: 317
Name: T1PPL Attach MFR1 Digit Receiver (Get Stage # From Next Instr) <PPL CFG Byte #>
Description: Allocates a MFR1 receiver to collect digits. The stage of digits to be collected is determined by the next instruction in the instruction list. It is like Atomic Function 315 with the added feature of configuring the MFR1 tone reception threshold.
Input Arg1: The first argument is the index into the ppl configuration byte array. The value of this byte is absolute value of the minimum dBm level of the MFR1 digits for detection. Valid entries for this ppl_cfg_byte are between 1 and 30, which equate to -1dBm and -30dBm, respectively. The MFR1 receiver will reject any tones below the detection level.
Input Arg2: NA
Outputs: NA
AF Number: 318
Name: T1PPL Attach MFR1 Digit Receiver (Get Stage # From Current Instr) <PPL CFG Byte #>
Description: Allocates a MFR1 receiver to collect digits. The stage of digits to be collected is determined by the current instruction in the instruction list. It is like Atomic Function 316 with the added feature of configuring the MFR1 tone reception threshold.
Input Arg1: The first argument is the index into the ppl configuration byte array. The value of this byte is absolute value of the minimum dBm level of the MFR1 digits for detection. Valid entries for this ppl_cfg_byte are between 1 and 30, which equate to -1dBm and -30dBm, respectively. The MFR1 receiver will reject any tones below the detection level.
Input Arg2: NA
Outputs: NA
MSP
1384
AF Number: 319
Name: L3PPL Test Inseize Ctrl for any Action ICB
Description: Checks the inseize ctrl instruction for any action ICBs and sets up an internal decision event accordingly.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0: Null
PPLevINT_EVENT_1: Exist
AF Number: 320
Name: L3PPL Test Current Inseize Ctrl Instr for Addr Signaling Type
Description: Sets up an internal decision event based upon the current stage’s inpulsing parameter address signaling type.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_1: DTMF
PPLevINT_EVENT_2:MFR1
PPLevINT_EVENT_3: MFR2
PPLevINT_EVENT_4: MFR1_ALL
PPLevINT_EVENT_5: DP
PPLevINT_EVENT_6: COMPELLED_KP
PPLevINT_EVENT_20: Default
AF Number: 321
Name: L3PPL Load GPR with Stage Complete Timer for Current Inseize Ctrl Instr <GPR #>
Description: Loads GPR specified in arg1 with the stage complete timer for the current inseize ctrl instruction.
Input Arg1: GPR # (1 - 25)
Input Arg2: NA
Outputs: NA
AF Number: 322
Name: L3PPL Test Current Inseize Ctrl Instr for Collection Method
Description: Sets up an internal decision event based upon the current stage’s inpulsing parameter collection method.
Input Arg1: NA
Index
1385
Input Arg2: NA
Outputs: PPLevINT_EVENT_1: USE_FIXED_NUMBER
PPLevINT_EVENT_2: USE_MULTIPLE_TERM_DIGITS
PPLevINT_EVENT_3: USE_KP_ST
PPLevINT_EVENT_4: USE_FIXED_OR_TERM
PPLevINT_EVENT_5: USE_COMPELLED_MODE
PPLevINT_EVENT_6: USE_KP_ST_ALL
PPLevINT_EVENT_7: USE_COMPELLED_KP
PPLevINT_EVENT_20: default
AF Number: 323
Name: L3PPL Test Current Inseize Ctrl Instr for Inpulsing Digit Str Cnt
Description: Tests the inpulsing parameter digit string count for the current inseize ctrl instruction.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0: 0 digit strings or invalid string count
PPLevINT_EVENT_1: 1 digit string
PPLevINT_EVENT_2: 2 digit strings
AF Number: 324
Name: L3PPL Load Current Inseize Ctrl Instr Data[0], Data [1] into GPR <GPR #>
Description: Loads current inseize ctrl instruction Data[0], Data [1] into GPR
Input Arg1: GPR # (1 - 25)
Input Arg2: NA
Outputs: NA
AF Number: 325
Name: L3PPL Test Previous Inseize Ctrl Instr Data
Description: Test for previous inseize ctrl instruction data and sets up an internal decision event accordingly.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0 + previous inseize ctrl instr data
PPLevINT_EVENT_255: previous inseize ctrl instr does not exist
MSP
1386
AF Number: 326
Name: L3PPL Test Previous Inseize Ctrl Instr
Description: Tests for previous inseize ctrl instruction and sets up an internal decision event accordingly.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0 + previous inseize ctrl instr does not exist
PPLevINT_EVENT_255: previous inseize ctrl does not exist
AF Number: 330
Name: L3PPL Test Wink Number in Host Generate CP Event
Description: Tests the wink number in the host generate call processing event and sets up an internal decision event accordingly.
Input Arg1: NA
Input Arg2: NA
Outputs: PPLevINT_EVENT_0 + Wink Number
PPLevINT_EVENT_225: No event to process
AF Number: 335
Name: L3PPL Do CPA without Line Signaling
Description: Sends a request to do Call Progress Analysis. The class is taken from the outseize control message.
Input Arg1: NA
Input Arg2: NA
Outputs: NA
PPL Events
Event Number
Event Name Event Description
53 L3PPLevL4GEN_CP_EVENT_WINK Host sends a generate call processing event of Wink on the specified channel.
54 L3PPLev_HOST_CONNECT Event received when the channel that was outseized received a “Connect” sent from the host.
Index
1387
63 L3PPLevL4_XMIT_FLASH Indicates host has sent a Call Processing Event of FLASH on the specified channel.
64 L3PPLevL4_XMIT_ONHOOK Indicates host has sent a Call Processing Event of ONHOOK on the specified channel.
65 L3PPLevL4_XMIT_OFFHOOK Indicates host has sent a Call Processing Event of OFFHOOK on the specified channel.
82 L3PPLevDSP_RESULT_FIRST_DIGIT_RCVD Used for compelled KP. Event received when the first KP digit is received.
100 T1PPLevRCV_LINE_SIG_00 Receive event of AB line signaling. A low B low.
101 T1PPLevRCV_LINE_SIG_01 Receive event of AB line signaling. A low B high.
102 T1PPLevRCV_LINE_SIG_10 Receive event of AB line signaling. A high B low.
103 T1PPLevRCV_LINE_SIG_11 Receive event of AB line signaling. A high B high.
MSP
1388
E1 Atomic Functions
Atomic Functions
Links
Click below to go directly to an Atomic Function.
Atomic Functions
System software version 4.0 or newer is required, unless otherwise noted.
AF Number: 51
Name: Set GPR to # of Digits Received in Stage
Description: Sets the value in the GPR indicated by Arg1 to the number of digits received for the stage indicated by Arg2.
Arg1: <GPR #> 1-25
Arg2: <Stage #> 1-4
AF Number: 52
Name: Store Received Digit in GPR
Description: Stores a single digit received in the GPR indicated by Arg1. If a digit durations reported, it is stored in the GPR indicated by Arg2.
GPR 2: Stage # of the received digits
GPR 3: String # of the received digits
GPR 4: Digit to store (index into digit buffer)
GPR 5: Value of the GPR where the digit is to be stored (1-25).
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 53
Name: Store Digits Received in GPR
Description: Stores a single digit received in the GPR indicated by Arg1. If a digit durations reported, it is stored in the GPR indicated by Arg2.
Arg1: <GPR #> 1-25
Arg2: <GPR #> 1-25
AF Number: 54
Index
1389
Name: L3PPL Store digit at fwd xmit ctr in General Purpose Register
Description: Sets the GPR indicated by Arg 2 to the digit indexed by the Stage number, as indicated by Arg 1
Arg1: <Stage Number> 1:4
Arg2: <General Purpose Register> 1:25
AF Number: 55
Name: L3PPL Store Digit Received in General Purpose Register
Description: Stores a single digit received in the GPR specified by Arg 1
Arg1: <Register Number> 1:25
Arg2: <Not Used>
AF Number: 56
Name: L3PPL Store General Purpose Register in Stage at FWD Xmt Dig Ctr
Description: Stores the digit indexed by the forward transmit digit ctr indicated by Arg 1 into the GPR indicated by Arg 2
Arg1: <Stage Number> 1:4
Arg2: <Register Number> 1:25
AF Number: 60
Name: Send L4 Out of Service/Blocked
Description: Sends a L3 to L4 Out of Service message with a status of Blocked in order to bring the channel out of service in the call processing layer (L4). This message should be sent when a remote blocked line signaling state is detected.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number 61
Name Send a Busied Out Message to Layer 4
Description Sends a L3 to L4 Busied Out message after generating local blocked line signaling due to processing a host Busied Out message. This results in updating the call processing layer (L4) for the local busied-out condition.
Arg1 <Not Used>
Arg2 <Not Used>
AF Number: 62
Name: Send a Q.931 CONNECT Message to Layer 4
MSP
1390
Description: Sends a Q.931 CONNECT message to layer 4 for notification that answer has been detected.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 63
Name: Send a DISCONNECT message to Layer 4
Description: Sends a DISCONNECT message to Layer 4 upon the detection of release signaling from the network.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 64
Name: Send a Q.931 CLEAR ACK to Layer 4
Description: Sends a Layer 3 to Layer 4 CLEAR ACK upon detection of idle signaling from the network after release. This will result in Layer 4 sending a Channel Released message to the host, provided that Layer 4 has previously sent an L4 Clear Req PPL event (#58) to the state machine.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 65
Name: Send an In Service Message to Layer 4
Description: Sends a Layer 3 to Layer 4 In Service message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 66
Name: Send an Out of Service (No Reason) Message to Layer 4
Description: Sends Layer 4 an Out of Service (No Reason) message due to distant end failure to release call.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 67
Name: Send Layer 4 a Call Processing Event message from Call Control Instruction
Description: Sends the host a Call Processing Event message with the event indicated by the current call control instruction and any associated data.
Index
1391
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 68
Name: Send Layer 5 a Call Processing Event Message
Description: Sends the host a Call Processing Event message with the event indicated by Arg1 and any associated data.
Arg1: <Call Processing Event> 117
Arg2: <Not Used>
AF Number: 69
Name: Send a Q.931 SETUP INDICATION to Layer 4 with Address Data
Description: Sends a SETUP INDICATION message to Layer 4 for notification of an incoming call, including any address digits collected to this point. This message will result in Layer 4 sending a Request for Service with Address Data message to the host.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 70
Name: Send a Q.931 SETUP INDICATION to Layer 4
Description: Sends a SETUP INDICATION message to Layer 4 for notification of an incoming call. This message will result in Layer 4 sending a Request for Service message to the host.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 71
Name: Send an Access Denied Message to Layer 4
Description: Sends an ACCESS DENIED message to Layer 4 for notification of an outseize attempt failure, including the failure reason indicated by Arg1 (this should be one of the Outseize Failure message response status).
Arg1 Arg1: <Outseize Failure Status>
Arg2: <Not Used>
AF Number: 72
Name: Send a Q.931 ALERTING Message to Layer 4
Description: Sends a Q.931 ALERTING message to Layer 4 for notification of a successful outseizure.
MSP
1392
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 73
Name: Send Layer 4 a Flash Event Notification
Description: Send Layer 4 a Flash Event Notification. Minimum Software Version: 4.1. Sends a Flash Detected message to L4. To enable host notification, see message Flash Timing Configure 0x0016 in the API Reference.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 74
Name: L3PPL Send a Setup Indication to Layer 4
Description: Sends a setup indication to Layer 4, to report an incoming call with associated address/information signals. The address signaling type is specified by the offset of the Config Byte.
Arg1: <Config Byte Offset> 1 - 200
Arg2:
AF Number: 77
Name: Send Layer 4 a Call Processing Event/Digits Message
Description: Sends Layer 4 a Call Processing Event/Digits message, including the stages of digits to be reported indicated by Arg1. This will result in Layer 4 sending a Call Processing Event/Digits message to the host.
Arg1: <Stages of Digits to Report>
Arg2: <Not Used>
AF Number: 78
Name: Send Call Processing Event /Digits Message
Description: Sends a Call Processing Event /Digits message to the host reporting the digit strings indicated by Arg1.
Arg1: <Stage # Bit Mask>
Bit 0 Stage 1
Bit 1 Stage 2
Bit 2 Stage 3
Bit 3 Stage 4
Arg2: <Not Used>
Index
1393
AF Number: 79
Name: Send Call Processing Event/Digit With Timing Information Message
Description: Sends a Call Processing Event/Digit With Timing Information message to the host reporting a single digit. If digit duration reporting is not enabled, the duration will be 0.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 80
Name: Send Inseize Control or Outseize Control Response to the Host
Description: Sends an Inseize Control or Outseize Control Response to the host with the error indicated by Arg1. The message sent is determined by which message was originally received.
Arg1: <Response Status> See API Reference for values
Arg2: <Not Used>
AF Number: 81
Name: Send a Call Processing Event Message with Event ID
Description: Sends a Call Processing Event message with the PPL Event indicated by Arg1.
Arg1: <PPL Event ID>
Arg2: <Not Used>
AF Number: 82
Name: Set Receive Stage Status (Minimum Software Version: 4.1)
Description: Updates the receive stage status field for the stage indicated by Arg1 to the value indicated by Arg2.
Arg1: <Stage #> 1 - 4
Arg2: <Value>
AF Number: 84
Name: Outpulse BWD R2 Signal in Compelled or Pulsed Mode
Description: Outpulses a BWD R2 signal in either compelled or pulsed mode, depending on the current FWD R2 signaling state. If a FWD R2 signal is present, the BWD R2 signal will be compelled, otherwise it will be pulsed.
Arg1: <BWD R2 Signal> 1 -15 (for both group A and group B).
Arg2: <Value>
MSP
1394
AF Number: 85
Name: Outpulse BWD R2 Signal in Compelled Mode
Description: Outpulses a BWD R2 signal in compelled mode.
Arg1: <BWD R2 Signal> 1 -15 (for both Group A and Group B).
Arg2: <Not Used>
AF Number: 86
Name: Outpulse BWD Pulsed R2 Signal
Description: Outpulses a BWD R2 signal in pulsed mode. The R2 signal value is indicated in Data Byte 2 of a Generate Call Processing Event instruction.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 87
Name: Outpulse BWD Compelled R2 Signal
Description: Outpulses a backward compelled R2 signal. The R2 signal value is indicated in Data Byte 2 of a Generate Call Processing Event instruction.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 88
Name: Outpulse BWD R2 Signal in Compelled Mode/Generate Completion Event
Description: Outpulses a backward R2 signal in compelled mode and instructs the MFDSP card to generate PPL Event 46 (R2 COMP CYCLE COMPLETE) when the R2 cycle is complete (silence is detected in both the forward and backward directions). The R2 signal value is indicated in Data Byte 2 of a Generate Call Processing Event instruction. The PPL must wait in a normal state for this event after executing this atomic function to guarantee that the R2 cycle has completed. Once this event is received, MFC R2 reception/transmission can be cancelled using AF 147.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 89
Name: Outpulse BWD R2 Signal in Compelled Mode/Generate Completion (Using GPR)
Description: Outpulses a backward R2 signal (from GPR indicated by Arg1) in compelled mode and instructs the MFDSP card to generate PPL Event 46 (R2 COMP CYCLE COMPLETE) when the R2 cycle is complete (silence is detected in both the forward and backward directions).
Index
1395
The PPL must wait in a normal state for this event after executing this atomic function to guarantee that the R2 cycle has completed. Once this event is received, MFC R2 reception/transmission can be cancelled using AF 147.
Arg1: <GPR #> 1-25
Arg2: <Not Used>
AF Number: 90
Name: Outpulse FWD R2 Signal in Compelled Mode
Description: Outpulses a forward R2 signal in compelled mode.
Arg1: <FWD R2 Signal> 1-15 (for both Group I and Group II).
Arg2: <Not Used>
AF Number: 91
Name: Outpulse BWD R2 Signal in Compelled or Pulsed Mode
Description: Outpulses a BWD R2 Signal in either compelled or pulsed mode, depending on the current tone receive state. The R2 signal value is indicated in Data Byte 2 of a Generate Call Processing Event message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 92
Name: Outpulse Next FWD Compelled R2 Signal
Description: Transmits the next FWD compelled R2 signal indicated by the FWD R2 Transmit Digit Counter from the stage indicated by Arg1.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 93
Name: Outpulse BWD R2 Signal in Forced Pulsed Mode
Description: Outpulses a backward R2 signal in pulsed mode and waits until the R2 signal has been pulsed to process the next atomic function.
Arg1: <BWD R2 Signal> 1-15 (for both Group A and Group B).
Arg2: <Not Used>
AF Number: 97
Name: L3PPL Outpulse Single MFR1 Digit
Description: Sends a request to TC to outpulse individual MFR1 digits.
Arg1: <Register Number>
MSP
1396
Arg2: <Outp Event Flag>
AF Number: 98
Name: Outpulse MFR1 Digits
Description: Sends an internal message to outpulse the MFR1 digit string(s) contained in the Outpulse Stage N Address Data ICB for the stage indicated in Arg1. Note: There must be a least one DSP configured for MFR1 tone transmission for this function to work.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 99
Name: Outpulse MFR1 Digits for Stage Indicated in Outseize Control Instruction
Description: Sends an internal message to outpulse the MFR1 digit string(s) contained in the Outpulse Stage N Address Data ICB for the stage indicated. Note: There must be at least one DSP configured for MFR1 tone transmission for this function to work.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 100
Name: Outpulse DTMF Digits
Description: Sends an internal message to outpulse the DTMF digit string(s) contained in the Outpulse Stage N Address Data ICB for the stage indicated in Arg1.
Note: There must be a least one DSP configured for DTMF tone transmission for this function to work.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 101
Name: Outpulse DTMF Digits for Stage Indicated in Outseize Control Instruction
Description: Sends an internal message to outpulse the DTMF digit string(s) contained in the Outpulse Stage N Address Data ICB for the stage indicated.
Note: There must be a least one DSP configured for DTMF tone transmission for this function to work.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 102
Index
1397
Name: Cancel Outpulsing Digits
Description: Cancels an outstanding outpulse digits request
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 103
Name: Outpulse DTMF Digits
Description: Minimum Software Version: 4.1
Initiates the collection of DTMF digits for the stage indicated by Arg1 using the timer values specified by the Generic Timer ID indicated by Arg2.
Arg1: <Stage #> 1 - 4
Arg2: <Timer ID> 1-100
AF Number: 104
Name: Outpulse MFR1 Digits
Description: Minimum Software Version: 4.1
Initiates the collection of MFR1 digits for the stage indicated by Arg1 using the timer values specified by the Generic Timer ID indicated by Arg2.
Arg1: <Stage #> 1 - 4
Arg2: <Timer ID> 1-100
AF Number: 105
Name: E1PPL Outpulse MFR1 digits in IFB mode
Description Sends a request to TC to outpulse MFR1 digits for the stage specified in Arg 1, using IFB mode. No KP/ST Framing
Arg1: <Stage Number> 1:4
Arg2: <Number of Cycles> 1:10
AF Number: 106
Name: Outpulse Dial Pulse Digits from Outseize Control Instruction
Description: Sends an internal message to outpulse the Dial Pulse digit string(s) contained in the Outpulse Stage N Address Data ICB for the stage indicated in the ICB. Note: A DSP does not need to be configured for this function to work.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 107
MSP
1398
Name: Outpulse Dial Pulse Digits from Outseize Control Instruction for Stage Indicated
Description: Sends an internal message to outpulse the Dial Pulse digit string(s) contained in the Outpulse Stage N Address Data ICB for the stage indicated by Arg1. Note: A DSP does not need to be configured for this function to work.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 108
Name: Cancel Outpulse Dial Pulse Digits
Description: Cancels an outstanding request for outpulsing Dial Pulse digits.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 109
Name: L3PPL Outpulse DP from fwd xmit ctr in General Purpose Register
Description Sends a request to xsig to outpulse DP digits for stage specified in Arg 1, beginning at the digit specified by the forward xmit digit ctr.
Arg1: <Stage Number> 1:4
Arg2: <Outp Event Flag> 0:1
0 = No outpulse complete event
1 = Send outpulse complete event
AF Number: 112
Name: Generate Tone
Description: Initiates the generation of the tone indicated by Arg1, for the number of cycles indicated by Arg2.
Arg1: <Tone ID> See message Connect Tone Pattern 0x002F in the API Reference.
Arg2: <# of Cycles>
AF Number: 113
Name: Generate Dialtone
Description: Initiates the transmission of North American Standard Dialtone.
Arg1: <Not Used>.
Arg2: <Not Used>
AF Number: 114
Index
1399
Name: Cancel Tone
Description: Cancels the generation of the tone indicated by Arg1.
Arg1: <Not Used>.
Arg2: <Not Used>
AF Number: 121
Name: Transmit Line Signaling
Description: Sets the transmit line signaling for a channel. Note: CCITT recommends that the C bit be low (0) and the D bit be high (1).
Arg1: <ABCD Signaling Bits>
The ABCD signaling bits are a binary mask representing the line signaling bit combination to be transmitted. The bit order is as follows:
Bit # 7 6 5 4 3 2 1 0
Signal Bit A B C D
Arg2: <Not Used>
AF Number: 122
Name: Transmit Default Idle Line Signaling
Description: Transmits the preconfigured idle line signaling ABCD bit pattern.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 123
Name: Enable CAS ABCD Bit Line Signaling Scanning
Description: Activates scanning of the Channel Associated Signaling (CAS) ABCD line signaling bits.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 126
Name: E1PPL Attach MFCR2 Reciever (1 - Forward, 2 - Backward) <PPL-CFG-Byte #>
Description: Allocates a MFR2 receiver for Forward/Backward R2 Reception. The first argument determines the direction of the MFR2 signal. The second argument is the location of the configuration byte that contains the setting for the MFR2 tone reception level.
Arg1: MFR2 direction: 1 - Forward, 2 - Backward
MSP
1400
Arg2: Index to ppl_cfg_byte which determines if MFR2 tone reception level is set to the high (-22dB) or low (-35dB). The index can be from 1 - 200.
AF Number: 127
Name: Setup for FWD Compelled R2 Reception
Description: Allocates a FWD R2 compelled DSP digit receiver. Note: This is a blocking atomic function.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 128
Name: Setup for BWD Compelled R2 Reception
Description: Allocates a BWD R2 compelled DSP digit receiver. Note: This is a blocking atomic function
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 129
Name: Allocate a FWD R2 Digit Buffer for Current Stage
Description: Allocates a forward R2 digit buffer for storing the current stage of address signaling.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 130
Name: Allocate a FWD R2 Digit Buffer
Description: Allocates and initializes a forward R2 signal digit buffer for the stage indicated by Arg1.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 131
Name: Reset FWD R2 Receive Digit Counter for Current Stage
Description: Sets the FWD R2 digit reception counter to 0 for the current address signaling stage.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1401
AF Number: 132
Name: Reset FWD R2 Receive Digit Counter
Description: Initializes the FWD R2 receive digit counter to 0 for the stage indicated by Arg1.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 133
Name: Store BWD R2 Signal as Event
Description: Stores the currently received BWD R2 signal for later reporting as a Call Processing Event.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 134
Name: Set BWD R2 Signal Event Bit
Description: Sets the BWD R2 signal event bit used for later reporting as a Call Processing Event.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 135
Name: Test For FWD Receive Digit Counter Value in Range
Description: Minimum Software Version: 4.1. Test atomic function that compares the number of digits collected in Stage 1 to the minimum and maximum number of digits indicated by Arg1 and Arg2 respectively, and returns an Internal PPL Event according to the results.
Arg1: <GPR #> 1-25
Arg2: <GPR #> 1-25
Test Result PPL Internal Event
<minimum 1
within range 2
> or = to maximum 3
AF Number: 136
Name: Clear Stage/FWD Digit Count
MSP
1402
Description: Clears the digit string and resets the digit count for the stage indicated by Arg1.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 139
Name: Send DSP Service Request to Collect Individual Digits/Make Matrix Slave (Addr Sig Type)
Description Sends a Request Digits message to sym to collect individual digits after call setup.
Arg1: <Address Signal Type> 1:2
Arg2: <Not Used>
AF Number: 140
Name: Setup for DTMF Reception with Inseize Control Instruction
Description: Allocates a DTMF digit receiver. Digit reception parameters used for controlling digit collection are determined by the inpulsing parameters associated with the stage indicated by the current Receive Stage N Inseize Control instruction.
Note: This is a blocking atomic function.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 141
Name: Setup for DTMF Reception
Description Allocates a DTMF digit receiver. Digit reception parameters used for controlling digit collection are determined by the inpulsing parameters associated with the stage indicated by Arg1.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 142
Name: Setup for MFR1 Reception with Inseize Control Instruction
Description: Allocates an MFR1 digit receiver. Digit reception parameters used for controlling digit collection are determined by the inpulsing parameters associated with the stage indicated by the current Receive Stage N Inseize Control instruction. Note: This is a blocking atomic function.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1403
AF Number: 143
Name: Setup for MFR1 Reception
Description: Allocates a MFR1 digit receiver. Digit reception parameters used for controlling digit collection are determined by the inpulsing parameters associated with the stage indicated by Arg1. Note: This is a blocking atomic function.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 144
Name: Setup for Dial Pulse Reception with Inseize Control Instruction
Description: Allocates a Dial Pulse (DP) digit receiver. Digit reception parameters used for controlling digit collection are determined by the inpulsing parameters associated with the stage indicated by the current Receive Stage N Inseize Control instruction.
Note: This is a blocking atomic function.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 145
Name: Setup for Dial Pulse Reception
Description: Allocates a Dial Pulse (DP) digit receiver. Digit reception parameters used for controlling digit collection are determined by the inpulsing parameters associated with the stage indicated by Arg1. Note: This is a blocking atomic function.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 146
Name: Send DSP Service Request to Collect Individual Digits
Description Sends a request to collect single digits after call setup and report digit to the host with a Call Processing Event of Digits. The Address Signaling Type is indicated by Arg1.
Arg1: <Address Signaling Type>
1 = DTMF
2 = MFR1
3= MFR2
Arg2: <Not Used>
Note: The following PPL Configuration Bytes must be configured prior to invoking this function:
MSP
1404
Bytes 196, 197 Digit Timer (MSB, LSB) = The maximum amount of time to wait for the digit. A value of 0xFFFF disables this timer.
Byte 198 0 = disabled, 1 = enabled)
Bit 0 = Report the digit at its falling edge (when the first digit is released). If the bit is not set the digit will be reported at its rising edge (when the digit is first pressed).
Bit 1 - Ignore # character as first digit.
Bit 2 = Report digit duration (the amount of time the digit has been pressed). Valid only if configuration bit# 0 is 1.
Bytes 199, 200 Minimum Receive Digit Duration Timer (MSB, LSB) = The minimum amount of time for a digit to be present before it is detected and validated.
AF Number: 147
Name: Cancel R2 Reception
Description: Releases an MFR2 signal receiver. This function can be used to release R2 receivers used for forward and backward R2 reception.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 148
Name: Collect DTMF Digits
Description: Minimum Software Version: 4.1 Initiates the collection of DTMF digits using the timers defined in the Config Bytes (Arg1) with the values specified by the Generic Timer ID indicated by Arg2.
Arg1: <Config Byte #> 1- 200
Arg2: <Timer ID> 1-100
AF Number: 149
Name: Collect MFR1 Digits
Description: Minimum Software Version: 4.1
Initiates the collection of MFR1 digits using the timers defined in the Config Bytes (Arg1) with the values specified by the Generic Timer ID indicated by Arg2.
Arg1: <Config Byte #> 1- 200
Arg2: <Timer ID> 1-100
AF Number: 150
Name: Send Request To Do Call Progress Analysis For Class 0 (North American)
Description: Sends an internal message to do Call Progress Analysis for Class 0 (North American). Note: There must be a least one DSP configured for call progress analysis for this function to work.
Index
1405
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 151
Name: Test Call Progress Analysis Result and Set up Internal Event
Description: Tests the result of Call Progress Analysis.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
Answer 80
Error 81
Continuous On 82
Max Silence Timeout 83
Not Determined Timeout
84
Max Determined Timeout
85
Signaling Answer 86
Dialtone 87
Other 0
AF Number: 152
Name: Report Call Progress Analysis Result to the Host
Description: Reports the Call Progress Analysis result indicated by Arg1 to the host.
Arg1: <Call Progress Analysis Result>
Arg2: <Not Used>
AF Number: 153
Name: Report Call Progress Analysis Result from Atomic Function 151 to the Host
Description: Reports the Call Progress Analysis result from Atomic Function 151 to the host.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 154
MSP
1406
Name: Send Request To Do Call Progress Analysis (Class From Arg1)
Description: Sends a request to do Call Progress Analysis for the class indicated by Arg1.
Arg1: <Call Progress Analysis Class>
Arg2: <Not Used>
AF Number: 155
Name: Send Request To Do Call Progress Analysis (Class from Outseize Control Message)
Description: Sends a request to do Call Progress Analysis for the class indicated by an Outseize Control message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 156
Name: Cancel Call Progress Analysis
Description: Sends a request to cancel Call Progress Analysis.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 157
Name: CPC Detection
Description: Initiates CPC detection.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 158
Name: Cancel CPC Detection
Description: Cancels CPC detection.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 159
Name: Reset FWD R2 Transmit Digit Counter to 1
Description: Sets the generate FWD R2 signal counter to 1 for initiation of FWD R2 signal transmission.
Arg1: <Not Used>
Index
1407
Arg2: <Not Used>
AF Number: 160
Name: Increment FWD R2 Transmit Digit Counter by 1
Description: Increments the generate FWD R2 signal counter by 1.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number 161
Name Decrement FWD R2 Transmit Digit Counter by 1
Description Decrements the generate FWD R2 signal counter by 1.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number 162
Name Decrement FWD R2 Transmit Digit Counter by 2
Description Decrements the generate FWD R2 signal counter by 2.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 163
Name: Decrement FWD R2 Transmit Digit Counter by 3
Description: Decrements the generate FWD R2 signal counter by 3.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 164
Name: Test if Current FWD Digit Count > Stage Digit Count
Description: Tests if the current FWD digit count is greater than the stage digit count for the stage number indicated by Arg1.
Arg1: Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
Test Result
PPL Internal Event
Greater than
1
MSP
1408
Other 0
AF Number: 165
Name: Test if Current FWD Digit Count <>== Stage Digit Count
Description: Tests if the current FWD digit count is greater than, less than, or equal to the stage digit count for the stage number indicated by Arg1.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
Test Result
PPL Internal Event
== 0
< 1
> 2
AF Number: 166
Name: Test if FWD Stage Digit Count == 0
Description: Tests if the current FWD digit count for the stage number indicated by Arg1 equals 0.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
Test Result PPL Internal Event
== 0 0
Other 1
AF Number: 167
Name: Store FWD Transmit Digit Counter Value in GPR
Description: Minimum Software Version: 4.1
Stores the value of the forward digit counter (i.e. number of digits received) for the current call in a GPR.
Arg1: <GPR #> 1-25
Arg2: <Not Used>
AF Number: 168
Name: Store GPR Value in FWD Transmit Digit Counter
Description: Transfers the contents of a General Purpose register into the forward digit counter for the current call.
Index
1409
Arg1: <GPR #> 1-25
Arg2: <Not Used>
AF Number: 169
Name: L3PPL Test if Current Xmit Digit Ctr = Stage Digit Count
Description: Checks that the total number of FWD digits to be transmitted is equal to the current FWD transmit digit counter.
Arg1: <Stage Number> 1:25
Arg2: <Not Used>
AF Number: 170
Name: Store FWD R2 Signal
Description: Stores the current FWD R2 signal in the digit buffer assigned to the receive digit stage indicated by Arg1. R2 FWD signals are stored in BCD encoded format. The location within the digit buffer where the signal is stored is determined by the current FWD digit counter.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 171
Name: Test If Digit Count == 0xFF
Description: Tests if the digit count for the stage number indicated by Arg1 equals 0xFF.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
Test Result PPL Internal Event
== 0xFF 2
< 0xFF 1
Other 0
AF Number: 172
Name: Setup Host Call Processing Event/Digits
Description: Sets up a Call Processing Event/Digits message to send to the host upon collection of a complete stage of digits.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
MSP
1410
AF Number: 173
Name: Increment Receive FWD R2 Digit Counter
Description: Increments the current receive stage digit counter due to reception of a FWD R2 signal.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 174
Name: Store L4 Inseize/Outseize ICBsr
Description: Stores Layer 4 Inseize or Outseize Control ICBs for later processing. These ICBs contain inseize or outseize instructions and related data (i.e.: R2 signal to generate). Layer 4 will send Layer 3 an Inseize Control or Outseize Control message after receiving and preprocessing a host Inseize Control or Outseize Control message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number 175
Name Test for Prior Sending of Layer 3 to Layer 4 SETUP INDICATION
Description Tests if an L3 to L4 SETUP INDICATION message has been previously sent.
Note: A SETUP INDICATION is sent to the Call Processing Layer (L4) to indicate that an incoming call has been received.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
Sent 1
Not Sent 0
AF Number: 179
Name: Use Pre-programmed Inseize Instruction List
Description: Points a channel to the inseize instruction list preconfigured on the channel with the Inseize Instruction List Configure message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 180
Name: Use Instructions in Inseize Control or Outseize Control message
Index
1411
Description: Points a channel to the inseize or outseize instruction list provided by the host through an interactive Inseize Control or Outseize Control message. Note: This function can be used for both inseize and outseize instruction processing.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 181
Name: Reset Instruction Index
Description: Resets the current inseize or outseize instruction pointer to instruction 1. Note: This function can be used for both inseize and outseize instruction processing.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 182
Name: Increment Instruction Index
Description: Increments the current inseize or outseize instruction pointer to the next instruction #. Note: This function can be used for both inseize and outseize instruction #. processing
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 183
Name: Test Current Inseize Control Instruction
Description: Tests for the current Inseize Control instruction
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
Null 0
Report Call Processing Event
1
Generate Call Processing Event
2
Receive Stage n Data 3
Wait for Host Control 4
Report Incoming Call 5
MSP
1412
Report Incoming Call with Data
6
Generate Inseize ACK 7
Send Host Inseize ACK 8
Use Instruction List 9
Other 20
AF Number: 184
Name: Set Call Control Instruction Index to Host Value
Description: Sets the call control instruction index to that indicated in the Use Instruction List ICB sent in an interactive Inseize Control or Outseize Control message by the host.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 185
Name: 3
Description: Tests the stage number in the current Inseize Control Instruction. The stage # is determined by the Receive Stage N Address Data Inseize Control instruction currently being processed.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result
PPL Internal Event
Stage # 1 1
Stage # 2 2
Stage # 3 3
Stage # 4 4
Other 0xFF
AF Number: 186
Name: Test Next Inseize Control Instruction
Description: Tests if the next Inseize Control Instruction is Receive Stage N Address Data.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1413
Test Result PPL Internal Event
Receive Stage N Address Data
1
Other 0
AF Number: 187
Name: Test Inseize Control Generate Call Processing Event Instruction
Description: Tests if the next Inseize Control Instruction is Receive Stage N Address Data.
Arg1: <Not Used>
Arg2: <Not Used>
Result PPL Internal Event
ANI Request Off Hook 5
Wink 1 6
Wink 2 7
Wink 3 8
Wink 4 9
Wink 5 10
Wink 6 11
Wink 7 12
Wink 8 13
BWD Pulsed R2 Signal 1
BWD Compelled R2 Signal 2
BWD Compelled R2 Signal with Cycle Completion
3
BWD Compelled or Pulsed R2 Signal 4
AF Number: 188
Name: Test Next Inseize Control Instruction for Address Signaling Type
Description: Tests for the receive signaling type from the inpulsing parameters of a stage. The stage number is obtained from the next Inseize Control Instruction, as indicated by the current instruction index (provided that it is a Receive Stage N instruction)..
Arg1: <Not Used>
Arg2: <Not Used>
MSP
1414
Test Result
PPL Internal Event
DTMF 1
MFR1 2
MFR2 3
Other 20
AF Number: 189
Name: Test Address Signaling Type of Stage N Inpulsing Parameters
Description: Tests the inpulsing parameters of the stage indicated by Arg1 for its receive signaling type.
Arg1: Stage #> 1 - 4
Arg2: <Not Used>
Test Result PPL Internal Event
DTMF 1
MFR1 2
MFR2 3
Other 20
AF Number: 190
Name: Return Inpulsing Signaling Type
Description: Tests for the receive signaling type from the inpulsing parameters of a stage. The stage number is obtained from the current Inseize Control Instruction, as indicated by the current instruction index (provided that it is a Receive Stage N instruction).
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
DTMF 1
MFR1 2
MFR2 3
Other 20
AF Number: 194
Name: Test for Outseize Control ICB Buffer
Index
1415
Description: Tests if the Outseize Control ICB buffer is attached to the Layer 4 to Layer 3 CALL REQUEST message.
Arg1: <Not Used>
Arg2: <Not Used>
Result PPL
Internal Event
Yes 1
No 0
AF Number: 195
Name: Test for Host Outseize Control Instructions
Description: Tests if there are Outseize Control Instructions from the host.
Arg1: <Not Used>
Arg2: <Not Used>
Result PPL
Internal Event
Yes 1
No 0
AF Number: 196
Name: Use Pre-programmed Outseize Instruction List
Description: Points a channel to use the channels pre-programmed outseize instruction list.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number 197
Name Test Current Outseize Control Instruction
Description Tests for the current Outseize Control instruction.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
Null 0
Scan for Wink 1 1
Scan for ANI Request Off-hook 2
MSP
1416
Scan for Dialtone 3
Report Call Processing Event 4
Outpulse Stage N Digits 5
Wait for Host Address Data 6
Wait for Host Control 7
Send Host Acknowledgment 8
Do Call Progress Analysis 9
Seize 10
Use Pre-programmed Instruction List
11
Cancel R2 Receiver 13
Scan for Backward R2 Signal 14
Wait for Host Control with Answer Supervision
15
Other 20
AF Number: 198
Name: Test for Outpulsing Data ICB
Description: Tests if there are host-supplied outpulsing digits for the current stage.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result
PPL Internal Event
Yes 1
No 0
AF Number 199
Name Test Address Signaling Type of Outpulse Stage N Address Data for Current Stage
Description Tests the address signaling type in the Outpulse Stage N Address Data ICB for the current stage. The stage number is obtained from the current outseize control instruction from list, provided that it is an Outpulse Stage N instruction.
Arg1: <Not Used>
Arg2: <Not Used>
Result PPL Internal Event
Index
1417
DTMF 1
MFR1 2
MFR2 3
MFR1 ALL 4
Dial Pulse 5
Compelled KP 6
Other 20
AF Number: 200
Name: Transfer Remaining Digits
Description: Takes digits remaining from the stage indicated by Arg1 and dynamically creates a Data ICB with the remaining address data for the stage indicated by Arg2.
Arg1: Stage #> 1 - 4
Arg2: <Stage #> 1 - 4
Note: If a Data ICB already exists for the stage indicated by Arg2, any digits it contains will be over-written by the digits from the stage indicated by Arg1.
AF Number: 201
Name: Return Config
Description: Byte #
Stores: the Config Offset where Outseize Control Instructions end in the GPR indicated by Arg1. The Config Byte indicated by Arg2 indicates where the Outseize Control Instructions begin.
Arg1: Arg1: <GPR #> 1-25
Arg2: <Config Byte #> 1- 200
AF Number 202
Name Test for Outpulsing Data ICB
Description Minimum Software Version: 4.1. Tests if there are host-supplied outpulsing digits for the current stage
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
Result PPL Internal Event
No 0
Yes 1
MSP
1418
AF Number: 203
Name: Test Address Signaling Type of Outpulse Stage N Address Data for Current Stage
Description: Minimum Software Version: 4.1. Tests the address signaling type in the Outpulse Stage N Address Data ICB for the stage indicated by Arg1.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
Test Result PPL Internal Event
DTMF 1
MFR1 2
MFR2 3
MFR1 ALL 4
Dial Pulse 5
Compelled KP 6
Other 20
AF Number: 204
Name: Store Digit Collection Status
Description: Stores the digit collection status for the stage indicated in the current Receive Stage N Address Data inseize control instruction.
Arg1: <Status #>
66 - Digits Received
67 - First Digit Timeout
68 - Inter-digit Timeout
69 - Digits Complete Timeout
Arg2: <Not Used>
AF Number: 205
Name: Store Digits
Description: Stores a DSP decoded digit string in the inpulsing stage digit buffer associated with the stage indicated in the current Receive Stage N Address Data inseize control instruction data.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1419
AF Number: 206
Name: Store Digits
Description: Stores a DSP decoded digit string in the inpulsing stage digit buffer associated with the stage indicated by Arg1.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 207
Name: Update Timeout Status
Description: Minimum Software Version: 4.1
Updates the Receive digit status for the stage indicated by Arg2 according to the test results shown below. The status is reported in the Request for Service with Data message.
Arg1: <Timeout Value>
Arg2: <Stage #> 1 - 4
Test Result Status
Digits Received 0x10 (Positive ACK)
First Digit Timeout 0x81(Permanent Signal Condition)
Interdigit Timeout 0x80 (Partial Dial Condition)
Digits Complete Timeout 0x92 (Inpulsing Complete Timeout)
AF Number: 208
Name: Store Single Digit in Stage
Description: Minimum Software Version: 4.1
Stores a single digit in the Receive Stage digit buffer for the stage indicated by Arg1. PPL Event 66 (DSP Result Digits) must be the event received immediately preceding this AF.
Arg1: <Stage #> 1 - 4
Arg2: <Not Used>
AF Number: 210
Name: Initiate a Channel Purge
Description: Resets a channel due to an unrecoverable error. Any associations which exist with this channel will also get implicated in the purging process.
Arg1: <Purge Reason>
Refer to message DSO Status Change 0x0042 in the API Reference for purge reasons.
MSP
1420
Arg2: <Not Used>
AF Number: 211
Name: Ignore PPL Event
Description: Event will be ignored (will not result in the generation of an Invalid Event indication)..
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 215
Name: Change PPL Protocol
Description: Changes a channels protocol to the protocol indicated by Arg1.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 216
Name: Restore Channels Preconfigured PPL Protocol
Description: Restores a channel's PPL protocol to the default preassigned protocol.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 225
Name: Send PPL Event Indication Message to the Host
Description: Sends a PPL Event Indication message to the host with the event indicated by Arg1. The ICB Count is 0.
Arg1: <PPL Event> See message PPL Event Indication 0x0043 in the API Reference.
Arg2: <Not Used>
AF Number: 226
Name: Send PPL Event Indication Message to the Host with GPR Value
Description: Sends a PPL Event Indication message to the host with the event indicated by Arg1. |
The value of the GPR indicated by Arg2 is returned to the host in a PPL GPR Data ICB
(Subtype, 0xFF, Data Length = 4).
Arg1: <PPL Event> See message PPL Event Indication 0x0043 in the API Reference.
Arg2: <GPR #> 1-25
Index
1421
AF Number: 227
Name: Send PPL Event Request ACK to Host
Description: Sends a response to a PPL Event Request message with the status value indicated by Arg1.
Arg1: <Value>
Arg2: <Not Used>
AF Number: 229
Name: L3 PPL Send L5 Event Indication with General Purpose Register Value <Event ID>
Description: Sends an Event Indication to Layer 5 with GPR value of Event ID
Arg1: <GPR #> 1-25
Arg2: <Not Used>
AF Number: 235
Name: Connect Recorded Announcement (Announcement ID)
Description: This function connects a single announcement.
Arg1: <Announcement ID> 0 to 1023.
Arg2: <Options>
Bit Mask. Setting the bit to 1 enables the event.
bit 0 = Start Announcement
bit 1 = Terminate Announcement
bit 2 = Barge In
AF Number: 236
Name: Connect Recorded Announcement (Config Byte)
Description: This function connects a single announcement. Arg1 indicates the index into the Config Byte containing the Announcement ID. Arg2 indicates the event options.
Arg1: <Config Byte #> 1- 200
Arg2: <Options>
Bit Mask. Setting the bit to 1 enables the event.
bit 0 = Start Announcement
bit 1 = Terminate Announcement
bit 2 = Barge In
AF Number: 237
MSP
1422
Name: Connect Recorded Announcement (GPR)
Description: This function connects a single announcement. Arg1 indicates the GPR containing the Announcement ID. Arg2 indicates the event options.
Arg1: <GPR #> 1- 25
Arg2: <Options>
Bit Mask. Setting the bit to 1 enables the event.
bit 0 = Start Announcement
bit 1 = Terminate Announcement
bit 2 = Barge In
AF Number: 238
Name: Connect Recorded Announcement (GPR/Config Byte)
Description: This function connects a single announcement. Arg1 indicates the GPR containing the index into the Config Byte containing the Announcement ID. Arg2 indicates the event options.
Arg1: <GPR #> 1- 25
Arg2: <Options>
Bit Mask. Setting the bit to 1 enables the event.
bit 0 = Start Announcement
bit 1 = Terminate Announcement
bit 2 = Barge In
AF Number: 239
Name: Connect Chained Recorded Announcement (GPR)
Description: This function connects a chained announcement without start and stop events.
Arg1 indicates the GPR containing the Announcement ID of the first announcement. Subsequent announcements are stored in subsequent GPRs. Arg2 indicates the GPR containing the number of announcements to be played.
Arg1: <GPR #> 1- 25
Arg2: <GPR #> 1- 25
AF Number: 240
Name: Connect Chained Recorded Announcement with Start Event (GPR)
Description: This function connects a chained announcement with start event.
Arg1 indicates the GPR containing the Announcement ID of the first announcement. Subsequent announcements are stored in subsequent GPRs.
Arg2 indicates the GPR containing the number of announcements to be played.
Index
1423
Arg1: <GPR #> 1- 25
Arg2: <GPR #> 1- 25
AF Number: 241
Name: Connect Chained Recorded Announcement with Termination Event (GPR)
Description: Minimum Software Version: 4.1
This function connects a chained announcement with stop event.
Arg1 indicates the GPR containing the Announcement ID of the first announcement. Subsequent announcements are stored in subsequent GPRs.
Arg2 indicates the GPR containing the number of announcements to be played.
Arg1: <GPR #> 1- 25
Arg2: <GPR #> 1- 25
AF Number: 243
Name: Cancel Announcement
Description: This functions disconnect a channel from an announcement.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 341
Name: L3PPL OUTP Non-Compelled R2 Sig w/o Blocking
Description: Sends a request to TC to outpulse a non-compelled R2 signal. It does not enter an internal blocking state to wait for the R2 signal to be outpulsed.
Arg1: <R2 sig> 1:15
Arg2: <direction> 1:2
AF Number: 342
Name: 3PPL OUTP Next Non-Compelled FWD R2 Sig w/o Blocking
Description: Sends a request to TC to outpulse non-compelled forward R2 signal, following the forward R2 transmit digit counter. Updates the digit counter and enters blocking state until R2 signals are outpulsed.
Arg1: <Stage Number> 1:4
Arg2: <Digit Count> 1:255
AF Number: 343
Name: L3PPL OUTP Next Non-Compelled FWD R2 Sig w/o Blocking
MSP
1424
Description: Sends a request to TC to outpulse nest non-compelled forward R2 signal, following the forward R2 transmit digit counter. Updates the forward R2 transmit digit counter. Does not enter internal blocking state to wait for R2 signal to be outpulsed.
Arg1: <Stage Number> 1:4
Arg2: <Digit Count> 1:255
AF Number: 344
Name: L3PPL Setup Non-Compelled FWD R2 Digit Reception
Description: Sends a request to TC to attach a non-compelled forward R2 signal receiver for non-compelled forward R2 signals of the stage specified in Arg 1. Enters an internal blocking state before proceeding, until the receiver is attached.
Arg1: <Stage Number> 1:4
Arg2: <Not Used>
AF Number: 345
Name: L3PPL Setup Non-Compelled R2 Digit Reception Indefinitely
Description: Sends a request to TC to attach a non-compelled R2 signal receiver for non-compelled forward or backward R2 signals. The receiver is attached until a Cancel Digit Reception is sent. Before proceeding, it enters an internal blocking state until the receiver is attached.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 346
Name: L3PPL Setup Non-Compelled R2 Digit Reception for Fixed Digits
Description: Sends a request to TC to attach a noon-compelled R2 signal receiver for non-compelled forward or backward R2 signals. The receiver is attached until the specified number of digits is received. before proceeding, it enters an internal blocking state until the receiver is attached.
Arg1: <Digit Count> 1:255
Arg2: <Not Used>
AF Number: 347
Name: L3PPL OUTP Non-Compelled BWD R2 Sig in Inseize Instruction
Description: Sends a request to TC to outpulse a non-compelled backward R2 signal in pulsed mode. This R2 signal is stored in a Generate Call Processing Event message.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1425
AF: Number 360
Name: E1PPL Attach MFR1 Digit Receiver (Get Stage # From Next Instr) <PPL CFG Byte #>
Description: Allocates a MFR1 receiver to collect digits. The stage of digits to be collected is determined by the current instruction in the instruction list and the MFR1 tone reception threshold is determined by argument 1.
Arg1: The first argument is the index into the ppl configuration byte array. The value of this byte is absolute value of the minimum dBm level of the MFR1 digits for detection. Valid entries for this ppl_cfg_byte are between 1 and 30, which equate to -1dBm and -30dBm, respectively. The MFR1 receiver will reject any tones below the detection level.
Arg2: <Not Used>
AF Number: 361
Name: T1PPL Attach MFR1 Digit Receiver (Get Stage # From Current Instr) <PPL CFG Byte #>
Description: Allocates a MFR1 receiver to collect digits. The stage of digits to be collected is determined by the current instruction in the instruction list and the MFR1 tone reception threshold is determined by argument 1.
Arg1: The first argument is the index into the ppl configuration byte array. The value of this byte is absolute value of the minimum dBm level of the MFR1 digits for detection. Valid entries for this ppl_cfg_byte are between 1 and 30, which equate to -1dBm and -30dBm, respectively. The MFR1 receiver will reject any tones below the detection level.
Arg2: <Not Used>
MSP
1426
VDAC IP Network Interface Atomic Functions
Atomic Functions
AF Number: 46
Name: Enable multipurpose timer
Type: Normal/Blocking/Test:Normal
Description: Enable 1 of 3 multipurpose timers indicated in Arg 1.
The value of the timer is stored in the timer indicated in Arg 2.
Arg 1: Timer Number (1 – 3)
Arg 2: Timer ID (1 – 100)
AF Number: 47
Name: Disable multipurpose timer
Type: Normal/Blocking/Test:Normal
Description: Disable 1 of 3 multipurpose timers indicated in Arg 1.
Arg 1: Timer number (1 – 3)
Arg 2: Reserved
AF Number: 55
Name: Initiate a channel purge
Type: Normal/Blocking/Test Normal
Description: Initiate a channel purge and pass the purge reason indicated in Arg 1 to Layer 4.
Arg 1: Purge reason (0 – 255)
Arg 2: Reserved
AF Number: 60
Name: Send DSP a Request Resource message
Type: Normal/Blocking/Test: Normal
Description: Send a request to DSP to connect to an available DSP channel.
Arg 1: Reserved
Arg 2: Reserved
AF Number: 61
Name: Send DSP a Release Resource message
Type: Normal/Blocking/Test: Normal
Index
1427
Description: Send a request to DSP to disconnect from a previously-connected DSP channel
Arg 1: Reserved
Arg 2: Reserved
AF Number: 70
Name: Send Layer 4 a Connect message (Answer)
Type: Normal/Blocking/Test: Normal
Description: Sends a Connect message to Layer 4.
Arg1: Reserved
Arg2: Reserved
AF Number: 71
Name: Send Layer 4 an Access Denied message
Type: Normal/Blocking/Test: Normal
Description: Send an Access Denied message to Layer 4 due to a failed connection attempt. Failure reason is indicated in Arg 1.
Arg1: Status ( 0 – 255)
Arg2: Reserved
AF Number: 72
Name: Send Layer 4 an alerting message
Type: Normal/Blocking/Test: Normal
Description: Sends an alerting message to Layer 4
Arg1: Reserved
Arg2: Reserved
AF Number: 73
Name: Send Layer 4 a clear Ack.message
Type: Normal/Blocking/Test: Normal
Description: Sends a clear request Ack. to Layer 4, with successful and lost RTP packets
Arg1: Reserved
Arg2: Reserved
AF Number: 74
Name: Send Layer 4 an In Service message
MSP
1428
Type: Normal/Blocking/Test: Normal
Description: Sends an In Service message to Layer 4
Arg1: Reserved
Arg2: Reserved
AF Number: 75
Name: Send Layer 4 a Disconnect message
Type: Normal/Blocking/Test: Normal
Description: Sends a Disconnect message to Layer 4
Arg1: Reserved
Arg2: Reserved
AF Number: 76
Name: Send Layer 4 a Clear Request acknowledgment without data
Type: Normal/Blocking/Test: Normal
Description: Sends a Clear Request acknowledgment to Layer 4, with no RTP packets status
Arg1: Reserved
Arg2: Reserved
AF Number: 80
Name: Send outseize control response
Type: Normal/Blocking/Test: Normal
Description: Sends a response to the Outseize Control message.
Arg1: Status (0 – 255)
Arg2: Reserved
AF Number: 85
Name: Store message into a temporary storage buffer
Type: Normal/Blocking/Test: Normal
Description: Saves the current message, including attached data, into a temporary storage buffer to use later.
Arg1: Reserved
Arg2: Reserved
AF Number: 90
Index
1429
Name: Send Layer 5 a PPL Event Request Acknowledgment
Type: Normal/Blocking/Test: Normal
Description: Send s a PPL Event Request acknowledgment to Layer 5.
Arg1: Status (0 – 255)
Arg2: Reserved
AF Number: 91
Name: Send Layer 5 a PPL Event Indication
Type: Normal/Blocking/Test: Normal
Description: Sends a PPL Event Indication to Layer 5.
Arg1: Event Number (0 – 255)
Arg2: Reserved
AF Number: 92
Name: Send Layer 5 a PPL Event Indication with General Purpose Register value
Type: Normal/Blocking/Test: Normal
Description: Sends a PPL Event Indication to Layer 5 along with the value of the specified General Purpose Register.
Arg1: Event Number (0 – 255)
Arg2: General Purpose Register number (0 – 53)
AF Number: 95
Name: DSPM setup resource
Type: Normal/Blocking/Test: Normal
Description: Sets up the resources required to communicate with the DSP Manager. This function should be called after the DSP Manager acknowledges the DSP resource request with a response of “DSP Resource Available”
Arg1: Reserved
Arg2: Reserved
AF Number: 96
Name: DSPM connect resource to TDM
Type: Normal/Blocking/Test: Normal
Description: Connects a DSP resource to the TDM bus. This function should be called after a resource has been setup.
Arg1: Reserved
Arg2: Reserved
MSP
1430
AF Number: 97
Name: DSPM disconnect resource from TDM
Type: Normal/Blocking/Test: Normal
Description: Disconnects a DSP resource to the TDM bus.
Arg1: Reserved
Arg2: Reserved
AF Number: 98
Name: DSPM remove resource.
Type: Normal/Blocking/Test: Normal
Description: Removes a DSP resource. This function should be called after all communication with the DSP Manager is completed.
Arg1: Reserved
Arg2: Reserved
Index
1431
Layer 4 Atomic Functions
Call Control Channel Management (0x0061)
Atomic Functions
The following Atomic Functions (AF) are specific to the MSP 1010 Call Control Channel Management component (0x0061).
AF Number 51
Name Store a L5 message type and sequence # from current message and return L5 reference ID in GPR
Description Allocates a node in the L5 reference linked list, stores the message type and sequence number, and returns the reference ID in the GPR # specified in Arg1.
Arg1 <GPR #>
Arg2 <Not Used>
AF Number 52
Name ACK L5 message using L5 outgoing buffer for L5 reference ID
Description Sends an acknowledgment for the message in the L5 message linked list, de-allocates the entry, and frees the reference ID. Also returns internal event 1 if the reference ID is found and the ACK is sent and 0 on failure.
Arg1 <GPR # containing Layer 5 Reference ID>
Arg2 <GPR # containing ACK Status>
AF Number: 53
Name: Block Invalid Events for State
Description: Queues invalid events in the next state until the next state.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 54
Name: Send L5 PPL Event Indication using outgoing L5 buffer
Description: Sends a PPL Event indication message to L5 with data in the outgoing L5 buffer.
Arg1: <Event ID>
Arg2 <Not Used>
AF Number: 55
Name: Clear L5 Reference ID
MSP
1432
Description: De-allocates the L5 reference link with the specified ID.
Arg1: <GPR # containing the Layer 5 Reference ID>
Arg2: <Not Used>
AF Number: 56
Name: ACK L5 message using L5 outgoing buffer for L5 reference ID with more status
Description: Sends an acknowledgment for the message in the L5 message LL. Also de-allocates the entry and frees the Reference ID. The more status is the last normal state of the PPL state machine. Also returns internal event 1 if the reference ID is found and the ACK is sent and 0 on failure.
Arg1: <GPR # containing Reference ID>
Arg2: <ACK Status>
AF Number: 57
Name: Stop all CH Timers
Description: Cancels any outstanding CH timers
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 58
Name: Purge channel with reason
Description: Initiates a purge of the channel any associated channel through the CM.
Arg1: <Reason>
Arg2: <Not Used>
AF Number: 59
Name: Test Host message resend enabled flag
Description: Tests the host configuration resend enable flag for messages
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 60
Name: Test Host RFS retry forever flag
Description: Test the host configuration RFS resend flag.
Arg1: <Not Used>
Index
1433
Arg2: <Not Used>
AF Number: 61
Name: ACK L5 message using L5 outgoing buffer for L5 Reference ID
Description: Sends an acknowledgment for the message in the L5 message LL. Also de-allocates the entry and frees the Reference ID.
Arg1: <GPR # containing Layer 5 Reference ID>
Arg2: <ACK Status>
AF Number: 62
Name: Update local channel parameters based on RW L3 data and incoming message in buffer
Description: Updates the shared RW local channel parameters based on the private RW channel parameters and any appropriate TLVs in the incoming buffer specified by arg1. This is how dB Padding and release modes are dynamically set.
Arg1: <Buffer>
0 = Use default (no buffer)
1 = Layer 5 Incoming Buffer
2 = Layer 4 Incoming Buffer
Arg2: <Not Used>
AF Number: 63
Name: Test for DSP Resource Free Request in incoming message buffer
Description: Tests for a DSP Resource Free TLV for the channel in the selected buffer. Returns internal event 0 if the TLV is not found, internal event 1 = free digit receiver, internal event 2 = free call progress transmitter, internal event 3 = free both.
Arg1: <Buffer>
1 = Layer 5 Incoming Buffer
2 = Layer 4 Incoming Buffer
Arg2: <Not Used>
AF Number: 64
Name: Test Host Link Connection Status
Description: Tests host link connection status.
Arg1: <Not Used>
Arg2: <Not Used>
Result 0 - Not Connected
MSP
1434
1 - Connected
AF Number: 76
Name: L4CH Test host port availability based on port ID in GPR
Description: Tests the real-time availability of the specified host port.
Arg1: <GPR w/ host port ID>
Arg2: <Not Used>
AF Number: 77
Name: L4CH Load host port ID into GPR
Description: Loads the shared RW host port ID into the GPR.
Arg1: <GPR for host port ID>
Arg2: <Not Used>
AF Number: 78
Name: L4CH Set host port ID from GPR
Description: Sets the shared RW host port ID based on the value of the specified GPR.
Arg1: <GPR with host port ID>
Arg2: <Not Used>
AF Number: 79
Name: L4CH Load host port ID from L5 ref ID into GPR
Description: Takes the host port from the L5 information referenced by L5 ref ID and stores the port ID into the GPR.
Arg1: <GPR w/ L5 ref ID>
Arg2: <GPR for host port ID>
AF Number: 80
Name: Store L5 data in L5 incoming buffer
Description: Transfers any data buffer attached to the L5 message to the L5 incoming buffer. Any data previously in the L5 incoming buffer is lost.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 81
Name: Store L4 data in L4 incoming buffer
Index
1435
Description Transfers any data buffer attached to the L4 message to the L4 incoming buffer. Any data previously in the L4 incoming buffer is lost.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 82
Name: Store L3 data in L3 incoming buffer
Description: Transfers any data buffer attached to the L3 message to the L3 incoming buffer. Any data previously in the L3 incoming buffer is lost.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 83
Name: Transfer data from L5 incoming to L3 outgoing
Description: Transfers data from one buffer to another using the mode specified in Arg1. The move action (0) moves the pointer and clears the source buffer. The copy action (1) makes an actual copy of the buffer and leaves the original in the incoming buffer.
Arg1: <Transfer Mode>
0 = Move
1 = Copy
Arg2: <Not Used>
AF Number: 84
Name: Transfer data from L5 incoming to L4 outgoing
Description: Transfers data from one buffer to another using the mode specified in Arg1. The move action (0) moves the pointer and clears the source buffer. The copy action (1) makes an actual copy of the buffer and leaves the original in the incoming buffer.
Arg1: <Transfer Mode>
0 = Move
1 = Copy
Arg2: <Not Used>
AF Number: 85
Name: Transfer data from L4 incoming to L3 outgoing
Description: Transfers data from one buffer to another using the mode specified in Arg1. The move action (0) moves the pointer and clears the source buffer. The copy
MSP
1436
action (1) makes an actual copy of the buffer and leaves the original in the incoming buffer.
Arg1: <Transfer Mode>
0 = Move
1 = Copy
Arg2: <Not Used>
AF Number: 86
Name: Transfer data from L3 incoming to L4 outgoing
Description: Transfers data from one buffer to another using the mode specified in Arg1. The move action (0) moves the pointer and clears the source buffer. The copy action (1) makes an actual copy of the buffer and leaves the original in the incoming buffer.
Arg1: <Transfer Mode>
0 = Move
1 = Copy
Arg2: <Not Used>
AF Number: 87
Name: Transfer data from L3 incoming to L5 outgoing
Description: Transfers data from one buffer to another using the mode specified in Arg1. The move action (0) moves the pointer and clears the source buffer. The copy action (1) makes an actual copy of the buffer and leaves the original in the incoming buffer.
Arg1: <Transfer Mode>
0 = Move
1 = Copy
Arg2: <Not Used>
AF Number: 88
Name: Clear L3 Outgoing Buffer
Description: De-allocates any L3 outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 89
Name: Clear L4 Outgoing Buffer
Description: De-allocates any L4 outgoing buffer.
Index
1437
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 90
Name: Clear L5 Outgoing Buffer
Description: De-allocates any L5 outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 91
Name: Test for L3 Outgoing Buffer
Description: Tests for the presence of the specified buffer. Return through an IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 92
Name: Test for L4 Outgoing Buffer
Description: Tests for the presence of the specified buffer. Return through an IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 93
Name: Test for L5 Outgoing Buffer
Description: Tests for the presence of the specified buffer. Return through an IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 94
Name: Test for L3 Incoming Buffer
Description: Tests for the presence of the specified buffer. Return through an IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 95
Name: Test for L4 Incoming Buffer
Description: Tests for the presence of the specified buffer. Return through an IS.
MSP
1438
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 96
Name: Test for L4 Incoming Buffer
Description: Tests for the presence of the specified buffer. Return through an IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 97
Name: Clear L3 Incoming Buffer
Description: De-allocates any L3 incoming buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 98
Name: Store TC data in TC incoming buffer
Description: Transfers any data buffer attached to the TC message to the TC incoming buffer. Any data previously in the TC incoming buffer is lost.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 99
Name: Test for TC incoming buffer
Description: Tests for the presence of the specified buffer. Return through an IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 100
Name: Clear TC incoming buffer
Description: Tests for the presence of the specified buffer. Return through an IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 101
Name: Transfer data from TC incoming to L5 outgoing
Index
1439
Description: Transfers data from one buffer to another using the mode specified in Arg1. The move action (0) moves the pointer and clears the source buffer. The copy action (1) makes an actual copy of the buffer and leaves the original in the incoming buffer.
Arg1: <Transfer Mode>
0 = Move
1 = Copy
Arg2: <Not Used>
AF Number: 102
Name: Transfer data from TC incoming to L4 outgoing
Description: Transfers data from one buffer to another using the mode specified in Arg1. The move action (0) moves the pointer and clears the source buffer. The copy action (1) makes an actual copy of the buffer and leaves the original in the incoming buffer.
Arg1: <Transfer Mode>
0 = Move
1 = Copy
Arg2: <Not Used>
AF Number: 103
Name: Transfer data from TC incoming to L3 outgoing
Description: Transfers data from one buffer to another using the mode specified in Arg1. The move action (0) moves the pointer and clears the source buffer. The copy action (1) makes an actual copy of the buffer and leaves the original in the incoming buffer.
Arg1: <Transfer Mode>
0 = Move
1 = Copy
Arg2: <Not Used>
AF Number: 104
Name: Clear L4 Incoming Buffer
Description: De-allocates any L4 incoming buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 105
Name: Clear L5 Incoming Buffer
MSP
1440
Description: De-allocates any L5 incoming buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 107
Name: Store L5 call processing event from L5 incoming buffer into
Description: Stores the call processing event id into the GPR.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 108
Name: L4CH transfer Host TLV from/to buffers
Description: L4CH transfer Host TLV from/to working buffer to/from the other buffer
Arg1: <XYZ>
X - Action
0 : To Working Buffer
1 : From Working Buffer
Y - Buffer Number
0 : Working
1: TC
3: L3
4: L4
5: L5
Z - Outgoing/Incoming
0: Outgoing
1: Incoming (when y = 1 then z can be either 0 or 1)
Note: possible values of arg1: 050, 150, 051, 151, 040, 140, 041, 141, 030, 130, 031, 131, 010 (or 011), 110 (or 111)
Arg2: <Not Used>
AF Number: 109
Name: L4CH Buffer Test
Description: Function to test for A Given Buffer.
Arg1: <Buffer>
0 = Working
Index
1441
1 = TC
3 = L3
4 = L4
5 = L5
Arg2: <Outgoing/Incoming> (Ignored when Arg1 = 0 or 1)
0: Outgoing Buffer
1: Incoming Buffer
Return Value:
PPLevINT_EVENT_0 - Buffer not present
PPLevINT_EVENT_1 - Buffer present
AF Number: 110
Name: L4CH Buffer Move/Copy
Description: L4CH Buffer Move/Copy from /To (L5,L4,L3, TC and Working )
Arg1: <Action>
0: Move
1: Copy
Arg2: <Buffer>
0 = Working
1 = TC
3 = L3
4 = L4
5 = L5
AF Number: 111
Name: L4CH Clear Buffer
Description: L4CH Clear Buffer
Arg1: <Clear>
0 = Clear Working buffer
3 = Clear the L3 outgoing buffer
4 = Clear the L4 outgoing buffer
5 = Clear the L5 outgoing buffer
Arg2: <Not Used>
AF Number: 120
Name: Test B Address in L5 incoming message equal to associated channel
MSP
1442
Description: Tests if the B address in the L5 incoming message is equal to the associated channel maintained by CM. If there is no active association, a FALSE is returned.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 121
Name: Test B Address in L5 incoming message equal to associated channel
Description: Tests if the B address in the L5 incoming message is equal to the associated channel maintained by CM. If there is no active association, a FALSE is returned.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 130
Name: Send L5 DS0 status change using L5 outgoing buffer
Description: Sends the specified message to L5..
Arg1: <Status>
Arg2: <Not Used>
AF Number: 131
Name: Send L5 RFS using outgoing L5 buffer
Description: Sends the specified message to L5.
Arg1: <RFS Retry Flag>
Arg2: <Not Used>
AF Number: 132
Name: Send L5 RFS w/ Data using outgoing L5 buffer
Description: Sends the specified message to L5.
Arg1: <RFS Retry Flag>
Arg2: <Not Used>
AF Number: 133
Name: Send L5 Channel Released using outgoing L5 buffer
Description: Sends the specified message to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1443
AF Number: 134
Name: Send L5 Channel Released w/ Data using outgoing L5 buffer
Description: Sends the specified message to L5.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 135
Name: Send L5 Call Processing Event using outgoing L5 buffer
Description: Sends the specified message to L5.
Arg1: <Event ID>
Arg2: <Not Used>
AF Number: 136
Name: Send L5 Release Request using outgoing L5 buffer
Description: Sends the specified message to L5.
Arg1: <Event ID>
Arg2: <Not Used>
AF Number: 137
Name: Send L5 Call Progress Analysis Result using L5 outgoing buffer
Description: Sends the specified message to L5.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 157
Name: Test RW channel status Interface Type
Description: Tests the current channel interface type. Return in IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 158
Name: Test L3 Incoming buffer for address data flag
Description: Test for address data TLV in incoming L3 buffer. Return in IS.
Arg1: <Not Used>
Arg2: <Not Used>
MSP
1444
AF Number: 159
Name: Store Access Denied data from L3 incoming buffer into
Description: Stores the access denied reason in the GPR from the L3 access denied message.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 161
Name: Test Channel Answer Supervision Mode
Description: Tests the current channel answer supervision mode. Return in IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 162
Name: Test L3 Channel state type in current message
Description: Tests the L3 channel status type for INS/OOS/etc.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 163
Name: Update RW L3 data based on L3 channel status in current message and RO config bytes
Description: Sets up the channel’s private RW properties based on the L3 provided data and the L4CH config bytes.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 164
Name: Test L3 Incoming buffer for call active flag
Description: Tests the L3 incoming message for the call active flag.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 165
Name: Test Channel Flash Timing Mode
Description: Tests the current channel flash timing mode. Return in IS.
Index
1445
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 166
Name: Test L3 Incoming buffer for L3 Clear Request Data
Description: Test for L3 clear request data TLV in incoming L3 buffer. Return in IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 170
Name: Send L3 Outseize Control request using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <GPR # containing Layer 4 Reference ID>
Arg2: <Not Used>
AF Number: 171
Name: Send L3 Call request using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 172
Name: Send L3 Inseize Control request using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <GPR # containing Layer 4 Reference ID>
Arg2: <Not Used>
AF Number: 173
Name: Send L3 Flash request using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 174
Name: Send L3 User Info request using L3 outgoing buffer
Description: Sends the specified L3 message.
MSP
1446
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 175
Name: Send L3 Generate L5 Event request using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 176
Name: Send L3 Transmit Off-hook request using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 177
Name: Send L3 Transmit Idle request using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 180
Name: Send L3 Alerting request using L3 outgoing buffer
Description: Sends the specified L3 message. Arg1 is a flag which determines whether the L3 outgoing buffer should be saved il L4CH after its sent to L3. This is needed to support Connect With Data for ISDN.
Arg1: <Action>
0 = Remove Buffer
1 = Retain Buffer
Arg2: <Not Used>
AF Number: 181
Name: Send L3 Connect request using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1447
AF Number: 182
Name: Send L3 Clear request using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 183
Name: Send L3 Host Connect request using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 184
Name: Send L3 Busy Out ACK using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 185
Name: Send L3 PPL Event using L3 outgoing buffer
Description: Sends the specified L3 message.
Arg1: <Event>
Arg2: <Not Used>
AF Number: 186
Name: Incrementing L4CH Function
Description: L4CH Function which increments the value in the global gp register
Arg1: <GGPR #>
Arg2: <Incr value>
AF Number: 187
Name: Decrementing L4CH Function
Description: L4CH Function which decrements the value in the global gp register
Arg1: <GGPR #>
Arg2: <Decr value>
MSP
1448
AF Number: 188
Name: Comparing L4CH Function
Description: L4CH Function which compares the value in the global general purpose register
Arg1: <GGPR #>
Arg2: <Test value>
Note: Returns True if equal
AF Number: 189
Name: Comparing GGPR L4CH Function
Description: L4CH Function which compares the value in the GGPR with GPR.
Arg1: <GGPR #>
Arg2: <GPR #>
Note: Returns True if equal
AF Number: 190
Name: Copying L4CH Function
Description: L4CH Function which copies the value in the GGPR to GPR.
Arg1: <GGPR #>
Arg2: <GPR #>
AF Number: 191
Name: Copying GPR L4CH Function
Description: L4CH Function which copies the value in the GPR to GGPR.
Arg1: <GGPR #>
Arg2: <Test value>
AF Number: 192
Name: Clearing GGPR L4CH Function
Description: L4CH Function which clears the contents in the GGPR indicated
Arg1: <GGPR #>
Arg2: <Not Used>
AF Number: 193
Name: Clearing GGPR L4CH Function
Index
1449
Description: L4CH Function which clears a number (indicated by arg2)
Arg1: <GGPR #>
Arg2: <Range #>
194 – 200
Reserved for future Global GPR AFs
AF Number: 194-200
Name: Reserved for future Global GPR AFs
Description: Reserved for future Global GPR AFs
Arg1: Not Applicable
Arg2: Not Applicable
Note Reserved for future Global GPR AFs
AF Number: 201
Name: Send Call Service Request to CM using L4 outgoing buffer
Description: Formats and sends a Call Service Request, including the current basic call state, to the local L4CM component .
Arg1: <Local Call State>
Arg2: <Not Used>
AF Number: 202
Name: Send Call Service ACK to CM using L4 outgoing buffer
Description: Responds to an L4CM Call Service Request with a Call Service ACK to CM including the current basic call state.
Arg1: <Local Call State>
Arg2: <Not Used>
AF Number: 203
Name: Send Call Service 1way Forced Request to CM using L4 outgoing buffer
Description: Formats and sends a Call Service Request for a 1-way forced connection to the local L4CM component, including the current basic call state.
Arg1: <Local Call State>
Arg2: <Not Used>
AF Number: 204
Name: Send Call Service Reject to CM with reason using L4 outgoing buffer
MSP
1450
Description: Responds to an L4CM component Call Service Request with a Call Service Reject to CM. The reject reason is derived from the GPR #. If the GPR number is 0 then it is derived directly from Arg2.
Arg1: <GPR #>
Arg2: <Reason>
AF Number: 205
Name: Send Alerting Call Service to CM using L4 outgoing buffer
Description: Sends an indication the a local alerting was received from L3 to CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 206
Name: Send Cut-thru Call Service to CM using L4 outgoing buffer
Description: Sends an indication the a local cut-thru was received from L3 to CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 207
Name: Send Answer Call Service to CM using L4 outgoing buffer
Description: Sends an indication the a local cut-thru was received from L3 to CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 208
Name: Send Clear Call Service to CM using L4 outgoing buffer
Description: Sends an indication that the local call is being released to CM. The DERM override is a flag used by CM to determine whether a clear call or clear connection is sent based on the DERM of the channel.
Arg1: <DERM Flag>
Arg2: <Not Used>
AF Number: 209
Name: Test CM Call State for Active Call
Description: Tests the CM managed shared RW for an active CM.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1451
AF Number: 210
Name: Send Flash Call Service to CM using L4 outgoing buffer
Description: Sends an indication that a flash event was received from L3 to CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 211
Name: Send Clear ACK Call Service to CM using L4 outgoing buffer
Description: Sends an indication that the clear event has been processed.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 212
Name: Test call service reject reason from L4 incoming buffer
Description: Tests the call service reject reason in the received call service reject message from CM. Return in IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 213
Name: Store call service reject reason from L4 incoming buffer in
Description: Stores the call service reject reason the specified GPR.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 214
Name: Send Clear Connection Service to CM using L4 outgoing buffer
Description: Sends an indication that the local channel is requesting a clearing of the association with the remote channel.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 215
Name: Send Clear Connection Service to CM using L4 outgoing buffer
Description: Sends an indication that the local channel is requesting a clearing of the association with the remote channel.
MSP
1452
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 222
Name: Send CM Event using L4 outgoing buffer
Description: Sends a programmable event to CM
Arg1: <Event ID>
Arg2: <Not Used>
AF Number: 223
Name: Send Clear Connection Service to CM using L4 outgoing buffer
Description: Sends an indication that the local channel is requesting a clearing of the association with the remote channel.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 224
Name: Send Update Channel Status Message to CM
Description: Sends Update Channel Status Message to CM.
Arg1: <Channel Status>
1 = Free
2 = Busy
Arg2: <Not Used>
AF Number: 225
Name: L4CH Test MCC Association
Description: Determine if an MCC instance is active for the local channel.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 226
Name: L4CH Query Virtual L4 Type
Description: Determines L4 bearer type (physical TDM or VoIP, virtual TDM or VoIP) by checking localChanLogicalID
Arg1: <Not Used>
Arg2: <Not Used>
Index
1453
AF Number: 227
Name: L4CH Query bearer service status
Description: Determines whether bearer service has been requested for this connection.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 228
Name: L4CH Check Associated PL4
Description: Checks whether valid PL4 is associated with this VL4 or not.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 229
Name: L4CH Send PL4 Request to RTR
Description: Obtains PL4 for use by a VL4 when a physical connection is requested.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 230
Name: L4CH Free Up PL4
Description: Frees up PL4 associated with this VL4
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 231
Name: L4CH Process RTR Response
Description: Extracts coupled PL4 ID from router reply and stores in "coupled" location in VL4’s shared RW area.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 232
Name: L4CH Send Modify Channel Service to L3 using L3 O/G buffer
Description: Sends the local route an indication that the channel is available to terminate route attempts.
MSP
1454
Arg1: <Channel Status>
0= Bearer Service On
1= Bearer Service Off
Arg2: <Not Used>
AF Number: 233
Name: L4CH Check if P-L4 decoupling needed
Description: Checks if a virtual span/channel should be decoupled from a physical span/channel.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 234
Name: L4CH Check if egress L4 is a P-L4.
Description: Checks if the out bound call leg is a physical span/channel or not.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 246
Name: Send Router member available
Description: Sends the local route an indication that the channel is available to terminate route attempts.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 247
Name: Send Router member busy
Description: Sends the local route an indication that the channel is not available to terminate route attempts because it is involved in a call.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 248
Name: Send Router member OOS
Description: Sends the local route an indication that the channel is available to terminate route attempts because it is OOS.
Arg1: <Not Used>
Index
1455
Arg2: <Not Used>
AF Number: 256
Name: L4CH Insert digit string into DSP data list from TC incoming buffer
Description: Copies one entire TC digit string into the DSP data list.
Arg1: <Data List Index>
Arg2: <String #>
AF Number: 257
Name: L4CH Insert digit string into DSP data list from TC incoming buffer
Description: Copies one entire TC digit string into the DSP data list.
Arg1: <Data List Index>
Arg2: <GPR w/ String #>
AF Number: 258
Name: L4CH Insert digit string into DSP data list from TC incoming buffer
Description: Copies one entire TC digit string into the DSP data list.
Arg1: <GPR w/ Data List Index>
Arg2: <String #>
AF Number: 259
Name: L4CH Insert digit string into DSP data list from TC incoming buffer
Description: Copies one entire TC digit string into the DSP data list.
Arg1: <GPR w/ data list index>
Arg2: <GPR w/ String #>
AF Number: 260
Name: Send Collect Digit String (suspend)
Description: Sends the appropriate DSP Service Request.
Arg1: <GPR offset>
Arg2: <Cfg byte offset>
Note: Arg1 indicates the offset of the first GPR in the sequence to be read. This may be used for such data as:
mode
maximum digits
# of term
MSP
1456
config flag
termchars
address signaling type
# of strings to collect
Arg2 specifies the Config Byte offset where more static data is stored. This data may include the following:
inter digit
first digit
completion
minimum receive duration
resume digit collection time
minimum receive inter-digit timer
This function suspends until a positive response is returned.
AF Number: 261
Name: L4CH Send Collect Digit String (no suspend)
Description: Sends the appropriate DSP Service Request.
Arg1: <GPR offset>
Arg2: <Cfg byte offset>
Note: Arg1 indicates the offset of the first GPR in the sequence to be read. This may be used for such data as:
mode
maximum digits
# of term
config flag
termchars
address signaling type
# of strings to collect
Arg2 specifies the Config Byte offset where more static data is stored. This data may include the following:
inter digit
first digit
completion
minimum receive duration
resume digit collection time
Index
1457
minimum receive inter-digit timer
This function suspends until a positive response is returned.
AF Number: 262
Name: Send Collect Digit String Request to SYM using L5 incoming buffer
Description: Sends the appropriate DSP service request to SYM. Arg1 specifies the GPR to find the L5 reference ID of the L5 message. The data in the L5 incoming buffer is used as the DSP service request data. This function does not suspend primitive.
Arg1: <GPR # containing Layer 5 Reference ID>
Arg2: <Not Used>
AF Number: 263
Name: Retrieve L5 Reference ID and response status from message in L4 incoming buffer
Description: Retrieves the appropriate information from the SYM DSP service request response.
Arg1: <GPR # containing Layer 5 Reference ID>
Arg2: <GPR # containing Status>
AF Number: 264
Name Store DSP Service Request Type specified in L5 Incoming Buffer in a GPR
Description: Store the service request type of the L5 DSP Service Request message in a GPR. The GPR# is specified in arg1
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 267
Name: Send Attach DTMF Receiver Request to SYM (suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR which contains the configuration bits.. Arg2 specifies the config byte offset from where the following data is stored digit wait, min. rcv duration timer. This function suspends until a positive response is returned from SYM.
Arg1: <GPR Offset>
Arg2: <Config byte Offset>
AF Number: 268
Name: Send Attach DTMF Receiver Request to SYM (suspend)
MSP
1458
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR which contains the configuration bits.. Arg2 specifies the config byte offset from where the following data is stored digit wait, min. rcv duration timer. This function suspends until a positive response is returned from SYM.
Arg1: <GPR Offset>
Arg2: <Config byte Offset>
AF Number: 269
Name: Send Attach DTMF Receiver Request to SYM using L5 incoming buffer
Description: Sends the appropriate DSP service request to SYM. Arg1 specifies the GPR to find the L5 reference ID of the L5 message. The data in the L5 incoming buffer is used as the DSP service request data. This function does not suspend primitive
Arg1: <GPR containing Layer 5 Reference ID>
Arg2: <Not Used>
AF Number: 270
Name: Send Energy Detection Request to SYM (suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR # from where consecutive GPRs specify the sensitivity level and reporting mode. Arg2 specifies the config byte offset from where the following data is stored: Scan duration timer, completion timer. This function suspends until a positive response is returned from SYM.
Arg1: <GPR Offset>
Arg2: <Config byte Offset>
AF Number: 271
Name: Send Energy Detection Request to SYM (no suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR # from where consecutive GPRs specify the sensitivity level and reporting mode. Arg2 specifies the config byte offset from where the following data is stored: Scan duration timer, completion timer. This function does not suspend primitive
Arg1: <GPR Offset>
Arg2: <Config byte Offset>
AF Number: 272
Name: Send Energy Detection Request to SYM using L5 incoming buffer
Description: Sends the appropriate DSP service request to SYM. Arg1 specifies the GPR to find the L5 reference ID of the L5 message. The data in the L5 incoming buffer is used as the DSP service request data. This function does not suspend primitive
Index
1459
Arg1: <GPR containing Layer 5 Reference ID>
Arg2: <Not Used>
AF Number: 273
Name: Send Attach CPA Receiver Request to SYM (suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR which contains the CPA class. This function suspends until a positive response is returned from SYM
Arg1: <GPR Offset>
Arg2: <Config byte Offset>
AF Number: 274
Name: Send Attach CPA Receiver Request to SYM (no suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR which contains the CPA class. This function does not suspend primitive.
Arg1: <GPR Offset>
Arg2: <Config Byte Offset>
AF Number: 275
Name: L4CH Send Attach CPA receiver request to SYM using L5 incoming buffer
Description: Sends the appropriate DSP service request to SYM. Arg1 specifies the GPR to find the L5 reference ID of the L5 message. The data in the L5 incoming buffer is used as the DSP service request data. This function does not suspend primitive.
Arg1: <GPR containing Layer 5 Reference ID>
Arg2: <Not Used>
AF Number: 280
Name: Store CPC Detection action specified in L5 incoming message in GPR
Description: Store the CPC action of the L5 CPC Detection message (L5 incoming buffer) in a GPR. The GPR# is specified in arg1.
Arg1: <GPR>
Arg2: <Not Used>
AF Number: 281
Name: Send CPC Detect Enable Request to SYM (suspend)
Description: Sends the appropriate DSP service request to SYM. This function suspends until a positive response is returned from SYM
MSP
1460
Arg1: <GPR Offset>
Arg2: <Config Byte Offset>
AF Number: 282
Name: Send CPC Detect Enable Request to SYM (no suspend)
Description: Sends a CPC Detect Enable Request to SYM (no suspend)
Arg1: <GPR Offset>
Arg2: <Config Byte Offset>
AF Number: 283
Name: Send CPC Detect Enable Request to SYM using L5 incoming buffer
Description: Sends the appropriate DSP service request to SYM. This function does not suspend primitive
Arg1: <GPR containing Layer 5 Reference ID>
Arg2: <Not Used>
AF Number: 284
Name: Send Cancel Digit Receiver to SYM
Description: Sends a request to cancel any active DSP services of the specified type.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 285
Name: Send Cancel Energy Receiver to SYM
Description: Sends a request to cancel any active DSP services of the specified type.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 286
Name: Send Cancel CPA Receiver to SYM
Description: Sends a request to cancel any active DSP services of the specified type.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1461
AF Number: 287
Name: Store Cancel DSP Service type specified in L5 incoming buffer in GPR
Description: Store the service cancel type of the L5 DSP Service Cancel message in a GPR. The GPR# is specified in arg1.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 290
Name: Send Connect Tone Pattern Request to SYM (suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR # from where consecutive GPRs specify the pattern Id, # cycles to transmit, and event flags. This function suspends until a positive response is returned from SYM
Arg1: <GPR Offset (Pattern ID, # of Cycles, Event Flag)>
Arg2: <Not Used>
AF Number: 291
Name: Send Connect Tone Pattern Request to SYM (no suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR # from where consecutive GPRs specify the pattern Id, # cycles to transmit, and event flags. This function does not suspend primitive.
Arg1: <GPR Offset (Pattern ID, # of Cycles, Event Flag)>
Arg2: <Not Used>
AF Number: 292
Name: Send Connect Tone Pattern Request to SYM using L5 incoming buffer
Description: Sends the appropriate DSP service request to SYM. Arg1 specifies the GPR to find the L5 reference ID of the L5 message. The data in the L5 incoming buffer is used as the DSP service request data. This function does not suspend primitive.
Arg1: <GPR containing Layer 5 Reference ID>
Arg2: <Not Used>
AF Number: 293
Name: Send Cancel Tone/RAN xmtr request to SYM
Description: Sends a request to cancel any active DSP services of the specified type.
Arg1: <Not Used>
Arg2: <Not Used>
MSP
1462
AF Number: 294
Name: Send Connect RAN Request to SYM using L5 incoming buffer (suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 specifies the GPR to find the L5 reference ID of the L5 message. The data in the L5 incoming buffer is used as the DSP service request data. This function suspends until a positive response is returned from SYM.
Arg1: <GPR containing Layer 5 Reference ID>
Arg2: <Not Used>
AF Number: 295
Name: Send Connect RAN Request to SYM using L5 incoming buffer (no suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 specifies the GPR to find the L5 reference ID of the L5 message. The data in the L5 incoming buffer is used as the DSP service request data. This function does not suspend primitive.
Arg1: <GPR containing Layer 5 Reference ID>
Arg2: <Not Used>
AF Number: 296
Name: Send Outpulse Digits Request to SYM (suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR # from where consecutive GPRs specify the signal type, string count, string format, string mode, and events flag. Arg2 specifies the config byte offset from where the following data is stored: First digit duration, digit duration, interdigit duration, and delay duration (4 UWords). The DSP Data List is used to maintain digits and digit counts. This function suspends until a positive response is returned from SYM
Arg1: <GPR Offset>
Arg2: <Config Byte Offset>
AF Number: 297
Name: Send Outpulse Digits Request to SYM (no suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR # from where consecutive GPRs specify the signal type, string count, string format, string mode, and events flag. Arg2 specifies the config byte offset from where the following data is stored: First digit duration, digit duration, interdigit duration, and delay duration (4 UWORDs). The DSP Data List is used to maintain digits and digit counts. This function does not suspend primitive
Arg1: <GPR Offset>
Arg2: <Config Byte Offset>
Index
1463
AF Number: 298
Name: Send Outpulse Digits Request to SYM using L5 incoming buffer
Description: Sends the appropriate DSP service request to SYM. Arg1 specifies the GPR to find the L5 reference ID of the L5 message. The data in the L5 incoming buffer is used as the DSP service request data. This function does not suspend primitive.
Arg1: <GPR containing Layer 5 Reference ID>
Arg2: <Not Used>
AF Number: 300
Name: L4CH Send Cancel 2833 Digit Rcvr to CATC
Description: Cancels a 2833 tone receiver service
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 301
Name: L4CH Check for CATC DSP Req
Description: Checks incoming L5 message to see if it contains a CATC 2833 request
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 302
Name: L4CH Send Attach 2833 DTMF Revr Request to CATC using L5 Incoming Buffer
Description: Sends an attach DTMF receiver request to CATC using data in L5 incoming buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 310
Name: Test Tone Xmit Generate L5 Event Flag
Description: Tests if the currently active DSP tone generator should have a L5 event generated upon a TC outpulsing complete event. Result through IS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 311
MSP
1464
Name: Translate TC Incoming buffer into L5 Outgoing buffer and send L5 Call Processing event
Description: Formats the correct call processing event message to L5 for the incoming TC event.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 312
Name: Store digit from First Digit event specified in TC incoming buffer in GPR
Description: Stores the digit from a TC first digit event in the specified buffer into a GPR. The GPR# is specified in arg1.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 313
Name: Store RAN ID from TC incoming buffer into
Description: Stores the RAN ID from a TC RAN starting or RAN complete event into the specified GPR.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 314
Name: Store digit info. type for timing specified in TC incoming buffer in GPR
Description: Stores the digit info type from a TC digits, inpulse complete timeout, or inter-digit timeout event into a GPR. The GPR # is specified in arg1.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 315
Name: Store digit info. type for timing specified in TC incoming buffer in GPR
Description: Stores the digit info type from a TC digits, inpulse complete timeout, or inter-digit timeout event into a GPR. The GPR # is specified in arg1.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 316
Name: Store digit string digit count from TC incoming buffer
Index
1465
Description: Stores the string’s digit count from a TC digits event in the specified GPR. The string number is specified in the second GPR argument. Unknown string # causes a channel purge.
Arg1: <GPR to store digit count>
Arg2: <GPR # containing string number>
AF Number: 317
Name: Store digit string digit from TC Incoming Buffer in GPR
Description: Stores a digit from a TC digits event in the specified buffer into a GPR. Arg1 holds the GPR # from where consecutive GPRs specify the string# and digit#. Arg2 specifies the GPR to store the digit. Unknown string # or digit # causes a channel purge.
Arg1: <GPR Offset>
Arg2: <GPR to store digits>
AF Number: 318
Name: Test digit string digit from TC incoming buffer
Description: Tests a digit from a TC digits event in the specified buffer into a GPR. Arg1 holds the GPR with the string#. Arg2 specifies the GPR with the digit #. Unknown string # or digit # causes a channel purge
Arg1: <GPR containing String #>
Arg2: <GPR containing digit #>
AF Number: 319
Name: Store digit from digit with timing info specified in TC Incoming Buffer in GPR <
Description: Stores the digit from a TC digits event with timing info in a GPR. The GPR# is specified in arg1.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 320
Name: Store digit interval from TC Incoming Buffer digit with timing info
Description: Stores the digit interval from a TC digits event with timing info. in the specified GPR.
Arg1: <GPR Containing Timing Information>
Arg2: <Not Used>
AF Number: 321
MSP
1466
Name: Store Call Progress Result from TC incoming buffer in GPR
Description: Stores the call progress result type in the TC incoming buffer in a GPR. The GPR # is specified in Arg1.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 322
Name: Store energy detect flag from TC incoming buffer in GPR
Description: Stores the energy flag from a TC energy detected event into a GPR. The GPR # is specified in arg1.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 323
Name: Store energy detection duration in TC incoming buffer into
Description: Stores the energy detect duration data from a TC energy detected event into the specified GPR.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 324
Name: Compare digits in digit string in TC incoming buffer
Description: Compares the digits from a TC digits event in the TC incoming buffer with a digit string in the config bytes. Arg1 holds the GPR # from where consecutive GPRs specify the string #, digit offset, and # of digits. Arg2 specifies the config byte offset for the stored digits.
Arg1: <GPR Offset>
Arg2: <Config byte Offset>
AF Number: 325
Name: Compare digits in digit string in TC incoming buffer to GPR stored digits
Description: Compares the digits from a TC digits event in the TC incoming buffer with a digit string stored in GPR(s). Arg1 holds the GPR # from where consecutive GPRs specify the string #, digit offset and # digits. Arg2 specifies the GPR # for the stored digits.
Arg1: <GPR offset (string #, digit offset, #digits)>
Arg2: <GPR # for start of stored digit string>
AF Number: 326
Index
1467
Name: Compare BCD digits in digit string in L3 incoming buffer
Description: Compares the digits from a TC digits event in the TC incoming buffer with a digit string in the config bytes. Arg1 holds the GPR # from where consecutive GPRs specify the stage #, string #, digit offset, and # of digits. Arg2 specifies the config byte offset for the stored digits.
Arg1: <GPR Offset>
Arg2: <Config byte Offset>
AF Number: 327
Name: Compare BCD digits in digit string in L3 incoming buffer to GPR stored digits
Description: Compares the digits from a TC digits event in the TC incoming buffer with a digit string stored in GPR(s). Arg1 holds the GPR # from where consecutive GPRs specify the stage #, string # , digit offset and # digits. Arg2 specifies the GPR # for the stored digits.
Arg1: <GPR offset (stage #, string #, digit offset, #digits)>
Arg2: <GPR # for start of stored digit string>
AF Number: 330
Name: Send Connect RAN Request to SYM using single RAN ID in GPR (suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR # from where the GPRs will specify the configuration options: Config flag and Event flag. Arg2 holds the GPR # which specifies the RAN ID. This is a suspend primitive function.
Arg1: <GPR offset (config flag, event flag)>
Arg2: <GPR # containing RAN ID>
AF Number: 331
Name: Send Connect RAN Request to SYM using single RAN ID in GPR (no suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 holds the GPR # from where the GPRs will specify the configuration options: Config flag and Event flag. Arg2 holds the GPR # which specifies the RAN ID. This is not a suspend primitive function.
Arg1: <GPR offset (config flag, event flag)>
Arg2: <GPR # containing RAN ID>
AF Number: 332
Name: Send Connect Tone Pattern Request to SYM without L5 data (will NOT send CPE)
Description: Sends the appropriate DSP service request to SYM. The host will not be informed (via Call Processing Event) when done. Arg1 will specify the Pattern ID.
MSP
1468
Arg2 will specify the number of cycles to transmit the tone pattern. This is a suspend primitive function.
Arg1: Arg1:<Pattern ID>
Arg2: Arg2:<# cycles to transmit>
AF Number: 333
Name: Send Connect Tone Pattern Request to SYM without L5 data (will send CPE)
Description: Sends the appropriate DSP service request to SYM. A Call Processing Event will be sent to the host when done. Arg1 will specify the Pattern ID. Arg2 will specify the number of cycles to transmit the tone pattern. This is a suspend primitive function.
Arg1: <Pattern ID>
Arg2: <# cycles to transmit>
AF Number: 340
Name: Create DSP Data List buffer
Description: Creates a buffer for DSP Data (chaining RAN IDs or digits). Initializes to all FFs. If buffer already exists, it is re-initialized. A maximum of 64 Ran Ids can be chained.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 341
Name: Remove DSP Data List buffer
Description: Cleans up the DSP Data List.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 342
Name: Load list size from DSP Data List into GPR
Description: Loads the current count of dsp data items in the DSP Data List into the specified GPR.
Arg1: <GPR #t>
Arg2: <Not Used>
AF Number: 343
Name: Insert item into DSP Data List
Index
1469
Description: Inserts the item given in arg2 into the DSP Data List at the index location specified in GPR. If index is -1, the item is appended to the end of the list
Arg1: <Index > <item>
Arg2: <Not Used>
AF Number: 344
Name: Insert item in DSP Data List
Description: Inserts the item given in arg2 into the DSP Data List at the index location specified in GPR. If index is -1, the item is appended to the end of the list
Arg1: <GPR # containing index #>
Arg2: <Item>
AF Number: 345
Name: Insert item in DSP Data List
Description: Inserts the item (given in GPR) into the DSP Data List at the index location specified in arg1. If index is -1, the item is appended to the end of the list
Arg1: < Index>
Arg2: <GPR # Containing Item>
AF Number: 346
Name: Insert item in DSP Data List
Description: Inserts the item (given in GPR) into the DSP Data List at the index location specified in GPR. If index is -1, the item is appended to the end of the list.
Arg1: <GPR # Containing Index>
Arg2: <GPR # Containing Item>
AF Number: 347
Name: Set item in DSP Data List
Description: Assigns the item given in arg2 to the DSP Data List at the index location. If index is -1, the item is appended to the end of the list.
Arg1: <Index>
Arg2: <Item>
AF Number: 348
Name: Set item in DSP Data List
Description: Assigns the item given in arg2 to the DSP Data List at the index location (given in GPR). If index is -1, the item is appended to the end of the list.
Arg1: <GPR # Containing Index>
MSP
1470
Arg2: <Item>
AF Number: 349
Name: Set item in DSP Data List
Description: Assigns the item given in GPR to the DSP Data List at the index location given in arg1. If index is -1, the item is appended to the end of the list.
Arg1: <Index>
Arg2: <GPR # Containing Item>
AF Number: 350
Name: Set item in DSP Data List
Description: Assigns the item given in GPR to the DSP Data List at the index location given in arg1. If index is -1, the item is appended to the end of the list.
Arg1: <GPR # Containing Index>
Arg2: <GPR # Containing Item>
AF Number: 351
Name: Remove item from DSP Data List
Description: Removes the item at the location indicated by Arg1 from the DSP Data List.
Arg1: <Index>
Arg2: <Not Used>
AF Number: 352
Name: Remove item from DSP Data List
Description: Removes the at the location indicated by Arg1from the DSP Data List.
Arg1: <GPR # Containing Index>
Arg2: <Not Used>
AF Number: 353
Name: Send Connect RAN Request to SYM using DSP Data List (suspend)
Description: Sends the appropriate DSP Service Request message to SYM. Arg1 will specify the Configuration flag option. Arg2 specifies the Event flag option. This is a suspend primitive function.
Arg1: <Config Flag>
Arg2: <Event Flag>
Index
1471
AF Number: 354
Name: Send Connect RAN Request to SYM using DSP Data List (no suspend)
Description: Sends the appropriate DSP service request to SYM. Arg1 will specify the Configuration flag option. Arg2 specifies the Event flag option. This is NOT a suspend primitive function.
Arg1: <Config Flag>
Arg2: <Event Flag>
AF Number: 355
Name: L4CH Delete and shift DSP data list entries
Description: Re-arranges the DSP data list by removing the entries starting at INDEX for COUNT.
Arg1: <GPR w/ index>
Arg2: <GPR w/ count>
AF Number: 356
Name: Store start time stamp, get current time stamp, get duration, report start time stamp
Description: Re-arranges the DSP data list by removing the entries starting at INDEX for COUNT.
Arg1: <Action>
0: report current time stamp
1: store the start time stamp
2: report the stored start time stamp
3: report the duration
Arg2: <Granularity in 100 milliseconds units>
AF Number: 357
Name: Get TLV into GPR from Working buffer
Description: This function takes two arguments and gets the desired TLV (corresponding to Host Tag) from working buffer and puts into GPR
Arg1: <GPR Index>
Arg2: <Host tag>
AF Number: 358
Name: Set TLV from GPR
Description: This function takes two arguments and makes an TLV and adds that to the working buffer.
MSP
1472
Arg1: <GPR Index>
Arg2: <Host tag>
AF Number: 359
Name: DSP Data List TLV
Description: Makes DSP Data List TLV and puts into working buffer
Arg1: <GPR Index w/ DSP Data List Index (start point IN the array)>
Arg2: <GPR Index w/ Count (number of entries wanted to read from the array>
AF Number: 360
Name: Get CFG TLV Tag in GPR
Description: Retrieves the Config Byte at which the TLV pointer in the Private RW area is pointing to and loads the value in the GPR passed as an argument to the function call
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 361
Name: Init CFG TLV Pointer to CFG Byte
Description: Initiates the TLV pointer in the Private RW area to point to the Config Byte passed as the argument.
Arg1: <Config Byte #>
Arg2: <Not Used>
AF Number: 362
Name: Set CFG TLV Pointer to next TLV
Description: Increments the TLV pointer in the Private RW area to point to the next TLV in the Config Bytes.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 363
Name: Load TLV Data in Data Block
Description: Get TLV data for the TLV pointer in Private RW area and loads it into the TLV Data Block in the Private RW area.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1473
AF Number: 364
Name: Add Routing Method TLV to CSR For Router
Description: Adds the Routing Method TLV to Call Service Request that goes to the CM
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 365
Name: Add Routing search Key TLV to CSR For Router
Description: Adds the Routing Search Key TLV to Call Service Request that goes to the CM
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 366
Name: Add Address Digits TLV to CSR For Router
Description: Adds the Address Digit TLV to Call Service Request that goes to the CM , argument can have 1,2 or 3. 1 for CPA Digits, 2 for ANI digits, 3 for Category
Arg1: <Digit Type #>
Arg2: <Not Used>
AF Number: 367
Name: Add Resource Group ID TLV to CSR For Router
Description: Adds the Resource Group ID TLV to Call Service Request that goes to CM.
Arg1: <Digit Type #>
Arg2: <Not Used>
AF Number: 368
Name: Load Address Digits [from TLV Data Block] in Digits Array
Description: Loads the Address Digits [from TLV Data Block] in to the Digits Array for further operations
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 369
MSP
1474
Name: Add Span/Channel TLV to CSR For Router
Description: Adds the Logical Span/Channel TLV to Call Service Request that goes to CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 370
Name: Load TLV Data From TLV Data Block to GPR
Description: Loads the TLV Data From TLV Data Block in to a Gen. Purpose Register specified by the argument
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 371
Name: Send Call Service Request to CM using L4 outgoing buffer with Protocol ID from Config Byte
Description: Sends the Call Service Request to CM using L4 outgoing buffer with Protocol ID derived from Config Byte #.
Arg1: <Config Byte #>
Arg2: <Local Call State>
AF Number: 372
Name: Add Incoming Span/Channel TLV to CSR For Router
Description: Adds the Incoming Span/Channel TLV to Call Service Request that goes to CM
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 374
Name: L4CH Transfer Data from DSP Data List to Digit Array
Description: This atomic function transfers digits from DSP Data List to the Digits array.
Arg1: <GPR # {GPR has Byte Count in it}>
Arg2: <GPR # {Offset within the DSP Data List}>
Note Arg1 is a GPR which has a count of digits to be copied. The count should be less than or equal to the number of digits in the DSP Data List.
Arg2 is the offset within the Dsp Data List to start the copy.
Index
1475
AF Number: 376
Name: L4CH Load channel information into working buffer
Description: Loads L4CH channel information into working buffer
Arg1: <Channel Info>
0: Local
1: Connected
Arg2: <Not Used>
AF Number: 377
Name: L4CH Add TLV from Digit Array to CSR For Router
Description: Adds Digit Type TLV to CSR for the TAG in GPR
Arg1: <GPR # {GPR has Tag Type in it}>
Arg2: <Not Used>
AF Number: 378
Name: L4CH Add Span/Channel TLV to CSR For Router with Offset
Description: This AF adds a Span/Channel Offset from its own channel num.
Arg1: <GGPR # {Span Offset}>
Arg2: <GGPR # {Channel Offset}>
Note Arg1 is the GGPR carrying Span Offset. If the GGPR has 0 in the offset value is taken from the cfg Byte TLV Data.
Arg2 is the GGPR carrying Channel offset. If the GGPR has 0 in the offset value is taken from the cfg Byte TLV Data.
AF Number: 379
Name: L4CH Add Call Profile stamp
Description: This AF where ever inserted adds the call profiling Data for that channel if Call profiling for that channel is enabled.
Arg1: <Check Point Number #>
Arg2: <Not Used>
Note: Arg1 has the check point number that the call profile has to be tagged with.
AF Number: 381
Name: L4CH Check CSRin incoming_l4 Buff, whether to send Call Req or Outseize Control
Description: Outgoing CH looks for the TLV inserted by incoming CH by calling atomic function 382.
MSP
1476
Arg1: <Not Used>
Arg2: <Not Used>
Note: Return 0x01 if Outseize Control
AF Number: 382
Name: L4CH Add TLV for the call Type in CSR in L4 Outgoing Buffer
Description: The incoming CH instance adds this TLV for the Outgoing CH to decide whether to send L3_call_req or L3_ouseize_control.
Arg1: <GP Register #>
Arg2: <Not Used>
AF Number: 383
Name: L4CH Add Standard OUTSEIZE ICB TLV in L4 incoming buffer
Description: L4CH adds standard OUTSEIZE ICB TLV in L4 incoming buffer
Arg1: <Option Type #>
Arg2: <Not Used>
Note: Adds a standard formatted ICB
1: Seize
2: Use Instruction List
AF Number: 385
Name: L4CH Send Route Control Msg Reject to RTR using L4 outgoing buffer
Description: Sends NACK for the message.
Arg1: <GPR #>
Arg2: <Not Used>
AF Number: 386
Name: L4CH Send Route Control Msg Ack to RTR using L4 outgoing buffer
Description: Sends an ACK for the message
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 387
Name: L4CH Store RTR Handle from Incoming L4 Buffer
Description: Stores the Router Handle in Private R/W for future communication with the router.
Index
1477
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 388
Name: L4CH Check CSR in l4 incoming, whether the CSR has Outseize ICBs
Description: Checks for Outseize Control ICB in the message.
Arg1: <Not Used>
Arg2: <Not Used>
Note: {Returns 0-Yes; 1-No}
AF Number: 389
Name: Invoke Timer
Description: Initiates the timer type specified in Arg 1 for the duration specified in the GPR indicated in Arg 2.
Arg1: <Timer Type>
Arg2: <GPR Index>
MSP
1478
Layer 4 Call Management (0x0062)
Atomic Functions
The following Atomic Functions (AF) are specific to the Layer 4 Call Management (0x0062) PPL component.
AF Number: 51
Name: Purge Call
Description: Initiates a purge of the local CH and the remote channel with reason in arg1.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 52
Name: Test Local Channel State of Msg in CH Incoming Buffer
Description: Tests the local CH channel state in either a CH Call Service Request or Call Service Ack. Return value through internal state.
Arg1: <Reason>
Arg2: <Not Used>
AF Number: 53
Name: Test Channel Answer Supervision Mode
Description: Tests the shared RW answer supervision mode. Return value through internal state.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 54
Name: Block Invalid Events in next Normal State
Description: Function to tell the state machine pre-processor to block any events which would be invalid events for the next normal state. The blocking is cleared after the state is exited.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 55
Name: Test Local End Release Mode
Index
1479
Description: Tests the shared RW local end release mode. Return value through internal state.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 56
Name: Test Distant End Release Mode
Description: Tests the shared RW distant end release mode. Return value through internal state.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 57
Name: Reset CM remote channel database
Description: Function to reset the RW area when a call is being torn down.
Arg1: <Not Used>
Arg2: <Not Used>
Note: The following RW variables are reset: Remote Chan ID, Remote PCM Format and Remote DB Padding.
AF Number: 58
Name: Store Local Channel State in L4 CH Incoming Buffer into GPR
Description: Extracts the L4 CH call state from the incoming message and stores it into the specified GPR.
Arg1: <GPR>
Arg2: <Not Used>
AF Number: 59
Name: Stop all CM Timers
Description: Stops any active CM Timers
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 60
Name: Test Flash Timing Mode
Description: Tests the shared RW flash timing mode. Return value through internal state.
MSP
1480
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 61
Name: Test DERM Override in CH Incoming Buffer
Description: Tests the value of the CH provided DERM override flag in the message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 62
Name: ACK PPL Event Request
Description: Used to ack the host PPL Event Request
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 63
Name: Send L5 PPL Event Indication <event ID> using outgoing L5 buffer
Description: Sends a PPL Event Indication to L5
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 70
Name: Send Connect Request to CM using CM outgoing buffer
Description: Function to send a connect request to the remote CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 71
Name: Send Call Service Request to CM using CM outgoing buffer
Description: Function to send a call service request to the remote CM. All relevant channel information is loaded into the outgoing message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 72
Name: Send Call Service Ack Request to CM using CM outgoing buffer
Index
1481
Description: Function to send a call service ack to the remote CM. All relevant channel information is loaded into the outgoing message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 73
Name: Send Call Service Reject Request to CM using CM outgoing buffer
Description: Function to send a call service reject to the remote CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 74
Name: Send Alerting Call Service Request to CM using CM outgoing buffer
Description: Function to send an alerting request to the remote CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 75
Name: Send Cut-Thru Call Service Request to CM using CM outgoing buffer
Description: Function to send a cut-thru request to the remote CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 76
Name: Send Answer Call Service Request to CM using CM outgoing buffer
Description: Function to send an answer request to the remote CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 77
Name: Send Clear Connection Service Request to CM using CM outgoing buffer
Description: Function to send a clear connection request to the remote CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 78
MSP
1482
Name: Send Clear Call Service Request to CM using CM outgoing buffer
Description: Function to send a clear call request to the remote CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 79
Name: Send CSR Reject to source of current msg
Description: Function to immediately send a call service reject to the remote CM with the specified reject reason.
Arg1: <Reject Reason>
Arg2: <Not Used>
AF Number: 80
Name: Send Channel Information Request to CM using outgoing CM buffer
Description: Function to send a channel information request to the remote CM. All relevant channel information is loaded into the outgoing message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 81
Name: Send Channel Information Ack using current CM message
Description: Function to immediately send a call information ack to the remote channel that requested the information.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 82
Name: Send Flash Service Request to CM using CM outgoing buffer
Description: Function to send a flash request to the remote CM.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 100
Name: Send Call Service Reject Indication to CH using CH outgoing buffer
Description: Function to send a call service reject indication to the local CH in response to a call service request made by the CH.
Arg1: <Not Used>
Index
1483
Arg2: <Not Used>
AF Number: 101
Name: Send Call Service ACK Indication to CH using CH outgoing buffer
Description: Function to send a call service ack indication to the local CH in response to a call service request made by the CH.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 102
Name: Send Alerting Call Service Indication to CH using CH outgoing buffer
Description: Function to send an alerting request indication to the local CH.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 103
Name: Send Cut-Thru Call Service Indication to CH using CH outgoing buffer
Description: Function to send a cut-thru request indication to the local CH.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 104
Name: Send Answer Call Service Indication to CH using CH outgoing buffer
Description: Function to send an answer request indication to the local CH.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 105
Name: Send Call Service Request Indication to CH using CH outgoing buffer
Description: Function to send a call service request indication to the local CH.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 106
Name: Send Clear Call Service Indication to CH using CH outgoing buffer
Description: Function to send a clear call request indication to the local CH.
MSP
1484
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 107
Name: Send Clear Connection Service Indication to CH using CH outgoing buffer
Description: Function to send a clear connection request indication to the local CH.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 108
Name: Send Flash Service Indication to CH using CH outgoing buffer
Description: Function to send a flash request indication to the local CH.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 109
Name: Send Clear Ack to CH using CH outgoing buffer
Description: Function to send a clear ack event to the local CH.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 110
Name: Send L4RTR Route Call Service Request
Description: Send L4RTR Route Call Service Request using RTR Outgoing Buffer
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 120
Name: Store Remote Chan ID from Call Service Req in CH Incoming Buffer
Description: Function to store only the remote channel ID into the local RW area from an incoming call service request or ack for acknowledgment or reject return purposes only.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 121
Index
1485
Name: Store Remote Chan Data from CM Call Service Req/Ack in CM Incoming Buffer
Description: Function to store all relevant channel information (i.e. Remote Chan ID, Remote PCM Format, Remote DB Padding) into the local RW area from an incoming call service request or ack.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 140
Name: Store CH data in CH incoming buffer
Description: Transfers any data buffer attached to the CH message to the CH incoming buffer. Any data previously in the CH incoming buffer is lost.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 141
Name: Store CM data in CM incoming buffer
Description: Transfers any data buffer attached to the CM message to the CM incoming buffer. Any data previously in the CM incoming buffer is lost.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 142
Name: Transfer data from CH incoming to CM outgoing
Description: Transfers data from one buffer to another in the specified mode. The buffer pointer is simply moved and the source pointer is cleared.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 143
Name: Transfer data from CM incoming to CH outgoing
Description: Transfers data from one buffer to another in the specified mode. The buffer pointer is simply moved and the source pointer is cleared.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 144
Name: Clear CH outgoing buffer
MSP
1486
Description: De-allocates any CH outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 145
Name: Clear CM outgoing buffer
Description: De-allocates any CH outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 146
Name: Test for CH outgoing buffer
Description: Deallocates any CH incoming buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 147
Name: Test for CM outgoing buffer
Description: Deallocates any CM incoming buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 160
Name: Send Local Call Connect VP Request to PC
Description: Informs PC that the local CM is ready for a voice path connection
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 161
Name: Send Remote Call Connect VP Request to PC
Description: Informs PC that the remote CM is ready for a voice path connection
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 162
Name: Send Disconnect VP Request to PC
Index
1487
Description: Instructs PC to disconnect the voice path
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 163
Name: Send Local Forced Connect VP Request to PC
Description: Instructs PC to immediately setup the voice path connection.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 170
Name: Set/Update Routing Status for Channel
Description: Updates the routing Database to the status { 1= FREE, 2=BUSY }
Arg1: <Not Used>
Arg2: <Not Used>
Note: <Status 1=FREE, 2=BUSY>
AF Number: 171
Name: Send Call Service Reject Indication to RTR using RTR Outgoing
Description: Sends a Reject message to the Remote RTR in response to a Call service request.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 172
Name: Store Remote Chan Data from RTR Call Service Req/Ack in RTR Incoming Buffer
Description: Stores the Remote Chan Data from RTR Call Service Req/Ack in RTR Incoming Buffer in the private RW area
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 173
Name: Transfer CH Incoming into RTR Outgoing
Description: Transfer’s the message from CH incoming buffer to RTR outgoing buffer
Arg1: <Not Used>
MSP
1488
Arg2: <Not Used>
AF Number: 174
Name: Store RTR Data Into RTR Incoming/RTR Addr. Block
Description: Stores the RTR Data Into RTR Incoming/RTR Addr. Block in the private RW area
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 175
Name: Transfer Data from RTR Incoming to CH Outgoing
Description: Transfer’s the message from RTR incoming buffer to CH outgoing buffer
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 176
Name: Send Call Service Request Ack to RTR using RTR outgoing buffer
Description:
Arg1: <Not Used>
Arg2: <Not Used>
Index
1489
Layer 4 Physical Connection (0x0063)
Atomic Functions
The following Atomic Functions (AF) are specific to the Layer 4 Physical Connection (0x0063) PPL component.
AF Number: 51
Name: PCM Connect local channel to remote channel
Description: Establishes a 1-way PCM connection with the remote channel as the source.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 52
Name: Disconnect local channel
Description: Disconnects the local channel form all other channels.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 53
Name: PCM Forced connect local channel to remote channel
Description: Sends a forced connection message to the local switch manager.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 54
Name: ACK PPL Event Request
Description: Sends an acknowledgment to a host PPL Event Request message with the status indicated in Arg1.
Arg1: <Status>
Arg2: <Not Used>
AF Number: 55
Name: Send L4 PPL Event Indication
Description: Sends a PPL Event Indication message to the host with the event indicated by Arg1.
Arg1: <Event ID>
MSP
1490
Arg2: <Not Used>
Index
1491
Call Control Router (0x0064)
Atomic Functions
The following AFs are specific to the MSP 1010 Call Control Router (0x0064) PPL component.
AF Number: 101
Name: Store incoming data in incoming buffer <0:initiate,1:terminate>
Description: Stores the incoming data in the buffer passed as the argument.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 102
Name: Get Routing method type from incoming initiate buffer and load in Gen. Purpose Register
Description: This function extracts the Route Group ID from the incoming message.
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 103
Name: Load Route Group ID type search key from incoming initiate buffer in Gen. Purpose Register
Description: This function extracts the Route Group ID from the incoming message.
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 104
Name: Set Resource Group Member pointer to the Address Element indexed by Gen. Purpose Register
Description: Points the Resource Group Member pointer to the Address Element index given in the GP Register.
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 106
Name: Load Entry Data tag in Gen. Purpose Register
Description: Loads the Entry Data Tag from the TLV that Entry Data TLV Pointer currently points to.
MSP
1492
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 107
Name: Test for end of route Table
Description: Tests for end of the route table for a given row num passed as an argument to the atomic function ( Null pointer means end of the route table… It means that the route table has to be continuous with non null rows ).
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 108
Name: Load Resource Group Member count in Gen. Purpose Register
Description: Loads the count of the total members in a Resource Group, in the specified Gen. Purpose Register.
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 109
Name: Test address type <0:initiate,1:terminate>
Description: Tests the address type for the initiate and terminate addresses
Arg1: 0-initiate address;
1-terminate address
Return Value:
PPLevINT_EVENT_0 - Invalid or unrecognized address
PPLevINT_EVENT_1 - Timeslot address (CM)
PPLevINT_EVENT_2 - Router address (RTR)
Arg2: <Not Used>
AF Number: 111
Name: Clear Buffer <0:incoming initiate,1:outgoing initiate,2:incoming terminate,3:outgoing terminate>
Description: Function to clear a specified working buffer
Arg1: 0-incoming init.
1-outgoing init.
2-incoming term
3-outgoing term
Index
1493
Arg2: <Not Used>
AF Number: 114
Name: Check Available status of timeslot in terminate address
Description Checks the status of the local timeslot; returns PPLevINT_EVENT_1 if free or PPLevINT_EVENT_0 if Busy.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 115
Name: Send Call Service Request to terminate address using outgoing terminate buffer
Description: Sends Call Service Request to terminate address using outgoing terminate buffer
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 116
Name: Send Call Service Reject to initiate address using outgoing initiate buffer
Description: Sends Call Service Reject to initiate address using outgoing initiate buffer
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 117
Name: Set Route table to point to the row number in Gen. Purpose Register
Description: Directs Route Table Pointer to the row number specified in the GP register.
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 120
Name: Set Entry Data TLV pointer to TLV indexed by Gen. Purpose Register
Description: Points the TLV pointer to the TLV index given in the GP Register.
Arg1: <Register #>
Arg2: <Not Used>
MSP
1494
AF Number: 121
Name: Load TLV count in Gen. Purpose Register
Description: Loads TLV count of the Entry Data Field of the Route Table in Gen. Purpose Register
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 122
Name: Initialize the Resource Group pointer to Resource Group ID in Gen. Purpose Register
Description: Initializes the Resource Group pointer to Resource Group ID specified in the Gen. Purpose Register
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 123
Name: Load Entry Data Field TLV Value in Gen. Purpose Register
Description: Loads the Entry Data Field TLV Data in Gen. Purpose Register
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 124
Name: Translate Address Element Block into terminate address and validate
Description: Validate Span/Channel address in Address Element Block and store result in Timeslot Info Block.
Return Value:
ERROR CASES:
PPLevINT_EVENT_0 - No Address in Block or invalid address
PPLevINT_EVENT_1 - Remote Node Busy
SUCCESS CASES:
PPLevINT_EVENT_10 - valid local span/channel
PPLevINT_EVENT_11 - valid remote span/channel
PPLevINT_EVENT_12 - valid remote node ID
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 125
Index
1495
Name: Initialize Route Table pointer to the table ID from the config Byte
Description: Initializes Route Table pointer to the table ID specified in the config Byte.
Arg1: <Config Byte #>
Arg2: <Not Used>
AF Number: 126
Name: Load Route Group ID from route table row in Gen. Purpose Register
Description: Loads the Route Group ID from route table row in the specified Gen. Purpose Register
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 127
Name: Load Criteria type from route table row in Gen. Purpose Register
Description: Loads the Criteria Type from route table row in the specified Gen. Purpose Register
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 128
Name: Load Address Digits from incoming initiate buffer into the criteria data array
Description: Loads Address Digits from incoming initiate buffer into the criteria data array
Arg1: <String #>
Arg2: <Not Used>
AF Number: 129
Name: Load incoming Logical Span/Channel num from incoming initiate buffer into the criteria data array
Description: Loads incoming Logical Span/Channel num from incoming initiate buffer into the criteria data array
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 130
Name: Load time of the day into the criteria data array
Description: Loads time of the day into the criteria data array
MSP
1496
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 132
Name: Transfer Data in buffer <0:initiate to terminate,1:terminate to initiate> <0:move,1:copy>
Description: Transfer Data between buffers
Arg1: 0-initiate to terminate
1-terminate to initiate
Arg2: 0-move,
1-copy
AF Number: 134
Name: Load number of digits to compare into the Gen Purpose Register
Description: Loads the number of digits to compare into the specified GP Register
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 136
Name: Compare number of digits loaded in the GP Register of the criteria data array to the criteria data field in the route table (with mask
Description: Compares the number of digits loaded in the GP Register of the criteria data array to the criteria data field in the route table.
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 137
Name: Compare Span Channel Address in criteria data array to the criteria data field in the route table
Description: Compares Span Channel Address in criteria data array to the criteria data field in the route table
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 138
Name: Compare Time of the day in criteria data array to the criteria data field in the route table
Index
1497
Description: Compares Time of the day in criteria data array to the criteria data field in the route table.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 142
Name: Load Resource Group Address Element TLV Data in Address Element block
Description: Loads the Resource Group Address Element TLV Data in Address Element block
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 148
Name: Send Call Service Request Ack to initiate address using outgoing initiate buffer
Description: Sends Call Service Request Ack to initiate address using outgoing initiate buffer
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 149
Name: Send Call Service Reject to initiate address using outgoing initiate buffer and reject reason
Description: Sends Call Service Reject to initiate address using outgoing initiate buffer and reject reason
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 151
Name: Load Resource Group TLV in Resource Group Array # in Gen Purpose Register
Description: Loads the Resource Group TLV in Resource Group Array # in Gen Purpose Register (Used while processing multi criteria requests)
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 152
Name: Initialize Resource Group Table pointer to the table ID from the config Byte
MSP
1498
Description: Initializes the Resource Group Table pointer to the table ID from the specified config Byte
Arg1: <Config Byte #>
Arg2: <Not Used>
AF Number: 153
Name: Find/Test a common set of Resource Group and load them into the resource group array
Description: Finds/Tests a common set of Resource Group and loads them into the resource group array (Used for Multi criteria)
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 154
Name: Resource Group Table pointer to the first table ID in the resource group array
Description: Initializes Resource Group Table pointer to the first table ID in the resource group array
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 155
Name: Load Resource Group TLV in Resource Group Array # in Gen Purpose Register
Description: Loads the Resource Group TLV in Resource Group Array # in Gen Purpose Register (Used while processing multi criteria requests)
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 156
Name: Load Entry Data Field TLV Data in Address Element Block
Description: Loads Entry Data Field TLV Data in Address Element Block
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 157
Name: Load Resource Group ID from incoming initiate buffer in Gen. Purpose Register
Index
1499
Description: Loads the Resource Group ID from incoming initiate buffer in Gen. Purpose Register
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 158
Name: Load Span/Channel Address Element from incoming initiate buffer in Address Element block
Description: Loads the Span/Channel Address Element from incoming initiate buffer in Address Element block
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 159
Name: Load Criteria Type search key from incoming initiate buffer into Gen. Purpose Register
Description: Loads the Criteria Type search key from incoming initiate buffer into Gen. Purpose Register
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 166
Name: Move Gen Purpose Register to Global Gen Purpose Register < Register #>
Description: Moves the contents of Gen Purpose Register to the specified Global Gen Purpose Register
Arg1: <To Register #>
Arg2: <Not Used>
AF Number: 167
Name: Move Global Register to Gen Purpose Register < Register #>
Description: Moves the contents of Global Register to the Gen Purpose Register
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 168
Name: Load Resource Group ID from incoming initiate buffer in Gen. Purpose Register
Description: Global Register (GP Register index #) to Gen Purpose Register
MSP
1500
Arg1: <Register #>
Arg2: <Not Used>
AF Number: 169
Name: Move Gen Register (GP Register index #) to Global Gen Purpose Register
Description: Moves Gen Register (GP Register index #) to Global Gen Purpose Register
Arg1: <Register #>
Arg2: <Not Used>
Index
1501
SS7 Atomic Functions
BT IUP CPC (0x0052)
Purpose
The following atomic functions are used by the BT IUP CPC variant
Atomic Functions
AF Number: 151
Name: IUPCPC Send IAM to L3P
Description: This function will forward the received IAM message to L3P. L3P will receive it as event IUP_L3PnIAM with an data buffer containing the received IAM message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success
AF Number: 152
Name: IUPCPC Send IFAM to L3P
Description: This function will forward the received IFAM message to L3P. L3P will receive it as event IUP_L3PnIFAM with an data buffer containing the received IFAM message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success
AF Number: 153
Name: IUPCPC Send SAM to L3P
Description: This function will forward the received SAM message to L3P. L3P will receive it as event IUP_L3PnSAM with an data buffer containing the received SAM message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success
MSP
1502
AF Number: 154
Name: IUPCPC Send FAM to L3P
Description: This function will forward the received FAM message to L3P. L3P will receive it as event IUP_L3PnFAM with an data buffer containing the received FAM message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success
AF Number: 155
Name: IUPCPC Send ASUI to L3P
Description: This function will forward the received ASUI message to L3P. L3P will receive it as event IUP_L3PnASUI with an data buffer containing the received ASUI message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success
AF Number: 156
Name: IUPCPC Send SND to L3P
Description: This function will forward the received SND message to L3P. L3P will receive it as event IUP_L3PnSND with an data buffer containing the received SND message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success
AF Number: 157
Name: IUPCPC Send SAD to L3P
Description: This function will forward the received SAD message to L3P. L3P will receive it as event IUP_L3PnSAD with an data buffer containing the received SAD message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1503
Outputs: Message queued for L3P
Returns: Success
AF Number: 158
Name: IUPCPC Send SASUI to L3P
Description: This function will forward the received SASUI message to L3P. L3P will receive it as event IUP_L3PnSASUI with an data buffer containing the received SASUI message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success
AF Number: 159
Name: IUPCPC Send ACM to L3P
Description: This function will forward the received ACM message to L3P. L3P will receive it as event IUP_L3PnACM with an data buffer containing the received ACM message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success
AF Number: 160
Name: IUPCPC Send CNG to L3P
Description: This function will forward the received CNG message to L3P. L3P will receive it as event IUP_L3PnCNG with an data buffer containing the received CNG message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success
AF Number: 161
Name: IUPCPC Send SEM to L3P
Description: This function will forward the received SEM message to L3P. L3P will receive it as event IUP_L3PnSEM with an data buffer containing the received SEM message converted into TLV format.
MSP
1504
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 162
Name: IUPCPC Send CNA to L3P
Description: This function will forward the received CNA message to L3P. L3P will receive it as event IUP_L3PnCNA with an data buffer containing the received CNA message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 163
Name: Check Incoming Congestion
Description: This function will check for congestion in the inbound direction.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: PPLevINT_EVENT_1 if congestion is detected. Otherwise, it is PPLevINT_EVENT_0.
Returns: Success always
AF Number: 166
Name: IUPCPC Send ANS to L3P
Description: This function will forward the received ANS message to L3P. L3P will receive it as event IUP_L3PnANS with an data buffer containing the received ANS message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 167
Name: IUPCPC Send CLR to L3P
Index
1505
Description: This function will forward the received CLR message to L3P. L3P will receive it as event IUP_L3PnCLR with an data buffer containing the received CLR message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 168
Name: IUPCPC Send RAM to L3P
Description: This function will forward the received RAM message to L3P. L3P will receive it as event IUP_L3PnRAM with an data buffer containing the received RAM message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 169
Name: IUPCPC Send REL to L3P
Description: This function will forward the received REL message to L3P. L3P will receive it as event IUP_L3PnREL with an data buffer containing the received REL message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 170
Name: IUPCPC Send CCF to L3P
Description: This function will forward the received CCF message to L3P. L3P will receive it as event IUP_L3PnCCF with an data buffer containing the received CCF message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
MSP
1506
AF Number: 171
Name: IUPCPC Send BLO to L3P
Description: This function will forward the received BLO message to L3P. L3P will receive it as event IUP_L3PnBLO with an data buffer containing the received BLO message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 172
Name: IUPCPC Send UBL to L3P
Description: This function will forward the received UBL message to L3P. L3P will receive it as event IUP_L3PnUBLwith an data buffer containing the received UBL message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 173
Name: IUPCPC Send BLA to L3P
Description: This function will forward the received BLA message to L3P. L3P will receive it as event IUP_L3PnBLA with an data buffer containing the received BLA message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 174
Name: IUPCPC Send UBA to L3P
Description: This function will forward the received UBA message to L3P. L3P will receive it as event IUP_L3PnUBA with an data buffer containing the received UBA message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Index
1507
Returns: Success always
AF Number: 175
Name: IUPCPC Send OVL to L3P
Description: This function will forward the received OVL message to L3P. L3P will receive it as event IUP_L3PnOVL with an data buffer containing the received OVL message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 176
Name: IUPCPC Send CFN to L3P
Description: This function will forward the received CFN message to L3P. L3P will receive it as event IUP_L3PnCFN with an data buffer containing the received CFN message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 178
Name: IUPCPC Send ACI to L3P
Description: This function will forward the received ACI message to L3P. L3P will receive it as event IUP_L3PnACI with an data buffer containing the received ACI message converted into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for L3P
Returns: Success always
AF Number: 179
Name: Send L5 PPL Event Indication without data.
Description: This function will send a PPL Event Indication to the host with the event number specified in Arg1.
Arg1: The Event Indication Number
Arg2: <Not Used>
MSP
1508
Outputs: Message queued for L5
Returns: Success, or the channel will purge if internal errors occur
AF Number: 180
Name: IUPCPC Send L5 PPL Event Indication with Raw Data
Description: This function will send a message to L3P indicating that an Invalid ACI message was received from MTP. L3P will receive it as event L3P_L3evINV_ACI with an data buffer containing the received invalid message converted into TLV format.
Arg1: The Event Indication Number
Arg2: <Not Used>
Outputs: Message queued for L5
Returns: Success always
AF Number: 181
Name: Get Timer associated value
Description: Retrieves the associated value
Arg1: Timer number
Arg2: Register to contain associated value
Returns: Success always
AF Number: 182
Name: Send PPL Event Indication CLR to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 183
Name: Send PPL Event Indication RE-ANSWER (RAN) to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 184
Name: Send PPL Event Indication SUS to L5
Arg1: <Not Used>
Arg2: <Not Used>
Index
1509
Returns: Success always
AF Number: 185
Name: Send PPL Event Indication RES to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 186
Name: Send PPL Event Indication SWAP to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 187
Name: Send Block Upon Release Event to L3
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 191
Name: IUPCPC Send IAM to SPRC
Description: This function will convert a TLV IAM message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 192
Name: IUPCPC Send IFAM to SPRC
Description: This function will convert a TLV IFAM message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
MSP
1510
Returns: Success always
AF Number: 193
Name: IUPCPC Send SAM to SPRC
Description: This function will convert a TLV SAM message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 194
Name: IUPCPC Send FAM to SPRC
Description: This function will convert a TLV FAM message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 195
Name: IUPCPC Send ASUI to SPRC
Description: This function will convert a TLV ASUI message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 196
Name: IUPCPC Send SND to SPRC
Description: This function will convert a TLV SND message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
Index
1511
AF Number: 197
Name: IUPCPC Send SAD to SPRC
Description: This function will convert a TLV SAD message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns Success always
AF Number: 198
Name: IUPCPC Send SASUI to SPRC
Description: This function will convert a TLV SASUI message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 199
Name: IUPCPC Send ACM to SPRC
Description: This function will convert a TLV ACM message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 200
Name: IUPCPC Send CNG to SPRC
Description: This function will convert a TLV CNG message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
MSP
1512
AF Number: 202
Name: IUPCPC Send CNA to SPRC
Description: This function will convert a TLV CNA message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 203
Name: IUPCPC Send SEM to SPRC
Description: This function will convert a TLV SEM message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 206
Name: IUPCPC Send ANS to SPRC
Description: This function will convert a TLV ANS message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 207
Name: IUPCPC Send CLR to SPRC
Description: This function will convert a TLV CLR message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 208
Index
1513
Name: IUPCPC Send RAM to SPRC
Description: This function will convert a TLV RAM message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 209
Name: IUPCPC Send REL to SPRC
Description: This function will convert a TLV REL message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 210
Name: IUPCPC Send CCF to SPRC
Description: This function will convert a TLV CCF message into raw format and queue it up for SPRC or MTP.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC or MTP
Returns: Success or PPLerrAF_INITIATED_RESET if the send to MTP fails
AF Number: 211
Name: IUPCPC Send BLO to SPRC
Description: This function will convert a TLV BLO message into raw format and queue it up for SPRC or MTP.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC or MTP
Returns: Success or PPLerrAF_INITIATED_RESET if the send to MTP fails
AF Number: 212
Name: IUPCPC Send UBL to SPRC
MSP
1514
Description: This function will convert a TLV UBL message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 213
Name: IUPCPC Send BLA to SPRC
Description: This function will convert a TLV BLA message into raw format and queue it up for SPRC or MTP.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC or MTP
Returns: Success or PPLerrAF_INITIATED_RESET if the send to MTP fails
AF Number: 214
Name: IUPCPC Send UBA to SPRC
Description: This function will convert a TLV UBA message into raw format and queue it up for SPRC or MTP.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC or MTP
Returns: Success or PPLerrAF_INITIATED_RESET if the send to MTP fails
AF Number: 215
Name: IUPCPC Send OVL to SPRC
Description: This function will convert a TLV OVL message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 216
Name: IUPCPC Send CFN to SPRC
Index
1515
Description: This function will convert a TLV CFN message into raw format and queue it up for SPRC or MTP.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC or MTP
Returns: Success or PPLerrAF_INITIATED_RESET if the send to MTP fails
AF Number: 218
Name: IUPCPC Send ACI to SPRC
Description: This function will convert a TLV ACI message into raw format and queue it up for SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message queued for SPRC
Returns: Success always
AF Number: 219
Name: IUPCPC SEND REL w/data to SPRC
Description: This function will format a raw Release message with the reason supplied in Arg1 and queue it up for MTP
Arg1: Decimal value of Release Reason
Arg2: <Not Used>
Outputs: Message queued for MTP
Returns: Success or PPLerrAF_INITIATED_RESET if the send to MTP fails
AF Number: 220
Name: IUPCPC Send CNA w/data to SPRC
Description: This function will format a raw Connection Not Admitted message with the reason suPPLied in Arg1 and queue it up for SPRC.
Arg1: Decimal value of CNA Reason
Arg2: Decimal value of CNA Diagnostics
Outputs: Message queued for SPRC or MTP
Returns: Success or PPLerrAF_INITIATED_RESET if the send to MTP fails
AF Number: 221
Name: Check for Incoming Congestion
MSP
1516
Description: This function will check an internal variable to see if incoming congestion has been detected.
Arg1: NA
Arg2: NA
Outputs: PPLevINT_EVENT_0 when no congestion exists. PPLevINT_EVENT_1
when Congestion IS Present.
Returns: Success always
AF Number: 232
Name: IUPCPC Test if Circuit is Blocked
Description: This function will test the blocked state of the circuit. The user may specify which of three types of blocking conditions for both local and remote circuit ends. The routine will return with a PPL event corresponding to it’s state. PPLevINT_EVENT_0 if not blocked, or PPLevINT_EVENT_1 if blocked.
Arg1: Circuit end to check. 0 = Local, 1 = Remote
Arg2: Type of Block to check. 0 = Maintenance, 1 = Hardware, 2 = Software
Outputs: See above
Returns: Success always
AF Number: 233
Name: IUPCPC Set Local Circuit Maintenance status to user specified state.
Description: This function will set the local circuit’s maintenance status to the value specified in Arg1.
Arg1: State
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 236
Name: IUPCPC Validate and Convert SPRC message to TLV format
Description: This function will validate and convert raw message into TLV format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: A buffer containing the TLV format of the raw message.
If successful PPLevINT_EVENT_1, otherwise PPLevINT_EVENT_0.
Returns: Success always
Index
1517
AF Number: 247
Name: IUPCPC Send Unknown MSG to SPRC
Description: This function will send a message containing the Generic TLV Entry Data to raw format, and send it to SPRC.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 250
Name: IUPCPC Get IUP message Parameter byte from the TLV into GPR #19
Description: This function will search for the TLV ID and byte specified in args 1 and 2 and return with GPR 19 containing the value of the specified byte.
Arg1: The TLV ID to be retrieved.
Arg2: The byte within the TLV to be place into GPR 19
Outputs: If successful GPR 19 will contain the specified byte and return with PPLevINT_EVENT_1.
Otherwise, GPR 19 will be set to 0 and we return PPLevINT_EVENT_0.
Returns: Success
AF Number: 253
Name: IUPCPC Update Remote Circuit Maintenance Block State to users specified state.
Description: This function will set an internal variable indicating the state of Remote Circuit’s maintenance block state.
Arg1: The State. 0 = Unblocked, 1 = Blocked
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success
MSP
1518
ISUP BLS, HGBS, and MGBS
Purpose
The following atomic function is used by the following components:
ISUP BLS (0x0016)
ISUP HGBS (0x007)
ISUP MGBS (0x0045)
Atomic Functions
AF Number: 69
Name: Check ISUP variant ID
Description: Finds ISUP variant ID of the stack.
Arg1: <Not Used>
Arg2: <Not Used>
Result: Returns a PPL event corresponding to the variant ID configured.
Index
1519
ISUP CPC (0x0012)
This section documents the atomic functions associated with ISUP CPC.
Atomic Functions
AF Number 51
Name Send SPRC Circuit Status Query
Description Sends a CIC circuit query to SPRC.
Arg1 <Not Used>
Arg2 <Not Used>
AF Number 52
Name Test Circuit Query Local Blocking MPC Status
Description Test the CIC Circuit status from SPRC for local maintenance blocking.
Arg1 <Not Used>
Arg2 <Not Used>
Test Result PPL Internal Event
Circuit not locally blocked
0
Circuit locally blocked
1
AF Number: 53
Name: Test Circuit Query Remote Blocking MPC Status
Description: Test the CIC Circuit status from SPRC for remote maintenance blocking.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
Circuit not remotely blocked
0
Circuit remotely blocked
1
AF Number: 54
MSP
1520
Name: Send SPRC CPC Circuit Status
Description: Sends a CIC circuit state update to SPRC with the ‘CPC’ status bits set to Arg1.
Arg1: <Circuit Status>
Arg2: <Not Used>
AF Number: 55
Name: Test Parameter with Bit Mask
Description: Tests a bit field within the parameter indicated by Arg1.
The most significant byte of Arg2 is used as a byte offset into the parameter. The least significant byte of Arg2 is used as a bit mask which is masked with the byte in the parameter specified in the MSB of Arg2. The result is then right-shifted until the right-most bit in the mask is in the least significant bit.
Arg1: <Parameter ID>
Arg2: <Byte Offset/Bit Mask>
Test Result
PPL Internal Event
Value 0 + value of bit field
AF Number: 56
Name: Send CCI Start
Description: Sends a Start event to CCI.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 57
Name: Test Parameter for Value
Description: Tests a byte within the parameter indicated by Arg1.
The most significant byte of Arg2 is used as a byte offset into the parameter. The least significant byte of Arg2 is used as the test value for the byte.
Arg1: <Parameter ID>
Arg2: <Byte Offset/Value>
Test Result PPL Internal Event
Values are not equal
0
Values are equal 1
Index
1521
AF Number: 58
Name: Send BLS Blocking
Description: Sends a Blocking event to BLS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 59
Name: Send SPRC MPC Remote Blk Circuit Status
Description: Sends a CIC circuit state update to SPRC with the ‘remote blocking’ status bit set to Arg1.
Arg1: <Circuit Status>
Arg2: <Not Used>
AF Number: 60
Name: Send SPRC Release Complete
Description: Formats and sends a RLC message to SPRC to be submitted to MTP using L3p provided parameters (if any are present).
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 61
Name: Send CRS Start
Description: Sends a Start event to CRS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 62
Name: Send SPRC Transient Circuit Status
Description: Sends a CIC circuit state update to SPRC with the ‘transient’ status bit set to Arg1.
Arg1: <Status>
Arg2: <Not Used>
AF Number: 63
Name: Send L3P Remote Block/Unblock Circuit Indication
Description: Sends L3P a Maintenance Block or Unblock, as indicated by Arg1.
MSP
1522
Arg1: <Circuit Status>
0 Maintenance Block
1 Maintenance Unblock
Arg2: <Not Used>
AF Number: 64
Name: Send L3P User-Defined Message Indication
Description: Formats and sends L3p a User-defined message indication including parameters.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 65
Name: Send SPRC User-Defined Message
Description: Formats and sends a user-defined message to SPRC to be submitted to MTP using L3P provided parameters.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 66
Name: Send BLR Unblocking
Description: Sends an unblocking indication to BLR.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 67
Name: Send HRB Unblocking
Description: Sends an unblocking indication to HRB.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 68
Name: Send CCI Stop
Description: Sends a stop indication to CCI.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1523
AF Number: 69
Name: Resend SPRC Release
Description: Resends a stored REL message to SPRC to be submitted to MTP. A REL message must first be stored in the re-transmission buffer (see Atomic Functions 72 and 73).
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 70
Name: Store IAM Information
Description: Temporarily stores an incoming IAM in a storage buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 71
Name: Send L3P Setup Indication
Description: Formats and sends a setup indication to L3P using the parameters in the current message. If no parameters are present in the current message, then the storage buffer is used as the parameter source.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 72
Name: Send SPRC Release
Description: Formats and sends a REL message to SPRC to be submitted to MTP using L3P provided parameters. The REL message is also copied and stored in the re-transmission buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 73
Name: Send SPRC Release
Description: Formats and sends a REL message to SPRC to be submitted to MTP using prestored parameters in the PPL Config Bytes at offset specified in Arg1. The REL message is also copied and stored in the re-transmission buffer.
Arg1: <Config Byte Offset of Parameters>
Arg2: <Not Used>
MSP
1524
AF Number: 74
Name: Send SPRC ACM
Description: Formats and sends an ACM message to SPRC to be submitted to MTP using L3P provided parameters.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 75
Name: Send L3P Release Indication
Description: Formats and sends a release indication to L3p using the parameters in the current message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 76
Name: Send L3P Reset Indication
Description: Formats and sends a reset indication to L3p using the parameters in the current message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 77
Name: Send SPRC ANM
Description: Formats and sends an ANM message to SPRC to be submitted to MTP using L3P provided parameters.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 78
Name: Send L3P Release Confirm
Description: Formats and sends a Release Confirm to L3P using the parameters in the current message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 79
Index
1525
Name: Send SPRC CPG
Description: Formats and sends an CPG message to SPRC to be submitted to MTP using L3P provided parameters.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 80
Name: Send SPRC IAM
Description: Formats and sends an IAM message to SPRC to be submitted to MTP using L3P provided parameters.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 81
Name: Send L3P ACM Indication
Description: Formats and sends an ACM indication to L3P using the parameters in the current message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 82
Name: Send L3P CPG Indication
Description: Formats and sends a CPG indication to L3P using the parameters in the current message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 83
Name: Send L3P ANM Indication
Description: Formats and sends an answer indication to L3P using the parameters in the current message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 84
Name: Send HGBS Blocking
Description: Sends a blocking event to HGBS.
MSP
1526
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 85
Name: Send L3P ISUP Event Indication
Description: Sends a generic event indication to L3p using the event ID specified in Arg1.
Arg1: <Event ID>
Arg2: <Not Used>
AF Number: 86
Name: Send L5 PPL Event Indication
Description: Formats and sends a PPL Event Indication to the host with no parameters.
Arg1: <Event ID>
Arg2: <Not Used>
AF Number: 87
Name: Test Circuit Query Local Blocking HWB Status
Description: Test the CIC Circuit status from SPRC for local hardware blocking.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result
PPL Internal Event
Not Blocked
0
Blocked 1
AF Number: 88
Name: Validate L3P SS7 Parameters
Description: Function to test that all mandatory parameters and all parameters lengths are valid for a L3p provided message ICB.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result
PPL Internal Event
Not Valid 0
Index
1527
Valid 1
AF Number: 89
Name: Test Circuit Query Remote Blocking HWB Status
Description: Test the CIC Circuit status from SPRC for remote hardware blocking.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result
PPL Internal Event
Not Blocked
0
Blocked 1
AF Number: 90
Name: Send CRR Reset Complete
Description: Sends a reset complete event to CRR.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 91
Name: Send CGRR Reset Complete
Description: Sends a reset complete event to CGRR.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 92
Name: Send L3P Local Reset Indication
Description: Formats and sends an local reset indication to L3P.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 93
Name: Send L3P Call Failure Indication with RLC pending
Description: Formats and sends a call failure indication to L3P with notification that a release complete event is still pending.
Arg1: <Not Used>
MSP
1528
Arg2: <Not Used>
AF Number: 94
Name: Send SPRC CON
Description: Formats and sends an CON message to SPRC to be submitted to MTP using L3P provided parameters.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 95
Name: Send CRS RESET After T5
Description: Send a ‘reset because of T5’ event to CRS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 96
Name: Send L3P CON Indication
Description: Formats and sends a CON indication to L3p using the parameters in the current message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 97
Name: Send CRCR Start
Description: Send a start event to CRCR.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 98
Name: Send L3p Call Failure Indication with no RLC pending
Description: Formats and sends a call failure indication to L3P with notification that no release complete event is pending.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 99
Name: Determine Controlling Exchange Based on DPC/CIC
Index
1529
Description: Function to determine the controlling exchange for dual seizure (glare) based on ITU-TS Q.767 sec. D.2.10.1.4.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 100
Name: CPC Send CRI Start
Description: Sends a Start event to CRI.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 101
Name: CPC Send L3P OOS Request
Description: Sends a CIC Out of Service Request to L3P.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 102
Name: CPC Send L3P In Service Request
Description: Sends a CIC In Service Request to L3P.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 105
Name: Cpc_af_105
Description: Go through the list of optional parameters and return various internal PPL events based on PCP instruction indicator (or no PCP found) if unexpected parameters are found.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 106
Name: Cpc_af_106
Description: Discard any unknown optional parameters from the message before sending the message to the host.
Arg1: <Not Used>
Arg2: <Not Used>
MSP
1530
AF Number: 107
Name: Cpc_af_107
Description: Send confusion if instruction indicator requires that notification should be sent.
Arg1: CFN Config Byte offset 150
Arg2: <Not Used>
AF Number: 108
Name: Cpc_af_108
Description: Test if notification should be sent or not.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
Do not send notification
0
Send notification 1
AF Number: 110
Name: Cpc_af_110
Description: Send a release with cause value 99 to the network.
Arg1: REL Config Byte offset 140
Arg2: <Not Used>
AF Number: 128
Name: Send L3P CRM indication.
Description: Send L3P an incoming CRM indication with data in ICB format.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 129
Name: Send L3P CRM status.
Description: Send the Circuit Reservation status message to L3P.
Arg1: Status to be sent
Arg2: <Not Used>
Index
1531
AF Number: 130
Name: Prepare ISUP message and send it to SPRC.
Description: Build/Re-use existing ISUP message and send it to SPRC.
Arg1: ISUP Message Config Index. Range 0-89
Arg2: Build/re-use flag Range 0-1
AF Number: 131
Name: Prepare ISUP message from Config Bytes and send to SPRC.
Description: Prepare ISUP message specified in Config Bytes and send it to SPRC.
Arg1: ISUP Msg. Config Index. Range 0-89
Arg2: PPL Config Byte offset Range 0-600
AF Number: 132
Name: Cpc_af_132
Description: Send OLM indication to L3P.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 134
Name: Send SSC ISUP message.
Type: Normal
Description: Send SSC an ISUP message with appropriate event.
Arg1: Msg Cfg Index
0 : 89
Arg2: Event ID
0 : 255
Result --
AF Number: 135
Name: Send SSC rel/reset indication
Type: Normal
Description: Sends the one of the following events to SSC based on the event ID:
Local Reset indication
Reset indication
Call failure RLC pending
MSP
1532
Call failure no RLC pending
Arg1: Event ID
0 : 255
Arg2: --
Result --
AF Number: 136
Name: Send SSC COT status
Type: Normal
Description: After the completion of the continuity procedures, this AF sends COT status to SSC.
Arg1: COT Status
0 – Failure, 1 – Success
Arg2: None
--
Result --
AF Number: 137
Name: Send SPRC SGM message
Type: Normal
Description: The Segmentation message constructed in the SSC is sent to the SPRC using this AF.
Arg1: None
--
Arg2: None
--
Result --
AF Number: 138
Name: Send SSC a PAM message
Type: Normal
Description: Forwards the PAM message to the SSC.
Arg1: Event ID
0 : 255
Arg2: None
Atomic Description Arg1 Arg2
Index
1533
Function
104 Check Network Suspend/Resume
-- --
111 Send L3P PPL Event Ind. Event ID (0 : 255)
--
112 Send SPRC ISUP message
Msg. cfg. index (0 : 78)
--
113 Not Used -- --
114 Not Used -- --
115 Not Used -- --
116 Send CCO start -- --
117 Send CCO stop -- --
120 Send SPRC COT status COT Status (0 : 1)
Par. offset (0:255)
121 Send CRO start -- --
122 Send CCO no reports -- --
123 Test if COT expected Par. ID (0 : 255) Par. offset (0:255)
124 CPC send CRCS start -- --
125 Send SPRC COT status COT Status (0 : 1)
Par. offset (0:200)
126 Send SPRC PAM message -- --
127 Send L5 ISUP PAM message
Event ID (0:255) --
AF Number: 149
Type: Normal
Name: Send the ISUP message to L3P CIC.
Description: This atomic function will send any ISUP message to L3PCIC for further processing.
Arg1: This is the Event ID in the L3PCIC.
Input range: 0-255
Arg2: This is the ISUP Message Configuration Index of the message to be sent to L3P CIC.
1-100
Test AF Results <Not Used>
MSP
1534
AF Number: 160
Name: Check ISUP variant ID
Description: Finds ISUP variant ID of the stack.
Arg1: <Not Used>
Arg2: <Not Used>
Result: Returns a PPL event corresponding to the variant ID configured.
Index
1535
cISUP SPRC (0x0013)
This section documents the atomic functions associated with ISUP SPRC.
Atomic Functions
AF Number: 51
Name: Send Message to MTP
Description: Delivers an outgoing message to MTP.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 52
Name: Update CPC Circuit Status and Remove Transient Circuit Status
Description: Updates the ‘CPC’ status bits and clears the ‘transient’ status bit in the CIC state database.
Arg1: <Event ID>
Arg2: <Not Used>
AF Number: 53
Name: Send Circuit Status to MPC
Description: Returns the current circuit state from the CIC state database to the requesting ISUP state machine.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 54
Name: Test ISUP Message Configuration Index
Description: Tests for the index into the ISUP Message Configuration Table.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result
PPL Internal Event
Index Value
0 + Index Value
MSP
1536
AF Number: 55
Name: Test for Unequipped CIC
Description: Test that the CIC(s) that this message refers to is equipped.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
Yes (Equipped) 0
No (At least one CIC is unequipped)
1
AF Number: 56
Name: Test If Confusion (CFN) Message
Description: Test if the incoming message is a CFN.
Arg1: <Event ID>
Arg2: <Event Data>
Test Result
PPL Internal Event
Yes 1
No 0
AF Number: 57
Name: Send UCIC to MTP
Description: Send a UCIC message based on the parameters stored in the configuration bytes at offset specified in Arg1.
Arg1: <Config Byte Offset>
Arg2: <Not Used>
AF Number: 58
Name: Send Call Control Message to CPC
Description: Delivers an incoming message to CPC.
Arg1: <Status Value>
Arg2: <Not Used>
AF Number: 59
Name: Send L5 PPL Event Indication for Span/Channel
Index
1537
Description: Sends a PPL Event Indication message to the host for the span/channel of the current message.
Arg1: <Event ID>
Arg2: <Not Used>
AF Number: 60
Name: Add DPC to Pause List
Description: Add the DPC to the pause queue and set it to expire in the number of timer ticks in Arg1.
Arg1: <# of Timer Ticks to Expiration>
Arg2: <Not Used>
AF Number: 61
Name: Check for DPC in Pause List and Remove
Description: Tests if a DPC in a RESUME message is in the Pause queue, and if so, removes it.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
Yes (DPC is in pause list)
1
No (DPC is not in pause list)
0
AF Number: 62
Name: Send Message to GBUR
Description: Delivers an incoming message to GBUR
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 63
Name: Send Message to GBUS
Description: Delivers an incoming message to GBUS
Arg1: <Not Used>
Arg2: <Not Used>
MSP
1538
AF Number: 64
Name: Send Message to CGRR
Description: Delivers an incoming message to CGRR.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 65
Name: Send Message to CGRS
Description: Delivers an incoming message to CGRS
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 66
Name: Send Message to CRI
Description: Delivers an incoming message to CRI.
Arg1: <Status Value>
Arg2: <Not Used>
AF Number: 67
Name: Send Message to CRR
Description: Delivers an incoming message to CRR.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 68
Name: Send Message to BLR
Description: Delivers an incoming message to BLR
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 69
Name: Send Message to BLS
Description: Delivers an incoming message to BLS
Arg1: <Not Used>
Arg2: <Not Used>
Index
1539
AF Number: 70
Name: Test if Valid Message
Description: Tests to determine if an ISUP Message is valid by consulting the ISUP Message Configuration template.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
Yes (Valid/Known) 1
No (Invalid/Unknown)
0
AF Number: 71
Name: Send Confusion (CFN) Message
Description: Send a CFN message based on the parameters stored in the configuration bytes at offset specified in Arg1.
Arg1: <Config Byte Offset W/ Parameters>
Arg2: <Not Used>
AF Number: 72
Name: Test if CRS Active
Description: Test if CRS for the CIC is active (non-idle).
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
No (Inactive) 0
Yes (Active) 1
AF Number: 73
Name: Test if CRI Active
Description: Tests if the CRI for the CIC is active (non-idle).
Arg1: <Not Used>
Arg2: <Not Used>
Test Result
PPL Internal Event
No 0
MSP
1540
(Inactive)
Yes (Active)
1
AF Number: 74
Name: Send MSG to CRS
Description: Delivers an incoming message to CRS
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 75
Name: Test if DPC is in Pause List
Description: Tests if the DPC of this message is in the DPC pause queue.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
No (Not in queue) 0
Yes (In queue) 1
AF Number: 76
Name: Validate Message Parsing
Description: Tests that the incoming message can be parsed according to the ISUP Message Configuration template.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
No (Corrupt message)
0
Yes (Valid message)
1
AF Number: 77
Name: Add MTP Message to Pause Queue
Description: Store outgoing message in the Pause Queue for MTP.
Arg1: <Not Used>
Index
1541
Arg2: <Not Used>
AF Number: 78
Name: Update MPC Blocking Circuit Status
Description: Updates the ‘Maintenance Blocking’ status bits (Maintenance Local Blocked, Maintenance Remote Blocked) in the CIC state database based on receiving an update message from an ISUP state machine.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 79
Name: Update Transient Circuit Status
Description: Updates the ‘transient’ status bit in the CIC state database based on receiving an update message from an ISUP state machine.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 80
Name: De-queue an MTP Message from Pause Message Queue and Send to MTP
Description: Tests for queued messages for the DPC which has received a RESUME event and, if one, sends it.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
No (No messages in queue)
0
Yes (Message sent) 1
AF Number: 81
Name: Test if Pause List is Empty
Description: Tests if DPC Pause queue is empty.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
No (Not 0
MSP
1542
Empty)
Yes (Empty) 1
AF Number: 82
Name: Decrement DPC Timer Values in Pause List
Description: Update all timers associated with the DPC Pause queue.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 83
Name: Send L3p Pause Expiration Events for Expired DPCs
Description: For all DPCs which have expired in Pause, queue, send a Pause event to L3p.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 84
Name: De-queue all Expired DPC Messages from Pause Message Queue
Description: Tests for expired DPC messages in the Pause Message queue and, if any, clears them.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
No (No expired messages)
0
Yes (Expired messages)
1
AF Number 85
Name Remove All Expired DPCs from the Pause List
Description Clears all expired DPCs in the DPC Pause List.
Arg1 <Not Used>
Arg2 <Not Used>
AF Number 86
Name Test MTP Status Cause Byte
Index
1543
Description Tests the status cause byte of an MTP indication.
Arg1 <Not Used>
Arg2 <Not Used>
Test Result PPL Internal Event
Congestion 1
Congestion 2
Congestion 3
User Part Unavailable
4
User Part Unequipped
5
User Part Inaccessible
6
AF Number: 87
Name: Send L5 Network Congestion Level Alarm
Description: Generates an alarm to the host indicating a level of network congestion and the DPC affected.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 88
Name: Send L3P ISUP Unavailable Event for DPC
Description: Sends L3P an indication that MTP has declared a remote ISUP unavailable.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 89
Name: Send L3P ISUP Resume Event for DPC
Description: Sends L3P an indication that MTP has issued a Resume for a DPC.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 90
Name: Send All ISUP SMs for a CIC a Stop Event
MSP
1544
Description: Broadcasts a STOP event to all ISUP state machines for a CIC.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 91
Name: Set Unequipped Bit and clear all other status for CIC
Description: Resets the CIC state database by clearing all status bits and setting the ‘unequipped’ bit.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 92
Name: Send Message to UCIC
Description: Delivers an incoming message to UCIC.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 93
Name: Update HW Blocking Circuit Status
Description: Updates the ‘Hardware Blocking’ status bits (Hardware Local Blocked, Hardware Remote Blocked) in the CIC state database based on receiving an update message from an ISUP state machine.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 94
Name: Update Maintenance SM Circuit Status
Description: Updates the maintenance-related status bits (Maintenance Unblock Wait, Hardware Unblock Wait, CRCR Recheck Active) in the CIC state database based on receiving an update message from an ISUP state machine.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 95
Name: Send MSG to CRCR
Description: Delivers an incoming MSU to CRCR.
Arg1: <Not Used>
Index
1545
Arg2: <Not Used>
AF Number: 96
Name: Test Circuit Status for CRCR Recheck
Description: Tests if CRCR Recheck is active for a CIC.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result
PPL Internal Event
No (Inactive)
0
Yes (Active)
1
AF Number: 97
Name: Test Message Parameter with Bit Mask
Description: Tests a bit field within the parameter indicated by Arg1.
The most significant byte of Arg2 is used as a byte offset into the parameter. The least significant byte of Arg2 is used as a bit mask which is masked with the byte in the parameter specified in the MSB of Arg2. The result is then right-shifted until the right-most bit in the mask is in the least significant bit
Arg1: <Not Used>
Arg2: <Not Used>
Test Result
PPL Internal Event
Value 0 + value of bit field
AF Number: 98
Name: Send Message to MGBR
Description: Delivers an incoming message to MGBR.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 99
Name: Send Message to MGBS
Description: Delivers an incoming message to MGBS.
Arg1: <Not Used>
MSP
1546
Arg2: <Not Used>
AF Number: 100
Name: Send Message to HGBR
Description: Delivers an incoming message to HGBR.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 101
Name: Send Message to HGBS
Description: Delivers an incoming message to HGBS.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 102
Name: Test Circuit Status for Transient
Description: Tests the ‘transient’ status bit in the CIC state database.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result
PPL Internal Event
Bit not set
0
Bit set 1
AF Number: 103
Name: CPC Circuit Status and remove unequipped status
Description: Updates the ‘CPC’ status bits and clears the ‘unequipped’ status bit in the CIC state database.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 104
Name: Clear status bits for unequipped circuits. Test if number of status bits is range
Description: Tests if the range field of the Range and Status parameter of an incoming message is in the range defined by Arg1 and Arg2.
Index
1547
The status bits for all unequipped circuits from the status field in the Range and Status parameter are cleared.
Arg1: <Value 1> Beginning of range.
Arg2: <Value 2> End of range.
Test Result PPL Internal Event
In range 1
Not in range 0
AF Number: 105
Name: Send L5 PPL Event Indication for stack
Description: Sends a PPL Event Indication to the host with entity of stack and event given by Arg1.
Arg1: <Event ID>
Arg2: <Not Used>
AF Number: 106
Name: Place DPC in UPU queue
Description: Places the DPC given in the MTP indication in the UPU queue.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 107
Name: Check for DPC in UPU Queue and remove
Description: Tests the User Part Unavailable (UPU) queue for the DPC given in the MTP indication and, if there, removes it.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
DPC in queue
1
No DPC in queue
0
AF Number: 108
Name: Send L3P User Part Accessible
Description: Sends L3P an indication that a remote ISUP has become accessible.
MSP
1548
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 109
Name: Clear Unequipped Bit for CIC
Description: Clears the ‘unequipped’ status bit in the CIC state database.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 110
Name: Update CPC Circuit Status
Description: Updates the ‘CPC’ status bits in the CIC state database.
Arg1: <Event ID>
Arg2: <Not Used>
AF Number: 129
Name: Sprc_af_129
Description: Find MCP parameter in the unrecognized message.
Arg1: <Event ID>
Arg2: <Not Used>
Test Result PPL Internal Event
If parameter found 1
If parameter not found
0
AF Number: 130
Name: Sprc_af_130
Description: Send unrecognized message PPL event indication containing unrecognized message to the host, with channel AIB.
Arg1: <Event Indication ID> 0-255
Arg2: <Not Used>
AF Number: 131
Name: Sprc_af_130
Description: Send a release with cause value 97 to the network and send and indication to CPC.
Index
1549
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 133
Type: Test
Name: SPRC test if Host controlled continuity enabled
Description: Looks into the common CPC area and checks if the Host Controlled Continuity is enabled.
Arg1: None
Arg2: None
Test AF Results: PPLevIntEVENT_0,PPLevIntEVENT_1
MSP
1550
ISUP SSC (0x0085)
This section documents the atomic functions associated with ISUP SSC.
Atomic Functions
AF Number: 52
Name: Send ISUP message to CPC
Type: Normal
Description: Sends message with the event specified in arg1 to CPC
Arg1: Event
0 : 255
Arg2: <Not Used>
AF Number: 53
Name: Test parameter with bitmask
Type: Test
Description: Test the parameter provided in arg1 with the bit-mask in the in arg2.
Arg1: Parameter ID
0 : 255
Arg2: Bitmask
0 : 255
Result PPLevIntEVENT_1 – If Bit mask qualifies
PPLevIntEVENT_0 – If it does not
AF Number: 54
Name: Store Message in buffer
Type: Normal
Description: Store the message in the MSG buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 55
Name: Assemble message in buffer
Type: Normal
Description: Assemble the message in MSG and SGM buffer into the MSG buffer.
Index
1551
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 56
Name: Send SGM message to L3P
Type: Normal
Description: Send the incoming Segmentation Message to L3P.
Arg1: Event ID
0 : 255
Arg2: <Not Used>
AF Number: 57
Name: Send ISUP message to L3P
Type: Normal
Description: Send the incoming ISUP message to L3P.
Arg1: Event ID
0:255
Arg2: <Not Used>
AF Number: 58
Name: Send Pass-through message to L5
Type: Normal
Description: Forward Pass through message to L5.
Arg1: ISUP message config index
0 :255
Arg2: <Not Used>
AF Number: 59
Name: Forward Incoming Message to L3P
Type: Normal
Description: Forwards Call control messages to L3P.
Arg1: Event
0 : 255
Arg2: <Not Used>
AF Number: 60
MSP
1552
Name: Forward Message to CPC
Type: Normal
Description: This messages forwards the message to CPC without any changes to it.
Arg1: Event
0: 255
Arg2: <Not Used>
AF Number: 61
Name: Send the Segmented Message to CPC
Type: Normal
Description: The AF sends the constructed SGM message to CPC.
Arg1: Event ID
0:255
Arg2: <Not Used>
AF Number: 62
Name: Store message in SGM buffer
Type: Normal
Description: Store incoming SGM message in SGM buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 63
Name: Test COT check flag in CPC
Type: Normal
Description: Test COT wait before RFS flag in CPC.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1553
L3P BT IUP (0x0011)
This section documents the atomic functions associated with L3P BT IUP.
Atomic Functions
AF Number: 160
Name: Send L3 an equip circuit request.
Description: This function will send an equip message to L3 (i.e. iupcpc).
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: Message is queued for L3
Returns: Success always
AF Number: 161
Name: Out of Service atomic function to restore the In-Service Protocol
Description: This function will restore the Primitive table and Event tables to point to the In-Service protocol, and the Protocol ID to the In-Service Protocol ID. The function exits with a status allowing the calling function, in message preprocessor file, to force the In-Service protocol to the desired state.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: See Description.
Returns: PPLerrSET_SM_STATE
AF Number: 162
Name: Out of Service atomic function to restore the In-Service Protocol
Description: This function will check for congestion in the outbound direction.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: PPLevINT_EVENT_1 if Output Congestion is detected; PPLevINT_EVENT_0 otherwise
Returns: Success always
AF Number: 170
Name: Validate L4/L5 Message
Description: This function will validate any message which originates from L4 or L5. Messages which contain IUP ICBs are validated and completed using the default information contained in the configuration byte area.
MSP
1554
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: The internal “down working” buffer will contain a valid TLV formatted message, if Success is returned.
The PPLevINT_EVENT_1 is set if successful, otherwise PPLevINT_EVENT_0 is returned.
Returns: Success always
AF Number: 171
Name: Send PPL Event Indication SSM to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 172
Name: Send PPL Event Indication SER to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 173
Name: Send PPL Event Indication ECM to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 174
Name: Send PPL Event Indication CFC to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 175
Name: Send PPL Event Indication OOR to L5
Arg1: <Not Used>
Arg2: <Not Used><Not Used>
Index
1555
Returns: Success always
AF Number: 176
Name: Send PPL Event Indication HLR to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 177
Name: Send PPL Event Indication SIM to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 178
Name: Send REL with Reason in REG to L3
Arg1: Register number containing the Release Reason
Arg2: <Not Used>
Returns: Success always
AF Number: 179
Name: Send CAN with Reason in REG to L3
Arg1: Register number containing the Release Reason
Arg2: <Not Used>
Returns: Success always
AF Number: 180
Name: Set Timer associated value
Description: Associates a value with one of the three timers. Later when the timer expires the value may be retrieved to determine the current usage of the timer and take the appropriate action.
Arg1: Timer number Range 1 thru 3
Arg2: Associated value
Returns: Success always
AF Number: 181
MSP
1556
Name: Get Timer associated value
Description: Retrieves the associated value
Arg1: Timer number
Arg2: Register to contain associated value
Returns: Success always
AF Number: 182
Name: Send PPL Event Indication CLR to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 183
Name: Send PPL Event Indication RE-ANSWER (RAN) to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 184
Name: Send PPL Event Indication SUS to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 185
Name: Send PPL Event Indication RES to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 186
Name: Send PPL Event Indication SWAP to L5
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
Index
1557
AF Number: 187
Name: Send Block Upon Release Event to L3
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 200
Name: Send IAM to L3
Description: This function will send the IAM message to L3. The IAM message is either taken from the “down working” buffer or if the down working buffer is empty, the IAM is taken from the Configuration Byte area.
Arg1: <Not Used>
Arg2: <Not Used>
Returns: Success always
AF Number: 201
Name: Send IFAM to L3
Description: This function will send the IFAM message to L3. The IFAM message is either taken from the “down working” buffer or if the down working buffer is empty, the IFAM is taken from the Configuration Byte area.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 202
Name: Send FAM to L3
Description: This function will send the FAM message to L3. The FAM message is either taken from the “down working” buffer or if the down working buffer is empty, the FAM is taken from the Configuration Byte area.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 203
Name: Send SAM to L3
MSP
1558
Description: This function will send the SAM message to L3. The SAM message is either taken from the “down working” buffer or if the down working buffer is empty, the SAM is taken from the Configuration Byte area.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 204
Name: Send REL to L3
Description: This function will send the REL message to L3. The REL message is either taken from the “down working” buffer or if the down working buffer is empty, the REL is taken from the Configuration Byte area.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 205
Name: Copy up working buffer to save buffer.
Description: This function will free the save buffer, if required. Allocate a new save buffer and copy the up working buffer into the save buffer.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 206
Name: Append up working buffers’ TLVs onto save buffer.
Description: This function will check to see that a save buffer has been allocated. (If not, this function will cause a channel purge.) Copy any TLVs in the up working buffer to the save buffer.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success or PPLerrAF_INITIATED_PURGE
AF Number: 207
Index
1559
Name: Swap up working buffer ptr with save buffer ptr
Description: This function will just sway the up working buffer ptr with the save buffer ptr.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 208
Name: Send SND to L3
Description: This function will send the SND message to L3. The SND message is either taken from the “down working” buffer or if the down working buffer is empty, the SND is taken from the Configuration Byte area.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 209
Name: Send CNA with Reason to L3
Description: This function will send a copy of the CNA message stored in the config byte area to L3. Arg1 is used to specify the reason value.
Arg1: Reason
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 210
Name: Send ACM to L3
Description: This function will send the ACM message to L3. The ACM message is either taken from the “down working” buffer or if the down working buffer is empty, the ACM is taken from the Configuration Byte area.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 211
MSP
1560
Name: Send ACI to L3. The “down working “ buffer must be contain the ACI message to be sent.
Description: This function will send the ACI message to L3
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success if the down working buffer contains a message. Otherwise, the channel will be purged.
AF Number: 212
Name: Send REL with Reason to L3
Description: This function will send the REL message to L3 with Arg1 containing the reason.
Arg1: Reason
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 213
Name: Send ANS to L3
Description: This function will send the ANS message to L3. The ANS message is either taken from the “down working” buffer or if the down working buffer is empty, the ANS is taken from the Configuration Byte area.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 214
Name: Send UNDEFINED message to L3
Description: This function will send the a message contained in the Generic TLV Entry Data or a message beginning with a unknown H0,H1 value within the H0,H1 Element TLV to L3.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success if the down working buffer contains a message. Otherwise, the channel will be purged.
Index
1561
AF Number: 215
Name: Send ACI to L3 of user defined type
Description: This function will send the specified ACI type message from the config byte area to L3.
Arg1: Desired ACI message type. Range 1 through 7
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success if a valid ACI message type is specified. Otherwise, the channel will be purged.
AF Number: 216
Name: Load requested ACI info from Config Bytes.
Description: This function will send the requested ACI type message from the config byte area to L3. The requested info is expected in an ACI type 7 message contained in the up working buffer.
Supported: ACI Information Request Codes are 1 through 9 , 11, and 12.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: PPLevINT_EVENT_1 if the ACI message is a type 7 Information Request. Otherwise, it will return PPLevINT_EVENT_0.
Returns: Success if a valid ACI message type is specified. Otherwise, the channel will be purged.
AF Number: 217
Name: Copy L3 message into Up Working Buffer
Description: This function will copy an incoming message form L3 into the up working buffer for use by L3P and possibly higher layers.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 218
Name: Send BLO to L3
Description: This function will send a Block message to L3. . The BLO message is either taken from the “down working” buffer or if the down working buffer is empty, the BLO is taken from the Configuration Byte area.
Arg1: <Not Used>
MSP
1562
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 219
Name: Send UBL to L3
Description: This function will send a Unblock message to L3. The UBL message is either taken from the “down working” buffer or if the down working buffer is empty, the UBL is taken from the Configuration Byte area.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 220
Name: Send an ACI type 7 Request message to L3 with user defined IRC type
Description: This function will send an ACI type 7 message to L3 with the Information Request Code specified in Arg1.
Arg1: The Information Request Code. Range 1 through 12 Except 3, 4, 10.
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success if Arg 1 is valid. Otherwise, the channel is purged.
AF Number: 221
Name: Send PPL Event Indication to the Host with event specified in the register.
Description: This function will send a PPL Event Indication to the Host. Arg1 specifies the register containing the event.
Arg1: The Register number which contains the event to be reported.
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 222
Name: Set OOS op Flag to the user specified value
Description: This function will set the Out Of Service operation flag.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1563
Outputs: <Not Used>
Returns: Success always
AF Number: 223
Name: L3PIUP Take CIC OOS
Description: This function will Cause an L3P reset to occur.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: With a status of PPLerrAF_INITIATED_RESET
AF Number: 224
Name: L3PIUP Test OOS OP Flag
Description: This function will setup a PPL internal event corresponding to the value of the Operation Flag.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: With a status of PPLevINT_EVENT_0 + the value of the Operation Flag
AF Number: 225
Name: L3PIUP Send Unequip message to L3
Description: This function will send an unequip message to L3
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 226
Name: L3PIUP Generated In-Service event
Description: This function will send a Transition to In-Service message to L3P.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
MSP
1564
AF Number: 227
Name: Send A CFN Event to L3
Description: This function will send a CFN event to L3.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 229
Name: Send A PPL Event Indication of ANS received before ACM to L5
Description: This function will send the above PPL Event Indication to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 230
Name: Send Access Denied to L4
Description: This function will send the Access Denied message to L4.
Arg1: Reason for denying access
Arg2: Call Status 0=Call Inactive, 1=Call Active
Outputs: <Not Used>
Returns: Success always
AF Number: 231
Name: Send PPL Event Indication to L5 if enabled by the corresponding Config Byte.
Description: This function will send a PPL Event Indication to L5 if the corresponding Config byte has been enabled to allow a PPL Event Indication to be issued.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success and PPLevINT_EVENT_1 PPL Event Indication was sent. Otherwise, it is a PPLevINT_EVENT_0.
AF Number: 232
Name: Test if IUP ICB is Present
Index
1565
Description: This function will test to see if an IUP ICB is present in the message.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success and a PPLevINT_EVENT_1. Otherwise, it is a PPLevINT_EVENT_0.
AF Number: 233
Name: Test if Stage N Address Data ICB is present
Description: This function will test to see if a Stage N Address Data ICB is present in the message.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success and a PPLevINT_EVENT_1. Otherwise, it is a PPLevINT_EVENT_0.
AF Number: 234
Name: Send Cut Through to L4
Description: This function will send a Cut Through message to L4.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 235
Name: Send Connect to L4
Description: This function will send a Connect message to L4.
Arg1: <Not Used>
Arg2: <Not Used><Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 236
Name: Send Disconnect to L4
Description: This function will send a Disconnect message to L4.
Arg1: <Not Used>
Arg2: <Not Used>
MSP
1566
Outputs: <Not Used>
Returns: Success always
AF Number: 237
Name: Send Clear Request to L4
Description: This function will send a Clear Request message to L4.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 238
Name: Test and Get Call Type ICB
Description: This function will test to see if a Call Type ICB is present in the message and if so, get the call type byte.
Arg1: Register number to contain the Call Type byte if one is present
Arg2: <Not Used>
Outputs: PPLevINT_EVENT_0 = No Call Type byte present, PPLevINT_EVENT_1 = Call Type byte is present.
Returns: Success always
AF Number: 239
Name: Setup Multi Purpose Timer 18 based upon No. Digits Requested and the Exchange Type.
Description: This function will setup the timeout value for timer 18 to a value based upon the number of digits required (in the register specified by Arg1) and the Exchange Type (in the register specified by Arg2).
Arg1: A register containing the number of digits requested in a SND message
Arg2: A register containing the Exchange Type. 0 = Terminating, 1 = Intermediate
Outputs: <Not Used>
Returns: Success if valid input arguments. Otherwise, the channel is purged.
AF Number: 240
Name: Test and Get ptr to TLV in specified buffer
Description: This function will examine the up or down working buffer to see if the IUP ICB contains the requested TLV.
Arg1: The requested TLV ID
Arg2: The buffer to check 0 = Upworking Buffer, 1 = Downworking Buffer
Index
1567
Outputs: PPLevINT_EVENT_1 if the TLV is located and an internal variable is setup pointing to the located TLV. Otherwise, PPLevINT_EVENT_0 is returned.
Returns: Success always
AF Number: 241
Name: Test and Get TLV byte into register
Description: This function will get the specified byte from the working buffer containing a TLV of interest, and copy it into the specified register.
Arg1: The number of the byte to fetch (Range 1 to 256), Beginning with the first data byte.
Arg2: The number of the register to contain the requested byte
Outputs: If successful PPLevINT_EVENT_1 is returned, Otherwise, the specified register is cleared and PPLevINT_EVENT_0 is returned.
Returns: Success always
AF Number: 242
Name: Get Config byte into GPR 10
Description: This function will get the specified configuration byte into General Purpose Register 10.
The user specifies the configuration byte by Block number and Byte number.
Arg1: The Block number containing the byte. (Range 1 to 3)
Arg2: The offset to the desired byte. (Range 1 to 200)
Outputs: If successful PPLevINT_EVENT_1, otherwise PPLevINT_EVENT_0 is returned.
Returns: Success always
AF Number: 243
Name: Arg1:GPR = Arg1:GPR – Arg2:GPR
Description: This function will subtract the contents of the register specified in Arg2 from the contents of the register specified in Arg1. The results are stored in register specified in Arg1.
Arg1: Any GPR
Arg2: Any GPR
Outputs: PPLevINT_EVENT_0 if the resulting contents of GPR specified in Arg1 is < 0 (i.e. Arg2 > Arg1)
PPLevINT_EVENT_1 if the resulting contents of GPR specified in Arg1 is > 0 (i.e. Arg1 > Arg2)
PPLevINT_EVENT_2 if the resulting contents of GPR specified in Arg1 is 0 (i.e. Arg1 = Arg2)
MSP
1568
Returns: Success always
AF Number: 244
Name: Form SND message using GPR value for N
Description: This message will format a SND message in TLV format using the contents of the register specified in Arg1 as the N value. (i.e. the number of digits requested). The SND message is either taken from the “down working” buffer or if the down working buffer is empty, the SND is taken from the Configuration Byte area.
Arg1: The number of a register containing the number of digits requested.
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 245
Name: Append accumulated addressed digits into Up Working buffer.
Description: This function will insert the original IAM message into the upworking buffer with the total accumulated address signals from the original IAM and subsequent SAM or FAM message.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success, If a previous IAM was not received the channel is purged.
AF Number: 246
Name: Arg1:GPR = Arg1:GPR + Arg2:GPR
Description: This function will add the contents of the register specified in Arg2 to the contents of the register specified in Arg1. The results are stored in register specified in Arg1.
Arg1: Any GPR
Arg2: Any GPR
Outputs: <Not Used>
Returns: Success always
AF Number: 247
Name: Save Address Digits
Description: This function will save the received address digits (form a IAM or IFAM) into an internal buffer. The contents of the internal buffer are overwritten with the new address digits.
Index
1569
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 248
Name: Append Address Digits
Description: This function will append the digits received from a SAM or FAM to internal buffer containing previously saved address digits.
Arg1: The number of a General Purpose Register to contain the total number of address digits collected for this call.
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success, Otherwise, PPLerrAF_INITIATED_PURGE if no digits were previously saved.
AF Number: 249
Name: Form ICB Setup message for L4
Description: This function will form a setup message for L4 in ICB format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success or PPLerrAF_INITIATED_PURGE if up working buffer is not valid.
AF Number: 250
Name: Form BCD Setup message for L4
Description: This function will form a setup message for L4 in BCD format.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success or PPLerrAF_INITIATED_PURGE if up working buffer is not valid.
AF Number: 251
Name: Send Formatted Setup message to L4
Description: This function will send the formatted message created by (Form ICB Setup message for L4 or Form BCD Setup message for L4) and send it to L4.
Arg1: <Not Used>
MSP
1570
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 252
Name: Send PPL Event Indication ACI to L5
Description: This function will send a PPL Event Indication of ACI to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 253
Name: Send PPL Event Indication SAM to L5
Description: This function will send a PPL Event Indication of SAM to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 254
Name: Send PPL Event Indication FAM to L5
Description: This function will send a PPL Event Indication of FAM to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 255
Name: Send NACK or ACK to L5
Description: This function will send a ACK or NACK to L5 based upon the contents of Arg1.
Arg1: 0 = NACK, 1 = ACK
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
Index
1571
AF Number: 256
Name: L3PIUP Send Response to Outseize Control Message
Description: This function will send an response to L5 with a status specified in Arg1.
Arg1: The value to be sent in the status field of the message
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 257
Name: Send PPL Event Indication UNDEFINED Msg to L5
Description: This function will send a PPL Event Indication of UNDEFINED message to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 258
Name: Send PPL Event Indication Circuit already Blocked to L5
Description: This function will send a PPL Event Indication to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 259
Name: Send PPL Event Indication Call Connected to L5
Description: This function will send a PPL Event Indication of Call Connected to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 260
MSP
1572
Name: Send PPL Event Indication SND to L5
Description: This function will send a PPL Event Indication of SND to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 261
Name: Form IFAM from Stage N Address Data ICB
Description: This function will format an IFAM TLV message from a Stage N Address Data ICB message.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: If successful PPLevINT_EVENT_1 is returned, otherwise PPLevINT_EVENT_0.
Returns: Success or Failure
AF Number: 262
Name: Send PPL Event Indication of Circuit NOT Blocked to L5
Description: This function will format a PPL Event Indication to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 263
Name: Send PPL Event Indication of Error Timer Expired, Sending CNA to L5
Description: This function will format a PPL Event Indication to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 264
Name: Send PPL Event Indication to host
Description: This function will format a PPL Event Indication message using the Arg1 value as the event, and send it to the host.
Index
1573
Arg1: The event.
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 265
Name: PURGE CHANNEL
Description: This function will cause the Channel to be Purged, with the reason specified in Arg1.
Arg1: The purge reason
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 266
Name: Send PPL Event Indication CFN to L5
Description: This function will send a PPL Event Indication of CFN to L5. In addition if a buffer is present
in the m_message it will be sent also.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 267
Name: Send PPL Event Indication No Response to ACI Request to L5
Description: This function will send a PPL event Indication to the L5 when timer 2 (i.e. TO-14) expires due to not receiving any ACI response from an ACI request.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 268
Name: Send PPL Event Indication of CNG to L5
Description: This function will send this indication to L5.
Arg1: <Not Used>
MSP
1574
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 269
Name: Send PPL Event Indication of CNA to L5
Description: This function will send this indication to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 270
Name: Send PPL Event Indication of RAM to L5
Description: This function will send this indication to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 271
Name: Send PPL Event Indication of SEM to L5
Description: This function will send this indication to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 272
Name: Send PPL Event Indication of SAD to L5
Description: This function will send this indication to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
Index
1575
AF Number: 273
Name: Send PPL Event Indication of SASUI to L5
Description: This function will send this indication to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 274
Name: Send PPL Event Indication of ASUI to L4
Description: This function will send this indication to L5.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 275
Name: Send PPL Event Indication of No response to SASUI request
Description: This function will send a PPL Event Indication to the L5 when Timer 2 (i.e. TO-14) expires due to not receiving any ASUI response from an SASUI request.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 276
Name: Load Requested ASUI info from Config Bytes
Description: This function will form the appropriate ASUI message into the down working buffer based upon the SASUI request in the up working buffer.
The ASUI message is taken from the Config byte area.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: If it is a valid request PPLevINT_EVENT_1, otherwise PPLevINT_EVENT_0.
Returns: Success always
AF Number: 277
MSP
1576
Name: Send ASUI to L3
Description: This function will send an ASUI message to L3.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 278
Name: Send SASUI to L3
Description: This function will send a SASUI message to L3.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 279
Name: Send SASUI request message to L3, with user defined type
Description: This function will send a SASUI message to L3, of the type specified in Arg1.
Arg1: The Type of ASUI message to be returned (range 0 to 255). Only 1 is currently valid.
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 280
Name: Force sending an ACM message to L3
Description: This function will dynamically build and send an ACM message to L3. The contents of the down working buffer are not accessed or disturbed.
Arg1:
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 281
Name: Set Remote Maintenance Blocking State
Index
1577
Description: This function will allow the user to set the Remote Maintenance Blocking state.
Input: Argument 1 0 = Unblocked, 1 = Blocked
Input: Argument 2 <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 282
Name: Set Local Maintenance Blocking State
Description: This function will allow the user to set the Local Maintenance Blocking state.
Input Argument 1: 0 = Unblocked, 1 = Blocked
Input Argument 2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 283
Name: Test Blocking State
Description: This function will allow the user to Test any of the following local or remote blocking states. Maintenance, Hardware, and Software.
Input Argument 1: Blocking Location. 0 = Local, 1 = Remote
Input Argument 2: Blocking Type. 0 = Maintenance, 1 = Hardware, 2 = Software.
Outputs: If blocked PPLevINT_EVENT_1 is returned, otherwise PPLevINT_EVENT_0.
Returns: Success always
AF Number: 284
Name: Send SAD to L3
Description: This function will send a SAD message to L3.
Input: Argument 1 <Not Used>
Input: Argument 2 <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 285
Name: Test Accumulated Digits against Config Byte Digits
Description: This function compares n digits of the accumulated digits string with the digit string contained in the config byte area, at the specified config block and
MSP
1578
byte number. If the config byte string contains a digit of F that digit is skipped, in the config byte area and the accumulated digit string area.
NOTE: The digit to begin comparison, within the accumulated digit string is set by the value in register 20.
Arg1: The Config byte block number. Range 1 through 3
Arg2: The byte number within the above block. Range 1 through 200
Outputs: PPLevINT_EVENT_0 if match fails. Or the config bytes exceed
the size block limit. PPLevINT_EVENT_1 if match succeeds
Returns: Success always
AF Number: 286
Name: Test Accumulated Digits against Immediate Value
Description: This function compares from 1 to 4 digits of the accumulated digits string with the digit string contained in Arg2. If a nibble within Arg2 contains an F that digit is skipped.
NOTE: The starting digit within the accumulated digit string is set by the value in register 20.
Arg1: The number of bytes present in Arg2 to check. (range 1 to 4)
Arg2: The digits to validate against the accumulated buffer.
NOTE: A value of 0x4321 would attempt to match a 1 against the first digit in the accumulated digit string, a 2 against the second digit, a 3 against the third...
Outputs: PPLevINT_EVENT_0 if match fails. Or the config bytes exceed
the size block limit. PPLevINT_EVENT_1 if match succeeds
Returns: Success always
AF Number: 287
Name: Send Alarm Msg to Host
Description: This function will send an ALARM message to the Host using the user defined Severity, Entity, and Alarm values. Please refer to ALARM.H for normal values for these elements.
Arg1: High byte Severity, Low byte Entity
Arg2: Alarm Value
Outputs: Alarm message is sent to L5
Returns: Success always
AF Number: 288
Name: Set OOS Reason
Description: This function will Set the Out Of Service Reason to the value specified in Arg1.
Index
1579
Arg1: OOS reason.
Arg2: <Not Used>
Outputs: ...rw->unique_to.l3p_tup.oos_reason = Arg1
Returns: Success always
AF Number: 289
Name: Send Purge Message to L4
Description: Just sends the Purge Message to L4.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: <Not Used>
Returns: Success always
AF Number: 290
Name: Clear Up Working Buffer Ptr
Description: This function will free the buffer attached to the up_working_buffer_ptr, if present.
Arg1: <Not Used>
Arg2: <Not Used>
Outputs: up_working_buff_ptr is set to NULL.
Returns: Success always
AF Number: 291
Name: Set the In-Service_startup_flag to value in Arg1.
Description: This function will set the read write variable "inservice_startup_flag" to the value suPPLied in Arg1.
Arg1: Value.
Arg2: <Not Used>
Outputs: ...inservice_startup_flag = value.
Returns: Success always
AF Number: 292
Name: Get the In-Service_startup_flag value into register
Description: This function will load the contents of In-Service_startup_flag variable into the register specified in Arg1.
Arg1: Register to contain the value of inservice_startup_flag.
Arg2: <Not Used>
MSP
1580
Outputs: <Not Used>
Returns: Success always
Index
1581
L3P CIC (0x000F)
This section documents the atomic functions associated with L3P CIC.
Atomic Functions
The following AFs are specific to the L3P CIC Call Control PPL component.
AF Number: 51
Name: Send L4 Channel Status In Service
Description: Sends L4 a channel in service indication.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 52
Name: Send ISUP Circuit Reset
Description: Sends ISUP a CIC reset request using no parameters.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 53
Name: Fault
Description: Generates an SS7 card fault using fault code in Arg1.
Arg1: <Fault Code>
Arg2: <Not Used>
AF Number: 54
Name: PPL Restore Channel’s Assigned Protocol
Description: Function to switch from the OOS to the INS protocol.
Arg1: <Fault Code>
Arg2: <Not Used>
AF Number: 55
Name: PPL Send L5 PPL Event Indication using L4/L5 Outgoing Buffer
Description: Sends a PPL Event Indication to the host using the event ID in Arg1 and sending up any ISUP parameters stored in the L4/L5 outgoing buffer.
MSP
1582
Arg1: <Event ID>
Arg2: <Not Used>
AF Number: 56
Name: Send L4 a Cut Through
Description: Sends L4 a cut through indication.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 57
Name: Send L5 PPL Event
Description: Sends a PPL event indication to the host using the Event ID in Arg1 and sending up ICB with the data in Arg2.
Arg1: <Event ID>
Arg2: <Event Data>
AF Number: 58
Name: Send ISUP OOS Maintenance Loopback Ack
Description: Notifies ISUP that the requested PCM loopback has been established.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 59
Name: Copy Default ISUP Parameters into L5 Incoming Buffer
Description: Loads the PPL Config Byte prestored parameters at offset in Arg1 into the L5 incoming buffer.
Arg1: <Config Byte Offset of Defaults>
Arg2: <Not Used>
AF Number: 61
Name: Test for Existence of BCD Encoded Digits in Message
Description: Tests an Outseize Control message for the existence of BCD digits.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
Digits not present 0
Index
1583
Digits present 1
AF Number: 62
Name: Send L4 a Q.931 Connect Message
Description: Sends L4 a Connect Indication.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 63
Name: Send L4 a Q.931 Disconnect
Description: Sends L4 a disconnect Indication.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 64
Name: Send L4 a Q.931 Clear using L4/L5 Outgoing Buffer
Description: Sends L4 a Clear indication including any parameters present in the L4/L5 outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 65
Name: Send L4 OOS Maintenance Loopback
Description: Send L4 an OOS indication which also requests that a PCM loopback be connected to the channel.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 66
Name: Send L4 an Out of Service Message
Description: Sends an Out of Service message to L3/L4 with the reason indicated by Arg1.
Arg1: <Reason>
Arg2: <Not Used>
AF Number: 67
Name: Test L5 Incoming Buffer for parameters and assemble with defaults
MSP
1584
Description: Search the L4/L5 incoming buffer for an ICB relating to the message configuration specified in Arg1. If found, the ICB is concatenated with prestored parameters in the Config Bytes at the index specified by Arg2 and the resulting ICB is placed into the L4 /L5 incoming buffer.
Arg1: <ISUP Message Config Index>
Arg2: <Config Byte with Default>
Test Result PPL Internal Event
No ICB Found 0
ICB Found 1
AF Number: 68
Name: Copy Default ISUP Parameters and use BCD-Encoded digits into L5 Incoming Buffer
Description: Searches for a Stage N Address Data ICB w/ BCD encoded digit strings in the L4/L5 incoming buffer. The digits are translated into SS7 Called and Calling Party Number parameters using the parameter IDs specified in the MSB (Called Party) and LSB (Calling Party) of Arg2.
The parameters are concatenated with prestored parameters in the config bytes at the index specified in Arg1. The resulting ICB is stored in the L4/L5 incoming buffer.
Arg1: <Config Byte Offset Of Defaults> 1-200
Arg2: <Called Number Party ID/Calling Number Party ID>
AF Number: 69
Name: Send L4 a Q.931 SETUP using L4/L5 Outgoing Buffer
Description: Sends L4 a call SETUP indication including any SS7 parameters present in the L4/L5 outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 71
Name: Transfer L5 Formatted Raw SS7 Parameters from L4/L5 Incoming to ISUP Outgoing Buffer
Description: Searches the L4/L5 incoming buffer for the ICB corresponding to the message configuration specified by Arg1. Once found, the ICB is transferred to the ISUP outgoing buffer.
Arg1: <ISUP Message Config Index>
Arg2: <Not Used>
AF Number: 72
Index
1585
Name: Send L4 a Q.931 Alerting
Description: Sends L4 an alerting indication including any parameters present in the L4/L5 outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 73
Name: Test for Existence of SS7 Parameters in Message
Description: Test any message for the presence of SS7 ICB buffers.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
No parameters present 0
Parameters present 1
AF Number: 74
Name: Purge Channel
Description: Initiates a channel purge with purge reason specified in Arg1.
Arg1: <Purge Code>
Arg2: <Not Used>
AF Number: 75
Name: Send L5 PPL Event Request ACK
Description: Sends an acknowledgment to a PPL event request with the status specified in Arg1.
Arg1: <Status>
Arg2: <Not Used>
AF Number: 76
Name: Assemble L5 Parameters into L5 Incoming Buffer w/ Defaults
Description: Stores the ICBs attached to the L4/L5 message into the L4/L5 incoming buffer. A search for an ICB whose message type matches the message type of the prestored parameters specified in Arg1 is invoked.
If found, the ICB is concatenated with prestored parameters in the Config Bytes at the index specified by Arg1 and the resulting ICB is placed into the L4 /L5 incoming buffer. If not found, the defaults are copied ‘as is’ into the L4 /L5 incoming buffer.
Arg1: <Config Byte # of Defaults>
Arg2: <Not Used>
MSP
1586
AF Number: 77
Name: Transfer Network ISUP Raw SS7 Parameters from ISUP Incoming to L4/L5 Outgoing Buffer
Description: Transfers the ISUP incoming ICB to the L4/L5 outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 78
Name: Transfer Network Raw Parameters from ISUP Incoming into BCD-Encoded Digits
Description: Searches the ISUP incoming buffer for the Called Party parameter (indicated by Arg1) and the Calling Party parameter (indicated by Arg2). If found, the parameters are translated into BCD encoded digits strings and placed into the L4/L5 outgoing buffer.
Arg1: <Called Number Party ID>
Arg2: <Calling Number>
AF Number: 79
Name: Send L4 a Q.931 SETUP using BCD Digits.
Description: Sends L4 a Call Setup using any BCD digit string in the L4/L5 outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 80
Name: Send ISUP Setup Request using ISUP Outgoing Buffer
Description: Sends ISUP a Call Setup Request using the SS7 parameters present in the ISUP outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 81
Name: Send ISUP Answer Request using ISUP Outgoing Buffer
Description: Sends ISUP an Answer Request using the SS7 parameters present in the ISUP outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1587
AF Number: 82
Name: Send ISUP Release Request using ISUP Outgoing Buffer
Description: Sends ISUP a Release Request using the SS7 parameters present in the ISUP outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 83
Name: Send ISUP Release Response
Description: Sends ISUP a Release Response using the SS7 parameters present in the ISUP outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 84
Name: Send ISUP Progress Request using ISUP Outgoing Buffer
Description: Sends ISUP a Progress Request using the SS7 parameters present in the ISUP outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 85
Name: Send ISUP Alert Request using ISUP Outgoing Buffer
Description: Sends ISUP an Alert Request using the SS7 parameters present in the ISUP outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 86
Name: Send ISUP Reset Response
Description: Sends ISUP a Reset response using the SS7 parameters present in the ISUP outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 87
MSP
1588
Name: Send ISUP Maintenance Block Response
Description: Sends ISUP a Maintenance Block response using the SS7 parameters present in the ISUP outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 88
Name: Send ISUP Maintenance Unblock Response
Description: Sends ISUP a Maintenance Unblock response using the SS7 parameters present in the ISUP outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 89
Name: Send ISUP Block Request using ISUP Outgoing Buffer
Description: Sends ISUP a Block Request using the SS7 parameters present in the ISUP outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 90
Name: Send L4 OOS Span Alarm
Description: Sends Layer 4 an Out of Service due to a span alarm.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 91
Name: Send ISUP Unblock Request using ISUP Outgoing Buffer
Description: Sends ISUP an Unblock Request using the SS7 parameters present in the ISUP outgoing buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 92
Name: Send L4 OOS DPC Inaccessible
Description: Sends L4 a channel status of OOS due to a DPC Inaccessible indication.
Index
1589
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 93
Name: Transfer ISUP Raw SS7 Parameter from ISUP Incoming To L4/L5 Outgoing Buffer
Description: Copies a parameter from the incoming ISUP buffer to the outgoing L4/L5 buffer.
Arg1: <Parameter ID>
Arg2: <Not Used>
AF Number: 94
Name: Send L5 Outseize Control ACK
Description: Acknowledges an Outseize Control message with status specified in Arg1.
Arg1: <Status>
Arg2: <Not Used>
AF Number: 95
Name: Send L4 Access Denied
Description: Send L4 an Access Denied message with the reason specified in Arg1. The L3 Clear Pending Flag indicates if a Clear is sent to L4.
Arg1: <Reason>
Arg2: <L3 Clear Pending Flag>
AF: Number 96
Name: Store Network SS7 Parameters into ISUP Incoming Buffer
Description: Stores any incoming ISUP parameters into the ISUP incoming buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 97
Name: Pass Return Value
Description: Used to request services as part of a group state machine. Arg1 is used to request different services.
Arg1: <Value> 1 Group Reset
2 Group Block
MSP
1590
3 Group Unblock
4 Group Reset Response
5 Group Hardware Block
6 Group Hardware Unblock
Arg2: <Not Used>
AF Number: 98
Name: Store ISUP Protocol Violation ICB into L4/L5 Outgoing Buffer
Description: Used to store the information generated by an ISUP protocol violation in the L4/L5 outgoing buffer for transport to the host as part of a protocol violation PPL Event Indication.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 99
Name: Store ISUP Protocol Violation ICB into L4/L5 Outgoing Buffer
Description: Used to store the information generated by an ISUP protocol violation in the L4/L5 outgoing buffer for transport to the host as part of a protocol violation PPL Event Indication.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 100
Name: Send ISUP Delete CIC Event
Description: Sends ISUP a delete CIC request which forces a CIC to the unequipped (OOS) state. (Minimum Software Version: 5.0)
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 101
Name: Send ISUP Connect Request using ISUP Outgoing Buffer
Description: Sends ISUP a connect request using the SS7 parameters present in the ISUP outgoing buffer. (Minimum Software Version: 5.0)
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 102
Name: Take CIC Out of Service
Index
1591
Description: Takes the CIC out of service. (Minimum Software Version: 5.0)
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 103
Name: Set Out of Service Operation Flag
Description: The Out of Service Operation Flag determines how the CIC will respond to the next transition from Out of Service to In service. (Minimum Software Version: 5.0)
Arg1: <Flag Value> 0x00 - Unblock
0x01 - Reset
Arg2: <Not Used>
AF Number: 127
Name: Test message ID in outseize
Description: This atomic function returns the message ID in the Outseize Control message.
Arg1: <Not Used>
Arg2: <Not Used>
Test AF Results PPLevINT_EVENT_1, PPLevINT_EVENT_234
AF Number: 128
Name: Send CRM to ISUP
Description: Sends a CRM request to ISUP with default parameters from configuration or the parameters sent by the host
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 129
Name: Test ISUP CRM status.
Description: Test the status value in the ISUP_CRM_STATUS message.
Arg1: <Not Used>
Arg2: <Not Used>
Test AF Results Status event ranging from PPLevINT_EVENT_1 to PPLevINT_EVENT_255
AF Number: 130
MSP
1592
Name: Send IAM request to ISUP.
Description: Send IAM request to ISUP after Circuit Reservation.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number 134
Name Cic_af_129
Description Send busy out request to EX/CPU.
Arg1 <Not Used>
Arg2 <Not Used>
Atomic Function Description Arguments
Arg1 (range) Arg2 (range)
# Description Arg1 Arg2
109 Send msg. to ISUP CCR -- --
110 Send msg. to SYM -- --
111 Send msg. to ISUP CCO -- --
112 Check for Positive status -- --
113 Send msg. to ISUP DCO -- --
114 Send ISUP CRCS ACK. msg. (ITU only)
-- --
115 Send ISUP CRCS CPA result (ITU only)
-- --
116 Send ISUP CRCS stop (ITU) -- --
117 Send ISUP CRO stop (ANSI) -- --
118 Send SYM Connect Tone msg. -- --
119 Send ISUP DCO CPA result -- --
120 Send ISUP CCO CPA result -- --
121 Send ISUP msg. Req. using outgoing buffer
Event ID (1 : 78) --
122 Validate and assemble msg. using config. table in L5 incoming buffer
Cfg. table entry (1 : 50)
--
123 Test message ID in PAM -- --
124 Send L5 Event Ind. without data Event ID. (1 : 255) --
125 Send ISUP CVT request msg. offset (1 : 255) --
Index
1593
126 Send ISUP CVT req. for User part test
msg. offset (1 : 255) --
AF Number: 160
Type: Normal
Name: Copy CDPN digits to Digit_Buffer.
Description: This function will parse through the incoming setup message for the CDPN parameter. When it finds the parameter, it will copy the address signals in the parameter to the Digit_Buffer in the RW area and update the Number_of_Digits parameter in the RW area.
Arg1: <Not Used>
Arg2: <Not Used>
Test AF Results <Not Used>
AF Number: 162
Type: Normal
Name: Append digits received in SAM to Digit_Buffer.
Description: This function will parse through the incoming SAM for the Subsequent Address Parameter. This will append the digits in the Subsequent Address Parameter to the Digit_Buffer in the RW area, and update the Number_of_Digits parameter to reflect the new total.
Arg1: <Not Used>
Arg2: <Not Used>
Test AF Results <Not Used>
AF Number: 163
Type: Normal
Name: Copy digits from Digit_Buffer to ISUP incoming buffer.
Description: This function will copy the digits from the Digit_Buffer to the CDPN parameter in the stored ISUP SETUP message. It will also update the CDPN parameter to reflect the increased length and also update the “Odd/Even” indicator field.
Arg1: <Not Used>
Arg2: <Not Used>
Test AF Results <Not Used>
AF Number: 164
Type: Normal
Name: Check the digits in the Digit_Buffer.
MSP
1594
Description: This function will compare the number of digits received with the maximum number of digits to be received. It will also check whether the maximum number of digits can be collected. This is indicated by the fact that the size of the config byte is greater than the normal size of the Digit_Buffer (40 bytes).
Arg1: Configuration byte offset
Input range: 0-600
Arg2: <Not Used>
Test AF Results <Not Used>
Index
1595
L3P Link (0x0010)
This section documents the atomic functions associated with L3P Link Control.
Atomic Functions
AF Number: 51
Name: Send Activate Link Request to MTP3
Description: Requests that a signaling link be activated. This attempts to bring the signaling link up, through the initial alignment procedure, to an In Service state at MTP2. This does not necessarily mean that the link is available for user traffic at MTP3 because the signaling link’s inhibited status is independent of its active status.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 54
Name: Send Deactivate Link Request to MTP3
Description: Requests that a signaling link be deactivated. This brings the signaling link to an inactive state at MTP2. If the signaling link was previously available at MTP3, it becomes unavailable.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 55
Name: Send Inhibit Link Request to MTP3
Description: Requests to inhibit a signaling link. An inhibited signaling link is not usable at MTP3 for user traffic. Inhibiting a signaling link does not affect its MTP2 state.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 56
Name: Send Uninhibit Link Request to MTP3
Description: Request to uninhibit a signaling link.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 57
Name: Send L5 PPL Event Indication Message with Data
MSP
1596
Description: Sends a PPL Event Request message to the host with data.
Arg1: <Event ID>
1 - Remote Inhibit, the signaling link has been inhibited from the remote signaling point.
2 - Remote Uninhibit, the signaling link has been uninhibited from the remote signaling point.
3 - Local Inhibit Denied, a local request to inhibit a signaling link has been denied, possibly due to local or remote conditions.
4 - Local Inhibit Timeout, a local request to inhibit a signaling link has timed-out.
5- Local Inhibit, the local request to inhibit a signaling link was successful.
6 - Local Uninhibit, a local condition has caused a signaling link to become uninhibited.
7 - Uninhibiting Not Possible, a request to the remote signaling point to uninhibit a signaling link was unsuccessful.
8 - Uninhibit Timeout, a request to the remote signaling point to uninhibit a signaling link has timed-out.
10 - Link Activated, the signaling link has become active (In Service at MTP2).
11 - Link Dead, the signaling link is not framed properly at the physical layer (Layer 1).
12 - L5 OOS, this acknowledges a Service State Configure message from the host that results in the signaling link going from the L3P active state to the L3P “L5 OOS, L1 Alive” state. A Service State Configure message to bring L5 to the OOS state also causes the link to be deactivated.
Arg2: <Event Data>
The event data is always the normal state of the PPL component:
0 - L5 OOS and L1 Dead
1- L5 OOS and L1 Alive
2 - L5 In Service and L1 Dead
3 - L5 Alive and L1 Alive
AF Number: 58
Name: Send L5 a Message Response
Description: Generates a PPL Event Request Positive ACK to the host.
Arg1: <Status Value> 0x10 - Positive ACK
Arg2: <Not Used>
Index
1597
L3P TUP (0x0011)
This section documents the atomic functions associated with L3P TUP.
Atomic Functions
AF Number: 51
Name: Check if segmentation required
Type: Test
Description: Based on the Length of the message and the OFCI/OBCI segmentation indicator, a decision is made if the message has to be segmented.
Arg1: OFCI/OBCI parameter ID
0 : 255
Arg2: None
--
Result PPLevIntEVENT_0 – Msg not segmented
PPLevIntEVENT_1 – Msg segmented
TUP Virtual CIC
The following AFs are specific to the L3P TUP Call Control PPL component for TUP Virtual CIC.
AF Number: 73
Type: Normal
Description: Send PPL Event Indication to Host with VCIC AIB
Arg1: Event Id 1:65535
Arg2: Not Used
AF Number: 136
Type: Normal
Description: Send channel status change PPL Event Indication to Host with VCIC AIB
Arg1: OOS flag. 0:1
Arg2: OOS reason. 0:255
AF Number: 137
Type: Normal
MSP
1598
Description: Send PPL Event Request ACK with VCIC AIB
Arg1: Status. 0:511
Arg2: Not Used
Index
1599
SCCP CSCC (0x007F)
AF #: 59
Name: Get the backup SSN
Type: Normal
Description: Get the backup SSN from the Replicated SSN table.
Arg1: None
--
Arg2: None
--
Test AF Results: --
AF #: 56
Name: Test if backup subsystem co-located.
Type: Test
Description: Check if the backup SSN belongs to our own node.
Arg1: None
--
Arg2: None
--
Test AF Results: PPLevINT_EVENT_0 – Backup SSN does not belong to our own node. PPLevINT_EVENT_1 – Backup SSN belongs to our own node.
AF #: 52
Name: Send SCMG msg in N_UNITDATA to SCLC
Type: Normal
Description: Sends the constructed N_UNITDATA request primitive to SCLC
Arg1: None
--
Arg2: None
--
Test AF Results: --
AF #: 53
Name: Broadcast subsystem prohibited to BCST
Type: Normal
MSP
1600
Description: Construct SSP (subsystem prohibited) message and send it to BCST which will inform all the signalling points.
Arg1: None
--
Arg2: None
--
Test AF Results: --
AF #: 54
Name: Send N_COORD confirm primitive to the concerned SSN
Type: Normal
Description: Constructs the N_COORD confirm primitive and sends it to the originating SSN.
Arg1: None
--
Arg2: None
--
Test AF Results: --
AF #: 57
Name: Check if SSN = SCMG
Type: Test
Description: Checks if the SSN from the received Subsystem out of service request is SCMG(=1).
Arg1: None
--
Arg2: None
--
Test AF Results: --
AF #: 58
Name: Check if sccp/subsystem resources available.
Type: Test
Description: Checks if the SSN is in the prohibit_ssn_list.
Arg1: None
--
Arg2: None
Index
1601
--
Test AF Results: PPLevINT_EVENT_0 – if SSN not in prohibit_ssn_listPPLevINT_EVENT_1 – if SSN is in prohibit_ssn_list.
AF #: 55
Name: Send N_COORD response primitive to the concerned SSN
Type: Normal
Description: Constructs N_COORD response primitive and sends it to the duplicate SSN.
Arg1: None
--
Arg2: None
--
Test AF Results: --
AF #: 60
Name: Test SCMG msg
Type: Test
Description: Tests if the message is SOR (subsystem out of service request) or SOG(subsystem out of service grant).
Arg1: None
--
Arg2: None
--
Test AF Results: PPLevINT_EVENT_0 – if msg is SORPPLevINT_EVENT_1 – if msg is SOG
MSP
1602
SCCP SCOC (0x007D)
AF #: AF_51
Name: Check Resources and initialize connection data
Type: Test
Description: This atomic function is responsible for allocation of resources and initializing connection specific data structure
Arg1: None
Input Range
Arg2: None
Input Range
Test AF Results: PPLevINT_EVENT_1 if success else PPLevINT_EVENT_0
AF #: Af_52
Name: Construct CO message from primitive
Type: Normal
Description: This function will construct the required message taking parameters from the incoming primitive
Arg1: CO Message id
1 – 26
Arg2: Decription
Input Range
Test AF Results: NA
AF #: Af_53
Name: Send the connection oriented message to SCRC
Type: Normal
Description: This function will send the message to the SCRC, with an appropriate event.
Arg1: CO Message id
1 – 26
Arg2: Description
Input Range
Test AF Results: NA
AF #: Af_55
Name: Construct Connection Oriented Primitive from CO message
Index
1603
Type: Normal
Description: This atomic function will take the message and construct a SCCP CO primitive from it.
Arg1: Primitive Id
20 – 30
Arg2: Description
Input Range
Test AF Results: NA
AF #: AF_56
Name: Send CO Primitive to SUSI
Type: Normal
Description: This function will send to SUSI the SCCP primitive.
Arg1: Primitive id
Input Range
Arg2: Description
Input Range
Test AF Results: NA
AF #: Af_57
Name: Initialize/Update connection information
Type: Normal
Description: This function will update the SCOC RW data will the connection info taken from the parameters of the SCCP primitive or the SCCP CO message.
Arg1: Description
Input Range
Arg2: Description
Input Range
Test AF Results: NA
AF #: Af_58
Name: Get Cause value from primitive and store in buffer
Type: Normal
Description: This function will determine the cause value for connection release or connection refusal and store it in the SCOC RW area.
Arg1: Description
Input Range
MSP
1604
Arg2: Description
Input Range
Test AF Results: NA
AF #: Af_59
Name: Construct CREF/RLSD/ERR message
Type: Normal
Description: Construct CREF/RLSD/ERR message with cause value stored earlier
Arg1: Message Id
1 – 26
Arg2: Description
Input Range
Test AF Results: NA
AF #: Af_60
Name: Construct CREF/RLSD/ERR message with cause
Type: Normal/Blocking/test
Description: Construct CREF/RLSD/ERR message with cause value as input
Arg1: Message id
1 – 26
Arg2: Cause value
0 – 255
Test AF Results: NA
AF #: Af_61
Name: Release resources associated with the connection
Type: Normal
Description: Release all the resources associated with the connection and re-init the connection related data.
Arg1: Description
Input Range
Arg2: Description
Input Range
Test AF Results: NA
AF #: Af_62
Index
1605
Name: Check Discrepancy between IT message and Connection data
Type: Test
Description: This atomic function will check the incoming IT message for discrepancy between the message data and the data in the connection table
Arg1: Description
Input Range
Arg2: Description
Input Range
Test AF Results: PPLevINT_EVENT_1 if no discrepancy else PPLevINT_EVENT_0
AF #: Af_63
Name: Construct DT message from Transmit queue
Type: Normal
Description: This function constructs the DT message from first data buffer of the transmit queue.
Arg1: Message Id
1 – 26
Arg2: Description
Input Range
Test AF Results: NA
AF #: Af_64
Name: Segment user data and put in Transmit queue
Type: Normal
Description: This atomic function segments the incoming N_DATA indication and puts the segmented data in the transmit queue
Arg1: Description
Input Range
Arg2: Description
Input Range
Test AF Results: NA
AF #: Af_65
Name: Validate source reference number
Type: Test
Description: This function matches the Destination LRN and the LRN in our Connection Data structure
MSP
1606
Arg1: Description
Input Range
Arg2: Description
Input Range
Test AF Results: PPLevINT_EVENT_0 if not matching else PPLevINT_EVENT_1
AF #: Af_69
Name: Construct a N_DISCONNECT Indication primitive with reason
Type: Normal
Description: This function constructs a N_DISCONNECT Indication primitive with the given reason.
Arg1: Reason
0 – 255
Arg2: Description
Input Range
Test AF Results: NA
AF #: Af_71
Name: Check M-bit Value
Type: Test
Description: This function checks the M-bit value of the outgoing/incoming DT message
Arg1: Message Id
6 – 7
Arg2: Description
Input Range
Test AF Results: PPLevINT_EVENT_1 if M-bit = 1 else PPLevINT_EVENT_0
AF #: Af_72
Name: Check Protocol class of the connection
Type: Test
Description: This function checks the protocol class of the connection from the connection data.
Arg1: Description
Input Range
Arg2: Description
Input Range
Index
1607
Test AF Results: For Protocol class:0 – PPLev_INT_EVENT_01 – PPLev_INT_EVENT_12 – PPLev_INT_EVENT_23 – PPLev_INT_EVENT_3Unknown – PPLev_INT_EVENT_4
AF #: Af_73
Name: Send User Notification event request to SUSI
Type: Normal
Description: This function constructs a ‘user notification event’ w/o data and sends it to SUSI.
Arg1: Event Id
0 – 255
Arg2: Description
Input: Range
Test AF Results NA
AF #: Af_74
Name: Store data in receive queue
Type: Normal
Description: This function strips the data from incoming messages and stores it in the receive queue
Arg1: Description
Input Range
Arg2: Description
Input Range
Test AF Results: NA
AF #: Af_75
Name: Assemble N_DATA indication from data in receive queue
Type: Normal
Description: This function assembles an N_DATA indication from data buffers in the receive queue
Arg1: Description
Input Range
Arg2: Description
Input Range
Test AF Results: NA
MSP
1608
AF #: Af_76
Name: Construct IT message from connection data
Type: Normal
Description: This function constructs an IT message to be sent over the network.
Arg1: Description
Input Range
Arg2: Description
Input Range
Test AF Results: NA
Index
1609
SCCP SCRC (0x0066)
Purpose
The following atomic functions are used by the PPL component, SCRC (SCCP Routing Control - 0x0066).
Atomic Functions
AF #: 74
Name: Assign DLRN and allocate resources
Type: Test
Description: Assign DLRN and verify if a free SOOC SM exists
Arg1: None
--
Arg2: None
--
Test AF Results: PPLevINT_EVENT_0 – Resources allocatedPPLevINT_EVENT_1 – Resources not allocated
AF #: 76
Name: Build default CREF
Type: Normal
Description: Builds a default CREF messages with specified cause
Arg1: Cause value
1 – 7
Arg2: None
--
Test AF Results: --
AF #: 77
Name: Send routing failure to SCOC
Type: Normal
Description: Constructs the routing failure message and sends it to SCOC.
Arg1: Return cause
0 –255
Arg1: None
--
MSP
1610
Test AF Results: --
AF #: 78
Name: Send CO message to SCOC
Type: Normal
Description: Constructs a message and send it to SCOC.
Arg1: None
--
Arg1: None
--
Test AF Results: --
AF #: 79
Name: Get CO message routing data into RW
Type: Test
Description: Retrieve the CO message address information into SCRC RW
Arg1: None
--
Arg1: None
--
Test AF Results: PPLevINT_EVENT_0 – Address info. not found.PPLevINT_EVENT_1 – Address info. found
AF #: 80
Name: Get data from outgoing CO message
Type: Normal
Description: Get routing information from outgoing CO message into SCRC RW data
Arg1: None
--
Arg1: None
--
Test AF Results: --
AF Number: 92
Name: Test whether Global Title Translation (GTT) is allowed for local sub-system.
Index
1611
Description: Tests whether GTT is needed and the sub-system number (SSN) is allowed to do GTT locally.
Arg1: <Not Used>
Arg2: <Not Used>
Results: PPLevINT_EVENT_1 if yes.
PPLevINT_EVENT_0 if GTT is not needed
AF Number: 93
Name: SCRC Global Title Translation
Description: This function performs GTT, returns the success or failure status, and determines whether to perform further treatment to the address after the GTT.
Arg1: <Not Used>
Arg2: <Not Used>
Results: PPLevINT_EVENT_0: success
PPLevINT_EVENT_1: No translation for an address of such nature
PPLevINT_EVENT_2: No translation for this specific address
PPLevINT_EVENT_3: SSN failure
PPLevINT_EVENT_4: SCCP unequipped
PPLevINT_EVENT_5: MTP failure
PPLevINT_EVENT_6: MSG overlength with new CDPA
PPLevINT_EVENT_7: Support UMTS calling party address treatment.
PPLevINT_EVENT_7: After GTT operation needed
AF Number: 94
Name: Universal mobile telecommunications systems (UMTS) calling party address (CGPA)treatment
Description: Supports UMTS CGPA treatment.
Arg1: <Not Used>
Arg2: <Not Used>
Result: PPLevINT_EVENT_0 if success
PPLevINT_EVENT_6 if fail
AF Number: 95
Name: SCRC updates the called party address (CDPA).
Description: Updates CDPA in the internal chained buffer with new CDPA results from GTT.
Arg1: <Not Used>
MSP
1612
Arg2: <Not Used>
Result: Void
Index
1613
SCCP SRTC (0x007E)
AF #: 73
Name: Get DPC from the Available_DPC_list
Type: Normal
Description: Read the dpc address from the available DPC list.
Arg1: None
--
Arg2: None
--
Test AF Results: --
AF #: 74
Name: Send SP Accessible to SPAC
Type: Normal
Description: Sends the SP accessible message to SPAC with the read dpc no (af 51)
Arg1: None
--
Arg2: None
--
Test AF Results: --
AF #: 76
Name: Check if more DPCs in the Available_DPC_list
Type: Test
Description: Checks if some more DPCs are there in the list.
Arg1: None
--
Arg2: None
--
Test AF Results: --
AF #: 77
Name: Send ‘Restart’ to SCOC
Type: Normal
MSP
1614
Description: Constructs the restart message and sends it to SCOC.
Arg1: --
Arg1: --
Test AF Results: --
Index
1615
SCCP SUSI (0x0067)
AF #: 74
Name: Validate incoming message from host
Type: Test
Description: Validate the ICB type/length
Arg1: None
--
Arg2: None
--
Test AF Results: PPLevINT_EVENT_0 – Message is invalidPPLevINT_EVENT_1 – Message Valid
AF #: 75
Name: Test resource availability
Type: Test
Description: Check if a free SCOC SM exists
Arg1: None
--
Arg2: None
--
Test AF Results: PPLevINT_EVENT_0 – Resources not allocated PPLevINT_EVENT_1 – Resources allocated
AF #: 76
Name: Send message indication to L5
Type: Normal
Description: Send an event indication to L5 with data
Arg1: Event id
0 – 255
Arg2: None
--
Test AF Results: --
AF #: 77
Name: Build message with defaults
MSP
1616
Type: Normal
Description: fill the primitives will default parameters if they don’t exist in the PPL Event Request
Arg1: None
--
Arg2: None
--
Test AF Results: --
AF #: 78
Name: Send PPL event request ACK with data ICB.
Type: Normal
Description: Adds a DATA ICB to the PPL event request ACK. The data ICB is added after the response status.
Arg1: Response status
0 – 255
Arg2: None
--
Test AF Results: --
AF #: 79
Name: Test protocol Class
Type: Test
Description: Return the protocol class received in the message.
Arg1: None
--
Arg2: None
--
Test AF Results: Class 0 – PPLevINT_EVENT_0Class 1 – PPLevINT_EVENT_1Class 2 – PPLevINT_EVENT_2 and so on.
AF #: 80
Name: Send message to SCOC
Type: Normal
Description: Send message to SCOC with received event
Arg1: None
--
Index
1617
Arg2: None
--
Test: AF Results --
AF #: 81
Name: Send message SCCP user
Type: Normal
Description: Send message to an SCCP user specified by the GPR
Arg1: GPR #
--
Arg2: None
--
Test AF Results: --
AF #: 82
Name: Save user flag in GPR
Type: Normal
Description: Save the user id flag specified in SUSI RO data into GPR.
Arg1: GPR #
--
Arg2: None
--
Test AF Results: --
AF #: 83
Name: Validate SLRN in host message
Type: Test
Description: Validate the SLRN in the primitive received from the host (except N_CONNECT request)
Arg1: None
--
Arg2: None
--
Test AF Results: PPLevINT_EVENT_1 – valid SLRNPPLevINT_EVENT_0 – Invalid SLRN
MSP
1618
ISDN Atomic Functions
L3P Call Control (0x0005) Atomic Functions
Purpose
This section describes the atomic functions for the L3P Call Control PPL component.
L3P Call Control Atomic Functions
The following atomic functions are specific to the ISDN L3P Call Control PPL component.
Atomic Functions
AF Number: 51
Name: Load Raw IE in L4 Buffer
Description: Loads a raw IE received from the distant end into a Raw IE ICB (0x11) to be sent to the host in a PPL Event Indication or PPL Event Request message for service with address data. If the IE is not received, then nothing is loaded.
Arg1: <IE Value> 0-255 (ITU-T Q.931 codeset 0)
Arg2: <Not Used>
AF Number: 52
Name: Load Formatted and Raw IEs in L4 Buffer
Description: Loads the formatted IE ICB subtype (0x10) and the raw IE type (0x11) with the IEs received. The supported formatted IEs can be loaded and all other IES are included as raw in the Raw ICB. Eventually, you must invoke an atomic function to send this information.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 53
Name: Copy Raw IEs into L4 Buffer
Description: Copies received IEs into the Raw IE ICB subtype (0x11) for sending at a later time.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 54
Index
1619
Name: Purge B Channel and Send Clear to L3
Description: Deletes all timers and frees DSP resources per B channel. Then, it releases the call to Layer 3.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 55
Name: Load Formatted IEs into L4 Buffer
Description: Loads specific formatted IEs into a formatted IE subtype (0x10) for later reporting to the host.
Arg1: <Formatted IE Type> 1-50
Arg2: <Not Used>
AF Number: 56
Name: Test if IE Exists in L4 Message
Description: Tests for an existing IE in a Layer 4 message for PPL Event Request and Outseize Control.
Arg1: <IE Type> 0-255
Arg2: <Not Used>
AF Number: 57
Name: Send BSM CR Purge Indication
Description: Sends the BSM (component 7) a purge indication that should return the In-Service DS0 Status Change to the host.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 58
Name: Send Purge Indication to L4
Description: Sends an L3P initiated purge to Layer 4.
Arg1: <Purge Value> 0-255
Arg2: <Not Used>
AF Number: 61
Name: Load L4 IEs in Sorted Order
Description: Translates formatted and raw IEs to be sent to Layer 3 in sorted order.
Arg1: <Not Used>
MSP
1620
Arg2: <Not Used>
AF Number: 62
Name: Load L4 Formatted IEs to L3 Buffer
Description: Loads just the formatted IEs into a buffer to Layer 3. These would be inserted by host in the PPL Event Request and the Outseize Control.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 63
Name: Load L4 Raw IEs to L3 Buffer
Description: Loads the Layer 4 Raw IEs into a buffer to send to Layer 3 at a later time.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 65
Name: PPL Send Host PPL Event Indication
Description: Sends a PPL Event Indication to host. If a previous atomic function’s loaded Layer 3 IEs to go to Layer 4, then they also get sent.
Arg1: <Event ID> 1-255
Arg2: <Not Used>
AF Number: 66
Name: Test L3 Error Indication and Map to Internal Event
Description: If the previous event was a Layer 3 Error Indication, the error is added to the internal event base and returned. The state that follows this error should be an internal state to test the value.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 68
Name: Test # of Stored Digits
Description: Test if the # of stored digits is less than or equal to the value in Arg1.
Arg1: <# of Digits> See AF 84
Arg2: <Not Used>
Test PPL Internal
Index
1621
Result Event
<= 1
Other 0
AF Number: 69
Name: Test if IEs Exist in L3 Message
Description: Tests to see if the IE indicated by Arg1exists in a Layer 3 message.
Arg1: <IE ID> 0-255 (ITU-T Q.931 codeset 0 IE value)
Arg2: <Not Used>
Test Result PPL Internal Event
Exists 1
Does not exist
0
AF Number: 70
Name: Load IE Library IE
Description: Copies previously stored IEs in the IE Library into the buffer to Layer 3.
Arg1: <IE Library Index> 0-30
Arg2: <Not Used>
AF Number: 71
Name: Test if Stored Digits Equals Config Byte Value
Description: Tests to see if # of stored digits is less than or equal the value in Arg1.
Arg1: <Config Byte>
Arg2: <Not Used>
Test Result
PPL Internal Event
<= 1
Other 0
AF Number: 72
Name: Test For Sending Complete Indication
Description: Tests to see if there is a Sending Complete Indication message.
Arg1: <Not Used>
MSP
1622
Arg2: <Not Used>
Test Result PPL Internal Event
Yes 1
No 0
AF Number: 73
Name: Load Cause Code IE
Description: Copies the Cause Code indicated in Arg1 into a buffer to send to L3.
Arg1: <Cause Code>
Arg2: <Not Used>
AF Number: 74
Name: Test First Data ICB in Outseize Control Message
Description: Tests the first Data ICB subtype in the Outseize Control message.
This lets the Layer 3 Plus protocol distinguish the BCD encoded format for sending the information, and the formatted and raw subtypes. The returned code is the internal event for the value.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 75
Name: Translate Network-specific IE from B Channel Option
Description: Looks into channel previously configured options (B Channel Configure) and creates and copies the network-specific IE in the buffer to Layer 3. This atomic function is not needed if the host includes this information in the Outseize Control message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 76
Name: Translate Bearer Capability IE from B Channel Option
Description: Looks into channel previously configured options (B Channel Configure) and creates and copies the Bearer Capability IE in the buffer to Layer 3. This atomic function is not needed if the host includes this information in the Outseize Control message.
Arg1: <Not Used>
Arg2: <Not Used>
Index
1623
AF Number: 77
Name: Load Outseize Control Address Digits to Q.931 IEs
Description: Takes the BCD encoded stage digits from the Outseize Control and creates the Called Party IE and loads it in a buffer to send to Layer 3.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 78
Name: Send Outseize Control Ack
Description: Sends an Outseize Control ACK.
Arg1: <Value> 0-255
Arg2: <Not Used>
AF Number: 79
Name: Send PPL Event Request Ack
Description: Sends a PPL Event Request ACK.
Arg1: <Value> 0-255
Arg2: <Not Used>
AF Number: 80
Name: Send L3 to L4 SETUP Indication Using BCD-Encoded Stages
Description: Extracts Layer 3 SETUP information to load called and calling party digits in the Request for Service with Address Data message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 81
Name: Send L3 to L4 SETUP Indication Exact L3 Frame
Description: Sends the exact received frame for the SETUP message to the host in the Request for Service with Address Data message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 82
Name: Test Bit Mask in Specified Byte Offset Of IE in L2 to L3 Message
Description: Tests any set of bits in any byte of an IE in a message from L3.
Arg1: <IE ID>
MSP
1624
Arg2: <Byte Offset/Bit Mask> Byte Offset (MSB)/Bit Mask (LSB)
AF Number: 83
Name: Test for Sufficient Digits In Stored Called Party IE Buffer
Description: Verifies that there are sufficient digits in the Called Party IE Buffer. The number of significant digits is indicated in Config Byte 10.
NOTE: This atomic function applies to Euro ISDN only
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 85
Name: Store Called Party IE Digits
Description: Stores the Called Party digits from the Called Party IE in a SETUP or INFORMATION message from L3 into the Overlap Receive buffer. See AF 68 and AF 71.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 86
Name: Send INFO Requests in Overlap Mode
Description: Sends Called Party digits in continuous INFORMATION messages to L3 with one Called Party digit per message. This function should only be used for testing.
The Call Type must be set to 1 (Called Party digits are in Call Type ICB) using the Call Type ICB in the Outseize Control message.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 87
Name: Test Call Type
Description: Tests the Call Type obtained from the Call Type ICB sent in an Outseize Control message.
Arg1: <Not Used>
Arg2: <Not Used>
Test Result PPL Internal Event
Call Type 1 Called Party digits are in Call Type ICB
1
Index
1625
Call Type 2
Host controls sending of INFORMATION messages 2 Call Type ICB does not exist
0
AF Number: 88
Name: Load Sending Complete IE
Description: Load Sending Complete IE in to a SETUP or INFORMATION message to L3.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 89
Name: Test Called Party Digits using Config Byte
Description: Tests 1 or 2 digits in the Stored Called Party buffer. The offset into the digit string is indicated in Arg1. The number of digits to test (1 or 2) is indicated in Arg2.
Arg1: <Config Byte Offset> Config Byte containing the offset in to the digit string.
Arg2: <Config Byte # Test Digits> 1 or 2
AF Number: 90
Name: Test Called Party Digits
Description: Tests 1 or 2 digits in the Stored Called Party buffer. The offset into the digit string is indicated in Arg1. The number of digits to test (1 or 2) is indicated in Arg2.
Arg1: <Offset> Offset in to the digit string.
Arg2: <# of Test Digits> 1 or 2
AF Number: 91
Name: Load Remaining Called Party Digits in L3L4 Formatted IE Buffer
Description: Load remaining Called Party digits received in INFORMATION message from L3 into Formatted IE buffer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 92
Name: Store L3L4 Form and Raw IEs
Description: Store the L3 to L4 Formatted and Raw IE buffers to be loaded later.
Arg1: <Not Used>
MSP
1626
Arg2: <Not Used>
AF Number: 93
Name: Load Stored L3L4 Form and Raw IE Buffer
Description: Load the stored Formatted and Raw IE buffers.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 94
Name: Send L3 ANI Request
Description: Sends an ANI feature request to L3.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 95
Name: Send L3 Vari-A-Bill Request
Description: Sends a Vari-a-Bill feature request to L3.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 96
Name: Load NSF IE with ANI Req Information from B Channel Option
Description: Load a Network-specific Facility IE with ANI on Demand request information from the B channel configuration settings.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 97
Name: Decode NSF IEs to Set Available Features And Services
Description: Decodes the Network-specific Facility IE in the incoming SETUP message to setup the available features and services supported by the call.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 98
Name: Test if Feature is Available
Index
1627
Description: Test if the feature indicated by Arg1 is supported for this call, as indicated in the Network-specific Facility IE in the SETUP message.
Arg1: <Feature #> See TR41459, Appendix 3, Section 4.2.2.2.
Arg2: <Not Used>
Test Result PPL Internal Event
Supported 0
Not Supported
1
AF Number: 99
Name: Test if Service is Supported
Description: Test if the service indicated by Arg1 is supported for this call, as indicated in the Network-specific Facility IE in the SETUP message.
Arg1: <Service #> See TR41459, Part 3, Section 3.6.5.19.
Arg2: <Not Used>
Test Result PPL Internal Event
Supported 0
Not Supported
1
AF Number: 100
Name: Send L3 SETUP Request
Description: Request Layer 3 to send a SETUP message. This includes any previously stored IEs to be sent.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 101
Name: Send L3 CALL PROCEEDING Request
Description: Requests Layer 3 to send a CALL PROCEEDING message. This includes any previously stored IEs to be sent.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 102
Name: Send L3 INFO Request
MSP
1628
Description: Requests Layer 3 to send an INFORMATION message. This includes all previously stored IEs to be sent.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 103
Name: Send L3 ALERTING Request
Description: Requests Layer 3 to send an ALERTING message. This includes all previously stored IEs to be sent.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 104
Name: Send L3 PROGRESS Request
Description: Requests Layer 3 to send a PROGRESS message. This includes all previously stored IEs to be sent.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 105
Name: Send L3 CONNECT Request
Description: Requests Layer 3 to send a CONNECT message. This includes all previously stored IEs to be sent.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 106
Name: Send L3 CLEAR Request
Description: Requests Layer 3 to send a DISCONNECT or a RELEASE message. This includes any previously stored IEs to be sent. The Clear Request representation is determined by the side that initiated the DISCONNECT.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 107
Name: Send L3 USER INFORMATION Request
Description: Requests Layer 3 to send a USER INFORAMTION message. This includes any previously saved IEs to be sent.
Index
1629
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 108
Name: Send L3 FACILITY Request
Description: Request Layer 3 to send a FACILITY message. This includes previously stored IEs to be sent.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 109
Name: Send L3 SEGMENT Request
Description: Send SEGMENT REQ message to L3.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 111
Name: Send L3 REGISTER Request
Description: Requests Layer 3 to send a REGISTER message. This includes previously stored IEs to be sent.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 112
Name: Store Call Type ICB
Description: Stores the Call Type ICB if one exists.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 113
Name: Send L3 a GENERIC EVENT Request
Description: Sends a GENERIC EVENT request to L3.
Arg1: <Event #>
Arg2: <Not Used>
AF Number: 116
MSP
1630
Name: Send L3 NOTIFY Request
Description: Requests Layer 3 to send a NOTIFY message including any previously stored IEs to be sent.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 117
Name: Send L3 MORE INFO Request
Description: Sends a MORE INFO request to L3 to initiate Overlap Sending.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 131
Name: Send L4 Setup Indication
Description: Informs Layer 4 of an incoming call; sends the Request For Service with Address Data to the host.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 132
Name: Send L4 ALERTING Indication (Connect TS Post-answer)
Description: Sends an alerting indication to Layer 4, which causes a two-way connection if the host sent a Connect (A, B) message previously. Do not use this form to make a two-way connection prior to answer.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 133
Name: Send L4 ALERTING Indication (Connect TS Now)
Description: Sends the alerting indication to Layer 4 but not until a connection answer occurs.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 134
Name: Send L4 CONNECT Indication
Description: Informs Layer 4 of distant end answer.
Index
1631
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 135
Name: Send L4 DISCONNECT Indication
Description: Inform Layer 4 of a DISCONNECT request from the distant end.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 136
Name: Send L4 CLEAR Indication
Description: Informs Layer 4 that the release sequence is complete and the call has returned to IDLE/NULL State.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 137
Name: Determine Congestion Level
Description: Finds out the current congestion level
Arg1: N/A
Arg2: N/A
AF Number: 138
Name: Send L4 Access Denied
Description: Sends a L3_CCPnACCESS_DENIED message to Layer 4 with status ISDN_STACK_CONGESTED (0x3E)
Arg1: Value of status field
Arg2: N/A
AF Number: 144
Name: Save type of Segmented Message in GPR if REASSEMBLY< GPR#>
Description: Saves Segmented Message type in GPR specified by Arg1, if REASSEMBLY flag is set in message
Arg1: GPR#
Arg2: <Not Used>
AF Number: 145
MSP
1632
Name: Save type of Segmented Message in GPR if REASSEMBLY and Release Request Enabled< GPR#>
Description: Saves Segmented Message type in GPR specified by Arg1, if REASSEMBLY flag is set in message and Channel Release Request is enabled on ISDN disconnect
Arg1: GPR#
Arg2: <Not Used>
AF Number: 146
Name: Compare type of Segmented Message with <GPR#>
Description: Compare type of Segmented Message with value of GPR specified by Arg1
Arg1: GPR#
Arg2: <Not Used>
Results: PPLevINTERNAL_EVENT_1 if Segmented Message type == GPR <Arg1>
PPLevINTERNAL_EVENT_0 if Segmented Message type != GPR <Arg1>
AF Number: 147
Name: Send L4 Segment Indication
Description: Send to SEGMENT Indication to L4
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 148
Name: Test for last segment of Segmented message
Description: Tests for last segment of Segmented message.
Arg1: <Not Used>
Arg2: <Not Used>
Results: PPLevINTERNAL_EVENT_1 if last Segment
PPLevINTERNAL_EVENT_0 if not last Segment
AF Number: 149
Name: Clear LP3_CC IE buffers
Description: Sets LP3_CC IE buffer pointers to NULL
Arg1: <Not Used>
Arg2: <Not Used>
Index
1633
L3P B Channel Control (0x0007) Atomic Functions
Purpose
This section describes the atomic functions used by the L3 Call Reference PPL component.
L3P B Channel Control atomic functions
The following AFs are specific to the ISDN L3P B Channel Control PPL component. See Common Atomic Functions (2-1) for the AFs common to all PPL components.
AF Number: 51
Name: Send Enable B Channel to L3
Description: Enables a B channel to Layer 3 and forces the SERVICE of in-service to be sent to the distant end.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 52
Name: Send Disable B Channel to L3
Description: Enables a B channel to Layer 3 and forces the service of Out-of-Service to be sent to the distant end.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 53
Name: Send L3 B Channel Maintenance to L3
Description: Enables a B channel to Layer 3 and forces a service of maintenance to be sent to the distant end.
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 54
Name: Send CCSM Service State Event
Description: Forces an indication to Layer 4 and causes a DS0 Status Change message to be sent to the host.
Arg1: <Not Used>
Arg2: <Not Used>
MSP
1634
AF Number: 55
Name: Test to see if the B channel is on the D channel Facility
Description: Checks to see if the B channel for this PPL resides on the same span as any other D channel (primary or backup).
Arg1: <Not Used>
Arg2: <Not Used>
AF Number: 56
Name: Send Remove Call to L3P CR
Description: Clear all calls using this B channel. Remove Call is sent to L3P CR
Arg1: <Not Used>
Arg2: <Not Used>
Index
1635
L3 Call Reference (0x0008) Atomic Function
Purpose
This section describes the atomic functions used by the L3 Call Reference PPL component.
L3 Call Reference Atomic Function
The following Atomic Function supports congestion control functionality to the ISDN PRI card. See Common Atomic Functions for the AFs common to all PPL components.
AF Number: 131
Name: Determine congestion level
Description: Finds out the current congestion level
Arg1: N/A
Arg2: N/A
The following Atomic Functions support QSIG/PSS1 Basic Call Signaling functionality. See Common Atomic Functions for the AFs common to all PPL components.
AF Number: 140
Name: Get Segmentation Event from L3 DSM message
Description: Extracts event coded message from L3DSM and returns corresponding internal event
Arg1: <Not Used>
Arg2: <Not Used>
Results: PPLevINTERNAL_EVENT_0 and Segmentation Event from L3 DSM
AF Number: 141
Name: Send SEGMENT Indication to L3P
Description: Send SEGMENT_IND message to LP3
Arg1: Event (1:3)
Arg2: <Not Used>
AF Number: 142
Name: Send SEGMENT Request to L3DSM
Description: Send SEGMENT_REQ message to L3DSM
MSP
1636
Arg1: Event (1:3)
Arg2: <Not Used>
AF Number: 143
Name: Validate called party number IE
Description: Validates called party number IE
Arg1: <Not Used>
Arg2: <Not Used>
Results: PPLevINT_EVENT_1 if IE is valid
PPLevINT_EVENT_0 if IE is missing
PPLevINT_EVENT_2 if IE is invalid
AF Number: 144
Name: Validate call state IE
Description: Checks if the call state indicated in the IE matches the current state. Validation is done if the IE is present.
Arg1: <Not Used>
Arg2: <Not Used>
Results: PPLevINT_EVENT_1 if IE is valid
PPLevINT_EVENT_0 if IE is missing or call state is invalid
AF Number: 145
Name: Validate cause IE
Description: Validates cause IE. Validation is done if the IE is present.
Arg1: <Not Used>
Arg2: <Not Used>
Results: PPLevINT_EVENT_1 if IE is valid
PPLevINT_EVENT_0 if IE is missing
PPLevINT_EVENT_2 if IE is invalid
AF Number: 146
Name: Validate progress indicator IE
Description: Validates progress indicator IE. Validation is done if the IE is present.
Arg1: <Not Used>
Arg2: <Not Used>
Results: PPLevINT_EVENT_1 if IE is valid
Index
1637
PPLevINT_EVENT_0 if IE is missing
PPLevINT_EVENT_2 if IE is invalid
AF Number: 147
Name: Validate channel IE
Description: Validates channel IE. Validation is done if the IE is present.
Arg1: <Not Used>
Arg2: <Not Used>
Results: PPLevINT_EVENT_1 if IE is valid
PPLevINT_EVENT_0 if IE is missing
PPLevINT_EVENT_2 if IE is invalid
AF Number: 148
Name: Validate bearer capability IE
Description: Validates bearer capability IE. Validation is done if the IE is present.
Arg1: <Not Used>
Arg2: <Not Used>
Results: PPLevINT_EVENT_1 if IE is valid
PPLevINT_EVENT_0 if IE is missing
PPLevINT_EVENT_2 if IE is invalid
MSP
1638
L3 Global Call Reference (0x0009) Atomic Function
Purpose
This section describes the atomic functions and PPL events for the L3 Global Call Reference PPL component.
L3 Global Call Reference PPL Atomic Functions
The following Atomic Function in Layer 3 GCR PPL Component (0x0009) adds functionality to provide for ISDN Bearer Connection Independent Supplementary Services. See Common Atomic Functions for the AFs common to all PPL components.
Atomic Functions
AF Number: 88
Name: Setup Call Reference
Type: Normal
Description: Sets up the Layer 3 GCR call reference data structure using the call reference specified in the ICB.
Arg1: N/A
Arg2: N/A
Results of Atomic Function 88
AF Number 88
Name Normal
Type Normal /Blocking/Test
Description Normal /Blocking/Test
Arg1 Description
Input Range
Arg2 Description
Input Range
L3 Global Call Reference L3/L5 Events
The sending of the PPL events to the host is configurable with PPL Configuration Bytes 3–10. These events are only valid using the ISDN Raw IE type (0x11)
Index
1639
PPL Event Request (L5 to L3)
PPL Event Indication (L3 to L5)
0x0001 Facility 0x0001 Facility Indication
0x0002 Facility ACK 0x0002 Facility ACK Indication
0x0003 Facility Rej 0x0003 Facility REJ Indication
0x0004 Restart 0x0004 Restart
0x0005 Restart ACK 0x0005 Restart ACK
0x0006 Status 0x0006 Status
0x0007 Status Enq 0x0007 Status Enquiry
0x0008 User Info 0x0008 User Information
MSP
1640