WPCL 2BJ|x ` H   x|@  6'6' m  ` A A @  <AP IX127E Amm  ` A A @  <AP IX127E Am   1Contents of Recommendation Q.932ă A !GENERIC PROCEDURES FOR THE CONTROL OF ISDN SUPPLEMENTARY SERVICES 1.HGeneral 2. HOverview of the generic protocols and their scope 3. HArrangements by which coexistence of protocols may be supported by a network 4. HKeypad protocol 5. HFeature key management protocol 6. HFunctional protocol 7. HMessage functional definitions and content 8. HGeneral 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 H* H G** Recommendation Q.932 GENERIC PROCEDURES FOR THE CONTROL OF ISDN SUPPLEMENTARY SERVICES 1.HGeneral  H HThis Recommendation defines the generic procedures applicable for the control of supplementary services at the usernetwork interface. These procedures may be used for the invocation and operation of supplementary services in association with existing calls or outside any existing calls. HThe 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. 2.HOverview of the generic protocols and of their scope HThree generic protocols are defined for the control of supplementary services at ISDN usernetwork 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.1HThe three generic protocols HThree generic protocols are defined for the control of supplementary services, two of which are stimulus, the third being functional; these protocols are: H the Keypad protocol; H the Feature key management protocol; H the Functional protocol. 2.1.1HThe Keypad protocol HThe 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]. HThis protocol applies to supplementary service invocation in the usertonetwork direction, and the keypad facility codes used for the invocation of individual supplementary services are network dependent. HThe 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.2HThe Feature key management protocol HThe 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 usertonetwork direction. The Feature indication information element may be included in various basic call control messages in the networktouser direction. HThis protocol typically applies to supplementary service operation during calls but also allows for noncall related supplementary service control. Noncall 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 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. HThis 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.3HThe Functional protocol HThe 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. HThis 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. HFunctional 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.2HSupport of the various generic protocols HNetworks 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.3HCoexistence of generic protocols HAs 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. HNetworks 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. HIn general, the Keypad protocol and Feature key management protocol have only local significance while the Functional protocol may have other than local significance. HFor 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 networktouser direction. 3.XHArrangements by which coexistence of protocols may be supported by a network HSome 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. HNetwork supporting multiple generic protocols per access in the   usertonetwork 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. HNetworks supporting more than one generic protocol per access in the networktouser 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. HUser 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.HKeypad protocol HThe 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. HAn example of the use of the Keypad protocol is given in Appendix I. 4.1HGeneral HThis generic procedure is based on the use of: H the Keypad facility information element by the user to invoke a L$MM$N .,supplementary service from the network by providing access codes =>>?using either enbloc or overlap sending; and H the Display information element by the network to give an FH!GG!Hindication to the local or remote user regarding a supplementary 7@889service being invoked. This procedure may be complemented in the (8))*case of calls where the Bearer capability information element in 0  the SETUP message is coded indicating "speech" or "3.1 kHz H audio", by the provision of inband tones/announcements to the K#LL$Muser. 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 networktouser 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 RecommendationQ.931 of receipt of the Keypad facility information element. HThe Keypad protocol may be used in conjunction with the Feature key management (5) or Functional protocol (6) during the invocation of a supplementary service. HThe 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.2HMessages used in the Keypad protocol HAs 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 usertonetwork direction. 4.3HCoding of the Keypad facility information element HThe 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.4HElements of procedure 4.4.1HGeneral HThe Keypad protocol includes the following aspects: H1)h  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; H2)h  supplementary service information can be sent from the user to the network either enbloc or using overlap sending; H3)h  the network may prompt the user to send the required information using the Display information element and/or inband tones or announcements. Whether this action shall occur or not is supplementary service and network specific. In any case, inband tones or announcements shall only be used when the Bearer capability information element indicates "speech" or "3.1 kHz audio"; H4)h  there may be different combinations of user provided information followed by network prompts. Examples of such possible combinations are shown in Table 41/Q.932, where the term "stage" is used to refer to information sent by the user between network prompts (if any). JTABLE 41/Q.932 Q ;Example of stages for sending of informationă Q HNumber of stages Sending information H H 1 All information sent enbloc H 1 All information sent overlap H 2 Overlap .. Prompt... Overlap H 2 Enbloc ... Prompt... Enbloc H 2 Overlap ... Prompt... Enbloc H 2 Enbloc.... Prompt... Overlap H 3 Overlap ... Prompt... Overlap ... Prompt H  ...Overlap, etc. HThe number of possible stages is network dependent and may also be dependent on the specific supplementary service being invoked. H4.5HProcedures at the invocation interface 4.5.1HUser procedures HThe procedures below define how information (using either enbloc or overlap sending) may be sent in a single stage from the user to the network. The procedures are applicable for each stage of usertonetwork information sending. 4.5.1.1 Enbloc sending of access codes HEnbloc sending of supplementary service information is accomplished by sending the "complete" supplementary service information in: H the SETUP message, if the supplementary service is being invoked during the call establishment; or H 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. HThe 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: H analysis of the information contents of the Keypad facility information element; or H the presence of a "sending complete" indication (see RecommendationQ.931, 5.1.3).  .,ԌHIf 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. HIf 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 HOverlap 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: Ha)h  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 Hb)h  for supplementary services invoked in the active or clearing phases of the call, consists of using two or more INFORMATION messages. HFor case a), normal overlap sending procedures, as specified in RecommendationQ.931, 5.1.3, shall be used. HFor case b), the transmission or receipt of INFORMATION messages shall not cause any change to the RecommendationQ.931 call state. HThe 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.2HNetwork procedures 4.5.2.1 Network responses to user requests HAfter receiving information from the user, the network may take one of the following actions. Items 14 are applicable in the cases of both enbloc and overlap sending; item 5 is applicable only in the case of information sent using overlap sending. H1)h  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). H2)h  Send a CALL PROCEEDING message to the user. HX 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. H3)h  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. H4)h  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 reinput the original information correctly. Such procedures are network dependent and may be supplementary service specific. H5)h  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. HThe precise action to be taken is dependent on the specific supplementary service being invoked. 4.5.2.2 Network prompting and inband tone/announcement control HThe network may prompt the user for more information or may provide inband 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 inband tone or announcement control should occur. Possible factors governing the provision of prompting and inband information are: H the nature of the supplementary service; H the value of the interdigit timer; H the type of interface; and H the current status or progress of the supplementary service request. HSimultaneously with the application of inband tones or announcements, the network may send a PROGRESS message containing a Progress indicator information element with the progress descriptor #8, "Inband information or appropriate pattern now available". HThe 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). HThe sending of the INFORMATION message by the network does not result in a change to the RecommendationQ.931 call state. However, when this message is sent in the network overlap sending state, timer T302 shall be reinitialized. HThe 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 timerT302. 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 HAn error condition exists in the following circumstances:  .,ԌHa)h  timer T302 expires and complete information has not been received; Hb)h  information containing a "sending complete" indication indicating enbloc sending, but the user information sent is not complete; Hc)h  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; Hd)h  The user attempts to invoke a supplementary service to which the user has not subscribed or to which the user is not allowed access. HThe 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.1For a supplementary service being invoked during call establishment HThe network shall take one of the following actions: Hi)h  Inband 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 BChannel to be used and including the Progress indicator information element with progress descriptor #8, "Inband information or appropriate pattern is now available".   HHX 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, "Inband information or appropriate pattern is now available".  `    HHX The network may prompt the user using the procedures as specified in 4.5.2.2 to reinput the required information. Otherwise, after the inband 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 RecommendationQ.931, 5.3.  `    Hii)  No inband 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.2For a supplementary service being invoked from the active state or Hduring the call clearing phase HThe network shall take one of the following actions: Hi)h  Inband tones or announcements are applied. The network may prompt the user using the procedures as specified in 4.5.2.2 to reinput 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 inband 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. Hii)  No inband 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.6HProcedures at the remote interface HThe 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.HFeature key management protocol HThe 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. HThe 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. HFeature 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.1HMessages HThe 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 usertonetwork direction: Ha)  SETUP Hb)  INFORMATION. HThe Feature indication information element may be sent in the networktouser direction in the following messages: .,Ԍ Ha)h  SETUP Hb)  SETUP ACKNOWLEDGE Hc)  CONNECT Hd)  CALL PROCEEDING He)  ALERTING Hf)  INFORMATION Hg)  DISCONNECT Hh)  RELEASE Hi)  RELEASE COMPLETE. 5.2HProcedures 5.2.1HAssumptions and restrictions Ha)h  These procedures assume that only one Feature activation request will appear in a message. Hb)h  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). Hc)h  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.2HInvocation of supplementary services HThe 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 HWhen the Feature activation information element is sent in the INFORMATION message, then the following rules apply: Ha)h  if no call references exist, then the dummy call reference must be used (for this noncall associated service type); Hb)h  if a call reference(s) has been established, then that value may be used regardless of whether the service type is call associated or noncall associated; Hc)h  if a call reference(s) has been established, the dummy call reference may be used only if the service type is noncall 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. HThis is summarized in Figure 51/Q.932. HO H3   H3  Service type  No calls exist  Call(s) exist  H3 H3     H3  Noncall  Use dummy call  Use dummy or active  H3  associated  reference  call reference  H3 H3     H3  Call  Error:  Use an active call  H3  associated  Not allowed  reference (Note 1)  H3   Note 1 The dummy call reference value may be used if only one call is established. HGFIGURE 51/Q.932 HO H6Use of the call reference in an INFORMATION messageă HO HIt 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.3HNetwork responses HThe network may respond to a Feature activation request in several ways. This action will be supplementary service and network specific. 5.2.3.1Normal responses 5.2.3.1.1Return of a Feature indication HThe 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.2Prompting for further information HThe 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). HThe 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.3Implicit response HThe 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.4Return of Signal, Cause, or Display information elements HThe 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 HWhen an error condition exists (as defined in 5.2.5), the network may: Ha)h  Respond with one or more of the following options: H 1)hreturn a Feature indication information element; H 2)prompt for further information (see Annex B); H 3)provide an implicit response; or H  4)return Signal, Cause, or Display information elements. Hb)  Ignore the Feature activation request and not respond at all. Hc)h  Clear appropriate existing calls in conjunction with the above actions. 5.2.4HGeneral aspects  HH5.2.4.1  Use of Feature indication information elements independent of a feature request HThe 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 HWhen explicitly deactivating a supplementary service, two methods may be used: Ha)h  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; Hb)h  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 HIf 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: Ha)h  the network may send a Feature indication information element in one of the call clearing messages (i.e., DISCONNECT, RELEASE, or RELEASE COMPLETE); Hb)h  the network may send a Feature indication information element in an INFORMATION message after clearing has occurred using the dummy call reference. 5.2.5HError conditions 5.2.5.1 Invalid feature activation request HIf 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 HIf 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 HIf 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: Ha)h  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; Hb)h  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. HThe determination of which action to take is network and supplementary service specific. 6.HFunctional protocol 6.1HGeneral 6.1.1HIntroduction HThis section specifies the functional signalling procedures for the control of supplementary services at the usernetwork interface. This generic protocol utilizes functions and services provided by RecommendationsQ.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.2HScope of the procedures HThe 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 usernetwork interface is a basic or primary rate interface. 6.1.3HCategories of procedures HTwo 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. HThe 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. HBoth categories are specified in a symmetrical manner and can be signalled ., both in the networktouser and the usertonetwork directions. 6.1.4HSupplementary service functions HThe control of supplementary services by either the network or the user includes the following cases: Ha)h  the invocation of supplementary services during the establishment of a call; Hb)h  the invocation of supplementary services during the clearing of a call; Hc)h  the invocation of call related supplementary services during the active state of a call; Hd)h  the invocation or registration of supplementary services independent from an active call; He)h  the invocation of multiple, different supplementary services within a single message; H Hf)h  the invocation of supplementary services related to different calls; Hg)h  cancellation of invoked supplementary services and notification to the initiator of the supplementary service. HThe 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). HThe 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)). HThe 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.2HSeparate messages category HThe 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 peertopeer 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. HThe following individual messages are defined: HHOLD HHOLD ACKNOWLEDGE HHOLD REJECT HRETRIEVE HRETRIEVE ACKNOWLEDGE HRETRIEVE REJECT. 6.2.1HHold and Retrieve functions HThe 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 RecommendationQ.921. In addition, the call reference of the held call shall be retained for possible subsequent call retrieval and channel reconnection. HAs 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. HOn 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 nonreservation of the B Channel, on a per call basis. HThe 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". HThe 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". HThe HOLD and RETRIEVE families of message may be used in a symmetrical manner. 6.2.2HHold procedures HThe Hold function should be invoked in association with an existing call (i.e., during the establishment or active phase of a call). HThe 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.3HRetrieve procedures HThe Retrieve function is requested by sending a RETRIEVE message. This message .,  may be sent while the auxiliary state is in the Call Held state. HThe 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. HIf 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. HIf 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.4HAuxiliary states for hold and retrieve HIt 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. HThere are four auxiliary states associated with the Hold and Retrieve functions: Hi)  Idle; Hii)  Hold Request A request has been made for the Hold function; Hiii) Call Held The call is held; Hiv)  Retrieve Request A request has been made for the Retrieve function. 6.2.5HAn example of dimensioned state space HSuppose a call is in the Outgoing Call Proceeding state. The dimensioned state space would be: E(Outgoing Call Proceeding, Idle) HNow the user requests the Hold function. The dimensioned state space would become: A(Outgoing Call Proceeding, Hold Request) HThe 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: C(Outgoing Call Proceeding, Call Held) HThe user may receive subsequent call progress messages changing the dimensioned state space to: L(Active, Call Held) HNow the user requests the Retrieve function. The dimensioned state space would become: H(Active, Retrieve Request) HWhen a call is reconnected, the dimensioned state space would be: N(Active, Idle) 6.3HCommon information element category HThe 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 usernetwork and NT2NT2 applications. HA 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. HThis functional procedure provides a flexible and open ended approach to the provision of supplementary service protocols and: H allows new services to be easily introduced; H allows multiple supplementary service invocations within one message; H supports supplementary services with a large number of variants without a proliferation of new messages; H supports noncall associated supplementary services. HIn 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.1HCall related supplementary service procedures HFor 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 9  (3276) CCITT\APIX\DOC\127E1.TXS98  (3276) CCITT\APIX\DOC\127E1.TXS8  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: H1)h  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; H2)h  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; H3)h  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. HThe option to be used depends on the individual supplementary service procedures, which are the subject of other Recommendations. HFor 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. HThe 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. HIf 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. HDepending upon the supplementary service invoked, one of the following will occur: H 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 H 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.2HCall independent supplementary service procedures HFor 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 usernetwork 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. HExamples of message exchange for supplementary service control for various scenarios is described by means of arrow diagrams in Appendix I. HTo 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: H1)h  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. H2)h  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. H3)h  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.3HResponses to multiple supplementary service invocations HThe possible correlation of responses to multiple supplementary service invocations is the subject of future Recommendations.