delim @@
|
| 5i' |
||
|
APPENDIX II 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 channel 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 interface 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 Fascicle VI.11 -- Rec. Q.931 1 |
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 UI I DISC Layer |
Unnumbered acknowledgement frame Unnumbered information frame (i.e. using unacknowledged information transfer at layer 2) Information frame Disconnect frame 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.
2 Fascicle VI.11 -- Rec. Q.931
|
II.1.2 |
Example message flow diagrams |
Figure Fascicle VI.11 -- Rec. Q.931 |
Figure II-1/Q.931, p.1 3 |
Figure II-2/Q.931, p.2 4 Fascicle VI.11 -- Rec. Q.931
Figure II-3/Q.931, p.3 Fascicle VI.11 -- Rec. Q.931 5
Figure II-4/Q.931, p.4 6 Fascicle VI.11 -- Rec. Q.931
Figure II-5/Q.931, p.5 Fascicle VI.11 -- Rec. Q.931 7
Figure II-6/Q.931, p.6 8 Fascicle VI.11 -- Rec. Q.931
|
II.2 |
Example conditions for cause mapping |
Figure II-7/Q.931, p.7 |
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 |
Fascicle VI.11 -- Rec. Q.931 9 |
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. 10 Fascicle VI.11 -- Rec. Q.931
Figure II-8/Q.931, p.8
Figure II-9/Q.931, p.9
Figure II-10/Q.931, p.10 Fascicle VI.11 -- Rec. Q.931 11
|
Figure II-11/Q.931, p.11 Figure II-12/Q.931, p.12 |
12 Fascicle VI.11 -- Rec. Q.931
|
Figure II-13/Q.931, p.13 Figure II-14/Q.931, p.14 |
Fascicle VI.11 -- Rec. Q.931 13
|
Figure II-15/Q.931, p.15 Figure II-16/Q.931, p.16 |
14 Fascicle VI.11 -- Rec. Q.931
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
center box; lw(60p) | cw(96p) | lw(42p) .
{ Bits 8 7 6 5 4 3 2 1
|
} Recommendation reference |
_ lw(60p) | lw(96p) | lw(42p) . |
lw(198p) . |
|||
|
Tableau Fascicle VI.11 -- Rec. |
Tableau III-1 [T198.931], p.17 Q.931 15 |
H.T. [T199.931]
TABLE III-2/Q.931
Message type code points
center box; lw(60p) | cw(120p) | lw(48p) .
|
{ Bits 8 7 6 5 4 3 2 1 } Recommendation reference |
_ lw(60p) | lw(120p) | lw(48p) . |
||
|
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 |
|||
|
center box; lw(66p) | lw(114p) . |
{ 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 |
|||
|
16 Fascicle |
VI.11 -- Rec. Q.931 |
|
English ABM ACK |
French ABM ACK |
ACRONYMS USED IN RECOMMENDATION Q.931 Spanish Meaning ABM Asynchronous Balanced Mode (of HDLC) ACU Acknowledgement |
ADPCM MICDA MICDA Adaptative Differential Pulse Code Modulation
|
AFI ARM AU BC BCD Bi Bi` Bj CEI CES |
AFI IAF Authority and Format Identifier ARM ARM Asynchronous Response Mode (of HDLC) AU UA Access Unit MFS CP Bearer Capability BCD DCB Binary Coded Decimal Bi Bi Indicated B Channel Bi` Bi` An idle B Channel Bi Bj Bj A B Channel in use CEI IPEC Connection Endpoint Identifier 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 Identifier (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 Organization 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 |
Fascicle VI.11 -- Rec. Q.931 17
LLC CCI CCB Low Layer Compatibility
|
LLI NACK NIC NRM NSAP NT2 OSI PABX PCM |
LLI IEL Logical Link Identifier (See Recommendation Q.921) NACK ACUN Negative Acknowledgement NIC RIR Network Independent Clock NRM NRM Normal Response Mode (of HDLC) NSAP PASR Network Service Access Point NT2 TR2 Network Termination of type two OSI ISA Open System Interconnection PABX CAP Private Automatic Branch Exchange MIC MIC Pulse Code Modulation |
18 Fascicle VI.11 -- Rec. Q.931
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 |
Extended (frame) |
|
SAPI SAPI IPAS Service Access Point Identifier (See Recommendation TA AT AT Terminal Adaptor (See Recommendation I.411) TE1 TE1 ET1 Terminal Equipment of type 1 (See Recommendation I.411) |
Q.921) I.411) |
|
TE2 TE2 ET2 Terminal Equipment of type 2 (See Recommendation TEI TEI IET Terminal Endpoint Identifier (See Recommendations Q.920 UDI UDI IDSR Unrestricted Digital Information UI UI UI Unnumbered Information (frame) VC CV CV (Switched) Virtual Circuit |
I.411) Q.920 and Q.921) |
|
References |
||
|
[1] [2] [3] [4] [5] |
CCITT Recommendation ISDN user-network interface layer 3 -- General aspects , | ol. VI(III), Rec. Q.930(I.450). CCITT Recommendation ISDN user-network interfaces -- Interface structures and access capabilities , | ol. III, Rec. I.412. CCITT Recommendation ISDN user-network interface -- Data link layer specification , | ol. VI(III), Rec. Q.921(I.441). CCITT Recommendation Generic procedures for the control of ISDN supplementary services , | ol. VI, Rec. Q.932. 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] [7] network [8] |
CCITT Recommendation Circuit mode bearer service categories , | Vol. III, Rec. I.231. CCITT Recommendation Support of data terminal equipments (DTEs) with V-series type interfaces by an integrated services digital (ISDN) , Vol. VIII, Rec. V.110. 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 terminal equipment with V-series type interfaces with provision for statistical multiplexing , | Vol. VIII, Rec. V.120.
|
[10] [11] [12] [13] [14] [15] |
CCITT Recommendation Pulse code modulation (PCM) of voice frequencies , | Vol. III, Rec. G.711. CCITT Recommendation 32 kbitB/Fs adaptive differential pulse code modulation (ADPCM) , | Vol. III, Rec. G.721. CCITT Recommendation 7 kHz audio coding within 64 kbit/s , | Vol. III, Rec. G.722. CCITT Recommendation Codec for audiovisual services AT n × 384 kbit/s , | Vol. III, Rec. H.261. CCITT Recommendation Support of packet mode terminal equipment by an ISDN , | ol. VIII, Rec. X.31. CCITT Recommendation Multiplexing rate adaptation and support of existing interfaces , | Vol. III, Rec. I.460. Fascicle VI.11 -- Rec. Q.931 |
19 |
[16] CCITT Recommendation Standardization of data signalling 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] [19] [20] [21] [22] [23] |
CCITT Recommendation ISDN numbering and addressing principles , | Vol. III, Rec. I.330. CCITT Recommendation Numbering plan for the ISDN era , | Vol. II, Rec. E.164. CCITT Recommendation Numbering plan for the international telephone service , | Vol. III, Rec. E.163. CCITT Recommendation International numbering plan for public data networks , | Vol. VIII, Rec. X.121. CCITT Recommendation Plan for telex destination codes , | Vol. II, Rec. F.69. 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] [28] [29] [30] |
CCITT Recommendation Primary rate user-network interface -- Layer 1 specification , | Vol. III, Rec. I.431. CCITT Recommendation Control procedures for teletex and Group 4 facsimile services , | Vol. VII, Rec. T.62. CCITT Recommendation A document application profile for the interchange of Group 4 facsimile documents , | Vol. VII, Rec. T.503. 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 , Rec. T.502. [32] CCITT Recommendation Network-independent basic transport 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 . |
| |
Vol. VII, |
[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 procedures
[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 20 Fascicle VI.11 -- Rec. Q.931
|
[42] [43] service . [44] |
ISO Standard 8348 Information processing systems -- Data communications -- Network service definition . ISO Standard 8473 Information processing systems -- Data communications protocol for providing the connectionless-mode network 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] [46] [47] [48] [49] [50] [51] [52] |
CCITT Recommendation ISDN user-network interface data link layer -- General aspects , | Vol. VI(III), Rec. Q.920(I.440). CCITT Recommendation Basic user-network interface -- Layer 1 specification , | Vol. III, Rec. I.430. CCITT Recommendation Definition of bearer service categories , | Vol. III, Rec. I.230. CCITT Recommendation Definition of teleservices , | Vol. III, Rec. I.240. CCITT Recommendation International Alphabet No. 5 , | Vol. VII, Rec. T.50. ISO Standard 646 Information processing -- ISO 7-bit coded character set for information interchange . CCITT Recommendations on Integrated services digital network (ISDN) , | Vol. III. CCITT Recommendation Support of data terminal equipments (DTEs) with V-series type interfaces by an integrated services digital |
network (ISDN) , | Vol. III, Rec. I.463.
GENERIC PROCEDURES FOR THE CONTROL OF |
ISDN SUPPLEMENTARY SERVICES
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 § 6, to the operation of individual supplementary services will be the subject of future Recommendations in this series.
Three generic protocols are defined for the control of supplementary 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 supplementary services, two of which are stimulus, the third being functional; these protocols are:
-- the Keypad protocol;
Fascicle VI.11 -- Rec. Q.932 21
-- the Feature key management protocol;
-- the Functional protocol.
22 Fascicle VI.11 -- Rec. Q.932
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 § 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-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 supplementary 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 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.
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 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.
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 § 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 § 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 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.
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 services available, and of the generic protocols supported on their access.
Fascicle VI.11 -- Rec. Q.932 23
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 profile.
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.
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 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-to-user direction.
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.
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 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.
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.
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 providing 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 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 ``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 standardized 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 24 Fascicle VI.11 -- Rec. Q.932
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 § 5.8 of Recommendation Q.931 of receipt of the Keypad facility information element.
Fascicle VI.11 -- Rec. Q.932 25
The Keypad protocol may be used in conjunction with the Feature key management (§ 5) or Functional protocol (§ 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 INFORMATION 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 4.4.1 |
Elements of procedure 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 supplementary |
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 sending;
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 provided 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
center box; cw(42p) | cw(144p) . Number of stages Sending information _ cw(42p) | lw(144p) . 1 { All information sent en-bloc
|
} cw(42p) | lw(144p) . 1 All information sent overlap cw(42p) | lw(48p) | lw(48p) | lw(48p) . 2 Overlap Prompt lw(48p) | lw(48p) | lw(48p) . 2 En-bloc Prompt En-bloc cw(42p) | lw(48p) | lw(48p) | lw(48p) . 2 Overlap cw(42p) | lw(48p) | lw(48p) | lw(48p) . 2 En-bloc Prompt Overlap cw(42p) | lw(48p) | lw(48p) | lw(48p) . 3 Overlap cw(42p) | lw(48p) | lw(48p) | lw(48p) . . | | | rompt Overlap, etc. |
Overlap cw(42p) | Prompt En-bloc Overlap Prompt |
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 26 Fascicle VI.11 -- Rec. Q.932
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 accomplished 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 during 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 prompting 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, § 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 § 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 § 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 § 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 combination 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, § 5.1.3, shall be used.
For case b), the transmission or receipt of INFORMATION messages 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 § 4.5.2.1. If the supplementary service information is invalid, then the error procedures as described in § 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 applicable only in the case of information sent using overlap sending.
Fascicle VI.11 -- Rec. Q.932 27
1) Clear the call reference via the normal call clearing procedures (see Recommendation Q.931, § 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 establishment and not in the cases of the supplementary service being invoked from the active or clearing phases of the call.
28 Fascicle VI.11 -- Rec. Q.932
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 § 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 supplementary 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 overlap 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 supplementary 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 information 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 situations where a user's response could be related to two unacknowledged network prompts.
Note -- 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.
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 service 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.
Fascicle VI.11 -- Rec. Q.932 29
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 information 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 § 4.5.2.2 to re-input the required information. Otherwise, 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, § 5.3.
ii) No in-band 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, § 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 § 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, § 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, § 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 § 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 equipment itself.
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.
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.
30 Fascicle VI.11 -- Rec. Q.932
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-machine interface.
5.1 Messages
|
The Feature activation and Feature indication information elements may be present in several Recommendation Q.931. The Feature activation information element may appear in the following messages in the a) SETUP b) INFORMATION. |
of the messages defined user-to-network direction: |
in |
The Feature indication information element may be sent in the network-to-user direction in the following messages:
|
a) b) c) d) e) f ) g) h) i) |
SETUP SETUP ACKNOWLEDGE CONNECT CALL PROCEEDING ALERTING INFORMATION DISCONNECT RELEASE RELEASE COMPLETE. |
|||
|
5.2 5.2.1 |
Procedures Assumptions and restrictions |
|||
|
a) b) |
These procedures assume that only one Feature activation request will appear in a message. 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 activation information element in the messages defined in § 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:
Fascicle VI.11 -- Rec. Q.932 31
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.
32 Fascicle VI.11 -- Rec. Q.932
|
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. specific. 5.2.3.1 Normal responses 5.2.3.1.1 Return of a Feature indication |
This action will be supplementary service and network |
The network may return a Feature indication information element in an INFORMATION message or any other appropriate call control message as defined in § 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 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.
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 § 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.
Fascicle VI.11 -- Rec. Q.932 33
5.2.3.2 Responses during error conditions
|
5.2.4 |
When an error condition exists (as defined in § 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. 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 supplementary 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 information element is to be returned, then one of the following options may be used:
a) the network may send a Feature indication information element in one of the call clearing messages (i.e., DISCONNECT, RELEASE, or RELEASE COMPLETE);
b) the network may send a Feature indication information 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
34 Fascicle VI.11 -- Rec. Q.932
If a user requests a feature using an invalid feature identifier number, the network may take actions specified in § 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 § 5.2.2.1, the network should not provide the service and should respond as indicated in § 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 following actions:
a) act upon all feature activation requests by returning multiple Feature indication information elements (or other responses as detailed in § 5.2.3.1). These may be sent in a single message or in multiple messages;
Fascicle VI.11 -- Rec. Q.932 35
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 supplementary service specific.
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 § 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 supplementary 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 information element and the invoke identifier present within the Facility information element itself [refer to cases d), e) and g)].
36 Fascicle VI.11 -- Rec. Q.932
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.
Fascicle VI.11 -- Rec. Q.932 37
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 synchronization of the peer-to-peer 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.
|
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 subscription 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 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, 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 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, 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 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.
38 Fascicle VI.11 -- Rec. Q.932
|
6.2.3 |
Retrieve procedures 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. |
||
|
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.
If the Retrieve request is successful, the RETRIEVE ACKNOWLEDGE message will be returned with the selected B-channel 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.
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 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.
|
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 changing the dimensioned state space to: (Active, Call Held) Now the user requests the Retrieve function. The dimensioned state space would become: (Active, Retrieve Request) Fascicle VI.11 |
-- Rec. Q.932 39 |
|
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 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-network and NT2-NT2 applications.
40 Fascicle VI.11 -- Rec. Q.932
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.
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 services. |
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.
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 control as specified in §§ 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:
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;
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;
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 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
-- 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).
Fascicle VI.11 -- Rec. Q.932 41
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 establishment of the signalling connection by transferring a REGISTER message across the user-network 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.
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 component). 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 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.
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-sent in another FACILITY message or the request can be cleared and the call reference value released with a RELEASE COMPLETE message.
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-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 invocations |
||||
|
The |
possible correlation of responses to multiple supplementary 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, § 4.3 of Recommendation Q.931 is applicable. For the |
functional |
supplementary service control, the dummy call reference is not applicable.
This section should be read in conjunction with § 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 § 3 of Recommendation Q.931.
7.1 Messages for supplementary service control
Table 7-1/Q.932 summarizes the messages specific to supplementary service control procedures.
42 Fascicle VI.11 -- Rec. Q.932
H.T. [T3.932]
TABLE 7-1/Q.932
Messages specific to supplementary service
control
center box; lw(90p) | cw(42p) . Reference _ lw(90p) | cw(42p) . FACILITY 7.1.1 lw(90p) | cw(42p) . HOLD 7.1.2 lw(90p) | cw(42p) . HOLD ACKNOWLEDGE 7.1.3 lw(90p) | cw(42p) . HOLD REJECT 7.1.4 lw(90p) | cw(42p) . REGISTER 7.1.5 lw(90p) | cw(42p) . RETRIEVE 7.1.6 lw(90p) | cw(42p) . RETRIEVE ACKNOWLEDGE 7.1.7 lw(90p) | cw(42p) . 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 supplementary 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 § 6. |
||||
|
H.T. [T4.932] TABLE 7-2/Q.932 FACILITY message content Message type: FACILITY Significance: local (Note 1) Direction: both |
center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Facility 8.2/Q.932 both M 8 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . 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
Fascicle VI.11 -- Rec. Q.932 43
|
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 § 6. H.T. [T5.932] TABLE 7-3/Q.932 HOLD message content Message type: HOLD Significance: local Direction: both |
center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . 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 44 Fascicle |
VI.11 -- Rec. Q.932 |
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 § 6. |
||||
|
H.T. [T6.932] TABLE 7-4/Q.932 HOLD ACKNOWLEDGE message content Message type: HOLD ACKNOWLEDGE Significance: local Direction: both |
center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . 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 |
Tableau 7-4/Q.932 [T6.932], p.25 |
|
|
Blanc |
Fascicle VI.11 -- Rec. |
Q.932 45 |
|
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 § 6. H.T. [T7.932] TABLE 7-5/Q.932 HOLD REJECT message content Message type: HOLD REJECT Significance: local Direction: both |
center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Cause 4.5/Q.931 both M 4 | (hy | 2 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . 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 46 Fascicle |
VI.11 -- Rec. Q.932 |
|
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 § 6. H.T. [T8.932] TABLE 7-6/Q.932 REGISTER message content Message type: REGISTER Significance: local (Note 1) Direction: both |
center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Facility 8.2/Q.932 both O (Note 4) 2 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . 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 supplementary service information.
|
Tableau |
Tableau 7-6/Q.932 [T8.932], p.27 |
|
|
Blanc |
Fascicle VI.11 -- Rec. |
Q.932 47 |
|
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 § 6. H.T. [T9.932] TABLE 7-7/Q.932 RETRIEVE message content Message type: RETRIEVE Significance: local Direction: both |
center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Channel identification 4.5/Q.931 both O (Note 1) 2 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Display 4.5/Q.931 n ñ | O (Note 2) (Note 3)
Note 1 -- If not included, its absence is interpreted as any channel 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 48 Fascicle |
VI.11 -- Rec. Q.932 |
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 § 6. |
||||
|
H.T. [T10.932] TABLE 7-8/Q.932 RETRIEVE ACKNOWLEDGE message content Message type: RETRIEVE ACKNOWLEDGE Significance: local Direction: both |
center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Channel identification 4.5/Q.931 both O (Note 1) 2 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . 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 |
Fascicle VI.11 -- |
Rec. Q.932 49 |
|
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 § 6. H.T. [T11.932] TABLE 7-9/Q.932 RETRIEVE REJECT message content Message type: RETRIEVE REJECT Significance: local Direction: both |
center box; cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Information element Reference Direction Type Length _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Protocol discriminator 4.2/Q.931 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Call reference 4.3/Q.931 both M 2 | (hy | _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Message type 8.1/Q.932 both M 1 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . Cause 4.5/Q.931 both M 4 | (hy | 2 _ lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) . 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 50 Fascicle |
VI.11 -- Rec. Q.932 |
Fascicle VI.11 -- Rec. Q.932 51