5i' SECTION 3 DATA USER PART (DUP) Recommendation Q.741 SIGNALLING SYSTEM No. 7 - DATA USER PART (This Recommendation appears in Fascicle VIII.3 of the Blue Book, as Recommendation X.61.) Blanc MONTAGE: PAGE 2 = PAGE BLANCHE SECTION 5 INTEGRATED SERVICES DIGITAL NETWORK USER PART (ISUP) Recommendation Q.761 FUNCTIONAL DESCRIPTION OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7 1 General The ISDN User Part is the Signalling System No. 7 protocol which provides the signalling functions required to support basic bearer services and supplementary services for voice and non-voice applications in an integrated services digital network. The ISDN User Part is also suited for application in dedicated telephone and circuit switched data networks and in analogue and mixed analogue/digital networks. In particular the ISDN User Part meets the requirements defined by CCITT for worldwide international semi-automatic and automatic telephone and circuit switched data traffic. The ISDN User Part is furthermore suitable for national appli- cations. Most signalling procedures, information elements and mes- sage types specified for international use are also required in typical national applications. Moreover, coding space has been reserved in order to allow national administrations and recognized private operating agencies to introduce network specific signalling messages and elements of information within the internationally standardized protocol structure. The ISDN User Part makes use of the services provided by the Message Transfer Part (MTP) and in some cases by the Signalling Connection Control Part (SCCP) for the transfer of information between ISDN User Parts. The ISDN User Part protocol which supports the basic bearer service is described in Recommendations Q.761 to Q.764 and Q.766. A general description of ISDN User Part signals and messages is pro- vided in Recommendation Q.762. Message formats and message field codings are defined in Recommendation Q.763, while the signalling procedures are described in Recommendation Q.764. Recommendation Q.766 deals with ISDN User Part performance objec- tives. ISDN User Part protocol elements which support supplementary services are described in Recommendation Q.730. Note - The message set, message formats and procedures speci- fied in this version of the ISDN User Part protocol are not in com- plete alignment with those of the 1984 version (Red Book). The two versions of the protocol are therefore not compatible in all aspects. 2 Services supported by the ISDN User Part The ISDN User Part protocol supports the basic bearer service, i.e. the establishment, supervision and release of 64 kbit/s cir- cuit switched network connections between subscriber line exchange terminations. In addition to the basic bearer service the ISDN User Part also supports the following supplementary services: - calling line identification, - call forwarding, - closed user groups, - directing dialling in, and - user-to-user signalling. 3 Services assumed from the Message Transfer Part (MTP) 3.1 General This section describes the functional interface presented by the Message Transfer Part to the ISDN User Part. In accordance with the description techniques defined by the Open System Interconnec- tion (OSI) model, information is transferred to and from the MTP in the form of Parameters carried by Primitives. The general syntax of a primitive is as follows: H.T. [T1.761] ________________________________________________________________________ X Generic name Specific name Parameter ________________________________________________________________________ | | | | | | | | | | | | | | | Tableau du S 3.1 [T1.761], p. where X designates the function providing the service (the MTP, in this case), the Generic name describes an action by X, the Specific name indicates the purpose of the primitive, i.e. whether it conveys a request for service, an indication that service related information has been received, a response to a ser- vice request or a confirmation that the requested service has been performed, and the Parameters contain the elements of supporting informa- tion transferred by the primitive. 3.2 Description of primitives The following paragraphs describe the primitives used across the ISDN User Part-Message Transfer Part functional interface. The primitives together with the parameters carried by each primitive are also shown in Table 1/Q.761. 3.2.1 Transfer The MTP-TRANSFER primitive is used either by the ISDN User Part to access the Signalling Message Handling function of the Mes- sage Transfer Part or by the latter to deliver signalling message information to the ISDN User Part. 3.2.2 Pause The MTP-PAUSE primitive is sent by the Message Transfer Part to indicate its inability to transfer messages to the destination specified as a parameter. 3.2.3 Resume The MTP-RESUME primitive is sent by the Message Transfer Part to indicate its ability to resume unrestricted transfer of messages to the destination specified as a parameter. 3.2.4 Status The MTP-STATUS primitive is sent by the Message Transfer Part to indicate that the signalling route to a specific destination is congested or the ISDN User Part at the destination is unavailable. The affected destination and the congestion indication are carried as parameters (see Table 1/Q.761) in the primitive. H.T. [T2.761] TABLE 1/Q.761 Message transfer part service primitives ______________________________________________________ Primitives Generic name Specific name Parameters ______________________________________________________ MTP-TRANSFER Request indication { OPC DPC SLS SIO Signalling info. } ______________________________________________________ MTP-PAUSE Indication Affected DPC ______________________________________________________ MTP-RESUME Indication Affected DPC ______________________________________________________ MTP-STATUT Indication { Affected DPC Cause (see Note) } ______________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OPC Originating point code DPC Destination point code SLS Signaling link selection code SIO Service information octet Note - The cause parameter can assume two values: - signalling network congested (level), where level is included only if natioal options with congestion priorities and multiple signalling states without congestion priorities (see Recommendation Q.704). - remote user unavailable. Tableau 1/Q.761 [T2.761], p. 4 End-to-end signalling 4.1 General End-to-end signalling is defined as the capability to transfer signalling information of end points significance directly between signalling end points in order to provide a requesting user with a basic or supplementary service. End-to-end signalling is used typically between call originat- ing and terminating local exchanges, to request or to respond to requests for additional call related information, to invoke a sup- plementary service or to transfer user-to-user information tran- sparently through the network. End-to-end signalling procedures are described in Recommendation Q.764, S 3. The following two methods of end-to-end signalling are sup- ported: 4.2 SCCP method of end-to-end signalling Connection-oriented or connectionless transfer of end-to-end signalling information can be accomplished by using the service provided the Signalling Connection Control Part (SCCP) of Signal- ling System No. 7. The relevant procedures are described in Recommendation Q.764, S 3.4. 4.3 Pass-along method of end-to-end signalling The pass-along method of end-to-end signalling provides transfer of signalling information without requiring the services of the SCCP. This method may be used between two exchanges when the information to be transferred relates to an existing call for which a physical connection between the same two exchanges has been esta- blished. The information transfer in this case occurs over the same signalling path as that used to set up the call and establish the physical connection. The relevant procedures are described in Recommendation Q.764, S 3.3. 5 Future enhancements Requirements for additional protocol capabilities, such as the ability to support new supplementary services, will result from time to time in the need to add to or modify existing protocol ele- ments and thus to create a new protocol version. In order to ensure adequate service continuity, the insertion of a new protocol version into one part of a network should be transparent to the remainder of the network. Compatible interwork- ing between protocol versions is optimized by adhering to the fol- lowing guidelines when specifying a new version: 1) Existing protocol elements, i.e. procedures, messages, parameters and codes, should not be changed unless a pro- tocol error needs to be corrected or it becomes necessary to change the operation of the service that is being supported by the proto- col. 2) The semantics of a message, a parameter or of a field within a parameter should not be changed. 3) Established rules for the formatting and encod- ing messages should not be modified. 4) The addition of parameters to the mandatory part of an existing message should not be allowed. If needed, a new mes- sage should be defined containing the desired set of existing and new mandatory parameters. 5) A parameter may be added to an existing message as long as it is allocated to the optional part of the message. 6) The addition of new octets to an existing manda- tory fixed length parameter should be avoided. If needed, a new optional parameter should be defined containing the desired set of existing and new information fields. 7) The sequence of fields in an existing variable length parameter should remain unchanged. New fields may be added at the end of the existing sequence of parameter fields. If a change in the sequence of parameter fields is required, a new parameter should be defined. 8) The all zeros code point should be used exclusively to indicate an unallocated (spare) or insignificant value of a parameter field. This avoids an all zeros code, sent by one protocol version as a spare value, to be interpreted as a sig- nificant value in another version. Recommendation Q.762 GENERAL FUNCTION OF MESSAGES AND SIGNALS This Recommendation describes the elements of signalling information used by the ISDN User Part protocol and their function. The encoding of these elements, the format of the messages in which they are conveyed and their application in the ISDN User Part sig- nalling procedures are described in Recommendations Q.763 and Q.764. Table 1/Q.762 gives the mandatory or optional parameters in the ISDN user part messages and Table 2/Q.762 the list of abbrevia- tions of these messages. 1 Signalling messages 1.1 Address complete message (ACM) A message sent in the backward direction indicating that all the address signals required for routing the call to the called party have been received. 1.2 Answer message (ANM) A message sent in the backward direction indicating that the call has been answered. In semi-automatic working this message has a supervisory function. In automatic working this message is used in conjunction with charging information in order to: - start metering the charge to the calling sub- scriber (see Recommendation Q.28), and - start measurement of call duration for interna- tional accounting purposes (Recommendation E.260). 1.3 Blocking message (BLO) A message sent only for maintenance purposes to the exchange at the other end of a circuit, to cause an engaged condition of that circuit for subsequent calls outgoing from that exchange. When a circuit is used in the bothway mode of operation an exchange receiving the blocking message must be capable of accepting incom- ing calls on the concerned circuit unless it has also sent a block- ing message. Under certain conditions, a blocking message is also a proper response to a reset circuit message. 1.4 Blocking acknowledgement message (BLA) A message sent in response to a blocking message indicating that the circuit has been blocked. 1.5 Call modification completed message (CMC) A message sent in response to a call modification request mes- sage indicating that the requested call modification (e.g. from voice to data) has been completed. 1.6 Call modification reject message (CMRJ) A message sent in response to a call modification request mes- sage indicating that the request has been rejected. 1.7 Call modification request message (CMR) A message sent in either direction indicating a calling or called party request to modify the characteristics of an esta- blished call (e.g. from data to voice). 1.8 Call progress message (CPG) A message sent in the backward direction indicating that an event has occurred during call set-up which should be relayed to the calling party. 1.9 Charge information message (CRG) (national use) Information sent in either direction for accounting and/or call charging purposes. 1.10 Circuit group blocking message (CGB) A message sent to the exchange at the other end of an identi- fied group of circuits to cause an engaged condition of this group of circuits for subsequent calls outgoing from that exchange. An exchange receiving a circuit group blocking message must be able to accept incoming calls on the group of blocked circuits unless it has also sent a blocking message. Under certain conditions, a cir- cuit group blocking message is also a proper response to a reset circuit message. 1.11 Circuit group blocking acknowledgement message (CGBA) A message sent in response to a circuit group blocking message to indicate that the requested group of circuits has been blocked. 1.12 Circuit group reset message (GRS) A message sent to release an identified group of circuits when, due to memory mutilation or other causes, it is unknown whether for example, a release or release complete message is appropriate for each of the circuits in the group. If at the receiving end a circuit is remotely blocked, reception of this mes- sage should cause that condition to be removed. 1.13 Circuit group reset acknowledgement message (GRA) A message sent in response to a circuit group reset message and indicating that the requested group of circuits has been reset. The message also indicates the maintenance blocking state of each circuit. 1.14 Circuit group unblocking message (CGU) A message sent to the exchange at the other end of an identi- fied group of circuits to cause cancellation in that group of cir- cuits of an engaged condition invoked earlier by a blocking or cir- cuit group blocking message. 1.15 Circuit group unblocking acknowledgement message (CGUA) A message sent in response to a circuit group unblocking mes- sage to indicate that the requested group of circuits has been unblocked. 1.16 Circuit group query message (CQM) A message sent on a routine or demand basis to request the far-end exchange to give the state of all circuits in a particular range. 1.17 Circuit group query response message (CQR) A message sent in response to a circuit group query message to indicate the state of all circuits in a particular range. 1.18 Confusion message (CFN) A message sent in response to any message (other than a confu- sion message) if the exchange does not recognize the message or detects a part of the message as being unrecognized. 1.19 Connect message (CON) A message sent in the backward direction indicating that all the address signals required for routing the call to the called party have been received and that the call has been answered. 1.20 Continuity message (COT) A message sent in the forward direction indicating whether or not there is continuity on the preceding circuit(s) as well as of the selected circuit to the following exchange, including verifica- tion of the communication path across the exchange with the speci- fied degree of reliability. 1.21 Continuity check request message (CCR) A message sent by an exchange for a circuit on which a con- tinuity check is to be performed, to the exchange at the other end of the circuit, requesting continuity checking equipment to be attached. 1.22 Delayed release message (DRS) (national use) A message sent in either direction indicating that the called or calling party has disconnected but that the network is holding the connection. 1.23 Facility accepted message (FAA) A message sent in response to a facility request message indi- cating that the requested facility has been invoked. 1.24 Facility reject message (FRJ) A message sent in response to a facility request message to indicate that the facility request has been rejected. 1.25 Facility request message (FAR) A message sent from an exchange to another exchange to request activation of a facility. 1.26 Forward transfer message (FOT) A message sent in the forward direction on semi-automatic calls when the outgoing international exchange operator wants the help of an operator at the incoming international exchange. The message will normally serve to bring an assistance operator (see Recommendation Q.101) into the circuit if the call is automatically set up at the exchange. When the call is completed via an operator (incoming or delay operator) at the incoming international exchange, the message should preferably cause this operator to be recalled. 1.27 Information message (INF) A message sent to convey information in association with a call, which may have been requested in an information request mes- sage. 1.28 Information request message (INR) A message sent by an exchange to request information in asso- ciation with a call. 1.29 Initial address message (IAM) A message sent in the forward direction to initiate seizure of an outgoing circuit and to transmit number and other information relating to the routing and handling of a call. 1.30 Loop back acknowledgement message (LPA) (national use) A message sent in the backward direction in response to a con- tinuity check request message indicating that a loop (or tran- sceiver in the case of a 2-wire circuit) has been connected. 1.31 Overload message (OLM) (national use) A message sent in the backward direction, on non-priority calls in response to an IAM, to invoke temporary trunk blocking of the circuit concerned when the exchange generating the message is subject to load control. 1.32 Pass-along message (PAM) A message that may be sent in either direction to transfer information between two signalling points along the same signalling path as that used to establish a physical connection between those two points. 1.33 Release message (REL) A message sent in either direction to indicate that the cir- cuit is being released due to the reason (cause) supplied and is ready to be put into the idle state on receipt of the release com- plete message. In case the call was forwarded or is to be rerouted, the appropriate indicator is carried in the message together with the redirection address and the redirecting address. 1.34 Release complete message (RLC) A message sent in either direction in response to the receipt of a released message, or if appropriate to a reset circuit mes- sage, when the circuit concerned has been brought into the idle condition. 1.35 Reset circuit message (RSC) A message sent to release a circuit when, due to memory muti- lation or other causes, it is unknown whether for example, a release or a release complete message is appropriate. If, at the receiving end, the circuit is remotely blocked, reception of this message should cause that condition to be removed. 1.36 Resume message (RES) A message sent in either direction indicating that the calling or called party, after having been suspended, is reconnected. 1.37 Subsequent address message (SAM) A message that may be sent in the forward direction following an initial address message, to convey additional called party number information. 1.38 Suspend message (SUS) A message sent in either direction indicating that the calling or called party has been temporarily disconnected. 1.39 Unblocking message (UBL) A message sent to the exchange at the other end of a circuit to cancel, in that exchange, the engaged condition of the circuit caused by a previously sent blocking or circuit group blocking mes- sage. 1.40 Unblocking acknowledgement message (UBA) A message sent in response to an unblocking message indicating that the circuit has been unblocked. 1.41 Unequipped circuit identification code message (UCIC) (national use) A message sent from one exchange to another when it receives an unequipped circuit identification code. 1.42 User-to-user information message (USR) A message to be used for the transport of user-to-user signal- ling independent of call control messages. 2 Signalling information 2.1 Access transport Information generated on the access side of a call and transferred transparently in either direction between originating and teminating local exchanges. The information is significant to both users and local exchanges. 2.2 Address presentation restricted indicator Information sent in either direction to indicate that the address information is not to be presented to a public network user, but can be passed to another public network. It may also be used to indicate that the address cannot be ascertained. 2.3 Address signal An element of information in a network number. The address signal may indicate digit values 0 to 9, code 11 or code 12. One address signal value (ST) is reserved to indicate the end of the called party number. 2.4 Automatic congestion level Information sent to the exchange at the other end of a circuit to indicate that a particular level of congestion exists at the sending exchange. 2.5 Call forwarding may occur indicator Information sent in the backward direction indicating that call forwarding may occur, depending on the response received (or lack thereof) from the called party. 2.6 Call identity Information sent in the call reference parameter indicating the identity of a call in a signalling point. 2.7 Call reference Circuit independent information identifying a particular call. 2.8 Called party number Information to identify the called party. 2.9 Called party's category indicator Information sent in the backward direction indicating the category of the called party, e.g. ordinary subscriber or payphone. 2.10 Called party's status indicator Information sent in the backward direction indicating the status of the called party, e.g. subscriber free. 2.11 Calling party number Information sent in the forward direction to identify the cal- ling party. 2.12 Calling party address request indicator Information sent in the backward direction indicating a request for the calling party address to be returned. 2.13 Calling party address response indicator Information sent in response to a request for the calling party address, indicating whether the requested address is included, not included, not available or incomplete. 2.14 Calling party number incomplete indicator Information sent in the forward direction indicating that the complete calling party number is not included. 2.15 Calling party's category Information sent in the forward direction indicating the category of the calling party and, in case of semi-automatic calls, the service language to be spoken by the incoming, delay and assis- tance operators. 2.16 Calling party's category request indicator Information sent in the backward direction indicating a request for the calling party's category to be returned. 2.17 Calling party's category response indicator Information sent in response to a request for the calling party's category, indicating whether or not the requested informa- tion is included in the response. 2.18 Cause value Information sent in either direction indicating the reason for sending the message (e.g. release message). Definitions for each cause value are listed below. a) Normal class Cause 1 - Unallocated (unassigned) number This cause indi- cates that the called party cannot be reached because, although the called party number is in a valid format, it is not currently allo- cated (assigned). Cause 2 - No route to specified transit network This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network which it does not recognize. The equipment sending this cause does not recognize the transit network either because the transit net- work does not exist or because that particular transit network, while it does exist, does not serve the equipment which is sending this cause. This cause is supported on a network-dependent basis. Cause 3 - No route to destination This cause indicates that the called party cannot be reached because the network through which the call has been routed does not serve the destination desired. This cause is supported on a network-dependent basis. Cause 4 - Send special information tone This cause indi- cates that the called party cannot be reached for reasons that are of long-term nature and that the special information tone should be returned to the calling party. Cause 5 - Misdialled trunk prefix This cause indicates the erroneous inclusion of a trunk prefix in the called party number (for national use only). Cause 16 - Normal call clearing This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared. Under normal situa- tion, the source of this cause is not the network. Cause 17 - User busy This cause is used when the called party has indicated the inability to accept another call. It is noted that the user equipment is compatible with the call. Cause 18 - No user responding This cause is used when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time. Cause 19 - No answer from user (user alerted) This cause is used when the called party has been alerted but does not respond with a connect indication within the prescribed period of time. Cause 21 - Call rejected This cause indicates that the equipment sending this cause does not wish to accept this call, although it could have accepted the call because the equipment sending this cause is neither busy or incompatible. Cause 22 - Number changed This cause is returned to a cal- ling party when the called number indicated by the calling party is no longer assigned. The new called number may optionally be included in the diagnostic field. If a network does not support this capability, cause number 1 shall be used. Cause 27 - Destination out of order This cause indicates that the destination requested by the user cannot be reached because the interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signalling message was unable to be delivered to the remote party; e.g. a physical layer or data link layer failure at the remote party, user equipment off-line, etc. Cause 28 - Address incomplete This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete. This condition may be determined in the incoming international exchange (or in the national destination network): - immediately after reception of an ST signal, or - on time-out after the last received digit. Cause 29 - Facility rejected This cause is returned when a supplementary service requested by the user cannot be provided by the network. Cause 31 - Normal, unspecified This cause is used to report a normal event only when no other cause in the normal class applies. b) Resource Unavailable class Cause 34 - No circuit available This cause indicates that there is no appropriate circuit presently available to handle the call. Cause 38 - Network out of order This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time, e.g. immediately re-attempting the call is not likely to be successful. Cause 41 - Temporary failure This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time, e.g. the use may wish to try another call attempt almost immediately. Cause 42 - Switching equipment congestion This cause indi- cates that the switching equipment generating this cause is experiencing a period of high traffic. Cause 47 - Resource unavailable, unspecified This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class applies. c) Service or Option Not Available class Cause 50 - Requested facility not subscribed This cause indicates that the user has requested a supplementary service which is implemented by the equipment which generated this cause, but the user is not authorized to use. Cause 55 - Incoming calls barred within CUG This cause indicates that although the called party is a member of the CUG for the incoming CUG call, incoming calls are not allowed within this CUG. Cause 57 - Bearer capability not authorized This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but the user is not authorized to use. Cause 58 - Bearer capability not presently available This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but which is not available at this time. Cause 63 - Service or option not available, unspecified This cause is used to report a service or option not available event only when no other cause in the service or option not avail- able class applies. d) Service or Option Not Implemented class Cause 65 - Bearer capability not implemented This cause indicates that the equipment sending this cause does not support the bearer capability requested. Cause 69 - Requested facility not implemented This cause indicates that the equipment sending this cause does not support the requested supplementary service. Cause 70 - Only restricted digital information bearer capa- bility is available This cause indicates that the calling party has requested an unrestricted bearer service but that the equipment sending this cause only supports the restricted version of the requested bearer capability. Cause 79 - Service or option not implemented, unspecified This cause is used to report a service or option not implemented event only when no other cause in the service or option not imple- mented class applies. e) Invalid Message (e.g. Parameter out of Range) class Cause 87 - Called user not member of CUG This cause indi- cates that the called user for the incoming CUG call is not a member of the specified CUG. Cause 88 - Incompatible destination This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility or high layer compatibility or other compatibility attributes (e.g. data rate) which cannot be accommodated. Cause 91 - Invalid transit network selection This cause indicates that a transit network identification was received which is of an incorrect format as defined in Annex C of Recommendation Q.931. Cause 95 - Invalid message, unspecified This cause is used to report an invalid message event only when no other cause in the invalid message class applies. f ) Protocol error (e.g. Unknown Message) class Cause 97 - Message type non-existent or not implemented This cause indicates that the equipment sending this cause has received a message which it does not recognize either because this is a message type not defined or defined but not implemented by the equipment sending this cause. Cause 99 - Parameter non-existent or not implemented - dis- carded This cause indicates that the equipment sending this cause has received a message which includes parameters not recognized because the parameters are not defined or are defined but not implemented by the equipment sending the cause. The cause indicates that the parameter(s) were discarded. Cause 103 - Parameter non-existent or not implemented - passed on This cause indicates that the equipment sending this cause has received a message which includes parameters not recog- nized because the parameters are not defined or are defined but not implemented by the equipment sending the cause. The cause indicates that the parameter(s) were ignored. In addition, if the equipment sending this cause is an intermediate point, then this cause indi- cates that the parameter(s) were passed on unchanged. Cause 111 - Protocol error, unspecified This cause is used to report a protocol error event only when no other cause in the protocol error class applies. g) Interworking class Cause 127 - Interworking, unspecified This cause indicates that there has been interworking with a network which does not pro- vide causes for actions it takes; thus, the precise cause for a message which is being sent cannot be ascertained. 2.19 Charge indicator Information sent in the backward direction indicating whether or not the call is chargeable. 2.20 Charge information request indicator (national use) Information sent in either direction requesting charge infor- mation to be returned. 2.21 Charge information response indicator (national use) Information sent in response to a request for charge informa- tion indicating whether or not the requested information is included. 2.22 Circuit group supervision message type indicator Information sent in a circuit group blocking or unblocking message, indicating whether blocking (unblocking) is maintenance oriented or hardware oriented. 2.23 Circuit identification code Information identifying the physical path between a pair of exchanges. 2.24 Circuit state indicator Information indicating the state of a circuit according to the sending exchange. 2.25 Closed user group call indicator Information indicating whether or not the concerned call can be set up as a closed user group call and, if a closed user group call, whether or not outgoing access is allowed. 2.26 Closed user group interlock code Information uniquely identifying a closed user group within a network. 2.27 Coding standard Information sent in association with a parameter (e.g. cause indicators) identifying the standard in which the parameter format is described. 2.28 Connected number Information sent in the backward direction to identify the connected party. 2.29 Connection request Information sent in the forward direction on behalf of the signalling connection control part requesting the establishment of an end-to-end connection. 2.30 Continuity check indicator Information sent in the forward direction indicating whether or not a continuity check will be performed on the circuit(s) con- cerned or is being (has been) performed on a previous circuit in the connection. 2.31 Continuity indicator Information sent in the forward direction indicating whether or not the continuity check on the outgoing circuit was successful. A continuity check successful indication also implies continuity of the preceding circuits and successful verification of the path across the exchange with the specified degree of reliability. 2.32 Credit Information sent in a connection request, indicating the window size requested by the signalling connection control part for an end-to-end connection. 3.33 Diagnostic Information sent in association which a cause value and which provides supplementary information about the reason for sending the message. 2.34 Echo control device indicator Information indicating whether or not a half echo control dev- ice is included in the connection. 2.35 End-to-end information indicator Information sent in either direction indicating whether or not the sending exchange has further call information available for end-to-end transmission. In the forward direction, an indication that end-to-end information is available will imply that the desti- nation exchange may obtain the information before alerting the called party. 2.36 End-to-end method indicator Information sent in either direction indicating the available methods, if any, for end-to-end transfer of information. 2.37 Event indicator Information sent in the backward direction indicating the type of event which caused a call progress message to be sent to the originating local exchange. 2.38 Event presentation restricted indicator Information sent in the backward direction indicating that the event should not be presented to the calling party. 2.39 Extension indicator Information indicating whether or not the associated octet has been extended. 2.40 Facility indicator Information sent in facility related messages identifying the facility or facilities with which the message is concerned. 2.41 Holding indicator (national use) Information sent in either direction indicating that holding of the connection is requested. 2.42 Hold provided indicator (national use) Information sent in either direction indicating that the con- nection will be held after the calling or called party has attempted to release. 2.43 In-band information indicator Information sent in the backward direction indicating that in-band information or an appropriate pattern is now available. 2.44 Internal network number indicator Information sent to the destination exchange indicating whether or not the call is allowed should the called party number prove to be an internal network number (e.g. mobile access point). 2.45 Interworking indicator Information sent in either direction indicating whether or not Signalling System No. 7 is used in all parts of the network connec- tion. 2.46 ISDN access indicator Information sent in either direction indicating whether or not the access signalling protocol is ISDN. 2.47 ISDN user part indicator Information sent in either direction to indicate that the ISDN user part is used in all preceding parts of the network connection. When sent in the backward direction, the preceding parts are those towards the called party. 2.48 ISDN user preference indicator Information sent in the forward direction indicating whether or not the ISDN user part is required or preferred in all parts of the network connection. 2.49 Local reference Information sent in the connection request, indicating the local reference allocated by the signalling connection control part to an end-to-end connection. 2.50 Location Information sent in either direction indicating where an event (e.g. release) was generated. 2.51 Malicious call identification request indicator (national use) Information sent in the backward direction to request the identity of the calling party for the purpose of malicious call idenification. 2.52 Modification indicator Information sent in the call modification indicators parameter indicating whether the call modification is to service 1 or ser- vice 2. 2.53 National/international call indicator Information sent in the forward direction indicating in the destination national network whether the call has to be treated as an international call or as a national call. 2.54 Nature of address indicator Information sent in association with an address indicating the nature of that address, e.g. ISDN international number, ISDN national significant number, or ISDN subscriber number. 2.55 Numbering plan indicator Information sent in association with a number indicating the numbering plan used for that number (e.g. ISDN number, Telex number). 2.56 Odd/even indicator Information sent in association with an address, indicating whether the number of address signals contained in the address is even or odd. 2.57 Original called number Information sent in the forward direction when a call is redirected and identifies the original called party. 2.58 Original redirection reason Information sent in either direction indicating the reason why the call was originally redirected. 2.59 Point code Information sent in the call reference parameter indicating the code of the signalling point in which the call identity allo- cated to the call reference is relevant. 2.60 Protocol class Information sent in the connection request parameter indicat- ing the protocol class requested by the signalling connection con- trol part for the end-to-end connection. 2.61 Protocol control indicator Information consisting of the end-to-end method indicator, the interworking indicator, the end-to-end information indicator, the SCCP method indicator and the ISDN user part indicator. The protocol control indicator is contained in both the forward and backward call indicators parameter field and describes the signal- ling capabilities within the network connection. 2.62 Range Information sent in a circuit group supervision message (e.g. circuit group blocking) to indicate the range of circuits affected by the action in the message. 2.63 Recommendation indicator Information sent in association with a cause value identifying the Recommendation to which the cause value applies. 2.64 Redirecting indicator Information sent in either direction indicating whether the call has been forwarded or rerouted and whether or not presentation of redirection information to the calling party is restricted. 2.65 Redirecting number Information sent in the forward direction when a call is redirected more than once, indicating the number from which the call was last redirected. 2.66 Redirecting reason Information sent in either direction indicating, in the case of calls undergoing multiple redirections, the reason why the call has been redirected. 2.67 Redirection counter Information sent in either direction indicating the number of redirections which have occurred on a call. 2.68 Redirection number Information sent in the backward direction indicating the number towards which the call must be rerouted or has been forwarded. 2.69 Routing label Information provided to the message transfer part for the pur- pose of message routing (see Recommendation Q.704, S 2.2). 2.70 Satellite indicator Information sent in the forward direction indicating the number of satellite circuits in the connection. 2.71 SCCP method indicator Information sent in either direction indicating the available SCCP methods, if any, for end-to-end transfer of information. 2.72 Screening indicator Information sent in either direction to indicate whether the address was provided by the user or network. 2.73 Signalling point code (national use) Information sent in a release message to identify the signal- ling point in which the call failed. 2.74 Solicited information indicator Information sent in an information message to indicate whether or not the message is a response to an information request message. 2.75 Status Information sent in a circuit group supervision message (e.g. circuit group blocking) to indicate the specific circuits, within the range of circuits stated in the message, that are affected by the action specified in the message. 2.76 Suspend/Resume indicator Information sent in the suspend and resume messages to indi- cate whether suspend/resume was initiated by an ISDN subscriber or by the network. 2.77 Temporary trunk blocking after release (national use) Information sent to the exchange at the other end of a circuit (trunk) to indicate low level of congestion at the sending exchange and that the circuit (trunk) should not be re-occupied by the receiving exchange for a short period of time after release. 2.78 Transit network selection (national use) Information sent in the initial address message indicating the transit network(s) requested to be used in the call. 2.79 Transmission medium requirement Information sent in the forward direction indicating the type of transmission medium required for the connection (e.g. 64 kbit/s unrestricted, speech). 2.80 User service information Information sent in the forward direction indicating the bearer capability requested by the calling party. 2.81 User-to-user indicators Information sent in association with a request (or response to a request) for user-to-user signalling supplementary service(s). 2.82 User-to-user information Information generated by a user and transferred transparently through the interexchange network between the originating and ter- minating local exchanges. Blanc H.T. [T1.762] __________________________________________________ TABLE 1/Q.762 (Sheet 1 of 3) { Mandatory or optional parameters in the ISDN user part messages } __________________________________________________ | | | | | | | | | | | | Tableau 1/Q.762 (feuillet 1 sur 3) [T1.762] A L'ITALIENNE, p. 3 H.T. [1T2.762] __________________________________________________ TABLE 1/Q.762 (Sheet 2 of 3) { Mandatory or optional parameters in the ISDN user part messages } __________________________________________________ | | | | | | | | | | | | Tableau 1/Q.762 (feuillet 2 sur 3) [1T2.762] A L'ITALIENNE, p. 4 H.T. [2T2.762] __________________________________________________ TABLE 1/Q.762 (Sheet 3 of 3) { Mandatory or optional parameters in the ISDN user part messages } __________________________________________________ | | | | | | | | | | | | Tableau 1/Q.762 (feuillet 3 sur 3) [2T2.762] A L'ITALIENNE, p. 5 H.T. [T3.762] TABLE A-2/Q.762 ISDN user part message acronyms ___________________________________________ ___________________________________________ | | | | | | | | | | Tableau 2/Q.762 [T3.762], p. 6 Recommendation Q.763 FORMATS AND CODES 1 General ISDN user part messages are carried on the signalling link by means of signal units the format of which is described in Recommendation Q.703, S 2.2. The format of and the codes used in the service information octet are described in Recommendation Q.704, S 14.2. The service indicator for the ISDN user part is coded 0101. The signalling information field of each message signal unit containing an ISDN user part message consists of an integral number of octets and encompasses the following parts (see Figure 1/Q.763): a) routing label; b) circuit identification code; c) message type code; d) the mandatory fixed part; e) the mandatory variable part; f ) the optional part, which may contain fixed length and variable length parameter fields. Note - The service information octet, the routing label and circuit identification code are not included in the SCCP user data parameter transferred between the ISDN user part and signalling connection control part. A description of the various message parts is given in the following sections. Figure 1/Q.763, (M), p. 1.1 Routing label The format and codes used for the routing label are described in Recommendation Q.704, S 2.2. For each individual circuit connec- tion, the same routing label must be used for each message that is transmitted for that connection. 1.2 Circuit identification code The format of the circuit identification code (CIC) is shown in Figure 2/Q.763. Figure 2/Q.763, (M), p. The allocation of circuit identification codes to individual circuits is determined by bilateral agreement and/or in accordance with applicable predetermined rules. For international applications, the four spare bits of the circuit identification field are reserved for CIC extension, pro- vided that bilateral agreement is obtained before any increase in size is performed. For national applications, the four spare bits can be used as required. Allocations for certain applications are defined below: a) 2048 kbit/s digital path For circuits which are derived from a 2048 kbit/s digital path (Recommendations G.732 and G.734) the circuit identification code contains in the 5 least significant bits a binary representa- tion of the actual number of the time slot which is assigned to the communication path. The remaining bits in the circuit identification code are used, where necessary, to identify these circuits uniquely among all other circuits of other systems interconnecting an originating and destination point. b) 8448 kbit/s digital path For circuits which are derived from a 8448 kbit/s digital path (Recommendations G.744 and G.747) the circuit identification code contains in the 7 least significant bits an identfication of the circuit which is assigned to the communication path. The codes in Table 1/Q.763 are used. The remaining bits in the circuit identification code are used, where necessary, to identify these circuits uniquely among all other circuits of other systems interconnecting an originating and destination point. c) Frequency division multiplex (FDM) systems in networks using the 2048 kbit/s pulse code modulation standard For frequency division multiplex systems existing in net- works that also use the 2048 kbit/s pulse code modulation standard, the circuit identification code contains in the 6 least significant bits the identification of a circuit within a group of 60 circuits carried by 5 basic frequency division multiplex groups which may or may not be part of the same supergroup. The codes in Table 2/Q.763 are used. The remaining bits in the circuit identification code are used, where necessary, to identify these circuits uniquely among all other circuits of other systems interconnecting an originating and destination point. H.T. [T1.763] TABLE 1/Q.763 2328.if 360<312 .nr 80 312 _______________________________ 0 0 0 0 0 0 0 Circuit 1 _______________________________ 0 0 0 0 0 0 1 Circuit 2 | || 0 0 1 1 1 1 1 Circuit 32 _______________________________ 0 1 0 0 0 0 0 Circuit 33 | || 1 1 1 1 1 1 0 Circuit 127 _______________________________ 1 1 1 1 1 1 1 Circuit 128 _______________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 1/Q.763 [T1.763], p. H.T. [T2.763] TABLE 2/Q.763 ____________________________________________________________________________ 0 0 0 0 0 0 Unallocated ____________________________________________________________________________ { 0 0 0 0 0 1 [Unable to Convert Formula] Circuit 12 } 1st basic (FDM) group ____________________________________________________________________________ { 0 0 1 1 0 1 0 0 1 1 1 0 0 0 1 1 1 1 0 1 0 0 0 0 0 1 0 0 0 1 [Unable to Convert Formula] Circuit 12 } 2nd basic (FDM) group ____________________________________________________________________________ { 0 1 1 0 1 0 | |0~1~1~1~1~1 1~0~0~0~0~0 1~0~0~0~0~1| | 1 0 0 1 1 0 } { Circuit 1 | |Circuit 6~ Unallocated Circuit 7~| | Circuit 12 } 3rd basic (FDM) group ____________________________________________________________________________ { 1 0 0 1 1 1 [Unable to Convert Formula] Circuit 9 Unallocated Circuit 10 Circuit 11 Circuit 12 } 4th basic (FDM) group ____________________________________________________________________________ { 1 1 0 1 0 0 [Unable to Convert Formula] Circuit 12 } 5th basic (FDM) group ____________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 2/Q.763 [T2.763], p. 1.3 Message type code The message type code consists of a one octet field and is mandatory for all messages. The message type code uniquely defines the function and format of each ISDN user part message. The allocation with reference to the appropriate descriptive section of this Recommendation is summarized in Table 3/Q.763. 1.4 Formatting principles Each message consists of a number of PARAMETERS listed and described in S 2. Each parameter has a NAME which is coded as a single octet (see Table 4/Q.763). The length of a parameter may be fixed or variable, and a LENGTH INDICATOR of one octet for each parameter may be included as described below. The detailed format is uniquely defined for each message type as described in S 3. A general format diagram is shown in Figure 3/Q.763. 1.5 Mandatory fixed part Those parameters that are mandatory and of fixed length for a particular message type will be contained in the mandatory fixed part position, length and order of the parameters is uniquely defined by the message type, thus the names of the parameters and the length indicators are not included in the message. 1.6 Mandatory variable part Mandatory parameters of variable length will be included in the mandatory variable part . Pointers are used to indicate the beginning of each parameter. Each pointer is encoded as a single octet. The name of each parameter and the order in which the pointers are sent is implicit in the message type. Parameter names are, therefore, not included in the message. The details of how pointers are encoded is found in S 2.3. The number of parameters, and thus the number of pointers is uniquely defined by the message type. A pointer is also included to indicate the beginning of the optional part. If the message type indicates that no optional part is allowed, then this pointer will not be present. If the message type indicates that an optional part is possible, but there is no optional part included in this particular message than a pointer field containing all zeros will be used. It is recommended that all future message types with a mandatory variable part indicate that an optional part is allowed. All the pointers are sent consecutively at the beginning of the mandatory variable part. Each parameter contains the parameter length indicator followed by the contents of the parameters. 1.7 Optional part The optional part consists of parameters that may or may not occur in any particular message type. Both fixed length and vari- able length parameters may be included. Optional parameters may be transmitted in any order. Each optional parameter will include the parameter name (one octet) and the length indicator (one octet) followed by the parameter contents. 1.8 End of optional parameters octet If optional parameters are present and after all optional parameters have been sent, an "end of optional parameters" octet containing all zeros will be transmitted. 1.9 Order of transmission Since all the fields consist of an integral number of octets, the formats are presented as a stack of octets. The first octet transmitted is the one shown at the top of the stack and the last is the one at the bottom (see Figure 3/Q.763). Unless otherwise indicated, within each octet and subfield the bits are transmitted with the least significant bit first. 1.10 Coding of spare bits Spare bits are coded 0 unless indicated otherwise. Figure 3/Q.763, (M), p. 1.11 National message types and parameters If message type codes and parameter name codes are required for national uses not included in this Recommendation, the codes chosen should be from the highest code downwards, that is, starting at code 11111111. Codes in the range 11111111 to 11100000 are reserved exclusively for this purpose. 2 Parameter formats and codes 2.1 Message type codes The encoding of the message type is shown in Table 3/Q.763. H.T. [T3.763] TABLE 3/Q.763 __________________________________________________________________________ Message type Reference (Table) Code __________________________________________________________________________ Address complete 5/Q.763 00000110 Answer 6/Q.763 00001001 Blocking 23/Q.763 00010011 Blocking acknowledgement 23/Q.763 00010101 Call modification completed 24/Q.763 00011101 Call modification request 24/Q.763 00011100 Call modification reject 24/Q.763 00011110 Call progress 7/Q.763 00101100 Circuit group blocking 25/Q.763 00011000 { Circuit group blocking acknowledgement } 25/Q.763 00011010 Circuit group query 26/Q.763 00101010 Circuit group query response 8/Q.763 00101011 Circuit group reset 26/Q.763 00010111 { Circuit group reset acknowledgement } 9/Q.763 00101001 Circuit group unblocking 25/Q.763 00011001 { Circuit group unblocking acknowledgement } 25/Q.763 00011011 { Charge information | ua) } (see Note) 00110001 Confusion 10/Q.763 00101111 Connect 11/Q.763 00000111 Continuity 12/Q.763 00000101 Continuity check request 23/Q.763 00010001 Delayed release | ua) 21/Q.763 00100111 Facility accepted 27/Q.763 00100000 Facility reject 13/Q.763 00100001 Facility request 27/Q.763 00011111 Forward transfer 21/Q.763 00001000 Information 14/Q.763 00000100 Information request 15/Q.763 00000011 Initial address 16/Q.763 00000001 { Loop back acknowledgement | ua) } 23/Q.763 00100100 Overload | ua) 23/Q.763 00110000 Pass-along 28/Q.763 00101000 Release 17/Q.763 00001100 Release complete 18/Q.763 00010000 Reset circuit 23/Q.763 00010010 Resume 22/Q.763 00001110 Subsequent address 19/Q.763 00000010 Suspend 22/Q.763 00001101 Unblocking 23/Q.763 00010100 Unblocking acknowledgement 23/Q.763 00010110 Unequipped CIC | ua) 23/Q.763 00101110 { User-to-user information } 20/Q.763 00101101 __________________________________________________________________________ { Reserved (used in 1984 version) } { 00001010 00001011 00001111 00100010 00100011 00100101 00100110 } __________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) For national use only Note - The format of this message is a national matter. Tableau 3/Q.763 [T3.763], p. 2.2 Coding of the length indicator The length indicator field is binary coded to indicate the number of octets in the parameter content field. The length indi- cated does not include the parameter name octet or the length indi- cator octet. 2.3 Coding of the pointers The pointer value (in binary) gives the number of octets between the pointer itself (included) and the first octet (not included) of the parameter associated with that pointer. The pointer value all zeros is used to indicate that, in the case of optional parameters, no optional parameter is present. 3 ISDN user part parameters 3.1 Parameter names The parameter name codes are given in Table 4/Q.763 together with references to the subsections in which they are described. 3.2 Access transport The format of the access transport parameter field is shown in Figure 4/Q.763. Figure 4/Q.763, (N), p. The information element is coded as described in Recommendation Q.931, S 4.5. Multiple Q.931 information elements can be included within the access transport parameter. The informa- tion elements applicable to a particular usage of the access tran- sport parameter are dependent on, and will be determined by, the relevant procedures. 3.3 Automatic congestion level The format of the automatic congestion level parameter field is shown in Figure 5/Q.763. Figure 5/Q.763, (N), p. H.T. [T4.763] TABLE 4/Q.763 ________________________________________________________________________________ Parameter name Reference ( S ) Code ________________________________________________________________________________ Access transport 3.2 00000011 Automatic congestion level 3.3 00100111 Backward call indicators 3.4 00010001 Call modification indicators 3.5 00010111 Call reference 3.6 00000001 Called party number 3.7 00000100 Calling party number 3.8 00001010 Calling party's category 3.9 00001001 Cause indicators 3.10 00010010 { Circuit group supervision message type indicator } 3.11 00010101 Circuit state indicator 3.12 00100110 { Closed user group interlock code } 3.13 00011010 Connected number 3.14 00100001 Connection request 3.15 00001101 Continuity indicators 3.16 00010000 End of optional parameters 3.17 00000000 Event information 3.18 00100100 Facility indicator 3.19 00011000 Forward call indicators 3.20 00000111 Information indicators 3.21 00001111 { Information request indicators } 3.22 00001110 { Nature of connection indicators } 3.23 00000110 { Optional backward call indicators } 3.24 00101001 { Optional forward call indicators } 3.25 00001000 Original called number 3.26 00101000 Range and status 3.27 00010110 Redirecting number 3.28 00001011 Redirection information 3.29 00010011 Redirection number 3.30 00001100 { Signalling point code | ua) } 3.31 00011110 Subsequent number 3.32 00000101 Suspend/Resume indicators 3.33 00100010 { Transit network selection | ua) } 3.34 00100011 { Transmission medium requirement } 3.35 00000010 User service information 3.36 00011101 User-to-user indicators 3.37 00101010 { User-to-user information } 3.38 00100000 ________________________________________________________________________________ { Reserved (used in 1984 version, Red Book) } { 00010100 00011001 00011011 00011100 00011111 } { Reserved for multi-slot identifier } 00100101 ________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) For national use only Tableau 4/Q.763 [T4.763], p. The following codes are used in the automatic congestion level parameter field: 00000000 spare 00000001 congestion level 1 exceeded 00000010 congestion level 2 exceeded 00000011 | o spare 11111111 3.4 Backward call indicators The format of the backward call indicators parameter field is shown in Figure 6/Q.763. Figure 6/Q.763, (MC), p. The following codes are used in the backward call indicators parameter field: bits B A: Charge indicator 0 0 no indication 0 1 no charge 1 0 charge 1 1 spare bits D C: Called party's status indicator 0 0 no indication 0 1 subscriber free 1 0 connect when free 1 1 spare bits F E: Called party's category indicator 0 0 no indication 0 1 ordinary subscriber 1 0 payphone 1 1 spare bits H G: End-to-end method indica- tor (Note) 0 0 no end-to-end method available (only link-by-link method available) 0 1 pass along method available 1 0 SCCP method available 1 1 pass along and SCCP methods available bit I: Interworking indicator (Note) 0 no interworking encountered 1 interworking encountered bit J: End-to-end information indicator (Note) 0 no end-to-end information available 1 end-to-end information available bit K: ISDN User Part indicator (Note) 0 ISDN User Part not used all the way 1 ISDN User Part used all the way bit L: Holding indicator (national use) 0 holding not requested 1 holding requested bit M: ISDN access indicator 0 terminating access non-ISDN 1 terminating access ISDN bit N: Echo control device indicator 0 incoming half echo control device not included 1 incoming half echo control device included bits P O: SCCP method indicator 0 0 no indication 0 1 connectionless method available 1 0 connection oriented method available 1 1 connectionless and connection oriented methods available Note - Bits G-K and O-P constitute the protocol control indi- cator. 3.5 Call modification indicators The format of the call modification indicators parameter field is shown in Figure 7/Q.763. Figure 7/Q.763, (MC), p. The following codes are used in the call modification indica- tors parameter field: bits B A: Modification indicator 0 0 spare 0 1 modify to service 1 1 0 modify to service 2 1 1 spare bits H C: Spare Note - Service 1 and 2 are described by the transmission medium requirement. 3.6 Call reference The format of the call reference parameter is shown in Figure 8/Q.763. Figure 8/Q.763, (N), p. The following codes are used in the subfields of the call reference parameter field: a) Call identity A code expressing in pure binary representation the iden- tification number allocated to the call. b) Point code The code of the signalling point in which the call identity is relevant. 3.7 Called party number The format of the called party number parameter field is shown in Figure 9/Q.763. Figure 9/Q.763, (N), p. The following codes are used in the subfields of the called party number parameter field: a) Odd/even indicator 0 even number of address signals 1 odd number of address signals b) Nature of address indicator 0000000 spare 0000001 subscriber number 0000010 spare, reserved for national use 0000011 national (significant) number 0000100 international number 0000101 | o spare 1101111 1110000 | o reserved for national use 1111110 1111111 spare c) Internal network number indicator (INN ind.) 0 routing to internal network number allowed 1 routing to internal network number not allowed d) Numbering plan indicator 000 spare 001 ISDN (Telephony) numbering plan (Recommandation E.164, E.163) 010 spare 011 Data numbering plan (Recommandation X.121) 100 Telex numbering plan (Recommendation F.69) 101 reserved for national use 110 reserved for national use 111 spare e) Address singal 0000 digit 0 0001 digit 1 0010 digit 2 0011 digit 3 0100 digit 4 0101 digit 5 0110 digit 6 0111 digit 7 1000 digit 8 1001 digit 9 1010 spare 1011 code 11 1100 code 12 1101 spare 1110 spare 1111 ST The most significant address signal is sent first. Subse- quent address signals are sent in successive 4-bit fields. f ) Filler In case of an odd number of address signals, the filler code 0000 is inserted after the last address signal. 3.8 Calling party number The format of the calling party number parameter field is shown in Figure 10/Q.763. Figure 10/Q.763, (N), p. The following codes are used in the calling party number parameter field. a) Odd/even indicator : See S 3.7 a). b) Nature of address indicator 0000000 spare 0000001 subscriber number 0000010 spare, reserved for national use 0000011 national (significant) number 0000100 international number 0000101 | o spare 1101111 1110000 | o reserved for national use 1111110 1111111 spare Note - Other types of nature of address indications (e.g. transit exchange identity) are for further study. c) Calling party number incomplete indicator (NI) 0 complete 1 incomplete d) Numbering plan indicator See S 3.7 d). e) Address presentation restricted (Pres. Restric.) indicator 00 presentation allowed 01 presentation restricted 10 address not available (Note) 11 spare Note - When the address is unavailable, the subfields in items a), b), c) and d) are coded with 0's. f ) Sceening indicator 00 reserved (Note) 01 user provided, verified and passed 10 reserved (Note) 11 network provided Note - Code 00 and 10 are reserved for "user provided, not verified" and "user provided, verified and failed" respec- tively. g) Address signal 0000 digit 0 0001 digit 1 0010 digit 2 0011 digit 3 0100 digit 4 0101 digit 5 0110 digit 6 0111 digit 7 1000 digit 8 1001 digit 9 1010 spare 1111 code 11 1100 code 12 1101 to spare 1111 h) Filler See S 3.7 f). 3.9 Calling party's category The format of the calling party's category parameter field is shown in Figure 11/Q.763. Figure 11/Q.763, (MC), p. The following codes are used in the calling party's category parameter field. 00000000 calling party's category unknown at this time 00000001 operator, language French 00000010 operator, language English 00000011 operator, language German 00000100 operator, language Russian 00000101 operator, language Spanish 00000110 available to Administrations for 00000111 selecting a particular language 00001000 by mutual agreement 00001001 reserved (see Recommendation Q.104) (Note) 00001010 ordinary calling subscriber 00001011 calling subscriber with priority 00001100 data call (voice band data) 00001101 test call 00001110 spare 00001111 payphone 00010000 | o spare 11011111 11100000 | o reserved for national use 11111110 11111111 spare Note - In national networks code 00001001 may be used to indicate that the calling party is a national operator. 3.10 Cause indicators The format of the cause indicators parameter field is shown in Figure 12/Q.763. Figure 12/Q.763, (N), p. The following codes are used in the subfields of the cause indicators parameter field: a) Extension indicator (ext) 0 octet continues through the next octet (e.g. octet 1 to 1a) 1 last octet b) Coding standard 00 CCITT standard, as described below 01 reserved for other international standards (Note) 10 national standard (Note) 11 standard specific to identified location (Note) Note - These other coding standards should be used only when the desired cause cannot be represented with the CCITT standard. c) Location 0000 user 0001 private network serving the local user 0010 public network serving the local user 0011 transit network 0100 public network serving the remote user 0101 private network serving the remote user 0111 international network 1010 beyond an interworking point, all other values are reserved. Note - Depending on the location of the users, the public network serving the local user may be the same network serving the remote user. Rules for coding the location field are defined in Recommendation Q.931 Annex J. d) Recommendation 0000000 Rec. Q.763 0000011 Rec. X.21 0000100 Rec. X.25 0000101 Public land mobile networks, Q.1000 Series. All other values are reserved. Note - If octet 1a is omitted, Recommendation Q.763 is assumed. e) Cause value The cause value is divided into two fields, a class (bits 5 through 7) and a value within a class (bits 1 through 4). The decimal equivalent of the cause value is shown in brackets beside the cause value. Class 000 and 001 - normal event: 0000001 (1) unallocated (unassigned) number 0000010 (2) no route to specified transit network (national use) 0000011 (3) no route to destination 0000100 (4) send special information tone 0000101 (5) misdialled trunk prefix 0010000 (16) normal call clearing 0010001 (17) user busy 0010010 (18) no user responding 0010011 (19) no answer from user (user alerted) 0010101 (21) call rejected 0010110 (22) number changed 0011011 (27) destination out of order 0011100 (28) address incomplete 0011101 (29) facility rejected 0011111 (31) normal - unspecified Class 010 - resource unavailable: 0100010 (34) no circuit available 0100110 (38) network out of order 0101001 (41) temporary failure 0101010 (42) switching equipment congestion 0101100 (44) requested channel not avail- able 0101111 (47) resource unavailable - unspecified Class 011 - service or option not available: 0110010 (50) requested facility not sub- scribed 0110111 (55) incoming calls barred within CUG 0111001 (57) bearer capability not author- ized 0111010 (58) bearer capability not presently available 0111111 (63) service/option not available - unspecified Class 100 - service or option not implemented: 1000001 (65) bearer capability not imple- mented 1000101 (69) requested facility not imple- mented 1000110 (70) only restricted digital infor- mation bearer capability is available 1001111 (79) service or option not imple- mented - unspecified Class 101 - invalid mesage (e.g. parameter out of range): 1010111 (87) called user not member of CUG 1011000 (88) incompatible destination 1011011 (91) invalid transit network selec- tion (national use) 1011111 (95) invalid message - unspecified Class 110 - protocol error (e.g. unknown message): 1100001 (97) message type non-existant or not implemented 1100011 (99) parameter non-existant or not implemented - discarded 1100101 (103) parameter non-existent or not implemented - passed on 1101111 (111) protocol error - unspecified Class 111 - interworking: 1111111 (127) interworking unspecified f ) Diagnostic The format and existence of the diagnostic field is depen- dant on the cause value and the location of generation. For causes generated by a public network, the following diagnostics may be included: Cause Diagnostic Format 1 Condition See below 2 Transit Network identity See S 3.34 (Note) 3 Condition See below 16 Condition See below 21 Condition See below 22 Called party number (new) See S 3.7 (Note) 29 Rejected parameter (Note) 50 Rejected parameter (Note) 57 Attribute identity See below 58 Attribute identity See below 65 Attribute identity See below 69 Rejected parameter (Note) 97 Message type See Table 3/Q.763 99 Parameter name(s) See Table 4/Q.763 103 Parameter name(s) See Table 4/Q.763 Note - These diagnostics shall also include the parameter name and length octets. 1) Diagnostic with attribute identity The format of the diagnostic field when coded with an attribute identity is shown in Figure 13/Q.763. Figure 13/Q.763, (N), p. The attribute number subfield identifies the rejected attribute as follows: 0110001 Information transfer capability 0110010 Information transfer mode 0110011 Information transfer rate 0110100 Structure 0110101 Configuration 0110110 Etablishment 0110111 Symmetry 0111000 Information transfer rate (dest to orig) 0111001 Layer identification and corresponding user information The rejected attribute and available attribute subfields are coded the same as in the equivalent octet of the user service information parameter field (see S 3.36) which contains the relevant attribute. Bits not related to the rejected attribute are coded 0. If more than one bearer capability attribute was rejected, the diagnostic field can be repeated. The extension bit (ext), when coded 0, indicates that this diagnostic continues to the next octet (e.g. octet 3a to 3b). The inclusion of the available attribute subfield is optional. 2) Condition diagnostic A condition diagnostic is a 1 octet field containing an extension bit (bit 8) and one of the following codes in bits 2-1: 00 unknown 01 permanent 10 transient 11 spare Bits 3 to 7 of a condition diagnostic are spare. 3.11 Circuit group supervision message type indicator The format of the circuit group supervision message type indi- cator parameter field is shown in Figure 14/Q.763. Figure 14/Q.763, (MC), p. The following codes are used in the circuit group supervision message type indicator parameter field: bits B A: Type indicator 0 0 maintenance oriented 0 1 hardward failure oriented 1 0 reserved for national use (used in 1984 version) 1 1 spare bits C H: Spare MONTAGE : SUITE RECOMMANDATION Q.763 SUR LE RESTE DE CETTE PAGE