旼컴컴컫컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴쩡컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴커 � Case � Called User's � Requested Service � Called User � Calling User Network � � � Capability � (Note 2) � Action � Interface Action � 쳐컴컴컵컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴캑 � 1 � Can analyze the � Services 1, 2, 3 � Return appropriate � Pass ACK to the calling � � � service and � Preferred or Required � ACK indication by the � user in normal call � � � accepts the � � response message � control messages. � � � service � � � � 쳐컴컴컵컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴캑 � 2 � Can analyze the � Services 1, 2, 3 � Clears the call with � Pass same cause to the � � � service but does � Required � appropriate message � calling user in the normal� � � not accept the � � and cause � call control clearing � � � service � � � message. � � � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴� � � � Services 1 (explicit � Ignore the request or � Pass NACK to the calling � � � � invocation), 2, 3 � return appropriate � user � � � � Preferred � NACK indication by � � � � � � the response message, � � � � � � the call is not � � � � � � cleared � � � � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴� � � � Service 1 (implicit � Return appropriate � Pass NACK to the calling � � � � invocation) Preferred. � NACK indication in � user in normal call � � � � � the response message. � control messages. The call� � � � � The call is not � is not cleared. � � � � � cleared � � 쳐컴컴컵컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴캐 � 3 � Cannot analyze � Services 1, 2, 3 � Treats as an � Clears the call with � � � the service � Required � unrecognized optional � appropriate message and � � � request. � � information element � cause. � � � 쳐컴컴컴컴컴컴컴컴컴컴컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴� � � � Services 1, 2, 3 � Treats as an � Passes back the implicit � � � � Preferred � unrecognized optional � user responses to the � � � � � information element � calling node (Note 3) � 읕컴컴컨컴컴컴컴컴컴컴컴컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴좔컴컴컴컴컴컴컴컴컴컴컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴켸 When interworking with a non-ISDN network occurs a PROGRESS or an ALERTING message with the Progress indicator information element indicating # 1 "call is not end-to-end ISDN; further call progress information may be available in-band" is sent to the calling user to indicate that the service cannot be guaranteed. If any one or all of the services requested is indicated as required, then the network or called user that cannot support or provide the request will send a RELEASE COMPLETE with cause # 50 "requested facility not subscribed" or cause # 69 "requested facility not implemented" and the service rejection associated with that service. 7.1.7.4 Transfer of USER INFORMATION messages The transfer of USER INFORMATION messages is defined in  7.1.4.4 and 7.1.5.6. 7.1.8 Summary of actions to be taken by the called side and subsequent network action Actions to be taken by the called side and the subsequent network actions are summarized in the following table. iii) Service 3: user-to-user signalling exchanged while a call is in the Active state, within USER INFORMATION messages. All three services may be used separately or in any combination in association with a single call. As an option, at call setup, users may be able to specify that the requested user-to-user signalling services(s) is (are) required for the call, i.e. the call should not be completed if user-to-user information cannot be passed. 7.1.2 Explicit invocation procedures for services 1, 2 and 3 Services 1, 2 and 3 listed above may be provided on a per call basis following an explicit request from a user. The standard explicit invocation procedure makes use of the Facility information element defined in  4. In addition, or alternatively, some networks may support explicit invocation procedures making use of: - Keypad facility information element; or - Feature activation information element. The exact operation of stimulus invocation procedures are network dependent but must follow the rules defined in  8 of this Recommendation. More detailed protocol aspects can also be found in  4 (for the keypad protocol invocation) and in  5 (for the feature management protocol invocation) of Recommendation Q.932. When a network supports more than one invocation procedure, the following principles shall be followed: - for invocations using the Keypad facility information element, the network will convey the remote user's response using a Signal, a Display, or a Feature indication information element; - for invocations using the Feature activation information element, the network will convey the remote user's response using a Feature indication information element; - for invocations using the Facility information element, the network will convey the remote user's response using a Facility information element. In the network-to-user direction, explicit service 1 and service 2 requests may be indicated using the Facility information element. In the network to user direction, service 3 requests may be indicated using: i) Signal information element (see note); ii) Display information element (see note); iii) Feature indication information element (see note); or iv) Facility information element. For indications using the Facility information element, the user will respond with a Facility information element. No response is needed when any of the first three information elements are used. Note - These may be used only when the network has knowledge that the user receiving the notification has subscribed to the service. In this case, the network will generate the service confirmation to the originating user (i.e., the user requesting the service) on behalf of the user who did not originate the service request. For service 3, invoked during the active state of a call, the message use is symmetric across the user-network interface; i.e., the FACILITY message is returned in response to a FACILITY message. 7.1.3 User-to-user signalling service 1 7.1.3.1 General characteristics Service 1 allows the users to communicate by means of user-to-user signalling by transferring user-to-user information within Recommendation Q.931 call control messages during call establishment and clearing phases. 7.1.3.2 User-to-user signalling - implicit service request (preferred, i.e. - not required) Service 1 may be implicitly requested by including a User-user information element of variable length as specified in  4.5.29 in the SETUP message transferred across the user-network interface at the calling side as described in  5.1.1. This information element is transported by the network and delivered unchanged in the User-user information element included in the SETUP message transferred across the user-network interface at the called side as described in  5.2.1. For invocation purposes, this information element must be at least three octets long as defined in  4.5.29. In the case where contention by users for the incoming call is not allowed (e.g., when the SETUP message containing an implicit service invocation is delivered using a point-to-point link at the data link layer or when the network, despite using broadcast capability at layer 2, knows based on the first response received from the user that no contention takes place), a User-user information element may be included in the ALERTING and/or CONNECT messages transferred across the user-network interface at the called side as described in  5.2.5. The content of this information element is transported by the network and delivered in the User-user information element included in the corresponding message(s) transferred across the user-network interface at the calling side as described in  5.1.7 and 5.1.8. On call request, the SETUP message sent by the calling user will contain a service 2 request. The SETUP message sent by the network at the called side, will also contain an explicit service 2 request. If the called user can support USER INFORMATION messages during call establishment, a service 2 acceptance shall be included in the ALERTING message sent to the network. This explicit acceptance indication shall be forwarded in the ALERTING message sent by the network to the calling user. 7.1.4.3 Service rejection If the called user or network does not understand the service 2 request, then the ALERTING message returned to the calling user will not include either a service 2 acceptance or rejection. This type of response shall be taken as an implicit rejection of service 2. Alternatively, if the network or called user cannot support USER INFORMATION messages during call establishment, and the request is indicated as preferred, a service 2 rejection is included in the ALERTING message. If the service 2 request indicated required, and the called user or network cannot support or provide the service, a RELEASE COMPLETE is sent with cause # 50 "requested facility not subscribed" or cause # 69 "requested facility not implemented" and a service 2 rejection. If the called user does not include a service 2 acceptance or rejection in the ALERTING message, the network shall return an explicit rejection in the ALERTING message sent to the calling user. In the case of interworking with a non-ISDN network, a PROGRESS or ALERTING message with the progress indicator information element indicating # 1 "call is not end-to-end ISDN; further call progress information may be available in-band" is sent to the calling user to indicate that the full service cannot be guaranteed. 7.1.4.4 Transfer of USER INFORMATION messages Once an ALERTING message has been received, both the involved users can transfer information between themselves by transferring USER INFORMATION messages across the user-network interface. The network provides for the transfer of such messages from the calling to the called side and vice versa. The USER INFORMATION message includes the Call reference, the Protocol discriminator, and the User-user information elements as defined in  3.1.26. The More data information element may also be included by the source user to indicate to the remote user that another USER INFORMATION message will follow, containing information belonging to the same block. The use of More data information element is not supervised by the network. If the user-to-user signalling facility is provided, no more than two USER INFORMATION messages may be transferred in each direction after the ALERTING message and before the CONNECT message. Sending or receiving of USER INFORMATION messages does not change the state of the call. 7.1.5 User-to-user signalling service 3 7.1.5.1 General Service 3 allows the users to communicate by means of transferring USER INFORMATION messages during the Active state of a call. This service allows either an implicit or explicit rejection (see  7.1.5.3.). This service may be requested during call establishment or during the Active state of the call. 7.1.5.2 Service request during call establishment Procedures for call establishment are as described in  5.1 and 5.2 with the following modifications. On call request, the SETUP message sent by the calling user will contain a service 3 request. The SETUP sent by the network at the called side will also contain a service 3 request. If the called user can support USER INFORMATION message transfer during the Active state, a service 3 acceptance shall be included in the CONNECT message. 7.1.5.3 Rejection of service requested during call establishment If the called user or network does not understand the service 3 request, then the CONNECT message returned to the calling user shall not include either a service 3 acceptance or rejection. This type of response will be taken as an implicit rejection of service 3. Alternatively, if the network or called user cannot support USER INFORMATION messages during the Active state, and the request is indicated as preferred, a service 3 rejection is included in the CONNECT message. If the service 3 request indicated required, and the called user or network cannot support or provide the service, a RELEASE COMPLETE is sent with cause # 50 "requested facility not subscribed" or cause # 69 "requested facility not implemented" and a service 3 rejection. If the called user does not include a service 3 acceptance or rejection in the CONNECT message, the network shall return a service 3 rejection in the CONNECT message sent to the calling user. When interworking with a non-ISDN network occurs a PROGRESS or an ALERTING message with the Progress indicator information element indicating # 1 "call is not end-to-end ISDN; further call progress information may be available in-band" is sent to the calling user to indicate that the service cannot be guaranteed. 7.1.5.4 Service request after call establishment During the Active state of a call, a user may request service 3 preferred only. A FACILITY message indicating a service 3 request is sent from the requesting user to the network. The network shall indicate the service 3 request to the user that did not request service 3 in the FACILITY message. If the user that did not request service 3 can support the transfer of USER INFORMATION messages during the Active state, a service 3 acceptance is returned in the FACILITY message. This explicit acceptance indication shall be conveyed back to the requesting user in a FACILITY message. 7.1.6 Unexpected USER INFORMATION messages 7.1.6.1 Receipt of USER INFORMATION messages in incompatible call states Whenever a USER INFORMATION message is received from the user and it is not allowed by an invoked service (e.g., in any other state than Active where only service 3 is invoked), the message will be discarded by the network. The network will respond with a STATUS message with a cause # 43 "access information discarded". 7.1.6.2 Receipt of unexpected USER INFORMATION messages Whenever a USER INFORMATION message is received by the network from the calling or called user after the network has indicated that user-to-user cannot be supported, that message shall be discarded without further action. 7.1.7 Requesting user-to-user signalling services 1, 2 and 3 7.1.7.1 General This section describes procedures for requesting services 1, 2 and 3 in the same SETUP message. These services are described in  7.1.3, 7.1.4 and 7.1.5, respectively. Note - User-to-user service 1 implicit request/acceptance follows  7.1.3.2 procedures. Only explicit service 1 requests may follow the procedure in this section. 7.1.7.2 Call establishment Procedures for call establishment are described in  7.1.3.3, 7.1.4.2, and 7.1.5.2 with the following modifications. On call request, the SETUP message sent by the calling user will contain independent service 1, 2, 3 requests. The SETUP sent by the network at the called sides will also contain the same independent service requests. If the called user can support the indicated services, then specific services acceptances may all be indicated in the ALERTING message. Alternatively, the user may accept services 1 and 2 in the ALERTING message, as defined in  7.1.3.3 and 7.1.4.2, and service 3 in the CONNECT message, as defined in  7.1.5.2. 7.1.7.3 Service rejection If the called user or network does not understand any of the services requested, then the ALERTING and CONNECT messages returned to the calling user will not include either a service acceptance or rejection. This type of response will be taken as an implicit rejection of all services. If the called user or network does not understand a specific service request, that specific service is implicitly rejected following the procedures defined in  7.1.3.6, 7.1.4.3 or 7.1.5.3. Alternatively, if the network or called user cannot support one or more services requested, and the service requests were indicated as preferred, the specific service rejection may be included in the ALERTING message. The services may also be rejected following the procedures in  7.1.3.6, 7.1.4.3 or 7.1.5.3. If the called user does not include a service 1, 2 or 3 acceptance or rejection in the ALERTING and/or CONNECT message, the network shall return a service 1, 2 or 3 rejection in the ALERTING and/or CONNECT message sent to the calling user. 7.2 Procedures for user-to-user signalling not associated with circuit-switched calls 7.2.1 General characteristics This feature allows the users to communicate by means of user-to-user signalling without setting up a circuit-switched connection. A temporary signalling connection is established and cleared in a manner similar to the control of a circuit-switched connection. 7.2.2 Call establishment Procedures for call establishment are as described in  5.1 and 5.2 with the following modifications. On call request, the calling user sends a SETUP message identifying, within the Bearer capability and Channel identification information elements, a temporary signalling connection to be established on SAPI=O. The SETUP message is encoded to indicate: Bearer capability information element - Unrestricted digital information in the information transfer capability field; - Packet mode in the transfer mode field; - User information layer 2 protocol is Recommendation Q.931 and user information layer 3 protocol is Recommendation Q.931 in the layer and protocol identification field. Channel identification information element - Exclusive in the preferred/exclusive field; - D Channel in the D-Channel indicator field; - No channel in the channel selection field. If the network determines that the requested temporary signalling connection service is not authorized or is not available, the network shall initiate call clearing in accordance with  5.3.2(a) or  5.3.2(c) with one of the following causes: a) #57 "bearer capability not authorized" b) #58 "bearer capability not presently available" c) #63 "service or option not available, unspecified" d) #65 "bearer service not implemented" The called user accepts the temporary signalling connection request by sending a CONNECT message towards the calling user. After the called user has received a CONNECT ACKNOWLEDGE message, it may begin sending USER INFORMATION messages. Once the calling user receives a CONNECT message, it can begin sending USER INFORMATION messages. 7.2.3 Transfer of USER INFORMATION messages Once a temporary signalling connection is established both users can transfer information between themselves by transferring USER INFORMATION messages across the user-network interface. The network provides for the transfer of such messages from the called to the calling side and vice versa. The USER INFORMATION message includes the Call reference, the Protocol discriminator, and the User-to-user information elements as defined in  3.3.13. The More data information element may also be sent by the source user to indicate to the remote user that another USER INFORMATION message will follow, containing information belonging to the same block. The use of the More data information element is not supervised by the network. 7.2.4 Congestion control of USER INFORMATION messages Congestion control procedures are the same as those described in  7.1.5.7. 7.2.5 Call clearing The clearing of an established temporary signalling connection can be initiated by the user or network by sending a RELEASE message towards the far end user. The clearing procedure followed and the timers involved are the same as those for clearing a circuit-switched connection as described in  5.3.3 and 5.3.4.