.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .ce 1000 APPENDIX\ II .ce 0 .ce 1000 (to Recommendation Q.931) .EF '% Fascicle\ VI.11\ \(em\ Rec.\ Q.931'' .OF '''Fascicle\ VI.11\ \(em\ Rec.\ Q.931 %' .sp 9p .RT .ce 0 .ce 1000 \fBExample message flow diagrams and example\fR .sp 1P .RT .ce 0 .ce 1000 \fBconditions for cause mapping\fR .ce 0 .LP II.1 \fIExample message flow diagrams\fR .sp 1P .RT .PP Examples of the procedures for the use of the B and D channel network connection types and the selection of the appropriate channel types are summarized in Figures II\(hy1B/FQ.931 to II\(hy7B/FQ.931. These figures are intended to complement the description in the preceding text and do not illustrate all possible situations. .PP \fINote\fR \ \(em\ Not all frames that may be sent across the TA interface may be represented in the following figures. .RT .sp 1P .LP II.1.1 \fIKey to the figures\fR .sp 9p .RT .LP \fIQ.931 messages\fR .LP [\ ] Layer 3 .LP C CONNECT .LP CA CONNECT ACKNOWLEDGE .LP CP CALL PROCEEDING .LP D DISCONNECT .LP R RELEASE .LP RC RELEASE COMPLETE .LP S SETUP .PP \fIX.25 layer 3 messages\fR .PP Any layer 3 message preceded by X.25 indicates an X.25 layer 3 packet (e.g. X.25 CR means X.25 \fIcall request\fR ). .RT .LP CA call accepted .LP CC call connected .LP CLC clear confirmation .LP CLI clear indication .LP CLR clear request .LP CR call request .LP IC incoming call .LP \fILayer 2 frames\fR .LP (\ ) Layer 2 .LP GTEI Group TEI (127) .LP A.B X.25 layer 2 addresses (includes command and response) .LP SABM Set asynchronous balance mode .LP SABME Set asynchronous balance mode extended. .LP UA Unnumbered acknowledgement frame .LP UI Unnumbered information frame (i.e.\ using unacknowledged information transfer at layer\ 2) .LP I Information frame .LP DISC Disconnect frame .PP Layer 2 addresses marked (x,\ p) indicates that the\ SAPI element 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. .bp .sp 1P .LP II.1.2 \fIExample message flow diagrams\fR .sp 9p .RT .LP .rs .sp 47P .ad r \fBFigure II\(hy1/Q.931, p.1\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure II\(hy2/Q.931, p.2\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure II\(hy3/Q.931, p.3\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure II\(hy4/Q.931, p.4\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure II\(hy5/Q.931, p.5\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure II\(hy6/Q.931, p.6\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 30P .ad r \fBFigure II\(hy7/Q.931, p.7\fR .sp 1P .RT .ad b .RT .sp 1P .LP II.2 \fIExample conditions for cause mapping\fR .sp 9p .RT .PP Figures II\(hy8/Q.931 through II\(hy16/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\(hy5/Q.931 and Table\ 6\(hy6/Q.931 as shown below: .RT .LP \fIFigure\fR \fIReference Table\fR .LP Q.931 failures during call establishment .LP II\(hy8 Table\ 6\(hy5/Q.931 .LP II\(hy9 Table\ 6\(hy5/Q.931 .LP II\(hy10 Table\ 6\(hy5/Q.931 .LP II\(hy11 Table\ 6\(hy5/Q.931 .LP II\(hy12 Table\ 6\(hy5/Q.931 .LP User side failures during X.25 data transfer phase .LP II\(hy13 Table\ 6\(hy5/Q.931 \fINote\ 1\fR .LP II\(hy14 Table\ 6\(hy5/Q.931 \fINote\ 2\fR .LP Network side premature clearing .LP II\(hy15 Table\ 6\(hy6/Q.931 .LP II\(hy16 Table\ 6\(hy6/Q.931 .PP \fINote\ 1\fR \ \(em\ This mapping is only needed in the case of the Q.931 message arriving prior to the clearing of the last virtual circuit. .PP \fINote\ 2\fR \ \(em\ This situation always results in either an X.25 \fIclear indication\fR | packet with cause No.\ 9, \fIout of order\fR | for switched virtual circuits, or an X.25 \fIreset\fR | packet with cause No.\ 9, \fIout of order\fR | for permanent virtual circuits. .bp .RT .LP .rs .sp 13P .ad r \fBFigure II\(hy8/Q.931, p.8\fR .sp 1P .RT .ad b .RT .LP .rs .sp 20P .ad r \fBFigure II\(hy9/Q.931, p.9\fR .sp 1P .RT .ad b .RT .LP .rs .sp 15P .ad r \fBFigure II\(hy10/Q.931, p.10\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 24P .ad r \fBFigure II\(hy11/Q.931, p.11\fR .sp 1P .RT .ad b .RT .LP .rs .sp 19P .ad r \fBFigure II\(hy12/Q.931, p.12\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 21P .ad r \fBFigure II\(hy13/Q.931, p.13\fR .sp 1P .RT .ad b .RT .LP .rs .sp 26P .ad r \fBFigure II\(hy14/Q.931, p.14\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 20P .ad r \fBFigure II\(hy15/Q.931, p.15\fR .sp 1P .RT .ad b .RT .LP .rs .sp 23P .ad r \fBFigure II\(hy16/Q.931, p.16\fR .sp 1P .RT .ad b .RT .LP .bp .ce 1000 APPENDIX\ III .ce 0 .ce 1000 (to Recommendation Q.931) .sp 9p .RT .ce 0 .ce 1000 \fBSummary of assigned information element identifier and\fR .sp 1P .RT .ce 0 .ce 1000 \fBmessage type code points for the Q.93x\(hySeries of Recommendations\fR .ce 0 .ce \fBH.T. [T198.931]\fR .ce TABLE\ III\(hy1/Q.931 .ce \fBInformation element code points\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(60p) | cw(96p) | lw(42p) . { Bits 8\ \ 7\ \ 6\ \ 5\ \ 4\ \ 3\ \ 2\ \ 1 } Recommendation reference _ .T& lw(60p) | lw(96p) | lw(42p) . .T& lw(198p) . .TE .nr PS 9 .RT .ad r \fBTableau III\(hy1 [T198.931], p.17\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [T199.931]\fR .ce TABLE\ III\(hy2/Q.931 .ce \fBMessage type code points\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(60p) | cw(120p) | lw(48p) . { Bits 8\ \ 7\ \ 6\ \ 5\ \ 4\ \ 3\ \ 2\ \ 1 } Recommendation reference _ .T& lw(60p) | lw(120p) | lw(48p) . .TE .nr PS 9 .RT .ad r \fBTableau III\(hy2 [T199.931], p.18\fR .sp 1P .RT .ad b .RT .ce \fBH.T. [T200.931]\fR .ce TABLE\ III\(hy3/Q.931 .ce \fBOperation values assigned within the invoke .ce component of the facility information element\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(66p) | lw(114p) . { 8\ \ 7\ \ 6\ \ 5\ \ 4\ \ 3\ \ 2\ \ 1 . 0\ \ 0\ \ 0\ \ 0\ \ 0\ \ 0\ \ 0\ \ 1 User\(hyuser service } _ .TE .nr PS 9 .RT .ad r \fBTableau III\(hy3 [T200.931], p.19\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .ce 1000 \fBACRONYMS\ USED\ IN\ RECOMMENDATION\ Q.931\fR .ce 0 .sp 1P .sp 2P .LP \s8English French Spanish Meaning .sp 1P .RT .sp 1P .LP \s9ABM ABM ABM Asynchronous Balanced Mode (of HDLC) .sp 9p .RT .LP ACK ACK ACU Acknowledgement .LP ADPCM MICDA MICDA Adaptative Differential Pulse Code Modulation .LP AFI AFI IAF Authority and Format Identifier .LP ARM ARM ARM Asynchronous Response Mode (of HDLC) .LP AU AU UA Access Unit .LP BC MFS CP Bearer Capability .LP BCD BCD DCB Binary Coded Decimal .LP Bi Bi Bi Indicated B Channel .LP Bi` Bi` Bi` An idle B Channel Bi .LP Bj Bj Bj A B Channel in use .LP CEI CEI IPEC Connection Endpoint Identifier .LP CES CES SEC Connection Endpoint Suffix .LP CSPDN RPDCC RPDCC Circuit Switched Public Data Network .LP D D D The D Channel .LP DDI SDA MDE Direct Dialling In .LP DLCI DLCI ICED Data Link Connection Identifier (See Recommendations\ Q.920/Q.921) .LP DTE ETTD ETD Data Terminal Equipment .LP HDLC HDLC HDLC High Level Data Link Control (procedures) .LP HLC CCS CCA High Layer Compatibility .LP I I I Information (frame) .LP IA5 AI5 AI5 International Alphabet No.\ 5 (defined by CCITT) .LP IE EI EI Information Element .LP ISDN RNIS RDSI Integrated Services Digital Network .LP ISO ISO ISO International Standard Organization .LP IWF IWF FIF Interworking Function .LP IWU UIF UIF Interworking Unit .LP LAN RLE RAL Local Area Network .LP LAPB LAPB LAPB Link Access Protocol\(hyBalanced .LP LAPD LAPD LAPD Link Acces Protocol on the D Channel .LP LLC CCI CCB Low Layer Compatibility .LP LLI LLI IEL Logical Link Identifier (See Recommendation\ Q.921) .LP NACK NACK ACUN Negative Acknowledgement .LP NIC NIC RIR Network Independent Clock .LP NRM NRM NRM Normal Response Mode (of HDLC) .LP NSAP NSAP PASR Network Service Access Point .LP NT2 NT2 TR2 Network Termination of type two .LP OSI OSI ISA Open System Interconnection .LP PABX PABX CAP Private Automatic Branch Exchange .LP PCM MIC MIC Pulse Code Modulation .bp .LP PH PH MP Packet Handler .LP PSPDN RPDCP RPDCP Packet Switched Public Data Network .LP PSTN RTPC RTPC Public Switched Telephony Network .LP PVC CVP CVP Permanent Virtual Circuit .LP RDTD RDTD RDR Restricted Differential Time Delay .LP SABME SABME SABME Set Asynchronous Balanced Mode Extended (frame) .LP SAPI SAPI IPAS Service Access Point Identifier (See Recommendation\ Q.921) .LP TA AT AT Terminal Adaptor (See Recommendation I.411) .LP TE1 TE1 ET1 Terminal Equipment of type\ 1 (See Recommendation\ I.411) .LP TE2 TE2 ET2 Terminal Equipment of type\ 2 (See Recommendation\ I.411) .LP TEI TEI IET Terminal Endpoint Identifier (See Recommendations\ Q.920 and Q.921) .LP UDI UDI IDSR Unrestricted Digital Information .LP UI UI UI Unnumbered Information (frame) .LP VC CV CV (Switched) Virtual Circuit .sp 2P .LP \fBReferences\fR .sp 1P .RT .LP [1] CCITT Recommendation \fIISDN user\(hynetwork interface layer 3 \(em General\fR \fIaspects\fR , | ol.\ VI(III), Rec.\ Q.930(I.450). .LP [2] CCITT Recommendation \fIISDN user\(hynetwork interfaces \(em Interface\fR \fIstructures and access capabilities\fR , | ol.\ III, Rec.\ I.412. .LP [3] CCITT Recommendation \fIISDN user\(hynetwork interface \(em Data link\fR \fIlayer specification\fR , | ol.\ VI(III), Rec.\ Q.921(I.441). .LP [4] CCITT Recommendation \fIGeneric procedures for the control of\fR \fIISDN supplementary services\fR , | ol.\ VI, Rec.\ Q.932. .LP [5] CCITT Recommendation \fIInterface between data terminal equipment\fR \fI(DTE) and data circuit terminating equipment (DCE) for terminals operating in\fR \fIthe packet mode and connected to public data networks by dedicated circuit\fR , | Vol.\ VIII, Rec.\ X.25. .LP [6] CCITT Recommendation \fICircuit mode bearer service categories\fR , | Vol.\ III, Rec.\ I.231. .LP [7] CCITT Recommendation \fISupport of data terminal equipments\fR \fI(DTEs) with V\(hyseries type interfaces by an integrated services digital\fR \fInetwork (ISDN)\fR , Vol.\ VIII, Rec.\ V.110. .LP [8] CCITT Recommendation \fISupport of X.21, X.21 | is and X.20 | is\fR \fIbased data terminal equipments (DTEs) by an integrated services digital\fR \fInetwork (ISDN)\fR , | ol.\ VIII, Rec.\ X.30. .LP [9] CCITT Recommendation \fISupport by an ISDN of data terminal equipment\fR \fIwith V\(hyseries type interfaces with provision for statistical\fR \fImultiplexing\fR , | Vol. VIII, Rec.\ V.120. .LP [10] CCITT Recommendation \fIPulse code modulation (PCM) of voice\fR \fIfrequencies\fR , | Vol.\ III, Rec.\ G.711. .LP [11] CCITT Recommendation \fI32 kbitB/Fs adaptive differential pulse code\fR \fImodulation (ADPCM)\fR , | Vol.\ III, Rec.\ G.721. .LP [12] CCITT Recommendation \fI7\ kHz audio coding within 64\ kbit/s\fR , | Vol.\ III, Rec.\ G.722. .LP [13] CCITT Recommendation \fICodec for audiovisual services\fR \fIAT\ n\ \(mu\ 384\ kbit/s\fR , | Vol.\ III, Rec.\ H.261. .LP [14] CCITT Recommendation \fISupport of packet mode terminal equipment by\fR \fIan ISDN\fR , | ol.\ VIII, Rec.\ X.31. .LP [15] CCITT Recommendation \fIMultiplexing rate adaptation and support\fR \fIof existing interfaces\fR , | Vol.\ III, Rec.\ I.460. .bp .LP [16] CCITT Recommendation \fIStandardization of data signalling\fR \fIrates for synchronous data transmission on leased telephone\(hytype circuits\fR , | Vol.\ VIII, Rec.\ V.6. .LP [17] CCITT Recommendation \fIInternational user classes of service in public\fR \fIdata networks and integrated services digital networks (ISDNs)\fR , | Vol.\ VIII, Rec.\ X.1. .LP [18] CCITT Recommendation \fIISDN numbering and addressing principles\fR , | Vol.\ III, Rec.\ I.330. .LP [19] CCITT Recommendation \fINumbering plan for the ISDN era\fR , | Vol.\ II, Rec.\ E.164. .LP [20] CCITT Recommendation \fINumbering plan for the international telephone\fR \fIservice\fR , | Vol.\ III, Rec.\ E.163. .LP [21] CCITT Recommendation \fIInternational numbering plan for public data\fR \fInetworks\fR , | Vol.\ VIII, Rec.\ X.121. .LP [22] CCITT Recommendation \fIPlan for telex destination codes\fR , | Vol.\ II, Rec.\ F.69. .LP [23] CCITT Recommendation \fINetwork service definition for open systems\fR \fIinterconnection (OSI) for CCITT applications\fR , | Vol.\ VIII, Rec.\ X.213. .LP [24] ISO Standard 8348 Addendum 2 \fIInformation processing systems \(em Data\fR \fIcommunications \(em Network service definition\fR . .LP [25] CCITT Recommendation \fIPrinciples relating ISDN numbers/subaddress to\fR \fIthe OSI reference model network layer addresses\fR , | Vol.\ III, Rec.\ I.334. .LP [26] CCITT Recommendation \fIInterface between data terminal equipment\fR \fI(DTE)\ and data circuit\(hyterminating equipment (DCE) for synchronous operation\fR \fIon public data networks\fR , | Vol.\ VIII, Rec.\ X.21. .LP [27] CCITT Recommendation \fIPrimary rate user\(hynetwork interface \(em Layer\ 1\fR \fIspecification\fR , | Vol.\ III, Rec.\ I.431. .LP [28] CCITT Recommendation \fIControl procedures for teletex and Group\ 4\fR \fIfacsimile services\fR , | Vol.\ VII, Rec.\ T.62. .LP [29] CCITT Recommendation \fIA document application profile for the\fR \fIinterchange of Group\ 4 facsimile documents\fR , | Vol.\ VII, Rec.\ T.503. .LP [30] CCITT Recommendation \fIA document application profile MM for the\fR \fIinterchange of formatted mixed mode documents\fR , | Vol.\ VII, Rec.\ T.501. .LP [31] CCITT Recommendation \fIDocument application profile PM1 for the\fR \fIinterchange of processable form documents\fR , | Vol.\ VII, Rec.\ T.502. .LP [32] CCITT Recommendation \fINetwork\(hyindependent basic transport service\fR \fIfor the telematic services\fR , | Vol.\ VII, Rec.\ T.70. .LP [33] CCITT Recommendation \fIDocument application profile for\fR \fIvideotex interworking\fR , | Vol.\ VII, Rec.\ T.504. .LP [34] CCITT Recommendation \fITeleservices supported by an ISDN\fR , | Vol.\ III, Rec.\ I.241. .LP [35] CCITT Recommendation \fISystem aspects of the use of the 7\ kHz audio\fR \fIcodec within 64\ kbit/s\fR , | Vol.\ III, Rec.\ G.725. .LP [36] ISO Standard 1745 \fIInformation processing \(em Basic mode control\fR \fIprocedures for data communication systems\fR . .LP [37] CCITT Recommendation \fILink access protocol balanced (LAPB) extended\fR \fIfor half\(hyduplex physical level facility\fR , | Vol.\ VII, Rec.\ T.71. .LP [38] ISO Standard 4335 \fIData communication \(em High\(hylevel data link control\fR \fIprocedures \(em Consolidation of elements of procedures\fR . .LP [39] ISO Standard 8802\(hy2 \fIInformation processing systems \(em Local area\fR \fInetworks \(em Part\ 2: Logical link control\fR . .LP [40] CCITT Recommendation \fIPacket switched signalling system between\fR \fIpublic networks providing data transmission services\fR , | Vol.\ VIII, Rec.\ X.75. .LP [41] ISO Standard 8208 \fIInformation processing systems \(em Data\fR \fIcommunications \(em X.25 packet level protocol for data terminal equipment\fR . .bp .LP [42] ISO Standard 8348 \fIInformation processing systems \(em Data\fR \fIcommunications \(em Network service definition\fR . .LP [43] ISO Standard 8473 \fIInformation processing systems \(em Data\fR \fIcommunications protocol for providing the connectionless\(hymode network\fR \fIservice\fR . .LP [44] CCITT Recommendation \fIProcedure for the exchange of protocol\fR \fIidentification during virtual call establishment on packet switched public\fR \fIdata networks\fR , | Vol.\ VIII, Rec.\ X.244. .LP [45] CCITT Recommendation \fIISDN user\(hynetwork interface data link\fR \fIlayer \(em General aspects\fR , | Vol.\ VI(III), Rec.\ Q.920(I.440). .LP [46] CCITT Recommendation \fIBasic user\(hynetwork interface \(em Layer\ 1\fR \fIspecification\fR , | Vol.\ III, Rec.\ I.430. .LP [47] CCITT Recommendation \fIDefinition of bearer service categories\fR , | Vol.\ III, Rec.\ I.230. .LP [48] CCITT Recommendation \fIDefinition of teleservices\fR , | Vol.\ III, Rec.\ I.240. .LP [49] CCITT Recommendation \fIInternational Alphabet No.\ 5\fR , | Vol.\ VII, Rec.\ T.50. .LP [50] ISO Standard 646 \fIInformation processing \(em ISO 7\(hybit coded\fR \fIcharacter set for information interchange\fR . .LP [51] CCITT Recommendations on \fIIntegrated services digital network (ISDN)\fR , | Vol.\ III. .LP [52] CCITT Recommendation \fISupport of data terminal equipments (DTEs)\fR \fIwith V\(hyseries type interfaces by an integrated services digital network\fR \fI(ISDN)\fR , | Vol.\ III, Rec.\ I.463. .sp 2P .LP \fBRecommendation Q.932\fR .RT .sp 2P .sp 1P .ce 1000 \fBGENERIC\ PROCEDURES\ FOR\ THE\ CONTROL\ OF\fR | \fBISDN\ SUPPLEMENTARY\ SERVICES\fR .EF '% Fascicle\ VI.11\ \(em\ Rec.\ Q.932'' .OF '''Fascicle\ VI.11\ \(em\ Rec.\ Q.932 %' .ce 0 .sp 1P .LP \fB1\fR \fBGeneral\fR .sp 1P .RT .PP This Recommendation defines the generic procedures applicable for the control of supplementary services at the user\(hynetwork interface. These procedures may be used for the invocation and operation of supplementary services in association with existing calls or outside any existing calls. .PP 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 \(sc\ 6, to the operation of individual supplementary services will be the subject of future Recommendations in this series. .RT .sp 2P .LP \fB2\fR \fBOverview of the generic protocols and of their scope\fR .sp 1P .RT .PP Three generic protocols are defined for the control of supplementary services at ISDN user\(hynetwork 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. .RT .sp 1P .LP 2.1 \fIThree generic protocols\fR .sp 9p .RT .PP Three generic protocols are defined for the control of supplementary services, two of which are stimulus, the third being functional; these protocols are: .RT .LP \(em the Keypad protocol; .LP \(em the Feature key management protocol; .LP \(em the Functional protocol. .bp .sp 1P .LP 2.1.1 \fIKeypad protocol\fR .sp 9p .RT .PP 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]. .PP This protocol applies to supplementary service invocation in the user\(hyto\(hynetwork direction, and the keypad facility codes used for the invocation of individual supplementary services are network dependent. .PP 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. .RT .sp 1P .LP 2.1.2 \fIFeature key management protocol\fR .sp 9p .RT .PP The Feature key management protocol is based on the use of two information elements that are specified in \(sc\ 8: the Feature activation and Feature indication information elements. The Feature activation information element may be included in the SETUP and in the INFORMATION messages in the user\(hyto\(hynetwork direction. The Feature indication information element may be included in various basic call control messages in the network\(hyto\(hyuser direction. .PP This protocol typically applies to supplementary service operation during calls but also allows for non\(hycall related supplementary service control. Non\(hycall 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 information 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 subscription time. As a service provider option, more than one service profile may be allocated to an interface, but in this case the terminal identification procedures as defined in Annex\ A must be used in order to relate an appropriate service profile to a particular user. .PP \fINote\fR \ \(em\ The term \*Qservice profile\*U 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 supplementary 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. .PP 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 contained in the network and of the association of Feature keys to specific supplementary service invocations is required to unambiguously 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 \(sc\ 5. .RT .sp 1P .LP 2.1.3 \fIFunctional protocol\fR .sp 9p .RT .PP 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 \(sc\ 7. This protocol is symmetrical, and is applicable to both the basic and primary rate access structures. .PP This protocol is functional in the sense that it requires the knowledge of the related supplementary service by the user equipment 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. .PP 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. .RT .sp 1P .LP 2.2 \fISupport of the various generic protocols\fR .sp 9p .RT .PP 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 services available, and of the generic protocols supported on their access. .bp .RT .sp 1P .LP 2.3 \fICo\(hyexistence of generic protocols\fR .sp 9p .RT .PP 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 profile. .PP Networks may support one or more of the three generic protocols; it is a network option as to whether one or more generic protocols are supported on a given access. .PP In general, the Keypad protocol and Feature key management protocol have only local significance while the Functional protocol may have other than local significance. .PP 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 procedure 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 indication or notification in the network\(hyto\(hyuser direction. .RT .sp 2P .LP \fB3\fR \fBArrangements by which co\(hyexistence of protocols may be\fR \fBsupported by a network\fR .sp 1P .RT .PP 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 subscription time. .PP Networks supporting multiple generic protocols per access in the user\(hyto\(hynetwork 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. .PP Networks supporting more than one generic protocol per access in the network\(hyto\(hyuser direction (i.e.,\ at the remote user interface) 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. .PP 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 appropriate procedures for network initiated supplementary services towards the associated group of one or more terminals. .RT .sp 2P .LP \fB4\fR \fBKeypad protocol\fR .sp 1P .RT .PP 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. .PP An example of the use of the Keypad protocol is given in Appendix\ I. .RT .sp 1P .LP 4.1 \fIGeneral\fR .sp 9p .RT .PP This generic procedure is based on the use of: .RT .LP \(em the Keypad facility information element by the user to invoke a supplementary service from the network by providing access codes using either en\(hybloc or overlap sending; and .LP \(em the Display information element by the network to give an indication to the local or remote user regarding a supplementary service being invoked. This procedure may be complemented in the case of calls where the Bearer capability information element in the SETUP message is coded indicating \*Qspeech\*U or \*Q3.1\ kHz audio\*U, by the provision of in\(hyband tones/announcements to the user. .PP \fINote\fR \ \(em\ 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 standardized the use of the Keypad facility information element in the network\(hyto\(hyuser 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 \(sc\ 5.8 of Recommendation\ Q.931 of receipt of the Keypad facility information element. .bp .PP The Keypad protocol may be used in conjunction with the Feature key management (\(sc\ 5) or Functional protocol (\(sc\ 6) during the invocation of a supplementary service. .PP 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. .RT .sp 1P .LP 4.2 \fIMessages used in the Keypad protocol\fR .sp 9p .RT .PP As specified in Recommendation Q.931, the Keypad facility information element may be included in both the SETUP and INFORMATION messages and may be sent in the user\(hyto\(hynetwork direction. .RT .sp 1P .LP 4.3 \fICoding of the Keypad facility information element\fR .sp 9p .RT .PP 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. .RT .sp 2P .LP 4.4 \fIElements of procedure\fR .sp 1P .RT .sp 1P .LP 4.4.1 \fIGeneral\fR .sp 9p .RT .PP The Keypad protocol includes the following aspects: .RT .LP 1) the Keypad protocol may be used during the call establishment, active, and clearing phases of a call to invoke supplementary services. Supplementary service information is conveyed in Keypad facility information elements sent in either SETUP or INFORMATION messages; .LP 2) supplementary service information can be sent from the user to the network either en\(hybloc or using overlap sending; .LP 3) the network may prompt the user to send the required information using the Display information element and/or in\(hyband tones or announcements. Whether this action shall occur or not is supplementary service and network specific. In any case, in\(hyband tones or announcements shall only be used when the Bearer capability information element indicates \*Qspeech\*U or \*Q3.1\ kHz audio\*U; .LP 4) there may be different combinations of user provided information followed by network prompts. Examples of such possible combinations are shown in Table\ 4\(hy1/Q.932, where the term \*Qstage\*U is used to refer to information sent by the user between network prompts (if any). .ce \fBH.T. [T1.932]\fR .ce TABLE\ 4\(hy1/Q.932 .ce \fBExample of stages for sending of information\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(42p) | cw(144p) . Number of stages Sending information _ .T& cw(42p) | lw(144p) . 1 { All information sent en\(hybloc } .T& cw(42p) | lw(144p) . 1 All information sent overlap .T& cw(42p) | lw(48p) | lw(48p) | lw(48p) . 2 Overlap Prompt Overlap .T& cw(42p) | lw(48p) | lw(48p) | lw(48p) . 2 En\(hybloc Prompt En\(hybloc .T& cw(42p) | lw(48p) | lw(48p) | lw(48p) . 2 Overlap Prompt En\(hybloc .T& cw(42p) | lw(48p) | lw(48p) | lw(48p) . 2 En\(hybloc Prompt Overlap .T& cw(42p) | lw(48p) | lw(48p) | lw(48p) . 3 Overlap Prompt Overlap .T& cw(42p) | lw(48p) | lw(48p) | lw(48p) . . | | | rompt Overlap, etc. .TE .LP \fINote\fR \ \(em\ The number of possible stages is network dependent and may also be dependent on the specific supplementry service being invoked. .nr PS 9 .RT .ad r \fBTable 4\(hy1/Q.932 [T1.932], p.20\fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP 4.5 \fIProcedures at the\fR \fIinvocation interface\fR .sp 1P .RT .sp 1P .LP 4.5.1 \fIUser procedures\fR .sp 9p .RT .PP The procedures below define how information (using either en\(hybloc 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\(hyto\(hynetwork information sending. .RT .sp 1P .LP 4.5.1.1 \fIEn\(hybloc sending of access codes\fR .sp 9p .RT .PP En\(hybloc sending of supplementary service information is accomplished by sending the \*Qcomplete\*U supplementary service information in: .RT .LP \(em the SETUP message, if the supplementary service is being invoked during the call establishment; or .LP \(em the INFORMATION message, if the supplementary service is being invoked from the active phase of the call or during the clearing phase of a call. .PP The term \*Qcomplete\*U supplementary service information means that sufficient supplementary service information is sent to the network to specify a service without any additional network prompting being required. The network determines that the supplementary service information is \*Qcomplete\*U by either: .LP \(em analysis of the information contents of the Keypad facility information element; or .LP \(em the presence of a \*Qsending complete\*U indication (see Recommendation\ Q.931, \(sc\ 5.1.3). .PP 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 \(sc\ 4.5.2.3. .PP 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 \(sc\ 4.5.2.1. .RT .sp 1P .LP 4.5.1.2 \fIOverlap sending of access codes\fR .sp 9p .RT .PP Overlap sending of supplementary service information is the sending of the \*Qcomplete\*U supplementary service information (see \(sc\ 4.5.1.1 for the definition of complete) segmented such that a number of Recommendation\ Q.931 messages are used to convey the \*Qcomplete\*U supplementary service information. The possible combination of messages: .RT .LP 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 .LP b) for supplementary services invoked in the active or clearing phases of the call, consists of using two or more INFORMATION messages. .PP For case a), normal overlap sending procedures, as specified in Recommendation\ Q.931, \(sc\ 5.1.3, shall be used. .PP For case b), the transmission or receipt of INFORMATION messages shall not cause any change to the Recommendation\ Q.931 call state. .PP The network shall respond to valid supplementary service information with one of the network responses as described in \(sc\ 4.5.2.1. If the supplementary service information is invalid, then the error procedures as described in \(sc\ 4.5.2.3 shall apply. .RT .sp 2P .LP 4.5.2 \fINetwork procedures\fR .sp 1P .RT .sp 1P .LP 4.5.2.1 \fINetwork responses to user requests\fR .sp 9p .RT .PP After receiving information from the user, the network may take one of the following actions. Items\ 1)\(hy4) are applicable in the cases of both en\(hybloc and overlap sending; item\ 5) is applicable only in the case of information sent using overlap sending. .RT .LP 1) Clear the call reference via the normal call clearing procedures (see Recommendation Q.931, \(sc\ 5.3) including the appropriate Cause and optional Display information element(s). .LP 2) Send a CALL PROCEEDING message to the user. .LP \fINote\fR \ \(em\ This network response is only applicable in a case where the supplementary service is being invoked during call establishment and not in the cases of the supplementary service being invoked from the active or clearing phases of the call. .bp .LP 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. .LP 4) Prompt the user for more information using the procedures as specified in \(sc\ 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\(hyinput the original information correctly. Such procedures are network dependent and may be supplementary service specific. .LP 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 overlap information sent during other phases of the call. .PP The precise action to be taken is dependent on the specific supplementary service being invoked. .sp 1P .LP 4.5.2.2 \fINetwork prompting and in\(hyband tone/announcement control\fR .sp 9p .RT .PP The network may prompt the user for more information or may provide in\(hyband 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\(hyband tone or announcement control should occur. Possible factors governing the provision of prompting and in\(hyband information are: .RT .LP \(em the nature of the supplementary service; .LP \(em the value of the inter\(hydigit timer; .LP \(em the type of interface; and .LP \(em the current status or progress of the supplementary service request. .PP Simultaneously with the application of in\(hyband tones or announcements, the network may send a PROGRESS message containing a Progress indicator information element with the progress descriptor No.\ 8, \fIIn\(hyband\fR \fIinformation or appropriate pattern now available\fR . .PP 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 information elements (but shall not contain the Called party number information element). .PP 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\(hyinitialized. .PP 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 situations where a user's response could be related to two unacknowledged network prompts. .PP \fINote\fR \ \(em\ As a network option, the Information Request procedures described in Annex\ B of this Recommendation may be used to prompt the user for additional information related to a given service request. .RT .sp 1P .LP 4.5.2.3 \fIError conditions and treatment\fR .sp 9p .RT .PP An error condition exists in the following circumstances: .RT .LP a) timer T302 expires and complete information has not been received; .LP b) information containing a \*Qsending complete\*U indication indicating en\(hybloc sending, but the user information sent is not complete; .LP 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; .LP d) the user attempts to invoke a supplementary service to which the user has not subscribed or to which the user is not allowed access. .PP The action to be taken by the network in these situations is as follows. .PP \fINote\fR \ \(em\ 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. .bp .RT .sp 1P .LP 4.5.2.3.1 \fISupplementary service being invoked during call\fR \fIestablishment\fR .sp 9p .RT .PP The network shall take one of the following actions: .RT .LP i) In\(hyband 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\(hychannel to be used and including the Progress indicator information element with progress descriptor No.\ 8, \fIIn\(hyband\fR \fIinformation or appropriate pattern is now available\fR . .LP 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, \fIIn\(hyband information or appropriate pattern\fR \fIis now available\fR . .LP The network may prompt the user using the procedures as specified in \(sc\ 4.5.2.2 to re\(hyinput the required information. Otherwise, after the in\(hyband 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, \(sc\ 5.3. .LP ii) No in\(hyband tones or announcements are to be applied. The call reference shall be cleared by the network initiating call clearing procedures as specified in Recommendation\ Q.931, \(sc\ 5.3. .sp 1P .LP 4.5.2.3.2 \fISupplementary service being invoked from the active\fR \fIstate or during the call clearing phase\fR .sp 9p .RT .PP The network shall take one of the following actions: .RT .LP i) In\(hyband tones or announcements are applied. The network may prompt the user using the procedures as specified in \(sc\ 4.5.2.2 to re\(hyinput 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\(hyband 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, \(sc\ 5.3. .LP ii) No in\(hyband 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, \(sc\ 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 \(sc\ 4.5.2.1, item\ 3). .sp 1P .LP 4.6 \fIProcedures at the remote interface\fR .sp 9p .RT .PP 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 equipment itself. .RT .sp 2P .LP \fB5\fR \fBFeature key management protocol\fR .sp 1P .RT .PP 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 themselves, 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 procedures. .PP The Feature key management protocol is based on two information 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 information 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. .bp .PP Feature indication is the means by which a response to a feature activation is indicated by the network. The feature identifier 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 indicator. The status indicator indicates the status of the requested service and may be used by the user's equipment as appropriate with its man\(hymachine interface. .RT .sp 1P .LP 5.1 \fIMessages\fR .sp 9p .RT .PP The Feature activation and Feature indication information elements 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\(hyto\(hynetwork direction: .RT .LP a) SETUP .LP b) INFORMATION. .PP The Feature indication information element may be sent in the network\(hyto\(hyuser direction in the following messages: .LP a) SETUP .LP b) SETUP ACKNOWLEDGE .LP c) CONNECT .LP d) CALL PROCEEDING .LP e) ALERTING .LP f ) INFORMATION .LP g) DISCONNECT .LP h) RELEASE .LP i) RELEASE COMPLETE. .sp 2P .LP 5.2 \fIProcedures\fR .sp 1P .RT .sp 1P .LP 5.2.1 \fIAssumptions and restrictions\fR .sp 9p .RT .LP a) These procedures assume that only one Feature activation request will appear in a message. .LP b) The phrase \*Qcall associated services\*U used herein is defined as services which act upon or relate to an existing call (as defined by the existence of a call reference). .LP 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. .sp 1P .LP 5.2.2 \fIInvocation of supplementary services\fR .sp 9p .RT .PP The user may request a feature by including a Feature activation information element in the messages defined in \(sc\ 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. .RT .sp 1P .LP 5.2.2.1 \fIDetermination of call reference in the INFORMATION message\fR .sp 9p .RT .PP When the Feature activation information element is sent in the INFORMATION message, then the following rules apply: .RT .LP a) if no call references exist, then the dummy call reference must be used (for this non\(hycall associated service type); .LP 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\(hycall associated; .LP c) if a call reference(s) has been established, the dummy call reference may be used only if the service type is non\(hycall 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. .bp .PP This is summarized in Figure 5\(hy1/Q.932. .LP .rs .sp 13P .ad r \fBFigure 5\(hy1/Q.931 [T2.932] \ \ (\*`a traiter comme tableau), p.21\fR .sp 1P .RT .ad b .RT .PP 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. .sp 1P .LP 5.2.3 \fINetwork responses\fR .sp 9p .RT .PP The network may respond to a Feature activation request in several ways. This action will be supplementary service and network specific. .RT .sp 2P .LP 5.2.3.1 \fINormal responses\fR .sp 1P .RT .sp 1P .LP 5.2.3.1.1 \fIReturn of a Feature indication\fR .sp 9p .RT .PP The network may return a Feature indication information element in an INFORMATION message or any other appropriate call control message as defined in \(sc\ 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. .RT .sp 1P .LP 5.2.3.1.2 \fIPrompting for further information\fR .sp 9p .RT .PP 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). .PP The user's response shall follow normal overlap sending procedures 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 information related to a given service request. .RT .sp 1P .LP 5.2.3.1.3 \fIImplicit response\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 5.2.3.1.4 \fIReturn of Signal, Cause, or Display information elements\fR .sp 9p .RT .PP The network may return any combination of Signal, Cause, or Display information elements in conjunction with the responses as described in \(sc\ 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. .bp .RT .sp 1P .LP 5.2.3.2 \fIResponses during error conditions\fR .sp 9p .RT .PP When an error condition exists (as defined in \(sc\ 5.2.5), the network may: .RT .LP a) Respond with one or more of the following options: .LP 1) return a Feature indication information element; .LP 2) prompt for further information (see Annex B); .LP 3) provide an implicit response; or .LP 4) return Signal, Cause, or Display information elements. .LP b) Ignore the Feature activation request and not respond at all. .LP c) Clear appropriate existing calls in conjunction with the above actions. .sp 2P .LP 5.2.4 \fIGeneral aspects\fR .sp 1P .RT .sp 1P .LP 5.2.4.1 \fIUse of Feature indication information elements independent\fR \fIof a feature request\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 5.2.4.2 \fIDeactivation procedures\fR .sp 9p .RT .PP When explicitly deactivating a supplementary service, two methods may be used: .RT .LP a) sending of a feature activation request with the same feature identifier may deactivate the supplementary service. Some supplementary services may be \*Qtoggled\*U on and off; .LP 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 supplementary service. .sp 1P .LP 5.2.4.3 \fIClearing of a call\fR .sp 9p .RT .PP 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 information element is to be returned, then one of the following options may be used: .RT .LP a) the network may send a Feature indication information element in one of the call clearing messages (i.e., DISCONNECT, RELEASE, or RELEASE COMPLETE); .LP b) the network may send a Feature indication information element in an INFORMATION message after clearing has occurred using the dummy call reference. .sp 2P .LP 5.2.5 \fIError conditions\fR .sp 1P .RT .sp 1P .LP 5.2.5.1 \fIInvalid feature activation request\fR .sp 9p .RT .PP If a user requests a feature using an invalid feature identifier number, the network may take actions specified in \(sc\ 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). .RT .sp 1P .LP 5.2.5.2 \fIInvalid call reference\fR .sp 9p .RT .PP If a user violates the use of the call reference as stated in \(sc\ 5.2.2.1, the network should not provide the service and should respond as indicated in \(sc\ 5.2.3.2. .RT .sp 1P .LP 5.2.5.3 \fISending of multiple feature activation requests\fR .sp 9p .RT .PP 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 following actions: .RT .LP a) act upon all feature activation requests by returning multiple Feature indication information elements (or other responses as detailed in \(sc\ 5.2.3.1). These may be sent in a single message or in multiple messages; .bp .LP 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. .PP The determination of which action to take is network and supplementary service specific. .LP \fB6\fR \fBFunctional protocol\fR .sp 1P .RT .sp 2P .LP 6.1 \fIGeneral\fR .sp 1P .RT .sp 1P .LP 6.1.1 \fIIntroduction\fR .sp 9p .RT .PP This section specifies the functional signalling procedures for the control of supplementary services at the user\(hynetwork 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]. .RT .sp 1P .LP 6.1.2 \fIScope of the procedures\fR .sp 9p .RT .PP The procedures defined in \(sc\ 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\(hynetwork interface is a basic or primary rate interface. .RT .sp 1P .LP 6.1.3 \fICategories of procedures\fR .sp 9p .RT .PP 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. .PP 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. .PP Both categories are specified in a symmetrical manner and can be signalled both in the network\(hyto\(hyuser and the user\(hyto\(hynetwork directions. .RT .sp 1P .LP 6.1.4 \fISupplementary service functions\fR .sp 9p .RT .PP The control of supplementary services by either the network or the user includes the following cases: .RT .LP a) the invocation of supplementary services during the establishment of a call; .LP b) the invocation of supplementary services during the clearing of a call; .LP c) the invocation of call related supplementary services during the active state of a call; .LP d) the invocation or registration of supplementary services independent from an active call; .LP e) the invocation of multiple, different supplementary services within a single message; .LP f ) the invocation of supplementary services related to different calls; .LP g) cancellation of invoked supplementary services and notification to the initiator of the supplementary service. .PP 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]. .PP 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 information element and the invoke identifier present within the Facility information element itself [refer to cases\ d), e) and\ g)]. .PP The identification of different supplementary service invocations within one single message is provided by the invoke identifier of the corresponding Facility information element [refer to cases\ e) and\ g)]. The identification of supplementary service invocations related to different calls is provided by different messages 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. .bp .RT .sp 1P .LP 6.2 \fISeparate messages category\fR .sp 9p .RT .PP 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 synchronization of the peer\(hyto\(hypeer state machines. Therefore, these functions cannot be performed in conjunction with the call establishment and clearing procedures but may be used in conjunction with various supplementary services. The functions of these messages are not to be duplicated or overlapped by those of the Facility information element. .PP The following individual messages are defined: .RT .LP HOLD .LP HOLD ACKNOWLEDGE .LP HOLD REJECT .LP RETRIEVE .LP RETRIEVE ACKNOWLEDGE .LP RETRIEVE REJECT. .sp 1P .LP 6.2.1 \fIHold and Retrieve functions\fR .sp 9p .RT .PP 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\(hychannel in use (if any) or any other B\(hychannel (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. .PP As an option, based on a subscription arrangement between the user and the service provider, the B\(hychannel may be released for subsequent re\(hyuse by the network for another call. .PP 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\(hychannel allocated to the call in progress or active when putting that call in the Call Held auxiliary state. .PP \fINote\ 1\fR \ \(em\ Generally, only one B\(hychannel is reserved for each user having put one (or more) call(s) on hold. However, as a subscription option, a network may reserve more than one B\(hychannel to a user. .PP \fINote\ 2\fR \ \(em\ Enhancements to the procedures may be required for users requesting the non\(hyreservation of the B\(hychannel, on a per call basis. .PP The HOLD ACKNOWLEDGE message puts the call in the held auxiliary 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, \fIFacility rejected\fR , or No.\ 50, \fIRequested facility not subscribed\fR , or No.\ 69, \fIRequested facility\fR \fInot implemented\fR . .PP The Retrieve function reconnects the user to the requested B\(hychannel. The RETRIEVE message requests that a call be retrieved. The RETRIEVE ACKNOWLEDGE message indicates that the Retrieve function 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, \fIRequested channel not available\fR , or No.\ 34, \fIno channel available\fR . .PP The HOLD and RETRIEVE families of message may be used in a symmetrical manner. .RT .sp 1P .LP 6.2.2 \fIHold procedures\fR .sp 9p .RT .PP The Hold function should be invoked in association with an existing call (i.e.,\ during the establishment or active phase of a call). .PP The invocation of the Hold function does not affect the existing 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 acknowledge 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. .bp .RT .sp 1P .LP 6.2.3 \fIRetrieve procedures\fR .sp 9p .RT .PP The Retrieve function is requested by sending a RETRIEVE message. This message may be sent while the auxiliary state is in the Call Held state. .PP The RETRIEVE message may indicate a preferred, any, or exclusive channel. Procedures for the use of the Channel identification 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. .PP If the Retrieve request is successful, the RETRIEVE ACKNOWLEDGE message will be returned with the selected B\(hychannel indicated. 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. .PP 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. .RT .sp 1P .LP 6.2.4 \fIAuxiliary states for hold and retrieve\fR .sp 9p .RT .PP 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 synchronization between the user and the network. This concept suggests 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. .PP There are four auxiliary states associated with the Hold and Retrieve functions: .RT .LP i) Idle; .LP ii) Hold Request \(em A request has been made for the Hold function; .LP iii) Call Held \(em The call is held; .LP iv) Retrieve Request \(em A request has been made for the Retrieve function. .sp 1P .LP 6.2.5 \fIAn example of dimensioned state space\fR .sp 9p .RT .PP Suppose a call is in the Outgoing Call Proceeding state. The dimensioned state space would be: .RT .sp 1P .ce 1000 (Outgoing Call Proceeding, Idle) .ce 0 .sp 1P .PP Now the user requests the Hold function. The dimensioned state space would become: .sp 1P .ce 1000 (Outgoing Call Proceeding, Hold Request) .ce 0 .sp 1P .PP 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: .sp 1P .ce 1000 (Outgoing Call Proceeding, Call Held) .ce 0 .sp 1P .PP The user may receive subsequent call progress messages changing the dimensioned state space to: .sp 1P .ce 1000 (Active, Call Held) .ce 0 .sp 1P .PP Now the user requests the Retrieve function. The dimensioned state space would become: .sp 1P .ce 1000 (Active, Retrieve Request) .ce 0 .sp 1P .PP When a call is reconnected, the dimensioned state space would be: .sp 1P .ce 1000 (Active, Idle) .ce 0 .sp 1P .LP 6.3 \fICommon information element category\fR .sp 9p .RT .PP The Common information element category applies only to supplementary 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\(hynetwork and NT2\(hyNT2 applications. .bp .PP A REGISTER, a FACILITY or an existing Recommendation Q.931 call control message is used to carry the Facility information element which requests the desired supplementary service. .PP This functional procedure provides a flexible and open ended approach to the provision of supplementary service protocols and: .RT .LP \(em allows new services to be easily introduced; .LP \(em allows multiple supplementary service invocations within one message; .LP \(em supports supplementary services with a large number of variants without a proliferation of new messages; .LP \(em supports non\(hycall associated supplementary services. .PP 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 providing improved stability to the basic call control procedures of Recommendation\ Q.931. .sp 1P .LP 6.3.1 \fICall related supplementary service procedures\fR .sp 9p .RT .PP For call related supplementary service procedures initiated at call establishment or call clearing, the procedures for call control as specified in \(sc\(sc\ 5 and\ 6 of Recommendation\ Q.931 are utilized. 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 supplementary service contained in an outgoing SETUP message, then the following options apply: .RT .LP 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 element and a return error or reject component type with the appropriate parameters in the Facility information element; .LP 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 appropriate data element in the Facility information element by means of a FACILITY message or in any appropriate Recommendation\ Q.931 message; .LP 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. .PP The option to be used depends on the individual supplementary service procedures, which are the subject of other Recommendations. .PP 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. .PP 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. .PP 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. .PP Depending upon the supplementary service invoked, one of the following will occur: .RT .LP \(em the network or user may retain both the connection 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 .LP \(em 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). .bp .sp 1P .LP 6.3.2 \fICall independent supplementary service procedures\fR .sp 9p .RT .PP 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 establishment of the signalling connection by transferring a REGISTER message across the user\(hynetwork interface. This signalling connection is identified by the call reference associated with the REGISTER 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. .PP Examples of message exchange for supplementary service control for various scenarios is described by means of arrow diagrams in Appendix\ I. .PP 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 component). One of the following will occur: .RT .LP 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 subsequently 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 contain the Facility information element. .LP 2) If the content of the Facility information element is not understood, then a FACILITY message or a RELEASE COMPLETE 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\(hysent in another FACILITY message or the request can be cleared and the call reference value released with a RELEASE COMPLETE message. .LP 3) If the content of the Facility information element 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 component return error. When the rejection has been returned in a FACILITY message, the Facility information element can be re\(hysent in another FACILITY message or the request can be cleared and the call reference value released with a RELEASE COMPLETE message. .sp 1P .LP 6.3.3 \fIResponses to multiple supplementary service invocations\fR .sp 9p .RT .PP The possible correlation of responses to multiple supplementary service invocations is the subject of future Recommendations. .RT .sp 1P .LP 6.3.4 \fICoding of the call reference\fR .sp 9p .RT .PP For general rules, format and coding of call reference values, \(sc\ 4.3 of Recommendation Q.931 is applicable. For the functional supplementary service control, the dummy call reference is not applicable. .RT .sp 2P .LP \fB7\fR \fBMessage functional definitions and content\fR .sp 1P .RT .PP This section should be read in conjunction with \(sc\ 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 \(sc\ 3 of Recommendation\ Q.931. .RT .sp 1P .LP 7.1 \fIMessages for supplementary service control\fR .sp 9p .RT .PP Table\ 7\(hy1/Q.932 summarizes the messages specific to supplementary service control procedures. .bp .RT .ce \fBH.T. [T3.932]\fR .ce TABLE\ 7\(hy1/Q.932 .ce \fBMessages specific to supplementary service .ce control\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | cw(42p) . Reference _ .T& lw(90p) | cw(42p) . FACILITY 7.1.1 .T& lw(90p) | cw(42p) . HOLD 7.1.2 .T& lw(90p) | cw(42p) . HOLD ACKNOWLEDGE 7.1.3 .T& lw(90p) | cw(42p) . HOLD REJECT 7.1.4 .T& lw(90p) | cw(42p) . REGISTER 7.1.5 .T& lw(90p) | cw(42p) . RETRIEVE 7.1.6 .T& lw(90p) | cw(42p) . RETRIEVE ACKNOWLEDGE 7.1.7 .T& lw(90p) | cw(42p) . RETRIEVE REJECT 7.1.8 _ .TE .nr PS 9 .RT .ad r \fBTable 7\(hy1/Q.932 [T3.932], p.22\fR .sp 1P .RT .ad b .RT .sp 1P .LP 7.1.1 \fIFACILITY\fR .sp 9p .RT .PP This message may be sent to request or acknowledge a supplementary service. The supplementary service to be invoked, and its associated parameters, are specified in the Facility information element (see Table\ 7\(hy2/Q.932). .PP For the use of this message, see \(sc 6. .RT .ce \fBH.T. [T4.932]\fR .ce TABLE\ 7\(hy2/Q.932 .ce \fBFACILITY message content\fR .ce Message type:\ FACILITY .ce Significance:\ local (Note 1) .ce Direction:\ both .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Facility 8.2/Q.932 both M 8 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Display 4.5/Q.931 n \(ra | O (Note 2) (Note 3) .TE .LP M\ Mandatory .LP O\ Optional .LP \fINote\ 1\fR \ \(em\ This message has local significance; however, it may carry information of global significance. .LP \fINote\ 2\fR \ \(em\ Included if the network provides information that can be presented to the user. .LP \fINote\ 3\fR \ \(em\ The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82\ octets. .nr PS 9 .RT .ad r \fBTable 7\(hy2/Q.932 [T4.932], p.23\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 7.1.2 \fIHOLD\fR .sp 9p .RT .PP This message is sent by the network or the user to request the hold function for an existing call (see Table\ 7\(hy3/Q.932). .PP For the use of this message, see \(sc 6. .RT .ce \fBH.T. [T5.932]\fR .ce TABLE\ 7\(hy3/Q.932 .ce \fBHOLD message content\fR .ce Message type:\ HOLD .ce Significance:\ local .ce Direction:\ both .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Display 4.5/Q.931 n \(ra | O (Note 1) (Note 2) .TE .LP \fINote\ 1\fR \ \(em\ Included if the network provides information that can be presented to the user. .LP \fINote\ 2\fR \ \(em\ The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82\ octets. .nr PS 9 .RT .ad r \fBTableau 7\(hy3/Q.932 [T5.932], p.24\fR .sp 1P .RT .ad b .RT .LP .rs .sp 25P .ad r Blanc .ad b .RT .LP .bp .sp 1P .LP 7.1.3 \fIHOLD ACKNOWLEDGE\fR .sp 9p .RT .PP This message is sent by the network or the user to indicate that the hold function has been successfully performed (see Table\ 7\(hy4B/FQ.932). .PP For the use of this message, see \(sc 6. .RT .ce \fBH.T. [T6.932]\fR .ce TABLE\ 7\(hy4/Q.932 .ce \fBHOLD ACKNOWLEDGE message content\fR .ce Message type:\ HOLD ACKNOWLEDGE .ce Significance:\ local .ce Direction:\ both .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Display 4.5/Q.931 n \(ra | O (Note 1) (Note 2) .TE .LP \fINote\ 1\fR \ \(em\ Included if the network provides information that can be presented to the user. .LP \fINote\ 2\fR \ \(em\ The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82\ octets. .nr PS 9 .RT .ad r \fBTableau 7\(hy4/Q.932 [T6.932], p.25\fR .sp 1P .RT .ad b .RT .LP .rs .sp 25P .ad r Blanc .ad b .RT .LP .bp .sp 1P .LP 7.1.4 \fIHOLD REJECT\fR .sp 9p .RT .PP This message is sent by the network or the user to indicate the denial of a request to hold a call (see Table\ 7\(hy5/Q.932). .PP For the use of this message, see \(sc 6. .RT .ce \fBH.T. [T7.932]\fR .ce TABLE\ 7\(hy5/Q.932 .ce \fBHOLD REJECT message content\fR .ce Message type:\ HOLD REJECT .ce Significance:\ local .ce Direction:\ both .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Cause 4.5/Q.931 both M 4 | (hy | 2 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Display 4.5/Q.931 n \(ra | O (Note 1) (Note 2) .TE .LP \fINote\ 1\fR \ \(em\ Included if the network provides information that can be presented to the user. .LP \fINote\ 2\fR \ \(em\ The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82\ octets. .nr PS 9 .RT .ad r \fBTableau 7\(hy5/Q.932 [T7.932], p.26\fR .sp 1P .RT .ad b .RT .LP .rs .sp 22P .ad r Blanc .ad b .RT .LP .bp .sp 1P .LP 7.1.5 \fIREGISTER\fR .sp 9p .RT .PP This message is sent by the user or the network to assign a new call reference for non\(hycall associated transactions (see Table\ 7\(hy6/Q.932). .PP For the use of this message, see \(sc 6. .RT .ce \fBH.T. [T8.932]\fR .ce TABLE\ 7\(hy6/Q.932 .ce \fBREGISTER message content\fR .ce Message type:\ REGISTER .ce Significance:\ local (Note 1) .ce Direction:\ both .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Facility 8.2/Q.932 both O (Note 4) 2 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Display 4.5/Q.931 n \(ra | O (Note 2) (Note 3) .TE .LP \fINote\ 1\fR \ \(em\ This message has local significance; however, it may carry information of global significance. .LP \fINote\ 2\fR \ \(em\ Included if the network provides information that can be presented to the user. .LP \fINote\ 3\fR \ \(em\ The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82\ octets. .LP \fINote\ 4\fR \ \(em\ Included if the network or the user provides supplementary service information. .nr PS 9 .RT .ad r \fBTableau 7\(hy6/Q.932 [T8.932], p.27\fR .sp 1P .RT .ad b .RT .LP .rs .sp 20P .ad r Blanc .ad b .RT .LP .bp .sp 1P .LP 7.1.6 \fIRETRIEVE\fR .sp 9p .RT .PP This message is sent by the network or the user to request the retrieval of a held call (see Table\ 7\(hy7/Q.932). .PP For the use of this message, see \(sc 6. .RT .ce \fBH.T. [T9.932]\fR .ce TABLE\ 7\(hy7/Q.932 .ce \fBRETRIEVE message content\fR .ce Message type:\ RETRIEVE .ce Significance:\ local .ce Direction:\ both .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Channel identification 4.5/Q.931 both O (Note 1) 2 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Display 4.5/Q.931 n \(ra | O (Note 2) (Note 3) .TE .LP \fINote\ 1\fR \ \(em\ If not included, its absence is interpreted as any channel acceptable. .LP \fINote\ 2\fR \ \(em\ Included if the network provides information that can be presented to the user. .LP \fINote\ 3\fR \ \(em\ The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82 octets. .nr PS 9 .RT .ad r \fBTableau 7\(hy7/Q.932 [T9.932], p.28\fR .sp 1P .RT .ad b .RT .LP .rs .sp 21P .ad r Blanc .ad b .RT .LP .bp .sp 1P .LP 7.1.7 \fIRETRIEVE ACKNOWLEDGE\fR .sp 9p .RT .PP This message is sent by the network or the user to indicate that the retrieve function has been successfully performed (see Table\ 7\(hy8/Q.932). .PP For the use of this message, see \(sc 6. .RT .ce \fBH.T. [T10.932]\fR .ce TABLE\ 7\(hy8/Q.932 .ce \fBRETRIEVE ACKNOWLEDGE message content\fR .ce Message type:\ RETRIEVE ACKNOWLEDGE .ce Significance:\ local .ce Direction:\ both .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Channel identification 4.5/Q.931 both O (Note 1) 2 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Display 4.5/Q.931 n \(ra | O (Note 2) (Note 3) .TE .LP \fINote\ 1\fR \ \(em\ Mandatory in all cases except when the sender accepts the specific B\(hychannel indicated in the RETRIEVE message. If included, a channel is indicated and specified as exclusive. .LP \fINote\ 2\fR \ \(em\ Included if the network provides information that can be presented to the user. .LP \fINote\ 3\fR \ \(em\ The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82\ octets. .nr PS 9 .RT .ad r \fBTableau 7\(hy8/Q.932 [T10.932], p.29\fR .sp 1P .RT .ad b .RT .LP .rs .sp 20P .ad r Blanc .ad b .RT .LP .bp .sp 1P .LP 7.1.8 \fIRETRIEVE REJECT\fR .sp 9p .RT .PP This message is sent by the network or the user to indicate the inability to perform the requested retrieve function (see Table\ 7\(hy9/Q.932). .PP For the use of this message, see \(sc 6. .RT .ce \fBH.T. [T11.932]\fR .ce TABLE\ 7\(hy9/Q.932 .ce \fBRETRIEVE REJECT message content\fR .ce Message type:\ RETRIEVE REJECT .ce Significance:\ local .ce Direction:\ both .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Cause 4.5/Q.931 both M 4 | (hy | 2 _ .T& lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Display 4.5/Q.931 n \(ra | O (Note 1) (Note 2) .TE .LP \fINote\ 1\fR \ \(em\ Included if the network provides information that can be presented to the user. .LP \fINote\ 2\fR \ \(em\ The minimum length is 2 octets. The maximum length is network dependent and is either 34 or 82 octets. .nr PS 9 .RT .ad r \fBTableau 7\(hy9/Q.932 [T11.932], p.30\fR .sp 1P .RT .ad b .RT .LP .rs .sp 22P .ad r Blanc .ad b .RT .LP .bp