InfoMagic Standards 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1992 / x / x301_2.asc < prev next >

Wrap

Text File | 1993-08-17 | 74.8 KB | 2,539 lines

C:\WINWORD\CCITTREC.DOT The drawings contained in this Recommendation have been done in Autocad Note û The DTE/DCE interface arrangements necessary in the cir- cuitûswitched service in CSPDNs to allow the called user to deny establish- ment of a reverse charging call, for example after calling line identification, have not yet been defined. The procedure chosen is likely to affect the net- work procedures for reverse charging calls. 7.2.2 Local charging prevention Local charging prevention is an optional user facility agreed to for a period of time. This user facility, when subscribed to, authorizes the DCE to prevent the establishment of calls which the subscriber must pay for by: a) not transmitting to the DTE incoming calls which request the reverse charging facility, and b) insuring that the charges are made to another party whenever a call is requested by the DTE. This other party can be determined by using any of a number of actions, both procedural and administra- tive. The procedural methods include: û the use of reverse charging, û identification of a third party using the network user identification facility (see º 7.4.5). When the party to be charged has not been established for a call request, the DCE will apply reverse charging to this call. Note û For an interim period of time, some networks may choose to enforce local charging prevention by clearing the call when the party to be charged has not been established. 7.2.3 Charging information Charging information is an optional user facility which may be either agreed for a period of time or requested by the DTE for a given call. If the DTE is the DTE to be charged, the DTE can request the charg- ing information facility on a per call basis by means of an appropriate facil- ity request in the call request phase or call confirmation phase. If a DTE subscribes to the charging information facility for a contrac- tual period, the facility is in effect for the DTE, whenever the DTE is the DTE to be charged, without sending the facility request in a call request phase or call confirmation phase. During the call clearing phase, the DCE will send to the charged DTE information about the charge for that call and/or other information which makes it possible for the user to calculate the charge. The charging information parameter may be expressed in any of the following measures: monetary unit, distance, segment count, call duration. 7.3 Facilities relating to specific routing conditions requested by the user of the call The optional user facilities which are standardized for different data transmission services, and are related to specific routing conditions requested by the user of the call are shown in Table 7û3/X.301. TABLE 7û3/X.301 Optional user facilities, standardized for different data transmission ser- vices, related to specific routing conditions requested by the user of the call Optional user facility Peri od Applie s per Applies to cir- cuit switched data transmission service Applies to packet switched data transmission service of tim e call PTS N CSP DN ISD N ISD N PSP DN MS S Redirection of calls X X X X X Deflection of calls X X X X Hunt group X X X X X RPOA selec- tion X X X FS X ? X X Called line address modi- fied notifica- tion X X X X Call redirec- tion or deflec- tion notification X X X X X 7.3.1 Redirection of calls 7.3.1.1 General Redirection of calls is an optional user facility assigned to the user for an agreed contractual period. The facility enables a user to have calls to his address redirected to a predetermined address. In the case of circuitûswitched service in CSPDNs this shall apply to all calls to the address. In the case of packetûswitched data transmission ser- vice in PSPDNs and ISDNs, this shall apply to calls which encounter the outûofûorder condition, or optionally other conditions, such as number busy. Provision of the facility and registration of the address to which calls are to be redirected is controlled by the Administration. It is for further study whether or not a facility is required to allow user control of the address registered to which calls are to be redirected. Depending on the possiblities offered by the Administration, facility activation and deactivation may be made: a) by the user by means of user controlled activation and deactivation procedures; b) by the network at predetermined times; c) by the Administration or Recognized Private Operating Agency (RPOA) on request of the user; d) by the Administration when providing and withdrawing the redirec- tion of calls facility from the address. User controlled procedures for inquiry of the status of the facility (i.e. whether the facility is activated or deactivated) may also be provided. For international calls, redirection may only be made within the destination network. Some Administrations may allow redirection between networks within the destination country. In general, a call may only be redirected once. However, some Administrations may provide for multiple redirections of a call in the packetûswitched data transmission service in PSPDNs and ISDNs. The basic service is limited to one call redirection. In addition, some net- works may offer either one of the following (mutually exclusive) capabili- ties. In the case where DTE A is the calling DTE, and DTE B is originally called DTE: 1) A list of alternate DTE's (C1, C2, . . .) is stored by the network of DTE B. Consecutive attempts of call redirection are tried to each of these addresses, in the order of the list, up to the completion of the call. 2) Call redirections may be logically chained; if DTE C has subscribed to call redirection to DTE D, a call redirected from DTE B to DTE C may be redirected to DTE D; call redirections and call deflec- tions may also be chained. In any case, networks will ensure that loops are avoided and that the Call Request Phase has a limited duration, consistent with a DTE time limit. The redirection of call facility will not violate the integrity of the closed user group facility. For the packet switched networks, when the call is redirected, the called address of the alternate DTE and the called line address modified notifica- tion facility, indicating the reason why the called address is different from the one originally requested will be indicated to the calling DTE during the call confirmation phase or call clearing phase (see º 7.3.5). When the call is redirected, some networks may indicate to the alternate DTE the reason for redirection and the address of the orignally called DTE, using the call redirection notification facility in the call request phase (see º7.3.6). The order of call setûup processing at the originally called DCE as well as the alternate DCE will be according to the sequence of call progress signals in Table 1/X.96. For those networks that provide systematic call redirection with the prior request of the called DTE, the systematic call redirection request will have the highest priority in the call setûup processing sequence at the originally called DCE. It is for further study whether there is a need for an optional user facility for the calling DTE to indicate whether or not it is permitted to redirect calls originated by this DTE. 7.3.1.2 Call setûup procedure for circuit switched data transmission services in CSPDNs 7.3.1.2.1 Calls not involving other facilities affecting the procedure Information that a user has the redirection of calls facility activated is stored, together with the redirection address, at the exchange to which the user is connected. When such a user is called, the call is set up to the redi- rection address in accordance with the following. 7.3.1.2.1.1 The redirection address is at the same exchange In this case the destination exchange connects the call to the redirec- tion address and returns the redirected call signal unless the call is rejected for one of the reasons indicated below. When receiving the redirected call signal, the originating exchange sends the corresponding call progress sig- nal to inform the calling user that the call has been redirected. In the case, where the user at the redirection address also has the redi- rection of calls facility activated, the destination exchange rejects the call and returns the access barred call progress signal. The call may also be rejected for other reasons (e.g. number busy) in accordance with the ordi- nary procedures. 7.3.1.2.1.2 The redirection address is at another exchange 7.3.1.2.1.2.1 In this case, the call is set up to the redirection address in accor- dance with one of the following procedures depending on the arrangements in the destination network. 7.3.1.2.1.2.2 The following procedure is based on the principle that the call is released back within the destination network and then set up to the new destination exchange. In the case of an international call, it is released back to the incoming gateway exchange. In the case of a national call, it is released back to the originating exchange. This procedure can be supported by common channel signalling Recommendation X.61. The means neces- sary to support this procedure are not defined in Recommendations X.70 and X.71. i) The first destination exchange returns the redirection request signal together with the redirection address towards the controlling exchange (i.e. the incoming gateway or originating exchange). ii) In the case of an international call, the incoming gateway exchange upon receipt of the redirection request signal, set up a new forward connection to the redirection address. The call control information forwarded includes a redirected call indication. The forward con- nection to the first redirection exchange is released. iii) In the case of a national call, the originating exchange acts in accordance with ii). iv) Upon receipt of the redirected call, the new destination exchange connects the call or rejects the call in accordance with º 7.3.1.2.1.1. The forward redirected call indication received by the new destination exchange is used to prevent further redirection. v) In the case where the call is connected to the redirection address, the originating exchange will receive the redirected call signal. It then sends the redirected call call progress signal to inform the calling user that the call has been redirected. 7.3.1.2.1.2.3 The following procedure is based on the principle that the con- nection is extended forward from the first destination exchange to the new destination exchange. This procedure can be supported by common channel signalling and decentralized signalling in accordance with Recommendation X.61, and Recommendations X.70 and X.71 respectively. i) The first destination exchange sets up the forward connection to the redirection address. The call control information forwarded will include a redirected call indication. ii) Upon receipt of the redirected call, the new destination exchange connects or rejects the call in accordance with º 7.3.1.2.1.1. The received redirected call indication is used to prevent further redi- rection. iii) In the case where the call is connected to the redirection address, the originating exchange will receive a redirected call signal. It then sends the redirected call call progress signal to inform the calling user that the call has been redirected. 7.3.1.2.2 Calls involving a closed user group facility Redirected calls are subject to the restrictions applying for the closed user group (CUG) facilities. a) In the case where the call is a CUG call, or the originally called user has a CUG facility, the call is rejected before redirection unless the validation check requirements applicable for the CUG facility con- cerned are satisfied. b) In the case where the call is a CUG call, or the user at the redirec- tion address has a CUG facility, the call is rejected unless the vali- dation check requirements applicable for the CUG facility concerned are satisfied. c) In the case where: i) the call is a CUG call, and ii) the redirection address is at an exchange other than the first des- tination exchange, and iii) the procedure for setting up the call to the redirection address is in accordance with º 7.3.1.2.1.2 (i.e. the call is released back), the first destination exchange has to send the CUG information received (e.g. the CUG call indication, and the interlock code) back to the controlling exchange together with the redirected call signal and the redirection address to enable the controlling exchange to include this CUG information in the call control information sent on the new forward connection. 7.3.1.2.3 The calling user has the called line identification facility In the case where a call from a user that has the called line identifica- tion facility is redirected, the called line identity sent to the calling user is the data number of the redirection address. 7.3.2 Deflection of calls 7.3.2.1 General Deflection of calls is an optional user facility assigned to the user for an agreed contractual period. The facility enables a user to deflect incoming calls to another address on a per call basis for use on a packet switched virtual call service. Upon reception of an incoming call request the originally called DTE responds with a clearing request including address of the DTE to which the call is to be deflected (i.e. data transfer phase never takes place between the calling DTE and originally called DTE). The network will consequently ini- tiate an incoming call on the DTE interface to which the call is deflected. For international calls, deflection may only be made within the desti- nation network. Some Administrations may allow redirection between net- works within the destination country. In general, a call may only be deflected once. However, some Administrations may provide for multiple deflections of a call in the packet switched data transmission service in PSP- DNs and ISDNs. The basic service is limited to one call deflection. In addition, in some networks call deflections and call redirections may be logically chained. In this case, networks will ensure that loops are avoided and that the call request phase has a limited duration, consistent with a DTE time limit. The deflection of call facility will not violate the integrity of the closed user group facility. For the packetûswitched networks, when the call is deflected, the called address of the alternate DTE and the Called line address modified notification facility, indicating the reason why the called address is different from the one originally requested will be indicated to the calling DTE dur- ing the call confirmation phase or call clearing phase (see º 7.3.5). When the call is deflected, some networks may indicate to the alter- nate DTE the reason for redirection and the address of the originally called DTE, using the call redirection or deflection notification facility in the call request phase (see º 7.3.6). It is for further study whether there is a need for an optional user facil- ity for the calling DTE to indicate whether or not it is permitted to deflect calls originated by this DTE. 7.3.3 Hunt group 7.3.3.1 General The hunt group facility is an optional user facility which distributes incoming calls containing a hunt group address across the available DTE/ DCE interfaces associated with the facility. Once a call is assigned to a DTE/DCE interface, the call is treated as a regular call. Calls originated on a DTE/DCE interface belonging to the hunt group are handled as normal calls. Note 1 û One or more addresses may be associated with the facility. If more than one address is associated with the facility, the selection procedure is performed irrespective of the particular called address. Note 2 û A specific address may be assigned to each DTE/DCE inter- face associated with a hunt group. Calls placed directly to these specific addresses are treated normally (no distribution of calls). When distribution has been performed, and a specific address has been assigned in each DTE/ DCE interface associated with the hunt group, this address should be returned to the calling DTE (as called line identification) together with an indicator indicating why the called line identification is different from the original called address. 7.3.3.2 Call setûup procedure When receiving an incoming call having a hunt group address, the destination exchange performs the selection of DTE/DCE interface, if there is at least one idle circuit/channel available for incoming calls on any of the DTE/DCE interfaces in the group. When calls are placed to a hunt group address, in the case specific addresses have also been assigned to the individual DTE/DCE interfaces, information is transferred to the calling DTE which contains: 1) the called address of the selected DTE/DCE interface, and 2) the reason why the called address is different from the one origi- nally requested. The exact arrangement is for further study. For packet switching virtual call service, called line address modified notification facility is used for this purpose. Some networks may apply call subscription time user facilities, com- mon to all DTE/DCE interfaces in the hunt group, place a limit on the num- ber of DTE/DCE interfaces in the hunt group, and/or constrain the size of the geographic region that can be served by a single hunt group. 7.3.4 RPOA selection 7.3.4.1 General This facility is an optional user facility which may be either agreed for a period of time or requested by a DTE on a per call basis for use on either circuit switched or packetûswitched virtual call services. In the countries that have more than one RPOA transit network, there is a requirement for a user facility which, when requested, allows the calling DTE to select either one or a sequence of more than one RPOA transit net- work(s) within the originating country. In the case of international calls, this facility, when requested, allows the calling DTE to select a particular inter- national RPOA within the country of that calling DTE. Note û The procedure for selection of multiple RPOAs is not yet spec- ified in the circuit switching interface Recommendations. 7.3.4.2 Call setûup procedure A user in a network providing the RPOA selection facility may request selection of a particular, or a sequence of more than one RPOA tran- sit network within the originating country, either for an agreed period of time or on a per call basis by a facility request including the NI(s) (see Rec- ommendation X.302) identifying the RPOA transit network(s) selected. In the case where a calling user request selection of one or more RPOA transit network(s), the originating network will route the call to the gateway exchange of the first RPOA transit network selected. In the case where the call is routed via one or more transit exchanges within the origi- nating network, an RPOA selection request indication and the DNIC(s) identifying the RPOA transit network(s) requested will be included in the internal network call control information forwarded by the originating exchange. In a similar manner, if the calling user selects a sequence of tran- sit networks, the first transit network shall route the call to the gateway exchange of the second RPOA transit network. Furthermore, the sequence of DNICs identifying the RPOAs selected by the user will be passed across the internetwork interface. Pending further study, the facility/utility used to provide this information is subject to bilateral agrement between the con- necting transit networks. The call control information sent over the international network will be as for an ordinary call and will not contain any RPOA selection related information. In the case where the selected RPOA transit network cannot accept the call, due to, for example, congestion or network failures, the call is rejected by the gateway exchange and an RPOA outûofûorder signal is returned towards the originating exchange which sends the corresponding call progress signal to the calling user. 7.3.5 Called line address modified notification Called line address modified notification is an optional user facility used by the DCE in the call confirmation or call clearing phase to inform the calling DTE as to why the called address in this phase is different from that specified by the calling DTE in the call request phase. When more than one address applies to a DTE/DCE interface, the called line address modified notification facility may be used by the responding DTE in the call clearing phase (when the call is rejected) or in the call confirmation phase, when the called address is presented by the responding DTE and different from that indicated to the DTE in the call request phase. When this facility is received from the responding DTE: 1) The DCE will clear the call if the called address is not one of those applying to the interface. 2) If call redirection has taken place in the PDN or ISDN, the DCE will replace the reason contained in the called line address modi- fied notification facility with the reason reflecting the status of the originally called DTE; otherwise, the reason is passed transpar- ently. Note û The DTE should be aware that a modification of any part of the called DTE addresses field without notification by the called line address modified notification facility may cause the call to be cleared. The following reasons can be indicated with the use of the called line address modified notification facility in call confirmation phase or clearing phase and transmitted to the calling DTE: 1) Call distribution with a hunt group, 2) Call redirection due to originally called DTE out of order, 3) Call redirection due to originally called DTE busy, 4) Call redirection due to prior request from the originally called DTE for systematic call redirection, 5) Called DTE originated, or 6) Call reflection by the originally called DTE. In call conformation or clearing phases, the reason indicated by the responding DTE in conjunction with the use of the called line access modi- fied notification facility should be ôDTE originatedö. 7.3.6 Call redirection or call deflection notification Call redirection or deflection notification is an optional user facility, used by the DCE in the call request phase to inform the alternate DTE that the call has been redirected or deflected, why the call was redirected and the address of the originally called DTE. The following reasons can be indicated with the call redirection or deflection notification facility: 1) Call redirection due to originally called DTE out of order. 2) Call redirection due to originally called DTE busy, 3) Call redirection due to prior request from the originally called DTE for systematic call redirection, 4) Call deflection by the originally called DTE, or 5) Call distribution within a hunt group. 7.4 Facilities related to protection mechanisms requested by the user of the call The optional user facilities which are standardized for different data transmission services and are related to protection mechanisms requested by the user of the call are shown in Table 7û4/X.310. TABLE 7û4/X.301 Optional user facilities, standardized for different data transmission ser- vices, related to protection mechanisms requested by the user of the call Optional user facility Peri od Applies per Applies to circuit switched data transmission ser- vice Applies to packet switched data transmission ser- vice of tim e call PTS N CSP DN ISD N ISD N PSP DN MSS CUG related facilities: û CUG X X X X X û CUG with out- going access X X X X X û CUG with incoming access X X X X X û Incoming calls barred within a CUG X X X X û Outgoing calls barred within a CUG X X X X û CUG selec- tion X (Note) X X X X û CUG with out- going access selection X (Note) FS X X X Bilateral CUG related facilities: û Bilateral CUG X X X X X û Bilateral CUG with outgoing access X X X X X û Bilateral CUG selection X (Note) X X X Incoming calls barred X X X X X Outgoing calls barred X X X X X NUI X X (Note) X X X NUI override permission X (Note) X X X Remarque û These facilities cannot be used unless the corresponding facili- ties are agreed for a period of time. 7.4.1 Closed user group 7.4.1.1 General The closed user group (CUG) facilities enable users to form groups with different combinations of restrictions for access from or to users having one or more of these facilities. The following CUG facilities are all optional user facilities that are assigned to the user for an agreed contracted period (see Note 1): a) Closed user group û this is the basic facility that enables a user to belong to one or more CUGs; b) Closed user group with outgoing access û this is an extension to a) which also enables the user to make outgoing calls to the open part of the network, and to DTEs having the incoming access capability [see c) below]; c) Closed user group with incoming access û this is a variant of a) which also enables the user to receive incoming calls from the open part of the network, and from DTEs having the outgoing access capability [see b) above]; d) Incoming calls barred within the closed user group û this is a sup- plementary facility to a), b) or c) which, when used, applies per user per CUG; e) Outgoing calls barred within the closed user group û this is a sup- plementary facility to a), b) or c) which, when used, applies per user per CUG; A user may belong to one or more CUGs. In the case where the user belongs to only one CUG, and the closed user group facility is subscribed to, it becomes the preferential CUG of that user. In the case where the user belongs to more than one CUG, and the closed user group facility is sub- scribed to, one of these CUGs is nominated as the preferential CUG of that user. Each user belonging to at least one CUG has subscribed to either the closed user group facility or one of both of the closed user groups with out- going access and the closed user group with incoming access. When the closed user group with outgoing access and/or the closed user group with incoming access facility is subscribed to, the DTE may choose whether or not to have a preferential CUG. For each CUG to which a user belongs, either or none of the supple- mentary facilities incoming calls barred within the closed user group or out- going calls barred within the closed user group facilities may apply for that user. Different combinations of CUG facilities may apply for different users belonging to the same CUG. The realization of the CUG facilities is done by the provision of inter- lock codes and is based on various validation checks at call setûup, deter- mining 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 verifica- tion that both the calling and called users belong to the same CUG as indi- cated by interlock codes. Membership of closed user groups is controlled by the Administration or RPOA in conjunction with user requests. Assignment of interlock codes is controlled by the Administration or RPOA, and cannot be controlled by the user. The international interlock code of an international CUG is specified in º 7.4.1.3. The international interlock code expresses the international CUG number assigned to the CUG in accordance with the administrative rules defined in Recommendation X.180. The originating network identification utility specified in Recommen- dation X.302 may be used for international CUG calls under control of the gateway exchange of the destination network (see º 7.4.1.2.2). Note 1 û Outgoing access and/or incoming access applies to an indi- vidual user and not to a specific closed user group. Note 2 û The requirements in º 7.4.1.2 include cases which do not necessarily exist in a particular network, either because the Administration (or RPOA) has chosen not to offer the full range of CUG facility combina- tions or because some combinations are not meaningful from the user's point of view. Note 3 û A network should, also in the case where the closed user group with outgoing access facility is not provided, be capable of supporting the signalling necessary to complete incoming calls from users in another network providing that facility. Note 4 û Private networks, including several different terminals and types of terminals will be connected to the public data network or ISDN. In these private networks, the different terminals may belong to different groups internally in the private networks, and may also have a need to com- municate into different CUGs in the public data network or ISDN. The option by the private network not to have a preferential CUG when subscrib- ing to the closed user group with outgoing access facility and/or the closed user group with incoming access facility allows for proper interpretation of the CUG facilities. The signals related to the treatment of calls in relation to CUGs are illustrated in Figure 7û6/X.301 and summarized in Tables 7û5/X.301, 7û6/ X.301 and 7û7/X.301. 7.4.1.2 Call setûup procedure 7.4.1.2.1 Originating exchange The DTE/DCE interface protocol and the actions at the originating exchange at call setûup from a user belong to a CUG depends on whether the user belongs to one or more CUGs and on the combination of CUG facilities that applies. See also Figure 7û7/X.301. 7.4.1.2.1.1 CUG selection For each CUG that a user belongs to, the interlock code assigned to the CUG is stored, and is associated to the user at the local exchange. In the case where a user belongs to more than one CUG, a selection of the CUG preferred, and thus of the corresponding interlock code, is required at call establishment. This selection is made on the following criteria. In the case where the calling user makes a facility request including an index identifying a particular CUG, this CUG is selected by the originat- ing exchange. In the case where the calling user belongs to one or more CUGs and has a preferential closed user group, no facility request concerning CUG facilities is made in the case: a) where the user belongs to one CUG only; b) where a user belonging to more than one CUG with or without out- going access, makes a call within the preferential CUG; or c) where a user, having the closed user group with outgoing access facility, makes an outgoing access call, or a call within the prefer- ential CUG. A facility request is always required for a call within any CUG other than the preferential CUG. Fig. 7û6/X.301/T0705591-88 = 9 cm TABLE 7û5/X.301 CUG signals into the network by the originating exchange resulting from CUG signals by the calling DTE and subscription parameters of the calling DTE Signaled by the call- ing DTE in the call request phase (see Note 1) CUG selection facility CUG/OA selec- tion facility No CUG nor CUG/OA selec- tion facility Subscription of the calling DTE CUG with preferen- tial (see Note 2) CUG utility (CUG speci- fied) (see Note 3) Not allowed (call cleared) CUG utility (Preferential CUG) (see Note 3) CUG/OA with pref- erential CUG/OA util- ity (CUG speci- fied) (see Note 3) Not allowed (call cleared) CUG/OA util- ity (Preferen- tial CUG) (see Note 4) CUG/IA with pref- erential CUG utility (CUG speci- fied) (see Note 3) Not allowed (call cleared) CUG utility (Preferential CUG) (see Note 3) CUG/IA/OA with preferential CUG/OA util- ity (CUG speci- fied) (see Note 3) Not allowed (call cleared) CUG/OA util- ity (Preferen- tial CUG) (see Note 4) CUG/OA without preferential CUG utility (CUG speci- fied) (see Note 3) CUG/OA util- ity (CUG speci- fied) (see Note 4) No CUG nor CUG/OA util- ity CUG/IA without preferential CUG utility (CUG speci- fied) (see Note 3) Not allowed (call cleared) Not allowed (call cleared) CUG/IA/OA with- out preferential CUG utility (CUG speci- fied) (see Note 3) CUG/OA util- ity (CUG speci- fied) (see Note 4) No CUG nor CUG/OA util- ity No CUG Not allowed (call cleared) Not allowed (call cleared) No CUG nor CUG/OA util- ity IA = incoming access. OA = outgoing access. Note 1 û The inclusion of both CUG and CUG/OA selection facilities is not allowed in the call request phase. Note 2 û CUG without preferential is not allowed. Note 3 û If outgoing calls are barred within the preferential, specified CUG or only CUG then the call is cleared. Note 4 û If outgoing calls are barred within the preferential, specified CUG or only CUG then only outgoing access applies. No CUG is signaled into the network. TABLE 7û6/X.301 CUG signals into the receiving subnetwork by the receiving internetwork exchange resulting from CUG signals to the receiving internetwork exchange and receiving subnetwork capabilities Signalled to the receiving internet- work exchange in the call request phase CUG utility CUG/OA selec- tion facility No CUG nor CUG/OA selec- tion facility Capabilities of the receiving subnetwork No CUG nor CUG/ OA utility is sup- ported Access barred (call cleared) Access barred (call cleared) No CUG nor CUG/OA util- ity Only the CUG util- ity is supported CUG utility (CUG speci- fied) Access barred a) (call cleared) No CUG nor CUG/OA util- ity Both the CUG and CUG/OA utilities are supported CUG utility (CUG speci- fied) CUG/OA util- ity (CUG speci- fied) No CUG nor CUG/OA util- ity OA = outgoing access. a) This entry needs further study for alignment with Table 24/X.25, note 6. TABLE 7û7/X.301 CUG signals to the called DTE by the destination exchange resulting from CUG signals from the network and subscription parameters of the called DTE Signalled from the network to the destination exchange in the call request phase CUG utility CUG/OA util- ity No CUG nor CUG/OA util- ity Subscription of the called DTE CUG with preferen- tial (see Note 1) CUG sel. fac. (CUG speci- fied) (see Note 2.3.4) CUG sel. fac. (CUG speci- fied) (see Note 2.3.4) Access barred (call cleared) CUG/OA with pref- erential CUG sel. fac. (CUG speci- fied) (see Note 2.3.4) CUG sel. fac. (CUG speci- fied) (see Note 2.3.4) Access barred (call cleared) CUG/IA with pref- erential CUG sel. fac. (CUG speci- fied) (see Note 2.3.4) CUG sel. fac. (CUG speci- fied) (see Note 4.5.6) No CUG nor CUG/OA sel. fac. CUG/IA/OA with preferential CUG sel. fac. (CUG speci- fied) (see Note 2.3.4) CUG sel. fac. (CUG speci- fied) (see Note 4.5.6) No CUG nor CUG/OA sel. fac. CUG/OA without preferential CUG sel. fac. (CUG speci- fied) (see Note 2.3) CUG sel. fac. (CUG speci- fied) (see Note 2.3) Access barred (call cleared) CUG/IA without preferential CUG sel. fac. (CUG speci- fied) (see Note 2.3) CUG/OA sel. fac. (CUG speci- fied) (see Note 5.6) No CUG nor CUG/OA sel. fac. CUG/IA/OA with- out preferential CUG sel. fac. (CUG speci- fied) (see Note 2.3) CUG/OA sel. fac. (CUG speci- fied) (see Note 5.6) No CUG nor CUG/OA sel. fac. No CUG Access barred (call cleared) No CUG nor CUG/OA sel. fac. No CUG nor CUG/OA sel. fac. Note 1 û CUG without preferential is not allowed. Note 2 û If the CUG specified to the destination exchange is not subscribed to by the called DTE, then the call is blocked. Note 3 û If incoming calls are barred within the specified CUG, then the call is blocked. Note 4 û If the specified CUG is the preferential CUG then the incoming call may contain no CUG nor CUG/OA facility. Note 5 û If the CUG specified to the destination exchange is not subscribed to by the called DTE, then Incoming Access applies; the incoming call con- tains no CUG nor CUG/OA selection facility. Note 6 û If incoming calls are barred within the specified CUG, then Incom- ing Access applies; the incoming call contains no CUG nor CUG/OA selec- tion facility. Fig. 7û7/X.301/T0705600-88 = 25 cm In the case where the calling user belongs to one or more CUGs and does not have a preferential closed user group, no facility request concerning CUG facilities is made in the case where a user having the closed user group with outgoing access facility makes an outgoing access call. 7.4.1.2.1.2 Call setûup from a user having the CUG or the CUG with incom- ing access facility The case where a user has both the closed user group with incoming access and closed user group with outgoing access facilities is handled in accor- dance with º 7.4.1.2.1.3. In this case, CUG selection is performed in accordance with º 7.4.1.2.1.1. In the case where the outgoing calls barred within the closed user group facility does not apply for the selected CUG, the call is setûup at the origi- nating exchange. The call control information forwarded to the next exchange then includes the interlock code of the selected CUG together with an indication that the call is a CUG call. In the case where the outgoing calls barred within the closed user group facility applies for the selected CUG, the call is rejected and the access barred call progress signal is returned to the calling user. 7.4.1.2.1.3 Call setûup from a user having the closed user group with outgo- ing access facility In the case where the calling user subscribes to the closed user group with outgoing access facility, and has a preferential (or only) CUG, the call is regarded as an outgoing access call and a call within the preferential (or only) CUG. In the case where the outgoing calls barred within the closed user group facility does not apply for the preferential (or only) CUG, the call is set up at the originating exchange. The call control information forwarded to the next exchange then includes the interlock code of the preferential (or only) CUG together with an indication that the call is a CUG call for which outgoing access is allowed. Note û With the above procedure it is not necessary to distinguish at the originating exchange between a call within a CUG and an outgoing access call. In the case where the outgoing calls barred within the closed user group facility applies for the preferential (or only) CUG, the call is regarded as an outgoing access call. In this case the call is set up at the originating exchange and no interlock code or CUG call indication is included in the call control information forwarded to the next exchange. In the case where the calling user subscribes to the closed user group with outgoing access facility, and does not have a preferential closed user group, the call is regarded as an outgoing access call, unless the calling user makes a facility request identifying a particular CUG for the call. 7.4.1.2.2 Transit exchange With the possible exception of some gateway exchanges, each transit exchange setûup a CUG call as an ordinary call. The information related to the CUG facilities received from the preceding exchange (i.e. an interlock code, a CUG call indication and possibly 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 international 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 the case where a destination network has a requirement for identifi- cation of the originating network for CUG calls, the originating network identification utility specified in Recommendation X.302 may be employed. 7.4.1.2.3 Destination exchange At the destination exchange, a validation check of the acceptability of a call is made where either the calling user (as indicated by a CUG call indi- cation in the control information received) or the called user belongs to a CUG. The call is connected only in cases where the information received checks with the information stored at the destination exchange, associated to the called user, as specified in the following. In cases where a call is rejected because of incompatible CUG information an access barred call progress signal is sent towards the calling user. The conditions for acceptance or rejection of calls because of the CUG facilities are illustrated in Figure7û8/X.301. Note û A call may be rejected for reasons other than those related to the CUG facilities. 7.4.1.2.3.1 Calls to a user having the CUG or the CUG with outgoing access facility The case where a user has both CUG with incoming access and CUG with outgoing access facilities is handled in accordance with º 7.4.1.2.3.2. In this case, an incoming call is accepted only when: a) it is a CUG call, including the case where outgoing access is allowed, and b) correspondence is found between the interlock code received and an interlock code associated with the called user, and c) the incoming calls barred within the closed user group facility does not apply for the CUG identified by the interlock code received. If all of the above conditions are not met, the call is rejected. 7.4.1.2.3.2 Calls to a user having the CUG with incoming access facility An incoming call is accepted in the cases when: a) it is an ordinary call, or b) it is a CUG call for which outgoing access is allowed, or c) it is a CUG for which outgoing access is not allowed, and both con- ditions specified in º 7.4.1.2.3.1 b) and c) apply. In all other cases, the incoming call is rejected. 7.4.1.2.3.3 CUG calls to a user not belonging to any CUG In the case where the incoming call is: a) a CUG call for which outgoing access is allowed, it is accepted, or b) a CUG call for which outgoing access is not allowed, it is rejected. 7.4.1.3 International interlock code Each international CUG is assigned a unique International CUG Number (ICN) according to the administrative rules defined in Recommen- dation X.180. Each international interlock code includes: a) four binary coded decimal digits expressing the DCC plus one digit, or DNIC, or the country or network of the coordinating Adminis- tration or Recognized Private Operating Agency, i.e. the decimal number A of the international CUG number; and b) a 16ûBit code expressing in pure binary representation the value of the decimal number B of the international CUG number. The interlock code is transferred, DNIC/DCC portion first, in accor- dance with the procedures specified by the relevant Recommendations X.61, X.70, X.71 or X.75. Note 1 û In some cases of signalling, all, some or none of the leading zeros are transmitted; see Recommendations X.70 and X.71. The binary code should then have the same meaning regardless of the number of lead- ing zeros. Note 2 û It is for further study whether or not the accommodation of international CUGs with members on public networks other than PDNs (e.g. ISDNs), will require any additional arrangements for handling international CUG interlock codes in PDNs. Fig. 7û8/X.301/T0705610-88 = 25 cm 7.4.2 Bilateral closed user group 7.4.2.1 General Bilateral closed user group and bilateral closed user group with outgo- ing access are optional user facilities assigned to the user for an agreed con- tractual period. The Bilatercal Closed User Group (BCUG) facility is a user facility that enables pairs of users to form bilateral relations allowing access between each other while excluding access to or from other users with which such a relation has not been formed. A user may belong to more than one BCUG. The Bilateral Closed User Group with Outgoing access (BCUGOA) facility is a user facility that enables a user to form BCUGs as with the bilat- eral closed user group facility, but at the same time allows the user to access by outgoing calls open users not having the bilateral closed user group or bilateral closed user group with outgoing access facilities. A user may simultaneously have the bilateral closed user group or bilateral closed user group with outgoing access facility and one or more of the closed user group (CUG) facilities. In such cases, a call within a CUG is handled separately from the bilateral closed user group facility and is not regarded as an outgoing access call in relation to the bilateral closed user group facility. Registration and cancellation of a BCUG of two users to the bilateral closed user group or bilateral closed user group with outgoing access facili- ties are controlled by the users concerned by means of automatic registration and cancellation procedures. The bilateral closed user group and bilateral closed user group with outgoing access facilities, including automatic user controlled facility regis- tration and cancellation, can be supported by common channel signalling (Recommendation X.61) for the circuitûswitched data transmission service. Decentralized signalling for the circuitûswitched data transmission (Recom- mendations X.70 and X.71) and for the packetûswitched data transmission service (Recommendation X.75) cannot support the facilities. The procedures for the bilateral closed user group facility are based on the mutual registration method. This method makes use of the features of abbreviated address calling. Thus, a user having the bilateral closed user group facility uses a local index (i.e. an abbreviated address) for each remote user with which a BCUG is formed. In the exchange to which the user is connected, a table associated with that user is available. The local index used to address a remote user corresponds to a position in the table containing the data number (address) of the remote user, the local index used by that remote user to address the local user, and an indication (associ- ation bit) about the status of the BCUG. 7.4.2.2 Registration procedures 7.4.2.2.1 When requesting registration of a BCUG, the user A makes a facil- ity request including the data number B of the remote user and the local index x used for that user. The originating exchange checks whether a data number has been registered or not in the position corresponding to the local index x received, in the local user A table. a) In the case where a data number has not yet been registered in posi- tion x in the user A table, the originating exchange registers data number B in that position. The originating exchange then sends a BCUG registration request to the destination exchange, including a data number B as a destination address, data number A as a source address and the local index x b) In the case where data number B for the remote user has already been registered in position x in the user A table, and its association bit has not yet been set, indicating that registration has not yet been completed, the originating exchange sends a BCUG registration request to the destination exchange, including the same informa- tion as described in a) above. c) In the case where data number B for the remote user has already been registered in position x in the user A table and its association bit has already been set, the originating exchange sends the regis- tration/cancellation confirmed call progress signal to user A. d) In the case where the data number registered in that position is dif- ferent from the data number B received, the originating exchange sends the local procedure error call progress signal to user A. 7.4.2.2.2 When receiving the BCUG registration request, the destination exchange checks the addressed user Btable. a) In the case where user B has already registered user A in a position y, where y is the local index used by user B for user A, and its asso- ciation bit has not yet been set, indicating that registration has not yet been completed, the destination exchange sets the association bit and registers local index x in that position. The destination exchange then responds to the originating exchange with a regis- tration completed signal together with the local index y. b) In the case where user B has already registered user A in position y and its association bit has already been set, the destination exchange checks the local index registered in that position. In the case when that local index is equal to the local index received, the destination exchange responds to the originating exchange as under item a) above. c) In the case where user B has not registered data number A in any position, the destination exchange responds to the originating exchange with a registration accepted signal. d) In the case where user B does not subscribe to the BCUG facility, the destination exchange responds to the originating exchange with an access barred call progress signal. e) In the case where user B is not accessable by user A for any other reason, the destination exchange responds to the originating exchange with the appropriate call progress signal. 7.4.2.2.3 When receiving the response to a BCUG registration request from the destination exchange, the action at the originating exchange depends on the signal received. a) In the case where a registration completed signal is received, the originating exchange sets the association bit and registers the local index y in position x in the user A table and send the registration/ cancellation confirmed call progress signal confirming registration to user A. b) In the case where a registration accepted signal is received, no fur- ther registration is made at the originating exchange and the regis- tration/cancellation confirmed call progress signal is sent to user A. c) In the case where a signal is received indicating that BCUG registra- tion has been rejected by the destination exchange, the originating exchange clears all the information in position x in the user A table and sends the corresponding call progress signal to user A. 7.4.2.2.4 With the above procedures, registration of a BCUG is completed when both users concerned have requested registration of each other and have received positive responses. 7.4.2.3 Cancellation procedure 7.4.2.3.1 When requesting cancellation of a BCUG, user A makes a facility request, including local index x. The originating exchange checks the status of position x in the user A table. a) In the case where a data number is registered in position x, the orig- inating exchange sends a BCUG cancellation request with data number B as address and including remote local index y and the calling user number A. Also, the originating exchange resets the association bit if it was set. b) In the case where no data number is registered in position x, the originating exchange returns the registration/cancellation con- firmed call progress signal to user A. 7.4.2.3.2 When receiving the BCUG cancellation request the destination exchange checks the addressed user Btable. a) In the case where the data number in position y in user B table is equal to the data number A received, the destination exchange clears all information in position y. b) In all other cases, and in particular in the case where the data num- ber stored in position y is different from the data number A received, the destination exchange does not alter any information stored in the user B table. In cases a) and b), the destination exchange sends a cancellation com- pleted signal to the originating exchange. 7.4.2.3.3 When receiving the cancellation completed signal in response to a BCUG cancellation request, the originating exchange clears all the informa- tion in position x in the user A table and sends the registration/cancellation confirmed call progress signal to user A. 7.4.2.3.4 With the above procedure, a BCUG is cancelled when either of the two users concerned has requested cancellation and has received the regis- tration/cancellation confirmed call progress signal. Note û Possible implications of abnormal conditions at cancellation may require further study. 7.4.2.4 Timeûout supervision in registration/cancellation procedure At the originating exchange in the facility registration/cancellation procedure, it is necessary to wait for receipt of the response from the desti- nation exchange after sending a BCUG registration/cancellation request. The duration of such periods has to be controlled by appropriate timeûouts. The following timeûouts are necesary: T1 û The time between the sending of the BCUG registration request and receipt of a response in accordance with º 7.4.2.2. T2 û The time between the sending of the BCUG cancellation request and receipt of a cancellation completed signal. On expiration of timeûout T1 or T2, the originating exchange sends the network congestion call progress sinal to user A thus indicating that the requested registration or cancellation has failed. User A then has to repeat the request for registration or cancellation. The value of T1 and T2 should (provisionally) be 5û10 seconds. 7.4.2.5 Call setûup procedure 7.4.2.5.1 Originating exchange 7.4.2.5.1.1 When making a call within a BCUG, the calling user A uses the local index x as address for the called user (in accordance with the proce- dure for the abbreviated address calling facility). The originating exchange checks the position corresponding to the local index x registered in the call- ing user A table. a) In the case where the association bit is set, indicating that the BCUG is registered by both the calling and called users, the origi- nating exchange sets up the call towards the destination exchange, using the called user data number B stored in the calling user A table. The call control information forwarded by the originating exchange includes an indication that the call is a BCUG call. b) In the case where the association bit is not set, indicating that the BCUG is not completely registered, the originating exchange rejects the call and sends the access barred call progress signal to the calling user. 7.4.2.5.1.2 In the case where a user having the bilateral closed user group facility makes a call with an ordinary data number or an abbreviated address not registered as a BCUG, the originating exchange rejects the call and sends access barred call progress signal to the calling user. Note û In the case where the user also belongs to a closed user group (CUG), calls within a CUG are handled independently and are not rejected because of the bilateral closed user group facility. 7.4.2.5.1.3 In the case where a user having the bilateral closed user group with outgoing access facility makes a call with an ordinary data number or an abbreviated address not registered as a BCUG, the call is handled as an outgoing acces call and is set up by the originating exchange in accordance with ordinary call set up procedure. 7.4.2.5.1.4 The possibility of transfer of the local index x (in the forward direction) and local index y (in the backward direction) and the possibility of additional verification checks at the destination exchange are for further study. 7.4.2.5.2 Transit exchange A transit exchange handles a BCUG call as an ordinary call. 7.4.2.5.3 Destination exchange 7.4.2.5.3.1 When receiving a BCUG call, the destination exchange may accept the call without checking whether the called user has the bilateral closed user group facility. 7.4.2.5.3.2 When receiving an ordinary call (i.e. not a BCUG call) to a user having the bilateral closed user group facility, the destination exchange rejects the call and responds with the access barred call progress signal to the originating exchange. 7.4.2.5.3.3 The call may be rejected for other reasons not related to the bilat- eral closed user group facility. Closed user group calls can be accepted regardless of the above conditions, provided that the requirements of that facility are met (see º 2). 7.4.2.5.4 Combination of BCUG and line or terminal identification facilities The possible arrangements for combinations of the bilateral closed user group or bilateral closed user group with outgoing access facilities and the calling line dentification and/or called line identification facilities and the form of calling or called DTE identification of BCUG calls are for fur- ther study. 7.4.3 Incoming calls barred Incoming call barred is an optional user facility agreed for a period of time. This facility applies to all calls used at the DTE/DCE interface. This facility, if subscribed to, prevents incoming calls from being pre- sented to the DTE. The DTE may originate outgoing calls. Note û Some Administrations may provide a capability that also allows a call to be presented to the DTE only in cases where the called address is the address of the calling DTE. 7.4.4 Outgoing calls barred Outgoing calls barred is an optional user facility agreed for a period of time. This facility applies to all calls used at the DTE/DCE interface. This user facility, if subscribed to, prevents the DCE from accepting outgoing calls from the DTE. The DTE may receive incoming calls. 7.4.5 Network User Identification Network User Identification is an optional user facility agreed for a period of time. This facility, if subscribed to, enables the DTE to provide information to the network for billing, security or network management pur- pose on a per call basis. This information may be provided by the calling DTE in the call request phase or by the called DTE in the call confirmation phase. It may be used whether or not the DTE has also subscribed to the local charging prevention facility (see º 7.2.2). If the DCE determines that the network user identifier is valid or not present when required by the net- work, it will clear the call. Network user identification is never transmitted to the remote DTE. The calling DTE address transmitted to the remote DTE in the calling DTE address field should not be inferred from the network user identification transmitted by the DTE in the call request phase. The contents and format of the NUI parameter is a national matter. Use of this feature between networks is subject to bilateral agreement between Administrations. 7.4.6 NUI override permission facility The NUI override permission facility is an optional user facility agreed to for a period of time. This facility, if subscribed to, permits an NUI facility, presented in the call request phase, to invoke features subscribed to by the DTE identified by that NUI and associated with the NUI. Facilities associated with the NUI shall override facilities which may apply to the interface. This override does not apply to existing calls or subsequent calls on the interface. It remains in effect for the duration of the particular call to which it applies. The optional subscription facilities that may be associated with an NUI are a national matter. 7.5 Facilities to convey user data in addition to the normal data flow in the data transfer phase Note û Different terms exist; in general ôuser dataö is used in Xûseries Recommendations, and ôuserûtoûuser informationö is used in Iûseries Rec- ommendations. 7.5.1 General Conveyance of user data in addition to the normal data flow in the data transfer phase can be considered in the following phases of a call: a) Call request phase (calling DTE to called DTE), b) Call confirmation phase (called DTE to calling DTE), c) Call clearing phase (clearing DTE to cleared DTE). Support of conveyance of user data during these phases is shown in Table 7û8/X.301. TABLE 7û8/X.301 Support by different networks to convey user data in addition to the normal data flow in the data transfer phase Network CSPDN or PSTN PSPDN or MSS ISDN Phases Cicuit switched Packet switched Call request phase No support Up to 16 octets or Up to 128 octets (fast select) Up to 128 octets Up to 16 octets or Up to 128 octets (fast select) Call confirma- tion phase No support Up to 128 octets (fast select) Up to 128 octets Up to 128 octets (fast select) Call clearing phase No support Up to 128 octets (fast select) Up to 128 octets Up to 128 octets (fast select) Note û Some networks require conveyance of an integral number of octets. For interworking between networks providing a different level of support of conveying user data in addition to the normal data flow in the data transfer phase, the following principles apply: a) the objective is that in the future all networks can support convey- ance of up to 128 octets user data during the call request phase, call confirmation phase, and call clearing phase, for the provision of data transmission services; b) in cases where conveyance of user data during these phases is requested, but where no support by the network is provided, an additional protocol mechanism, which is not operated by the net- work itself should be utilized (example: the use of packet proce- dures over the PSTN); c) in cases where rule b) fails or is not provided, the data calls will be aborted; an appropriate call progress message is returned to the DTE initiating the phase. 7.5.2 Fast select The optional user facilities which are standardized for different data transmission services, and are related to fast select are shown in Table 7û9/ X.301. TABLE 7û9/X.301 Optional user facilities standardized for different data transmission services, related to fast select Optional user facility Peri od Appl ies Applies to circuit switched data transmission ser- vice Applies to packet switched data transmission ser- vice of tim e per call PST N CSP DN ISD N ISD N PSP DN MSS Fast select X X X X Fast select acceptance X X X X Calling DTEs can request the fast select facility on a per call basis by means of an appropriate facility request in the call request phase. The fast select facility allows conveyance during the call request phase from calling DTE to called DTE of user data up to 128 octets. If the fast select facility indicates ôno Restriction on Responseö, it allows for either during the call confirmation phase or during the call clearing phase or during both phases the conveyance of up to 128 octets user data from called DTE (or clearing DTE) to calling DTE (or cleared DTE). If the fast select facility indicates ôRestriction on Responseö, it allows no call confirmation phase and data transfer phase. However, it does allow con- veyance during the call clearing phase (if initiated by the called DTE) of up to 128 octets from called DTE to calling DTE. Where a calling DTE requests a fast select facility, the incoming call should only be delivered to the called DTE if that DTE has subscribed to the fast select acceptance facility (see º 7.5.3). Where a calling DTE requests the fast select facility, and if the called DTE has subscribed to fast select acceptance, the fast select facility and whether or not there is a ôRestriction on Responseö will be conveyed during the call request phase from calling DTE to called DTE. If the called DTE has not subscribed to the fast select acceptance facility, no calls containing the fast select facility will be delivered to the called DTE. Such calls will be cleared by the network and a call progress signal fast select acceptance not subscribed will be returned to the calling DTE. Note 1 û For an interim period, some networks may not allow a DTE to transmit any user data in the call clearing phase when this phase is not initi- ated as a response on the call request phase. Note 2 û The user data conveyed in addition to the normal data flow in the data transfer phase will not be fragmented for delivery across the DTE/DCE interface. Note 3 û The significance of the call confirmation phase, or the call clearing phase conveying the call progress signal DTE originated as a direct response to the call request phase where the fast select facility has been used, is that the user data in the call request phase has been received by the called DTE. 7.5.3 Fast select acceptance Fast select acceptance is an optional user facility agreed for a period of time. This facility, if subscribed to, authorizes the DCE to transmit to the called DTE incoming calls which request the fast select facility. In the absence of this facility, the DCE will not transmit to the called DTE incom- ing calls which request the fast select facility. 7.6 Other facilities The other optional user facilities which are standardized for different data transmission services are shown in Table 7û10/X.301. TABLE 7û10/X.301 Other optional user facilities standardized for different data transmission services Optional user facility Peri od Appl ies Applies to circuit switched data transmission ser- vice Applies to packet switched data transmission ser- vice of tim e per call PST N CSP DN ISD N ISD N PSP DN MSS Manual answer X X Connect when free X X Waiting allowed X X FS Receipt confir- mation selection X X X X Expedited data negotiation X X X X FS = For further study. 7.6.1 Manual answer 7.6.1.1 General Manual answer is a DTE operating mode allowed by some networks for the circuitûswitched service in CSPDNs. DTEs operating in this mode may, when called, delay responding by the call accepted signal. Information indicating that a DTE operates with manual answer is stored at the exchange to which the user is connected. 7.6.1.2 Call establishment procedure In the case of a call to a user DTE operating with manual answer, the destination exchange sends the terminal called signal to the originating exchange at connection of the call. At the originating exchange, this results in sending of the terminal called call progress signal to the calling user. It also results in extending the value of any timeûout applicable to this phase of the call. The call is completed as an ordinary call when the call accepted signal is received from the called user by the destination exchange and a signal indicating that the call has been connected is sent towards the originating exchange. If the call accepted signal is not received by the destination exchange within the applicable DCE timeûout after sending of the incoming call signal to the called user, the call is cleared from the destination exchange without sending any call progress type backward signal. Note û In the case where the originating network does not allow man- ual answer and the called user operates with manual answer, the originating network may charge the calling user for the time from the receipt of the ter- minal called signal. 7.6.2 Connect when free and waiting allowed 7.6.2.1 General Connect when free and waiting allowed are optional user facilities assigned to the user for an agreed contractual period. A user subscribing to the connect when free facility is assigned a number of waiting positions at his local exchange at which incoming calls received can wait when the access line(s) to the user is busy. The waiting allowed facility enables a user calling a busy user having the connect when free facility to wait for the completion of the call when the called user becomes free. During waiting, the connection is maintained. The two facilities thus provide an opportunity for users having certain data traffic characteristics to make more efficient use of the network than in the ordinary case when a call to a busy user is rejected. Facility registration is controlled by the Administration or Recog- nized Private Operating Agency. 7.6.2.2 Call establishment procedure 7.6.2.2.1 When receiving a call to a busy user (i.e., at least one access line to the called user is occupied by a call in progress) having the connect when free facility, the destination exchange checks the waiting positions at the called user: a) in the case where a free waiting position exists the call is placed in the queue and the connect when free signal is sent towards the originating exchange; b) in the case where all waiting positions the occupied the call is rejected and the number busy signal is sent towards the originating exchange. The call may be rejected for other reasons not related to the connect when free facility. 7.6.2.2.2 The action at the originating exchange depends on whether the calling user has the waiting allowed facility and which signal is received. a) In the case where the connect when free signal is received and the calling user has the waiting allowed facility, the connect when free call progress signal is sent to the calling user. The calling user can then either wait for completion of the call or clear the call. In the case where the calling user chooses to wait, the connection is maintained but is not throughûconnected. The normal timeûout for completion of the call at the originating exchange is inhibited. The calling user cannot make or receive another call on the same access line during waiting. b) In the case where the connect when free signal is received and the calling user does not have the waiting allowed facility, the number busy signal is sent to the calling user and the call is cleared. c) In the case where the number busy signal is received, the number busy call progress signal is sent to the calling user and the call is cleared; this is also the case when the calling user has the waiting allowed facility. 7.6.2.2.3 When an access line becomes free to the called user, the destina- tion exchange connects the first call in the queue in the normal manner. A signal indicating that the call has been connected is sent towards the origi- nating exchange. 7.6.2.2.4 When receiving the signal indicating that the call has been con- nected, the originating exchange throughûconnects the call in the normal manner. 7.6.2.2.5 The waiting time will be charged. The calling user may send a clear request at any time to terminate the waiting which will result in normal network clearing and removal of the call from the queue. The waiting may also be terminated by the destination exchange in some abnormal situations resulting in a clearing sequence towards the calling user. Note û The possible provision of a network timeûout to limit the wait- ing time is for further study. 7.6.3 Receipt confirmation selection 7.6.3.1 General Receipt confirmation selection is an optional user facility that permits on a per call basis of whether or not the receipt of data units in the data transfer phase will be confirmed endûtoûend. Note û Realization of this facility in PSPDNs and ISDNs can be per- formed by using the Dûbit procedures (see Recommendation X.25). 7.6.3.2 Call request phase and call confirmation phase The calling DTE may request during the call request phase endûtoû end acknowledgement of delivery of data units it will be transmitting in the data transfer phase, by setting the receipt selection parameter to endûtoûend acknowledgement. During the call request phase, any (part of the) network involved in the call, as well as the called DTE, that cannot support this endû toûend acknowledgement will set the receipt selection parameter to ônon endûtoûend acknowledgementö. The finally resulting value will be applica- ble for the call and will be conveyed by the called DTE to the calling DTE during the call confirmation phase. 7.6.3.3 Data transfer phase Delivery of data units to the receiving DTE will be confirmed to the sending DTE if the receipt confirmation parameter, conveyed in the call confirmation phase, had the value ôendûtoûend acknowledgementö. Note û In some cases (e.g. in PSPDNs) endûtoûend receipt confirma- tion in this phase could still be applied independent of the presence of the negotiation in the call request phase/call confirmation phase. However, defi- nitions in Recommendation X.213 do also require the negotiation. 7.6.3.4 Call clearing phase No endûtoûend acknowledgement applies to this phase. 7.6.4 Expedited data negotiation 7.6.4.1 General Expedited data negotiation is an optional user facility that permits on a per call basis negotiation during the call request phase and call confirma- tion phase of whether or not expedited data transfer can be applied during the data transfer phase. 7.6.4.2 Call request phase and call confirmation phase The calling DTE may request in the call request phase the possibility to use expedited data procedures in the data transfer phase, by setting the expedited data parameter to ôexpedited dataö. During the call request phase, any (part of the) network involved in the call, as well as the called DTE, that cannot support this expedited data, will set the expedited data negotiation parameter to ôno expedited dataö. The finally resulting value will be appli- cable for the call and will be conveyed by the called DTE to the calling DTE during the call transfer phase. The public networks involved in the call are not required to look at or operate on this parameter; however some networks may look at the parame- ter if they wish.