2.9 Abnormal conditions

Because Signalling System No. 7 circuits have the capability of both-way operation, it is possible that the two exchanges will attempt to seize the same circuit at approximately the same time.

2.9.1.1 Unguarded interval

2.9.1.2 Detection of dual seizure

A dual seizure is detected by an exchange from the fact that it receives an initial address message for a circuit for which it has sent an initial address message, but before it receives a valid backwards message.

As a circuit group may handle a mixture of 64 kbit/s, multirate connection types and N ´ 64 kbit/s connection type, dual seizure by calls of different connection types is possible. In this case the initial address messages may have different circuit identification codes.

2.9.1.3 Preventive action

Different methods for circuit selection can be envisaged to minimize the occurrence of dual seizure. In the following, two methods are described. For both-way circuit groups supporting multirate connection types, method 1 only (described below) should be used. For both-way circuit groups not supporting multirate connection types either method 1 or 2 may be used. Further study is required to determine the field of application of each method and to ensure that the two methods do inter-work satisfactorily.

Other methods for circuit selection may also be used provided that they give the same degree of protection against dual seizure also when one of the methods specified is used at the other end.

An opposite order of selection is used at each exchange of a both-way circuit group.

Each exchange of a both-way circuit group has priority access to the group of circuits which it is controlling (see 2.9.1.4). Of this group the circuit which has been released the longest is selected (first-in, first-out). In addition each exchange of a both-way circuit group has non-priority access to
the group of circuits which it is non-controlling. Of this group the latest released circuit is selected (last-in, first-out) if all circuits in the group are busy.

It is necessary to take preventive action in cases where Signalling System No. 7 uses a signalling data link with long propagation time.

2.9.1.4 Action to be taken on detection of dual seizures

In the event of dual seizure, one exchange will be the control exchange and the other the non-control exchange. On detection of a dual seizure, the call being processed by the control exchange will be completed and the received initial address message will be disregarded. If the initial address message has been segmented using a segmentation message, then this second segment will also be disregarded. Any following subsequent address message(s) will also be disregarded.

Under these conditions, the call being processed by the control exchange will be allowed to mature. The call being processed by the non-control exchange will be backed off and the switch-path released. A release message will not be sent. The non-control exchange will make an automatic repeat attempt on the same or on an alternative route.

a) Where neither call involved is a multirate connection type or N ´ 64 kbit/s connection type

Each exchange will control one half of the circuits in a both-way circuit group. The exchange with the higher signalling point code will control all even-numbered circuits (circuit identification code) and the other exchange the odd-numbered circuits.

The exchange processing the call involving the greater number of 64 kbit/s circuits will be the control exchange.

The circuit identification code used in the initial address message shall be divided by the number of 64 kbit/s circuits required by the call; the integer part of this operation shall be taken as the result (i.e. any fraction part shall be discarded):

– if the result is even then the exchange with the higher signalling point code shall control the connection;

– if the result is odd then the exchange with the lower signalling point code shall control the connection.

d) Where at least one of the calls involved is of N ´ 64 kbit/s connection types

One of the exchanges will control, by prior bilateral agreement, all the circuits derived from the digital path supporting the N ´ 64 kbit/s connection.

2.9.2 Transmission alarm handling for digital inter-exchange circuits

When fully digital circuits are provided between two exchanges, which have some inherent fault indication feature giving an indication to the switching system when faults on transmission systems are detected, the switching system should inhibit selection of the circuits concerned for the period the fault conditions persist.

2.9.3 Reset of circuits and circuit groups

In systems which maintain circuit status in memory there may be occasions when the memory becomes mutilated. In such a case the circuits must be reset to the idle condition at both exchanges to make them available for new traffic. Since the exchange with the mutilated memory does not know
whether the circuits are idle, busy outgoing, busy incoming, blocked, etc., reset circuit messages or a circuit group reset message should be sent as appropriate for the affected circuits.

2.9.3.1 Reset circuit message

If only a few circuits are concerned, a reset circuit message should be sent for each affected circuit.

a) if it is the incoming or outgoing exchange on a connection in any state of call set-up or during a call, accept the message as a release message and respond by sending a release complete message, after the circuit has been made idle;

b) if the circuit is in the idle condition, accept the message as a release message and respond by sending a release complete message;

c) if it has previously sent a blocking message, or if it is unable to release the circuit as described above, respond by the blocking message. If an incoming or outgoing call is in progress, this call should be released and the circuit returned to the "idle, blocked" state. A release complete message is sent following the blocking message. The blocking message should be acknowledged by the affected exchange. If the acknowledgement is not received, the repetition procedure specified in 2.9.4 should be followed;

d) if it has previously received a blocking message, respond by releasing a possible outgoing call or call attempt on the circuit, remove the blocked condition, restore the circuit to the idle state, and respond with a release complete message;

e) if the message is received after the sending of an initial address message but before receipt of a backward message relating to that call, clear the circuit and make an automatic repeat attempt on another circuit if appropriate;

f) if the message is received after having sent a reset circuit message, respond by a release complete message. After receipt of the appropriate acknowledgement message, the circuit should be made available for service;

h) when the reset circuit message identifies a circuit being used by a multirate connection type or N ´ 64 kbit/s connection type call, in addition, in order to make idle all circuits used for the call but not indicated in the reset circuit message, send reset circuit messages (or circuit group reset messages) for those circuits to the affected exchange. Alternatively, the exchange receiving the reset message may, before completing the reset procedure, clear those circuits used for the call but not indicated in the reset message, using the normal release procedure.

The affected exchange will then reconstruct its memory according to the received response(s) to the reset circuit and respond to the message(s) in the normal way, i.e. blocking acknowledgement message in response to a blocking message.

If no release complete message is received in acknowledgement to the reset circuit message before 15-60 seconds, (T16) the reset circuit message should be repeated. If an acknowledgement for the message is not received within 5-15 minutes (T17) after the initial reset circuit message, the maintenance system should be notified. However, the sending of the reset circuit message should continue at 5-15 minutes (T17) intervals until maintenance intervention occurs.

2.9.3.2 Circuit group reset message

If a considerable number of circuits or all circuits are affected by a memory mutilation, (a) circuit group reset message(s) should be used to make them available for new traffic.

The maximum number of circuits to be reset with a circuit group reset message is limited to 32.

On receipt of a circuit group reset message the receiving (unaffected) exchange will:

b) send the appropriate circuit group blocking message(s) if it had previously sent a hardware failure oriented circuit group blocking message;

c) respond by a circuit group reset acknowledgement message in which the status indicator bits of the circuits available for service or blocked for reasons of hardware failure are coded 0 and the status indicator bits of all circuits blocked for maintenance reasons are set to 1;

d) if it had previously received (a) blocking message(s) or (a) circuit group blocking message(s) for one or more of the circuit(s) involved, the blocked condition will be removed and the circuits will be made available for service;

e) if a circuit group reset message is received concerning circuits for which a circuit group reset message or reset circuit message(s) have been sent, the circuits concerned are made available for service after receipt of the appropriate acknowledgement message;

f) appropriate messages should be sent on interconnected circuits to release them;

g) when the circuit group reset message identifies circuits being used by a multirate connection type or N ´ 64 kbit/s connection type call, in addition, in order to make idle all circuits used for the call but not indicated in the circuit group reset message, send reset circuit messages (or circuit group reset messages) for those circuits to the affected exchange. Alternatively, the exchange receiving the reset message may, before completing the reset procedure, clear those circuits used for the call but not indicated in the reset message, using the normal release procedure.

The affected exchange will then reconstruct its memory according to the possibly received circuit group blocking messages and the received circuit group reset acknowledgement message. It will respond to the possibly received circuit group blocking messages in the normal way.

If no acknowledgement to a circuit group reset message is received before 15-60 seconds (T22) the circuit group reset message should be repeated. If an acknowledgement for the circuit group reset message is not received within 5-15 minutes (T23) after sending the initial circuit group reset message the maintenance system should be notified. However, the sending of the circuit group reset message should continue at 5-15 minutes (T23) intervals until maintenance intervention occurs.

A correct acknowledgement should match the original circuit group reset message in range and circuit identification code indicated in the routeing label. The circuit identification code in the routeing label of both circuit group reset messages and circuit group reset acknowledgement messages should belong to a circuit whose control is allocated to the ISDN User Part.

All circuit identification codes in the range of a circuit group reset and circuit group reset acknowledgement message must belong to circuits whose control is allocated to the ISDN User Part.

2.9.3.3 Abnormal circuit group reset message procedures

i) If a circuit group reset message is received indicating reset of more circuits than allowed by the receiving exchange, it is discarded.

ii) If a circuit group reset acknowledgement message is received which is not a correct response to a sent circuit group reset message, it is discarded.

iii) If a circuit group reset message is received requesting reset of circuits that are not controlled by the ISDN User Part, or a circuit group reset acknowledgement message that contains circuit identification codes that are not controlled by the ISDN User Part, the message is discarded.

2.9.4 Failure in the blocking/unblocking sequence

An exchange will repeat the blocking (unblocking) message or the circuit group blocking (unblocking) message on failure to receive the appropriate acknowledgement in response to one of these messages before 15-60 seconds (T12, T14, T18, T20 appropriately). (See 2.8.2.)

If the appropriate acknowledgement is not received within a period of 5-15 minutes (T13, T15, T19, T21 appropriately) after sending the initial blocking (unblocking) message or group blocking (unblocking) message, the maintenance system should be alerted, the repetition of the blocking (unblocking) message or circuit group blocking (unblocking) message should be continued at the intervals specified by T13, T15, T19 and T21, respectively, until maintenance intervention occurs and the circuit(s) taken out of (returned to) service as appropriate.

2.9.5 Receipt of unreasonable signalling information messages

The Message Transfer Part of the signalling system will avoid mis-sequencing, or double delivery, of messages with a high reliability (Recommendation Q.706 [14]). However undetected errors at the signalling link level and exchange malfunctions may produce signalling information messages that are either ambiguous or inappropriate.

Unreasonable or unexpected signalling information may also be received at an exchange due to differing levels of signalling protocol enhancements at different exchanges within a network: an exchange using a more enhanced version of the protocol may send information to a less enhanced exchange which is outside the protocol definition supported at that exchange.

The degree of applicability of the procedures below at exchanges where there are differences between the capabilities of the incoming and outgoing signalling systems, e.g. between the national and international sides of a gateway, is for further study.

The procedures listed below do not include the procedures for the blocking, circuit group blocking and the circuit group reset, these are covered in 2.8.2.3 and 2.9.3.3 respectively.

a) The message length is less than the number of octets required for the fixed mandatory part, the mandatory variable pointers and the start of optional parameters pointer.

b) A mandatory variable or start of optional parameter's pointer points beyond the message length.

c) A mandatory variable or optional parameter's length indicator causes the overall message length to be exceeded.

For the purposes of format error detection, the message length may be interpreted as either:

Interpretation i) is preferred as it will detect errors which may not be found by interpretation ii). However it is not contained in the MTP Recommendations that the received message length is passed to its users by the MTP.

2.9.5.1 Handling of unexpected messages

An unexpected message is one which contains a message type code that is within the set supported at this exchange, but is not expected to be received in the current state of the call.

In order to resolve possible ambiguities in the state of a circuit when unexpected messages are received the following will apply:

a) if a release message is received relating to an idle circuit it will be acknowledged with a release complete message;

b) if a release complete message is received relating to an idle circuit it will be discarded;

c) if a release complete message is received relating to a busy circuit for which a release message has not been sent, the circuit will be released and a release message will be sent;

d) if a segmentation message is received and if the circuit is seized by the call, in case the segmentation has not been announced in the simple segmentation indicator the segmentation message shall be discarded;

e) if a release complete message is received identifying one of the busy circuits being used by a multirate connection type or N ´ 64 kbit/s connection type call for which a release message has not been sent, the call will be cleared, all circuits made idle and a release message sent indicating the lowest circuit identification code of the multiple 64 kbit/s circuits used by the call;

f) if other unexpected signalling messages are received, the following actions will be undertaken:

– if the circuit is seized by a call, after receipt of a backward message required for the call set-up, the unexpected signalling message is discarded, except in certain cases, see item c);

– if the circuit is seized by a call, before receipt of a backward message required for the call set-up, the Reset Circuit Message is sent (or, in the case of a multirate connection type or N ´ 64 kbit/s connection type call, a circuit group reset message or multiple reset circuit messages are sent). If the circuit is seized by an incoming call, any interconnected circuits will be released. If the circuit is seized by an outgoing call, an automatic repeat attempt is provided on another circuit.

2.9.5.2 General requirements on receipt of unrecognized signalling information messages and parameters

It may happen that an exchange receives unrecognized signalling information, i.e. messages, parameter types or parameter values. This can typically be caused by the upgrading of the signalling system used by other exchanges in the network. In these cases the following compatibility procedures are invoked to ensure the predictable network behaviour.

a) compatibility information received in the same message as the unrecognized information;

NOTE 1 – This cause value may be received from a Blue Book (1988) ISDN User Part, but will not be generated from a (1997) ISDN User Part.

For all the above cause values a diagnostic field is included containing, dependent on the cause value either, the unrecognized parameter name(s), the message type code, or the message type code and the unrecognized parameter name(s).

i) Signalling for a facility completely provided between the originating and destination local exchanges could utilize one of the end-to-end methods defined in Recommendation Q.730 [16], i.e. such facilities do not have to be supported by transit exchanges.

ii) The forward compatibility information contains different instructions for different exchanges. There are two types of exchanges, type A and type B exchanges. The classification of type A and B exchanges to the functional type an exchange may perform is listed below. It is determined on a per call basis. The classification of an exchange to the functional type can change during a call due to, for example, supplementary services.

– Originating exchange, i.e. the exchange in which the call is generated from a national public network point of view.

– Destination exchange, i.e. the exchange to which the call is destined from a national public network point of view.

– Interworking exchange, i.e. the exchange in which interworking is performed between ISDN User Part and other user parts or signalling systems.

NOTE 2 – In an incoming or outgoing international exchange, the instruction to pass on a message or a parameter does not preclude the normal policing functions of these exchanges. It is recommended that an exchange interconnecting two national networks should behave as an incoming or outgoing international exchange.

– National or international transit exchange, i.e. an exchange that acts just as a transit node.

iii) Since type A and type B exchanges can be both national and international exchanges, the compatibility mechanism is applicable to the national and international network.

iv) As a minimum, all implementations must recognize all messages specified in Table 4/Q.761 [18] and all parameters specified in Table 5/Q.761 [18].

v) If an exchange receives a confusion, a release, a release complete or facility reject message indicating an unrecognized message or parameter received, it assumes interaction with an exchange at a different functional level. See 2.9.5.3 for more details on this.

vi) All unrecognized messages that can be received only contain parameters coded as optional parameters, no "new" messages will contain mandatory fixed or mandatory variable parameters.

If messages are received without compatibility information and are not recognized, they are discarded and the confusion message is sent.

When an unrecognized parameter or message is received, the exchange should find some corresponding instructions contained in the parameter compatibility information or message compatibility information parameters respectively. The parameter compatibility information parameter may contain compatibility instructions for more than one parameter. The message
compatibility information parameter contains the instructions specific for the handling of the complete message.

If the exchange does not find instructions in an appropriate compatibility parameter or if the compatibility parameter is not found in the message, the actions default to a basic action. Details of this are found in 2.9.5.3.

The instruction indicators are a set of Boolean indicators. The following general rules apply to the examination of these instruction indicators:

i) Depending on the role of the exchange in the call, i.e. type A or type B, and the settings of the indicators only a subset of the indicators are examined, some being ignored.

Only type B exchanges examine the "Transit at Intermediate Exchange indicator". If it is set to "Transit Interpretation", the other indicators are ignored. If it is set to "End Node Interpretation", the actions in accordance with the setting of the remaining indicators are performed.

Type A exchanges always interpret the remaining indicators, i.e. all indicators except the "Transit at Intermediate Exchange indicator".

Consequently, "End Node Interpretation" means that all kinds of exchanges, i.e. type A and type B, have to interpret the instruction indicators.

ii) Instruction indicators marked as "spare" are not examined. They may be used by future versions of the ISDN User Part; in this case the future version of the ISDN User Part will set the currently defined instruction indicators to a reasonable value for the current version. This rule ensures that more types of instructions can be defined in the future without creating a backward compatibility problem.

iii) An exchange must decide what exchange type it is for the before performing compatibility actions.

iv) At a type B exchange the unrecognized information should be passed on unchanged, if the "Transit at Intermediate exchange indicator" is set to "Transit Interpretation".

v) At a type B exchange that has not been instructed to pass on the unrecognized information, if the "Release Call indicator" is set to "Release Call", the call is released.

At a type A exchange, the call is released if the "Release Call indicator" is set to "Release Call".

vi) At a type B exchange that has not been instructed to pass on the unrecognized information or at a type A exchange, in any case the following is applicable if the "Release Call indicator" is set to "Do Not Release Call":

– if the "Discard Message indicator", or the "Discard Parameter indicator" is set to "Discard Message/Discard Parameter", the message or parameter is discarded, as instructed,

– and then, if the "Send Notification indicator" is set to "Send Notification", a confusion message is sent towards the exchange that sent the unrecognized information.

vii) For the case of an unrecognized parameter it is possible for the instruction to require that either the unrecognized parameter or the whole message is discarded. This provides for the case where the sending exchange determines that it is not acceptable for the message to continue being processed without this parameter.

viii) In case a parameter is included more than once in the same message, the instruction indicator of the parameter compatibility information parameter is set according to the most stringent combination of the possible codings (i.e. the coding "1" of a bit in the instruction indicator is dominant).

ix) In case a message is used for more than one procedure related to the same call and the codings of the instruction indicator of the message compatibility information parameter described in the corresponding texts are different, the instruction indicator is set according to the most stringent combination of the possible codings (i.e. the coding "1" of a bit in the instruction indicator is dominant).

x) At a type A exchange where "pass on" has been specified for a message or parameter and "pass on" is not possible, then the "pass on not possible indicator" and "send notification indicator" are checked.

xi) In case of for example a repeat attempt if a confusion message is sent or passed on with the indication that a parameter of an IAM is discarded, this parameter shall not be sent in a new Initial address message.

xii) If an exchange applies the instruction "discard message" according to the parameter compatibility information parameter, it should discard the first segment and its possible associated segmentation message whenever timer T34 has been started.

xiii) If unrecognized information is received at a broadband/narrow-band interworking point, the broadband/narrow-band interworking indicator is checked.

xiv) Tables 10 and 11 clarify the handling of the received compatibility information:

Table 10/Q.764 – On receipt of message compatibility information parameter
Instruction indicator			Required action
B	C	D
0	X	0	Pass on message (Notes 1, 2 and 3)
0	0	1	Discard message
0	1	1	Discard message and send notification
1	X	X	Release call (Note 1)
Bit	B 0 1	Release call indicator Do not release call Release call
Bit	C 0 1	Send notification indicator Do not send notification Send notification
Bit	D 0 1	Discard message indicator Do not discard message (pass on) Discard message
If pass on is set (bit D = 0) but not possible then bits C and E are checked.
Bit	E 0 1	Pass on not possible indicator Release call Discard information
Bit	GF 00 01 10 11	Broadband/narrow-band interworking indicator Pass on Discard message Release call Reserved, assume "00"
NOTE 1 – "x" = don't care. NOTE 2 – Applicable to type B exchanges and incoming or outgoing international exchanges. Other exchanges (e.g. originating, terminating, interworking) check bit E to determine the required action. NOTE 3 – In case of passing on a message, no notification is sent, bit C is ignored.

Table 11/Q.764 – On receipt of parameter compatibility information parameter
Instruction indicator				Required action
B	C	D	E
0	X	0	0	Pass on parameter (Notes 1 and 2)
0	0	0	1	Discard parameter
0	0	1	0	Discard message
0	0	1	1	Discard message
0	1	0	1	Discard parameter and send notification
0	1	1	0	Discard message and send notification
0	1	1	1	Discard message and send notification
1	X	X	X	Release call (Note 1)
Bit	B 0 1	Release call indicator Do not release call Release call
Bit	C 0 1	Send notification indicator Do not send notification Send notification
Bit	D 0 1	Discard message indicator Do not discard message (pass on) Discard message
Bit	E 0 1	Discard parameter indicator Do not discard parameter (pass on) Discard parameter
If pass on is set (bit D = 0 and bit E = 0 ) but not possible, bits C, F and G are checked.
Bit	GF 00 01 10 11	Pass on not possible indicator Release call Discard message Discard parameter Reserved in 1993 version, assume "00"
Bit	JI 00 01 10 11	Broadband/narrow-band interworking indicator Pass on Discard message Release call Discard parameter
NOTE 1 – 1 "x" = don't care. NOTE 2 – Applicable to type B exchanges and incoming or outgoing international exchanges. Other exchanges (i.e. originating, terminating, interworking) shall check Bits G and F to determine the required action.

2.9.5.3 Procedures for the handling of the unrecognized messages or parameters

A confusion message must not be sent in response to a received confusion, facility reject, release or release complete message. Any unrecognized parameters received in a confusion, facility reject or
release complete message are discarded. Any unrecognized mandatory parameter value received in a confusion or facility reject message will result in the message being discarded.

2.9.5.3.1 Unrecognized messages

Depending on the instructions received in the "Message Compatibility Information parameter", a type A exchange receiving an unrecognized message will either:

NOTE 1 – The transparent passing of a message is only applicable when the signalling is ISUP'92 or a later version.

A release and a confusion message shall include the cause value #97 (message type non-existent or not implemented-discarded), followed by a diagnostic field containing the message type code.

If an unrecognized message is received without "Message compatibility Information parameter" at an exchange, the message is discarded and a confusion message is returned. A confusion message shall include the cause value # 97, "message type non-existent or not implemented – discarded", followed by a diagnostic field containing the message type code.

NOTE 2 – All messages not included in Table 4/Q.761 [18] may be regarded as unrecognized. As a minimum all implementations must recognize all messages specified in Table 4/Q.761 [18].

Depending on the instructions received in the "Message Compatibility Information parameter", a type B exchange receiving an unrecognized message will either:

A confusion message shall include the cause value #97 (message type non-existent or not implemented-discarded), followed by a diagnostic field containing the message type code.

A release message shall include the cause value #97, "message type non-existent or not implemented – discarded", followed by a diagnostic field containing the message type code.

NOTE 3 – All messages not included in Table 4/Q.761 [18] may be regarded as unrecognized. As a minimum all implementations must recognize all messages specified in Table 4/Q.761 [18].

If an unrecognized message is received without "Message compatibility Information parameter" at an exchange, the message is discarded and a confusion message is returned. A confusion message shall include the cause value #97 (message type non-existent or not implemented-discarded), followed by a diagnostic field containing the message type code.

2.9.5.3.2 Unrecognized parameters

Receipt of unrecognized parameters can only refer to optional parameters, since mandatory parameters will always be recognized by their location in a message.

The minimum set of recognized parameters is contained in Table 5/Q.761 [18]. Unexpected parameters (a parameter in the "wrong" message) are handled like unrecognized parameters.

Depending on the instructions received in the "Parameter Compatibility Information parameter", a type A exchange receiving an unrecognized parameter will either:

NOTE – The transparent passing of a parameter is only applicable when the signalling is ISUP'92 or a later version.

A confusion message shall include the cause value #99 (parameter non-existent or not implemented-discarded) followed by a diagnostic field containing the parameter name, or #110 (message with unrecognized parameter-discarded), followed by a diagnostic field containing the message name and the name of the first detected unrecognized parameter which caused the message to be discarded. A confusion message may refer to multiple unrecognized parameters.

A release message shall include the cause value #99 (parameter non-existent or not implemented-discarded) followed by a diagnostic field containing the parameter name.

If an unrecognized parameter is received in a facility request message, the parameter is handled like unrecognized parameters in other messages.

If a release message is received containing an unrecognized parameter, depending on the instructions received in the compatibility information parameter, a type A exchange will either:

– discard the parameter and send a cause 99, "parameter non-existent or not implemented-discarded", in the release complete message.

If an exchange receives and detects an unrecognized parameter without a "Parameter Compatibility Information parameter", the actions taken will be dependent on whether the unrecognized parameter is passed on or discarded. If the unrecognized parameter is discarded, a confusion message is sent to the exchange from which the unrecognized
parameter was received. The confusion message contains the cause value #99 (parameter non-existent or not implemented-discarded), followed by a diagnostic field containing the parameter name. A confusion message may refer to multiple unrecognized parameters. If the unrecognized parameter is passed on unmodified, no subsequent actions are necessary.

If a facility request message is received with unrecognized parameters, the message is discarded and a facility reject message is returned including the cause value #99 (parameter non-existent or not implemented-discarded), followed by the parameter name code in the diagnostic field.

If a release message containing an unrecognized parameter is received at a type A exchange, a release complete message is returned including the cause value #99 (parameter non-existent or not implemented-discarded).

Depending on the instructions received in the "Parameter Compatibility Information parameter", a type B exchange receiving an unrecognized parameter will either:

A release message shall include the cause value #99 (parameter non-existent or not implemented-discarded), followed by a diagnostic field containing the parameter name.

If an unrecognized parameter is received in a facility request message, the parameter is handled like unrecognized parameters in other messages.

Depending on the instructions received in the "Parameter Compatibility Information parameter", an exchange receiving an unrecognized parameter in a release message will either:

– discard the parameter and send a cause 99, "parameter non-existent or not implemented – discarded", in the release complete message.

If a release message containing an unrecognized parameter that cannot be passed on is received at a type B exchange, a release complete message is returned including the cause value #99 (parameter non-existent or not implemented-discarded).

2.9.5.3.3 Unrecognized parameter values

Any parameter values marked as "spare", "reserved" or "national use" in Recommendation Q.763 [19] may be regarded as unrecognized.

If an exchange receives and detects a recognized parameter, but the contents are unrecognized, then the actions are as defined as below:

Unrecognized mandatory parameter values can only occur for parameters defined in messages of the Blue Book 1988 ISDN User Part. This ISDN User Part does not contain any mandatory parameters in new messages.

If an exchange receives and detects an unrecognized mandatory parameter value, the actions taken in the different types of exchanges will be dependent on Tables A.1 and A.2/Q.763 [19].

If a Facility Request message is received with unrecognized mandatory parameter value(s) the actions to be taken are described in the above mentioned tables, i.e. the message is discarded and a Facility Reject message is returned including the cause value #99 (parameter non-existent or not implemented- discarded), followed by the parameter name code in the diagnostic field indicating the first detected unrecognized parameter.

If a Release message is received with unrecognized mandatory parameter value(s) the actions to be taken are described in the above mentioned tables.

The procedures as stated for unrecognized parameters apply. There is no specific compatibility information field for each parameter value. For all parameter values contained in a parameter, the compatibility information of the parameter applies.

If unrecognized parameter values are received and detected in optional parameters which are already defined in Blue Book Recommendation Q.763 [19], the actions taken will be dependent on the tables contained in Recommendation Q.763 [19].

2.9.5.4 Procedures for the handling of responses indicating unrecognized information has been sent

2.9.5.4.1 Type A exchanges

Action taken on receipt of these messages at an originating or terminating exchange will depend on the call state and the affected service.

The definition of any procedure that is outside the basic call set-up protocol, as defined in this Recommendation, should include procedures for handling responses that indicate that another exchange has received, but not recognized, information belonging to that procedure. The procedure receiving this response should take the appropriate actions.

The default action taken on receipt of a confusion message is to discard the message without disrupting normal call processing.

2.9.5.4.2 Type B exchanges

An exchange receiving confusion (message type non-existent or not implemented-discarded) has to determine the appropriate subsequent actions as described for type A exchanges in the above subclause.

ii) Confusion (parameter non-existent or not implemented-discarded, or passed on)

The actions taken at a type B exchange, on receipt of a confusion message will depend on whether the exchange has the functionality to generate the parameter identified in the diagnostic field:

a) If the exchange does not have the functionality to generate the parameter, the decision on what action should be taken is deferred to an exchange that does contain this functionality. This is achieved by passing the confusion message transparently through the type B exchange.

b) If this exchange does have the functionality to generate the parameter, the procedural element that created or modified the information should determine any subsequent actions, as described for type A exchanges above.

If a type B exchange does not have the capability to take action on receipt of facility reject, it should pass the message transparently to the preceding or succeeding exchange.

Action taken on receipt of a release or a release complete message with cause indicating unrecognized information is as for the normal procedures for these messages.

Table 12a/Q.764 – Handling of responses indicating unrecognized information has been sent
	Exchange has the functionality to generate the information
	Cause
Message	Parameter discarded	Parameter passed on	Message discarded	Message passed on
Confusion	(Procedure dependent action)
Facility reject	Normal procedures	Procedure depend. Action	Not applicable	Not applicable
Release	Normal procedures	Not applicable	Not applicable	Not applicable
Release complete	Normal procedures	Normal procedures	Not applicable	Not applicable

Table 12b/Q.764 – Handling of responses indicating unrecognized information has been sent
	Exchange does not have the functionality to generate the information
	Cause
Message	Parameter discarded	Parameter passed on	Message discarded	Message passed on
Confusion	Defer action (transit confusion)
Facility reject	Defer action (transit)
Release	Normal procedures	Not applicable	Not applicable	Not applicable
Release complete	Normal procedures	Normal procedures	Not applicable	Not applicable

2.9.5.5 Procedures for handling unreasonable information

a) is of valid type, i.e. it is not unexpected or unrecognized as described in 2.9.5.1 and 2.9.5.3; and

b) it contains parameters of recognized type and value, i.e. the procedures in 2.9.5.3 do not apply,

it is still possible that the contents of the message are unreasonable. This can be as a result of conflicting information within the message. The following example of this is identified.

– The Protocol Control Indicators, (in either the Forward or Backward call indicators) can contain conflicting information. e.g. End–to–End Method Indicator set to "no method available", but the SCCP Method Indicator set to indicate that an SCCP method is available. This situation should be handled by assuming the lower network capability for the affected parameter.

2.9.6 Failure to receive a "release complete" message – Timer T1 and T5

If a release complete message is not received in response to a release message before expiry of timer (T1) the exchange will retransmit the release message.

On transmitting the initial release message, a 5-15 minute timer (T5) is started. If no release complete message is received on the expiry of this timer (T5), the exchange shall:

iv) continue the sending of the reset circuit message at 5-15 minute intervals until maintenance action occurs.

2.9.7 Failure to receive a response to an information request message (national use)

If a response is not received in response to an information request message before timer T33 expires, the exchange will release the connection and the maintenance system may be informed.

2.9.8 Other failure conditions

2.9.8.1 Inability to release in response to a release message

If an exchange is unable to return the circuit to the idle condition in response to a release message, it should immediately remove the circuit from service, alert the maintenance system and send the blocking message.

Upon receipt of the blocking acknowledgement message, the release complete message is sent in acknowledgement of the release message.

2.9.8.2 Call-failure

The call-failure indication (cause value #31) is sent in a release message (see 2.2) whenever a call attempt fails and other specific cause values do not apply. Reception of the release message at any Signalling System No. 7 exchange will cause the release message to be sent to preceding exchanges. If the signalling does not permit the release message to be sent, the appropriate signal, tone or announcement is sent to preceding exchanges.

2.9.8.3 Abnormal release conditions

If the conditions for normal release as covered in 2.3 are not fulfilled, release will take place under the following conditions:

– release all equipment and the connection on failure to meet the conditions for normal release of address and routeing information before 20-30 seconds after sending the latest address message;

– release all equipment and release the connection on failure to receive an answer message within time T9 specified in Recommendation Q.118 [10] after the receipt of the address complete message. The call is released in the backward direction with cause value #19 (no answer from user; user alerted).

An incoming international exchange shall release all equipment and the connection into the national network and send back a release message in the following cases:

– on failure to receive a continuity message if applicable before 10-15 seconds (T8) after receipt of the initial address message; or

– on failure to receive a backward signal from a national network (where expected) before 20-30 seconds (T7) after receipt of the latest address message; or

– on receipt of a release message after an address complete message has been generated; or

– on failure to receive an address message before 15-20 seconds (T35) after receipt of the latest address message and before the minimum or fixed number of digits have been received.

The exchange shall release all equipment and the connection and send back the release message in the following cases:

– on failure to receive a continuity message if applicable before 10-15 seconds after receipt of the initial address message; or

– on failure to meet the conditions for normal release as covered in 2.3 before 20-30 seconds after sending the latest address message; or

– on failure to receive an address message before 15-20 seconds (T35) after receipt of the latest address message and before the minimum or fixed number of digits have been received.

2.9.9 Temporary Trunk Blocking (TTB) (national use)

TTB is essentially a means of blocking circuits on a route, for a predetermined period, to reduce traffic to an exchange which has invoked load control. Circuits are removed from service on a per circuit basis under delay time-out conditions applied by the unaffected exchange, on receipt of an overload message.

2.9.9.1 Procedures

In an originating exchange, calls originating from non-priority class lines will not set the calling party category parameter field to "subscriber with priority" in the outgoing initial address message.

When an initial address message is received by an exchange which is subject to load control and the calling party category parameter does not indicate a priority call, the initial address message is not processed and an overload message is returned to the preceding exchange.

At an originating, or intermediate exchange receipt of the overload message shall cause the following actions:

– A timer (T3) is started, value 2 minutes. On expiry of the timer the release procedure shall be initiated for the circuit concerned. During the overload time-out period the circuit concerned is not available for traffic from the affected node to the unaffected node.

– The call attempt will be continued on an alternative route if available. If not the call will be released in the backward direction with cause value # 42 (switching equipment congestion).

In an originating exchange, calls originating from priority class lines will set the calling party category parameter field to "subscriber with priority" in the outgoing initial address message.

At an intermediate or terminating exchange where load control has been invoked, the priority call will override the load control and the call will continue in its attempt to be set up.