5i' Figure 1/Q.724, p. 1 Figure 2/Q.724, p. 2 Figure 3/Q.724 (feuillet 1 sur 7), p. 3 Figure 3/Q.724 (feuillet 2 sur 7), p. 4 Figure 3/Q.724 (feuillet 3 sur 7), p. 5 Figure 3/Q.724 (feuillet 4 sur 7), p. 6 Figure 3/Q.724 (feuillet 5 sur 7), p. 7 Figure 3/Q.724 (feuillet 6 sur 7), p. 8 Figure 3/Q.724 (feuillet 7 sur 7), p. 9 Figure 4/Q.724, p. 10 Figure 5/Q.724, p. 11 Figure 6/Q.724 (feuillet 1 sur 2), p. 12 Figure 6/Q.724 (feuillet 2 sur 2), p. 13 Figure 7/Q.724, p. 14 Figure 8/Q.724 (feuillet 1 sur 4), p. 15 Figure 8/Q.724 (feuillet 2 sur 4), p. 16 Figure 8/Q.724 (feuillet 3 sur 4), p. 17 Figure 8/Q.724 (feuillet 4 sur 4), p. 18 Figure 9/Q.724, p. 19 Figure 10/Q.724, p. 20 Figure 11/Q.724, p. 21 Figure 12/Q.724, p. 22 Figure 13/Q.724, p. 23 Figure 14/Q.724 (feuillet 1 sur 2), p. 24 Figure 14/Q.724 (feuillet 2 sur 2), p. 25 Figure 15/Q.724 (feuillet 1 sur 2), p. 26 Figure 15/Q.724 (feuillet 2 sur 2), p. 27 Figure 16/Q.724 (feuillet 1 sur 2), p. 28 Figure 16/Q.724 (feuillet 2 sur 2), p. 29 Figure 17/Q.724 (feuillet 1 sur 2), p. 30 Figure 17/Q.724 (feuillet 2 sur 2), p. 31 Figure 18/Q.724 (feuillet 1 sur 2), p. 32 Figure 18/Q.724 (feuillet 2 sur 2), p. 33 Figure 19/Q.724 (feuillet 1 sur 2), p. 34 Figure 19/Q.724 (feuillet 2 sur 2), p. 35 References [1] CCITT Recommendation Sending sequence of numerical (or address) signals , | Rec. Q.107. [2] CCITT Recommendation Performance requirements , | Rec. Q.504. [3] CCITT Recommendation Special release arrangements , | Rec. Q.118. [4] CCITT Recommendation Overflow-alternative, routing-rerouting automatic repeat attempt , | Rec. Q.12. [5] CCITT Recommendation Interruption control , | Rec. Q.416. Recommendation Q.725 SIGNALLING PERFORMANCE IN THE TELEPHONE APPLICATION 1 Introduction This Recommendation gives the requirements of the telephone application of Signalling System No. 7. In Recommendation Q.706, the Message Transfer Part performance is described. The Message Transfer Part is the basis of the tele- phone application of Signalling System No. 7 and provision of a signalling network to serve the telephone service must take account of the performance of the Message Transfer Part and the require- ments of the telephone application. For example, taking account of the message transfer times detailed in Recommendation Q.706 and the requirements for message transfer times between two telephone exchanges, a figure may be derived for the total permissible number of signalling links in signalling relations in tandem for a partic- ular call. 2 Unsuccessful calls due to signalling malfunction The proportion of calls that are unsuccessful due to signal- ling malfunction should be less than 1 in 105. By means of error detection (see Recommendation Q.703) as well as transmission fault indication (see Recommendations G.732 [1] and G.733 [2]), it is ensured that, overall, not more than one error in 108 of all signal units transmitted is accepted and will cause false operation. Unsuccessful calls may be caused by undetected errors, loss of messages or messages delivered out of sequence (during emergency situations within the signalling network) and may result in: - incomplete call set-up, - misrouted calls (e.g. connection of wrong numbers), - calls routed correctly but mishandled (e.g. false clearing). 3 Unavailability of a signalling route set The overall unavailability of a signalling route set causing the unavailability of a signalling relation should not exceed a total of 10 minutes per year. Note - The availability of a signalling route set within a signalling network may be enhanced by replication of signalling links, signalling paths and signalling routes. 4 Labelling potential The label of the Telephone User Part of Signalling System No. 7 provides the potential to identify 16 | 84 signalling points and up to 4096 speech circuits for each signalling relation. 5 Cross-office transfer time 5.1 Functional reference points and transfer time com- ponents Figure 1/Q.725, p. 5.2 Definitions a) cross-office transfer time, Tvcvu Tc\duis the period which starts when the last bit of the signal unit leaves the incoming signalling data link and ends when the last bit of the signal unit enters the outgoing signalling data link for the first time. It also includes the queueing delay in the absence of disturbances but not the additional queueing delay caused by retransmission. b) user handling time, Tvhvu Th\duis the period which starts when the last bit of the message has entered the Telephone User Part and ends when the last bit of the derived message has left the Telephone User Part. 5.3 Queueing delay The formulae for the queueing delays are described in Recommendation Q.706, S 4.2. The telephone traffic model assumed is given in Table 1/Q.725, from which the proportion of signal messages may be obtained as shown in Table 2/Q.725. Using Table 2/Q.725, examples of queueing delays are calculated as shown in Figures 2/Q.725 to 5/Q.725, where one call attempt per second per 64 kbit/s signalling data link may yield 0.00577 Erlang of the traffic loading of each channel. 5.4 Estimates for message transfer time The figures in Table 3/Q.725 are related to a signalling bit rate of 64 kbit/s. 5.5 Effect of retransmission As a consequence of correction by retransmission, not more than one in 104 signals should be delayed more than 300 ms as a long-term average. This requirement refers to each signalling link. This requirement is laid down in order to ensure satisfactory answer delays. H.T. [T10] TABLE 1/Q.725 Traffic model __________________________________________ Sending procedure "En bloc" Overlap __________________________________________ | | | | | | | | _______________________________________________________________________ Type of call AW SB CC AB AW SB CC AB _______________________________________________________________________ Percent calls 30 10 5 5 30 10 5 5 _______________________________________________________________________ { Others 112 3,5 2 3 0 3,5 2 3 2 _______________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AW Answered SB Subscriber busy and not answered CC Circuit conges- tion AB Abortive Note - The assumptions used in this model are chosen for illustra- tive purposes, and should not be considered to be typical. Tableau 1/Q.725 [T1.725], p. 37 Blanc H.T. [T2.725] TABLE 2/Q.725 Proportion of messages ___________________________________________________________________________ Length (bits) 176 152 128 112 104 Total ___________________________________________________________________________ { Messages per call in both directions } 0.45 0.5 0.45 2.0 2.9 6.3 ___________________________________________________________________________ Percent 7.1 | | | | | | | | 7.9| | | | | | | | 7.1 | | | | | | | | 31.7| | | | | | | | 46.0 | | | | | | | | 100 | ___________________________________________________________________________ { Mean message length (T m ) } 117.2 bits ___________________________________________________________________________ k 1 1.032 ___________________________________________________________________________ k 2 1.107 ___________________________________________________________________________ k 3 1.239 ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 2/Q.725 [T2.725], p. 38 Figure 2/Q.725, p. 39 Figure 3/Q.725, p. 40 Figure 4/Q.725, p. 41 Figure 5/Q.725, p. 42 H.T. [T3.725] TABLE 3/Q.725 lw(60p) | lw(60p) | lw(30p) | lw(30p) . Tableau 3/Q.725 [T3.725], p. 43 References [1] CCITT Recommendation Characteristics of primary PCM multiplex equipment operating at 2048 kbit/s , | Rec. G.732. [2] CCITT Recommendation Characteristics of primary PCM multiplex equipment operating at 1544 kbit/s , | Rec. G.733. Blanc MONTAGE: PAGE PAIRE = PAGE BLANCHE SECTION 2 ISDN SUPPLEMENTARY SERVICES Recommendation Q.730 ISDN SUPPLEMENTARY SERVICES 1 General 1.1 This Recommendation describes the signalling procedures for Supplementary Services to be used in conjunction with the ISDN User Part defined in Recommendations Q.761-764, Q.766 and the Tran- saction Capabilities Applications Part (TCAP) defined in Recommendations Q.771-774. Each Supplementary Service has been defined in separate sec- tions each containing the complete procedures encompassing both the ISDN User Part and the procedures to be used on the top of TCAP where appropriate. Each section contains a general paragraph giving details of the specific service with references to the Stage I and II descrip- tions defined in the relevant Recommendations of the I.200 and Q.80 Series. The call set-up procedures and the actions taken at originating exchanges, etc. are defined. Arrow diagrams showing the message flows for both successful and unsuccessful establishment of the service are generally included. The formats and codings aspects are not defined in this Recommendation but references are made to the appropriate ISDN User Part, TC or SCCP Recommendations. 1.2 Information request/response The "information request/response" message interchange described in the calling line identity supplementary services uses a general request/response mechanism (e.g. INR/INF messages) which can be used in the future for supplementary services not currently defined (see Recommendation Q.764). 1.3 Exceeding the maximum message length (e.g. ISDN User Part 272 octets) If for any reason the combination of basic plus supplementary service information causes the overall maximum length of the mes- sage (e.g. Initial Address Message) to be exceeded then the user-to-user supplementary service 1, if included, should be rejected (see S 2 covering interactions). The combination of other services which may cause the message length to be exceeded will depend on the call state and the requested service. 1.4 Layout of Recommendation Q.730 S 1 General S 2 User-to-user signalling (Note) S 3 Close user group S 4 Calling line identification (presentation and restriction) S 5 Direct dialling in S 6 Call forwarding (Note) S 7 Time-out table for supplementary services (requires further study) Note - The text for the explicit invocation of the user-to-user signalling has been included as Annex A. 2 User-to-user signalling service 2.1 General description of user-to-user service The user-to-user signalling supplementary service(s) provide(s) a means of communication between two users by using the ISDN User Part or SCCP protocols defined in Recommendations Q.711-714 and Q.761-764, 766. In order for the services to be usable, they also have to be provided in the access protocol. User-to-user signalling is used to exchange I.257 information between two users to provide the user-to-user services described in Recommendation I.257. This section is specific to Signalling System No. 7. The general description for services 1-3 may be found in the last mentioned Recommendation and the functional description in Recommendation Q.87. 2.1.1 User-to-user services Three user-to-user signalling services associated with circuit-switched calls that may be provided by the network users are: Service 1: user-to-user signalling exchanged during the set-up and clearing phases of a call, within ISDN User Part call set-up and release messages as defined in Recommendation Q.763; Service 2: user-to-user signalling exchanged during call set-up between the address complete or call progress messages and the answer or connect messages, within user-to-user information messages; and Service 3: user-to-user signalling exchanged while a call is in the active state, within user-to-user information messages. All three services may be used separately or in any combina- tion within a single call. As an option at call set-up, users may be able to specify whether the requested user-to-user signalling service(s) is(are) essential or non-essential for the call (i.e. whether the call should be completed or not if user-to-user infor- mation cannot be passed). Up to 128 octets of user information may be transferred in a message in each of the three services informa- tion parameter name, the protocol control indicator or the length octets. 2.1.2 Service request _________________________ During an interim period of time, networks may support a lesser number (e.g. 32 octets) due to protocol res- trictions; 32 octets will always be supported. Restric- tions may apply to calls requesting user-to-user infor- mation more than 32 octets. Service 1 may be requested implicitly by the presence of the user-to-user information parameter in the Initial Address Message. An implicit request is "non-essential" by default. Explicit requests of Service 1 and 2 must be in the Initial Address Message. Service 3 may be explicitly requested in the Ini- tial Address Message during call set-up. When there is an explicit request a single user-to-user indicators parameter will be used with one of the following indications for each of the three ser- vices: - no information; - requested, non-essential; - requested, essential. 2.1.3 Response (Confirmation) If explicit requests are used there should, in general, be explicit responses in a user-to-user indicators parameter with one of the following indications for each of the three services: - no information; - provided; - not provided. Implicit "not provided" responses occur when: - Service 1 has been implicitly requested and no user-to-user information is received in call set-up or release mes- sages; or - Service 1, 2 or 3 has been explicitly requested and there is no indication of acceptance or rejection from call control. 2.1.4 Flow control The exchange of user-to-user signalling is limited by flow control procedures provided on the access by either the user or network. The need for interexchange flow control procedures by the ISDN User Part for user-to-user signalling should be evaluated. 2.2 Procedures for user-to-user signalling associated with circuit-switched call The following sections only specify the signalling procedure used to implicitly invoke the Service 1. Signalling procedures defined to support the other services are specified in Annex A. 2.2.1 User-to-user signalling, Service 1 2.2.1.1 General characteristics Service 1 allows users to communicate with user-to-user sig- nalling by transferring user-to-user information within ISDN User Part messages during the call set-up and clearing phases. The user-to-user signalling service provided is not a guaranteed ser- vice. If for any reason the combination of the basic plus supple- mentary service information causes the overall maximum length of the message to be exceeded then if the User-to-user Signalling Ser- vice 1 is included, then the service should be rejected. 2.2.1.2 User-to-user signalling in the call set-up phase - implicit service request Procedures for call set-up are as described in Recommendation Q.764, S 2, with the following changes: Service 1 may be invoked by sending the user-to-user informa- tion parameter of variable length that is specified in Recommendation Q.763, S 3.34 in an Initial Address Message that is requested in a call set-up request from call control. This informa- tion parameter is transported across the network and delivered unchanged to the terminating call control for the called user. The user-to-user indicators parameter will not be sent. The reception of a user-to-user information parameter in a call set-up or release request from the terminating call control is an implicit indication of the acceptance of Service 1. The user or network may not be able to interpret incoming user-to-user information. In such situations, the user should dis- card this information without disrupting normal call handling. No specific signalling is provided by the network to accommodate this situation. 2.2.1.3 Interworking In the case of interworking with a non-ISDN network, the "interworking" protocol control information will be returned to the originating exchange in the first appropriate message, e.g. an Address Complete Message. Two ISDN networks that interwork may have to retain knowledge of the service request until it is clear whether both can support the service. 2.2.1.4 Rejection of implicit service requests Networks that cannot provide the service requested may not return a rejection indication. 2.2.1.5 User-to-user signalling in the call clearing phase A user-to-user information parameter may be included in the Release Message. The user-to-user information parameter received at the distant exchange in the Release Message is passed to the call control for the remote user. In the case of simultaneous clearing of the call, the Release Message may not reach the distant local exchange and the user-to-user information will be lost. 2.2.1.6 Message flow diagrams The message flow diagrams are shown in Figure 1B/FQ.730 as well as the use of user-to-user signalling service 1 when impli- citly requested in a point-to-point configuration. The messages shown with dashed lines are not part of the ISDN User Part protocol and are for information only. For detailed information on the access protocol user-to-user procedures the ISDN access protocol Recommendation should be examined. Figure 1/Q.730, p. 44 2.2.2 Interaction with other supplementary services 2.2.2.1 Call forwarding services Interactions with the call forwarding services are shown in the call forwarding protocol sections. 2.2.2.2 Call waiting service Interactions with the call waiting service are shown in the call waiting protocol sections. (Call waiting is for further study.) 2.2.2.3 Other services There are no known interactions with services other than those listed. 2.2.2.4 State transition diagrams The state transition diagrams may be found in Stage 2 descrip- tions of the user-to-user service. 3 Closed user group (CUG) 3.1 General The closed user group (CUG) supplementary service enables a group of users to intercommunicate only among themselves or, as required, one or more users may be provided with incoming/outgoing access to users outside the group. The stage I definition of the CUG service is given in Recommendation I.255, and its stage II service definition including network functions are given in Recommendation Q.85. The realization of the CUG facilities is done by the provision of interlock codes and is based on various validation checks as defined in Q.85 at call set-up, determining whether or not a requested call to or from a user having a CUG facility is allowed. In particular, a validation check is performed by verifying that both the calling and called parties belong to the CUG indicated by the interlock code. The data for each CUG that a user belongs to can either be stored at the local exchange to which the user is connected (decen- tralized administration of CUG data), or at dedicated point(s) in the network (centralized administration of CUG data). In S 3.2 the call set-up procedure based on decentralized administration of CUG data is specified making use of the ISDN User Part as defined in Recommendations Q.761-764 and Q.766. In S 3.3 the call set-up procedure based on centralized administration of CUG data is specified making use of the ISDN User Part as defined in Recommendations Q.761-764 and Q.766 and the Transaction Capabilities Application Part (TCAP) as defined in Recommendations Q.771-775. Section 3.4 specifies the application service element (ASE), situated above the Transaction Capabilities Application Part (TCAP), and used for CUG validation check with centralized adminis- tration of CUG data. 3.2 Call set-up procedure with decentralized administration of CUG data 3.2.1 Originating exchange The actions at the originating exchange at call set-up from a user belonging to a CUG depend on the result of the validation checks performed there based on whether the user belongs to one or more CUGs and on the combination of CUG facilities that applies. a) CUG call without outgoing access If the result of the validation check indicates that the call should be dealt with as a CUG call, the interlock code of the selected CUG is obtained. The initial address message forwarded to the next exchange then includes the interlock code together with an indication that the call is a CUG call without outgoing access. The ISUP preference indicator of the forward call indicators parameter in the IAM is set to "ISUP required all the way". b) CUG call with outgoing access If the result of the validation check indicates that the call should be dealt with as a CUG call with outgoing access, the interlock code of the selected CUG together with an outgoing access indication is obtained. The initial address message forwarded to the next exchange then includes the interlock code together with an indication that the call is a CUG call for which outgoing access is allowed. The ISUP preference indicator of the forward call indica- tors parameter in the IAM is set to "ISUP preferred all the way", unless another service requires a more stringent setting. c) Non-CUG call If the result of the validation check indicates that the call should be dealt with as a non-CUG call, the initial address message forwarded to the next exchange then does not include an interlock code nor a CUG call indication. d) Call rejected If the result of the validation check indicates that the call is to be rejected, the call set-up is not initiated. 3.2.2 Transit exchange With the possible exception of some gateway exchanges, each transit exchange sets up a CUG call as an ordinary call. The infor- mation related to the CUG facilities received from the preceding exchange, i.e. an interlock code, a CUG call indication - possibly with an indication that outgoing access is allowed - is forwarded to the succeeding exchange. In the case of an international CUG call, no special functions are required at the gateway exchange provided that the interna- tional interlock code assigned to the international CUG concerned is used in the national network. However, in the case where a national interlock code other than the applicable international interlock code is used within a national network, interlock code conversion is required at the gateway (or corresponding) exchange. In case of interworking with a network which does not support the CUG facility, the gateway exchange may release the call, depending on the contents of the CUG call indicator in the received IAM. The action at the gateway exchange, in this case, is indicated in Table 1/Q.730. In cases where a call is rejected as the result of the interworking, a release message including the cause parame- ter indicating ## 88 is sent towards the originating exchange. 3.2.3 Destination exchange At the destination exchange a validation check of the accepta- bility of a call is made according to the rule specified in the Recommendation Q.85 where either the calling party (as indicated by a CUG call indication in the initial address message received) or the called party belongs to a CUG. The call set-up is continued only in cases where the information received checks with the infor- mation stored at the destination exchange. Table 2/Q.730 indicates the action to be taken by the destination exchange as the result of the validation check. In cases where a call is rejected as the result of the valida- tion check because of incompatible CUG information, a release mes- sage including the cause parameter indicating one of the following values is sent towards the originating exchange: ##55: Incoming calls barred within CUG ##87: Called user not member of CUG ##88: Incompatible destination Figure 2/Q.730 illustrates example message flows for CUG calls with decentralized administration of CUG data. 3.3 Call set-up procedure with centralized administration of CUG data In the local exchange an indication is stored, showing only whether the user has one or none of the closed user group facili- ties. 3.3.1 Originating exchange The originating exchange requests the CUG validation check to the dedicated point by invocation of the "CUG check 1" operation through TCAP. This operation and associated parameters are described in S 3.4 of this Recommendation. The following actions at the originating exchange depend on the result of this validation check: a) CUG call indication If the result of the validation check for the calling user at the originating exchange indicates that the check for the cal- ling user has been successful, the interlock code of the selected CUG possibly together with an outgoing access indication is obtained. The initial address message forwarded to the next exchange then includes the interlock code together with an indica- tion that the call is a CUG call without outgoing access or a CUG call with outgoing access. b) Non-CUG call indication If the result of the validation check indicates that the call should be dealt with as a non-CUG call, the initial address message forwarded to the next exchange then does not include an interlock code nor a CUG call indication. c) Call rejected If the result of the validation check indicates that the call is to be rejected, the call set-up is not initiated. 3.3.2 Transit exchange Refer to S 3.2.2. 3.3.3 Destination exchange In the case of an incoming CUG call for which the validation check for the calling user has successfully been performed, the received initial address message includes the interlock code and CUG call indication possibly with an indication that outgoing access is allowed. The destination exchange then forwards the information received in the initial address message to the dedi- cated point for CUG validation check. In this case, the destination exchange invokes the "CUG check 2" operation through TCAP. This operation and associated parameters are defined in S 3.4 of this Recommendation. a) Check successful indication If the result of the validation check indicates that the check has been successful, the index of the CUG selected for the called user and possibly an outgoing access indication are obtained. The CUG call set-up request is forwarded to the called user with these indications. b) Non-CUG call indication If the result of the validation check indicates that the call should be dealt with as a non-CUG call, the set-up request of a non-CUG call is forwarded to the called user. c) Call rejected If the result of the validation check indicates that the call is rejected, the reason why the call has been rejected is obtained. A release message including the cause parameter indicat- ing one of the values as listed in S 3.2.3 is sent towards the ori- ginating exchange. 3.3.4 Dedicated point At the dedicated point, the CUG validation check is performed according to the rules defined in Recommendation Q.85. The pro- cedures between the dedicated point and the exchange follow those as defined in the ASE part of this Recommendation. Figure 3/Q.730 illustrates an example message flow for a CUG call with centralized administration of CUG data. H.T. [T1.730] TABLE 1/Q.730 Action at the gateway with a network without CUG capability _______________________________________________________________________________ CUG call indicator in IAM { Action at the gateway exchange } _______________________________________________________________________________ CUG without outgoing access { Release the call with cause ##88 } _______________________________________________________________________________ CUG with outgoing access { Treat the call as an ordinary call | ua) } _______________________________________________________________________________ Non-CUG Treat the call as an ordinary call _______________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) Discard the interlock code parameter and change the CUG call indicator of the optional forward call indicator to indicate non-CUG call or discard the whole parameter if appropriate. Tableau 1/Q.730 [T1.730], p. 45 H.T. [T2.730] TABLE 2/Q.730 Handling of a CUG call at the destination exchange ____________________________________________________________________________________________________________________________________________ Class of called user | CUG call indicator in IAM CUG match check No ICB ICB CUG + IA No ICB ____________________________________________________________________________________________________________________________________________ Match CUG call | | | Release cause ##55 CUG call | | { No match { { CUG with OA not allowed Release cause ##55 ____________________________________________________________________________________________________________________________________________ Match CUG call | | Release cause ##55 CUG+OA call | | Non-CUG call No match { CUG with OA allowed Non-CUG call | | | | | | | | | | | | | | Non-CUG call ____________________________________________________________________________________________________________________________________________ Non-CUG - { Release the call with cause ##88 } Non-CUG call Non-CUG call ____________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IA Incoming access OA Outgoing access ICB Incoming calls barred Match The interlock code in the received IAM matches one of the CUGs to which the called user belongs. No match The interlock code does not match any of the CUGs to which the called user belongs. Note - As OA attribute of the called user is of no concern at the destination exchange, CUG+OA class is equivalent to CUG, and CUG/IA class is equivalent to CUG+IA in this table. Subscription of pre- ferential CUG by the called user is also of no concern in this table. Tableau 2/Q.730 [T2.730], p. 46 Figure 2/Q.730, p. 47 Figure 3/Q.730, p. 48