delim @@
| 5i'
|
SECTION 3 DATA USER PART (DUP) |
SIGNALLING SYSTEM No. 7 -- DATA USER PART
(This Recommendation appears in Fascicle VIII.3 of the Blue Book, as Recommendation X.61.)
Blanc
Fascicle VI.8 -- Rec. Q.741 1
MONTAGE: PAGE 2 = PAGE BLANCHE 2 Fascicle VI.8 -- Rec. Q.741
SECTION 5
INTEGRATED SERVICES DIGITAL NETWORK USER PART (ISUP)
FUNCTIONAL DESCRIPTION OF THE ISDN USER PART
OF SIGNALLING SYSTEM No. 7
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 applications. Most signalling procedures, information elements and message 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 provided 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 objectives.
ISDN User Part protocol elements which support supplementary services are described in Recommendation Q.730.
Note -- The message set, message formats and procedures specified in this version of the ISDN User Part protocol are not in complete alignment with those of the 1984 version (Red Book). The two versions of the protocol are therefore not compatible in all aspects.
Fascicle VI.8 -- Rec. Q.761 3
The ISDN User Part protocol supports the basic bearer service, i.e. the establishment, supervision and release of 64 kbit/s circuit 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.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 Interconnection (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] |
|||
|
center box; lw(12p) | lw(60p) | lw(60p) | lw(60p) . name Parameter lw(192p) . |
cw(12p) | cw(60p) | cw(60p) | cw(60p) . X |
Generic name Specific |
|
|
Tableau du § 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 service request or a confirmation that the requested service has been performed, and
the Parameters contain the elements of supporting information 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 Message Transfer Part or by the latter to deliver signalling message information to the ISDN User Part.
4 Fascicle VI.8 -- Rec. Q.761
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
center box; cw(72p) sw(54p) | cw(54p) , c | c | ^ . Primitives Parameters Generic name Specific name _ lw(72p) | lw(54p) | lw(54p) . MTP-TRANSFER Request indication { OPC DPC SLS SIO Signalling info.
} _ lw(72p) | lw(54p) | lw(54p) . MTP-PAUSE Indication Affected DPC _ lw(72p) | lw(54p) | lw(54p) . MTP-RESUME Indication Affected DPC _ lw(72p) | lw(54p) | lw(54p) . 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.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.
Fascicle VI.8 -- Rec. Q.761 5
End-to-end signalling is used typically between call originating and terminating local exchanges, to request or to respond to requests for additional call related information, to invoke a supplementary service or to transfer user-to-user information transparently through the network.
|
End-to-end signalling procedures are described in Recommendation Q.764, § 3. The following two methods of end-to-end signalling are supported: |
||
|
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 Signalling System No. 7. The relevant procedures are described in Recommendation Q.764, § 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 established. 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, § 3.3.
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 elements 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 interworking between protocol versions is optimized by adhering to the following guidelines when specifying a new version:
|
1) Existing protocol elements, i.e. procedures, messages, parameters and codes, should not be changed unless a protocol error needs |
||
|
to be |
corrected or it becomes necessary to change the operation of the service that is being supported by the protocol. 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 encoding 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 message 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 mandatory 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 significant value in another version.
6 Fascicle VI.8 -- Rec. Q.761
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 signalling 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 abbreviations of these 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 subscriber (see Recommendation Q.28), and start measurement of call duration for international 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 incoming calls on the concerned circuit unless it has also sent a blocking 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 message 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 message indicating that the request has been rejected.
1.7 Call modification request message (CMR)
Fascicle VI.8 -- Rec. Q.762 7
A message sent in either direction indicating a calling or called party request to modify the characteristics of an established 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. |
8 Fascicle VI.8 -- Rec. Q.762
1.10 Circuit group blocking message (CGB)
A message sent to the exchange at the other end of an identified 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 circuit 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 message 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 identified group of circuits to cause cancellation in that group of circuits of an engaged condition invoked earlier by a blocking or circuit group blocking message.
|
1.15 |
Circuit group unblocking acknowledgement message (CGUA) A message sent in response to a circuit group unblocking message 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 confusion 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.
Fascicle VI.8 -- Rec. Q.762 9
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 verification of the communication path across the exchange with the specified degree of reliability.
10 Fascicle VI.8 -- Rec. Q.762
1.21 Continuity check request message (CCR)
A message sent by an exchange for a circuit on which a continuity 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 indicating 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 message. |
|
|
1.28 |
Information request message (INR) A message sent by an exchange to request information in association 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 continuity check request message indicating that a loop (or transceiver in the case of a 2-wire circuit) has been connected.
1.31 Overload message (OLM) (national use)
Fascicle VI.8 -- Rec. Q.762 11
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.
12 Fascicle VI.8 -- Rec. Q.762
1.33 Release message (REL)
A message sent in either direction to indicate that the circuit is being released due to the reason (cause) supplied and is ready to be put into the idle state on receipt of the release complete 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 message, 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 mutilation 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 message.
|
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 signalling independent of call control messages. Fascicle VI.8 |
-- Rec. Q.762 13 |
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.
14 Fascicle VI.8 -- Rec. Q.762
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 calling 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.
Fascicle VI.8 -- Rec. Q.762 15
|
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 assistance 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 information is included in |
the response.
16 Fascicle VI.8 -- Rec. Q.762
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 indicates that the called party cannot be reached because, although the called party number is in a valid format, it is not currently allocated (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 network 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 indicates 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 situation, 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 calling 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.
Fascicle VI.8 -- Rec. Q.762 17
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 indicates 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 available 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 capability 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 implemented class applies.
18 Fascicle VI.8 -- Rec. Q.762
e) Invalid Message (e.g. Parameter out of Range) class
Cause 87 -- Called user not member of CUG This cause indicates 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 -- discarded 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 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 ignored. In addition, if the equipment sending this cause is an intermediate point, then this cause indicates 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 provide 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 information to be returned. |
|
|
2.21 |
Charge information response indicator (national use) Information sent in response to a request for charge information 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.
Fascicle VI.8 -- Rec. Q.762 19
|
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) concerned 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
20 Fascicle VI.8 -- Rec. Q.762
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 device 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 destination exchange may obtain the information before alerting the called party.
Fascicle VI.8 -- Rec. Q.762 21
|
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 connection 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 Information |
Interworking indicator Information sent in either direction indicating whether or not Signalling System No. 7 is used in all parts of the network connection. |
|
|
2.46 |
ISDN Information |
ISDN access indicator Information sent in either direction indicating whether or not the access signalling protocol is ISDN. |
|
|
2.47 22 |
ISDN Fascicle |
ISDN user part indicator VI.8 -- Rec. Q.762 |
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.
Fascicle VI.8 -- Rec. Q.762 23
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 service 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 2.54 |
as a national call. 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 allocated to the call |
reference is relevant.
24 Fascicle VI.8 -- Rec. Q.762
2.60 Protocol class
Information sent in the connection request parameter indicating the protocol class requested by the signalling connection control 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 signalling capabilities within the network connection.
Fascicle VI.8 -- Rec. Q.762 25
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 Information |
Redirection counter Information sent in either direction indicating the number of redirections which have occurred on a call. |
|
|
2.68 |
Redirection Information |
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 Information |
Routing label Information provided to the message transfer part for the purpose of message routing (see Recommendation Q.704, § 2.2). |
|
|
2.70 |
Satellite Information |
Satellite indicator Information sent in the forward direction indicating the number of satellite circuits in the connection. |
|
|
2.71 |
SCCP Information |
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 Information |
Screening indicator Information sent in either direction to indicate whether the address was provided by the user or network. |
|
|
26 |
Fascicle |
VI.8 -- Rec. Q.762 |
|
2.73 |
Signalling point code (national use) Information sent in a release message to identify the signalling 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. Fascicle VI.8 -- Rec. Q.762 27 |
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 indicate 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 |
terminating local exchanges.
28 Fascicle VI.8 -- Rec. Q.762
Blanc
Fascicle VI.8 -- Rec. Q.762 29
H.T. [T1.762]
center box; cw(348p) . TABLE 1/Q.762 (Sheet 1 of 3) cw(348p) .
{ 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 |
|
|
30 |
Fascicle VI.8 -- Rec. Q.762 |
H.T. [1T2.762]
center box; cw(348p) . TABLE 1/Q.762 (Sheet 2 of 3) cw(348p) .
{ Mandatory or optional parameters in the ISDN user part messages
|
} Tableau 1/Q.762 (feuillet 2 sur 3) [1T2.762] A L'ITALIENNE, |
A L'ITALIENNE, p. 4 |
||
|
Fascicle VI.8 -- Rec. Q.762 |
31 |
H.T. [2T2.762]
center box; cw(348p) . TABLE 1/Q.762 (Sheet 3 of 3) cw(348p) .
{ 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 |
|
|
32 |
Fascicle VI.8 -- Rec. Q.762 |
H.T. [T3.762]
TABLE A-2/Q.762
ISDN user part message acronyms
|
center box; lw(30p) | lw(30p) | lw(30p) | lw(138p) . |
||
|
Fascicle VI.8 -- |
Tableau 2/Q.762 [T3.762], p. 6 Rec. Q.762 33 |
FORMATS AND CODES
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, § 2.2.
The format of and the codes used in the service information octet are described in Recommendation Q.704, § 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) b) c) d) e) f ) |
routing label; circuit identification code; message type code; the mandatory fixed part; the mandatory variable part; 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.
34 Fascicle VI.8 -- Rec. Q.763
Figure 1/Q.763, (M), p. Fascicle VI.8 -- Rec. Q.763 35
1.1 Routing label
The format and codes used for the routing label are described in Recommendation Q.704, § 2.2. For each individual circuit connection, 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, provided 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 representation 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 networks 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.
36 Fascicle VI.8 -- Rec. Q.763
H.T. [T1.763]
TABLE 1/Q.763
center box; cw(42p) | cw(42p) . 0 0 0 0 0 0 0 Circuit 1 _ cw(42p) | cw(42p) . 0 0 0 0 0 0 1 Circuit 2 cw(42p) | cw(42p) . @ left | right | @ cw(42p) | cw(42p) . 0 0 1 1 1 1 1 Circuit 32 _ cw(42p) | cw(42p) . 0 1 0 0 0 0 0 Circuit 33 cw(42p) | cw(42p) . @ left | right | @ cw(42p) | cw(42p) . 1 1 1 1 1 1 0 Circuit 127 _ cw(42p) | cw(42p) . 1 1 1 1 1 1 1 Circuit 128 _
|
Tableau 1/Q.763 [T1.763], p. |
||
|
H.T. [T2.763] TABLE 2/Q.763 center box; cw(42p) | cw(42p) | lw(66p) . 0 0 0 0 0 0 Unallocated _ cw(42p) | cw(42p) | lw(66p) . { 0 0 0 0 0 1 [Unable to Convert Formula] Circuit 12 } 1st basic (FDM) group _ cw(42p) | cw(42p) | lw(66p) . { 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 _ cw(42p) | cw(42p) | lw(66p) . { 0 1 1 0 1 0 @ left | 0 1 1 1 1 1~1 0 0 0 0 0~1 0 0 0 0 1 right | @ 1 0 0 1 1 0 |
||
|
} { Circuit 1 @ left | Circuit~6 ~Unallocated~Circuit~7 right | @ Circuit 12 |
||
|
} 3rd basic (FDM) group _ cw(42p) | cw(42p) | lw(66p) . { 1 0 0 1 1 1 [Unable to Convert Formula] Circuit 9 Unallocated Circuit 10 Circuit 11 Circuit 12 } 4th basic (FDM) group _ cw(42p) | cw(42p) | lw(66p) . { 1 1 0 1 0 0 [Unable to Convert Formula] Circuit 12 } 5th basic (FDM) group _ |
||
|
Tableau 2/Q.763 [T2.763], p. |
Fascicle VI.8 -- Rec. Q.763 37
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 § 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 § 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 § 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 variable 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.
38 Fascicle VI.8 -- Rec. Q.763
1.10 Coding of spare bits
Spare bits are coded 0 unless indicated otherwise.
Fascicle VI.8 -- Rec. Q.763 39
|
1.11 |
National message types and parameters |
Figure 3/Q.763, (M), p. |
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.1 Message type codes
40 Fascicle VI.8 -- Rec. Q.763
The encoding of the message type is shown in Table 3/Q.763.
Fascicle VI.8 -- Rec. Q.763 41
H.T. [T3.763]
TABLE 3/Q.763
center box; cw(156p) | cw(36p) | cw(36p) . Message type Reference (Table) Code _ lw(156p) | cw(36p) | cw(36p) . Address complete 5/Q.763 00000110 lw(156p) | cw(36p) | cw(36p) . Answer 6/Q.763 00001001 lw(156p) | cw(36p) | cw(36p) . Blocking 23/Q.763 00010011 lw(156p) | cw(36p) | cw(36p) . Blocking acknowledgement 23/Q.763 00010101 lw(156p) | cw(36p) | cw(36p) . Call modification completed 24/Q.763 00011101 lw(156p) | cw(36p) | cw(36p) . Call modification request 24/Q.763 00011100 lw(156p) | cw(36p) | cw(36p) . Call modification reject 24/Q.763 00011110 lw(156p) | cw(36p) | cw(36p) . Call progress 7/Q.763 00101100 lw(156p) | cw(36p) | cw(36p) . Circuit group blocking 25/Q.763 00011000 lw(156p) | cw(36p) | cw(36p) .
{ Circuit group blocking acknowledgement
} 25/Q.763 00011010 lw(156p) | cw(36p) | cw(36p) . Circuit group query 26/Q.763 00101010 lw(156p) | cw(36p) | cw(36p) . Circuit group query response 8/Q.763 00101011 lw(156p) | cw(36p) | cw(36p) . Circuit group reset 26/Q.763 00010111 lw(156p) | cw(36p) | cw(36p) .
|
{ Circuit group reset acknowledgement } 9/Q.763 00101001 lw(156p) | cw(36p) | cw(36p) . Circuit group unblocking 25/Q.763 |
00011001 lw(156p) | cw(36p) | cw(36p) . |
|||
|
{ Circuit group unblocking acknowledgement } 25/Q.763 00011011 lw(156p) | cw(36p) | cw(36p) . { Charge information | ua) } (see Note) 00110001 lw(156p) | cw(36p) | cw(36p) . Confusion 10/Q.763 |
00101111 lw(156p) | cw(36p) | cw(36p) |
. |
Connect 11/Q.763 00000111 lw(156p) | cw(36p) | cw(36p) . Continuity 12/Q.763 00000101 lw(156p) | cw(36p) | cw(36p) . Continuity check request 23/Q.763 00010001 lw(156p) | cw(36p) | cw(36p) . Delayed release | ua)
accepted 27/Q.763 00100000 lw(156p) | cw(36p) | cw(36p) . Facility reject 21/Q.76313/Q.763 0010011100100001lw(156p)lw(156p)| cw(36p)| cw(36p)| |cw(36p)cw(36p) .. FacilityFacility request 27/Q.763 00011111 lw(156p) | cw(36p) | cw(36p) . Forward transfer 21/Q.763 00001000 lw(156p) | cw(36p) | cw(36p) . Information 14/Q.763 00000100 lw(156p) | cw(36p) | cw(36p) . Information request 15/Q.763 00000011 lw(156p) | cw(36p) | cw(36p) . Initial address 16/Q.763 00000001 lw(156p) | cw(36p) | cw(36p) .
{ Loop back acknowledgement | ua)
} 23/Q.763 00100100 lw(156p) | cw(36p) | cw(36p) . Overload | ua)
Pass-along 28/Q.763 00101000 lw(156p) | cw(36p) | cw(36p) . Release 17/Q.76323/Q.7630000110000110000lw(156p)lw(156p)| cw(36p)| cw(36p)| cw(36p)| cw(36p). Release. complete 18/Q.763 00010000 lw(156p) | cw(36p) | cw(36p) . Reset circuit 23/Q.763 00010010 lw(156p) | cw(36p) | cw(36p) . Resume 22/Q.763 00001110 lw(156p) | cw(36p) | cw(36p) . Subsequent address 19/Q.763 00000010 lw(156p) | cw(36p) | cw(36p) . Suspend 22/Q.763 00001101 lw(156p) | cw(36p) | cw(36p) . Unblocking 23/Q.763 00010100 lw(156p) | cw(36p) | cw(36p) . Unblocking acknowledgement 23/Q.763 00010110 lw(156p) | cw(36p) | cw(36p) . Unequipped CIC | ua)
|
cw(36p) . { User-to-user information } 20/Q.763 00101101 _ lw(156p) | cw(36p) | cw(36p) . { 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. 42 Fascicle VI.8 -- Rec. Q.763 |
23/Q.763 |
00101110 lw(156p) | cw(36p) | 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 indicated does not include the parameter name octet or the length indicator 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.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, § 4.5. Multiple Q.931 information elements can be included |
within the access transport parameter. The information elements applicable to a particular usage of the access transport 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 Fascicle VI.8 -- Rec. Q.763 |
Figure 5/Q.763, (N), p. 43 |
H.T. [T4.763]
TABLE 4/Q.763
center box; cw(156p) | cw(36p) | cw(36p) . Parameter name Reference ( § ) Code _ lw(156p) | cw(36p) | cw(36p) . Access transport 3.2 00000011 lw(156p) | cw(36p) | cw(36p) . Automatic congestion level 3.3 00100111 lw(156p) | cw(36p) | cw(36p) . Backward call indicators 3.4 00010001 lw(156p) | cw(36p) | cw(36p) . Call modification indicators 3.5 00010111 lw(156p) | cw(36p) | cw(36p) . Call reference 3.6 00000001 lw(156p) | cw(36p) | cw(36p) . Called party number 3.7 00000100 lw(156p) | cw(36p) | cw(36p) . Calling party number 3.8 00001010 lw(156p) | cw(36p) | cw(36p) . Calling party's category 3.9 00001001 lw(156p) | cw(36p) | cw(36p) . Cause indicators 3.10 00010010 lw(156p) | cw(36p) | cw(36p) .
{ Circuit group supervision message type indicator
} 3.11 00010101 lw(156p) | cw(36p) | cw(36p) . Circuit state indicator 3.12 00100110 lw(156p) | cw(36p) | cw(36p) .
{ Closed user group interlock code
} 3.13 00011010 lw(156p) | cw(36p) | cw(36p) . Connected number 3.14 00100001 lw(156p) | cw(36p) | cw(36p) . Connection request 3.15 00001101 lw(156p) | cw(36p) | cw(36p) . Continuity indicators 3.16 00010000 lw(156p) | cw(36p) | cw(36p) . End of optional parameters 3.17 00000000 lw(156p) | cw(36p) | cw(36p) . Event information 3.18 00100100 lw(156p) | cw(36p) | cw(36p) . Facility indicator 3.19 00011000 lw(156p) | cw(36p) | cw(36p) . Forward call indicators 3.20 00000111 lw(156p) | cw(36p) | cw(36p) . Information indicators 3.21 00001111 lw(156p) | cw(36p) | cw(36p) .
|
{ Information request indicators } 3.22 00001110 lw(156p) | cw(36p) | cw(36p) . { Nature of connection indicators } 3.23 00000110 lw(156p) | cw(36p) | cw(36p) . { Optional backward call indicators } 3.24 00101001 lw(156p) | cw(36p) | cw(36p) . { Optional forward call indicators } 3.25 00001000 lw(156p) | cw(36p) | cw(36p) . Original |
. Original called number 3.26 00101000 lw(156p) | cw(36p) | cw(36p) . Range and |
|
status 3.27 00010110 lw(156p) | cw(36p) | cw(36p) . information 3.29 00010011 lw(156p) | cw(36p) | cw(36p) |
. Redirecting number 3.28 00001011 lw(156p) | cw(36p) | cw(36p) . Redirection . Redirection number 3.30 00001100 lw(156p) | cw(36p) | cw(36p) . |
{ Signalling point code | ua)
} 3.31 00011110 lw(156p) | cw(36p) | cw(36p) . Subsequent number 3.32 00000101 lw(156p) | cw(36p) | cw(36p) . Suspend/Resume indicators 3.33 00100010 lw(156p) | cw(36p) | cw(36p) .
|
{ Transit network selection | ua) } 3.34 00100011 lw(156p) | cw(36p) | cw(36p) . { Transmission medium requirement } 3.35 00000010 lw(156p) | cw(36p) | cw(36p) . User |
. User service information 3.36 00011101 lw(156p) | cw(36p) | cw(36p) . User-to-user |
|
indicators 3.37 00101010 lw(156p) | cw(36p) | cw(36p) |
. |
|
{ User-to-user information } 3.38 00100000 _ lw(156p) | cw(36p) | cw(36p) . { Reserved (used in 1984 version, Red Book) } { 00010100 00011001 00011011 00011100 |
00011111 |
|
} lw(156p) | cw(36p) | cw(36p) . { Reserved for multi-slot identifier } 00100101 a) |
|
|
For national use only |
Tableau 4/Q.763 [T4.763], p. 44 Fascicle VI.8 -- Rec. Q.763
|
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 indicator (Note) |
|||
|
Fascicle VI.8 -- Rec. Q.763 45 |
|
0 0 1 1 bit |
0 1 0 1 I: |
no end-to-end method available (only link-by-link method available) pass along method available SCCP method available pass along and SCCP methods available Interworking indicator (Note) |
|
0 no 1 interworking bit J: |
no interworking encountered interworking encountered J: End-to-end information indicator (Note) |
(Note) |
||
|
46 |
0 no 1 end-to-end bit K: 0 ISDN 1 ISDN bit L: 0 holding 1 holding Fascicle |
no end-to-end information available end-to-end information available K: ISDN User Part indicator (Note) ISDN User Part not used all the way ISDN User Part used all the way L: Holding indicator (national use) holding not requested holding requested VI.8 -- Rec. Q.763 |
|
bit 0 1 bit 0 1 bits 0 0 1 1 |
M: ISDN access indicator terminating access non-ISDN terminating access ISDN N: Echo control device indicator incoming half echo control device not included incoming half echo control device included P O: SCCP method indicator 0 no indication 1 connectionless method available 0 connection oriented method available 1 connectionless and connection oriented |
methods available |
|
Note -- Bits G-K and O-P constitute the protocol control indicator. |
|||
|
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 indicators 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. |
||
|
Fascicle VI.8 -- Rec. Q.763 47 |
Figure 8/Q.763, (N), p. 48 Fascicle VI.8 -- Rec. Q.763
|
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 identification 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 |
use |
|
|
0000011 national (significant) number 0000100 international number 0000101 | o spare |
||
|
Fascicle VI.8 -- Rec. Q.763 49 |
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
50 Fascicle VI.8 -- Rec. Q.763
|
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. Subsequent 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. Fascicle VI.8 -- |
Rec. Q.763 51 |
Figure 10/Q.763, (N), p. 52 Fascicle VI.8 -- Rec. Q.763
|
The following codes are used in the calling party number parameter field. a) Odd/even indicator : See § 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 § 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
Fascicle VI.8 -- Rec. Q.763 53
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'' respectively. 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 |
54 Fascicle VI.8 -- Rec. Q.763
|
1010 1111 1100 1101 to |
spare code 11 code 12 spare |
|||
|
1111 h) |
Filler |
|
See § 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 |
|||
|
Fascicle VI.8 -- Rec. Q.763 55 |
|
00010000 | o 11011111 11100000 | o |
spare 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.
56 Fascicle VI.8 -- Rec. Q.763
|
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) |
Figure 12/Q.763, (N), p. |
Note -- These other coding standards should be used only when the desired cause cannot be represented with the CCITT standard.
|
c) 0000 0001 0010 0011 0100 0101 0111 1010 |
Location user private network serving the local user public network serving the local user transit network public network serving the remote user private network serving the remote user international network 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.
Fascicle VI.8 -- Rec. Q.763 57
d) Recommendation
|
0000000 0000011 0000100 0000101 |
Rec. Q.763 Rec. X.21 Rec. X.25 Public land mobile networks, Q.1000 Series. |
All other values are reserved.
Note -- If octet 1a is omitted, Recommendation Q.763 is assumed. 58 Fascicle VI.8 -- Rec. Q.763
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 available 0101111 (47) resource unavailable -- unspecified Class 011 -- service or option not available: 0110010 (50) requested facility not subscribed 0110111 (55) incoming calls barred within CUG 0111001 (57) bearer capability not authorized 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 implemented |
implemented |
|
|
1000101 (69) requested facility not implemented 1000110 (70) only restricted digital information bearer capability is available 1001111 (79) service or option not implemented -- unspecified Class 101 -- invalid mesage (e.g. parameter out of range): 1010111 (87) called user not |
not member of CUG |
|
|
1011000 (88) incompatible destination Fascicle |
VI.8 -- Rec. Q.763 59 |
1011011 (91) invalid transit network selection (national use)
1011111 (95) invalid message -- unspecified
|
60 |
Class 110 -- protocol error (e.g. unknown message): 1100001 (97) 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 Fascicle VI.8 -- Rec. Q.763 |
message type non-existant or not implemented |
f ) Diagnostic
The format and existence of the diagnostic field is dependant 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 2 3 16 21 22 29 50 57 58 65 69 97 99 103 |
Condition See below Transit Network identity See § 3.34 (Note) Condition See below Condition See below Condition See below Called party number (new) See § 3.7 (Note) Rejected parameter (Note) Rejected parameter (Note) Attribute identity See below Attribute identity See below Attribute identity See below Rejected parameter (Note) Message type See Table 3/Q.763 Parameter name(s) See Table 4/Q.763 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 Fascicle |
VI.8 -- Rec. Q.763 61 |
|
0110110 0110111 0111000 0111001 |
Etablishment Symmetry Information transfer rate (dest to orig) 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 § 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.
62 Fascicle VI.8 -- Rec. Q.763
|
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 indicator parameter field is shown in Figure 14/Q.763. |
||
|
Figure |
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 Fascicle VI.8 -- Rec. |
Q.763 63 |
MONTAGE : SUITE RECOMMANDATION Q.763 SUR LE RESTE DE CETTE PAGE 64 Fascicle VI.8 -- Rec. Q.763
Fascicle VI.8 -- Rec. Q.763 65