Intel NetStructure SS7 Protocols ISUP Programmer's Manual. Document Reference: U04SSS

Transcription

1 Intel NetStructure SS7 Protocols ISUP Programmer's Manual Document Reference: U04SSS

2 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 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. ISUP Programmer s Manual Issue 12 Page 2

3 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 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 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 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. ISUP Programmer s Manual Issue 12 Page 3

4 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 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 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 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 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 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. ISUP Programmer s Manual Issue 12 Page 4

5 CONTENTS 1. Introduction Abbreviations Related Documentation Feature Overview General Description Module Overview Module Configuration Customising ISUP variants Internal Data Structures Global Ram Data Structure Circuit Group Data Structure Per Circuit Data Structure Interface to System Services System Functions Timer Operation Interface to MTP Interface to Application Application Message - Header Format Transmit Request Receive indication Application Message - User Data Format Parameter extension mechanism Application Messages to ISUP Alerting request Application transport request Generic charge request Circuit seized request Collection Charging request Confusion request Continuity request End-to-end message request Exit request Facility request Facility response Forward transfer request Identification request Identification response Information request Loop back acknowledgement request Loop prevention request Network resource management request Overload request Pre-release information request Proceeding request Progress request Release response Release request Request information request Resume request Segmentation request Setup request Setup response Suspend request ISUP Programmer s Manual Issue 12 Page 5

6 Unrecognised message request User information request Application Messages from ISUP Alerting indication Application transport indication Generic charge indication Circuit seized indication Collection Charging indication Confusion indication Continuity indication End-to-end message indication Exit indication Facility indication Facility confirmation Forward transfer indication Identification indication Identification confirmation Information indication Loop back acknowledgement indication Loop prevention indication Network resource management indication Overload indication Pre-release information indication Proceeding indication Progress indication Release confirmation Release indication Request information indication Resume indication Segmentation indication Setup confirmation Setup indication Suspend indication Unrecognised message indication User information indication Parameter Definitions Called party number Calling party number Cause indicators Custom parameter Message data Number of metering pulses Tariff type Unrecognised parameter Use of Call Control Primitives Call Clearing procedure Call Collision procedure Hop counter procedure Continuity Testing Malicious Call Identification (MCID) Supplementary Service Message Segmentation ISUP Programmer s Manual Issue 12 Page 6

7 10. Management Interface Circuit Group Supervision Control Request Circuit Group Supervision Control Confirmation Circuit Group Supervision Control Indication Circuit Group Supervision Status Indication Local Overload Request Remote point code status indication Non-Primitive Interface Configure Request Configure Circuit Group Request Configure Timers Request End Circuit Group Request Variant Initialisation Custom Parameter Configuration Read RAM Request Read Circuit Group Request Read Circuit Request Read Revision Request Read Circuit Group Status Request Send Maintenance Event Mask Request Send Software Event Mask Request Trace Mask Configuration Request Send Selective Trace Event Mask Request Maintenance Event Indication Software Event Indication Management Event Indication Trace Event Indication Selective Trace Event Indication APPENDIX A ISUP National variants A1. German ISUP A2. UK ISUP A3. Japan (TTC) ISUP A4. Nortel RLT A.4.1 Nortel RLT (ANSI) A.4.2 Nortel RLT (ITU) A5. Italian ISUP A6. French ISUP A7. China ISUP A8. Finnish ISUP APPENDIX B Messages currently supported by the ISUP module B1. ITU-T Messages B2. ITU-T Parameters B3. ANSI T1.113 Messages B4. ANSI T1.113 Parameters APPENDIX C Message type table APPENDIX D ISUP Configuration option settings APPENDIX E ISUP Repeat parameters APPENDIX F Timer Services F1. Keep Time F2. Timer Expiry ISUP Programmer s Manual Issue 12 Page 7

8 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 , 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. ISUP Programmer s Manual Issue 12 Page 8

9 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 ISUP Programmer s Manual Issue 12 Page 9

10 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 , 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 [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 UCS Preliminary August 1999 [14] Nortel RLT (ITU) Specification: Standard 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 edition 1 [21] China ISUP Specification: YDN 038 (1997) ISUP Programmer s Manual Issue 12 Page 10

11 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 (1995). - Software implementation of ANSI T 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. ISUP Programmer s Manual Issue 12 Page 11

12 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. ISUP Programmer s Manual Issue 12 Page 12

13 5.2.1 Customising ISUP variants The ISUP module supports a variant-based mechanism that enables the user to select a customreserved 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. ISUP Programmer s Manual Issue 12 Page 13

14 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 percall 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. ISUP Programmer s Manual Issue 12 Page 14

15 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 GCT_receive GCT_grab Send a message to another task. Receive the next message from the module s input queue, blocking the task if no message is ready. As GCT_receive, but no blocking if no message is ready. The following functions are required for message allocations for inter-task communication: getm relm Allocate a message from the system. 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. ISUP Programmer s Manual Issue 12 Page 15

16 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 MTP-TRANSFER-IND MTP-PAUSE MTP-RESUME MTP-STATUS Transmit message to MTP Receive message from MTP Remote point code unavailable indication from MTP Remote point code available indication from MTP 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. ISUP Programmer s Manual Issue 12 Page 16

17 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 Receive Indication Message from application to ISUP Message from ISUP to application. The message structure and parameters for each primitive are defined in the following paragraphs: Transmit Request This primitive is used by the application to send a message to the ISUP module. PRIMITIVE REQUEST TO ISUP: type: id: src: dst: rsp_req: hclass: status: err_info: len: parameters: ISP_MSG_TX_REQ (0xc700) call_ref Application module ID ISUP module ID Number of bytes of user data 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. ISUP Programmer s Manual Issue 12 Page 17

18 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: id: src: dst: rsp_req: hclass: status: err_info: len: parameters: ISP_MSG_RX_IND (0x8701) call_ref ISUP module ID Application module ID Number of bytes of user data 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. ISUP Programmer s Manual Issue 12 Page 18

19 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 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 Length Data 1 byte 1 byte 1 byte 1 byte Length bytes (1 to 253) ISUP Programmer s Manual Issue 12 Page 19

20 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: Primitive Alerting request Message Value type Dec Hex ACM CPG x06 0x2c Use Indicates incoming called party being alerted. Application transport APM 65 0x41 To issue an application transport message. request 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 MPM 201 0xc9 Used to carry charging information. request End-to-end message request PAM 40 0x28 Requests that an end-to-end message is sent. Facility request FAR FAC x1f 0x33 Request activation of a particular facility or action at another exchange. Facility response FAA 32 0x20 Used to accept or reject a facility. FRJ 33 0x21 Previously requested with a facility request. Forward transfer request FOT 8 0x08 Send forward transfer to the network. Information request SAM 2 0x02 Subsequent address digits for overlap signalling. 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 INR 3 0x03 Requests additional call information. request Resume request RES 14 0x0e Resumes suspended call. Segmentation request SGM 56 0x38 Requests that a message segment is sent. Suspend request SUS 13 0x0d Suspends call. Setup request IAM 1 0x01 Initiates outgoing call. Setup response ANM CON 9 7 0x09 0x07 Answers incoming call. ISUP Programmer s Manual Issue 12 Page 20

21 Primitive Unrecognised message request Message Value type Dec Hex Use 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 Alerting request This primitive is used by the application to indicate that the called subscriber s phone is ringing. The primitive takes the form of an Address Complete message when it is the first backward message issued by the destination exchange or a Call Progress message after the first backward message has been issued First backward message issued Message type: ACM Address Complete Message Mandatory Parameters: None Optional Parameters: Backward call indicators Access transport Cause indicators Call reference Optional backward call indicators Remote operations Service activation Transmission medium used User to user indicators User to user information Defaults to 0x1416 if not supplied i.e. Subscriber Free Ordinary Subscriber, Charge Terminating access ISDN ISDN Used all the way May be used to accept user to user information service 1, 2 or 3 (previously requested in a set-up indication). Discarded if user to user service 1 has not been accepted. Continued ISUP Programmer s Manual Issue 12 Page 21

22 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 ISUP Programmer s Manual Issue 12 Page 22

23 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 Optional backward call indicators Redirection number Remote operations Service activation Transmission medium used User to user indicators User to user information Defaults to 0x01 if not supplied i.e. ALERTING May be used to accept user to user information service 1, 2 or 3 Discarded if user to user service 1 has not been accepted 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) ISUP Programmer s Manual Issue 12 Page 23

24 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 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 ISUP Programmer s Manual Issue 12 Page 24

25 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 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 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 ISUP Programmer s Manual Issue 12 Page 25

26 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 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 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 T ), to indicate Exit. Optional Parameters: Outgoing trunk group number ISUP Programmer s Manual Issue 12 Page 26

27 Facility request This primitive is used by the application to request activation of a particular facility or action at another exchange. Two forms of this primitive are supported. FAR is used to request a particular facility during the active (speech) phase of a call, and FAC is used during either the setup or active phase of a call to request a particular action at another exchange Facility request Message type: FAR Facility Request Message 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 ISUP Programmer s Manual Issue 12 Page 27

28 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 Facility response This message is used by the application to accept or reject a previously requested user to user supplementary service 3 during the active (speech) stage of a call Accepted Message type: FAA Facility Accepted Message Mandatory Parameters: Facility indicator Optional Parameters: Call reference User to user indicators The following optional parameters are supported in ITU-T mode only: Connection request Parameter compatibility information ISUP Programmer s Manual Issue 12 Page 28

29 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 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 ISUP Programmer s Manual Issue 12 Page 29

30 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 Identification response NOTE: This message is only applicable to ITU-T operation This primitive is used by the application to respond to the Identification Indication primitive. Message type: IRS Identification Response Message 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 ISUP Programmer s Manual Issue 12 Page 30

31 Information request This primitive is used by the application to submit additional call information to the network and may take two forms Subsequent address digits NOTE: This message is only applicable to ITU-T operation This message may be used to convey subsequent outgoing call called party number address digits to the network when overlap signalling is employed. It is not used for ANSI operation. Message type: SAM Subsequent Address Message Mandatory Parameters: Subsequent number Optional Parameters: None ISUP Programmer s Manual Issue 12 Page 31

32 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 ISUP Programmer s Manual Issue 12 Page 32

33 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 Loop prevention request NOTE: This message is only applicable to ITU-T operation This primitive is used as part of the ECT supplementary service. Message type: LOP Loop Prevention Message Mandatory Parameters: None Optional Parameters: Message compatibility information Parameter compatibility information Call transfer reference Loop prevention indicators ISUP Programmer s Manual Issue 12 Page 33

34 Network resource management request NOTE: This message is only applicable to ITU-T operation This primitive is used by the application to modify network resources associated with a certain call. This message is sent along any established path in any direction in any phase of a call. Message type: NRM Network Resource Management Message Mandatory Parameters: None Optional Parameters: Echo control information Message compatibility information Parameter compatibility information Transmission medium requirement Overload request NOTE: This message is only applicable to ITU-T operation This primitive is used by the application to invoke temporary trunk blocking of a circuit. Message type: OLM Overload Message Mandatory Parameters: None Optional Parameters: None ISUP Programmer s Manual Issue 12 Page 34

35 Pre-release information request NOTE: This message is only applicable to ITU-T operation This primitive can be issued in all call states up until release. It is used by the application to send end-to-end information prior to the release of a call. Message type: PRI Pre-Release Information Message Mandatory Parameters: None Optional Parameters: Optional forward call indicators Optional backward call indicators Message compatibility information Parameter compatibility information Application transport parameter This parameter may be repeated (see Appendix E) End of optional parameter ISUP Programmer s Manual Issue 12 Page 35

36 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 User to user information May be used to accept user to user information service 1, 2 or 3 (previously requested in a set-up indication). 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 ISUP Programmer s Manual Issue 12 Page 36