5i' MONTAGE: REC. Q.763 EN-T | TE DE CETTE PAGE Recommendation Q.764 SIGNALLING PROCEDURES 1 General 1.1 Relationship with other Recommendations This Recommendation describes the signalling procedures for the set-up and cleardown of national and international ISDN connec- tions. The messages and signals are defined in Recommendation Q.762 and their format and content are given in Recommendation Q.763. Recommendation Q.730 contains the procedures for supplementary ser- vices. (These were previously S 4 of Recommendation Q.764.) 1.2 Numbering (see Recommendations E.163, E.164) The procedures described assume that the ISDN uses the inter- national numbering plan defined for the ISDN and thus provides a basic circuit switched service between ISDN terminals or between ISDN terminals and terminals being connected to the existing inter- national telephony network. 1.3 Address signalling In general, the call set-up procedure described is standard for both speech and non-speech connections using en-bloc address signalling for calls between ISDN terminals. Overlap address sig- nalling is also specified. 1.4 Basic procedures The basic call control procedure is divided into three phases; call set-up, the data/conversation phase and call cleardown. Mes- sages on the signalling link are used to establish and terminate the different phases of a call. Standard inband supervisory tones and/or recorded announcements are returned to the caller onspeech and 3.1 kHz connections to provide information on call progress. Calls originating from ISDN terminals may be supplied with more detailed call progress information by means of additional messages in the access protocol supported by a range of messages in the net- work. 1.5 Signalling methods Two signalling methods are used in this Recommendation: - link-by-link; - end-to-end. The link-by-link method is primarily used for messages that need to be examined at each exchange (see S 2). The end-to-end methods are used for messages of end point significance (see Recommendation Q.730). The link-by-link method may be used for messages of end point significance. (However, the messages may be affected by processing delays.) 1.6 Layout of Recommendation Q.764 The procedures specified in S 2 of this Recommendation relate to basic calls (i.e. calls not involving supplementary services). Section 3 of this Recommendation specifies the procedures relating to end-to-end signalling connections. The additional requirements to be met in the case of calls involving supplementary services and network utilities are specified in Recommendation Q.730. The timers used in this Recommendation are summarized in Annex A. The SDLs for the ISDN-UP are presented in Annex B. 1.7 Interworking with other signalling systems or user parts Only some examples are included in this Recommendation and these should not be used as a definitive interworking guide. 2 Basic call control and signalling procedures Figures 1/Q.764 to 10/Q.764 at the end of this section show the ISDN call set-up sequences which are described below. 2.1 Successful call set-up 2.1.1 Forward address signalling - en bloc operation 2.1.1.1 Actions required at originating exchange a) Circuit selection When the originating exchange has received the complete selection information from the calling party, and has determined that the call is to be routed to another exchange, selection of a suitable, free, inter-exchange circuit takes place and an initial address message is sent to the succeeding exchange. Appropriate routing information is either stored at the originating exchange or at a remote database to which a request may be made. The selection of the route will depend on the called party number, connection type required and the network signalling capa- bility required. This selection process may be performed at the exchange or with the assistance of the remote database. In addition, in the case of a subscriber with digital access, the set-up message contains bearer capability information which is analyzed by the originating exchange to determine the correct connection type and network signalling capability. The bearer capability information will be mapped into the user service information parameter of the initial address message. The informa- tion received from the access interface is used to set the value of the transmission medium requirement parameter. The first value of bearer information received will be used to set the initial mode of the connection. The connection types allowed are: - speech; - 3.1 kHz audio; - 64 kbit/s unrestricted; - alternate speech/64 kbit/s unrestricted; - alternate 64 kbit/s unrestricted/speech. The network signalling capabilities allowed are: - ISDN-UP preferred; - ISDN-UP required; - ISDN-UP not required (any signalling system). The information used to determine the routing of the call by the originating exchange will be included in the initial address message, (as transmission medium requirement and forward call indi- cators), to enable correct routing at intermediate exchanges. The initial address message conveys implicitly the meaning that the indicated circuit has been seized. In the case where Nx64 kbit/s (N_"2) connections are required, the procedures for a single 64 kbit/s connection may be used if the Nx64 kbit/s are contiguous 64 kbit/s channels and are pre-assigned for Nx64 kbit/s use. If subaddress information is received from the calling access, this information is passed unchanged to the destination exchange in the access transport parameter of the initial address message. b) Address information sending sequence The sending sequence of address information on interna- tional calls will be the country code (not sent to an incoming international exchange) followed by the national (significant) number. On national connections, the address information may be the local number or the national (significant) number as required by the Administration concerned. For calls to international operator positions (Code 11 and Code 12) refer to Recommendation Q.107. The end of pulsing (ST) signal will be used whenever the originating exchange or the outgoing exchange is in a position to know by digit analysis that the final digit has been sent. c) Initial address message The initial address message (IAM) in principle contains all the information that is required to route the call to the des- tination exchange and connect the call to the called party. All initial address messages will include a protocol con- trol indicator (in the forward call indicator parameter) and a transmission medium requirement parameter. The originating exchange will set the parameters in the protocol control indicator and in the ISDN-UP preference indicator to indicate: i) the type of end-to-end method that can be accom- modated (S 3); ii) the availability of Signalling System No. 7 signalling; iii) the use of the ISDN-UP; iv) whether further information is available (to be requested before the called party is alerted); v) network signalling capability required, e.g. ISDN-UP required all the way. The ISDN-UP preference indicator is set according to the bearer service, teleservice and supplementary service(s) requested. The exact setting depends on the service demand conditions and may be different depending on individual cases. In principle, if the service demand requires ISDN-UP to be essential then the indicator is set to "required", if the service required is optional but pre- ferred it is set to "preferred", otherwise it is set to "not required". The indicator is set to either "required" or "pre- ferred", or "not required", according to the most stringent condi- tion required by one or more of the parameters in the initial address message. In addition, if end-to-end signalling is essential to provide the requested service the indicator should always be set to "required" (see Recommendation E.172). The transmission medium requirement parameter contains the connection type required information, e.g. 3.1 kHz audio. The originating exchange may also include in the initial address message: i) a call reference (including the point code of the originating exchange) to enable the destination exchange to establish an end-to-end connection (S 3); ii) the calling party number if this is to be passed forward without being requested. The calling party number could contain Code 11 or 12 if the call is from an international operator; iii) an SCCP connection request parameter; and iv) other information related to supplementary ser- vices and network utilities. The initial address message can contain an access transport parameter. d) Transfer of information not included in the ini- tial address message As an alternative to the inclusion of call set-up user facility information in the initial address message, any call set-up user facility information that need not be examined at intermediate exchanges and which can be requested from by the des- tination exchange (see Recommendation Q.763, S 3.22), may be tran- sported between the originating and destination exchange. The method of transportation for this information can be by the link-to-link method (see S 2.1.6) or via the end-to-end methods (see S 3). e) Completion of transmission path Through connection of the transmission path will be com- pleted in the backward direction (the transmission path is com- pleted in the forward direction on receipt of a connect or answer message) at the originating exchange immediately after the sending of the initial address message, except in those cases where condi- tions on the outgoing circuit prevent it (see S 2.1.9). It is also acceptable that on speech or 3.1 kHz audio calls, through-connection of the transmission path will be com- pleted in both directions immediately after the initial address message has been sent, except in those cases where conditions on the outgoing circuit prevent it (see S 2.1.9). f ) Network protection timer When the originating exchange or the controlling exchange has sent the initial address message the awaiting address complete timer (T7) is started. If timer (T7) expires the connection is released and an indication is returned to the calling subscriber. 2.1.1.2 Actions required at an intermediate exchange a) Circuit selection An intermediate exchange, on receipt of an initial address message will analyze the called party number and the other routing information (S 2.1.1.1 | )) to determine the routing of the call. If the intermediate exchange can route the call using the connec- tion type specified in the transmission medium requirement parame- ter, a free inter-exchange circuit is seized and an initial address message is sent to the succeeding exchange. Within a network if the intermediate exchange does not route the call using just the connection type specified in the transmission medium requirement parameter, the exchange may also examine the user service informa- tion containing the bearer capability information (if available) to determine if a suitable route can be selected. In this case if a new connection type is provided the transmission medium requirement parameter is modified to the new connection type. For calls between networks, the gateway exchange (e.g. outgoing ISC) must ensure that the transmission medium requirement parameter is set according to the service requested by the customer (see Recommendation E.172). More specifically this parameter is carried unchanged within the international network. When no echo suppressor or nature-of-circuit indication is received from a preceding exchange using a signalling system with fewer facilities, the indicators will be considered as received "no" unless positive knowledge is available. b) Parameters in the initial address message An intermediate exchange may modify signalling information received from the preceding exchange according to the capabilities used on the outgoing route. Signalling information that may be changed are nature of connection indicator, end-to-end method indi- cator; the most significant digits in the called party number may be amended or omitted (see S 2.1.1.1 | )). A change of the end-to-end method used may also alter parameters (see S 3). Other signalling information is passed on transparently, e.g. the access transport parameter, user service information, etc. c) Completion of transmission path Through-connection of the transmission path in both direc- tions will be completed at an intermediate exchange immediately after the initial address message has been sent, except in those cases where conditions on the outgoing circuit prevent it (see S 2.1.9). 2.1.1.3 Actions required at the destination exchange a) Selection of called party Upon receipt of an initial address message the destination exchange will analyze the called party number to determine to which party the call should be connected. It will also check the called party's line condition and perform various checks to verify whether or not the connection is allowed. These checks will include correspondence of compatibility checks, e.g. checks associated with supplementary services. At this point, certain call set-up information may need to be obtained from an originating or controlling exchange (see S 2.1.6). Examination of the protocol control indicator will show whether end-to-end information is necessary to be obtained before further processing of the call, in this case the SCCP, pass along or information request and information messages can be used. In this case where the connection is allowed, the destina- tion exchange will set up a connection to the called party. If a continuity check has to be performed on one or more of the circuits involved in a connection, setting up of the connection to the called party must be prevented until the continuity of such cir- cuits has been verified. 2.1.2 Forward address signalling - Overlap operation 2.1.2.1 Actions required at originating exchange a) Circuit selection When the originating exchange has received sufficient information [see S 2.1.2.1 | )] from the calling party to determine that the call is to be routed to another exchange, selection of a suitable, free, inter-exchange circuit takes place and an initial address message is sent to the succeeding exchange. Appropriate routing information is either stored at the originating exchange or at a remote database to which a request may be made. The selection of the route will depend on the called party number, connection type required and the network signalling capa- bility required. This selection process may be performed at the exchange or with the assistance of a remote database. In addition, in the case of a subscriber with digital access, the set-up message contains bearer capability information which is analyzed by the originating exchange to determine the correct connection type and network signalling capability. The bearer capability information will be mapped into the user service information parameter of the initial address message. The informa- tion received from the access interface is used to set the value of the transmission medium requirement parameter. The first value of bearer information received will be used to set the initial mode of the connection. The connection types allowed are: - speech; - 3.1 kHz audio; - 64 kbit/s unrestricted; - alternate speech/64 kbit/s unrestricted; - alternate 64 kbit/s unrestricted/speech. The network signalling capabilities allowed are: - ISDN-UP preferred; - ISDN-UP required; - ISDN-UP not required (any signalling system). The information used to determine the routing of the call by the originating exchange will be included in the IAM, (as transmission medium requirement and forward call indicators), to enable correct routing at intermediate exchanges. The IAM conveys implicitly the meaning that the indicated circuit has been seized. In the case where N x 64 kbit/s (N _" 2) connections are required, the procedures for a single 64 kbit/s connection may be used if the N x 64 kbit/s are contiguous 64 kbit/s channels and are pre-assigned for N x 64 kbit/s use. If subaddress information is received from the calling access, this information is passed unchanged to the destination exchange in the access transport parameter of the initial address message only. b) Address information sending sequence The sending sequence of address information on interna- tional calls will be the country code (not sent to an incoming international exchange) followed by the national (significant) number. On national connections, the address information may be the local number or the national (significant) number as required by the Administration concerned. For calls to international operator positions (Code 11 and Code 12) refer to Recommendation Q.107. The end of pulsing (ST) signal will be used whenever the originating exchange or the outgoing exchange is in a position to know by digit analysis that the final digit has been sent. c) Content of initial and subsequent address mes- sages The initial and subsequent address messages in principle contain all of the information that is required to route the call to the destination exchange and connect the call to the called party. The contents of the initial address message is the same as described in S 2.1.1.1 | ). The only purpose of the subsequent address message is to carry further digits. All digits required for routing the call through the inter- national network will be sent in the IAM. On calls with a country code in the number (except in the case of calls to special opera- tors), the IAM will contain a minimum of 4 digits and should con- tain as many digits as are available. Within national networks the address information contained within the IAM may vary depending on the routing requirement within the network. The remaining digits of the number may be sent in subse- quent address messages containing one or several digits as they are received. Efficiency can be gained by grouping together as many digits as possible. However, to prevent an increase in postsending delay in those cases where overlap operation with subscribers' dialling is used, it may be desirable to send the last few digits individually. The end-of-pulsing (ST) signal is always sent in the fol- lowing situations: i) semi-automatic calls; ii) test calls; and iii) when the end-of-pulsing (ST) signal is received. In automatic working, the end-of-pulsing (ST) signal will be sent whenever the originating or outgoing exchange is in a posi- tion to know, by digit analysis, that the final digit has been sent. Digit analysis may consist of an examination of the country code and counting the maximum (or fixed) number of digits of the national number. In other cases, the end-of-pulsing signal is not sent and the end-of-address information is determined by the receipt of the address complete message or connect message from the incoming exchange. d) Transfer of information not included in the ini- tial address message As an alternative to the inclusion of call set-up user facility information in the initial address message, any call set-up user facility information that need not be examined at intermediate exchanges and which can be requested by the destina- tion exchange (see Recommendation Q.763, S 3.22), may be tran- sported between the originating and destination exchange. The method of transportation for this information can be by the link-by-link method (see S 2.1.6) or via the end-to-end methods (see S 3). e) Completion of transmission path Through connection of the transmission path in the back- ward direction (the transmission path is completed in the forward direction on receipt of connect or answer message) at the originat- ing exchange will be completed except in the cases where conditions on the outgoing circuit prevent it (see S 2.1.9): i) immediately after the sending of the initial address message, or ii) when digit analysis or timer (T1\d0), or receipt of the address complete message indicates that all digits have been received. It is also acceptable that on speech or 3.1 kHz audio calls, through connection of the transmission path will be com- pleted in both directions immediately after the initial address message has been sent, except in the cases where conditions on the outgoing circuit prevent it (see S 2.1.9). f ) Network protection timer Each time when the originating exchange has sent an address message the awaiting address complete timer (T7) is started. If timer (T7) expires the connection is released and an indication is sent to the calling subscriber. 2.1.2.2 Actions required at an intermediate exchange a) Circuit selection An intermediate exchange, on receipt of an IAM, will analyze the digits available and the other routing information [see S 2.1.2.1 | )] to determine the routing of the call. If the inter- mediate exchange can route the call using the connection type specified in the transmission medium requirement parameter a suit- able free inter-exchange circuit is seized and an IAM is sent to the succeeding exchange. If the number of digits in the called party number are not sufficient to route the call the routing will be carried out when the intermediate exchange has received additional digits in subsequent address message(s). Any address digits received in subsequent address messages during the circuit selection process may be included in this IAM. Any subsequent address messages received after the IAM has been sent, are for- warded to the succeeding exchange as subsequent address message(s). Within the network if the intermediate exchange does not route the call just using the connection type specified in the transmission medium requirement parameter, the exchange may also examine the user service information containing the bearer capabil- ity information (if available) to determine if a suitable route can be selected. In this case the transmission medium requirement parameter is modified to the new connection type. For calls between networks, the gateway exchange (e.g. outgoing ISC) must ensure that the transmission medium requirement parameter is set according to the service requested by the customer (see Recommendation E.172). More specifically this parameter is carried unchanged within the international network. When no echo suppressor or nature-of-circuit indication is received from a preceding exchange using a signalling system with fewer facilities the indicators will be considered as received "no" unless positive knowledge is available. Selection of the outgoing national circuit normally can start at an incoming international exchange on receipt of the IAM and signalling can proceed on the first national link. b) Parameters in the initial address message An intermediate exchange may modify signalling information received from the preceding exchange according to the capabilities used on the outgoing route. Signalling information that may be changed are nature of connection indicator, end-to-end method indi- cator; the most significant digits in the called party number may be amended or omitted [see S 2.1.1.1 | )]. A change of the end-to-end method used may also alter parameters (see S 3). Other signalling information is passed on transparently, e.g. the access transport parameter, user service information, etc. c) Completion of transmission path Through-connection of the transmission path in both direc- tions will be completed at an intermediate exchange immediately after the initial address message has been sent, except in those cases where conditions on the outgoing circuit prevent it (see S 2.1.9). 2.1.2.3 Actions required at the destination exchange a) Selection of called party Upon the receipt of the sufficient called party number information the destination exchange will analyze the called party number to determine to which party the call should be connected. It will also check the called party's line condition and perform vari- ous checks, to verify whether or not the connection is allowed. These checks will include correspondence of compatibility checks, e.g. checks associated with supplementary services. At this point, certain call set-up information may need to be obtained from an originating or controlling exchange (see S 2.1.6). Examination of the protocol control indicator will show whether end-to-end information is necessary to be obtained before further processing of the call, in this case the SCCP, pass along or information request and information messages can be used. In the case where the connection is allowed, the destina- tion exchange will set up a connection to the called party. If a continuity check has to be performed on one or more of the circuits involved in a connection, setting up of the connection to the called party must be prevented until the continuity of such cir- cuits has been verified. 2.1.3 Calling party number The calling party number can either be included in the initial address message [SS 2.1.1.1 | ) and 2.1.2.1 | )] or requested by the destination exchange (see S 2.1.6). If the calling party number is required at the destination exchange but is not included in the initial address message, the destination exchange will analyze the protocol control indicator to determine if the request and response should be conducted by one of the procedures in S 3. The destina- tion exchange will investigate the presence/absence or the calling party number parameter to determine whether a request is useful or not. Further it may be necessary to withhold the sending of the address complete message until the calling party number has been successfully delivered. 2.1.4 Address complete message, connect message and call progress message 2.1.4.1 Return of address complete message from destination exchange An address complete message will be sent from the destination exchange as soon as it has been determined that the complete called party number has been received, or an indication received from the called party that an inband tone is being connected (for this case see SS 2.1.5 and 2.2.4). However there is no direct mapping from alerting, received from the access signalling system, to address complete in the network. In the case that the continuity check is performed the destination exchange will withhold sending the address complete message until a successful continuity indication has been received (see S 2.1.9). Address complete is sent from the destination exchange in the following conditions: 1) In the case where the terminating access is non ISDN the following action takes place at the destination exchange: a) In all cases an address complete message is sent as soon as it has been determined that the complete called party number has been received, and the destination exchange established that the subscriber is free. Indicators in the address complete message will be set to indicate: - call line status: "Subscriber free" - ISDN access indicator: "Non ISDN" b) In the case of a PBX an address complete message is sent as soon as it has been determined that the called party number has been received. Indicators in the address complete mes- sage will be set to indicate: - called line status: "No indication" - ISDN access indicator: "Non ISDN". 2) In the case where the terminating access is ISDN, the following conditions can apply: a) If an indication that the address is complete or no status indication has been received from the ISDN access prior to the destination exchange determining that the complete called party number has been received, the indicators in the address com- plete message will be set as follows: - called line status: "No indication" - ISDN access indicator: "ISDN". Note - In case a) the indication that the destination user is being alerted is transferred in a call progress message (see S 2.1.5). b) The destination exchange concludes from the receipt of an indication from the ISDN access that the complete called party number has been received. In this case the indicators in the address complete message will be set as follows: - called line status: "Subscriber free" - ISDN access indicator: "ISDN". 2.1.4.2 Return of connect message from the destination exchange If a connect indication is received from the ISDN access under the following conditions: - no alerting indication received from the ISDN access and - an address complete message has not yet been sent by the destination exchange, a connect message is sent by the destination exchange. This connect message signifies both address complete and answer conditions. Indicators in the connect message will indicate: - called line status: "Subscriber free" - ISDN access indicator: "ISDN". The destination exchange will through-connect before the con- nect message is sent. 2.1.4.3 Receipt of address complete message or connect mes- sage at an intermediate exchange Upon receipt of an address complete message an intermediate exchange will send the corresponding address complete message to the preceding exchange. If a connect message is received at an intermediate exchange instead of an address complete message, a connect message will be sent to the preceding exchange. 2.1.4.4 Receipt of address complete message or the connect message at the originating exchange a) When the originating exchange receives an address complete message the appropriate exchange functions take place. b) On receipt of an address complete message with the called line status indicator set to "subscriber free" an alert- ing indication is passed to the calling party if possible. c) On receipt of the address complete message the awaiting address complete timer (T7) is stopped and the awaiting answer timer (T9) is started. If timer (T9) expires the connection is released and an indication is sent to the calling subscriber. d) If the connect message is received then the appropriate exchange functions take place. The awaiting address complete timer (T7) is stopped (see S 2.1.7.2). 2.1.4.5 Through-connection and awaiting answer indication at the destination exchange The sending of the awaiting answer indication (e.g. ring tone) at the destination exchange depends on the type of call. On speech and 3.1 kHz calls and call to an analogue called party the awaiting answer indication is applied to the transmission path to the cal- ling party from the destination exchange on receipt of an alerting indication from the called party or from information contained within the destination exchange that the called party will not or is prohibited from providing inband tone. Regardless of whether tones are to be provided or not, the destination exchange will through-connect after the reception of the connection indication from the called party and before sending the answer/connect message to the preceding exchange. If the destination exchange does not send the awaiting answer indication because the destination user provides for the sending of tones, then the destination exchange will through-connect the transmission path in the backward direction on receipt of the pro- gress indication. The complete through-connection of the transmission path at answer is covered in S 2.1.7. 2.1.4.6 Address complete message with charging information The address complete message carries a charge indicator. 2.1.4.7 Address complete message with other information Additional information can be included in the address complete messages (e.g. related to supplementary services, see Recommendation Q.730). 2.1.4.8 Return of address complete message in interworking situations An address complete message will not be sent until the cross-office check is made, if applicable (see S 2.1.10). If the succeeding network does not provide electrical called-party's-line-condition indications the last Signalling System No. 7 exchange shall originate and send an address complete message when the end of address signalling has been determined: a) by receipt of an end-of-pulsing (ST) signal; or b) by receipt of the maximum number of digits used in the national numbering plan; or c) by analysis of the national (significant) number to indicate that a sufficient number of digits has been received to route the call to the called party; or d) by receipt of an end-of-selection signal from the succeeding network (e.g. number received signal in Signalling System No. 5); or e) exceptionally, if the succeeding network uses overlap signalling and number analysis is not possible, by observ- ing that timer (T1\d0) has elapsed since the last digit was received, and that no fresh information has been received; in such circumstances, transmission to the national network of the last digit received must be prevented until the end of the waiting period which causes an address complete message to be sent back- ward. In this way, it is ensured that no national answer signal can arrive before an address complete message has been sent. If in normal operation, a delay in the receipt of an address complete signal from the succeeding network is expected, the last common channel signalling exchange will originate and send an address complete message 15 to 20 seconds (timer (T1\d1)) after receiving the latest address message. The time-out condition is an upper limit considering the clauses of S 2.9.10.3 (20 to 30 seconds waiting for address complete message timer (T7) for outgoing inter- national exchanges in abnormal release conditions). 2.1.4.9 Return of sub-address information in address com- plete message, connect message or call progress message If sub-address information is received from the called access this information is passed unchanged to the originating exchange in the access transport parameter of the address complete message, connect message or call progress message. 2.1.5 Call progress The call progress message is sent (either before or after the address complete message) from an exchange in the backward direc- tion indicating that an event has occurred during call set-up which should be relayed to the calling party. 2.1.5.1 Return of call progress message from the destina- tion exchange The call progress message is sent from the destination exchange if the address complete message has been sent and subse- quently: - an indication is received that the called party is being alerted, the call progress message contains an event indicator that is set to "alerting" - a progress indication is received from the called party, the call progress message contains an event indicator that is set to "progress". If the indication received from the called party contains a "progress indication", this is carried by the call progress message in the access transport parameter (transported unchanged across the public network). The destination exchange may on receipt of the indication from the called party, that contains an appropriate progress indicator, through-connect the speech path, see S 2.1.4.5. In the case of call failure and the connection of a tone or announcement being returned before the address complete message has been returned, see S 2.2.4. 2.1.5.2 Action at an intermediate exchange On receipt of a call progress message an intermediate exchange will send the corresponding call progress message to the preceding exchange. 2.1.5.3 Actions at the originating exchange On receipt of a call progress message at the originating exchange, no state change occurs (i.e. the awaiting address com- plete or the awaiting answer timer are not stopped), and the appropriate indication is sent to the calling user. If the call progress message contained information carried in the access tran- sport parameter it is transferred unaltered into the indication returned to the calling user. 2.1.6 Information messages 2.1.6.1 Requesting information An information request message may be sent to any exchange in the forward (backward) call establishment direction after sending (receiving) an IAM during call set-up. 2.1.6.2 Sending information On sending an information request message a timer (T3\d3) is started. No second information request message may be sent in the same direction until a response information message is received. If the timer (T3\d3) expires before the response message is received, see S 2.10.7. The value of this timer (T3\d3) is 12-15 seconds to allow for a cascade of information request messages, as described in item ii). The response information message may be sent as fol- lows: i) if all the information requested is available locally, then an information message containing all the required information is sent in response; ii) if all the information is not available locally, but may be available remotely, than an information request message may be sent to a subsequent exchange in the connection in an attempt to extract the information not locally available. (This information request message may be delayed if one has already been sent and the response not yet received.) On receipt of a response, all the information necessary to respond to the original informa- tion message is sent in an information message; iii) if all the information is not available locally or remotely, then an information message containing only the available information is sent and the requested but not delivered information is indicated as "not available", using either the indication in the information indicator or an appropriate cod- ing in the requested parameter. 2.1.6.3 Sending unsolicited information Information that is available at an exchange and that does not correspond to information which can be or has been requested by an information request message, can be sent in the information message with the solicited information indicator set to signify that the message has been sent unsolicited. The unsolicited information message can be used only if the ISDN user part has been used all the way. It can be sent in any direction in any call state (except in the awaiting release com- plete state). Solicited and unsolicited information must not be sent in the same information message; if unsolicited information is to be sent at the same time together with solicited information, this has to be done in a separate message with the solicited information indi- cator set to "unsolicited". 2.1.6.4 Receiving an information message Upon receipt of an information message which does neither con- tain the requested information nor an indication that the requested information is not available, the actions taken will depend on whether the call can be progressed. 2.1.7 Answer message 2.1.7.1 Return of answer message from destination exchange When the called party answers, the destination exchange con- nects through the transmission path and the ringing tone is removed if applicable. An answer message to the preceding exchange is sent. If the destination exchange is the exchange controlling charging, then charging may begin. 2.1.7.2 Receipt of answer message at intermediate exchange Upon receipt of an answer message, an intermediate exchange sends the corresponding answer message to the preceding exchange and, if this is the exchange controlling charging, charging may begin, and timer (T9) is stopped. 2.1.7.3 Receipt of answer message at originating exchange When the originating exchange receives an answer message indi- cating the required connection has been completed, the transmission path is connected-through in the forward direction, if not already connected. The awaiting answer timer (T9) is stopped. If the ori- ginating exchange is the exchange controlling charging, charging may begin if applicable. The calling party is informed. 2.1.7.4 Return of answer from automatic terminals When connections are set-up to terminals having an automatic answer feature, the alerting indication may not be received from the called party. If a destination exchange receives an answer indication an answer message is sent provided that an address com- plete message has been sent, otherwise the connect message is sent. 2.1.7.5 Answer with charging information The answer message received from the destination exchange or from a succeeding network carries a charge indicator. 2.1.8 Continuity-check Because the signalling in Signalling System No. 7 does not pass over the circuit, facilities should be provided for making a continuity-check of the circuit in the circumstances described below. The application of the continuity-check depends on the type of the transmission system used for the circuit. For transmission systems having some inherent fault indication features giving an indication to the switching system in case of fault, a continuity-check is not required. However, a per call continuity-check may be needed on fully digital circuits when cir- cuits or bundles of circuits in primary multiplex groups are dropped and inserted en route between switches, and alarm indica- tions carried on bits of the primary multiplex frame structure are lost in passing through an intermediate transmission facility that does not relay them transparently. Typical, per call continuity-checks may be needed when the transmission link between switches contains a TDMA satellite system, a digital circuit multi- plication system or a digital access and cross connection system, where fault indications are lost (see Recommendation Q.33). When an initial address message is received with a request for a continuity-check relating to a digital circuit having inherent fault indication, one of the following actions is taken: either a) the continuity-check request is disre- garded; or b) a continuity-check loop is connected and the maintenance system is alerted. In this case the call may fail since no continuity signal may be received from the distant end. Note - The reception of such a request could only be caused by an abnormal condition such as administrative errors or the occurrence of signalling errors. When the circuit type is unknown to an SS No. 7 exchange, or in an application where both analogue and digital circuits may be served or when no inherent fault indication is available, a continuity-check loop should always be connected in the following case: i) when the exchange has the capability to process initial address messages with continuity-check request and such messages are received; ii) when continuity-check request messages are received. Means should be provided in SS No. 7 to detect circuit iden- tification code misunderstandings between SS No. 7 exchanges. For exchanges having both analogue and digital circuits served by SS No. 7, the continuity-check initiated by a continuity-check request message could be used to test for proper alignment of cir- cuit code identities. On those exchanges, reception of a continuity-check request message should always cause a loop to be attached to the circuit. Alternative methods for detection of circuit identity misunderstandings in exchanges with all digital circuits may be employed. The continuity-check is not intended to eliminate the need for routine testing of the transmission path. The continuity check of the circuit will be done, link-by-link, on a per call basis or by a statistical method prior to the commencement of conversation. Procedures and requirements are specified in Recommendation Q.724, S 7. The actions to be taken when pilot supervision is used are described in Recommendation Q.724, S 9. 2.1.9 Special procedures at an interworking point 2.1.9.1 Completion of transmission path at an interworking exchange In general, completion of the transmission path at an inter- working point should occur as soon as possible during the call set-up phase. The actual point of switch-through will vary depend- ing on the interworking signalling system, e.g. whether inband or outband signalling is used or whether a continuity-check procedure is applied. When interworking with other internationally specified signal- ling systems, the following rules on switch-through should be applied: H.T. [T1.764] ________________________________________________________________________________________________________________________________________________________________________________________ SS No. 7 SS No. 7 { When no continuity-check is to be made on the outgoing circuit, through-connection should occur after sending the initial address message. When continuity-check is to be made on the outgoing circuit, through-connection should occur after residual check tone has propagated through the return path of the circuit (see Recommendation Q.724, S 7.3). } ________________________________________________________________________________________________________________________________________________________________________________________ { SS No. 6 SS No. 7 .ta 3720u 4392u SS No. 5 SS No. 7 .ta 3720u 4392u R1 SS No. 7 .ta 3720u 4392u SS No. 7 SS No. 6 } { When no continuity-check is to be made on the outgoing circuit, through-connection can occur after sending the initial address message. When a continuity-check is to be made on the outgoing circuit, through-connection can occur after residual check tone has propagated through the return path of the circuit (see Recommendation Q.724, S 7.3). } ________________________________________________________________________________________________________________________________________________________________________________________ R2 SS No. 7 { Through-connection should occur after receipt of address complete. } ________________________________________________________________________________________________________________________________________________________________________________________ { SS No. 7 SS No. 5 .ta 3720u 4392u SS No. 7 R1 } { Through-connection can occur after sending ST (end of pulsing) signal and removal of a possible check loop. } ________________________________________________________________________________________________________________________________________________________________________________________ SS No. 7 R2 { Through-connection should occur after sending of address complete. } ________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [T1.764], p. When a continuity-check is made on the outgoing circuit, and early connection is made, there is a possibility that the calling party has its go and return paths temporarily looped (from the instant of through-connection to the instant of loop removal of the incoming end of the circuit). This problem can be prevented by using the optional single report continuity-check procedure given in Recommendation Q.724, S 7.3. 2.1.9.2 Alerting of called party If in an interworking situation a continuity-check has to be performed on one or more of the circuits involved in the connection preceding the interworking point, appropriate measures must be taken to prevent alerting of the called party until the continuity of such circuits has been verified. Interworking situations which could be discriminated are: a) SS No. 7 any non No. 7 signalling system. b) International SS No. 7 national SS No. 7 not performing continuity-check. For a) the last digit(s) of the national number have to be withheld in any (interworking) transit exchange or terminating exchange in case of DDI (direct dialling in) or the alerting of the called party is postponed in the terminating exchange in case of non DDI. For b) either the last digit(s) of the national number are withheld in the incoming international transit exchange, a transit exchange in the national network or the terminating exchange in case of DDI (direct dialling in) or the setting up of the connec- tion to the called party is postponed in the terminating exchange in case of non DDI. 2.1.10 Cross office check For digital exchanges, the requirements mentioned in Recommendation Q.543 shall be met. For other exchanges, Administra- tions shall ensure the reliability of a connection through a switching machine (cross-office check) either on a per call basis or by a statistical method. With either method, the probability of the connection being established with an unacceptable transmission quality should not exceed 0.00001 as the long-term average. 2.1.11 Charging procedures 2.1.11.1 Basic call charging Charging will normally begin when the exchange(s) controlling charging receives the answer or connect message from the network. Optionally an Administration may wish to begin charging prior to the receipt of the answer or connect message for national and/or international calls. 2.1.11.2 Network charging messages (national option) When the charging exchange does not have the capability to determine the charge rate for a particular call, charge information may be received during the call set-up. Also, charge rate informa- tion may be returned during call set-up, followed subsequently by further charge information messages during the conversation/data phase, should the original rate require to be changed during the call. 2.1.12 Forward transfer message The forward transfer message may be sent in telephony semi-automatic working in either of the following two cases: a) following a call switched automatically to a subscriber, or following a call established via a special operator, the controlling operator wishes to call in an assistance operator. On receipt of the forward transfer message at the incoming interna- tional exchange, an assistance operator is called in; b) following a call via codes 11 and 12, the con- trolling operator wishes to recall the incoming international exchange. Receipt of the forward transfer message at the incoming international exchange recalls the incoming operator on calls com- pleted via the operator positions at the exchange. 2.1.13 Transit network selection (national option) If transit network selection information is included in the set-up information from the calling party or is provided on a sub- scription basis, this information is carried in the transit network selection parameter, and is used for routing of the call, e.g. to a specific carrier. A sequence of transit networks may be specified by the calling party, in which case the transit network selection parameter is repeated in the order specified. 2.2 Unsuccessful call set-up If at any time in the call set-up the connection cannot be completed a release message is returned. This message contains the reason. 2.2.1 Actions at exchange initiating a release message The initiating exchange immediately starts the release of the switched path (if established). The exchange sends a release mes- sage to the preceding exchange and a timer (T1) is started to ensure that a release complete message is received from the preced- ing exchange within time T1[expiration of timer (T1) is covered in S 2.10.6]. 2.2.2 Actions at intermediate exchange On receipt of a release message from the succeeding exchange, an intermediate exchange: i) immediately start the release of the switched path; when the circuit is reselectable, a release complete message is returned to the succeeding exchange; ii) at the same time as the start of the release of the switched path, a release message is sent to the preceding exchange. A timer (T1) is started to ensure that a release complete message is received from the preceding exchange within time T1(expiration of this time is covered in S 2.10.6). 2.2.3 Actions at the controlling exchange (i.e. the exchange controlling the call) On receipt of a release message from the succeeding exchange, the controlling exchange starts the release of the switched path. In addition, the controlling exchange will: (if applicable) a) return an indication (in band or out band) to the calling party (see S 2.2.4); or b) attempt to re-route the call set-up; or c) initiate release procedures to the preceding exchange (as described in S 2.2.4). In case a) above an indication is carried in the call progress message or address complete message indicating in-band information is available, (see S 2.2.4). When the controlling exchange is ready for circuit re-selection, a release complete message is sent to the succeeding exchange. 2.2.4 Tones and announcements If a call set-up fails and an in-band tone or announcement has to be returned to the calling party from an exchange or called party, the exchange or user concerned connects the in-band tone to the transmission path. If an address complete message has been returned to the preceding exchange a call progress message indicating that in-band tone information is available, is returned to the preceding exchange (see S 2.1.5). If an address complete message has not been returned to the preceding exchange already, an address complete message, with the appropriate cause parameter and the "in-band information" indicator set in the optional backward call indicator, will be returned to the originating exchange. 2.3 Normal call release The release procedures are based on a two message (release, release complete) approach whereby the release message initiates release of the circuit switched connection. The same procedures are used in the network irrespective of whether they are initiated by the calling party, the called party or the network. The normal release procedure can be prevented by the network if this is required on a particular call (S 2.6). To satisfy the need for rapid transfer of release across the network, it is required that the circuit is selectable from the subsequent exchange within the mean cross-office transfer time, Tc\du, for simple messages as specified in Recommendation Q.766. 2.3.1 Release initiated by a calling party a) Actions at the originating exchange On receipt of a request to release the call from the cal- ling party, the originating exchange immediately starts the release of the switched path. A release message is sent to the succeeding exchange and a timer (T1) is started to ensure that a release com- plete message is received from the succeeding exchange within T1(expiration of this time is covered in S 2.10.6). b) Actions at an intermediate exchange On receipt of a release message from the preceding exchange, an intermediate exchange: i) immediately starts the release of the switched path; when the circuit is reselectable, a release complete message is returned to the preceding exchange; ii) at the same time as the start of the release of the switched path, sends a release message to the succeeding exchange. A timer (T1) is started to ensure that a release complete message is received from the succeeding exchange within time T1(expiration of this time is covered in S 2.10.6). c) Actions at the destination exchange On receipt of a release message from the preceding exchange, the destination exchange will start the release of the switched path. When the circuit is ready for reselection a release complete message is returned to the preceding exchange. d) Charging Charging is stopped upon receipt of the release message at the charging exchange or on receipt of a request to release the call from the calling party when the charging exchange is the ori- ginating local exchange. e) Collision of release messages In the case when two points in the connection both ini- tiate the release of a call, a release message may be received at an exchange from a succeeding or preceding exchange after the release of the switched path is initiated. In this case, the exchange will return a release complete message to the exchange from which the concerned release message was received. The release complete message will be sent when the circuit is ready for re-selection. 2.3.2 Release initiated by a called party The procedures in S 2.3.1 apply, except that the functions at the originating and destination exchanges are transposed. 2.3.3 Release initiated by the network The procedures in S 2.3.1 apply, except that they can be ini- tiated at any exchange (originating, destination or intermediate). 2.3.4 Storage and release of IAM information Each exchange of the connection shall store during the call set-up the information contained in the initial address message sent (the originating exchange) or received (intermediate or desti- nation exchange). The information to be stored includes all parame- ters in the IAM. The contents of the IAM information shall be updated, if the value of parameters change during the call set-up. The IAM information can be released from memory: a) in the originating exchange when the address complete message or connect message has been received and the cal- ling party does not subscribe to a supplementary service which would cause a new call set-up (e.g. call transfer). The release of the information when the calling party does subscribe to a supple- mentary service is covered in Recommendation Q.730; b) in the intermediate exchange when the address complete message or the connect message has been received; c) in the destination exchange when the address complete message or connect message has been sent and the called party does not subscribe to a supplementary service which would cause a new call set-up (e.g. call transfer). The release of the information when the called party does subscribe to a supplementary service is covered in Recommendation Q.730, and when the call is released earlier and no automatic repeat attempt is to be attempted. 2.4 Transfer of user-to-user information 2.4.1 Requirements for transfer of user-to-user data See Recommendation Q.730. 2.5 Suspend, resume 2.5.1 Suspend The suspend message indicates a temporary cessation of commun- ication without releasing the call. It can only be accepted during the conversation/data phase. A suspend message can be either gen- erated in response to a suspend request from the calling/called party or generated by the network in response to a clearback indi- cation from an interworking node or an on-hook condition from an analogue called (telephone) party. 2.5.1.1 Suspend initiated by a calling party A suspend message is generated in response to a suspend request from a calling party. a) Actions at originating exchange On receipt of a suspend request from the calling party, the originating exchange sends a suspend message to the succeeding exchange. b) Actions at an intermediate exchange On receipt of the suspend message from the peceding exchange the intermediate exchange sends a suspend message to the succeeding exchange. c) Actions at destination exchange On receipt of the suspend message from the preceding exchange, the destination exchange informs the called party that a suspend has been requested. d) Actions at the suspend request controlling exchange On receipt of the suspend request from a user or the suspend message, the controlling exchange starts a timer (T2) to ensure that a resume request or resume message is received within timer (T2). If the timer (T2) expires, the procedures in S 2.5.3 apply. 2.5.1.2 Suspend initiated by a called party The procedures in S 2.5.1.1 apply, except that the functions at the originating and destination exchanges are transposed. 2.5.1.3 Suspend initiated by the network A suspend message can be generated by the network in response to a clearback indication from an interworking node or an on-hook condition from an analogue called party. a) Action at the terminating exchange (destination) or an interworking exchange On receipt of an on-hook condition in the terminating exchange or a clearback signal at the interworking exchange, the exchange may send a suspend (network) message to the preceding exchange. b) Action at the intermediate exchange On receipt of a suspend message the exchange will send a suspend message to the preceding exchange. c) Action at the controlling exchange On receipt of the on-hook condition or clearback indica- tion or suspend message, the controlling exchange starts a timer (T6) to ensure that an off-hook condition, a re-answer indication, a resume (network) message or a release message is received. The value of this timer (T6) is covered in Recommendation Q.118. If the timer (T6) expires, the procedures in S 2.5.3 apply. 2.5.2 Resume A resume message indicates a request to recommence communica- tion. A request to release the call received from the calling or called party will override the suspend/resume sequence and the pro- cedures given in S 2.3 will be followed. 2.5.2.1 Resume initiated by a calling party Having initiated a suspend condition, a calling party may request a reconnection within timer T2. The procedures in S 2.5.1.1 items a), b) and c) apply except that the resume message replaces the suspend message. On receipt of the resume message, the control- ling exchange cancels the timer (T2). 2.5.2.2 Resume initiated by a called party The procedures in S 2.5.2.1 apply except that the functions at the originating and destination exchange are transposed. 2.5.2.3 Resume initiated by the network A resume message is initiated by the network, if a suspend message had previously been sent, in response to a re-answer indi- cation from an interworking node or an off-hook condition from an analogue called party. a) Action at the terminating exchange or interwork- ing exchange On receipt of a re-answer indication at the interworking exchange or an off-hook condition in the terminating exchange, the exchange may send a resume (network) message to the preceding exchange if a suspend (network) message had previously been sent. b) Actions of the intermediate exchange On receipt of a resume message the exchange will send a resume message to the preceding exchange. c) Action of the controlling exchange (i.e. exchange controlling the call) On receipt of the off-hook condition, re-answer signal, release message or resume message the controlling exchange stops the timer (T6) [started in S 2.5.1.3 c)]. 2.5.3 Expiration of timer (T [Mangled Text] If a request for reconnection or a resume message is not received within timer (T2) or timer (T6) covered in Recommendation Q.118 then the controlling exchange will initiate the release procedure outlined in S 2.3.3. 2.6 Delayed release (national option) The delayed release message is generated by the network in response to a request from the calling/called party to release the call if the network is applying a hold to the connection. The delayed released message can be sent in either direction. The local exchange receiving the release request sends a delayed release message. The connection is split, timer (T3) is started (to prevent network lock-up) and charging is stopped. At the other end of the connection, the delayed release message causes an indication to be sent to the called/calling party. Receipt of a connect or reconnection request from the called/calling party during the held state (after the delayed release message has been sent) will not cause the network to set up or resume the connection. When the hold condition is removed or the timer (T3) matures, the network generates the normal release sequence (S 2.3.3). 2.7 In-call modification At the start of the call, it is required to know whether the call is an alternate speech/64 kbit/s or alternate 64 kbit/s/speech unrestricted call request. If this is the case then the following procedures apply: Following call set-up the calling or called party may choose to modify the characteristics of the call during the conversation/data phase. During call set-up, the network will have chosen a suitable route (e.g. 64 kbit/s and ISDN user part signal- ling used all the way) according to information included in the initial address message. 2.7.1 Successful completion 2.7.1.1 Actions required at the exchange originating the call modification a) On receipt of a call modification request from the called/calling party, the initiating exchange checks that call modification is allowed and that the necessary resources are avail- able. If acceptable, the resources are reserved and the call modif- ication request message is sent. A timer (T4) is started to ensure that a call modification completed message is received within timer (T4). b) On receipt of the call modification complete message, the exchange modifies the resource and, when complete, informs the initiating party that the modification is complete. The timer (T4) is cancelled. 2.7.1.2 Actions required at intermediate exchanges a) On receipt of the call modification request mes- sage an intermediate exchange checks that the necessary resources are available. If acceptable, the resources are reserved and the call modification request message is passed on to the next exchange. b) On receipt of a call modification completed mes- sage, the intermediate exchange modifies the resource and, when complete, sends a call modification completed message to the next exchange. 2.7.1.3 Actions required at the local exchange receiving the request call for in-call modification a) On receipt of a call modification request mes- sage the exchange checks that call modification is allowed and that the necessary resources are available. If acceptable, the resources are reserved and the call modification indication is sent to the called/calling party. b) After the calling/called party has changed state and the modification in the local exchange has been completed, a call modification complete message is returned to the network. 2.7.2 Unsuccessful completion Basically three cases of unsuccessful completion can be iden- tified: i) If the in call modification request fails at an intermediate or at the remote exchange, i.e. because no resources are available or in call modification is not allowed, a call modif- ication reject message is returned in the direction of the exchange originating the in call modification request. The connection is maintained in its current mode. ii) If an intermediate exchange or the exchange initiating the call modification request fails to modify the characteristics of the transmission path, the connection is released. iii) If at the exchange initiating the call modifi- cation request timer (T4) expires, the connection is released. 2.7.2.1 Actions required at the local exchange initiating the call modification On receipt of the call modification reject message the exchange keeps the characteristics of the transmission path in the current mode, stops the timer (T4) and informs the initiating party. If resources have been reserved upon reception of the call modification request, they are released. 2.7.2.2 Actions required at an intermediate exchange If the in call modification request fails or if the call modification reject message is received by the intermediate exchange the characteristics of the transmission path are kept in the current mode and the call modification reject message is returned in the initiating direction. If resources have been reserved upon reception of the call modification request message, they are released. If an intermediate exchange, upon receipt of a call modifica- tion complete message, fails to change the characteristics of the transmission path, it initiates the release of the connection in both directions. 2.7.2.3 Action required at the remote local exchange receiving the call modification request from the network If at the remote local exchange the in call modification can- not be performed, the characteristics of the transmission path are kept in the current mode and the call modification reject message is returned to the network. If resources have been reserved upon reception of the call modification request message, they are released. 2.8 Echo control procedure 2.8.1 General The echo control procedure is used on a per call basis to con- vey information between exchange nodes about the demand and ability to insert echo control devices. The procedure is invoked when a call is to be routed on a connection for which echo control is necessary. It could be ini- tiated at the originating exchange or at an intermediate exchange. 2.8.2 Forward direction 2.8.2.1 Actions at the originating exchange If an originating exchange has sufficient information to determine that echo control is necessary for the outgoing circuit then: - an outgoing half echo control device is enabled; and - the echo control device indicator of the nature of connection indicators parameter field in the IAM is set. 2.8.2.2 Actions at an intermediate exchange If an intermediate exchange has sufficient information to determine that echo control is required for the outgoing circuit then one of the following actions can occur: a) When the nature of connection indicators param- eter field in the IAM indicates that an echo control device is already included: - no change to the nature of connection indicators parameter field in the IAM is made; - an incoming half echo control device is reserved; and - any outgoing half echo control device is dis- abled. b) When the nature of connection indicators param- eters in the IAM does not indicate that an echo control device is already included: - an outgoing half echo control device is enabled; and - the echo control device indicator in the nature of connection indicators parameter field is set. If the intermediate exchange has sufficient information to determine that echo control is not required for the outgoing cir- cuit then one of the following actions can occur: a) When the nature of connection indicators parameter field in the IAM indicates that an echo control device is already included: - no change to the nature of connection indicators parameter field in the IAM is made; and - an incoming half echo control device is reserved. b) When the nature of connection indicator parame- ter field in the IAM does not indicate that an echo control device is already included: - no additional action is required. 2.8.2.3 Actions at the destination exchange See S 2.8.3.1 below. 2.8.3 Backward direction 2.8.3.1 Actions at the destination exchange Upon the receipt of an IAM with the indication "outgoing half echo control device included" in the nature of connection indica- tors parameter field, the following action is taken: - an incoming half echo control device is enabled; and - the echo control device indicator of the backward call indicators parameter field in the first backward message (i.e. ACM or connect or call progress) is set. If the destination exchange is unable to include an incoming half echo control device, the information is conveyed to the preceding exchange by an echo control device indicator in the nature of connection indicators field not being set in the first backward message. 2.8.3.2 Actions at an intermediate exchange Upon receipt of the first backward message (i.e. ACM or con- nect or call progress) in response to an IAM with echo control indication, then one of the following actions can occur: a) When the backward call indicators parameter field indicates that an incoming half echo control device is not already included: - the reserved incoming half echo control device is included; and - the echo control device indicator in the back- ward call indicators parameter field is set. b) When the backward call indicators parameter field indicates that an incoming half echo control device is already included: - the reserved incoming half echo control is released; and - no change to the backward call indicators parame- ter field in the backward message is made. 2.8.3.3 Actions at the originating exchange No additional action is required. 2.9 Network features 2.9.1 Automatic repeat attempt Automatic repeat attempt, as defined in Recommendation Q.12, is provided in Signalling System No. 7. An automatic repeat attempt will be made (up to the point when the initial address message information is released, see S 2.3.4): i) on detection of dual seizure (at the non-control exchange) (see S 2.10.1.4); ii) on receipt of the blocking message after send- ing an address message and before any backward message has been received (see S 2.9.2); iii) on receipt of a reset circuit message after sending an address message and before a backward message has been received [see S 2.10.3.1 e)]; iv) on failure of continuity-check, when a con- tinuity check is performed; v) on receipt of an unreasonable message during call set up (see S 2.10.5). 2.9.2 Blocking and unblocking of circuits and circuit groups The blocking (unblocking) message and the circuit group block- ing (unblocking) message are provided to permit the switching equipment or maintenance system to remove from (and return to) traffic the distant terminal(s) of a circuit or group of circuits because of a fault or to permit testing. Since the circuits served by the ISDN user part have both-way capability, the blocking message or circuit group blocking message can be originated by either exchange. The receipt of a blocking message or a circuit group blocking message will have the effect of prohibiting non test calls on the relevant circuit(s) outgoing from the exchange until an unblocking message or an appropriate circuit group unblocking message is received, but will not prohibit test calls incoming to that exchange. An acknowledgement sequence is always required for the blocking and unblocking message as well as for the circuit group blocking message and circuit group unblocking messages using the blocking acknowledgement message, the unblocking acknowledgement message, the appropriate circuit group blocking acknowledgement messages and the appropriate circuit group unblock- ing acknowledgement message respectively. The acknowledgement is not sent until the appropriate action - either blocking or unblocking - has been taken. The release message should not over- ride a blocking message and return circuits to service which might be faulty. The blocked circuit(s) will be returned to service on transmission of the unblocking acknowledgement message or the appropriate circuit group unblocking acknowledgement message at one exchange and on receipt of the unblocking acknowledgement message or the appropriate circuit group unblocking acknowledgement message at the other exchange. 2.9.2.1 Other actions on receipt of a blocking message In the event of a blocking message being received, after an initial address message has been sent in the opposite direction on that circuit, and before a backward message relating to that call has been received, an automatic repeat attempt will be made on another circuit. The exchange receiving the blocking message releases the original call attempt in the normal manner after send- ing the blocking acknowledgement message and will not seize that circuit for subsequent calls. If the blocking message is received: - after an initial address message has been sent for that circuit in the opposite direction and after at least one backward message relating to that call has been received, or - after an intial address message has been received for that circuit beforehand, the exchange will not seize that circuit for subsequent calls. The fact that the circuit is engaged on a call will not delay transmission of the blocking (unblocking) acknowledgement message. If a blocking message is sent and subsequently an initial address message is received in the opposite direction, the follow- ing action is taken: - for test calls, the call should be accepted, if possible. In the case where the test call cannot be accepted, the blocking message must be returned; - for calls other than test calls, the blocking message must be returned and the initial address message discarded. When a circuit is blocked by use of the blocking message the maintenance system should be informed at both ends of the circuit. 2.9.2.2 Circuit group blocking and unblocking messages The following circuit group blocking (unblocking) messages and their corresponding acknowledgement messages are provided: - maintenance oriented circuit group blocking (unblocking) message; - hardware failure oriented circuit group blocking (unblocking) message; The circuits to be blocked (unblocked) are indicated in the status field. The maximum number of circuits to be blocked (unblocked) with one circuit group blocking (unblocking) message is limited to 32. A received circuit group blocking (unblocking) acknowledgement message has to match in the parameter value of the circuit identif- ication code, the circuit group supervision message type indicator, and the range field (see Recommendation Q.763) with the previously sent group blocking (unblocking) message in order to be considered a valid acknowledgement. A circuit is controlled by the ISND user part if it can be used by the ISDN user part as a circuit switched bearer. Hence, time slots in a digital path that are used for synchronisation (e.g. time slot 0 in a 2048 kbit/s digital path) or as signalling channels are not circuits whose control is allocated to the ISDN user part. Some of the circuit identification code values covered by the range field of a circuit group blocking (unblocking acknowledge- ment) message may not be allocated to any circuit. Then the corresponding status bits in the status field are set to 0. This is not allowed for the circuit identification code values related to status bits being set to 1. Those circuit identification code values must always be allocated to circuits whose control is allo- cated to the ISDN user part. In particular the circuit identifica- tion code value indicated in the label of a message must be allo- cated to a circuit. The maintenance oriented circuit group blocking (unblocking) procedures set (remove) the same blocking states as the blocking (unblocking) procedures. This means that a blocking state set by a maintenance oriented circuit group blocking message or indicated as blocked for maintenance purposes in the status field of a circuit group reset acknowledgement message can be removed by an unblocking message. Similarly, a blocking state set by a blocking message can be removed by a maintenance oriented circuit group unblocking mes- sage. The maintenance blocked state set by maintenance oriented cir- cuit group blocking message, by a status indicator in a circuit group reset acknowledgement message or a blocking message cannot be removed by a hardware oriented circuit group unblocking message. The range of circuits to be blocked (unblocked) is indicated in the range field. Those circuits within the range that have to be blocked (unblocked) are indicated in the status field. The same rule applies to the acknowledgements. For the circuits blocked for maintenance reasons the same con- ditions apply and the same actions have to be taken as described in S 2.9.2.1. For the circuits seized by ongoing calls or call attempts and blocked for reasons of harware failure the following actions will be taken: - all interconnected circuits have to be released by the appropriate messages; - the affected circuits are set to the condition "idle hardware blocked" without any exchange of release messages. The fact that a circuit is engaged on a call will not delay the transmission of the corresponding circuit group blocking (unblocking) acknowledgement message. The hardware blocked state can only be removed by a hardware failure oriented circuit group unblocking message. For all instances of circuit group blocking the maintenance system should be notified at both ends of the circuit(s). 2.9.2.3 Abnormal blocking and circuit group blocking pro- cedures The following procedures are designed to cover abnormal cases which may occur in the circuit group blocking/unblocking pro- cedures. i) If a circuit group blocking message is received relating to remotely blocked circuits then blocking acknowledgement indications for those circuits are given in the status field of the corresponding circuit group blocking acknowledgement message which will be sent in response. ii) If a circuit group un unblocking message is received relating to circuits which are not in the state remotely blocked, then unblocking acknowledgement indications for those cir- cuits are given in the status field of the corresponding circuit group unblocking acknowledgement message which will be sent in response. iii) When an exchange upon receipt of a circuit group blocking (unblocking) message is not able to give an appropriate blocking (unblocking) acknowledgement indication for each circuit identification code (e.g. because that/those circuit identification code(s) is(are) not allocated to any circuit at the receiving exchange) for which also a blocking (unblocking) indica- tion is given in the status field of the received group blocking (unblocking) message, then no blocking (unblocking) acknowledgement indication relating to that/those circuit identification code(s) will be given in the status field of the corresponding circuit group blocking (unblocking) acknowledgement message which will be sent in response. iv) If a circuit group blocking acknowledgement message in response to a circuit group blocking message is received containing in the status field the indications no blocking aknowledgement for the circuits which are to be blocked due to the previously sent circuit group blocking message, then (a) circuit group blocking message(s) will be repeated for the circuits con- cerned (see S 2.10.4). The same rule applies to the unblocking pro- cedures. v) If a circuit group blocking acknowledgement mes- sage in response to a circuit group blocking message is received containing in the status field blocking acknowledgement indications for the circuits which are not to be blocked due to the previously sent circuit group blocking message and are not marked locally blocked, then a circuit group unblocking message will be sent for the circuits concerned. iv) If a circuit group unblocking acknowledgement message in response to a group unblocking message is received con- taining in the status field unblocking acknowledgement indications for circuits which are not to be unblocked due to the previously sent circuit group unblocking message and have to remain marked locally blocked, then a circuit group blocking message will be sent for the circuits concerned. vii) If a circuit group blocking acknowledgment message which is not expected as an acknowledgent for any circuit group blocking message is received: - relating to circuits which all are in the status locally blocked the received circuit group blocking acknowledgement will be discarded; - relating to circuits part or all of which are not in the status locally blocked then a circuit group unblocking mes- sage will be sent for the relevant circuits. viii) If a circuit group unblocking acknowledgement message which is not expected as an acknowledgement for any circuit group unblocking message is received: - relating to circuits none of which is in the status locally blocked then the circuit group unblocking ack- nowledgement message will be discarded; - relating to circuits part or all of which are locally blocked then a circuit group blocking message will be sent for the relevant circuits. ix) If a circuit group blocking (unblocking) mes- sage or a circuit group blocking (unblocking) acknowledgement mes- sage refers to status changes for more than 32 circuits the receiv- ing exchange may discard that message. x) If a blocking message is received for a blocked circuit, a blocking acknowledgement message will be sent. xi) If an unblocking message is received for an unblocked circuit, an unblocking acknowledgement message will be sent. xii) If a blocking acknowledgement message, which is not expected as an acknowledgement for a blocking message, is received: - relating to a circuit which is locally blocked, the blocking acknowledgement message is discarded; - relating to a circuit which is not locally blocked, then an unblocking message will be sent; xiii) If an unblocking acknowledgement message, which is not an expected response to an unblocking message, is received: - relating to a circuit which is not locally blocked, the received unblocking acknowledgement message is dis- carded; - relating to a circuit which is locally blocked then a blocking message will be sent. xiv) If a non test initial address message is received on a remotely blocked circuit, the remotely blocked state of the circuit is removed and the initial address message is pro- cessed normally unless the circuit is also locally blocked in which case the initial address message is discarded. This applies to the blocking state whether maintenance, hardware or both. However it should not be the preferred method of unblocking a circuit. 2.9.3 Circuit group query 2.9.3.1 General The circuit group query test allows an exchange to audit the state of a circuit on a demand or routine basis. The value N of the range field of the circuit group query mes- sage, including N=0 for a single circuit, indicates the range to be tested. The maximum value of N is 31. If that value is exceeded the circuit group query message is discarded. 2.9.3.2 Interpretation of circuit states For the purposes of circuit query procedures, there are states which are classified into four major categories, as follows: 1) unequipped and transient conditions, 2) call processing states, 3) maintenance blocking states, 4) hardware blocking states. The two states "unequipped" and "transient" do not overlap with other states. Call processing states include: 1) idle, 2) circuit incoming busy, 3) circuit outgoing busy. Maintenance blocking states include: 1) unblocked, 2) remotely blocked, 3) locally blocked, 4) locally and remotely blocked. Hardware blocking states include: 1) unblocked, 2) remotely blocked, 3) locally blocked, 4) locally and remotely blocked. A circuit is "unequipped" if the circuit is not available for ISDN user part. Call processing or maintenance action cannot be performed on it. This is a unique state and will not overlap with any other state. The "transient" state refers to any transient call processing or maintenance states. Call processing is in a transient state a) after having sent an initial address message and waiting for the first backward message (whether a suspended call is in a transient state in the context of circuit group query is for further consideration), or b) after having sent a release message and waiting for the release complete message. Transient maintenance states are those, where the exchange after having sent a (group) (un)blocking message is awaiting the proper (group) (un)blocking acknowledgement message from the remote exchange. The circuit state is also considered transient as long as a circuit (group) reset message has not been acknowledged. The "idle" state is a call-processing state of an equipped, non-busy circuit. The "circuit incoming busy" or "circuit outgoing busy" refers to a stable call processing state. The hardware or maintenance "remotely blocked" state refers to the state marked by the exchange when the far-end exchange ini- tiates blocking. The maintenance blocking state can co-exist with "idle", "circuit incoming busy", or "circuit outgoing busy" state. The hardware blocking state can only co-exist with the "idle" call processing state, as calls are immediately released when hardware blocking is invoked. The hardware or maintenance "locally blocked" state refers to the state marked by the exchange when it initiated blocking to the far-end exchange and the proper acknowledgement was received. The maintenance blocking state can co-exist with "idle", "circuit incoming busy", or "circuit outgoing busy" state. The hardware blocking state can only co-exist with the "idle" call processing state, as calls are immediately released when hardware blocking is invoked. To initiate the circuit group query procedure, the sending exchange sends a circuit group query message indicating in the routing label and range field those circuits to be audited. If no response to the circuit group query message is received before timer (T3\d4 12-15 seconds) expires, maintenance systems should be informed. The receiving exchange will process the circuit group query message, and return a circuit group query response message setting the circuit state indicators to the state of the circuits being audited. If this circuit group procedure uncovers discrepancies in the state of a circuit as perceived at the two ends. The action to be taken in order to align the two views are for further study. 2.10 Abnormal conditions 2.10.1 Dual seizure Because Signalling System No. 7 circuits have the capability of bothway operation, it is possible that the two exchanges will attempt to seize the same circuit at approximately the same time. 2.10.1.1 Unguarded interval The exchange must detect dual seizure and take action as defined in S 2.10.1.4. 2.10.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. 2.10.1.3 Preventive action Different methods for circuit selection can be envisaged to minimise the occurrence of dual seizure. In the following, two methods are described. 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. Method 1 An opposite order of selection is used at each exchange of a bothway circuit group. Method 2 Each exchange of a bothway circuit group has priority access to the group of circuits which it is controlling (see S 2.10.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 bothway circuit group has non-priority access to the group of cir- cuits 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. For call control purposes a bothway circuit group can be sub- divided into subgroups in an exchange. It is necessary to take preventive action in cases where Sig- nalling System No. 7 uses a signalling data link with long propaga- tion time. 2.10.1.4 Action to be taken on detection of dual seizures Each exchange will control one half of the circuits in a both- way circuit group. On detection of a dual seizure, the call being processed by the control exchange for that circuit will be com- pleted and the received initial address message will be disre- garded. Under these conditions, the call being processed by the con- trol 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. For the purpose of resolution of dual seizure on bothway cir- cuits, the exchange with the higher signalling point code will con- trol all even-numbered circuits (circuit identification code) and the other exchange the odd-numbered circuits. The designation of control may also be used for maintenance system purposes. 2.10.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 tansmission systems are detected, the switching system should inhibit selection of the circuits concerned for the period the fault conditions per- sist. 2.10.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.10.3.1 Reset circuit message If only a few circuits are concerned a reset circuit message should be sent for each affected circuit. On receipt of a reset circuit message the receiving (unaf- fected) exchange will: 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 com- plete 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 pro- gress, 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 S 2.10.4 should be followed; d) if it has previously received a blocking mes- sage, 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. The circuit should be restored to the idle state; g) clear any interconnected circuits by the appropriate method (e.g. release). The affected exchange will then reconstruct its memory accord- ing 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 4-15 seconds, the reset circuit message should be repeated. If an acknowledgement for the message is not received within 1 minute after the initial reset circuit message, the maintenance system should be notified. However, the sending of the reset circuit message should continue at 1 minute intervals until maintenance intervention occurs. 2.10.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: a) restore the circuits to the idle state; 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 acknowledge- ment 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 ack- nowledgement message; f ) appropriate messages should be sent on inter- connected circuits to release them. The affected exchange will then reconstruct its memory accord- ing 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 4-15 seconds the circuit group reset message should be repeated. If an acknowledgement for the circuit group reset mes- sage is not received within 1 minute after sending the initial cir- cuit group reset message the maintenance system should be notified. However, the sending of the circuit group reset message should con- tinue at 1 minute intervals until maintenance intervention occurs. A correct acknowledgement should match the original circuit group reset message in range and circuit identification code indi- cated in the routing label. The circuit identification code in the routing 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-UP. 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-UP. 2.10.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 mes- sage 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-UP, the message is discarded. 2.10.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 4-15 seconds (T1\d2). (See S 2.9.2). If the appropriate acknowledgement is not received within a period of one minute (T2\d0) after sending the initial blocking (unblocking) message or group blocking (unblocking) message, the maintenance system should be alerted, the repetition of the block- ing (unblocking) message or circuit group blocking (unblocking) message should be continued at one minute intervals until mainte- nance intervention occurs and the circuit(s) taken out of (returned to) service as appropriate. 2.10.5 Receipt of unreasonable and unrecognized signalling information messages The message transfer part of the signalling system will avoid missequencing, or double delivery, of messages with a high relia- bility (Recommendation Q.706, S 2). However, undetected errors at the signalling link level and exchange malfunctions may produce signalling information messages that are either ambiguous or inap- propriate. The procedures listed below do not include the procedures for the blocking, circuit group blocking and the circuit group reset; these are covered in SS 2.9.2.3 and 2.10.3.3 respectively. 2.10.5.1 Handling of unexpected messages An unexpected message is one which is recognized and valid but has been received in the wrong phase 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 mes- sage; b) if a release complete message is received relat- ing 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 (the possibility of maintaining the connection is for further study); d) if other unreasonable signalling information is received, the following actions will be undertaken: - if the circuit is idle, the reset circuit message is sent; - if the circuit has been seized by a call, after receipt of a backward message required for the call set-up, the unreasonable signalling information is discarded; - if the circuit has been seized by a call, before receipt of a backward message required for the call set-up, the reset circuit message is sent. If the circuit is seized by an incoming call, the call will be released. If the circuit is seized by an outgoing call, an automatic repeat attempt is provided on another circuit; e) if unreasonable signalling information caused by conflicting code point values in the protocol control indicator as specified in Recommendation Q.763 is received in a backwards call set-up message, and if the conflicting conditions can be reconciled by assuming lower network capability in the affected parameter, the call should be allowed to continue if the service requirements for the call can be satisfied. Except in certain cases (see S 2.10.1) any other unexpected messages received will be discarded. If the discarding of the sig- nalling information prevents a call from being completed, that call will eventually be released by the expiry of a time out. 2.10.5.2 General requirements on receipt of unrecognized signalling information messages and parameters Normally an exchange knows the signalling system or version of a signalling system to be used to its adjacent exchanges. However, in certain circumstances (e.g. upgrading of a signalling system in the network) it may happen that an exchange receives unrecognized information, i.e. messages or parameters or parameter values. No distinction is being made between unrecognized and unimplemented functions. The procedure to be used on receipt of unrecognized informa- tion, may use one of the following messages: - confusion, - release, - release complete, - facility reject. It should be noted that the use of the confusion message is mainly to facilitate interworking with subsequent issues of the ISDN user part protocol. In these cases the message will include one of the following cause values with a diagnostic field contain- ing either the unrecognized message type code or the unrecognized parameter name code (this information will be returned as soon as possible): - unrecognized message, - unrecognized parameter passed on (see Note), - unrecognized parameter discarded (see Note). Note - In a confusion message these parameters are always followed by the parameter name code in the diagnostic field. The procedures are based on the following assumptions: - Signalling for a facility completely provided between the originating and destination local exchanges will util- ise one of the end-to-end methods defined in S 3, i.e. such facili- ties do not have to be supported by transit exchanges. - As a minimum, all implementations must recognize all messages specified in Table 1/Q.764. - If an exchange receives a confusion, release, release complete or facility reject message indicating an unrecog- nized message parameter or parameter value received it assumes interworking with an exchange at a different functional level. - Unrecognized parameters only refer to optional parameters since mandatory parameters will always be recognized by their location in a message. Action taken on receipt of these messages, will depend on the call state and the affected service. The default action taken on receipt of a confusion message is to discard the message without disrupting normal call processing. In addition, if the cause received indicates discarded information and that information is important, the call may be released with a release message with the cause "normal, unspecified". The actions taken at an intermediate node, e.g. transit exchange on receipt of a confusion message will be dependent on the call state. If an intermediate node, e.g. transit exchange, does not have the capability to take action on receipt of a facility reject mes- sage, it should pass the message transparently to the preceding or succeeding exchange. Action taken on receipt of a release complete message with cause indicating unrecognized information may be as for the normal procedures. H.T. [T2.764] TABLE 1/Q.764 Minimum messages recognized __________________________________________ Address complete Answer Blocking Blocking acknowledgement Call progress Circuit group blocking { Circuit group blocking acknowledgement } Circuit group reset { Circuit group reset acknowledgement } Circuit group unblocking { Circuit group unblocking acknowledgement } Connect Continuity Confusion Facility reject Facility request Forward transfer Information Information request Initial address Release Release complete Reset circuit Resume Subsequent address Suspend Unblocking Unblocking acknowledgement __________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T2.764], p. 2.10.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 message. a) Unrecognized mesages If an unrecognized message is received at an exchange, the message is discarded and a confusion message returned. The confu- sion message will include the cause value "unrecognized message" followed by a diagnostic field containing the message type code. Note - All messages not included in Table 1/Q.764 may be regarded as unrecognized. As a minimum all implementations must recognize all messages specified in Table 1/Q.764. b) Unrecognized parameters If an exchange receives and detects an unrecognized param- eter the actions taken will be dependent on whether the call can be progressed or not. If the call cannot be processed a release message is sent containing the cause "unrecognized parameter discarded" followed by the parameter name code in the diagnostic field. If the call can be progressed, the call is processed and the message is sent to the succeeding/preceding exchange. The unrecognized parameter may be either passed on or discarded. If the unrecognized parameter is discarded a confusion message is sent to the exchange from which the unrecognized parame- ter was received. The confusion message contains the cause "unrecognized parameter discarded". If the unrecognized parameter is passed on, a confusion message may be sent to the exchange from which the unrecognized parameter was received. If a facility request message is received with unrecognized parameters the message is discarded and a facility reject message is returned including the cause "unrecognized parameter discarded" followed by the parameter name code in the diagnostic field. If a release message is received with an unrecognized parameter, a release complete message is returned including the cause "unrecognized parameter passed on" followed by the parameter name code in the diagnostic field. c) Unrecognized parameter values If an exchange receives and detects a recognized parameter but the contents are unrecognized, then the actions taken are as defined below: i) Unrecognized mandatory parameter values If an exchange receives and detects an unrecognized manda- tory parameter value, the actions taken will be dependent on whether the call can be progressed or not. If the call can be progressed, the unrecognized mandatory parameter value shall be passed on unmodified. A confusion message with the cause "unrecognized parameter passed on" is sent to the exchange from which the unrecognized mandatory parameter value was received. If the call cannot be progressed or the unrecognized manda- tory parameter value cannot be passed unmodified, a release message with the cause "unrecognized parameter discarded" followed by the parameter name in the diagnostic field is returned. If a facility request message is received with an unrecog- nized mandatory parameter value(s) the message is discarded and a facility reject message is returned including the cause "unrecog- nized parameter discarded" followed by the parameter name code in the diagnostic field. If a release message is received with an unrecognized man- datory parameter value, a release complete message is returned including the cause "unrecognized parameter passed on" followed by the parameter name code in the diagnostic field. ii) Unrecognized optional parameter values If an exchange receives and detects an unrecognized optional parameter value, the actions taken will be dependent on whether the call can be progressed or not. If the call can be progressed, the unrecognized optional parameter value may be passed on unmodified or discarded. If the unrecognized optional parameter value has been passed on unmodi- fied, a confusion message with the cause "unrecognized parameter passed on" may be sent to the exchange from which the unrecognized optional parameter value was received. If the unrecognized parame- ter value has been discarded, a confusion message shall be returned. If the call cannot be progressed, a release message with the cause "unrecognized parameter discarded" followed by the param- eter name in the diagnostic field shall be returned. If a facility request message is received with an unrecog- nized optional parameter value(s) the message is discarded and a facility reject message is returned including the clause "unrecog- nized parameter discarded" followed by the parameter name code in the diagnostic field. If a release message is received with an unrecognized optional parameter value, a release complete message is returned including the cause "unrecognized parameter passed on" followed by the parameter name code in the diagnostic field. 2.10.6 Failure to receive a "release complete" message - time T1 and T5 If a release complete message is not received in response to a release message before time (T1) the exchange will retransmit the release message. On retransmitting the initial release message, a one minute timer (T5) is started. If no release complete message is received on the expiry of this timer (T5), the exchange shall: i) send a reset circuit message; ii) alert the maintenance system; iii) remove the circuit from service; iv) continue the sending of the reset circuit mes- sage at 1 minute intervals until maintenance action occurs. 2.10.7 Failure to receive a response to an information request message If a response is not received in response to an information request message before timer (T2) expires, the exchange will release the connection and the maintenance system may be informed. 2.10.8 Other failure conditions 2.10.8.1 Inability to release in response to a release mes- sage 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.10.8.2 Call-failure The call-failure indication is sent in a release message (S 2.2) whenever a call attempt fails and other specific signals do not apply. Reception of the release message at any Signlalling 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.10.8.3 Abnormal release conditions If the conditions for normal release as covered in S 2.3 are not fulfilled, release will take place under the following condi- tions: a) Outgoing international or national controlling exchange The exchange shall: - release all equipment and the connection on failure to meet the conditions for normal release of address and routing 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 (T6) specified in Recommendation Q.118 after the receipt of the address complete message. b) Incoming international exchange 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. The procedures for the release message are detailed in S 2.2.2. c) Transit exchange 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 S 2.3 before 20-30 seconds after sending the latest address message; The procedures for the release message are detailed in S 2.2.2. 2.10.8.4 If messages are lost during an end-to-end transfer, appropriate actions will be taken according to the type of end-to-end technique being used. 2.10.8.5 For calls involving the SCCP, expiration of the call supervision timer (concerned with call set-up) will result in the SCCP being notified of an error condition. 2.10.9 Temporary Trunk Blocking (TTB) (national use) TTB is essentially a means of blocking circuits, for a predetermined period, on a route or part of route, 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. 2.10.10 Temporary trunk blocking before release of call (use of a discrete overload message) 2.10.10.1 Characteristics When load control is invoked IAMs associated with non-priority calls received on the circuits concerned are "backed-off" by return of the overload message in response to the IAM. Release of the cir- cuit is then delayed by the unaffected node for a period, e.g. 2 minutes, after which the circuit is cleared by normal release procedures. Calls backed-off by overload messages may be processed on alternative routes, if available, by-passing the affected nodes; if not they are released in the backward direction with reason (net- work) congestion. Initial address messages marked as priority are not subject to the overload procedure; they are accepted by the affected node and processed as normal. During the overload time-out period the circuit concerned is not available for traffic from the affected node to the unaffected node. Recognition of the overload situation does not involve the examination of existing messages for detection of an optional TTB parameter. 2.10.10.2 Procedures a) Non priority call set-up to an exchange subject to load control i) Actions at originating exchange 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 IAM. ii) Actions at an intermediate or terminating exchange When an IAM is received by an exchange which is subject to load control and the calling party category parameter does not indicate a priority call the IAM is not processed and an overload message is returned to the preceding exchange. iii) Actions on receipt of the overload message At an originating, or intermediate exchange receipt of the overload message shall cause the following actions: - A timer (T overload) is started, provisional value 2 minutes. On expiry of the timer the release procedure shall be initiated of the circuit concerned. - The call attempt will be continued on an alter- native route if available. If not the call will be released in the backward direction with cause "congestion". b) Priority call set-up to an exchange subject to load con- trol i) Actions at originating exchange In an originating exchange, calls originating from prior- ity class lines will set the calling party category parameter field to "subscriber with priority" in the outgoing IAM. ii) Actions at intermediate or terminating exchange At an intermediate or terminating exchange where load con- trol has been invoked, the priority call will override the load control and the call will continue in its attempt to be set up. 2.11 ISDN user part signalling congestion control 2.11.1 General On receipt of congestion indication primitives (see also Recommendation Q.704 S 11.2.3) the ISDN user part should reduce traffic load (e.g. call attempts) into the affected direction in several steps. 2.11.2 Procedures When the first congestion indication primitive is received by the ISDN user part, the traffic load into the affected direction is reduced by one step. At the same time two timers T2\d9and T3\d0are started. During T2\d9all received congestion indication primitives for the same direction are ignored in order not to reduce traffic too rapidly. Reception of a congestion indication primitive after the expiry of T2\d9, but still during T3\d0, will decrease the traffic load by one more step and restart T2\d9and T3\d0. This stepwise reduction of the ISDN user part signalling traffic is con- tinued until maximum reduction is obtained by arriving at the last step. If T3\d0expires (i.e. no congestion indication primitives having been received during the T3\d0period) traffic will be increased by one step and T3\d0will be restarted unless full traffic load has been resumed. Timers T2\d9and T3\d0have the following values: T2\d9 = 300-600 ms, T3\d0 = 5-10 s. The number of steps of traffic reduction and the type and/or amount of increase/decrease of traffic load at the various steps are considered to be an implementation matter. 2.12 Automatic congestion control Automatic Congestion Control (ACC) is used when an exchange is in an overload condition (see also Recommendation Q.542). Two lev- els of congestion are distinguished, a less severe congestion threshold (congestion level 1) and a more severe congestion thres- hold (congestion level 2). If either of the two congestion thresholds are reached, an automatic congestion level parameter is added to all release mes- sages generated by the exchange. This parameter indicates the level of congestion (congestion level 1 or 2) to the adjacent exchanges. The adjacent exchanges, when receiving a release message containing an automatic congestion level parameter should reduce their traffic to the overload affected exchange. If the overloaded exchange returns to a normal traffic load it will cease including automatic congestion level parameters in release messages. The adjacent exchanges then, after a predetermined time, automatically return to their normal status. 2.12.1 Receipt of a release message containing an automatic congestion level parameter When an exchange receives a release message containing an automatic congestion level parameter the ISDN user part should pass the appropriate information to the signalling system independent network management/overload control function within the exchange. This information consists of the received congestion level informa- tion and the circuit identification to which the release message applies. ACC actions are applicable only at exchanges adjacent to the congested exchange. Therefore, an exchange that receives a release message containing an automatic congestion level parameter should discard that parameter after notifying the network management/overload control function. 2.12.2 Actions taken during overload Whenever an exchange is in an overload state (congestion level 1 or 2), the signalling system independent network management/overload control function will direct the ISDN user part to include an automatic congestion level parameter in every release message transmitted by the exchange. The network management/overload control function will indicate which congestion level (1 or 2) to code in the automatic congestion level parameter. When the overload condition has ended the network management/overload control function will direct the ISDN user part to cease including automatic congestion level parameters in the transmitted release messages. 2.13 Unequipped circuit identification code message (national option) An Unequipped Circuit Identification Code (UCIC) message is sent by an exchange in response to either the reception of an IAM, a CCR, a circuit supervision message, or a circuit group supervi- sion message on which it is unable to act as a consequence of its inability to perform a circuit identification code translation. The sending of the UCIC in response to the reception of other messages with UCIC is for further study. If an unequipped circuit identification code message is received for an SS No. 7 circuit which has been seized and an initial address message transmitted, the receiving exchange shall: 1) remove the indicated circuit from the service and report the circuit to the maintenance system for maintenance action; 2) re-attempt the call on another circuit providing the rejected attempt was a first attempt. If the rejected attempt was a second attempt, either a release message should be returned, (if the incoming circuit is an SS No. 7) or a recorded announcement connected (if the incoming circuit is conventional). If an unequipped circuit identification code message is received in response to the transmission of a circuit supervision message, or a continuity check request message, the circuit should be removed from the service and the circuit reported to the mainte- nance system for maintenance action. An exchange receiving a circuit group supervision message whose CIC in the routing label is unequipped should respond with a UCIC message for the circuit in the label. This in effect is the acknowledgement to the initial message. An exchange receiving a circuit group message where CIC in the routing label is equipped but one or more of the indicated circuits by the range field is unequipped merely responds in the manner that it would have if the circuit were equipped. The unequipped state of the circuit(s) will be recovered when an IAM, a CCR message, or circuit query message is received for the affected circuit(s). An exchange receiving an unequipped CIC message after having transmitted a circuit group supervision message removes the indi- cated circuit from service, assumes the regular acknowledgement message will not be received and treats the other circuits as though the responding exchange had not taken the action on the affected circuits indicated in the initial message. Blanc