6.14.2	Closed user group with outgoing access
	Closed user group with outgoing access is an optional user facility agreed for a period of time for virtual calls. This user facility, if subscribed to, enables the DTE to belong to one or more closed user groups (as in § 6.14.1) and to originate virtual calls to DTEs in the open part of the network (i.e., DTEs not belonging to any closed user group) and to DTEs belonging to other CUGs with the incoming access capability.
	When the closed user group with outgoing access facility is subscribed to and the DTE has a preferential CUG, then only the closed user group selection facility (as in § 6.14.6) is applicable for use at the interface.
	When the closed user group with outgoing access facility is subscribed to and the network offers to the DTE the capability of choosing whether or not to have a preferential CUG (i.e., the closed user group with outgoing access selection facility (see § 6.14.7) is offered by the network), and the DTE has no preferential CUG, then both the closed user group selection and the closed user group with outgoing access selection facilities are applicable for use at the interface.
6.14.3	Closed user group with incoming access
	Closed user group with incoming access is an optional user facility agreed for a period of time for virtual calls. This user facility, if subscribed to, enables the DTE to belong to one or more closed user groups (as in § 6.14.1) and to receive incoming calls from DTEs in the open part part of the network (i.e., DTEs not belonging to any closed user group) and from DTEs belonging to other CUGs with the outgoing access capability.
	When the closed user group with incoming access facility is subscribed to and the DTE has a preferential CUG, then only the closed user group selection facility is applicable for use at the interface.
	When the closed user group with incoming access facility is subscribed to and the network offers to the DTE the capability of choosing whether or not to have a preferential CUG (i.e., the closed user group with outgoing access selection facility is offered by the network), and the DTE has no preferential CUG, then both the closed user group selection and the closed user group with outgoing access selection facilities are applicable for use at the interface.
6.14.4	Incoming calls barred within a closed user group
	Incoming calls barred within a closed user group is an optional user facility agreed for a period of time. This user facility, if subscribed to for a given closed user group, permits the DTE to originate virtual calls to DTEs in this closed user group, but precludes the reception of incoming calls from DTEs in this closed user group.
6.14.5	Outgoing calls with barred within a closed user group
	Outgoing calls barred within a closed user group is an optional user facility agreed for a period of time. This user facility, if subscribed for a given closed user group, permits the DTE to receive virtual calls from DTEs in this closed user group, but prevents the DTE from originating virtual calls to DTEs in this closed user group.
6.14.6	Closed user group selection
	Closed user group selection is an optional user facility which may be used on a per virtual call basis. This facility may be requested or received by a DTE only if it has subscribed to the closed user group facility, or the closed user group with outgoing access facility and/or the closed user group with incoming access facility.
	The closed user group selection facility (see §§ 7.2.1 and 7.2.2.3) may be used by the calling DTE in the call request packet to specify the closed user group selected for a virtual call.
	The closed user group selection facility is used in the incoming call packet to indicate to the called DTE the closed user group selected for a virtual call.
	The number of closed user groups to which a DTE can belong is network dependent. If the maximum value of the index assigned for use by the DTE to select the closed user group is 99 or less, the basic format of the closed user group selection facility must be used. If the maximum value of the index assigned is between 100 and 9999, the extended format of the closed user group selection facility must be used.
	Some networks may permit a DTE to use either the basic or extended format of the closed user group selection facility when the index is 99 or less.
	Note – When a DTE subscribes to less than 101 closed user groups, the network should be able to agree on a maximum value of the index smaller than 100 if requested by the DTE.
	The appearance in a call request packet of both formats, or a format inconsistent with the number of CUGs subscribed to, will be treated as a facility code not allowed.
	The significance of the closed user group selection facility in call request packets is given in Table 26/X.25 and in incoming call packets is given in Table 27/X.25.
6.14.7	Closed user group with outgoing access selection
	Closed user group with outgoing access selection is an optional user facility which may be used on a per virtual call basis. This facility may be requested by a DTE only if the network supports it and the DTE has subscribed to the closed user group with outgoing access facility or to both the closed user group with outgoing access and closed user group with incoming access facilities. This facility may be received by a DTE only if the network supports it and the DTE has subscribed to the closed user group with incoming access facility or to both the closed user group with incoming access and closed user group with outgoing access facilities.
	The closed user group with outgoing access selection facility (see §§ 7.2.1 and 7.2.2.4) may be used by the calling DTE in the call request packet to specify the closed user group selected for a virtual call and to indicate that outgoing access is also desired.
TABLE 26/X.25
Meaning of closed user group facilities in call request packets
Contents of call request packet (see Note 2)				
	 Closed user group selection facility	 Closed user group with outgoing access selection facility	 Neither closed user group selection nor closed user group with outgoing access selection facility	
Closed user group subscription of the calling DTE (see Note 1)				
CUG with preferential 
(see Note 3)	 CUG specified 
(see Note 4)	 Not allowed 
(call cleared)	 Preferential or only CUG (see Note 4)	
 CUG/IA with preferential	 CUG specified 
(see Note 4)	 Not allowed 
(call cleared)	 Preferential or only CUG (see Note 4)	
 CUG/OA with preferential	 CUG specified + outgoing access
 (see Note 4)	 Not allowed 
(call cleared)	 Preferential or only CUG + outgoing access 
(see Notes 5, 6)	
 CUG/IA/OA with preferential	 CUG specified + 
outgoing access 
(see Note 4)	 Not allowed 
(call cleared)	 Preferential or only CUG + outgoing access 
(see Notes 5, 6)	
 CUG/IA without preferential	 CUG specified 
(see Note 4)	 Not allowed 
(call cleared)	 Not allowed 
(call cleared)	
 CUG/OA without preferential	 CUG specified 
(see Note 4)	 CUG specified + outgoing access (see Notes 5, 6)	 Outgoing access	
 CUG/IA/OA without preferential	 CUG specified 
(see Note 4)	 CUG specified + outgoing access 
(see Notes 5, 6)	 Outgoing access	
 No CUG	 Not allowed 
(call cleared)	 Not allowed 
(call cleared)	 Outgoing access	
OA: Outgoing access
IA:  Incoming access
Note 1 – The order of subscription types is different from that in Table 27/X.25.
Note 2 – The inclusion of both the closed user group selection facility and the closed user group with outgoing access selection facility is not allowed in the call request packet.
Note 3 – CUG without preferential is not allowed.
Note 4 – If outgoing calls are barred within the specified CUG or within the preferential or only CUG, then the call is cleared.
Note 5 – If outgoing calls are barred within the specified CUG or within the preferential or only CUG, then only outgoing access applies.
Note 6 – For international calls, if the destination network does not support the closed user group with outgoing access selection facility, the call may be cleared even if the called DTE belongs to the specified closed user group or to the open world or has incoming access.

TABLE 27/X.25
Meaning of closed user group facilities in incoming call packets
Contents of incoming call packet 				
	 Closed user group selection facility	 Closed user group with outgoing access selection facility	 Neither closed user group selection nor closed user group with outgoing access selection facility	
Closed user group Lsubscription of the called DTE (see Note 1)				
CUG with preferential 
(see Note 2)	 CUG specified (see Note 3)	 Not applicable	 Preferential or only CUG (see Note 3)	
 CUG/OA with preferential	 CUG specified (see Note 3)	 Not applicable	 Preferential or only CUG (see Note 3)	
 CUG/IA with preferential	 CUG specified + incoming access (see Note 4)	 Not applicable	 Preferential or only CUG + incoming access (see Note 5)	
 CUG/IA/OA with preferential	 CUG specified + incoming access (see Note 4)	 Not applicable	 Preferential or only CUG + incoming access (see Note 5)	
 CUG/OA without preferential	 CUG specified (see Note 3)	 Not applicable	 Not applicable	
 CUG/IA without preferential	 CUG specified (see Note 3)	 CUG specified + incoming access (see Note 4)	 Incoming access	
 CUG/IA/OA without preferential	 CUG specified (see Note 3)	 CUG specified + incoming access (see Note 4)	 Incoming access	
 No CUG	 Not applicable	 Not applicable	 Incoming access	
 OA: Outgoing access
IA: Incoming access
Note 1 – The order of subscription types is different from that in Table 26/X.25.
Note 2 – CUG without preferential is not allowed.
Note 3 – When incoming calls are barred within this CUG, the call is blocked; there is no incoming call.
Note 4 – When incoming calls are barred within this CUG, only incoming access applies and the incoming call packet carries neither the closed user group selection nor the closed user group with outgoing access selection facility.
Note 5 – When incoming calls are barred within this CUG, only incoming access applies.
	The closed user group with outgoing access selection facility is used in the incoming call packet to indicate to the called DTE the closed user group selected for a virtual call and that outgoing access had applied at the calling DTE.
	The closed user group with outgoing access selection facility can only be present in the facility field of call set–up packets if the DTE does not have a preferential closed user group.

	The number of closed user groups to which a DTE can belong is network dependent. If the maximum value of the index assigned for use by the DTE to select the closed user group is 99 or less, the basic format of the closed user group with outgoing access selection facility must be used. If the maximum value of the index assigned is between 100 and 9999, the extended format of the closed user group with outgoing access selection facility must be used.
	Some networks may permit a DTE to use either the basic or extended format of the closed user group with outgoing access selection facility when the index is 99 or less.
	Note – When a DTE subscribes to less than 101 closed user groups, the network should be able to agree to a maximum value of the index smaller than 100 if requested by the DTE.
	The appearance in a call request packet of both formats or a format inconsistent with the number of CUGs subscribed to will be treated as a facility code not allowed.
	The significance of the presence of the closed user group with outgoing access selection facility in call request packets is given in Table 26/X.25 and in incoming call packets is given in Table 27/X.25.
6.14.8	Absence of both CUG selection facilities
	The significance of the absence of both the closed user group selection facility and the closed user group with outgoing access selection facility in call request packets is given in Table 26/X.25 and in incoming call packets is given in Table 27/X.25.
6.15	Bilateral closed user group related facilities
	The set of bilateral closed user group (BCUG) optional user facilities enables pairs of DTEs to form bilateral relations allowing access between each other while excluding access to or from other DTEs with which such a relation has not been formed. Different combinations of access restrictions for DTEs having these facilities result in various combinations of accessibility.
	A DTE may belong to one or more BCUGs. Each DTE belonging to at least one BCUG has either the bilateral closed user group facility (see § 6.15.1) or the bilateral closed user group with outgoing access facility (see § 6.15.2). For a given BCUG, it is permissible for one DTE to subscribe to the bilateral closed user group facility while the other DTE subscribes to the bilateral closed user group with outgoing access facility.
	When a DTE belonging to one or more BCUGs places a virtual call, the DTE should indicate in the call request packet the BCUG selected by using the bilateral closed user group selection facility (see § 6.15.3). When a DTE belonging to one or more BCUGs receives a virtual call, the BCUG selected will be indicated in the incoming call packet through the use of the bilateral closed user group selection facility.
	The number of BCUGs to which a DTE can belong is network dependent.
6.15.1	Bilateral closed user group
	Bilateral closed user group is an optional user facility agreed for a period of time for virtual calls. This facility, if subscribed to, enables the DTE to belong to one or more bilateral closed user groups. A bilateral closed user group permits a pair of DTEs who bilaterally agree to communicate with each other to do so, but precludes communication with all other DTEs.
6.15.2	Bilateral closed user group with outgoing access
	Bilateral closed user group with outgoing access is an optional user facility agreed for a period of time for virtual calls. This facility, if subscribed to, enables the DTE to belong to one or more bilateral closed user groups (as in § 6.15.1) and to originate virtual calls to DTEs in the open part of the network (i.e., DTEs not belonging to any bilateral closed user group).
6.15.3	Bilateral closed user group selection
	Bilateral closed user group selection is an optional user facility which may be used on a per virtual call basis. This facility should be requested or will only be received by a DTE if it has subscribed to the bilateral closed user group facility (see § 6.15.1), or the bilateral closed user group with outgoing access facility (see § 6.15.2).
	The bilateral closed user group selection facility (see §§ 7.2.1 and 7.2.2.5) is used by the calling DTE in the call request packet to specify the bilateral closed user group selected for a virtual call. The called DTE address length shall be coded all zeros.
	The bilateral closed user group selection facility is used in the incoming call packet to indicate to the called DTE, the bilateral closed user group selected for a virtual call. The calling DTE address length will be coded all zeros.
6.16	Fast select
	Fast select is an optional user facility which may be requested by a DTE for a given virtual call.
	DTEs can request the fast select facility on a per call basis by means of an appropriate facility request (see §§ 7.2.1 and 7.2.2.6) in a call request packet using any logical channel which has been assigned to virtual calls.
	The fast select facility, if requested in the call request packet and if it indicates no restriction on response, allows this packet to contain a call user data field of up to 128 octets, authorizes the DCE to transmit to the DTE, during the DTE waiting state, a call connected or clear indication packet with a called or clear user data field respectively of up to 128 octets, and authorizes the DTE and the DCE to transmit after the call is connected, a clear request or a clear indication packet, respectively, with a clear user data field of up to 128 octets.
	The fast select facility, if requested in the call request packet and if it indicates restriction on response, allows this packet to contain a call user data field of up to 128 octets and authorizes the DCE to transmit to the DTE, during the DTE waiting state, a clear indication packet with a clear user data field of up to 128 octets; the DCE would not be authorized to transmit a call connected packet.
	When a DTE requests the fast select facility in a call request packet, the incoming call packet should only be delivered to the called DTE if that DTE has subscribed to the fast select acceptance facility (see § 6.17).
	If the called DTE has subscribed to the fast select acceptance facility, it will be advised that the fast select facility, and an indication of whether or not there is a restriction on the response, has been requested through the inclusion of the appropriate facility (see §§ 7.2.1 and 7.2.2.6) in the incoming call packet.
	If the called DTE has not subscribed to the fast select acceptance facility, an incoming call packet with the fast select facility requested will not be transmitted and a clear indication packet with the cause “Fast select acceptance not subscribed” will be returned to the calling DTE.
	The presence of the fast select facility indicating no restriction on response in an incoming call packet permits the DTE to issue as a direct response to this packet a call accepted or clear request packet with a called or clear user data field, respectively, of up to 128 octets. If the call is connected, the DTE and the DCE are then authorized to transmit a clear request or a clear indication packet, respectively, with a clear user data field of up to 128 octets.
	The presence of the fast select facility indicating restriction on response in an incoming call packet permits the DTE to issue as a direct response to this packet a clear request packet with a clear user data field of up to 128 octets; the DTE would not be authorized to send a call accepted packet.
	Note – The call user data field, the called user data field and the clear user data field will not be fragmented for delivery across the DTE/DCE interface.
	The significance of the call connected packet or the clear indication packet with the cause “DTE originated” as a direct response to the call request packet with the fast select facility is that the call request packet with the data field has been received by the called DTE.
	All other procedures of a call in which the fast select facility has been requested are the same as those of a virtual call.
6.17	Fast select acceptance
	Fast select acceptance is an optional user facility agreed for a period of time. This user facility, if subscribed to, authorizes the DCE to transmit to the DTE incoming calls which request the fast select facility. In the absence of this facility, the DCE will not transmit to the DTE incoming calls which request the fast select facility.
6.18	Reverse charging
	Reverse charging is an optional user facility which may be requested by a DTE for a given virtual call (see §§ 7.2.1 and 7.2.2.6).
6.19	Reverse charging acceptance
	Reverse charging acceptance is an optional user facility agreed for a period of time for virtual calls. This user facility, if subscribed to, authorizes the DCE to transmit to the DTE incoming calls which request the reverse charging facility. In the absence of this facility, the DCE will not transmit to the DTE incoming calls which request the reverse charging facility.
6.20	Local charging prevention
	Local charging prevention is an optional user facility agreed for a period of time for virtual calls. This user facility, when subscribed to, authorizes the DCE to prevent the establishment of virtual calls which the subscriber must pay for by:
a)	not transmitting to the DTE incoming calls which request the reverse charging facility, and
b)	ensuring 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 user of reverse charging,
–	identification of a third party using NUI subscription facility (see § 6.21.1) and NUI selection facility (see § 6.21.3).
	When the party to be charged has not been established for a call request, the DCE that receives the call request packet 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.
6.21	Network user identification (NUI) related facilities
	The set of network user identification (NUI) related facilities enables the DTE to provide information to the network for purposes of billing, security, network management, or to invoke subscribed facilities.
	This set is composed of three optional user facilities, NUI subscription facility (see § 6.21.1) and NUI override facility (see § 6.21.2) may be agreed for a period of time for virtual calls. A DTE may subscribe to one or both of these facilities. When one or both of these facilities are subscribed to, one or several network user identifiers are also agreed for a period of time. A given network user identifier may be either specific or common to NUI subscription facility and NUI override facility. The network user identifier is transmitted by the DTE to the DCE in the NUI selection facility (see § 6.21.3).
	Network user identifier 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 identifier transmitted by the DTE in the NUI selection facility in the call request packet.
6.21.1	NUI subscription
	NUI subscription is an optional user facility agreed for a period of time for virtual calls. This facility, if subscribed to, enables the DTE to provide information to the network for billing, security or network management purposes on a per call basis. This information may be provided by the DTE in the call request packet or in the call accepted packet by using the NUI selection facility (see § 6.21.3). It may be used whether or not the DTE has also subscribed to the local charging prevention facility (see § 6.20). If the DCE determines that the network user identifier is invalid or that the NUI selection facility is not present when required by the network, it will clear the call as described in Annex C.
6.21.2	NUI override
	NUI override is an optional user facility agreed for a period of time for virtual calls. When this facility is subscribed to, one or more network user identifiers are also agreed for a period of time. Associated with each network user identifier is a set of subscription–time optional user facilities. When one of these network user identifiers is provided in a call request packet by means of the NUI selection facility (see § 6.21.3), the set of subscription–time optional user facilities associated with it overrides the facilities which apply to the interface. This override does not apply to other 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 user facilities that may be associated with a network user identifier when the NUI override facility has been subscribed to are specified in Annex H. The optional user facilities which have been agreed for a period of time for the interface and which are not overriden by using the NUI override facility remain in effect.
6.21.3	NUI selection
	NUI selection is an optional user facility which may be requested by a DTE for a given virtual call (see §§ 7.2.1 and 7.2.2.7). This user facility may be requested by a DTE only if it has subscribed to the NUI subscription facility (see § 6.21.1) and/or the NUI override facility. NUI selection facility permits the DTE to specify which network user identifier is to be used in conjunction with the NUI subscription facility and/or the NUI override facility.
	NUI selection may be requested in a call request packet if the selected network user identifier has been agreed in conjunction with the NUI subscription facility or the NUI override facility. NUI selection may be requested in the call accepted packet if the selected network user identifier has been agreed in conjunction with the NUI subscription facility.
	Some networks may require that the NUI selection facility be requested by the DTE in every call request packet and, possibly, in every call accepted packet transmitted on a given DTE/DCE interface, when the NUI subscription facility has been agreed for a period of time for the interface.
	If the network determines that the network user identifier is invalid or that any of the optional user facilities requested in the call request packet are not allowed for the DTE, it will clear the call.
6.22	Charging information
	Charging information is an optional user facility which may be either agreed for a period of time or requested by a DTE for a given virtual 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 (see §§ 7.2.1 and 7.2.2.8.1) in a call request packet or call accepted packet.
	If a DTE subscribes to the charging information 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 call request or call accepted packets.
	Using the clear indication or DCE clear confirmation packet, the DCE will send to the DTE information about the charge for that call and/or other information which makes it possible for the user to calculate the charge.
6.23	RPOA related facilities
	The set of RPOA optional user facilities provides for the calling DTEs designation of a sequence of one or more RPOA transit network(s) within the originating country through which the call is to be routed when more than one RPOA transit network exists at a sequence of one or more gateways. In the case of international calls, this capability includes the selection of an international RPOA in the originating country.
6.23.1	RPOA subscription
	RPOA subscription is an optional user facility agreed for a period of time for virtual calls. This user facility, if subscribed to, applies (unless overriden for a single virtual call by the RPOA selection facility) to all virtual calls where more than one RPOA transit network exist at a sequence of one or more gateways. The RPOA subscription facility provides a sequence of RPOA transit networks through which calls are to be routed. In the absence of both the RPOA subscription facility and the RPOA selection facility (see § 6.23.2), no user designation of RPOA transit networks is in effect.
6.23.2	RPOA selection
	RPOA selection is an optional user facility which may be requested by a DTE for a given virtual call (see §§ 7.2.1 and 7.2.2.9). It is not necessary to subscribe to the RPOA subscription facility in order to use this facility. This facility, when used for a given virtual call, applies for this virtual call only where more than one RPOA transit network exist at a sequence of one or more gateways. The RPOA selection facility provides a sequence of RPOA transit networks through which the call is to be routed. The presence of this facility in a call request packet completely overrides the sequence of RPOA transit networks that may have been specified by the RPOA subscription facility (see § 6.23.1).
	If the DTE selects only one RPOA transit network, either the basic or extended format of the RPOA selection facility may be used. If the DTE selects more than one RPOA transit network, the extended format of the RPOA selection facility is used. The appearance of both formats in a call request packet will be treated as a facility code not allowed.
6.24	Hunt group
	Hunt group is an optional user facility agreed for a period of time. This user facility, if subscribed to, distributes incoming calls having an address associated with the hunt group across a designated grouping of DTE/DCE interfaces.
	Selection is performed for an incoming virtual call if there is at least one idle logical channel, excluding one–way outgoing logical channels, available for virtual calls on any of the DTE/DCE interfaces in the group. Once a virtual call is assigned to a DTE/DCE interface, it is treated as a regular call.
	When virtual calls are placed to a hunt group address in the case that specific addresses have also been assigned to the individual DTE/DCE interfaces, the clear indication packet (when no call accepted packet has been transmitted) or the call connected packet transferred to the calling DTE optionally will contain the called DTE address of the selected DTE/DCE interface and the called line address modified notification facility (see § 6.26) indicating the reason why the called DTE address is different from the one originally requested.
	Virtual calls may be originated by the DTEs on DTE/DCE interfaces belonging to the hunt group; these are handled in the normal manner. In particular, the calling DTE address transferred to the remote DTE in the incoming call packet is the hunt group address unless the DTE/DCE interface has a specific address assigned. Permanent virtual circuits may be assigned to DTE/DCE interfaces belonging to the hunt group. These permanent virtual circuits are independent of the operation of the hunt group. Some networks may apply virtual call subscription time user facilities in 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.
6.25	Call redirection and call deflection related facilities
	The set of call redirection and call deflection optional user facilities enables the redirection or the deflection of calls destined to one DTE (the “originally called DTE”) to another DTE (“the alternative DTE”). The call redirection facility (see § 6.25.1) allows the DCE, in specific circumstances, to redirect calls destined to the originally called DTE; no incoming call packet is transmitted to the originally called DTE when such a redirection is performed. The call deflection related facilities (see § 6.25.2) allow the originally called DTE to deflect individual incoming virtual calls after reception of the incoming call packet by this originally called DTE. A DTE may subscribe to the call redirection facility, to the call deflection subscription facility, or to both.
	When a call to which the call redirection or call deflection facilities are applied is cleared, the clearing cause shall be that generated during the last attempt to reach a called DTE/DCE interface.
	Call redirection or call deflection is limited to the network of the DTE originally called.
	The basic service is limited to one call redirection or call deflection. In addition, some networks may permit a chaining of several call redirections or call deflections. In all cases, networks will ensure that loops are avoided and that the connection establishment phase has a limited duration, consistent with the DTE time limit T21 (see Table D‑2/X.25).
	When the virtual call is redirected or deflected, the clear indication packet, when no call accepted packet has been transmitted by any DTE, or the call connected packet transferred to the calling DTE will contain the called address of the alternative DTE and the called line address modified notification facility (see § 6.26), indicating the reason why the called address is different from the one originally requested.
	When the virtual call is redirected or deflected, some networks may indicate to the alternative DTE that the call was redirected or deflected, the reason for redirection or deflection, and the address of the originally called DTE, using the call redirection or call deflection notification facility (see § 6.25.3) in the incoming call packet.
	Further information on the coding of the alternative DTE address is given in Appendix IV/X.25.
6.25.1	Call redirection
	Call redirection is an optional user facility agreed for a period of time. This user facility, if subscribed to, redirects calls destined to this DTE when:
1)	the DTE is out of order, or
2)	the DTE is busy.
	Some networks may provide call redirection only in case of 1). Some networks may offer, in addition:
3)	systematic call redirection due to a prior request by the subscriber according to criteria other than 1) and 2) above, agreed to between the network and the subscriber.
	In addition to the basic service, some networks may offer either one of the following (mutually exclusive) capabilities:
1)	a list of alternative DTEs (C1, C2, . . .) is stored by the network of the originally called DTE (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.
	The order of call set–up processing at the originally called DCE as well as the alternative DCE will be according to the sequence of call progress signals in Table 1/X.96. For those networks that provide systematic call redirection due to a prior request by the subscriber, the systematic call redirection request will have the highest priority in the call set–up processing sequence at the originally called DCE.
6.25.2	Call deflection related facilities
6.25.2.1	Call deflection subscription
	Call deflection subscription is an optional user facility agreed for a period of time. This facility, if subscribed to, enables the DTE to request, by using the call deflection selection facility (see § 6.25.2.2), that an individual call presented to it by transmission of an incoming call packet be deflected to an alternative DTE.
	The DCE may use a network timer, with a value agreed to with the subscriber, to limit the time between the transmission to the originally called DTE or an incoming call packet and the request by this originally called DTE of deflecting the call. Once this timer has expired, the originally called DTE will no longer be permitted to use the call deflection selection facility to deflect the call. If the originally called DTE tries to deflect the call after the expiration of this internal timer, the network clears the call.
6.25.2.2	Call deflection selection
	Call deflection selection is an optional user facility which may be used on a per virtual call basis. This facility may be requested by a DTE only if it has subscribed to the call deflection subscription facility (see § 6.25.2.1).
	The call deflection selection facility (see §§ 7.2.1 and 7.2.2.10) may be used by the called DTE in the clear request packet only in direct response to an incoming call packet to specify the alternative DTE address to which the call is to be deflected. If the call deflection selection facility is used in the clear request packet, then the DTE must also include any CCITT– specified DTE facilities and user data to be sent to the alternative DTE. Up to 16 octets of user data may be included in the clear request packet in this case, if the original call was established without fast select; up to 128 octets of user data may be included in the clear request packet if the original call was established with fast select. If no CCITT–specified DTE facilities are included in the clear request packet, then there will be none in the incoming call packet to the alternative DTE. If no clear user data is included in the clear request packet, then no call user data will be included in the incoming call packet to the alternative DTE. When requested for a given virtual call, the network deflects the call to the alternative DTE and does not respond to the calling DTE as a result of the clearing of the originally called DTE/DCE interface. The X.25 facilities that are present in the incoming call packet transmitted to the alternative DTE are those that would have been present in the incoming call packet if the call was a direct call from the calling DTE to the alternative DTE; moreover, the call redirection or call deflection notification facility (see § 6.25.3) may also be present, if supported by the network.
	Note – For an interim period, some networks may not allow a deflected incoming call packet's contents to be modified, in which case a deflecting DTE is not permitted to use any user data or CCITT–defined DTE facilities in the clear request packet.
	The bit 7 of the General Format Identifier (see § 4.3.3) in the incoming call packet transmitted to the originally called DTE or the alternative DTE has the same value as the same bit in the call request packet.
	If the network offers only the basic service and if a call redirection or call deflection has already been performed, the DCE clears the call as indicated in Annex C when the call deflection selection facility is used.
6.25.3	Call redirection or call deflection notification
	Call redirection or call deflection notification is a user facility used by the DCE in the incoming call packet to inform the alternative DTE that the call has been redirected or deflected, why the call was redirected or deflected, and the address of the originally called DTE.
	The following reasons can be indicated with the use of the call redirection or call deflection notification facility (see § 7.2.1 and 7.2.2.11):
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.
	Some networks may also use the following reason in network–dependent cases not described in this Recommendation:
5)	call distribution within a hunt group.
6.26	Called line address modified notification
	Called line address modified notification is an optional user facility used by the DCE in the call connected or clear indication packets (see §§ 7.2.1 and 7.2.2.12) to inform the calling DTE why the called DTE address in the packet is different from that specified in the call request packet.
	When more than one address applies to a DTE/DCE interface, the called line address modified notification facility may be used by the DTE in the clear request packet (when no call accepted packet has been transmitted) or the call accepted packet, when the called DTE address is present in the packet and different from that specified in the incoming call packet. When this facility is received from the DTE, the DCE will clear the call if the called DTE address is not one of those applying to the interface.
	Note – The DTE should be aware that a modification of any part of the called DTE address 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 connected or clear indication packets transmitted to the calling DTE:
1)	call distribution within 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 a prior request from the originally called DTE according to criteria agreed to between the network and the subscriber,
5)	called DTE originated,
6)	call deflection by the originally called DTE.
	In call accepted or clear request packets, the reason indicated in conjunction with the use of the called line address modified notification facility should be “Called DTE originated”.
	When several reasons could apply to a same call, the reason to be indicated by the network in the call connected or the clear indication packet by means of the called line address modified notification facility is as specified below:
1)	the indication of a call redirection or call deflection in the network has precedence over the indication of distribution within a hunt group or over a called DTE originated indication,
2)	the called DTE originated indication has precedence over the indication of distribution within a hunt group,
3)	when several call redirections or call deflections have been performed, the first one has precedence over the others.
	The called DTE address indicated in the call connected or the clear indication packets should correspond to the last DTE which has been reached or attempted.
6.27	Transit delay selection and indication
	Transit delay selection and indication is an optional user facility which may be requested by a DTE for a given virtual call. This facility permits selection and indication, on a per call basis, of the transit delay applicable to that virtual call as defined in § 4.3.8.
	A DTE wishing to specify a desired transit delay in the call request packet for a virtual call indicates the desired value (see §§ 7.2.1 and 7.2.2.13).
	The network, when able to do so, should allocate resources and route the virtual call in a manner such that the transit delay applicable to that call does not exceed the desired transit delay.
	The incoming call packet transmitted to the called DTE and the call connected packet transmitted to the calling DTE, will both contain the indication of the transit delay applicable to the virtual call. This transit delay may be smaller than, equal to, or greater than the desired transit delay requested in the call request packet.
	Note – During the interim period when this optional user facility is not yet supported by all networks, the indication of the transit delay applicable to the virtual call will not be provided in the incoming call packet transmitted to the called DTE, if either a transit network or the destination network does not support this facility.
6.28	TOA/NPI address subscription
	Note – This facility is designated in Recommendation X.2 for further study (FS).
	TOA/NPI address subscription is an optional user facility agreed for a period of time for virtual calls.
	When this facility is subscribed to, the DCE and the DTE shall always use the TOA/NPI address format of the call set–up and clearing packets transmitted between the DCE and the DTE (see § 5.2.1).
	When the DCE needs to transmit an incoming call packet to a DTE which has not been subscribed to this facility, and the calling DTE address to be transmitted in this packet cannot be contained in the non–TOA/NPI address format of the address block, the DCE will include no calling DTE address.
	Note – Some Administrations may provide a subscription–time option of the TOA/NPI address subscription facility, allowing the user to indicate that the DCE shall clear the call with cause “incompatible destination” and a specific diagnostic in the case described in that last paragraph above, rather than include no calling DTE address.
7	Formats for facility fields and registration fields
7.1	General
	The facility field is present only when a DTE is using an optional user facility requiring some indication in the call request, incoming call, call accepted, call connected, clear request, clear indication or DCE clear confirmation packet.
	The registration field is present in a registration request packet only when the DTE wishes to request the DCE to agree or to stop a previous agreement for an optional user facility and is present in a registration confirmation packet when the DCE whishes to indicate which optional user facilities are available or which optional user facilities are currently in effect.
	The facility/registration field contains one or more facility/registration elements. The first octet of each facility/registration element contains a facility/registration code to indicate the facility or facilities requested/negociated.
	The facility/registration codes are divided into four classes, by making use of bits 8 and 7 of the facility/registration code field, in order to specify facility/registration parameters consisting of 1, 2, 3 or a variable number of octets. The general class coding of the facility/registration code field is shown in Table 28/X.25.
TABLE 28/X.25
General class coding for facility/registration code fields
Bits	 8	 7	 6	 5	 4	 3	 2	 1		
Class A	 0	 0	 X	 X	 X	 X	 X	 X	 for single octet parameter field	
 Class B	 0	 1	 X	 X	 X	 X	 X	 X	 for double octet parameter field	
 Class C	 1	 0	 X	 X	 X	 X	 X	 X	 for triple octet parameter field	
 Class D	 1	 1	 X	 X	 X	 X	 X	 X	 for variable length parameter field	
	For class D the octet following the facility/registration code indicates the length, in octets, of the facility/registration parameter field. The facility/registration parameter field length is binary coded and bit 1 is the low order bit of this indicator.
	The formats for the four classes are shown in Figure 23/X.25.
	The facility/registration code field is binary coded and, without extension, provides for a maximum of 64 facility/registration codes for classes A, B and C and 63 facility/registration codes for class D giving a total of 255 facility/registration codes.
	Facility/registration code 11111111 is reserved for extension of the facility/registration code. The octet following this octet indicates an extended facility/registration code having the format A, B, C and D as defined above. Repetition of facility/registration code 11111111 is permitted and additional extensions thus result.
	The coding of the facility/registration parameter field is dependent on the facility being requested/negociated.
	A facility/registration code may be assigned to identify a number of specific facilities, each having a bit in the parameter field indicating facility requested/facility not requested. In this situation, the parameter field is binary encoded with each bit position relating to a specific facility. A 0 indicates that the facility related to the particular bit is not requested and a 1 indicates that the facility related to the particular bit is requested. Parameter bit positions not assigned to a spectific facility are set to zero. If none of the facilities represented by the facility/registration code are requested for a virtual call or for on–line facility registration, the facility/registration code and its associated parameter field need not be present.
	In addition to the facility/registration codes defined in § 7, other codes may be used for:
–	non–X.25 facilities which may be provided by some network(s) (call set–up and registration packets);
–	CCITT–specified DTE facilities as described in Annex G of this Recommendation (call set–up, clear request and clear indication packets).

	Class A										Class B										
		Bits										Bits									
		 8	 7	 6	 5	 4	 3	 2	 1			 8	 7	 6	 5	 4	 3	 2	 1		
	Octets										Octets										
	0	 0	 0	 X	 X	 X	 X	 X	 X		 0	 0	 1	 X	 X	 X	 X	 X	 X		
	1	Facility/registration parameter field									1		Facility/registration								
											2	parameter field									
	Class C										Class D										
		Bits										Bits									
		 8	 7	 6	 5	 4	 3	 2	 1			 8	 7	 6	 5	 4	 3	 2	 1		
	Octets										Octets										
	0	 1	 0	 X	 X	X	 X	 X	 X		0	 1	 1	 X	 X	 X	 X	 X	 X		
	 1		Facility/registration								1	Facility/registration 
parameter field length									
	 2		parameter								2	Facility/registration parameter field									
	3		field																		
																					
FIGURE 23/X.25
Facility/registration element general formats
	Facility/registration markers, consisting of a single octet pair, are used to separate requests for X.25 facilities as defined in §§ 6 and 7 from other categories as defined above, and, when several categories of facilities are simultaneously present, to separate these categories from each other.
	The first octet of the marker is a facility/registration code field and is set to zero. The second octet is a facility/registration parameter field.
	The facility/registration parameter field of a marker is set to zero when the marker precedes requests for:
–	registration codes specific to the local network (registration packets);
–	non–X.25 facilities provided by the network in case of intranetwork calls (call set–up packets);
–	non–X.25 facilities provided by the network to which the calling DTE is connected, in case of internetwork calls (call set–up packets).

	The facility parameter field of a marker is set to all ones when the marker precedes requests for non–X.25 facilities provided by the network to which the called DTE is connected, in case of internetwork calls (call set–up packets).
	The facility parameter field of a marker is set to 00001111 when the marker precedes requests for CCITT–specfied DTE facilities.
	All networks will support the facility markers with a facility parameter field set to all ones or to 00001111.
	DTEs should not use a facility marker with a facility parameter field set to all ones in case of intranetwork calls. However, if a DTE uses such a marker in an intranetwork call, the DCE is not obliged to clear the call, and the marker, with the corresponding facility requests, may be transmitted to the remote DTE.
	Facility/registration codes for X.25 facilities and for the other categories of facilities may be simultaneously present. However, requests for X.25 facilities must precede the other requests, and requests for CCITT–specified DTE facilities must follow the other requests.
	The coding of CCITT–specified DTE facilities should comply with the description in Annex G. However, the DCE is not required to verify that compliance. If the network verifies that compliance and finds an error, it may clear the call with the cause “Invalid facility request”. The CCITT–specified DTE facilities are passed unchanged by public data networks between the two packet–mode DTEs.
7.2	Coding of facility field in call set–up and clearing packets
	The coding of the facility code field and the format of the facility parameter field are the same in the various call set–up and clearing packets in which they are used.
7.2.1	Coding of the facility code fields
	Table 29/X.25 gives the coding of the facility code fields and the packet types in which they may be present.
7.2.2	Coding of the facility parameter fields
7.2.2.1	Flow control parameter negotiation facility
7.2.2.1.1	Packet size
	The packet size for the direction of transmission from the called DTE is indicated in bits 4, 3, 2 and 1 of the first octet of the facility parameter field. The packet size for the direction of transmission from the calling DTE is indicated in bits 4, 3, 2 and 1 of the second octet. Bits 8, 7, 6 and 5 of each octet must be zero.
	The four bits indicating each packet size are binary coded and express the logarithm base 2 of the number of octets of the maximum packet size.
	Networks may offer values from 4 to 12, corresponding to packet sizes of 16, 32, 64, 126, 256, 512, 1024, 2048 or 4096, or a contiguous subset of these values. All Administrations will provide a packet size of 128.
7.2.2.1.2	Window size
	The window size for the direction of transmission from the called DTE is indicated in bits 7 to 1 of the first octet of the facility parameter field. The window size for the direction of transmission from the calling DTE is indicated in bits 7 to 1 of the second octet. Bit 8 of each octet must be zero.
	The bits indicating each window size are binary coded and express the size of the window. A value of zero is not allowed.
TABLE 29/X.25
TABLE ON LANDSCAPE. (2 PAGES). CAN FIND IT IN FILE NAMED "25T29-E.DOC"
	Window sizes of 8 to 127 are only valid if extended sequence numbering is used (see § 6.2). The ranges of contiguous values allowed by a network for calls with normal numbering and extended numbering are network dependent. All Administrations will provide a window size of 2.
7.2.2.2	Throughput class negotiation facility
	The throughput class for the direction of data transmission from the called DTE is indicated in bits 8, 7, 6 and 5. The throughput class for the direction of data transmission from the calling DTE is indicated in bits 4, 3, 2 and 1.
	The four bits indicating each throughput class are binary coded and correspond to throughput classes as indicated in Table 30/X.25.
TABLE 30/X.25
Coding of throughput classes
Bits:	4	3	2	1		
or					Throughput class (bit/s)	
Bits:	8	7	6	5		
	0	0	0	0	Reserved	
	0	0	0	1	Reserved	
	0	0	1	0	Reserved	
	0	0	1	1	75	
	0	1	0	0	150	
	0	1	0	1	300	
	0	1	1	0	600	
	0	1	1	1	1 200	
	1	0	0	0	2 400	
	1	0	0	1	4 800	
	1	0	1	0	9 600	
	1	0	1	1	19 200	
	1	1	0	0	48 000	
	1	1	0	1	64 000	
	1	1	1	0	Reserved	
	1	1	1	1	Reserved	
7.2.2.3	Closed user group selection facility
7.2.2.3.1	Basic format
	The index to the closed user group selected for the virtual call is in the form of two decimal digits. Each digit is coded in a semi–octet in binary coded decimal with bit 5 being the low order bit of the first digit and bit 1 being the low order bit of the second digit.
	Indexes to the same closed user group at different DTE/DCE interfaces may be different.
7.2.2.3.2	Extended format
	The index to the closed user group selected for the virtual call is in the form of four decimal digits. Each digit is coded in a semi–octet in binary coded decimal with bit 5 of the first octet being the low order bit of the first digit, bit 1 of the first octet being the low order bit of the second digit, bit 5 of the second octet being the low order bit of the third digit and bit 1 of the second octet being the low order bit of the fourth digit.
	Indexes to the same closed user group at different DTE/DCE interfaces may be different.
7.2.2.4	Closed user group with outgoing access selection facility
7.2.2.4.1	Basic format
	The index to the closed user group selected for the virtual call is in the form of two decimal digits. Each digit is coded in a semi–octet in binary coded decimal with bit 5 being the low order bit of the first digit and bit 1 being the low order bit of the second digit.
	Indexes to the same closed user group at different DTE/DCE interfaces may be different.
7.2.2.4.2	Extended format
	The index to the closed user group selected for the virtual call is in the form of four decimal digits. Each digit is coded in a semi–octet in binary coded decimal with bit 5 of the first octet being the low order bit of the first digit, bit 1 of the first octet being the low order bit of the second digit, bit 5 of the second octet being the low order bit of the third digit, and bit 1 of the second octet being the low order bit of the fourth digit.
	Indexes to the same closed user group at different DTE/DCE interfaces may be different.
7.2.2.5	Bilateral closes user group selection facility
	The index to the bilateral closed user group selected for the virtual call is in the form of 4 decimal digits. Each digit is coded in a semi–octet in binary coded decimal with bit 5 of the first octet being the low order bit of the first digit, bit 1 of the first octet being the low order bit of the second digit, bit 5 of the second octet being the low order bit of the third digit, and bit 1 of the second octet being the low order bit of the fourth digit.
	Indexes to the same bilateral closed user group at different DTE/DCE interfaces may be different.
7.2.2.6	Reverse charging and fast select facilities
	The coding of the facility parameter field is:
Bit 1 = 0 for reverse charging not requested
Bit 1 = 1 for reverse charging requested
Bit 8 = 0 and bit 7 = 0 or 1	for fast select not requested
Bit 8 = 1 and bit 7 = 0		for fast select requested with no restriction on response
Bit 8 = 1 and bit 7 = 1		for fast select requested with restriction on response
	Note – Bits 6, 5, 4, 3 and 2 may be assigned to other facilities in the future; presently, they are set to 0.
7.2.2.7	NUI selection facility
	The octet following the facility code field indicates the length, in octets, of the facility parameter field. The following octets contain the network user identifier, in a format determined by the network administration.
7.2.2.8	Charging information facility
7.2.2.8.1	Parameter field for requesting service
	The coding of the facility parameter field is:
	Bit 1 = 0 for charging information not requested
	Bit 1 = 1 for charging information requested
	Note – Bits 8, 7, 6, 5, 4, 3 and 2 may be assigned to other facilities in the future; presently, they are set to 0.
7.2.2.8.2	Parameter field indicating monetary unit
	The octet following the facility code field indicates the length, in octets, of the facility parameter field.
	The parameter field indicates the charging. The coding of the parameter is for further study.
7.2.2.8.3	Parameter field indicating segment count
	The octet following the facility code field indicates the length, in octets, of the facility parameter field and has the value n ×8 where n is the number of different tariff periods managed by the network.
	For each tariff period, the first four octets of the facility parameter field indicate the number of segments sent to the DTE. The following four octets indicate the number of segments received from the DTE.
	Each digit is coded in a semi–octet in binary coded decimal and bit 1 or bit 5 of each semi–octet is the low order bit of each digit and bits 4 to 1 of the last octet represent the lowest order digit of the segment count.
	Segment size and the specific packet types to be counted are a matter of the Administration in the case of national calls and are specified in Recommendation D.12 for international calls.
	Note – The relationship between a particular tariff period and its place in the parameter field is a national matter. The order is given by each Administration.
7.2.2.8.4	Parameter field indicating call duration
	The octet following the facility code field indicates the length, in octets, of the facility parameter field and has the value n × 4 where n is the number of different tariff periods managed by the network.
	For each tariff period, the first octet of the facility parameter field indicates number of days, the second indicates number of hours, the third indicates number of minutes and the fourth indicates number of seconds. Each digit is coded in a semi–octet in binary coded decimal and bit 1 or bit 5 of each semi–octet is the low order bit of each digit. Bits 4 to 1 of each octet represent the low order digit.
	Note – The relationship between a particular tariff period and its place in the parameter field is a national matter. The order is given by each Administration.
7.2.2.9	RPOA selection facility
7.2.2.9.1	Basic format
	The parameter field contains the data network identification code for the requested initial RPOA transit network and is in the form of four decimal digits.
	Each digit is coded in a semi–octet in binary coded decimal with bit 5 of the first octet being the low order bit of the first digit, bit 1 of the first octet being the low order bit of the second digit, bit 5 of the second octet being the low order bit of the third digit, and bit 1 of the second octet being the low order bit of the fourth digit.
7.2.2.9.2	Extended format
	The octet following the facility code field indicates the length, in octets, of the facility parameter field and has the value n × 2, where n is the number of RPOA transit networks selected.
	Each RPOA transit network is indicated by a data network identification code, and is in the form of four decimal digits. Each digit is coded in a semi–octet in binary coded decimal with bit 5 of the first octet being the low order bit of the first digit, bit 1 of the first octet being the low order bit of the second digit, bit 5 of the second octet being the low order bit of the third digit, and bit 1 of the second octet being the low order of the fourth digit.
	RPOA transit network should appear in the facility parameter field in the order that the calling DTE wishes them to be traversed.
7.2.2.10	Call deflection selection facility
	The octet following the facility code indicates the length, in octets, of the facility parameter field and has the value n + 2, where n is the number of octets necessary to hold the called address of the DTE to which the call is to be deflected (the alternative DTE).

	The first octet of the facility parameter field indicates the reason for the DTE deflecting the call. The coding of this octet is:
	bits:	8	7	6	5	4	3	2	1
	or		1	1	X	X	X	X	X	X
	Note – Each X may be independently set to 0 of 1 by the called DTE and is passed transparently to the DTE to which the call is deflected. If bits 8 and 7 are not set to 1 by the called DTE, they are forced to this value by the DCE.
	The second octet indicates the number of semi–octets in the alternative DTE address. This address length indicator is binary coded and bit 1 is the low order bit. Its value is limited to 15 when the A bit is set to 0 (see § 5.2.1), to 17 when the A bit is set to 1.
	The following octets contains the alternative DTE address, using coding which corresponds to the coding of the called DTE address field in the address block (see § 5.2.1). When the number of semi–octets of the alternative DTE address is odd, a semi–octet with zeros in bits 4, 3, 2 and 1 will be inserted after the last semi–octet in order to maintain octet alignment.
7.2.2.11	Call restriction or call deflection notification facility
	The octet following the facility code field indicates the length, in octets, of the facility parameter field and has the value n + 2, where n is the number of octets necessary to hold the originally called DTE address.
	The first octet of the facility parameter field indicates the reason for the call redirection of call deflection. The coding of this octet is given in Table 31/X.25.
TABLE 31/X.25
Coding of the reason in the call redirection or call deflection notification facility parameter field
	Bits								
	 8	 7	 6	 5	 4	 3	 2	 1	
Originally called DTE busy	 0	 0	 0	 0	 0	 0	 0	 1	
Call distribution within a hunt group a)	 0	 0	 0	 0	 0	 1	 1	 1	
Originally called DTE out of order	 0	 0	 0	 0	 1	 0	 0	 1	
Systematic call redirection	 0	 0	 0	 0	 1	 1	 1	 1	
Call deflection by the originally called DTE b)	 1	 1	 X	 X	 X	 X	 X	 X	
a)	This value may be used by some networks for network–dependent reasons not described in this Recommendation.
b)	The Xs are those set by the originally called DTE in the call deflection selection facility (see § 7.2.2.10).
	The second octet indicates the number of semi–octets in the originally called DTE address. This address length indicator is binary coded and bit 1 is the low order bit. Its value is limited to 15 when the A bit is set to 0 (see § 5.2.1), to 17 when the A bit is set to 1.
	The following octets contain the originally called DTE address. When both the calling DTE and the alternative DTE have subscribed to the TOA/NPI address subscription facility (see § 6.2.8), or when none of them have subscribed to this facility, the originally called DTE address is coded identically to the called DTE address field in the call request packet. When these conditions are not satisfied, the network converts from one address format to the other (see § 5.2.1). When the number of semi–octets of the originally added DTE address is odd, a semi–octet with zeros in bits 4, 3, 2 and 1 will be inserted after the last semi–octet in order to maintain octet alignment.
7.2.2.12	Called line address modified notification facility
	The coding of the facility parameter field for called line address modified notification is given in Table 32/X.25.
TABLE 32/X.25
Coding of the parameter field for called line address modified notification facility
	Bits								
	 8	 7	 6	 5	 4	 3	 2	 1	
Call redirection due to originally called DTE busy	 0	 0	 0	 0	 0	 0	 0	 1	
Call distribution within a hunt group	 0	 0	 0	 0	 0	 1	 1	 1	
Call redirection due to originally called DTE out of order	 0	 0	 0	 0	 1	 0	 0	 1	
 Call redirection due to prior request from originally called DTE for systematic call redirection	 0	 0	 0	 0	 1	 1	 1	 1	
 Called DTE originated a)	 1	 0	 X	 X	 X	 X	 X	 X	
 Call deflection by the originally called DTE b)	 1	 1	 X	 X	 X	 X	 X	 X	
a)	Each X may be independently set to 0 or 1 by the called DTE and is passed transparently to the calling DTE. Bit 8, when received from the called DTE, and when it is not set to 1, is forced to 1 by the DCE.
b)	The Xs are those set by the originally called DTE in the call deflection selection facility (see § 7.2.2.10).
7.2.2.13	Transit delay selection and indication facility
	This parameter is two octets. Transit delay is expressed in milliseconds, binary coded, with bit 8 of octet 1 being the high order bit and bit 1 of octet 2 being the low order bit. The expressed transit delay may have a value from 0 to 65 534 (all bits set to 1 but the low order bit).
	Note – During the interim period when this optional user facility is not yet supported by all networks, the transit delay indicated in the call connected packet transmitted to the calling DTE should have a value of 65 535 (all ones) when either a transit network involved in the virtual call or the destination network does not support this facility. So, this value should be interpreted by the calling DTE as an indication that the actual transit delay cannot be transmitted to it.
7.3	Coding of the registration field of registration packets
	The coding of the registration code field and the format of the registration parameter field are the same in registration request packets and registration confirmation packets in which they are used.
7.3.1	Coding of the registration code fields
	Table 33/X.25 gives the coding of the registration code field and the registration code field and the packet types in which they may be present.
TABLE 33/X.25
Coding of the registration code field
	May be used in:		Registration code								
Facility	registration 	registration 	Bits								
	request	confirmation	 8	 7	 6	 5	 4	 3	 2	 1	
 Facilities that may be negotiated only when all logical channels used for virtual calls are in state p1	 X	 X	 0	 0	 0	 0	 0	 1	 0	 1	
 Facilities that may be negotiated at any time	 X	 X	 0	 1	 0	 0	 0	 1	 0	 1	
 Availability of facilities	X	 0	 1	 0	 0	 0	 1	 1	 0		
 Non–negotiable facility values	X	 0	 0	 0	 0	 0	 1	 1	 0		
 Default throughput classes assignment	 X	 X	 0	 0	 0	 0	 0	 0	 1	 0	
 Non–standard default packet sizes	 X	 X	 0	 1	 0	 0	 0	 0	 1	 0	
 Non–standard default window sizes	 X	 X	 0	 1	 0	 0	 0	 0	 1	 1	
 Logical channel type ranges	 X	 X	 1	 1	 0	 0	 1	 0	 0	 0	
Note – Whether or not the call redirection facility may be negotiated requires further study.
	The absence of a registration code in a registration request packet means that the DTE does not want to modify the previous agreement for the concerned facility(ies).
	The absence of a registration code in a registration confirmation packet means that the concerned facility(ies) is not supported by the DCE or is not permitted by the DCE to be negociated by the on–line facility registration facility.
	DTEs and DCEs should discard registration elements with registration codes that they do not support or do not know.
7.3.2	Coding of the registration parameter fields
7.3.2.1	Facilities that may be negotiated only when all logical channels used for virtual calls are in state p1
	Each one of the following bits of the registration parameter field corresponds to one facility that may be negotiated only when all logical channels for virtual calls are in state p1 (see annex F), and that needs only a single bit value to indicate its value. The correspondence between bits and facilities is given in Table 34/X.25.
TABLE 34/X.25
Correspondence between bits and facilities for the registration parameter field corresponding to facilities that may be negotiated only when all logical channels used for virtual calls are in state p1
Bit number	 Facility corresponding to the bit	
8		
7		
 6	 Reserved for future use (see Note 1)	
 5		
 4		
 3	 D bit modification facility	
 2	 Packet retransmission facility	
 1	 Extended packet sequence numbering facility (see Note 2)	
Note 1 – Bits 8, 7, 6, 5 and 4 should be ignored when received and set to 0 when transmitted by DTE or DCE.
Note 2 – Further study is needed to determine the exact method to negotiate this facility.
	A bit set to 1/0 in a registration request packet means that the DTE asks for the DCE to invoke/revoke the corresponding facility.
	A bit set to 1/0 in a registration confirmation packet means that the corresponding facility is invoked/revoked by the DCE.
7.3.2.2	Facilities that may be negotiated at any time
	Each one of the following bits of the registration parameter field corresponds to one facility that may be negotiated at any time (see Annex F). The correspondence between bits and facilities is given in Table 35/X.25.
	A bit set to 1/0 in a registration request packet means that the DTE asks for the DCE to invoke/revoke the corresponding facility.
	A bit set to 1/0 in a registration confirmation packet means that the corresponding facility is invoked/revoked by the DCE.
7.3.2.3	Availability of facilities
	Each one of the following bits of the registration parameter field corresponds to one facility whose availability must be indicated to the DTE. The correspondence between bits and facilities is given in Table 36/X.25.
	A bit set to 1/0 by the DCE in a registration confirmation packet means that the corresponding facility is available/not available for use by the DTE, or negotiable/not negotiable by the DTE.
7.3.2.4	Non–negotiable facilities values
	Each one of the following bits of the registration parameter field corresponds to one facility which is not available for negotiation but whose value should be indicated to the DTE.
	Bit 1: Local charging prevention facility
	Note – Bits 8, 7, 6, 5, 4, 3 and 2 should be ignored when received by the DTE and set to 0 when transmitted by the DCE.
TABLE 35/X.25
Correspondence between bits and facilities for the registration parameter field corresponding to facilities that may be negotiated at any time
Octet number	 Bit number	 Facility corresponding to the bit	
	8	 Reserved for future use (see Note)	
	7	 Charging information facility (per interface basis)	
	6	 Throughput classe negotiation facility	
	5	 Flow control parameter negotiation facility	
1	4	 Reverse charging acceptance facility	
	3	 Fast select acceptance facility	
	2	 Outgoing calls barred facility	
	1	 Incoming calls barred facility	
 2	 1 to 8	 Reserved for future use (see Note)	
 Note – Bit 8 of octet 1 and bits 8, 7, 6, 5, 4, 3, 2 and 1 of octet 2 should be ignored when received and set to 0 when transmitted by the DTE or DCE.
TABLE 36/X.25
Correspondence between bits and facilities for the registration parameter field indicating availability of facilites
Octet number	 Bit number	 Facility corresponding to the bit	
 	8	 Reverse charging facility (see Note 1)	
	7	 Reverse charging acceptance facility	
	6	 Charging information facility (per call basis) (see Note 1)	
	5	 Charging information facility (per interface basis)	
1	4	 Called line address modified notification facility (see Note 1)	
	3	 D bit modification facility	
	2	 Packet retransmission facility	
	1	 Extended packet sequence numbering facility	
 2	8		
	7	   Reserved for future use (see Note 2)	
	6		
	5	 RPOA selection facility (see Note 1)	
	4	 Logical channel type ranges registration facility	
	3	 Non–standard default packet size registration facility	
	2	 Non–standard default window size registration facility	
	1	 Default throughput classes assignment registration facility	
 Note 1 – A bit set to 1/0 for the corresponding facility indicates that it is available for use by the DTE; no further negotiation is required for these facilities.
Note 2 – Bits 8, 7 and 6 of octet 2 should be ignored when received by the DTE and set to 0 when transmitted by the DCE.
	A bit is set to 1/0 in a registration confirmation packet when the DCE has invoked/revoked the corresponding facility.
7.3.2.5	Default throughput classes
	The throughput class for the direction of data transmission from the DTE is indicated in bits 8, 7, 6 and 5. The throughput class for the direction of data transmission from the DCE is indicated in bits 4, 3, 2 and 1.
	The four bits indicating each throughput class are binary coded and correspond to throughput classes as indicated in Table 30/X.25 (see § 7.2.2.2).
	Note – Registration applies only to facility values for virtual calls; it does not apply to facility values for permanent virtual circuits.
7.3.2.6	Non–standard default packet sizes
	The packet size for the direction of data transmission from the DCE is indicated in bits 4, 3, 2 and 1 of the first octet. The packet size for the direction of data transmission from the DTE is indicated in bits 4, 3, 2 and 1 of the second octet. Bits 8, 7, 6 and 5 of each octet must be zero.
	The four bits indicating each packet size are binary coded and express the logarithm base 2 of the number of octets of the maximum packet size.
	Networks may offer values from 4 to 12, corresponding to packet sizes of 16, 32, 64, 128, 256, 512, 1024, 2048 or 4096, or a subset of these values. All Administrations will provide a packet size of 128.
	Note – Registration applies only to facility values for virtual calls; it does not apply to facility values for permanent virtual circuits.
7.3.2.7	Non–standard default window sizes
	The window size for the direction of data transmission from the DCE is indicated in bits 7 to 1 of the first octet. The window size for the direction of data transmission from the DTE is indicated in bits 7 to 1 of the second octet. Bit 8 of each octet must be zero.
	The bits indicating each window size are binary coded and express the size of the window. A value of zero is not allowed.
	Window sizes of 8 to 127 are only valid when extended sequence numbering is used. The ranges of values allowed by a network are network dependent. All Administrations will provide a window size of 2.
	Note – Registration applies only to facility values for virtual calls; it does not apply to facility values for permanent virtual circuits.
7.3.2.8	Logical channel types ranges
	The octet following the registration code field indicates the length, in octets, of the registration parameter field and shall indicate 14 octets.
	Bits 4, 3, 2 and 1 of octets 1, 3, 5, 7, 9 and 11 of registration parameter field shall contain the logical channel group number for parameters LIC, HIC, LTC, HTC, LOC and HOC, respectively (see Annex A). Bits 8, 7, 6 and 5 of these octets must be set to zero.
	Octets 2, 4, 6, 8, 10 and 12 of the registration parameter field shall contain the logical channel numbers for parameters LIC, HIC, LTC, HTC, LOC and HOC, respectively (see Annex A).
	No one–way incoming logical channels is represented by LIC and HIC both equal to zero; no two–way logical channels is represented by LTC and HTC both equal to zero; and no one–way outgoing logical channels is represented by LOC and HOC both equal to zero.
	Bits 4, 3, 2 and 1 of octet 13 of the registration parameter field shall contain the high order bits of the total number of logical channels to be used for virtual calls. Bits 8, 7, 6 and 5 of octet 13 must be set to zero. Octet 14 of the registration parameter field shall contain the low order bits of the total number of logical channels to be used for virtuals calls.
	Note 1 – The inequalites of Annex A must apply to non–zero values of LIC, HIC, LTC, HTC, LOC and HOC.
	Note 2 – The total number of logical channels to be used for virtual calls as indicated in octets 13 and 14 is equal to the sum of the number of one–way incoming logical channels, two–way logical channels and one–way outgoing logical channels.