5i' APPENDIX II (to Recommendation Q.931) Example message flow diagrams and example conditions for cause mapping II.1 Example message flow diagrams Examples of the procedures for the use of the B and D channel network connection types and the selection of the appropriate chan- nel types are summarized in Figures II-1B/FQ.931 to II-7B/FQ.931. These figures are intended to complement the description in the preceding text and do not illustrate all possible situations. Note - Not all frames that may be sent across the TA inter- face may be represented in the following figures. II.1.1 Key to the figures Q.931 messages [ ] Layer 3 C CONNECT CA CONNECT ACKNOWLEDGE CP CALL PROCEEDING D DISCONNECT R RELEASE RC RELEASE COMPLETE S SETUP X.25 layer 3 messages Any layer 3 message preceded by X.25 indicates an X.25 layer 3 packet (e.g. X.25 CR means X.25 call request ). CA call accepted CC call connected CLC clear confirmation CLI clear indication CLR clear request CR call request IC incoming call Layer 2 frames ( ) Layer 2 GTEI Group TEI (127) A.B X.25 layer 2 addresses (includes command and response) SABM Set asynchronous balance mode SABME Set asynchronous balance mode extended. UA Unnumbered acknowledgement frame UI Unnumbered information frame (i.e. using unack- nowledged information transfer at layer 2) I Information frame DISC Disconnect frame Layer 2 addresses marked (x, p) indicates that the SAPI ele- ment of the frame address is coded for packet type (SAPI = 16) information as described in Recommendation Q.921. Layer 2 addresses marked (x, s) refer to signalling type (SAPI = 0) information. II.1.2 Example message flow diagrams Figure II-1/Q.931, p.1 Figure II-2/Q.931, p.2 Figure II-3/Q.931, p.3 Figure II-4/Q.931, p.4 Figure II-5/Q.931, p.5 Figure II-6/Q.931, p.6 Figure II-7/Q.931, p.7 II.2 Example conditions for cause mapping Figures II-8/Q.931 through II-16/Q.931 show example conditions when cause mappings would be utilized between Q.931 and X.25 [5] messages and utilize the specific mappings of Table 6-5/Q.931 and Table 6-6/Q.931 as shown below: Figure Reference Table Q.931 failures during call establishment II-8 Table 6-5/Q.931 II-9 Table 6-5/Q.931 II-10 Table 6-5/Q.931 II-11 Table 6-5/Q.931 II-12 Table 6-5/Q.931 User side failures during X.25 data transfer phase II-13 Table 6-5/Q.931 Note 1 II-14 Table 6-5/Q.931 Note 2 Network side premature clearing II-15 Table 6-6/Q.931 II-16 Table 6-6/Q.931 Note 1 - This mapping is only needed in the case of the Q.931 message arriving prior to the clearing of the last virtual circuit. Note 2 - This situation always results in either an X.25 clear indication | packet with cause No. 9, out of order | for switched virtual circuits, or an X.25 reset | packet with cause No. 9, out of order | for permanent virtual circuits. Figure II-8/Q.931, p.8 Figure II-9/Q.931, p.9 Figure II-10/Q.931, p.10 Figure II-11/Q.931, p.11 Figure II-12/Q.931, p.12 Figure II-13/Q.931, p.13 Figure II-14/Q.931, p.14 Figure II-15/Q.931, p.15 Figure II-16/Q.931, p.16 APPENDIX III (to Recommendation Q.931) Summary of assigned information element identifier and message type code points for the Q.93x-Series of Recommendations H.T. [T198.931] TABLE III-1/Q.931 Information element code points _________________________________________________________________ { Bits 8 7 6 5 4 3 2 1 } Recommendation reference _________________________________________________________________ _________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau III-1 [T198.931], p.17 H.T. [T199.931] TABLE III-2/Q.931 Message type code points _______________________________________________________________ { Bits 8 7 6 5 4 3 2 1 } Recommendation reference _______________________________________________________________ _______________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau III-2 [T199.931], p.18 H.T. [T200.931] TABLE III-3/Q.931 Operation values assigned within the invoke component of the facility information element ____________________________________________ { 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 User-user service } ____________________________________________ | | | | | | | | | | | | | | | | | | Tableau III-3 [T200.931], p.19 ACRONYMS USED IN RECOMMENDATION Q.931 English French Spanish Meaning ABM ABM ABM Asynchronous Balanced Mode (of HDLC) ACK ACK ACU Acknowledgement ADPCM MICDA MICDA Adaptative Differential Pulse Code Modulation AFI AFI IAF Authority and Format Identifier ARM ARM ARM Asynchronous Response Mode (of HDLC) AU AU UA Access Unit BC MFS CP Bearer Capability BCD BCD DCB Binary Coded Decimal Bi Bi Bi Indicated B Channel Bi` Bi` Bi` An idle B Channel Bi Bj Bj Bj A B Channel in use CEI CEI IPEC Connection Endpoint Identifier CES CES SEC Connection Endpoint Suffix CSPDN RPDCC RPDCC Circuit Switched Public Data Network D D D The D Channel DDI SDA MDE Direct Dialling In DLCI DLCI ICED Data Link Connection Iden- tifier (See Recommendations Q.920/Q.921) DTE ETTD ETD Data Terminal Equipment HDLC HDLC HDLC High Level Data Link Control (procedures) HLC CCS CCA High Layer Compatibility I I I Information (frame) IA5 AI5 AI5 International Alphabet No. 5 (defined by CCITT) IE EI EI Information Element ISDN RNIS RDSI Integrated Services Digital Network ISO ISO ISO International Standard Organi- zation IWF IWF FIF Interworking Function IWU UIF UIF Interworking Unit LAN RLE RAL Local Area Network LAPB LAPB LAPB Link Access Protocol-Balanced LAPD LAPD LAPD Link Acces Protocol on the D Channel LLC CCI CCB Low Layer Compatibility LLI LLI IEL Logical Link Identifier (See Recommendation Q.921) NACK NACK ACUN Negative Acknowledgement NIC NIC RIR Network Independent Clock NRM NRM NRM Normal Response Mode (of HDLC) NSAP NSAP PASR Network Service Access Point NT2 NT2 TR2 Network Termination of type two OSI OSI ISA Open System Interconnection PABX PABX CAP Private Automatic Branch Exchange PCM MIC MIC Pulse Code Modulation PH PH MP Packet Handler PSPDN RPDCP RPDCP Packet Switched Public Data Network PSTN RTPC RTPC Public Switched Telephony Network PVC CVP CVP Permanent Virtual Circuit RDTD RDTD RDR Restricted Differential Time Delay SABME SABME SABME Set Asynchronous Balanced Mode Extended (frame) SAPI SAPI IPAS Service Access Point Iden- tifier (See Recommendation Q.921) TA AT AT Terminal Adaptor (See Recommenda- tion I.411) TE1 TE1 ET1 Terminal Equipment of type 1 (See Recommendation I.411) TE2 TE2 ET2 Terminal Equipment of type 2 (See Recommendation I.411) TEI TEI IET Terminal Endpoint Identifier (See Recommendations Q.920 and Q.921) UDI UDI IDSR Unrestricted Digital Informa- tion UI UI UI Unnumbered Information (frame) VC CV CV (Switched) Virtual Circuit References [1] CCITT Recommendation ISDN user-network interface layer 3 - General aspects , | ol. VI(III), Rec. Q.930(I.450). [2] CCITT Recommendation ISDN user-network interfaces - Interface structures and access capabilities , | ol. III, Rec. I.412. [3] CCITT Recommendation ISDN user-network interface - Data link layer specification , | ol. VI(III), Rec. Q.921(I.441). [4] CCITT Recommendation Generic procedures for the control of ISDN supplementary services , | ol. VI, Rec. Q.932. [5] CCITT Recommendation Interface between data terminal equipment (DTE) and data circuit terminating equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit , | Vol. VIII, Rec. X.25. [6] CCITT Recommendation Circuit mode bearer service categories , | Vol. III, Rec. I.231. [7] CCITT Recommendation Support of data terminal equip- ments (DTEs) with V-series type interfaces by an integrated ser- vices digital network (ISDN) , Vol. VIII, Rec. V.110. [8] CCITT Recommendation Support of X.21, X.21 | is and X.20 | is based data terminal equipments (DTEs) by an integrated services digital network (ISDN) , | ol. VIII, Rec. X.30. [9] CCITT Recommendation Support by an ISDN of data termi- nal equipment with V-series type interfaces with provision for sta- tistical multiplexing , | Vol. VIII, Rec. V.120. [10] CCITT Recommendation Pulse code modulation (PCM) of voice frequencies , | Vol. III, Rec. G.711. [11] CCITT Recommendation 32 kbitB/Fs adaptive differential pulse code modulation (ADPCM) , | Vol. III, Rec. G.721. [12] CCITT Recommendation 7 kHz audio coding within 64 kbit/s , | Vol. III, Rec. G.722. [13] CCITT Recommendation Codec for audiovisual services AT n x 384 kbit/s , | Vol. III, Rec. H.261. [14] CCITT Recommendation Support of packet mode terminal equipment by an ISDN , | ol. VIII, Rec. X.31. [15] CCITT Recommendation Multiplexing rate adaptation and support of existing interfaces , | Vol. III, Rec. I.460. [16] CCITT Recommendation Standardization of data signal- ling rates for synchronous data transmission on leased telephone-type circuits , | Vol. VIII, Rec. V.6. [17] CCITT Recommendation International user classes of service in public data networks and integrated services digital networks (ISDNs) , | Vol. VIII, Rec. X.1. [18] CCITT Recommendation ISDN numbering and addressing principles , | Vol. III, Rec. I.330. [19] CCITT Recommendation Numbering plan for the ISDN era , | Vol. II, Rec. E.164. [20] CCITT Recommendation Numbering plan for the interna- tional telephone service , | Vol. III, Rec. E.163. [21] CCITT Recommendation International numbering plan for public data networks , | Vol. VIII, Rec. X.121. [22] CCITT Recommendation Plan for telex destination codes , | Vol. II, Rec. F.69. [23] CCITT Recommendation Network service definition for open systems interconnection (OSI) for CCITT applications , | Vol. VIII, Rec. X.213. [24] ISO Standard 8348 Addendum 2 Information processing systems - Data communications - Network service definition . [25] CCITT Recommendation Principles relating ISDN numbers/subaddress to the OSI reference model network layer addresses , | Vol. III, Rec. I.334. [26] CCITT Recommendation Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for synchronous operation on public data networks , | Vol. VIII, Rec. X.21. [27] CCITT Recommendation Primary rate user-network inter- face - Layer 1 specification , | Vol. III, Rec. I.431. [28] CCITT Recommendation Control procedures for teletex and Group 4 facsimile services , | Vol. VII, Rec. T.62. [29] CCITT Recommendation A document application profile for the interchange of Group 4 facsimile documents , | Vol. VII, Rec. T.503. [30] CCITT Recommendation A document application profile MM for the interchange of formatted mixed mode documents , | Vol. VII, Rec. T.501. [31] CCITT Recommendation Document application profile PM1 for the interchange of processable form documents , | Vol. VII, Rec. T.502. [32] CCITT Recommendation Network-independent basic tran- sport service for the telematic services , | Vol. VII, Rec. T.70. [33] CCITT Recommendation Document application profile for videotex interworking , | Vol. VII, Rec. T.504. [34] CCITT Recommendation Teleservices supported by an ISDN , | Vol. III, Rec. I.241. [35] CCITT Recommendation System aspects of the use of the 7 kHz audio codec within 64 kbit/s , | Vol. III, Rec. G.725. [36] ISO Standard 1745 Information processing - Basic mode control procedures for data communication systems . [37] CCITT Recommendation Link access protocol balanced (LAPB) extended for half-duplex physical level facility , | Vol. VII, Rec. T.71. [38] ISO Standard 4335 Data communication - High-level data link control procedures - Consolidation of elements of pro- cedures [39] ISO Standard 8802-2 Information processing systems - Local area networks - Part 2: Logical link control . [40] CCITT Recommendation Packet switched signalling system between public networks providing data transmission services , | Vol. VIII, Rec. X.75. [41] ISO Standard 8208 Information processing systems - Data communications - X.25 packet level protocol for data terminal equipment [42] ISO Standard 8348 Information processing systems - Data communications - Network service definition . [43] ISO Standard 8473 Information processing systems - Data communications protocol for providing the connectionless-mode network service . [44] CCITT Recommendation Procedure for the exchange of protocol identification during virtual call establishment on packet switched public data networks , | Vol. VIII, Rec. X.244. [45] CCITT Recommendation ISDN user-network interface data link layer - General aspects , | Vol. VI(III), Rec. Q.920(I.440). [46] CCITT Recommendation Basic user-network interface - Layer 1 specification , | Vol. III, Rec. I.430. [47] CCITT Recommendation Definition of bearer service categories , | Vol. III, Rec. I.230. [48] CCITT Recommendation Definition of teleservices , | Vol. III, Rec. I.240. [49] CCITT Recommendation International Alphabet No. 5 , | Vol. VII, Rec. T.50. [50] ISO Standard 646 Information processing - ISO 7-bit coded character set for information interchange . [51] CCITT Recommendations on Integrated services digital network (ISDN) , | Vol. III. [52] CCITT Recommendation Support of data terminal equip- ments (DTEs) with V-series type interfaces by an integrated ser- vices digital network (ISDN) , | Vol. III, Rec. I.463. Recommendation Q.932 GENERIC PROCEDURES FOR THE CONTROL OF | ISDN SUPPLEMENTARY SERVICES 1 General This Recommendation defines the generic procedures applicable for the control of supplementary services at the user-network interface. These procedures may be used for the invocation and operation of supplementary services in association with existing calls or outside any existing calls. The detailed procedures applicable to individual supplementary services are outside the scope of this Recommendation. However, typical examples of the application of these generic procedures to some supplementary services are provided in Appendix I to this Recommendation for explanatory and illustrative purposes only. The application of the Functional protocol defined in S 6, to the operation of individual supplementary services will be the subject of future Recommendations in this series. 2 Overview of the generic protocols and of their scope Three generic protocols are defined for the control of supple- mentary services at ISDN user-network interfaces. These protocols operate at layer 3 of the control plane at the SB/FT reference points, and assume that the use of layers 1 and 2 conforms to Recommendations I.430 | 1], I.431 | 2] and Q.921 | 3]. In addition, the three generic protocols assume the existence of an established data link and use the acknowledged information transfer service available at the layer 2 to layer 3 interface. 2.1 Three generic protocols Three generic protocols are defined for the control of supple- mentary services, two of which are stimulus, the third being func- tional; these protocols are: - the Keypad protocol; - the Feature key management protocol; - the Functional protocol. 2.1.1 Keypad protocol The Keypad protocol is based on the use of the Keypad facility and Display information elements. The Keypad facility information element may be included in the SETUP and INFORMATION messages. The Display information element may be included in any message sent by the network to the user according to Recommendation Q.931[4]. This protocol applies to supplementary service invocation in the user-to-network direction, and the keypad facility codes used for the invocation of individual supplementary services are network dependent. The protocol is stimulus in the sense that it does not require any knowledge about the invoked supplementary service by the user equipment. It may be used in any state of a call and in association with a call for supplementary service invocation and is applicable to both the basic and primary rate access structures. Paragraph 4 contains a detailed specification of this generic protocol. 2.1.2 Feature key management protocol The Feature key management protocol is based on the use of two information elements that are specified in S 8: the Feature activa- tion and Feature indication information elements. The Feature activation information element may be included in the SETUP and in the INFORMATION messages in the user-to-network direction. The Feature indication information element may be included in various basic call control messages in the network-to-user direction. This protocol typically applies to supplementary service operation during calls but also allows for non-call related supple- mentary service control. Non-call related supplementary service control is accomplished by sending an INFORMATION message with the dummy call reference value and which contains a Feature activation information element. The user may send a Feature activation request at any time, and the network may send a Feature indication informa- tion element at any time. The supplementary service associated with the Feature identifier is service provider dependent and must be coordinated between the user and the service provider at subscrip- tion time. As a service provider option, more than one service pro- file may be allocated to an interface, but in this case the termi- nal identification procedures as defined in Annex A must be used in order to relate an appropriate service profile to a particular user. Note - The term "service profile" refers to the information that the network maintains for a given user to characterize the service offered by the network to that user. A portion of this may contain the association of feature identifiers to specific supple- mentary services. A service profile is normally allocated to an interface but may optionally be allocated to a particular user's terminal equipment or to a group of user's terminal equipment using the procedures as defined in Annex A. This protocol is stimulus in the sense that it does not require knowledge of the invoked supplementary service by the user's terminal equipment. Knowledge of the service profile con- tained in the network and of the association of Feature keys to specific supplementary service invocations is required to unambigu- ously define the requested supplementary service. This protocol is typically applicable to the basic rate access structure. A detailed description of this protocol is contained in S 5. 2.1.3 Functional protocol The Functional protocol is based on the use of the Facility information element and the FACILITY message, as well as of other specific functional messages specified in S 7. This protocol is symmetrical, and is applicable to both the basic and primary rate access structures. This protocol is functional in the sense that it requires the knowledge of the related supplementary service by the user equip- ment supporting it. This facilitates user equipment operation without human intervention by defining semantics for the protocol elements which user equipment can process on its own. Functional procedures may follow a Keypad or a Feature key management supplementary service invocation. Messages that are specific to a function are used to invoke supplementary services that require synchronization of resources at both sides of an interface. The common generic message (i.e., the FACILITY message) is used to invoke supplementary services that do not require such resource synchronization. 2.2 Support of the various generic protocols Networks may support more than one of these generic protocols for the control of supplementary services. The support of multiple generic protocols is a network option. Users shall be informed by the service provider at subscription time of the supplementary ser- vices available, and of the generic protocols supported on their access. 2.3 Co-existence of generic protocols As a general rule, the Functional protocol shall be used unless the network specifies the use of a stimulus protocol for the invocation of certain supplementary services, or the users have subscribed to a Feature key management facility and service pro- file. Networks may support one or more of the three generic proto- cols; it is a network option as to whether one or more generic pro- tocols are supported on a given access. In general, the Keypad protocol and Feature key management protocol have only local significance while the Functional protocol may have other than local significance. For a given call instance, the protocol applied at a local interface may be different from the one applied at a remote user's interface. For example, one of the two stimulus protocols may be used at the requesting user's interface, while a functional pro- cedure will, in general, be applied at the remote user's interface unless a network chooses, as an option, to use the Keypad protocol or Feature key management protocol for supplementary service indi- cation or notification in the network-to-user direction. 3 Arrangements by which co-existence of protocols may be sup- ported by a network Some networks may support only one of the generic protocols per user access for the invocation of supplementary services. Other networks may choose to support a single generic protocol for the control of supplementary services, depending on the user access interface type (e.g., Feature key or Keypad on the basic access, Functional on the primary access). This has to be arranged at sub- scription time. Networks supporting multiple generic protocols per access in the user-to-network direction (i.e., for the supplementary service invocation) will implicitly recognize the protocol option chosen by the user on the basis of the received message type or information element type. Networks supporting more than one generic protocol per access in the network-to-user direction (i.e., at the remote user inter- face) may choose to apply a particular protocol depending on the supplementary service characteristics involved. In a case where, for a given supplementary service, more than one protocol can be supported, then the use of the terminal identification procedure as described in Annex A may have to be used in order to determine the protocol supported by that user's terminal equipment, as registered at subscription time. User service profile procedures, as described in Annex A of this Recommendation, provide a means of characterizing the service(s) offered to different groups of one or more terminals on the same user access interface. A network may, therefore, use a parameter within a user service profile to determine the appropri- ate procedures for network initiated supplementary services towards the associated group of one or more terminals. 4 Keypad protocol The Keypad protocol is based on the use of the Keypad facility and Display information elements. While the generic procedures associated with Keypad invocation are specified in this section, the allocation of the access codes used to requestB/Findicate a supplementary service are not to be standardized within the CCITT. An example of the use of the Keypad protocol is given in Appendix I. 4.1 General This generic procedure is based on the use of: - the Keypad facility information element by the user to invoke a supplementary service from the network by provid- ing access codes using either en-bloc or overlap sending; and - the Display information element by the network to give an indication to the local or remote user regarding a supple- mentary service being invoked. This procedure may be complemented in the case of calls where the Bearer capability information ele- ment in the SETUP message is coded indicating "speech" or "3.1 kHz audio", by the provision of in-band tones/announcements to the user. Note - As a network option, the Keypad facility information element may be used by the network to give an indication to the user when the network expects an automatic reaction to the received information to acknowledge an invoked supplementary service. As the semantics of the Keypad facility information element are not stand- ardized the use of the Keypad facility information element in the network-to-user direction may inhibit terminal portability since for a terminal to operate successfully on more than one network it must be capable of interpreting various different semantics as assigned by the network to the Keypad facility information. In any case, user equipment not supporting this option shall follow the error recovery procedures defined in S 5.8 of Recommendation Q.931 of receipt of the Keypad facility information element. The Keypad protocol may be used in conjunction with the Feature key management (S 5) or Functional protocol (S 6) during the invocation of a supplementary service. The Keypad protocol is based on the use of the Keypad facility information element within the INFORMATION or SETUP messages during the establishment, active and clearing phases of a call. 4.2 Messages used in the Keypad protocol As specified in Recommendation Q.931, the Keypad facility information element may be included in both the SETUP and INFORMA- TION messages and may be sent in the user-to-network direction. 4.3 Coding of the Keypad facility information element The contents of the Keypad facility information element are a string of IA5 characters. The syntax of the IA5 character string and the allocation of values for given supplementary services are not subject to CCITT standardization. 4.4 Elements of procedure 4.4.1 General The Keypad protocol includes the following aspects: 1) the Keypad protocol may be used during the call establishment, active, and clearing phases of a call to invoke sup- plementary services. Supplementary service information is conveyed in Keypad facility information elements sent in either SETUP or INFORMATION messages; 2) supplementary service information can be sent from the user to the network either en-bloc or using overlap send- ing; 3) the network may prompt the user to send the required information using the Display information element and/or in-band tones or announcements. Whether this action shall occur or not is supplementary service and network specific. In any case, in-band tones or announcements shall only be used when the Bearer capability information element indicates "speech" or "3.1 kHz audio"; 4) there may be different combinations of user pro- vided information followed by network prompts. Examples of such possible combinations are shown in Table 4-1/Q.932, where the term "stage" is used to refer to information sent by the user between network prompts (if any). H.T. [T1.932] TABLE 4-1/Q.932 Example of stages for sending of information ________________________________________________________________________________________ Number of stages Sending information ________________________________________________________________________________________ 1 { All information sent en-bloc } 1 All information sent overlap 2 Overlap Prompt Overlap 2 En-bloc Prompt En-bloc 2 Overlap Prompt En-bloc 2 En-bloc Prompt Overlap 3 Overlap Prompt Overlap . | | | rompt Overlap, etc. ________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - The number of possible stages is network dependent and may also be dependent on the specific supplementry service being invoked. Table 4-1/Q.932 [T1.932], p.20 4.5 Procedures at the invocation interface 4.5.1 User procedures The procedures below define how information (using either en-bloc or overlap sending) may be sent in a single stage from the user to the network. The procedures are applicable for each stage of user-to-network information sending. 4.5.1.1 En-bloc sending of access codes En-bloc sending of supplementary service information is accom- plished by sending the "complete" supplementary service information in: - the SETUP message, if the supplementary service is being invoked during the call establishment; or - the INFORMATION message, if the supplementary service is being invoked from the active phase of the call or dur- ing the clearing phase of a call. The term "complete" supplementary service information means that sufficient supplementary service information is sent to the network to specify a service without any additional network prompt- ing being required. The network determines that the supplementary service information is "complete" by either: - analysis of the information contents of the Keypad facility information element; or - the presence of a "sending complete" indication (see Recommendation Q.931, S 5.1.3). If the network determines that the information contents of the Keypad facility information element are invalid, the network shall use the error procedures specified in S 4.5.2.3. If the network determined that the information contents are valid and that the user is allowed to invoke the requested service, the network shall respond using the procedures as specified in S 4.5.2.1. 4.5.1.2 Overlap sending of access codes Overlap sending of supplementary service information is the sending of the "complete" supplementary service information (see S 4.5.1.1 for the definition of complete) segmented such that a number of Recommendation Q.931 messages are used to convey the "complete" supplementary service information. The possible combina- tion of messages: a) for supplementary services invoked during call establishment, consists of using the SETUP message plus one or more INFORMATION messages which will be sent in the overlap sending state; or b) for supplementary services invoked in the active or clearing phases of the call, consists of using two or more INFORMATION messages. For case a), normal overlap sending procedures, as specified in Recommendation Q.931, S 5.1.3, shall be used. For case b), the transmission or receipt of INFORMATION mes- sages shall not cause any change to the Recommendation Q.931 call state. The network shall respond to valid supplementary service information with one of the network responses as described in S 4.5.2.1. If the supplementary service information is invalid, then the error procedures as described in S 4.5.2.3 shall apply. 4.5.2 Network procedures 4.5.2.1 Network responses to user requests After receiving information from the user, the network may take one of the following actions. Items 1)-4) are applicable in the cases of both en-bloc and overlap sending; item 5) is applica- ble only in the case of information sent using overlap sending. 1) Clear the call reference via the normal call clearing procedures (see Recommendation Q.931, S 5.3) including the appropriate Cause and optional Display information element(s). 2) Send a CALL PROCEEDING message to the user. Note - This network response is only applicable in a case where the supplementary service is being invoked during call estab- lishment and not in the cases of the supplementary service being invoked from the active or clearing phases of the call. 3) Send an INFORMATION or clearing message to the user that includes a Display information element containing an appropriate response to the request for a supplementary service. The receipt of an INFORMATION message by the user shall not cause any change to the Recommendation Q.931 call state. 4) Prompt the user for more information using the procedures as specified in S 4.5.2.2. This further information could be additional, or new information input by the user or another attempt by the user to re-input the original information correctly. Such procedures are network dependent and may be supple- mentary service specific. 5) Wait for more overlap information. The allowed waiting period is governed by timer T302 in the case of information sent in the overlap sending state and call control timers for over- lap information sent during other phases of the call. The precise action to be taken is dependent on the specific supplementary service being invoked. 4.5.2.2 Network prompting and in-band tone/announcement control The network may prompt the user for more information or may provide in-band tones or announcements regardless of whether or not the Keypad facility information element was included in the initial SETUP message. The network shall determine whether prompting and/or in-band tone or announcement control should occur. Possible factors governing the provision of prompting and in-band information are: - the nature of the supplementary service; - the value of the inter-digit timer; - the type of interface; and - the current status or progress of the supplemen- tary service request. Simultaneously with the application of in-band tones or announcements, the network may send a PROGRESS message containing a Progress indicator information element with the progress descriptor No. 8, In-band information or appropriate pattern now available . The network may, in addition to an audible prompt (i.e., tone or announcement), request information from the user by sending an INFORMATION message which contains the Display and/or Signal infor- mation elements (but shall not contain the Called party number information element). The sending of the INFORMATION message by the network does not result in a change to the Recommendation Q.931 call state. However, when this message is sent in the network overlap sending state, timer T302 shall be re-initialized. The network may prompt the user more than once (i.e., multiple stages may occur), but the network should not prompt the user again prior to the user's response, or, when in the overlap sending state, prior to the expiry of timer T302. This is to avoid situa- tions where a user's response could be related to two unack- nowledged network prompts. Note - As a network option, the Information Request pro- cedures described in Annex B of this Recommendation may be used to prompt the user for additional information related to a given ser- vice request. 4.5.2.3 Error conditions and treatment An error condition exists in the following circumstances: a) timer T302 expires and complete information has not been received; b) information containing a "sending complete" indication indicating en-bloc sending, but the user information sent is not complete; c) information received by the network (complete or incomplete) is invalid. Invalid information is information sent with incorrect format or containing invalid facility identifier or parameter codes; d) the user attempts to invoke a supplementary ser- vice to which the user has not subscribed or to which the user is not allowed access. The action to be taken by the network in these situations is as follows. Note - The text below identifies possible actions that may be taken in an error situation. The specific action to be taken is network and supplementary service dependent. 4.5.2.3.1 Supplementary service being invoked during call establishment The network shall take one of the following actions: i) In-band tones or announcements are applied. If a SETUP ACKNOWLEDGE message has not already been sent, the network shall send a CALL PROCEEDING message to the user, indicating the B-channel to be used and including the Progress indicator informa- tion element with progress descriptor No. 8, In-band information or appropriate pattern is now available . If a SETUP ACKNOWLEDGE message has already been sent, the network shall send a PROGRESS message to the user, including the Progress indicator information element with the progress descriptor No. 8, In-band information or appropriate pattern is now available . The network may prompt the user using the procedures as specified in S 4.5.2.2 to re-input the required information. Oth- erwise, after the in-band tone or announcement has been applied, the call reference shall be cleared by either the user initiating call clearing or the network initiating call clearing at the expiry of a tone or announcement timer. Both the network and the user shall use the clearing procedures as specified in Recommendation Q.931, S 5.3. ii) No in-band tones or announcements are to be applied. The call reference shall be cleared by the network ini- tiating call clearing procedures as specified in Recommendation Q.931, S 5.3. 4.5.2.3.2 Supplementary service being invoked from the active state or during the call clearing phase The network shall take one of the following actions: i) In-band tones or announcements are applied. The network may prompt the user using the procedures as specified in S 4.5.2.2 to re-input the request. Otherwise, depending on the specific supplementary service being invoked, the call shall either be cleared or remain in the same call state. In the case where the call is cleared, clearing shall occur after the in-band tone or announcement has been applied. Clearing shall occur either by the user initiating call clearing or by the network initiating call clearing at the expiry of a tone or announcement timer. Both the network and the user shall use the clearing procedures as specified in Recommendation Q.931, S 5.3. ii) No in-band tones or announcements are to be applied. Depending on the specific supplementary service being invoked, the call shall either be cleared or remain in the same call state. In the case where the call is to be cleared, the call reference shall be cleared by the network initiating call clearing using the procedures as specified in Recommendation Q.931, S 5.3. If the call remains in the same call state, the user may be informed that the supplementary service request was unsuccessful by the network sending an INFORMATION message in accordance with S 4.5.2.1, item 3). 4.6 Procedures at the remote interface The Display and/or Signal information elements can be used for the purpose of providing notification to the remote user from the network. In this case, however, this information is used simply for the purpose of informing the human user, and no automatic reaction to the received information is to be performed by the user's equip- ment itself. 5 Feature key management protocol The Feature key management protocol is a mechanism allowing users to invoke network supplementary services. As these are stimulus procedures, the protocol elements do not, in and of them- selves, identify the service invoked. To determine the service invoked requires knowledge of the user's service profile maintained in the network. No call state changes directly occur by these pro- cedures. The Feature key management protocol is based on two informa- tion elements: Feature activation and Feature indication. The Feature activation information element is the means by which a user requests a supplementary service. The Feature activation informa- tion element contains a feature identifier number which the network then maps to the corresponding service as indicated by that user's service profile. The user's equipment need not have any knowledge of what service is being indicated by the feature identifier number and the user may send a feature request at any time. Feature indication is the means by which a response to a feature activation is indicated by the network. The feature iden- tifier number correlates the network's response with a user's request and/or an indicator associated with a user's equipment. The Feature indication information element also contains a status indi- cator. The status indicator indicates the status of the requested service and may be used by the user's equipment as appropriate with its man-machine interface. 5.1 Messages The Feature activation and Feature indication information ele- ments may be present in several of the messages defined in Recommendation Q.931. The Feature activation information element may appear in the following messages in the user-to-network direc- tion: a) SETUP b) INFORMATION. The Feature indication information element may be sent in the network-to-user direction in the following messages: a) SETUP b) SETUP ACKNOWLEDGE c) CONNECT d) CALL PROCEEDING e) ALERTING f ) INFORMATION g) DISCONNECT h) RELEASE i) RELEASE COMPLETE. 5.2 Procedures 5.2.1 Assumptions and restrictions a) These procedures assume that only one Feature activation request will appear in a message. b) The phrase "call associated services" used herein is defined as services which act upon or relate to an existing call (as defined by the existence of a call reference). c) These procedures are used for the invocation of supplementary services which relate to predefined specific bearer capabilities andB/For are context dependent. Hence the capability to include protocol elements to indicate the bearer capability that the supplementary service is to act upon is not provided. 5.2.2 Invocation of supplementary services The user may request a feature by including a Feature activa- tion information element in the messages defined in S 5.1. If the INFORMATION message is used, it may be sent at any time. The user will indicate the desired feature by specifying the appropriate value in a feature identifier number. 5.2.2.1 Determination of call reference in the INFORMATION message When the Feature activation information element is sent in the INFORMATION message, then the following rules apply: a) if no call references exist, then the dummy call reference must be used (for this non-call associated service type); b) if a call reference(s) has been established, then that value may be used regardless of whether the service type is call associated or non-call associated; c) if a call reference(s) has been established, the dummy call reference may be used only if the service type is non-call associated. If the service type is call associated, then the appropriate call reference must be used. An exception to this rule is when only one call is established. In this instance it is permissible for the user to use the dummy call reference for either service type. This is summarized in Figure 5-1/Q.932. Figure 5-1/Q.931 [T2.932] (a traiter comme tableau), p.21 It is always correct for the user's equipment to use the dummy call reference when no calls exist, or to use an established call reference if one exists, independent of the service type. 5.2.3 Network responses The network may respond to a Feature activation request in several ways. This action will be supplementary service and network specific. 5.2.3.1 Normal responses 5.2.3.1.1 Return of a Feature indication The network may return a Feature indication information ele- ment in an INFORMATION message or any other appropriate call con- trol message as defined in S 5.1. The feature indication may or may not have the same feature identifier number as was present in the original feature activation request. The status indicator will be provided as appropriate to the specific supplementary service requested. 5.2.3.1.2 Prompting for further information The network may prompt the user for more information. When in the overlap sending state, it may do so using the information request procedures (described in Annex B). The user's response shall follow normal overlap sending pro- cedures as defined in Recommendation Q.931. As a network option, the information request procedures described in Annex B of this Recommendation may be used to prompt the user for additional infor- mation related to a given service request. 5.2.3.1.3 Implicit response The network, under certain situations, may not return any explicit indication to the user after a feature activation request. In this case the response is implicit, such as the acknowledgement inherent in providing the service. 5.2.3.1.4 Return of Signal, Cause, or Display information elements The network may return any combination of Signal, Cause, or Display information elements in conjunction with the responses as described in S 5.2.3.1. The use of these information elements is supplementary service and network specific. Coding and the appropriate messages that may contain these information elements are as defined in Recommendation Q.931. 5.2.3.2 Responses during error conditions When an error condition exists (as defined in S 5.2.5), the network may: a) Respond with one or more of the following options: 1) return a Feature indication information element; 2) prompt for further information (see Annex B); 3) provide an implicit response; or 4) return Signal, Cause, or Display information elements. b) Ignore the Feature activation request and not respond at all. c) Clear appropriate existing calls in conjunction with the above actions. 5.2.4 General aspects 5.2.4.1 Use of Feature indication information elements independent of a feature request The network may choose to send Feature indication information at any time independent of the status of any call(s). Multiple Feature indication information elements may be returned in an INFORMATION message or in an appropriate call control message if more than one indicator is to be updated. 5.2.4.2 Deactivation procedures When explicitly deactivating a supplementary service, two methods may be used: a) sending of a feature activation request with the same feature identifier may deactivate the supplementary service. Some supplementary services may be "toggled" on and off; b) sending of a feature activation request with a different feature identifier which is explicitly defined (between the user and network) as the deactivator for that particular sup- plementary service. 5.2.4.3 Clearing of a call If a Feature activation information element is sent using the call reference of an active call, and that call is cleared for some reason, then there does not exist a call reference with which to correlate the feature indication. If a Feature indication informa- tion element is to be returned, then one of the following options may be used: a) the network may send a Feature indication infor- mation element in one of the call clearing messages (i.e., DISCON- NECT, RELEASE, or RELEASE COMPLETE); b) the network may send a Feature indication infor- mation element in an INFORMATION message after clearing has occurred using the dummy call reference. 5.2.5 Error conditions 5.2.5.1 Invalid feature activation request If a user requests a feature using an invalid feature identif- ier number, the network may take actions specified in S 5.2.3.2 as appropriate. An invalid feature identifier number is one in which the user has not subscribed to a corresponding service, or the value is not understood by the service provider (e.g., out of range). 5.2.5.2 Invalid call reference If a user violates the use of the call reference as stated in S 5.2.2.1, the network should not provide the service and should respond as indicated in S 5.2.3.2. 5.2.5.3 Sending of multiple feature activation requests If a sequence of feature activation requests is received in separate messages so rapidly that the network cannot respond to the first feature activation request prior to receiving a subsequent feature activation request, the network may take one of the follow- ing actions: a) act upon all feature activation requests by returning multiple Feature indication information elements (or other responses as detailed in S 5.2.3.1). These may be sent in a single message or in multiple messages; b) act upon the first feature activation request by returning a single response. This response should correspond to the first feature activation request. Feature activation requests after the first request are discarded and ignored by the network. The determination of which action to take is network and sup- plementary service specific. 6 Functional protocol 6.1 General 6.1.1 Introduction This section specifies the functional signalling procedures for the control of supplementary services at the user-network interface. This generic protocol utilizes functions and services provided by Recommendations Q.930 | 5] and Q.931 | 4] basic call control procedures and the functions of the data link layer as defined in Recommendations Q.920 | 6]/Q.921 | 3]. 6.1.2 Scope of the procedures The procedures defined in S 6 specify the basic methodology for the control (e.g., invocation, notification, cancellation, etc.) of supplementary services. The procedures are independent of whether or not the user-network interface is a basic or primary rate interface. 6.1.3 Categories of procedures Two categories of procedures are defined for the functional signalling for supplementary services. The first category, called the separate message approach, utilizes separate message types to indicate a desired function. The HOLD and RETRIEVE set of messages are identified for this category. The second category, called the common information element procedure, utilizes the Facility information element and applies only to supplementary services that do not require synchronization of resources between the user and the network. Both categories are specified in a symmetrical manner and can be signalled both in the network-to-user and the user-to-network directions. 6.1.4 Supplementary service functions The control of supplementary services by either the network or the user includes the following cases: a) the invocation of supplementary services during the establishment of a call; b) the invocation of supplementary services during the clearing of a call; c) the invocation of call related supplementary services during the active state of a call; d) the invocation or registration of supplementary services independent from an active call; e) the invocation of multiple, different supplemen- tary services within a single message; f ) the invocation of supplementary services related to different calls; g) cancellation of invoked supplementary services and notification to the initiator of the supplementary service. The correlation of a call related supplementary service and the call which it modifies is provided by use of the call reference [cases a), b), c), e), f ) and g) listed above]. The correlation of call independent supplementary service invocations and their responses, is provided by the combination of the call reference of the message containing the Facility informa- tion element and the invoke identifier present within the Facility information element itself [refer to cases d), e) and g)]. The identification of different supplementary service invoca- tions within one single message is provided by the invoke identif- ier of the corresponding Facility information element [refer to cases e) and g)]. The identification of supplementary service invo- cations related to different calls is provided by different mes- sages with the corresponding call reference of the appropriate call [refer to case f)], i.e., different call reference values are used to identify each call individually. 6.2 Separate messages category The messages defined in this section are specified as separate functional messages for invoking specific functions which require changes of the resources and auxiliary state and also require syn- chronization of the peer-to-peer state machines. Therefore, these functions cannot be performed in conjunction with the call estab- lishment and clearing procedures but may be used in conjunction with various supplementary services. The functions of these mes- sages are not to be duplicated or overlapped by those of the Facil- ity information element. The following individual messages are defined: HOLD HOLD ACKNOWLEDGE HOLD REJECT RETRIEVE RETRIEVE ACKNOWLEDGE RETRIEVE REJECT. 6.2.1 Hold and Retrieve functions The Hold function is used to put an existing call which is in the establishment or in the active phase in the Call Held auxiliary state. By default, it reserves the B-channel in use (if any) or any other B-channel (if none was already reserved) for that user which is identified by a Connection Endpoint Suffix (CES), as defined in Recommendation Q.921. In addition, the call reference of the held call shall be retained for possible subsequent call retrieval and channel reconnection. As an option, based on a subscription arrangement between the user and the service provider, the B-channel may be released for subsequent re-use by the network for another call. On receipt of a HOLD message the user or the network shall return a HOLD ACKNOWLEDGE message, provided that the requested function can be performed. The network disconnects any B-channel allocated to the call in progress or active when putting that call in the Call Held auxiliary state. Note 1 - Generally, only one B-channel is reserved for each user having put one (or more) call(s) on hold. However, as a sub- scription option, a network may reserve more than one B-channel to a user. Note 2 - Enhancements to the procedures may be required for users requesting the non-reservation of the B-channel, on a per call basis. The HOLD ACKNOWLEDGE message puts the call in the held auxili- ary state and indicates that the Hold function has been performed. The HOLD REJECT message indicates that the hold request was denied and returns the call to the condition it was in prior to the hold request. The HOLD REJECT message contains the Cause information element with e.g., cause No. 29, Facility rejected , or No. 50, Requested facility not subscribed , or No. 69, Requested facility not implemented . The Retrieve function reconnects the user to the requested B-channel. The RETRIEVE message requests that a call be retrieved. The RETRIEVE ACKNOWLEDGE message indicates that the Retrieve func- tion has been performed. The RETRIEVE REJECT message indicates that the retrieve request was denied. The RETRIEVE REJECT message contains the Cause information element with e.g., cause No. 44, Requested channel not available , or No. 34, no channel available . The HOLD and RETRIEVE families of message may be used in a symmetrical manner. 6.2.2 Hold procedures The Hold function should be invoked in association with an existing call (i.e., during the establishment or active phase of a call). The invocation of the Hold function does not affect the exist- ing Recommendation Q.931 call states but does affect the auxiliary state. The request for placing a call on hold places the auxiliary state in the Hold Request state. The responding entity will ack- nowledge this request with a HOLD ACKNOWLEDGE message if this operation was successful. This will result in the auxiliary state being put in the Call Held state. If the requested Hold function cannot be obtained, then a HOLD REJECT message will be returned with the appropriate cause. This will result in the auxiliary state returning to the Idle state. 6.2.3 Retrieve procedures The Retrieve function is requested by sending a RETRIEVE mes- sage. This message may be sent while the auxiliary state is in the Call Held state. The RETRIEVE message may indicate a preferred, any, or exclusive channel. Procedures for the use of the Channel identifi- cation information element are as defined for basic call control. Upon the sending of the RETRIEVE message, the auxiliary state of the initiator's terminal would be the Retrieve Request state. If the Retrieve request is successful, the RETRIEVE ACK- NOWLEDGE message will be returned with the selected B-channel indi- cated. The initiator should not assume that call retrieval has occurred until it receives this message. The auxiliary state would then return to the Idle state. If the Retrieve request is not successful, the RETRIEVE REJECT message will be returned with an appropriate cause. The auxiliary state machine would then remain in the Call Held state. 6.2.4 Auxiliary states for hold and retrieve It is possible to place a call on hold in the Outgoing Call Proceeding, Call Delivered, or the Active state. The concept of dimensioned state space is being introduced to ensure state syn- chronization between the user and the network. This concept sug- gests dimensioning the call state machine into two dimensions. In other words, there would be two states associated with each call. The first would be a Recommendation Q.931 call state and the second would be an auxiliary state associated with Hold. Suppose the dimensioned state space is represented by two coordinates: one is a Recommendation Q.931 call state coordinate and the other is a Hold coordinate. If a Recommendation Q.931 call state transition occurs, the former coordinate is updated. If a call is put on hold, the hold coordinate is updated. When the held call is reconnected, the hold coordinate is again updated. There are four auxiliary states associated with the Hold and Retrieve functions: i) Idle; ii) Hold Request - A request has been made for the Hold function; iii) Call Held - The call is held; iv) Retrieve Request - A request has been made for the Retrieve function. 6.2.5 An example of dimensioned state space Suppose a call is in the Outgoing Call Proceeding state. The dimensioned state space would be: (Outgoing Call Proceeding, Idle) Now the user requests the Hold function. The dimensioned state space would become: (Outgoing Call Proceeding, Hold Request) The call is then put on Hold. The user becomes aware of this upon receiving the HOLD ACKNOW LEDGE message from the network. The dimensioned state space would now be: (Outgoing Call Proceeding, Call Held) The user may receive subsequent call progress messages chang- ing the dimensioned state space to: (Active, Call Held) Now the user requests the Retrieve function. The dimensioned state space would become: (Active, Retrieve Request) When a call is reconnected, the dimensioned state space would be: (Active, Idle) 6.3 Common information element category The Common information element category applies only to sup- plementary services where no synchronization of resources is required between the two signalling entities. However, the user equipment is required to have the capability to track the operation of the supplementary service procedures through various Recommendation Q.931 call states. The procedures are symmetrical and applicable to both user-network and NT2-NT2 applications. A REGISTER, a FACILITY or an existing Recommendation Q.931 call control message is used to carry the Facility information ele- ment which requests the desired supplementary service. This functional procedure provides a flexible and open ended approach to the provision of supplementary service protocols and: - allows new services to be easily introduced; - allows multiple supplementary service invocations within one message; - supports supplementary services with a large number of variants without a proliferation of new messages; - supports non-call associated supplementary ser- vices. In addition, the use of the FACILITY message allows the actions and events related to supplementary services to be clearly separated from those associated with basic call control, hence pro- viding improved stability to the basic call control procedures of Recommendation Q.931. 6.3.1 Call related supplementary service procedures For call related supplementary service procedures initiated at call establishment or call clearing, the procedures for call con- trol as specified in SS 5 and 6 of Recommendation Q.931 are util- ized. This enables, for example, the originating user to send a supplementary service invocation within a SETUP message and to receive from the remote user a return result, return error, or reject component type in the Facility information element within an ALERTING message, CONNECT message, or any other appropriate message from the service provider. If for some reason the network or user is not able to process the call related invocation of a supplemen- tary service contained in an outgoing SETUP message, then the fol- lowing options apply: 1) the network or user may clear the call request and reject the supplementary service invocation by means of a RELEASE COMPLETE message which contains the Cause information ele- ment and a return error or reject component type with the appropri- ate parameters in the Facility information element; 2) the network or user may continue to process the call request according to normal Recommendation Q.931 call control procedures, and reject the supplementary service invocation by including a return error or reject component type with an appropri- ate data element in the Facility information element by means of a FACILITY message or in any appropriate Recommendation Q.931 mes- sage; 3) the network or user may continue to process the call request according to the Recommendation Q.931 call control procedures, and ignore the supplementary service invocation. The option to be used depends on the individual supplementary service procedures, which are the subject of other Recommendations. For call related supplementary service invocations during the Active state of a call, the FACILITY message is used for the exchange of the Facility information elements over the existing signalling connection. This signalling connection is identified by the call reference of the corresponding active call. The call reference provides the means to correlate FACILITY messages belonging to the same signalling transaction. In the case of call related invocations, the call reference correlates with the appropriate call transaction. When a supplementary service affects more than one call, different call references are used to identify each call individually. This implies the use of different FACILITY messages in order to manage each call separately. If a call related FACILITY message is sent using the call reference of a call in progress or of an active call, and this call is cleared due to call related causes, then the call reference may not be cleared simultaneously in call cases. Depending upon the supplementary service invoked, one of the following will occur: - the network or user may retain both the connec- tion and the call reference association and may send a response within a Facility information element in a FACILITY message prior to the initiation of the normal call clearing procedures; or - the network or user may send a response within a Facility information element in the first clearing message (i.e., DISCONNECT, RELEASE, or RELEASE COMPLETE message). 6.3.2 Call independent supplementary service procedures For supplementary service procedures independent of an active call, the initiating side must first establish a reliable data link connection between the network and the user according to the data link services described in Recommendation Q.921. Once the data link connection is established the user or the network starts the estab- lishment of the signalling connection by transferring a REGISTER message across the user-network interface. This signalling connec- tion is identified by the call reference associated with the REGIS- TER message. The requested supplementary service is identified by the operation value within the Facility information element. This signalling connection may be released by the exchange of return result, return error or reject component types contained in the Facility information element within a RELEASE COMPLETE message. Examples of message exchange for supplementary service control for various scenarios is described by means of arrow diagrams in Appendix I. To assign a call reference value and convey the supplementary service invocation, a REGISTER message with an optional Facility information element is used. The Facility information element present either in the REGISTER message or in a subsequent message identifies the supplementary service involved and the type of operation (i.e., invoke, return result, return error or reject com- ponent). One of the following will occur: 1) When the REGISTER message contains a Facility information element and the requested service is available, a FACILITY message containing the Facility information element may be returned. One or more exchanges of FACILITY messages may subse- quently occur. To terminate the service interaction and release the call reference value, a RELEASE COMPLETE message is sent by either side of the interface. The RELEASE COMPLETE message may also con- tain the Facility information element. 2) If the content of the Facility information ele- ment is not understood, then a FACILITY message or a RELEASE COM- PLETE message with the Facility information element is returned with the Reject component type. When the rejection has been returned in a FACILITY message, the Facility information element can be re-sent in another FACILITY message or the request can be cleared and the call reference value released with a RELEASE COM- PLETE message. 3) If the content of the Facility information ele- ment is understood, but the supplementary service request cannot be provided, then a FACILITY message or a RELEASE COMPLETE message with the Facility information element is returned with the com- ponent return error. When the rejection has been returned in a FACILITY message, the Facility information element can be re-sent in another FACILITY message or the request can be cleared and the call reference value released with a RELEASE COMPLETE message. 6.3.3 Responses to multiple supplementary service invoca- tions The possible correlation of responses to multiple supplemen- tary service invocations is the subject of future Recommendations. 6.3.4 Coding of the call reference For general rules, format and coding of call reference values, S 4.3 of Recommendation Q.931 is applicable. For the functional supplementary service control, the dummy call reference is not applicable. 7 Message functional definitions and content This section should be read in conjunction with S 3 of Recommendation Q.931. All messages are additional to those defined in that section and the following tables should be interpreted according to the introduction of S 3 of Recommendation Q.931. 7.1 Messages for supplementary service control Table 7-1/Q.932 summarizes the messages specific to supplemen- tary service control procedures. H.T. [T3.932] TABLE 7-1/Q.932 Messages specific to supplementary service control ___________________________________ Reference ___________________________________ FACILITY 7.1.1 HOLD 7.1.2 HOLD ACKNOWLEDGE 7.1.3 HOLD REJECT 7.1.4 REGISTER 7.1.5 RETRIEVE 7.1.6 RETRIEVE ACKNOWLEDGE 7.1.7 RETRIEVE REJECT 7.1.8 ___________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 7-1/Q.932 [T3.932], p.22 7.1.1 FACILITY This message may be sent to request or acknowledge a supple- mentary service. The supplementary service to be invoked, and its associated parameters, are specified in the Facility information element (see Table 7-2/Q.932). For the use of this message, see S 6. H.T. [T4.932] TABLE 7-2/Q.932 FACILITY message content Message type: FACILITY Significance: local (Note 1) Direction: both ____________________________________________________________________________ Information element Reference Direction Type Length ____________________________________________________________________________ Protocol discriminator 4.2/Q.931 both M 1 ____________________________________________________________________________ Call reference 4.3/Q.931 both M 2 | (hy | ____________________________________________________________________________ Message type 8.1/Q.932 both M 1 ____________________________________________________________________________ Facility 8.2/Q.932 both M 8 | (hy | ____________________________________________________________________________ Display 4.5/Q.931 n | O (Note 2) (Note 3) ____________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | M Mandatory O Optional Note 1 - This message has local significance; however, it may carry information of global significance. Note 2 - Included if the network provides information that can be presented to the user. Note 3 - The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82 octets. Table 7-2/Q.932 [T4.932], p.23 7.1.2 HOLD This message is sent by the network or the user to request the hold function for an existing call (see Table 7-3/Q.932). For the use of this message, see S 6. H.T. [T5.932] TABLE 7-3/Q.932 HOLD message content Message type: HOLD Significance: local Direction: both ___________________________________________________________________________ Information element Reference Direction Type Length ___________________________________________________________________________ Protocol discriminator 4.2/Q.931 both M 1 ___________________________________________________________________________ Call reference 4.3/Q.931 both M 2 | (hy | ___________________________________________________________________________ Message type 8.1/Q.932 both M 1 ___________________________________________________________________________ Display 4.5/Q.931 n | O (Note 1) (Note 2) ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - Included if the network provides information that can be presented to the user. Note 2 - The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82 octets. Tableau 7-3/Q.932 [T5.932], p.24 Blanc 7.1.3 HOLD ACKNOWLEDGE This message is sent by the network or the user to indicate that the hold function has been successfully performed (see Table 7-4B/FQ.932). For the use of this message, see S 6. H.T. [T6.932] TABLE 7-4/Q.932 HOLD ACKNOWLEDGE message content Message type: HOLD ACKNOWLEDGE Significance: local Direction: both ___________________________________________________________________________ Information element Reference Direction Type Length ___________________________________________________________________________ Protocol discriminator 4.2/Q.931 both M 1 ___________________________________________________________________________ Call reference 4.3/Q.931 both M 2 | (hy | ___________________________________________________________________________ Message type 8.1/Q.932 both M 1 ___________________________________________________________________________ Display 4.5/Q.931 n | O (Note 1) (Note 2) ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - Included if the network provides information that can be presented to the user. Note 2 - The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82 octets. Tableau 7-4/Q.932 [T6.932], p.25 Blanc 7.1.4 HOLD REJECT This message is sent by the network or the user to indicate the denial of a request to hold a call (see Table 7-5/Q.932). For the use of this message, see S 6. H.T. [T7.932] TABLE 7-5/Q.932 HOLD REJECT message content Message type: HOLD REJECT Significance: local Direction: both ____________________________________________________________________________ Information element Reference Direction Type Length ____________________________________________________________________________ Protocol discriminator 4.2/Q.931 both M 1 ____________________________________________________________________________ Call reference 4.3/Q.931 both M 2 | (hy | ____________________________________________________________________________ Message type 8.1/Q.932 both M 1 ____________________________________________________________________________ Cause 4.5/Q.931 both M 4 | (hy | 2 ____________________________________________________________________________ Display 4.5/Q.931 n | O (Note 1) (Note 2) ____________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - Included if the network provides information that can be presented to the user. Note 2 - The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82 octets. Tableau 7-5/Q.932 [T7.932], p.26 Blanc 7.1.5 REGISTER This message is sent by the user or the network to assign a new call reference for non-call associated transactions (see Table 7-6/Q.932). For the use of this message, see S 6. H.T. [T8.932] TABLE 7-6/Q.932 REGISTER message content Message type: REGISTER Significance: local (Note 1) Direction: both ___________________________________________________________________________ Information element Reference Direction Type Length ___________________________________________________________________________ Protocol discriminator 4.2/Q.931 both M 1 ___________________________________________________________________________ Call reference 4.3/Q.931 both M 2 | (hy | ___________________________________________________________________________ Message type 8.1/Q.932 both M 1 ___________________________________________________________________________ Facility 8.2/Q.932 both O (Note 4) 2 | (hy | ___________________________________________________________________________ Display 4.5/Q.931 n | O (Note 2) (Note 3) ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - This message has local significance; however, it may carry information of global significance. Note 2 - Included if the network provides information that can be presented to the user. Note 3 - The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82 octets. Note 4 - Included if the network or the user provides supplemen- tary service information. Tableau 7-6/Q.932 [T8.932], p.27 Blanc 7.1.6 RETRIEVE This message is sent by the network or the user to request the retrieval of a held call (see Table 7-7/Q.932). For the use of this message, see S 6. H.T. [T9.932] TABLE 7-7/Q.932 RETRIEVE message content Message type: RETRIEVE Significance: local Direction: both ___________________________________________________________________________ Information element Reference Direction Type Length ___________________________________________________________________________ Protocol discriminator 4.2/Q.931 both M 1 ___________________________________________________________________________ Call reference 4.3/Q.931 both M 2 | (hy | ___________________________________________________________________________ Message type 8.1/Q.932 both M 1 ___________________________________________________________________________ Channel identification 4.5/Q.931 both O (Note 1) 2 | (hy | ___________________________________________________________________________ Display 4.5/Q.931 n | O (Note 2) (Note 3) ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - If not included, its absence is interpreted as any chan- nel acceptable. Note 2 - Included if the network provides information that can be presented to the user. Note 3 - The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82 octets. Tableau 7-7/Q.932 [T9.932], p.28 Blanc 7.1.7 RETRIEVE ACKNOWLEDGE This message is sent by the network or the user to indicate that the retrieve function has been successfully performed (see Table 7-8/Q.932). For the use of this message, see S 6. H.T. [T10.932] TABLE 7-8/Q.932 RETRIEVE ACKNOWLEDGE message content Message type: RETRIEVE ACKNOWLEDGE Significance: local Direction: both ___________________________________________________________________________ Information element Reference Direction Type Length ___________________________________________________________________________ Protocol discriminator 4.2/Q.931 both M 1 ___________________________________________________________________________ Call reference 4.3/Q.931 both M 2 | (hy | ___________________________________________________________________________ Message type 8.1/Q.932 both M 1 ___________________________________________________________________________ Channel identification 4.5/Q.931 both O (Note 1) 2 | (hy | ___________________________________________________________________________ Display 4.5/Q.931 n | O (Note 2) (Note 3) ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - Mandatory in all cases except when the sender accepts the specific B-channel indicated in the RETRIEVE message. If included, a channel is indicated and specified as exclusive. Note 2 - Included if the network provides information that can be presented to the user. Note 3 - The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82 octets. Tableau 7-8/Q.932 [T10.932], p.29 Blanc 7.1.8 RETRIEVE REJECT This message is sent by the network or the user to indicate the inability to perform the requested retrieve function (see Table 7-9/Q.932). For the use of this message, see S 6. H.T. [T11.932] TABLE 7-9/Q.932 RETRIEVE REJECT message content Message type: RETRIEVE REJECT Significance: local Direction: both ____________________________________________________________________________ Information element Reference Direction Type Length ____________________________________________________________________________ Protocol discriminator 4.2/Q.931 both M 1 ____________________________________________________________________________ Call reference 4.3/Q.931 both M 2 | (hy | ____________________________________________________________________________ Message type 8.1/Q.932 both M 1 ____________________________________________________________________________ Cause 4.5/Q.931 both M 4 | (hy | 2 ____________________________________________________________________________ Display 4.5/Q.931 n | O (Note 1) (Note 2) ____________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - Included if the network provides information that can be presented to the user. Note 2 - The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82 octets. Tableau 7-9/Q.932 [T11.932], p.30 Blanc