DSI Protocol Stacks - Dialogic/media/manuals/ss7/cd/GenericInfo/...Dialogic® DSI Protocol Stacks ISUP Programmer's Manual Issue 17 3 Contents Revision History ... A.4 Nortel RLT

www.dialogic.com

Dialogic® DSI Protocol Stacks ISUP Programmer's Manual

2

Copyright© 2003-2012 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 Dialogic Corporation or its subsidiaries (“Dialogic”). Reasonable effort is made to ensure the accuracy of the

information contained in the document. However, Dialogic does not warrant the accuracy of this information and cannot accept

responsibility for errors, inaccuracies or omissions that may be contained 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 LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC 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 sustaining, 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 intellectual 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, Cantata, 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: May 2012

Dialogic® DSI Protocol Stacks ISUP Programmer's Manual Issue 17

3

Contents

Revision History ............................................................................................................ 8

1 About this Publication ....................................................................................... 11

1.1 Introduction ......................................................................................................................... 11 1.2 Abbreviations ....................................................................................................................... 11 1.3 Related Documentation ......................................................................................................... 12 1.4 Feature Overview ................................................................................................................. 13

2 General Description ........................................................................................... 14

2.1 Module Overview .................................................................................................................. 14 2.2 Module Configuration ............................................................................................................ 14

2.2.1 Customizing ISUP variants ......................................................................................... 15

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 ............................................................................. 18

4.1 System Functions ................................................................................................................. 18 4.2 Timer Operation ................................................................................................................... 18

5 Interface to MTP ................................................................................................ 19

6 Interface to Application ..................................................................................... 20

6.1 Introduction ......................................................................................................................... 20 6.2 Application Message - Header Format ...................................................................................... 20

6.2.1 Transmit Request ..................................................................................................... 20 6.2.2 Receive Indication .................................................................................................... 21

6.3 Application Message - User Data Format .................................................................................. 22 6.4 Parameter Extension Mechanism ............................................................................................ 23 6.5 Application Messages to ISUP ................................................................................................. 23

6.5.1 Alerting Request ....................................................................................................... 25 6.5.2 Application Transport Request .................................................................................... 27 6.5.3 „Generic‟ Charge Request .......................................................................................... 28 6.5.4 Circuit Seized Request .............................................................................................. 28 6.5.5 Collection Charging Request ...................................................................................... 29 6.5.6 Confusion Request .................................................................................................... 29 6.5.7 Continuity Request ................................................................................................... 29 6.5.8 End-to-End Message Request ..................................................................................... 30 6.5.9 Exit Request 30 6.5.10 Facility Request ........................................................................................................ 30 6.5.11 Facility Response ...................................................................................................... 32 6.5.12 Forward Transfer Request .......................................................................................... 33 6.5.13 Identification Request ............................................................................................... 33 6.5.14 Identification Response ............................................................................................. 33 6.5.15 Information Request ................................................................................................. 34 6.5.16 Loop Back Acknowledgement Request ......................................................................... 35 6.5.17 Loop Prevention Request ........................................................................................... 35 6.5.18 Network Resource Management Request ..................................................................... 36 6.5.19 Overload Request ..................................................................................................... 36 6.5.20 Pre-Release Information Request ............................................................................... 37

Contents

4

6.5.21 Proceeding request ................................................................................................... 37 6.5.22 Progress Request ...................................................................................................... 38 6.5.23 Release Response ..................................................................................................... 40 6.5.24 Release Request ....................................................................................................... 40 6.5.25 Request Information Request ..................................................................................... 41 6.5.26 Resume Request ...................................................................................................... 42 6.5.27 Segmentation Request .............................................................................................. 42 6.5.28 Setup Request.......................................................................................................... 43 6.5.29 Setup Response ....................................................................................................... 45 6.5.30 Subsequent Directory Number Request ....................................................................... 48 6.5.31 Suspend Request ...................................................................................................... 48 6.5.32 Unrecognised Message Request .................................................................................. 49 6.5.33 User Information Request .......................................................................................... 49

6.6 Application Messages from ISUP ............................................................................................. 50 6.6.1 Alerting Indication .................................................................................................... 52 6.6.2 Application Transport Indication ................................................................................. 55 6.6.3 „Generic‟ Charge Indication ........................................................................................ 55 6.6.4 Circuit Seized Indication ............................................................................................ 56 6.6.5 Collection Charging Indication .................................................................................... 56 6.6.6 Confusion Indication ................................................................................................. 56 6.6.7 Continuity Indication ................................................................................................. 57 6.6.8 End-to-End Message Indication .................................................................................. 57 6.6.9 Exit Indication .......................................................................................................... 57 6.6.10 Facility Indication ..................................................................................................... 58 6.6.11 Facility Confirmation ................................................................................................. 59 6.6.12 Forward Transfer Indication ....................................................................................... 60 6.6.13 Identification Indication ............................................................................................. 60 6.6.14 Identification Confirmation ......................................................................................... 61 6.6.15 Information Indication ............................................................................................... 61 6.6.16 Loop Back Acknowledgement Indication ...................................................................... 62 6.6.17 Loop Prevention Indication ......................................................................................... 63 6.6.18 Network Resource Management Indication ................................................................... 63 6.6.19 Overload Indication ................................................................................................... 64 6.6.20 Pre-Release Information Indication ............................................................................. 64 6.6.21 Proceeding Indication ................................................................................................ 65 6.6.22 Progress Indication ................................................................................................... 66 6.6.23 Release Confirmation ................................................................................................ 67 6.6.24 Release Indication .................................................................................................... 67 6.6.25 Request Information Indication .................................................................................. 68 6.6.26 Resume Indication .................................................................................................... 69 6.6.27 Segmentation Indication ............................................................................................ 69 6.6.28 Setup Confirmation ................................................................................................... 70 6.6.29 Setup Indication ....................................................................................................... 72 6.6.30 Subsequent Directory Number Indication ..................................................................... 74 6.6.31 Suspend Indication ................................................................................................... 75 6.6.32 Unrecognised Message Indication ............................................................................... 75 6.6.33 User Information Indication ....................................................................................... 75

6.7 Parameter Definitions ............................................................................................................ 76 6.7.1 Called Party Number ................................................................................................. 82 6.7.2 Calling Party Number ................................................................................................ 82 6.7.3 Cause Indicators....................................................................................................... 83 6.7.4 Custom Parameter .................................................................................................... 84 6.7.5 Message Data84 6.7.6 Number of Metering Pulses ........................................................................................ 85 6.7.7 Tariff Type 85 6.7.8 Unrecognised Parameter ............................................................................................ 86

6.8 Use of Call Control Primitives .................................................................................................. 86 6.8.1 Call Clearing Procedure ............................................................................................. 86 6.8.2 Call Collision Procedure ............................................................................................. 87 6.8.3 Hop Counter Procedure ............................................................................................. 90 6.8.4 Continuity Testing..................................................................................................... 91 6.8.5 Malicious Call Identification (MCID) Supplementary Service ......................................... 104


5

6.8.6 Message Segmentation ........................................................................................... 105 6.8.7 Automatic Circuit Group Blocking ............................................................................. 105 6.8.8 BICC Application Transport ...................................................................................... 107

7 Management Interface .................................................................................... 108

7.1 Introduction ....................................................................................................................... 108 7.2 Circuit Group Supervision Control Request ............................................................................. 109 7.3 Circuit Group Supervision Control Confirmation ...................................................................... 110 7.4 Circuit Group Supervision Control Indication .......................................................................... 111 7.5 Circuit Group Supervision Status Indication ............................................................................ 112 7.6 Local Overload Request ....................................................................................................... 113 7.7 Remote Point Code Status Indication ..................................................................................... 114

8 Non-Primitive Interface ................................................................................... 116

8.1 Configure Request .............................................................................................................. 116 8.2 Configure Circuit Group Request ........................................................................................... 121 8.3 Configure Timers Request .................................................................................................... 131

8.3.1 Timer default values ............................................................................................... 134 8.4 End Circuit Group Request ................................................................................................... 136 8.5 Variant Initialisation ............................................................................................................ 137 8.6 Custom Parameter Configuration .......................................................................................... 138 8.7 Change Circuit Group Configuration Request .......................................................................... 139 8.8 Read RAM Request .............................................................................................................. 141 8.9 Read Circuit Group Request ................................................................................................. 141 8.10 Read Circuit Request ........................................................................................................... 142 8.11 Read Revision Request ........................................................................................................ 142 8.12 Read Circuit Group Status Request ....................................................................................... 143 8.13 Read Circuit Group Statistics Request .................................................................................... 147 8.14 Read Circuit Group Data Request .......................................................................................... 148 8.15 Read Circuit Group Identity Request ..................................................................................... 148 8.16 Send Maintenance Event Mask Request ................................................................................. 149 8.17 Send Software Event Mask Request ...................................................................................... 150 8.18 Trace Mask Configuration Request ........................................................................................ 151 8.19 Send Selective Trace Event Mask Request .............................................................................. 154 8.20 Maintenance Event Indication ............................................................................................... 155 8.21 Software Event Indication .................................................................................................... 159 8.22 Management Event Indication .............................................................................................. 162 8.23 Trace Event Indication ......................................................................................................... 163 8.24 Selective Trace Event Indication ........................................................................................... 164 8.25 Heartbeat Request/Indication ............................................................................................... 166

Appendix A: ISUP National Variants ......................................................................... 168

A.1 German ISUP ..................................................................................................................... 168 A.2 UK ISUP ............................................................................................................................ 169 A.3 Japan (TTC) ISUP ............................................................................................................... 170 A.4 Nortel RLT ......................................................................................................................... 171

A.4.1 Nortel RLT (ANSI)................................................................................................... 171 A.4.2 Nortel RLT (ITU) ..................................................................................................... 172

A.5 Italian ISUP ....................................................................................................................... 173 A.6 French ISUP ....................................................................................................................... 174 A.7 China ISUP ........................................................................................................................ 175 A.8 Finnish ISUP ...................................................................................................................... 177 A.9 BICC ................................................................................................................................. 177

Appendix B: Messages Currently Supported by the ISUP Module .............................. 179

B.1 ITU-T Messages .................................................................................................................. 179 B.2 ITU-T Parameters ............................................................................................................... 180 B.3 ANSI T1.113 Messages ........................................................................................................ 184

Contents

6

B.4 ANSI T1.113 Parameters...................................................................................................... 185

Appendix C: Message Type Table .............................................................................. 187

Appendix D: ISUP Configuration Option Settings ...................................................... 189

Appendix E: ISUP Repeat Parameters ....................................................................... 192

Appendix F: Timer Services ...................................................................................... 193

F.1 Keep Time ......................................................................................................................... 193 F.1 Timer Expiry....................................................................................................................... 194

Index 195

Figures Figure 1. Notation used for Parameter Specifications ................................................................. 81 Figure 2. Format of the Called Party Number Parameter ............................................................. 82 Figure 3. Format of the Calling Party Number Parameter ............................................................ 82 Figure 4. Format of the Cause Indicators Parameter .................................................................. 83 Figure 5. Format of the Custom Parameter ............................................................................... 84 Figure 6. Format of the Message Data Parameter ...................................................................... 84 Figure 7. Format of the Number of Metering Pulses Parameter .................................................... 85 Figure 8. Format of the Tariff Parameter .................................................................................. 85 Figure 9. Format of the Unrecognised Parameter ....................................................................... 86 Figure 10. Example of an External Call Collision where this End of the Circuit is Master .................... 88 Figure 11. Example of an External Call Collision where this end of the Circuit is Slave...................... 89 Figure 12. Example of an Internal Call Collision........................................................................... 89 Figure 13. Example of a Successful Continuity Check Request Message Received ............................ 92 Figure 14. Example of a Continuity Check Request Message Received (Unsuccessful Continuity Check

followed by Successful Continuity Check) .................................................................... 93 Figure 15. Example of a Successful Continuity Check Received During Incoming Call Set Up ............ 94 Figure 16. Example of an Unsuccessful Continuity Check Received During Incoming Call Set Up ....... 95 Figure 17. Example of a Continuity Check Request Message Received (ANSI) ................................. 96 Figure 18. Example of a T36 Expiry ........................................................................................... 97 Figure 19. Example of a Successful Continuity Check Request Message Sent .................................. 99 Figure 20. Example of a Continuity Check Request Message Sent (Unsuccessful Continuity Check

Followed By Successful Continuity Check) ................................................................. 100 Figure 21. Example of a Continuity Check Success Outgoing Call Set Up ...................................... 101 Figure 22. Example of a Continuity Check Success during Outgoing Call Set Up ............................ 102 Figure 23. Example of a Call collision where the Incoming Call has Priority ................................... 103 Figure 24. Example of a Reset Circuit Received During a Continuity Test Call ................................ 104

Tables Table 1. All Application Messages sent by the ISUP Module to the User Application ....................... 50 Table 2. Release Cause Values used in the Release indication sent to the Application when Call

Processing Timers Expire .......................................................................................... 83 Table 3. ISUP Module Confirmation Message Statuses............................................................. 108


7

Revision History

8

Revision History

Issue Date Description

17 May 2012 Corrections for German ISUP

16 March 2011 Support for ISUP circuit group measurements.

Extend German ISUP support.

Per group options ISPX1GOP_NO_EOOP, ISP1GOP_NOCUG, ISPX1GOP_IC_CPG and ISPX1GOP_SLS8 added.

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 ISUP, and Finnish ISUP added.

MPM added.

Redirecting parameter now supported in TTC IAM.

11 August 2001 Support for user custom optional parameter. 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.

10 December 1999 Continuity check and circuit seized added. 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.


9

Issue Date Description

9 July 1998 Point code length, SIO value, UCIC option and timer values may now be configured on 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.

8 May 1997 A circuit group may now be ended without having to restart the module. This allows 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.

7 September 1996 Now supports ITU-T 1992 messages and parameters (whilst allowing Blue Book only 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.

6 May 1996 Now supports ANSI operation as a run-time configuration option. Circuit group configuration message parameter definitions changed to allow the optional use of 24bit point codes.

5 April 1996 Call clearing mechanism modified to require a response from the application in all 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.

4 April 1996 Backward call indicators in ANM sent to ISUP module are now optional and if omitted 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.

3 August 1995 New messages added: ISP_MSG_STATUS_IND, ISP_MSG_OVLD_REQ, 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

2 February 1994

1 September 1993

Revision History

10

Note: The latest release issue of this guide can be found at: http://www.dialogic.com/support/helpweb/signaling

http://www.dialogic.com/support/helpweb/signaling


11

1 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. Appendix B on page 179 lists the ITU-T ISUP and the ANSI T1.113 ISUP messages and parameters that are currently supported by the module.

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

Section 1 About this Publication

12

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

part functional description

[3] ITU-T recommendation Q.762, Signalling System No.7 ISDN User part general functions of messages and signals

[4] ITU-T recommendation Q.763 Signalling System No.7 ISDN User part format and codes

[5] ITU-T recommendation Q.764, Signalling System No.7 ISDN User

part signalling procedures

[6] ITU-T recommendation Q.765 (2000), Signalling System No. 7 – Application transport mechanism

[7] ITU-T recommendation Q.767, Application of the ISDN user part of CCITT signalling system No. 7 for international ISDN interconnections

[8] ETSI standard 300 356-1, Integrated Services Digital Network (ISDN); Signalling System No.7

[9] ANSI recommendation T1.113, Signalling System No.7 Integrated Services Digital Network (ISDN) User Part

[10] UK ISUP Specification: PNO-ISC Specification Number 007 ISDN User Part (ISUP)

[11] German ISUP Specification: Zeichengabe im ZZN7 Version 3.0.0

[12] 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

[13] Italian ISUP Specification: Specifica Tecnica N.763

[14] Nortel RLT (ANSI) Specification: Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 297-2621-345 Preliminary 04.01 August 1999

[15] Nortel RLT (ITU) Specification: 411- 2131-199 Standard 08.04

August 1998 Wireless Networks DMS-MTX Software Delta for Planners MTX07

[16] Japan (TTC) ISUP Specification: JT-Q761-JT-Q764 and JT-Q850

[17] U10SSS, Software Environment Programmer's Manual

[18] French ISUP Specification: SPIROU 1998 – 002-005 edition 1

[19] China ISUP Specification: YDN 038 (1997)

[20] Finnish ISUP Specification: SFS 5779 Signalling in the public switched

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)

[21] ITU-T Recommendation Q.1901, Bearer Independent Call Control Protocol

[22] ITU-T Recommendation Q.1902.1, Bearer Independent Call Control protocol (Capability Set 2): Functional description


13

[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 independent 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] ITU-T Recommendation Q.1902.5 (2001), Exception

[27] 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.

Section 2 General Description

14

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.


15

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 Section 8.6 on page 138 and Section 8.7 on page 139 for further details.

The variant-based mechanism may be initialized as follows:

1. Configure the ISUP module using the Configure Request message (0x7700) as described in Section 2.2: Module Configuration on page 14.

2. Two „custom‟ variant values are specifically reserved for this procedure as shown in the following table (refer to the <variant> parameter in Section 8.2: Configure Circuit Group Request on page 121):

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.

Section 2 General Description

16

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.


17

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.

Section 4 Interface to System Services

18

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 no message is ready.

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.

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 193.


19

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® SS7 Protocols.

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.

Section 6 Interface to Application

20

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 Section 4: Interface to System Services on page 18.

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:

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)


21

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)

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.


22

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

Parameter Parameter Parameter Zero

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 Parameter Parameter Zero

Parameter Name

Parameter Length

Parameter

Data

1 byte 1 byte „Length‟ bytes (1 to 255)

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 23 and Section 6.6 on page 50. All applicable parameters for each message are listed in the following sub-sections (refer also to Appendix A: ISUP National Variants on page 168) and a list of all supported parameters are provided in Section 6.7: Parameter Definitions on page 76.


23

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

Parameter Name - 256

Parameter Length

Parameter Data

1 byte 1 byte 1 byte 1 byte „Length‟ bytes (1 to 253)

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:

Primitive Message type

Value Use

Dec Hex

Alerting request ACM

CPG

6

44

0x06

0x2c

Indicates incoming called party being alerted.

Application transport request

APM 65 0x41 To issue an application transport message.

Charge request (Generic)

CRG 49 0x31 Carries charging information.

Circuit seized request SZE 199 0xc7 Used to initiate a continuity test call and indicates that a circuit has been seized for an outgoing call (but no address information has yet been sent).

Confusion request CFN 47 0x2f Requests that a confusion message is sent.

Continuity request COT 5 0x05 Indicates whether the continuity test succeeded.

Collection charging request

MPM 201 0xc9 Used to carry charging information.

End-to-end message request

PAM 40 0x28 Requests that an end-to-end message is sent.

Facility request FAR

FAC

31

51

0x1f

0x33

Request activation of a particular facility or action at another exchange.

Facility response FAA 32 0x20 Used to accept or reject a facility .

FRJ 33 0x21 Previously requested with a facility request.

Forward transfer request

FOT 8 0x08 Send forward transfer to the network.

Information request SAM 2 0x02 Subsequent address digits for overlap signaling.


24


Value Use

Dec Hex

INF 4 0x04 Sends additional call information.

Identification request IDR 54 0x36 Used to request an action regarding the MCID supplementary service.

Identification response

IRS 55 0x37 Used to respond to the IDR message.

Loop back acknowledgement request

LPA 36 0x24 Indicates to the network that a continuity check loop has been applied to the circuits.

Loop prevention request

LOP 64 0x40 Use with ECT supplementary service.

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 request

INR 3 0x03 Requests additional call information.

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

9

7

0x09

0x07

Answers incoming call.

Subsequent Directory Number

SDM 67 0x43 Subsequent directory number digits for overlap signaling

Unrecognised message request

UMT 254 0xfe Allows an unsupported message type to be sent by the application.

User information request

USR 45 0x2d Requests that user-to-user data is sent.


25

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.

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 Appendix E: ISUP Repeat Parameters on page 192).


26

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)


None

Optional parameters

Access transport


Cause indicators

Call reference

Event information

Defaults to 0x01 if not supplied. i.e. ALERTING


Redirection number

Remote operations

Service activation



May be used to accept user to user information service 1, 2 or 3


Discarded if user to user service 1 has not been accepted



27



Backward GVNS


Call history information

Call transfer number


Connected number




Generic number





The following optional parameters are supported in ANSI mode only:

Business group

Generic number (address)

Generic digits


Network transport



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)


None


28

Optional parameters

Message compatibility information


Application transport parameter


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)


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)


Nature of connection indicators

Optional parameters

None


29

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)


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)


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)


Continuity indicators

Optional parameters

None


30

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)


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



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)


31


Facility indicator

Optional parameters

Call reference


Connection request



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 digits

Network transport

Action Request

Message type

FAC (Facility Message)


None

Optional parameters

Remote operations

Service activation


Access transport


Generic notification




32

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)


Facility indicator

Optional parameters

Call reference



Connection request


Rejected

Message type

FRJ (Facility Rejected Message)


Facility indicator

Cause indicators

Optional parameters

Call reference




Called party number



33

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)


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)


None

Optional parameters

MCID request indicator



6.5.14 Identification Response


This primitive is used by the application to respond to the Identification

Indication primitive.

Message type

IRS (Identification Response Message)


None


34

Optional parameters

MCID response indicators




Access transport

Generic number


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.

Subsequent Address Digits


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)


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)




35

Optional parameters

Calling party category


Call reference

Access transport

The following optional parameters are supported in ITU-T mode:

Connection request




Business group

Charge number

Originating line information

Redirecting number



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)


None

Optional parameters

None

6.5.17 Loop Prevention Request


This primitive is used as part of the ECT supplementary service.

Message type

LOP (Loop Prevention Message)


36


None

Optional parameters



Call transfer reference

Loop prevention indicators

6.5.18 Network Resource Management Request


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)


None

Optional parameters




Transmission medium requirement

6.5.19 Overload Request


This primitive is used by the application to invoke temporary trunk blocking of

a circuit.

Message type

OLM (Overload Message)


None

Optional parameters

None


37

6.5.20 Pre-Release Information Request


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)


None

Optional parameters

Optional forward call indicators







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




Optional parameters

Access transport

Call reference

Cause indicators


Remote operations

Service activation




38

May be used to accept user to user information service 1, 2 or 3 (previously requested in a set-up indication).



The following parameters are supported in ITU-T mode only





Connected number



This parameter may be repeated (see Appendix E: ISUP Repeat

Parameters on page 192).



Redirection number


UID action indicator


Business group

Generic digits


Network transport



6.5.22 Progress Request

This primitive is used by the application to convey information about the progress of the call.

Message type



Event information

Optional parameters

Access transport


39

Automatic Congestion Level


Cause indicators

Call reference


Redirection number

Remote operations

Service activation









Backward GVNS






Connected number








Business group


Generic digits


Network transport


40



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)


None

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 Section 6.8.1: Call Clearing Procedure on page 86 for further information.

Message type

REL (Release Message)


None

Optional parameters

Access transport

Cause indicators

Defaults to the following if not supplied:


41

Coding standard = ITU-T

Location = User

Recommendation = Q.931

Cause Value = Normal. Unspecified


This parameter may be repeated in this message

Signalling point code




The following optional parameters are supported in ITU-T mode only


Automatic congestion control




Redirection number


Remote operations

Display


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)


Information request indicators


42

Optional parameters

Call reference

The following optional parameters are only supported in ITU-T mode only:



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)


None

Optional parameters

Suspend/resume indicators

Defaults to 0x00 if not supplied, i.e. ISDN Subscriber Initiated

Call reference

6.5.27 Segmentation Request


This primitive is used by the application to send the second segment of an ISUP message.

Message type

SGM (Segmentation Message)


None

Optional parameters

Access transport

User-to-user information


Generic digit


43




Generic number


6.5.28 Setup Request

This primitive is used by the application to initiate an outgoing call.

Message type

IAM (Initial Address Message)


Called party number

Optional parameters

Access transport

Calling party's category

Defaults to 0x0a if not supplied

Call reference


Forward call indicators

Defaults to 0x0040 if not supplied

Generic digits




Hop counter


Defaults to 0x00 if not supplied

Original called number

Redirecting number


Remote operations

Service activation

Transit network selection


44

User service information

In ANSI mode, defaults to 0x80, 0x90 , 0xa2 CCITT coding standard information transfer capability speech 64kbit/s circuit mode --law (layer

1 protocol)

User service information prime


If no user to user indicators are provided, presence of user to user information is considered as an implicit request of service 1.

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

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:


Forward GVNS

Freephone indicators


Generic reference

Location number

MLPP precedence

Network management controls



Originating ISC point code


Propagation delay counter

Redirection number

UID capability indicator


45

SCF ID


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


May be used to request user to user information service 1, 2 or 3


Business group

Carrier identification

Carrier selection information

Charge number


Egress service

Generic name


Jurisdiction

Network transport

Operator services 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.


46

Before ACM Issued


Message type

CON (Connect Message)


None

Optional parameters



Access transport


Defaults to 0x1416 if not supplied , i.e. Subscriber Free, Ordinary Subscriber, Charge, Terminating access ISDN, ISDN used all the way

Backward GVNS


Call reference

Connected number

Conference treatment indicator



This parameter may be repeated (see Appendix E: ISUP Repeat Parameters on page 192)

Generic number





Redirection number


Remote operations

Service activation






47


Setup response

Message type

ANM (Answer Message)


None

Optional parameters

Access transport


Call reference


Remote operations

Service activation









Backward GVNS


Connected number

Display




Generic number




Redirection number


48



Business group

Generic digits


Network transport

Notification parameter


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.


Message type

SDM (Subsequent Directory Number Message)


None

Optional parameters

Subsequent number


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)


None

Optional parameters


Defaults to 0x00 if not supplied (i.e. ISDN Subscriber Initiated)

Call reference


49

6.5.32 Unrecognised Message Request


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


Message data

Optional parameters

None

6.5.33 User Information Request


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)



Optional parameters

Access transport

Call reference


50

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


Value Use

Dec Hex

Alerting indication ACM

CPG

6

44

0x06

0x2c

Indicates outgoing called party being alerted.

Application transport indication

APM 65 0x41 Issued on receipt of an application transport message.

Charge indication (Generic)

CRG 50 0x32 Carries charging information

Circuit seized indication

SZE 199 0xc7 Used for continuity checking and indicates that a circuit has been seized for an incoming call (but no address information has yet been received).

Collection charging indication

MPM 201 0xc9 Used to carry charging information.

Confusion indication CFN 47 0x2f Indicates that a confusion message has been received.

Continuity indication COT 5 0x05 Indicates whether the continuity test succeeded.

End-to-end message indication

PAM 40 0x28 Conveys received end-to-end message.

Facility confirmation FAA 32 0x20 Indicates that the remote party has accepted the user to user service 3 request.

Facility indication FAR 31 0x1f Indicates that the remote party is requesting user to user information service 3 during the active phase of a call.

Forward transfer indication

FOT 8 0x08 Indicates that a forward transfer message has been received.

Information indication SAM 2 0x02 Subsequent address digits for overlap signaling.

INF 4 0x04 Provides additional call information.

Identification indication

IDR 54 0x36 Used to request an action regarding the MCID supplementary service.

Identification confirmation

IRS 55 0x37 Used to respond to the IDR message.

Loop back acknowledgement indication

LPA 36 0x24 Indicates to the application that a continuity check loop has been applied to the circuit.

Loop prevention indication

LOP 64 0x40 Use with ECT supplementary service.


51


Value Use

Dec Hex

Network resource management indication

NRM 50 0x32 Indicates that network resources associated have been modified.

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

7

0x09

0x07

Outgoing call answered indication.

Setup indication IAM 1 0x01 Incoming call indication.

Subsequent Directory Number

SDM 67 0x43 Subsequent directory number digits for overlap signaling

Unrecognised message indication

UMT 254 0xfe Conveys a received message with unrecognized message type to the user.

User information indication

USR 45 0x2d Conveys received user to user data.


52

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




Optional parameters

Access transport

Cause indicators

Call reference


Remote operations

Service activation



Indicates that a previously requested supplementary service has been provided







Connected number





Redirection number




53





Connected number





Redirection number




Business group

Generic digits


Network transport



Received following ACM

Message type



Event information

Optional parameters

Access transport



Remote operations

Service activation



Indicates that a previously requested supplementary service has been

provided


54





Backward GVNS




Connected number




Generic number






Business group


Generic digits


Network transport





55

6.6.2 Application Transport Indication


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)


None

Optional parameters






6.6.3 ‘Generic’ Charge Indication


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)


Message data

Optional parameters

None


56

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 Section 6.8.4: Continuity Testing on page 91).

Message type

SZE (Circuit seized)



Optional parameters

None

6.6.5 Collection Charging Indication

This primitive is used ISUP after alerting to convey the number of charging units.

Message type

MPM (Collection Charging Message)



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)


None

Optional parameters

Cause Indicators


57

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)


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)


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



Event information

Must be coded as value 0x7d (defined as „spare‟ by ANSI T1.113.3), to

indicate Exit.

Optional parameters



58

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)


Facility indicator


ITU-T mode only

Optional parameters

Call reference


Connection request



Business group

Called party number


Charge number


Generic digits

Network transport

Action requested indication

Message type

FAC (Facility Message)


None

Optional parameters

Remote operations

Service activation


59


Access transport





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)


Facility indicator


Optional parameters

The following parameters are supported in ITU-T mode only:

Call reference

Connection request


Rejected

Message type

FRJ (Facility Rejected Message)


Facility indicator

Cause indicators

Optional parameters

Call reference




60


Called 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)


None

Optional parameters

Call reference


Cause indicators

6.6.13 Identification Indication


This primitive is used by ISUP to indicate that the malicious call identification

supplementary service has been requested.

Message type

IDR (Identification Indication Message)


None

Optional parameters

MCID request indicators




61

6.6.14 Identification Confirmation


This primitive is used by ISUP to indicate that a response to an Identification Request has been received.

Message type

IRS (Identification Confirmation Message)


None

Optional parameters





Access transport

Generic number


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


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)


Subsequent number

Optional parameters

None


62

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)



Optional parameters

Access transport

Calling party category


Call reference

The following optional parameters are supported in ITU mode only:




Business group

Charge number


Redirecting number



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)


63


None

Optional parameters

None

6.6.17 Loop Prevention Indication


This message is issued by ISUP upon receipt of a Loop prevention message

from the network.

Message type

LOP (Loop Prevention Message)


None

Optional parameters



Call transfer reference


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)


None

Optional parameters





64

6.6.19 Overload Indication


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)


None

Optional parameters

None

6.6.20 Pre-Release Information Indication


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)


None

Optional parameters









65

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




Optional parameters

Access transport

Cause indicators


Remote operations

Service activation















Redirection number



Business group

Generic digits


Network transport


66



6.6.22 Progress Indication

This primitive is used to convey progress information relating to the call.

Message type



Event information

Optional parameters

Access transport



Remote operations

Service activation











Parameters on page 192)






Business group


Generic digits


67


Network transport



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)


None

Optional parameters


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)


Cause indicators


68

Optional parameters

Access transport

Automatic congestion level




Redirection number

Signalling point code









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)



Optional parameters

Call reference





69


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)



Optional parameters

Call reference

6.6.27 Segmentation Indication


This primitive contains the second segment of an ISUP message.

Message type

SGM (Segmentation Message)


None

Optional parameters

Access transport

User-to-user information


Generic digit




Generic number




70

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


Message type

CON (Connect Message)



Optional parameters


Access transport

Backward GVNS


Call reference

Connected number





Generic number






Redirection number


Remote operations

Service activation



71


The response to a previously issued user to user supplementary service request.



After ACM received

Message type

ANM (Answer Message)


None

Optional parameters

Access transport


Connected number


Remote operations

Service activation



The response to a previously issued user to user supplementary service

request.









Generic number




Redirection number


72



Business group


Network transport

Notification parameter


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)



Forward call indicators

Calling party's category


ITU-T mode only

User service information

Mandatory for ANSI mode only. Optional for ITU-T operation.

Called party number

Optional parameters

Access transport


Call reference



Generic digits



Original called number


Redirecting number

Remote operations


73

Service activation

Transit network selection

Redirecting number



Indicates that the calling party is requesting one or more user to user

supplementary services.




Call offering treatment indicators

Called IN number

CCSS



Collect call request


Connection request

Correlation id


Forward GVNS

Freephone indicators



Generic reference

Hop counter

Location number MLPP preference




Origination ISC point code



SCF id



74

UID capability indicators



Business group

Carrier identification


Charge number


Egress service

Generic name

Hop counter


Jurisdiction

Network transport



Precedence

Service code indicator


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.


Message type

SDM (Subsequent Directory Number Message)


None

Optional parameters

Subsequent number



75

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)



Optional parameters

Call reference

6.6.32 Unrecognised Message Indication


This primitive is used to transit an unknown message type.

Message type



Message data

Optional parameters

None

6.6.33 User Information Indication


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)



Optional parameters

Access transport

Call reference


76

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 168 for the list of

supported national specific parameters.

Parameter Name Value

Definition/Reference Length

Notes Hex Dec Min Max


0x2e 46 Q.763 Section 3.2 1 1 1

Access transport 0x03 3 Q.763 Section 3.3

1 255 1

Application transport 0x78 120 Q763 Addenda (09/98) 3 255 1, 4

Automatic Congestion Level

0x27 39 Q.763 Section 3.4 (09/97)

1 1

Automatic rerouting 0x96 150 Q.1902.3 (amd 3) section 6.107

1 2 -

Backward call indicators 0x11 17 Q.763 Section 3.5 2 2

Backward GVNS 0x4d 77 Q.763 Section 3.62 (09/97)

1 1 1

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


0x6e 110 Q.763 Section 3.72 (09/97)

1 1 1

Call history information 0x2d 45 Q.763 Section 3.7 2 2 1

Call offering treatment indicators

0x70 112 Q.763 Section 3.74 (09/97)

1 1 1

Call reference 0x01 1 Q.763 Section 3.8 T1.113 Section 3.5

5 6 1, 2

Call transfer number 0x45 69 Q.763 Section 3.64 (09/97)

2 18 -

Call transfer reference 0x43 67 Q.763 Section 3.65 (09/97)

1 1


77




Called directory number 0x1ed 493 Q.1902.3 section 6.15 2 18 -

Called party number 0x04 4 See Section 6.7.1 on page 82 of this manual

1 18 5

Called IN number 0x6f 111 Q.763 Section 3.73 (09/97)

2 18 -

Calling geodetic location 0x81 129 Q.1902.3 section 6.15 8 255 1

Calling party geodetic velocity information

0x83 131 Q.1902.3 section 6.19 4 255 1

Calling party number 0x0a 10 See Section 6.7.2 on page 82 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


0xee 238 T1.113 Section 3.8B & Q.1902.3 section 6.22

1 1 1

Cause indicators 0x12 18 See Section 6.7.3 on page 83 of this manual

2 255 -

CCNR possible indicator 122 0x7a Q.1902.3 section 6.24 1 1 -

CCSS 0x4b 75 Q.763 Section 3.63 (09/97)

1 1 1

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 characteristic indicator

0xe5 229 T1.113 Section 3.10A 1 1 1

Circuit group supervision message type

0x15 21 Q.763 Section 3.13 1 1 3

Circuit identification name

0xe8 232 T1.113 Section 3.11A 26 26 1

Circuit state indicator 0x26 38 Q.763 Section 3.14 2 32 3

Circuit validation response indicator

0xe6 230 T1.113 Section 3.11C 1 1 1


0x1a 26 Q.763 Section 3.15 4 4 1

Coding decoding processing

0xa5 165 Q.1902.3 section 6.31 1 255 1

Collect call request 0x79 121 Q.763 Section 3.81 (09/97)

1 1 1


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


78




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 84 of this manual

1 255 4

Display information 0x73 115 Q.763 Section 3.77 (09/97)

1 255 1

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 (09/97)

3 26 1

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


0x2c 44 Q.763 Section 3.25 1 1 1, 4


0xc0 192 Q.763 Section 3.26 3 14 1, 4

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 T1.113 Section 3.20D

1 1 1

HTR information 0x82 130 Q.1902.3 section 6.50 2 18 -

Information indicators 0x0f 15 Q.763 Section 3.28 2 2 -


0x0e 14 Q.763 Section 3.29 2 2 -

Inter nodal traffic group identifier

0xa3 163 Q.1902.3 section 6.54 1 255 1

Jurisdiction 0xc4 196 T1.113 Section 3.23A 1 3 1

Location number 0x3f 63 Q.763 Section 3.30 3 13 1


0x44 68 Q.763 Section 3.67 (09/97)

1 1 -


0x38 56 Q.763 Section 3.33 1 1 -

MCID request indicators 0x3b 59 Q.763 Section 3.31 1 1 1


0x3c 60 Q.763 Section 3.32 1 1 1

Message data 0xfa 250 See Section 6.7.5 on page 84 of this manual

1 255 1


79




MLPP precedence 0x3a 58 Q.763 Section 3.34 6 6 1


0x06 6 Q.763 Section 3.35 1 1 -


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


0xff 255 See Section 6.7.6 on page 85 of this manual

1 1 1

Number portability forward information

0x8d 141 Q.1902.3 section 6.65 1 255 1


0xc2 194 T1.113 Section 3.24D 1 1 1


0x29 41 Q.763 Section 3.37 1 1 -


0x08 8 Q.763 Section 3.37 1 1 -

Original Called IN number

0x7f 127 Q.1902.3 section 6.68 2 18 -

Original called number 0x28 40 Q.763 Section 3.38 2 13 1

Origination ISC point code

0x2b 43 Q.763 Section 3.39 2 2 1


0xea 234 T1.113 Section 3.26A 1 1 5


0xe7 231 T1.113 Section 3.26B 1 3 1


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 information

0x89 137 Q.1902.3 section 6.74 1 255 1

Pivot routing forward information

0x88 136 Q.1902.3 section 6.75 1 255 1

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 -


0x31 49 Q.763 Section 3.42 2 2 1

Query on Release Capability

0x85 133 Q.1902.3 section 6.79 1 1 -

Range and status 0x26 22 Q.763 Section 3.43 1 33 3


80




Redirecting number 0x0b 11 Q.763 Section 3.44 2 13 1

Redirect backward information

0x8c 140 Q.1902.3 section 6.81 1 255 1

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 information

0x8b 139 Q.1902.3 section 6.84 1 255 1

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


0x40 64 Q.763 Section 3.47 1 1 1

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


0xed 237 T1.113 Section 3.30A 1 1 1

Subsequent number 0x05 5 Q.763 Section 3.51 2 12 -


0x22 34 Q.763 Section 3.52 1 1 -

Tariff type 0xfe 254 See Section 6.7.7 on page 85 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


0x02 2 Q.763 Section 3.54 1 1 -


0x2e 62 Q.763 Section 3.55 1 1 1

Transmission medium requirement used

0x35 53 Q.763 Section 3.56 1 1 1

UID action indicators 0x74 116 Q.763 Section 3.78 (09/97)

2 2 -

UID capability indicators 0x75 117 Q.763 Section 3.79 (09/97)

2 2 -

Unrecognised parameter 0xf9 249 See Section 6.7.8 on page 86 of this manual

3 255 4

User service information 0x1d 29 Q.763 Section 3.57 2 11 1


81





0x30 48 Q.763 Section 3.58 2 11 1

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


0x34 52 Q.763 Section 3.59 2 3 1

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:

Parameter Name

Minimum Parameter Length

ITU ANSI

Called party number 2 1

Originating line information - 1

Signalilng point code 2 3

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


82

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

1 ODD/ EVEN

Nature of address indicator

2 INN

Ind.

Numbering plan Spare

3 2nd address signal 1st address signal

:

n Filler (if necessary) Nth address signal

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.

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

1 ODD/ EVEN

Nature of address indicator

2 NI Numbering plan Presentation indicator

Screening indicator

2nd address signal 1st address signal

:

n Filler (if necessary) Nth address signal


83

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

102 Recovery on timer expiry

T3 Started on receipt of overload message 31 Normal, unspecified

T6 Waiting for RES after (network) SUS is received

102 Recovery on timer expiry

T7 Waiting for ACM 31 Normal, unspecified

T8 Waiting for COT 41 Temporary failure

T9 Waiting for ANM 19 No answer from user (user alerted)

T35 Waiting for ST digit 28 Address incomplete

T38 Waiting for RES after (network) SUS is received in an international exchange

- timer not supported


84

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

:


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).


85

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.


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


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


86

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 Figure 9 below. No checking of the data in the 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 Section 8.2: Configure Circuit Group

Request on page 121 for details.

Figure 9. Format of the Unrecognised Parameter

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

:


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.


87

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 Section 8.2: Configure Circuit Group Request on page 121).

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 sub-sections.


88

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

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.

IAM

ISUP

MODULE

USER

APPLICATION NETWORK

IAM

IAM


89

Figure 11. Example of an External Call Collision where this end of the Circuit is Slave

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.

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

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.

IAM

ISUP

MODULE

USER

APPLICATION NETWORK

IAM

IAM

IAM

ISUP

MODULE

USER

APPLICATION NETWORK

IAM IAM IAM


90

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 Section 8.2:

Configure Circuit Group Request on page 121).

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 76) 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 Section 6.8.1: Call Clearing Procedure on page 86 shall

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.

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.


91

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 Section 6.6.4: Circuit Seized Indication on page 56. 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 Section 6.8.1: Call Clearing Procedure on page 86).

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 131 for details.


92

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

RLC RLC

CCR CCR

REL REL

RLC

ISUP MODULE

USER APPLICATION NETWORK


93

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)

REL

CCR SZE

COT (failure) COT (failure)

RLC

RLC RLC

CCR SZE

REL REL

RLC

ISUP MODULE

USER

APPLICATION NETWORK


94

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

IAM IAM

COT (success) COT (success)

ACM ACM

ANM ANM

ISUP MODULE

USER

APPLICATION NETWORK

Call in Speech State: Proceed as usual


95

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

RLC

REL

IAM IAM


RLC

REL RLC

CCR SZE

REL REL

ISUP MODULE

USER

APPLICATION NETWORK


96

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 6.5.16: Loop Back Acknowledgement Request on page 35.

Figure 17. Example of a Continuity Check Request Message Received (ANSI)

RLC RLC

CCR CCR

LPA LPA

RLC

REL REL

ISUP MODULE



97

Timer expiry during continuity test call

Timers T27 (waiting for CCR) and T36 (waiting for REL after CCR) are run by the ISUP module. On expiry, the circuit is reset and the call is released to the application in the usual way.

Figure 18. Example of a T36 Expiry

Outgoing Circuits

There are two situations where continuity checks on outgoing circuits may occur:

When a Circuit seized request (SZE) message is received for an idle circuit.

When a continuity check is performed on an outgoing circuit during call set up.

In order to support continuity checks on idle circuits, the Circuit seized

request primitive is used. This special primitive is not defined by ITU or ANSI but is used to indicate that the circuit has been seized and the format of this primitive is described in Section 6.5.4 Circuit Seized Request on page 28. The Circuit seized request is sent by the user application to ISUP causing a CCR message to be sent by the ISUP module to the network.

The application needs to control the continuity checking equipment (the

transceivers) and run timers to determine when a continuity check has failed and when to initiate a continuity recheck.

RLC

RSC

CCR SZE

REL

RLC RLC

T36 expiry

ISUP

MODULE

USER

APPLICATION NETWORK


98

The application must run all the timers associated with the continuity check and perform the appropriate actions on expiry. For ITU ISUP, the timers are as follows:

Timer Value Cause for initiation Normal termination

Action on expiry

T24 <2 seconds

When the Circuit seized request (or the Setup request for a call where a continuity check is to be performed) is sent.

At the receipt of backward check tone.

Remove the transceiver, send Continuity request with the Continuity indicators set to continuity check failed and start T25 or T26 (as appropriate). If a Setup request had been sent, the outgoing call should be retried on another circuit.

T25 1-10 seconds

When continuity check failure is detected after sending a Setup request.

- Send Circuit seized request, apply the transceiver, and start T24.

T26 1-3 minutes

When continuity check failure is detected after sending a Circuit seized request.

- Send Circuit seized request, apply the transceiver, and start T24.

See Section 8.3: Configure Timers Request on page 131 for details.

The following subsections show a number of different scenarios where a continuity check is made on an outgoing circuit. In each case, the application initiates the test by sending either a Setup request or a Circuit seized request (depending on whether the continuity check is being performed during normal call set up or as a continuity test call), applying a transceiver to the circuit to

generate the tone, and starting timer T24(waiting to send COT on receipt of

backward check tone). The Nature of connection indicators parameter in the Circuit seized request or Setup request must have the Continuity check indicator set to “continuity check required on this circuit”. If the application detects that the backward check tone was received correctly, this indicates that the continuity check was successful.


99

Successful continuity test call

To initiate a continuity test call, the application needs to send a Circuit seized request to the ISUP module. The Circuit seized request must contain the Nature of connection indicators parameter with the Continuity check indicator set to “continuity check required on this circuit”. At the same time as the Circuit seized request is sent, the application must apply the transceiver to

generate the tone and start timer T24 (waiting for sending COT on receipt of backward check tone) to await completion of the continuity check.

Once the continuity test has completed successfully, the transceiver should be removed and the call should be released.

Figure 19. Example of a Successful Continuity Check Request Message Sent

SZE

REL REL

RLC RLC

CCR

ISUP

MODULE

USER

APPLICATION NETWORK


100

Unsuccessful continuity test call

The continuity test is initiated as in the previous example. If the continuity check is unsuccessful, a Continuity request is sent indicating failure and timer T26 (waiting for sending CCR on subsequent COT failure) should be started by the application. The transceiver should be removed at this point. On expiry of this timer, the continuity test should be re-initiated on the same

circuit by sending a Circuit seized request, applying the transceiver, and starting timer T24 (waiting for sending COT on receipt of backward check tone).

Removing and re-applying the transceiver (rather than leaving it in place whilst waiting to perform the continuity re-check) avoids the possibility that the continuity check may continually fail due to the fact that the transceiver

was not correctly applied initially.

Figure 20. Example of a Continuity Check Request Message Sent (Unsuccessful Continuity Check Followed By Successful Continuity Check)

SZE CCR

SZE

REL REL

RLC RLC

CCR



ISUP

MODULE

USER

APPLICATION NETWORK


101

Successful continuity check during call set up

After a continuity check has succeeded during normal call set up, timer T24 (waiting for sending COT on receipt of backward check tone) should be stopped and the transceiver removed. The application initiates the continuity request thus indicating success and the call should be allowed to proceed in the normal manner.

Figure 21. Example of a Continuity Check Success Outgoing Call Set Up

Call in Speech State: Proceed as usual

ANM ANM


ACM ACM

IAM IAM

ISUP MODULE

USER

APPLICATION NETWORK


102

Unsuccessful continuity check during call set up

Following an unsuccessful continuity check during normal call set up, timer T25 (waiting to send CCR and repeat continuity check) should be started by the application. On expiry of the timer, the application should initiate the continuity recheck by sending a Circuit seized request, applying the transceiver, and starting T24 (waiting for sending COT on receipt of backward

check tone).

Figure 22. Example of a Continuity Check Success during Outgoing Call Set Up

ANSI operation

In ANSI ISUP, the Loop Back Acknowledgement indication (LPA) message is received after the CCR message is sent to indicate that the other end has connected the loop. On receipt of the LPA, the sending side should start sending the check tone.

The ANSI ISUP standard defines a timer, Tccr, which is used to wait for the LPA message. This timer is implemented in the ISUP module as timer T104 (waiting for LPA). Timer T104 may optionally be run. This timer is controlled by a circuit group option (ISPGOP_TCCR_CTRL), if this option is set, the ISUP module will wait for an LPA message and on its receipt shall pass on the LPA message before changing to an appropriate state. If the option is set, on

T104 expiry, the circuit will be reset.

RLC RLC

REL REL

IAM IAM


CCR CCR

ISUP MODULE



103

Call collision

A continuity test call may be initiated at both ends of a circuit simultaneously. When a call collision condition occurs, the ISUP module checks the value of bits 0 and 1 of the circuit group options field to determine which call should be allowed to succeed. As far as the application is concerned, the call collision conditions described in Section 6.8.2: Call Collision Procedure on

page 87 apply. For example, if the incoming call has priority, the application will accept the Circuit seized indication and the outgoing continuity test will be abandoned and subsequently the incoming call will be processed. If the outgoing call has priority, the application will not be aware that a call collision condition has occurred because the CCR message received from the network shall be ignored by the ISUP module.

Call collision may also occur between an outgoing continuity test and an

incoming normal call (i.e. IAM received). If this situation should occur, the normal call will always have priority and the application will receive a Setup indication and consequently the outgoing continuity test attempt will be discarded.

Figure 23. Example of a Call collision where the Incoming Call has Priority

SZE CCR

RLC

REL REL

CCR SZE

RLC

RLC

ISUP MODULE


The incoming continuity test call is processed and the outgoing call is

discarded


104

Reset circuit received during a continuity test call

A reset circuit message may be received during an outgoing continuity test call if the timer waiting for REL at the other end expires. This will cause the ISUP module to release the continuity test call.

Figure 24. Example of a Reset Circuit Received During a Continuity Test Call

6.8.5 Malicious Call Identification (MCID) Supplementary

Service

Configuration

The ISUP module supports the malicious call identification supplementary

service when configured for following protocol variants: ITU 1992, Germany and UK.

ITU-T Recommendation Q.731.7 specifies that timer T39 is used for this procedure. When the per circuit group ISPX1GOP_T39 option is set, this will cause timer T39 to be initiated, to await for an IRS message after an IDR message has been sent.

If timer T39 expires (when no IRS message is received from the previous

exchange), the ISUP module will generate an IRS message containing the MCID response indicator with the following default values to the user

application and the call will be allowed to continue.


Bit Field Value Meaning

A MCID response indicator 0 MCID not provided

B Hold provided indicator 0 Holding not provided

RLC

CCR SZE

RSC

REL

RLC RLC

ISUP

MODULE

USER

APPLICATION NETWORK


105

6.8.6 Message Segmentation

If the ISUP module receives a message with the segmentation indicator set, it starts T34 (wait for segmentation message). If T34 expires, ISUP will send an empty segmentation (SGM) message to the user application indicating that the timer has expired. An empty SGM message will also be sent to the

user application if another ISUP message is received in the same direction before the segment was received. For example, if the ISUP module received an ACM from the network with the segmentation indicator set and then it received an ANM but the second segment of the ACM was not received, the ISUP module would send ACM followed by an empty SGM followed by the ANM to the user application.

In this way, the ISUP module ensures that the user application will always

receive an SGM message following a message with the segmentation indicator set and will never receive a "stray" message segment. The user application does not need to run timer T34.

Whether the application stores the received message whilst awaiting the segment or passes it to the other side of the call depends on the position in the network i.e. the "exchange type" as defined by ITU. For exchange types

1, 3, 5, and 6 (originating exchange, outgoing international exchange, incoming international exchange, and destination exchange) the user should wait for the segment to be received and assemble the message before passing it on in the appropriate direction. For exchange types 2 and 4 (transit national and international exchanges) the user should pass on the message immediately and pass on the segment when it is received. This is in accordance with the ITU SDL diagrams in Q.764.

Note that, because of the limit of 320 bytes of information in the parameter area of an MSG, if a message longer than this length is sent to the ISUP module by the user application, it must be first segmented since the ISUP

module does not support the division of a long application message into an ISUP message plus a message segment.

6.8.7 Automatic Circuit Group Blocking

Introduction

Automatic circuit group blocking allows the ISUP module to automatically hardware block the circuit group(s) when the status of the user application is detected to be unavailable and out of service.

Configuration

The ISPX1GOP_AUTO_BLK (bit 9) per circuit group option in the <ext_1_options> field in the Configure Circuit Group Request message (0x7701) shall be used to determine whether automatic blocking should be

performed for the circuit group.

If the ISPX1GOP_AUTO_BLK option is set, automatic blocking of circuits will be performed for the circuit group and heartbeat messages will be generated and sent to the user application.

If the option is not set, automatic blocking of circuits will not be performed for the circuit group and heartbeat messages will not be sent to the user application.


106

Procedure

When the autoblocking feature is activated, the ISUP module will periodically send a Heartbeat message, CAL_MSG_HEARTBEAT, 0x7718, to the user application, to determine its status. A single heartbeat message will be sent every 30 seconds regardless of the number of circuit groups configured per user instance.

If the user application fails to respond to a Heartbeat message (from the ISUP module) within 3 seconds the ISUP module will consider the user application to be unavailable and out of service. Circuit groups associated with the application and for which autoblocking has been invoked (refer to Section 8.2: Configure Circuit Group Request on page 121) will be hardware blocked and a blocking message (CGB) will be sent by the ISUP module to the

network for those circuit groups affected.

If autoblocking is executed, ISUP will continue to send, to the user application, Heartbeat messages with the UIHB_FLAGS_CGRPS_BLOCKED flag (bit 0) set to a value of 1 indicating that the ISUP circuit groups have been blocked.

A user application, when it subsequently recovers, will indicate to the ISUP module that it is again available and in service. The user application may do this using the following methods:

The user application will wait for a Heartbeat message from the ISUP module. When received, the user application will respond with a heartbeat message with the UIHB_FLAGS_CGRPS_BLOCKED flag set to 1.

The user application will generate a Heartbeat message to request a Heartbeat message immediately from the ISUP module, in order to determine whether the circuit groups have been blocked. For such cases,

where the user instance id is not known, the user should ensure that the

<user instance id> in the Heartbeat message is set to 0xffff.


107

6.8.8 BICC Application Transport

If the ISUP module receives a message containing an application transport parameter with the Application context set to BAT ASE and the segmentation indicator not set to final segment, it starts timer TIM_REASS (wait for segmentation message, if enabled – see treass in ISP_MSG_CNF_TIM). If

TIM_REASS expires, ISUP will send an Application Transport (APM) message with the context identifier set to EUCEH ASE, the APM segmentation Indicator (set to final segment(0)), the Segmentation local reference, and the Origination Address to the user application indicating that the timer has expired.

8 7 6 5 4 3 2 1

ext = 1 Application context identifier = 0x6 (EUCEH ASE) 1

ext = 1 0 SNI = 0 RCI = 0 2

ext = 0 SI = 0 APM segmentation indicator = 0 3

ext. Segmentation local reference 3a

Originating Address length 4

Originating Address 4a

Destination Address length = 0 5

ext = 1 APM-User context identifier = 5 6

ext = 1 Reason = Reassembly error = 2 7

An APM message will also be sent to the user application if another BICC message is received in the same direction, for the same CIC, OPC, DPC and SIO, before the APM segment or a SGM message was received. For example, if the ISUP module received an ACM from the network containing a

segmented APP parameter and subsequently received an ANM before the second segment of the APP parameter, the ISUP module would send ACM followed by an APM before sending the ANM to the user application.

In this way, the ISUP module ensures that the user application will always receive an APM message following a message with the segmentation indicator set and will never receive a "stray" message segment. The user application does not need to run timer TIM_REASS.

APM Segment validation can be disabled by setting the BICX1GOP_REASS bit of the ext_1_options field of ISP_MSG_CNF_GRP to 0.

Whether the application stores the received message whilst awaiting the

segment or passes it to the other side of the call depends on the position in the network.

Section 7 Management Interface

108

7 Management Interface

7.1 Introduction The management interface allows the user to interface with the Circuit Supervision Control (CSC) block of the ISUP module. The interface is

message based and uses the same basic message structure as defined in the previous section. The messages available allow the user to carry out the following circuit supervision functions:

Reset a circuit or circuit group

Abort a reset cycle

Block a circuit or circuit group

Unblock a circuit or circuit group

Abort a blocking/unblocking attempt

Request the circuit status from the remote signaling point (Circuit group query)

In the case of blocking, two circuit blocking procedures are defined. One procedure causes immediate release of all affected circuits. This is referred to by ITU-T as “Hardware Blocking”, and by ANSI as “Blocking with immediate release of all circuits”. In the following sections, the term

Hardware Blocking will be used.

The second type of blocking does not cause immediate release of circuits, and is referred to by ITU-T as “Maintenance Blocking” and by ANSI as “Blocking without release of circuits”. In the following sections, the term Maintenance

Blocking will be used.

Commands originated by the user take the form of a Circuit Group

Supervision Request. On completion of command execution, the user receives notification in the form of a Circuit Group Supervision Confirmation. Events initiated at the remote end of the network are notified to the user in a Circuit Group Supervision Indication.

When the ISUP module returns a confirmation message containing a status value, the status will be one of the following:

Table 3. ISUP Module Confirmation Message Statuses

Value Mnemonic Description

0 none Success

1 ISPE_BAD_ID Inappropriate or invalid id in request message

5 ISPE_BAD_MSG Inappropriate or unrecognized message type.

6 ISPE_BAD_PARAM Invalid parameters contained in message.

The message structure and parameters for each message are defined in the

following sub-sections.


109

7.2 Circuit Group Supervision Control Request This message is issued by system management to initiate a circuit group supervision control function. The functions supported are RESET, BLOCK

UNBLOCK and QUERY. The command operates on specified circuits within the specified circuit group.

Message Header

structure MSG

type ISP_MSG_CGSC_REQ (0x7703)

id gid

src Originating module ID

dst ISUP module ID

rsp_req Sending layer's bit set if confirmation required

hclass 0x00

status 0x00

err_info 0x00

len 6

Parameter Area

parameters offset 0, size 1 ptype Management primitive type.

offset 1, size 1 reserved reserved - must be set to zero

offset 2, size 4: cic_mask Bits set to indicate affected circuits in group.

ISUP Response

method By returning the message to the sender

type 0x3703

status SUCCESS

ISP_BAD_ID

ISP_BAD_PARAM

Parameters

gid

The group identifier for the Circuit Group.

ptype

The type of management primitive taken from the following table:

Value Name Function

0 Reset Reset circuit(s)

1 Stop Reset Abort reset operation

Note: The circuits specified in this message must be identical to those in the Reset Request message.

2 M-Block Maintenance block circuit(s)


110

Value Name Function

3 M-Unblock Maintenance unblock circuit(s)

4 M-Stop Abort maintenance (un)blocking

5 H-Block Hardware block circuit(s)

6 H-Unblock Hardware unblock circuit(s)

7 H-Stop Abort hardware (un)blocking

8 Query Initiate circuit group query

14 Set-Ic-Active Set state of circuit(s) to incoming active

15 Set-Og-Active Set state of circuit(s) to outgoing active

cic_mask

A 32 bit mask indicating to which of the circuits in the circuit group the

message applies. It is usual for a command to apply to all circuits in the circuit group in which case cic_mask may be set to all ones.

7.3 Circuit Group Supervision Control Confirmation This message is issued by ISUP to indicate successful completion of a circuit group supervision control function.

Event Confirmation From ISUP

structure MSG

type ISP_MSG_CGSC_CONF (0x0709)

id gid

src ISUP module ID

dst Management module ID

rsp_req 0x00

hclass 0x00

status 0x00

err_info 0x00

len 6


offset 1, size 1 reserved Set to zero


Parameters

gid



111

ptype


Value Name Function

0 Reset Reset circuit(s)

1 Stop Reset Abort reset operation

2 M-Block Maintenance block circuit(s)

3 M-Unblock Maintenance unblock circuit(s)

4 M-Stop Abort maintenance (un)blocking

5 H-Block Hardware block circuit(s)

6 H-Unblock Hardware unblock circuit(s)

7 H-Stop Abort hardware (un)blocking

14 Set-Ic-Active Set state of circuit(s) to incoming active

15 Set-Og-Active Set state of circuit(s) to outgoing active

cic_mask

A 32 bit mask indicating to which of the circuits in the circuit group the

message applies.

7.4 Circuit Group Supervision Control Indication This message is issued by ISUP to indicate completion of a circuit group supervision control function which was initiated by message(s) received from

the remote signaling point.

Message Header

structure MSG

type ISP_MSG_CGSC_IND (0x0708)

id gid

src ISUP module ID


rsp_req 0x00

hclass 0x00

status 0x00

err_info 0x00

len 6

Parameter Area


offset 1, size 1 reserved Set to zero

offset 2, size 4 cic_mask Bits set to indicate affected circuits in group.


112

Parameters

gid


ptype


Value Name Function

0 Reset Circuit(s) reset

2 M-Block Circuit(s) maintenance blocked

3 M-Unblock Circuit(s) maintenance unblocked

5 H-Block Circuit(s) hardware blocked.

6 H-Unblock Circuit(s) hardware unblocked

12 Available The destination point code (signalilng point) for the circuits in this group is now available.

13 Unavailable The destination point code (signalling point) for the circuits in this group has become temporarily unavailable.

cic_mask

A 32 bit mask indicating to which of the circuits in the circuit group the message applies.

7.5 Circuit Group Supervision Status Indication This message is issued by ISUP to indicate completion of a circuit group query function requested by the user and contains the circuit state for the requested circuits as provided by the remote signaling point.

Message Header

structure MSG

type ISP_MSG_CGSS_IND (0x070c)

id gid

src ISUP module ID


rsp_req 0x00

hclass 0x00

status 0x00

err_info 0x00

len 38


113

Parameter Area

parameters offset 0, size 1: ptype Management primitive type.

offset 1, size 1: reserved Set to zero


offset 6, size 32: circuit_status The circuit status as indicated from the remote signaling point

Parameters

ptype


Value Name Function

8 Query Initiate circuit group query

circuit_status

This is an array of 32 octets, each octet indicating the state of a circuit. The first octet corresponds to the circuit represented by the least significant bit of the cic_mask. The status for any circuit for which the bit in cic_mask is not set will be set to zero. The circuit state is as encoded in the ISUP circuit state indicator defined in Q.763.(ISUP Formats and Codes).

7.6 Local Overload Request This message may be used by the application to set a local overload condition. This condition will be signaled to the remote signaling point by inserting an automatic congestion control level parameter in all release

messages issued to the network.

Message Header

structure MSG

type ISP_MSG_OVLD_REQ (0x770d)

id 0


dst ISUP module ID

rsp_req Sending layer‟s bit set if required

hclass 0x00

status overload_level (see below)

err_info 0x00

len 0


114

ISUP Response


type 0x370d

status SUCCESS

ISP_BAD_ID

ISP_BAD_PARAM

Parameters

overload_level

This is the overload level that the application wishes to indicate to the remote signaling point. Permitted values are listed in the following table:

Value Meaning

0 Overload condition no longer exists.

1 Lower overload level exceeded.

2 Upper overload level exceeded.

7.7 Remote Point Code Status Indication This primitive is used by the ISUP module to inform the user of the availability and congestion status of a remote signaling point.

Primitive Indication From ISUP

type ISP_MSG_STATUS (0x070e)

id 0

src ISUP module ID


rsp_req 0x00

hclass 0x00

status 0x01 = Remote user unavailable

0x02 = Congestion

err_info 0x00

len 6

parameters offset 0, size 4 affected point code

offset 4, size 2 congestion_status (only applicable for remote congestion, otherwise set to zero)


115

Parameters

congestion_status

The congestion status of the indicated remote signaling point (remote user) encoded according to the following table:

Value Meaning

0 No congestion

1 Congestion level 1 (minimum level of congestion reported)

2 Congestion level 2

3 Congestion level 3 (maximum level of congestion reported)

Section 8 Non-Primitive Interface

116

8 Non-Primitive Interface

In addition to the primitives defined for the User to ISUP interface and the ISUP to MTP interface, the ISUP module supports non-primitive requests for configuration and diagnostic purposes. The message structure and parameters for each message are defined in the following subsections.

When the ISUP module returns a confirmation message containing a status value, the status will be one of the following:

Value Mnemonic Description

0 none Success

1 ISPE_BAD_ID Inappropriate or invalid id in request message.

5 ISPE_BAD_MSG Inappropriate or unrecognized message type.

6 ISPE_BAD_PARAM Invalid parameters contained in message.

7 ISPE_BAD_LICENSE Invalid message / parameter for this license.

8 ISPE_NO_MEMORY No memory available.

8.1 Configure Request This message must be the first message issued to the ISUP module. It is used to configure the environment dependent features for the module. It is sometimes referred to as the „per-module‟ configuration message. Please

refer to Section 2.2: Module Configuration on page 14 for details of how the configuration messages are used.

Message Header

structure MSG

type ISP_MSG_CONFIG (0x7700)

id 0


dst ISUP module ID


hclass 0x00

status 0x00

err_info 0x00

len 40


117

Parameter Area

parameters offset 0, size 2 options Run time options

offset 2, size : module_id Used for partner module_id

offset 3, size 1 mngt_id Management module id.

offset 4, size 1 user_id User's module id.

offset 5, size 1 mtp_id MTP module id

offset 6, size 1 sccp_id SCCP module id (not currently used)

offset 7, size 1 maint_id Maintenance module id.

offset 8, size 2 timer_res Timer resolution.

offset 10, size 2 num_tscan Number of ticks per second.

offset 12, size 2 num_grps Max number of circuit groups in use.

offset 14, size 2 num_ccts Max number of circuits in use.

offset 16, size 2 max_sif Max length of SIF supported by MTP.

offset 18, size 1 sio Service Information Octet.

offset 19, size 1 trace_id Trace module id. .

offset 20, size 2 gap_msgs Number of messages sent every gap_tim ticks.

offset 22, size 2 gap_tim Number of ticks between gap_msgs messages.

offset 24, size 16 reserved Reserved for future use – set to zero.

ISUP Response


type 0x3700

status SUCCESS

ISPE_BAD_PARAM


118

Parameters

options

Run-time options assigned according to the following table:

Bit Number Mnemonic Description

0 ISPF_TFRM If set to 1, messages sent to the MTP module will use T_FRAME format. If set to zero, messages sent to the MTP will use the MSG format.

1 ISPF_DUAL When set to 1, if a message is received from MTP for a circuit that does not belong to a circuit group, the message is passed on to the partner module specified in the module_id field of this message. This option allows two instances of the ISUP module to exist in a single signaling point. Each instance handles a sub-set of the total circuits and co-operates with the other instance to ensure that all messages arrive at the correct instance. Note that for correct operation, all circuits on one route must be handled by the same instance of ISUP.

2 ISPF_ACR This bit should always be set to 1 for applications conforming to the call release procedures described in this issue of the ISUP programmer‟s manual.

Earlier application versions will set this bit to zero.

3 ISPF_CCR If set to 1, when a call collision is detected, the ISUP module will release the call to the user by sending a REL with cause value 44 “circuit is not available”.

4 ISPF_NAI This bit should always be set to 1 for applications conforming to the call clearing procedures described in this issue of the ISUP programmer‟s manual.

Earlier application versions will set this bit to zero.

5 ISPF_UCIC If set to 1, when the module receives a message for an unrecognized circuit it will issue an Unequipped CIC (UCIC) message and will recognize receipt of a UCIC message.

Note: for new applications this option should be set to 0 and the corresponding circuit group extended option ISPXGOP_UCIC (bit 15) used instead. This option is retained for backwards compatibility.

6 ISPF_GSPS If set to 1, causes a Circuit Group Supervision Indication (one for each circuit group affected) to be sent to indicate remote point code availability instead of the Remote Point Code Status Indication primitive.

7 Reserved Reserved for future use and must be set to zero.

8 ISPF_24PC If set to 1, causes 24 bit point codes, 14 bit cic and 5 bit sls to be used. If set to zero, 14 bit point codes, 12 bit cic and 4 bit sls will be used.

9 ISPF_ANSI If set to 1, ANSI (T1.113 - 1992) operation is selected.

Note: for new applications this option should be set to 0 and the variant parameter of the Configure Circuit Group Request message should be used instead. This option is retained for backwards compatibility.


119


10 ISPF_RPT_UERR If set to 1, unexpected messages, unexpected parameters and formatting errors in messages from the user application are reported. Refer to Section 8.21: Software Event Indication on page 159. (ISPe_PAR_FMT_ERR, ISPe_PAR_UNEXPECTED, ISPe_MSG_UNRECOG, ISPe_FMT_ERR, ISPe_WRONG_CID, and ISPe_UMSG_UNEXPECTED) for further information.

11 ISPF_PC_SIZE If set to 1, the size of the point code used is determined at run-time for messages received from the MTP. (The label format is indicated in the id field of the MTP_TRANSFER_IND).

If the option is not set, the point code size of a message received from the MTP is determined by the setting of the ISPF_24PC module option.

Note: currently this option may only be used when using 16-bit point codes (i.e. when ISPX1GOP_16PC is set).

12 ISPF_16CID If set to 1, the most significant bit of the call reference will no longer be automatically set by the ISUP module to indicate outgoing calls, instead, the most significant bit now forms part of the actual circuit id.

If set to 0 and up to a maximum of 32768 circuits are configured, the most significant bit of the call reference will be automatically set by the ISUP module to indicate outgoing calls. (This is backwards compatible with earlier versions of ISUP). If more than 32768 circuits are configured, the most significant bit of the call reference will not indicate an outgoing call but instead it is part of an actual circuit id.

13 ISPF_1ST_RESUME

If set to 1, this will enable a ISP_CGSC_IND message (0x070c) to be sent on receipt of the first MTP-RESUME message.

14 – 15 Reserved Reserved for future use – set to zero.

module_id

The module id for the partner ISUP module. (The contents of this field are only used when the ISPF_DUAL bit is set in the options field).

mngt_id

The module id for the management module. This is the module to which all event and error indications and signaling point status indications are sent. It is also the default module id for the per-circuit group mngt_id when not specified separately in the circuit group configuration message.

user_id

The default module id for the application module used when the per-circuit group user_id is not specified in the circuit group configuration message.

mtp_id

The default module id for the MTP module used when the per-circuit group mtp_id is not specified in the circuit group configuration message.


120

sccp_id

Reserved for future use, this should always be set to zero.

maint_id

The default module id for the maintenance module used when the per-circuit group maint_id is not specified in the circuit group configuration message.

timer_res

The number of system ticks between timer expiry messages being issued to the ISUP module. This should usually be configured so that a timer expiry message is sent to the ISUP module every 100ms.

num_tscan

The number of timer expiry messages received for each full scan of the protocol timer table. This should usually be set to 10 so that each timer is checked once per second (or every 10 timer expiry messages).

num_grps

The maximum number of circuit groups that will be used.

num_ccts

The maximum number of circuits that will be used.

max_sif

The maximum length Signaling Information Field permitted by the MTP. This

may be set to up to 4200 depending on the MTP capabilities. Typical value is

272 or, when large messages are used, 544.

sio

The default value to be used for the Service Indicator Octet in messages issued to the MTP when the per-circuit group SIO is not specified in the circuit group configuration message.

trace_id

Trace module id. Module id to which trace messages will be sent. If this parameter is not supplied (set to zero) trace messages will be sent to the management module id.

gap_msgs

Maximum number of pc status indication messages sent every gap_tim ticks.

If this parameter is not supplied (set to zero), maximum 5 messages will be sent every ticks.

gap_tim

Number of ticks between gap_msgs messages.


121

8.2 Configure Circuit Group Request This message is used to assign circuits to a circuit group and to configure the operating parameters for the circuit group.

Message Header

structure MSG

type ISP_MSG_CNF_GRP (0x7701)

id gid


dst ISUP module ID


hclass 0x00

status 0x00

err_info 0x00

len 64 (see below)

Parameter Area

parameters offset 0, size 4: opc The point code of the SP.

offset 4, size 4: dpc The point code of the remote SP.

offset 8, size 2: base_cic The first CIC in the circuit group.

offset 10, size 2: base_cid Circuit Identifier corresponding to first CIC.

offset 12, size 4: cic_mask Bits set to indicate circuits included in group.

offset 16, size 2: options Circuit group options.

offset 18, size 2: ext_options Extended options.

offset 20, size 1: mngt_id Management module id.

offset 21, size 1: mngt_inst Management module instance number.

offset 22, size 1: user_id User module id.

offset 23, size 1: user_inst User module instance number.

offset 24, size 1: mtp_id MTP3 module id.

offset 25, size 1: mtp_inst MTP3 module instance number.

offset 26, size 1: sccp_id Reserved - set to zero.

offset 27, size 1: sccp_inst Reserved - set to zero.

offset 28, size 1: maint_id Maintenance module id.

offset 29, size 1: maint_inst Maintenance module instance number.

offset 30, size 1: sio Circuit group sio.

offset 31, size 1: tim_tab_id Set of timer table id for circuit group.

offset 32, size 4: ext_1_options More extended options.


122

parameters offset 36, size 1: variant Specific variant of ISUP selected for the group.

offset 37, size 1: ihop_count Initial hop count value

offset 38, size 2: base_cic_msb Most significant byte of the base_cic, (BICC)

offset 40, size 24:

Reserved for future use – set to zero.

ISUP Response


type 0x3701

status SUCCESS

ISP_BAD_ID

ISP_BAD_PARAM

Parameters

opc

The originating point code to be used in all ISUP messages issued for circuits

in the circuit group. The opc will usually be set to the same value for all circuit groups at a signaling point.

dpc

The destination point code is the point code of the signaling point at the remote end of the voice circuits in the circuit group.

base_cic

The Circuit Identification Code of the first circuit in the circuit group. This

value must be agreed between administrations before configuring the module.

base_cid

The Circuit Identifier used for the circuit corresponding to the first cic in the circuit group. The Circuit Identifier is of local significance only. The user however must ensure that each cid is allocated to only one circuit group!

cic_mask

Each circuit group may contain up to 32 circuits. The circuits allocated to the circuit group are identified by setting bits in the cic_mask. The least significant bit (bit 0) corresponds to the first cic and must always be set. Bit

n in the cic_mask (if set) corresponds to circuit identification code = (base_cic + n) and circuit identifier = (base_cid + n). If the bit is not set then this cic and cid can instead be allocated to a different circuit group.

Note that a single circuit group may not span more than 32 cics (or 24 cics for ANSI circuit groups).


123

options

The options field allows various run-time options as shown in the following table to be selected for the circuits in the circuit group.


0 - 1 - Outgoing call priority set as follows:

0 - Incoming call priority on all circuits.

1 - Outgoing call priority on all circuits.

2 - Highest point code has priority on even cics.

3 - Highest point code has priority on odd cics

2 ISPGOP_ACM_CTRL If set to 1, the ISUP module will run timer T7 whilst awaiting ACM. If set to zero timer T7 will not be used.

3 ISPGOP_ANM_CTRL If set to 1, the ISUP module will run timer T9 whilst awaiting ANM. If set to zero timer T9 will not be used.

4 ISPGOP_SUS_CTRL If set to 1, the ISUP module will run timer T2 or T6 whilst in the Suspended state. If set to zero timers T2 and T6 will not be used.

5 ISPGOP_RST_REQD If set to 1, the state of the circuit once configured is 'unknown' and must be reset before becoming available for use by ISUP. If set to zero, the state of the circuit once configured will be initialized to 'idle'.

6 ISPGOP_REQ_CLI If set to 1, the calling line identity (CLI) will be automatically requested during incoming call set-up if not provided in the IAM.

7 ISPGOP_EN_ST If set to 1, an ST (end of dialing) address signal will be generated (i.e. a SAM containing only an ST digit will be generated) and issued to the user during incoming call set-up after a period of T10 after the last address signal has been received, if no ST digit was included.

8 ISPGOP_USR_SVC1 If set to 1, the user application is able to process user to user supplementary service 1. If set to zero, incoming calls containing an essential user to user service 1 request will be released by the ISUP module with cause 69, „requested facility not implemented‟.




124


11 ISPGOP_COM If set to 1, the user application is permitted to send a Call Offering Message (COM) to the network. This option is intended for use only in the Italian national network and should otherwise be set to zero.

12 ISPGOP_T35 If set to 1, protocol timer T35 will be enabled. If set to zero, timer T35 will be disabled. T35 is started on receipt of an IAM from the network and restarted on receipt of any SAM messages until an ST digit is received. If the timer expires, the call is automatically cleared.

13 Reserved Reserved for future use and must be set to zero.

14 ISPGOP_TCCR_CTRL If set to 1, the ISUP module will run T104 which is used whilst awaiting the LPA message after having sent CCR. On expiry, the circuit is reset. If set to zero, T104 will not run and the LPA message will not be handled.

15 Reserved Reserved for future use – set to zero.

ext_options

The extended options field allows various run-time options as shown in the following table to be selected for the circuits in the circuit group.


0 ISPXGOP_BLK_767 This bit selects the abnormal circuit group blocking procedures to be used and should be set as follows:

0 - Q.764 (Blue Book) operation

1 - Q.767, Q.764 (03/93) and ANSI T1.113 operation

1 ISPXGOP_UBK_MH If set to 1, a received circuit group unblocking message will remove both the remote Maintenance and Hardware blocking conditions regardless of the value of the received circuit group supervision message type indicator. Otherwise, the type of a received Unblocking message must match that of the previously received Blocking message to remove the remote blocking condition.

2 ISPXGOP_RPT_CGSM If set to 1, the ISUP module will repeat CGB messages for each circuit group blocking operation and repeat GRS for each circuit group reset operation. If set to zero, only one message will be issued for each operation.

Note: this option should be set for ANSI based operations.

3 ISPXGOP_UMSG_CFN If set to 1, when the module receives an unrecognized protocol message it will issue a „Confusion‟ (CFN) message and will recognize receipt of a CFN message.


125


4 ISPXGOP_ANSI If set to 1, ANSI (T1.113 - 1992) operation is enabled. Typically, for ANSI operation in accordance with T1.113 bits 0, 1, 2, 3, 4, 5 and 13 need to be set.

Note: for new applications, this option should be set to 0 and the variant parameter in this message should be used instead. This option is retained for backwards compatibility.

5 ISPXGOP_PRI_BA If set to 1 message priority in accordance with T1.111.5 (1992) will be encoded in the MTP-label SSF bits BA.

6 ISPXGOP_T34 If set to 1, T34 will be enabled. If set to zero, T34 will be disabled. T34 is started on receipt of a message with the segmentation indicator set (indicating that a second segment is expected) in an exchange which reassembles segments (i.e. exchange type 1, 3, 5, or 6). If the timer expires, an empty message segment (i.e. a SGM message with no parameters) will be passed to the user.

7 ISPXGOP_TRAN_PAM If set to 1, any Pass-along message received by ISUP will be transferred as a Pass-along message (providing that it is received in a valid call state) and the application will need to handle the received PAM accordingly. If set to zero, the message contained within the PAM will be extracted and processed.

8 - 10 ISPXGOP_COMPAT 0 - Blue Book compatibility handling is performed

(i.e. unrecognized messages and parameters are handled as specified in Blue Book)

The following values all relate to Q.764 (03/93) operation:

1 - no compatibility handling is performed (all unrecognized messages and parameters are passed to the user application)

2 - end node (i.e. exchange type A) message and parameter compatibility handling will be performed (passing on unrecognized information is possible)

3 - end node (i.e. exchange type A) message and parameter compatibility handling will be performed (passing on unrecognized information is not possible)

4 - transit (i.e. exchange type B) message and parameter compatibility handling will be performed

5-7 - reserved for future use

11 ISPXGOP_ITU92 Note: For new applications, this option should be set to 0 and the variant parameter in this message should be used instead. This option is retained for backwards compatibility. If set to 1, this option may be used to set to enable the ITU-T 1992 extensions.


126


12 ISPXGOP_CAUSE_767 If set to 1, the format and usage of the Cause indicators parameter sent out follows Q.767 i.e. the Recommendation field and diagnostics are not included. Also, the Cause indicators parameter is not sent in an RLC message. If set to zero, the format and usage of the Cause indicators parameter sent out follows Q.763.

13 ISPXGOP_DEL_ST If set to 1, removes any ST digit from the end of the Called party number.

14 ISPXGOP_24PC This option is for future use. It should currently be set to zero.

15 ISPXGOP_UCIC If set to 1, when the module receives a message for an unrecognized circuit it will issue an „Unequipped CIC‟ (UCIC) message and will recognize receipt of a UCIC message. If set to zero, the value of the UCIC module option i.e. ISPF_UCIC will be used to determine if a UCIC message is recognized.

mngt_id

The module_id of the module for which circuit group supervision indications and confirmations for this circuit group will be sent. If this field is set to zero or the length of the parameter area is less than 26 bytes (for backwards compatibility with previous releases of software) then ISUP will use the

mngt_id supplied in the per-module configuration message and force the mngt_inst to zero.

mngt_inst

The instance number used in messages sent to the mngt_id module.

user_id

The module_id of the module for which received indications for this circuit group will be sent. If this field is set to zero or the length of the parameter

area is less than 26 bytes (for backwards compatibility with previous releases of software) then ISUP will use the user_id supplied in the per-module configuration message and force user_inst to zero.

user_inst

The instance number used in messages sent to the user_id module.

mtp_id

The module_id of the module for which all MTP-TRANSFER-REQ messages are sent If this field is set to zero or the length of the parameter area is less than 26 bytes (for backwards compatibility with previous releases of software) then ISUP will use the mtp_id supplied in the per-module configuration message and force mtp_inst to zero.

mtp_inst

The instance number used in messages sent to the mtp_id module.


127

sccp_id

Reserved for future use, this should always be set to zero.

maint_id

The module_id of the module for which all protocol maintenance indications are sent. If this field is set to zero or the length of the parameter area is less than 26 bytes (for backwards compatibility with previous releases of

software) then ISUP will use the supplied in the per-module configuration message and force maint_inst to zero.

maint_inst

The instance number used in messages sent to the maint_id module.

sio

The value to be used for the Service Indicator Octet in messages issued to the MTP for the group being configured, instead of the sio provided in the

module configuration message. If the length of the parameter area is less than 64 bytes (for backwards compatibility with previous releases of software) then ISUP will use the sio supplied in the per-module configuration message.

tim_tab_id

The id of the timer table to be used for circuits in this group. If the length of the parameter area is less than 31 bytes (for backwards compatibility with

previous releases of software) then ISUP will use timer table 0. Up to four timer tables (id 0 to 3) are supported by the module.

ext_1_options

Further run-time options assigned according to the following table:


0 ISPX1GOP_ADD_ST If set to 1, messages sent to the user will have an ST digit added to the called party number.

Note: this option may also be used for ANSI ISUP, which does not allow use of the ST digit, and means that the format of the Setup indication is the same regardless of whether the call is received over ANSI or ITU ISUP.

1 ISPX1GOP_16PC If set to 1, circuit groups are configured to use 16-bit point codes. Note that currently all groups must use the same point code size. This circuit group option is intended to be used in conjunction with the ISPF_PC_SIZE module option.

2 ISPX1GOP_T33EXP_NOREL If set to 1, when timer T33 expires, the call is NOT released.

3 ISPX1GOP_USR_SVC_PRV If set to 1, user-to-user service does not have to be requested to use user-to-user information parameter.


128


4 ISPX1GOP_T39 If set to 1, this will cause timer T39 (waiting for IRS after sending IDR) to be initiated. If set to zero, timer T39 will not be initiated after sending the IDR message.

Typically, this option would be set for the MCID supplementary service at a destination exchange.

5 ISPX1GOP_T38 If set to 1, this will cause timer T38 (wait for RES message) to be initiated. If set to zero, timer T38 will be disabled.

6 ISPX1GOP_SEND_UPT If set to 1, this will enable the user part unavailability procedure to be initiated by causing a „user part test‟ message to be sent to the network when a MTP-STATUS message indicating “user part unavailable – inaccessible remote user” is received.

This option will dictate whether a „user part test‟ message is sent on receipt of an MTP-STATUS primitive and will not affect the sending of a „user part available‟ message in response to the „user part test‟ message.

Note that all groups with the same DPC must have the same setting of this option otherwise configuration will fail.

For ITU-T operation, if this procedure is initiated a UPT message will be sent to the network and the ISUP module will wait for a UPA message in response.

7 ISPX1GOP_TX_CRG The ISUP module supports a generic mechanism for handling the Charge (CRG) message providing that the variant used is based upon ITU-T.

If set to 1, any Charge Request primitive received by the ISUP module from the user application will be passed in the transparent format to the network and a CRG message received from the network will be passed transparently to the user as a Charge Indication primitive.

Note: this option is applicable to ITU operation only. If using Italian ISUP this option should not be set since specific handling has been implemented for this variant).

8 ISPX1GOP_CCL If set to 1, any Calling Party Clearing Indication received will be passed transparently to the user application.

If set to zero, when a Calling Party Clearing Indication is received, this message will be mapped to a Release Indication with a proprietary cause value of 0x7c (to indicate that a Calling Party Clearing Indication has been received) and sent to the user application instead.

9 ISPX1GOP_AUTO_BLK If set to 1, this will enable Circuit Group Auto Blocking functionality. A Heartbeat message will be sent by ISUP to the User Instance which must be confirmed.


129


10 Reserved for future use – set to zero.

11 ISPX1GOP_SET_LOC

Used in conjunction with ISPX1GOP_LOC to set the location value to be indicated in the cause parameter.

If set to 1, the location value in the cause parameter will be determined by the 4-bit ISPX1GOP_LOC option. Otherwise the location value is set to 0x05 = “Private network, remote user (RPN)”.

12-15 ISPX1GOP_LOC Sets the location value to be indicated in the cause parameter during call release.

The following cause location values are defined by Q.850:

0x00 - “User (U)”

0x01 - “Private network, local user (LPN)”

0x02 - “Public network, local user (LN)”

0x03 - “Transit network (TN)”

0x04 - “Public network, remote user (RLN)”

0x05 - “Private network, remote user (RPN)”

0x07 - “International (INTL)”

0x0a - “Beyond interworking point (BI)”

0x0c - “Reserved”

0x0d - “Reserved”

0x0e - “Reserved”

0x0f - “Reserved”

16 ISPX1GOP_TREASS If set to 1, the syntax of segmented Application Transport parameters is checked, and timer Treass (BICC) will be enabled. If set to zero, the syntax is not checked and timer Treass will be disabled.

Timer Treass is started on receipt of a BICC message containing an APP parameter with the sequence and segmentation indicators indicating that more segments are expected. If the timer expires, an APM message will be passed to the user.

17-18 BICX1GOP_COMPAT 0 - no compatibility handling is performed (all unrecognized BICC IEs are passed to the user application)

1 – IE compatibility handling will be performed (passing on unrecognized information is possible)

2 - IE compatibility handling will be performed (passing on unrecognized information is not possible)

19 ISPX1GOP_NO_EOOP 0 - Add an End of Optional Parameters octet to the end of messages (that may contain optional parameters) when no optional parameters are present.

1 - ISUP messages containing no optional parameters will be transmitted to the network without the End of Optional Parameters octet.


130


20 ISP1GOP_NOCUG If set to 1 incoming calls will automatically be released with cause #29 when the „Closed user group call indicator‟, in the Optional Forward Call Indicators parameter, is set to “closed user group call, outgoing access not allowed”.

21 ISPX1GOP_IC_CPG If set to 1support the reception of a CPG in the forward direction.

22 ISPX1GOP_SLS8 If set to 1 and ISUP has been configured for 24 bit point codes ISUP will set the SLS to the 8 least significant bits of the CIC otherwise it will set the SLS to 5 bits

23 - 31 Reserved Reserved for future use and must be set to zero.

variant

This field allows different specific variants of ISUP to be selected for a group. This parameter can be configured on a per-circuit group basis and takes the following values:


Dec Hex

0 0x00 ISPGVAR_BB Blue book ISUP (Q.761 – Q.764 1988)

(Default option)

1 0x01 ISPGVAR_ITU92 Q.761 – Q.764 (1992 and later editions)

Also used for national variants that are closely based on Q.763.

2 0x02 ISPGVAR_ANSI ANSI ISUP (T1.113-1992)

3 0x03 ISPGVAR_GER German ISUP1

4 0x04 ISPGVAR_UK UK ISUP2

5 0x05 ISPGVAR_TTC Japan TTC ISUP3

6 0x06 ISPGVAR_ANSI_RLT Nortel RLT - ANSI4

7 0x07 ISPGVAR_ITU_RLT Nortel RLT - ITU5

8 0x08 ISPGVAR_ANSI95 1995 ANSI ISUP (T1.113-1995)

9 0x09 ISPGVAR_ITAL Italian ISUP6

10 0x0a ISPGVAR_SSURF French ISUP7

11 0x0b ISPGVAR_CHN China ISUP8

1 German ISUP Specification: Zeichengabe im ZZN7 Version 3.0.0 2 UK ISUP Specification: PNO-ISC Specification Number 007 ISDN User Part (ISUP) 3 Japan (TTC) ISUP Specification: JT-Q761-JT-Q764 and JT-Q850 4 Nortel RLT (ANSI) Specification: Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 297-2621-345 Preliminary 04.01 August 1999 5 Nortel RLT (ITU) Specification: 411- 2131-199 Standard 08.04 August 1998 Wireless Networks DMS-MTX Software Delta for Planners MTX07 6 Italian ISUP Specification: Specifica Tecnica N.763 7 French ISUP Specification: SPIROU 1998 – 002-005 edition 1 8 China ISUP Specification: YDN 038 (1997)


131


Dec Hex

12 0x0c ISPGVAR_ITU2000 ISUP‟2000

13 0x0d ISPGVAR_BICC BICC [24] to [30]

253 0xfd ISPGVAR_CUST02 Custom variant CUST02

254 0xfe ISPGVAR_CUST01 Custom variant CUST01

Further details related to the above national or proprietary ISUP variants can be found in Appendix A: ISUP National Variants on page 168.

Note: The existing options in previous releases that allow 1992 ISUP and ANSI ISUP to be configured may still be used for backwards compatibility.

ihop_count

This field contains the initial hop count value. Refer to Section 6.8.3: Hop

Counter Procedure on page 90 for details.

cic_msb

This field contains the two most significant bytes of the base_cic of the first circuit of the group when the group is using BICC variant.

8.3 Configure Timers Request This message is used to configure the timer values for all of the ISUP protocol timers. It is an optional message and need not be issued if the internal default timer values are acceptable. The message may be issued at any time

after the initial per-module configuration message has been sent to the ISUP module. Timer values will take effect the next time the timer is started.

The timer resolution for all protocol timers is either in units of num_tscan system ticks or (in the case of T29 and T30) individual system ticks. Usually the system tick is set to 100ms and num_tscan (in the per-module configuration message) is set to 10 giving timer units of 1 second and 100ms respectively.

The maximum timer value is 512 seconds.

The ID field is used to select the timer table to be configured. Up to four

timer tables can be supported.

Note The signaling point timers always use table 0.

Message Header

structure MSG

type: ISP_MSG_CNF_TIM (0x7702)

id tim_tab_id


dst ISUP module ID

rsp_req Sending layer‟s bit set if confirmation required


132

hclass 0x00

status 0x00

err_info 0x00

len 0, 80, or 128 (see below)


133

Parameter Area

parameters offset 0, size 1: version Version of configure timers message

offset 1, size 1: reserved Must be set to zero.

Offset 2, size 2: t1

offset 4, size 2: t2



























offset 58, size 2: t29 (Resolution in ticks)

offset 60, size 2: t30 (Resolution in ticks)






134

Parameter Area

parameters offset 70, size 2: t35







offset 84, size 2: treass

offset 86, size 2: Reserved for future use – set to zero.

ISUP Response

Method By returning the message to the sender

Type 0x3702

Status SUCCESS

Parameters

version

The version of the Configure Timer Request message being used.

Note: A message length of 0 may also be used with either version 0 or version 1. This causes the ISUP timers to be set to their default values.

8.3.1 Timer default values

The following tables gives the ISUP and BICC timers default values (a tick

period of 100ms and num_tscan set to 10 are assumed):

Timer ISUP Default (seconds)

BICC Default (seconds)

Description

t1 10 10 Waiting for RLC

t2 180 0 Waiting for user resume on receipt of user suspend

t3 180 0 Waiting to Initiate release on receipt of overload message

t4 300 0 Waiting for UPA (ITU)

t5 60 60 Delay to alert maintenance on failure to receive RLC

t6 180 180 Waiting for network resume or REL on receipt of network suspend

t7 25 25 Waiting for ACM or CON

t8 13 13 Waiting for cot after IAM

t9 45 45 Waiting for ANM

t10 5 0 Waiting to receive last address digits


135



Description

before sending ACM

t11 not implemented not implemented N/A

t12 10 0 Waiting for BLA

t13 60 0 Delay to alert maintenance on failure to receive BLA

t14 10 0 Waiting for UBA

t15 60 0 Delay to alert maintenance on failure to receive UBA

t16 10 10 Waiting for RLC after sending RSC not due to T5 expiry

t17 60 60 Delay to alert maintenance on failure to receive acknowledgement of RSC.

T18 10 10 Waiting for GBA

t19 60 60 Delay to alert maintenance on failure to receive GBA

t20 10 10 Waiting for GUA

t21 60 60 Delay to alert maintenance on failure to receive GUA

t22 10 10 Waiting for GRA

t23 60 60 Delay to alert maintenance on failure to receive GRA

t24 2 0 Waiting for sending COT on receipt of backward check tone

t25 5 0 Waiting for sending CCR and repeat continuity check

t26 120 0 Waiting for sending CCR on subsequent cot failure

t27 240 0 Waiting for continuity check request on receipt of cot failure indication

t28 10 10 Waiting for CQR

t29 0.5 0.5 Waiting for new congestion indication

t30 8 8 Delay to restore traffic by one step on receipt of congestion indication



t33 14 14 Waiting for INF after sending INR

t34 3 3 Waiting for segmentation message

t35 20 20 Waiting for ST digit of for the minimum of digits

t36 13 0 Wait for REL after receiving CCR (Note: ANSI T1.113-1995 refers to this timer as T34)



136



Description

t38 150 150 Waiting for RES

t39 10 0 Waiting for IRS

t40-t102 not implemented not implemented N/A

t103 20 20 Timer Tccr,r, (only in ANSI mode) – Waiting for receiving CCR after COT failure

t104 3 3 Timer Tccr – Waiting for LPA

treass 0 18 Timer waiting for last APP segment BICC only)

8.4 End Circuit Group Request This message is used to end a circuit group (and all the circuits in that group). It allows the user to add and remove circuit groups dynamically at run time.

Message Header

structure MSG

type ISP_MSG_END_GRP (0x770f)

id gid


dst ISUP module ID


hclass 0x00

status 0x00

err_info 0x00

len 0

ISUP Response


type 0x370f

status SUCCESS

ISP_BAD_ID


137

8.5 Variant Initialisation This message is used to specify a custom variant to allowing proprietary parameters to be sent and received.

Message Header

structure MSG

type ISP_MSG_SET_CUSTVAR (0x5712)

id cust_variant


dst ISUP module ID


hclass 0x00

status 0x00

err_info 0x00

len 1

Parameter Area

parameters offset 0, size 1 base variant

ISUP Response


type 0x1712

status SUCCESS

ISP_BAD_ID

ISPE_BAD_PARAM

Parameters

cust_variant

The name of custom ISUP protocol variant (refer to variants 0xfd and 0xfe in the „variant‟ field in Section 8.2: Configure Circuit Group Request on page 121).

base variant

The variant on which the custom variant is based e.g. ITU, ANSI. The base

variant should be selected from the existing variants currently supported by the ISUP module (refer to variants 0-9 in the „variant‟ field in Section 8.2 on page 121).


138

8.6 Custom Parameter Configuration This message allows proprietary parameters to be added and removed from an ISUP message.

Message Header

structure MSG

type ISP_MSG_CUSTPARAM (0x5713)

id cust_variant


dst ISUP module ID


hclass 0x00

status 0x00

err_info 0x00

len 32

Parameter Area

parameters offset 0, size 1: version – should be set to zero

offset 1, size 1: operation

offset 2, size 1: message type


offset 8, size 24: parameter types

ISUP Response


type 0x1713

status SUCCESS

ISP_BAD_ID

ISPE_BAD_PARAM

Parameters

version

The version of the Custom Parameter Configuration message

cust_variant

The name of custom ISUP protocol variant (refer to variants 0xfd and 0xfe in

the „variant‟ field in Section 8.2 on page 121.


139

operation

This allows a proprietary parameter to be added or deleted from a particular message type (see „message type‟ parameter) as shown in the table below:

Value Operation Description

0 Add Add the proprietary parameter to the message type.

1 Delete Delete the proprietary parameter from the message type.

Other N/A All other values reserved and currently if used will cause an error indication with status ISPE_BAD_PARAM to be returned.

message type

The message type which the custom parameter must be supported or

removed from.

parameter types

The name of the parameter as used in the network. A maximum of 24 proprietary parameters may be specified in this message. A value of zero in the array of parameter types indicates that the byte is empty (i.e. no parameter specified).

8.7 Change Circuit Group Configuration Request This message will allow certain parameters relating to a specific circuit group (configured) to be changed.

Message Header

structure MSG

type ISP_MSG_CNG_GRP (0x7715)

id gid


dst ISUP module ID


hclass 0x00

status 0x00

err_info 0x00

len 10


140

Parameter Area

parameters offset 0, size 1: mngt_id Management module id.

offset 1, size 1: mngt_inst Management module instance number.

offset 2, size 1: user_id User module id.

offset 3, size 1: user_inst User module instance number.

offset 4, size 1: maint_id Maintenance module id.

offset 5, size 1: maint_inst Maintenance module instance number.


ISUP Response


type 0x3715

status SUCCESS

ISP_BAD_ID

ISPE_BAD_PARAM

Parameters

gid


mngt_id

The module_id of the module for which circuit group supervision indications and confirmations for this circuit group will be sent.

mngt_inst

The instance number used in messages sent to the mngt_id module.

user_id

The module_id of the module for which received indications for this circuit group will be sent.

user_inst

The instance number used in messages sent to the user_id module.

maint_id

The module_id of the module for which all protocol maintenance indications are sent.

maint_inst

The instance number used in messages sent to the maint_id module.


141

8.8 Read RAM Request This message is provided solely for diagnostic purposes to request the address of the ISUP modules internal ram structure for diagnostic purposes.

Read Request to ISUP

structure MSG

type ISP_MSG_R_RAM (0x6704)

id 0


dst ISUP module ID

rsp_req Sending layer's bit set

hclass 0x00

status 0x00

err_info 0x00

len 4

parameters offset 0, size 4: RAM address written by ISUP in response message.

ISUP Response

method By sending a MSG

type 0x2704

status SUCCESS

8.9 Read Circuit Group Request This message is provided solely for diagnostic purposes to request the address of the given circuit group structure in the ISUP modules internal ram structure for diagnostic purposes.


structure MSG

type ISP_MSG_R_GRP (0x6705)

id gid (Circuit Group Identifier)

src originating module ID

dst ISUP module ID

rsp_req sending layer's bit set

hclass 0x00

status 0x00

err_info 0x00

len 4

parameters offset 0, size 4: Address of circuit group structure written by ISUP in response message.


142

ISUP Response

method by sending a MSG

type 0x2705

status SUCCESS

8.10 Read Circuit Request This message is provided solely for diagnostic purposes to request the address of the given per- circuit data structure in the ISUP modules internal ram structure for diagnostic purposes.


structure MSG

type ISP_MSG_R_CCT (0x6706)

id cid (Circuit Identifier)


dst ISUP module ID

rsp_req sending layer's bit set

hclass 0x00

status 0x00

err_info 0x00

len 4

parameters offset 0, size 4: Address of circuit structure written by ISUP in response message.

ISUP Response


type 0x2706

status SUCCESS

8.11 Read Revision Request This message is provided solely for diagnostic purposes to request the module type and software revision number.


structure MSG

type GEN_MSG_MOD_IDENT (0x6111)

id 0


dst ISUP module ID


hclass 0x00


143


status 0x00

err_info 0x00

len 28

parameters

(written by ISUP in response message)

offset 0, size 2: type Currently undefined.

Offset 2, size 1: maj_rev Major version number

offset 3, size 1: min_rev Minor version number

offset 4, size 24: text Null terminated string giving textual module identity

ISUP Response

method by returning the message to the sender

type 0x2111

status SUCCESS

8.12 Read Circuit Group Status Request This message requests the local status of circuits within a circuit group.


structure MSG

type ISP_MSG_R_STATUS (0x6710)

id gid


dst ISUP module ID


hclass 0x00

status 0x00

err_info 0x00

len 68

parameters offset 0, size 4: cic_mask Bits set to indicate circuits for which status is being requested.

offset 4, size 64: status Circuit status.

ISUP Response


type 0x2710

status SUCCESS

ISP_BAD_ID

ISP_BAD_PARAM

ISP_BAD_MSG


144

Parameters

gid


cic_mask

A 32-bit mask indicating to which of the circuits in the circuit group the message applies. A "1" set in bit n (0<n<31) indicates that the message

applies to circuit n.

status

This is an array of 32 pairs of octets, each pair indicating the status of the circuit. Each circuit state is represented by one 16-bit value. The first pair of octets corresponds to the circuit represented by the least significant bit of the cic_mask. The status for any circuit for which the bit in cic_mask is not set will be set to zero.

In each octet pair, the first octet (the most significant octet) is encoded as in the ISUP circuit state indicator parameter defined in ITU-T Recommendation Q.763 ISUP formats and codes (09/97) Section 3.14. Those states used by ISUP are defined in the following two tables (the state values indicated in the tables represents the value of the entire octet) :

Circuit state indicator parameter - bits DC equal to 00:

Value State Description

Maintenance blocking states:

0x00 Maintenance blocking – transient The circuit is in a transient Maintenance State. For example, a blocking message has been sent and no acknowledgement has yet been received.

0x03 Maintenance blocking – unequipped The circuit does not belong to a group.

Circuit state indicator parameter - bits DC not equal to 00:

Value State Description

Maintenance blocking states:

0x0d Maintenance blocking – locally blocked Circuit locally maintenance blocked.

0x0e Maintenance blocking – remotely blocked Circuit remotely maintenance blocked.

Call processing states:

0x04 Call processing – circuit incoming busy Incoming call.

0x08 Call processing – circuit outgoing busy Outgoing call.

0x0c Call processing – circuit idle Circuit idle.

Hardware blocking states:

0x1c Hardware blocking – locally blocked Circuit locally hardware blocked.

0x2c Hardware blocking – remotely blocked Circuit remotely hardware blocked.


145

The second octet (the least significant octet) gives the internal circuit state value of the CPC state machine. The internal circuit states are as follows:

Value State

Incoming call states:

0x00 Incoming call – idle

0x01 Incoming call – waiting for continuity

0x02 Incoming call – waiting for ACM

0x03 Incoming call – waiting for ANM

0x04 Incoming call – answered

0x05 Incoming call – suspended

0x06 Incoming call – waiting for RLC

0x07 Incoming call – waiting for Release confirmation from application

0x08 Incoming call – waiting for Reset response from application

0x09 Incoming call – waiting for Release request from application

0x0a Incoming call – overload

Circuit being reset states:

0x20 internally in an unknown state

0x21 circuit being reset – waiting for release complete (for a circuit involved in a group reset)

0x22 circuit being reset – waiting for GRA

0x23 circuit being reset – waiting for RLC

Call in progress states:

0x44 call in progress – waiting for the application to release

0x45 call in progress – locally autoblocked

0x47 call in progress – waiting RLC (from CPC)

Incoming continuity test call states:

0xc0 incoming continuity test call – idle

0xc1 incoming continuity test call – waiting for CCR

0xc2 incoming continuity test call – waiting for REL

0xc3 incoming continuity test call – waiting for the application to release

0xc4 incoming continuity test call – waiting for CCR and waiting for the application to release

Outgoing call states:

0x80 outgoing call – idle

0x81 outgoing call – waiting for continuity

0x82 outgoing call – waiting for ACM

0x83 outgoing call – waiting for ANM

0x84 outgoing call – answered

0x85 outgoing call – suspended


146

Value State

Outgoing call states:

0x86 outgoing call – waiting for RLC

0x87 outgoing call – waiting for Release confirmation from application

0x88 outgoing call – waiting for Reset response from application

0x89 outgoing call – waiting for Release request from application

0x8a outgoing call – overload

Outgoing continuity test call states:

0xe0 outgoing continuity test call – idle

0xe1 outgoing continuity test call – waiting for timeout (before new continuity test call is initiated)

0xe2 outgoing continuity test call – waiting for backward check tone

0xe3 outgoing continuity test call – waiting for RLC

0xe4 outgoing continuity test call – waiting for LPA


147

8.13 Read Circuit Group Statistics Request This messages request statistics on a per circuit group basis.

Read Measurements Request to ISUP

structure MSG

type ISP_MSG_R_GRP_STATS (0x6719)

id gid


dst ISUP module ID

rsp_req Set to 1 to reset the measurements or 0 to leave measurements unmodified

hclass 0x00

status 0x00

err_info 0x00

len 32

parameters offset 0, size 1: version must be set to zero..

offset 1, size 3: Reserved must be set to zero.

offset 1, size 3: Period The measurement period

offset 4, size 4: ic_attempt Incoming call attempts

offset 8, size 4: og_attempt Outgoing call attempts

offset 12, size 4: ic_answered Incoming calls answered

offset 16, size 4: og_answered Outgoing calls answered

offset 24, size 4: duration Total accumulated call duration for completed calls in the group

offset 28, size 4: max_device Maximum number of devices busy at one time

ISUP Response


type 0x2719

status SUCCESS

ISP_BAD_ID

ISP_BAD_PARAM

ISP_BAD_MSG


148

8.14 Read Circuit Group Data Request This message requests the data for a specified circuit group. The data will be given in the confirmation message and will be of exactly the same format as

the Configure Circuit Group Request (ISP_MSG_CNF_GRP). Refer to Section 8.2: Configure Circuit Group Request on page 121 for details.


structure MSG

type ISP_MSG_R_GRP_DATA (0x6717)

id gid


dst ISUP module ID


hclass 0x00

status 0x00

err_info 0x00

len See Section 8.2: Configure Circuit Group Request on page 121 for details.

Parameters See Section 8.2: Configure Circuit Group Request on page 121 for details.

ISUP Response


type 0x2717

status SUCCESS

ISP_BAD_ID

ISP_BAD_PARAM

ISP_BAD_MSG

Parameters

gid


8.15 Read Circuit Group Identity Request This message requests indication of configured (active) circuit groups. The response provided will be a bit mask of circuit groups.

Message Header

structure MSG

type ISP_MSG_R_GRPID (0x6715)

id base gid


dst ISUP module ID


149

Message Header


hclass 0x00

status 0x00

err_info 0x00

len user defined

Parameter Area

parameters offset 0, size user defined: gid mask Circuit Group Mask

ISUP Response


type 0x2715

status SUCCESS

ISP_BAD_ID

ISPE_BAD_PARAM

Parameters

base gid

The group number from which the ISUP module will start searching for groups

len

The number of bytes of information to be requested e.g. if the group id is 1 and the length is 4 this will request whether groups 1-32 are configured or not.

gid mask

A mask of configured circuit groups where a bit‟s position corresponds to a circuit group id offset from the base gid and it‟s value will indicate whether the corresponding circuit group has been configured in ISUP or not. If the bit is set, this indicates that the corresponding circuit group is configured.

8.16 Send Maintenance Event Mask Request Sends a mask indicating which maintenance events should be active to the ISUP module. All maintenance events are active when the module is initialized. This message can be used to turn off some or all maintenance events or turn them back on again. The message may be sent at any time

after the initial per-module configuration message has been sent to the ISUP module.

Message Header

structure MSG

type ISP_MSG_S_MAINT_MASK (0x570f)


150

Message Header

id 0


dst ISUP module ID


hclass 0x00

status 0x00

err_info 0x00

len 9

Parameter Area

parameters offset 0, size 9: mask Bits set to indicate maintenance events which should be active

ISUP Response


type 0x170f

status SUCCESS

ISP_BAD_PARAM

Parameters

mask

A bit mask indicating maintenance events that are active. A „1‟ indicates that

an event is active and a „0‟ indicates that it is not active. The first octet sent is for maintenance event codes 0-7, the second octet for maintenance event codes 8-15, etc.

Refer to Section 8.20: Maintenance Event Indication on page 155 for a list of maintenance events.

8.17 Send Software Event Mask Request Sends a mask indicating which software events should be active to the ISUP module. All software events are active when the module is initialized. This message can be used to turn off some or all software events or turn them back on again. The message may be sent at any time after the initial per-module configuration message has been sent to the ISUP module.

Message Header

structure MSG

type ISP_MSG_S_ERROR_MASK (0x5710)

id 0


dst ISUP module ID



151

hclass 0x00

status 0x00

err_info 0x00

len 9

Parameter Area

parameters offset 0, size 9: mask Bits set to indicate software events which should be active

ISUP Response


type 0x1710

status SUCCESS

ISP_BAD_PARAM

Parameters

mask

A bit mask indicating the software events that are active. A „1‟ indicates that an event is active and a „0‟ indicates that it is not active. The first octet sent is for software event codes 0-7, the second octet for software event codes 8-15, etc.

Refer to Section 8.21: Software Event Indication on page 159 for a list of

software events.

8.18 Trace Mask Configuration Request Set the ISUP module's event masks for tracing (input and output) messages

to the trace module on a per-primitive basis and tracing non-primitive events on a per-event basis. The Trace Mask Configuration Request message can be used to enable and disable the tracing of some or all of the messages supported by the ISUP module. This message may be sent at any time even before the initial per-module configuration message has been sent to the ISUP module. The fields in the masks are defined below:

Message Header

structure MSG

type ISP_MSG_S_TRACE_MASK (0x5711)

id 0


dst ISUP module ID


hclass 0x00

status 0x00

err_info 0x00


152

Message Header

len 16

Parameter Area

parameters offset 0, size 4: op_evt_mask Output event trace mask

offset 4, size 4: ip_evt_mask Input event trace mask

offset 8, size 4: non_prim_mask Non-primitive trace mask


ISUP Response


type 0x1711

status SUCCESS

ISP_BAD_PARAM

Parameters

op_evt_mask

The output event trace mask. This is a 32-bit value with bits set to 1 to cause a trace message to be sent to the system trace module whenever a message is issued by ISUP for the events indicated:

31 30 29 28 27 26 25 24

0 0 0 0 0 0 0 0

23 22 21 20 19 18 17 16

0 0 0 0 0 0 0 0

15 14 13 12 11 10 9 8

0 0 0 0 0 0 0 0

7 6 5 4 3 2 1 0

0 0 PC STATUS CGSS IND

CGSC IND

CGSC CONF

TRF REQ

RX IND

RX_IND- Receive Indication

TRF_REQ- MTP Transfer Request

CGSC_CONF- Circuit Group Supervision Control Confirmation

CGSC_IND- Circuit Group Supervision Control Indication

CGSS_IND- Circuit Group Supervision Status Indication

PC_STATUS- Remote Point Code Status Indication


153

ip_evt_mask

The input event trace mask. This is a 32-bit value with bits set to 1 to cause a trace message to be sent to the system trace module on receipt of messages indicating the events shown:

31 30 29 28 27 26 25 24

0 0 0 0 0 0 0 0

23 22 21 20 19 18 17 16

0 0 0 0 0 0 0 0

15 14 13 12 11 10 9 8

0 0 0 0 0 0 0 0

7 6 5 4 3 2 1 0

0 OVLD REQ

CGSC REQ

MTP STATUS

MTP RESUME

MTP PAUSE

TRF IND

TX REQ

TX_REQ- Transmission Request

TRF_IND- MTP Transfer Indication

MTP PAUSE - MTP Pause Indication

MTP RESUME - MTP Resume Indication

MTP STATUS- MTP Status Indication

CGSC_REQ- Circuit Group Supervision Control Request

OVLD_REQ- Overload Request

non_prim_mask

The non-primitive trace mask. This is a 32-bit value with bits set to 1 to cause a trace message to be sent to the system trace module when ISUP receives the associated non-primitive message.

31 30 29 28 27 26 25 24

0 0 0 0 0 0 0 0

23 22 21 20 19 18 17 16

0 0 0 0 0 0 0 CONFIG

15 14 13 12 11 10 9 8

HRTBT R GRPID R DATA CNG GRP CUST PARAM

SET CUSTVAR

MGT EV IND

SW EVT


154

7 6 5 4 3 2 1 0

MT EVT SSW MSK

SMT MSK

R STATUS END GRP

CNF GRP

CNF TIM

0 (reserved)

CNF_TIM – Timer Configuration Message

CNF_GRP – Circuit Group Configuration Message

END_GRP – End Circuit Group Request

R_STATUS – Read Circuit Group Status Request

SMT_MSK – Send Maintenance Event Mask Request

SSW_MSK – Send Software Event Mask Request

MT_EVT – Maintenance Event Indication

SW_EVT – Software Event Indication

MGT_EV – Management Event Indication

SET_CUSTVAR – Set Custom Variant Message

CUSTPARAM – Custom Variant Parameter Message

CNG_GRP – Change Circuit Group Configuration Request

R_DATA – Read Circuit Group Data Request

R_GRPID – Read Circuit Group Identity Request

HRTBT - Heartbeat Request/Indication

CONFIG - Configure Request

8.19 Send Selective Trace Event Mask Request This message is issued by the ISUP module to enable additional diagnostic information to be reported along with software and maintenance events for debug purposes. Sends a mask indicating which selective trace events should be active to the ISUP module. This message can be used to turn off some or

all software events or turn them back on again. The message may be sent at any time after the initial per-module configuration message has been sent to the ISUP module.

Message Header

structure MSG

type ISP_MSG_S_SELTRACE_MASK (0x5714)

id 0


dst ISUP module ID


hclass 0x00

status 0x00

err_info 0x00

len 9


155

Parameter Area

parameters offset 0, size 9: mask Bits set to indicate selective trace events which should be active

ISUP Response


type 0x1714

status SUCCESS

ISP_BAD_PARAM

Parameters

mask

A bit mask indicating the selective trace events that are active. A „1‟ indicates that an event is active and a „0‟ indicates that it is not active. The first octet sent is for selective trace event codes 0-7, the second octet for selective trace event codes 8-15, etc.

Refer to Section 8.24: Selective Trace Event Indication on page 164 for a list of selective trace events.

8.20 Maintenance Event Indication This message is issued by the ISUP module to notify system maintenance of various protocol events in accordance with ITU-T Q.764.

Message Header

structure MSG

type ISP_MSG_MAINT_IND (0x070a)

id gid

src ISUP module ID

dst Maintenance module ID

rsp_req 0x00

hclass 0x00

status Maintenance event code (see below)

err_info Time-stamp

len 0, 1, 2 or 4

Parameter Area

parameters offset 0, size Len Event specific data

Parameters

gid



156

Each indication may contain further Event Specific Data relating to the event, this consists of 0, 1, 2 or 4 bytes of additional data which is contained in the parameter area of the message. Currently the event specific data for most events indicates the circuits to which the events apply in terms of a 32-bit cic_mask with bits set to indicate the affected circuits within the circuit group.

Note For reset indications, a 32-bit cic_mask is used but only the affected circuit within the circuit group is indicated e.g. if a number of circuits are reset a maintenance event indication message will be sent for each of the circuits reset.

The Maintenance Event Code contained in the status field of the message indicates the type of event. Possible values are listed in the following table :

Status Data Mnemonic Description

1 0x01 cic_mask CCm_BLR_Blocking Circuit has been remotely maintenance blocked

2 0x02 cic_mask CCm_BLR_Unblocking Circuit has been remotely maintenance unblocked

3 0x03 cic_mask CCm_BLS_Blocking Circuit has been locally maintenance blocked

4 0x04 cic_mask CCm_BLS_Blocked Circuit has been locally maintenance blocked by a group blocking function.

5 0x05 - - Not used.

6 0x06 cic_mask CCm_BLS_Reset Local circuit maintenance blocking removed by circuit reset.

7 0x07 cic_mask CCm_BLS_T13_Expired Failed to receive BLA (T13 expired)

8 0x08 cic_mask CCm_BLS_T13_Recovery BLA received after T13 expiry

9 0x09 cic_mask CCm_BLS_T15_Expired Failed to receive UBA (T15 expiry)

10 0x0a cic_mask CCm_BLS_T15_Recovery UBA received after T15 expiry

11 0x0b cic_mask CCm_BLS_Bad_BLA Received an unexpected BLA

12 0x0c cic_mask CCm_BLS_Bad_UBA Received an unexpected UBA

13 0x0d cic_mask CCm_MGBS_Blocking Initiating local circuit group maintenance blocking

14 0x0e cic_mask CCm_MGBS_BLK_Reset Circuit(s) reset while waiting for maintenance blocking acknowledgement.

15 0x0f cic_mask CCm_MGBS_UBLK_Reset Circuit(s) reset while waiting for maintenance unblocking acknowledgement.

16 0x10 cic_mask CCm_MGBS_T19_Expired Failed to receive Circuit Group maintenance blocking acknowledgement, CGBA, T19 expired


157


17 0x11 cic_mask CCm_MGBS_T21_Expired Failed to receive Circuit Group maintenance unblocking acknowledgement, CGUA, T21 expired

18 0x12 cic_mask CCm_MGBS_T19_Recovery Received CGUA (maintenance) after T19 expired

19 0x13 cic_mask CCm_MGBS_T21_Recovery Received CGUA (maintenance) after T21 expired

20 0x14 cic_mask CCm_MGBR_Blocking Circuits remotely maintenance blocked by receipt of circuit group blocking

21 0x15 cic_mask CCm_MGBR_Unblocking Circuits remotely maintenance unblocked by receipt of circuit group unblocking

22 0x16 cic_mask CCm_HLB_Unblocking Circuit locally hardware unblocked

23 0x17 cic_mask CCm_HRB_Unblocking Circuit remotely hardware unblocked

24 0x18 cic_mask CCm_HGBS_Blocking Circuit(s) locally hardware blocked.

25 0x19 cic_mask CCm_HGBS_BLK_Reset Circuit(s) reset while waiting for hardware blocking acknowledgement.

26 0x1a cic_mask CCm_HGBS_UBLK_Reset Circuit(s) reset while waiting for hardware unblocking acknowledgement.

27 0x1b cic_mask CCm_HGBS_T19_Expired Failed to receive Circuit Group hardware blocking acknowledgement, T19 expired

28 0x1c cic_mask CCm_HGBS_T21_Expired Failed to receive Circuit Group hardware unblocking acknowledgement, T21 expired

29 0x1d cic_mask CCm_HGBS_T19_Recovery Received CGBA (hardware) after T19 expired

30 0x1e cic_mask CCm_HGBS_T21_Recovery Received CGUA (hardware) after T21 expired

31 0x1f cic_mask CCm_HGBR_Blocking Circuit(s) remotely hardware blocked

32 0x20 cic_mask CCm_CRS_T17_Recovery Received single circuit reset response after T17 expired.

33 0x21 cic_mask CCm_CRS_T17_Expired Failed to receive response to single circuit reset, T17 expired

34 0x22 cic_mask CCm_CRS_T23_Recovery Received circuit group reset acknowledgement after T23 expired.

35 0x23 cic_mask CCm_CRS_T23_Expired Failed to receive response to circuit group reset, T23 expired

36 0x24 cic_mask CCm_CRCS_Check_failed Outgoing continuity re-check failed


158


37 0x25 cic_mask CCm_CRCS_Check_ok Outgoing continuity re-check succeeded

38 0x26 cic_mask CCm_CRCS_T5_Expired Outgoing continuity re-check failed to receive RLC (T5 expired)

39 0x27 cic_mask CCm_CRCR_Failure Incoming continuity re-check failed.

40 0x28 cic_mask CCm_CRCR_Recovery Incoming continuity re-check succeeded

41 0x29 cic_mask CCm_CPC_T5_Expired Failed to receive RLC after sending REL, (T5 expired)

42 0x2a cic_mask CCm_MGBS_Bad_CGBA Bad or unexpected circuit group blocking (maintenance) acknowledgement received.

43 0x2b cic_mask CCm_MGBS_Bad_CGUA Bad or unexpected circuit group unblocking (maintenance) acknowledgement received.

44 0x2c cic_mask CCm_MGBS_No_CGBA Failed to receive circuit group blocking (maintenance) acknowledgement

45 0x2d cic_mask CCm_MGBS_No_CGUA Failed to receive circuit group unblocking (maintenance) acknowledgement

46 0x2e cic_mask CCm_HGBS_Bad_CGBA Bad or unexpected circuit group blocking (hardware) acknowledgement received.

47 0x2f cic_mask CCm_HGBS_Bad_CGUA Bad or unexpected circuit group unblocking (hardware) acknowledgement received.

48 0x30 cic_mask CCm_HGBS_No_CGBA Failed to receive circuit group blocking (hardware) acknowledgement

49 0x31 cic_mask CCm_HGBS_No_CGUA Failed to receive circuit group unblocking (hardware) acknowledgement

50 0x32 cic CCm_MDSC_Bad_CIC Message received for an unknown cic. The gid field contains the group Id of a group in the same route.

51 0x33 cic_mask CCm_CQR_T28_Expired Failed to receive a circuit group query response.

52 0x34 cic_mask CCm_SPRC_UCIC_rxd UCIC message received for specified circuit.

53 0x35 cic_mask CCm_SPRC_CFN_rxd Confusion message received for specified circuit.

54 0x36 cic_mask CCm_SPRC_Bad_mtype Bad (unrecognized) protocol message type received on specified circuit.


159


55 0x37 0 CCm_GRS_Bad_cct GRS or GRA received for circuits that are not configured or for an incorrect range.

56 0x38 0 CCm_CGB_Bad_cct CGB or CGBA received for circuits that are not configured or for an incorrect range.

57 0x39 0 CCm_CGU_Bad_cct CGU or CGUA received for circuits that are not configured or for an incorrect range.

58 0x3a 0 CCm_CQM_Bad_cct CQM or CQR received for circuits that are not configured or for an incorrect range.

59 0x3b cic_mask CCm_CC_Zero_hops The number of hops allowed for this call has been exceeded.

60 0x3c cic_mask CCm_HGBS_Unblocking Circuits locally hardware unblocked by receipt of circuit group unblocking.

61 0x3d cic_mask CCm_MGBS_Unblocking Circuits locally maintenance unblocked by receipt of circuit group unblocking.

62 0x3e cic CCm_BLS_Bad_CGU CGU received for circuits that are not configured or for an incorrect range.

63 0xc3f cic CCm_APP_unk_ac98 Unknown '98 AC received

64 0x40 cic CCm_APP_unk_ac2000 Unknown '2000 AC received

65 0x41 cic CCm_APP_len_err_1 Length Error decoding APP - unable to recover segmentation indicator

66 0x42 cic CCm_APP_len_err_2 Length Error decoding APP - unable to recover addresses

67 0x43 cic CCm_APP_ext Invalid extension indicator

68 0x44 cic CCm_APP_seg_ind Invalid segmentation indicator (either > 9, either not x-1)

69 0x45 cic CCm_APP_seg_new Invalid new segment

70 0x46 cic CCm_APP_seg_unexp Unexpected segment

71 0x47 cic CCm_APP_IE Error recovering IE

72 0x48 0 CCm_GEN_Param_discard Parameters have been discarded from a message sent to the network layer due to message size limitations. This event will only be reported once.

8.21 Software Event Indication This message is issued by the ISUP module to notify system management of

various software events specific to the ISUP module which under normal operating conditions should not occur. These events may be due to lack of system resources or errors within the software.


160

Message Header

structure MSG

type ISP_MSG_ERROR_IND (0x070b)

id See below

src ISUP module ID


rsp_req 0x00

hclass 0x00

status Software event code (see below)

err_info Time-stamp

len 0, 2, or 4 bytes (event specific)

Parameter Area

parameters offset 0, size 2: Parameter 1 (optional – dependent on status value)

offset 2, size 2: Parameter 2 (optional – dependent on status value)

The Software Event Code contained in the status field of the message

indicates the type of event. The following table lists the definition of each id field and the parameter fields for each status.

The cic is the Circuit identification code and the cid is the circuit id.

Status Mnemonic id Parameter Description

1 2

3 0x03 ISPe_ISPM_LOW 0 N/A N/A The internal pool of ISPM message buffers is running short of entries. If this fault persists, contact support for assistance.

4 0x04 ISPe_NO_ISPM 0 N/A N/A The pool of ISPM message buffers has been exhausted. If this event occurs then correct operation of the module is not guaranteed.

5 0x05 ISPe_BAD_MSG message type

N/A N/A An unsupported (inter-module) message type has been received by the module.

6 0x06 ISPe_RECV_FAIL cic N/A N/A Format error in received protocol message.

7 0x07 ISPe_TX_FMT_ERR message type

cid N/A Failure to format message for transmission.

8 0x08 ISPe_TIM_START_ERR timer identifier

timer reference

cid An attempt was made to re-use an active timer resource (timer identifier).

9 0x09 ISPe_PAR_FMT_ERR parameter name

cid message type

A parameter whose length is outside the defined limits has been received from the user.


161

Status Mnemonic id Parameter Description

1 2

10 0x0a ISPe_PAR_UNEXPECTED parameter name

cid message type

A parameter which is either unrecognized or not expected in this primitive has been received by ISUP from the user.

11 0x0b ISPe_MSG_UNRECOG message type

cid N/A A message which is unrecognized has been received from the user.

12 0x0c ISPe_BAD_FMT_LABEL 0 N/A N/A Bad label format received.

13 0x0d ISPe_MSG_FMT_ERR message type

cid N/A A badly formatted primitive has been received from the user.

14 0x0e ISPe_WRONG_CID cid message type

N/A A primitive has been received from the user for an unknown circuit ID.

15 0x0f ISPe_UMSG_UNEXPECTED cid message type

state (see following „Call state‟ table)

An unexpected message type has been received from the user.

16 0x10 ISPe_APM_LOW 0 0 0 A message has been received from MTP/M3UA with an APP parameter indicating new but not last segment, and the module is running short of internal APM structures. This is a warning only; the module is still behaving correctly.

17 0x11 ISPe_NO_APM 0 0 0 A message has been received from MTP/M3UA with an APP parameter indicating new but not last segment, and the module has exhausted all internal APM structures.

18 0x12 ISPe_NO_MSG 0 0 0 The pool of long messages has been exhausted. If this event occurs then correct operation of the module is not guaranteed.

Call states

For error indications with status ISPe_UMSG_UNEXPECTED, (0x0f), the valid call states that may be reported are listed in the table below:

Call State Description

0x40 Idle

0x41 Outgoing call set-up

0x42 Incoming call set-up

0x43 Call connected

0x44 Waiting for the application to release

0x45 Locally autoblocked

0x46 Awaiting REL (from CPC)


162

0x47 Waiting RLC (from CPC)

0x48 Awaiting local reset complete

0x49 Overload

0x4a Wait for user to release and reset complete

0x4b Overload – RLC received from user

0x4c Waiting for continuity recheck

0x4d Incoming circuit seized

0x4e Outgoing circuit seized

0x4f Overload (incoming calls)

8.22 Management Event Indication This message is issued by the ISUP module to notify system management of general software events which under normal operating conditions should not occur. These events may be due to lack of system resources or errors within the software.

Message Header

structure MSG

type MGT_MSG_EVENT_IND (0x0008)

id See below

src ISUP module ID


rsp_req 0x00

hclass 0x00

status Management event code (see below)

err_info Time-stamp

len 0

The Management Event Code contained in the status field of the message indicates the type of event. Possible values are listed in the following table which also lists the meaning of the id field in each case.

Status Mnemonic id Description

47 0x2f ERR_SDLSIG_LOW 0 The internal signal queue is running short of entries. If this fault persists, the software should be re-built with more signals allocated to the signal queue.

46 0x2e ERR_NO_SDLSIG 0 The internal signal queue has been exhausted. If this event occurs then correct operation of the module is not guaranteed.


163

8.23 Trace Event Indication The ISUP module may be configured to trace to management most primitives issued or received. This is useful for debug purposes. The ISUP event masks

are used to enable and disable tracing on a per primitive basis for each link. The traced primitives are reported as event indications as shown below:

Message Header

structure MSG

type MGT_MSG_TRACE_EV (0x0003)

id 0

src ISUP module id

dst trace module id

rsp_req 0x00

hclass 0x00

status 0x00

err_info 0x00

len 18 + length of traced data

Parameter Area

parameters offset 0, size 1 source module id

offset 1, size 1 destination module id

offset 2, size 2 id

offset 4, size 2 type

offset 6, size 2 status

offset 8, size 4 timestamp

offset 12, size 4 pointer to the message being traced

offset 16, size 2 data length

offset 18, size 0..280 contents of the MSG parameter area


164

8.24 Selective Trace Event Indication This message is issued by the ISUP module optionally to enable additional diagnostic information to be reported along with selected software events and

maintenance events for debug purposes. When certain maintenance and software events are reported the ISUP module, may be configured to also send, to the Trace module, a Selective Trace Event Indication that caused the event to be reported. For events that are selectively traced the ISUP module will trace the entire message that caused the software or maintenance event to be reported e.g. Initial Address and Group Reset for events such as those

indicating insufficient data or incorrect data.

Message Header

structure MSG

type MGT_MSG_SEL_TRACE (0x0f16)

id 0

src ISUP module ID

dst Trace module ID

rsp_req 0x00

hclass 0x00

status Reason for trace (see below)

err_info 0

len 18 + length of traced data

Parameter Area

parameters offset 0, size 1 source module id

offset 1, size 1 destination module id

offset 2, size 2 id

offset 4, size 2 type

offset 6, size 2 status

offset 8, size 4 timestamp

offset 12, size 4 pointer to message being traced

offset 16, size 2 data length

offset 18, size 0..280 contents of the MSG parameter area


165

The Reason for trace contained in the status field of the message indicates the type of event. Possible values are listed in the following table:

Status Mnemonic Description

Dec Hex

1 0x01 ISPt_Zero_Hops Refer to Maintenance event indication 59 (0x3b).

2 0x02 ISPt_Bad_Cic Refer to Maintenance event indication 50 (0x32).

3 0x03 ISPt_SPRC_CFN_rxd Refer to Maintenance event indication 53 (0x35).

4 0x04 ISPt_SPRC_Bad_mtype Refer to Maintenance event indication 54(0x36).

5 0x05 ISPt_GRS_Bad_cct Refer to Maintenance event indication 55 (0x37).

6 0x06 ISPt_CGB_Bad_cct Refer to Maintenance event indication 56 (0x38).

7 0x07 ISPt_CGU_Bad_cct Refer to Maintenance event indication 57 (0x39).

8 0x08 ISPt_CQM_Bad_cct Refer to Maintenance event indication 58 (0x3a).

9 0x09 ISPt_RECV_FAIL Refer to Software event indication 6 (0x06).

10 0x0a ISPt_PAR_FMT_ERR Refer to Software event indication 9 (0x09).

11 0x0b ISPt_BAD_FMT_LABEL Refer to Software event indication 12 (0x0c).

12 0x0c ISPt_MSG_FMT_ERR Refer to Software event indication 13 (0x0d).

13 0x0d ISPt_UMSG_UNEXPECTED Refer to Software event indication 15 (0x0f).

14 0x0e ISPt_WRONG_CID Refer to Software event indication 14 (0x0e).


166

8.25 Heartbeat Request/Indication This message is issued by the ISUP module to determine the status of the user application for instance whether it is in service and can also be sent, by

the user application, to request a new heartbeat message from the ISUP module.

Message Header

structure MSG

type CAL_MSG_HEARTBEAT (0x7718)

id 0

src 1. ISUP module ID

2. User Application module ID

dst 1. User Application module ID

2. ISUP module ID

rsp_req 0x00

hclass 0x00

status 0x00

err_info 0x00

len 64

Parameter Area

parameters offset 0, size 2: user instance id

offset 2, size 2: state

offset 4, size 2: flags

offset 6, size 58: reserved for future use - set to zero

Parameters

user instance id

The User ID.

state

The status of the user application.

Value Meaning Description

0 Unconfigured No circuit groups have been configured.

1 Down The user application is unavailable and out of service. The circuit groups have been hardware blocked.

2 Up The user application is available and in service.


167

flags

Sets by the ISUP module, or by the user application to indicate or request information respectively.

Bit Mnemonic Description

0 UIHB_FLAGS_CGRPS_BLOCKED

The UIHB_FLAGS_CGRPS_BLOCKED flag can be set in heartbeat messages from the ISUP module and from the user application.

If set in heartbeat messages from the ISUP module, this indicates to the user, that the ISUP circuit group(s) have been blocked.

If set in heartbeat messages from the user application, this indicates to the ISUP module, that the user application is once again available and in service.

1 UIHB_FLAGS_HB_RQST

The UIHB_FLAGS_HB_RQST flag can only be set in Heartbeat messages from the user application to the ISUP module.

If set, this is used by the user application to request a new heartbeat message immediately from the ISUP module. The user application should send this to determine whether the ISUP circuit groups have been blocked.

Appendix A: ISUP National Variants

168


This section will provide message and parameter information specific to each national variant supported by the ISUP module (for configuration settings refer to Section 8.2 on page 121).

Note that the coding and decoding of parameters whose decimal value is greater than 255 will require the use of the parameter extension mechanism described in Section 6.4: Parameter Extension Mechanism on page 23 of this programmer‟s manual.

A.1 German ISUP German ISUP Specification: Zeichengabe im ZZN7 Version 3.0.0

Configuration and options

In order to use this feature, ISPGVAR_GER must be set in the „variant‟ field in the Configure Circuit Group Request message (see Section 8.2 on page 121).

For German ISUP, set the circuit group options as recommended for the „ETSI‟ variant (refer to Appendix D: ISUP Configuration Option Settings on page 189).

Parameters

When this variant is selected, the following German ISUP specific parameters

may be used:

Parameter Name

Parameter Value Mandatory

/Optional

Parameter

Length Message used

Comments

German ISUP API

Hex Dec Hex Dec Min Max

Carrier selection

0xf0 240 0x23* 35* Optional 1 1 IAM Maps to transit network selection parameter (API).

Multi-carrier environment

0xee 238 0x1ee 494 Optional 1 1 IAM

Subscriber priority class

0xfe 254 0xf7 247 Optional 1 1 IAM

NP.FF

[Nationaler Parameter in der IAM]

0xff

255 0x1f8 504 Optional 4 4 IAM

NP.SSP

[Nationaler Parameter für den Service Switching Point]

0xfc

245 0x1f9 505 Optional 1 2 IAM

NP.UKK

[Nationaler Parameter für die

0xff 252 0x1fa 506 Optional 1 3 IAM


169

Ursprungskundenkennug]

* Refer to Section 6.7 on page 76 for details.

A.2 UK ISUP UK ISUP Specification: PNO-ISC Specification Number 007 ISDN User Part (ISUP)


In order to use this feature, ISPGVAR_UK must be set in the „variant‟ field in

the Configure Circuit Group Request message (see Section 8.2 on page 121).

For UK ISUP, set the circuit group options as recommended for the „ETSI‟ variant (refer to Appendix D: ISUP Configuration Option Settings on page 189). In addition to these recommended option settings, the ISPX1GOP_T33EXP_NOREL circuit group option (bit 2 in the „more extended options‟ field) applicable only to UK ISUP must also be set. When set, this will prevent the call from being released on expiry of timer T33 (wait for INF after sending INR).

Parameters

When this variant is selected, the following UK ISUP specific parameters may be used:

Parameter Name

Parameter Value Mandatory/ Optional

Parameter

Length Message used

Comments

UK ISUP API


Called subscriber‟s basic service marks

0xfa 250 0xd0 208 Optional 3 3 ACM, ANM, CPG, CON, INF

Called subscriber's terminating facility marks

0xf7 247 0x1f7 503 Optional 2 2 INF

Calling subscriber's basic service marks

0xf9 249 0xd1 209 Optional 3 3 INF

Calling subscriber‟s originating facility marks

0xf8 248 0xdb 219 Optional 2 2 INF

Last diverting line identity

0xfc 252 0x1fc 508 Optional 2 18 IAM

National information indicators

0xf5 245 0xdc 220 Optional 2 2 INF

National information

0xf6 246 0xdd 221 Optional 2 2 INR


170

Parameter Name


Parameter

Length Message used

Comments

UK ISUP API


request indicators

Presentation number

0xfd 253 0xde 222 Optional 2 18 IAM

National forward call indicators

0xfe 254 0xf6 246 Optional 2 2 IAM Used to convey the CLI Blocking indicator(CBI) and the Network translated address indicator on bit 2.

Partial calling line ID

0xfb 251 0xfb 251 Optional 9 9 IAM

UK national forward call indicators (link-by-link)

0xf4 244 0x1f4 500 Optional 1 2 IAM

A.3 Japan (TTC) ISUP Japan (TTC) ISUP Specification: JT-Q761-JT-Q764 and JT-Q850


In order to use this feature, ISPGVAR_TTC must be set in the „variant‟ field in the Configure Circuit Group Request message (see Section 8.2 on page 121).

For Japanese (TTC) ISUP, set the circuit group options as recommended for the „ITU‟ variant (refer to Appendix D: ISUP Configuration Option Settings on page 189). In addition to these suggested option settings, the ISPF_PC_SIZE module option (bit 11 in the „options‟ field) and the ISPX1GOP_16PC circuit

group option (bit 1 in the „more extended options‟ field) must also be set.

Parameters

When this variant is selected, the following Japanese (TTC) ISUP specific parameters may be used:

Parameter Name Parameter Value Mandatory/ Optional

Parameter

Length Message used

Comments

Japan (TTC) ISUP

API


Additional party's category

0xf3 243 0xf3 243 Optional 2 254 ACM, ANM, CPG, IAM

Carrier information transfer

0xf1 241 0xf1 241 Optional 2 255 ACM, CPG, IAM

Cause of no ID 0xf5 245 0xf5 245 Optional 1 1 IAM

Charge area information

0xfd 253 0x1fd 509 Optional 1 255 ACM, ANM, CPG, IAM

Charge 0xfb 251 0xca 202 Optional 1 255 ACM, CPG


171


Parameter

Length Message used

Comments

Japan (TTC) ISUP

API


information

Charge information delay

0xf2 242 0xf2 242 Optional 1 255 ACM, CPG

Charge information type

0xfa 250 0xe4 228 Optional 1 1 ACM, CPG

National redirection reason

0xf4 244 0xf4 244 Optional 1 1 IAM, REL

Network function type

0xfe 254 0x1fe 510 Optional 2 254 ACM, CON, IAM

Mobile communication call number

0x47 247 0xf0 240 Optional 7 7 ACM, CPG, IAM

Mobile communication end information transfer

0xf8 248 0xe2 226 Optional 1 255 ACM, ANM, CPG, IAM, REL, SUS

PHS terminal identification number

0xf6 246 0xe0 224 Optional 2 18 IAM

Redirecting number*

0x0b 11 0x0b 11 Optional 2 18 IAM

Subscriber number

0xf9 249 0xdf 223 Optional 2 17 IAM


A.4 Nortel RLT

A.4.1 Nortel RLT (ANSI)

Nortel RLT (ANSI) Specification: Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 297-2621-345 Preliminary 04.01 August 1999


In order to use this feature, ISPGVAR_ANSI_RLT in the „variant‟ field must be set in the Configure Circuit Group Request message (see Section 8.2 on page 121).

For Nortel RLT(ANSI) ISUP, set the circuit group options as recommended for the „ANSI‟ variant (refer to Appendix D: ISUP Configuration Option Settings on page 189). In addition to these recommended option settings, the

ISPX1GOP_USR_SVC_PRV circuit group option (bit 3 in the „more extended options‟) must also be set.


172

Parameters

When this variant is selected, the following Nortel RLT(ANSI) ISUP specific parameters may be used:


Parameter

Length Message used

Comments

Nortel RLT (ANSI) ISUP

API


Charge adjustment 0xea 234 0x1f2 498 Optional 6 6 FAR

Operator information 0xe4 228 0x1f1 497 Optional 12 12 FAR

ANM


0x70 112 0xea 234 Optional 1 1 FAR, IAM

Signalling point code* 0x1e 30 0x1e 30 Optional 3 3 FAR

Subsequent number* 0x05 5 0x05 5 Optional 2 17 FAR

Supplementary line information

0x72 114 0x1f3 499 Optional 3 3 IAM

User-to-user information*

0x20 32 0x20 32 Optional 1 129 FAR


A.4.2 Nortel RLT (ITU)

Nortel RLT (ITU) Specification: 411- 2131-199 Standard 08.04 August 1998 Wireless Networks DMS-MTX Software Delta for Planners MTX07


In order to use this feature, ISPGVAR_ITU_RLT must be set in the „variant‟ field in the Configure Circuit Group Request message (see Section 8.2 on page 121).

For Nortel RLT(ITU) ISUP, set the circuit group options as recommended for

the „ITU‟ variant (refer to Appendix D: ISUP Configuration Option Settings on page 189).

Parameters

When this variant is selected, the following Nortel RLT (ITU) ISUP specific parameters may be used:

Parameter Name Parameter Value Mandatory/ Optional Parameter

Length Message used

Comments

Nortel RLT (ITU) ISUP

API


Signalling point code*

0x1e 30 0x1e 30 Optional 2 2 FAR

* Refer to Section 6.7 on page 76.


173

A.5 Italian ISUP Italian ISUP Specification: Specifica Tecnica N.763


In order to use this feature, ISPGVAR_ITAL must be set in the „variant‟ field in the Configure Circuit Group Request message (see Section 8.2 on page 121.

For Italian ISUP set the circuit group options as recommended for the „ITU‟ variant (refer to Appendix D: ISUP Configuration Option Settings on page 189). In addition to these recommended option settings, the ISPGOP_COM

circuit group option (bit 11 in the „options‟ field) applicable only to Italian

ISUP may also be set (refer to „Messages specific to the Italian network„ below).

Messages

Messages specific to Italian ISUP:

Message Name

Message Type

Message Value Usage Comments

Italian ISUP API

Hex Dec Hex Dec

Call Offering

COM 0xe0 224 0x2c* 44* The COM message may be issued by the application for an outgoing call in the waiting ANM state. The ISUP call processing state machine(s) will change state to the outgoing answered state and a Call Offering Message (COM) will be issued to the network

In order to use this message, the ISPGVAR_ITAL variant need not be set but the ISPGOP_COM option in the „options‟ field in the Configure Circuit Group Request message must be set.

To issue a COM message, the application must issue a CPG containing the event information parameter** set to 0x7e.

On receipt of an ACM(user busy) indication, the user application may request an intrusion into an active call by sending a call offering message (COM), in which case the ISUP call processing state machines will enter the connected, speech state.

The COM message has no mandatory or optional parameters.

Maps to the CPG* message (API).

Charge CRG 0x31 49 0x31 49 The CRG message may be issued after call setup and before release in the wait for ACM i.e. in the answered and suspended states.

The CRG message has no mandatory parameters (see „Parameters‟ table).

* Refer to Section 6.5 on page 23 and Section 6.6 on page 50 for details.

** Refer to Section 6.7 on page 76 for details.


174

Parameters

When this variant is selected, the following Italian ISUP specific parameters may be used:

Parameter Name


Parameter

Length Message used

Comments

Italian ISUP API


Charge band

0xe1 225 0x1f0 496 Optional 2 2 CRG

Charge band request

0xe4 228 0x1ef 495 Optional 1 1 IAM

Charge units indicator

0xe3 227 0xff* 255* Optional 1 1 CRG Maps to number of metering pulses parameter (API).


A.6 French ISUP French ISUP Specification: SPIROU 1998 – 002-005 edition 1


In order to use this feature, ISPGVAR_SSURF must be set in the „variant‟ field in the Configure Circuit Group Request message (see Section 8.2 on page 121).

For French ISUP, set the circuit group options as recommended for the „ETSI‟

variant (refer to Appendix D: ISUP Configuration Option Settings on page 189).

Messages

Messages specific to French ISUP:

Message Name Message Type


French ISUP API

Hex Dec Hex Dec

Charge Unit [Unités de taxation]

ITX 0xe1 225 0xc9* 201* Sent in the backward direction in the answered and suspended states to provide a number of charging units.

Maps to MPM message (API).

Charging Acknowledgement [Accusé de reception de taxation]

TXA 0xe2 226 0xca 202 Sent in the forward direction in the answered and suspended states to acknowledge the receipt of a Charge Unit (ITX) [Unités de taxation] message.

The TXA message has no mandatory or optional parameters.


175

* Refer to Section 6.5 on page 23 and Section 6.6 on page 50 for details.

Parameters

When this variant is selected, the following French ISUP specific parameters may be used:


Parameter

Length Message used

Comments

French ISUP API


Called directory number [Numéro d‟annuaire du demandé]

0x7d 125 0x1ed 493 Optional 2 18 IAM

Charge unit number [Nombre d‟unités de taxation]

0xc3 195 0xff* 255* Mandatory 1 1 ITX Maps to number of metering pulses parameter (API).

Message number [Nombre de messages]

0xc2 194 0xd7 215 Mandatory 1 1 ITX


A.7 China ISUP China ISUP Specification: YDN 038 (1997)


In order to use this feature, ISPGVAR_CHN must be set in the „variant‟ field in the Configure Circuit Group Request message (see Section 8.2 on page 121).

For China ISUP, set the circuit group options as recommended for the „ITU‟

variant (refer to Appendix D: ISUP Configuration Option Settings on page 189). In addition to these recommended option settings, the ISPF_24PC module option (bit 8 in the „options‟ field) and the ISPXGOP_24PC circuit group option (bit 14 in the „extended options‟ field) must also be set. The ISPX1GOP_CCL circuit group configuration option (bit 8 in the „more extended options‟ field) applicable only to China ISUP, may optionally be set to enable either a Calling Party Clearing Indication or a Release Indication to be sent to

the user application.


176

Messages

Messages specific to China ISUP:

Message Name Message Type


China ISUP API

Hex Dec Hex Dec

Calling Party Clearing CCL 0xfc 252 0xcc 204 Sent in the forward direction in the answered state.

Refer to the more extended options (ISPX1GOP_CCL) in Section 8.2 on page 121.

Metering Pulse MPM 0xfd 253 0xc9 201 Sent in the backward direction in the answered and suspended states.

Operator OPR 0xfe 254 0xcd 205 Sent in the forward and backward direction in the answered state.

* Refer to Section 6.6.24: Release Indication on page 67 for details.

Parameters

When this variant is selected, the following China ISUP specific parameters may be used:

Parameter Name


Parameter

Length Message used Comments

China ISUP API


Charge information

0xfd 254 0xca 202 Fixed 2 2 MPM

Message compatibility information*

0x38 56 0x38 56 Optional 1 1 CCL,MPM OPR



177

A.8 Finnish ISUP Finnish ISUP Specification: SFS 5779 Signalling in the public switched 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)


In order to use this feature, ISPGVAR_ITU92 must be set in the „variant‟ field in the Configure Circuit Group Request message (see Section 8.2 on page 121) and set the circuit group options as recommended for the „ITU‟ variant

(refer to Appendix D: ISUP Configuration Option Settings on page 189).

Messages

Messages specific to Finnish ISUP:

Message Name

Message Type


Finnish ISUP API

Hex Dec Hex Dec

Charge CRG 0x31 49 0x31 49 The CRG message may be issued after call setup and before release in the wait for ACM i.e. in the answered and suspended states.

The CRG message has two mandatory parameters only – the number of metering pulses* parameter and the tariff type* parameter.


A.9 BICC 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


In order to use this feature, ISPGVAR_BICC must be set in the „variant‟ field in the Configure Circuit Group Request message (see Section 8.2 on page 121).

Parameters specific to BICC:

SIO: BICC has a different SIO from ISUP. While ISUP usually uses 0x05, BICC usually uses 0x0d. The SIO field in the ISP_MSG_CONFIG (0x7700) and ISP_MSG_CNF_GRP (0x7701) messages must be set accordingly.

CIC: The CIC are 32 bits long in BICC. The cic_msb field in the ISP_MSG_CNF_GRP message represents the two most significant bytes of the cic (the least significant bytes being represented by the base_cic).

The module constructs the BICC CIC based on the cic_msb, the base_cic and the cic_mask.

CIC Control: The priority of cics should be allocated as follows:


178

If the value of the OPC is greater than the DPC, priority (or control) should be given to EVEN cics by setting bits 0-1 of the options field in the ISP_MSG_CNF_GRP message to 2.

If the value of the OPC is lower than the DPC, priority (or control) should be given to ODD cics by setting bits 0-1 of the options field in the ISP_MSG_CNF_GRP message to 3.

The module can support both ISUP and BICC groups at the same time under the following conditions:

Groups configured for BICC and ISUP must differentiate by at least the following parameters: OPC, DPC, or SIO. The module does not support BICC and ISUP groups with the same OPC, DPC and SIO.

BICC and ISUP use different timers and timer values. Hence, groups configured for BICC must be configured to use different timer tables

to those groups configured for ISUP. The tim_tab_id field in the ISP_MSG_CNF_GRP message must be set accordingly.

Segmented Application Transport data:

The ISPX1GOP_REASS field in the ISP_MSG_CNF_GRP message may optionally be enabled if the syntax of segmented application context parameters must be validated and if timer Treass (to wait for the final APP segment) should be initiated.

Timer TIM_REASS in the ISP_MSG_CNF_TIM (0x7702) message is used by the module when it receives segments of Application transport parameters.

Compatibility handling: The BICX1GOP_COMPAT field in the ISP_MSG_CNF_GRP message may optionally be enabled to verify the

compatibility of BICC IEs.

Parameters

When this variant is selected, the following BICC specific parameters may be used:

Parameter Name Parameter Value Length Reference

Hex Dec Min Max

IN service compatibility 0xa2 162 1 255 Q.1902.3 section 6.53


179

Appendix B: Messages Currently Supported by the

ISUP Module

B.1 ITU-T Messages

Message Type

Q.763 (1992 and later)

Message expected by ISUP module

Message generated by ISUP module

Address complete YES YES

Answer YES YES

Application transport YES YES

Blocking YES YES

Blocking acknowledgement YES YES

Call modification completed NO (Discarded if received) NO

Call modification request NO (Discarded if received) NO

Call modification reject NO (Discarded if received) NO

Call progress YES YES

Collection Charge YES YES

Circuit group blocking YES YES

Circuit group blocking acknowledgement YES YES

Circuit group query YES YES

Circuit group query response YES YES

Circuit group reset YES YES

Circuit group reset acknowledgement YES YES

Circuit group unblocking YES YES

Circuit group unblocking acknowledgement YES YES

Charge information YES YES

Confusion YES YES (optionally)

Connect YES YES

Continuity YES YES

Continuity check request YES YES

Delayed release NO (Discarded if received) NO

Facility YES YES

Facility accepted YES YES

Facility reject YES YES

Facility request YES YES

Forward transfer YES YES

Identification request YES YES

Appendix B: Messages Currently Supported by the ISUP Module

180

Message Type

Q.763 (1992 and later)

Message expected by ISUP module


Identification response YES YES

Information YES YES

Information request YES YES

Initial address YES YES

Loop back acknowledgement YES YES

Loop prevention YES YES

Network resource management YES YES

Overload YES YES

Pass-along YES YES

Pre-release information YES YES

Release YES YES

Release complete YES YES

Reset circuit YES YES

Resume YES YES

Segmentation YES YES

Subsequent address YES YES

Subsequent Directory Number YES YES

Suspend YES YES

Unblocking YES YES

Unblocking acknowledgement YES YES

Unequipped CIC YES (optionally) YES (optionally)

User Part available YES (optionally) YES

User Part test YES YES (optionally)

User-to-user information YES YES

B.2 ITU-T Parameters

Parameter name Code (binary) Code (decimal) Parameter supported by ISUP module

Access delivery information 00101110 46 YES

Access transport 00000011 3 YES

Application transport 01111000 120 YES

Automatic congestion level 00100111 39 YES

Automatic rerouting 10010110 150 YES

Backward call indicators 00010001 17 YES

Backward GVNS 01001101 77 YES


181


Call diversion information 00110110 54 YES

Call diversion treatment indicators 01101110 110 YES

Call history information 00101101 45 YES

Call offering treatment indicators 01110000 112 YES

Call reference 00000001 1 YES

Call transfer number 01000101 69 YES

Call transfer reference 01000011 67 YES

Called directory number 0x7d 125 YES

Called IN number 01101111 111 YES

Called party number 00000100 4 YES

Calling geodetic location 10000001 129 YES

Calling party number 00001010 10 YES

Calling party geodetic velocity information 10000011 131 YES

Calling party‟s category 00001001 9 YES

Carrier selection information 11101110 238 YES

Cause indicators 00010010 18 YES

CCNR possible indicator 01111010 122 YES

CCSS 01001011 75 YES

Charged party identification 01110001 113 YES

Circuit assignment map 00100101 37 YES

Circuit group supervision message type 00010101 21 YES

Circuit state indicator 00100110 38 YES

Closed user group interlock code 00011010 26 YES

Coding decoding processing 10100101 165 YES

Collect call request 01111001 121 YES

Conference treatment indicators 01110010 114 YES

Connected number 00100001 33 YES

Connection request 00001101 13 YES

Continuity indicators 00010000 16 YES

Correlation ID 01100101 101 YES

Display information 01110011 115 YES

Echo control information 00110111 55 YES

End of optional parameters 00000000 0 YES

Event information 00100100 36 YES

Facility indicator 00011000 24 YES

Forward call indicators 00000111 7 YES


182


Forward GVNS 01001100 76 YES

Freephone indicators 01000001 65 YES

Generic digits 11000001 193 YES

Generic notification indicator 00101100 44 YES

Generic number 11000000 192 YES

Generic reference 01000010 66 YES

Global call reference 10100100 164 YES

Hop counter 00111101 61 YES

HTR information 10000010 130 YES

IN service compatibility 10100010 162 YES

Identification request indicators 00110110 54 YES

Identification indicator 00110111 55 YES

Information indicators 00001111 15 YES

Information request indicators 00001110 14 YES

Inter nodal traffic group identifier 10100011 163 YES

Location number 00111111 63 YES

Loop prevention indicators 01000100 68 YES

Message compatibility information 00111000 56 YES

MCID request indicators 00111011 59 YES

MCID response indicators 00111100 60 YES

MLPP precedence 00111010 58 YES

Nature of connection indicators 00000110 6 YES

Network management controls 01011011 91 YES

Network routing number 10000100 84 YES

Network specific facility 00101111 47 YES

Number portability forward information 10001101 141 YES

Optional backward call indicators 00101001 41 YES

Optional forward call indicators 00001000 8 YES

Original Called IN number 01111111 127 YES

Original called number 00101000 40 YES

Origination ISC point code 00101011 43 YES

Parameter compatibility information 00111001 57 YES

Pivot capability 01111011 123 YES

Pivot counter 10000111 135 YES

Pivot routing backward information 10001001 137 YES

Pivot routing forward information 10001000 136 YES


183


Pivot routing indicators 01111100 124 YES

Pivot status 10000110 134 YES

Propagation delay counter 00110001 49 YES

Query on Release Capability 10000101 133 YES

Range and status 00010110 22 YES

Redirect backward information 10001100 140 YES

Redirect capability 1001110 78 YES

Redirect counter 1110111 119 YES

Redirect forward information 10001011 139 YES

Redirect status 10001010 138 YES

Redirecting number 00001011 11 YES

Redirection information 00010011 19 YES

Redirection number 00001100 12 YES

Redirection number restriction indicator 01000000 64 YES

Remote operations 00110010 50 YES

SCF ID 01100110 102 YES

Service activation 00110011 51 YES

Signalling point code 00011110 30 YES

Subsequent number 00000101 5 YES

Suspend/Resume indicators 00100010 34 YES

Transit network selection 00100011 35 YES

Transmission medium requirement 00000010 2 YES

Transmission medium requirement prime 00111110 62 YES

Transmission medium used 00110101 53 YES

UID action indicators 0111 0100 116 YES

UID capability indicators 0111 0101 117 YES

User service information 00011101 29 YES

User service information prime 00110000 48 YES

User teleservice information 00110100 52 YES

User-to-user indicators 00101010 42 YES

User-to-user information 00100000 32 YES


184

B.3 ANSI T1.113 Messages

Message Type ANSI T1.113.3 Message expected by ISUP module


Address complete YES YES

Answer YES YES

Blocking YES YES

Blocking acknowledgement YES YES

Call progress YES YES

Circuit group blocking YES YES

Circuit group blocking acknowledgement YES YES

Circuit group query YES YES

Circuit group query response YES YES

Circuit group reset YES YES

Circuit group reset acknowledgement YES YES

Circuit group unblocking YES YES

Circuit group unblocking acknowledgement YES YES

Circuit reservation NO (Discarded if received) NO

Circuit reservation acknowledgement NO (Discarded if received) NO

Circuit validation response NO NO

Circuit validation test NO NO

Confusion YES YES (optionally)

Continuity YES YES

Continuity check request YES YES

Exit YES YES

Facility accepted YES YES

Facility reject YES YES

Facility request YES YES

Forward transfer YES YES

Information YES YES

Information request YES YES

Initial address YES YES

Loop back acknowledgement YES YES

Pass-along YES YES

Release YES YES

Release complete YES YES

Reset circuit YES YES

Resume YES YES

Suspend YES YES


185

Message Type ANSI T1.113.3 Message expected by ISUP module


Unblocking YES YES

Unequipped CIC YES (optionally) YES (optionally)

Unblocking acknowledgement YES YES

B.4 ANSI T1.113 Parameters


Access transport 00000011 3 YES

Application transport 01111000 120 YES

Automatic congestion level 00100111 39 YES

Backward call indicators 00010001 17 YES

Business group 11000110 198 YES

Call reference 00000001 1 YES

Called party number 00000100 4 YES

Calling party number 00001010 10 YES

Calling party‟s category 00001001 9 YES

Carrier identification 11000101 197 YES

Carrier selection information 11101110 238 YES

Cause indicators 00010010 18 YES

Charge number 11101011 235 YES

Circuit assignment map 00100101 37 YES

Circuit group characteristic indicator 11100101 229 YES

Circuit group supervision message type 00010101 21 YES

Circuit identification name 11101000 232 YES

Circuit state indicator 00100110 38 YES

Circuit validation response indicator 11100110 230 YES

Closed user group interlock code 00011010 26 YES

Common language location identification 11101001 233 YES

Continuity indicators 00010000 16 YES

Connection request 00001101 13 NO

Egress 11000011 195 YES

End of optional parameters 00000000 0 YES

Event information 00100100 36 YES

Facility indicator 00011000 24 YES

Forward call indicators 00000111 7 YES

Generic digits 11000001 193 YES


186


Generic name 11000111 199 YES

Generic number (address) 11000000 192 YES

Hop counter 00111101 61 YES

Information indicators 00001111 15 YES

Information request indicators 00001110 14 YES

Jurisdiction 11000100 196 YES

MLPP precedence 00111010 58 YES

Nature of connection indicators 00000110 6 YES

Network transport 11101111 239 YES

Notification indicator 11100001 225 YES

Operator services information 11000010 194 YES

Optional backward call indicators 00101001 41 YES

Originating line information 11101010 234 YES

Original called number 00101000 40 YES

Outgoing trunk group number 11100111 231 YES

Range and status 00010110 22 YES

Redirecting number 00001011 11 YES

Redirection information 00010011 19 YES


187

Appendix C: Message Type Table

The following table lists, by message type, all the messages described in this manual in ascending order.

The message type for the confirmation message is set as described in the U10SSS, Software Environment Programmer's Manual, in the paragraph describing the rsp_req field. Note that only request messages may have an associated confirmation message. If there is an associated confirmation message, the confirmation message type is indicated in the confirmation

message column.

Message Type

Mnemonic Description See page Confirmation Message

0x0003 MGT_MSG_TRACE_EV Trace Event Indication 163 -

0x0008 MGT_MSG_EVENT_IND Management Event Indication 162 -

0x0708 ISP_MSG_CGSC_IND Circuit Group Supervision Control Indication

111 -

0x0709 ISP_MSG_CGSC_CONF Circuit Group Supervision Control Confirmation

110 -

0x070a ISP_MSG_MAINT_IND Maintenance Event Indication 155 -

0x070b ISP_MSG_ERROR_IND Software Event Indication 159 -

0x070c ISP_MSG_CGSS_IND Circuit Group Supervision Status Indication

112 -

0x070d ISP_MSG_OVLD_REQ Local Overload Request 113 -

0x070e ISP_MSG_STATUS Remote Point Code Status Indication

114 -

0x0f16 MGT_MSG_SEL_TRACE Selective Trace Event Indication 164 -

0x570f ISP_MSG_S_MAINT_MASK Send Maintenance Event Mask Request

149 0x170f

0x5710 ISP_MSG_S_ERROR_MASK Send Software Event Mask Request 150 0x1710

0x5711 ISP_MSG_S_TRACE_MASK Trace Mask Configuration Request 151 0x1711

0x5712 ISP_MSG_SET_CUSTVAR Variant Initialisation 137 0x1712

0x5713 ISP_MSG_CUSTPARAM Custom Parameter Configuration 138 0x1713

0x5714 ISP_MSG_S_SELTRACE_MASK Send Selective Trace Event Mask Request

154 0x1714

0x6111 GEN_MSG_MOD_IDENT Read Revision Request 142 0x2111

0x6704 ISP_MSG_R_RAM Read RAM Request 141 0x2704

0x6705 ISP_MSG_R_GRP Read Circuit Group Request 141 0x2705

0x6706 ISP_MSG_R_CCT Read Circuit Request 142 0x2706

0x6710 ISP_MSG_R_STATUS Read Circuit Group Status Request 143 0x2710

0x6715 ISP_MSG_R_GRP_DATA Read Circuit Group Data Request 148 0x2715

0x6717 ISP_MSG_R_GRPID Read Circuit Group Identity Request 148 0x2717

0x7700 ISP_MSG_CONFIG Configure Request 116 0x3700

0x7701 ISP_MSG_CNF_GRP Configure Circuit Group Request 121 0x3701

Appendix C: Message Type Table

188

Message Type

Mnemonic Description See page Confirmation Message

0x7702 ISP_MSG_CNF_TIM Configure Timers Request 131 0x3702

0x7703 ISP_MSG_CGSC_REQ Circuit Group Supervision Control Request

109 0x3703

0x770d ISP_MSG_OLVD_REQ Local Overload Request 113 0x370d

0x770f ISP_MSG_END_GRP End Circuit Group Request 136 0x370f

0x7715 ISP_MSG_R_CNG_GRP Change Circuit Group Configuration Request

139 0x3715

0x7718 CAL_MSG_HEARTBEAT Heartbeat Request/Indication 166 0x3718

0x8701 CAL_MSG_RX_IND Receive Indication to user - -

0xc700 ISP_MSG_TX_REQ Transmit request from user - -


189

Appendix D: ISUP Configuration Option Settings

This section tabulates suggested circuit group option settings for various different variants of ISUP. Please note that module options are not listed as they are dependent upon the user application rather than the protocol variant (refer to Section 8.1: Configure Request on page 116 for further details).

For the suggested circuit group options in this section, the variant in the Configure Circuit Group Request message should be set as follows:

Variant (as indicated in the option tables in this

appendix)

Value of ‘variant’ field in the Configure Circuit Group Request message

9

Value Mnemonic

ANSI 2 ISPGVAR_ANSI

8 ISPGVAR_ANSI95

ETSI (V2 and V3) 1 ISPGVAR_ITU92

ITU Blue Book 0 ISPGVAR_BB

ITU (03/93 and later) 1 ISPGVAR_ITU92

Q.767 0 ISPGVAR_BB

The option value fields for the following options tables are described as follows:

Option value Description

0 Option should not be set.

1 Option must be set.

>1 Option must be set (recommended value as indicated).

Options

Bit Option Variant

ANSI ETSI ITU Blue Book ITU Q.767

2 ISPGOP_ACM_CTRL 1 1 1 1 1

3 ISPGOP_ANM_CTRL 1 1 1 1 1

4 ISPGOP_SUS_CTRL 1 1 1 1 1

5 ISPGOP_RST_REQD 0 0 0 0 0

6 ISPGOP_REQ_CLI 0* 0* 0* 0* 0*

7 ISPGOP_EN_ST 0 0* 0* 0* 0*

8 ISPGOP_USR_SVC1 0 0* 0* 0* 0*

9 ISPGOP_USR_SVC2 0 0* 0* 0* 0*

10 ISPGOP_USR_SVC3 0 0* 0* 0* 0*

11 ISPGOP_COM 0 0 0 0 0

12 ISPGOP_T35 0 0* 0 0* 0*

9 See Configure Circuit Group Request on page 24.

Appendix D: ISUP Configuration Option Settings

190

Bit Option Variant


13 Reserved 0 0 0 0 0

14 ISPGOP_TCCR_CTRL 1 0 0 0 0

15 Reserved 0 0 0 0 0

For bits 0 -1 in the „options‟ field refer to Section 8.2: Configure Circuit Group Request on page 121.

Extended Options

Bit Option Variant


0 ISPXGOP_BLK_767 1 1 0 1 1

1 ISPXGOP_UBK_MH 1 0 0 0 0

2 ISPXGOP_RPT_CGSM 1 0 0 0 0

3 ISPXGOP_UMSG_CFN 1 1 1 1 0

4 ISPXGOP_ANSI (see note 1)

0 0 0 0 0

5 ISPXGOP_PRI_BA 1 0 0 0 0

6 ISPXGOP_T34 0 1* 0 1 0

7 ISPXGOP_TRAN_PAM 0* 0* 0* 0* 0

8-10 ISPXGOP_COMPAT 0 2* 0 2* 0

11 ISPXGOP_ITU92 (see note 1)

0 0 0 0 0

12 ISPXGOP_CAUSE_767 0 0 0 0 1

13 ISPXGOP_DEL_ST 1* 0 0 0 0

14 ISPXGOP_24PC 0 0 0 0 0

15 ISPXGOP_UCIC 1 0 1 1 0


191

More Extended Options

Bit Option Variant


0 ISPX1GOP_ADD_ST 1* 0 0 0 0

1 ISPX1GOP_16PC 0 0 0 0 0

2 ISPX1GOP_T33EXP_NOREL 0 0 0 0 0

3 ISPX1GOP_USR_SVC_PRV 0 0 0 0 0

4 ISPX1GOP_T39 0 1 0 1 0

5 ISPX1GOP_T38 0 0 0 1 0

6 ISPX1GOP_SEND_UPT 0 1* 0 1* 0

7 ISPX1GOP_TX_CRG 0 1 1 1 0

8 ISPX1GOP_CCL 0 0 0 0 0

9 ISPX1GOP_AUTO_BLK 0 0 0 0 0

10 Reserved 0 0 0 0 0

11 ISPX1GOP_SET_LOC 0* 0* 0* 0* 0*

12-15 ISPX1GOP_LOC 0* 0* 0* 0* 0*

16 ISPX1GOP_TREASS 0 0 0 0 0

17-18 BICX1GOP_COMPAT 0 0 0 0 0

19 ISPX1GOP_NO_EOOP 0 1 1 1 0

20 ISP1GOP_NOCUG 1 1 1 1 0

21 ISPX1GOP_IC_CPG 0 1 0 1 0

22 ISPX1GOP_SLS8 1 0 0 0 0

Note: * Indicates that the option value may be set differently according to the needs of the particular application and still comply with the indicated specification.

Although ISPXGOP_ANSI and ISPXGOP_ITU92 are permitted options, for new

applications it is recommended that the user should use the variant field in the Configure Circuit Group Request10 message for setting the variant instead. These options have been retained for backwards compatibility.

10 See Section 8.2 on page 24.

Appendix E: ISUP Repeat Parameters

192

Appendix E: ISUP Repeat Parameters

This section describes all supported parameters that can be repeated and indicates the maximum number of repetitions permitted per message.

Value Name of parameter Maximum number of repetitions within one message

Hex Dec

0x14 20 Custom parameter 24

0xc1 193 Generic digits 5

0x2c 44 Generic notification 5

0x78 120 Application transport 20

0xc0 192 Generic number 5

0x42 66 Generic reference 5

0xe1 255 Notification indicator 5

0xf9 249 Unrecognised parameter 20


193

Appendix F: Timer Services

The notion of time in the ISUP module is based on a periodic timer tick received from the timer module every 100ms. This „tick‟ is used to run all ISUP protocol timers. This appendix details the messages format which are used by the ISUP module to control timer services.

F.1 Keep Time Message sent to request the timer module to issue a periodic timer tick (TM_EXP) message to the ISUP module.

Message Header

structure MSG

type KEEP_TIME (0x7006)

id 0

src Sending module‟s ID

dst Timer module ID

rsp_req 0

hclass 0x00

status 0x00

err_info 0x00

len 6

Parameter Area

parameters offset 0, size 2: Reserved Should be set to zero if issued by the user and discarded when received by the timer module.

offset 4, size 2: resolution

Parameters

resolution

The number of operating system ticks between timer expiry messages being issued to the ISUP module. This parameter is set from the timer_res parameter in the ISUP module configuration message (Section 8.1: Configure Request on page 116).

Appendix F: Timer Services

194

F.1 Timer Expiry Periodic timer tick message issued by the timer module.

Message Header

structure MSG

type TM_EXP (0xc002)

id index of timer in table

src Timer module ID

dst Destination module ID

rsp_req 0

hclass 0x00

status 0x00

err_info 0x00

len 4

Parameter Area

parameters offset 0, size 4: Reserved Must be set to zero.


195

Index

A

Abbreviations in this manual, 11 Alerting Indication, 53 Alerting Request, 26 ANSI T1.113 Messages, 185 ANSI T1.113 Parameters, 186 Application interface, 21 Application message

Header format, 21 user data format, 23

Application messages from ISUP, 51 Application messages to ISUP, 24 Application Transport Indication, 56 Application Transport Request, 28 Automatic Circuit Group Blocking, 106

B

BICC, 178 BICC Application Transport, 108

C

Call Clearing Procedure, 87 Call Collision Procedure, 88 Called Party Number, 83 Calling Party Number, 83 Cause Indicators, 84 Change Circuit Group Configuration Request, 140 China ISUP, 176 Circuit group data structure, 18 Circuit Group Supervision Control Confirmation,

111 Circuit Group Supervision Control Indication, 112 Circuit Group Supervision Control Request, 110 Circuit Group Supervision Status Indication, 113 Circuit Seized Indication, 57 Circuit Seized Request, 29 Collection Charging Indication, 57 Collection Charging Request, 30

Configure Circuit Group Request, 122 Configure Request, 117 Configure Timers Request, 132 Confusion Indication, 57 Confusion Request, 30 Continuity Indication, 58 Continuity Request, 30 Continuity Testing, 92 Custom Parameter, 85 Custom Parameter Configuration, 139

E

End Circuit Group Request, 137 End-to-End Message Indication, 58 End-to-End Message Request, 31

Exit Indication, 58 Exit Request, 31

F

Facility Confirmation, 60 Facility Indication, 59 Facility Request, 31 Facility Response, 33 Finnish ISUP, 178 Forward Transfer Indication, 61 Forward Transfer Request, 34 French ISUP, 175

G

Generic Charge Indication, 56 Generic Charge Request, 29 German ISUP, 169 Global Ram data structure, 18

H

Header format, application message, 21 Heartbeat Request/Indication, 167 Hop Counter Procedure, 91

I

Identification Confirmation, 62 Identification Indication, 61 Identification Request, 34 Identification Response, 34 Information Indication, 62 Information Request, 35 Interface

application, 21 MTP, 20

Interface to system services, 19 Internal data structures, 18

circuit group data structure, 18 global Ram data structure, 18 pre-circuit data structure, 18

ISUP Configuration Option Settings, 190 ISUP module

about, 15 configuration, 15 customizing, 16 features, 13

ISUP National Variants, 169 ISUP Programmer‟s Manual

abbreviations in, 11 about, 11 related documentation, 12

ISUP Repeat Parameters, 193 Italian ISUP, 174 ITU-T Messages, 180 ITU-T Parameters, 181

Index

196

J

Japan (TTC) ISUP, 171

K

Keep Time, 194

L

Local Overload Request, 114 Loop Back Acknowledgement Indication, 63 Loop Back Acknowledgement Request, 36 Loop Prevention Indication, 64 Loop Prevention Request, 37

M

Maintenance Event Indication, 156 Malicious Call Identification (MCID)

Supplementary Service, 105 Management Event Indication, 163

Management Interface, 109 Message Data, 85 Message Segmentation, 106 Message Type Table, 188 Messages Currently Supported by the ISUP

Module, 180 MTP

interface to, 20

N

Network Resource Management Indication, 64 Network Resource Management Request, 37 Non-Primitive Interface, 117 Nortel RLT, 172 Nortel RLT (ANSI), 172 Nortel RLT (ITU), 173 Number of Metering Pulses, 86

O

Overload Indication, 65 Overload Request, 38

P

Parameter Definitions, 77 Parameter extension mechanism, 24 Pre-circuit data structure, 18 Pre-Release Information Indication, 65 Pre-Release Information Request, 38 Proceeding Indication, 66 Proceeding request, 39 Progress Indication, 67 Progress Request, 40

R

Read Circuit Group Data Request, 149 Read Circuit Group Identity Request, 149 Read Circuit Group Request, 142 Read Circuit Group Status Request, 144 Read Circuit Request, 143 Read RAM Request, 142 Read Revision Request, 143 Receive indication, 22 Related documentation, 12 Release Confirmation, 68 Release Indication, 68 Release Request, 42 Release Response, 41 Remote Point Code Status Indication, 115 Request Information Indication, 69 Request Information Request, 43 Resume Indication, 70 Resume Request, 43

S

Segmentation Indication, 70 Segmentation Request, 44 Selective Trace Event Indication, 165 Send Maintenance Event Mask Request, 150 Send Selective Trace Event Mask Request, 155 Send Software Event Mask Request, 151 Setup Confirmation, 71 Setup Indication, 73 Setup Request, 44 Setup Response, 47 Software Event Indication, 161 Subsequent Directory Number Indication, 75 Subsequent Directory Number Request, 49 Suspend Indication, 76 Suspend Request, 50 System functions, 19

T

Tariff Type, 86 Timer default values, 135 Timer Expiry, 195 Timer operation, 19 Timer Services, 194 Trace Event Indication, 164 Trace Mask Configuration Request, 152 Transmit request, 21

U

UK ISUP, 170 Unrecognised Message Indication, 76 Unrecognised Message Request, 50 Unrecognised Parameter, 87 Use of Call Control Primitives, 87 User data format, application message, 23 User Information Indication, 76 User Information Request, 51


197

V Variant Initialisation, 138

Documents

DSI Protocol Stacks - Dialogic/media/manuals/ss7/cd/GenericInfo/...Dialogic® DSI Protocol Stacks ISUP Programmer's Manual Issue 17 3 Contents Revision History ... A.4 Nortel RLT