Dialogic® SS7 Protocols
ISUP Programmer's Manual
www.dialogic.com
Copyright© 2003-2008 Dialogic Corporation. All Rights Reserved. You may not reproduce this document in whole or in part without
permission in writing from Dialogic Corporation at the address provided below.
All contents of this document are furnished for informational use only and are subject to change without notice and do not represent a
commitment on the part of Dialogi c Corporation or its subsidiaries (“Dialogic”). Reasonable effort is made to ensure the accuracy of the
information contained in the document. Howev er, Dialogic does not warrant the accuracy of this information and cannot accept
responsibility for errors, inaccuracies or omissions that may be cont ain ed in this document.
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED,
BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN
A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIAB ILITY WHATSOEVER, AND DIALOGIC DISCLAIMS
ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIAL OGIC PRODUCTS INCLUDING LIABILITY OR
WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL
PROPERTY RIGHT OF A THIRD PARTY.
Dialogic products are not intended for use in medical, life saving, life susta inin g, critical control or safety systems, or in nuclear facility
applications.
It is possible that the use or implementation of any one of the concepts, applications, or ideas described in this document, in marketing
collateral produced by or on web pages maintained by Dialogic may infringe one or more patents or other intellectua l property rights
owned by third parties. Dialogic does not provide any intellectual property licenses with the sale of Dialogic products other than a
license to use such product in accordance with intellectual property owned or validly licensed by Dialogic and no such licenses are
provided except pursuant to a signed agreement with Dialogic. More detailed information about such intellectual property is available
from Dialogic’s legal department at 9800 Cavendish Blvd., 5th Floor, Montreal, Quebec, Canada H4M 2V9.
Dialogic encourages all users of its products to procure all necessary intellectual property licenses required to implement
any concepts or applications and does not condone or encourage any intellectual property infringement and disclaims any
responsibility related thereto. These intellectual property licenses may differ from country to country and it is the
responsibility of those who develop the concepts or applications to be aware of and comply with different national license
requirements.
Dialogic, Dialogic Pro, Brooktrout, Ca ntata, SnowShore, Eicon, Eicon Networks, Eiconcard, Diva, SIPcontrol, Diva ISDN, TruFax,
Realblocs, Realcomm 100, NetAccess, Instant ISDN, TRXStream, Exnet, Exnet Connect, EXS, ExchangePlus VSE, Switchkit, N20,
Powering The Service-Ready Network, Vantage, Connecting People to Information, Connecting to Growth and Shiva, among others as
well as related logos, are either registered trademarks or trademarks of Dialogic. Dialogic's trademarks may be used publicly only with
permission from Dialogic. Such permission may only be granted by Dialogic’s legal department at 9800 Cavendish Blvd., 5th Floor,
Montreal, Quebec, Canada H4M 2V9. Any authorized use of Dialogic's trademarks will be subject to full respect of the trademark
guidelines published by Dialogic from time to time and any use of Dialogic’s trademarks requires proper acknowledgement.
The names of actual companies and products mentioned herein are the trademarks of their respective owners.
Publication Date:
Document Number: U04SSS, Issue 15
2
February 2008
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
Contents
Revision History............................................................................................................7
1 About this Publication .........................................................................................9
1.1 Introduction...........................................................................................................................9
1.2 Abbreviations......................................................................................................................... 9
1.3 Related Documentation ......................................................................................................... 10
1.4 Feature Overview ................................................................................................................. 11
2 General Description...........................................................................................13
2.1 Module Overview..................................................................................................................13
2.2 Module Configuration ............................................................................................................ 13
2.2.1 Customizing ISUP variants......................................................................................... 14
3 Internal Data Structures ...................................................................................17
3.1 Introduction......................................................................................................................... 17
3.2 Global Ram Data Structure .................................................................................................... 17
3.3 Circuit Group Data Structure.................................................................................................. 17
3.4 Per Circuit Data Structure...................................................................................................... 17
4 Interface to System Services.............................................................................19
4.1 System Functions ................................................................................................................. 19
4.2 Timer Operation ................................................................................................................... 19
5 Interface to MTP................................................................................................21
6 Interface to Application.....................................................................................23
6.1 Introduction......................................................................................................................... 23
6.2 Application Message - Header Format...................................................................................... 23
6.2.1 Transmit Request ..................................................................................................... 23
6.2.2 Receive Indication .................................................................................................... 24
6.3 Application Message - User Data Format .................................................................................. 25
6.4 Parameter Extension Mechanism ............................................................................................ 26
6.5 Application Messages to ISUP................................................................................................. 26
6.5.1 Alerting Request....................................................................................................... 28
6.5.2 Application Transport Request.................................................................................... 30
6.5.3 ‘Generic’ Charge Request .......................................................................................... 31
6.5.4 Circuit Seized Request .............................................................................................. 31
6.5.5 Collection Charging Request ...................................................................................... 32
6.5.6 Confusion Request.................................................................................................... 32
6.5.7 Continuity Request ................................................................................................... 32
6.5.8 End-to-End Message Request..................................................................................... 33
6.5.9 Exit Request .......................................................................................................... 33
6.5.10 Facility Request........................................................................................................ 33
6.5.11 Facility Response...................................................................................................... 35
6.5.12 Forward Transfer Request.......................................................................................... 36
6.5.13 Identification Request ............................................................................................... 36
6.5.14 Identification Response ............................................................................................. 36
6.5.15 Information Request................................................................................................. 37
6.5.16 Loop Back Acknowledgement Request......................................................................... 38
6.5.17 Loop Prevention Request........................................................................................... 39
6.5.18 Network Resource Management Request ..................................................................... 39
6.5.19 Overload Request..................................................................................................... 40
6.5.20 Pre-Release Information Request ............................................................................... 40
3
Contents
6.5.21 Proceeding request ...................................................................................................41
6.5.22 Progress Request...................................................................................................... 42
6.5.23 Release Response..................................................................................................... 43
6.5.24 Release Request....................................................................................................... 44
6.5.25 Request Information Request .....................................................................................45
6.5.26 Resume Request....................................................................................................... 45
6.5.27 Segmentation Request ..............................................................................................46
6.5.28 Setup Request..........................................................................................................46
6.5.29 Setup Response .......................................................................................................49
6.5.30 Subsequent Directory Number Request ....................................................................... 52
6.5.31 Suspend Request...................................................................................................... 52
6.5.32 Unrecognised Message Request.................................................................................. 53
6.5.33 User Information Request.......................................................................................... 53
6.6 Application Messages from ISUP ............................................................................................. 54
6.6.1 Alerting Indication .................................................................................................... 56
6.6.2 Application Transport Indication ................................................................................. 59
6.6.3 ‘Generic’ Charge Indication ........................................................................................59
6.6.4 Circuit Seized Indication............................................................................................60
6.6.5 Collection Charging Indication....................................................................................60
6.6.6 Confusion Indication ................................................................................................. 60
6.6.7 Continuity Indication.................................................................................................61
6.6.8 End-to-End Message Indication ..................................................................................61
6.6.9 Exit Indication..........................................................................................................61
6.6.10 Facility Indication ..................................................................................................... 62
6.6.11 Facility Confirmation ................................................................................................. 63
6.6.12 Forward Transfer Indication .......................................................................................64
6.6.13 Identification Indication............................................................................................. 64
6.6.14 Identification Confirmation.........................................................................................65
6.6.15 Information Indication............................................................................................... 65
6.6.16 Loop Back Acknowledgement Indication ...................................................................... 66
6.6.17 Loop Prevention Indication.........................................................................................67
6.6.18 Network Resource Management Indication................................................................... 67
6.6.19 Overload Indication...................................................................................................68
6.6.20 Pre-Release Information Indication .............................................................................68
6.6.21 Proceeding Indication................................................................................................ 69
6.6.22 Progress Indication................................................................................................... 70
6.6.23 Release Confirmation ................................................................................................ 71
6.6.24 Release Indication .................................................................................................... 71
6.6.25 Request Information Indication .................................................................................. 72
6.6.26 Resume Indication....................................................................................................73
6.6.27 Segmentation Indication............................................................................................ 73
6.6.28 Setup Confirmation...................................................................................................74
6.6.29 Setup Indication.......................................................................................................76
6.6.30 Subsequent Directory Number Indication.....................................................................78
6.6.31 Suspend Indication ...................................................................................................79
6.6.32 Unrecognised Message Indication ............................................................................... 79
6.6.33 User Information Indication ....................................................................................... 79
6.7 Parameter Definitions............................................................................................................ 80
6.7.1 Called Party Number .................................................................................................86
6.7.2 Calling Party Number ................................................................................................86
6.7.3 Cause Indicators.......................................................................................................87
6.7.4 Custom Parameter....................................................................................................88
6.7.5 Message Data ..........................................................................................................88
6.7.6 Number of Metering Pulses ........................................................................................89
6.7.7 Tariff Type ..........................................................................................................89
6.7.8 Unrecognised Parameter............................................................................................90
6.8 Use of Call Control Primitives..................................................................................................90
6.8.1 Call Clearing Procedure .............................................................................................90
6.8.2 Call Collision Procedure ............................................................................................. 91
6.8.3 Hop Counter Procedure ............................................................................................. 94
6.8.4 Continuity Testing..................................................................................................... 95
6.8.5 Malicious Call Identification (MCID) Supplementary Service ......................................... 108
4
DialogicTP®TP SS7 Protocols ISUP Programmer's Manual Issue 15
6.8.6 Message Segmentation ........................................................................................... 109
6.8.7 Automatic Circuit Group Blocking ............................................................................. 109
6.8.8 BICC Application Transport...................................................................................... 111
7 Management Interface ....................................................................................113
7.1 Introduction....................................................................................................................... 113
7.2 Circuit Group Supervision Control Request............................................................................. 114
7.3 Circuit Group Supervision Control Confirmation ...................................................................... 115
7.4 Circuit Group Supervision Control Indication .......................................................................... 116
7.5 Circuit Group Supervision Status Indication............................................................................ 117
7.6 Local Overload Request ....................................................................................................... 118
7.7 Remote Point Code Status Indication..................................................................................... 119
8 Non-Primitive Interface...................................................................................121
8.1 Configure Request .............................................................................................................. 121
8.2 Configure Circuit Group Request........................................................................................... 126
8.3 Configure Timers Request.................................................................................................... 136
8.3.1 Timer default values ............................................................................................... 138
8.4 End Circuit Group Request ................................................................................................... 140
8.5 Variant Initialisation............................................................................................................ 141
8.6 Custom Parameter Configuration .......................................................................................... 142
8.7 Change Circuit Group Configuration Request .......................................................................... 143
8.8 Read RAM Request.............................................................................................................. 145
8.9 Read Circuit Group Request ................................................................................................. 145
8.10 Read Circuit Request........................................................................................................... 146
8.11 Read Revision Request ........................................................................................................ 146
8.12 Read Circuit Group Status Request ....................................................................................... 147
8.13 Read Circuit Group Data Request.......................................................................................... 150
8.14 Read Circuit Group Identity Request ..................................................................................... 151
8.15 Send Maintenance Event Mask Request ................................................................................. 152
8.16 Send Software Event Mask Request ...................................................................................... 153
8.17 Trace Mask Configuration Request ........................................................................................ 154
8.18 Send Selective Trace Event Mask Request.............................................................................. 157
8.19 Maintenance Event Indication............................................................................................... 158
8.20 Software Event Indication.................................................................................................... 162
8.21 Management Event Indication .............................................................................................. 165
8.22 Trace Event Indication......................................................................................................... 166
8.23 Selective Trace Event Indication ........................................................................................... 167
8.24 Heartbeat Request/Indication............................................................................................... 169
Appendix A: ISUP National Variants .........................................................................171
A.1 German ISUP..................................................................................................................... 171
A.2 UK ISUP ............................................................................................................................ 172
A.3 Japan (TTC) ISUP ............................................................................................................... 173
A.4 Nortel RLT ......................................................................................................................... 174
A.4.1 Nortel RLT (ANSI)................................................................................................... 174
A.4.2 Nortel RLT (ITU)..................................................................................................... 175
A.5 Italian ISUP ....................................................................................................................... 176
A.6 French ISUP....................................................................................................................... 177
A.7 China ISUP ........................................................................................................................ 178
A.8 Finnish ISUP ...................................................................................................................... 180
A.9 BICC................................................................................................................................. 180
Appendix B: Messages Currently Supported by the ISUP Module..............................183
B.1 ITU-T Messages.................................................................................................................. 183
B.2 ITU-T Parameters............................................................................................................... 184
B.3 ANSI T1.113 Messages........................................................................................................ 188
B.4 ANSI T1.113 Parameters ..................................................................................................... 189
5
Contents
Appendix C: Message Type Table..............................................................................191
Appendix D: ISUP Configuration Option Settings......................................................193
Appendix E: ISUP Repeat Parameters.......................................................................197
Appendix F: Timer Services ......................................................................................199
F.1 Keep Time ......................................................................................................................... 199
F.1 Timer Expiry ...................................................................................................................... 200
Index .............................................................................................................201
Figures
Figure 1. Notation used for Parameter Specifications ................................................................. 85
Figure 2. Format of the Called Party Number Parameter.............................................................86
Figure 3. Format of the Calling Party Number Parameter............................................................ 86
Figure 4. Format of the Cause Indicators Parameter ..................................................................87
Figure 5. Format of the Custom Parameter...............................................................................88
Figure 6. Format of the Message Data Parameter ......................................................................88
Figure 7. Format of the Number of Metering Pulses Parameter.................................................... 89
Figure 8. Format of the Tariff Parameter .................................................................................. 89
Figure 9. Format of the Unrecognised Parameter.......................................................................90
Figure 10. Example of an External Call Collision where this End of the Circuit is Master....................92
Figure 11. Example of an External Call Collision where this end of the Circuit is Slave...................... 93
Figure 12. Example of an Internal Call Collision .......................................................................... 93
Figure 13. Example of a Successful Continuity Check Request Message Received............................96
Figure 14. Example of a Continuity Check Request Message Received (Unsuccessful Continuity Check
followed by Successful Continuity Check).................................................................... 97
Figure 15. Example of a Successful Continuity Check Received During Incoming Call Set Up ............98
Figure 16. Example of an Unsuccessful Continuity Check Received During Incoming Call Set Up .......99
Figure 17. Example of a Continuity Check Request Message Received (ANSI)...............................100
Figure 18. Example of a T36 Expiry......................................................................................... 101
Figure 19. Example of a Successful Continuity Check Request Message Sent ................................ 103
Figure 20. Example of a Continuity Check Request Message Sent (Unsuccessful Continuity Check
Followed By Successful Continuity Check) ................................................................. 104
Figure 21. Example of a Continuity Check Success Outgoing Call Set Up...................................... 105
Figure 22. Example of a Continuity Check Success during Outgoing Call Set Up............................ 106
Figure 23. Example of a Call collision where the Incoming Call has Priority ................................... 107
Figure 24. Example of a Reset Circuit Received During a Continuity Test Call................................ 108
Tables
Table 1. All Application Messages sent by the ISUP Module to the User Application....................... 54
Table 2. Release Cause Values used in the Release indication sent to the Application when Cal l
Processing Timers Expire ..........................................................................................87
Table 3. ISUP Module Confirmation Message Statuses............................................................. 113
6
DialogicTP®TP SS7 Protocols ISUP Programmer's Manual Issue 15
Revision History
Issue Date Description
15 February 2008 Minor alterations to sections 6.5.30 and 6.6.30.
14 January 2008 Rebranded and reformatted, plus minor changes and updates.
13 June 2006 Support for Bearer Independent Call Control (BICC) added.
New messages added: Change Circuit Group Configuration Request, Read Circuit
Group Data Request and Read Circuit Group Identity Request.
Options ISPF_24PC, ISPF_PC_SIZE and ISPX1GOP_16PC updated.
New module option, ISPF_16CID, added in ISP_MSG_CONFIG to maintain backward
compatibility and support 64k configurations.
Support for tracing of Configuration Request and Heartbeat request messages.
Support for location value in Release cause.
12 July 2003 Branding changed: references to System7 removed. Support for French ISUP, China
11 August 2001 Support for user custom optional parameter.
10 December 1999 Continuity check and circuit seized added.
9 July 1998 Point code length, SIO value, UCIC option and timer values may now be configured on
ISUP, and Finnish ISUP added.
MPM added.
Redirecting parameter now supported in TTC IAM.
Support for MCID supplementary service.
APM and PRI message definitions corrected.
Support for ITU-T 1997.
New software event (15).
New group options for the user part unavailability procedure and selective tracing
added.
New parameter in Configure Circuit Group Request message for hop counter
procedure added.
New timer T4 and T38 added.
New maintenance events for the hop counter procedure and the user part
unavailability procedure added.
New Selective trace event request mask and Selective trace event indication
messages.
Generic CRG message now supported.
Appendix E added.
Editorial changes.
Enhanced remote point code status indication.
Additional circuit states report added in read circuit group status.
New software event added.
ISUP configuration option settings added.
Table of messages added.
Minor editorial changes.
a circuit group basis, allowing both ITU and ANSI circuit groups to be supported at the
same time.
Added new circuit group option to remove ST digit from end of Called party number
sent to network and another circuit group option to add ST digit to end of Called party
number sent to user.
User teleservice information and Freephone indicators parameters are now supported.
Generic number supported in Release message.
Message tracing now supported
New maintenance events added to report invalid group messages received.
7
Revision History
Issue Date Description
8 May 1997 A circuit group may now be ended without having to restart the module. This allows
7 September 1996 Now supports ITU-T 1992 messages and parameters (whilst allowing Blue Book only
6 May 1996 Now supports ANSI operation as a run-time configuration option.
5 April 1996 Call clearing mechanism modified to require a response from the application in all
4 April 1996 Backward call indicators in ANM sent to ISUP module are now optional and if omitted
3 August 1995 New messages added: ISP_MSG_STATUS_IND, ISP_MSG_OVLD_REQ,
2 February 1994
1 September 1993
the application to dynamically configure and end individual circuit groups as required.
The local status of a circuit may now be read. New primitives have been added to
allow enabling and disabling of all maintenance and software events.
New support for Temporary Trunk Blocking procedures (Overload_ind added) and
Charging procedures (Charge_req and Charge_ind added).
New circuit group option for Q.767 formatting of cause parameter.
operation using a run-time configuration option.
Table of supported parameters added.
Optional support for T34 (segmentation), pass-along messages, and message and
parameter compatibility handling added.
New module option to allow reporting of errors in application messages sent to ISUP.
Circuit group configuration message parameter definitions changed to allow the
optional use of 24bit point codes.
cases and to require the application to wait for a Release confirmation from the ISUP
module before commencing a new call.
Use of the most significant bit of the call reference to indicate an outgoing call
removed.
Ability to configure and re-configure all protocol timer values at run-time added.
Additional optional parameters added: Redirection information, Redirection number,
Redirecting Number and Signalling point code.
Optional support for UCIC message and timer T35 added.
Read call request message removed.
This revision of the manual describes the operation of the ISUP protocol module with a
core revision number of V2.00 and later.
ISUP will not insert any default.
Original called number and User service information parameters added to setup
request and setup indication.
Forward transfer message and Call offering message (Italian network only) added.
Support for dual instance of ISUP (ISPF_DUAL) added.
Per-circuit group adjacent module_id’s and instance numbers added to circuit-group
configuration message.
ISP_MSG_CGSS_IND.
Parameters added to user primitives: access transport, user to user information, user
to user indicators
New user primitive types added: Facility_req, Facility_resp, Facility_ind, Facility_conf,
User_info_req, User_info_ind
Circuit group query added to circuit group supervision control request.
Additional circuit group options defined
Note: The latest release issue of this guide can be found at:
http://www.dialogic.com/support/helpweb/signaling
8
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
About this Publication
1.1 Introduction
The ISUP module is a software implementation of the Signalling System
Number 7, ISDN User Part (ISUP). In addition to supporting major ISUP
variants such as ITU-T recommendations Q.761-Q.764, Q.767, ETSI standard
ETS 300 356-1, and ANSI T1.113 the ISUP module supports national variants
including German ISUP and Japanese TTC ISUP. It is also possible for the
user to customize existing variants by adding or deleting parameters. The
ISUP module supports, as a purchasable option, the BICC (Bearer
Independent Call Control) protocol which is treated as a variant in its own
right.
This document is the Programmer's Manual for the ISUP module. It is
intended for use by users developing their own application programs that will
interface with and use the functionality provided by the ISUP module.
The module uses the services provided by the Message Transfer Part (MTP) to
exchange signaling messages with remote signaling points. It supports a
number of both-way telephony circuits. The circuits can be divided into a
number of circuit groups; each group may be assigned different attributes
allowing the user considerable flexibility in the configuration of the module.
The ISUP module is event driven and uses standard structured messages for
inter-process communication. It is intended to be used in conjunction with
the MTP module either on hardware platforms or on user supplied hardware.
However, the software is portable and the well-defined message structure
and the independent nature of the module allows ISUP to be used with
alternative MTP implementations if required.
This manual gives an overview of the internal operation of the ISUP module
and defines the structure of all messages that can be sent to, or issued by,
the module. It also describes all the configuration parameters.
on page 183 lists the ITU-T ISUP and the ANSI T1.113 ISUP messages and
parameters that are currently supported by the module.
Appendix B
1.2 Abbreviations
ANSI American National Standards Institute
BICC Bearer Independent Call Control
CIC Circuit Identification Code
DPC Destination Point Code
ISDN Integrated Services Digital Network
ISUP ISDN User Part
ITU International Telecommunication Union
MTP Message Transfer Part
OPC Originating Point Code
SS7 Signalling System Number 7
9
Section 1 About this Publication
1.3 Related Documentation
[1] ITU-T recommendation Q.730, ISDN Supplementary services
[2] ITU-T recommendation Q.761, Signalling System No.7 ISDN User
10
part functional description
[3]
[4] ITU-T recommendation Q.763 Signalling System No.7 ISDN User part
[5]
[6] ITU-T recommendation Q.765 (2000), Signalling System No. 7 –
[7] ITU-T recommendation Q.767, Application of the ISDN user part of
[8]
[9] ANSI recommendation T1.113, Signalling System No.7 Integrated
[10]
[11] German ISUP Specification: Zeichengabe im ZZN7 Version 3.0.0
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20] Finnish ISUP Specification: SFS 5779 Signalling in the public switched
[21]
[22]
ITU-T recommendation Q.762, Signalling System No.7 ISDN User
part general functions of messages and signals
format and codes
ITU-T recommendation Q.764, Signalling System No.7 ISDN User
part signalling procedures
Application transport mechanism
CCITT signalling system No. 7 for international ISDN interconnections
ETSI standard 300 356-1, Integrated Services Digital Network
(ISDN); Signalling System No.7
Services Digital Network (ISDN) User Part
UK ISUP Specification: PNO-ISC Specification Number 007 ISDN User
Part (ISUP)
ITU-T recommendation Q.850, Usage of cause and location in the
Digital Subscriber Signalling System No.1 and the Signalling System
No.7 ISDN User Part
Italian ISUP Specification: Specifica Tecnica N.763
Nortel RLT (ANSI) Specification: Digital Switching Systems UCS DMS-
250 SS7 RLT Feature Application Guide UCS12 297-2621-345
Preliminary 04.01 August 1999
Nortel RLT (ITU) Specification: 411- 2131-199 Standard 08.04
August 1998 Wireless Networks DMS-MTX Software Delta for Planners
MTX07
Japan (TTC) ISUP Specification: JT-Q761-JT-Q764 and JT-Q850
U10SSS, Software Environment Programmer's Manual
French ISUP Specification: SPIROU 1998 – 002-005 edition 1
China ISUP Specification: YDN 038 (1997)
telephone network (PSTN). ISDN User Part ISUP Version 2 of the
national Signalling System No. 7. Application of ITU-T
recommendations Q.761. Q.764 and Q.766 in Finland (1994)
ITU-T Recommendation Q.1901, Bearer Independent Call Control
Protocol
ITU-T Recommendation Q.1902.1, Bearer Independent Call Control
protocol (Capability Set 2): Functional description
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
[23] ITU-T Recommendation Q.1902.2 (2001), Bearer independent Call
Control protocol (CS-2) and Signalling System No. 7 – ISDN User Part
general functions of messages and parameters
[24] ITU-T Q. Recommendation 1902.3 (2001), Bearer i n dependent call
control protocol (CS-2) and signalling system No. 7 – ISDN user part
formats and codes
[25] ITU-T Recommendation Q.1902.4 (2001), Bearer independent call
control protocol (CS-2) basic call procedures
[26]
[27]
ITU-T Recommendation Q.1902.5 (2001), Exception
ITU-T Q.765.5 (2000), Signalling System No. 7 – Application
transport mechanism: Bearer Independent Call Control (2000)
1.4 Feature Overview
Key features of the ISUP module include:
• Software implementation of ITU-T recommendation Q.761-Q.764 (1997).
• Software implementation of ITU-T recommendation Q.767 (1992).
• Software implementation of ETSI standard ETS 300 356-1 (1995).
• Software implementation of ANSI T1.113-1995.
• Software implementation of ITU-T recommendation Q.1901, Q1902.1-
Q.1902.5 (2001).
• Message oriented interface.
• Configuration options on a per-circuit group basis.
• User configuration of all protocol timers.
• Support for both en-bloc and overlap address signaling.
• Support for Suspend and Resume.
• Full user control of Circuit Supervisory functions - Reset, Blocking,
Unblocking and Query.
• Support for circuit group as well as individual circuit supervision
messages.
• Support for supplementary services.
• Built-in generation of Automatic congestion control parameter.
• Ability to add or delete optional parameters to define a custom ISUP
variant.
• Debug tracing of messages exchanged with the user and MTP.
• Ability to send and receive CRG messages for ITU based variants.
11
Section 1 About this Publication
12
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
2 General Description
2.1 Module Overview
The ISUP module implements full ISDN User Part functionality. This includes
Call Processing Control (CPC), Circuit Supervision Control (CSC) and
Signalling Procedure Control (SPRC) all of which are fully supported. In
addition, the module implements some Call Control functionality to provide a
clean interface with the user that is defined entirely in terms of ISUP
messages.
Each circuit is identified internally by a Circuit Identifier (cid). Circuit
Identifiers range from zero up to one less than the total number of circuits. A
circuit must be assigned to a circuit group before it can be used.
Circuit groups allow a number of circuits to be configured with common
attributes. They are identified by the group identifier (gid) which ranges from
zero to one less than the total number of circuit groups. Each circuit group
must be assigned an Originating Point Code (OPC) and a Destination Point
Code (DPC), the Circuit Identification Code (CIC) of the first circuit in the
group and the Circuit Identifier (cid) that will be used for this circuit. Further
circuits may be included in the group providing that the CIC of the last circuit
is no more than 31 greater than the first CIC. The circuits do not need to lie
in a contiguous block. The Circuit Identifier cid for each additional circuit will
have the same offset from the first cid as the CIC has from the first CIC.
Each circuit group also has a number of options such as Outgoing/Incoming
Call Priority selection and whether the module is the controlling exchange for
certain timers and features.
All protocol primitives between the application and the ISUP module use a
Call Reference (call_ref) to identify the circuit used for the call. The call
reference is identical to the Circuit Identifier (cid) with the exception that for
messages issued by the ISUP module relating to outgoing calls the most
significant bit of the call_ref is set to one when the ISUP module is configured
for 32768 circuits or less, and the ISPF_16CID flag is set to 0. In all other
cases (more than 32768 circuits configured, or ISPF_16CID flag set to 1), the
cid is identical to the call_reference. The ISUP module now ignores the setting
of the most significant bit of the call_ref and it is recommended that existing
applications which placed significance on this bit be modified to ignore it also.
2.2 Module Configuration
The module is configured for operation by the user in three stages. Initially,
a global configuration message must be sent to the module to configure
environment dependent parameters (in general these parameters will be
fixed for any single application).
Then, an optional message to set the values of protocol timers is issued.
Finally, a configuration message is required for each circuit group before
attempting to originate or accept calls.
The variant of ISUP (e.g. ITU-T, ANSI, national variants or BICC) to be used
for circuits in a group is specified by a configuration parameter in the circuit
group configuration message.
13
Section 2 General Description
Depending on the platform that ISUP is running, some or all of these
configuration messages may be generated based on text based configuration
files (config.txt). In such cases the user does not need to generate the
individual configuration messages. Refer to the product documentation for the
specific product for further information.
2.2.1 Customizing ISUP variants
The ISUP module supports a variant-based mechanism that enables the user
to select a custom-reserved variant thus permitting the ISUP module to send
and receive proprietary parameters (in supported ISUP messages only) to
and from the network. The following messages are required for this
mechanism:
• Variant Initialisation message (0x5712)
• Custom Parameter Configuration message (0x5713)
Refer to
details.
The variant-based mechanism may be initialized as follows:
1. Configure the ISUP module using the Configure Request message
2. Two ‘custom’ variant values are specifically reserved for this procedure
Section 8.6 on page 142 and Section 8.7 on page 143 for further
(0x7700) as described in
Section : 2.2 Module Configuration on page 13.
as shown in the following table (refer to the <variant> parameter in
Section : 8.2 Configure Circuit Group Request on pa ge 126):
Value Mnemonic Meaning
0xfd ISPGVAR_CUST02 Custom variant CUST02
0xfe ISPGVAR_CUST01 Custom variant CUST01
Configure a circuit group and select one of the available custom variant
values using the Configure Circuit Group Request message (0x7701).
The Configure Circuit Group Request message may be sent at any stage
after the ISUP module has been configured; it is not necessary to wait
until after the custom variant and parameters have been configured.
3. Initialize a custom variant using the Variant Initialisation message
(0x5712) and specify the ISUP variant e.g. ISPGVAR_ITU92 upon which
the custom variant is based. The Variant Initialisation message may be
sent at any stage after the ISUP module has been configured but it must
be sent before the Custom Parameter Configuration message (described
in the next step).
4. Configure the custom parameter using the Custom Parameter
Configuration message (0x5713). The Custom Parameter Configuration
message may be sent at any stage after the ISUP module has been
configured but it must be sent before the sending and receiving of any
customized parameters.
14
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
The Custom Parameter Configuration message should be sent when a
proprietary parameter is to be added to, or removed from, an existing ISUP
message. A separate Custom Parameter Configuration message is required
and must be sent for each ISUP message to which the proprietary parameter
is to be added, or from which it is to be omitted.
15
Section 2 General Description
16
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
3 Internal Data Structures
3.1 Introduction
This chapter describes the internal data structures that are used by the ISUP
module to assist the user in understanding the operation of the module. It is
not necessary to acquire detailed knowledge of these structures in order to
use the module.
3.2 Global Ram Data Structure
The entire data storage used by the module is contained in a single structure.
This structure contains global configuration settings, per circuit storage,
circuit group configuration data, and per-call storage all relating to operation
of the ISUP protocol. It also contains internal event queues, timer control
structures and internal buffers for message processing.
3.3 Circuit Group Data Structure
Each circuit group has a data structure within the global ram structure that
contains the user supplied configuration parameters for the circuit group (e.g.
Signaling Point Codes, Circuit Identification and Configuration Options). The
information in the circuit group data structure applies to all circuits in the
circuit group.
3.4 Per Circuit Data Structure
Each circuit has a data structure within the global ram structure that is used
to store the current state of state machines associated with the circuit and
any current call details.
17
Section 3 Internal Data Structures
18
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
4 Interface to System Services
4.1 System Functions
In addition to the primitive interfaces and the management interface to the
ISUP module (which are described in later sections) the module requires a
few basic system services to be supplied by the underlying operating system.
In most cases, this is achieved by the use of the appropriate Development
package.
The following functions are used for inter-task communication:
GCT_send Send a message to another task.
GCT_receive Receive the next message from the module’s input queue, blocking the task if
GCT_grab As GCT_receive, but no blocking if no message is ready.
The following functions are required for message allocations for inter-task
communication:
getm Allocate a message from the system.
relm Release a message back to the system.
no message is ready.
4.2 Timer Operation
In order to provide internal implementation of the ISUP protocol timers the
module needs to receive a periodic timer tick message. This is generated
either by the on-board timer module or the tick and tim binaries supplied as
part of the development package.
The following action request message is issued by the ISUP module:
KEEP_TIME Issued by ISUP to initialize timer services.
The ISUP module expects the following notification on a periodic basis from
the timer module:
TM_EXP Issued by the timer module to notify of periodic timer tick.
The format of these messages is described in Appendix F: Timer Services on
page 199
.
19
Section 4 Interface to System Services
20
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
5 Interface to MTP
The ISUP module interfaces with the Message Transfer Part (MTP) using the
following primitives, all of which are defined in ITU-T Recommendation
Q.704.
MTP-TRANSFER-REQ Transmit message to MTP
MTP-TRANSFER-IND Receive message from MTP
MTP-PAUSE Remote point code unavailable indication from MTP
MTP-RESUME Remote point code available indication from MTP
MTP-STATUS Signaling point congested or Remote user unavailable indication
from MTP
The message format used to convey these primitives is defined in the MTP3
Programmer's Manual.
The ISUP module is usually used in conjunction with the MTP module.
However, the use of primitives in accordance with Q.704 ensures that it can
also be integrated with other MTP implementations if required.
To provide further flexibility the ISUP module supports the use of both
T_FRAMEs and R_FRAMEs or the use of MSGs for MTP-TRANSFERs between
the ISUP and MTP.
T_FRAMES and R_FRAMES are most useful when the ISUP module is running
on the same processor as MTP, whilst MSGs are generally used when the
ISUP module is running on a different processor than the one used for the
MTP, or in conjunction with an MTP other than the Dialogic
A module configuration option (ISPF_TFRM) allows the user to select between
sending T_FRAMEs or sending MSGs. Receipt of both R_FRAMEs and MSGs is
supported in either mode.
®
SS7 Protocols.
21
Section 5 Interface to MTP
22
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6 Interface to Application
6.1 Introduction
All primitives at the application interface (i.e. between the ISUP module and
the user) are passed by sending messages between the modules. Each
message is of type MSG as defined in the Software Environment
Programmer’s Manual.
The basic structure of each message (irrespective of the message type) is the
same. The message contains a message header, the length of the user data
and the user data. The message must be contained in a single buffer that
should be allocated by the sending module (using the getm function) and
either released (using the relm function) or passed to another module by the
receiving module. The getm and relm functions are described in
Interface to System Services on page 19.
The first sub-section of this chapter describes the format of the message
header associated with each type of message and the next section describes
the format of the user data contained within the message.
6.2 Application Message - Header Format
Two primitive message types are sent between the application and the ISUP
module:
Section : 4
Transmit Request Message from application to ISUP
Receive Indication Message from ISUP to application.
The message structure and parameters for each primitive are defined in the
following paragraphs:
6.2.1 Transmit Request
This primitive is used by the application to send a message to the ISUP
module.
Primitive Request to ISUP
Field Name Meaning
type ISP_MSG_TX_REQ (0xc700)
id call_ref
src Application module ID
dst ISUP module ID
rsp_req 0x00
hclass 0x00
status 0x00
err_info 0x00
len Number of bytes of user data
parameters User data (Len bytes in length)
23
Section 6 Interface to Application
call_ref is used to identify the circuit or call to which the message refers.
Currently, when 32768 circuits or less are configured, the most significant bit
of the
call_ref is ignored by the ISUP module, and the remaining bits map
directly to the Circuit Identifier
cid so the valid range for call_ref is from 0 to
one less than the number of circuits supported. If more than 32768 circuits
are configured, then the call_ref is identical to the cid.
Note: Earlier revisions of the ISUP module required the most significant bit of the
call_ref to be set in all messages relating to outgoing calls.
6.2.2 Receive Indication
This primitive is used by the ISUP module to send a message to the
application module.
Primitive Indication From ISUP
Field Name Meaning
type ISP_MSG_RX_IND (0x8701)
id call_ref
src ISUP module ID
dst Application module ID
rsp_req 0x00
hclass 0x00
status 0x00
err_info 0x00
len Number of bytes of user data
parameters User data (Len bytes in length)
24
call_ref is used to identify the circuit or call to which the message refers.
Currently, when 32768 circuits or less are configured and the ISPF_16CID
flag is set to 0, the most significant bit of the
call_ref is set to 1 by the ISUP
module for all messages relating to outgoing calls and the remaining bits map
directly to the Circuit Identifier
cid. If 32768 circuits or less are configured
and the ISPF_16CID flag is set to 1, or if more than 32768 circuits are
configured, then the call_ref is identical to the cid.
Note: Earlier revisions of the ISUP module required the most significant bit of the
call_ref to be set in all messages relating to outgoing calls. To allow for
interworking with earlier application software which make use of this bit the ISUP
module continues to set the bit in all messages relating to outgoing calls for
configurations with 32768 circuits or less, when the ISPF_16CID flag has been set
to 0. It is recommended that existing applications be modified to ignore the
setting of the most significant bit.
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.3 Application Message - User Data Format
The format of user data in transmit request and receive indication messages
between the Application and the ISUP module is based on the ISUP message
format specified in Q.763.
The first byte of the data is the ISUP message type. The message type
values are specified in Table 4/Q.763 and the last byte of the data is zero to
indicate that there are no further parameters contained within the message.
Any parameters associated with the message are placed between the
message type byte and the last byte of the data. The parameter area is
therefore formatted as follows:
ISUP
Message Type
The parameters may be placed in any order. The first byte of a parameter is
the parameter name (based on Table 5/Q.763 but specified in Section 9 of
this programmer’s manual), the second byte is the length of parameter data
to follow (excluding the parameter name and the length byte itself), this is
followed by the parameter data which is formatted (based on Q.763) as
defined in section 9. Each parameter is therefore formatted as follows:
ISUP
Message Type
Parameter
Name
1 byte 1 byte ‘Length’ bytes (1 to 255)
Parameter Parameter Parameter Zero
Parameter Parameter Parameter
Parameter
Length
Parameter
Data
Zero
Note: Unlike the message format specified in Q.763, there are no 'fixed' or 'variable'
parameters where the parameter name or type are implied by their position in the
message. Instead all parameters contain parameter name, parameter length and
parameter data.
Within each message, there are Mandatory parameters, which must always
be present and Optional parameters, which may or may not be present.
Many of the optional values have default values, which are added by the ISUP
module if not provided by the user as described in the parameter
specification.
All supported application messages are listed in
Section 6.5 on page 26 and
Section 6.6 on page 54. All applicable parameters for each message are
listed in the following sub-sections (refer also to Appendix A: ISUP National
Variants
on page 171) and a list of all supported parameters are provided in
Section : 6.7 Parameter Definitions on page 80.
25
Section 6 Interface to Application
6.4 Parameter Extension Mechanism
The CCPN_parameter type value 128 (0x80) is used as an extension
parameter indicator. The parameter extension mechanism is used for all
parameter types whose decimal value is greater than 255 at the common
control interface. If a parameter value of 128 (0x80) is contained within a
message for sending to or received from the user, the actual parameter type
value (minus 256) is contained in the third byte which is subsequently
followed by the length of the parameter and its data as shown below:
Name Length Data
0x80 Parameter
Length + 2
1 byte 1 byte 1 byte 1 byte ‘Length’ bytes (1 to 253)
Parameter
Name - 256
Parameter
Length
6.5 Application Messages to ISUP
The following table lists all application messages (message type
ISP_MSG_TX_REQ) sent to ISUP module by the user application:
Parameter Data
26
type
Alerting request ACM
CPG
Application transport
request
Charge request
(Generic)
Circuit seized request SZE 199 0xc7 Used to initiate a continuity test call
Confusion request CFN 47 0x2f Requests that a confusion message is
Continuity request COT 5 0x05 Indicates whether the continuity test
Collection charging
request
End-to-end message
request
Facility request FAR
Forward transfer
request
Information request SAM 2 0x02 Subsequent address digits for overlap
APM 65 0x41 To issue an application transport
CRG 49 0x31 Carries charging information.
MPM 201 0xc9 Used to carry charging information.
PAM 40 0x28 Requests that an end-to-end message
FAC
FAA 32 0x20 Used to accept or reject a facility . Facility response
FRJ 33 0x21 Previously requested with a facility
FOT 8 0x08 Send forward transfer to the network.
Value Primitive Message
Dec Hex
6
0x06
44
0x2c
31
0x1f
51
0x33
Indicates incoming called party being
alerted.
message.
and indicates that a circuit has been
seized for an outgoing call (but no
address information has yet been
sent).
sent.
succeeded.
is sent.
Request activation of a particular
facility or action at another exchange.
request.
signaling.
Use
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
type
Value Primitive Message
Dec Hex
Use
INF 4 0x04 Sends additional call information.
Identification request IDR 54 0x36 Used to request an action regarding
the MCID supplementary service.
Identification
IRS 55 0x37 Used to respond to the IDR mess age.
response
Loop back
acknowledgement
request
Loop prevention
LPA 36 0x24 Indicates to the network that a
continuity check loop has been applied
to the circuits.
LOP 64 0x40 Use with ECT supplementary service.
request
Network resource
management request
NRM 50 0x32 Request modifications to network
resources associated with a call.
Overload request OLM 48 0x30 Used to initiate temporary trunk
blocking.
Pre-release
information request
PRI 66 0x42 Used by the application to request end-
to-end information prior to the release
of a call.
Proceeding request ACM 6 0x06 Indicates incoming called party number
is complete.
Progress request CPG 44 0x2c Carries progress information.
Release request REL 12 0x0c Initiates call clearing.
Release response RLC 16 0x10 Confirms that application has
completed call clearing. (Used when
call clearing has been originated by the
ISUP module).
Request information
INR 3 0x03 Requests additional call information.
request
Resume request RES 14 0x0e Resumes suspended call.
Segmentation
request
SGM 56 0x38 Requests that a message segment is
sent.
Suspend request SUS 13 0x0d Suspends call.
Setup request IAM 1 0x01 Initiates outgoing call.
Setup response ANM
CON
Subsequent Directory
SDM 67 0x43 Subsequent directory number digits for
Number
Unrecognised
UMT 254 0xfe Allows an unsupported message type
message request
User information
USR 45 0x2d Requests that user-to-user data is sent.
9
0x09
7
0x07
Answers incoming call.
overlap signaling
to be sent by the application.
request
27
Section 6 Interface to Application
6.5.1 Alerting Request
This primitive is used by the application to indicate that the called
subscriber's phone is ringing. The primitive takes the form of an Address
Complete message when it is the first backward message issued by the
destination exchange or a Call Progress message after the first backward
message has been issued.
First Backward Message Issued
Message type
ACM (Address Complete Message)
Mandatory parameters
None
Optional parameters
• Backward call indicators
Defaults to 0x1416 if not supplied i.e. Subscriber Free Ordinary
Subscriber, Charge Terminating access ISDN, ISDN used all the way
• Access transport
• Cause indicators
• Call reference
• Optional backward call indicators
• Remote operations
• Service activation
• Transmission medium used
• User to user indicators
May be used to accept user to user information service 1, 2 or 3
(previously requested in a set-up indication).
• User to user information
Discarded if user to user service 1 has not been accepted.
28
The following optional parameters are supported in ITU-T mode only:
• Access delivery information
• Application transport
• Call diversion information
• Conference treatment indicators
• Connected number
• Echo control information
• Generic notification indicator
This parameter may be repeated (see
Parameters
on page 197).
Appendix E: ISUP Repeat
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
• Network specific facility
• Parameter compatibility information
• Redirection number
• Redirection number restriction indicator
• UID action indicators
The following parameters are supported in ANSI mode only:
• Business group
• Generic digits
• Information indicators
• Network transport
• Notification indicator
• Redirection information
Issued following ACM
Message type
CPG (Call Progress Message)
Mandatory parameters
None
Optional parameters
• Access transport
• Backward call indicators
• Cause indicators
• Call reference
• Event information
Defaults to 0x01 if not supplied. i.e. ALERTING
• Optional backward call indicators
• Redirection number
• Remote operations
• Service activation
• Transmission medium used
• User to user indicators
May be used to accept user to user information service 1, 2 or 3
• User to user information
Discarded if user to user service 1 has not been accepted
The following optional parameters are supported in ITU-T mode only:
29
Section 6 Interface to Application
• Access delivery information
• Application transport
• Backward GVNS
• Call diversion information
• Call history information
• Call transfer number
• Conference treatment indicators
• Connected number
• Echo control information
• Generic notification indicator
This parameter may be repeated (see
Appendix E: ISUP Repeat
Parameters on page 197).
• Generic number
• Network specific facility
• Parameter compatibility information
• Redirection number restriction indicator
• UID action indicators
The following optional parameters are supported in ANSI mode only:
• Business group
• Generic number (address)
• Generic digits
• Information indicators
• Network transport
• Notification indicator
This parameter may be repeated (see
Parameters
on page 197).
6.5.2 Application Transport Request
Note: This message is only applicable to ITU operation.
This primitive can be issued in all call states up until release. It is used by
the application to send an application transport message which is passed on
in same direction without changing state.
Message type
APM (Application Transport Message)
Mandatory parameters
None
Appendix E: ISUP Repeat
30
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
Optional parameters
• Message compatibility information
• Parameter compatibility information
• Application transport parameter
This parameter may be repeated (see
Parameters
on page 197).
• End of optional parameter
6.5.3 ‘Generic’ Charge Request
Note: This message is only applicable to ITU-T operation.
This primitive is used by the application to convey charging information
relating to a call. This message can be issued by the application in all call
states up to and including the answered and suspended states, provided that
the circuit group ISPX1GOP_TX_CRG option is set.
Message type
CRG (Charge Message)
Appendix E: ISUP Repeat
Mandatory parameters
• Message data
Optional parameters
None
6.5.4 Circuit Seized Request
This primitive is used by the application to indicate that the circuit has been
seized for an outgoing call (but no address information has yet been sent)
and may be issued to initiate a continuity test call. When this primitive is
received by the ISUP module, a CCR message will be sent to the network.
Message type
SZE (Circuit Seized Message)
Mandatory parameters
• Nature of connection indicators
Optional parameters
None
31
Section 6 Interface to Application
6.5.5 Collection Charging Request
This primitive is used by the application after alerting to provide the number
of charging units to be billed to the calling subscriber.
Message type
MPM (Collection Charging Message)
Mandatory parameters
• Number of metering pulses
• Message number
Optional parameters
None
6.5.6 Confusion Request
This primitive is issued by the application to cause a confusion message to be
sent to the network.
Message type
CFN (Confusion Message)
Mandatory parameters
None
Optional parameters
• Cause Indicators
6.5.7 Continuity Request
This primitive is used by the application to indicate whether a continuity test
has succeeded.
Message type
COT (Continuity Message)
Mandatory parameters
• Continuity indicators
Optional parameters
None
32
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.5.8 End-to-End Message Request
This primitive is used by the application for end-to-end signaling.
Message type
PAM (Pass Along Message)
Mandatory parameters
• Message data
Optional parameters
None
6.5.9 Exit Request
Note: This message is only applicable to ANSI operation
An Exit Message may be sent in the backward direction from a gateway
exchange before Address Complete to indicate that call setup information has
successfully been passed to an adjacent network. This message may be
issued by the application for an incoming call in the waiting ACM state and
will only be accepted if the ISPGOP_ANSI circuit group option is selected.
Message type
CPG (Call Progress Message)
Mandatory parameters
• Event information
Must be coded as value 0x7d (defined as ‘spare’ by ANSI T1.113.3), to
indicate Exit.
Optional parameters
• Outgoing trunk group number
6.5.10 Facility Request
This primitive is used by the application to request activation of a particular
facility or action at another exchange.
Two forms of this primitive are supported. FAR is used to request a particular
facility during the active (speech) phase of a call, and FAC is used during
either the setup or active phase of a call to request a particular action at
another exchange.
Facility Request
Message type
FAR (Facility Request Message)
33
Section 6 Interface to Application
Mandatory parameters
• Facility indicator
Optional parameters
• Call reference
The following optional parameters are supported in ITU-T mode only:
• Connection request
• Parameter compatibility information
• User to user indicators
The following optional parameters are supported in ANSI mode only (and are
conveyed transparently by the ISUP module):
• Business group
• Called party number
• Calling party number
• Charge number
• Generic number (address)
• Generic digits
• Network transport
Action Request
Message type
FAC (Facility Message)
Mandatory parameters
None
Optional parameters
• Remote operations
• Service activation
The following optional parameters are supported in ITU-T mode only:
• Access transport
• Call transfer number
• Generic notification
• Message compatibility information
• Parameter compatibility information
34
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.5.11 Facility Response
This message is used by the application to accept or reject a previously
requested user to user supplementary service 3 during the active (speech)
stage of a call.
Accepted
Message type
FAA (Facility Accepted Message)
Mandatory parameters
• Facility indicator
Optional parameters
• Call reference
• User to user indicators
The following optional parameters are supported in ITU-T mode only:
• Connection request
• Parameter compatibility information
Rejected
Message type
FRJ (Facility Rejected Message)
Mandatory parameters
• Facility indicator
• Cause indicators
Optional parameters
• Call reference
The following optional parameters are supported in ITU-T mode only:
• User to user indicators
The following optional parameters are supported in ANSI mode only:
• Called party number
• Calling party number
35
Section 6 Interface to Application
6.5.12 Forward Transfer Request
This message is used by the application to send a Forward Transfer message
to the network.
Message type
FOT (Forward Transfer Message)
Mandatory parameters
None
Optional parameters
• Call reference
The following optional parameters are supported in ANSI mode:
• Cause indicator
6.5.13 Identification Request
Note: This message is only applicable to ITU-T operation
This primitive is used by the application to request action regarding the
malicious call identification supplementary service. This message is sent in
the backward direction.
Message type
IDR (Identification Request Message)
Mandatory parameters
None
Optional parameters
• MCID request indicator
• Message compatibility information
• Parameter compatibility information
6.5.14 Identification Response
Note: This message is only applicable to ITU-T operation
This primitive is used by the application to respond to the Identification
Indication primitive.
Message type
IRS (Identification Response Message)
36
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
Mandatory parameters
None
Optional parameters
• MCID response indicators
• Message compatibility information
• Parameter compatibility information
• Calling party number
• Access transport
• Generic number
This parameter may be repeated (see
Parameters
on page 197).
• Charged party identification
6.5.15 Information Request
This primitive is used by the application to submit additional call information
to the network and may take two forms.
Appendix E: ISUP Repeat
Subsequent Address Digits
Note: This message is only applicable to ITU-T operation
This message may be used to convey subsequent outgoing call called party
number address digits to the network when overlap signaling is employed. It
is not used for ANSI operation.
Message type
SAM (Subsequent Address Message)
Mandatory parameters
• Subsequent number
Optional parameters
None
Additional call information
This primitive is used by ISUP to convey call information (other than called
address digits) during incoming call set-up, and may be used to implement
simple segmentation procedures whereby including this additional information
in an Initial Address Message would cause the message to be over length.
Message type
INF (Information Message)
37
Section 6 Interface to Application
Mandatory parameters
• Information indicators
Optional parameters
• Calling party category
• Calling party number
• Call reference
• Access transport
The following optional parameters are supported in ITU-T mode:
• Connection request
• Network specific facility
• Parameter compatibility infor m a tio n
The following optional parameters are supported in ANSI mode only:
• Business group
• Charge number
• Originating line information
• Redirecting number
• Redirection information
• User to user information
6.5.16 Loop Back Acknowledgement Request
This primitive is used by the application to indicate that a continuity check
loop has been applied to the circuit.
When this primitive is received by the ISUP module, an LPA message will be
sent to the network.
Message type
LPA (Loop Back Acknowledgement Message)
Mandatory parameters
None
Optional parameters
None
38
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.5.17 Loop Prevention Request
Note: This message is only applicable to ITU-T operation
This primitive is used as part of the ECT supplementary service.
Message type
LOP (Loop Prevention Message)
Mandatory parameters
None
Optional parameters
• Message compatibility information
• Parameter compatibility information
• Call transfer reference
• Loop prevention indicators
6.5.18 Network Resource Management Request
Note: This message is only applicable to ITU-T operation
This primitive is used by the application to modify network resources
associated with a certain call. This message is sent along any established
path in any direction in any phase of a call.
Message type
NRM (Network Resource Management Message)
Mandatory parameters
None
Optional parameters
• Echo control information
• Message compatibility information
• Parameter compatibility information
• Transmission medium requirement
39
Section 6 Interface to Application
6.5.19 Overload Request
Note: This message is only applicable to ITU-T operation
This primitive is used by the application to invoke temporary trunk blocking of
a circuit.
Message type
OLM (Overload Message)
Mandatory parameters
None
Optional parameters
None
6.5.20 Pre-Release Information Request
Note: This message is only applicable to ITU-T operation
This primitive can be issued in all call states up until release. It is used by
the application to send end-to-end information prior to the release of a call.
Message type
PRI (Pre-Release Information Message)
Mandatory parameters
None
Optional parameters
• Optional forward call indicators
• Optional backward call indicators
• Message compatibility information
• Parameter compatibility information
• Application transport parameter
This parameter may be repeated (see
Parameters
on page 197).
• End of optional parameter
Appendix E: ISUP Repeat
40
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.5.21 Proceeding request
This primitive is used by the application to indicate that for an incoming call
sufficient address digits have been received to connect the call. It must only
be used as the first backward message issued by the application.
Message type
ACM (Address Complete Message)
Mandatory parameters
• Backward call indicators
Optional parameters
• Access transport
• Call reference
• Cause indicators
• Optional backward call indicators
• Remote operations
• Service activation
• Transmission medium used
• User to user indicators
May be used to accept user to user information service 1, 2 or 3
(previously requested in a set-up indication).
• User to user information
Discarded if user to user service 1 has not been accepted
The following parameters are supported in ITU-T mode only
• Access delivery information
• Application transport
• Call diversion information
• Conference treatment indicators
• Connected number
• Echo control information
• Generic notification indicator
This parameter may be repeated (see
Appendix E: ISUP Repeat
Parameters on page 197).
• Network specific facility
• Parameter compatibility information
• Redirection number
• Redirection number restriction indicator
• UID action indicator
41
Section 6 Interface to Application
The following optional parameters are supported in ANSI mode only:
• Business group
• Generic digits
• Information indicators
• Network transport
• Notification indicator
• Redirection information
6.5.22 Progress Request
This primitive is used by the application to convey information about the
progress of the call.
Message type
CPG (Call Progress Message)
Mandatory parameters
• Event information
Optional parameters
• Access transport
• Automatic Congestion Level
• Backward call indicators
• Cause indicators
• Call reference
• Optional backward call indicators
• Redirection number
• Remote operations
• Service activation
• Transmission medium used
• User to user indicators
May be used to accept user to user information service 1, 2 or 3
• User to user information
Discarded if user to user service 1 has not been accepted
The following optional parameters are supported in ITU-T mode only:
• Access delivery information
• Application transport
• Backward GVNS
• Call diversion information
42
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
• Call history information
• Call transfer number
• Conference treatment indicators
• Echo control information
• Connected number
• Generic notification indicator
This parameter may be repeated (see
Parameters on page 197).
• Network specific facility
• Parameter compatibility information
• Redirection number restriction indicator
• UID action indicators
The following optional parameters are supported in ANSI mode only:
• Business group
• Generic number (address)
• Generic digits
• Information indicators
• Network transport
• Notification indicator
This parameter may be repeated (see
Parameters
on page 197).
Appendix E: ISUP Repeat
Appendix E: ISUP Repeat
6.5.23 Release Response
This primitive is used by the application in the case when call clearing was
initiated by the ISUP module. It advises the ISUP module that the application
has finished clearing the switch path and that the circuit is now available for
re-selection.
Whenever a Release indication (REL) is received from the ISUP module, the
application must return a Release response (RLC) to the ISUP module once it
has finished clearing the call. An optional Release request (REL) may also be
returned before the Release response (RLC) – see description of the Release
request primitive.
Message type
RLC (Release Complete Message)
Mandatory parameters
None
43
Section 6 Interface to Application
Optional parameters
The following parameters are supported in ITU-T mode only
• Cause indicators
6.5.24 Release Request
This primitive is used by the application to initiate call clearing and as an
immediate response to a received Release indication primitive from the ISUP
module.
To initiate call clearing, the application should send this message to the ISUP
module. It should then wait until a Release confirmation (RLC) is received
from the ISUP module before selecting the circuit for a new outgoing call
attempt. Refer to
further information.
Message type
REL (Release Message)
Mandatory parameters
None
Section : 6.8.1 Call Clearing Procedure on page 90 for
Optional parameters
• Access transport
• Cause indicators
Defaults to the following if not supplied:
• Coding standard = ITU-T
• Location = User
• Recommendati on = Q.931
• Cause Value = Normal. Unspeci f ied
• Generic number (address)
This parameter may be repeated in this message
• Signalling point code
• User to user information
Discarded if user to user service 1 has not been accepted
• User to user indicators
The following optional parameters are supported in ITU-T mode only
• Access delivery information
• Automatic congestion control
• Network specific facility
• Parameter compatibility information
• Redirection information
44
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
• Redirection number
• Redirection number restriction indicator
• Remote operations
• Display
The following optional parameters are supported in ANSI mode only:
• Call reference
• Charge number
• Generic digits
• Network transport
• Service activation
6.5.25 Request Information Request
This primitive is used by the application to request additional call information.
Message type
INR (Information Request Message)
Mandatory parameters
• Information request indicators
Optional parameters
• Call reference
The following optional parameters are only supported in ITU-T mode only:
• Network specific facility
• Parameter compatibility information
The following optional parameters are only supported in ANSI mode only:
• Network transport
6.5.26 Resume Request
This primitive is used by the application to resume a call that was previously
suspended.
Message type
RES (Resume Message)
Mandatory parameters
None
45
Section 6 Interface to Application
Optional parameters
• Suspend/resume indicators
Defaults to 0x00 if not supplied, i.e. ISDN Subscriber Initiated
• Call reference
6.5.27 Segmentation Request
Note: This message is only applicable to ITU-T operation
This primitive is used by the application to send the second segment of an
ISUP message.
Message type
SGM (Segmentation Message)
Mandatory parameters
None
Optional parameters
• Access transport
• User-to-user information
• Message compatibility information
• Generic digit
This parameter may be repeated (see
Parameters
• Generic notification
This parameter may be repeated (see Appendix E: ISUP Repeat
Parameters
• Generic number
This parameter may be repeated (see
Parameters
on page 197).
on page 197).
on page 197).
Appendix E: ISUP Repeat
Appendix E: ISUP Repeat
6.5.28 Setup Request
This primitive is used by the application to initiate an outgoing call.
Message type
IAM (Initial Address Message)
Mandatory parameters
• Called party number
46
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
Optional parameters
• Access transport
• Calling party's category
Defaults to 0x0a if not supplied
• Call reference
• Calling party number
• Forward call indicators
Defaults to 0x0040 if not supplied
• Generic digits
This parameter may be repeated (see
Parameters
on page 197).
• Generic number (address)
This parameter may be repeated (see Appendix E: ISUP Repeat
Parameters
).on page 197
• Hop counter
• Nature of connection indicators
Defaults to 0x00 if not supplied
• Original called number
• Redirecting number
• Redirection information
• Remote operations
• Service activation
• Transit network selection
• User service information
In ANSI mode, defaults to 0x80, 0x90 , 0xa2 CCITT coding standard
information transfer capability speech 64kbit/s circuit mode
1 protocol)
• User service information prime
• User to user information
If no user to user indicators are provided, presence of user to user
information is considered as an implicit request of service 1.
Appendix E: ISUP Repeat
μ
--law (layer
The following optional parameters are supported in ITU-T mode only:
Application transport
• Backward GVNS
• Call diversion treatment indicators
• Call offering treatment indicator
• Called IN number
• CCSS
47
Section 6 Interface to Application
• Circuit assignment map
• Closed user group interlock code
• Collect call request
• Conference treatment indicator
• Connection request
• Correlation id
The following parameters are supported in ITU-T mode only:
• Echo control information
• Forward GVNS
• Freephone indicators
• Generic notification indicator
• Generic reference
• Location number
• MLPP precedence
• Network management controls
• Network specific facility
• Optional forward call ind icators
• Originating ISC point code
• Parameter compatibility information
• Propagation delay counter
• Redirection number
• UID capability indicator
• SCF ID
• Transmission medium requirement
Required in ITU-T mode only. Permitted values are:
• 0x00Speech
• 0x0264kb/s Unrestricted
• 0x033.1kHz Audio
• 0x0664kb/s Preferred
Defaults to Speech if not supplied
• Transmission medium requirement prime
• User teleservice information
• User to user indicators
May be used to request user to user information service 1, 2 or 3
48
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
The following optional parameters are supported in ANSI mode only:
• Business group
• Carrier identification
• Carrier selection information
• Charge number
• Circuit assignment map
• Egress service
• Generic name
• Information request indicators
• Jurisdiction
• Network transport
• Operator services information
• Originating line information
• Precedence
• Service code indicator
• Special processing request
• Transaction request
6.5.29 Setup Response
This primitive is used by the application to answer an incoming call. There
are two forms of the primitive. In ITU-T mode, one form is used before an
Address Complete message has been issued and the other after an Address
Complete message has been issued. In ANSI mode, a single primitive is used
both before and after Address Complete.
Before ACM Issued
Note: This message is only applicable to ITU-T operation.
Message type
CON (Connect Message)
Mandatory parameters
None
Optional parameters
• Application transport
• Access delivery information
• Access transport
49
Section 6 Interface to Application
• Backward call indicators
Defaults to 0x1416 if not supplied , i.e. Subscriber Free, Ordinary
Subscriber, Charge, Terminating access ISDN, ISDN used all the way
• Backward GVNS
• Call history information
• Call reference
• Connected number
• Conference treatment indicator
• Echo control information
• Generic notification indicator
This parameter may be repeated (see
Parameters
)on page 197
Appendix E: ISUP Repeat
• Generic number
This parameter may be repeated (see
Appendix E: ISUP Repeat
Parameters ).on page 197
• Network specific facility
• Optional backward call indicators
• Parameter compatibility information
• Redirection number
• Redirection number restriction indicator
• Remote operations
• Service activation
• Transmission medium used
• User to user indicators
May be used to accept user to user information service 1, 2 or 3
• User to user information
Discarded if user to user service 1 has not been accepted
50
Setup response
Message type
ANM (Answer Message)
Mandatory parameters
None
Optional parameters
• Access transport
• Backward call indicators
• Call reference
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
• Optional backward call indicators
• Remote operations
• Service activation
• Transmission medium used
• User to user indicators
May be used to accept user to user information service 1, 2 or 3
• User to user information
Discarded if user to user service 1 has not been accepted
The following optional parameters are supported in ITU-T mode only:
• Access delivery information
• Application transport
• Backward GVNS
• Call history information
• Connected number
• Display
• Echo control information
• Generic notification indicator
This parameter may be repeated (see
Parameters
on page 197).
• Generic number
This parameter may be repeated (see Appendix E: ISUP Repeat
Parameters
on page 197).
• Parameter compatibility information
• Network specific facility
• Redirection number
• Redirection number restriction indicator
Appendix E: ISUP Repeat
The following optional parameters are supported in ANSI mode only:
• Business group
• Generic digits
• Information indicators
• Network transport
• Notification parameter
This parameter may be repeated (see
Parameters
on page 197).
Appendix E: ISUP Repeat
51
Section 6 Interface to Application
6.5.30 Subsequent Directory Number Request
This primitive is used by the application to convey subsequent directory
number address digits to the network when overlap signaling is employed. It
is not used for ANSI operation.
Note: This message is only applicable to ITU-T operation
Message type
SDM (Subsequent Directory Number Message)
Mandatory parameters
None
Optional parameters
• Subsequent number
• Message compatibility information
6.5.31 Suspend Request
This message is used by the application to suspend a call that is currently
connected.
Message type
SUS (Suspend Message)
Mandatory parameters
None
Optional parameters
• Suspend/resume indicators
Defaults to 0x00 if not supplied (i.e. ISDN Subscriber Initiated)
• Call reference
52
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.5.32 Unrecognised Message Request
Note: This message is only applicable to ITU-T operation.
This primitive is used by the application to allow a message that is not known
to the ISUP module to be transmitted to the network. It may be useful in the
case that a national variant requires transmission of an additional message
type.
The ISUP module performs no checks on the contents of the message and
providing that a call is active will send the message directly to the network.
Message type
Unrecognised message
Mandatory parameters
• Message data
Optional parameters
None
6.5.33 User Information Request
Note: This message is only applicable to ITU-T operation.
This primitive is used by the application to transfer user information to the
remote party during call set-up (supplementary service 2) or during the
established (speech) phase of a call (supplementary service 3). If the
corresponding supplementary service has not been requested and
subsequently accepted, this primitive will be discarded.
Note: It is only possible to exchange two user to user messages in each directions (i.e. 4
messages in all) for the supplementary service 2.
Message type
USR (User Information Message)
Mandatory parameters
• User to user information
Optional parameters
• Access transport
• Call reference
53
Section 6 Interface to Application
6.6 Application Messages from ISUP
The following table lists all application messages (message type
ISP_MSG_RX_IND) sent by ISUP module to the user application:
Table 1. All Application Messages sent by the ISUP Module to the User Application
type
Alerting indication ACM
CPG
Application transport
indication
Charge indication
(Generic)
Circuit seized
indication
Collection charging
indication
Confusion indication CFN 47 0x2f Indicates that a confusion message
Continuity indication COT 5 0x05 Indicates whether the continuity test
End-to-end message
indication
Facility confirmation FAA 32 0x20 Indicates that the remote party has
Facility indication FAR 31 0x1f Indicates that the remote party is
Forward transfer
indication
Information indication
Identification
indication
Identification
confirmation
Loop back
acknowledgement
indication
Loop prevention
indication
APM 65 0x41 Issued on receipt of an application
CRG 50 0x32 Carries charging information
SZE 199 0xc7 Used for continuity checking and
MPM 201 0xc9 Used to carry charging information.
PAM 40 0x28 Conveys received end-to-end
FOT 8 0x08 Indicates that a forward transfer
SAM 2 0x02 Subsequent address digits for overlap
INF 4 0x04 Provides additional call information.
IDR 54 0x36 Used to request an action regarding
IRS 55 0x37 Used to respond to the IDR mess age.
LPA 36 0x24 Indicates to the application that a
LOP 64 0x40 Use with ECT supplementary service.
Value Primitive Message
Dec Hex
6
0x06
44
0x2c
Indicates outgoing called party being
alerted.
transport message.
indicates that a circuit has been seized
for an incoming call (but no address
information has yet been received).
has been received.
succeeded.
message.
accepted the user to user service 3
request.
requesting user to user information
service 3 during the active phase of a
call.
message has been received.
signaling.
the MCID supplementary service.
continuity check loop has been applied
to the circuit.
Use
54
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
Network resource
management
type
Dec Hex
NRM 50 0x32 Indicates that network resources
associated have been modified.
Value Primitive Message
Use
indication
Overload indication OLM 48 0x30 Indicates that remote switch is in
overload.
Proceeding indication ACM 6 0x06 Indicates outgoing called party number
is complete.
Progress indication CPG 44 0x2c Carries progress information.
Pre-release
information indication
PRI 66 0x42 Indicates that end-to-end information
has been requested.
Release indication REL 12 0x0c Initiates call clearing.
Release confirmation RLC 16 0x10 Indicates that circuit has returned to
IDLE state and is available for re-
selection.
Request information
indication
INR 3 0x03 Indicates a request for additional call
information.
Resume indication RES 14 0x0e Call resumed indication.
Segmentation
indication
SGM 56 0x38 Conveys an additional message
segment.
Suspend indication SUS 13 0x0d Call suspended indication.
Setup confirmation ANM
CON
9
0x09
7
0x07
Outgoing call answered indication.
Setup indication IAM 1 0x01 Incoming call indication.
Subsequent Directory
Number
Unrecognised
message indication
SDM 67 0x43 Subsequent directory number digits for
overlap signaling
UMT 254 0xfe Conveys a received message with
unrecognized message type to the
user.
User information
USR 45 0x2d Conveys received user to user data.
indication
55
Section 6 Interface to Application
6.6.1 Alerting Indication
This primitive is used by ISUP to indicate that the called subscriber's phone is
ringing. The primitive takes the form of an Address Complete message when
it is the first backward message issued by the destination exchange or a Call
Progress message after the first backward message has been issued.
First backward message received
Message type
ACM (Address Complete Message)
Mandatory parameters
• Backward call indicators
Optional parameters
• Access transport
• Cause indicators
• Call reference
• Optional backward call indicators
• Remote operations
• Service activation
• Transmission medium used
• User to user indicators
Indicates that a previously requested supplementary service has been
provided
• User to user information
56
The following optional parameters are supported in ITU-T mode only:
• Access delivery information
• Application transport
• Call diversion information
• Conference treatment indicators
• Connected number
• Echo control information
• Generic notification indicator
• Network specific facility
• Parameter compatibility information
• Redirection number
The following optional parameters are supported in ITU-T mode only:
• Redirection number restriction indicator
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
• UID action indicators
• Access delivery information
• Application transport
• Call diversion information
• Connected number
• Echo control information
• Generic notification indicator
• Network specific facility
• Parameter compatibility information
• Redirection number
• Redirection number restriction indicator
• UID action indicators
The following optional parameters are supported in ANSI mode only:
• Business group
• Generic digits
• Information indicators
• Network transport
• Notification indicator
• Redirection information
Received following ACM
Message type
CPG (Call Progress Message)
Mandatory parameters
• Event information
Optional parameters
• Access transport
• Backward call indicators
• Optional backward call indicators
• Remote operations
• Service activation
• Transmission medium used
• User to user indicators
Indicates that a previously requested supplementary service has been
provided
57
Section 6 Interface to Application
• User to user information
The following optional parameters are supported in ITU-T mode only:
• Access delivery information
• Application transport
• Backward GVNS
• Call diversion information
• Call history information
• Call transfer number
• Connected number
• Echo control information
• Generic notification indicator
This parameter may be repeated (see
Parameters
on page 197).
Appendix E: ISUP Repeat
• Generic number
• Parameter compatibility information
• Network specific facility
• Redirection number restriction indicator
• UID action indicators
The following optional parameters are supported in ANSI mode only:
• Business group
• Generic number (address)
• Generic digits
• Information indicators
• Network transport
• Notification indicator
This parameter may be repeated (see
Parameters
on page 197).
Appendix E: ISUP Repeat
58
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.6.2 Application Transport Indication
Note: This message is only applicable to ITU-T operation.
This primitive can be issued in all call states up until release. It is used by
ISUP to convey application information received from the network without
changing state.
Message type
APM (Application Transport Message)
Mandatory parameters
None
Optional parameters
• Message compatibility information
• Parameter compatibility information
• Application transport parameter
This parameter may be repeated (see
Parameters
on page 197).
• End of optional parameter
Appendix E: ISUP Repeat
6.6.3 ‘Generic’ Charge Indication
Note: This message is only applicable to ITU-T operation.
This primitive is used to convey charging information relating to a call. This
primitive can be issued by ISUP in all call states up to and including the
answered and suspended states providing that the circuit group
ISPX1GOP_TX_CRG option is set.
Message type
CRG (Charge Message)
Mandatory parameters
• Message data
Optional parameters
None
59
Section 6 Interface to Application
6.6.4 Circuit Seized Indication
This primitive is used by ISUP to indicate that the circuit has been seized for
an incoming call (but no address information has yet been received) and a
continuity test call has been received (refer to
Testing
Message type
SZE (Circuit seized)
Mandatory parameters
• Nature of connection indicators
Optional parameters
None
on page 95).
6.6.5 Collection Charging Indication
This primitive is used ISUP after alerting to convey the number of charging
units.
Section 6.8.4: Continuity
Message type
MPM (Collection Charging Message)
Mandatory parameters
• Number of metering pulses
• Message number
Optional parameters
None
6.6.6 Confusion Indication
This primitive is issued by ISUP on receipt of a Confusion message from the
network.
Message type
CFN (Confusion Message)
Mandatory parameters
None
Optional parameters
• Cause Indicators
60
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.6.7 Continuity Indication
This primitive is used by ISUP to convey information about whether or not a
continuity test has succeeded.
Message type
COT (Continuity Message)
Mandatory parameters
• Continuity indicators
Optional parameters
None
6.6.8 End-to-End Message Indication
This primitive is used by ISUP for end-to-end signaling.
Message type
PAM (Pass Along Message)
Mandatory parameters
• Message data
Optional parameters
None
6.6.9 Exit Indication
Note: This message is only applicable to ANSI operation
An Exit Message may be received in the backwards direction from a gateway
exchange before Address Complete to indicate that call setup information has
successfully been passed to an adjacent network.
Message type
CPG (Call Progress Message)
Mandatory parameters
• Event information
Must be coded as value 0x7d (defined as ‘spare’ by ANSI T1.113.3), to
indicate Exit.
Optional parameters
• Outgoing trunk group number
61
Section 6 Interface to Application
6.6.10 Facility Indication
This message is issued by ISUP to indicate that the remote party is either
requesting a user to user supplementary service during the active (speech)
stage of a call, or the activation of a particular facility.
Facility requested indication
Message type
FAR (Facility Request Message)
Mandatory parameters
• Facility indicator
• User to user indicators
ITU-T mode only
Optional parameters
• Call reference
The following optional parameters are supported in ITU-T mode only:
• Connection request
• Parameter compatibility infor m a tio n
The following optional parameters are supported in ANSI mode only:
• Business group
• Called party number
• Calling party number
• Charge number
• Generic number (address)
• Generic digits
• Network transport
Action requested indication
Message type
FAC (Facility Message)
Mandatory parameters
None
Optional parameters
• Remote operations
• Service activation
62
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
The following optional parameters are supported in ITU-T mode only:
• Access transport
• Call transfer number
• Generic notification
• Message compatibility information
• Parameter compatibility information
6.6.11 Facility Confirmation
This message is issued by ISUP to indicate that the remote party has
accepted (provided) or rejected a supplementary service previously requested
by the user during the active (speech) stage of a call. This primitive may
take two forms.
Accepted
Message type
FAA (Facility Accepted Message)
Mandatory parameters
• Facility indicator
• User to user indicators
Optional parameters
The following parameters are supported in ITU-T mode only:
• Call reference
• Connection request
• Parameter compatibility information
Rejected
Message type
FRJ (Facility Rejected Message)
Mandatory parameters
• Facility indicator
• Cause indicators
Optional parameters
• Call reference
The following optional parameters are supported in ITU-T mode only:
• User to user indicators
63
Section 6 Interface to Application
The following optional parameters are supported in ANSI mode only:
• Called party number
• Calling party number
6.6.12 Forward Transfer Indication
This message is issued by ISUP upon receipt of a Forward Transfer message
from the network.
Message type
FOT (Forward Transfer Message)
Mandatory parameters
None
Optional parameters
• Call reference
The following optional parameters are supported in ANSI mode only:
• Cause indicators
6.6.13 Identification Indication
Note: This message is only applicable to ITU-T operation
This primitive is used by ISUP to indicate that the malicious call identification
supplementary service has been requested.
Message type
IDR (Identification Indication Message)
Mandatory parameters
None
Optional parameters
• MCID request indicators
• Message compatibility information
• Parameter compatibility information
64
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.6.14 Identification Confirmation
Note: This message is only applicable to ITU-T operation
This primitive is used by ISUP to indicate that a response to an Identification
Request has been received.
Message type
IRS (Identification Confirmation Message)
Mandatory parameters
None
Optional parameters
• MCID response indicators
• Message compatibility information
• Parameter compatibility information
• Calling party number
• Access transport
• Generic number
This parameter may be repeated (see
Parameters on page 197).
Appendix E: ISUP Repeat
6.6.15 Information Indication
This primitive is used by the ISUP module to convey additional call
information to the user that was not present in the initial set-up indication.
The primitive may take two forms depending on the information being
indicated.
Subsequent address digits
Note: This message is only applicable to ITU-T operation
This primitive is used by ISUP to indicate subsequent incoming called party
number address digits from the network when overlap signaling is employed.
Message type
SAM (Subsequent Address Message)
Mandatory parameters
• Subsequent number
Optional parameters
None
65
Section 6 Interface to Application
Additional call information
This primitive is used by ISUP to indicate additional call information (other
than called address digits) during incoming call set-up.
Message type
INF (Information Message)
Mandatory parameters
• Information indicators
Optional parameters
• Access transport
• Calling party category
• Calling party number
• Call reference
The following optional parameters are supported in ITU mode only:
• Parameter compatibility information
• Network specific facility
The following optional parameters are supported in ANSI mode only:
• Business group
• Charge number
• Originating line information
• Redirecting number
• Redirection information
• User to user information
6.6.16 Loop Back Acknowledgement Indication
Loop back acknowledgement indication
This primitive is used by ISUP to indicate to the application that a continuity
check loop has been applied to the circuit. When an LPA message is received
from the network by the ISUP module, this primitive will be sent to the
application.
Message type
LPA (Loop Back Acknowledgement Message)
66
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
Mandatory parameters
None
Optional parameters
None
6.6.17 Loop Prevention Indication
Note: This message is only applicable to ITU-T operation.
This message is issued by ISUP upon receipt of a Loop prevention message
from the network.
Message type
LOP (Loop Prevention Message)
Mandatory parameters
None
Optional parameters
• Message compatibility information
• Parameter compatibility information
• Call transfer reference
• Loop prevention indicators
6.6.18 Network Resource Management Indication
This primitive is used by ISUP to convey network resources associated with a
certain call. This message is sent along any established path in any direction
in any phase of a call.
Message type
NRM (Network Resource Management Message)
Mandatory parameters
None
Optional parameters
• Message compatibility information
• Parameter compatibility information
• Echo control information
67
Section 6 Interface to Application
6.6.19 Overload Indication
Note: This message is only applicable to ITU-T operation.
This primitive is used by the ISUP module to indicate that the remote switch
is in overload. It is sent when an Overload message is received from the
remote switch during outgoing call set-up. On receipt of this indication, the
application should re-route the call (if possible).
The Overload indication will be followed by a Release indication (cause value
= 42). Release of the original outgoing circuit does not complete until timer
T3 expires, so preventing the circuit being reused while the remote switch is
in overload.
Message type
OLM (Overload Message)
Mandatory parameters
None
Optional parameters
None
6.6.20 Pre-Release Information Indication
Note: This message is only applicable to ITU-T operation.
This primitive can be issued in all call states up until release. It is used by
the ISUP module to convey end-to-end information.
Message type
PRI (Pre-Release Information)
Mandatory parameters
None
Optional parameters
• Optional forward call indicators
• Optional backward call indicators
• Message compatibility information
• Parameter compatibility information
• Application transport parameter
This parameter may be repeated (see
Parameters
on page 197).
• End of optional parameter
Appendix E: ISUP Repeat
68
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.6.21 Proceeding Indication
This primitive is used by ISUP to indicate that the destination exchange
recognizes that sufficient address digits have been sent (on an outgoing call)
to allow the call to proceed.
Message type
ACM (Address Complete Message)
Mandatory parameters
• Backward call indicators
Optional parameters
• Access transport
• Cause indicators
• Optional backward call indicators
• Remote operations
• Service activation
• Transmission medium used
• User to user indicators
Indicates that a previously requested supplementary service has been
provided
• User to user information
The following optional parameters are supported in ITU-T mode only:
• Access delivery information
• Call diversion information
• Conference treatment indicators
• Generic notification indicator
This parameter may be repeated (see
Parameters
on page 197).
Appendix E: ISUP Repeat
• Echo control information
• Network specific facility
• Parameter compatibility information
• Redirection number
• Redirection number restriction indicator
The following optional parameters are supported in ANSI mode only:
• Business group
• Generic digits
• Information indicators
• Network transport
69
Section 6 Interface to Application
• Notification indicator
• Redirection information
6.6.22 Progress Indication
This primitive is used to convey progress information relating to the call.
Message type
CPG (Call Progress Message)
Mandatory parameters
• Event information
Optional parameters
• Access transport
• Backward call indicators
• Optional backward call indicators
• Remote operations
• Service activation
• Transmission medium used
• User to user indicators
Indicates that a previously requested supplementary service has been
provided
• User to user information
70
The following optional parameters are supported in ITU-T mode only:
• Access delivery information
• Application transport
• Call diversion information
• Generic notification indicator
This parameter may be repeated (see
Parameters
on page 197)
Appendix E: ISUP Repeat
• Network specific facility
• Parameter compatibility information
• Redirection number restriction indicator
• UID action indicators
The following optional parameters are supported in ANSI mode only:
• Business group
• Generic number (address)
• Generic digits
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
• Information indicators
• Network transport
• Notification indicator
This parameter may be repeated (see
Parameters on page 197).
6.6.23 Release Confirmation
This primitive is used by ISUP to indicate that the call clearing sequence has
completed and the circuit is again available for re-selection.
At the end of each call, the application must wait until the Release
confirmation (RLC) has been received before selecting the circuit for a new
outgoing call.
Message type
RLC (Release Complete Message)
Mandatory parameters
None
Appendix E: ISUP Repeat
Optional parameters
The following optional parameters are supported in ITU-T mode only:
• Cause indicators
6.6.24 Release Indication
This primitive is used by ISUP to initiate call clearing, either due to receipt of
a REL message from the network or having detected a local condition (such
as timer expiry) which requires call clearing.
On receipt of Release indication (REL) from ISUP the application should (if it
has not already issued Release request) respond immediately with a Release
request (REL). Then when the switch path has been cleared the application
should issue a Release response (RLC) to the ISUP module. Note that, if the
switch path is cleared immediately, only RLC (not REL followed by RLC) is
required.
Message type
REL (Release Message)
Mandatory parameters
• Cause indicators
71
Section 6 Interface to Application
Optional parameters
• Access transport
• Automatic congestion level
• Generic number (address)
This parameter may be repeated (see
Parameters
on page 197).
Appendix E: ISUP Repeat
• Redirection information
• Redirection number
• Signalling point code
• User to user indicators
• User to user information
The following optional parameters are supported in ITU-T mode only:
• Access delivery information
• Network specific facility
• Parameter compatibility information
• Redirection number restriction indicator
The following optional parameters are supported in ANSI mode only:
• Call reference
• Charge number
• Generic digits
• Network transport
• Service activation
6.6.25 Request Information Indication
This primitive is used to indicate to the application a request for additional
call information.
Message type
INR (Information Request Message)
Mandatory parameters
• Information request indicators
Optional parameters
• Call reference
The following optional parameters are supported in ITU-T mode:
• Network specific facility
• Parameter compatibility information
72
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
The following optional parameters are supported in ANSI mode:
• Network termination
6.6.26 Resume Indication
This primitive is used by ISUP to indicate that a call that had been suspended
is now resuming.
Message type
RES (Resume Message)
Mandatory parameters
• Suspend/resume indicators
Optional parameters
• Call reference
6.6.27 Segmentation Indication
Note: This message is only applicable to ITU-T operation
This primitive contains the second segment of an ISUP message.
Message type
SGM (Segmentation Message)
Mandatory parameters
None
Optional parameters
• Access transport
• User-to-user information
• Message compatibility information
• Generic digit
This parameter may be repeated (see
Parameters
on page 197).
Appendix E: ISUP Repeat
• Generic notification
This parameter may be repeated (see Appendix E: ISUP Repeat
Parameters
on page 197).
• Generic number
This parameter may be repeated (see
Parameters
on page 197).
Appendix E: ISUP Repeat
73
Section 6 Interface to Application
6.6.28 Setup Confirmation
This primitive is used by ISUP to indicate that an outgoing call has been
answered. ITU-T defines two forms of the primitive, one for use before an
Address Complete message and the other for use after an Address Complete
message. ANSI defines one form of the primitive.
Before ACM received
Note: This message is only applicable to ITU-T operation
Message type
CON (Connect Message)
Mandatory parameters
• Backward call indicators
Optional parameters
• Access delivery information
• Access transport
• Backward GVNS
• Call history information
• Call reference
• Connected number
• Conference treatment indicators
• Echo control information
• Generic notification indicator
This parameter may be repeated (see
Parameters
• Generic number
This parameter may be repeated (see Appendix E: ISUP Repeat
Parameters
• Network specific facility
• Optional backward call indicators
• Parameter compatibility information
• Redirection number
• Redirection number restriction indicator
• Remote operations
• Service activation
• Transmission medium used
on page 197).
on page 197).
Appendix E: ISUP Repeat
74
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
• User to user indicators
The response to a previously issued user to user supplementary service
request.
• User to user information
Discarded if user to user service 1 has not been accepted
After ACM received
Message type
ANM (Answer Message)
Mandatory parameters
None
Optional parameters
• Access transport
• Backward call indicators
• Connected number
• Optional backward call indicators
• Remote operations
• Service activation
• Transmission medium used
• User to user indicators
The response to a previously issued user to user supplementary service
request.
• User to user information
Discarded if user to user service 1 has not been accepted
The following optional parameters are supported in ITU-T mode:
• Access delivery information
• Call history information
• Echo control information
• Generic notification indicator
This parameter may be repeated (see
Parameters
on page 197).
Appendix E: ISUP Repeat
• Generic number
This parameter may be repeated (see Appendix E: ISUP Repeat
Parameters
on page 197).
• Network specific facility
• Parameter compatibility information
• Redirection number
75
Section 6 Interface to Application
• Redirection number restriction indicator
The following optional parameters are supported in ANSI mode:
• Business group
• Information indicators
• Network transport
• Notification parameter
This parameter may be repeated (see
Parameters
on page 197).
6.6.29 Setup Indication
This primitive is used by ISUP to indicate the arrival of an incoming call.
Message type
IAM (Initial Address Message)
Mandatory parameters
• Nature of connection indicators
• Forward call indicators
• Calling party's category
• Transmission medium requirement
ITU-T mode only
• User service information
Mandatory for ANSI mode only. Optional for ITU-T operation.
• Called party number
Appendix E: ISUP Repeat
76
Optional parameters
• Access transport
• Calling party number
• Call reference
• Generic number (address)
This parameter may be repeated (see
Parameters
on page 197).
Appendix E: ISUP Repeat
• Generic digits
This parameter may be repeated (see Appendix E: ISUP Repeat
Parameters
on page 197).
• Original called number
• Redirection information
• Redirecting number
• Remote operations
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
• Service activation
• Transit network selection
• Redirecting number
• User service information prime
• User to user indicators
Indicates that the calling party is requesting one or more user to user
supplementary services.
• User to user information
The following optional parameters are supported in ITU-T mode only:
• Call diversion treatment indicators
• Call offering treatment indicators
• Called IN number
• CCSS
• Circuit assignment map
• Closed user group interlock code
• Collect call request
• Conference treatment indicators
• Connection request
• Correlation id
• Echo control information
• Forward GVNS
• Freephone indicators
• Generic notification indicator
This parameter may be repeated (see
Parameters
on page 197).
• Generic reference
• Hop counter
• Location number MLPP preference
• Network management controls
• Network specific facility
• Optional forward call ind icators
• Origination ISC point code
• Parameter compatibility information
• Propagation delay counter
• SCF id
• Transmission medium requirement prime
Appendix E: ISUP Repeat
77
Section 6 Interface to Application
• UID capability indicators
• User teleservice information
The following optional parameters are supported in ANSI mode only:
• Business group
• Carrier identification
• Carrier selection information
• Charge number
• Circuit assignment map
• Egress service
• Generic name
• Hop counter
• Information request indicators
• Jurisdiction
• Network transport
• Operator services information
• Originating line information
• Precedence
• Service code indicator
• Special processing request
• Transaction request
6.6.30 Subsequent Directory Number Indication
This primitive is used by ISUP to indicate subsequent incoming directory
number address digits from the network when overlap signaling is employed.
It is not used for ANSI operation.
Note: This message is only applicable to ITU-T operation
Message type
SDM (Subsequent Directory Number Message)
Mandatory parameters
None
Optional parameters
• Subsequent number
• Message compatibility information
78
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.6.31 Suspend Indication
This message is used by ISUP to indicate that a currently connected call has
been suspended.
Message type
• SUS (Suspend Message)
Mandatory parameters
• Suspend/resume indicators
Optional parameters
• Call reference
6.6.32 Unrecognised Message Indication
Note: This message is only applicable to ITU-T operation.
This primitive is used to transit an unknown message type.
Message type
Unrecognised message
Mandatory parameters
• Message data
Optional parameters
None
6.6.33 User Information Indication
Note: This message is only applicable to ITU-T operation.
This primitive is issued to the application to convey user information received
from the remote party during call set-up (supplementary service 2) or during
the established (speech) phase of a call (supplementary service 3).
Message type
USR (User Information Message)
Mandatory parameters
• User to user information
Optional parameters
• Access transport
• Call reference
79
Section 6 Interface to Application
6.7 Parameter Definitions
The following section defines the parameters that are used in messages
between the local user and ISUP. The parameters are used in the parameter
area of ISP_MSG_TX_REQ (0xc700) and ISP_MSG_RX_IND (0x8701)
messages as detailed in the appropriate message specifications.
Where possible, parameters are defined by reference to either ITU-T Q.763
(1992), ITU-T Q.763 (1997), ITU-T Q.1902.3 (2000) or ANSI T1.113 (1995)
and the format of the parameter is identical to that formatted over the
network.
Where there are differences from the standards, or where additional
information is required for clarity, the parameter is described in subsequent
sub-sections. A set of notes after the table provides further detail where
necessary.
Note: The maximum and minimum length of parameters described below excludes the
name and length octets, whereas they are usually taken into account in ITU-T and
ANSI specs.
Refer to Appendix A: ISUP National Variants on page 171 for the list of
supported national specific parameters.
Parameter Name
Access delivery
information
Access transport 0x03 3 Q.763 Section 3.3
Application transport 0x78 120 Q763 Addenda (09/98) 3 255 1, 4
Automatic Congestion
Level
Automatic rerouting 0x96 150 Q.1902.3 (amd 3)
Backward call indicators 0x11 17 Q.763 Section 3.5 2 2
Backward GVNS 0x4d 77 Q.763 Section 3.62
Business group 0xc6 198 T1.113 Section 3.3A 9 255 1
Call diversion information 0x36 54 Q.763 Section 3.6 1 1 1
Call diversion treatment
indicators
Call history information 0x2d 45 Q.763 Section 3.7 2 2 1
Call offering treatment
indicators
Call reference 0x01 1 Q.763 Section 3.8
Call transfer number 0x45 69 Q.763 Section 3.64
Call transfer reference 0x43 67 Q.763 Section 3.65
Value Length
Hex Dec
0x2e 46 Q.763 Section 3.2 1 1 1
0x27 39 Q.763 Section 3.4
0x6e 110 Q.763 Section 3.72
0x70 112 Q.763 Section 3.74
Definition/Reference
Min Max
1 255 1
1 1
(09/97)
1 2 -
section 6.107
1 1 1
(09/97)
1 1 1
(09/97)
1 1 1
(09/97)
5 6 1, 2
T1.113 Section 3.5
2 18 -
(09/97)
1 1
(09/97)
Notes
80
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
Parameter Name
Value Length
Hex Dec
Definition/Reference
Min Max
Called directory number 0x1ed 493 Q.1902.3 section 6.15 2 18 Called party number 0x04 4 See Section 6.7.1 on
of this manual
page 86
Called IN number 0x6f 111 Q.763 Section 3.73
1 18 5
2 18 -
(09/97)
Calling geodetic location 0x81 129 Q.1902.3 section 6.15 8 255 1
Calling party geodetic
0x83 131 Q.1902.3 section 6.19 4 255 1
velocity information
Calling party number 0x0a 10 See Section 6.7.2 on
page 86
of this manual
2 18 -
Calling party’s category 0x09 9 Q.763 Section 3.11 1 1 Carrier identification 0xc5 197 T1.113 Section 3.8A 3 3 1
Carrier selection
information
Cause indicators 0x12 18 See Section 6.7.3 on
0xee 238 T1.113 Section 3.8B &
Q.1902.3 section 6.22
page 87
of this manual
1 1 1
2 255 -
CCNR possible indicator 122 0x7a Q.1902.3 section 6.24 1 1 CCSS 0x4b 75 Q.763 Section 3.63
1 1 1
(09/97)
Charge number 0xeb 235 T1.113 Section 3.10 1 13 1
Charged party
identification
0x71 113 Q.763 Section 3.75
(09/97)
1 255 1
Circuit assignment map 0x25 37 T1.113 Section 3.10B 4 4 1
Circuit group
0xe5 229 T1.113 Section 3.10A 1 1 1
characteristic indicator
Circuit group supervision
0x15 21 Q.763 Section 3.13 1 1 3
message type
Notes
Circuit identification
0xe8 232 T1.113 Section 3.11A 26 26 1
name
Circuit state indicator 0x26 38 Q.763 Section 3.14 2 32 3
Circuit validation
0xe6 230 T1.113 Section 3.11C 1 1 1
response indicator
Closed user group
0x1a 26 Q.763 Section 3.15 4 4 1
interlock code
Coding decoding
0xa5 165 Q.1902.3 section 6.31 1 255 1
processing
Collect call request 0x79 121 Q.763 Section 3.81
1 1 1
(09/97)
Conference treatment
indicators
0x72 114 Q.763 Section 3
(09/97)
1 1
Connected number 0x21 33 Q.763 Section 3.16 2 13 1
Connection request 0x0d 13 Q.763 Section 3.17 5 7 1
81
Section 6 Interface to Application
Parameter Name
Value Length
Hex Dec
Definition/Reference
Min Max
Notes
Continuity indicators 0x10 16 Q.763 Section 3.18 1 1 Correlation Id 0x65 101 Q.763 Section 3.70 1 255 1
Custom parameter 0x14 20 See Section 6.7.4 on
page 88
of this manual
Display information 0x73 115 Q.763 Section 3.77
1 255 4
1 255 1
(09/97)
Echo control information 0x37 55 Q.763 Section 3.19 1 1 Egress 0xc3 195 T1.113 Section 3.16A 1 255 1
Event information 0x24 36 Q.763 Section 3.21 1 1 Facility indicator 0x18 24 Q.763 Section 3.22 1 1 Forward call indicators 0x07 7 Q.763 Section 3.23 2 2 Forward GVNS 0x4c 76 Q.763 Section 3.66
3 26 1
(09/97)
Freephone indicators 0x41 65 ETS 300 356-1 1 1 1
Generic digits 0xc1 193 Q.763 Section 3.24 2 255 1, 4
Generic name 0xc7 199 T1.113 Section 3.20C 1 16 1
Generic notification
0x2c 44 Q.763 Section 3.25 1 1 1, 4
indicator
Generic number
0xc0 192 Q.763 Section 3.26 3 14 1, 4
(address)
Generic reference 0x42 66 Q.763 Section 3.27 3 255 1, 4
Global call reference 0xa4 164 Q.1902.3 section 6.48 6 255 1
Hop counter 0x3d 61 Q.763 Section 3.80
1 1 1
T1.113 Section 3.20D
HTR information 0x82 130 Q.1902.3 section 6.50 2 18 Information indicators 0x0f 15 Q.763 Section 3.28 2 2 Information request
0x0e 14 Q.763 Section 3.29 2 2 -
indicators
Inter nodal traffic group
0xa3 163 Q.1902.3 section 6.54 1 255 1
identifier
Jurisdiction 0xc4 196 T1.113 Section 3.23A 1 3 1
Location number 0x3f 63 Q.763 Section 3.30 3 13 1
Loop prevention
indicators
Message compatibility
0x44 68 Q.763 Section 3.67
1 1 -
(09/97)
0x38 56 Q.763 Section 3.33 1 1 -
information
MCID request indicators 0x3b 59 Q.763 Section 3.31 1 1 1
MCID response
0x3c 60 Q.763 Section 3.32 1 1 1
indicators
Message data 0xfa 250 See Section 6.7.5 on
of this manual
page 88
1 255 1
82
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
Parameter Name
Value Length
Hex Dec
Definition/Reference
Min Max
Notes
MLPP precedence 0x3a 58 Q.763 Section 3.34 6 6 1
Nature of connection
0x06 6 Q.763 Section 3.35 1 1 -
indicators
Network management
controls
0x5b 91 Q.763 Section 3.68
(09/97)
1 1 1
Network routing number 0x84 132 Q.1902.3 section 6.63 1 18 Network specific facility 0x2f 47 Q.763 Section 3.36 2 255 1
Network transport 0xef 239 T1.113 Section 3.24A 3 255 1
Notification indicator 0xe1 225 T1.113 Section 3.24B 1 1 1, 4
Number of metering
pulses
Number portability
0xff 255 See Section 6.7.6 on
page 89
of this manual
0x8d 141 Q.1902.3 section 6.65 1 255 1
1 1 1
forward information
Operator services
0xc2 194 T1.113 Section 3.24D 1 1 1
information
Optional backward call
0x29 41 Q.763 Section 3.37 1 1 -
indicators
Optional forward call
0x08 8 Q.763 Section 3.37 1 1 -
indicators
Original Called IN
0x7f 127 Q.1902.3 section 6.68 2 18 -
number
Original called number 0x28 40 Q.763 Section 3.38 2 13 1
Origination ISC point
0x2b 43 Q.763 Section 3.39 2 2 1
code
Originating line
0xea 234 T1.113 Section 3.26A 1 1 5
information
Outgoing trunk group
0xe7 231 T1.113 Section 3.26B 1 3 1
number
Parameter compatibility
information
0x39 57 Q.763 Section
3.41(09/97)
2 176 -
Pivot capability 0x7b 123 Q.1902.3 section 6.72 1 1 Pivot counter 0x87 135 Q.1902.3 section 6.73 1 1 Pivot routing backward
0x89 137 Q.1902.3 section 6.74 1 255 1
information
Pivot routing forward
0x88 136 Q.1902.3 section 6.75 1 255 1
information
Pivot routing indicators 0x7c 124 Q.1902.3 section 6.76 1 1 Pivot status 0x86 134 Q.1902.3 section 6.77 1 1 Propagation delay
0x31 49 Q.763 Section 3.42 2 2 1
counter
Query on Release
0x85 133 Q.1902.3 section 6.79 1 1 -
Capability
Range and status 0x26 22 Q.763 Section 3.43 1 33 3
83
Section 6 Interface to Application
Parameter Name
Value Length
Hex Dec
Definition/Reference
Min Max
Notes
Redirecting number 0x0b 11 Q.763 Section 3.44 2 13 1
Redirect backward
0x8c 140 Q.1902.3 section 6.81 1 255 1
information
Redirect capability 0x4e 78 Q.763 Section 3 Table 5 1 1 -
Redirect counter 0x77 119 Q.763 Section 3 Table 5 1 1 -
Redirect forward
0x8b 139 Q.1902.3 section 6.84 1 255 1
information
Redirect status 0x8a 138 Q.1902.3 section 6.85 1 1 Redirection information 0x13 19 Q.763 Section 3.45 1 2 1
Redirection number 0x0c 12 Q.763 Section 3.46 3 13 1
Redirection number
0x40 64 Q.763 Section 3.47 1 1 1
restriction indicator
Remote operations 0x32 50 Q.763 Section 3. 48 1 255 1
SCF ID 0x66 102 Q.763 Section 3.71 1 255 1
Service activation 0x33 51 Q.763 Section 3.49 1 255 1
Service code indicator 0xec 236 T1.113 Section 3.29D 1 10 1
Signalling point code 0x1e 30 Q.763 Section 3.50 2 3 1, 2, 5
Special processing
0xed 237 T1.113 Section 3.30A 1 1 1
request
Subsequent number 0x05 5 Q.763 Section 3.51 2 12 Suspend/resume
0x22 34 Q.763 Section 3.52 1 1 -
indicators
Tariff type 0xfe 254 See Section 6.7.7 on
page 89
of this manual
1 1 1
Transaction request 0xe3 227 T1.113 Section 3.31B 6 255 1
Transit network selection 0x23 35 Q.763 Section 3.53 2 255 1
Transmission medium
0x02 2 Q.763 Section 3.54 1 1 -
requirement
Transmission medium
0x2e 62 Q.763 Section 3.55 1 1 1
requirement prime
Transmission medium
0x35 53 Q.763 Section 3.56 1 1 1
requirement used
UID action indicators 0x74 116 Q.763 Section 3.78
2 2 -
(09/97)
UID capability indicators 0x75 117 Q.763 Section 3.79
2 2 -
(09/97)
Unrecognised parameter 0xf9 249 See Section 6.7.8 on
page 90
of this manual
3 255 4
User service information 0x1d 29 Q.763 Section 3.57 2 11 1
84
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
Parameter Name
User service information
prime
User-to-user indicators 0x2a 42 Q.763 Section 3.53 1 1 User-to-user information 0x20 32 Q.763 Section 3.61 1 129 1
User teleservice
information
Value Length
Hex Dec
0x30 48 Q.763 Section 3.58 2 11 1
0x34 52 Q.763 Section 3.59 2 3 1
Definition/Reference
Min Max
Notes
Notes
• The ISUP module transports this parameter transparently without
verifying its format.
• The length of this parameter depends on the length of a point code.
• This parameter is generated within the ISUP module and is not passed
across the user interface.
• This parameter may be repeated. Refer to Appendix E for further
information.
• The minimum length of this parameter may differ depending on the ISUP
variant used:
Minimum Parameter Length
Parameter Name
Called party number 2 1
Originating line information - 1
Signalilng point code 2 3
ITU ANSI
Figure 1. Notation used for Parameter Specifications
The notation used for the parameter specifications is shown below:
MSB 7 6 5 4 3 2 LSB
Parameter name and value
Parameter length (in octets)
1 First octet of parameter
2
:
n Final octet of parameter
85
Section 6 Interface to Application
6.7.1 Called Party Number
The format of the called party number is defined in ITU-T Q.763 Section 3.9.
Due to the importance of the parameter is also shown in the following figure:
Figure 2. Format of the Called Party Number Parameter
8 7 6 5 4 3 2 1
Name = 00000100 (4)
Length = 2 - 18
ODD/
1
EVEN
2 INN
Ind.
3 2nd address signal 1st address signal
:
n Filler (if necessary) Nth address signal
Numbering plan Spare
For ANSI, the Called party number parameter is defined in T1.113 Section
3.6. If the Nature of Address Indicator indicates that “no number present”
octets 2-n of the parameter are omitted.
Nature of address indicator
6.7.2 Calling Party Number
The format of the calling party number parameter is defined in ITU-T Q.763
Section 3.10. Due to the importance of the parameter it is also shown in the
following figure:
Figure 3. Format of the Calling Party Number Parameter
8 7 6 5 4 3 2 1
Name = 00001010 (10)
Length = 2 – 18
ODD/
1
EVEN
2 NI Numbering plan Presentation
2nd address signal 1st address signal
:
n Filler (if necessary) Nth address signal
Nature of address indicator
indicator
Screening
indicator
86
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.7.3 Cause Indicators
The format of the cause indicators parameter is defined in ITU-T Q.763
Section 3.12. Due to the importance of the parameter it is also shown in the
following figure:
Figure 4. Format of the Cause Indicators Parameter
8 7 6 5 4 3 2 1
Name = 00010010 (18)
Length = 2 - 255
1 Ext. Coding standard Spare Location
2 Ext. Cause value
3 First octet of diagnostics (if any)
:
n Last octet of diagnostics (if any)
The following table lists the release cause values that are used in the Release
indication sent to the application when call processing timers expire.
Table 2. Release Cause Values used in the Release indication sent to the
Application when Call Processing Timers Expire
Timer Cause
Timer Description Value Description
T2 Waiting for RES after (user) SUS is
received
T3 Started on receipt of overload message 31 Normal, unspecified
T6 Waiting for RES after (network) SUS i s
received
T7 Waiting for ACM 31 Normal, unspecified
T8 Waiting for COT 41 Temporary failure
T9 Waiting for ANM 19 No answer from user (user
T35 Waiting for ST digit 28 Address incomplete
T38 Waiting for RES after (network) SUS is
received in an international exchange
102 Recovery on timer expiry
102 Recovery on timer expiry
alerted)
- timer not supported
87
Section 6 Interface to Application
6.7.4 Custom Parameter
The custom parameter is not defined by ITU-T or ANSI. It is a proprietary
parameter which is used for sending and receiving user defined parameters
between the user and the network in either direction. The user defined
parameter is encapsulated inside this special parameter which is reserved for
this purpose. The encapsulated user defined parameter is encoded as it would
appear in a message received from the network in name-length-data format.
Figure 5. Format of the Custom Parameter
8 7 6 5 4 3 2 1
Name = 00010100 (20)
Length = 3 – 255
1 Parameter name (as received from network)
2 Length of parameter (ie ‘Length – 2)
3 First octet of data (message type)
4 Second octet of data
:
n Last octet of data
6.7.5 Message Data
The message data parameter is not defined by ITU-T or ANSI. It is a
proprietary parameter which is used to convey whole messages transparently
between the user and the network in either direction. The data contained in
the parameter commences with the message type octet and continues with
the data in the exact format that it is conveyed to the network.
Figure 6. Format of the Message Data Parameter
8 7 6 5 4 3 2 1
Name = 11111010 (250)
Length = 1 – 255
1 First octet of data (message type)
2 Second octet of data
:
n Last octet of data
This parameter is used by ISUP to convey whole messages transparently
(e.g. PAM, ‘Generic’ CRG and unrecognized messages).
Pass Along message
The message data parameter may be used by ISUP to signal the content of a
received Pass Along Message to the user (the ISPXGOP_TRAN_PAM circuit
group option must be set).
88
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
The first byte of the data field contains the message type (this is the message
type contained in the PAM e.g. IAM, REL) followed by the rest of the message
data which is encoded as it would appear in a message received from the
network.
‘Generic’ Charge message
The message data parameter may be used to convey the entire national
specific Charge message within the generic Charge message and the
information is sent in transparent format to the user (the ISPX1GOP_TX_CRG
circuit group option must be set).
The data field contains all the parameters contained within the Charge
message.
Unrecognised message
The message data parameter may be used by ISUP to signal the content of a
received unrecognized message to the user (depending on the setting of the
ISPGXOP_COMPAT circuit group option).
The first byte of the data field contains the message type.
6.7.6 Number of Metering Pulses
The number of metering pulses parameter is not defined by ITU-T. It is a
proprietary parameter which is used to convey a number of metering pulses.
The format of the parameter is as follows:
Figure 7. Format of the Number of Metering Pulses Parameter
8 7 6 5 4 3 2 1
Name = 11111111 (255)
Length = 1
Number of metering pulses
6.7.7 Tariff Type
The tariff type parameter is not defined by ITU-T. It is a proprietary
parameter which is used to convey a tariff type. The format of the parameter
is as follows:
Figure 8. Format of the Tariff Parameter
8 7 6 5 4 3 2 1
Name = 11111110 (254)
Length = 1
1 Tariff type
89
Section 6 Interface to Application
6.7.8 Unrecognised Parameter
The Unrecognised parameter is used to convey parameter types that are
proprietary or unknown by the ISUP module. The format of the unrecognised
parameter is shown in
unknown parameter will be performed within the ISUP module.
If a received unknown parameter is to be conveyed, the entire unknown
parameter (the name, length and data) must be encapsulated within the
‘data’ area of the unrecognised parameter. The per-circuit group
ISPGOP_COMPAT option must also be set to an appropriate value to enable
the required handling to be performed when such parameter types are
received by the ISUP module. Refer to
Request
Figure 9. Format of the Unrecognised Parameter
on page 126 for details.
8 7 6 5 4 3 2 1
Name = 11111001 (249)
Length 3 – 255
1 Parameter name
2 Length of parameter
3 First octet of data
:
n Last octet of data
Figure 9 below. No checking of the data in the
Section :
8.2 Configure Circuit Group
6.8 Use of Call Control Primitives
6.8.1 Call Clearing Procedure
The ISUP module supports a full handshake mechanism during call release.
This is known as the Application Controlled Release mechanism. It ensures
that the ISUP module has received a release action from both the network
and the user before it considers the circuit idle.
This is significant in the case where the network sends IAM on a circuit
immediately after sending clear forward. Early versions of the ISUP module
acknowledged the clear forward with a release guard at the same time as
issuing a Release Indication to the user. In the case of user failure or where
the user was slow in sending a Release Request, the user could
unintentionally release the new incoming call.
The use of the Application Controlled Release mechanism prevents these
problems.
Configuration
The ISPF_ACR and ISPF_NAI options in the module configuration message
must be set to activate the Application Controlled Release mechanism in
ISUP.
90
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
Note: All new user applications should make use of the Application Controlled Release
mechanism.
Procedure
If the user receives a Release Indication (REL) message from ISUP:
• The user application must acknowledge it immediately with a Release
Response (RLC). The user must then wait until the ISUP module
responds with a Release Confirmation (RLC) before attempting a new call
on this circuit.
• ISUP will continue to send Release Indication until the user issues Release
Response. The user application may send a Release Request prior to the
Release Response. (This may be useful if it is not possible for the
application to complete release of the circuit immediately.) If a Setup
Indication is received from the network before the user issues a Release
Response the circuit will automatically be blocked. When the user does
issue the Release Response the circuit is automatically unblocked.
• If the Release Indication has been generated by ISUP (without ISUP
having received a Release Indication from the network) this normally
indicates that an error condition such as timer expiry has occurred. In
such cases, the ISUP module will continue to send Release Indications to
the user until such time the user sends a Release Response. ISUP
should then send a Release Confirmation to the user.
If the user application sends a Release Request (REL) to ISUP:
• The user application must wait for the ISUP module to acknowledge it
with a Release Confirmation primitive before attempting a new call on
that circuit.
If the user application attempts to set-up a new call before the ISUP module
has sent Release Confirmation, the Setup Request will be discarded and a
maintenance event will be indicated to the Maintenance module.
6.8.2 Call Collision Procedure
In order to ensure that the correct behavior is taken by the ISUP module
when a call collision (or glare) condition is detected, bits 0-1 in the <option>
field in the Configure Circuit Group Request message (0x7701) must be set to
the required value (refer to
page 126
).
Setting the appropriate circuit group option will assign one end of the circuit
to be slave and the other to be master. For example, if bits 0 and 1 are set
to one i.e. “Outgoing call priority on all circuits” then this end of the circuit
will be master.
For the ISUP module, there are two types of call collision: external call
collision and internal call collision. These are described in the following subsections.
Section : 8.2 Configure Circuit Group Request on
91
Section 6 Interface to Application
External Call collision
This is when the call collision occurs between the ISUP module and the
network i.e. the network sends an IAM to ISUP at the same time as ISUP
sends an IAM to the network.
Figure 10. Example of an External Call Collision where this End of the Circuit is
Master
USER
APPLICATION
ISUP
MODULE
NETWORK
IAM
IAM
IAM
If this end of the circuit is master, the network should always accept the
outgoing call. Therefore, when an (outgoing) IAM is received from the user
application and a second (incoming) IAM is received from the network
causing an external call collision condition, the outgoing IAM received from
the application will be sent to the network. However, this means that the
incoming IAM will not be passed to the user application and consequently
shall be discarded. If this condition occurs, the user application will not be
aware that a call collision condition has occurred.
92
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
Figure 11. Example of an External Call Collision where this end of the Circuit is Slave
USER
APPLICATION
ISUP
MODULE
NETWORK
IAM
IAM
IAM
If this end of the circuit is slave, the application should always accept the
incoming call. Therefore, when an (outgoing) IAM is received from the
application and an (incoming) IAM is received from the network causing an
external call collision condition, the incoming IAM received from the network
will be passed to the application. The outgoing IAM will be discarded by the
far end, hence, it will not be necessary to release the outgoing call attempt.
If this situation occurs, it will be the user application’s responsibility to re-try
the outgoing call on another circuit.
IAM
Internal Call Collision
This is when the call collision occurs between the user application and the
ISUP module i.e. the application sends an IAM to ISUP at the same time as
ISUP sends an IAM to the application.
Figure 12. Example of an Internal Call Collision
USER
APPLICATION
ISUP
MODULE
IAM
IAM
Internal call collision is indistinguishable from external call collision where this
end is configured to slave. Therefore, when an internal call collision is
detected the user application should always accept the incoming call.
NETWORK
IAM
93
Section 6 Interface to Application
6.8.3 Hop Counter Procedure
The ITU-T Recommendation Q.764 (09/97) specifies a hop counter procedure
which is designed to detect routing errors introduced when configuration
changes are made for instance when new circuits are added. A hop counter
parameter may optionally be included in a Setup Request primitive and its
value is decremented at each exchange. This is a temporary problem and the
hop counter procedure is optional.
Configuration
To activate the hop counter procedure, the initial hop count value should be
configured and set in the ‘ihop’ per circuit group parameter in the Configure
Circuit Group Request message (0x7701) message (refer to
Configure Circuit Group Request on page 126).
Note that the hop counter procedure will not be activated if the initial hop
counter value is set to zero.
Procedure
If the hop counter procedure is activated (i.e. initial hop count value is
greater than zero):
• If the hop counter parameter (refer to Section : 6.7 Parameter Definitions
on page 80) is present in the Setup Request primitive, the value of the
hop counter parameter will be decremented by one. However, if the
value of the hop counter reaches zero signifying that a routing error has
been detected, ISUP will release the call by sending a Release indication
with cause #25 (exchange routing error) to the user application. In order
to return the circuit to the idle state the call clearing sequences as
described in
apply. A Maintenance Event Indication with status CCm_CC_Zero_hops
(0x3b) will also be reported indicating the circuit on which the routing
error was detected.
• If the Setup Request primitive does not contain a hop counter parameter,
a hop counter parameter will be added, by ISUP, to the Setup Request
primitive (before the it is sent to the network) and the value of the hop
counter will be set to the initial hop count value.
Section : 6.8.1 Call Clearing Procedure on page 90 shall
Section :
8.2
94
Note: If the hop counter parameter is to be included, an additional 3 bytes will be added
to the Setup Request primitive.
If the hop counter procedure is not activated (i.e. initial hop count value is
set to zero):
• If the hop counter parameter is present in the Setup Request primitive,
the value of the hop counter parameter will not be decremented but will
be included and conveyed in the Setup Request primitive.
• If the Setup Request primitive does not contain a hop counter parameter,
a hop counter parameter will not be added, by ISUP, to the Setup
Request primitive.
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
6.8.4 Continuity Testing
Incoming circuits
There are two situations where continuity checks on incoming circuits may
occur:
• When a Continuity check request (CCR) message is received for an idle
circuit.
• When a continuity check is performed on an incoming circuit during call
set up.
In order to support continuity checks on idle circuits, the Circuit seized
indication (SZE) primitive is used. This primitive is not defined by ITU or
ANSI but is used by the ISUP module to indicate that the circuit has been
seized and the format of this primitive is described in
Seized Indication on page 60. The Circuit seized indication is sent by ISUP to
the application to indicate that the circuit is in use but the call cannot be
routed at present.
On receipt of the Circuit seized indication, the application should mark the
circuit as being busy so that it is not available for selection for an outgoing
call). One way of achieving this would be to introduce a “circuit seized” state
in the application. The application should remain in this state until either a
Setup indication is received (in which case the call should proceed as normal)
or else a Release indication is received (in which case the call is released as
described in
The following subsections show a number of different example scenarios
where a continuity check is made on an incoming circuit.
See Section 8.3: Configure Timers Request on page 136 for details.
Section : 6.8.1 Call Clearing Procedure on page 90).
Section :
6.6.4 Circuit
95
Section 6 Interface to Application
Successful continuity test call
When a Continuity check request (CCR) message is received, a Circuit seized
indication (SZE) is sent to the application. The Circuit seized indication will
contain the Nature of connection indicators with the Continuity check
indicator set to “continuity check required on this circuit”, indicating that the
application should apply the check loop.
Once the continuity test has completed successfully, the call will be cleared
from the network and call release to the application proceeds as normal.
Figure 13. Example of a Successful Continuity Check Request Message Received
USER
APPLICATION
ISUP
MODULE
NETWORK
CCR CCR
REL REL
RLC
RLCRLC
96
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
)
Unsuccessful continuity test call
When the CCR message is received, a Circuit seized indication (SZE) is sent
to the application as above. In this case, a COT message is received from the
network, indicating that the continuity test was unsuccessful. The call is
released to the application, except that no Release confirmation (RLC) is sent
at this stage. This ensures that the circuit does not go idle because a CCR
message is expected. When the second CCR is received, a Circuit seized
indication (SZE) is sent to the application. Note that the application needs to
be able to handle this primitive in the state where it would normally be
expecting Release confirmation (RLC).
The check loop should be removed when the application receives the Release
indication (REL) and re-applied when the Circuit seized indication (SZE) is
received. Removing and re-applying the loop (rather than leaving it in place
while waiting for the continuity re-check) avoids the possibility that the
continuity check continually fails because the loop was not correctly applied
the first time.
Figure 14. Example of a Continuity Check Request Message Received (Unsuccessful
Continuity Check followed by Successful Continuity Check)
USER
APPLICATION
ISUP
MODULE
NETWORK
SZE
COT (failure)
COT (failure
CCR
REL
RLC
SZE
REL
CCR
REL
RLC
RLC
RLC
97
Section 6 Interface to Application
)
A
A
Successful continuity check during call set up
A COT message is received from the network, indicating that the continuity
test was successful and the call should be allowed to proceed in the normal
manner.
Figure 15. Example of a Successful Continuity Check Received During Incoming Call
Set Up
USER
APPLICATION
ISUP
MODULE
NETWORK
IAM
IAM
COT (success)
COT (success
CM
NM
ACM
ANM
Call in Speech State: Proceed as usual
98
Dialogic® SS7 Protocols ISUP Programmer's Manual Issue 15
)
Unsuccessful continuity check during call set up
When the COT message is received from the network, indicating that the
continuity test was unsuccessful, the call is released to the application, except
that no Release confirmation (RLC) is sent at this stage because a CCR
message is expected. When the CCR is received, a Circuit seized indication
(SZE) is sent to the application.
Figure 16. Example of an Unsuccessful Continuity Check Received During Incoming
Call Set Up
USER
APPLICATION
COT (failure)
IAM
ISUP
MODULE
NETWORK
IAM
COT (failure
REL
RLC
SZE
CCR
REL
REL
REL
RLC
RLC
99
Section 6 Interface to Application
A
ANSI operation
In ANSI, the Loop Back Acknowledgement request (LPA) message is used to
indicate that the continuity check loop has been successfully applied this
primitive is described in Section
Request
on page 38.
6.5.16: Loop Back Acknowledgement
Figure 17. Example of a Continuity Check Request Message Received (ANSI)
USER
APPLICATION
ISUP
MODULE
NETWORK
LPA
CCR
LP
CCR
REL
REL
RLC
RLC
RLC
100
Loading...