home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-22 | 597.7 KB | 10,407 lines
5i' 6 Packet communications procedures This section is intended to explain the role of the D-channel signalling procedures in the support of packet communications in an ISDN. A complete description of terminal adaptor functions can be found in Recommendation X.31. According to Recommendation X.31, the user may access packet facilities by means of one of the following alternatives: a) circuit-switched access to PSPDN services (Case A) by establishing a transparent circuit-switched access con- nection through the ISDN to the access port of a public network (e.g., PSPDN) referred to as "access unit (AU)" in the following sections. This connection may be initiated by the user or the AU. From the ISDN point of view, the circuit-switched call control pro- cedures of S 5 apply. Only the B-channel is used in this case. b) packet-switched access to an ISDN virtual cir- cuit service (Case B) by establishing a packet-mode access connection to the packet handler (PH) of an ISDN. This connection may be initiated by the user or the ISDN. Both B- and D-channels may be used in this case. The protocol and the text of SS 6.1 to 6.5 and Appendix II of Recommendation Q.931, and SS 6.1 to 6.5 and Appendix III of Recommendation X.31[14], are identical. The term "user" refers to the user equipment which may consist of an ISDN packet-mode terminal (TE1) or a combination of an exist- ing data terminating equipment (DTE/TE2) attached to a terminal adaptor (TA). A DTE may not receive all of the information provided in Q.931 signalling messages at the user-network interface. The ISDN TA/TE1 presents an S/T-interface towards the network and therefore the TA/TE1 implementation should embody the pro- cedures described in Recommendation Q.921 [3] and this Recommenda- tion for B- and D-channel connection establishment and control. For demand access connections, SS 6.1 through 6.4 apply. Exam- ple message flows for demand access connections are shown in Appendix II. Two types of semi-permanent connection on B- and D-channels are covered in this section: 1) physical layer semi-permanently established between the terminal and the PH/AU, i.e., the I.430/I.431 physical layer remains activated and the physical path through the ISDN is connected semi-permanently; and 2) data link and physical layers semi-permanently established between the terminal and the PH/AU (in this type, the network shall keep the data link layer in the established state). When a PVC is used, there must exist a type 2) semi-permanent connection. In semi-permanent connection type 1), the procedures of S 6.3 are followed for call establishment and release. In semi-permanent connection type 2), only the procedures of S 6.3.2 are followed for call establishment and release. When semi-permanent connection type 2) is used for PVCs, none of the following procedures apply. Semi-permanent connections are established via a provisioning process without Q.931 procedures. 6.1 Outgoing access If the user selects an already established channel for the outgoing virtual call, then the procedures described in S 6.3 apply. If the selected channel is not established to the AU/PH, then the procedures for activating a channel described in the fol- lowing subsections are to be used before establishing the virtual call using the procedures of S 6.3. For outgoing data calls, the user first must decide whether the circuit-switched (Case A) or packet switched services (Case B) are desired from the network. For outgoing circuit calls, the user follows the procedures of S 6.1.1. For outgoing packet calls, a user decides whether B-channel or D-channel is to be used for the packet call. If the user decides to use the B-channel, then the procedures described in S 6.1.2.1 are used. If the user decides to use the D-channel, then the procedures described in S 6.1.2.2 are used. Note - Some networks may not support every type of access. In the case of B-channel access, the network will clear a request for unsupported services by sending a RELEASE COMPLETE message with cause No. 65, bearer capability not implemented . In the case of a request for D-channel access (an SABME with SAPI=16), on a network port which does not support the service, no response is required of the network. 6.1.1 Circuit-switched access to PSPDN services (Case A) The B-channel connection between the user and the AU shall be controlled using the D-channel signalling procedures for call establishment described in S 5.1. The specific B-channel to be used as a switched connection is selected using the channel selection procedures described in S 5.1.2 and summarized in Table 6-1/Q.931. H.T. [T168.931] TABLE 6-1/Q.931 User requested channel and network response. Outgoing access to either an AU or PH _____________________________________________________________________________________________________ { Channel indicated in the SETUP message user to network direction } { Allowable network response (network-user) } Channel indication Preferred or exclusive D-channel indication _____________________________________________________________________________________________________ Exclusive No Bi Bi Preferred No Bi, Bi` _____________________________________________________________________________________________________ (Ignore) No Bi` Any | | | | | | | | | | | | | | | | | | | | | | | | | _____________________________________________________________________________________________________ (Absent) Bi` _____________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bi the indicated (idle) B-channel Bi` any (other) idle B-channel Note 1 - All other encodings are invalid. Note 2 - All columns under the heading "Channel indicated in the SETUP message" indicate possible user codings of the Channel iden- tification information element contained in the SETUP message sent by the user to the network requesting a connection to an AU or PH (see S 4.5.13). The column under "Allowable network response" refers to the allowable responses by the network to the user. Table 6-1/Q.931 [T168.931], p. On the basis of the call set-up information (e.g. Called party number identifying an AU, Transit network selection, etc.) and/or a subscription time agreement, the network provides a connection to the appropriate AU. The Bearer capability information element included in the SETUP message shall be coded with: - information transfer capability set to either: a) unrestricted digital information ; or b) restricted digital information ; - transfer mode set to circuit mode ; - information rate set to 64 kbit/s . Note - Bearer capability information element octets 4a and 4b shall not be included. The user may also specify the layer 1 (e.g., rate adaption), layer 2 (i.e., LAPB), and layer 3 (i.e., X.25) information transfer protocols in the low layer compatibility information element in the SETUP message (see Annex L). 6.1.2 Access to the ISDN virtual circuit service (Case B) 6.1.2.1 B-channel Demand access B-channel connections are controlled using the D-channel signalling procedures for call establishment described in S 5.1 using the messages defined in S 3.2 with the following excep- tions: a) the procedures for overlap sending specified in S 5.1.3 do not apply; b) the procedures for call proceeding and overlap sending specified in S 5.1.5.2 do not apply; c) the procedures for notification of interworking at the origination interface specified in S 5.1.6 do not apply; d) the procedures for call confirmation indication specified in S 5.1.7 do not apply; e) the procedures for call connection specified in S 5.1.8 apply as follows: - upon accepting the access connection, 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 an access connection to the packet handler has been established; - on receipt of the CONNECT message, the calling user may optionally send a CONNECT ACKNOWLEDGE message, and shall enter the Active state; f ) the procedures for call rejection specified in S 5.1.9 apply as follows: - when unable to accept the access connection, the network shall initiate call clearing at the originating user-network interface as described in S 5.3; g) the procedures for transit network selection specified in S 5.1.10 do not apply. The specific B-channel to be used as a demand connection is selected using the channel selection procedures described in S 5.1.2 and summarized in Table 6-1/Q.931. For a demand connection to an ISDN PH, the Bearer capability information element included in the SETUP message shall be coded with: - information transfer capability set to unres- tricted digital information ; - transfer mode set to packet mode ; - information transfer rate set to 00000; - user information layer 2 protocol set to Recom- mendation X.25, link layer ; - user information layer 3 protocol set to Recommendation X.25, packet layer . Note - Octets 4a, 4b, 5a, 5b, 5c and 5d shall not be included. The demand access connection can then be used to suport packet communications according to X.25 link layer and X.25 packet layer procedures as specified in S 6.3. 6.1.2.2 D-channel The D-channel provides a connection which enables the ISDN user terminal to access a PH function within the ISDN by establish- ing a link layer connection (SAPI=16) to that function which can then be used to support packet communications according to X.25 layer 3 procedures as defined in S 6.3. The X.25 packet layer uses the acknowledged information transfer service (i.e., I-frames) pro- vided by LAPD (see Recommendation Q.920 [45]). Consequently, Q.931 procedures are not required to provide D-channel access. A number of packet mode user equipment can operate simultane- ously over the D-channel, each using a separate layer 2 data link identified by an appropriate address (see Recommendation Q.921) in frames transferred between the user and PH. 6.2 Incoming access 6.2.1 Access from PSPDN services (Case A) The ISDN signals the establishment of the circuit-mode connec- tion using the procedures described in S 5.2. The virtual calls are signalled between the user and the AU using the procedures described in S 6.3. 6.2.1.1 General The general procedures performed by the AU are those defined in Recommendation X.32. 6.2.1.2 Channel selection If the physical circuit desired by the AU does not exist between the terminal and the AU, the procedures for physical chan- nel establishment described in the following sections apply. The format of the SETUP message sent by the network to the user is in accordance with S 3.1. The bearer capability information element included in the SETUP message shall be coded with: - information transfer capability set to either: a) unrestricted digital information ; or b) restricted digital information ; - transfer mode set to circuit mode ; - information rate set to 64 kbit/s . Note - Bearer capability information element octets 4a and 4b shall not be included. The Channel identification information element shall be coded according to Table 6-2/Q.931. H.T. [T169.931] TABLE 6-2/Q.931 Network requested channel and user response. Incoming access from an AU ________________________________________________________________________________________________________________________ { Channel indicated in the SETUP message network to user direction } { Allowable user response (user-network) } Channel indication Preferred or exclusive D-channel indication ________________________________________________________________________________________________________________________ Bi Exclusive No Bi Bi Preferred No Bi, Bi` ________________________________________________________________________________________________________________________ | | | | | | Note 1 Bi indicated (idle) B-channel Bi` any other idle B-channel (not permitted for broadcast call offering) Note 1 - This encoding is not used for broadcast call offering. Note 2 - All other encodings are invalid. Table 6-2/Q.931 [T169.931], p. The B-channel connection to the called user shall be esta- blished by the network using the signalling procedures described in S 5.2. The call is offered by sending the SETUP message on a point-to-point data link or on the broadcast data link. The user responds to the SETUP as specified in S 5. 6.2.2 Access from the ISDN virtual circuit service (Case B) To offer an incoming call, the network must perform the fol- lowing steps in sequence: 1) Channel selection - the physical channel/logical link to be used for the incoming call must be identified. The net- work may use customer profile information, network resources, etc., to choose the channel, or the procedures in Step 2 below. 2) Physical channel/logical link establishment - if the physical B-channel or the logical link of the D-channel have not been determined by Step 1, the network may use the procedures in S 6.2.2.3. The network may then proceed with Step 3. 3) Virtual call establishment - the network estab- lishes the virtual call using the procedures described in S 6.3. In the configuration for the ISDN virtual circuit service, the choice of channel type to be used for the delivery of a new incom- ing call packet shall be made by the network as described below. a) A new incoming call | acket may be indicated to the ISDN customer by a call offering procedure between the network and all user packet mode terminals (see SS 3.2.3.2 and 3.2.3.3 of Recommendation X.31 [14]). b) An incoming virtual call directed to a terminal with an established connection to the PH may be offered directly to the terminal over the established access connection without the use of Q.931 call offering procedures (see SS 3.2.3.1 and 3.2.3.2 of Recommendation X.31 [14]). 6.2.2.1 B-channel When calls are to be offered on the B-channels without channel negotiation, the procedures described in S 5.2 of Recommendation Q.931 using the messages of S 3.2 of Recommendation Q.931 apply with the following exceptions: a) The procedures for overlap receiving specified in S 5.2.4 of Recommendation Q.931 do not apply. b) The procedures for receipt of CALL PROCEEDING and ALERTING specified in S 5.2.5.2 apply with the following excep- tion: - The receipt of an ALERTING message shall not cause the network to send a corresponding ALERTING message to the calling user. c) The procedures for call failure specified in S 5.2.5.3 apply with the following note: - The network clears the incoming X.25 virtual call towards the calling X.25 DTE using the appropriate cause from Table 6-5/Q.931. d) The procedures for notification of interworking at the terminating interface specified in S 5.2.6 apply with the following exceptions: - The case of the call entering an ISDN environment during call establishment is not applicable. - In the case of a call leaving the ISDN environ- ment within the called user's premises, no notification is sent to the calling party. - The case of in-band information/patterns is not applicable. e) The procedures for active indication specified in S 5.2.8 apply with the following exception: - The network shall not initiate procedures to send a CONNECT message towards the calling user. f ) The procedures for user notification specified in S 5.2.10 do not apply. Where an established B-channel connection is to be used, the incoming call | acket will be delivered in accordance with S 6.3. Where a new B-channel connection is to be established, the identity of the selected user will be associated with the Connec- tion Endpoint Suffix (CES) from which the first CONNECT message has been received. 6.2.2.2 D-channel The D-channel provides a connection which enables the ISDN PH to access an ISDN user terminal or vice versa. This access is accomplished by establishing a link layer connection (SAPI = 16) to the terminal or network which can then be used to support packet communications according to X.25[5] layer 3 procedures as defined in S 6.3. The layer 2 procedures shall be in accordance with Recommendation Q.921[3]. The D-channel provides a semi-permanent connection for packet access since all layer 2 frames containing a packet mode SAPI (16) are routed automatically between the user and the PH function. When an incoming call is offered to packet mode user equipment at the user interface, the channel selection procedures described in S 6.2.2.3 shall be used. A number of packet mode terminals can operate simultaneously over the D-channel, each using a separate layer 2 link identified by an appropriate TE1 (see Recommendation Q.921) in frames transferred between the terminal and the network. 6.2.2.3 Call offering 6.2.2.3.1 Channel selection through call offering The call offering procedure is performed using the layer 3 messages and procedures of S 5. The call offering procedure is integrated into the circuit-switched call control procedures, sig- nalled on the D-channel, with the channel selection being accom- plished by means of the channel selection procedure if offered as a network option. As described in S 5, the network selects the first user which responds to the call offering with a CONNECT message. When the selected user has requested that the X.25 call be set up over a new B-channel, the network will indicate that the channel is acceptable by returning a CONNECT ACKNOWLEDGE message to the user. If multiple terminals have responded positively to the SETUP message, the net- work shall clear each of the non-selected terminals with a RELEASE message containing cause No. 26, non-selected user clearing . When the selected user has requested that the X.25 call be set up over an established B-channel or the D-channel, the network shall respond to the CONNECT message with a RELEASE message con- taining cause No. 7, call awarded and being delivered in an esta- blished channel . The network shall also return a RELEASE message containing cause No. 26, non-selected user clearing to any other positively responding terminals. The network will then deliver the X.25 call over the selected channel. Note 1 - There is no time significance between the delivery of the RELEASE message and the incoming call | packet, i.e., either may occur first. Note 2 - The network shall send the RELEASE message(s) and the user(s) shall respond with RELEASE COMPLETE. If the channel indicated by the first positively responding user is not available, the network will use Q.931 call clearing procedures to clear the call with cause No. 6, channel unacceptable . If the channel indicated in the SETUP message is not acceptable to the user, the user will clear the call with a RELEASE message containing cause No. 34, no circuit/channel available , or cause No. 44, requested circuit/channel not available . On the basis of a network option or subscription agreement, the network may choose the access channel or access channel type (e.g. B or D) for a particular incoming packet call. When the Channel indication information element indicates Channel indication - No channel , Exclusive , and D-channel indica- tion - Yes , then the Bearer capability information element should be encoded as follows: - information transfer capability set to either: a) unrestricted digital information ; or b) restricted digital information ; - transfer mode set to: packet mode ; - information rate set to: packet mode (00000) ; - layer 2 protocol set to: Recommendation Q.921 ; - Layer 3 protocol set to: Recommendation X.25, packet layer . In all other cases, the Bearer capability information element should be encoded as follows: - information transfer capability set to either: a) unrestricted digital information ; or b) restricted digital information ; - transfer mode set to: packet mode ; - information rate set to: packet mode (00000) ; - layer 2 protocol set to: Recommendation X.25 [5], link layer ; - Layer 3 protocol set to: Recommendation X.25, packet layer . There exists an understanding that if the terminal responds with D-channel indication set (see Table 6-3/Q.931), the Layer 2 protocol to be used is Recommendation Q.921 (LAPD)[3]. The channel selection procedure for incoming calls is indepen- dent of the type of channel selected at the calling end. In this respect, any combination of channel type used at each end is possi- ble, provided the user rates and available bandwidth are compati- ble. The channel selection principle to be used in the procedure is shown in Table 6-3/Q.931. Note 3 - When the incoming SETUP message is sent on a broad- cast data link with a Channel identification information element which indicates an idle B-channel and preferred , the called user is not permitted to respond with a different idle B-channel in the response. The option to respond with a different idle channel is restricted to point-to-point call offerings. Note 4 - Networks providing packet mode call offering shall provide Q.931 signalling procedures for packet mode calls on SAPI = 0. For an interim period, some networks, by subscription agreement, may offer SAPI = 16 broadcast call offering procedures for providing Q.931 signalling. This option shall use all Q.31 pro- cedures for packet mode calls with the following restriction: all calls will be offered as D-channel exclusive and will not provide channel selection procedures. Terminals implementing SAPI = 16 pro- cedures shall also implement SAPI = 0 procedures for portability. H.T. [T170.931] TABLE 6-3/Q.931 Network requested channel and user response. Incoming access for packet mode __________________________________________________________________________________________________________ { Channel indicated in the SETUP message network to user direction } { Allowable user response (user-network) } Channel indication Preferred or exclusive D-channel indication __________________________________________________________________________________________________________ No Bi Bi Exclusive Yes Bi, D __________________________________________________________________________________________________________ No Bi, Bi`, Bj Bi Preferred Yes Bi, Bi`, Bj, D __________________________________________________________________________________________________________ No Bj No channel Preferred Yes Bj, D __________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bi indicated (idle) B-channel Bi` any other idle B-channel (not permitted in response to broad- cast call offering) Bj an established B-channel under the user's control D the D-channel Note - All other encodings are invalid. Table 6-3/Q.931 [T170.931], p. 6.2.2.3.2 Information element mapping Some networks may choose to provide a service of mapping some or all of the information from the incoming call packet into the SETUP message (see S 3.2.3 of Recommendation X.31). Table 6-4/Q.931 shows the mapping of the X.25 incoming call elements to Q.931 information elements. The incoming call packet will still contain these fields when it is delivered. See S 3.2.3 of Recommendation X.31 for mapping requirements. H.T. [T171.931] TABLE 6-4/Q.931 Mapping of X.25 information elements to corresponding Q.931 SETUP message information elements in packet-mode incoming call (Note 1) __________________________________________________________________________________________________ { Information elements in X.25 incoming call packet } { Corresponding information element in Q.931 SETUP message } __________________________________________________________________________________________________ Called address Called party number A-bit (Note 3) For further study Modulus { _____________________________________________________________ { { Throughput class negotiation Information rate Reverse charging For further study For further study Bilateral closed user group { { Flow control parameter negotiation Redirecting number __________________________________________________________________________________________________ Calling address extension Calling party sub-address Called address extension Called party sub-address { Minimum throughput class Information rate DTE facility __________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - Mapping is optional or required as indicated in S 3.2.3 of Recommendation X.31. Note 2 - The maximum length of the user data within the user-user information element is network dependent and is either 32 or 128 octets. Note 3 - The need and procedures for A-bit mapping is for further study. Table 6-4/Q931 [T171.931], p. 6.2.2.3.3 Channel selection without call offering Where the network and user have agreed beforehand, the network may route an incoming call to the called user over an established B-channel connection or D-channel link without the need for any signalling for channel selection. 6.3 Virtual call establishment and release In all cases, once the physical channel has been selected and, if necessary, connected to the PH or AU, the virtual call is esta- blished according to the procedures below. Some networks may require some of the terminal identification procedures of Recommendation X.32 as well. 6.3.1 Link layer establishment and release Link layer (LAPB on the B-channel or LAPD on the D-channel) establishment shall be initiated by: - the calling terminal in the case of outgoing calls; - the AU in the case of incoming calls in Case A; or - the PH in the case of incoming calls in Case B. Link layer release may be initiated by: - the terminal; - the AU in Case A; or - the PH in Case B. 6.3.2 Packet layer virtual call set-up and release The packet layer procedures of X.25 [5] will be used for layer 3 call set-up and release. The packet layer procedure will addi- tionally be able to control and monitor the established or released state of the link layer. In Case B, the PH may maintain a timer T320 (defined in Recommendation Q.931). T320, if implemented, is started: a) upon clearance of the last virtual call; or b) upon transmission of a CONNECT message by the network in case of an outgoing B-channel access access connection; or c) upon transmission of a CONNECT ACKNOWLEDGE mes- sage by the network in case of an incoming B-channel access connec- tion; or d) upon establishment of the link layer for D-channel access connections. T320 is canceled upon: 1) establishment of the first (next) virtual call; or 2) receipt of Q.931 clearing message from the user; or 3) disconnection of the SAPI = 16 link on the D-channel. Upon expiry of T320, the PH will release the link layer and, in the case of B-channel access, initiate clearing of the B-channel. X.25 logical channels are associated with their underlying logical link. Specifically, in case of the use of the B-channel for packet communication, there is an association between the logical channels and the LAPB logical link below them. Thus the same logi- cal channel number may be used simultaneously on each different B-channel. 6.4 Call clearing 6.4.1 B-channel The clearing of the switched connection shall be effected by using the D-channel signalling procedures for call clearing as specified in S 5.3. For access to PSPDN services, no exceptions apply. For the ISDN virtual circuit service, the messages of S 3.2 are used, and the following exceptions apply: - The terms defined in S 5.3.1 (Terminology) apply by replacing "circuit-switched ISDN connection" with "demand packet mode access connection". - The exception condition f ) specified in S 5.3.2 does not apply. - The procedures for clearing with tones and announcements provided in S 5.3.4.1 do not apply. The B-channel may be cleared at any time by the user though, in general, it will be cleared following the clearing of the last virtual call over that B-channel. In the ISDN virtual circuit ser- vice, if the user clears the B-channel access connection using a Q.931 clearing message while X.25 [5] virtual calls still exist on the B-channel, the network shall clear the X.25 virtual call(s) with cause No. 17, remote procedure error , and diagnostic No. 64, call set-up, call clearing, or registration problem . In Case B, if a Q.931 RESTART message is received by the PH during the X.25 data transfer phase, the X.25 virtual calls shall be treated as follows: - For switched virtual circuits, an X.25 clear indication | packet shall be sent with cause No. 9, out of order , and diagnostic No. 0, no additional information . - For permanent virtual circuits, an X.25 reset | packet shall be sent containing cause No. 9, out of order and diag- nostic No. 0, no additional information . At the expiration of timer T320, the network may disconnect the X.25 link layer and the access connection. B-channel clearing is as described in S 5.3 with the exceptions above, with cause No. 102, recovery on timer expiry . 6.4.2 D-channel D-channel access connections are cleared using the disconnect procedures as defined in S 6.3. 6.4.3 Additional error handling information When failure occurs, or the X.25 virtual call is cleared prematurely, the rules of S 5.8 shall apply. In addition, the fol- lowing rules for determining the appropriate cause to be used shall apply in order of decreasing priority: 1) If a Q.931 clearing message or RESTART message is received by the PH during the X.25 data transfer phase, S 6.4.1 applies. 2) If a call is required by the destination user using Q.931 messages, the X.25 virtual call shall be cleared using a clear indication packet and the appropriate cause from Table 6-5/Q.931. 3) If a condition exists that prevents the Q.931 SETUP message from being delivered at the user-network interface, the X.25 virtual call shall be cleared using a clear indication packet and a cause shall be selected appropriate to the condition. Table 6-5/Q.931 shall serve as a guide to selecting an appropriate cause, i.e., the X.25 mapping of the Q.931 cause describing the interface condition shall be used. 4) If the Q.931 SETUP message is sent across the user-network interface, but no response is received to the second expiry of timer T303, rule No. 3 applies. 5) If the Q.931 SETUP message is sent across the user-network interface, and a response is received from a user which results in the clearing of the call at the user-network interface, the X.25 virtual call shall be cleared using a clear indication packet containing the appropriate cause from Table 6-5/Q.931 relative to the cause received/sent in the Q.931 clearing message. 6) If an X.25 clear request packet is received from the originating user prior to the delivery of the X.25 incoming call packet to the called user (premature clearing), the PH shall send a clear confirmation packet to the calling user and the access connection shall be treated as follows: - If the Q.931 SETUP message was associated with the Unconditional notification class of service (see S 3.2.3 of Recommendation X.31[14]), the access connection, when and if esta- blished, shall be cleared. The Q.931 clearing message shall contain the appropriate cause as described in Table 6-6/Q.931. - If the Q.931 SETUP message was associated with the Conditional notification class of service (see S 3.2.3 of Recommendation X.31) and there exists at least one terminal which responds positively to the Q.931 SETUP message, then two options are allowed: a) the access connection is cleared as described for the Unconditional class of service; or b) the access connection is established and timer T320 is started. Upon expiry of the timer T320, the access connec- tion is cleared with cause No. 102, recovery on timer expiry , and diagnostic indicating timer T320. H.T. [1T172.931] TABLE 6-5/Q.931 Mapping of Q.931 cause fields to X.25 cause field ______________________________________________________________________________________________________________________________________________________________________________________________________________________ Item Q.931 cause Code Q.931 diagnostic X.25 cause Code X.25 diagnostic Code ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 1 { Unallocated (unassigned) number } 1 { Condition: unknown, transient, permanent } Not obtainable 13 Invalid called address 67 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 2 No route to destination 3 { Condition: unknown, transient, permanent } Not obtainable 13 Invalid called address 67 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 3 Channel unacceptable 6 (None) Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 4 Normal call clearing 16 { Condition: unknown, transient, permanent } DTE originated 0 No additional information 0 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 5 User busy 17 (None) Number busy 1 No logical channel available 71 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 6 No user responding 18 (None) Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 7 User alerting, no answer 19 (None) Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 8 Call rejected 21 { Condition: unknown, transient, permanent + user applied diagnostics } DTE originated 0 No additional information 0 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 9 Number changed 22 New destination address Not obtainable 13 Invalid called address 67 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 10 Destination out of order 27 (None) Out of order 9 No additional information 0 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 11 { Invalid number format (incomplete number) } 28 (None) Local procedure error 19 Invalid called address 67 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 12 Normal, unspecified 31 (None) DTE originated 0 No additional information 0 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 13 No circuit/channel available 34 (None) Number busy 1 No logical channel available 71 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 14 Network out of order 38 (None) Out of order 9 No additional information 0 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ 15 Temporary failure 41 Network identity Out of order 9 No additional information 0 ______________________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 6-5/Q.931 [1T172.931], p. 5 H.T. [2T172.931] TABLE 6-5/Q.931 (cont.) ___________________________________________________________________________________________________________________________________________________________________________________________________________________ Item Q.931 cause Code Q.931 diagnostic X.25 cause Code X.25 diagnostic Code ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 16 { Switching equipment congestion } 42 Network identity Network congestion 5 No additional information 0 ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 17 { Requested circuit/channel not available } 44 (None) Number busy 1 No logical channel available 71 ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 18 { Resources unavailable unspecified } 47 (None) Network congestion 5 No additional information 0 ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 19 { Quality of service unavailable } 49 { Condition: unknown, transient, permanent } Network congestion No additional information ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 20 { Bearer capability not authorized } 57 { Bearer capability information element identifier } Incompatible destination 33 No aditional Information 0 ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 21 { Bearer capability not presently available } 58 { Bearer capability information element identifier } Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 22 { Service or option not available, unspecified } 63 (None) Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 23 { Bearer service not implemented } 65 Attribute numbers Incompatible destination 33 No additional information 0 ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 24 Channel type not implemented 66 Channel type Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 25 { Service or option not implemented, unspecified } 79 (None) Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 26 Invalid call reference value 81 (None) Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ___________________________________________________________________________________________________________________________________________________________________________________________________________________ 27 { Identified channel does not exist } 82 Channel identity Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ___________________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 6-5/Q.931 [2T172.931], p. 6 H.T. [3T172.931] TABLE 6-5/Q.931 (cont.) ____________________________________________________________________________________________________________________________________________________________________________________________________ Item Q.931 cause Code Q.931 diagnostic X.25 cause Code X.25 diagnostic Code ____________________________________________________________________________________________________________________________________________________________________________________________________ 28 Incompatible destination 88 Incompatible parameter Incompatible destination 33 No additional information 0 ____________________________________________________________________________________________________________________________________________________________________________________________________ 29 Invalid message, unspecified 95 (None) Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ____________________________________________________________________________________________________________________________________________________________________________________________________ 30 { Mandatory information element is missing } 96 { Information element identifier(s) } Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ____________________________________________________________________________________________________________________________________________________________________________________________________ 31 { Message type non-existent or not implemented } 97 Message type Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ____________________________________________________________________________________________________________________________________________________________________________________________________ 32 { Message not compatible with call state or message type non-existent or not implemented } 98 Message type Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ____________________________________________________________________________________________________________________________________________________________________________________________________ 33 { Information element non-existent or not implemented } 99 { Information element identifier(s) } Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ____________________________________________________________________________________________________________________________________________________________________________________________________ 34 { Invalid information element contents } 100 { Information element identifier(s) } Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ____________________________________________________________________________________________________________________________________________________________________________________________________ 35 { Message not compatible with call state } 101 Message type Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ____________________________________________________________________________________________________________________________________________________________________________________________________ 36 Recovery on timer expiry 102 Timer number Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ____________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 6-5/Q.931 [3T172.931], p. 7 H.T. [4T172.931] TABLE 6-5/Q.931 (end) ____________________________________________________________________________________________________________________________________________________________________ Item Q.931 cause Code Q.931 diagnostic X.25 cause Code X.25 diagnostic Code ____________________________________________________________________________________________________________________________________________________________________ 37 Protocol error, unspecified 111 (None) Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ____________________________________________________________________________________________________________________________________________________________________ 38 Interworking unspecified 127 (None) Remote procedure error 17 { Call setup, call clearing or registration problem } 64 ____________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - When clearing occurs during the X.25 data transfer phase, the procedure described in S 6.4.1 should be used. Note 2 - When a Q.931 RESTART message is received during the X.25 data transfer phase, switched virtual circuits shall be cleared with a clear indication packet containing cause No. 9, Out of order , with diagnostic No. 0, no additional information an X.25 reset packet sent with the same cause and diagnostic. Tableau 6-5/Q.931 [4T172.931], p. 8 H.T. [T173.931] TABLE 6-6/Q.931 Mapping of X.25 cause to Q.931 for premature clearing of the incoming call _______________________________________________________________________________ { X.25 cause in clear indication packet } Q.931 error condition _______________________________________________________________________________ | | | | | | | | | | | | | | | | _______________________________________________________________________________________________________________________________________________________________ Item X.25/X.96 cause Code Diagnostic | Code| Q.931 cause | Code| Diagnostic _______________________________________________________________________________________________________________________________________________________________ 1 DTE originated 0 No additional information 0 1XX DTE specified XX Normal call clearing 16 (None) _______________________________________________________________________________________________________________________________________________________________ 2 Network congestion 5 No additional information 0 { Switching equipment congestion } 42 (None) _______________________________________________________________________________________________________________________________________________________________ 3 Out of order 9 No additional information 0 Destination out of order 27 (None) _______________________________________________________________________________________________________________________________________________________________ 4 Remote procedure error 17 (Any allowed) Procotol error, unspecified 111 (None) _______________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - Instead of providing the above mapping of X.25 to Q.931 the PH, as a network option, may code the Q.931 cause information ele- ment to indicate CCITT Coding Standard in octet 3, X.25 in octet 3a, and code octets 4 and 5 according to Recommendation X.25, copying the cause from the X.25 clear indication packet rather than mapping it to a Q.931 cause. Tableau 6-6/Q.931 [T173.931], p. 9 6.4.4 Cause mappings 6.4.4.1 Access to/from PSPDN services (Case A) The AU may choose to follow the procedures in S 6.4.4.2 when mapping between causes delivered by the ISDN or the PSPDN. 6.4.4.2 Access to/from the ISDN virtual circuit service (Case B) There are several cases where it is necessary to map causes between Q.931 and X.25 [5]. Networks shall use Table 6-5/Q.931 and Table 6-6/Q.931 to map the causes between Q.931 and X.25 messages. The figures in Appendix II describe some example situations. 6.5 Access collision When the network offers a packet mode call at the interface simultaneously with the user requesting a packet mode call, the network shall give priority to the completion of the incoming call. If the user determines that accepting the incoming call would meet the needs of its own outgoing call request, the user may clear the call request and accept the incoming call. 7 User-to-user signalling procedures 7.1 Procedures for user-to-user signalling associated with circuit-switched calls 7.1.1 General The user-to-user signalling supplementary service(s) provides a means of communication between two users by using as a basis the layer 3 protocol defined in S 5. User-to-user signalling is used to exchange information between two users to provide the services described in the I.257A Recommendations. The exchange of user-to-user signalling is limited by flow control procedures pro- vided by the network or the user. The exchange of user-to-user information is not a network acknowledgement service. Any ack- nowledgement procedure shall be controlled at a higher layer between users. Three user-to-user signalling services associated with circuit-switched calls that may be provided by the network to users are: i) Service 1: user-to-user signalling exchanged during the set-up and clearing phases of a call, within Q.931 call control messages. ii) Service 2: user-to-user signalling exchanged during call establish- ment, between the ALERTING and CONNECT messages, within USER INFOR- MATION messages. iii) Service 3: user-to-user signalling exchanged while a call is in the Active state, within USER INFORMATION messages. All three services may be used separately or in any combina- tion in association with a single call. As an option, at call set-up, users may be able to specify that the requested user-to-user signalling service(s) is (are) required for the call, i.e., the call should not be completed if user-to-user information cannot be passed. 7.1.2 Explicit invocation procedures for services 1, 2 and 3 Services 1, 2 and 3 listed above may be provided on a per call basis following an explicit request from a user. The standard explicit invocation procedure makes use of the Facility information element defined in S 4. In addition, or alternatively, some networks may support explicit invocation procedures making use of: - keypad facility information element; or - feature activation information element. The exact operation of stimulus invocation procedures are network dependent but must follow the rules defined in S 8 of this Recommendation. More detailed protocol aspects can also be found in S 4 (for the keypad protocol invocation) and in S 5 (for the feature management protocol invocation) of Recommendation Q.932. When a network supports more than one invocation procedure, the following principles shall be followed: - for invocations using the Keypad facility infor- mation element, the network will convey the remote user's response using a Signal, a Display, or a Feature indication information ele- ment; - for invocations using the Feature activation information element, the network will convey the remote user's response using a Feature information element; - for invocations using the Facility information element, the network will convey the remote user's response using a Facility information element. In the network-to-user direction, explicit service 1 and ser- vice 2 requests may be indicated using the Facility information element. In the network-to-user direction, service 3 request may be indicated using: i) signal information element (see Note); ii) display information element (see Note); iii) feature indication information element (see Note); or iv) facility information element. For indications using the Facility information element, the user will respond with a Facility information element. No response is needed when any of the first three information elements are used. Note - These may be used only when the network has knowledge that the user receiving the notification has subscribed to the ser- vice. In this case, the network will generate the service confirma- tion to the originating user (i.e., the user requesting the ser- vice) on behalf of the user who did not originate the service request. For service 3, invoked during the active state of a call, the message use is symmetric across the user-network interface; i.e., the FACILITY message is returned in response to a FACILITY message. 7.1.3 User-to-user signalling service 1 7.1.3.1 General characteristics Service 1 allows the users to communicate by means of user-to-user signalling by transferring user-to-user information within Recommendation Q.931 call control messages during call establishment and clearing phases. 7.1.3.2 User-to-user signalling - implicit service request (preferred, i.e. - not required) Service 1 may be implicitly requested by including a User-user information element of variable length as specified in S 4.5.29 in the SETUP message transferred across the user-network interface at the calling side as described in S 5.1.1. This information element is transported by the network and delivered unchanged in the User-user information element included in the SETUP message transferred across the user-network interface at the called side as described in S 5.2.1. For invocation purposes, this information element must be at least three octets long as defined in S 4.5.29. In the case where contention by users for the incoming call is not allowed (e.g., when the SETUP message containing an implicit service invocation is delivered using a point-to-point link at the data link layer or when the network, despite using broadcast capa- bility at layer 2, knows based on the first response received from the user that no contention takes place), a User-user information element may be included in the ALERTING and/or CONNECT messages transferred across the user-network interface at the called side as described in S 5.2.5. The content of this information element is transported by the network and delivered in the User-user informa- tion element included in the corresponding message(s) transferred across the user-network interface at the calling side as described in SS 5.1.7 and 5.1.8. In the case where users are allowed to contend for an incoming call (e.g., when the SETUP message containing an implicit service invocation is delivered using the broadcast capability at the data link layer and the network is unable to determine based upon the first response received from the user that there is no contention), the User-user information element may be included in the CONNECT message transferred at the called side. The content of the User-user information element delivered to the calling user shall be that received from the selected terminal as described in S 5.2.8. Note 1 - The user may not be able to interpret incoming user-to-user information. In such situations, the user should dis- card this information without disrupting normal call handling. No specific signalling is provided by the network to accommodate this situation. Note 2 - In accordance with Recommendation X.213, the called user may perform compatibility checking using the User-user information element contents (see Annex B). 7.1.3.3 User-to-user signalling in the call establishment phase - explicit service request (preferred or required) Procedures for call establishment are as described in SS 5.1 and 5.2 with the following modifications: On call request, the SETUP message sent by the calling user shall contain a service 1 request. The SETUP message sent by the network at the called side shall also contain an explicit service 1 request. In the case where contention by users for the incoming call is not allowed (e.g., when the SETUP is delivered using the point-to-point data link layer or when the SETUP is delivered using the broadcast capability at the data link layer and the network is able to determine that no contention is occurring), and the called user can support the transfer of User-user information elements during the call, a service 1 acceptance shall be included in the ALERTING message. This explicit service 1 acceptance will be forwarded by the network to the calling user in the ALERTING message. A User-user information element may be included in the ALERT- ING message and/or CONNECT message transferred across the user-network interface at the called side as described in S 5.2.5. In accordance with Recommendation X.213, the called user may perform compatibility checking using the User-user information ele- ment contents (see Annex B). Note - The use of the explicit service 1 request procedures in the case where contention by the users for the incoming call is allowed (e.g. the SETUP message is delivered using the broadcast capability at the data link layers and the network is unable to determine that there is no contention) is for further study. 7.1.3.4 Interworking In the case of interworking with a non-ISDN network, the return of a PROGRESS or an ALERTING message with the Progress indi- cator information element indicating No. 1, call is not end-to-end ISDN; further call progress information may be available in-band , to the calling user shall serve as indication that, in particular, the delivery of User-user information elements in call control mes- sages cannot be guaranteed. 7.1.3.5 Rejection of implicit service requests Networks that cannot provide the service requested will not return a rejection indication. 7.1.3.6 Rejection of explicit service requests If the called user or network does not understand the service 1 request, then the ALERTING message returned to the calling party shall not include either a service 1 acceptance or rejection. This type of response will be taken as an implicit rejection of ser- vice 1. If the network or called user cannot support service 1, and it was requested as preferred, a service 1 rejection is included in the ALERTING message. If the service 1 request indicated as required and the called user or network cannot support it, a RELEASE COMPLETE is sent with cause No. 50, requested facility not subscribed , or cause No. 69, requested facility not implemented , and a service 1 rejection. If the called user does not include a service 1 acceptance or rejection in the ALERTING message, the network shall return an explicit rejection in the ALERTING message sent to the calling user. 7.1.3.7 User-to-user signalling in the call clearing phase A User-user information element may be included in the first message used to initiate the normal call clearing phase (see SS 5.3.3 and 5.3.4). The information contained in such an information element is transferred to the remote user in the first clearing message (see SS 5.3.3 and 5.3.4). Such a transfer is only performed if the information is received at the local exchange of the remote user before sending a clearing message to that user, otherwise, the information is discarded without sending any notification. In addition, when a SETUP message has been delivered using the broadcast capability at the data link layer, and the network is unable to determine from the first response received from the user that there is no contention, only the following user-to-user infor- mation transfer is allowed: i) in the network to called user direction: in the case of premature clearing by the calling user, user-to-user information is sent in the first clearing message to each called user that has already responded to the incoming SETUP message; ii) in the called user-network direction: the user-to-user information will only be accepted from a terminal which is selected. If multiple clearing messages are received, the network may, as a network option, retain the User-user information element along with the cause retained according to S 5.2.5.4. In the event that this cause is returned to to calling user, the associated User-user information element shall also be returned. If there are multiple clearing messages containing causes of equal priority and User-user information elements, the User-user information element contained in the first clearing message will be sent to the calling user. If any of the clearing messages with the highest priority causes do not contain User-user information elements and other clearing mes- sages with causes of lower priority do contain User-user informa- tion elements, no User-user information element shall be sent back to the calling user. In the case where contention by users for the incoming call is not allowed (e.g., when the SETUP message is delivered using the point-to-point data link layer or the network knows that a user responding to a SETUP sent using the broadcast capability at the data link layer is not contending for the call) a User-user infor- mation element may be included in the first clearing message sent by the called user prior to entering the Active state. In the case where contention by users for the incoming call is not allowed, if the called user rejects the call with a RELEASE COMPLETE message containing user-user information, the network shall deliver the user-user information in the DISCONNECT message sent to the calling user. However, if the network is providing in-band information to the calling user, and chooses not to ini- tiate clearing procedures at that time, the network may deliver the user-user information in a PROGRESS message sent to the calling user. If the network is providing in-band information to the calling user, in conjunction with call clearing, the network shall include the User-user information element in the DISCONNECT message sent to the calling user. Note - It is intended that this capability may be used to provide the clearing data transfer described in Recommendation X.213. 7.1.3.8 Unexpected user-user information in call control messages The network shall discard the User-user information element if it is received from either user in an ALERTING, CONNECT, DISCON- NECT, RELEASE or RELEASE COMPLETE message but a request for user-user signalling was not indicated (either explicitly or impli- citly) in the SETUP message delivered to the user. If this occurs, the network shall take action on the remaining contents of the mes- sage received from the user and shall send a STATUS message to the user containing cause No. 43, access information discarded 7.1.4 User-to-user signalling service 2 7.1.4.1 General characteristics Service 2 allows the users to communicate by means of user-to-user signalling by transferring two USER INFORMATION mes- sages in each direction during the call establishment phase. This service allows either an implicit or explicit rejection (see S 7.1.4.3). Service 2 is only applicable when a SETUP message has been delivered using the point-to-point data link layer at the user-network interface at the called side. 7.1.4.2 Call establishment Procedures for call establishment are as described in SS 5.1 and 5.2 with the following modifications. On call request, the SETUP message sent by the calling user will contain a service 2 request. The SETUP message sent by the network at the called side will also contain an explicit service 2 request. If the called user can support USER INFORMATION messages dur- ing call establishment, a service 2 acceptance shall be included in the ALERTING message sent to the network. This explicit acceptance indication shall be forwarded in the ALERTING message sent by the network to the calling user. 7.1.4.3 Service rejection If the called user or network does not understand the ser- vice 2 request, then the ALERTING message returned to the calling user will not include either a service 2 acceptance or rejection. This type of response shall be taken as an implicit rejection of service 2. Alternatively, if the network or called user cannot sup- port USER INFORMATION messages during call establishment, and the request is indicated as preferred, a service 2 rejection is included in the ALERTING message. If the service 2 request indicated is required, and the called user or network cannot support or provide the service, a RELEASE COMPLETE is sent with cause No. 50, requested facility not sub- scribed , or cause No. 69, requested facility not implemented , and a service 2 rejection. If the called user does not include a service 2 acceptance or rejection in the ALERTING message, the network shall return an explicit rejection in the ALERTING message sent to the calling user. In the case of interworking with a non-ISDN network, a PRO- GRESS or ALERTING message with the progress indicator information element indicating No. 1, call is not end-to-end ISDN; further call progress information may be available in-band , is sent to the cal- ling user to indicate that the full service cannot be guaranteed. 7.1.4.4 Transfer of USER INFORMATION messages Once an ALERTING message has been received, both the involved users can transfer information between themselves by transferring USER INFORMATION messages across the user-network interface. The network provides for the transfer of such messages from the calling to the called side and vice versa. The USER INFORMATION message includes the Call reference, the Protocol discriminator, and the User-user information elements as defined in S 3.1.23. The More data information element may also be included by the source user to indicate to the remote user that another USER INFORMATION message will follow, containing informa- tion belonging to the same block. The use of More data information element is not supervised by the network. If the user-to-user signalling facility is provided, no more than two USER INFORMATION messages may be transferred in each direction after the ALERTING message and before the CONNECT mes- sage. Sending or receiving of USER INFORMATION messages does not change the state of the call. 7.1.5 User-to-user signalling service 3 7.1.5.1 General Service 3 allows the users to communicate by means of transferring USER INFORMATION messages during the Active state of a call. This service allows either an implicit or explicit rejection (see S 7.1.5.3). This service may be requested during call estab- lishment or during the Active state of the call. 7.1.5.2 Service request during call establishment Procedures for call establishment are as described in SS 5.1 and 5.2 with the following modifications: a) On call request, the SETUP message sent by the calling user will contain a service 3 request. The SETUP sent by the network at the called side will also contain a service 3 request. b) If the called user can support USER INFORMATION message transfer during the Active state, a service 3 acceptance shall be included in the CONNECT message. 7.1.5.3 Rejection of service requested during call estab- lishment If the called user or network does not understand the service 3 request, then the CONNECT message returned to the calling user shall not include either a service 3 acceptance or rejection. This type of response will be taken as an implicit rejection of ser- vice 3. Alternatively, if the network or called user cannot support USER INFORMATION messages during the Active state, and the request is indicated as preferred, a service 3 rejection is included in the CONNECT message. If the service 3 request indicated required, and the called user or network cannot support or provide the service, a RELEASE COMPLETE is sent with cause No. 50, requested facility not subscribed , or cause No. 69, requested facility not implemented , and a service 3 rejection. If the called user does not include a service 3 acceptance or rejection in the CONNECT message, the network shall return a ser- vice 3 rejection in the CONNECT message sent to the calling user. When interworking with a non-ISDN network occurs, a PROGRESS or an ALERTING message with the Progress indicator information ele- ment indicating No. 1, call is not end-to-end ISDN; further call progress information may be available in-band , is sent to the cal- ling user to indicate that the service cannot be guaranteed. 7.1.5.4 Service request after call establishment During the Active state of a call, a user may request service 3 preferred only. A FACILITY message indicating a service 3 request is sent from the requesting user to the network. The network shall indicate the service 3 request to the user that did not request service 3 in the FACILITY message. If the user that did not request service 3 can support the transfer of USER INFORMATION messages during the Active state, a service 3 acceptance is returned in the FACILITY message. This explicit acceptance indication shall be conveyed back to the requesting user in a FACILITY message. 7.1.5.5 Rejection of service request after call establish- ment If the user that did not request service 3 or network does not understand the service 3 request, then no message is returned. This response shall be taken as an implicit rejection of the service request. Alternatively, if the requested user or network cannot support or provide the service requested, a service 3 rejection shall be returned in the FACILITY message. If the requested user does not respond to the service 3 request, the network shall return a service 3 rejection to the cal- ling user. 7.1.5.6 Transfer of USER INFORMATION messages Once the call is established, both users can transfer informa- tion between themselves by transporting USER INFORMATION messages across the user-network interface. The network provides for the transfer of such messages from the calling to the called side and vice versa. The USER INFORMATION message includes the Call reference, the Protocol discriminator, and the User-user information elements. The More data information element may also be included by the source user to indicate to the remote user that another USER INFORMATION message will follow, containing information belonging to the same block. The use of the More data information element is not super- vised by the network. 7.1.5.7 Congestion control of USER INFORMATION messages The network or user will flow-control, when needed, the transfer of USER INFORMATION messages from a user or network by means of a CONGESTION CONTROL message containing a congestion level information element. Two indications of congestion level are speci- fied: receive not ready and receive ready . On receipt of the former, the user or network should suspend sending USER INFORMATION messages; on receipt of the latter, sending may recommence. After having sent a receive not ready indication, the network or user shall discard USER INFORMATION messages which are subsequently received. The network or user will send a CONGESTION CONTROL mes- sage with a receive not ready indication whenever a USER INFORMA- TION message is locally discarded, if it is possible. The CONGES- TION CONTROL message shall also include a cause No. 43, access information discarded . The receipt of the receive ready indication shall be inter- preted as an indication that no more than n USER INFORMATION mes- sages may be sent before another receive ready indication is received. The value of n requires further study. Congestion control procedure itself should be regarded as local. 7.1.6 Unexpected USER INFORMATION messages 7.1.6.1 Receipt of USER INFORMATION messages in incompati- ble call states Whenever a USER INFORMATION message is received from the user and it is not allowed by an invoked service (e.g., in any other state than Active where only service 3 is invoked), the message will be discarded by the network. The network will respond with a STATUS message with a cause No. 43, access information discarded . 7.1.6.2 Receipt of unexpected USER INFORMATION messages Whenever a USER INFORMATION message is received by the network from the calling or called user after the network has indicated that user-to-user cannot be supported, that message shall be dis- carded without further action. 7.1.7 Requesting user-to-user signalling services 1, 2 and 3 7.1.7.1 General This section describes procedures for requesting services 1, 2 and 3 in the same SETUP message. These services are described in SS 7.1.3, 7.1.4 and 7.1.5, respectively. Note - User-to-user service 1 implicit request/acceptance follows S 7.1.3.2 procedures. Only explicit service 1 requests may follow the procedure in this section. 7.1.7.2 Call establishment Procedures for call establishment are described in SS 7.1.3.3, 7.1.4.2, and 7.1.5.2 with the following modifications. On call request, the SETUP message sent by the calling user will contain independent service 1, 2, 3 requests. The SETUP sent by the network at the called sides will also contain the same independent service requests. If the called user can support the indicated services, then specific services accep- tances may all be indicated in the ALERTING message. Alternatively, the user may accept services 1 and 2 in the ALERTING message, as defined in SS 7.1.3.3 and 7.1.4.2, and service 3 in the CONNECT message, as defined in S 7.1.5.2. 7.1.7.3 Service rejection If the called user or network does not understand any of the services requested, then the ALERTING and CONNECT messages returned to the calling user will not include either a service acceptance or rejection. This type of response will be taken as an implicit rejection of all services. If the called user or network does not understand a specific service request, that specific service is implicitly rejected following the procedures defined in SS 7.1.3.6, 7.1.4.3 or 7.1.5.3. Alternatively, if the network or called user cannot support one or more services requested, and the service requests were indicated as preferred, the specific service rejec- tion may be included in the ALERTING messages. The services may also be rejected following the procedures in SS 7.1.3.6, 7.1.4.3 or 7.1.5.3. If the called user does not include a service 1, 2 or 3 accep- tance or rejection in the ALERTING and/or CONNECT message, the net- work shall return a service 1, 2 or 3 rejection in the ALERTING and/or CONNECT message sent to the calling user. When interworking with a non-ISDN network occurs, a PROGRESS or an ALERTING message with the Progress indicator information ele- ment indicating No. 1, call is not end-to-end ISDN; further call progress information may be available in-band , is sent to the cal- ling user to indicate that the service cannot be guaranteed. If any or all of the services requested is indicated as required, then the network or called user that cannot support or provide the request will send a RELEASE COMPLETE with cause No. 50, requested facility not subscribed , or cause No. 69, requested facility not implemented , and the service rejection associated with that service. 7.1.7.4 Transfer of USER INFORMATION messages The transfer of USER INFORMATION messages is defined in SS 7.1.4.4 and 7.1.5.6. 7.1.8 Summary of actions to be taken by the called side and subsequent network action Actions to be taken by the called side and the subsequent net- work actions are summarized in Table 7-1/Q.931. H.T. [T174.931] TABLE 7-1/Q.931 Actions to be taken at the called side (Note 1) _______________________________________________________________________________________________________________________________________________________ Case Called user's capability Requested service (Note 2) Called user action { Calling user network interface action } _______________________________________________________________________________________________________________________________________________________ 1 { Can analyze the service and accepts the service } { Services 1, 2, 3 preferred or required } { Return appropriate ACK indication by the response message } { Pass ACK to the calling user in normal call control messages } _______________________________________________________________________________________________________________________________________________________ { { 2 { _______________________________________________________________________________________________________________________________________________________ { Services 1, 2, 3 preferred { 3 { _______________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - This Table covers the point-to-point case. In the point-to-multipoint case, it is applied only if no contention to a broadcast SETUP EXISTS. Note 2 - When an implicit user-to-user signalling invocation is received for service 1 (which means that the user-to-user informa- tion element is included in the SETUP but the explicit invocation is not), the request is regarded as preferred. Note 3 - When no indication of acceptance or rejection of requested service is received from the called user, then it is regarded an an implicit service rejection. Therefore, in service 1 the user-user information element carried by originating SETUP mes- sage is not guaranteed an acknowledgement. The action to be taken in this case is up to the calling user. Table 7-1/Q.931 [T174.931], p. 7.2 Procedures for user-to-user signalling not associated with circuit-switched calls 7.2.1 General characteristics This feature allows the users to communicate by means of user-to-user signalling without setting up a circuit-switched con- nection. A temporary signalling connection is established and cleared in a manner similar to the control of a circuit-switched connection. 7.2.2 Call establishment Procedures for call establishment are as described in SS 5.1 and 5.2 with the following modifications. On call request, the calling user sends a SETUP message iden- tifying, within the Bearer capability and Channel identification information elements, a temporary signalling connection to be esta- blished on SAPI = 0. The SETUP message is encoded to indicate: i) Bearer capability information element: - Unrestricted digital information in the informa- tion transfer capability field; - Packet mode in the transfer mode field; - User information layer 2 protocol is Recommendation Q.921 and user information layer 3 protocol is Recommendation Q.931 in the layer and protocol identification field. ii) Channel identification information element: - Exclusive in the preferred/exclusive field; - D-channel in the D-channel indicator field; - No channel in the channel selection field. If the network determines that the requested temporary signal- ling connection service is not authorized or is not available, the network shall initiate call clearing in accordance with S 5.3.2 | ) or S 5.3.2 | ) 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 . The called user accepts the temporary signalling connection request by sending a CONNECT message towards the calling user. After the called user has received a CONNECT ACKNOWLEDGE message, it may begin sending USER INFORMATION messages. Once the calling user receives a CONNECT message, it can begin sending USER INFORMA- TION messages. 7.2.3 Transfer of USER INFORMATION messages Once a temporary signalling connection is established, both users can transfer information between themselves by transferring USER INFORMATION messages across the user-network interface. The network provides for the transfer of such messages from the called to the calling side and vice versa. The USER INFORMATION message includes the Call reference, the Protocol discriminator, and the User-to-user information elements as defined in S 3.3.13. The More data information element may also be sent by the source user to indicate to the remote user that another USER INFORMATION message will follow, containing informa- tion belonging to the same block. The use of the More data informa- tion element is not supervised by the network. 7.2.4 Congestion control of USER INFORMATION messages Congestion control procedures are the same as those described in S 7.1.5.7. 7.2.5 Call clearing The clearing of an established temporary signalling connection can be initiated by the user or network by sending a RELEASE mes- sage towards the far end user. The clearing procedure followed and the timers involved are the same as those for clearing a circuit-switched connection as described in SS 5.3.3 and 5.3.4. 8 Application of circuit-switched supplementary services to terminals using stimulus procedures This section describes how stimulus procedures may be used by an ISDN terminal to invoke supplementary services. Signalling messages sent by terminals using stimulus pro- cedures to invoke network supplementary services are usually gen- erated as a direct result of actions by the terminal user (e.g. feature key activation) and in general do little more than describe the event which has taken place at the man-machine inter- face (MMI). For the establishment of supplementary services, such stimulus operations at the MMI will normally be conveyed in the keypad or feature activation information element within, for exam- ple, the INFORMATION message. The meaning of the keypad or feature activation information may be customer specific. Similarly, signal- ling messages sent by the network to terminals using stimulus pro- cedures may contain explicit instructions regarding the operations to be performed by the terminals (e.g. feature indication, start alerting, etc.) Terminals using stimulus procedures are not expected to main- tain a record of the states of that service since they have a master-slave relationship with the network. Such terminals may also support only a compatible subset of the call states defined in S 2.1.1 and may only report that compatible subset in the call state information element as described in the procedures of S 5. At a minimum, the user shall be able to report the call state when the call is active. 9 List of system parameters The description of timers in the following tables should be considered a brief summary. The precise details are found in SS 5 and 6, which should be considered the definitive descriptions. 9.1 Timers in the network side The timers specified in Table 9-1/Q.931 are maintained in the network side of the interface. 9.2 Timers in the user side The timers specified in Table 9-2/Q.931 are maintained in the user side of the interface. Timers T305, T308 and T313 are manda- tory for all user side implementations. Blanc H.T. [1T175.931] _________________________________________________ TABLE 9-1/Q.931 { Timers in the network side } _________________________________________________ | | | | | | | | | | __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Timer number Default time-out value State of call Cause for start Normal stop At the first expiry At the second expiry Cross-reference __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T301 Minimum 3 min Call received ALERT received CONN received Clear call Timer is not restarted Note 2 __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T302 10-15 s (Note 5) Overlap sending { SETUP ACK sent. Receipt of INFO, restarts T302 } { With sending complete indication, or network alert, or connect request received } { Clear if call information determined to be definitely incomplete; else send CALL PROC } Timer is not restarted Mandatory __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T303 4 s (Note 1) Call present SETUP sent { ALERT, CONN, CALL PROC or SETUP ACK received, REL COMP received if SETUP sent on point-point data link } { Retransmit SETUP; restart T303. If REL COMP has been received, clear the call } { Clear network connection. Enter call abort state } Mandatory __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T304 20 s (provisional values) Overlap receiving { SETUP ACK received. Sending of INFO restarts T304 } { Send INFO; receive CALL PROC, ALERT or CONN } Clear the call Timer is not restarted { Mandatory only if S 5.2.4 implemented } __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T305 30 s Disconnect indication { DISC without progress indicator No. 8 sent } REL or DISC received Network sends REL Timer is not restarted Mandatory __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 9-1/Q.931 [1T175.931], p. 11 A L'ITALIENNE H.T. [2T175.931] _________________________________________________ { TABLE 9-1/Q.931(cont.) } _________________________________________________ | | | | | | | | ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Timer number Default time-out value State of call Cause for start Normal stop At the first expiry At the second expiry Cross-reference ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T306 30 s (Note 6) Disconnect indication { DISC with progress indicator No. 8 sent. } REL or DISC received { Stop the tone/announcement. Send REL } Timer is not restarted { Mandatory when in-band tones/ announcements are provided; see SS 5.4, 5.3.4.1 and Rec. I.300 series } ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T307 3 min Null SUSP ACK sent RES received { Clear the network connection. Release call identity } Timer is not restarted Mandatory ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T308 4 s (Note 1) Release request REL sent REL COMP or REL received { Retransmit REL and restart T308 } { Place B-channel in maintenance condition. Release call reference (Note 9) } Mandatory ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T309 90 s Any stable state { Data link disconnection. Calls in stable states are not lost } Data link reconnected { Clear network connection. Release B-channel and call reference } Timer is not restarted Mandatory ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T310 10 s (Note 7) Incoming call proceeding CALL PROC received { ALERT, CONN or DISC received. If DISC, retain cause and continue timing } { Clear call in accordance with S 5.2.5.3 } Timer is not restarted Mandatory ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T312 T303 + 2 s { Call present, call abort, etc. } { SETUP sent or resent on broadcast data link } Timeout Note 4 Timer is not restarted Mandatory ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | Tableau 9-1/Q.931 [2T175.931], p. 12 A L'ITALIENNE H.T. [3T175.931] _________________________________________________ { TABLE 9-1/Q.931 (end) } _________________________________________________ | | | | | | | | __ Timer number Default time-out value State of call Cause for start Normal stop At the first expiry At the second expiry Cross-reference __ T314 4 s Receiving segmented message Message segment received Last message segment received Discard message Timer is not restarted Mandatory see Annex K __ T316 2 min Restart request REST sent REST ACK received { REST may be retransmitted several times } { REST may be retransmitted several times } { Mandatory when S 5.5 is implemented } __ T317 (Note 3) Restart REST received { Internal clearing of call references } Maintenance notification Timer is not restarted { Mandatory when S 5.5 is implemented } __ T320 30 s (Note 8) { a) For B-channel access: active b) For D-channel access: null } { a) For B-channel access: CONN sent or received b) For D-channel access: DL-ESTABLISH-CONFIRM or DL-ESTABLISH-INDICATION received c) Last logical channel, cleared } { Call request packet received; or incoming call packet delivered; or DISC received; or for D-channel access DL-RELEASE-IND received } { a) For B-channel access: disconnect link layer and initiate clearing b) For D-channel access: send DL-RELEASE- REQ } Timer is not restarted Optional. See S 6.3 __ T321 30 s Any call state D-channel failure { Response to layer 3 message received } { Send DL-ESTABLISH- REQ on both D-channels } Timer is not restarted { Mandatory when ANNEX F is implemented } __ T322 4 s Any call state STAT ENQ sent { STAT DISC REL or REL COM received } { STAT ENQ may be retransmitted several times } { STAT ENQ may be retransmitted several times } { Mandatory when S 5.8.10 is implemented } __ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 9-1/Q.931 [3T175.931], p. 13 A L'ITALIENNE H.T. [4T175.931] Tableau 9-1/Q.931 [4T175.931], p. 14 A L'ITALIENNE H.T. [1T176.931] _________________________________________________ TABLE 9-2/Q.931 { Timers in the user side } _________________________________________________ | | | | | | | | | | _________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Timer number Default time-out value State of call Cause for start Normal stop At the first expiry At the second expiry Cross-reference _________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T301 Minimum 3 min Call delivered ALERT received CONN received Clear call Timer is not restarted { Mandatory when Annex D is implemented. (Note 3) } _________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T302 15 s (provisional value) Overlap receiving { SETUP ACK sent. Restart when INFO received } { INFO received with sending complete indication; or internal alerting; or internal connection; or a determination that sufficient call information has been received } { Clear if call information determined to be incomplete; else, send CALL PROCeeding } Timer is not restarted { Mandatory only if S 5.2.4 is implemented } _________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T303 4 s (Note 1) Call initiated SETUP sent { ALERT (Annex D) CONN (Annex D) SETUP ACK, CALL PROC, or REL COMP received } { Retransmit SETUP; restart T303. If REL COMP was received, clear the call (Annex D) } { Clear internal connection. Send REL COMP. Enter null state } { Mandatory when Annex D is implemented; otherwise optional } _________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T304 15 s Overlap sending { INFO sent. Restarted when INFO sent again } { CALL PROC ALERT, CONN, or DISC received } DISC sent Timer is not restarted Optional _________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ T305 30 s Disconnect request DISC sent REL or DISC received REL sent Timer is not restarted Mandatory _________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 9-2/Q.931 [1T176.931], p. 15 A L'ITALIENNE H.T. [2T176.931] _________________________________________________ { TABLE 9-2/Q.931 (cont.) } _________________________________________________ | | | | | | | | ___________ Timer number Default time-out value State of call Cause for start Normal stop At the first expiry At the second expiry Cross-reference ___________ T308 4 s (Note 1) Release request REL sent REL COMP or REL received Retransmit REL; restart T308 { B-channel placed in maintenance condition. Call reference released (Note 5) } Mandatory ___________ T309 90 s Any stable state { Data link disconnection. Calls in stable states are not lost } Data link reconnected { Clear internal connection. Release B-channel and call reference } Timer is not restarted Optional ___________ T310 (Note 4) 10 s Outgoing call proceeding CALL PROC received { ALERT, CONN, DISC, or PROG received } Send DISC Timer is not restarted { Mandatory when Annex D is implemented } ___________ T313 4 s (Note 1) Connect request CONN sent CONNect ACKnowledge received Send DISCconnect Timer is not restarted Mandatory ___________ T314 4 s Receiving segmented message Message segment received Last message segment received Discard message Timer is not restarted Mandatory; see Annex L ___________ T316 2 m Restart request REST sent REST ACK received { REST may be retransmitted several times } { REST may be restransmitted several times } { Mandatory when S 5.5 is implemented } ___________ T317 (Note 2) Restart REST received { Internal clearing of call references } Maintenance notification Timer is not restarted { Mandatory when S 5.5 is implemented } ___________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 9-2/Q.931 [2T176.931], p. 16 A L'ITALIENNE H.T. [3T176.931] _________________________________________________ { TABLE 9-2/Q.931 (end) } _________________________________________________ | | | | | | | | _____________________________________________________________________________________________________________________________________________________________________________________________________________________________ Timer number Default time-out value State of call Cause for start Normal stop At the first expiry At the second expiry Cross-reference _____________________________________________________________________________________________________________________________________________________________________________________________________________________________ T318 4 s Resume request RES sent RES ACK or RES REJ received { Clear internal connection. Release call reference. Enter null state } Timer is not restarted { Mandatory when S 5.6 is implemented } _____________________________________________________________________________________________________________________________________________________________________________________________________________________________ T319 4 s Suspend request SUSP sent SUSP ACK or SUSP REJ received { Enter active state. Notify user application } Timer is not restarted { Mandatory when S 5.6 is implemented } _____________________________________________________________________________________________________________________________________________________________________________________________________________________________ T321 30 s Any call state D-channel failure { Response to layer 3 message received } { Send DL-ESTABLISH- REQ on both D-channels } Timer is not restarted { Mandatory when Annex F is implemented } _____________________________________________________________________________________________________________________________________________________________________________________________________________________________ T322 4 s Any call state STAT ENQ sent { STAT, DISC, REL or REL COMP received } { STAT ENQ may be retransmitted several times } { STAT ENQ may be retransmitted several times } { Mandatory when S 5.8.10 is implemented } _____________________________________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - This default value assumes the use of default values at layer 2; i.e., (N200 + 1) times T200. Whether these values should be modified when layer 2 default values are modified by an automatic negotiation procedure is for further study. Note 2 - The value of this timer is implementation dependent, but should be less than the value of T316. Note 3 - The user may already have applied an internal alerting supervision timing function; e.g., incorporated within call con- trol. If such a function is known to be operating on the call, then timer T301 is not used. Note 4 - T310 is not started if progress indictor 1 or 2 has been delivered in the CALL PROCEEDING message or in a prevous PROGRESS message. Note 5 - The restart procedures contained in S 5.5 may be used on B-channels in the maintenance condition. Tableau 9-2/Q.931 [3T176.931], p. 17 A L'ITALIENNE 
