The drawings contained in this Recommendation have been done in Autocad
	Note – The DTE/DCE interface arrangements necessary in the circuit–switched service in CSPDNs to allow the called user to deny establishment of a reverse charging call, for example after calling line identification, have not yet been defined. The procedure chosen is likely to affect the network 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 administrative. 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 charging information facility on a per call basis by means of an appropriate facility request in the call request phase or call confirmation phase.
	If a DTE subscribes to the charging information facility for a contractual 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 services,
related to specific routing conditions requested by the user of the call

Optional user facility	
Period	
Applies per 	 Applies to circuit switched data transmission service			 Applies to packet switched data transmission service			
	of time	call	PTSN	CSPDN	ISDN	ISDN	PSPDN	MSS	
Redirection of calls	X			 X	 	X	X	X	
Deflection of calls		X				X	X	X	
Hunt group	X			 X		X	X	X	
RPOA selection	X	X		X	FS	X ?	X	X	
Called line address modified notification		X				X	X	X	
Call redirection or deflection 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 service 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 redirection 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 networks may offer either one of the following (mutually exclusive) capabilities. 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 deflections 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 notification 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 redirection 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 redirection 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 signal to inform the calling user that the call has been redirected.
	In the case, where the user at the redirection address also has the redirection 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 ordinary 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 accordance 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 necessary 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 connection 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 connection 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 redirection.
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 concerned are satisfied.
b)	In the case where the call is a CUG call, or the user at the redirection address has a CUG facility, the call is rejected unless the validation 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 destination 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 identification 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 initiate an incoming call on the DTE interface to which the call is deflected.
	For international calls, deflection 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 deflected once. However, some Administrations may provide for multiple deflections of a call in the packet switched data transmission service in PSPDNs 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 during the call confirmation phase or call clearing phase (see § 7.3.5).
	When the call is deflected, some networks may indicate to the alternate 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 facility 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 interface 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 originally 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, common to all DTE/DCE interfaces in the hunt group, place a limit on the number 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 network(s) within the originating country. In the case of international calls, this facility, when requested, allows the calling DTE to select a particular international RPOA within the country of that calling DTE.
	Note – The procedure for selection of multiple RPOAs is not yet specified 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 transit 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 Recommendation 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 originating 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 transit 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 connecting 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 modified notification facility with the reason reflecting the status of the originally called DTE; otherwise, the reason is passed transparently.
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 modified 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 services,
related to protection mechanisms requested by the user of the call

Optional user facility	
Period 	
Applies per	Applies to circuit switched data transmission service			Applies to packet switched data transmission service			
 	of time	 call	PTSN	CSPDN	ISDN	ISDN	PSPDN	MSS	
CUG related facilities:									
–	CUG	X			 X		X	X	X	
–	CUG with outgoing 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 selection		X (Note)		X		X	X	X	
–	CUG with outgoing 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 facilities 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 supplementary 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 supplementary 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 subscribed 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 outgoing 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 supplementary facilities incoming calls barred within the closed user group or outgoing 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 interlock codes and is based on various validation checks 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 verification that both the calling and called users belong to the same CUG as indicated 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 Recommendation 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 individual 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 combinations 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 communicate into different CUGs in the public data network or ISDN. The option by the private network not to have a preferential CUG when subscribing 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 originating 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 outgoing 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 preferential 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 calling 
DTE in the call
request phase
(see Note 1) 	 

CUG selection facility	

CUG/OA selection facility	 

No CUG nor CUG/OA selection facility	
Subscription
of the calling 
DTE				
CUG with preferential
(see Note 2)	CUG utility (CUG specified) (see Note 3)	Not allowed (call cleared)	CUG utility
(Preferential CUG)
(see Note 3)	
CUG/OA with preferential	CUG/OA utility (CUG specified) (see Note 3)	Not allowed (call cleared)	CUG/OA utility (Preferential CUG)
(see Note 4)	
CUG/IA with preferential	CUG utility (CUG specified) (see Note 3)	Not allowed (call cleared)	CUG utility (Preferential CUG)
(see Note 3)	
CUG/IA/OA with preferential	CUG/OA utility (CUG specified) (see Note 3)	Not allowed (call cleared)	CUG/OA utility (Preferential CUG)
(see Note 4)	
CUG/OA without preferential	CUG utility (CUG specified) (see Note 3)	CUG/OA utility (CUG specified) (see Note 4)	No CUG nor CUG/OA utility	
CUG/IA without preferential	CUG utility (CUG specified) (see Note 3)	Not allowed (call cleared)	Not allowed (call cleared)	
CUG/IA/OA without preferential	CUG utility (CUG specified) (see Note 3)	CUG/OA utility (CUG specified) (see Note 4)	No CUG nor CUG/OA utility	
No CUG	Not allowed (call cleared)	Not allowed (call cleared)	No CUG nor CUG/OA utility	
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 internetwork exchange
in the call request 
phase 	

CUG utility	

CUG/OA selection facility	

 No CUG nor CUG/OA selection facility	
Capabilities 
of the receiving
subnetwork				
No CUG nor CUG/OA utility is supported	 Access barred
(call cleared)	Access barred
(call cleared)	No CUG nor CUG/OA utility	
Only the CUG utility is supported	 CUG utility
(CUG specified)	 Access barred a)
(call cleared)	No CUG nor CUG/OA utility	
Both the CUG and CUG/OA utilities are supported	 CUG utility
(CUG specified)	CUG/OA utility
(CUG specified)	 No CUG nor CUG/OA utility	
 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 utility	
No CUG nor CUG/OA utility	
Subscription
of the called
DTE				
CUG with preferential
(see Note 1)	CUG sel. fac.
(CUG specified)
(see Note 2.3.4)	CUG sel. fac.
 (CUG specified)
(see Note 2.3.4)	Access barred
 (call cleared)	
CUG/OA with preferential	CUG sel. fac.
(CUG specified)
(see Note 2.3.4)	 CUG sel. fac.
(CUG specified)
(see Note 2.3.4)	Access barred
(call cleared)	
CUG/IA with preferential	CUG sel. fac.
(CUG specified)
(see Note 2.3.4)	CUG sel. fac.
(CUG specified)
(see Note 4.5.6)	No CUG nor CUG/OA
sel. fac.	
CUG/IA/OA with
preferential	CUG sel. fac.
(CUG specified)
(see Note 2.3.4)	CUG sel. fac.
(CUG specified)
(see Note 4.5.6)	No CUG nor CUG/OA
sel. fac.	
CUG/OA without preferential	CUG sel. fac.
(CUG specified)
(see Note 2.3)	CUG sel. fac.
(CUG specified)
(see Note 2.3)	Access barred
(call cleared) 	
CUG/IA without preferential	CUG sel. fac.
(CUG specified)
(see Note 2.3)	CUG/OA sel. fac.
(CUG specified)
(see Note 5.6)	No CUG nor CUG/OA
sel. fac.	
CUG/IA/OA without preferential	CUG sel. fac.
(CUG specified)
(see Note 2.3)	CUG/OA sel. fac.
(CUG specified)
(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 contains no CUG nor CUG/OA selection facility.
Note 6 – If incoming calls are barred within the specified CUG, then Incoming Access applies; the incoming call contains no CUG nor CUG/OA selection 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 incoming 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 accordance 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 originating 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 outgoing 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 identification 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 indication 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       Figure 7–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 conditions 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 Recommendation 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 Administration 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 accordance 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 leading 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 outgoing access are optional user facilities assigned to the user for an agreed contractual 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 bilateral 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 facilities 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 registration 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 (Recommendations 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 (association 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 facility 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 position 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 information 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 registration/cancellation confirmed call progress signal to user A.
d)	In the case where the data number registered in that position is different 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 B table.
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 association 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 registration 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 further registration is made at the originating exchange and the registration/cancellation confirmed call progress signal is sent to user A.
c)	In the case where a signal is received indicating that BCUG registration 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 originating 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 confirmed call progress signal to user A.
7.4.2.3.2		When receiving the BCUG cancellation request the destination exchange checks the addressed user B table.
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 number 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 completed 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 information 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 registration/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 destination 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 procedure for the abbreviated address calling facility). The originating exchange checks the position corresponding to the local index x registered in the calling 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 originating 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 bilateral 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 further 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 presented 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 purpose 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 network, 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 Recommendations.
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 confirmation 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 conveyance 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 network itself should be utilized (example: the use of packet procedures 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	
Period	 
Applies  	Applies to circuit switched data transmission service			Applies to packet switched data transmission service			
 	of time	per call	PSTN	CSPDN	ISDN	ISDN	PSPDN	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 conveyance 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 initiated 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 incoming 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	
Period	 
Applies  	Applies to circuit switched data transmission service			Applies to packet switched data transmission service			
 	of time	per call	PSTN	CSPDN	ISDN	ISDN	PSPDN	MSS	
Manual answer	 X			X					
Connect when free	 X			X					
Waiting allowed	 X		 	X	FS				
Receipt confirmation 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 manual 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 terminal 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 Recognized 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 destination 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 originating exchange.
7.6.2.2.4		When receiving the signal indicating that the call has been connected, 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 waiting 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 performed 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 applicable 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 confirmation in this phase could still be applied independent of the presence of the negotiation in the call request phase/call confirmation phase. However, definitions 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 confirmation 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 applicable 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 parameter if they wish.