5i' FASCICLE VI.11 Recommendations Q.930 to Q.940 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 (DSS 1), NETWORK LAYER, USER-NETWORK MANAGEMENT Blanc MONTAGE: PAGE 2 = PAGE BLANCHE SECTION 1 NETWORK LAYER Recommendation Q.930 ISDN USER-NETWORK INTERFACE LAYER 3 - GENERAL ASPECTS 1 General 1.1 Introduction This Recommendation describes in general terms the D-channel layer 3 functions and protocol employed across an ISDN user-network interface. Details are provided in Recommendation Q.931(I.451) [1] and in Recommendation Q.932(I.452) [2]. _________________________ This Recommendation appears in the I-series of Recom- mendations as Recommendation I.450. The term "Layer 3" is a general term used in these Recommenda- tions to refer to the procedures described in Recommendation Q.931(I.451) and in Recommendation Q.932(I.452). The layer 3 protocol provides the means to establish, maintain and terminate network connections across an ISDN between communi- cating application entities. In addition, it provides generic pro- cedures which may be used for the invocation and operation of sup- plementary services. The detailed description of the layer 3 protocol in Recommendation Q.931(I.451) and Recommendation Q.932(I.452) make use of the definition and termi- nology concepts of the ISDN protocol reference model given in Recommendation I.320 [3]. Recommendation Q.931(I.451) and Recommendation Q.932(I.452) do not at present cover all functions which may be specified for layer 3. Recommendation Q.931(I.451), Recommendation Q.932(I.452) and Recommendation I.320 are not presently completely consistent in their structure of protocols. Further study is required to enhance these Recommendations in order to resolve these inconsistencies. Alignment/interworking between facilities defined in the Q.930-series Recommendations and the services defined in the I.250-series Recommendations is for further study. The application of Recommendations Q.931 and Q.932 to the detailed operation of each individual supplementary service will be the subject for the future Recommendations in the Q.930 series. 1.2 Connection control by the user of an ISDN requires: a) application of layer 3 protocol for control of circuit-switched connections and/or packet-switched connections, in combination with; b) application of an appropriate data link layer service (supported by an appropriate physical layer service). Layer 3 provides to the user the functions associated with the establishment and operation of a network connection. Layer 3 makes invisible to the user how it utilizes underlying resources such as data link connections to provide a network connection. 1.3 Services provided by the data link layer Layer 3 utilizes functions and services provided by the data link as defined in Recommendations Q.920(I.440) [4] and Q.921(I.441) [5]. These services are summarized below: a) establishment of data link connections; b) error-protected transmission of data; c) re-establishment of data link connection (indi- cating loss of information). 1.4 Symmetry of the layer 3 protocol It is intended that the layer 3 protocol is fully symmetrical to enable direct user-to-user communication (e.g., PABX-to-PABX communication over a leased circuit). In order to achieve this objective, several options are incor- porated in Recommendation Q.931. They are described in Annex D to Recommendation Q.931. 2 Structure of layer 3 2.1 Categories of functions There are two categories of functions performed at layer 3 and services provided by layer 3 in the establishment of network con- nections. The first category contains those functions which directly control the connection establishment. The second category contains those functions relating to the transport of messages additional to the functions provided by the data link layer. An example of the additional layer 3 functions is the provision of re-routing of signalling messages on an alternate D-channel (where provided) in the event of D-channel failure. Other possible functions in this category may include multiplexing and message segmenting and blocking. It is intended that the communications between these two categories will be aligned as far as possible with the primitives used between the user parts and the message transfer part in Sig- nalling System No. 7. Further study is required to determine the functions to be included in each category. 2.2 Layer 3 functions The layer 3 protocol described in this Recommendation is designed to effect the establishment and control of circuit-switched and packet-switched connections. The functions support procedures for both basic call and call control in conjunc- tion with network-provided supplementary facilities. Furthermore, services involving the use of connections of different types, according to user's specification, may be effected through "multi-media" call control procedures. Functions performed by layer 3 include the following: a) processing of primitives for communicating with the data link layer; b) generation and interpretation of layer 3 mes- sages for peer-level communication; c) administration of timers and logical entities (e.g., call-references) used in the call control procedures; d) administration of access resources including B-channels and packet-layer logical channels (e.g., Recommendation X.25 [6]); e) checking to ensure that services provided are consistent with user requirements (e.g., as expressed by bearer capability, addresses, low layer and high layer compatibilities). This list of layer 3 functions is not exhaustive, and it is not intended to imply that all functions are provided on both the terminal and the network side of the user-network interface. The following general functions may also be performed by layer 3: a) routing and relaying; b) network connection control; c) conveying user-to-network and network-to-user information; d) network connection multiplexing; e) segmenting and reassembly; f ) error detection; g) error recovery; h) sequencing; i) congestion control and user data flow control; and j) restart. 2.2.1 Routing and relaying Network connections exist either between users or between users and ISDN exchanges. Network connections may involve inter- mediate systems which provide relays to other interconnecting sub- networks and which facilitate interworking with other networks. Routing functions determine an appropriate route between layer 3 addresses. 2.2.2 Network connection control This function includes mechanisms for providing network con- nections making use of data link connections provided by the data link layer. 2.2.3 Conveying user information This function may be carried out with or without the estab- lishment of a circuit-switched connection. 2.2.4 Network connection multiplexing Layer 3 provides multiplexing of call control information for multiple calls onto a single data link connection. 2.2.5 Segmenting and reassembly Layer 3 may segment and reassemble Recommendation Q.931 mes- sages for the purpose of facilitating their transfer across local user-network interface. 2.2.6 Error detection Error detection functions are used to check for procedural errors in the layer 3 protocol. Error detection in layer 3 uses, among other information, error notification of loss of information from the data link layer. 2.2.7 Error recovery This function includes mechanisms for recovering from detected errors. 2.2.8 Sequencing This function includes mechanisms for providing the service of sequenced delivery of layer 3 information over a given network con- nection when requested. In normal conditions layer 3 ensures the delivery of information in the sequence it is submitted by the user. 2.2.9 Congestion control and user data flow control Layer 3 may indicate rejection or unsuccessful indication for connection establish requests to control congestion within a net- work. Flow control for the user-to-user signalling messages is described in Recommendation Q.931(I.451). 2.2.10 Restart This function is used to return channels and interfaces to an idle condition to recover from certain abnormal conditions. 3 Structure of layer 3 Recommendations The following is the structure of the layer 3 Recommendations: Q.930(I.450) - ISDN user-network interface layer 3 - General aspects Q.931(I.451) - ISDN user-network interface layer 3 specification for basic call control Q.932(I.452) - Generic procedures for the control of ISDN supplementary services 4 Interface between layer 3 and the adjacent layers 4.1 Overview of the interfaces ISDN user-network interface layer 3 provides its services to the upper layer via layer 3 service access point (SAP), and receives services from the data link layer via data link layer SAP, as is shown in Figure 1/Q.930. A particular service is provided to the upper layer, or received from the data link layer, by exchang- ing a corresponding sequence of primitives across the SAP. 4.2 Interface between layer 3 and data link layer Overview of the interface between ISDN user-network interface layer 3 and the data link layer from the view point of the data link layer is given in S 2 of Recommendation Q.920(I.440). Primi- tives and primitive procedures for this interface are specified in S 4 of Recommendation Q.921(I.441). 4.3 Interface between layer 3 and upper layer Primitives and primitive procedures for this interface are left for further study. Figure 1/Q.930, p. References [1] CCITT Recommendation ISDN user-network interface layer 3 specification for basic call control , Vol, VI(III), Rec. Q.931(I.451). [2] CCITT Recommendation Generic procedures for the control of ISDN supplementary services , Vol. VI(III), Rec. Q.932(I.452). [3] CCITT Recommendation ISDN protocol reference model , Vol. III, Rec. I.320. [4] CCITT Recommendation ISDN user-network interface data link layer - General aspects , Vol. VI(III), Rec. Q.920(I.440). [5] CCITT Recommendation ISDN user-network interface data link layer specification , Vol. VI(III), Rec. Q.921(I.441). [6] CCITT Recommendation Interface between data terminal equipment (DTE) and data circuit terminating equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit , Vol. VIII, Rec. X.25. Abbreviations used in Recommendations Q.930(I.450) and Q.931(I.451) See list at the end of Recommendation Q.931. Recommendation Q.931 ISDN USER-NETWORK INTERFACE LAYER 3 SPECIFICATION FOR BASIC CALL CONTROL 1 General This Recommendation specifies the procedures for the estab- lishing, maintaining, and clearing of network connections at the ISDN user-network interface. These procedures are defined in terms of messages exchanged over the D-channel of basic and primary rate interface structures. The functions and procedures of this proto- col, and the relationship with other layers, are described in gen- eral terms in Recommendation Q.930 (I.450) [1]. This Recommendation is intended to specify the essential features, procedures, and messages required for call control in the D-channel. However, there are some details of procedure which have not yet been specified, and which will be the subject of further study. 1.1 Scope of the Recommendation The procedures currently described in this Recommendation are for the control of circuit-switched connections, user-to-user sig- nalling connections, and packet-switched connections. The transport of other message-based information flows on the D-channel is a sub- ject for further study and will be included in related Recommenda- tions. Note 1 - The term "layer 3" is used for the functions and protocol described in this Recommendation [see Recommendation Q.930 (I.450)]. The terms "data link layer" and "layer 2" are used inter- changeably to refer to the layer immediately below layer 3. Note 2 - Alignment of the functions and protocol with those of OSI network layer is for further study. 1.2 Application to interface structures The layer 3 procedures apply to the interface structures defined in Recommendation I.412 [2]. They use the functions and services provided by layer 2. The unacknowledged information transfer service is used by layer 3 to provide point-to-multipoint operation as described in S 5.2. The layer 3 procedures request the services of layer 2 and receive information from layer 2 using the primitives defined in Recommendation Q.921 [3]. These primitives are used to illustrate the communication between the protocol layers and are not intended to specify or constrain implementations. 2 Overview of call control In this Recommendation the terms "incoming" and "outgoing" are used to describe the call as viewed by the user side of the inter- face. In the paragraphs which follow states are defined for circuit switched calls in S 2.1 (call states), for packet mode access con- nections in S 2.2 (access connection states) for temporary signal- ling connections in S 2.3 (call states), and for the interface in S 2.4 (global call reference states). This paragraph defines the basic call control states that individual calls may have. These definitions do not apply to the state of the interface itself, any attached equipment, the D-channel, or the logical links used for signalling on the D-channel. Because several calls may exist simultaneously at a user-network interface, and each call may be in a different state, the state of the interface itself cannot be unambiguously defined. Note - Additional states and SDL diagrams may be defined when new procedures are developed. Detailed description of the procedures for call control are given in SS 5, 6, 7, and 8 in terms of: (a) the messages defined in S 3 which are transferred across the user-network interface; and (b) the information processing and actions that take place at the userside and the network side. Overview and detailed SDL diagrams for call control of circuit-switched calls are contained in Annex A. Throughout this Recommendation, references are made to B-channels. For services using H-channels, the references to B-channels should be taken to refer to the appropriate H-channel. Further study may be needed on other enhancements to support such services. 2.1 Circuit switched calls This paragraph defines the basic call control states for cir- cuit switched calls. The procedures for call control are given in S 5. Annex D contains optional procedures (as an extension to the basic procedures) to allow symmetric signalling. These states are defined in Annex D. 2.1.1 Call states at the user side of the interface The states which may exist on the user side of the user-network interface are defined in this paragraph. 2.1.1.1 Null state (U0) No call exists. 2.1.1.2 Call initiated (U1) This state exists for an outgoing call, when the user requests call establishment from the network. 2.1.1.3 Overlap sending (U2) This state exists for an outgoing call when the user has received acknowledgement of the call establishment request which permits the user to send additional call information to the network in overlap mode. 2.1.1.4 Outgoing call proceeding (U3) This state exists for an outgoing call when the user has received acknowledgement that the network has received all call information necessary to effect call establishment. 2.1.1.5 Call delivered (U4) This state exists for an outgoing call, when the calling user has received an indication that remote user alerting has been ini- tiated. 2.1.1.6 Call present (U6) This state exists for an incoming call when the user has received a call establishment request but has not yet responded. 2.1.1.7 Call received (U7) This state exists for an incoming call when the user has indi- cated alerting but has not yet answered. 2.1.1.8 Connect request (U8) This state exists for an incoming call when the user has answered the call and is waiting to be awarded the call. 2.1.1.9 Incoming call proceeding (U9) This state exists for an incoming call when the user has sent acknowledgement that the user has received all call information necessary to effect call establishment. 2.1.1.10 Active (U10) This state exists for an incoming call when the user has received an acknowledgement from the network that the user has been awarded the call. This state exists for an outgoing call when the user has received an indication that the remote user has answered the call. 2.1.1.11 Disconnect request (U11) This state exists when the user has requested the network to clear the end-to-end connection (if any) and is waiting for a reponse. 2.1.1.12 Disconnect indication (U12) This state exists when the user has received an invitation to disconnect because the network has disconnected the end-to-end con- nection (if any). 2.1.1.13 Suspend request (U15) This state exists when the user has requested the network to suspend the call and is waiting for a response. 2.1.1.14 Resume request (U17) This state exists when the user has requested the network to resume a previously suspended call and is waiting for a response. 2.1.1.15 Release request (U19) This state exists when the user has requested the network to release and is waiting for a response. 2.1.1.16 Overlap receiving (U25) This state exists for an incoming call when the user has ack- nowledged the call establishment request from the network and is prepared to receive additional call information (if any) in overlap mode. 2.1.2 Network call states The call states that may exist on the network side of the user-network interface are defined in this paragraph. 2.1.2.1 Null state (N0) No call exists. 2.1.2.2 Call initiated (N1) This state exists for an outgoing call when the network has received a call establishment request but has not yet responded. 2.1.2.3 Overlap sending (N2) This state exists for an outgoing call when the network has acknowledged the call establishment request and is prepared to receive additional call information (if any) in overlap mode. 2.1.2.4 Outgoing call proceeding (N3) This state exists for an outgoing call when the network has sent acknowledgement that the network has received all call infor- mation necessary to effect call establishment. 2.1.2.5 Call delivered (N4) This state exists for an outgoing call when the network has indicated that remote user alerting has been initiated. 2.1.2.6 Call present (N6) This state exists for an incoming call when the network has sent a call establishment request but has not yet received a satis- factory response. 2.1.2.7 Call received (N7) This state exists for an incoming call when the network has received an indication that the user is alerting but has not yet received an answer. 2.1.2.8 Connect request (N8) This state exists for an incoming call when the network has received an answer but the network has not yet awarded the call. 2.1.2.9 Incoming call proceeding (N9) This state exists for an incoming call when the network has received acknowledgement that the user has received all call infor- mation necessary to effect call establishment. 2.1.2.10 Active (N10) This state exists for an incoming call when the network has awarded the call to the called user. This state exists for an out- going call when the network has indicated that the remote user has answered the call. 2.1.2.11 Disconnect request (N11) This state exists when the network has received a request from the user to clear the end-to-end connection (if any). 2.1.2.12 Disconnect indication (N12) This state exists when the network has disconnected the end-to-end connection (if any) and has sent an invitation to disconnect the user-network connection. 2.1.2.13 Suspend request (N15) This state exists when the network has received a request to suspend the call but has not yet responded. 2.1.2.14 Resume request (N17) This state exists when the network has received a request to resume a previously suspended call but has not yet responded. 2.1.2.15 Release request (N19) This state exists when the network has requested the user to release and is waiting for a response. 2.1.2.16 Call abort (N22) This state exists for an incoming call for the point-to-multipoint configuration when the call is being cleared before any user has been awarded the call. 2.1.2.17 Overlap receiving (N25) This state exists for an incoming call when the network has received acknowledgement of the call establishment request which permits the network to send additional call information (if any) in the overlap mode. 2.2 Packet-mode access connections This paragraph defines the basic packet-mode access connection control states for access to the ISDN virtual circuit bearer ser- vice (case B). The procedures for access connection control are given in S 6. 2.2.1 Access connection states at the user side of the interface The states which may exist on the user side of the user-network interface are defined in this paragraph. 2.2.1.1 Null state (U0) No access connection exists. 2.2.1.2 Call initiated (U1) This state exists for an outgoing access connection, when the user requests access connection establishment from the network. 2.2.1.3 Outgoing call proceeding (U3) This state exists for an outgoing access connection when the user has received acknowledgement that the network has received all access connection information necessary to effect access connection establishment. 2.2.1.4 Call present (U6) This state exists for an incoming access connection when the user has received a access connection establishment request but has not yet responded. 2.2.1.5 Call received (U7) This state exists for an incoming access connection when the user has indicated alerting but has not yet answered. 2.2.1.6 Connect request (U8) This state exists for an incoming access connection when the user has accepted the access connection and is waiting to be awarded the access connection. 2.2.1.7 Incoming call proceeding (U9) This state exists for an incoming access connection when the user has sent acknowledgement that the user has received all access connection information necessary to effect access connection estab- lishment. 2.2.1.8 Active (U10) This state exists for an incoming access connection when the user has received an acknowledgement from the network that the user has been awarded the access connection. This state exists for an outgoing access connection when the user has received an indication that the local network has completed the access connection. 2.2.1.9 Disconnect request (U11) This state exists when the user has requested the local net- work to clear the access connection and is waiting for a response. 2.2.1.10 Disconnect indication (U12) This state exists when the user has received an invitation to disconnect because the network has disconnected the access connec- tion to-end connection (if any). 2.2.1.11 Release request (U19) This state exists when the user has requested the network to release the access connection and is waiting for a response. 2.2.2 Access connection states at the network side of the interface The states which may exist on the network side of the user-network interface are defined in this paragraph. 2.2.2.1 Null state (N0) No access connection exists. 2.2.2.2 Call initiated (N1) This state exists for an outgoing access connection when the network has received an access connection establishment request but has not yet responded. 2.2.2.3 Outgoing call proceeding (N3) This state exists for an outgoing access connection when the network has sent acknowledgement that the network has received all access connection information necessary to effect access connection establishment. 2.2.2.4 Call present (N6) This state exists for an incoming access connection when the network has sent an access connection establishment request but has not yet received a satisfactory response. 2.2.2.5 Call received (N7) This state exists for an incoming access connection when the network has received an indication that the user is alerting but has not yet received an answer. 2.2.2.6 Connect request (N8) This state exists for an incoming access connection when the network has received an answer but the network has not yet awarded the access connection. 2.2.2.7 Incoming call proceeding (N9) This state exists for an incoming access connection when the network has received acknowledgment that the user has received all access connection information necessary to effect access connection establishment. 2.2.2.8 Active (N10) This state exists for an incoming access connection when the network has awarded the access connection to the called user. This state exists for an outgoing access connection when the local net- work has indicated that the access connection has been completed. 2.2.2.9 Disconnect request (N11) This state exists when the network has received a request from the user to clear the access connection. 2.2.2.10 Disconnect indication (N12) This state exists when the network has sent an invitation to disconnect the user-network access connection. 2.2.2.11 Release request (N19) This state exists when the network has requested the user to release the access connection and is waiting for a response. 2.2.2.12 Call abort (N22) This state exists for an incoming access connection for the point-to-multipoint configuration when the access connection is being cleared before any user has been awarded the access connec- tion. 2.3 Temporary signalling connections This paragraph defines the basic call control states for user-to-user signalling not associated with circuit switched calls. The procedures for call control are given in S 7.2. 2.3.1 Call states at the user side of the interface The states which may exist on the user side of the user-network interface are defined in this paragraph. 2.3.1.1 Null state (U0) No call exists. 2.3.1.2 Call initiated (U1) This state exists for an outgoing call, when the user requests call establishment from the network. 2.3.1.3 Overlap sending (U2) This state exists for an outgoing call when the user has received acknowledgement of the call establishment request which permits the user to send additional call information to the network in overlap mode. 2.3.1.4 Outgoing call proceeding (U3) This state exists for an outgoing call when the user has received acknowledgement that the network has received all call information necessary to effect call establishment. 2.3.1.5 Call delivered (U4) This state exists for an outgoing call, when the calling user has received an indication that remote user alerting has been ini- tiated. 2.3.1.6 Call present (U6) This state exists for an incoming call when the user has received a call establishment request but has not yet responded. 2.3.1.7 Call received (U7) This state exists for an incoming call when the user has indi- cated alerting but has not yet answered. 2.3.1.8 Connect request (U8) This state exists for incoming call when the user has answered the call and is awaiting to be awarded the call. 2.3.1.9 Incoming call proceeding (U9) This state exists for an incoming call when the user has sent acknowledgement that the user has received all call information necessary to effect call establishment. 2.3.1.10 Active (U10) This state exists for an incoming call when the user has received an acknowledgement from the network that the user has been awarded the call. This state exists for an outgoing call when the user has received an indication that the remote user has answered the call. 2.3.1.11 Release request (U19) This state exists when the user has requested the network to release and is waiting for a response. 2.3.1.12 Overlap receiving (U25) This state exists for an incoming call when the user has ack- nowledged the call establishment request from the network and is prepared to receive additional call information (if any) in overlap mode. 2.3.2 Network call states The call states that may exist on the network side of the user-network interface are defined in this paragraph. 2.3.2.1 Null state (N0) No call exists. 2.3.2.2 Call initiated (N1) This state exists for an outgoing call when the network has received a call establishment request but has not yet responded. 2.3.2.3 Overlap sending (N2) This state exists for an outgoing call when the network has acknowledged the call establishment request and is prepared to receive additional call information (if any) in overlap mode. 2.3.2.4 Outgoing call proceeding (N3) This state exists for an outgoing call when the network has sent acknowledgement that the network has received all call infor- mation necessary to effect call establishment. 2.3.2.5 Call delivered (N4) This state exists for an outgoing call when the network has indicated that remote user alerting has been initiated. 2.3.2.6 Call present (N6) This state exists for an incoming call when the network has sent a call establishment request but has not yet received a satis- factory response. 2.3.2.7 Call received (N7) This state exists for an incoming call when the network has received an indication that the user is alerting but has not yet received an answer. 2.3.2.8 Connect request (N8) This state exists for an incoming call when the network has received an answer but the network has not yet awarded the call. 2.3.2.9 Incoming call proceeding (N9) This state exists for an incoming call when the network has received acknowledgement that the user has received all call infor- mation necessary to effect call establishment. 2.3.2.10 Active (N10) This state exists for an incoming call when the network has awarded the call to the called user. This state exists for an out- going call when the network has indicated that the remote user has answered the call. 2.3.2.11 Release request (N19) This state exists when the network has requested the user to release and is waiting for a response. 2.3.2.12 Call abort (N22) This state exists for an incoming call for the point-to-multipoint configuration when the call is being cleared before any user has been awarded the call. 2.3.2.13 Overlap receiving (N25) This state exists for an incoming call when the network has received acknowledgement of the call establishment request which permits the network to send additional call information (if any) in the overlap mode. 2.4 States associated with the global call reference This paragraph defines the states that the protocol may adopt using the global call reference. The procedures for use of the glo- bal call reference for RESTART are contained in S 5.5. There is only one global call reference per interface. 2.4.1 Call states at the user side of the interface The states which may exist on the user side of the user net- work interface are defined in this paragraph. 2.4.1.1 Null (Rest 0) No transaction exists. 2.4.1.2 Restart request (Rest 1) This state exists for a restart transaction when the user has sent a restart request but has not yet received an acknowledgement response from the network. 2.4.1.3 Restart (Rest 2) This state exists when a request for a restart has been received from the network and responses have not yet been received from all locally active call references. 2.4.2 Call states at the network side of the interface The states which may exist on the network side of the user-network interface are defined in this paragraph. 2.4.2.1 Null (Rest 0) No transaction exists. 2.4.2.2 Restart request (Rest 1) This state exists for a restart transaction when the network has sent a restart request but has not yet received an acknowledge- ment response from the user. 2.4.2.3 Restart (Rest 2) This state exists when a request for a restart has been received from the user and a response has not yet been received from all locally active call references. 3 Message functional definitions and content This paragraph provides an overview of the Q.931 message structure, which highlights the functional definition and informa- tion content (i.e. semantics) of each message. Each definition includes: a) A brief description of the message direction and use, including whether the message has: 1) Local significance, i.e. relevant only in the originating or terminating access; 2) Access significance, i.e. relevant in the ori- ginating and terminating access, but not in the network; 3) Dual significance, i.e. relevant in either the originating or terminating access and in the network; or 4) Global significance, i.e. relevant in the ori- ginating and terminating access and in the network. b) A table listing the codeset 0 information ele- ments in the order of their appearance in the message (same rela- tive order for all message types). For each information element the table indicates: 1) the section of this Recommendation describing the information element; 2) the direction in which it may be sent; i.e., user to network (`u n'), network to user (`n u'), or both; Note - The user-network terminology in S 3 refers to the TE-TE, TE-NT2, and NT2-ET interface structures. Annex D contains a description of the information element usage for symmetric NT2-NT2 interfaces. 3) whether inclusion is mandatory (`M') or optional (`O'), with a reference to notes explaining the cir- cumstances under which the information element shall be included; 4) the length of the information element (or per- missible range of lengths), in octets, where `*' denotes an unde- fined maximum length, which may be network or service dependant. Note - All messages may contain information elements from codesets 5, 6 and 7 and corresponding locking and non-locking shift information elements which comply with the coding rules specified in SS 4.5.2-4.5.4. None of these information elements, however, are listed in any of the tables in S 3. c) Further explanatory notes, as necessary. 3.1 Messages for circuit mode connection control Table 3-1/Q.931 summarizes the messages for circuit-mode con- nection control. H.T. [T1.931] TABLE 3-1/Q.931 Messages for circuit-mode connection control lw(126p) | lw(42p) . Table 3-1/Q.931 [T1.931], p. 3.1.1 Alerting This message is sent by the called user to the network and by the network to the calling user to indicate that called user alert- ing has been initiated. See Table 3-2/Q.931. H.T. [T2.931] TABLE 3-2/Q.931 ALERTING message content Message type: ALERTING Significance: global Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-2/Q.931 [T2.931], p. 3.1.2 Call proceeding This message is sent by the called user to the network or by the network to the calling user to indicate that the requested call establishment has been initiated and no more call establishment information will be accepted. See Table 3-3/Q.931. H.T. [T3.931] TABLE 3-3/Q.931 CALL PROCEEDING message content Message type: CALL PROCEEDING Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-3/Q.931 [T3.931], p. Blanc 3.1.3 Congestion control This message is sent by the user or the network to indicate the establishment or termination of flow control on the transmis- sion of USER INFORMATION messages. See Table 3-4/Q.931. H.T. [T4.931] TABLE 3-4/Q.931 CONGESTION CONTROL message content Message type: CONGESTION CONTROL Significance: local (Note 1) Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-4/Q.931 [T4.931], p. Blanc 3.1.4 Connect This message is sent by the called user to the network and by the network to the calling user to indicate call acceptance by the called user. See Table 3-5/Q.931. H.T. [T5.931] TABLE 3-5/Q.931 CONNECT message content Message type: CONNECT Significance: global Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-5/Q.931 [T5.931], p. 3.1.5 Connect acknowledge This message is sent by the network to the called user to indicate the user has been awarded the call. It may also be sent by the calling user to the network to allow symmetrical call control procedures. See Table 3-6/Q.931. H.T. [T6.931] TABLE 3-6/Q.931 CONNECT ACKNOWLEDGE message content Message type: CONNECT ACKNOWLEDGE Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-6/Q.931 [T6.931], p. Blanc 3.1.6 Disconnect This message is sent by the user to request the network to clear an end-to-end connection or is sent by the network to indi- cate that the end-to-end connection is cleared. See Table 3-7/Q.931. H.T. [T7.931] TABLE 3-7/Q.931 DISCONNECT message content Message type: DISCONNECT Significance: global Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-7/Q.931 [T7.931], p. Blanc 3.1.7 Facility This message is defined in Recommendation Q.932 [4]. 3.1.8 Information This message is sent by the user or the network to provide additional information. It may be used to provide information for call establishment (e.g. overlap sending and receiving) or miscel- laneous call-related information. See Table 3-8/Q.931. H.T. [T8.931] TABLE 3-8/Q.931 INFORMATION message content Message type: INFORMATION Significance: local (Note 1) Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-8/Q.931 [T8.931], p. 3.1.9 Notify This message is sent by the user or the network to indicate information pertaining to a call, such as user suspended. See Table 3-9/Q.931. H.T. [T9.931] TABLE 3-9/Q.931 NOTIFY message content Message type: NOTIFY Significance: access Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-9/Q.931 [T9.931], p. Blanc 3.1.10 Progress This message is sent by the user or the network to indicate the progress of a call in the event of interworking or in relation with the provision of in-band information/patterns. See Table 3-10/Q.931. H.T. [T10.931] TABLE 3-10/Q.931 PROGRESS message content Message type: PROGRESS Significance: global Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-10/Q.931 [T10.931], p. Blanc 3.1.11 Release This message is sent by the user or the network to indicate that the equipment sending the message has disconnected the channel (if any) and intends to release the channel and the call reference, and that the receiving equipment should release the channel and prepare to release the call reference after sending RELEASE COM- PLETE. See Table 3-11/Q.931. H.T. [T11.931] TABLE 3-11/Q.931 RELEASE message content Message type: RELEASE Significance: local (Note 1) Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-11/Q.931 [T11.931], p. Blanc 3.1.12 Release complete This message is sent by the user or the network to indicate that the equipment sending the message has released the channel (if any) and call reference, the channel is available for reuse, and the receiving equipment shall release the call reference. See Table 3-12/Q.931. H.T. [T12.931] TABLE 3-12/Q.931 RELEASE COMPLETE message content Message type: RELEASE COMPLETE Significance: local (Note 1) Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-12/Q.931 [T12.931], p. Blanc 3.1.13 Resume This message is sent by the user to request the network to resume a suspended call. See Table 3-13/Q.931. H.T. [T13.931] TABLE 3-13/Q.931 RESUME message content Message type: RESUME Significance: local Direction: user to network ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-13/Q.931 [T13.931], p. 3.1.14 Resume acknowledge This message is sent by the network to the user to indicate completion of a request to resume a suspended call. See Table 3-14/Q.931. H.T. [T14.931] TABLE 3-14/Q.931 RESUME ACKNOWLEDGE message content Message type: RESUME ACKNOWLEDGE Significance: local Direction: network to user ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-14/Q.931 [T14.931], p. 3.1.15 Resume reject This message is sent by the network to the user to indicate failure of a request to resume a suspended call. See Table 3-15/Q.931. H.T. [T15.931] TABLE 3-15/Q.931 RESUME REJECT message content Message type: RESUME REJECT Significance: local Direction: network to user ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-15/Q.931 [T15.931], p. Blanc 3.1.16 Setup This message is sent by the calling user to the network and by the network to the called user to initiate call establishment. See Table 3-16/Q.931. H.T. [1T16.931] TABLE 3-16/Q.931 SETUP message content Message type: SETUP Significance: global Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-16/Q.931 [1T16.931], p. H.T. [2T16.931] Note 1 - Included if the user or the network optionally indicates that all information necessary for call establishment is included in the SETUP message. Note 2 - The Repeat indicator information element is included immediately before the first Bearer capability information element when either the in-call modification procedure or the bearer capa- bility negotiation procedure is used (see Annex O). Note 3 - May be repeated if the bearer capability negotiation pro- cedure is used. For bearer capability negotiation, either two or three Bearer capability information elements may be included in descending order of priority, i.e., highest priority first. Note 4 - Mandatory in the network-to-user direction. Included in the user-to-network direction when the user wants to indicate a channel. If not included, its absence is interpreted as "any chan- nel acceptable". Note 5 - May be included for functional operation of supplementary services (see S 7). Note 6 - Included in the event of interworking or in connection with the provision of in-band information/patterns. Note 7 - Included by the calling user or the network to indicate network-specific facilities information (see Annex E). Note 8 - Included if the network provides information that can be presented to the user. Note 9 - The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. Note 10 - Either the Called party number or the Keypad facility information element is included by the user to convey called party number information to the network. The Keypad facility information element may also be included by the user to convey other call establishment information to the network. - Included if the network optionally provides additional informa- tion describing tones (see S 8). Note 12 - As a network option, may be used for stimulus operation of supplementary services (see SS 7 and 8). Note 13 - May be included by the calling user or the network to identify the calling user. Note 14 - Included in the user-to-network direction when the cal- ling user wants to indicate the calling party subaddress. Included in the network-to-user direction if the calling user included a Calling party subaddress information element in the SETUP message. Note 15 - Either the Called party number or the Keypad facility information element is included by the user to convey called party number information to the network. The Called party number infor- mation element is included by the network when called party number information is conveyed to the user. Note 16 - Included in the user-to-network direction when the cal- ling user wants to indicate the called party subaddress. Included in the network-to-user direction if the calling user included a Called party subaddress information element in the SETUP message. Note 17 - Included by the calling user to select a particular transit network (see Annex C). Note 18 - Included in the user-to-network direction when the cal- ling user wants to pass low layer compatibility information to the called user. Included in the network-to-user direction if the cal- ling user included a Low layer compatibility information element in the SETUP message. Note 19 - Included in the user-to-network direction when the cal- ling user wants to pass High layer compatibility information to the called user. Included in the network-to-user direction if the cal- ling user included a High layer compatibility information element in the SETUP message. Note 20 - Included in the user-to-network direction when the cal- ling user wants to pass user information to the called user. Included in the network-to-user direction if the calling user included a user-user information element in the SETUP message. Con- ditions for this transfer are described in S 7. Note 21 - The minimum length is 2 octets; the standard default maximum length is 131 octets. H.T. [T17.931] TABLE 3-17/Q.931 SETUP ACKNOWLEDGE message content Message type: SETUP ACKNOWLEDGE Significance: local Direction: both Notes to Table 3-16/Q.931 [2T16.931], p. Blanc 3.1.17 Setup acknowledge This message is sent by the network to the calling user or by the called user to the network to indicate that call establishment has been initiated, but additional information may be required. See Table 3-17/Q.931. H.T. [T17.931] TABLE 3-17/Q.931 SETUP ACKNOWLEDGE message content Message type: SETUP ACKNOWLEDGE Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-17/Q.931 [T17.931], p. Blanc 3.1.18 Status This message is sent by the user or the network in response to a STATUS ENQUIRY message or at any time during a call to report certain error conditions listed in S 5.8. See Table 3-18/Q.931. H.T. [T18.931] TABLE 3-18/Q.931 STATUS message content Message type: STATUS Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-18/Q.931 [T18.931], p. Blanc 3.1.19 Status enquiry This message is sent by the user or the network at any time to solicit a STATUS message from the peer layer 3 entity. Sending a STATUS message in response to a STATUS ENQUIRY message is manda- tory. See Table 3-19/Q.931. H.T. [T19.931] TABLE 3-19/Q.931 STATUS ENQUIRY message content Message type: STATUS ENQUIRY Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-19/Q.931 [T19.931], p. 3.1.20 Suspend This message is sent by the user to request the network to suspend a call. See Table 3-20/Q.931. H.T. [T20.931] TABLE 3-20/Q.931 SUSPEND message content Message type: SUSPEND Significance: local Direction: user to network ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-20/Q.931 [T20.931], p. 3.1.21 Suspend acknowledge This message is sent by the network to the user to indicate completion of a request to suspend a call. See Table 3-21/Q.931. H.T. [T21.931] TABLE 3-21/Q.931 SUSPEND ACKNOWLEDGE message content Message type: SUSPEND ACKNOWLEDGE Significance: local Direction: network to user ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-21/Q.931 [T21.931], p. 3.1.22 Suspend reject This message is sent by the network to the user to indicate failure of a request to suspend a call. See Table 3-22/Q.931. H.T. [T22.931] TABLE 3-22/Q.931 SUSPEND REJECT message content Message type: SUSPEND REJECT Significance: local Direction: network to user ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-22/Q.931 [T22.931], p. 3.1.23 User information This message is sent by the user to the network to transfer information to the remote user. This message is also sent by the network to the user to deliver information from the other user. This message is used if the user-to-user transfer is part of an allowed information transfer as defined in SS 7.1.4 or 7.1.5. See Table 3-23/Q.931. H.T. [T23.931] TABLE 3-23/Q.931 USER INFORMATION message content Message type: USER INFORMATION Significance: access Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-23/Q.931 [T23.931], p. Blanc 3.2 Messages for packet-mode access connection control Table 3-24/Q.931 summarizes the messages for packet-mode access connection control. The message tables in this paragraph should be used for Case B (packet switched access to an ISDN vir- tual circuit service) as defined in S 6. For Case A (circuit switched access to PSPDN services) the message tables in S 3.1 should be used. H.T. [T24.931] TABLE 3-24/Q.931 Messages for packet-mode access connection control lw(126p) | lw(42p) . Table 3-24/Q.931 [T24.931], p. Blanc 3.2.1 Alerting This message is sent by the called user to the network to indicate that called user alerting has been initiated. See Table 3-25/Q.931. H.T. [T25.931] TABLE 3-25/Q.931 ALERTING message content Message type: ALERTING Significance: local Direction: user to network ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-25/Q.931 [T25.931], p. Blanc 3.2.2 Call proceeding This message is sent by the called user to the network or by the network to the calling user to indicate that the requested access connection establishment has been initiated. See Table 3-26/Q.931. H.T. [T26.931] TABLE 3-26/Q.931 CALL PROCEEDING message content Message type: CALL PROCEEDING Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-26/Q.931 [T26.931], p. Blanc 3.2.3 Connect This message is sent by the called user to the network and by the network to the calling user to indicate acceptance of the access connection. See Table 3-27/Q.931. H.T. [T27.931] TABLE 3-27/Q.931 CONNECT message content Message type: CONNECT Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-27/Q.931 [T27.931], p. Blanc 3.2.4 Connect acknowledge This message is sent by the network to the called user to indicate the user has been awarded the access connection. It may also be sent by the calling user to the network to allow symmetri- cal access connection control procedures. See Table 3-28/Q.931. H.T. [T28.931] TABLE 3-28/Q.931 CONNECT ACKNOWLEDGE message content Message type: CONNECT ACKNOWLEDGE Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-28/Q.931 [T28.931], p. Blanc 3.2.5 Disconnect This message is sent by the user to request the network to clear an access connection or is sent by the network to the user to indicate that the access connection has been cleared. See Table 3-29/Q.931. H.T. [T29.931] TABLE 3-29/Q.931 DISCONNECT message content Message type: DISCONNECT Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-29/Q.931 [T29.931], p. Blanc 3.2.6 Progress This message is sent by the called user to indicate the pro- gress of an access connection establishment in the event of inter- working within a private network. See Table 3-30/Q.931. H.T. [T30.931] TABLE 3-30/Q.931 PROGRESS message content Message type: PROGRESS Significance: local Direction: user to network ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-30/Q.931 [T30.931], p. Blanc 3.2.7 Release This message is sent by the user or the network to indicate that the equipment sending the message has disconnected the channel (if any) and intends to release the channel and the call reference, and that the receiving equipment should release the channel and prepare to release the call reference after sending RELEASE COM- PLETE. This message is sent by the network to the user to indicate that the access connection is awarded on either the D-channel or an existing channel and that the network intends to release the call reference. See Table 3-31/Q.931. H.T. [T31.931] TABLE 3-31/Q.931 RELEASE message content Message type: RELEASE Significance: local (Note 1) Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-31/Q.931 [T31.931], p. Blanc 3.2.8 Release complete This message is sent by the user or the network to indicate that the equipment sending the message has released the channel (if any) and call reference, the channel is available for reuse, and the receiving equipment shall release the call reference. See Table 3-32/Q.931. H.T. [T32.931] TABLE 3-32/Q.931 RELEASE COMPLETE message content Message type: RELEASE COMPLETE Significance: local (Note 1) Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-32/Q.931 [T32.931], p. Blanc 3.2.9 Setup This message is sent by the calling user to the network and by the network to the called user to initiate access connection estab- lishment. See Table 3-33/Q.931. H.T. [1T33.931] TABLE 3-33/Q.931 SETUP message content Message type: SETUP Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-33/Q.931 [1T33.931], p. H.T. [2T33.931] Note 1 - May be used to describe a CCITT telecommunication service involving packet-mode access connections, if appropriate. Note 2 - Mandatory in the network-to-user direction. Included in the user-to-network direction when the user wants to indicate a channel. If not included, its absence is interpreted as "any chan- nel acceptable". Note 3 - Included in the event of interworking within a private network. Note 4 - Included if the network provides information that can be presented to the user. Note 5 - The minimum length is 2 octets; the maximum length is network dependent and is either 34 or 82 octets. Note 6 - Included in the network-to-user direction if the network implements X.25 | 5]/Q.931 information element mapping and provides indication to the called user of the information rate for the call. Note 7 - Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the maximum permissible transit delay for the call. Note 8 - Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the end-end transit delay for the call. Note 9 - Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the packet layer binary parameters for the call. Note 10 - Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the packet layer window size for the call. Note 11 - Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the packet size for the call. Note 12 - Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the calling party number. Note 13 - Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the calling party subaddress. Note 14 - Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the called party number. Note 15 - Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the called party subaddress. Note 16 - Included in the network-to-user direction if the network implements X.25/Q.931 information element mapping and provides indication to the called user of the number from which a call diversion or transfer was invoked. Note 17 - Included in the network-to-user direction if the calling user included user information and the network implements X.25/Q.931 information element mapping. Note 18 - The minimum length is 2 octets; the standard default maximum length is 131 octets. H.T. [T34.931] TABLE 3-34/Q.931 STATUS message content Message type: STATUS Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Notes to Table 3-33/Q.931 [2T33.931], p. Blanc 3.2.10 Status This message is sent by the user or the network in response to a STATUS ENQUIRY message or at any time to report certain error conditions listed in S 5.8. See Table 3-34/Q.931. H.T. [T34.931] TABLE 3-34/Q.931 STATUS message content Message type: STATUS Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-34/Q.931 [T34.931], p. Blanc 3.2.11 Status enquiry This message is sent by the user or the network at any time to solicit a STATUS message from the peer layer 3 entity. Sending a STATUS message in response to a STATUS ENQUIRY message is manda- tory. See Table 3-35/Q.931. H.T. [T35.931] TABLE 3-35/Q.931 STATUS ENQUIRY message content Message type: STATUS ENQUIRY Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-35/Q.931 [T35.931], p. Blanc 3.3 Messages for user-to-user signalling not associated with circuit switched calls Table 3-36/Q.931 summarizes the messages for the control of non-call associated temporary signalling connections and the transfer of user-user information. H.T. [T36.931] TABLE 3-36/Q.931 Messages for temporary signalling connection control lw(126p) | lw(42p) . Table 3-36/Q.931 [T36.931], p. Blanc 3.3.1 Alerting This message is sent by the called user to the network and by the network to the calling user to indicate that called user alerting has been initiated. See Table 3-37/Q.931. H.T. [T37.931] TABLE 3-37/Q.931 ALERTING message content Message type: ALERTING Significance: global Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-37/Q.931 [T37.931], p. Blanc 3.3.2 Call proceeding This message is sent by the called user to the network and by the network to the calling user to indicate that the requested establishment has been initiated and no more call establishment information will be accepted. See Table 3-38/Q.931. H.T. [T38.931] TABLE 3-38/Q.931 CALL PROCEEDING message content Message type: CALL PROCEEDING Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-38/Q.931 [T38.931], p. Blanc 3.3.3 Congestion control This message is sent by the user or the network to indicate the establishment or termination of flow control on the transmission of USER INFORMATION messages. See Table 3-39/Q.931. H.T. [T39.931] TABLE 3-39/Q.931 CONGESTION CONTROL message content Message type: CONGESTION CONTROL Significance: local (Note 1) Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-39/Q.931 [T39.931], p. Blanc 3.3.4 Connect This message is sent by the called user to the network and by the network to the calling user to indicate call acceptance by the called user. See Table 3-40/Q.931. H.T. [T40.931] TABLE 3-40/Q.931 CONNECT message content Message type: CONNECT Significance: global Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-40/Q.931 [T40.931], p. Blanc 3.3.5 Connect acknowledge This message is sent by the network to the called user to indicate the user has been awarded the call. It may also be sent by the calling user to the network to allow symmetrical call control procedures. See Table 3-41/Q.931. H.T. [T41.931] TABLE 3-41/Q.931 CONNECT ACKNOWLEDGE message content Message type: CONNECT ACKNOWLEDGE Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-41/Q.931 [T41.931], p. Blanc 3.3.6 Information This message is sent by the user or the network to provide additional information. It may be used to provide information for call establishment (e.g. overlap sending and receiving) or miscel- laneous call-related information. See Table 3-42/Q.931. H.T. [T42.931] TABLE 3-42/Q.931 INFORMATION message content Message type: INFORMATION Significance: local (Note 1) Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-42/Q.931 [T42.931], p. Blanc 3.3.7 Release This message is sent by the user or the network to indicate that the equipment sending the message has disconnected the channel (if any) and intends to release the channel and the call reference, and that the receiving equipment should release the channel and prepare to release the call reference after sending RELEASE COM- PLETE. See Table 3-43/Q.931. H.T. [T43.931] TABLE 3-43/Q.931 RELEASE message content Message type: RELEASE Significance: local (Note 1) Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-43/Q.931 [T43.931], p. Blanc 3.3.8 Release complete This message is sent by the user or the network to indicate that the equipment sending the message has released the channel (if any) and call reference, the channel is available for reuse, and the receiving equipment shall release the call reference. See Table 3-44/Q.931. H.T. [T44.931] TABLE 3-44/Q.931 RELEASE COMPLETE message content Message type: RELEASE COMPLETE Significance: local (Note 1) Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-44/Q.931 [T44.931], p. Blanc 3.3.9 Setup This message is sent by the calling user to the network and by the network to the called user to initiate call establishment. See Table 3-45/Q.931. H.T. [1T45.931] TABLE 3-45/Q.931 SETUP message content Message type: SETUP Significance: global Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-45/Q.931 [1T45.931], p. Blanc H.T. [2T45.931] Note 1 - Included if the user or the network optionally indicates that all information necessary for call establishment is included in the SETUP message. Note 2 - The Bearer capability and compatibility information ele- ments may be used to describe a CCITT telecommunication service, if appropriate. Note 3 - Included by the calling user or the network to indicate network specific facilities information (see Annex E). Note 4 - Included if the network provides information that can be presented to the user. - The minimum length is 2 octets; Note 5 the maximum length is network dependent and is either 34 or 82 octets. Note 6 - Either the Called party number or the Keypad facility information element is included by the user to convey called party number information to the network during overlap sending. The Keypad facility information element may also be included by the user to convey other call establishment information to the network. Note 7 - May be included by the calling user or the network to identify the calling user. Note 8 - Included in the user-to-network direction when the cal- ling user wants to indicate the calling party subaddress. Included in the network-to-user direction if the calling user included a Calling party subaddress information element in the SETUP message. Note 9 - Either the Called party number or the Keypad facility information element is included by the user to convey called party number information to the network. The Called party number infor- mation element is included by the network when called party number information is conveyed to the user. Note 10 - Included in the user-to-network direction when the cal- ling user wants to indicate the called party subaddress. Included in the network-to-user direction if the calling user included a Called party subaddress information element in the SETUP message. Note 11 - Included by the calling user to select a particular transit network (see Annex C). Note 12 - Included in the user-to-network direction when the cal- ling user wants to pass low layer compatibility information to the called user. Included in the network-to-user direction if the cal- ling user included a low layer compatibility information element in the SETUP message. Note 13 - Included in the user-to-network direction when the cal- ling user wants to pass high layer compatibility information to the called user. Included in the network-to-user direction if the cal- ling user included a high layer compatibility information element in the SETUP message. Note 14 - Included in the user-to-network direction when the cal- ling user wants to pass user information to the called user. Included in the network-to-user direction if the calling user included a user-user information element in the SETUP message. Con- ditions for this transfer are described in S 7. Note 15 - The minimum length is 2 octets; the standard default maximum length is 131 octets. H.T. [T46.931] TABLE 3-46/Q.931 SETUP ACKNOWLEDGE message content Message type: SETUP ACKNOWLEDGE Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Notes to Table 3-45/Q.931 [2T45.931], p. Blanc 3.3.10 Setup acknowledge This message is sent by the network to the calling user or by the called user to the network to indicate that call establishment has been initiated, but additional information may be required. See Table 3-46/Q.931. H.T. [T46.931] TABLE 3-46/Q.931 SETUP ACKNOWLEDGE message content Message type: SETUP ACKNOWLEDGE Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-46/Q.931 [T46.931], p. Blanc 3.3.11 Status This message is sent by the user or the network in response to a STATUS ENQUIRY message or at any time to report error conditions listed in S 5.8. See Table 3-47/Q.931. H.T. [T47.931] TABLE 3-47/Q.931 STATUS message content Message type: STATUS Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-47/Q.931 [T47.931], p. Blanc 3.3.12 Status enquiry This message is sent by the user or the network at any time to solicit a STATUS message from the peer layer 3 entity. Sending a STATUS message in response to a STATUS ENQUIRY message is mandatory. See Table 3-48/Q.931. H.T. [T48.931] TABLE 3-48/Q.931 STATUS ENQUIRY message content Message type: STATUS ENQUIRY Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-48/Q.931 [T48.931], p. 3.3.13 User information This message is sent by the user to the network to transfer information to the remote user. This message is also sent by the network to the user to deliver information from the other user. See Table 3-49/Q.931. H.T. [T49.931] TABLE 3-49/Q.931 USER INFORMATION message content Message type: USER INFORMATION Significance: access Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-49/Q.931 [T49.931], p. 3.4 Messages used with the global call reference Table 3-50/Q.931 summarizes the messages which may use the global call reference defined in S 4.3. H.T. [T50.931] TABLE 3-50/Q.931 Messages used with the global call reference lw(126p) | lw(42p) . Table 3-50/Q.931 [T50.931], p. 3.4.1 Restart This message is sent by the user or the network to request the recipient to restart (i.e., return to idle condition) the indicated channel(s) or interface. See Table 3-51/Q.931. H.T. [T51.931] TABLE 3-51/Q.931 RESTART message content Message type: RESTART Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-51/Q.931 [T51.931], p. 3.4.2 Restart acknowledge This message is sent to acknowledge the receipt of a RESTART message and to indicate that the requested restart is complete. See Table 3-52/Q.931. H.T. [T52.931] TABLE 3-52/Q.931 RESTART ACKNOWLEDGE message content Message type: RESTART ACKNOWLEDGE Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-52/Q.931 [T52.931], p. Blanc 3.4.3 Status This message is sent by the user or the network at any time during a call to report certain error conditions listed in S 5.8. See Table 3-53/Q.931. H.T. [T53.931] TABLE 3-53/Q.931 STATUS message content Message type: STATUS Significance: local Direction: both ______________________________________________ ______________________________________________ | | | | | | | | | | | | Table 3-53/Q.931 [T53.931], p. Blanc