5i' 5 Circuit-switched call control procedures The call states referred to in this section cover the states perceived by the network, states perceived by the user and states which are common to both user and network. Unless specifically qualified, all states described in the following text should be understood as common (see SS 2.1.1 and 2.1.2 for user and network call states respectively). An overview diagram of call states is given in Figures A-2/Q.931 and A-3/Q.931 (Annex A). Detailed specification and description language (SDL) diagrams for the procedures specified in this section are contained in Figures A-4/Q.931 through A-6/Q.931. When there is an ambiguity in the narrative text, the SDL diagrams in Figures A-4/Q.931 through A-6/Q.931 should be used to resolve conflict. Where the text and the SDL are in disagreement, the text should be used as the prime source. Note - This section describes the sequence of messages asso- ciated with the control of circuit-switched connections. Optional extensions to this basic protocol and exceptions that apply in the case of packet-mode connections or supplementary services are described elsewhere in this Recommendation or in Recommendation Q.932 [4]. Annex D also contains optional extensions to the basic call establishment procedures defined in S 5 for sym- metric signalling. Future enhancements to the procedures defined in S 5 are being considered to obtain symmetric basic call control procedures that can be used, for example, in PABX-to-PABX applica- tions. All messages in this Recommendation may contain two types of information elements, functional and/or stimulus. Functional infor- mation elements are characterized as requiring a degree of intelli- gent processing by the terminal in either their generation or analysis. Stimulus information elements, on the other hand, are either generated as a result of single event at the user/terminal interface or contain a basic instruction from the network to be executed by the terminal. As a general principle, all the messages sent by the network to the user may contain a display information element whose con- tents may be displayed by the terminal; the content of this infor- mation element shall be network dependent. Note - Keypad facility information elements shall only be conveyed in the direction user to network. Display information ele- ments shall conveyed in the direction network to user. In addition to the messages exchanged as described in the following sections, INFORMATION messages for call control may be sent by the user or by the network only after the first response to a SETUP has been sent or received, and before clearing of the call reference is initiated. An INFORMATION message received in the release request state may be ignored. In order to accommodate the transfer of Layer 3 messages which exceeds the data link layer maximum frame length (i.e. defined in Recommendation Q.921) [3], a method of message segmentation and reassembly may optionally be implemented as described in Annex K. Message segmentation shall only be used where all the information comprising the unsegmented message is available at the time of sending the first message segment. Note - Message segmentation is not used to replace existing procedures where information is yet to be provided by call control, e.g. digit by digit sending in overlap mode, although this may be used in addition. Message segmentation shall only be used when the message length exceeds the value of the N201 parameter defined in Recommendation Q.921 [3]. 5.1 Call establishment at the originating interface Before these procedures are invoked, a reliable data link con- nection must be established between the user (TE/NT2) and the net- work. All layer 3 messages shall be sent to the data link layer using a DL-DATA-REQUEST primitive. The data link services described in Recommendations Q.920 (I.440) [45] and Q.921 [3] are assumed. 5.1.1 Call request A user initiates call establishment by transferring a SETUP message across the user-network interface. Following the transmis- sion of the SETUP message, the call shall be considered by the user to be in the call initiated state. The message shall always contain a call reference, selected according to the procedures given in S 4.3. In selecting a call reference, the dummy call reference value shall not be used. The bearer capability information element is mandatory in the SETUP message, even in the case of overlap sending. If the user knows all appropriate channels controlled by the D-channel are in use, it shall not transfer a SETUP message across the user-network interface. If the user does not monitor the status of channels in use, it may send a SETUP during an all channels busy condition. In this case the network returns a RELEASE COMPLETE mes- sage with cause No. 34, no circuit/channel available . Furthermore the SETUP message may also contain all or part of the call information (i.e. address and facility requests) necessary for call establishment depending on whether en-bloc or overlap pro- cedures are being used respectively (see S 5.1.3). If en-bloc sending is used, the SETUP message shall contain all the information required by the network to process the call, and, in particular, the called party address information if present, is contained as follows: a) in the called party number information element possibly completed by the called party subaddress information ele- ment; or, b) the keypad facility information element which may also be used to convey other call information. Note - The support of a) is mandatory in all networks. Whether the support of b) is mandatory or optional requires further study. For overlap sending, see S 5.1.3. 5.1.2 B-channel selection - originating In the SETUP message, the user will indicate one of the fol- lowing: a) channel is indicated, no acceptable alternative; or b) channel is indicated, any alternative is accept- able, or, c) any channel is acceptable. If no indication is included, alternative c) is assumed. In cases a) and b), if the indicated channel is available, the network selects it for the call. In case b), if the network cannot grant the preferred channel, it selects any other available B-channel associated with the D-channel. In case c), the network selects any available B-channel associated with the D-channel. The selected B-channel is indicated in the first message returned by the network in response to the SETUP message (i.e. a SETUP ACKNOWLEDGE or CALL PROCEEDING message). After transmitting this message, the network shall activate the B-channel connection. The user need not attach until receiving a CALL PROCEEDING/SETUP ACKNOWLEDGE/PRO GRESS/ALERTING message with the progress indicator No. 8 in-band information or appropriate pattern is now available or progress indication No. 1 call is not end-to-end ISDN; further call progress information may be available in-band . Prior to this time, the network cannot assume that the user has attached to the B-channel. After this time, the user shall be connected to the B-channel, provided the equipment does not gen- erate local tone. Upon receipt of the CONNECT message the user shall attach to the B-channel (if it has not already done so). In case a) if the specified channel is not available, and in cases b) and c) if no channel is available, a RELEASE COMPLETE mes- sage with cause No. 44 requested circuit/channel not available or No. 34 no circuit/channel available , respectively, is sent by the network as described in S 5.3. 5.1.3 Overlap sending If overlap sending is used, the SETUP message contains either: a) no called number information; or, b) incomplete called number information; or c) called number information which the network can- not determine to be complete. On receipt of such a SETUP message, the network starts timer T302 (the value of timer T302 is specified in S 9.1), sends a SETUP ACKNOWLEDGE message to the user, and enters the overlap sending state. In case a), the network will return dial tone, if required by the tone option. In this case it may include progress indicator No. 8 in-band information or appropriate pattern is now available in the SETUP ACKNOWLEDGE message. Note - Some networks which systematically provide the conven- tional telephone dial tone will not generate the progress indicator when providing the dial tone. When the SETUP ACKNOWLEDGE message is received, the user enters the overlap sending state and optionally starts timer T304 (the value of timer T304 is specified in S 9.2). After receiving the SETUP ACKNOWLEDGE message, the user sends the remainder of the call information (if any) in one or more INFORMATION messages. The called party number information may be provided by the user as follows: a) in the called party number information element; or, b) in the keypad facility information element, exclusively. The called party number must be sent in a unique way. Note 1 - The support of a) is mandatory in all networks. Whether the support of b) is mandatory or optional requires further study. Note 2 - Besides the possible called party number [conveyed by method a) or b) as described above], the INFORMATION messages may contain additional call information (i.e. for supplementary services). The interpretation of the contents of keypad facility information elements is network-specific, and in accordance with the dialling plan provided to that user. It should be noted that the user shall transfer all the additional call information (con- tained within the keypad facility information element) before the network determines that the called party number (contained within the called party number information element or the keypad facility information element) is complete, and terminates the overlap send- ing procedure using the CALL PROCEEDING message as recommended in S 5.1.5.2. If, for symmetry purposes, the user employs timer T304, the user restarts timer T304 when each INFORMATION message is sent. The call information in the message which completes the infor- mation sending may contain a sending complete indication, (e.g. the ## character or, as a network option, the sending complete infor- mation element) appropriate to the dialling plan being used. The network shall restart timer T302 on the receipt of every INFORMA- TION message not containing a sending complete indication. 5.1.4 Invalid call information If, following the receipt of SETUP message or during overlap sending, the network determines that the call information received from the user is invalid (e.g. invalid number), then the network shall initiate call clearing as defined in S 5.3 with a cause such as one of the following: No. 1 unassigned (unallocated) number ; No. 3 no route to destination ; No. 22 number changed ; No. 28 invalid number format (incomplete number) . 5.1.5 Call proceeding 5.1.5.1 Call proceeding, en-bloc sending If en-bloc sending is used (i.e. the network can determine that the SETUP message contains all the information required from the user to establish the call) and if the network can determine that access to the requested service is authorized and available, the network shall: send a CALL PROCEEDING message to the user to acknowledge the SETUP message and to indicate that the call is being processed; and enter the outgoing call proceeding state. When the user receives the CALL PROCEEDING message, the user shall enter the outgoing call proceeding state. Similarly, if the network determines that a requested service is not authorized or is not available, the network shall initiate call clearing in accordance with S 5.3 with one of the following causes: a) No. 57 bearer capability not authorized ; b) No. 58 bearer capability not presently available ; c) No. 63 service or option not available, unspeci- fied ; or d) No. 65 bearer service not implemented . Note - If a supplementary service is not authorized and is not available, the procedure to be used is defined in the supple- mentary service control procedures. 5.1.5.2 Call proceeding, overlap sending If overlap sending is used following the occurrence of one of these conditions: a) the receipt by the network of a sending com- plete indication which the network understands; or, b) analysis by the network that all call informa- tion necessary to effect call establishment has been received. and if the network can determine that access to the requested ser- vices and supplementary service is authorized and available, the network shall: send a CALL PROCEEDING message to the user; stop timer T302; and enter the outgoing call proceeding state. Similarly if the network determines that a requested service or supplementary service is not authorized or is not available, the network shall initiate call clearing in accordance with S 5.3 with one of the following causes: 1) No. 57 bearer capability not authorized ; 2) No. 58 bearer capability not presently available ; 3) No. 63 service or option not available, unspeci- fied ; or 4) No. 65 bearer service not implemented . Note 1 - The CALL PROCEEDING message is sent to indicate that the requested call establishment has been initiated, and no more call establishment information will be accepted. Note 2 - If a supplementary service is not authorized or is not available, the procedure to be used is defined in the supple- mentary service control procedures. When the user receives the CALL PROCEEDING message, the user shall enter the outgoing call proceeding state. If, for symmetry purposes, the calling user employs timer T304, the user shall stop timer T304 when the CALL PROCEEDING message is received. If, for symmetry purposes, the calling user employs timer T304 then, on expiry of T304, the user shall initiate call clearing in accordance with S 5.3 with cause No. 102 recovery on time expiry . An alerting or connect indication received from the called party will stop timer T302 and cause an ALERTING or CONNECT message respectively to be sent to the calling user. No CALL PROCEEDING message shall be sent by the network. If, for symmetry purposes, the calling user employs timer T304, the user shall stop timer T304 on receiving the ALERTING or CONNECT message. At the expiration of timer T302, the network shall: i) initiate call clearing in accordance with S 5.3 with cause No.28 invalid number format (incomplete number) sent to the calling user and with cause No.102 recovery on timer expiry is sent towards the called user, if the network determines that the call information is definitely incomplete; otherwise, ii) send a CALL PROCEEDING message and enter the outgoing call proceeding state. 5.1.6 Notification of interworking at the originating interface During call establishment, the call may leave an ISDN environ- ment; e.g. because of interworking with another network, with a non-ISDN user, or with non-ISDN equipment within the calling or called user's premises. When such situations occur, a progress indicator information element shall be returned to the calling user either: a) in an appropriate call control message when a state change is required (SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING or CONNECT); or b) in the PROGRESS message when no state change is appropriate. One of the following progress description values shall be included in the PROGRESS indicator information element in the mes- sage sent to the user (for further information, see Annex I): 1) No. 1 call is not end-to-end ISDN; further call progress information may be available in-band ; 2) No. 2 destination address is non-ISDN ; 3) No. 4 call has returned to the ISDN . Call is now end-to-end ISDN. If the PROGRESS indicator information element is included in a call control message, the procedures as described in the rest of S 5.1 apply. If the PROGRESS indicator information element is included in the PROGRESS message, no state change will occur but any supervisory timers shall be stopped. In both cases, if indi- cated by the PROGRESS indicator information element, the user shall connect to (if not connected already) and then monitor the B-channel for further in-band information. If the interface at which the progress indication originates is the point at which a call enters the ISDN environment from a non-ISDN environment, one or more of the following progress indica- tor information elements shall be included in the SETUP message sent to the network: i) No. 1 call is not end-to-end ISDN; further call progress information may be available in-band ; ii) No. 3 origination address is non-ISDN . 5.1.7 Call confirmation indication Upon receiving an indication that user alerting has been ini- tiated at the called address, the network shall: send an ALERTING message across the user-nerwork interface of the calling address; and enter the call delivered state. When the user receives the ALERTING message, the user: may begin an internally-generated alerting indication and shall enter the call delivered state. 5.1.8 Call connected Upon receiving an indication that the call has been accepted, the network shall: send a CONNECT message across the user-network interface to the calling user; and enter the active state. This message indicates to the calling user that a connection has been established through the network and stops a possible local indication of alerting. On receipt of the CONNECT message, the calling user: shall stop any user-generated alerting indications; may optionally send a CONNECT ACKNOWLEDGE message, and shall enter the active state. The network shall not take any action on receipt of a CONNECT ACK- NOWLEDGE message when it perceives the call to be in the active state. 5.1.9 Call rejection Upon receiving an indication that the network or the called user is unable to accept the call, the network shall initiate call clearing at the originating user-network interface as described in S 5.3, using the cause provided by the terminating network or the called user. 5.1.10 Transit network selection When the transit network selection information element is present, the call shall be processed according to Annex C. 5.2 Call establishment at the destination interface This procedure assumes that a data link connection providing services described in Recommendation Q.920 (I.440) [3] may not exist before the first layer 3 message (SETUP) is transferred across the interface. However, reliable data link connections must be established by each of the users (terminals and/or NT2s) at the interface before they respond to the SETUP message. Permanent data link connections are not precluded, and may be recommended as a national option. The SETUP message offered on a point-to-point data link shall be delivered to layer 2 using a DL-DATA-REQUEST primitive. No use shall be made of the DL-UNIT-DATA-REQUEST primitive other than for operation using the broadcast capability of the data link layer. The call reference contained in all messages exchanged across the user-network interface shall contain the call reference value specified in the SETUP message delivered by the network. In select- ing a call reference, the dummy call reference value shall not be used. 5.2.1 Incoming call The network will indicate the arrival of a call at the user-network interface by transferring a SETUP message across the interface. This message is sent if the network can select an idle B-channel. In some circumstances (e.g. provision of other bearer services S 6), the SETUP message may also be sent when no B-channel is idle. The number of calls presented in these circumstances may be limited. In addition to the mandatory information elements, the SETUP message may include, as required, the information elements described in S 3.1.16 (e.g. display, low layer compatibility). If a multipoint terminal configuration exists at the user-network interface, this message shall be sent using a broadcast capability at the data link layer. In this case, the SETUP message should contain the appropriate part of the called party number as required (e.g. for DDI) and/or sub-address if pro- vided. However, if the network has knowledge that a single-point configuration exists at the interface, a point-to-point data link shall be used to carry the SETUP message. After sending the SETUP message, the network starts timer T303. If the SETUP message was sent via a broadcast data link, timer T312 shall also be started. (The values of timers T303 and T312 are specified in S 9.1.) The network then enters the call present state. Note - Timer T312 is used to supervise the retention of the call reference when the SETUP message was transmitted by a broad- cast data link. The value of timer T312 is such that if a network disconnect indication is received during the call establishment phase, it maximizes the probability that all responding users will be released prior to release of the call reference. Refer to S 5.3.2 (e) for procedures to be followed on expiry of timer T312. If en-bloc receiving is used, the SETUP message shall contain all the information required by the called user to process the call. In this case, the SETUP message may contain the sending com- plete information element. Upon receipt of a SETUP message, the user will enter the call present state. Depending on the contents of the received message, either en-bloc receiving procedure (see S 5.2.5.1) or overlap receiving procedure (see S 5.2.4) follows. However, if the SETUP message includes the sending complete information element, en-bloc receiv- ing procedure shall follow. Therefore, those users who support overlap receiving procedure shall recognize the sending complete information element. Note - Users supporting only the en-bloc receiving procedure need not recognize the sending complete information element and may directly analyze the received SETUP message on the assumption that all the call information is contained in the message. If no response to the SETUP message is received by the network before the first expiry of timer T303, the SETUP message will be retransmitted and timers T303 and T312 restarted. Note - In the case of overlap sending within the network, the appropriate part of the called party number as required (e.g. for DDI) may also be conveyed by means of INFORMATION messages to the called user on a point-to-point data link (see S 5.2.4). 5.2.2 Compatibility checking A user receiving a SETUP message shall perform compatibility checking before responding to that SETUP message. Any reference to "user" in SS 5.2.3 through 5.2.7 implicitly refers to a compatible user equipment. Annex B defines compatibility checking to be performed by users upon receiving a SETUP message. When the SETUP message was delivered via a broadcast data link, an incompatible user shall either: a) ignore the incoming call; or, b) respond by sending a RELEASE COMPLETE message with cause No. 88 incompatible destination , and enter the Null state. The network processes this RELEASE COMPLETE message in accordance with S 5.2.5.3. When the SETUP message was delivered via a point-to-point data link, an incompatible user shall respond with RELEASE COMPLETE mes- sage with cause No. 88 incompatible destination , and enter the Null state. The network shall process this RELEASE COMPLETE message in accordance with S 5.2.5.3. 5.2.3 B-channel selection - destination 5.2.3.1 SETUP message delivered by point-to-point data link When the SETUP message is delivered by a point-to-point data link, negotiation for the selection of a B-channel will be permit- ted between the network and the user. Only B-channels controlled by the same D-channel will be the subject of the selection procedure. The selection procedure is as follows: a) In the SETUP message, the network will indicate one of the following: 1) channel is indicated, no acceptable alternative, or, 2) channel is indicated, any alternative is accept- able; or, 3) any channel is acceptable; or, 4) no B-channel available. Note - Not all networks will support the no B-channel available condition. b) In cases 1) and 2), if the indicated channel is acceptable and available, the user selects it for the call. In case 2), if the user cannot grant the indicated chan- nel, it selects any other available B-channel associated with the D-channel, and identifies that channel in the first message sent in response to the SETUP message. In case 3), the user selects any available B-channel asso- ciated with the D-channel, and identifies that channel in the first message sent in response to the SETUP message. If in case 1) the B-channel indicated in the first response message is not the channel offered by the network, or in cases 2) and 3) the B-channel indicated in the first response mes- sage is unacceptable to the network, it will clear the call by sending a RELEASE message with cause No.6 channel unacceptable [see S 5.3.2 | )]. in case 4), the user rejects the call by sending RELEASE COMPLETE message with cause No. 34 no circuit/channel available unless it is able to proceed with the call. The user wishing to re-use a B-channel it has already allocated to another call (e.g. by releasing, or holding it, or by multiplexing packet calls) shall send the appropriate message containing the channel identifi- cation information element, coded as channel is indicated, no alternative acceptable . c) If no channel identification information ele- ment is present in the first response message, the B-channel indi- cated in the SETUP message will be assumed. d) When a B-channel has been selected by the user, that channel may be connected by the user. e) In case 1) if the indicated B-channel is not available, or in cases 2), 3), and 4) if no B-channel is available and the user cannot proceed with the offered call, the user returns a RELEASE COMPLETE message with cause No. 44 requested circuit/channel not available or No. 34 no circuit/channel avail- able , respectively, and returns to the Null state. 5.2.3.2 SETUP message delivered by broadcast data link When the SETUP message is delivered by a broadcast data link the channel selection procedure, provided in S 5.2.3.1, is not applicable. The network sends a SETUP message with the channel identification information element indicating one of the following: a) channel indicated, no alternative is acceptable; or, b) no channel available. The network starts timers T303 and T312. In case a), if the user can accept the call on the indicated channel, the user shall send the appropriate message (see SS 5.2.4 and 5.2.5). If the user cannot accept the call on the indicated channel, the user shall send a RELEASE COMPLETE message with cause No. 44 requested circuit/channel not available . The user, in any case, must not connect to the channel until a CONNECT ACKNOWLEDGE message has been received. In case b), the user not controlling any channel shall send a RELEASE COMPLETE message with cause No. 34 no circuit/channel available . The user wishing to re-use a B-channel it has already allocated to another call (e.g. by releasing, or holding it, or by multiplexing packet calls) shall send the appropriate message con- taining the channel identification information element, coded as channel is indicated, no alternative acceptable . 5.2.4 Overlap receiving When a user determines that a received SETUP message contains either: a) no called number information; or, b) incomplete called number information; or, c) called number information which the user cannot determine to be complete; and when the user: d) is compatible with other call characteristics (see Annex B); and, e) implements overlap receiving; the user shall: start timer T302; send a SETUP ACKNOWLEDGE message to the network; and enter the overlap receiving state. When the SETUP ACKNOWLEDGE message is received, the network shall: stop timer T303; start timer T304; enter the overlap receiv- ing state; and send the remainder of the call information (if any) in one or more INFORMATION messages, starting timer T304 when each INFORMATION message is sent. The called party number information is provided in the called party number information element. The call address information may contain a sending complete indication (e.g. No. or, as a network option, the sending complete information element) appropriate to the dialling plan being used. Note - If the network can determine that sufficient call setup information will be received by the called user by sending the next INFORMATION message, it is recommended that the INFORMA- TION message contains the sending complete information element. The user shall START TIMER T302 on receipt of every INFORMA- TION message not containing a sending complete indication. Following the receipt of a sending complete indication which the user understands, or the determination that sufficient call information has been received, the user shall stop timer T302 (if implemented) and send a CALL PROCEEDING message to the network. Alternatively, depending on internal events, the user may send an ALERTING or a CONNECT message to the network. Note - The CALL PROCEEDING message in this case will cause that the originating exchange to send a CALL PROCEEDING message to the originating user, if not already sent (see for example Recom- mendation Q.699). At the expiration of timer T302 the user shall: a) initiate clearing in accordance with S 5.3 with cause No. 28 invalid number format (incomplete number) if it deter- mines that the call information is definitely incomplete; or, b) if sufficient information has been received, send a CALL PROCEEDING, ALERTING or CONNECT message as appropriate. At the expiration of timer T304 the network initiates call clearing in accordance with S 5.3, with cause No. 28 invalid number format (incomplete number) sent to the calling user, and cause No. 102 recovery on timer expiry sent to the called user. If, following the receipt of a SETUP message or during overlap receiving, the user determines that the received call information is invalid (e.g. invalid called party number), it shall initiate call clearing in accordance with S 5.3 with a cause such as one of the following: No. 1 unassigned (unallocated) number ; No. 3 no route to destination ; No. 22 number changed ; No. 28 invalid number format (incomplete number) . Upon receipt of the complete call information the user may further perform some compatibility checking functions, as outlined in Annex B. When the call is offered on a point-to-point data link, only one SETUP ACKNOWLEDGE message can be received in response to the call offering. When the call is offered to the user on a broadcast data link, multiple SETUP ACKNOWLEDGE messages may be received by the network which shall then complete as many overlap receiving procedures as such SETUP ACKNOWLEDGE messages were received. It is the network responsibility to limit the number of over- lap receiving procedures to be completed for a given call. The default maximum is fixed to eight. Some networks will limit the call offering completion in overlap receiving to single data link and will therefore clear the subsequent responding users after the first SETUP ACKNOWLEDGE message has been received, in accordance with the non-selected user clearing procedures described in S 5.2.9. 5.2.5 Call confirmation 5.2.5.1 Response to en-bloc SETUP or completion of overlap receiving When the user determines that sufficient call setup informa- tion has been received and compatibility requirements (see Annex B) have been satisfied, the user responds with either a CALL PROCEED- ING, ALERTING, or CONNECT message (see Note 2), and enters the incoming call proceeding , call received, or connect request state, respectively. Note 1 - The possibility of alternative responses (e.g. in connection with supplementary services) is for further study. Note 2 - A progress indicator information element may be included in CALL PROCEEDING, ALERTING, and CONNECT message (e.g. when an analogue terminal is connected to an ISDN PABX). The CALL PROCEEDING message may be sent by the user which cannot respond to a SETUP message with an ALERTING, CONNECT, or RELEASE COMPLETE message before expiration of timer T303. When the SETUP message was delivered via a broadcast data link, an incompatible user shall either: a) ignore the incoming call; or, b) respond by sending a RELEASE COMPLETE message with cause No. 88 incompatible destination , and enter the Null state. The network processes this RELEASE COMPLETE message in accordance with S 5.2.5.3. When the SETUP message was delivered via a point-to-point data link, an incompatible user shall respond with a RELEASE COMPLETE message with cause No. 88 incompatible destination . The network processes this RELEASE COMPLETE message in accordance with S 5.2.5.3. A busy user which satisfies the compatibility requirements indicated in the SETUP message shall normally respond with a RELEASE COMPLETE message with cause No. 17 user busy . The network processes this RELEASE COMPLETE message in accordance with S 5.2.5.3. If the user wishes to refuse the call, a RELEASE COMPLETE mes- sage shall be sent with the cause No. 21 call rejected , and the user returns to the Null state. The network processes this RELEASE COMPLETE message in accordance with S 5.2.5.3. 5.2.5.2 Receipt of CALL PROCeeding and ALERTing When the SETUP message is delivered on a broadcast data link, the network shall maintain a state machine that tracks the overall progression of the incoming call. The network shall also maintain an associated call state for each responding user as determined by the data link on which a message is received. Upon receipt of the first CALL PROCEEDING message from a user (assuming no other user had previously responded with an ALERTING or CONNECT message when the SETUP message has been delivered on a broadcast data link), the network shall: stop timer T303 (or, in the case of overlap receiving, timer T304 for that user); start timer T310; and enter the incoming call proceeding state. When the SETUP message has been delivered on a broadcast data link, the network shall (at a minimum) associate the incoming call proceeding state with each called user that sends a CALL PROCEEDING message as a first response to the broadcast SETUP message prior to expiration of timer T312. Actions to be taken when a user sends a first response to an incoming call after the expiration of timer T312 are described in S 5.2.5.4. Timer T310 shall not be res- tarted. Upon receipt of the first ALERTING message from a user (assum- ing no other user has previously responded with a CONNECT message when the SETUP message has been delivered on a broadcast data link), the network shall: stop timer T304 for that user (in the case of overlap receiving); stop timer T303 or T310 (if running); start timer T301 (unless another internal alerting supervision timer function exists; e.g. incorporated in call control); enter the call received state; and send a corresponding ALERTING message to the calling user. When the SETUP message has been delivered on a broadcast data link, the network shall (at a minimum) associate the call received state with each called user that sends an ALERTING message either as a first response to the broadcast SETUP message or following a CALL PROCEEDING message. Timer T304 shall not be restarted. 5.2.5.3 Called user clearing during incoming call estab- lishment If the SETUP message has been delivered on a point-to-point data link and a RELEASE COMPLETE or DISCONNECT message is received before a CONNECT message has been received, the network shall: stop timer T303, T304, T310 or T301 (if running); continue to clear the user as described in S 5.3.3, and clear the call to the calling user with the cause received in the RELEASE COMPLETE or DISCONNECT message. If the SETUP message has been delivered on a broadcast data link and a RELEASE COMPLETE message is received whilst timer T303 is running, the message cause shall be retained by the network. If timer T303 expires (i.e. if no valid message such as CALL PROCEED- ING, ALERTING or CONNECT has been received) the cause previously retained when a RELEASE COMPLETE message was received is sent back to the calling user in a DISCONNECT message and the network shall enter the call abort state. When multiple RELEASE COMPLETE messages are received with different causes, the network shall: 1) ignore any cause No. 88 incompatible destination ; and, 2) give preference to the following causes (if received) in the order listed below: (highest) No. 17 user busy ; No. 21 call rejected ; 3) any other received cause may also be included in the clearing message sent to the originating user (see S 5.3). If the SETUP message has been delivered on a broadcast data link and a user which has previously sent a SETUP ACKNOWLEDGE, CALL PROCEEDING or ALERTING message sends a DISCONNECT message to the network, the actions taken by the network depend on whether timer T312 is running and whether other called users have responded to the SETUP message. Case 1 | DISCONNECT received prior to expiry of timer T312 If timer T312 is running and the network receives a DISCONNECT message after having received a SETUP ACKNOWLEDGE, CALL PROCEEDING or ALERTING message from a called user (but before receiving a CON- NECT message), timer T312, as well as timer T310 or T301 (if run- ning), should continue to run. The network shall retain the cause in the DISCONNECT message and shall continue to clear the user as described in S 5.3.3. The network shall stop timer T304 (if run- ning) for this user. Upon expiration of timer T312, if either: a) no other users have responded to the incoming call; or b) all users that have responded to the incoming call have been cleared or are in the process of being cleared: the network shall stop timer T310 or T301 (if running) and shall clear the call to the calling user. If an ALERTING message has been received, the cause sent to the calling user shall be a cause received from the called user, giving preference to (in order of priority): No. 21 call rejected ; any other cause sent by a called user. If only SETUP ACKNOWLEDGE, or CALL PROCEEDING messages have been received, the cause sent to the calling user shall be a cause received from the called user, giving preference to (in order of priority): No. 17 user busy ; No. 21 call rejected ; any other appropriate cause sent by a called user. Case 2 | DISCONNECT received after expiry of timer T312 If timer T312 has expired and the network receives a DISCON- NECT message from the called user after having received a SETUP ACKNOWLEDGE, CALL PROCEEDING or ALERTING message (but before receiving a CONNECT message), the network shall continue to clear the user as described in S 5.3.3. The network shall stop timer T304 (if running) for this user. If other called users have responded to the SETUP message with a SETUP ACKNOWLEDGE, CALL PROCEEDING or ALERTING message, and still have the opportunity to accept the call by sending a CONNECT mes- sage, the network shall retain the cause in the DISCONNECT message. The network shall continue to process the incoming call for the remaining responding users (T310 or T301, if running, shall con- tinue to run). If either: a) no other users have responded to the incoming call; or b) all users that have responded to the incoming call have been cleared or are in the process of being cleared: the network shall stop timer T310 or T301 (if running) and shall clear the call to the calling user. If an ALERTING message has been received, the cause sent to the calling user shall be a cause received from the called user, giving preference to (in order of priority): No. 21 call rejected ; or any other cause sent by a called user. If only SETUP ACKNOWLEDGE, or CALL PROCEEDING message have been received, the cause sent to the calling user shall be a cause received from the called user, giving preference to (in order of priority): No. 17 user busy ; No. 21 call rejected ; any other appropriate cause sent by a called user. 5.2.5.4 Call failure If the network does not receive any response to the retransmitted SETUP message prior to the expiration of timer T303, then the network shall initiate clearing procedures towards the calling user with cause No. 18 no user responding . a) If the SETUP message was delivered by a broad- cast data link, the network shall enter the call abort state. b) if the SETUP message was delivered on a point-to-point data link, the network shall also initiate clearing procedures towards the called user in accordance with S 5.3.4, using cause No. 102 recovery on timer expiry . If the network receives a user's first response to SETUP when in the call abort state but before timer T312 has expired, the net- work shall initiate clearing to the called user as described in S 5.3.2 | ), except that the cause No. 102 recovery on timer expiry shall be sent. If the network receives a message that is a user's first response to an incoming call after timer T312 has expired, the network will interpret this message as a message received with an invalid call reference value, as described in S 5.8.3.2. If the network has received a CALL PROCEEDING message, but does not receive an ALERTING, CONNECT, or DISCONNECT message prior to the expiration of timer T310, then the network shall: initiate clearing procedures towards the calling user with cause No. 18 no user responding ; and initiate clearing procedures towards the called user. 1) If the SETUP message was delivered by a broad- cast data link, the called user shall be cleared in accordance with S 5.3.2 | ), except that cause No. 102 recovery on timer expiry shall be sent. 2) If the SETUP message was delivered on a point-to-point data link, the called user shall be cleared in accordance with S 5.3.4 using cause No. 102 recovery on timer expiry . If the network has received an ALERTING message, but does not receive a CONNECT or DISCONNECT message prior to the expiry of timer T301 (or a corresponding internal alerting supervision timing function), then the network shall: initiate clearing procedures towards the calling user with cause No. 19 user alerting, no answer ; and initiate clearing procedures towards the called user. i) If the SETUP message was delivered by a broad- cast data link, the called user shall be cleared in accordance with S 5.3.2 | ), except that cause No. 102 recovery on timer expiry shall be sent. ii) If the SETUP message was delivered on a point-to-point data link, the called user shall be cleared in accordance with S 5.3.4 using cause No. 102 recovery on timer expiry . 5.2.6 Notification of interworking at the terminating interface During call establishment, the call may enter an ISDN environ- ment, e.g. because of interworking with another network, with a non-ISDN user, or with non-ISDN equipment within the calling or called user's premises. When this occurs, the point at which call enters an ISDN environment shall cause a progress indicator infor- mation element to be included in the SETUP message to be sent to the called user. a) No. 1 call is not end-to-end ISDN; further call progress information may be available in-band ; Note - On receipt of progress indicator No. 1, the called user shall connect to the B-channel in accordance with the pro- cedures of S 5.2.8. b) No. 3 origination address is non-ISDN . In addition, the user shall notify the calling party if the call has left the ISDN environment within the called user's prem- ises, or upon the availability of in-band information/patterns. When such situations occur, a progress indication shall be sent by the user to the network either: 1) in an appropriate call control message when a state change is required (SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING or CONNECT); or 2) in the PROGRESS message when no state change is appropriate. One of the following progress description values shall be included in the progress indicator information element in the mes- sage sent to the network (for further information, see Annex I): i) No. 1 call is not end-to-end ISDN; further call progress information may be available in-band ; ii) No. 2 destination address is non-ISDN ; iii) No. 4 call has returned to the ISDN . If the progress indicator information element is included in a call control message, the procedures as described in the rest of S 5.2 apply. If the progress indicator information element is included in the PROGRESS message, no state change will occur but any supervisory timers shall be stopped. 5.2.7 Call accept A user indicates acceptance of an incoming call by sending a CONNECT message to the network. Upon sending the CONNECT message the user shall start timer T313 (the value of timer T313 is speci- fied in S 9.2). If an ALERTING message had previously been sent to the network, the CONNECT message may contain only the call refer- ence. If a call can be accepted using the B-channel indicated in the SETUP message, and no user alerting is required, a CONNECT message may be sent without a previous ALERTING message. Note - Further study is required on the need for means to avoid service degradation (e.g. speech clipping) on connections involving an NT2. 5.2.8 Active indication On receipt of the first CONNect message, the network shall: stop (if running) timers T301, T303, T304 and T310; complete the circuit-switched path to the selected B-channel; send a CONNECT ACKNOWLEDGE message to the user which first accepted the call; ini- tiate procedures to send a CONNECT message towards the calling user; and enter the active state. The CONNECT ACKNOWLEDGE message indicates completion of the circuit-switched connection. There is no guarantee of an end-to-end connection until a CONNECT message is received at the calling user. Upon receipt of the CONNECT ACKNOWLEDGE message the user shall: stop timer T313 and enter the active state. When timer T313 expires prior to receipt of a CONNECT ACK- NOWLEDGE message, the user shall initiate clearing in accordance with S 5.3.3 A user which has received the SETUP via the broadcast data link, and has been awarded the call, shall connect to the B-channel only after it has received the CONNECT ACKNOWLEDGE message. Only the user that is awarded the call will receive the CONNECT ACK- NOWLEDGE message. A user which has received the SETUP via a point-to-point data link may connect to the B-channel as soon as channel selection has been completed. 5.2.9 Non-selected user clearing In addition to sending the CONNECT ACKNOWLEDGE message to the user selected for the call, the network shall send RELEASE message [as described in S 5.3.2 | )] to all other users at the interface that have sent SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING or CON- NECT messages in response to the SETUP message. These RELEASE mes- sages are used to notify the users that the call is no longer offered to them. The procedures described in S 5.3.4 are then fol- lowed. Any user which having previously sent a CONNECT message and started timer T313, and which subsequently receives a RELEASE mes- sage, shall stop timer T313 and follow the procedures of S 5.3.4. 5.3 Call clearing 5.3.1 Terminology The following terms are used in this Recommendation in the description of clearing procedures: - A channel is connected when the channel is part of a circuit-switched ISDN connection established according to this Recommendation. - A channel is disconnected when the channel is no longer part of a circuit-switched ISDN connection, but is not yet available for use in a new connection. - A channel is released when the channel is not part of a circuit-switched ISDN connection and is available for use in a new connection. Similarly, a call reference that is released is available for reuse. 5.3.2 Exception conditions Under normal conditions, call clearing is usually initiated when the user or the network sends a DISCONNECT message and follows the procedures defined in SS 5.3.3 and 5.3.4 respectively. The only exceptions to the above rule are as follows: a) In response to a SETUP message, the user or net- work can reject a call (e.g. because of the unavailability of a suitable B-channel) by: responding with a RELEASE COMPLETE message provided no other response has previously been sent (e.g. the SETUP ACKNOWLEDGE message in the case of overlap sending); releasing the call reference; and enter the Null state. b) In the case of a multipoint terminal configura- tion, non-selected user call clearing will be initiated with RELEASE message(s) from the network (see S 5.2.9). The RELEASE mes- sage shall contain cause No. 26 non-selected user clearing . c) Clearing of temporary signalling connections will be initiated by sending a RELEASE message as described in SS 5.3.3 and 5.3.4. d) Unsuccessful termination of the B-channel selec- tion procedure (see SS 5.2.3.1 and 5.1.2) by the side offering the call is accomplished by sending a RELEASE message as described in SS 5.3.3 and 5.3.4. The RELEASE message shall contain cause No. 6 channel unacceptable . e) 1) In the case of a SETUP message sent via the broadcast data link, if a network disconnect indication is received during call establishment, and prior to the expiry of timer T312, timer T303 is stopped (if running) and the network enters the call abort state. Any user which has responded, or sub- sequently responds before timer T312 expires, will be cleared by a RELEASE message (with the cause code(s) contained in the network disconnect indication) and the procedures of S 5.3.4 are then fol- lowed for that user. Upon expiry of timer T312, the network shall treat any subsequent responses according to the procedures defined in S 5.8.3.2. The network shall enter the Null state upon comple- tion of clearing procedures for all responding users. 2) In the case of a SETUP message sent via the broadcast data link, if a network disconnect indication is received during call establishment after expiry of timer T312, any user which has responded shall be cleared by a RELEASE message (with the cause code(s) contained in the network disconnect indication) and the procedures of S 5.3.4 are then followed for that user. The net- work enters the Null state upon completion of clearing procedures for all responding users. Note - A separate state machine exists for each responding user. f ) When timer T318 expires, the user initiates internal call clearing by sending a RELEASE message with cause No. 102 recovery on timer expiry ; starting timer T308; and continuing as described in S 5.3.3. 5.3.3 Clearing initiated by the user Apart from the exceptions identified in SS 5.3.2 and 5.8, the user shall initiate clearing by: sending a DISCONNECT message; starting timer T305 (the value of timer T305 is specified in S 9.2); disconnecting the B-channel; and entering the disconnect request state. Note - When a user initiates call clearing by sending a RELEASE message, the procedures described in S 5.3.4 are then fol- lowed. The network shall enter the disconnect request state upon receipt of a DISCONNECT message. This message then prompts the net- work to disconnect the B-channel, and to initiate procedures for clearing the network connection to the remote user. Once the B-channel used for the call has been disconnected, the network shall: send a RELEASE message to the user; start timer T308 (the value of a timer T.308 is specified in S 9.1); and enter the release request state. Note - The RELEASE message has only local significance and does not imply an acknowledgement of clearing from the remote user. On receipt of the RELEASE message the user shall: cancel timer T305; release the B-channel; send a RELEASE COMPLETE message; release the call reference; and return to the Null state. Following the receipt of a RELEASE COMPLETE message from the user, the net- work shall: stop timer T308; release both the B-channel and the call reference; and return to the Null state. If timer T305 expires, the user shall: send a RELEASE message to the network with the cause number originally contained in the DISCONNECT message; start timer T308 and enter the release request state. In addition, the user may indicate a second cause informa- tion element with cause No. 102 recovery on timer expiry . If timer T308 expires for the first time, the network shall: retransmit the RELEASE message and timer T308 shall be restarted. In addition, the network may indicate a second cause information element with cause No. 102 recovery on timer expiry . If no RELEASE COMPLETE message is received from the user before timer T308 expires a second time, the network shall: place the B-channel in a maintenance condition; release the call reference; and return to the Null state. Note 1 - The restart procedures contained in S 5.5 may be used on B-channels in the maintenance condition. Note 2 - Other actions which could be taken by the network upon receipt of a DISCONNECT message are for further study. 5.3.4 Clearing initiated by the network Apart from the exception conditions identified in SS 5.3.2 and 5.8, the network shall initiate clearing by: sending a DISCONNECT message; and entering the disconnect indication state. The DISCON- NECT message is a local invitation to clear and does not imply that the B-channel has been disconnected at the user-network interface. Note - When the network initiates clearing by sending a RELEASE message, the procedures described in S 5.3.3 are followed. 5.3.4.1 Clearing when tones/announcements provided When in-band tones/announcements are provided (see S 5.4), the DISCONNECT message contains progress indicator No. 8 in-band infor- mation or appropriate pattern now available . The network shall: start timer T306; and enter the disconnect indication state. On receipt of the DISCONNECT message with progress indicator No. 8, the user may: connect (if not already connected) to the B-channel to receive the in-band tone/announcement; and enter the disconnect indication state. Alternatively, to continue clearing without connecting to the in-band tone/announcement, the user shall: disconnect the B-channel; send a RELEASE message; start timer T308; and enter the release request state. If the user connects to the provided in-band tone/announcement, the user may subsequently continue clearing (before the receipt of a RELEASE from the network) by: disconnect- ing from the B-channel; sending a RELEASE message; starting timer T308; and entering the release request state. On receipt of the RELEASE message, the network shall: stop timer T306; disconnect and release the B-channel; send a RELEASE COMPLETE message; release the call reference; and return to the Null state. If timer T306 expires, the network shall continue clearing by: disconnecting the B-channel; sending a RELEASE message with the cause number originally contained in the DISCONNECT message; start- ing timer T308; and entering the release request state. In addition to the original clearing cause, the RELEASE mes- sage may contain a second cause information element with cause No. 102 recovery on timer expiry ; this cause may optionally contain a diagnostic field identifying the timer that expired. On receipt of the RELEASE message, the user shall act accord- ing to S 5.3.3. 5.3.4.2 Clearing when tones/announcements not provided When in-band tones/announcements are not provided, the DISCON- NECT message does not contain progress indicator No. 8 in-band information or appropriate pattern now available . The network shall initiate clearing by: sending the DISCONNECT message; start timer T305; disconnects the B-channel; and enters the disconnect indication state. On the receipt of the DISCONNECT message without progress indicator No. 8, the user shall: disconnect the B-channel; send a RELEASE message; start timer T308; and enter the release request state. On receipt of the RELEASE message, the network shall: stop timer T305; release the B-channel; send a RELEASE COMPLETE message; release the call reference; and return to the Null state. If timer T305 expires, the network shall: send a RELEASE mes- sage to the user with the cause number originally contained in the DISCONNECT message; start timer T308; and enter the release request state. In addition to the original clearing cause, the RELEASE mes- sage may contain a second cause information element with cause No. 102 recovery on timer expiry . 5.3.4.3 Completion of clearing Following the receipt of a RELEASE COMPLETE message from the network, the user shall: stop timer T308; release both the B-channel and the call reference; and return to the Null state. If a RELEASE COMPLETE is not received by the user before the first expiry of timer T308, the RELEASE message shall be retransmitted and timer T308 shall be restarted. If no RELEASE COMPLETE message is received from the network before timer T308 expires a second time, the user may: place the B-channel in a maintenance condition; shall release the call reference; and return to the Null state. Note - The restart procedures contained in S 5.5 may be used on B-channels in the maintenance condition. 5.3.5 Clear collision Clear collision occurs when both the user and the network simultaneously DISSCONNECT messages specifying the same call refer- ence value. When the network receives a DISSCONNECT message whilst in the disconnect indication state, the network shall: stop timer T305 or T306 (whichever is running); disconnect the B-channel (if not disconnected); send a RELEASE message; start timer T308; and enter the release request state. Similarly, when the user receives a DISCONNECT message whilst in the disconnect request state, the user shall: stop timer T305; send a RELEASE message; start timer T308; and enter the release request state. Clear collision can also occur when both sides simultaneously transfer RELEASE messages related to the same call reference value. The entity receiving such a RELEASE message whilst within the release request state shall: stop timer T308; release the call reference and B-channel; and enter, if appropriate, the Null state (without sending or receiving a RELEASE COMPLETE message). 5.4 In-band tones and announcements When in-band tones/announcements not associated with a call state change are to be provided by the network before reaching the active state, a PROGRESS message is returned simultaneously with the application of the in-band tone/announcement. The PROGRESS mes- sage contains the progress indicator No. 8 in-band information or appropriate pattern is now available . When tones/announcements have to be provided together with a call state change, then the appropriate message (e.g. for ALERTING, DISCONNECT etc.; see appropriate section) with progress indicator No. 8 in-band information or appropriate pattern is now available is sent simultaneously with the application of the in-band tone/announcement. Note 1 - When the network provides CCITT standardized telecommunications services, the service requirement for provision of in-band tones/announcements is as indicated in the I.200 Series of Recommendations. Note 2 - When the PROGRESS message is used, the user may ini- tiate call clearing as a result of the applied in-band tone/announcement, according to the procedures specified in S 5.3.3. Note 3 - The protocol currently described in S 5.4 applies at the calling user-network interface. The protocol to be applied at the internetwork interface and at the called user-network interface requires further study. 5.5 Restart procedure The restart procedure is used to return channels and inter- faces to an idle condition. The procedure is usually invoked when the other side of the interface does not respond to other call con- trol messages or a failure has occurred (e.g. following a data link failure, when a backup D-channel can be used; or following the expiry of timer T308 due to the absence of response to a clearing message). Note - Layer 3 procedures and resources associated with those data links with SAPI = "0000 | 00" should be initialized by the restart procedures. When: a) both the user and the network are aware of the configuration of the interface; and b) the interface is a basic access (Recommendation I.430 [46]) where a point-to-point configuration exists; or, c) the interface is a primary rate access (Recommendation I.431 [27]); then the user and the network shall implement the procedures of S 5.5. In all other cases, the procedures of S 5.5 are optional. 5.5.1 Sending RESTART A RESTART message is sent by the network or user in order to return channels or interfaces to the Null state. The channel iden- tification information element must be present in the RESTART mes- sage when a specified channel, or interface other than the one con- taining the D-channel, is to be returned to the idle condition. Absence of the channel identification information element indicates that the interface containing the D-channel is to be restarted. Upon transmitting the RESTART message the sender enters the restart request state, starts timer T316, and waits for a RESTART ACKNOWLEDGE message. Receipt of a RESTART ACKNOWLEDGE message stops timer T316, frees the channels and call reference values for reuse, and enters the Null state. If a RESTART ACKNOWLEDGE message is not received prior to expiry of timer T316 one or more subsequent RESTART messages may be sent until a RESTART ACKNOWLEDGE message is returned. Meanwhile, no calls shall be placed or accepted over the channel or interface by the originator of the RESTART message. A network shall limit the number of consecutive unsuccessful restart attempts to a default limit of two. When this limit is reached, the network shall make no further restart attempts. An indication will be provided to the appropriate maintenance entity. The channel or interface is con- sidered to be in an out-of-service condition until maintenance action has been taken. The RESTART and RESTART ACKNOWLEDGE message shall contain the global call reference value (all zero) to which the restart request state is associated. These messages are transferred via the appropriate point-to-point data link in the multiple frame mode using the DL-DATA-REQUEST primitive. 5.5.2 Receipt of RESTART Upon receiving a RESTART message the recipient shall enter the restart state associated to the global call reference and start timer T317; it shall then initiate the appropriate internal actions to return the specified channels to the idle condition and call references to the Null state. Upon completion of internal clearing, timer T317 shall be stopped and a RESTART ACKNOWLEDGE message transmitted to the originator, and the Null state entered. If timer T317 expires prior to completion of internal clearing an indication shall be sent to the maintenance entity (i.e. a prim- itive should be transmitted to the system management entity). Note 1 - Even if all call references are in the Null state, and all channels are in the idle condition, the receiving entity shall transmit a RESTART ACKNOWLEDGE message to the originator upon receiving a RESTART message. Note 2 - If the RESTART message is sent by a user, the net- work shall return to the Null state only those Q.931 calls which are: a) associated with the data link connection end- point identifier (DLCI; see Recommendation Q.920); and b) which correspond to the specified channel(s) or interface. 5.6 Call rearrangements The elements of procedure in this section provide for physical layer and/or data link layer rearrangements after a call has entered the active state as defined in S 2.2.1.5. The procedure is restricted to use on the same interface structure, and resumption on the same B-channel. The activation of this procedure at a user-network interface may correspond to a number of possible events such as the following: a) physical disconnection of user equipment and reconnection; b) physical replacement of one user equipment by another; c) the human user moves from one equipment to another; d) suspension of call and its subsequent reactiva- tion at the same user equipment. These procedures have only local significance; i.e. the invo- cation of call rearrangement affects only states at the originating end, and it does not affect any terminating states. The procedures in this section are described in terms of func- tional messages and information elements. If the procedures for call suspension in this section are not followed prior to the physical disconnection of the terminal from the interface, then the integrity of the call cannot be guaranteed by the network. 5.6.1 Call suspension The procedure is initiated by the user, who shall: send a SUSPEND message containing the current call reference; start timer T319; and enter the suspend request state. The user may optionally include in this message a bit sequence (e.g. IA5 characters) to be known by the application or human user, and by the network, as the call identity for subsequent reconnec- tion. Where no call identity information is included by the user, (e.g. the call identity information element is absent or empty) the network shall store this fact so that resumption is possible only by a procedure conveying no call identity information. Note - If the call identity information element is present with a null length, the message shall be handled as if it was absent. The default maximum length of the call identity value within the call identity information element is eight octets. If the net- work receives a call identity value longer than the maximum length supported, the network shall truncate the call identity value to the maximum length; take the action specified in S 5.8.7 and con- tinue processing. 5.6.2 Call suspended Following the receipt of a SUSPEND message the network enters the suspend request state. After a positive validation of the received call identity the network shall: send a SUSPEND ACK- NOWLEDGE message; and start timer T307. (The value of T307 is specified in S 9.1.) At this time, the network shall consider the call reference to be released and enter the Null state for that call reference. The call identity associated with the suspended call has to be stored by the network and cannot be accepted for another suspension until it is released. The B-channel involved in the connection will be reserved by the network until reconnection of the call (or until a clearing cause occurs, e.g. expiry of timer T307). A NOTIFY message with notification indicator No. 0 (user suspended) is sent to the other user. When the user receives the SUSPEND ACKNOWLEDGE message, the user shall: stop timer T319; release the B-channel and call refer- ence; and enter the Null state. Following the receipt of the SUSPEND ACKNOWLEDGE, the user may disconnect the underlying data link connection. In any case, if the user physically disconnects from the interface without having disconnected the data link connection, standard data link layer procedures are started by the network side of the data link layer supervision, resulting in the release of the data link layer con- nection. 5.6.3 Call suspend error On receipt of a SUSPEND message, the network will respond by sending a SUSPEND REJECT message with cause No. 84 call identity in use if the information contained in the SUSPEND message is not suf- ficient to avoid ambiguities on subsequent call re-establishment. This will apply, in particular, when at a given user-network inter- face, a SUSPEND message is received with a call identity sequence already in use, or when the SUSPEND message does not contain any call identity sequence and the null-value call identity is already allocated for that interface. On receipt of the SUSPEND REJECT mes- sage, the user shall: stop timer T319; and return to the active state. If timer T319 expires, the user shall: notify the user application; and return to the active state. In these cases the state of the call is not altered within the network (i.e. it remains in the active state). 5.6.4 Call re-establishment At the connection end where suspension was initiated, the user may request re-establishment of a call after physical reconnection of a terminal by sending a RESUME message containing the call identity exactly as that used at the time of call suspension; starting timer T318; and entering the resume request state. If the SUSPEND message did not include a call identity information ele- ment, then the corresponding RESUME message shall also not include a call identity information element. The call reference included in the RESUME message is chosen by the user according to the normal allocation of outgoing call reference (see S 4.3). On receipt of a RESUME message, the network enters the resume request state. After a positive validation of the call identity that relates to the suspended call containing a valid identity that relates to a currently suspended call, the network shall: send a RESUME ACKNOWLEDGE message to the user; release the call identity; stop timer T307 and enter the active state. The RESUME ACKNOWLEDGE message shall specify the B-channel reserved to the call by the network by means of the channel identification element, coded B-channel is indicated, no alternative is acceptable . The network shall also send a NOTIFY message with the notifi- cation indicated user resumed to the other user. No memory of the previously received call identity sequence is kept by the network after sending the RESUME ACKNOWLEDGE message. This call identity is now available for another suspension. On receipt of the RESUME ACKNOWLEDGE message, the user shall: stop timer T318 and enter the active state. 5.6.5 Call resume errors If a received RESUME message cannot be actioned by the network (e.g. as a result of an unknown call identity, a RESUME REJECT mes- sage shall be returned to the requesting user indicating one of the following causes: a) No. 83 a suspended call exists, but this call identity does not ; b) No. 85 no call suspended ; or, c) No. 86 call having the requested call identity has been cleared . The call identity remains unknown. The call reference con- tained in the RESUME message is released by both the user and net- work side. Upon receipt of the RESUME REJECT message the user shall: stop timer T318; and enter the Null state. If timer T307 expires the network shall initiate clearing of the network connection with cause No. 102 recovery on timer expiry ; discard the call identity; and release the reserved B-channel. On release, the call identity can then be used for subsequent call suspension. If before the expiry of timer T307 the call is cleared by the remote user, the B-channel reservation is released but the call identity may be preserved by some networks along with a clearing cause (e.g. cause No. 16 normal clearing ). If timer T318 expires, the user shall initiate internal call clearing with cause No. 102 recovery on timer expiry , in accor- dance with S 5.3.2 | ). 5.6.6 Double suspension Simultaneous suspension of the call at both ends is possible. The procedures do not prevent this from occurring. If double suspensions are not desired the users must protect against this by other means; e.g. higher layer negotiation protocols. 5.6.7 Call re-arrangement notification controlled by an NT2 When the call rearrangement is controlled by the NT2, the pro- cedures shall be applied by the NT2 at reference point S. The NT2 shall inform the remote user by sending a NOTIFY message described in SS 5.6.2 and 5.6.4 across reference point T. 5.7 Call collisions Call collisions as such cannot occur at the network. Any simultaneous incoming or outgoing calls are dealt with separately and assigned different call references. Channel selection conflicts may occur if an incoming call and outgoing call select the same channel. This is resolved by the net- work through channel selection mechanisms described in SS 5.1.2 and 5.2.2. In the case of such conflicts, the network shall give priority to the incoming call over the call request received from the user. It shall clear the outgoing call whenever the B-channel cannot be allocated by the network or accepted by the user originating the call. Note - Some terminal adaptors supporting existing non-voice terminals (e.g. X.21) may need to resolve double channel selection by clearing the incoming call and reattempting the outgoing call setup in order to satisfy the requirements of the interface at reference point R. 5.8 Handling of error conditions All procedures transferring signalling information by using the protocol discriminator of Q.931 user-network call control messages are applicable only to those messages which pass the checks described in SS 5.8.1 through 5.8.7. Detailed error handling procedures are implementation depen- dent and may vary from network to network. However, capabilities facilitating the orderly treatment of error conditions are provided for in this section and shall be provided in each implementation. Paragraphs 5.8.1 through 5.8.7 are listed in order of pre- cedence. 5.8.1 Protocol discrimination error When a message is received with a protocol discriminator coded other than Q.931 user-network call control message , that message shall be ignored. "Ignore" means to do nothing, as if the message had never been received. 5.8.2 Message too short When a message is received that is too short to contain a com- plete message type information element, that message shall be ignored. 5.8.3 Call reference error 5.8.3.1 Invalid call reference format If the call reference information element octet 1, bits 5 through 8 do not equal 0000, then the message shall be ignored. If the call reference information element octet 1, bits 1 through 4 indicate a length greater than the maximum length sup- ported by the receiving equipment (see S 4.3), then the message shall be ignored. 5.8.3.2 Call reference procedural errors a) Whenever any message except SETUP, RELEASE, RELEASE COMPLETE, STATUS or RESUME is received specifying a call reference which is not recognized as relating to an active call or to a call in progress, clearing is initiated by sending a RELEASE message with cause No. 81 invalid call reference value and follow- ing the procedures in S 5.3, specifying the call reference in the received message. Alternatively, the receiving entity may send a RELEASE COMPLETE message with cause No. 81 invalid call reference value and remain in the Null state. b) When a RELEASE message is received that speci- fied a call reference which is not recognized as relating to an active call or to a call in progress, a RELEASE message with cause No. 81 invalid call reference value is returned specifying the call reference in the received message. c) When a RELEASE COMPLETE message is received specifying a call reference which is not recognized as relating to an active call or to a call in progress, no action should be taken. d) When a SETUP or RESUME message is received spcifying a call reference which is not recognized as relating to an active call or to a call in progress, and with a call reference flag incorrectly set to "1", this message shall be ignored. e) When a SETUP message is received specifying a call reference which is recognized as relating to an active call or to a call in progress, this SETUP message shall be ignored. f ) When any message except RESTART, RESTART ACK- NOWLEDGE, or STATUS is received using the global call reference, no action should be taken on this message and a STATUS message using the global call reference with a call state indicating the current state associated with the global call reference and cause No. 81 invalid call reference shall be returned. g) When a STATUS message is received specifying a call reference which is not recognized as relating to an active call or to a call in progress, the procedures of S 5.8.11 shall apply. 5.8.4 Message type or message sequence errors Whenever an unexpected message, except RELEASE or RELEASE COM- PLETE, or unrecognized message is received in any state other than the Null state, a STATUS message shall be returned with cause No. 98 message not compatible with call state or message type non-existent or not implemented and the corresponding diagnostic. If a network or user can distinguish between unimplemented (or non-existent) message types and implemented message types which are incompatible with the call state, then a STATUS message may be sent with one of the following causes: a) cause No. 97 message type non-existent or not implemented ; or, b) cause No. 101 message not compatible with call state . Alternatively, a STATUS ENQUIRY message may be sent requesting the call state of the entity (see S 5.8.10). No change in state shall be made in either case at this time. However, two exceptions to this procedure exist. The first exception is when the network or the user receives an unexpected RELEASE message (e.g. if the DISCONNECT message was corrupted by undetected transmission errors). In this case no STATUS or STATUS ENQUIRY message is sent. Whenever the network receives an unex- pected RELEASE message, the network shall: disconnect and release the B-channel; clear the network connection and the call to the remote user with the cause in the RELEASE message sent by the user or, if not included, cause No. 31 normal, unspecified ; return a RELEASE COMPLETE message to the user; release the call reference; stop all timers; and enter the Null state. Whenever the user receives an unexpected RELEASE message, the user shall: disconnect and release the B-channel; return a RELEASE COMPLETE message to the network; release the call reference; stop all timers; and enter the Null state. The second exception is when the network or the user receives an unexpected RELEASE COMPLETE message. Whenever the network receives an unexpected RELEASE COMPLETE message, the network shall: disconnect and release the B-channel; clear the network connection and the call to the remote user with the cause indicated by the user or, if not included, cause No. 111 protocol error, unspecified ; release the call reference; stop all timers; and enter the Null state. Whenever the user receives an unexpected RELEASE COMPLETE message, the user shall: disconnect and release the B-channel; release the call reference; stop all timers; and enter the Null state. 5.8.5 General information element errors The general information element error procedures may also apply to information elements in codesets other than 0. In that case, the diagnostics in the cause information element may indicate information elements other than those in codeset 0 by applying the locking or non-locking shift procedures as described in S 4.5. 5.8.5.1 Information element out of sequence A variable length information element which has a code value lower than the code value of the variable length information ele- ment preceding it shall be considered as an out of sequence infor- mation element. If the network or user receives a message containing an out of sequence information element, it may ignore this information ele- ment and continue to process the message. If this information is mandatory, and the network or user chooses to ignore this out of sequence information element, then the error handling procedure for missing mandatory information elements as described in S 5.8.6.1 shall be followed. If the ignored information element is non-mandatory, the receiver continues to process the message. Note - Some implementations may choose to process all the information elements received in a message regardless of the order in which they are placed. 5.8.5.2 Duplicated information elements If an information element is repeated in a message in which repetition of the information element is not permitted, only the contents of information element appearing first shall be handled and all subsequent repetitions of the information element shall be ignored. When repetition of information elements is permitted, only the contents of permitted information elements shall be handled. If the limit on repetition of information elements is exceeded, the contents of information elements appearing first up to the limit of repetitions shall be handled and all subsequent repetitions of the information element shall be ignored. 5.8.6 Mandatory information element errors 5.8.6.1 Mandatory information element missing When a message other than SETUP, DISCONNECT, RELEASE or RELEASE COMPLETE is received which has one or more mandatory infor- mation elements missing, no action should be taken on the message and no state change should occur. A STATUS message is then returned with cause No. 96 mandatory information element is missing . When a SETUP or RELEASE message is received which has one or more mandatory information elements missing, a RELEASE COMPLETE message with cause No. 96 mandatory information element is missing shall be returned. When a DISCONNECT message is received with the cause informa- tion element missing, the actions taken shall be the same as if a DISCONNECT message with cause No. 31 normal, unspecified was received (see S 5.3), with the exception that the RELEASE message sent on the local interface contains cause No. 96 mandatory infor- mation element is missing . When a RELEASE COMPLETE message is received with a cause information element missing, it will be assumed that a RELEASE COM- PLETE message was received with cause No. 31 normal, unspecified . 5.8.6.2 Mandatory information element content error When a message other than SETUP, DISCONNECT, RELEASE, or RELEASE COMPLETE is received which has one or more mandatory information elements with invalid content, no action should be taken on the message and no state change should occur. A STATUS message is then returned with cause No. 100 invalid information element contents . When a SETUP or RELEASE message is received which has one or more mandatory information elements with invalid content, a RELEASE COMPLETE message with cause No. 100 invalid information element contents shall be returned. When a DISCONNECT message is received with invalid content of the cause information element, the actions taken shall be the same as if a DISCONNECT message with cause No. 31 normal, unspecified was received (see S 5.3), with the exception that the RELEASE mes- sage sent on the local interface contains cause No. 100 invalid information element contents When a RELEASE COMPLETE message is received with invalid con- tent of the cause information element, it will be assumed that a RELEASE COMPLETE message was received with cause No. 31 normal, unspecified . Information elements with a length exceeding the maximum length (given in S 3) will be treated as information element with content error. 5.8.7 Non-mandatory information element errors The following sections identify actions on information ele- ments not recognized as mandatory. 5.8.7.1 Unrecognized information element When a message is received which has one or more unrecognized information elements, the receiving entity shall check whether any are encoded to indicate comprehension required (refer to Table 4-3/Q.931 for information element identifiers reserved with this meaning). If any unrecognized information element is encoded to indicate "comprehension required", then the procedures in S 5.8.6.1 are followed; i.e. as if a "missing mandatory information element" error condition had occurred. If all unrecognized informa- tion elements are not encoded to indicate "comprehension required", then the receiving entity shall proceed as follows: Action shall be taken on the message and those information elements which are recognized and have valid content. When the received message is other than DISCONNECT, RELEASE or RELEASE COM- PLETE, a STATUS message may be returned containing one cause infor- mation element. The STATUS message indicates the call state in which the receiver detected the error. The cause information ele- ment shall contain cause No. 99 information element non-existent or not implemented , and the diagnostic field, if present, shall contain the information element identifier for each information element which was unrecognized. Subsequent actions are determined by the sender of the unrecognized information elements. If a clearing message contains one or more unrecognized information elements, the error is reported to the local user in the following manner: a) When a DISCONNECT message is received which has one or more unrecognized information elements, a RELEASE message with cause No. 99, information element non-existent or not imple- mented , shall be returned. The cause information element diagnos- tic field, if present, shall contain the information element iden- tifier for each information element which was unrecognized. b) When a RELEASE message is received which has one or more unrecognized information elements, a RELEASE COMPLETE mes- sage with cause No. 99, information element non-existent or not implemented , shall be returned. The cause information element diagnostic field, if present, shall contain the information element identifier for each information element which was unrecognized. c) When a RELEASE COMPLETE message is received which has one or more unrecognized information elements, no action shall be taken on the unrecognized information. Note - The diagnostic(s) of cause No. 99 facilitates the decision in selecting an appropriate recovery procedure at the reception of a STATUS message. Therefore, it is recommended to pro- vide cause No. 99 with diagnostic(s) if a layer 3 entity expects the peer to take an appropriate action at the receipt of a STATUS message, although inclusion of diagnostic(s) is optional. 5.8.7.2 Non-mandatory information element content error When a message is received which has one or more non-mandatory information elements with invalid content, action shall be taken on the message and those information elements which are recognized and have valid content. A STATUS message may be returned containing one cause information element. The STATUS message indicates the call state in which the receiver detected the error. The cause informa- tion element shall contain cause No. 100 invalid information ele- ment contents , and the diagnostic field, if present, shall contain the information element identifier for each information element which has invalid contents. Information elements with a length exceeding the maximum length (given in S 3) will be treated as an information element with content error. But for access information elements (see Annex G; e.g. user-user information element, called party subad- dress information element), cause No. 43 access information dis- carded is used instead of cause No. 100 invalid information element contents . However, in some networks, access information elements may be truncated and processed. 5.8.8 Data link reset Whenever a Q.931 entity is informed of a spontaneous data link layer reset by means of the DL-ESTABLISH-INDICATION primitive, the following procedures apply: a) For calls in the overlap sending and overlap receiving states, the entity shall initiate clearing by sending a DISCONNECT message with cause No. 41 temporary failure , and fol- lowing the procedures of S 5.3. b) For calls in the disestablishment phase (states N11, N12, N19, N22, U11, U12 and U19), no action shall be taken. c) Calls in the establishment phase (states N1, N3, N4, N6, N7, N8, N9, U1, U3, U4, U6, U7, U8 and U9) and in the active, suspend request, and resume request states shall be main- tained according to the procedures contained in other parts of S 5. 5.8.9 Data link failure Whenever a Q.931 entity is notified by its data link entity via the DL-RELEASE-INDICATION primitive that there is a data link layer malfunction, the following procedure shall apply: a) The calls in the overlap sending or overlap receiving states shall be cleared internally. For any call without a timer running (see S 9), a timer T309 shall be started. Note - If timer T309 is already running, it shall not be restarted. b) The Q.931 entity may request layer 2 reestab- lishment by sending a DL-ESTABLISH-REQUEST primitive if a call is not in the Null state. Otherwise, the Q.931 entity may clear inter- nally. Note - If the transfer mode of the call is circuit-mode, the Q.931 entity may clear the calls. If the transfer mode of the call is packet-mode and layer 1 is recognized as normal in spite of the data link failure, the Q.931 entity shall not clear the call and shall request data link reestablishment. When informed of layer 2 reestablishment by means of the DL-ESTABLISH-CONFIRM primitive, the following procedure shall apply: 1) Stop timer T309. 2) Optionally, a STATUS message may also be sent to report the current call state to the peer entity. Alternatively, a STATUS ENQUIRY message can be sent to verify the call state of the peer entity. If timer T309 expires prior to data link reestablishment, the network shall: clear the network connection and call to the remote user with cause No. 27 destination out of order ; disconnect and release the B-channel; release the call reference; and enter the Null state. When a backup D-channel is available, the procedures in Annex F may be used. Note - The implementation of timer T309 in the user side is optional. If timer T309 expires prior to data link reestablishment, the user shall: clear an attached connection (if any) with cause No. 27 destination out of order ; disconnect and release the B-channel; release the call reference; and enter the Null state. 5.8.10 Status enquiry procedure Whenever an entity wishes to check the correctness of a call state at a peer entity, a STATUS ENQUIRY message may be sent requesting the call state. This may, in particular, apply to pro- cedural error conditions described in SS 5.8.8 and 5.8.9. Upon sending the STATUS ENQUIRY message, timer T322 shall be started in anticipation of receiving a STATUS message. While timer T322 is running, only one outstanding request for call state infor- mation shall exist. Therefore, if timer T322 is already running, it shall not be restarted. If a clearing message is received before timer T322 expires, timer T322 shall be stopped, and call clearing shall continue. Upon receipt of a STATUS ENQUIRY message, the receiver shall respond with a STATUS message, reporting the current call state and cause No. 30 response to STATUS ENQUIRY or No. 97 message type non-existent or not implemented (see S 5.8.4). Receipt of the STATUS ENQUIRY message does not result in a state change. The sending or receipt of the STATUS message in such a situa- tion will not directly affect the call state of either the sender or receiver. The side having received the STATUS message shall inspect the cause information element. If the STATUS message con- tains cause No. 97 message type non-existent or not implemented , timer T322 shall continue to time for an explicit response to the STATUS ENQUIRY message. If a STATUS message is received that con- tains cause No. 30 response to status enquiry , timer T322 shall be stopped and the appropriate actiont taken, based on the information in that STATUS message, relative to the current state of the receiver. If timer T322 expires and a STATUS message with cause No. 97 message type non-existent or not implemented was received, the appropriate action shall be taken, based on the information in that STATUS message, relative to the current call state of the receiver. These further appropriate actions are implementation depen- dent. However, the actions prescribed in the following section shall apply. If timer T322 expires, and no STATUS message was received, the STATUS ENQUIRY message may be retransmitted one or more times until a response is received. The number of times the STATUS ENQUIRY mes- sage is retransmitted as an implementation dependent value. The call shall be cleared to the local interface with cause No. 41, temporary failure , if the STATUS ENQUIRY is retransmitted the max- imum number of times. If appropriate, the network shall also clear the network connection, using cause No. 41, temporary failure . 5.8.11 Receiving a STATUS message On receipt of a STATUS message reporting an incompatible state, the receiving entity shall: a) clear the call by sending the appropriate clearing message with cause No. 101 message not compatible with call state ; or, b) take other actions which attempt to cover from a mismatch and which are an implementation option. Except for the following rules, the determination of which states are incompatible is left as an implementation decision: a) If a STATUS message indicating any call state except the Null state is received in the Null state, then the receiving entity shall either: 1) send a RELEASE message with cause No. 101 mes- sage not compatible with call state ; and then follow the pro- cedures of S 5.3; or, 2) send a RELEASE COMPLETE message with cause No. 101 message not compatible with call state ; and remain in the Null state. b) If a STATUS message indicating any call state except the Null state is received in the release request state, no action shall be taken. c) If a STATUS message, indicating the Null state, is received in any state except the Null state, the receiver shall release all resources and move into the Null state. When in the Null state, the receiver of a STATUS message indi- cating the Null state shall take no action other than to discard the message and shall remain in the Null state. A STATUS message may be received indicating a compatible call state but containing one of the following causes: i) No. 96 mandatory information element is missing ; ii) No. 97 message type non-existing or not implemented; iii) No. 99 information element non-existent or not implemented ; or iv) No. 100 invalid information element contents . In this case the actions to be taken are an implementation option. If other procedures are not defined, the receiver shall clear the call with the appropriate procedure defined in S 5.3, using the cause specified in the received STATUS message. On receipt of a STATUS message specifying the global call reference and reporting an incompatible state in the restart request or restart state, the receiving Q.931 entity shall inform layer management and take no further action on this message. When in the null state, then on receipt of a STATUS message with the global call reference no action shall be taken. Note - Further actions as a result of higher layer activity (e.g. system or layer management) and implementation dependent (including the retransmission of RESTART). Except for the above case, the error handling procedures when receiving a STATUS message specifying the global call reference are an implementation option. 5.9 User notification procedure This procedure allows the network to notify a user of any appropriate call-related event during the active state of a call. It also allows a user to notify the remote user of any appropriate call-related event during the active state of a call by sending a NOTIFY message containing a notify indicator to the network; upon receipt of this message, the network must send a NOTIFY message containing the same notify indicator to the other user involved in the call. No state change occurs at any of the interface sides fol- lowing the sending or the receipt of this message.