- 2 - AP IX-127-E Contents of Recommendation Q.932 GENERIC PROCEDURES FOR THE CONTROL OF ISDN SUPPLEMENTARY SERVICES 1. General 2. Overview of the generic protocols and their scope 3. Arrangements by which co-existence of protocols may be supported by a network 4. Keypad protocol 5. Feature key management protocol 6. Functional protocol 7. Message functional definitions and content 8. General message format and information element coding Annex A: User service profiles and terminal identification Annex B: Information request procedures Appendix I: Illustration of the application of the three protocol types Appendix II: Functional reference model for the operation of supplementary services Appendix III: General description of the component encoding rules List of acronyms References * * * Recommendation Q.932 GENERIC PROCEDURES FOR THE CONTROL OF ISDN SUPPLEMENTARY SERVICES 1. General This Recommendation defines the generic procedures applicable for the control of supplementary services at the user-network interface. These procedures may be used for the invocation and operation of supplementary services in association with existing calls or outside any existing calls. The detailed procedures applicable to individual supplementary services are outside the scope of this Recommendation. However, typical examples of the application of these generic procedures to some supplementary services are provided in Appendix I to this Recommendation for explanatory and illustrative purposes only. The application of the Functional protocol defined in  6, to the operation of individual supplementary services will be the subject of future Recommendations in this series. - 3 - AP IX-127-E 2. Overview of the generic protocols and of their scope 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 S/T reference points, and assume that the use of layers 1 and 2 conform to CCITT 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 The 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; - the Feature key management protocol; - the Functional protocol. 2.1.1 The 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 The 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 to 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 - 4 - AP IX-127-E 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 The 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. 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. 3. Arrangements by which co-existence of protocols may be supported by a - 5 - AP IX-127-E network Some networks may support only one of the generic protocols per user access for the invocation of supplementary services. Other networks may choose to support a single generic protocol for the control of supplementary services, depending on the user access interface type (e.g., Feature key or Keypad on the basic access, Functional on the primary access). This has to be arranged at subscription time. Network 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. 4. Keypad protocol The Keypad protocol is based on the use of the Keypad facility and Display information elements. While the generic procedures associated with Keypad invocation are specified in this section, the allocation of the access codes used to request/indicate 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 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. 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. - 6 - AP IX-127-E 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 Elements of procedure 4.4.1 General The Keypad protocol includes the following aspects: 1) the Keypad protocol may be used during the call establishment, active, and clearing phases of a call to invoke 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). TABLE 4-1/Q.932 Example of stages for sending of information Number of stages Sending information 1 All information sent en-bloc 1 All information sent overlap 2 Overlap .. Prompt... Overlap 2 En-bloc ... Prompt... En-bloc 2 Overlap ... Prompt... En-bloc 2 En-bloc.... Prompt... Overlap 3 Overlap ... Prompt... Overlap ... Prompt ...Overlap, etc. The number of possible stages is network dependent and may also be dependent on the specific supplementary service being invoked. 4.5 Procedures at the invocation interface 4.5.1 User procedures - 7 - AP IX-127-E 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 - 8 - AP IX-127-E 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. 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. 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 # 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. - 9 - AP IX-127-E 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. 4.5.2.3.1 For a 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 # 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 # 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 For a supplementary service being invoked from the active state or during the call clearing phase The network shall take one of the following actions: - 10 - AP IX-127-E 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. 5. Feature key management protocol The Feature key management protocol is a mechanism allowing users to invoke network supplementary services. As these are stimulus procedures, the protocol elements do not, in and of 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. 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 of the messages defined in Recommendation Q.931. The Feature activation information element may appear in the following messages in the user-to-network direction: a) SETUP b) INFORMATION. - 11 - AP IX-127-E The Feature indication information element may be sent in the network-to-user direction in the following messages: a) SETUP b) SETUP ACKNOWLEDGE c) CONNECT d) CALL PROCEEDING e) ALERTING f) INFORMATION g) DISCONNECT h) RELEASE i) RELEASE COMPLETE. 5.2 Procedures 5.2.1 Assumptions and restrictions a) These procedures assume that only one Feature activation request will appear in a message. b) The phrase "call associated services" used herein is defined as services which act upon or relate to an existing call (as defined by the existence of a call reference). c) These procedures are used for the invocation of supplementary services which relate to predefined specific bearer capabilities and/or 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: a) if no call references exist, then the dummy call reference must be used (for this non-call associated service type); b) if a call reference(s) has been established, then that value may be used regardless of whether the service type is call associated or non-call associated; c) if a call reference(s) has been established, the dummy call reference may be used only if the service type is non-call associated. If the service type is call associated, then the appropriate call reference must be used. An exception to this rule is when only one call is established. In this instance it is permissible for the user to use the dummy call reference for either service type. This is summarized in Figure 5-1/Q.932. 旼컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴쩡컴컴컴컴컴컴컴컴컴컴커 � Service type � No calls exist � Call(s) exist � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴캑 � � � � � Non-call � Use dummy call � Use dummy or active � � associated � reference � call reference � 쳐컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴캑 - 12 - AP IX-127-E � � � � � Call � Error: � Use an active call � � associated � Not allowed � reference (Note 1) � 읕컴컴컴컴컴컴컨컴컴컴컴컴컴컴컴좔컴컴컴컴컴컴컴컴컴컴켸 Note 1 - The dummy call reference value may be used if only one call is established. FIGURE 5-1/Q.932 Use of the call reference in an INFORMATION message It is always correct for the user's equipment to use the dummy call reference when no calls exist, or to use an established call reference if one exists, independent of the service type. 5.2.3 Network responses The network may respond to a Feature activation request in several ways. This action will be supplementary service and network specific. 5.2.3.1 Normal responses 5.2.3.1.1 Return of a Feature indication The network may return a Feature indication information 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. 5.2.3.2 Responses during error conditions 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; - 13 - AP IX-127-E 2) prompt for further information (see Annex B); 3) provide an implicit response; or 4) return Signal, Cause, or Display information elements. b) Ignore the Feature activation request and not respond at all. c) Clear appropriate existing calls in conjunction with the above actions. 5.2.4 General aspects 5.2.4.1 Use of Feature indication information elements independent of a feature request The network may choose to send Feature indication information at any time independent of the status of any call(s). Multiple Feature indication information elements may be returned in an INFORMATION message or in an appropriate call control message if more than one indicator is to be updated. 5.2.4.2 Deactivation procedures When explicitly deactivating a supplementary service, two methods may be used: a) sending of a feature activation request with the same feature identifier may deactivate the supplementary service. Some supplementary services may be "toggled" on and off; b) sending of a feature activation request with a different feature identifier which is explicitly defined (between the user and network) as the deactivator for that particular 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 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 - 14 - AP IX-127-E 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; 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. Functional protocol 6.1 General 6.1.1 Introduction This section specifies the functional signalling procedures for the control of supplementary services at the user-network interface. This generic protocol utilizes functions and services provided by Recommendations Q.930[5] and Q.931[4] basic call control procedures and the functions of the data link layer as defined in Recommendations Q.920[6]/Q.921[3]. 6.1.2 Scope of the procedures The procedures defined in  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; - 15 - AP IX-127-E 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)). 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. 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 reuse 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. - 16 - AP IX-127-E 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 # 29 "Facility rejected", or # 50 "Requested facility not subscribed" or # 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 # 44 "Requested channel not available" or # 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. 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: - 17 - AP IX-127-E 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 ACKNOWLEDGE 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) 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. 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. - 18 - AP IX-127-E 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). 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 (3276) CCITT\AP-IX\DOC\127E1.TXS - 19 - AP IX-127-E 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 resent 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 resent 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. (3276) CCITT\AP-IX\DOC\127E1.TXS