Intel NetStructure™ SS7 Protocols ISUP …® NetStructure™ SS7 Protocols ISUP Programmer's...

Intel® NetStructure™ SS7 Protocols ISUP Programmer's Manual

Document Reference: U04SSS

ISUP Programmer’s Manual Issue 12

Disclaimer

The product may contain design defects or errors known as errata, which may cause the product to deviate from published specifications.�

Information in this document is provided in connection with Intel® products. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document. Except as provided in Intel’s Terms and Conditions of Sale for such products, Intel assumes no liability whatsoever, and Intel disclaims any express or implied warranty, relating to sale and/or use of Intel products including liability or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent, copyright or other intellectual property right. Intel products are not designed, intended or authorized for use in any medical, life saving, or life sustaining applications or for any other application in which the failure of the Intel product could create a situation where personal injury or death may occur. Intel may make changes to specifications and product descriptions at any time, without notice.

Intel and Intel NetStructure are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.�

* Other names and brands may be claimed as the property of others.

Copyright © 1993-2003 Intel Corporation. All rights reserved. No part of this document may be copied, or reproduced in any form, or by any means without prior written consent of Intel.


REVISION HISTORY

ISSUE DATE BY CHANGES

1 27-Sep-93 SRG

2 17-Feb-94 SRG

3 24-Aug-95 SFP 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

4 04-Apr-96 SRG 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.

5 17-Apr-96 SRG 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.

6 30-May-96 SFP 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.

7 10-Sep-96 JER 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.


ISSUE DATE BY CHANGES

8 06-May-97 JER 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.

9 02-Jul-98 JER 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.

10 02-Dec-99 JB 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.

11 16-Aug-01 JB, ML 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.

12 24-Jul-03 ML 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.


CONTENTS 1. Introduction.................................................................................................................................. 8

2. Abbreviations............................................................................................................................... 9

3. Related Documentation ............................................................................................................. 10

4. Feature Overview ...................................................................................................................... 11

5. General Description................................................................................................................... 12 5.1 Module Overview............................................................................................................. 12 5.2 Module Configuration ...................................................................................................... 12

5.2.1 Customising ISUP variants ................................................................................. 13 6. Internal Data Structures............................................................................................................. 14

6.1 Global Ram Data Structure ............................................................................................. 14 6.2 Circuit Group Data Structure........................................................................................... 14 6.3 Per Circuit Data Structure ............................................................................................... 14

7. Interface to System Services..................................................................................................... 15 7.1 System Functions............................................................................................................ 15 7.2 Timer Operation .............................................................................................................. 15

8. Interface to MTP........................................................................................................................ 16

9. Interface to Application .............................................................................................................. 17 9.1 Application Message - Header Format............................................................................ 17

9.1.1 Transmit Request ............................................................................................... 17 9.1.2 Receive indication............................................................................................... 18

9.2 Application Message - User Data Format ....................................................................... 19 9.3 Parameter extension mechanism ................................................................................... 19 9.4 Application Messages to ISUP........................................................................................ 20

9.4.1 Alerting request................................................................................................... 21 9.4.2 Application transport request .............................................................................. 24 9.4.3 ‘Generic’ charge request..................................................................................... 24 9.4.4 Circuit seized request ......................................................................................... 25 9.4.5 Collection Charging request................................................................................ 25 9.4.6 Confusion request............................................................................................... 25 9.4.7 Continuity request ............................................................................................... 26 9.4.8 End-to-end message request ............................................................................. 26 9.4.9 Exit request ......................................................................................................... 26 9.4.10 Facility request.................................................................................................. 27 9.4.11 Facility response ............................................................................................... 28 9.4.12 Forward transfer request .................................................................................. 29 9.4.13 Identification request......................................................................................... 30 9.4.14 Identification response...................................................................................... 30 9.4.15 Information request........................................................................................... 31 9.4.16 Loop back acknowledgement request .............................................................. 33 9.4.17 Loop prevention request ................................................................................... 33 9.4.18 Network resource management request .......................................................... 34 9.4.19 Overload request .............................................................................................. 34 9.4.20 Pre-release information request ....................................................................... 35 9.4.21 Proceeding request........................................................................................... 36 9.4.22 Progress request .............................................................................................. 37 9.4.23 Release response............................................................................................. 38 9.4.24 Release request................................................................................................ 39 9.4.25 Request information request............................................................................. 40 9.4.26 Resume request ............................................................................................... 40 9.4.27 Segmentation request....................................................................................... 41 9.4.28 Setup request.................................................................................................... 42 9.4.29 Setup response................................................................................................. 44 9.4.30 Suspend request............................................................................................... 46


9.4.31 Unrecognised message request ....................................................................... 46 9.4.32 User information request .................................................................................. 47

9.5 Application Messages from ISUP.................................................................................... 48 9.5.1 Alerting indication................................................................................................ 49 9.5.2 Application transport indication ........................................................................... 52 9.5.3 ‘Generic’ charge indication.................................................................................. 52 9.5.4 Circuit seized indication ...................................................................................... 53 9.5.5 Collection Charging indication ............................................................................ 53 9.5.6 Confusion indication............................................................................................ 53 9.5.7 Continuity indication............................................................................................ 54 9.5.8 End-to-end message indication .......................................................................... 54 9.5.9 Exit indication...................................................................................................... 54 9.5.10 Facility indication............................................................................................... 55 9.5.11 Facility confirmation .......................................................................................... 56 9.5.12 Forward transfer indication ............................................................................... 57 9.5.13 Identification indication...................................................................................... 58 9.5.14 Identification confirmation ................................................................................. 58 9.5.15 Information indication........................................................................................ 59 9.5.16 Loop back acknowledgement indication ........................................................... 60 9.5.17 Loop prevention indication ................................................................................ 60 9.5.18 Network resource management indication ....................................................... 61 9.5.19 Overload indication ........................................................................................... 61 9.5.20 Pre-release information indication .................................................................... 62 9.5.21 Proceeding indication........................................................................................ 63 9.5.22 Progress indication ........................................................................................... 64 9.5.23 Release confirmation ........................................................................................ 65 9.5.24 Release indication............................................................................................. 66 9.5.25 Request information indication ......................................................................... 67 9.5.26 Resume indication ............................................................................................ 67 9.5.27 Segmentation indication.................................................................................... 68 9.5.28 Setup confirmation............................................................................................ 68 9.5.29 Setup indication ................................................................................................ 71 9.5.30 Suspend indication............................................................................................ 72 9.5.31 Unrecognised message indication.................................................................... 73 9.5.32 User information indication ............................................................................... 73

9.6 Parameter Definitions...................................................................................................... 74 9.6.1 Called party number............................................................................................ 77 9.6.2 Calling party number........................................................................................... 77 9.6.3 Cause indicators ................................................................................................. 78 9.6.4 Custom parameter .............................................................................................. 79 9.6.5 Message data ..................................................................................................... 79 9.6.6 Number of metering pulses ................................................................................ 80 9.6.7 Tariff type............................................................................................................ 80 9.6.8 Unrecognised parameter .................................................................................... 81

9.7 Use of Call Control Primitives ......................................................................................... 82 9.7.1 Call Clearing procedure ...................................................................................... 82 9.7.2 Call Collision procedure ...................................................................................... 83 9.7.3 Hop counter procedure ....................................................................................... 85 9.7.4 Continuity Testing ............................................................................................... 86 9.7.5 Malicious Call Identification (MCID) Supplementary Service.............................. 97 9.7.6 Message Segmentation ...................................................................................... 97


10. Management Interface............................................................................................................... 98 10.1 Circuit Group Supervision Control Request.......................................................... 99 10.2 Circuit Group Supervision Control Confirmation................................................. 100 10.3 Circuit Group Supervision Control Indication...................................................... 101 10.4 Circuit Group Supervision Status Indication ....................................................... 102 10.5 Local Overload Request ..................................................................................... 103 10.6 Remote point code status indication................................................................... 104

11. Non-Primitive Interface ............................................................................................................ 105 11.1 Configure Request.............................................................................................. 105 11.2 Configure Circuit Group Request........................................................................ 108 11.3 Configure Timers Request.................................................................................. 115 11.4 End Circuit Group Request................................................................................. 118 11.5 Variant Initialisation............................................................................................. 119 11.6 Custom Parameter Configuration ....................................................................... 120 11.7 Read RAM Request............................................................................................ 121 11.8 Read Circuit Group Request............................................................................... 121 11.9 Read Circuit Request.......................................................................................... 122 11.10 Read Revision Request ...................................................................................... 123 11.11 Read Circuit Group Status Request ................................................................... 124 11.12 Send Maintenance Event Mask Request............................................................ 127 11.13 Send Software Event Mask Request .................................................................. 128 11.14 Trace Mask Configuration Request .................................................................... 129 11.15 Send Selective Trace Event Mask Request ....................................................... 133 11.16 Maintenance Event Indication............................................................................. 134 11.17 Software Event Indication ................................................................................... 137 11.18 Management Event Indication ............................................................................ 139 11.19 Trace Event Indication ........................................................................................ 140 11.20 Selective Trace Event Indication ........................................................................ 141

APPENDIX A ISUP National variants ................................................................................................ 142 A1. German ISUP................................................................................................................ 142 A2. UK ISUP........................................................................................................................ 143 A3. Japan (TTC) ISUP......................................................................................................... 144 A4. Nortel RLT..................................................................................................................... 145

A.4.1 Nortel RLT (ANSI) ............................................................................................ 145 A.4.2 Nortel RLT (ITU)............................................................................................... 146

A5. Italian ISUP ................................................................................................................... 147 A6. French ISUP.................................................................................................................. 149 A7. China ISUP.................................................................................................................... 150 A8. Finnish ISUP ................................................................................................................. 151

APPENDIX B Messages currently supported by the ISUP module ................................................... 152 B1. ITU-T Messages ........................................................................................................... 152 B2. ITU-T Parameters ......................................................................................................... 154 B3. ANSI T1.113 Messages ................................................................................................ 156 B4. ANSI T1.113 Parameters .............................................................................................. 157

APPENDIX C Message type table ..................................................................................................... 159

APPENDIX D ISUP Configuration option settings ............................................................................. 160

APPENDIX E ISUP Repeat parameters ............................................................................................ 162

APPENDIX F Timer Services............................................................................................................. 163 F1. Keep Time..................................................................................................................... 163 F2. Timer Expiry .................................................................................................................. 163


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 (formerly CCITT) 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 customise existing variants by adding or deleting parameters.

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 signalling messages with remote Signalling 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 lists the ITU-T ISUP and the ANSI T1.113 ISUP messages and parameters that are currently supported by the module.


2. Abbreviations ANSI American National Standards Institute

ISDN Integrated Services Digital Network

ISUP ISDN User Part

ITU International Telecommunication Union

SS7 Signalling System Number 7

MTP Message Transfer Part

OPC Originating Point Code

DPC Destination Point Code

CIC Circuit Identification Code


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 Q764, Signalling System No.7 ISDN User part signalling procedures

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

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

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

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

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

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

[12] Italian ISUP Specification: Specifica Technica N.763

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

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

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

[16] U10SSS, Software Environment Programmer’s Manual

[17] U01SIU, SIU 131/SIU231 User Manual

[18] U08SSP, SS7 Programmer’s Manual for PCCS6

[19] U03HSP, SS7 Programmer’s Manual for SPCI2S, SPCI4 & CPM8

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

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


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.

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

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


5. General Description

5.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. This feature is retained for backwards compatibility and will be removed in a future release so that the call_ref will be identical to the cid. 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.

5.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 and national variants) to be used for circuits in a group is specified by a configuration parameter in the circuit group configuration message.

A configuration utility is provided which may (or, for some products must) be used to configure the module. When using the configuration utility it is not necessary to send the messages mentioned above since the is done automatically by the utility.

Please refer to [17], [18], or [19] as applicable.


5.2.1 Customising 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 to and from the network. This mechanism may be initialised as follows:

1. Configure the ISUP module as described earlier in this section. The Configure Circuit Group Request message (with the custom variant set) 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.

Two ‘custom’ variants are specifically reserved for this procedure as shown in the following table (refer also to Section 11.2 Configure Circuit Group Request):

Value Mnemonic Meaning

0xfd ISPGVAR_CUST02 Custom variant CUST02

0xfe ISPGVAR_CUST01 Custom variant CUST01

2. Initialise a custom variant using the ISP_MSG_SET_CUSTVAR message (refer to Section 11.5 Variant Initialisation).

3. Configure the custom parameter using the ISP_MSG_CUSTPARAM message (refer to Section 11.6 Custom Parameter Configuration). This message should be sent when a proprietary parameter is to be added or removed from an ISUP message. Also, a separate Custom Prameter Configuration message is required and must be sent for each ISUP message containing the proprietary parameter.


6. Internal Data Structures 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.

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

6.2 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. Signalling Point Codes, Circuit Identification and Configuration Options). The information in the circuit group data structure applies to all circuits in the circuit group.

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


7. Interface to System Services

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

7.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 usually achieved using either the Enhanced Driver Module or the Timer module in which case the following messages are used by the ISUP module:

The following action request message is issued by the ISUP module: KEEP_TIME Issued by ISUP to initialise timer services.

The ISUP module expects the following notification message on timer expiry: TM_EXP Issued by the timer module to notify on time-out.

The format of these messages are described in APPENDIX F Timer Services.

The user should note that whilst the timer functionality is usually provided by the given Intel® NetStructure™ SS7 Protocols, the timer functionality required by the ISUP module is very basic (just a single message being issued on a periodic basis). In most cases, it is a trivial exercise to implement this functionality using the user’s own choice of operating environment if required.


8. 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 Signalling point congested or Remote user

unavailable indication from MTP The message format used to convey these primitives is defined in the Programmer’s Manual for PCCS6.

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 Intel® NetStructure™ 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.


9. Interface to Application 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 Motorola ADS302 Software 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 7.

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.

9.1 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:

9.1.1 Transmit Request This primitive is used by the application to send a message to the ISUP module.

PRIMITIVE REQUEST TO ISUP: 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)

call_ref is used to identify the circuit or call to which the message refers. Currently 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.

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.


9.1.2 Receive indication This primitive is used by the ISUP module to send a message to the application module.

PRIMITIVE INDICATION FROM ISUP 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 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. In the future call_ref will be made identical to the Circuit Identifier 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. It is recommended that existing applications be modified to ignore the setting of the most significant bit.


9.2 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 sections 9.4 - 9.5. All applicable parameters for each message are listed in the following sub-sections (refer also to APPENDIX A) and a list of all supported parameters are provided in Section 9.6 Parameter Definitions.

9.3 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 parameters 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 255) is contained in the third byte which is subsequently followed by the length of the parameter and its data as shown below:

0x80 Length + 2

Parameter name - 255

Length Data

1 byte 1 byte 1 byte 1 byte ‘Length’ bytes (1 to 253)


9.4 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:

Value Primitive Message type Dec Hex

Use

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 50 0x32 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.

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

FRJ 33 0x21 Previously requested with a facility request. Forward transfer request FOT 8 0x08 Send forward transfer to the network.

SAM 2 0x02 Subsequent address digits for overlap signalling. Information request 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.



Use

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.

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

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

Continued


Alerting request (First backward message issued) (continued):

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


9.4.1.2 Issued following ACM

Message type: CPG Call Progress Message Mandatory Parameters: None Optional Parameters: Access transport Backward call indicators Cause indicators Call reference Event information Defaults to 0x01 if not supplied i.e. ALERTING Optional backward call indicators Redirection number Remote operations Service activation Transmission medium used User to user indicators May be used to accept user to user information service 1, 2 or 3 User to user information Discarded if user to user service 1 has not been accepted The following optional parameters are supported in ITU-T mode only: Access delivery information Application transport Backward GVNS Call diversion information Call history information Call transfer number Conference treatment indicators Connected number Echo control information Generic notification indicator This parameter may be repeated (see Appendix E) Generic number Network specific facility Parameter compatibility information Redirection number restriction indicator UID action indicators The following optional parameters are supported in ANSI mode only: Business group Generic number (address) Generic digits Information indicators Network transport Notification indicator This parameter may be repeated (see Appendix E)


9.4.2 Application transport request

NOTE: This message is only applicable to ITU operation.

This primitive can be issued in all call states up until release. It is used by the application to send an application transport message which is passed on in same direction without changing state.

Message type: APM Application Transport Message Mandatory Parameters: None Optional Parameters: Message compatibility information Parameter compatibility information Application transport parameter This parameter may be repeated (see Appendix E) End of optional parameter

9.4.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 providing that the circuit group ISPX1GOP_TX_CRG option is set.

Message type: CRG Charge Message Mandatory Parameters: Message data Optional Parameters: None


9.4.4 Circuit seized request This primitive is used by the application to indicate that the circuit has been seized for an outgoing call (but no address information has yet been sent) and may be issued to initiate a continuity test call. When this primitive is received by the ISUP module, a CCR message will be sent to the network.

Message type: SZE Circuit Seized Message Mandatory Parameters: Nature of connection indicators Optional Parameters: None

9.4.5 Collection Charging request

This primitive is used by the application after alerting to provide the number of charging units to be billed to the calling subscriber.

Message type: MPM Collection Charging Message Mandatory Parameters: Number of metering pulses

Message number Optional Parameters: None

9.4.6 Confusion request

This primitive is issued by the application to cause a confusion message to be sent to the network.

Message type: CFN Confusion Message Mandatory Parameters: None Optional Parameters: Cause Indicators


9.4.7 Continuity request This primitive is used by the application to indicate whether a continuity test has succeeded.

Message type: COT Continuity Message Mandatory Parameters: Continuity indicators Optional Parameters: None

9.4.8 End-to-end message request

This primitive is used by the application for end-to-end signalling.

Message type: PAM Pass Along Message Mandatory Parameters: Message data Optional Parameters: None

9.4.9 Exit request

NOTE: This message is only applicable to ANSI operation

An Exit Message may be sent in the backward direction from a gateway exchange before Address Complete to indicate that call setup information has successfully been passed to an adjacent network. This message may be issued by the application for an incoming call in the waiting ACM state and will only be accepted if the ISPGOP_ANSI circuit group option is selected.

Message type: CPG Call Progress Message Mandatory Parameters: Event information Must be coded as value 0x7d (defined as ‘spare’ by ANSI T1.113.3), to indicate Exit. Optional Parameters: Outgoing trunk group number


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

9.4.10.1 Facility request

Message type: FAR Facility Request Message Mandatory Parameters: Facility indicator Optional Parameters: Call reference The following optional parameters are supported in ITU-T mode only: Connection request Parameter compatibility information User to user indicators The following optional parameters are supported in ANSI mode only (and are conveyed transparently by the ISUP module): Business group Called party number Calling party number Charge number Generic number (address) Generic digits Network transport


9.4.10.2 Action request

Message type: FAC Facility Message Mandatory Parameters: None Optional Parameters: Remote operations Service activation The following optional parameters are supported in ITU-T mode only: Access transport Call transfer number Generic notification Message compatibility information Parameter compatibility information

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

9.4.11.1 Accepted

Message type: FAA Facility Accepted Message Mandatory Parameters: Facility indicator Optional Parameters: Call reference User to user indicators The following optional parameters are supported in ITU-T mode only: Connection request Parameter compatibility information


9.4.11.2 Rejected

Message type: FRJ Facility Rejected Message Mandatory Parameters: Facility indicator Cause indicators Optional Parameters: Call reference The following optional parameters are supported in ITU-T mode only: User to user indicators The following optional parameters are supported in ANSI mode only: Called party number Calling party number

9.4.12 Forward transfer request This message is used by the application to send a Forward Transfer message to the network.

Message type: FOT Forward Transfer Message Mandatory Parameters: None Optional Parameters: Call reference The following optional parameters are supported in ANSI mode: Cause indicator


9.4.13 Identification request

NOTE: This message is only applicable to ITU-T operation

This primitive is used by the application to request action regarding the malicious call identification supplementary service. This message is sent in the backward direction.

Message type: IDR Identification Request Message Mandatory Parameters:

None Optional Parameters: MCID request indicator Message compatibility information Parameter compatibility information

9.4.14 Identification response


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

Message type: IRS Identification Response Message Mandatory Parameters: None

Optional Parameters: MCID response indicators Message compatibility information Parameter compatibility information Calling party number Access transport Generic number This parameter may be repeated (see Appendix E) Charged party identification


9.4.15 Information request This primitive is used by the application to submit additional call information to the network and may take two forms.

9.4.15.1 Subsequent address digits


This message may be used to convey subsequent outgoing call called party number address digits to the network when overlap signalling is employed. It is not used for ANSI operation.

Message type: SAM Subsequent Address Message Mandatory Parameters: Subsequent number Optional Parameters: None


9.4.15.2 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 Mandatory Parameters: Information indicators Optional Parameters: Calling party category Calling party number Call reference Access transport The following optional parameters are supported in ITU-T mode: Connection request Network specific facility Parameter compatibility information The following optional parameters are supported in ANSI mode only: Business group Charge number Originating line information Redirecting number Redirection information User to user information


9.4.16 Loop back acknowledgement request This primitive is used by the application to indicate that a continuity check loop has been applied to the circuit.

When this primitive is received by the ISUP module, an LPA message will be sent to the network.

Message type: LPA Loop Back Acknowledgement Message Mandatory Parameters: None Optional Parameters: None

9.4.17 Loop prevention request


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

Message type: LOP Loop Prevention Message Mandatory Parameters: None Optional Parameters: Message compatibility information Parameter compatibility information Call transfer reference Loop prevention indicators


9.4.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 Mandatory Parameters: None Optional Parameters: Echo control information Message compatibility information Parameter compatibility information Transmission medium requirement

9.4.19 Overload request


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

Message type: OLM Overload Message Mandatory Parameters: None Optional Parameters: None


9.4.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 Mandatory Parameters: None Optional Parameters: Optional forward call indicators Optional backward call indicators Message compatibility information Parameter compatibility information Application transport parameter This parameter may be repeated (see Appendix E) End of optional parameter


9.4.21 Proceeding request This primitive is used by the application to indicate that for an incoming call sufficient address digits have been received to connect the call. It must only be used as the first backward message issued by the application.

Message type: ACM Address Complete Message Mandatory Parameters: Backward call indicators Optional Parameters: Access transport Call reference Cause indicators Optional backward call indicators Remote operations Service activation Transmission medium used User to user indicators May be used to accept user to user information service 1, 2 or 3 (previously requested in a set-up indication). User to user information Discarded if user to user service 1 has not been accepted The following parameters are supported in ITU-T mode only Access delivery information Application transport Call diversion information Conference treatment indicators Connected number Echo control information Generic notification indicator This parameter may be repeated (see Appendix E) Network specific facility Parameter compatibility information Redirection number Redirection number restriction indicator UID action indicator The following optional parameters are supported in ANSI mode only: Business group Generic digits Information indicators Network transport Notification indicator Redirection information


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

Message type: CPG Call Progress Message Mandatory Parameters: Event information Optional Parameters: Access transport Automatic Congestion Level Backward call indicators Cause indicators Call reference Optional backward call indicators Redirection number Remote operations Service activation Transmission medium used User to user indicators May be used to accept user to user information service 1, 2 or 3 User to user information Discarded if user to user service 1 has not been accepted The following optional parameters are supported in ITU-T mode only: Access delivery information Application transport Backward GVNS Call diversion information Call history information Call transfer number Conference treatment indicators Echo control information Connected number Generic notification indicator This parameter may be repeated (see Appendix E) Network specific facility Parameter compatibility information Redirection number restriction indicator UID action indicators The following optional parameters are supported in ANSI mode only: Business group Generic number (address) Generic digits Information indicators Network transport Notification indicator This parameter may be repeated (see Appendix E)


9.4.23 Release response This primitive is used by the application in the case when call clearing was initiated by the ISUP module. It advises the ISUP module that the application has finished clearing the switch path and that the circuit is now available for re-selection.

Whenever a Release indication (REL) is received from the ISUP module the application must return a Release response (RLC) to the ISUP module once it has finished clearing the call. An optional Release request (REL) may also be returned before the Release response (RLC) – see description of the Release request primitive.

Message type: RLC Release Complete Message Mandatory Parameters: None Optional Parameters: The following parameters are supported in ITU-T mode only Cause indicators


9.4.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 9.7.1 Call Clearing procedure for further information.

Message type: REL Release Message Mandatory Parameters: None Optional Parameters: Access transport Cause indicators Defaults to the following if not supplied: Coding standard = CCITT Location = User Recommendation = Q.763 Cause Value = Normal Unspecified Generic number (address) This parameter may be repeated in this message Signalling point code User to user information Discarded if user to user service 1 has not been accepted User to user indicators The following optional parameters are supported in ITU-T mode only Access delivery information Automatic congestion control Network specific facility Parameter compatibility information Redirection information Redirection number Redirection number restriction indicator Remote operations Display The following optional parameters are supported in ANSI mode only: Call reference Charge number Generic digits Network transport Service activation


9.4.25 Request information request This primitive is used by the application to request additional call information.

Message type: INR Information Request Message Mandatory Parameters: Information request indicators Optional Parameters: Call reference The following optional parameters are only supported in ITU-T mode only: Network specific facility Parameter compatibility information The following optional parameters are only supported in ANSI mode only: Network transport

9.4.26 Resume request This primitive is used by the application to resume a call that was previously suspended.

Message type: RES Resume Message Mandatory Parameters: None Optional Parameters: Suspend/resume indicators Defaults to 0x00 if not supplied i.e. ISDN Subscriber Initiated Call reference


9.4.27 Segmentation request


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

Message type: SGM Segmentation Message Mandatory Parameters: None Optional Parameters: Access transport User-to-user information Message compatibility information Generic digit This parameter may be repeated (see Appendix E) Generic notification This parameter may be repeated (see Appendix E) Generic number This parameter may be repeated (see Appendix E)


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

Message type: IAM Initial Address Message Mandatory Parameters: Called party number Optional Parameters: Access transport Calling party’s category Defaults to 0x0a if not supplied Call reference Calling party number Forward call indicators Defaults to 0x0040 if not supplied Generic digits This parameter may be repeated (see Appendix E) Generic number (address) This parameter may be repeated (see Appendix E) Hop counter Nature of connection indicators Defaults to 0x00 if not supplied Original called number Redirecting number Redirection information Remote operations Service activation Transit network selection User service information In ANSI mode, defaults to 0x80, 0x90 , 0xa2 CCITT coding standard Information transfer capability speech 64kbit/s circuit mode µ-law (layer 1 protocol) User service information prime User to user information If no user to user indicators are provided, presence of user to user information is considered as an implicit request of service 1. 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

Continued


Setup request (continued):

The following parameters are supported in ITU-T mode only: Echo control information Forward GVNS Freephone indicators Generic notification indicator Generic reference Location number MLPP precedence Network management controls Network specific facility Optional forward call indicators Originating ISC point code Parameter compatibility information Propagation delay counter Redirection number UID capability indicator SCF ID Transmission medium requirement Required in ITU-T mode only. Permitted values are: 0x00 Speech 0x02 64kb/s Unrestricted 0x03 3.1kHz Audio 0x06 64kb/s Preferred Defaults to Speech if not supplied Transmission medium requirement prime User teleservice information User to user indicators May be used to request user to user information service 1, 2 or 3 The following optional parameters are supported in ANSI mode only: Business group Carrier identification Carrier selection information Charge number Circuit assignment map Egress service Generic name Information request indicators Jurisdiction Network transport Operator services information Originating line information Precedence Service code indicator Special processing request Transaction request


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

9.4.29.1 Before ACM issued

Note: This message is only applicable to ITU-T operation.

Message type: CON Connect Message Mandatory Parameters: None Optional Parameters: Application transport Access delivery information Access transport Backward call indicators Defaults to 0x1416 if not supplied i.e. Subscriber Free Ordinary Subscriber, Charge Terminating access ISDN ISDN Used all the way

Backward GVNS Call history information Call reference Connected number Conference treatment indicator Echo control information Generic notification indicator This parameter may be repeated (see Appendix E) Generic number This parameter may be repeated (see Appendix E) Network specific facility Optional backward call indicators Parameter compatibility information Redirection number Redirection number restriction indicator Remote operations Service activation Transmission medium used User to user indicators May be used to accept user to user information service 1, 2 or 3 User to user information Discarded if user to user service 1 has not been accepted


9.4.29.2 Setup response

Message type: ANM Answer Message Mandatory Parameters: None Optional Parameters: Access transport Backward call 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 User to user information Discarded if user to user service 1 has not been accepted The following optional parameters are supported in ITU-T mode only: Access delivery information Application transport Backward GVNS Call history information Connected number Display Echo control information Generic notification indicator This parameter may be repeated (see Appendix E) Generic number This parameter may be repeated (see Appendix E) Parameter compatibility information Network specific facility Redirection number Redirection number restriction indicator The following optional parameters are supported in ANSI mode only: Business group Generic digits Information indicators Network transport Notification parameter This parameter may be repeated (see Appendix E)


9.4.30 Suspend request This message is used by the application to suspend a call that is currently connected.

Message type: SUS Suspend Message Mandatory Parameters: None Optional Parameters: Suspend/resume indicators Defaults to 0x00 if not supplied (i.e. ISDN Subscriber Initiated) Call reference

9.4.31 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 Mandatory Parameters: Message data Optional Parameters: None


9.4.32 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 that it is only possible to exchange two user to user messages in each directions (i.e. 4 messages in all) for the supplementary service 2.

Message type: USR User Information Message Mandatory Parameters: User to user information Optional Parameters: Access transport Call reference


9.5 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:


Use

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.

SAM 2 0x02 Subsequent address digits for overlap signalling. Information indication 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.

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.



Use

Setup indication IAM 1 0x01 Incoming call indication.

Unrecognised message indication

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

User information indication USR 45 0x2d Conveys received user to user data.

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

9.5.1.1 First backward message received

Message type: ACM Address Complete Message Mandatory Parameters: Backward call indicators Optional Parameters: Access transport Cause indicators Call reference Optional backward call indicators Remote operations Service activation Transmission medium used User to user indicators Indicates that a previously requested supplementary service has been provided User to user information The following optional parameters are supported in ITU-T mode only: Access delivery information Application transport Call diversion information Conference treatment indicators Connected number Echo control information Generic notification indicator Network specific facility Parameter compatibility information Redirection number Redirection number restriction indicator UID action indicators

Continued


Alerting request (First backward message issued) (continued):

The following optional parameters are supported in ITU-T mode only: Access delivery information Application transport Call diversion information Connected number Echo control information Generic notification indicator Network specific facility Parameter compatibility information Redirection number Redirection number restriction indicator UID action indicators The following optional parameters are supported in ANSI mode only: Business group Generic digits Information indicators Network transport Notification indicator Redirection information


9.5.1.2 Received following ACM

Message type: CPG Call Progress Message Mandatory Parameters: Event information Optional Parameters: Access transport Backward call indicators Optional backward call indicators Remote operations Service activation Transmission medium used User to user indicators Indicates that a previously requested supplementary service has been provided User to user information The following optional parameters are supported in ITU-T mode only: Access delivery information Application transport Backward GVNS Call diversion information Call history information Call transfer number Connected number Echo control information Generic notification indicator This parameter may be repeated (see Appendix E) Generic number Parameter compatibility information Network specific facility Redirection number restriction indicator UID action indicators The following optional parameters are supported in ANSI mode only: Business group Generic number (address) Generic digits Information indicators Network transport Notification indicator This parameter may be repeated (see Appendix E)


9.5.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 Mandatory Parameters: None Optional Parameters: Message compatibility information Parameter compatibility information Application transport parameter This parameter may be repeated (see Appendix E) End of optional parameter

9.5.3 ‘Generic’ charge indication NOTE: This message is only applicable to ITU-T operation.

This primitive is used to convey charging information relating to a call. This primitive can be issued by ISUP in all call states up to and including the answered and suspended states providing that the circuit group ISPX1GOP_TX_CRG option is set.

Message type: CRG Charge Message Mandatory Parameters: Message data Optional Parameters: None


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

Message type: SZE Circuit seized Mandatory Parameters: Nature of connection indicators Optional Parameters: None

9.5.5 Collection Charging indication

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

Message type: MPM Collection Charging Message Mandatory Parameters: Number of metering pulses

Message number Optional Parameters: None

9.5.6 Confusion indication

This primitive is issued by ISUP on receipt of a Confusion message from the network.

Message type: CFN Confusion Message Mandatory Parameters: None Optional Parameters: Cause Indicators


9.5.7 Continuity indication This primitive is used by ISUP to convey information about whether or not a continuity test has succeeded.

Message type: COT Continuity Message Mandatory Parameters: Continuity indicators Optional Parameters: None

9.5.8 End-to-end message indication

This primitive is used by ISUP for end-to-end signalling.

Message type: PAM Pass Along Message Mandatory Parameters: Message data Optional Parameters: none

9.5.9 Exit indication

NOTE: This message is only applicable to ANSI operation

An Exit Message may be received in the backwards direction from a gateway exchange before Address Complete to indicate that call setup information has successfully been passed to an adjacent network.

Message type: CPG Call Progress Message Mandatory Parameters: Event information Must be coded as value 0x7d (defined as ‘spare’ by ANSI T1.113.3), to indicate Exit. Optional Parameters: Outgoing trunk group number


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

9.5.10.1 Facility requested indication

Message type: FAR Facility Request Message Mandatory Parameters: Facility indicator User to user indicators ITU-T mode only Optional Parameters: Call reference The following optional parameters are supported in ITU-T mode only: Connection request Parameter compatibility information The following optional parameters are supported in ANSI mode only: Business group Called party number Calling party number Charge number Generic number (address) Generic digits Network transport


9.5.10.2 Action requested indication

Message type: FAC Facility Message Mandatory Parameters: None Optional Parameters: Remote operations Service activation The following optional parameters are supported in ITU-T mode only: Access transport Call transfer number Generic notification Message compatibility information Parameter compatibility information

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

9.5.11.1 Accepted

Message type: FAA Facility Accepted Message Mandatory Parameters: Facility indicator User to user indicators Optional Parameters: The following parameters are supported in ITU-T mode only: Call reference Connection request Parameter compatibility information


9.5.11.2 Rejected

Message type: FRJ Facility Rejected Message Mandatory Parameters: Facility indicator Cause indicators Optional Parameters: Call reference The following optional parameters are supported in ITU-T mode only: User to user indicators The following optional parameters are supported in ANSI mode only: Called party number Calling party number

9.5.12 Forward transfer indication

This message is issued by ISUP upon receipt of a Forward Transfer message from the network.

Message type: FOT Forward Transfer Message Mandatory Parameters: None Optional Parameters: Call reference The following optional parameters are supported in ANSI mode only: Cause indicators


9.5.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 Mandatory Parameters: None

Optional Parameters: MCID request indicators Message compatibility information Parameter compatibility information

9.5.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 Mandatory Parameters: None

Optional Parameters: MCID response indicators Message compatibility information Parameter compatibility information Calling party number Access transport Generic number This parameter may be repeated (see Appendix E)


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

9.5.15.1 Subsequent address digits


This primitive is used by ISUP to indicate subsequent incoming called party number address digits from the network when overlap signalling is employed.

Message type: SAM Subsequent Address Message Mandatory Parameters: Subsequent number Optional Parameters: None

9.5.15.2 Additional call information

This primitive is used by ISUP to indicate additional call information (other than called address digits) during incoming call set-up.

Message type: INF Information Message Mandatory Parameters: Information indicators Optional Parameters: Access transport Calling party category Calling party number Call reference The following optional parameters are supported in ITU mode only: Parameter compatibility information Network specific facility

Continued


Additional call information (continued):

The following optional parameters are supported in ANSI mode only: Business group Charge number Originating line information Redirecting number Redirection information User to user information

9.5.16 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 Mandatory Parameters: None Optional Parameters: None

9.5.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 Mandatory Parameters: None Optional Parameters: Message compatibility information Parameter compatibility information Call transfer reference Loop prevention indicators


9.5.18 Network resource management indication This primitive is used by ISUP to convey network resources associated with a certain call. This message is sent along any established path in any direction in any phase of a call.

Message type: NRM Network Resource Management Message Mandatory Parameters: None Optional Parameters: Message compatibility information Parameter compatibility information Echo control information

9.5.19 Overload indication NOTE: This message is only applicable to ITU-T operation.

This primitive is used by the ISUP module to indicate that the remote switch is in overload. It is sent when an Overload message is received from the remote switch during outgoing call set-up. On receipt of this indication, the application should re-route the call (if possible).

The Overload indication will be followed by a Release indication (cause value = 42). Release of the original outgoing circuit does not complete until T3 expires, so preventing the circuit being reused while the remote switch is in overload.

Message type: OLM Overload Message Mandatory Parameters: None Optional Parameters: None


9.5.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 Mandatory Parameters: None Optional Parameters: Optional forward call indicators Optional backward call indicators Message compatibility information Parameter compatibility information Application transport parameter This parameter may be repeated (see Appendix E) End of optional parameter


9.5.21 Proceeding indication This primitive is used by ISUP to indicate that the destination exchange recognises that sufficient address digits have been sent (on an outgoing call) to allow the call to proceed.

Message type: ACM Address Complete Message Mandatory Parameters: Backward call indicators Optional Parameters: Access transport Cause indicators Optional backward call indicators Remote operations Service activation Transmission medium used User to user indicators Indicates that a previously requested supplementary service has been provided User to user information The following optional parameters are supported in ITU-T mode only: Access delivery information Call diversion information Conference treatment indicators Generic notification indicator This parameter may be repeated (see Appendix E) Echo control information Network specific facility Parameter compatibility information Redirection number Redirection number restriction indicator

The following optional parameters are supported in ANSI mode only: Business group Generic digits Information indicators Network transport Notification indicator Redirection information


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

Message type: CPG Call Progress Message Mandatory Parameters: Event information Optional Parameters: Access transport Backward call indicators Optional backward call indicators Remote operations Service activation Transmission medium used User to user indicators Indicates that a previously requested supplementary service has been provided User to user information The following optional parameters are supported in ITU-T mode only: Access delivery information Application transport Call diversion information Generic notification indicator This parameter may be repeated (see Appendix E) Network specific facility Parameter compatibility information Redirection number restriction indicator UID action indicators The following optional parameters are supported in ANSI mode only: Business group Generic number (address) Generic digits Information indicators Network transport Notification indicator This parameter may be repeated (see Appendix E)


9.5.23 Release confirmation This primitive is used by ISUP to indicate that the call clearing sequence has completed and the circuit is again available for re-selection.

At the end of each call, the application must wait until the Release confirmation (RLC) has been received before selecting the circuit for a new outgoing call.

Message type: RLC Release Complete Message Mandatory Parameters: None Optional Parameters: The following optional parameters are supported in ITU-T mode only: Cause indicators


9.5.24 Release indication This primitive is used by ISUP to initiate call clearing, either due to receipt of a REL message from the network or having detected a local condition (such as timer expiry) which requires call clearing.

On receipt of Release indication (REL) from ISUP the application should (if it has not already issued Release request) respond immediately with a Release request (REL). Then when the switch path has been cleared the application should issue a Release response (RLC) to the ISUP module. Note that, if the switch path is cleared immediately, only RLC (not REL followed by RLC) is required.

Message type: REL Release Message Mandatory Parameters: Cause indicators Optional Parameters: Access transport

Automatic congestion level Generic number (address) This parameter may be repeated (see Appendix E) Redirection information Redirection number Signalling point code User to user indicators User to user information The following optional parameters are supported in ITU-T mode only: Access delivery information Network specific facility Parameter compatibility information Redirection number restriction indicator The following optional parameters are supported in ANSI mode only: Call reference Charge number Generic digits Network transport Service activation


9.5.25 Request information indication This primitive is used to indicate to the application a request for additional call information.

Message type: INR Information Request Message Mandatory Parameters: Information request indicators Optional Parameters: Call reference

The following optional parameters are supported in ITU-T mode: Network specific facility Parameter compatibility information

The following optional parameters are supported in ANSI mode: Network termination

9.5.26 Resume indication This primitive is used by ISUP to indicate that a call that had been suspended is now resuming.

Message type: RES Resume Message Mandatory Parameters: Suspend/resume indicators Optional Parameters: Call reference


9.5.27 Segmentation indication


This primitive contains the second segment of an ISUP message.

Message type: SGM Segmentation Message Mandatory Parameters: None Optional Parameters: Access transport User-to-user information Message compatibility information Generic digit This parameter may be repeated (see Appendix E) Generic notification This parameter may be repeated (see Appendix E) Generic number This parameter may be repeated (see Appendix E)

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

9.5.28.1 Before ACM received


Message type: CON Connect Message Mandatory Parameters: Backward call indicators Optional Parameters: Access delivery information Access transport Backward GVNS Call history information Call reference Connected number Conference treatment indicators Echo control information Generic notification indicator This parameter may be repeated (see Appendix E) Generic number This parameter may be repeated (see Appendix E)

Continued


Setup confirmation (continued): Network specific facility Optional backward call indicators Parameter compatibility information Redirection number Redirection number restriction indicator Remote operations Service activation Transmission medium used User to user indicators The response to a previously issued user to user supplementary service request. User to user information Discarded if user to user service 1 has not been accepted


9.5.28.2 After ACM received

Message type: ANM Answer Message Mandatory Parameters: None Optional Parameters: Access transport Backward call indicators Connected number Optional backward call indicators Remote operations Service activation Transmission medium used User to user indicators The response to a previously issued user to user supplementary service request. User to user information Discarded if user to user service 1 has not been accepted The following optional parameters are supported in ITU-T mode: Access delivery information Call history information Echo control information Generic notification indicator This parameter may be repeated (see Appendix E) Generic number This parameter may be repeated (see Appendix E) Network specific facility Parameter compatibility information Redirection number Redirection number restriction indicator The following optional parameters are supported in ANSI mode: Business group Information indicators Network transport Notification parameter This parameter may be repeated (see Appendix E)


9.5.29 Setup indication This primitive is used by ISUP to indicate the arrival of an incoming call.

Message type: IAM Initial Address Message Mandatory Parameters: Nature of connection indicators Forward call indicators Calling party’s category Transmission medium requirement ITU-T mode only User service information Mandatory for ANSI mode only. Optional for ITU-T operation. Called party number Optional Parameters: Access transport Calling party number Call reference Generic number (address) This parameter may be repeated (see Appendix E) Generic digits This parameter may be repeated (see Appendix E) Original called number Redirection information Redirecting number Remote operations Service activation Transit network selection Redirecting number User service information prime User to user indicators Indicates that the calling party is requesting one or more user to user supplementary services. User to user information The following optional parameters are supported in ITU-T mode only: Call diversion treatment indicators Call offering treatment indicators Called IN number CCSS Circuit assignment map Closed user group interlock code Collect call request Conference treatment indicators Connection request Correlation id Echo control information Forward GVNS Freephone indicators

Continued

Setup indication (continued):


The following optional parameters are supported in ITU-T mode only (continued): Generic notification indicator This parameter may be repeated (see Appendix E) Generic reference Hop counter Location number MLPP preference Network management controls Network specific facility Optional forward call indicators Origination ISC point code Parameter compatibility information Propagation delay counter SCF id Transmission medium requirement prime UID capability indicators User teleservice information The following optional parameters are supported in ANSI mode only: Business group Carrier identification Carrier selection information Charge number Circuit assignment map Egress service Generic name Hop counter Information request indicators Jurisdiction Network transport Operator services information Originating line information Precedence Service code indicator Special processing request Transaction request

9.5.30 Suspend indication This message is used by ISUP to indicate that a currently connected call has been suspended.

Message type: SUS Suspend Message Mandatory Parameters: Suspend/resume indicators Optional Parameters: Call reference


9.5.31 Unrecognised message indication


This primitive is used by ISUP to transit an unrecognised message.

Message type: Unrecognised message Mandatory Parameters: Message data Optional Parameters: None

9.5.32 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 Mandatory Parameters: User to user information Optional Parameters: Access transport Call reference


9.6 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 and ISP_MSG_RX_IND 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) 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 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 for the list of supported national specific parameters.

Value Definition/Reference Length Notes Parameter Name Hex Dec Min Max

Access delivery information 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 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 Call diversion treatment indicators 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 Called party number 0x04 4 Section 9.6.1 of this

programmer’s manual 1 18 5

Called IN number 0x6f 111 Q.763 Section 3.73 (09/97) 2 18 - Calling party number 0x0a 10 Section 9.6.2 of this

programmer’s manual 2 18 -

Calling party’s category 0x09 9 Q.763 Section 3.11 1 1 - Carrier identification 0xc5 197 T1.113 Section 3.8A 3 3 1 Carrier selection information 0xee 238 T1.113 Section 3.8B 1 1 1 Cause indicators 0x12 18 Section 9.6.3 of this

programmer’s manual 2 255 -

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 Closed user group interlock code 0x1a 26 Q.763 Section 3.15 4 4 1



Collect call request 0x79 121 Q.763 Section 3.81 (09/97) 1 1 1 Conference treatment indicators 0x72 114 Q.763 Section 3 (09/97) 1 1 Connected number 0x21 33 Q.763 Section 3.16 2 13 1 Connection request 0x0d 13 Q.763 Section 3.17 5 7 1 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 Section 9.6.4 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 Generic notification indicator 0x2c 44 Q.763 Section 3.25 1 1 1, 4 Generic number (address) 0xc0 192 Q.763 Section 3.26 3 14 1, 4 Generic reference 0x42 66 Q.763 Section 3.27 3 255 1, 4 Hop counter 0x3d 61 Q.763 Section 3.80

T1.113 Section 3.20D 1 1 1

Information indicators 0x0f 15 Q.763 Section 3.28 2 2 - Information request indicators 0x0e 14 Q.763 Section 3.29 2 2 - Jurisdiction 0xc4 196 T1.113 Section 3.23A 1 3 1 Location number 0x3f 63 Q.763 Section 3.30 3 13 1 Loop prevention indicators 0x44 68 Q.763 Section 3.67 (09/97) 1 1 - Message compatibility information 0x38 56 Q.763 Section 3.33 1 1 - MCID request indicators 0x3b 59 Q.763 Section 3.31 1 1 1 MCID response indicators 0x3c 60 Q.763 Section 3.32 1 1 1 Message data 0xfa 250 Section 9.6.5 of this

manual 1 255 1

MLPP precedence 0x3a 58 Q.763 Section 3.34 6 6 1 Nature of connection indicators 0x06 6 Q.763 Section 3.35 1 1 - Network management controls 0x5b 91 Q.763 Section 3.68 (09/97) 1 1 1 Network specific facility 0x2f 47 Q.763 Section 3.36 2 255 1 Network transport 0xef 239 T1.113 Section 3.24A 3 255 1 Notification indicator 0xe1 225 T1.113 Section 3.24B 1 1 1, 4 Number of metering pulses 0xff 255 Section 9.6.6 of this

manual 1 1 1

Operator services information 0xc2 194 T1.113 Section 3.24D 1 1 1 Optional backward call indicators 0x29 41 Q.763 Section 3.37 1 1 - Optional forward call indicators 0x08 8 Q.763 Section 3.37 1 1 - 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 Originating line information 0xea 234 T1.113 Section 3.26A 1 1 5 Outgoing trunk group number 0xe7 231 T1.113 Section 3.26B 1 3 1 Parameter compatibility information 0x39 57 Q.763 Section 3.41(09/97) 2 176 - Propagation delay counter 0x31 49 Q.763 Section 3.42 2 2 1 Range and status 0x26 22 Q.763 Section 3.43 1 33 3



Redirecting number 0x0b 11 Q.763 Section 3.44 2 13 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 - Redirection information 0x13 19 Q.763 Section 3.45 1 2 1 Redirection number 0x0c 12 Q.763 Section 3.46 3 13 1 Redirection number restriction indicator

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 Special processing request 0xed 237 T1.113 Section 3.30A 1 1 1 Subsequent number 0x05 5 Q.763 Section 3.51 2 12 - Suspend/resume indicators 0x22 34 Q.763 Section 3.52 1 1 - Tariff type 0xfe 254 Section 9.6.7 of this

manual 1 1 1

Transaction request 0xe3 227 T1.113 Section 3.31B 6 255 1 Transit network selection 0x23 35 Q.763 Section 3.53 2 255 1 Transmission medium requirement 0x02 2 Q.763 Section 3.54 1 1 - Transmission medium requirement prime

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 Section 9.6.8 of this

manual 3 255 4

User service information 0x1d 29 Q.763 Section 3.57 2 11 1 User service information prime 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 User teleservice information 0x34 52 Q.763 Section 3.59 2 3 1

Notes: 1. The ISUP module transports this parameter transparently without verifying its format.

2. The length of this parameter depends on the length of a point code.

3. This parameter is generated within the ISUP module and is not passed across the user interface.

4. This parameter may be repeated. Refer to Appendix E for further information.

5. The minimum length of this parameter may differ depending on the ISUP variant used:

Minimum parameter length Parameter Name ITU ANSI

Called party number 2 1 Originating line information - 1 Signalling point code 2 3


The notation used for the parameter specifications is shown below:

MSB 7 6 5 4 3 2 LSB

Parameter name & value

Parameter length (in octets)

1 1st octet of parameter

2

:

n final octet of parameter

9.6.1 Called party number

The format of the called party number is defined in Q.763 Section 3.9. Due to the importance of the parameter is also shown in the following figure:

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

9.6.2 Calling party number

The format of the calling party number parameter is defined in Q.763 Section 3.10. Due to the importance of the parameter it is also shown in the following figure:

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


9.6.3 Cause indicators

The format of the cause indicators parameter is defined in Q.763 Section 3.12. Due to the importance of the parameter it is also shown in the following figure:

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.

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


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

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 (i.e. ‘Length’ – 2)

3 first octet of data (message type)

4 second octet of data

:

n last octet of data

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

8 7 6 5 4 3 2 1

Name = 11111010 (250)

Length = 1 - 255

1 first octet of data (message type)

second octet of data

:


This parameter is used by ISUP to convey whole messages transparently (e.g. PAM, ‘Generic’ CRG and unrecognised 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).

The first byte of the data field contains the message type (this is the message type contained in the PAM e.g. IAM, REL) followed by the rest of the message data which is encoded as it would appear in a message received from the network.


‘Generic’ Charge message

The message data parameter may be used to convey the entire national specific Charge message within the generic Charge message and the information is sent in transparent format to the user (the ISPX1GOP_TX_CRG circuit group option must be set).

The data field contains all the parameters contained within the Charge message.

Unrecognised message

The message data parameter may be used by ISUP to signal the content of a received unrecognised 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.

9.6.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:

8 7 6 5 4 3 2 1

Name = 11111111 (255)

Length = 1

Number of metering pulses

9.6.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:

8 7 6 5 4 3 2 1

Name = 11111110 (254)

Length = 1

1 Tariff type


9.6.8 Unrecognised parameter

The ISUP module uses this parameter to transport unrecognised parameters transparently. The format of the unrecognised parameter is shown in the following figure. It encapsulates the unrecognised parameter including the name and length of the parameter itself.

The parameter may be used by an application to send a parameter type which is currently not supported by the ISUP module to the network. If a proprietary parameter is to be sent, the application should include the entire proprietary parameter in the ‘data’ area of the unrecognised parameter. No checking is performed within the ISUP module.

The ISUP module will pass any unrecognised received parameters up to the application using this parameter (depending on the setting of the circuit group option ISPGOP_COMPAT).

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

:



9.7 Use of Call Control Primitives

9.7.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 primitive 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.

If the user receives a Release Indication primitive from ISUP:

• The user application must acknowledge it immediately with a Release Response primitive. The user must then wait until the ISUP module responds with a Release Confirmation primitive before attempting a new call on this circuit.

• ISUP will continue to send Release Indication until the user issues Release Response. The user 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 primitive 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 REL message from the network) this normally indicates that an error such as timer expiry has occurred. In this condition, the ISUP module will continue to send Release Indications to the user until the user sends a Release Response. ISUP should then send a Release Confirmation to the user.

If the user sends a Release Request primitive to ISUP:

• The user 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 does attempt to set-up a call before the ISUP module has sent Release Confirmation, the Setup Request will be discarded. A maintenance event is indicated to the Maintenance module.

Note: All new user applications should make use of the Application Controlled Release mechanism. It is enabled by setting the ISPF_ACR and ISPF_NAI options in the module configuration message.


9.7.2 Call Collision procedure

In order to ensure that the correct behaviour is taken by the ISUP module when call collision (also known as glare) occurs, bits 0-1 in the option field in the Configure Circuit Group Request message must be set to the required value (refer to Section 11.2 Configure Circuit Group Request).

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.

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.

Example 1 – 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.

IAMIAMIAM

ISUP MODULE

USER APPLICATION NETWORK


Example 2 – 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’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.

Example 3 – Internal call collision

Internal call collision is indistinguishable from external call collision where this end is configured to slave. Therefore, the application should always accept the incoming call.

IAM

IAMIAMIAM

ISUP MODULE


IAMIAM

IAM

ISUP MODULE



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

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 ISP_MSG_CNF_GRP message (refer to Section 11.2 Configure Circuit Group Request). Note that if the initial hop counter value is set to zero, the hop counter procedure is deactivated.

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 9.6 Parameter Definitions) 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 9.7.1 Call Clearing procedure shall apply. A maintenance event (CCm_CC_Zero_hops) 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, the hop counter parameter will be included in the Setup Request primitive (sent to the network) and it will be set to the initial hop counter value. Note that 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 in the Setup Request primitive.

• If the Setup Request primitive does not contain a hop counter parameter, the hop counter parameter will not be included in the Setup Request primitive.


9.7.4 Continuity Testing

9.7.4.1 Incoming circuits

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

a) when a Continuity check request (CCR) message is received for an idle circuit

b) 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 9.5.4. 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 9.7.1 Call Clearing procedure).

The following subsections show a number of different scenarios where a continuity check is made on an incoming circuit.

Refer to Section 11.3 Configure Timers Request for details.

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.

Example 1 – Continuity check request message received (successful continuity check)

RLCRLC

CCRCCR

RELREL

RLC

ISUP MODULE



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.

Example 2 – Continuity check request message received (unsuccessful continuity check followed by successful continuity check)

REL

CCRSZE

COT (failure)COT (failure)

RLC

RLC RLC

CCRSZE

RELREL

RLC

ISUP MODULE



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.

Example 3 – Continuity check received during incoming call set up (successful continuity check)

IAMIAM

COT (success)COT (success)

ACM ACM

ANM ANM

ISUP MODULE


Call in Speech State: Proceed as usual


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.

Example 4 – Continuity check received during incoming call set up (unsuccessful continuity check)

RLC

REL

IAMIAM

COT (failure)COT (failure)

RLC

REL RLC

CCRSZE

RELREL

ISUP MODULE



ANSI operation

In ANSI, the Loop Back Ackowledgement request (LPA) message is used to indicate that the continuity check loop has been successfully applied this primitive is described in Section 9.4.16 Loop back acknowledgement request.

Example 5 – Continuity check request message received (ANSI)

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.

Example 6 – T36 expiry

RLCRLC

CCRCCR

LPALPA

RLC

RELREL

ISUP MODULE


RLC

RSC

CCRSZE

REL

RLC RLC

T36 expiry

ISUP MODULE



9.7.4.2 Outgoing circuits

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

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

b) 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 9.4.4 Circuit seized request. 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.

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.

Refer to Section 11.3 Configure Timers Request 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.


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.

Example 1 – Continuity check request message sent (successful continuity check)

SZE

REL REL

RLC RLC

CCR

ISUP MODULE



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.

Example 2 – Continuity check request message sent (unsuccessful continuity check followed by successful continuity check)

SZE CCR

SZE

REL REL

RLC RLC

CCR

COT (failure) COT (failure)

COT (success) COT (success)

ISUP MODULE



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.

Example 3 – Continuity check success outgoing call set up

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

Example 4 – Continuity check success during outgoing call set up

Call in Speech State: Proceed as usual

ANM ANM

COT (success) COT (success)

ACM ACM

IAM IAM

ISUP MODULE


RLC RLC

REL REL

IAM IAM

COT (failure) COT (failure)

CCR CCR

ISUP MODULE



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.

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

Example 6 – Call collision. 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


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.

Example 7 – Reset circuit received

RLC

CCRSZE

RSC

REL

RLCRLC

ISUP MODULE



9.7.5 Malicious Call Identification (MCID) Supplementary Service

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 to the user application and the call will be allowed to continue. The fields in the MCID response indicator will be set as follows:

MCID response indicators

Bit Field Value Meaning

A MCID response indicator 0 MCID not provided

B Hold provided indicator 0 Holding not provided

9.7.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, it sends 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 and 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 (transitnational 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.


10. Management Interface 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 signalling 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:

Value Mnemonic Description

0 none Success 1 ISPE_BAD_ID Inappropriate or invalid id in request message 5 ISPE_BAD_MSG Inappropriate or unrecognised message type. 6 ISPE_BAD_PARAM Invalid parameters contained in message.

The message structure and parameters for each message are defined in the following subsections.


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

ACTION REQUEST TO ISUP: 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 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

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


10.2 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 parameters: offset 0, size 1: ptype Management primitive type. offset 1, size 1: reserved Set to zero offset 2, size 4: cic_mask Bits set to indicate affected circuits in group.



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.


10.3 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 signalling point.

EVENT INDICATION FROM ISUP: structure: MSG type: ISP_MSG_CGSC_IND (0x0708) id: gid src: ISUP module ID dst: Management module ID rsp_req: 0x00 hclass: 0x00 status: 0x00 err_info: 0x00 len: 6 parameters: offset 0, size 1: ptype Management primitive type. offset 1, size 1: reserved Set to zero offset 2, size 4: cic_mask Bits set to indicate affected circuits in group.



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 (signalling point) for the circuits in this group are 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.


10.4 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 signalling point.

EVENT INDICATION FROM ISUP: structure: MSG type: ISP_MSG_CGSS_IND (0x070c) id: gid src: ISUP module ID dst: Management module ID rsp_req: 0x00 hclass: 0x00 status: 0x00 err_info: 0x00 len: 38 parameters: offset 0, size 1: ptype Management primitive type. offset 1, size 1: reserved Set to zero offset 2, size 4: cic_mask Bits set to indicate affected circuits in group. offset 6, size 32: circuit_status The circuit status as indicated from the remote signalling point


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


10.5 Local Overload Request This message may be used by the application to set a local overload condition. This condition will be signalled to the remote signalling point by inserting an automatic congestion control level parameter in all release messages issued to the network.

EVENT INDICATION FROM ISUP: structure: MSG type: ISP_MSG_OVLD_REQ (0x770d) id: 0 src: Originating module ID 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 ISUP RESPONSE: method: By returning the message to the sender type: 0x370d status: SUCCESS ISP_BAD_ID ISP_BAD_PARAM

overload_level - This is the overload level that the application wishes to indicate to the remote signalling 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.


10.6 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 signalling point.

PRIMITIVE INDICATION FROM ISUP type: ISP_MSG_STATUS (0x070e) id: 0 src: ISUP module ID dst: Management 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)

congestion_status - the congestion status of the indicated remote signalling 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)


11. 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 unrecognised message type. 6 ISPE_BAD_PARAM Invalid parameters contained in message.

11.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 5.2 Module Configuration for details of how the configuration messages are used.

ACTION REQUEST TO ISUP: structure: MSG type: ISP_MSG_CONFIG (0x7700) id: 0 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: 40 parameters: offset 0, size 2: options Run time options offset 2, size 1: 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 20: reserved reserved for future use - set to zero.

ISUP RESPONSE: method: By returning the message to the sender type: 0x3700 status: SUCCESS ISPE_BAD_PARAM


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 signalling 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 Reserved Reserved for future use and must be set to zero. 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

unrecognised circuit it will issue an Unequipped CIC (UCIC) message and will recognise 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.

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 11.17 Software Event Indication (ISPe_PAR_FMT_ERR, ISPe_PAR_UNEXPECTED, ISPe_MSG_UNRECOG, ISPe_FMT_ERR, ISPe_WRONG_CID, and ISPe_UMSG_UNEXPECTED) for further information.


Bit Number


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 the MTP only supports one point code size at a time and this option is not required and should be set to zero.

12 - 15 Reserved Reserved for future use and must be 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 signalling 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.

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 Signalling Information Field permitted by the MTP. This should either be set to 62 or 272 depending on the MTP capabilities.

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.


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

ACTION REQUEST TO ISUP: structure: MSG type: ISP_MSG_CNF_GRP (0x7701) 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: 64 (see below) 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. 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 26: Reserved for future use. ISUP RESPONSE: method: By returning the message to the sender type: 0x3701 status: SUCCESS ISP_BAD_ID ISP_BAD_PARAM


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 signalling point.

dpc - The destination point code is the point code of the signalling 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).

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.

Bit Number


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 cic’s. 3 - Highest point code has priority on odd cic’s

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 initialised 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 dialling) 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’.


Bit Number




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 and must be 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.

Bit Number


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.

3 ISPXGOP_UMSG_CFN If set to 1, when the module receives an unrecognised protocol message it will issue a ‘Confusion’ (CFN) message and will recognise receipt of a CFN message.


Bit Number


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. unrecognised 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 unrecognised 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 unrecognised information is possible) 3 - end node (i.e. exchange type A) message and parameter compatibility handling will be performed (passing on unrecognised 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.

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.


Bit Number


14 ISPXGOP_24PC If set to 1, messages sent to the MTP for this circuit group will use 24 bit point codes. If set to zero, the point code size used in the message is determined by the setting of the ISPF_24PC module option. 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.

15 ISPXGOP_UCIC If set to 1, when the module receives a message for an unrecognised circuit it will issue an ‘Unequipped CIC’ (UCIC) message and will recognise 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 recognised.

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.

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.


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

Bit Number


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 is particularly useful with 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.

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


Bit Number


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

Value Dec Hex

Mnemonic Meaning

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 ISUP [10] 4 0x04 ISPGVAR_UK UK ISUP [9] 5 0x05 ISPGVAR_TTC Japan TTC ISUP [15] 6 0x06 ISPGVAR_ANSI_RLT Nortel RLT - ANSI [13] 7 0x07 ISPGVAR_ITU_RLT Nortel RLT - ITU [14] 8 0x08 ISPGVAR_ANSI95 1995 ANSI ISUP (T1.113-1995) 9 0x09 ISPGVAR_ITAL Italian ISUP [12]

10 0x0a ISPGVAR_SSURF French ISUP [20] 11 0x0b ISPGVAR_CHN China ISUP [21]

253 0xfd ISPGVAR_CUST02 Custom variant CUST02

254 0xfe ISPGVAR_CUST01 Custom variant CUST01

Further details related to national or proprietary ISUP variants can be found in APPENDIX A.

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 9.7.3 Hop counter procedure for details.


11.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 ID field is used to select the timer table to be configured. Up to four timer tables can be supported. Note that the signalling point timers always use table 0.

ACTION REQUEST TO ISUP: structure: MSG type: ISP_MSG_CNF_TIM (0x7702) id: tim_tab_id 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: 0, 80, or 128 (see below) 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 6, size 2: t3 offset 8, size 2: t4 offset 10, size 2: t5 offset 12, size 2: t6 offset 14, size 2: t7 offset 16, size 2: t8 offset 18, size 2: t9 offset 20, size 2: t10 offset 22, size 2: t11 offset 24, size 2: t12 offset 26, size 2: t13 offset 28, size 2: t14 offset 30, size 2: t15 offset 32, size 2: t16 offset 34, size 2: t17 offset 36, size 2: t18 offset 38, size 2: t19 offset 40, size 2: t20

Continued


Continued offset 42, size 2: t21 offset 44, size 2: t22 offset 46, size 2: t23 offset 48, size 2: t24 offset 50, size 2: t25 offset 52, size 2: t26 offset 54, size 2: t27 offset 56, size 2: t28 offset 58, size 2: t29 (Resolution in ticks) offset 60, size 2: t30 (Resolution in ticks) offset 62, size 2: t31 offset 64, size 2: t32 offset 66, size 2: t33 offset 68, size 2: t34 offset 70, size 2: t35 offset 72, size 2: t36 offset 74, size 2: t37 offset 76, size 2: t38 offset 78, size 2: t39 offset 80, size 2: t103 offset 82, size 2: t104 offset 84, size 44: reserved ISUP RESPONSE: Method: By returning the message to the sender Type: 0x3702 Status: SUCCESS

version - The version of the Configure Timer Request message being used.

Version Description

0 For backwards compatibility. If version is set to 0, message length of 80 bytes should be used (see note also).

1 Allows all supported timers to be configured. If version is set to 1, message length of 128 bytes should be used (see note also).

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.


Timer default values

The following tables gives the ISUP timers default values (a tick period of 100ms and num_tscan set to 1 are assumed):

Timer Default

(seconds) Description

t1 10 Waiting for RLC t2 180 Waiting for user resume on receipt of user suspend t3 180 Waiting to Initiate release on receipt of overload message t4 300 Waiting for UPA (ITU) t5 60 Delay to alert maintenance on failure to receive RLC t6 180 Waiting for network resume or REL on receipt of network suspend t7 25 Waiting for ACM or CON t8 13 Waiting for cot after IAM t9 45 Waiting for ANM

t10 5 Waiting to receive last address digits before sending ACM t11 not implemented N/A t12 10 Waiting for BLA t13 60 Delay to alert maintenance on failure to receive BLA t14 10 Waiting for UBA t15 60 Delay to alert maintenance on failure to receive UBA t16 10 Waiting for RLC after sending RSC not due to T5 expiry t17 60 Delay to alert maintenance on failure to receive acknowledgement of RSC. t18 10 Waiting for GBA t19 60 Delay to alert maintenance on failure to receive GBA t20 10 Waiting for GUA t21 60 Delay to alert maintenance on failure to receive GUA t22 10 Waiting for GRA t23 60 Delay to alert maintenance on failure to receive GRA t24 2 Waiting for sending COT on receipt of backward check tone t25 5 Waiting for sending CCR and repeat continuity check t26 120 Waiting for sending CCR on subsequent cot failure t27 240 Waiting for continuity check request on receipt of cot failure indication t28 10 Waiting for CQR t29 0.5 Waiting for new congestion indication t30 8 Delay to restore traffic by one step on receipt of congestion indication t31 not implemented N/A t32 not implemented N/A t33 14 Waiting for INF after sending INR t34 3 Waiting for segmentation message t35 20 Waiting for ST digit of for the minimum of digits t36 13 Wait for REL after receiving CCR (note T1.113-1995 refers to it as T34) t37 not implemented N/A t38 150 Waiting for RES t39 10 Waiting for IRS

t40-t102 not implemented N/A t103 20 Timer Tccr,r, (only in ANSI mode) - Waiting for receiving CCR after COT

failure t104 3 Timer Tccr - Waiting for LPA


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

ACTION REQUEST TO ISUP: structure: MSG type: ISP_MSG_END_GRP (0x770f) 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: 0 ISUP RESPONSE: method: By returning the message to the sender type: 0x370f status: SUCCESS ISP_BAD_ID


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

ACTION REQUEST TO ISUP: structure: MSG type: ISP_MSG_SET_CUSTVAR (0x5712) id: cust_variant 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: 1 parameters: offset 0, size 1: base variant ISUP RESPONSE: method: By returning the message to the sender type: 0x1712 status: SUCCESS ISP_BAD_ID ISPE_BAD_PARAM

cust_variant – the name of custom ISUP protocol variant (refer to variants 0xfd and 0xfe in the ‘variant’ field in Section 11.2 Configure Circuit Group Request).

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


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

ACTION REQUEST TO ISUP: structure: MSG type: ISP_MSG_CUSTPARAM (0x5713) id: cust_variant 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: 32 parameters: offset 0, size 1: version – should be set to zero offset 1, size 1: operation offset 2, size 1: message type offset 3, size 5: reserved for future use – should be set to zero offset 8, size 24: parameter types ISUP RESPONSE: method: By returning the message to the sender type: 0x1713 status: SUCCESS ISP_BAD_ID ISPE_BAD_PARAM

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

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


11.7 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 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: RAM address written by ISUP in response message. ISUP RESPONSE: method: By sending a MSG type: 0x2704 status: SUCCESS

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

READ REQUEST TO ISUP: 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. ISUP RESPONSE: method: by sending a MSG type: 0x2705 status: SUCCESS


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

READ REQUEST TO ISUP: structure: MSG type: ISP_MSG_R_CCT (0x6706) id: cid (Circuit 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 structure written by ISUP in response message. ISUP RESPONSE: method: by sending a MSG type: 0x2706 status: SUCCESS


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

READ REQUEST TO ISUP: structure: MSG type: GEN_MSG_MOD_IDENT (0x6111) id: 0 src: originating module ID dst: ISUP module ID rsp_req: Sending layer’s bit set hclass: 0x00 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


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

READ REQUEST TO ISUP: structure: MSG type: ISP_MSG_R_STATUS (0x6710) id: gid src: originating module ID dst: ISUP module ID rsp_req: Sending layer’s bit set 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: method: by sending a MSG type: 0x2710 status: SUCCESS ISP_BAD_ID ISP_BAD_PARAM ISP_BAD_MSG


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

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


Value State

0x84 outgoing call – answered 0x85 outgoing call – suspended

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


11.12 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 initialised. 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.

ACTION REQUEST TO ISUP: structure: MSG type: ISP_MSG_S_MAINT_MASK (0x570f) id: 0 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: 9 parameters: offset 0, size 9: mask Bits set to indicate maintenance events which should be active ISUP RESPONSE: method: By sending a MSG type: 0x170f status: SUCCESS ISP_BAD_PARAM

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 11.16 Maintenance Event Indication for a list of maintenance events.


11.13 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 initialised. 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.

ACTION REQUEST TO ISUP: structure: MSG type: ISP_MSG_S_ERROR_MASK (0x5710) id: 0 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: 9 parameters: offset 0, size 9: mask Bits set to indicate software events which should be active ISUP RESPONSE: Method: By sending a MSG Type: 0x1710 Status: SUCCESS ISP_BAD_PARAM

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 11.17 Software Event Indication for a list of software events.


11.14 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 fields in the masks are defined below:

ACTION REQUEST TO ISUP: structure: MSG type: ISP_MSG_S_TRACE_MASK (0x5711) id: 0 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: 16 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 offset 12, size 4: Reserved for future use ISUP RESPONSE: method: By sending a MSG type: 0x1711 status: SUCCESS ISP_BAD_PARAM


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


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 0

15 14 13 12 11 10 9 8

0 0 0 0 CUST PARAM

SET CUSTVAR

MGT EV IND

SW EVT

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


11.15 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 masintenance 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.

ACTION REQUEST TO ISUP: structure: MSG type: ISP_MSG_S_SELTRACE_MASK (0x5714) id: 0 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: 9 parameters: offset 0, size 9: mask Bits set to indicate selective trace events which should be active ISUP RESPONSE: Method: By sending a MSG Type: 0x1714 Status: SUCCESS ISP_BAD_PARAM

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 11.20 Selective Trace Event Indication for a list of selective trace events.


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

EVENT INDICATION FROM ISUP: 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 parameters: offset 0, size Len Event specific data


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


Maintenance Event Codes (continued):

Value Data Mnemonic Meaning

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

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


Maintenance Event Codes (continued):

Value Data Mnemonic Meaning

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 (unrecognised) protocol message type

received on specified circuit. 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.


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

EVENT INDICATION FROM ISUP: structure: MSG type: ISP_MSG_ERROR_IND (0x070b) id: See below src: ISUP module ID dst: Management 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) 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

1 Parameter

2 Description

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


Status Mnemonic id Parameter 1

Parameter 2

Description

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

10 0x0a ISPe_PAR_UNEXPECTED parameter name

cid message type

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

11 0x0b ISPe_MSG_UNRECOG message type

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

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

14 0x0e ISPe_WRONG_CID cid message type

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

15 0x0f ISPe_UMSG_UNEXPECTED cid message type

state (table below)

An unexpected message type has been received from the user application.

Call states:

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


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

EVENT INDICATION FROM ISUP: structure: MSG type: MGT_MSG_EVENT_IND (0x0008) id: See below src: ISUP module ID dst: Management 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.


11.19 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:

EVENT INDICATION FROM ISUP: 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 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


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

EVENT INDICATION FROM ISUP: 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 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

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

Dec Hex Mnemonic Description

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


APPENDIX A ISUP National variants This section will provide message and parameter information specific to each national variant supported by the ISUP module (for configuration settings refer to Section 11.2).

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 9.3 of this programmer’s manual.

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

For German ISUP set the circuit group options as recommended for the ‘ETSI’ variant (refer to APPENDIX D ISUP CONFIGURATION OPTION SETTINGS).

Parameters

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

Parameter Value

German ISUP API

Length Parameter Name

Hex Dec Hex Dec

Mandatory /Optional Parameter Min Max

Message used

Comments

Carrier selection 0xf0 240 0x23* 35* Optional 2 3 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

* Refer to Section 9.6 for details.


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

For UK ISUP set the circuit group options as recommended for the ‘ETSI’ variant (refer to APPENDIX D ISUP CONFIGURATION OPTION SETTINGS). 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 Value

UK ISUP API


Hex Dec Hex Dec


Message used

Comments

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

0xf2 252 0x1fc 508 Optional 2 18 IAM

National information indicators

0xf5 245 0xdc 220 Optional 2 2 INF

National information request indicators

0xf6 246 0xdd 221 Optional 2 2 INR

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 2 2 IAM


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

For Japanese (TTC) ISUP set the circuit group options as recommended for the ‘ITU’ variant (refer to APPENDIX D ISUP CONFIGURATION OPTION SETTINGS). 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 Value

Japan (TTC) ISUP

API


Hex Dec Hex Dec

Mandatory /Optional Parameter

Min Max

Message used

Comments

Additional party’s category

0xf1 241 0xf3 243 Optional 2 254 ACM, ANM,

CPG, IAM

Carrier information transfer

0xf2 242 0xf1 241 Optional 4 255 ACM, CPG, IAM

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

Charge area information

0xf4 244 0x1fd 509 Optional 1 255 ACM, ANM,

CPG, IAM

Charge information 0xf5 245 0xca 202 Optional 1 1 ACM, CPG

Charge information delay

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

Charge information type

0xf7 247 0xe4 228 Optional 1 1 ACM, CPG

National redirection reason

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

Network function type 0xf9 249 0x1fe 510 Optional 2 254 ACM, CON, IAM

Mobile communication call number

0xfa 250 0xf0 240 Optional 7 7 ACM, CPG, IAM

Mobile communication end information transfer

0xfb 251 0xe2 226 Optional 1 255 ACM, ANM,

CPG, IAM, REL, SUS

PHS terminal identification number

0xfd 253 0xe0 224 Optional 2 18 IAM

Redirecting number* 0x0b 11 0x0b 11 Optional 2 13 IAM

Subscriber number 0xfe 254 0xdf 223 Optional 2 17 IAM



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

For Nortel RLT(ANSI) ISUP set the circuit group options as recommended for the ‘ANSI’ variant (refer to APPENDIX D ISUP CONFIGURATION OPTION SETTINGS). 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.

Parameters

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

Parameter Value

Nortel RLT (ANSI) ISUP

API


Hex Dec Hex Dec


Min Max

Message used

Comments

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

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

Originating line information

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

Signalling point code*

0x1e 30 0x1e 30 Optional 2 2 FAR

Subsequent number*

0x05 5 0x05 5 Optional 2 12 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.

For Nortel RLT(ITU) ISUP set the circuit group options as recommended for the ‘ITU’ variant (refer to APPENDIX D ISUP Configuration option settings).

Parameters

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

Parameter Value

Nortel RLT (ITU) ISUP

API


Hex Dec Hex Dec


Min Max

Message

used

Comments

Signalling point code*

0x1e 30 0x1e 30 Optional 2 2 FAR

* Refer to Section 9.6.


A5. Italian ISUP

Italian ISUP Specification: Specifica Technica N.763


In order to use this feature, ISPGVAR_ITAL must be set in the variant field in the Configure Circuit Group Request message.

For Italian ISUP set the circuit group options as recommended for the ‘ITU’ variant (refer to APPENDIX D ISUP CONFIGURATION OPTION SETTINGS). 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 Value

Italian ISUP API Message Name Message

type Hex Dec Hex Dec

Usage Comments

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 Sections 9.4-9.5 for details.

** Refer to Section 9.6 for details.


Parameters

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

Parameter Value

Italian ISUP API


Hex Dec Hex Dec


Message used

Comments

Charge band 0xe1 225 0x1f0 496 Optional 1 1 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).



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

For French ISUP set the circuit group options as recommended for the ‘ETSI’ variant (refer to APPENDIX D ISUP Configuration option settings).

Messages

Messages specific to French ISUP:

Message Value

French ISUP API Message Name Message


Usage Comments

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.

* Refer to 9.4-9.5 for details.

Parameters

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

Parameter Value

French ISUP API


Hex Dec Hex Dec


Message used

Comments

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



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

For China ISUP set the circuit group options as recommended for the ‘ITU’ variant (refer to APPENDIX D ISUP Configuration option settings). 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.

Messages

Messages specific to China ISUP:

Message Value

China ISUP API Message Name Message


Usage Comments

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 11.2 Configure Circuit Group Request.

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

Parameters

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

Parameter Value

China ISUP API


Hex Dec Hex Dec


Message used

Comments

Charge information 0xfd

254 0xca 202 Fixed 2 2 MPM

Message compatibility information*

0x38 56 0x38 56 Optional 1 1 CCL,MPM OPR



A8. Finnish ISUP

In order to use this message, ISPGVAR_ITU92 must be set in the variant field in the Configure Circuit Group Request message and set the circuit group options as recommended for the ‘ITU’ variant (refer to APPENDIX D ISUP CONFIGURATION OPTION SETTINGS).

Messages

Messages specific to Finnish ISUP:

Message Value

Italian ISUP API Message Name Message


Usage Comments

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.



APPENDIX B Messages currently supported by the ISUP module

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

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


Message Type

Q.763 (1992 and later)


module


module

Subsequent address 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


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

Backward call indicators 00010001 17 YES

Backward GVNS 01001101 77 YES

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 IN number 01101111 111 YES

Called party number 00000100 4 YES

Calling party number 00001010 10 YES

Calling party’s category 00001001 9 YES

Cause indicators 00010010 18 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

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

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

Hop counter 00111101 61 YES

Identification request indicators 00110110 54 YES

Identification indicator 00110111 55 YES

Information indicators 00001111 15 YES

Information request indicators 00001110 14 YES

Location number 00111111 63 YES


Parameter name Code (binary) Code

(decimal)

Parameter

supported by ISUP

module

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 specific facility 00101111 47 YES

Optional backward call indicators 00101001 41 YES

Optional forward call indicators 00001000 8 YES

Original called number 00101000 40 YES

Origination ISC point code 00101011 43 YES

Parameter compatibility information 00111001 57 YES

Propagation delay counter 00110001 49 YES

Range and status 00010110 22 YES

Redirect capability 1001110 78 YES

Redirect counter 1110111 119 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


B3. ANSI T1.113 Messages

Message Type

ANSI T1.113.3


module


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

Unblocking YES YES

Unequipped CIC YES (optionally) YES (optionally)

Unblocking acknowledgement YES YES


B4. ANSI T1.113 Parameters

Parameter name Code

(binary)

Code

(decimal)

Parameter supported

by ISUP module

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

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


Parameter name Code

(binary)

Code

(decimal)

Parameter supported

by ISUP module

Redirection number 00001100 12 YES

Remote operations 00110010 50 YES

Service activation 00110011 51 YES

Service code indicator 11101100 236 YES

Signalling point code 00011110 46 YES

Special processing request 11101101 237 YES

Subsequent number 00000101 5 YES

Suspend/Resume indicators 00100010 34 YES

Transaction request 11100011 227 YES

Transit network selection 00100011 35 YES

Transmission medium used 00110101 53 YES

User service information 00011101 29 YES

User service information prime 00110000 48 YES

User-to-user indicators 00101010 42 YES

User-to-user information 00100000 32 YES


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 System Software Environment Programmer’s Manual [16], 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 Confirmation

Message

0x0003 MGT_MSG_TRACE_EV Trace Event Indication -

0x0008 MGT_MSG_EVENT_IND Management Event Indication -

0x0708 ISP_MSG_CGSC_IND Circuit Group Supervision Control Indication -

0x0709 ISP_MSG_CGSC_CONF Circuit Group Supervision Control Confirmation -

0x070a ISP_MSG_MAINT_IND Maintenance Event Indication -

0x070b ISP_MSG_ERROR_IND Software Event Indication -

0x070c ISP_MSG_CGSS_IND Circuit Group Supervision Status Indication -

0x070d ISP_MSG_OVLD_REQ Local Overload Request -

0x070e ISP_MSG_STATUS Remote point code status indication -

0x0f16 MGT_MSG_SEL_TRACE Selective Trace Event Indication -

0x570f ISP_MSG_S_MAINT_MASK Send Maintenance Event Mask Request 0x170f

0x5710 ISP_MSG_S_ERROR_MASK Send Software Event Mask Request 0x1710

0x5711 ISP_MSG_S_TRACE_MASK Trace Mask Configuration Request 0x1711

0x5712 ISP_MSG_SET_CUSTVAR Variant Initialisation 0x1712

0x5713 ISP_MSG_CUSTPARAM Custom Parameter Configuration 0x1713

0x5714 ISP_MSG_S_SELTRACE_MASK Send Selective Trace Event Mask Request 0x1714

0x6111 GEN_MSG_MOD_IDENT Read Revision Request 0x2111

0x6704 ISP_MSG_R_RAM Read RAM Request 0x2704

0x6705 ISP_MSG_R_GRP Read Circuit Group Request 0x2705

0x6706 ISP_MSG_R_CCT Read Circuit Request 0x2706

0x6710 ISP_MSG_R_STATUS Read Circuit Group Status Request 0x2710

0x7700 ISP_MSG_CONFIG Configure Request 0x3700

0x7701 ISP_MSG_CNF_GRP Configure Circuit Group Request 0x3701

0x7702 ISP_MSG_CNF_TIM Configure Timers Request 0x3702

0x7703 ISP_MSG_CGSC_REQ Circuit Group Supervision Control Request 0x3703

0x770d ISP_MSG_OLVD_REQ Local Overload Request 0x370d

0x770f ISP_MSG_END_GRP End Circuit Group Request 0x370f

0x8701 CAL_MSG_RX_IND Receive Indication to user -

0xc700 ISP_MSG_TX_REQ Transmit request from user -


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 11.1 Configure Request 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:

Value of ‘variant’ field in the

Configure Circuit Group Request message

Variant

(as indicated in the option

tables in this section) Value Mnemonic

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

ANSI 2

8

ISPGVAR_ANSI

ISPGVAR_ANSI95

The option value fields for the 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

Variant Bit Option

ETSI ITU Blue

Book

ITU Q.767 ANSI

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

13 Reserved 0 0 0 0 0

14 ISPGOP_TCCR_CTRL 0 0 0 0 1

15 Reserved 0 0 0 0 0

For bits 0 (ISPGOP_OGC_PRI ) and 1(ISPGOP_PRI_CIC) in the ‘options’ field refer to Section 11.2 Configure Circuit Group Request.


Extended Options

Variant Bit Option

ETSI ITU Blue

Book

ITU Q.767 ANSI

0 ISPXGOP_BLK_767 1 0 1 1 1

1 ISPXGOP_UBK_MH 0 0 0 0 1

2 ISPXGOP_RPT_CGSM 0 0 0 0 1

3 ISPXGOP_UMSG_CFN 1 1 1 0 1

4 ISPXGOP_ANSI (see note 1) 0 0 0 0 0

5 ISPXGOP_PRI_BA 0 0 0 0 1

6 ISPXGOP_T34 1* 0 1 0 0

7 ISPXGOP_TRAN_PAM 0* 0* 0* 0 0*

8-10 ISPXGOP_COMPAT 2* 0 2* 0 0

11 ISPXGOP_ITU92 (see note 1) 0 0 0 0 0

12 ISPXGOP_CAUSE_767 0 0 0 1 0

13 ISPXGOP_DEL_ST 0 0 0 0 1*

14 ISPXGOP_24PC 0 0 0 0 1

15 ISPXGOP_UCIC 0 1 1 0 1

More Extended Options

Variant Bit Option

ETSI ITU Blue

Book

ITU Q.767 ANSI

0 ISPX1GOP_ADD_ST 0 0 0 0 1*

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 1 0 1 0 0

5 ISPX1GOP_T38 0 0 1 0 0

6 ISPX1GOP_SEND_UPT 1* 0 1* 0 0

7 ISPX1GOP_TX_CRG 1 1 1 0 0

8 ISPX1GOP_CCL 0 0 0 0 0

9-15 Not used 0 0 0 0 0

Notes:

* Indicates that the option value may be set differently according to the needs of the particular application and still comply with the indicated specification.

1 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 Request message for setting the variant instead. These options have been retained for backwards compatibility.


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

Hex Dec

Name of parameter Maximum number of repetitions

within one message

0x03 3 Application transport 20

0x14 20 Custom parameter 24

0xc1 193 Generic digits 5

0x2c 44 Generic notification 5

0xc0 192 Generic number 5

0x42 66 Generic reference 5

0xe1 255 Notification indicator 5

0xf9 249 Unrecognised parameter 20


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.

F1. Keep Time

Message sent to request the timer module to issue a periodic timer tick (TM_EXP) message to the ISUP module.

ACTION REQUEST TO ISUP: 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 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

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

F2. Timer Expiry

Periodic timer tick message issued by the timer module.

ACTION REQUEST TO ISUP: 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 parameters: offset 0, size 4: Reserved Must be set to zero.

Intel NetStructure™ SS7 Protocols ISUP …® NetStructure™ SS7 Protocols ISUP Programmer's...

Documents

Transcript of Intel NetStructure™ SS7 Protocols ISUP …® NetStructure™ SS7 Protocols ISUP Programmer's...