C:\WINWORD\CCITTREC.DOT

Recommendation Q.762

GENERAL FUNCTION OF MESSAGES AND SIGNALS

	This Recommendation describes the elements of signalling informa-
tion 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. 
Table1/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		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 subscriber (see Recommen-
dation Q.28), and

—	start measurement of call duration for international accounting pur-
poses (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 sub-
sequent 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)

	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 charg-
ing purposes.

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 subse-
quent 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 indi-
cating 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 con-
dition 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 indi-
cate 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.

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 cir-
cuit to the following exchange, including verification of the communication 
path across the exchange with the specified degree of reliability.

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 acti-
vation 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 out-
going 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)

	A message sent in the backward direction, on non—priority calls in 
response to an IAM, to invoke temporary trunk blocking of the circuit con-
cerned 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 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 cir-
cuit 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 com-
plete 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 ini-
tial 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.

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 infor-
mation 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 can-
not 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 indi-
cate 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 for-
warding 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.

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 cate-
gory, indicating whether or not the requested information 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 indicates that the called party cannot be reached because, 
although the called party number is in a valid format, it is not cur-
rently 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 net-
work 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 net-
work, while it does exist, does not serve the equipment which is 
sending this cause. This cause is supported on a network—depen-
dent 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 rea-
sons 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 compati-
ble 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 conect 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 incom-
patible.

Cause 22 — Number changed

	This cause is returned to a calling party when the called number indi-
cated by the calling party is no longer assigned. The new called 
number may optionally be included in the diagnostic field. If a net-
work 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 function-
ing 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 success-
ful.

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 ser-
vice 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 unre-
stricted bearer service but that the equipment sending this cause 
only supports the restricted version of the requested bearer capabil-
ity.

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.

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 compati-
bility 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 Recom-
mendation 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 indi-
cates 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 indi-
cates that the parameter(s) were ignored. In addition, if the equip-
ment 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 indi-
cating 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 hard-
ware 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 net-
work.

2.27	Coding standard

	Information sent in association with a parameter (e.g. cause indica-
tors) 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

	Information sent in association which a cause value and which pro-
vides 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.

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 con-
nection 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 indicator

	Information sent in either direction indicating whether or not Signal-
ling System No. 7 is used in all parts of the network connection.

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 connec-
tion.

2.49	Local reference

	Information sent in the connection request, indicating the local refer-
ence 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 indicat-
ing 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 
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 number-
ing 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.

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.

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 redi-
rected.

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 redi-
rected.

2.67	Redirection counter

	Information sent in either direction indicating the number of redirec-
tions 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 purpose of 
message routing (see RecommendationQ.704, § 2.2).

2.70	Satellite indicator

	Information sent in the forward direction indicating the number of sat-
ellite 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 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.

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 mes-
sage.

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 net-
work.

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 cir-
cuit (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 trans-
mission 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 capa-
bility 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.

TABLE 1/Q.762 (Sheet 1 of 3)

Mandatory or optional parameters in the ISDN user part messages

THIS TABLE CAN BE FOUND IN FILE NAMED "762T1-E.DOC". IT 
HAS TO BE PRINTED IN A3 FORMAT.

IT CONTAINS 3 PAGES.

TABLE A—2/Q.762

ISDN user part message acronyms



English

 French

 Spanish

 ACM

 ACO

 MDC

 Address complete

 ANM

 REP

 RST

 Answer

 BLA

 BLA

 ARB

 Blocking acknowledgement

 BLO

 BLO

 BLO

 Blocking

 CCR

 CCD

 PPC

 Continuity check request

 CFN

 ICO

 CFN

 Confusion

 CGB

 BLG

 BGC

 Circuit group blocking

 CGBA

 BGA

 ARBG

 Circuit group blocking acknowledge-
ment

 CGU

 DBG

 DGC

 Circuit group unblocking

 CGUA

 DGA

 ARDG

 Circuit group unblocking acknowl-
edgement

 CMC

 MAE

 MLC

 Call modification completed

 CMR

 MAD

 PML

 Call modification request

 CMRJ

 MAR

 RFA

 Call modification reject

 CON

 CON

 CNX

 Connect

 COT

 CCP

 CON

 Continuity

 CPG

 PRG

 PRL

 Call progress

 CRG

 TAX

 TAS

 Charge information

 CQM

 IGD

 IGC

 Circuit group query

 CQR

 IGR

 RIG

 Circuit group query response

 DRS

 LID

 LID

 Delayed release

 FAA

 SUAC

 FAA

 Facility accepted

 FAR

 SUDM

 PFA

 Facility request

 FOT

 IOP

 INT

 Forward transfer

 FRJ

 SURF

 RFA

 Facility reject

 GRA

 RZA

 ARRG

 Circuit group reset acknowledgement

 GRS

 RZG

 RGC

 Circuit group reset

 IAM

 MIA

 MID

 Initial address

 INF

 INF

 INF

 Information

 INR

 IND

 PIN

 Information request

 LPA

 BOA

 AEB

 Loop back acknowledgment

 OLM

 SUR

 SBC

 Overload

 PAM

 FAP

 MDP

 Pass along

 REL

 LIB

 LIB

 Release

 RES

 RPR

 REA

 Resume

 RLC

 LIT

 LIC

 Release complete

 RSC

 RZC

 RCI

 Reset circuit

 SAM

 MSA

 MSD

 Subsequent address

 SUS

 SUS

 SUS

 Suspend

 UBL

 DBO

 DBL

 Unblocking

 UBA

 DBA

 ARD

 Unblocking acknowledgement

 UCIC

 CINE

 CICN

 Unequipped circuit identification 
code

 USR

 UAU

 IUU

 User—to—user information