.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .LP \fBMONTAGE: REC. Q.763 EN\(hyT\* | TE DE CETTE PAGE\fR .LP \v'26P' .sp 2P .LP \fBRecommendation\ Q.764\fR .RT .sp 2P .sp 1P .ce 1000 \fBSIGNALLING\ PROCEDURES\fR .EF '% Fascicle\ VI.8\ \(em\ Rec.\ Q.764'' .OF '''Fascicle\ VI.8\ \(em\ Rec.\ Q.764 %' .ce 0 .sp 1P .LP \fB1\fR \fBGeneral\fR .sp 1P .RT .sp 1P .LP 1.1 \fIRelationship with other Recommendations\fR .sp 9p .RT .PP This Recommendation describes the signalling procedures for the set\(hyup and cleardown of national and international ISDN connections. 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 services. (These were previously \(sc\ 4 of Recommendation\ Q.764.) .RT .sp 1P .LP 1.2 \fINumbering\fR (see Recommendations E.163, E.164) .sp 9p .RT .PP The procedures described assume that the ISDN uses the international 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 international telephony network. .RT .sp 1P .LP 1.3 \fIAddress signalling\fR .sp 9p .RT .PP In general, the call set\(hyup procedure described is standard for both speech and non\(hyspeech connections using en\(hybloc address signalling for calls between ISDN terminals. Overlap address signalling is also specified. .bp .RT .sp 1P .LP 1.4 \fIBasic procedures\fR .sp 9p .RT .PP The basic call control procedure is divided into three phases; call set\(hyup, the data/conversation phase and call cleardown. Messages 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 network. .RT .sp 1P .LP 1.5 \fISignalling methods\fR .sp 9p .RT .PP Two signalling methods are used in this Recommendation: .RT .LP \(em link\(hyby\(hylink; .LP \(em end\(hyto\(hyend. .PP The link\(hyby\(hylink method is primarily used for messages that need to be examined at each exchange (see \(sc\ 2). The end\(hyto\(hyend methods are used for messages of end point significance (see Recommendation\ Q.730). .PP The link\(hyby\(hylink method may be used for messages of end point significance. (However, the messages may be affected by processing delays.) .RT .sp 1P .LP 1.6 \fILayout of Recommendation Q.764\fR .sp 9p .RT .PP The procedures specified in \(sc\ 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\(hyto\(hyend 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\(hyUP are presented in Annex\ B. .RT .sp 1P .LP 1.7 \fIInterworking with other signalling systems or user parts\fR .sp 9p .RT .PP Only some examples are included in this Recommendation and these should not be used as a definitive interworking guide. .RT .sp 2P .LP \fB2\fR \fBBasic call control and signalling procedures\fR .sp 1P .RT .PP Figures 1/Q.764 to 10/Q.764 at the end of this section show the ISDN call set\(hyup sequences which are described below. .RT .LP 2.1 \fISuccessful call set\(hyup\fR .sp 1P .RT .sp 2P .LP 2.1.1 \fIForward address signalling \(em en bloc operation\fR .sp 1P .RT .sp 1P .LP 2.1.1.1 \fIActions required at originating exchange\fR .sp 9p .RT .LP a) \fICircuit selection\fR .LP 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\(hyexchange circuit takes place and an initial address message is sent to the succeeding exchange. .LP Appropriate routing information is either stored at the originating exchange or at a remote database to which a request may be made. .LP The selection of the route will depend on the called party number, connection type required and the network signalling capability required. This selection process may be performed at the exchange or with the assistance of the remote database. .LP In addition, in the case of a subscriber with digital access, the set\(hyup 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 information 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. .bp .LP The connection types allowed are: .LP \(em speech; .LP \(em 3.1 kHz audio; .LP \(em 64 kbit/s unrestricted; .LP \(em alternate speech/64 kbit/s unrestricted; .LP \(em alternate 64 kbit/s unrestricted/speech. .LP The network signalling capabilities allowed are: .LP \(em ISDN\(hyUP preferred; .LP \(em ISDN\(hyUP required; .LP \(em ISDN\(hyUP not required (any signalling system). .LP 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 indicators), to enable correct routing at intermediate exchanges. The initial address message conveys implicitly the meaning that the indicated circuit has been seized. .LP In the case where N\(mu64 kbit/s (N\(>="2) connections are required, the procedures for a single 64\ kbit/s connection may be used if the N\(mu64\ kbit/s are contiguous 64\ kbit/s channels and are pre\(hyassigned for N\(mu64\ kbit/s use. .LP 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. .LP b) \fIAddress information sending sequence\fR .LP The sending sequence of address information on international 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. .LP 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. .LP c) \fIInitial address message\fR .LP The initial address message (IAM) in principle contains all the information that is required to route the call to the destination exchange and connect the call to the called party. .LP All initial address messages will include a protocol control indicator (in the forward call indicator parameter) and a transmission medium requirement parameter. .LP The originating exchange will set the parameters in the protocol control indicator and in the ISDN\(hyUP preference indicator to indicate: .LP i) the type of end\(hyto\(hyend method that can be accommodated (\(sc\ 3); .LP ii) the availability of Signalling System No. 7 signalling; .LP iii) the use of the ISDN\(hyUP; .LP iv) whether further information is available (to be requested before the called party is alerted); .LP v) network signalling capability required, e.g. ISDN\(hyUP required all the way. .LP The ISDN\(hyUP 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\(hyUP to be essential then the indicator is set to \*Qrequired\*U, if the service required is optional but preferred it is set to \*Qpreferred\*U, otherwise it is set to \*Qnot required\*U. The indicator is set to either \*Qrequired\*U or \*Qpreferred\*U, or \*Qnot required\*U, according to the most stringent condition required by one or more of the parameters in the initial address message. In addition, if end\(hyto\(hyend signalling is essential to provide the requested service the indicator should always be set to \*Qrequired\*U (see Recommendation\ E.172). .LP The transmission medium requirement parameter contains the connection type required information, e.g.\ 3.1\ kHz audio. .bp .LP The originating exchange may also include in the initial address message: .LP i) a call reference (including the point code of the originating exchange) to enable the destination exchange to establish an end\(hyto\(hyend connection (\(sc\ 3); .LP 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; .LP iii) an SCCP connection request parameter; and .LP iv) other information related to supplementary services and network utilities. .LP The initial address message can contain an access transport parameter. .LP d) \fITransfer of information not included in the initial\fR \fIaddress message\fR .LP As an alternative to the inclusion of call set\(hyup user facility information in the initial address message, any call set\(hyup user facility information that need not be examined at intermediate exchanges and which can be requested from by the destination exchange (see Recommendation\ Q.763, \(sc\ 3.22), may be transported between the originating and destination exchange. The method of transportation for this information can be by the link\(hyto\(hylink method (see \(sc\ 2.1.6) or via the end\(hyto\(hyend methods (see \(sc\ 3). .LP e) \fICompletion of transmission path\fR .LP Through connection of the transmission path will be completed in the backward direction (the transmission path is completed 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 conditions on the outgoing circuit prevent it (see \(sc\ 2.1.9). .LP It is also acceptable that on speech or 3.1 kHz audio calls, through\(hyconnection of the transmission path will be completed 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 \(sc\ 2.1.9). .LP f ) \fINetwork protection timer\fR .LP When the originating exchange or the controlling exchange has sent the initial address message the awaiting address complete timer (T\d7\u) is started. If timer (T\d7\u) expires the connection is released and an indication is returned to the calling subscriber. .sp 1P .LP 2.1.1.2 \fIActions required at an\fR \fIintermediate exchange\fR .sp 9p .RT .LP a) \fICircuit selection\fR .LP An intermediate exchange, on receipt of an initial address message will analyze the called party number and the other routing information (\(sc\ 2.1.1.1 | )) to determine the routing of the call. If the intermediate exchange can route the call using the connection type specified in the transmission medium requirement parameter, a free inter\(hyexchange 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 information 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. .LP 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. .LP When no echo suppressor or nature\(hyof\(hycircuit indication is received from a preceding exchange using a signalling system with fewer facilities, the indicators will be considered as received \*Qno\*U unless positive knowledge is available. .LP b) \fIParameters in the initial address message\fR .LP 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\(hyto\(hyend method indicator; the most significant digits in the called party number may be amended or omitted (see \(sc\ 2.1.1.1 | )). A change of the end\(hyto\(hyend method used may also alter parameters (see \(sc\ 3). Other signalling information is passed on transparently, e.g.\ the access transport parameter, user service information,\ etc. .bp .LP c) \fICompletion of transmission path\fR .LP Through\(hyconnection of the transmission path in both directions 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 \(sc\ 2.1.9). .sp 1P .LP 2.1.1.3 \fIActions required at the\fR \fIdestination exchange\fR .sp 9p .RT .LP a) \fISelection of called party\fR .LP 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. .LP At this point, certain call set\(hyup information may need to be obtained from an originating or controlling exchange (see \(sc\ 2.1.6). Examination of the protocol control indicator will show whether end\(hyto\(hyend 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. .LP In this case where the connection is allowed, the destination 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 circuits has been verified. .sp 2P .LP 2.1.2 \fIForward address signalling \(em Overlap operation\fR .sp 1P .RT .sp 1P .LP 2.1.2.1 \fIActions required at originating exchange\fR .sp 9p .RT .LP a) \fICircuit selection\fR .LP When the originating exchange has received sufficient information [see \(sc\ 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\(hyexchange circuit takes place and an initial address message is sent to the succeeding exchange. .LP Appropriate routing information is either stored at the originating exchange or at a remote database to which a request may be made. .LP The selection of the route will depend on the called party number, connection type required and the network signalling capability required. This selection process may be performed at the exchange or with the assistance of a remote database. .LP In addition, in the case of a subscriber with digital access, the set\(hyup 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 information 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. .LP The connection types allowed are: .LP \(em speech; .LP \(em 3.1 kHz audio; .LP \(em 64 kbit/s unrestricted; .LP \(em alternate speech/64 kbit/s unrestricted; .LP \(em alternate 64 kbit/s unrestricted/speech. .LP The network signalling capabilities allowed are: .LP \(em ISDN\(hyUP preferred; .LP \(em ISDN\(hyUP required; .LP \(em ISDN\(hyUP not required (any signalling system). .LP 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. .bp .LP In the case where N\ \(mu\ 64 kbit/s (N\ \(>="\ 2) connections are required, the procedures for a single 64\ kbit/s connection may be used if the N\ \(mu\ 64\ kbit/s are contiguous 64\ kbit/s channels and are pre\(hyassigned for N\ \(mu\ 64\ kbit/s use. .LP 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. .LP b) \fIAddress information sending sequence\fR .LP The sending sequence of address information on international 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. .LP 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. .LP c) \fIContent of initial and subsequent address messages\fR .LP 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 \(sc\ 2.1.1.1 | ). The only purpose of the subsequent address message is to carry further digits. .LP All digits required for routing the call through the international network will be sent in the IAM. On calls with a country code in the number (except in the case of calls to special operators), the IAM will contain a minimum of 4\ digits and should contain 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. .LP The remaining digits of the number may be sent in subsequent 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. .LP The end\(hyof\(hypulsing (ST) signal is always sent in the following situations: .LP i) semi\(hyautomatic calls; .LP ii) test calls; and .LP iii) when the end\(hyof\(hypulsing (ST) signal is received. .LP In automatic working, the end\(hyof\(hypulsing (ST) signal will be sent whenever the originating or outgoing exchange is in a position 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\(hyof\(hypulsing signal is not sent and the end\(hyof\(hyaddress information is determined by the receipt of the address complete message or connect message from the incoming exchange. .LP d) \fITransfer of information not included in the initial\fR \fIaddress message\fR .LP As an alternative to the inclusion of call set\(hyup user facility information in the initial address message, any call set\(hyup user facility information that need not be examined at intermediate exchanges and which can be requested by the destination exchange (see Recommendation\ Q.763, \(sc\ 3.22), may be transported between the originating and destination exchange. The method of transportation for this information can be by the link\(hyby\(hylink method (see \(sc\ 2.1.6) or via the end\(hyto\(hyend methods (see \(sc\ 3). .LP e) \fICompletion of transmission path\fR .LP Through connection of the transmission path in the backward direction (the transmission path is completed in the forward direction on receipt of connect or answer message) at the originating exchange will be completed except in the cases where conditions on the outgoing circuit prevent it (see \(sc\ 2.1.9): .LP i) immediately after the sending of the initial address message, or .LP ii) when digit analysis or timer (T\d1\\d0\u), or receipt of the address complete message indicates that all digits have been received. .bp .LP It is also acceptable that on speech or 3.1 kHz audio calls, through connection of the transmission path will be completed 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 \(sc\ 2.1.9). .LP f ) \fINetwork protection timer\fR .LP Each time when the originating exchange has sent an address message the awaiting address complete timer (T\d7\u) is started. If timer (T\d7\u) expires the connection is released and an indication is sent to the calling subscriber. .sp 1P .LP 2.1.2.2 \fIActions required at an intermediate exchange\fR .sp 9p .RT .LP a) \fICircuit selection\fR .LP An intermediate exchange, on receipt of an IAM, will analyze the digits available and the other routing information [see \(sc\ 2.1.2.1 | )] to determine the routing of the call. If the intermediate exchange can route the call using the connection type specified in the transmission medium requirement parameter a suitable free inter\(hyexchange 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 forwarded to the succeeding exchange as subsequent address message(s). .LP 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 capability 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. .LP 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. .LP When no echo suppressor or nature\(hyof\(hycircuit indication is received from a preceding exchange using a signalling system with fewer facilities the indicators will be considered as received \*Qno\*U unless positive knowledge is available. .LP 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. .LP b) \fIParameters in the initial address message\fR .LP 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\(hyto\(hyend method indicator; the most significant digits in the called party number may be amended or omitted [see \(sc\ 2.1.1.1 | )]. A change of the end\(hyto\(hyend method used may also alter parameters (see \(sc\ 3). Other signalling information is passed on transparently, e.g.\ the access transport parameter, user service information,\ etc. .LP c) \fICompletion of transmission path\fR .LP Through\(hyconnection of the transmission path in both directions 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 \(sc\ 2.1.9). .sp 1P .LP 2.1.2.3 \fIActions required at the destination exchange\fR .sp 9p .RT .LP a) \fISelection of called party\fR .LP 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 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. .bp .LP At this point, certain call set\(hyup information may need to be obtained from an originating or controlling exchange (see \(sc\ 2.1.6). Examination of the protocol control indicator will show whether end\(hyto\(hyend 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. .LP In the case where the connection is allowed, the destination 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 circuits has been verified. .sp 1P .LP 2.1.3 \fICalling party number\fR .sp 9p .RT .PP The calling party number can either be included in the initial address message [\(sc\(sc\ 2.1.1.1 | ) and\ 2.1.2.1 | )] or requested by the destination exchange (see \(sc\ 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 \(sc\ 3. The destination 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. .RT .sp 2P .LP 2.1.4 \fIAddress complete message, connect message and call\fR \fIprogress message\fR .sp 1P .RT .sp 1P .LP 2.1.4.1 \fIReturn of address complete message from destination exchange\fR .sp 9p .RT .PP 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 \(sc\(sc\ 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 \(sc\ 2.1.9). .PP Address complete is sent from the destination exchange in the following conditions: .RT .LP 1) In the case where the terminating access is non ISDN the following action takes place at the destination exchange: .LP 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: .LP \(em call line status: \*QSubscriber free\*U .LP \(em ISDN access indicator: \*QNon ISDN\*U .LP 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 message will be set to indicate: .LP \(em called line status: \*QNo indication\*U .LP \(em ISDN access indicator: \*QNon ISDN\*U. .LP 2) In the case where the terminating access is ISDN, the following conditions can apply: .LP 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 complete message will be set as follows: .LP \(em called line status: \*QNo indication\*U .LP \(em ISDN access indicator: \*QISDN\*U. .LP \fINote\fR \ \(em\ In case a) the indication that the destination user is being alerted is transferred in a call progress message (see \(sc\ 2.1.5). .LP 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: .LP \(em called line status: \*QSubscriber free\*U .LP \(em ISDN access indicator: \*QISDN\*U. .bp .sp 1P .LP 2.1.4.2 \fIReturn of connect message from the destination exchange\fR .sp 9p .RT .PP If a connect indication is received from the ISDN access under the following conditions: .RT .LP \(em no alerting indication received from the ISDN access and .LP \(em an address complete message has not yet been sent by the destination exchange, .LP a connect message is sent by the destination exchange. This connect message signifies both address complete and answer conditions. .PP Indicators in the connect message will indicate: .LP \(em called line status: \*QSubscriber free\*U .LP \(em ISDN access indicator: \*QISDN\*U. .PP The destination exchange will through\(hyconnect before the connect message is sent. .sp 1P .LP 2.1.4.3 \fIReceipt of address complete message or connect message\fR \fIat an intermediate exchange\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 2.1.4.4 \fIReceipt of address complete message or the connect message\fR \fIat the originating exchange\fR .sp 9p .RT .LP a) When the originating exchange receives an address complete message the appropriate exchange functions take place. .LP b) On receipt of an address complete message with the called line status indicator set to \*Qsubscriber free\*U an alerting indication is passed to the calling party if possible. .LP c) On receipt of the address complete message the awaiting address complete timer (T\d7\u) is stopped and the awaiting answer timer (T\d9\u) is started. If timer (T\d9\u) expires the connection is released and an indication is sent to the calling subscriber. .LP d) If the connect message is received then the appropriate exchange functions take place. The awaiting address complete timer (T\d7\u) is stopped (see \(sc\ 2.1.7.2). .sp 1P .LP 2.1.4.5 \fIThrough\(hyconnection and awaiting answer indication\fR \fIat the destination exchange\fR .sp 9p .RT .PP 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 calling 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. .PP Regardless of whether tones are to be provided or not, the destination exchange will through\(hyconnect after the reception of the connection indication from the called party and before sending the answer/connect message to the preceding exchange. .PP 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\(hyconnect the transmission path in the backward direction on receipt of the progress indication. .PP The complete through\(hyconnection of the transmission path at answer is covered in \(sc\ 2.1.7. .RT .sp 1P .LP 2.1.4.6 \fIAddress complete message with charging information\fR .sp 9p .RT .PP The address complete message carries a charge indicator. .RT .sp 1P .LP 2.1.4.7 \fIAddress complete message with other information\fR .sp 9p .RT .PP Additional information can be included in the address complete messages (e.g.\ related to supplementary services, see Recommendation\ Q.730). .RT .sp 1P .LP 2.1.4.8 \fIReturn of address complete message in interworking situations\fR .sp 9p .RT .PP An address complete message will not be sent until the cross\(hyoffice check is made, if applicable (see \(sc\ 2.1.10). .bp .PP If the succeeding network does not provide electrical called\(hyparty's\(hyline\(hycondition 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: .RT .LP a) by receipt of an end\(hyof\(hypulsing (ST) signal; or .LP b) by receipt of the maximum number of digits used in the national numbering plan; or .LP 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 .LP d) by receipt of an end\(hyof\(hyselection signal from the succeeding network (e.g.\ number received signal in Signalling System\ No.\ 5); or .LP e) exceptionally, if the succeeding network uses overlap signalling and number analysis is not possible, by observing that timer (T\d1\\d0\u) 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 backward. In this way, it is ensured that no national answer signal can arrive before an address complete message has been sent. .PP 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 (T\d1\\d1\u)) after receiving the latest address message. The time\(hyout condition is an upper limit considering the clauses of \(sc\ 2.9.10.3 (20 to 30\ seconds waiting for address complete message timer (T\d7\u) for outgoing international exchanges in abnormal release conditions). .sp 1P .LP 2.1.4.9 \fIReturn of sub\(hyaddress information in address complete message,\fR \fIconnect message or call progress message\fR .sp 9p .RT .PP If sub\(hyaddress 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. .RT .sp 1P .LP 2.1.5 \fICall progress\fR .sp 9p .RT .PP The call progress message is sent (either before or after the address complete message) from an exchange in the backward direction indicating that an event has occurred during call set\(hyup which should be relayed to the calling party. .RT .sp 1P .LP 2.1.5.1 \fIReturn of call progress message from the destination exchange\fR .sp 9p .RT .PP The call progress message is sent from the destination exchange if the address complete message has been sent and subsequently: .RT .LP \(em an indication is received that the called party is being alerted, .LP the call progress message contains an event indicator that is set to \*Qalerting\*U .LP \(em a progress indication is received from the called party, .LP the call progress message contains an event indicator that is set to \*Qprogress\*U. .PP If the indication received from the called party contains a \*Qprogress indication\*U, this is carried by the call progress message in the access transport parameter (transported unchanged across the public network). .PP The destination exchange may on receipt of the indication from the called party, that contains an appropriate progress indicator, through\(hyconnect the speech path, see \(sc\ 2.1.4.5. .PP 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 \(sc\ 2.2.4. .RT .sp 1P .LP 2.1.5.2 \fIAction at an intermediate exchange\fR .sp 9p .RT .PP On receipt of a call progress message an intermediate exchange will send the corresponding call progress message to the preceding exchange. .bp .RT .sp 1P .LP 2.1.5.3 \fIActions at the originating exchange\fR .sp 9p .RT .PP On receipt of a call progress message at the originating exchange, no state change occurs (i.e.\ the awaiting address complete 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 transport parameter it is transferred unaltered into the indication returned to the calling user. .RT .sp 2P .LP 2.1.6 \fIInformation messages\fR .sp 1P .RT .sp 1P .LP 2.1.6.1 \fIRequesting information\fR .sp 9p .RT .PP 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\(hyup. .RT .sp 1P .LP 2.1.6.2 \fISending information\fR .sp 9p .RT .PP On sending an information request message a timer (T\d3\\d3\u) is started. No second information request message may be sent in the same direction until a response information message is received. If the timer (T\d3\\d3\u) expires before the response message is received, see \(sc\ 2.10.7. The value of this timer (T\d3\\d3\u) is 12\(hy15\ seconds to allow for a cascade of information request messages, as described in item\ ii). The response information message may be sent as follows: .RT .LP i) if all the information requested is available locally, then an information message containing all the required information is sent in response; .LP 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 information message is sent in an information message; .LP 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 \*Qnot available\*U, using either the indication in the information indicator or an appropriate coding in the requested parameter. .sp 1P .LP 2.1.6.3 \fISending unsolicited information\fR .sp 9p .RT .PP 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. .PP 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 complete state). .PP 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 indicator set to \*Qunsolicited\*U. .RT .sp 1P .LP 2.1.6.4 \fIReceiving an information message\fR .sp 9p .RT .PP Upon receipt of an information message which does neither contain 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. .RT .sp 2P .LP 2.1.7 \fIAnswer message\fR .sp 1P .RT .sp 1P .LP 2.1.7.1 \fIReturn of answer message from destination exchange\fR .sp 9p .RT .PP When the called party answers, the destination exchange connects 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. .bp .RT .sp 1P .LP 2.1.7.2 \fIReceipt of answer message at intermediate exchange\fR .sp 9p .RT .PP 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 (T\d9\u) is stopped. .RT .sp 1P .LP 2.1.7.3 \fIReceipt of answer message at originating exchange\fR .sp 9p .RT .PP When the originating exchange receives an answer message indicating the required connection has been completed, the transmission path is connected\(hythrough in the forward direction, if not already connected. The awaiting answer timer (T\d9\u) is stopped. If the originating exchange is the exchange controlling charging, charging may begin if applicable. The calling party is informed. .RT .sp 1P .LP 2.1.7.4 \fIReturn of answer from automatic terminals\fR .sp 9p .RT .PP When connections are set\(hyup 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 complete message has been sent, otherwise the connect message is sent. .RT .sp 1P .LP 2.1.7.5 \fIAnswer with charging information\fR .sp 9p .RT .PP The answer message received from the destination exchange or from a succeeding network carries a charge indicator. .RT .sp 1P .LP 2.1.8 \fIContinuity\(hycheck\fR .sp 9p .RT .PP Because the signalling in Signalling System No. 7 does not pass over the circuit, facilities should be provided for making a continuity\(hycheck of the circuit in the circumstances described below. .PP The application of the continuity\(hycheck depends on the type of the transmission system used for the circuit. .PP For transmission systems having some inherent fault indication features giving an indication to the switching system in case of fault, a continuity\(hycheck is not required. However, a per call continuity\(hycheck may be needed on fully digital circuits when circuits or bundles of circuits in primary multiplex groups are dropped and inserted en route between switches, and alarm indications 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\(hychecks may be needed when the transmission link between switches contains a TDMA satellite system, a digital circuit multiplication system or a digital access and cross connection system, where fault indications are lost (see Recommendation\ Q.33). .PP When an initial address message is received with a request for a continuity\(hycheck relating to a digital circuit having inherent fault indication, one of the following actions is taken: .RT .LP either a) the continuity\(hycheck request is disregarded; .LP or b) a continuity\(hycheck 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. .PP \fINote\fR \ \(em\ The reception of such a request could only be caused by an abnormal condition such as administrative errors or the occurrence of signalling errors. .PP 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\(hycheck loop should always be connected in the following case: .RT .LP i) when the exchange has the capability to process initial address messages with continuity\(hycheck request and such messages are received; .LP ii) when continuity\(hycheck request messages are received. .PP Means should be provided in SS No. 7 to detect circuit identification code misunderstandings between SS\ No.\ 7 exchanges. .PP For exchanges having both analogue and digital circuits served by SS\ No.\ 7, the continuity\(hycheck initiated by a continuity\(hycheck request message could be used to test for proper alignment of circuit code identities. On those exchanges, reception of a continuity\(hycheck request message should always cause a loop to be attached to the circuit. .PP Alternative methods for detection of circuit identity misunderstandings in exchanges with all digital circuits may be employed. .bp .PP The continuity\(hycheck is not intended to eliminate the need for routine testing of the transmission path. .PP The continuity check of the circuit will be done, link\(hyby\(hylink, 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, \(sc\ 7. .PP The actions to be taken when pilot supervision is used are described in Recommendation\ Q.724, \(sc\ 9. .RT .sp 2P .LP 2.1.9 \fISpecial procedures at an interworking point\fR .sp 1P .RT .sp 1P .LP 2.1.9.1 \fICompletion of transmission path at an interworking exchange\fR .sp 9p .RT .PP In general, completion of the transmission path at an interworking point should occur as soon as possible during the call set\(hyup phase. The actual point of switch\(hythrough will vary depending on the interworking signalling system, e.g.\ whether inband or outband signalling is used or whether a continuity\(hycheck procedure is applied. .PP When interworking with other internationally specified signalling systems, the following rules on switch\(hythrough should be applied: .RT .ce \fBH.T. [T1.764]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(48p) | lw(180p) . SS No. 7 \(ra SS No. 7 { When no continuity\(hycheck is to be made on the outgoing circuit, through\(hyconnection should occur after sending the initial address message. When continuity\(hycheck is to be made on the outgoing circuit, through\(hyconnection should occur after residual check tone has propagated through the return path of the circuit (see Recommendation\ Q.724, \(sc\ 7.3). } _ .T& lw(48p) | lw(180p) . { SS No. 6 \(ra SS No. 7 .line SS No. 5 \(ra SS No. 7 .line R1 \(ra SS No. 7 .line SS No. 7 \(ra SS No. 6 } { When no continuity\(hycheck is to be made on the outgoing circuit, through\(hyconnection can occur after sending the initial address message. When a continuity\(hycheck is to be made on the outgoing circuit, through\(hyconnection can occur after residual check tone has propagated through the return path of the circuit (see Recommendation\ Q.724, \(sc\ 7.3). } _ .T& lw(48p) | lw(180p) . R2 \(ra SS No. 7 { Through\(hyconnection should occur after receipt of address complete. } _ .T& lw(48p) | lw(180p) . { SS No. 7 \(ra SS No. 5 .line SS No. 7 \(ra R1 } { Through\(hyconnection can occur after sending ST (end of pulsing) signal and removal of a possible check loop. } _ .T& lw(48p) | lw(180p) . SS No. 7 \(ra R2 { Through\(hyconnection should occur after sending of address complete. } _ .TE .nr PS 9 .RT .ad r \fB[T1.764], p.\fR .sp 1P .RT .ad b .RT .PP When a continuity\(hycheck 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\(hyconnection 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\(hycheck procedure given in Recommendation\ Q.724, \(sc\ 7.3. .sp 1P .LP 2.1.9.2 \fIAlerting of called party\fR .sp 9p .RT .PP If in an interworking situation a continuity\(hycheck 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: .RT .LP a) SS No. 7 \(ra any non No. 7 signalling system. .LP b) International SS No. 7 \(ra national SS No. 7 not performing continuity\(hycheck. .PP 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. .bp .PP 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 connection to the called party is postponed in the terminating exchange in case of non DDI. .RT .sp 1P .LP 2.1.10 \fICross office check\fR .sp 9p .RT .PP For digital exchanges, the requirements mentioned in Recommendation\ Q.543 shall be met. For other exchanges, Administrations shall ensure the reliability of a connection through a switching machine (cross\(hyoffice 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\(hyterm average. .RT .sp 2P .LP 2.1.11 \fICharging procedures\fR .sp 1P .RT .sp 1P .LP 2.1.11.1 \fIBasic call charging\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 2.1.11.2 \fINetwork charging messages\fR (national option) .sp 9p .RT .PP 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\(hyup. Also, charge rate information may be returned during call set\(hyup, followed subsequently by further charge information messages during the conversation/data phase, should the original rate require to be changed during the call. .RT .sp 1P .LP 2.1.12 \fIForward transfer message\fR .sp 9p .RT .PP The forward transfer message may be sent in telephony semi\(hyautomatic working in either of the following two cases: .RT .LP 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 international exchange, an assistance operator is called in; .LP b) following a call via codes 11 and 12, the controlling 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 completed via the operator positions at the exchange. .sp 1P .LP 2.1.13 \fITransit network selection\fR (national option) .sp 9p .RT .PP If transit network selection information is included in the set\(hyup information from the calling party or is provided on a subscription 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. .PP 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. .RT .sp 1P .LP 2.2 \fIUnsuccessful call set\(hyup\fR .sp 9p .RT .PP If at any time in the call set\(hyup the connection cannot be completed a release message is returned. This message contains the reason. .RT .sp 1P .LP 2.2.1 \fIActions at exchange initiating a\fR \fIrelease message\fR .sp 9p .RT .PP The initiating exchange immediately starts the release of the switched path (if established). The exchange sends a release message to the preceding exchange and a timer (T\d1\u) is started to ensure that a release complete message is received from the preceding exchange within time\ T\d1\u[expiration of timer (T\d1\u) is covered in\ \(sc\ 2.10.6]. .bp .RT .sp 1P .LP 2.2.2 \fIActions at intermediate exchange\fR .sp 9p .RT .PP On receipt of a release message from the succeeding exchange, an intermediate exchange: .RT .LP i) immediately start the release of the switched path; when the circuit is reselectable, a release complete message is returned to the succeeding exchange; .LP 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 (T\d1\u) is started to ensure that a release complete message is received from the preceding exchange within time\ T\d1\u(expiration of this time is covered in\ \(sc\ 2.10.6). .sp 1P .LP 2.2.3 \fIActions at the controlling exchange\fR (i.e.\ the exchange controlling the call) .sp 9p .RT .PP On receipt of a release message from the succeeding exchange, the controlling exchange starts the release of the switched path. .PP In addition, the controlling exchange will: (if applicable) .RT .LP a) return an indication (in band or out band) to the calling party (see\ \(sc\ 2.2.4); or .LP b) attempt to re\(hyroute the call set\(hyup; or .LP c) initiate release procedures to the preceding exchange (as described in\ \(sc\ 2.2.4). .PP In case\ a) above an indication is carried in the call progress message or address complete message indicating in\(hyband information is available, (see\ \(sc\ 2.2.4). .PP When the controlling exchange is ready for circuit re\(hyselection, a release complete message is sent to the succeeding exchange. .RT .sp 1P .LP 2.2.4 \fITones and announcements\fR .sp 9p .RT .PP If a call set\(hyup fails and an in\(hyband 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\(hyband tone to the transmission path. .PP If an address complete message has been returned to the preceding exchange a call progress message indicating that in\(hyband tone information is available, is returned to the preceding exchange (see\ \(sc\ 2.1.5). .PP 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 \*Qin\(hyband information\*U indicator set in the optional backward call indicator, will be returned to the originating exchange. .RT .sp 1P .LP 2.3 \fINormal call release\fR .sp 9p .RT .PP The release procedures are based on a two message (release, release complete) approach whereby the release message initiates release of the circuit switched connection. .PP 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 (\(sc\ 2.6). .PP 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\(hyoffice transfer time, T\dc\\du\u, for simple messages as specified in Recommendation\ Q.766. .RT .sp 1P .LP 2.3.1 \fIRelease initiated by a calling party\fR .sp 9p .RT .LP a) \fIActions at the originating exchange\fR .LP On receipt of a request to release the call from the calling party, the originating exchange immediately starts the release of the switched path. A release message is sent to the succeeding exchange and a timer (T\d1\u) is started to ensure that a release complete message is received from the succeeding exchange within\ T\d1\u(expiration of this time is covered in\ \(sc\ 2.10.6). .bp .LP b) \fIActions at an intermediate exchange\fR .LP On receipt of a release message from the preceding exchange, an intermediate exchange: .LP i) immediately starts the release of the switched path; when the circuit is reselectable, a release complete message is returned to the preceding exchange; .LP 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 (T\d1\u) is started to ensure that a release complete message is received from the succeeding exchange within time\ T\d1\u(expiration of this time is covered in\ \(sc\ 2.10.6). .LP c) \fIActions at the destination exchange\fR .LP 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. .LP d) \fICharging\fR .LP 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 originating local exchange. .LP e) \fICollision of release messages\fR .LP In the case when two points in the connection both initiate 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\(hyselection. .sp 1P .LP 2.3.2 \fIRelease initiated by a called party\fR .sp 9p .RT .PP The procedures in \(sc\ 2.3.1 apply, except that the functions at the originating and destination exchanges are transposed. .RT .sp 1P .LP 2.3.3 \fIRelease initiated by the network\fR .sp 9p .RT .PP The procedures in \(sc 2.3.1 apply, except that they can be initiated at any exchange (originating, destination or intermediate). .RT .sp 1P .LP 2.3.4 \fIStorage and release of IAM information\fR .sp 9p .RT .PP Each exchange of the connection shall store during the call set\(hyup the information contained in the initial address message sent (the originating exchange) or received (intermediate or destination exchange). The information to be stored includes all parameters in the\ IAM. The contents of the\ IAM information shall be updated, if the value of parameters change during the call set\(hyup. .PP The IAM information can be released from memory: .RT .LP a) in the originating exchange when the address complete message or connect message has been received and the calling party does not subscribe to a supplementary service which would cause a new call set\(hyup (e.g.\ call transfer). The release of the information when the calling party does subscribe to a supplementary service is covered in Recommendation\ Q.730; .LP b) in the intermediate exchange when the address complete message or the connect message has been received; .LP 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\(hyup (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, .LP and when the call is released earlier and no automatic repeat attempt is to be attempted. .sp 2P .LP 2.4 \fITransfer of user\(hyto\(hyuser information\fR .sp 1P .RT .sp 1P .LP 2.4.1 \fIRequirements for transfer of user\(hyto\(hyuser data\fR .sp 9p .RT .PP See Recommendation Q.730. .bp .RT .sp 2P .LP 2.5 \fISuspend, resume\fR .sp 1P .RT .sp 1P .LP 2.5.1 \fISuspend\fR .sp 9p .RT .PP The suspend message indicates a temporary cessation of communication without releasing the call. It can only be accepted during the conversation/data phase. A suspend message can be either generated in response to a suspend request from the calling/called party or generated by the network in response to a clearback indication from an interworking node or an on\(hyhook condition from an analogue called (telephone) party. .RT .sp 1P .LP 2.5.1.1 \fISuspend initiated by a calling party\fR .sp 9p .RT .PP A suspend message is generated in response to a suspend request from a calling party. .RT .LP a) \fIActions at originating exchange\fR .LP On receipt of a suspend request from the calling party, the originating exchange sends a suspend message to the succeeding exchange. .LP b) \fIActions at an intermediate exchange\fR .LP On receipt of the suspend message from the peceding exchange the intermediate exchange sends a suspend message to the succeeding exchange. .LP c) \fIActions at destination exchange\fR .LP On receipt of the suspend message from the preceding exchange, the destination exchange informs the called party that a suspend has been requested. .LP d) \fIActions at the suspend request controlling exchange\fR .LP On receipt of the suspend request from a user or the suspend message, the controlling exchange starts a timer (T\d2\u) to ensure that a resume request or resume message is received within timer (T\d2\u). If the timer (T\d2\u) expires, the procedures in\ \(sc\ 2.5.3 apply. .sp 1P .LP 2.5.1.2 \fISuspend initiated by a called party\fR .sp 9p .RT .PP The procedures in\ \(sc\ 2.5.1.1 apply, except that the functions at the originating and destination exchanges are transposed. .RT .sp 1P .LP 2.5.1.3 \fISuspend initiated by the network\fR .sp 9p .RT .PP A suspend message can be generated by the network in response to a clearback indication from an interworking node or an on\(hyhook condition from an analogue called party. .RT .LP a) \fIAction at the terminating exchange (destination) or an\fR \fIinterworking exchange\fR .LP On receipt of an on\(hyhook 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. .LP b) \fIAction at the intermediate exchange\fR .LP On receipt of a suspend message the exchange will send a suspend message to the preceding exchange. .LP c) \fIAction at the controlling exchange\fR .LP On receipt of the on\(hyhook condition or clearback indication or suspend message, the controlling exchange starts a timer (T\d6\u) to ensure that an off\(hyhook condition, a re\(hyanswer indication, a resume (network) message or a release message is received. The value of this timer (T\d6\u) is covered in Recommendation\ Q.118. If the timer (T\d6\u) expires, the procedures in\ \(sc\ 2.5.3 apply. .sp 1P .LP 2.5.2 \fIResume\fR .sp 9p .RT .PP A resume message indicates a request to recommence communication. A request to release the call received from the calling or called party will override the suspend/resume sequence and the procedures given in\ \(sc\ 2.3 will be followed. .bp .RT .sp 1P .LP 2.5.2.1 \fIResume initiated by a calling party\fR .sp 9p .RT .PP Having initiated a suspend condition, a calling party may request a reconnection within timer\ T\d2\u. The procedures in\ \(sc\ 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 controlling exchange cancels the timer\ (T\d2\u). .RT .sp 1P .LP 2.5.2.2 \fIResume initiated by a called party\fR .sp 9p .RT .PP The procedures in\ \(sc\ 2.5.2.1 apply except that the functions at the originating and destination exchange are transposed. .RT .sp 1P .LP 2.5.2.3 \fIResume initiated by the network\fR .sp 9p .RT .PP A resume message is initiated by the network, if a suspend message had previously been sent, in response to a re\(hyanswer indication from an interworking node or an off\(hyhook condition from an analogue called party. .RT .LP a) \fIAction at the terminating exchange or interworking\fR \fIexchange\fR .LP On receipt of a re\(hyanswer indication at the interworking exchange or an off\(hyhook 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. .LP b) \fIActions of the intermediate exchange\fR .LP On receipt of a resume message the exchange will send a resume message to the preceding exchange. .LP c) \fIAction of the controlling exchange\fR (i.e.\ exchange controlling the call) .LP On receipt of the off\(hyhook condition, re\(hyanswer signal, release message or resume message the controlling exchange stops the timer (T\d6\u) [started in\ \(sc\ 2.5.1.3\ c)]. .sp 1P .LP 2.5.3 \fIExpiration of timer (T\fI .sp 9p .ce [Mangled Text] .PP If a request for reconnection or a resume message is not received within timer (T\d2\u) or timer (T\d6\u) covered in Recommendation\ Q.118 then the controlling exchange will initiate the release procedure outlined in\ \(sc\ 2.3.3. .RT .sp 1P .LP 2.6 \fIDelayed release\fR (national option) .sp 9p .RT .PP 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. .PP The local exchange receiving the release request sends a delayed release message. The connection is split, timer (T\d3\u) is started (to prevent network lock\(hyup) 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. .PP 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 (T\d3\u) matures, the network generates the normal release sequence (\(sc\ 2.3.3). .RT .sp 1P .LP 2.7 \fIIn\(hycall modification\fR .sp 9p .RT .PP 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: .PP Following call set\(hyup the calling or called party may choose to modify the characteristics of the call during the conversation/data phase. During call set\(hyup, the network will have chosen a suitable route (e.g.\ 64\ kbit/s and ISDN user part signalling used all the way) according to information included in the initial address message. .RT .sp 2P .LP 2.7.1 \fISuccessful completion\fR .sp 1P .RT .sp 1P .LP 2.7.1.1 \fIActions required at the exchange originating the call\fR \fImodification\fR .sp 9p .RT .LP 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 available. If acceptable, the resources are reserved and the call modification request message is sent. A timer (T\d4\u) is started to ensure that a call modification completed message is received within timer (T\d4\u). .bp .LP 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 (T\d4\u) is cancelled. .sp 1P .LP 2.7.1.2 \fIActions required at intermediate exchanges\fR .sp 9p .RT .LP a) On receipt of the call modification request message 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. .LP b) On receipt of a call modification completed message, the intermediate exchange modifies the resource and, when complete, sends a call modification completed message to the next exchange. .sp 1P .LP 2.7.1.3 \fIActions required at the local exchange receiving the request\fR \fIcall for in\(hycall modification\fR .sp 9p .RT .LP a) On receipt of a call modification request message 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. .LP 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. .sp 1P .LP 2.7.2 \fIUnsuccessful completion\fR .sp 9p .RT .PP Basically three cases of unsuccessful completion can be identified: .RT .LP 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 modification reject message is returned in the direction of the exchange originating the in call modification request. The connection is maintained in its current mode. .LP 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. .LP iii) If at the exchange initiating the call modification request timer (T\d4\u) expires, the connection is released. .sp 1P .LP 2.7.2.1 \fIActions required at the local exchange initiating the call\fR \fImodification\fR .sp 9p .RT .PP On receipt of the call modification reject message the exchange keeps the characteristics of the transmission path in the current mode, stops the timer (T\d4\u) and informs the initiating party. If resources have been reserved upon reception of the call modification request, they are released. .RT .sp 1P .LP 2.7.2.2 \fIActions required at an intermediate exchange\fR .sp 9p .RT .PP 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. .PP If an intermediate exchange, upon receipt of a call modification complete message, fails to change the characteristics of the transmission path, it initiates the release of the connection in both directions. .RT .sp 1P .LP 2.7.2.3 \fIAction required at the remote local exchange receiving the call\fR \fImodification request from the network\fR .sp 9p .RT .PP If at the remote local exchange the in call modification cannot 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. .bp .RT .sp 2P .LP 2.8 \fIEcho control procedure\fR .sp 1P .RT .sp 1P .LP 2.8.1 \fIGeneral\fR .sp 9p .RT .PP The echo control procedure is used on a per call basis to convey information between exchange nodes about the demand and ability to insert echo control devices. .PP The procedure is invoked when a call is to be routed on a connection for which echo control is necessary. It could be initiated at the originating exchange or at an intermediate exchange. .RT .sp 2P .LP 2.8.2 \fIForward direction\fR .sp 1P .RT .sp 1P .LP 2.8.2.1 \fIActions at the originating exchange\fR .sp 9p .RT .PP If an originating exchange has sufficient information to determine that echo control is necessary for the outgoing circuit then: .RT .LP \(em an outgoing half echo control device is enabled; and .LP \(em the echo control device indicator of the nature of connection indicators parameter field in the IAM is set. .sp 1P .LP 2.8.2.2 \fIActions at an intermediate exchange\fR .sp 9p .RT .PP 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: .RT .LP a) When the nature of connection indicators parameter field in the IAM indicates that an echo control device is already included: .LP \(em no change to the nature of connection indicators parameter field in the IAM is made; .LP \(em an incoming half echo control device is reserved; and .LP \(em any outgoing half echo control device is disabled. .LP b) When the nature of connection indicators parameters in the IAM does not indicate that an echo control device is already included: .LP \(em an outgoing half echo control device is enabled; and .LP \(em the echo control device indicator in the nature of connection indicators parameter field is set. .PP If the intermediate exchange has sufficient information to determine that echo control is not required for the outgoing circuit then one of the following actions can occur: .LP a) When the nature of connection indicators parameter field in the IAM indicates that an echo control device is already included: .LP \(em no change to the nature of connection indicators parameter field in the IAM is made; and .LP \(em an incoming half echo control device is reserved. .LP b) When the nature of connection indicator parameter field in the IAM does not indicate that an echo control device is already included: .LP \(em no additional action is required. .sp 1P .LP 2.8.2.3 \fIActions at the destination exchange\fR .sp 9p .RT .PP See \(sc 2.8.3.1 below. .RT .sp 2P .LP 2.8.3 \fIBackward direction\fR .sp 1P .RT .sp 1P .LP 2.8.3.1 \fIActions at the destination exchange\fR .sp 9p .RT .PP Upon the receipt of an IAM with the indication \*Qoutgoing half echo control device included\*U in the nature of connection indicators parameter field, the following action is taken: .RT .LP \(em an incoming half echo control device is enabled; and .LP \(em 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. .bp .PP 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. .sp 1P .LP 2.8.3.2 \fIActions at an intermediate exchange\fR .sp 9p .RT .PP Upon receipt of the first backward message (i.e.\ ACM or connect or call progress) in response to an IAM with echo control indication, then one of the following actions can occur: .RT .LP a) When the backward call indicators parameter field indicates that an incoming half echo control device is not already included: .LP \(em the reserved incoming half echo control device is included; and .LP \(em the echo control device indicator in the backward call indicators parameter field is set. .LP b) When the backward call indicators parameter field indicates that an incoming half echo control device is already included: .LP \(em the reserved incoming half echo control is released; and .LP \(em no change to the backward call indicators parameter field in the backward message is made. .sp 1P .LP 2.8.3.3 \fIActions at the originating exchange\fR .sp 9p .RT .PP No additional action is required. .RT .sp 2P .LP 2.9 \fINetwork features\fR .sp 1P .RT .sp 1P .LP 2.9.1 \fIAutomatic repeat attempt\fR .sp 9p .RT .PP 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 \(sc\ 2.3.4): .RT .LP i) on detection of dual seizure (at the non\(hycontrol exchange) (see\ \(sc\ 2.10.1.4); .LP ii) on receipt of the blocking message after sending an address message and before any backward message has been received (see\ \(sc\ 2.9.2); .LP iii) on receipt of a reset circuit message after sending an address message and before a backward message has been received [see\ \(sc\ 2.10.3.1\ e)]; .LP iv) on failure of continuity\(hycheck, when a continuity check is performed; .LP v) on receipt of an unreasonable message during call set up (see\ \(sc\ 2.10.5). .sp 1P .LP 2.9.2 \fIBlocking and unblocking of circuits and circuit groups\fR .sp 9p .RT .PP The blocking (unblocking) message and the circuit group blocking (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. .PP Since the circuits served by the ISDN user part have both\(hyway 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 unblocking acknowledgement message respectively. The acknowledgement is not sent until the appropriate action\ \(em\ either blocking or unblocking\ \(em\ has been taken. The release message should not override 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. .bp .RT .sp 1P .LP 2.9.2.1 \fIOther actions on receipt of a blocking message\fR .sp 9p .RT .PP 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 sending the blocking acknowledgement message and will not seize that circuit for subsequent calls. .PP If the blocking message is received: .RT .LP \(em 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 .LP \(em after an intial address message has been received for that circuit beforehand, .LP the exchange will not seize that circuit for subsequent calls. .PP The fact that the circuit is engaged on a call will not delay transmission of the blocking (unblocking) acknowledgement message. .PP If a blocking message is sent and subsequently an initial address message is received in the opposite direction, the following action is taken: .RT .LP \(em 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; .LP \(em for calls other than test calls, the blocking message must be returned and the initial address message discarded. .PP When a circuit is blocked by use of the blocking message the maintenance system should be informed at both ends of the circuit. .sp 1P .LP 2.9.2.2 \fICircuit group blocking and unblocking messages\fR .sp 9p .RT .PP The following circuit group blocking (unblocking) messages and their corresponding acknowledgement messages are provided: .RT .LP \(em maintenance oriented circuit group blocking (unblocking) message; .LP \(em hardware failure oriented circuit group blocking (unblocking) message; .PP The circuits to be blocked (unblocked) are indicated in the status field. .PP The maximum number of circuits to be blocked (unblocked) with one circuit group blocking (unblocking) message is limited to\ 32. .PP A received circuit group blocking (unblocking) acknowledgement message has to match in the parameter value of the circuit identification 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. .PP 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. .PP Some of the circuit identification code values covered by the range field of a circuit group blocking (unblocking acknowledgement) 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 allocated to the ISDN user part. In particular the circuit identification code value indicated in the label of a message must be allocated to a circuit. .PP 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 message. .PP The maintenance blocked state set by maintenance oriented circuit 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. .PP 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. .bp .PP For the circuits blocked for maintenance reasons the same conditions apply and the same actions have to be taken as described in\ \(sc\ 2.9.2.1. .PP For the circuits seized by ongoing calls or call attempts and blocked for reasons of harware failure the following actions will be taken: .RT .LP \(em all interconnected circuits have to be released by the appropriate messages; .LP \(em the affected circuits are set to the condition \*Qidle hardware blocked\*U without any exchange of release messages. .PP The fact that a circuit is engaged on a call will not delay the transmission of the corresponding circuit group blocking (unblocking) acknowledgement message. .PP The hardware blocked state can only be removed by a hardware failure oriented circuit group unblocking message. .PP For all instances of circuit group blocking the maintenance system should be notified at both ends of the circuit(s). .RT .sp 1P .LP 2.9.2.3 \fIAbnormal blocking and circuit group blocking procedures\fR .sp 9p .RT .PP The following procedures are designed to cover abnormal cases which may occur in the circuit group blocking/unblocking procedures. .RT .LP 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. .LP 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 circuits are given in the status field of the corresponding circuit group unblocking acknowledgement message which will be sent in response. .LP 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) indication 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. .LP 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 concerned (see\ \(sc\ 2.10.4). The same rule applies to the unblocking procedures. .LP v) If a circuit group blocking acknowledgement message 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. .LP iv) If a circuit group unblocking acknowledgement message in response to a group unblocking message is received containing 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. .LP vii) If a circuit group blocking acknowledgment message which is not expected as an acknowledgent for any circuit group blocking message is received: .LP \(em relating to circuits which all are in the status locally blocked the received circuit group blocking acknowledgement will be discarded; .LP \(em relating to circuits part or all of which are not in the status locally blocked then a circuit group unblocking message will be sent for the relevant circuits. .bp .LP viii) If a circuit group unblocking acknowledgement message which is not expected as an acknowledgement for any circuit group unblocking message is received: .LP \(em relating to circuits none of which is in the status locally blocked then the circuit group unblocking acknowledgement message will be discarded; .LP \(em relating to circuits part or all of which are locally blocked then a circuit group blocking message will be sent for the relevant circuits. .LP ix) If a circuit group blocking (unblocking) message or a circuit group blocking (unblocking) acknowledgement message refers to status changes for more than\ 32 circuits the receiving exchange may discard that message. .LP x) If a blocking message is received for a blocked circuit, a blocking acknowledgement message will be sent. .LP xi) If an unblocking message is received for an unblocked circuit, an unblocking acknowledgement message will be sent. .LP xii) If a blocking acknowledgement message, which is not expected as an acknowledgement for a blocking message, is received: .LP \(em relating to a circuit which is locally blocked, the blocking acknowledgement message is discarded; .LP \(em relating to a circuit which is not locally blocked, then an unblocking message will be sent; .LP xiii) If an unblocking acknowledgement message, which is not an expected response to an unblocking message, is received: .LP \(em relating to a circuit which is not locally blocked, the received unblocking acknowledgement message is discarded; .LP \(em relating to a circuit which is locally blocked then a blocking message will be sent. .LP 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 processed 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. .sp 2P .LP 2.9.3 \fICircuit group query\fR .sp 1P .RT .sp 1P .LP 2.9.3.1 \fIGeneral\fR .sp 9p .RT .PP The circuit group query test allows an exchange to audit the state of a circuit on a demand or routine basis. .PP The value N of the range field of the circuit group query message, 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. .RT .sp 1P .LP 2.9.3.2 \fIInterpretation of circuit states\fR .sp 9p .RT .PP For the purposes of circuit query procedures, there are states which are classified into four major categories, as follows: .RT .LP 1) unequipped and transient conditions, .LP 2) call processing states, .LP 3) maintenance blocking states, .LP 4) hardware blocking states. .PP The two states \*Qunequipped\*U and \*Qtransient\*U do not overlap with other states. .PP Call processing states include: .RT .LP 1) idle, .LP 2) circuit incoming busy, .LP 3) circuit outgoing busy. .PP Maintenance blocking states include: .LP 1) unblocked, .LP 2) remotely blocked, .LP 3) locally blocked, .LP 4) locally and remotely blocked. .bp .PP Hardware blocking states include: .LP 1) unblocked, .LP 2) remotely blocked, .LP 3) locally blocked, .LP 4) locally and remotely blocked. .PP A circuit is \*Qunequipped\*U 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. .PP The \*Qtransient\*U state refers to any transient call processing or maintenance states. .PP Call processing is in a transient state .RT .LP 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 .LP b) after having sent a release message and waiting for the release complete message. .PP 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. .PP The circuit state is also considered transient as long as a circuit (group) reset message has not been acknowledged. .PP The \*Qidle\*U state is a call\(hyprocessing state of an equipped, non\(hybusy circuit. The \*Qcircuit incoming busy\*U or \*Qcircuit outgoing busy\*U refers to a stable call processing state. .PP The hardware or maintenance \*Qremotely blocked\*U state refers to the state marked by the exchange when the far\(hyend exchange initiates blocking. The maintenance blocking state can co\(hyexist with \*Qidle\*U, \*Qcircuit incoming busy\*U, or \*Qcircuit outgoing busy\*U state. The hardware blocking state can only co\(hyexist with the \*Qidle\*U call processing state, as calls are immediately released when hardware blocking is invoked. .PP The hardware or maintenance \*Qlocally blocked\*U state refers to the state marked by the exchange when it initiated blocking to the far\(hyend exchange and the proper acknowledgement was received. The maintenance blocking state can co\(hyexist with \*Qidle\*U, \*Qcircuit incoming busy\*U, or \*Qcircuit outgoing busy\*U state. The hardware blocking state can only co\(hyexist with the \*Qidle\*U call processing state, as calls are immediately released when hardware blocking is invoked. .PP 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 (T\d3\\d4\u\ 12\(hy15 seconds) expires, maintenance systems should be informed. .PP 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. .PP 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. .RT .sp 2P .LP 2.10 \fIAbnormal conditions\fR .sp 1P .RT .sp 1P .LP 2.10.1 \fIDual seizure\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 2.10.1.1 \fIUnguarded interval\fR .sp 9p .RT .PP The exchange must detect dual seizure and take action as defined in \(sc\ 2.10.1.4. .RT .sp 1P .LP 2.10.1.2 \fIDetection of dual seizure\fR .sp 9p .RT .PP 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. .bp .RT .sp 1P .LP 2.10.1.3 \fIPreventive action\fR .sp 9p .RT .PP 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\(hywork satisfactorily. .PP 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. .RT .sp 1P .LP \fIMethod 1\fR .sp 9p .RT .PP An opposite order of selection is used at each exchange of a bothway circuit group. .RT .sp 1P .LP \fIMethod 2\fR .sp 9p .RT .PP Each exchange of a bothway circuit group has priority access to the group of circuits which it is controlling (see \(sc\ 2.10.1.4). Of this group the circuit which has been released the longest is selected (first\(hyin, first\(hyout). In addition each exchange of a bothway circuit group has non\(hypriority access to the group of circuits which it is non\(hycontrolling. Of this group the latest released circuit is selected (last\(hyin, first\(hyout) if all circuits in the group are busy. .PP For call control purposes a bothway circuit group can be subdivided into subgroups in an exchange. .PP It is necessary to take preventive action in cases where Signalling System No.\ 7 uses a signalling data link with long propagation time. .RT .sp 1P .LP 2.10.1.4 \fIAction to be taken on detection of dual seizures\fR .sp 9p .RT .PP Each exchange will control one half of the circuits in a bothway circuit group. On detection of a dual seizure, the call being processed by the control exchange for that circuit will be completed and the received initial address message will be disregarded. .PP Under these conditions, the call being processed by the control exchange will be allowed to mature. The call being processed by the non\(hycontrol exchange will be backed off and the switch\(hypath released. A release message will not be sent. The non\(hycontrol exchange will make an automatic repeat attempt on the same or on an alternative route. .PP For the purpose of resolution of dual seizure on bothway circuits, the exchange with the higher signalling point code will control all even\(hynumbered circuits (circuit identification code) and the other exchange the odd\(hynumbered circuits. The designation of control may also be used for maintenance system purposes. .RT .sp 1P .LP 2.10.2 \fITransmission alarm handling for digital inter\(hyexchange\fR \fIcircuits\fR .sp 9p .RT .PP 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 persist. .RT .sp 1P .LP 2.10.3 \fIReset of circuits and circuit groups\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 2.10.3.1 \fIReset circuit message\fR .sp 9p .RT .PP If only a few circuits are concerned a reset circuit message should be sent for each affected circuit. .PP On receipt of a reset circuit message the receiving (unaffected) exchange will: .RT .LP a) if it is the incoming or outgoing exchange on a connection in any state of call set\(hyup or during a call, accept the message as a release message and respond by sending a release complete message, after the circuit has been made idle; .bp .LP b) if the circuit is in the idle condition, accept the message as a release message and respond by sending a release complete message; .LP c) if it has previously sent a blocking message, or if it is unable to release the circuit as described above, respond by the blocking message. If an incoming or outgoing call is in progress, this call should be released and the circuit returned to the \*Qidle, blocked\*U 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 \(sc\ 2.10.4 should be followed; .LP d) if it has previously received a blocking message, respond by releasing a possible outgoing call or call attempt on the circuit, remove the blocked condition, restore the circuit to the idle state, and respond with a release complete message; .LP 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; .LP 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; .LP g) clear any interconnected circuits by the appropriate method (e.g.\ release). .PP The affected exchange will then reconstruct its memory according to the received response(s) to the reset circuit and respond to the message(s) in the normal way, i.e.\ blocking acknowledgement message in response to a blocking message. .PP If no release complete message is received in acknowledgement to the reset circuit message before 4\(hy15 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. .RT .sp 1P .LP 2.10.3.2 \fICircuit group reset message\fR .sp 9p .RT .PP 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. .PP The maximum number of circuits to be reset with a circuit group reset message is limited to\ 32. .PP On receipt of a circuit group reset message the receiving (unaffected) exchange will: .RT .LP a) restore the circuits to the idle state; .LP b) send the appropriate circuit group blocking message(s) if it had previously sent a hardware failure oriented circuit group blocking message; .LP c) respond by a circuit group reset acknowledgement message in which the status indicator bits of the circuits available for service or blocked for reasons of hardware failure are coded\ 0 and the status indicator bits of all circuits blocked for maintenance reasons are set to\ 1; .LP 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; .LP e) if a circuit group reset message is received concerning circuits for which a circuit group reset message or reset circuit message(s) have been sent the circuits concerned are made available for service after receipt of the appropriate acknowledgement message; .LP f ) appropriate messages should be sent on interconnected circuits to release them. .PP The affected exchange will then reconstruct its memory according to the possibly received circuit group blocking messages and the received circuit group reset acknowledgement message. It will respond to the possibly received circuit group blocking messages in the normal way. .PP If no acknowledgement to a circuit group reset message is received before 4\(hy15\ seconds the circuit group reset message should be repeated. If an acknowledgement for the circuit group reset message is not received within 1\ minute after sending the initial circuit group reset message the maintenance system should be notified. However, the sending of the circuit group reset message should continue at 1\ minute intervals until maintenance intervention occurs. .bp .PP A correct acknowledgement should match the original circuit group reset message in range and circuit identification code indicated 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\(hyUP. .PP 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\(hyUP. .RT .sp 1P .LP 2.10.3.3 \fIAbnormal circuit group reset message procedures\fR .sp 9p .RT .LP i) If a circuit group reset message is received indicating reset of more circuits than allowed by the receiving exchange, it is discarded. .LP ii) If a circuit group reset acknowledgement message is received which is not a correct response to a sent circuit group reset message, it is discarded. .LP 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\(hyUP, the message is discarded. .sp 1P .LP 2.10.4 \fIFailure in the blocking/unblocking sequence\fR .sp 9p .RT .PP 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\(hy15\ seconds (T\d1\\d2\u). (See \(sc\ 2.9.2). .PP If the appropriate acknowledgement is not received within a period of one minute (T\d2\\d0\u) after sending the initial blocking (unblocking) message or group blocking (unblocking) message, the maintenance system should be alerted, the repetition of the blocking (unblocking) message or circuit group blocking (unblocking) message should be continued at one minute intervals until maintenance intervention occurs and the circuit(s) taken out of (returned to) service as appropriate. .RT .sp 1P .LP 2.10.5 \fIReceipt of unreasonable and unrecognized signalling\fR \fIinformation messages\fR .sp 9p .RT .PP The message transfer part of the signalling system will avoid missequencing, or double delivery, of messages with a high reliability (Recommendation\ Q.706, \(sc\ 2). However, undetected errors at the signalling link level and exchange malfunctions may produce signalling information messages that are either ambiguous or inappropriate. .PP The procedures listed below do not include the procedures for the blocking, circuit group blocking and the circuit group reset; these are covered in \(sc\(sc\ 2.9.2.3 and 2.10.3.3 respectively. .RT .sp 1P .LP 2.10.5.1 \fIHandling of unexpected messages\fR .sp 9p .RT .PP An unexpected message is one which is recognized and valid but has been received in the wrong phase of the call. .PP In order to resolve possible ambiguities in the state of a circuit when unexpected messages are received the following will apply: .RT .LP a) if a release message is received relating to an idle circuit it will be acknowledged with a release complete message; .LP b) if a release complete message is received relating to an idle circuit it will be discarded; .LP 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); .LP d) if other unreasonable signalling information is received, the following actions will be undertaken: .LP \(em if the circuit is idle, the reset circuit message is sent; .LP \(em if the circuit has been seized by a call, after receipt of a backward message required for the call set\(hyup, the unreasonable signalling information is discarded; .LP \(em if the circuit has been seized by a call, before receipt of a backward message required for the call set\(hyup, 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; .bp .LP 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\(hyup 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. .PP Except in certain cases (see \(sc\ 2.10.1) any other unexpected messages received will be discarded. If the discarding of the signalling information prevents a call from being completed, that call will eventually be released by the expiry of a time out. .sp 1P .LP 2.10.5.2 \fIGeneral requirements on receipt of unrecognized\fR \fIsignalling information messages and parameters\fR .sp 9p .RT .PP 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. .PP The procedure to be used on receipt of unrecognized information, may use one of the following messages: .RT .LP \(em confusion, .LP \(em release, .LP \(em release complete, .LP \(em facility reject. .PP 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 containing either the unrecognized message type code or the unrecognized parameter name code (this information will be returned as soon as possible): .LP \(em unrecognized message, .LP \(em unrecognized parameter passed on (see Note), .LP \(em unrecognized parameter discarded (see Note). .PP \fINote\fR \ \(em\ In a confusion message these parameters are always followed by the parameter name code in the diagnostic field. .PP The procedures are based on the following assumptions: .RT .LP \(em Signalling for a facility completely provided between the originating and destination local exchanges will utilise one of the end\(hyto\(hyend methods defined in \(sc\ 3, i.e.\ such facilities do not have to be supported by transit exchanges. .LP \(em As a minimum, all implementations must recognize all messages specified in Table\ 1/Q.764. .LP \(em If an exchange receives a confusion, release, release complete or facility reject message indicating an unrecognized message parameter or parameter value received it assumes interworking with an exchange at a different functional level. .LP \(em Unrecognized parameters only refer to optional parameters since mandatory parameters will always be recognized by their location in a message. .PP 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 \*Qnormal, unspecified\*U. .PP The actions taken at an intermediate node, e.g.\ transit exchange on receipt of a confusion message will be dependent on the call state. .PP If an intermediate node, e.g.\ transit exchange, does not have the capability to take action on receipt of a facility reject message, it should pass the message transparently to the preceding or succeeding exchange. .PP Action taken on receipt of a release complete message with cause indicating unrecognized information may be as for the normal procedures. .bp .RT .ce \fBH.T. [T2.764]\fR .ce TABLE\ 1/Q.764 .ce \fBMinimum messages recognized\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(150p) . Address complete .T& lw(150p) . Answer .T& lw(150p) . Blocking .T& lw(150p) . Blocking acknowledgement .T& lw(150p) . Call progress .T& lw(150p) . Circuit group blocking .T& lw(150p) . { Circuit group blocking acknowledgement } .T& lw(150p) . Circuit group reset .T& lw(150p) . { Circuit group reset acknowledgement } .T& lw(150p) . Circuit group unblocking .T& lw(150p) . { Circuit group unblocking acknowledgement } .T& lw(150p) . Connect .T& lw(150p) . Continuity .T& lw(150p) . Confusion .T& lw(150p) . Facility reject .T& lw(150p) . Facility request .T& lw(150p) . Forward transfer .T& lw(150p) . Information .T& lw(150p) . Information request .T& lw(150p) . Initial address .T& lw(150p) . Release .T& lw(150p) . Release complete .T& lw(150p) . Reset circuit .T& lw(150p) . Resume .T& lw(150p) . Subsequent address .T& lw(150p) . Suspend .T& lw(150p) . Unblocking .T& lw(150p) . Unblocking acknowledgement _ .TE .nr PS 9 .RT .ad r \fBTable [T2.764], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 2.10.5.3 \fIProcedures for the handling of the unrecognized\fR \fImessages or parameters\fR .sp 9p .RT .PP A confusion message must not be sent in response to a received confusion message. .RT .LP a) \fIUnrecognized mesages\fR .LP If an unrecognized message is received at an exchange, the message is discarded and a confusion message returned. The confusion message will include the cause value \*Qunrecognized message\*U followed by a diagnostic field containing the message type code. .LP \fINote\fR \ \(em\ 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. .LP b) \fIUnrecognized parameters\fR .LP If an exchange receives and detects an unrecognized parameter the actions taken will be dependent on whether the call can be progressed or not. .LP If the call cannot be processed a release message is sent containing the cause \*Qunrecognized parameter discarded\*U followed by the parameter name code in the diagnostic field. .LP 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. .LP If the unrecognized parameter is discarded a confusion message is sent to the exchange from which the unrecognized parameter was received. The confusion message contains the cause \*Qunrecognized parameter discarded\*U. .bp .LP If the unrecognized parameter is passed on, a confusion message may be sent to the exchange from which the unrecognized parameter was received. .LP If a facility request message is received with unrecognized parameters the message is discarded and a facility reject message is returned including the cause \*Qunrecognized parameter discarded\*U followed by the parameter name code in the diagnostic field. .LP If a release message is received with an unrecognized parameter, a release complete message is returned including the cause \*Qunrecognized parameter passed on\*U followed by the parameter name code in the diagnostic field. .LP c) \fIUnrecognized parameter values\fR .LP If an exchange receives and detects a recognized parameter but the contents are unrecognized, then the actions taken are as defined below: .LP i) \fIUnrecognized mandatory parameter values\fR .LP If an exchange receives and detects an unrecognized mandatory parameter value, the actions taken will be dependent on whether the call can be progressed or not. .LP If the call can be progressed, the unrecognized mandatory parameter value shall be passed on unmodified. A confusion message with the cause \*Qunrecognized parameter passed on\*U is sent to the exchange from which the unrecognized mandatory parameter value was received. .LP If the call cannot be progressed or the unrecognized mandatory parameter value cannot be passed unmodified, a release message with the cause \*Qunrecognized parameter discarded\*U followed by the parameter name in the diagnostic field is returned. .LP If a facility request message is received with an unrecognized mandatory parameter value(s) the message is discarded and a facility reject message is returned including the cause \*Qunrecognized parameter discarded\*U followed by the parameter name code in the diagnostic field. .LP If a release message is received with an unrecognized mandatory parameter value, a release complete message is returned including the cause \*Qunrecognized parameter passed on\*U followed by the parameter name code in the diagnostic field. .LP ii) \fIUnrecognized optional parameter values\fR .LP 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. .LP 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 unmodified, a confusion message with the cause \*Qunrecognized parameter passed on\*U may be sent to the exchange from which the unrecognized optional parameter value was received. If the unrecognized parameter value has been discarded, a confusion message shall be returned. .LP If the call cannot be progressed, a release message with the cause \*Qunrecognized parameter discarded\*U followed by the parameter name in the diagnostic field shall be returned. .LP If a facility request message is received with an unrecognized optional parameter value(s) the message is discarded and a facility reject message is returned including the clause \*Qunrecognized parameter discarded\*U followed by the parameter name code in the diagnostic field. .LP If a release message is received with an unrecognized optional parameter value, a release complete message is returned including the cause \*Qunrecognized parameter passed on\*U followed by the parameter name code in the diagnostic field. .sp 1P .LP 2.10.6 \fIFailure to receive a \*Qrelease complete\*U message \(em time T\fI\d\fI1\fR\u \fIand T\fI\d\fI5\fR\u .sp 9p .RT .PP If a release complete message is not received in response to a release message before time (T\d1\u) the exchange will retransmit the release message. .PP On retransmitting the initial release message, a one minute timer (T\d5\u) is started. If no release complete message is received on the expiry of this timer (T\d5\u), the exchange shall: .RT .LP i) send a reset circuit message; .LP ii) alert the maintenance system; .bp .LP iii) remove the circuit from service; .LP iv) continue the sending of the reset circuit message at 1\ minute intervals until maintenance action occurs. .sp 1P .LP 2.10.7 \fIFailure to receive a response to an information request message\fR .sp 9p .RT .PP If a response is not received in response to an information request message before timer (T\d2\u) expires, the exchange will release the connection and the maintenance system may be informed. .RT .sp 2P .LP 2.10.8 \fIOther failure conditions\fR .sp 1P .RT .sp 1P .LP 2.10.8.1 \fIInability to release in response to a release message\fR .sp 9p .RT .PP 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. .PP Upon receipt of the blocking acknowledgement message, the release complete message is sent in acknowledgement of the release message. .RT .sp 1P .LP 2.10.8.2 \fICall\(hyfailure\fR .sp 9p .RT .PP The call\(hyfailure indication is sent in a release message (\(sc\ 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. .RT .sp 1P .LP 2.10.8.3 \fIAbnormal release conditions\fR .sp 9p .RT .PP If the conditions for normal release as covered in \(sc\ 2.3 are not fulfilled, release will take place under the following conditions: .RT .LP a) \fIOutgoing international or national controlling exchange\fR .LP The exchange shall: .LP \(em release all equipment and the connection on failure to meet the conditions for normal release of address and routing information before 20\(hy30\ seconds after sending the latest address message; .LP \(em release all equipment and release the connection on failure to receive an answer message within time (T\d6\u) specified in Recommendation\ Q.118 after the receipt of the address complete message. .LP b) \fIIncoming international exchange\fR .LP 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: .LP \(em on failure to receive a continuity message if applicable before 10\(hy15\ seconds (T\d8\u) after receipt of the initial address message; or .LP \(em on failure to receive a backward signal from a national network (where expected) before 20\(hy30\ seconds (T\d7\u) after receipt of the latest address message; or .LP \(em on receipt of a release message after an address complete message has been generated. .LP The procedures for the release message are detailed in \(sc\ 2.2.2. .LP c) \fITransit exchange\fR .LP The exchange shall release all equipment and the connection and send back the release message in the following cases: .LP \(em on failure to receive a continuity message if applicable before 10\(hy15\ seconds after receipt of the initial address message; or .LP \(em on failure to meet the conditions for normal release as covered in \(sc\ 2.3 before 20\(hy30 seconds after sending the latest address message; .LP The procedures for the release message are detailed in \(sc\ 2.2.2. .bp .sp 1P .LP 2.10.8.4\ \ If messages are lost during an end\(hyto\(hyend transfer, appropriate actions will be taken according to the type of end\(hyto\(hyend technique being used. .sp 9p .RT .LP 2.10.8.5\ \ For calls involving the SCCP, expiration of the call supervision timer (concerned with call set\(hyup) will result in the SCCP being notified of an error condition. .sp 1P .LP 2.10.9 \fITemporary Trunk Blocking (TTB)\fR (national use) .sp 9p .RT .PP 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. .RT .sp 2P .LP 2.10.10 \fITemporary trunk blocking\fR \fIbefore release of call (use\fR \fIof a discrete overload message)\fR .sp 1P .RT .sp 1P .LP 2.10.10.1 \fICharacteristics\fR .sp 9p .RT .PP When load control is invoked IAMs associated with non\(hypriority calls received on the circuits concerned are \*Qbacked\(hyoff\*U by return of the overload message in response to the IAM. Release of the circuit is then delayed by the unaffected node for a period, e.g. 2\ minutes, after which the circuit is cleared by normal release procedures. .PP Calls backed\(hyoff by overload messages may be processed on alternative routes, if available, by\(hypassing the affected nodes; if not they are released in the backward direction with reason (network) congestion. .PP Initial address messages marked as priority are not subject to the overload procedure; they are accepted by the affected node and processed as normal. .PP During the overload time\(hyout period the circuit concerned is not available for traffic from the affected node to the unaffected node. .PP Recognition of the overload situation does not involve the examination of existing messages for detection of an optional TTB parameter. .RT .sp 2P .LP 2.10.10.2 \fIProcedures\fR .sp 1P .RT .sp 1P .LP a) \fINon priority call set\(hyup to an exchange subject\fR \fIto load control\fR .sp 9p .RT .LP i) \fIActions at originating exchange\fR .LP In an originating exchange, calls originating from non\(hypriority class lines will not set the calling party category parameter field to \*Qsubscriber with priority\*U in the outgoing IAM. .LP ii) \fIActions at an intermediate or terminating exchange\fR .LP 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. .LP iii) \fIActions on receipt of the overload message\fR .LP At an originating, or intermediate exchange receipt of the overload message shall cause the following actions: .LP \(em 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. .LP \(em The call attempt will be continued on an alternative route if available. If not the call will be released in the backward direction with cause \*Qcongestion\*U. .sp 1P .LP b) \fIPriority call set\(hyup to an exchange subject to load\fR \fIcontrol\fR .sp 9p .RT .LP i) \fIActions at originating exchange\fR .LP In an originating exchange, calls originating from priority class lines will set the calling party category parameter field to \*Qsubscriber with priority\*U in the outgoing IAM. .LP ii) \fIActions at intermediate or terminating exchange\fR .LP At an intermediate or terminating exchange where load control has been invoked, the priority call will override the load control and the call will continue in its attempt to be set up. .bp .sp 2P .LP 2.11 \fIISDN user part signalling congestion control\fR .sp 1P .RT .sp 1P .LP 2.11.1 \fIGeneral\fR .sp 9p .RT .PP On receipt of congestion indication primitives (see also Recommendation\ Q.704 \(sc\ 11.2.3) the ISDN user part should reduce traffic load (e.g.\ call attempts) into the affected direction in several steps. .RT .sp 1P .LP 2.11.2 \fIProcedures\fR .sp 9p .RT .PP 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 T\d2\\d9\uand T\d3\\d0\uare started. During T\d2\\d9\uall 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 T\d2\\d9\u, but still during T\d3\\d0\u, will decrease the traffic load by one more step and restart\ T\d2\\d9\uand\ T\d3\\d0\u. This stepwise reduction of the ISDN user part signalling traffic is continued until maximum reduction is obtained by arriving at the last step. If T\d3\\d0\uexpires (i.e.\ no congestion indication primitives having been received during the T\d3\\d0\uperiod) traffic will be increased by one step and T\d3\\d0\uwill be restarted unless full traffic load has been resumed. .PP Timers T\d2\\d9\uand T\d3\\d0\uhave the following values: .RT .LP T\d2\\d9\u\ =\ 300\(hy600 ms, .LP T\d3\\d0\u\ =\ 5\(hy10 s. .PP 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. .sp 1P .LP 2.12 \fIAutomatic congestion control\fR .sp 9p .RT .PP Automatic Congestion Control (ACC) is used when an exchange is in an overload condition (see also Recommendation\ Q.542). Two levels of congestion are distinguished, a less severe congestion threshold (congestion level\ 1) and a more severe congestion threshold (congestion level\ 2). .PP If either of the two congestion thresholds are reached, an automatic congestion level parameter is added to all release messages 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. .PP If the overloaded exchange returns to a normal traffic load it will cease including automatic congestion level parameters in release messages. .PP The adjacent exchanges then, after a predetermined time, automatically return to their normal status. .RT .sp 1P .LP 2.12.1 \fIReceipt of a release message containing an automatic\fR \fIcongestion level parameter\fR .sp 9p .RT .PP 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 information and the circuit identification to which the release message applies. .PP 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. .RT .sp 1P .LP 2.12.2 \fIActions taken during\fR \fIoverload\fR .sp 9p .RT .PP 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. .bp .PP The network management/overload control function will indicate which congestion level (1\ or\ 2) to code in the automatic congestion level parameter. .PP 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. .RT .sp 1P .LP 2.13 \fIUnequipped circuit identification code message\fR (national option) .sp 9p .RT .PP 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 supervision 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. .PP 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: .RT .LP 1) remove the indicated circuit from the service and report the circuit to the maintenance system for maintenance action; .LP 2) re\(hyattempt 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). .PP 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 maintenance system for maintenance action. .PP 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). .PP An exchange receiving an unequipped CIC message after having transmitted a circuit group supervision message removes the indicated 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. .RT .LP .rs .sp 20P .ad r Blanc .ad b .RT .LP .bp