home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / troff / 8_6_03.tro < prev    next >
Encoding:
Text File  |  1991-12-22  |  177.4 KB  |  6,089 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright (~c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v'|.5i'
  22. .LP
  23. \fBMONTAGE : FIN DE LA RECOMMANDATION X.300 EN\(hyT\*\|ETE DE CETTE PAGE\fR 
  24. .sp 2P
  25. .LP
  26. \v'23P'
  27. \fBRecommendation\ X.301\fR 
  28. .RT
  29. .sp 2P
  30. .RT
  31. .sp 2P
  32. .ce 1000
  33. \fBDESCRIPTION\ OF\ THE\ \fR \fBGENERAL\ ARRANGEMENTS\ FOR\fR \|
  34. \fBCALL\ CONTROL\ WITHIN\ A\fR 
  35. .EF '%    Fascicle\ VIII.6\ \(em\ Rec.\ X.301''
  36. .OF '''Fascicle\ VIII.6\ \(em\ Rec.\ X.301    %'
  37. .ce 0
  38. .ce 1000
  39. \fBSUBNETWORK\ AND\ BETWEEN\ SUBNETWORKS\ FOR\ THE\ PROVISION\ OF\ DATA\fR 
  40. .ce 0
  41. .sp 1P
  42. .ce 1000
  43. \fBTRANSMISSION\ SERVICES\fR 
  44. .ce 0
  45. .sp 1P
  46. .ce 1000
  47. \fI(Formerly Part of Recommendation X.300, Malaga\(hyTorremolinos, 1984;\fR 
  48. .sp 9p
  49. .RT
  50. .ce 0
  51. .sp 1P
  52. .ce 1000
  53. \fIamended at Melbourne, 1988)\fR 
  54. .ce 0
  55. .sp 1P
  56. .LP
  57.     The\ CCITT,
  58. .sp 1P
  59. .RT
  60. .sp 1P
  61. .LP
  62. \fIconsidering\fR 
  63. .sp 9p
  64. .RT
  65. .PP
  66. (a)
  67. that Recommendation X.1 defines the international user classes of service 
  68. in public data networks and ISDN; 
  69. .PP
  70. (b)
  71. that Recommendation X.2 defines the international user services and facilities 
  72. in PDNs and ISDN; 
  73. .PP
  74. (c)
  75. that Recommendation X.10 defines the different
  76. categories fo access of data terminal equipment (DTE) to the different data
  77. transmission services provided by public data networks (PDNs) and ISDN;
  78. .PP
  79. (d)
  80. that Recommendation X.96 defines call progress signals including those 
  81. used in conjunction with international user facilities; 
  82. .PP
  83. (e)
  84. that Recommendations X.20, X.20\|\fIbis\fR , X.21, X.21\|\fIbis\fR , X.25, 
  85. X.28, X.29, X.32, X.351 and X.352 already specify the detailed procedures 
  86. applicable to different types of DTE/DCE interfaces on PDNs and that 
  87. Recommendations\ X.30, X.31, I.420 and\ I.421 specify detailed procedures
  88. applicable for access to ISDN;
  89. .PP
  90. (
  91. f
  92. ) 
  93. that Recommendations X.61, X.70, X.71 and
  94. X.75 already specify the detailed procedures applicable to call control
  95. between two PDNs on the same type and that Recommendation\ X.75 can also be
  96. applied for interworking between different PDNs and for interworking
  97. involving\ ISDN;
  98. .bp
  99. .PP
  100. (g)
  101. that PDNs and ISDNs may be used to support CCITT
  102. recommended services (in particular, Telematic services);
  103. .PP
  104. (h)
  105. that Recommendation X.200 specifies the reference model of open systems 
  106. interconnection for CCITT Applications; 
  107. .PP
  108. (i)
  109. that Recommendation X.213 defines the connection\(hymode
  110. network service (NS) of open systems interconnection for CCITT Applications;
  111. .PP
  112. (j
  113. )
  114. that Recommendations X.130, X.131, X.134,
  115. X.135, X.136, X.137 and\ X.140 define the quality of service parameters and
  116. values required for public data transmission services;
  117. .PP
  118. (k)
  119. that Recommendation X.300 defines the general principles for interworking 
  120. between public networks and between public networks and other networks 
  121. for the provision of data transmission services; 
  122. .PP
  123. (l)
  124. that Recommendation X.302 describes the general
  125. arrangements for internal network utilities within subnetwork and intermediate 
  126. utilities between subnetworks for the provision of data transmission services; 
  127. .PP
  128. (m)
  129. that interworking with common channel signalling
  130. network (CCSN) needs to be considered, in view of the requirements for
  131. transferring operational information between Administrations;
  132. .PP
  133. (n)
  134. the need that DTEs can communicate through different
  135. networks, and through different interworking conditions between networks;
  136. .PP
  137. (o)
  138. the need for arrangements for interworking between
  139. public networks and between public networks and other public networks for 
  140. the provision of data transmission services; 
  141. .PP
  142. (p)
  143. the need, in particular:
  144. .LP
  145.     \(em
  146.     for certain user facitilities and network utilities for
  147. communication through the national networks between the
  148. internationally designed data terminal equipment interface protocols
  149. and international inter\(hyexchange control and signalling procedures;
  150. .LP
  151.     \(em
  152.     for certain internationally defined network utilities for
  153. international operation of public networks;
  154. .LP
  155.     \(em
  156.     for compatibility and uniformity in the principle for
  157. realization of international user facilities and network utilities in
  158. public networks;
  159. .sp 1P
  160. .LP
  161. \fIunanimously recommend\fR 
  162. .sp 9p
  163. .RT
  164. .PP
  165. that arrangements for call control interworking between public
  166. networks and between public networks and other networks, and that the necessary 
  167. elements: 
  168. .LP
  169.     \(em
  170.     for realization of interworking between different networks
  171. providing data transmission service, and
  172. .LP
  173.     \(em
  174.      for realization of international user facilities and network utilities 
  175. for data transmission services, 
  176. .LP
  177. be in accordance with the principles and procedures specified in this
  178. Recommendation.
  179. .sp 1P
  180. .ce 1000
  181. CONTENTS
  182. .ce 0
  183. .sp 1P
  184. .sp 2P
  185. .LP
  186. 0
  187.     \fIIntroduction\fR 
  188. .sp 1P
  189. .RT
  190. .sp 1P
  191. .LP
  192. 1
  193.     \fIScope and field of application\fR 
  194. .sp 9p
  195. .RT
  196. .sp 1P
  197. .LP
  198. 2
  199.     \fIReferences\fR 
  200. .sp 9p
  201. .RT
  202. .sp 1P
  203. .LP
  204. 3
  205.     \fIDefinitions\fR 
  206. .sp 9p
  207. .RT
  208. .sp 1P
  209. .LP
  210. 4
  211.     \fIAbbreviations\fR 
  212. .sp 9p
  213. .RT
  214. .sp 1P
  215. .LP
  216. 5
  217.     \fIGeneral aspects of call control\fR 
  218. .sp 9p
  219. .RT
  220. .sp 1P
  221. .LP
  222. \fB 
  223.     5.1
  224.     Model applicable to internetwork arrangements
  225. .sp 9p
  226. .RT
  227. .LP
  228.     5.2
  229.     Classification of internetwork signals
  230. .LP
  231.     5.3
  232.     General principles concerning internetwork signals
  233. .bp
  234. .sp 1P
  235. .LP
  236. 6
  237.     \fITransfer of addressing information\fR 
  238. .sp 9p
  239. .RT
  240. .LP
  241.     6.1
  242.     General
  243. .LP
  244.     6.2
  245.     Transfer of X.121 calling address
  246. .LP
  247.     6.3
  248.     Transfer of E.164 calling address
  249. .LP
  250.     6.4
  251.     Transfer of X.121 called address
  252. .LP
  253.     6.5
  254.     Transfer of E.164 called address
  255. .LP
  256.     6.6
  257.     Format of X.121 addresses
  258. .LP
  259.     6.7
  260.     Coding of E.164 addresses
  261. .LP
  262.     6.8
  263.     Transfer of address information additional to
  264. Recommendation\ X.121 and\ E.164
  265. .sp 2P
  266. .LP
  267. 7.
  268.     \fIArrangements for user facilities\fR 
  269. .sp 1P
  270. .RT
  271. .sp 1P
  272. .LP
  273.     7.1
  274.     Facilities related to the quality of service (QOS) for
  275. the call
  276. .sp 9p
  277. .RT
  278. .LP
  279.     7.2
  280.     Facilities related to the charging conditions applying to   the call
  281. .LP
  282.     7.3
  283.     Facilities related to the specific routing conditions
  284. requested by the user of the call
  285. .LP
  286.     7.4
  287.     Facilities related to protection mechanisms requested by
  288. the user of the call
  289. .LP
  290.     7.5
  291.     Facilities to convey user data in addition to the normal
  292. data flow in the data transfer phase
  293. .LP
  294.     7.6
  295.     Other facilities
  296. .sp 2P
  297. .LP
  298. 8.
  299.     \fIArrangements for Call Progress Signals\fR 
  300. .sp 1P
  301. .RT
  302. .sp 1P
  303. .LP
  304.     8.1
  305.     Call progress signals during call establishment
  306. .sp 9p
  307. .RT
  308. .LP
  309.     8.2
  310.     Clearing call progress signals during data transfer
  311. .LP
  312.     8.3
  313.     Reset call progress signals during data transfer
  314. .LP
  315.     8.4
  316.      Internetwork arrangements involving call progress signals defined in 
  317. Recommendations\ X.96 and\ Q.931. 
  318. .LP
  319.     8.5
  320.      Internetwork arrangements involving call progress signals defined in 
  321. Recommendations\ X.96 and\ Q.699 
  322. .LP
  323.     8.6
  324.      Internetwork arrangements involving call progress signals defined in 
  325. Recommendations\ Q.931 and\ Q.699. 
  326. .sp 1P
  327. .LP
  328. \fIAppendix\ I\fR     \(em
  329.     Protocol elements of different networks used for the
  330. facilities and arrangements described in this Recommendation.
  331. .sp 9p
  332. .RT
  333. .sp 1P
  334. .LP
  335. \fIAppendix\ II\fR     \(em
  336.     Arrangements to support the OSI Network Service.
  337. .sp 9p
  338. .RT
  339. .sp 2P
  340. .LP
  341. \fB0\fR     \fBIntroduction\fR 
  342. .sp 1P
  343. .RT
  344. .PP
  345. This Recommendtion is one of a set of Recommendations produced to facilitate 
  346. consideration of interworking between networks. It is related to 
  347. Recommendation\ X.300, which defines the general principles for interworking
  348. between public networks, and between public networks and other networks 
  349. for the provision of data transmission services. Recommendation\ X.300 
  350. indicates, in 
  351. particular, how collections of physical equipment can be considered as
  352. \*Qsubnetworks\*U for consideration of interworking situations.
  353. .PP
  354. This Recommendation describes general arrangements for call control
  355. within and between subnetworks for the provision of data transmission services. 
  356. Only those arrangements are described that may (also) have significance 
  357. for end users of a call. Facilities that are not visible to end users of 
  358. a call are the subject of other Recommendations (e.g.\ those arrangements 
  359. described in 
  360. Recommendation\ X.302).
  361. .RT
  362. .sp 2P
  363. .LP
  364. \fB1\fR     \fBScope and field of application\fR 
  365. .sp 1P
  366. .RT
  367. .PP
  368. The purpose of this Recommendation is to describe detailed
  369. internetwork arrangements for call control applicable to interworking at the
  370. OSI network layer, including some of the arrangements necessary to provide
  371. support for the capability of the OSI connection\(hymode\ NS.
  372. .PP
  373. These arrangements are not applicable to interworking involving
  374. communication capability as described in section\ 7.2 of
  375. Recommendation\ X.300.
  376. .bp
  377. .PP
  378. It is for further study whether or not any of these arrangements are also 
  379. applicable to other types of interworking, for example interworking by 
  380. port access as described in Recommendation\ X.300.
  381. .PP
  382. Arrangements that are solely used for internal or internetwork
  383. operation, and which are not visible for end\(hyusers, are not described 
  384. in this Recommendation. For such arrangements see Recommendation\ X.302. 
  385. .RT
  386. .sp 2P
  387. .LP
  388. \fB2\fR     \fBReferences\fR 
  389. .sp 1P
  390. .RT
  391. .LP
  392. E.164/I.331
  393.     The numbering plan for the ISDN era,
  394. .LP
  395. I.230\(hySeries
  396.     Bearer services supported by an ISDN,
  397. .LP
  398. I.250\(hySeries
  399.     Supplementary services supported by an ISDN,
  400. .LP
  401. I.420
  402.     Basic user\(hynetwork interface,
  403. .LP
  404. I.421
  405.     Primary rate user\(hynetwork interface,
  406. .LP
  407. Q.699
  408.     Interworking between ISDN user\(hynetwork of interface protocol and
  409. signalling system No.\ 7 ISDN user part.
  410. .LP
  411. Q.931/I.451
  412.     ISDN user\(hynetwork interface layer\ 3 specification,
  413. .LP
  414. X.1
  415.     International user classes of service in public data networks
  416. (PDNs) and ISDNs,
  417. .LP
  418. X.2
  419.     International data transmission services and optional user facilities
  420. in PDNs and ISDNs,
  421. .LP
  422. X.10
  423.      Categories of access for data terminal equipment (DTE) to public data 
  424. transmission services, 
  425. .LP
  426. X.20
  427.     Interface between data terminal equipment (DTE) and Data
  428. Circuit\(hyterminating Equipment (DCE) for star\(hystop transmission services 
  429. on 
  430. PDNs,
  431. .LP
  432. X.20\|\fIbis\fR     Use on PDNs of DTE which is designed for interfacing to
  433. asynchronous duplex V\(hySeries modems,
  434. .LP
  435. X.21
  436.     Interface between data terminal equipment (DTE) and Data
  437. Circuit\(hyTerminating Equipment (DCE) for synchronous operation on PDNs,
  438. .LP
  439. X.21\|\fIbis\fR     Use on PDNs of DTE which is designed for interfacing to
  440. synchronous V\(hySeries modems,
  441. .LP
  442. X.22
  443.     Multiplex DTE/DCE interface for user classes\ 3\(hy6,
  444. .LP
  445. X.25
  446.     Interface between data terminal equipment (DTE) and data
  447. Circuit\(hyterminating equipment (DCE) for terminals operating in the packet\(hymode 
  448. and connected to public data networks by dedicated circuit, 
  449. .LP
  450. X.28
  451.     DTE/DCE interface for a start\(hystop mode DTE accessing the packet
  452. assembly/disassembly (PAD) facility in a PDN situated in the same country,
  453. .LP
  454. X.29
  455.     Procedures for the exchange of control information and user data
  456. between PAD facility and packet\(hymode DTE or another PAD,
  457. .LP
  458. X.30/I.461
  459.     Support of X.21, X.21\|\fIbis\fR and X.20\|\fIbis\fR based data terminal
  460. equipment (DTEs) by an integrated services digital network\ (ISDN),
  461. .LP
  462. X.31/I.462
  463.     Support of packet\(hymode terminal equipment by an ISDN,
  464. .LP
  465. X.32
  466.     Interface between data terminal equipment (DTE) and data
  467. circuit\(hyterminating equipment (DCE) for terminals operating in the packet\(hymode 
  468. and accessing a packet\(hyswitched public data network through a public 
  469. switched telephone network or an integrated services digital network or 
  470. a 
  471. circuit\(hyswitched public data network.
  472. .LP
  473. X.61
  474.     Signalling System No.\ 7 \(em Data user part,
  475. .LP
  476. X.70
  477.      Terminal and transit control signalling system for start\(hystop services 
  478. on internatinal circuits between anisochronous data networks, 
  479. .bp
  480. .LP
  481. X.71
  482.     Decentralized terminal and transit control signalling system on
  483. international circuits between synchronous data networks,
  484. .LP
  485. X.75
  486.     Packet\(hyswitched signalling system between public networks providing
  487. data transmission services,
  488. .LP
  489. X.80
  490.      Interworking of inter\(hyexchange signalling systems for circuit\(hyswitched 
  491. data services, 
  492. .LP
  493. X.96
  494.     Call progress signals in PDNs,
  495. .LP
  496. X.110
  497.     Routing principles for international public data services through
  498. switched PDNs of the same type,
  499. .LP
  500. X.121
  501.     International numbering plan for public data networks,
  502. .LP
  503. X.130
  504.      Provisional objectives for call set\(hyup and clear\(hydown times in 
  505. public synchronous data networks (circuit switching), 
  506. .LP
  507. X.131
  508.     Provisional objectives for grade of service in international data
  509. communications over circuit\(hyswitched PDNs,
  510. .LP
  511. X.134
  512.     Portion boundaries and packet layer reference events: basis for
  513. defining packet\(hyswitched performance paramenters,
  514. .LP
  515. X.135
  516.      Speed of service (delay and throughput) performance values for public 
  517. data networks when providing international packet\(hyswitched service, 
  518. .LP
  519. X.136
  520.     Accuracy and dependability performance values for public data
  521. networks when providing international packet\(hyswitched service,
  522. .LP
  523. X.137
  524.     Availability performance values for public data networks when
  525. providing international packet\(hyswitched service,
  526. .LP
  527. X.140
  528.     General quality of service parameters for communication via PDNs,
  529. .LP
  530. X.180
  531.     Administrative arrangements for international closed user groups
  532. (CUGs),
  533. .LP
  534. X.200
  535.     Reference model for open systems interconnection for CCITT
  536. Applications,
  537. .LP
  538. X.213
  539.      Network Service Definition for Open Systems Interconnection for CCITT 
  540. Applications, 
  541. .LP
  542. X.300
  543.     General principles and arrangements for interworking between public
  544. networks, and between public networks and other networks for the provision 
  545. of data transmission services, 
  546. .LP
  547. X.302
  548.      Description of the general arrangements for internal network utilities 
  549. within a subnetwork and between subnetworks for the provision of data 
  550. transmission services,
  551. .LP
  552. X.351
  553.      Special requirements to be met for packet assembly/disassembly (PAD) 
  554. facilities located at or in association with coastal earth stations in 
  555. the 
  556. maritime satellite service,
  557. .LP
  558. X.352
  559.     Interworking between packet\(hyswitched public data networks and the
  560. maritime satellite data transmission system.
  561. .sp 2P
  562. .LP
  563. \fB3\fR     \fBD\*'efinitions\fR 
  564. .sp 1P
  565. .RT
  566. .PP
  567. This Recommendation makes use of the following terms defined in
  568. Recommendation\ X.300:
  569. .RT
  570. .LP
  571.     a)
  572.     Transmission capability
  573. .LP
  574.     b)
  575.     Communication capability
  576. .LP
  577.     c)
  578.     Data transmission service
  579. .PP
  580. This Recommendation makes use of the following terms defined in
  581. Recommendation\ X.135:
  582. .LP
  583.     a)
  584.     Transit delay
  585. .PP
  586. This Recommendation makes use of the following terms defined in
  587. Recommendation\ X.140:
  588. .RT
  589. .LP
  590.     a)
  591.     User information transfer rate
  592. .PP
  593. This Recommendation makes use of the following terms defined in
  594. Fascicle\ X.1:
  595. .RT
  596. .LP
  597.     a)
  598.     Optional user facility
  599. .bp
  600. .sp 2P
  601. .LP
  602. \fB4\fR     \fBAbbreviations\fR 
  603. .sp 1P
  604. .RT
  605. .LP
  606.     BCUGB
  607.     Bilateral closed user group
  608. .LP
  609.     BCUGOA
  610.     Bilateral closed user group with outgoing access
  611. .LP
  612.     CC
  613.     Country code
  614. .LP
  615.     CSPDN
  616.     Circuit\(hyswitched public data network
  617. .LP
  618.     CTD
  619.     Cumulative transit delay
  620. .LP
  621.     CUG
  622.     Closed user group
  623. .LP
  624.     DCC
  625.     Data country code
  626. .LP
  627.     DCE
  628.     Data circuit\(hyterminating equipment
  629. .LP
  630.     DNIC
  631.     Data network identification code
  632. .LP
  633.     DSE
  634.     Data switching exchange
  635. .LP
  636.     DTE
  637.     Data terminating equipment
  638. .LP
  639.     EETDN
  640.     End\(hyto\(hyend transit delay negotiation
  641. .LP
  642.     FS
  643.     Further study
  644. .LP
  645.     IA
  646.     Incoming access
  647. .LP
  648.     IC
  649.     Interlock code
  650. .LP
  651.     ICB
  652.     Incoming calls barred
  653. .LP
  654.     ICCM
  655.     Interworking by call control mapping
  656. .LP
  657.     IDSE
  658.     International data switching exchange
  659. .LP
  660.     IPA
  661.     Interworking by port access
  662. .LP
  663.     ISDN
  664.     Integrated services digital network
  665. .LP
  666.     IWF
  667.     Interworking function
  668. .LP
  669.     MATD
  670.     Maximum acceptable transit delay
  671. .LP
  672.     MSS
  673.     Maritime satellite service
  674. .LP
  675.     NA
  676.     Not applicable
  677. .LP
  678.     NAE
  679.     Network address extension
  680. .LP
  681.     NAPI/TOA
  682.     Numbering and addressing plan indicator/Type of
  683. address (equivalent to NPI/TOA used in X.25)
  684. .LP
  685.     NC
  686.     Network connection
  687. .LP
  688.     NDC
  689.     National destination code
  690. .LP
  691.     NPI/TOA
  692.     Numbering plan indicator/TOA (equivalent to
  693. NAPI/TOA used in Rec.\ Q.931)
  694. .LP
  695.     NS
  696.     Network service (pertaining to OSI)
  697. .LP
  698.     NTN
  699.     Network terminal number
  700. .LP
  701.     NUI
  702.     Network user identification
  703. .LP
  704.     OA
  705.     Outgoing access
  706. .LP
  707.     OCB
  708.     Outgoing calls barred
  709. .LP
  710.     OSI
  711.     Open systems interconnection
  712. .LP
  713.     PSDN
  714.     Packet\(hyswitched data network
  715. .LP
  716.     PSPDN
  717.     Packet\(hyswitched public data network
  718. .LP
  719.     PSTN
  720.     Public\(hyswitched telephone network
  721. .LP
  722.     QOS
  723.     Quality of service
  724. .LP
  725.     QRP
  726.     QOS reference point
  727. .LP
  728.     RPOA
  729.     Recognized private operating agency
  730. .bp
  731. .LP
  732.     SN
  733.     Subscriber number
  734. .LP
  735.     TDI
  736.     Transit delay indication
  737. .LP
  738.     TDS
  739.     Transit delay selection
  740. .LP
  741.     TDSAI
  742.     Transit delay selection and indication
  743. .LP
  744.     TOA
  745.     Type of address
  746. .LP
  747.     TTD
  748.     Target transit delay
  749. .sp 2P
  750. .LP
  751. \fB5\fR     \fBGeneral aspects of call control\fR 
  752. .sp 1P
  753. .RT
  754. .PP
  755. The internetwork arrangements described in this section relate
  756. to the general aspects of call control.
  757. .RT
  758. .sp 1P
  759. .LP
  760. 5.1
  761.     \fIModel applicable to internetwork arrangements\fR 
  762. .sp 9p
  763. .RT
  764. .PP
  765. The internetwork arrangements for call control are established
  766. according to the model illustrated in Figures\ 5\(hy1 and\ 5\(hy2/X.301.
  767. .RT
  768. .LP
  769. .rs
  770. .sp 16P
  771. .ad r
  772. \fBFigure 5\(hy1/X.301, p.\fR 
  773. .sp 1P
  774. .RT
  775. .ad b
  776. .RT
  777. .LP
  778. .rs
  779. .sp 16P
  780. .ad r
  781. \fBFigure 5\(hy2/X.301, p.\fR 
  782. .sp 1P
  783. .RT
  784. .ad b
  785. .RT
  786. .LP
  787. .bp
  788. .sp 1P
  789. .LP
  790. 5.2
  791.     \fIClassification of internetwork signals\fR 
  792. .sp 9p
  793. .RT
  794. .PP
  795. Recommendations dealing with internetwork signalling systems
  796. describe various signals that can be classified as follows:
  797. .RT
  798. .sp 1P
  799. .LP
  800. 5.2.1
  801.     \fIInternetwork data link control signals\fR 
  802. .sp 9p
  803. .RT
  804. .PP
  805. Data link control signals (e.g., availability of physical
  806. circuit(s)) are related to the particularly considered data link and therefore 
  807. are normally confined within the two ends of the link itself. Thus, these 
  808. signals do not normally pass across the interworking function.
  809. .PP
  810. An exception to this may be when, for example, a large number of data links 
  811. in a network are unavailable or faulty, so as to prejudge routing of the 
  812. calls from an interconnected network. In this case, appropriate operational 
  813. signals may be generated towards the interconnected network to the extent
  814. allowed by the signalling arrangements provided in the interconnected network.
  815. .PP
  816. \fINote\ 1\fR \ \(em\ A given data link may convey signalling data and/or user
  817. data.
  818. .PP
  819. \fINote\ 2\fR \ \(em\ Between two packet switching networks, Recommendation\ 
  820. X.75 indicates that a given data link may employ several physical circuits. 
  821. .RT
  822. .sp 1P
  823. .LP
  824. 5.2.2
  825.     \fIInternetwork call control signals\fR 
  826. .sp 9p
  827. .RT
  828. .PP
  829. This type of signal includes all signals that convey between two
  830. networks the appropriate data and control information for a given call.
  831. These signals are essentially related to:
  832. .RT
  833. .LP
  834.     \(em
  835.     call estabishment,
  836. .LP
  837.     \(em
  838.     data transfer,
  839. .LP
  840.     \(em
  841.     call release.
  842. .PP
  843. \fINote\ 1\fR \ \(em\ Some signals are essential for call establishment, 
  844. for example: DTE addresses, indications for user facilities whenever required, 
  845. and call progress signals. These signals are subject to general descriptions 
  846. in the relevant Recommendations (for example, DTE addresses in Recommendation\ 
  847. X.121, call progress signals in Recommendation\ X.96). Also, the way to 
  848. convey these 
  849. signals between two networks is described in the Recommendations dealing 
  850. with the internetwork signalling systems. 
  851. .PP
  852. \fINote\ 2\fR \ \(em\ Some internetwork signalling systems specify that 
  853. all call control signals employ a unique data link; this is the case in 
  854. the signalling system defined in Recommendation\ X.75. Some other inter\(hynetwork 
  855. signalling 
  856. systems specify that the call control signals employ more than one data 
  857. link; this is the case in the common channel signalling system, where both 
  858. a 
  859. signalling channel and a data channel are used for the same call.
  860. .RT
  861. .sp 1P
  862. .LP
  863. 5.2.3
  864.     \fIInternetwork operation signals\fR 
  865. .sp 9p
  866. .RT
  867. .PP
  868. This type of signal would consist of all signals that are not
  869. directly related to the control of a specific data link or a specifc call
  870. between two networks; these operation signals would provide the necessary
  871. general information for a satisfactory operation of the internetwork
  872. connections such as:
  873. .RT
  874. .LP
  875.     \(em
  876.     system availability,
  877. .LP
  878.     \(em
  879.     circuit efficiency,
  880. .LP
  881.     \(em
  882.     congestion or failure conditions, etc.
  883. .PP
  884. \fINote\ 1\fR \ \(em\ The transmission of some internetwork operation
  885. signals may cause a network to modify general rules applying to the network
  886. operation, such as: change in routing scheme, control of data flow when
  887. applicable, clearing of some calls,\ etc.
  888. .PP
  889. \fINote\ 2\fR \ \(em\ The transmission of such internetwork operation signals
  890. does not prevent networks from processing some of these signals used for
  891. internetwork operation. In particular, a network may wish to note the
  892. exact circumstances of a call clearing related to a remote network failure, 
  893. in order to take necessary actions as soon as possible (change in routing 
  894. scheme,\ etc.).
  895. .bp
  896. .RT
  897. .sp 1P
  898. .LP
  899. 5.3
  900.     \fIGeneral principles concerning internetwork signals\fR 
  901. .sp 9p
  902. .RT
  903. .PP
  904. This section describes some general principles that could be used as a 
  905. basic for the interworking between different types of networks. 
  906. .RT
  907. .sp 1P
  908. .LP
  909. 5.3.1
  910.     \fIBasic status of a data link\fR 
  911. .sp 9p
  912. .RT
  913. .PP
  914. On every data link established in a network, the data link control signals 
  915. should provide both ends with the capability of controlling at any time 
  916. the status of the link. In particular, each end should be able to know 
  917. whether or not the data link is fully operational; in the case the data 
  918. link is not 
  919. fully operational whether or not it is still available for additional data
  920. transmission signals related to existing call(s), signals related to new
  921. call(s); also whether or not existing call(s) should be cleared (or reset), 
  922. due to that data link problem. 
  923. .PP
  924. \fINote\ 1\fR \ \(em\ Following that principle, provision should be made 
  925. within the appropriate internetwork signalling Recommendations, so that 
  926. each network could be aware of the status of the links in an interconnected 
  927. network whenever required. 
  928. .RT
  929. .sp 1P
  930. .LP
  931. 5.3.2
  932.     \fICall request and call confirmation phases\fR 
  933. .sp 9p
  934. .RT
  935. .PP
  936. The establishment of a call between two subscribers should consist of two 
  937. consecutive phases: 
  938. .RT
  939. .LP
  940.     \(em
  941.     first a CALL REQUEST phase, when:
  942. .LP
  943.     \(em
  944.     a call is requested by a subscriber, with specific
  945. parameters,
  946. .LP
  947.     \(em
  948.     this call request is processed and routed through
  949. the network(s), unless it cannot be accepted by the network(s),
  950. .LP
  951.     \(em
  952.     the call request is indicated to the called
  953. subscriber;
  954. .LP
  955.     \(em
  956.     then a CALL CONFIRMATION phase, when:
  957. .LP
  958.     \(em
  959.      a call acceptance is reported by the called subscriber, unless this subscriber 
  960. does not acept the call, 
  961. .LP
  962.     \(em
  963.     final arrangements are made through the network(s) for  that call,
  964. .LP
  965.     \(em
  966.     the call establishment is confirmed to the calling
  967. subscriber.
  968. .PP
  969. \fINote\ 1\fR \ \(em\ During each one of those two phases, the various
  970. actions are not necessarily carried on separately. For example, network
  971. equipment may process some call request signals received from a subscriber,
  972. before further parameters for the call request are transmitted by that
  973. subscriber.
  974. .PP
  975. \fINote\ 2\fR \ \(em\ Currently, the establishment of a call through certain
  976. combinations of networks necessitates more than the two phases mentioned in
  977. this section; for example, when accessing a packet switching network from a
  978. circuit switched network, the complete establishment of the switched access 
  979. is usually required before the virtual call can be requested. Following 
  980. the 
  981. principle indicated in this section, provision should be made within the
  982. appropriate internetwork signalling Recommendations, for the establishment 
  983. of direct calls between both end users whenever it is possible. Consequently, 
  984. provision should also be made within the numbering plan so that a subscriber
  985. line could be directly and uniquely identified from any network.
  986. .PP
  987. \fINote\ 3\fR \ \(em\ The way to accept and route a call through different
  988. networks may depend not only on the called DTE address, but also on parameters 
  989. or facilities defined for that call. Following the principle indicated 
  990. in this section, in the case where some parameters or facilities may require 
  991. negociation during the call establishment:
  992. .RT
  993. .LP
  994.     \(em
  995.      the calling DTE can only indicate its specific requirements for the call 
  996. when it requests the call, 
  997. .LP
  998.     \(em
  999.      the called DTE can only modify the call characteristics when it accepts 
  1000. the call. 
  1001. .sp 1P
  1002. .LP
  1003. 5.3.3
  1004.     \fIData transfer phase\fR 
  1005. .sp 9p
  1006. .RT
  1007. .PP
  1008. Different types of networks may provide different functionalities in this 
  1009. phase, e.g. transfer capabilities of continuous bit streams, transfer of 
  1010. blocks of data, and features like flow control, sequencing, error 
  1011. notification, reset services, receipt confirmation and expedited data
  1012. transfer.
  1013. .bp
  1014. .RT
  1015. .sp 1P
  1016. .LP
  1017. 5.3.3
  1018.     \fICall clearing phase\fR 
  1019. .sp 9p
  1020. .RT
  1021. .PP
  1022. Any network or user involved in a call should have the possibility to clear 
  1023. immediately that call. 
  1024. .PP
  1025. At the time a call is cleared, any network involved in the call would immediately 
  1026. stop transmitting user data for the call, and report the call 
  1027. clearing to the adjacent networks, unless they are already informed of that
  1028. clearing. The clearing signal should then be transmitted with all necessary
  1029. details, i.e., cause and diagnostic codes.
  1030. .PP
  1031. As soon as a call clearing is locally completed any resource used for that 
  1032. call can be re\(hyused by the network for other calls. 
  1033. .PP
  1034. \fINote\ 1\fR \ \(em\ Following that principle, the receipt of a clear
  1035. confirmation does not necessarily mean that the end user was already informed 
  1036. of the clearing, and confirmed it. 
  1037. .PP
  1038. \fINote\ 2\fR \ \(em\ The call clearing principle indicated in this section 
  1039. does not prevent both users from exchanging end\(hyto\(hyend information 
  1040. about the 
  1041. clearing of the call, if they wish to do so at the end of data transfer
  1042. (example: invitation to clear data packet in Recommendation\ X.29).
  1043. .PP
  1044. \fINote\ 3\fR \ \(em\ In some cases of clearing collisions, for example 
  1045. when both a DTE and a network initiate the Call Clearing Phase simultaneously, 
  1046. parameter information provided by the DTE may be lost. 
  1047. .PP
  1048. For the purpose of this Recommendation, a DTE that initiates the Call Clearing 
  1049. Phase is labeled \*QClearing DTE\*U. A DTE that does not initiate the Call 
  1050. Clearing Phase, but is informed of this phase by the network, is labeled 
  1051. \*QCleared DTE\*U.
  1052. .RT
  1053. .sp 2P
  1054. .LP
  1055. \fB6\fR     \fBTransfer of addressing information\fR 
  1056. .sp 1P
  1057. .RT
  1058. .PP
  1059. The internetwork arrangements described in this section provide
  1060. the capability to transfer all elements of addressing information for the
  1061. provision of data transmission services. This comprises addressing information 
  1062. defined in Recommendation\ E.164, Recommendation\ X.121 and any additional 
  1063. addressing information defined at the Network Layer of OSI. Table\ 6\(hy1/X.301
  1064. lists the optional user facilities relating to addressing information described 
  1065. in this section. 
  1066. .RT
  1067. .LP
  1068. .sp 2
  1069. .ce
  1070. \fBH.T. [T1.301]\fR 
  1071. .ce
  1072. TABLE\ 6\(hy1/X.301
  1073. .ce
  1074. \fBOptional user facilities relating to the transfer of addressing\fR 
  1075. .ce
  1076. \fBinformations\fR 
  1077. .ps 9
  1078. .vs 11
  1079. .nr VS 11
  1080. .nr PS 9
  1081. .TS
  1082. center box;
  1083. cw(54p) | cw(18p) | cw(30p) | cw(24p) sw(18p) sw(24p) | cw(18p) sw(24p) sw(18p) , ^  | ^  | ^  | c | c | c | c | c | c.
  1084. Optional user facility    Period  of time    Applies  per call    T{
  1085. Applies to circuit switched data
  1086. transmission
  1087. service
  1088. T}    T{
  1089. Applies to packet switched data
  1090. transmission
  1091. service
  1092. T}
  1093.             PTSN    CSPDN    ISDN    ISDN    PSPDN    MSS
  1094. _
  1095. .T&
  1096. lw(54p) | cw(18p) | lw(30p) | lw(24p) | cw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) .
  1097. Calling line identification    X            X                
  1098. .T&
  1099. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | lw(18p) | lw(24p) | lw(18p) .
  1100. Calling line identification    X    X  (Note)        X    FS            
  1101. .T&
  1102. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  1103. T{
  1104. Network address extension (NAE)/
  1105. sub\(hyaddress
  1106. T}        X                X    X    T{
  1107. X
  1108. \fINote\fR
  1109. \ \(em\ This facility cannot be used unless the corresponding facility has
  1110. been agreed for a period of time.
  1111. .parag
  1112. T}
  1113. _
  1114. .TE
  1115. .nr PS 9
  1116. .RT
  1117. .ad r
  1118. \fBTable 6\(hy1/X.301 [T1.301], p.\fR 
  1119. .sp 1P
  1120. .RT
  1121. .ad b
  1122. .RT
  1123. .LP
  1124. .bp
  1125. .sp 1P
  1126. .LP
  1127. 6.1
  1128.     \fIGeneral\fR 
  1129. .sp 9p
  1130. .RT
  1131. .PP
  1132. For the provision of data transmission services, different
  1133. numbering plans are considered. These are the Recommendation\ X.121 numbering
  1134. plan and the Recommendation\ E.164 numbering plan. Currently
  1135. Recommendation\ X.121 is used by PDNs and Recommendation\ E.164 is used by the
  1136. telephony network ISDN Recommendation\ E.164 will be used by ISDNs. Because 
  1137. of this, this section will refer to networks that make use of X.121 numbering 
  1138. as an X.121 domain (PDNs) and networks that make use of E.164 as an E.164 
  1139. domain (ISDNs). 
  1140. .PP
  1141. For interworking between X.121 domains and E.164 domains some
  1142. indication is needed in the protocol of the numbering plan of the address
  1143. present in the address protocol element(s). This indication can take the 
  1144. form of an escape associated directly with the address or a protocol element 
  1145. indication separate from the address protocol element. This latter method 
  1146. will be referred to as a Numbering Plan Indicator/Type of Address (NPI/TOA) 
  1147. in which case the domains can be considered as one combined domain. The 
  1148. actual value of the escape in PDNs and ISDNs is defined in X.121 and E.166. 
  1149. The form of the 
  1150. NPI/TOA depends on the actual network access protocol used.
  1151. .PP
  1152. It should be noted that no indication of address type or numbering
  1153. plan is needed if the call is contained solely within one numbering plan
  1154. domain. Some networks may require the indication to be present at all cases.
  1155. .PP
  1156. The model shown in Figure 6\(hy1/X.301 is used to describe internetwork 
  1157. arrangements for the treatement of address information conveyance. 
  1158. .PP
  1159. In the figure the following cases terms are used:
  1160. .RT
  1161. .LP
  1162.     a)
  1163.     international data number: DNIC + NTN or DCC +
  1164. NN, as defined in Recommendation\ X.121;
  1165. .LP
  1166.     b)
  1167.     international X.121 format: case\ a), or Escape + other
  1168. international number, as defined in Recommendation\ X.121;
  1169. .LP
  1170.     c)
  1171.     X.121 formats: Prefix (if any) + case\ b), or other
  1172. national format;
  1173. .LP
  1174.     d)
  1175.     E.164 international number: CC + N(S)N, as defined in
  1176. Recommendation\ E.164;
  1177. .LP
  1178.     e)
  1179.     international E.164 format: case d) or Escape + other
  1180. international number;
  1181. .LP
  1182.     f
  1183. )
  1184.     E.164 format: prefix (if any) + case\ e), or other
  1185. national format;
  1186. .LP
  1187.     g)
  1188.     combined domain address: the domain is determined by
  1189. NPI/TOA.
  1190. .sp 1P
  1191. .LP
  1192. 6.2
  1193.     \fITransfer of X.121 calling address\fR 
  1194. .sp 9p
  1195. .RT
  1196. .PP
  1197. This section describes arrangements for the transfer of calling
  1198. address information defined in Recommendation\ X.121 through PDNs and ISDNs.
  1199. Such information is referred to in this section as the \*QX.121 calling 
  1200. address\*U. In this section, it is assumed that the originating network 
  1201. is a PDN (X.121 
  1202. domain).
  1203. .RT
  1204. .sp 1P
  1205. .LP
  1206. 6.2.1
  1207.     \fITransfer during call request phase\fR 
  1208. .sp 9p
  1209. .RT
  1210. .PP
  1211. The X.121 calling address shall be provided by the originating PDN. In 
  1212. some cases this will occur automatically, and in others it will be provided 
  1213. only when requested by the destination PDN (see \(sc\ 6.1.4). The originating 
  1214. PDN is responsible for the accuracy of the X.121 calling address when it is
  1215. provided.
  1216. .PP
  1217. However, the following particular situations occur:
  1218. .RT
  1219. .PP
  1220. 6.2.1.1
  1221. In some cases of interworking with an E.164 domain, a method of indicating 
  1222. that the calling address is an X.121 address must be employed. This shall 
  1223. be done either by using a standardized escape digit to indicate an X.121 
  1224. address follows or by some form of NPI/TOA indicating the calling address 
  1225. is an X.121 address. 
  1226. .sp 9p
  1227. .RT
  1228. .PP
  1229. 6.2.1.2
  1230. In some cases, even where the transfer of the X.121 calling
  1231. address is technically possible, there may be administrative reasons why the
  1232. identity of the calling user, and therefore the X.121 calling address related 
  1233. to it, cannot be passed over an international boundary. In such a case, 
  1234. the 
  1235. identification of the originating network shall be provided instead of the
  1236. X.121 calling address.
  1237. .bp
  1238. .LP
  1239. .rs
  1240. .sp 47P
  1241. .ad r
  1242. \fBFigure 6\(hy1/X.301 [1T2.301], p. 4\fR 
  1243. .sp 1P
  1244. .RT
  1245. .ad b
  1246. .RT
  1247. .LP
  1248. .bp
  1249. .LP
  1250. .rs
  1251. .sp 11P
  1252. .ad r
  1253. \fBFigure 6\(hy1/X.301 [2T2.301], p. 5\fR 
  1254. .sp 1P
  1255. .RT
  1256. .ad b
  1257. .RT
  1258. .PP
  1259. 6.2.1.3
  1260. Networks other than PDNs and ISDNs, whenever they are used in
  1261. conjunction with the PDN for offering data transmission services, should, if
  1262. possible, provide for the transfer of an X.121 calling address. However, 
  1263. this transfer is not technically possible through some current networks; 
  1264. for 
  1265. example, for a call passing through a PSTN, into a PDN, the telephone network 
  1266. is not always able to indicate the X.121 calling address to the data network. 
  1267. In such a case, information transferred through the PDN instead of the 
  1268. X.121 
  1269. calling address is for further study.
  1270. .PP
  1271. 6.2.1.4
  1272. In the circuit switched service in CSPDNs, the X.121 calling
  1273. address can be transferred as the calling line identification. It is
  1274. transferred to the called DTE only if the called DTE subscribers to the
  1275. \fIcalling line identification\fR facility (see \(sc\ 6.1.4).
  1276. .PP
  1277. 6.2.1.5
  1278. In packet switched service in PSPDNs, ISDNs, and in the
  1279. circuit\(hyswitched data transmission service in ISDNs, the X.121 calling 
  1280. address is transferred to the called DTE in the address field (appropriate 
  1281. to 
  1282. the relevant protocol) signalled to the called DTE (see Appendix\ I to this
  1283. Recommendation).
  1284. .sp 1P
  1285. .LP
  1286. 6.2.2
  1287.     \fITransfer during call confirmation phase\fR 
  1288. .sp 9p
  1289. .RT
  1290. .PP
  1291. Provided the route for the call is selected during the call request phase, 
  1292. the X.121 calling address does not need to be transferred back through 
  1293. the PDNs and ISDNs during the call confirmation phase. 
  1294. .RT
  1295. .sp 1P
  1296. .LP
  1297. 6.2.3
  1298.     \fITransfer during other phases of the call\fR 
  1299. .sp 9p
  1300. .RT
  1301. .PP
  1302. The X.121 calling address may not need to be transferred through
  1303. the PDNs during any other phase of the call.
  1304. .RT
  1305. .sp 2P
  1306. .LP
  1307. 6.2.4
  1308.     \fICalling line identification\fR 
  1309. .sp 1P
  1310. .RT
  1311. .sp 1P
  1312. .LP
  1313. 6.2.4.1
  1314.     \fIGeneral\fR 
  1315. .sp 9p
  1316. .RT
  1317. .PP
  1318. Calling line identification is an optional user facility,
  1319. standardized for circuit\(hyswitched data transmission services on a CSPDN, 
  1320. that enables a user to be informed of the identity of the calling user 
  1321. for incoming calls. When provided the facility applies to all incoming 
  1322. calls. 
  1323. .PP
  1324. Calling line identification is an optional user facility assigned to the 
  1325. user for an agreed contractual period. 
  1326. .PP
  1327. The calling line identity is the X.121 data number of the calling
  1328. user. For international calls, the identity is the complete X.121 international 
  1329. data number including the DNIC or DCC component as applicable. 
  1330. .PP
  1331. \fINote\fR \ \(em\ The implications of a possible combination of \fIcalling 
  1332. line\fR \fIidentification\fR and the \fIbilateral closed user group\fR 
  1333. facility are for further study. 
  1334. .PP
  1335. Information indicating that a user has the \fIcalling line\fR 
  1336. \fIidentification\fR facility is stored at the exchange to which the user is
  1337. connected. The identity sent to the called user is originating under control 
  1338. of the exchange to which the calling user is connected. 
  1339. .PP
  1340. Facility registration is controlled by the Administration or
  1341. Recognized Private Operating Agency (RPOA).
  1342. .bp
  1343. .RT
  1344. .sp 1P
  1345. .LP
  1346. 6.2.4.2
  1347.     \fICall establishment procedure\fR 
  1348. .sp 9p
  1349. .RT
  1350. .PP
  1351. The procedure for a call to a user having the \fIcalling line\fR 
  1352. \fIidentification\fR facility varies depending on whether the calling line 
  1353. identity is included in the initial call control information received by 
  1354. the destination exchange at call establishment. 
  1355. .RT
  1356. .LP
  1357.     a)
  1358.      In the case where the calling line identity is included in the call control 
  1359. information received by the destination exchange, this 
  1360. identity is sent to the called user in accordance with the applicable\ 
  1361. DTE/DCE interface protocol. 
  1362. .LP
  1363.     b)
  1364.      In the case where the calling line identity is not included in the call 
  1365. control information received by the destination exchange, it sends a request 
  1366. for identification towards the originating exchange. 
  1367. .LP
  1368.     i)
  1369.      In the case where the originating network does provide the \fIcalling 
  1370. line identification\fR facility, the originating exchange responds with 
  1371. the calling line which is forwarded by the destination exchange to the 
  1372. called user in accordance with the applicable\ DTE/DCE interface protocol.
  1373. .LP
  1374.     ii)
  1375.     In the case where he originating network does not
  1376. provide the \fIcalling line identification\fR facility, the originating 
  1377. exchange 
  1378. responds with the originating network identity (see
  1379. Recommendation\ X.302). In this case, the identification sent by the destination 
  1380. exchange to the called user is in accordance with the applicable\ DTE/DCE 
  1381. interface protocol.
  1382. .PP
  1383. The destination exchange must not connect through until the
  1384. identity has been completely sent to the called user. Also, in the case 
  1385. where decentralized signalling is used, transit exchanges have to delay 
  1386. through\(hyconnection in certain situations until a possible identification has
  1387. been completed in accordance with the applicable interexchange signalling
  1388. procedures (see Recommendations\ X.70 and\ X.71).
  1389. .sp 1P
  1390. .LP
  1391. 6.3
  1392.     \fITransfer of E.164 calling address\fR 
  1393. .sp 9p
  1394. .RT
  1395. .PP
  1396. This section describes arrangements for the transfer of calling
  1397. address information defined in Recommendation\ E.164.
  1398. .RT
  1399. .sp 1P
  1400. .LP
  1401. 6.3.1
  1402.     \fITransfer during call request phase\fR 
  1403. .sp 9p
  1404. .RT
  1405. .PP
  1406. The E.164 calling address shall be provided by the originating
  1407. E.164 network for data\(hymode calls, when calling line identification is
  1408. provided. The originating\ E.164 network is responsible for validating 
  1409. the\ E.164 calling address, when provided. In the case where the calling 
  1410. address is 
  1411. conveyed transparent for the\ E.164 network (e.g.\ part access), such
  1412. validation, if any, will be done outside the\ E.164 network.
  1413. .PP
  1414. However, the following particular situations occur:
  1415. .RT
  1416. .PP
  1417. 6.3.1.1
  1418. In case of interworking with a non\(hyE.164 network, a method of indicating 
  1419. that the calling address is a E.164 address must be employed. This shall 
  1420. be done either by using a standardized escape digit to indicate a\ E.164 
  1421. address follows or by some form of NPI/TOA indicating the calling address 
  1422. is 
  1423. an\ E.164 address.
  1424. .sp 9p
  1425. .RT
  1426. .PP
  1427. 6.3.1.2
  1428. In some cases, even where the transfer of the E.164 calling
  1429. address is technically possible, there may be administrative reasons why the
  1430. identity of the calling user, and therefore the\ E.164 calling address 
  1431. related to it, cannot be passed over an international boundary. In such 
  1432. a case, the 
  1433. procedures are for further study.
  1434. .PP
  1435. 6.3.1.3
  1436. Networks other than PDNs and ISDNs, whenever they are used in
  1437. conjunction with the PDN and ISDN for offering data transmission services,
  1438. should, if possible, provide for the transfer of\ E.164 calling address.
  1439. However, this transfer may not be technically possible through some current
  1440. networks; for example, for a call passing through a PSTN, into a PDN or 
  1441. ISDN, the telephone network is not always able to indicate the\ E.164 calling 
  1442. address to the\ E.164 network. In such a case, alternate calling address 
  1443. information 
  1444. transferred through the PDN or ISDN instead of the\ E.164 calling address 
  1445. is for further study. 
  1446. .PP
  1447. 6.3.1.4
  1448. In a PDN or ISDN the E.164 calling address can be transferred to the called 
  1449. DTE in calling address field (appropriate to the relevant protocol) signalling 
  1450. to the called DTE (see Appendix\ I). 
  1451. .PP
  1452. \fINote\fR \ \(em\ Not all DTEs will be able to accept the long packet
  1453. format that will be required for full\ E.164 addresses in post Time\ \*QT\*U. 
  1454. The 
  1455. calling address could not be delivered to such\ DTEs.
  1456. .bp
  1457. .PP
  1458. 6.3.1.5
  1459. In an ISDN, the E.164 calling address is transferred to the called DTE 
  1460. primarily in the calling DTE address field signalled to the called\ DTE. 
  1461. It can also be transferred in a duplicate manner using notification procedures 
  1462. in the calling party number information element contained in the\ SETUP 
  1463. message 
  1464. sent to the called party across the D\(hyChannel (see Recommendation\ X.31). In
  1465. this case, the calling party number information element must be so coded 
  1466. as to indicate that the calling address is an\ E.164 address. 
  1467. .PP
  1468. \fINote\fR \ \(em\ Not all DTEs will be able to accept the long packet
  1469. format that will be required for full\ E.164 addresses in post Time\ \*QT\*U. 
  1470. The 
  1471. calling address could not be delivered to such\ DTEs.
  1472. .sp 1P
  1473. .LP
  1474. 6.4
  1475.     \fITransfer of X.121 called address\fR 
  1476. .sp 9p
  1477. .RT
  1478. .PP
  1479. This section describes arrangements for the transfer of called
  1480. address information defined in Recommendation\ X.121 through\ PDNs and\ ISDNs.
  1481. Such information is referred to in this section as the \*QX.121 called 
  1482. address\*U. 
  1483. .PP
  1484. \fINote\fR \ \(em\ The X.121 called address resides only on a PDN.
  1485. .RT
  1486. .sp 1P
  1487. .LP
  1488. 6.4.1
  1489.     \fITransfer during call request phase\fR 
  1490. .sp 9p
  1491. .RT
  1492. .PP
  1493. As it is essential for the purposes of call establishment,
  1494. inlcuding routing, the\ X.121 called address is systematically transferred
  1495. through the\ PDNs and\ ISDNs during the call request phase.
  1496. .RT
  1497. .sp 1P
  1498. .LP
  1499. 6.4.2
  1500.     \fITransfer during call confirmation phase\fR 
  1501. .sp 9p
  1502. .RT
  1503. .PP
  1504. The destination network does not need to provide the X.121 called address 
  1505. (or called line identity) if not requested. When provided, the 
  1506. destination PDN is responsible for validating the X.121 called address.
  1507. .PP
  1508. However, the following particular situations occur:
  1509. .RT
  1510. .PP
  1511. 6.4.2.1
  1512. In the circuit switched data transmission service in CSPDNs,
  1513. the X.121 called address can be transferred to the calling\ DTE as the called
  1514. line identity. It is transferred if the calling DTE requests the
  1515. \fIcalled line identification\fR facility (see \(sc\ 6.4.4). If the call 
  1516. has been 
  1517. redirected or if a \fIhunt group\fR facility has been invoked in the
  1518. destination\ PDN, the address of the called\ DTE/DCE interface over which the
  1519. call is established shall be transferred.
  1520. .sp 9p
  1521. .RT
  1522. .PP
  1523. 6.4.2.2
  1524. In PSPDNs and ISDNs, the X.121 called address can be transferred to the 
  1525. calling DTE. In the case of \fIcall redirection\fR facility, the address 
  1526. of the called\ DTE/DCE interface over which the call is established is 
  1527. always 
  1528. transferred. In the case of \fIhunt group\fR facility, this address is always
  1529. transferred, if a specific address has been assigned to the individual\ 
  1530. DTC/DCE interface over which the call is established. 
  1531. .sp 1P
  1532. .LP
  1533. 6.4.3
  1534.     \fITransfer during other phases of the call\fR 
  1535. .sp 9p
  1536. .RT
  1537. .PP
  1538. The X.121 called address does not need to be transferred through
  1539. the network during any other phase of the call.
  1540. .PP
  1541. However, the following particular situation occurs:
  1542. .RT
  1543. .PP
  1544. 6.4.3.1
  1545. In the packet switched data transmission service, a clear
  1546. request issued by a\ DTE, to which a call has been redirected or distributed
  1547. among a hunt group as a direct response to the call request phase, should
  1548. contain the address of the\ DTE/DCE interface. This is mandatory in the
  1549. \fIhunt group\fR facility case only if specific addresses have been assigned 
  1550. to the individual\ DTE/DCE interfaces of the hunt group. When this clear 
  1551. request is 
  1552. destined for an\ E.164 network, some method of indicating this in an\ X.121
  1553. number must be used (see \(sc\ 6.1).
  1554. .sp 9p
  1555. .RT
  1556. .sp 2P
  1557. .LP
  1558. 6.4.4
  1559.     \fICalled line identification\fR 
  1560. .sp 1P
  1561. .RT
  1562. .sp 1P
  1563. .LP
  1564. 6.4.4.1
  1565.     \fIGeneral\fR 
  1566. .sp 9p
  1567. .RT
  1568. .PP
  1569. \fICalled line identification\fR \|is a user facility, standardized
  1570. for circuit\(hyswitched data transmission services on a\ CSPDN, that enables 
  1571. a user to be informed for outgoing calls of the identity of the user to 
  1572. which the call has been connected. When provided, the facility applies 
  1573. to all outgoing calls. 
  1574. .bp
  1575. .PP
  1576. It is an optional user facility assigned to the user for an agreed
  1577. contractual period.
  1578. .PP
  1579. The called line identification is the X.121 data number of the user to 
  1580. which the call has been connected. For international calls, the identity 
  1581. is the complete\ X.121 international data number including the\ DNIC or\ 
  1582. DCC component as applicable. 
  1583. .PP
  1584. Information indicating that a user has the \fIcalled line\fR 
  1585. \fIidentification\fR \|facility is stored at the exchange to which the user is
  1586. connected. The identity sent to the calling user is originated under control 
  1587. of the exchange to which the called user is connected. 
  1588. .RT
  1589. .sp 1P
  1590. .LP
  1591. 6.4.4.2
  1592.     \fICall establishment procedures\fR 
  1593. .sp 9p
  1594. .RT
  1595. .PP
  1596. In the case of a call from a user having the \fIcalled line\fR 
  1597. \fIidentification\fR \|facility, the call control information forwarded by the
  1598. originating exchange at call establishment includes a request for called 
  1599. line identification. The procedure then depends on whether or not the destination 
  1600. network provides the facility.
  1601. .RT
  1602. .LP
  1603.     a)
  1604.      In the case where the destination network does provide the \fIcalled 
  1605. line identification\fR \|facility, the destination exchange responds with 
  1606. the called line identity, which is returned by the originating exchange 
  1607. to the calling user in accordance with applicable\ DTE/DCE interface protocol. 
  1608. .LP
  1609.     b)
  1610.      In the case where the destination network does not provide the \fIcalled 
  1611. line identification\fR \|facility, the destination network responds, depending 
  1612. on what type of signalling is used, with the destination network 
  1613. identity (Recommendation\ X.302) or with a \*Qdummy\*U identification
  1614. (Recommendation\ X.70 or\ X.71). The information sent by the originating 
  1615. exchange to the calling user is in accordance with the applicable\ DTE/DCE 
  1616. interface 
  1617. protocol.
  1618. .PP
  1619. For circuit switched calls, the originating exchange must not
  1620. connect through until the identity has been completely sent to the called 
  1621. user. Also, in the case where decentralized signalling is used, transit 
  1622. exchanges 
  1623. have to delay through\(hyconnection in certain situations until a possible
  1624. identification has been completed in accordance with the applicable
  1625. interexchange signalling procedures (see Recommendations\ X.70 and\ X.71).
  1626. .sp 1P
  1627. .LP
  1628. 6.5
  1629.     \fITransfer of E.165 called address\fR 
  1630. .sp 9p
  1631. .RT
  1632. .PP
  1633. This section describes the arrangements for the transfer of called address 
  1634. information defined in Recommendation\ E.164. 
  1635. .RT
  1636. .sp 1P
  1637. .LP
  1638. 6.5.1
  1639.     \fITransfer during call request phase\fR 
  1640. .sp 9p
  1641. .RT
  1642. .PP
  1643. As it is essential for the purposes of call establishment,
  1644. including routing, the\ E.164 called address is systematically transferred
  1645. through the\ PDNs and\ ISDNs during the call request phase.
  1646. .PP
  1647. However, the following particular situation occurs:
  1648. .RT
  1649. .PP
  1650. 6.5.1.1
  1651. In the case of interworking with a non\(hyE.164 network where the transit 
  1652. network is a\ PDN, a method of indicating that the called address is 
  1653. an\ E.164 address must be employed. This shall be done either by using a
  1654. standardized escape digit to indicate an\ E.164 address follows or by some 
  1655. form of\ NPI/TOA indicating the called address is an\ E.164 address. 
  1656. .sp 9p
  1657. .RT
  1658. .sp 1P
  1659. .LP
  1660. 6.5.2
  1661.     \fITransfer during call confirmation phase\fR 
  1662. .sp 9p
  1663. .RT
  1664. .PP
  1665. The destination network does not need to provide the E.164 called address 
  1666. (or called line identity) if not requested. When provided, the 
  1667. destination network is responsible for validating the\ E.164 called address.
  1668. .PP
  1669. However, the following particular situation occurs:
  1670. .RT
  1671. .PP
  1672. 6.5.2.1 
  1673. In PDNs and ISDNs, the E.164 called address can be transferred to the calling 
  1674. DTE as the called line identification. In the case of \fIcall\fR 
  1675. \fIre\(hydirection\fR facility, the address of the called\ DTE/DCE interface 
  1676. over which the call is established is always transferred. In the case of 
  1677. the \fIhunt goup\fR facility, this address is always transferred, if a 
  1678. specific address has been 
  1679. assigned to the individual\ DTE/DCE interface over which the call is
  1680. established.
  1681. .sp 9p
  1682. .RT
  1683. .PP
  1684. \fINote\fR \ \(em\ Not all DTEs will be able to accept the long packet
  1685. format that will be required for full\ E.164 addresses in post Time\ \*QT\*U. 
  1686. The 
  1687. calling address could not be delivered to such\ DTEs.
  1688. .bp
  1689. .sp 1P
  1690. .LP
  1691. 6.5.3
  1692.     \fITransfer during other phases of the call\fR 
  1693. .sp 9p
  1694. .RT
  1695. .PP
  1696. The E.164 called address does not need to be transferred through
  1697. the network during any other phase of the call.
  1698. .PP
  1699. However, the following particular situation occurs:
  1700. .RT
  1701. .PP
  1702. 6.5.3.1
  1703. In the packet switched data transmission service, a clear
  1704. request issued by a DTE, to which a call has been redirected or distributed
  1705. among a hunt goup as a direct response to the call request phase, should
  1706. .sp 9p
  1707. .RT
  1708. .LP
  1709. contain the address of the\ DTE/DCE interface. This is mandatory in the
  1710. \fIhunt group\fR facility case only if specific addresses have been assigned 
  1711. to the individual\ DTE/DCE interfaces of the hunt goup. When this clear 
  1712. request is 
  1713. destined for an\ X.121 network, some method of indicating this in an\ E.164
  1714. number must be used (see \(sc\ 6.1).
  1715. .sp 1P
  1716. .LP
  1717. 6.6
  1718.     \fIFormat of X.121 addresses\fR 
  1719. .sp 9p
  1720. .RT
  1721. .PP
  1722. Section 6.1 describes the different cases for the format of\ X.121   addresses.
  1723. .PP
  1724. Address information defined in Recommendation X.121 is referred to in this 
  1725. section as the \*QX.121\ address\*U. 
  1726. .PP
  1727. Whenever an X.121 address has to be conveyed across a DTE/DCE
  1728. interface
  1729. or an IDSE\ X/Y interface, according to the requirements mentioned in this
  1730. Recommendation, this transfer should be done according to the following
  1731. principles:
  1732. .RT
  1733. .PP
  1734. 6.6.1
  1735. For international calls, the X.121 address shall be given
  1736. explicitly in the form of the complete international data number including
  1737. the\ DNIC or\ DCC component as applicable.
  1738. .sp 9p
  1739. .RT
  1740. .PP
  1741. 6.6.2
  1742. The exact format of an address signal may not necessarily be the same nationally. 
  1743. Such a format is a matter for specific arrangement at each 
  1744. interface involved in the call: calling\ DTE/DCE interface, called\ DTE/DCE
  1745. interface and interexchange interfaces.
  1746. .PP
  1747. For example, on an X.21 or X.25 interface, the same address may be represented 
  1748. in either one of the ways illustrated in\ a) or\ b) and/or\ c) or\ d) and/or\ 
  1749. e) of Figure\ 6\(hy2/X.301. 
  1750. .LP
  1751. .rs
  1752. .sp 18P
  1753. .ad r
  1754. \fBFigure 6\(hy2/X.301 (CCIRR\(hy59111), p.\fR 
  1755. .sp 1P
  1756. .RT
  1757. .ad b
  1758. .RT
  1759. .PP
  1760. This example illustrates the use of a prefix, as recognized in
  1761. Recommendation\ X.121, as one way to distinguish between different format 
  1762. of the same address. 
  1763. .PP
  1764. In the case of mobile services, a conversion between different address 
  1765. formats may be required at various interfaces throughout the network, for 
  1766. roaming subscribers.
  1767. .PP
  1768. \fINote\fR \ \(em\ A roaming mobile subscriber is a subscriber who may obtain
  1769. fully automatic connections, even when he moves out of his normal area of
  1770. operation.
  1771. .bp
  1772. .RT
  1773. .PP
  1774. 6.6.3
  1775. The specific format(s) that can be used at a given interface
  1776. are defined in the appropriate\ CCITT Recommendations dealing with the
  1777. interface.
  1778. .sp 9p
  1779. .RT
  1780. .sp 1P
  1781. .LP
  1782. 6.7
  1783.     \fIFormat of E.164 Addresses\fR 
  1784. .sp 9p
  1785. .RT
  1786. .PP
  1787. Section 6.1 describes the different cases for the format of E.164   addresses.
  1788. .PP
  1789. Address information defined in Recommendation E.164 is referred to in this 
  1790. section as the\ \*QE.164 address\*U. 
  1791. .PP
  1792. Whenever an E.164 address has to be conveyed across a network/user
  1793. interface or an interexchange interface, according to the requirements
  1794. mentioned in this Recommentation, this transfer should be done according 
  1795. to the following principles: 
  1796. .RT
  1797. .PP
  1798. 6.7.1
  1799. For internetwork calls the E.164 address shall be given
  1800. explicitly in the form of the complete international subscriber number
  1801. including the\ CC and\ N(s)N.
  1802. .sp 9p
  1803. .RT
  1804. .PP
  1805. 6.7.2
  1806. The exact coding (format) of an address signal may not necessarily be the 
  1807. same nationally. Such a format is a matter for specific arrangement at 
  1808. each interface involved in the call: calling network/user interface, called 
  1809. network/user interface and interexchange interfaces.
  1810. .PP
  1811. For example, on an ISDN interface, the same address may be
  1812. represented in either one of the ways illustrated in\ a) or\ b) and/or\ 
  1813. c) or\ d) of Figure\ 6\(hy3/X.301. 
  1814. .LP
  1815. .rs
  1816. .sp 15P
  1817. .ad r
  1818. \fBFigure 6\(hy3/X.301, p.\fR 
  1819. .sp 1P
  1820. .RT
  1821. .ad b
  1822. .RT
  1823. .PP
  1824. This example illustrates the use of a prefix, as recognized in
  1825. Recommendation E.164 as one way to distinguish between codings (or formats) 
  1826. of the same address. 
  1827. .PP
  1828. 6.7.3
  1829. The specific formats that can be used at a given interface are
  1830. defined in the appropriate\ CCITT Recommendation dealing with that interface.
  1831. .sp 1P
  1832. .LP
  1833. 6.8
  1834.      \fITransfer of address information additional to\fR \fIRecommendation\ 
  1835. X.121 and\ E.164\fR 
  1836. .sp 9p
  1837. .RT
  1838. .PP
  1839. This section describes arrangements for the transfer of address
  1840. information additional to that defined in Recommendations\ X.121 and\ E.164.
  1841. .RT
  1842. .sp 1P
  1843. .LP
  1844. 6.8.1
  1845.     \fIGeneral\fR 
  1846. .sp 9p
  1847. .RT
  1848. .PP
  1849. The Network Addressing Extension (NAE)/subaddress (see note)
  1850. mechanism allows the transfer through PDNs on a per call basis of addressing
  1851. information beyond the total limit established for X.121/E.164\ addresses. 
  1852. This mechanism is standardized for circuit and packet switching data transmission 
  1853. service as shown in Table\ 6\(hy2/X.301.
  1854. .bp
  1855. .RT
  1856. .ce
  1857. \fBH.T. [T3.301]\fR 
  1858. .ce
  1859. TABLE\ 6\(hy2/X.301
  1860. .ce
  1861. \fBOptional user facilities standardized for different data\fR 
  1862. .ce
  1863.  
  1864. .ce
  1865. \fBtransmission services,\fR 
  1866. .ce
  1867. \fBrelated to addressing information\fR 
  1868. .ce
  1869. \fBadditional to Recommendations X.121 and E.164\fR 
  1870. .ps 9
  1871. .vs 11
  1872. .nr VS 11
  1873. .nr PS 9
  1874. .TS
  1875. center box;
  1876. cw(54p) | cw(18p) | cw(30p) | cw(24p) sw(18p) sw(24p) | cw(18p) sw(24p) sw(18p) , ^  | ^  | ^  | c | c | c | c | c | c.
  1877. Optional user facility    Period  of time    Applies  per call    T{
  1878. Applies to circuit switched data
  1879. transmission
  1880. service
  1881. T}    T{
  1882. Applies to packet switched data
  1883. transmission
  1884. service
  1885. T}
  1886.             PTSN    CSPDN    ISDN    ISDN    PSPDN    MSS
  1887. _
  1888. .T&
  1889. lw(54p) | lw(18p) | cw(30p) | lw(24p) | lw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  1890. Calling NAE/sub\(hyaddress        X            X    X    X    X 
  1891. .T&
  1892. lw(54p) | lw(18p) | cw(30p) | lw(24p) | lw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  1893. Called NAE/sub\(hyaddress        X            X    X    X    X 
  1894. _
  1895. .TE
  1896. .nr PS 9
  1897. .RT
  1898. .ad r
  1899. \fBTableau 6\(hy2/X.301 [T3.301], p.\fR 
  1900. .sp 1P
  1901. .RT
  1902. .ad b
  1903. .RT
  1904. .LP
  1905. .sp 3
  1906. .PP
  1907. If sufficient space exists in the fields carrying X.121/E.164
  1908. address information, and an arrangement exists between users and networks
  1909. concerned, this constitutes an alternative capability, available on a per 
  1910. call basis without requiring the\ NAE mechanism, for the transfer of addressing 
  1911. information additional to that defined in Recommendation\ X.121/E.164.
  1912. .PP
  1913. \fINote\fR \ \(em\ Different terms exists: In general, NAE is used in X\(hySeries 
  1914. Recommendations, and subaddress is used in I\(hySeries Recommendations. 
  1915. .RT
  1916. .sp 1P
  1917. .LP
  1918. 6.8.2
  1919.     \fIRealization\fR 
  1920. .sp 9p
  1921. .RT
  1922. .PP
  1923. The detailed realization of the NAE mechanism at each type of
  1924. internetwork and user interface is independently defined in the appropriate
  1925. signalling and interface Recommendations.
  1926. .RT
  1927. .sp 1P
  1928. .LP
  1929. 6.8.3
  1930.     \fIPrinciples\fR 
  1931. .sp 9p
  1932. .RT
  1933. .PP
  1934. The following principles apply equally and independently to both
  1935. called and calling address information:
  1936. .RT
  1937. .PP
  1938. 6.8.3.1
  1939. The transfer of addressing information at the OSI Network Layer additional 
  1940. to that defined in Recommendation\ X.121/E.164 is possible during any phase 
  1941. of the call in which address information defined in\ X.121/E.164 can also 
  1942. be transferred (see \(sc\(sc\ 6.1 and\ 6.7 above). 
  1943. .sp 9p
  1944. .RT
  1945. .PP
  1946. 6.8.3.2
  1947. The addressing information in the NAE/subaddress can be of
  1948. variable length. It can comprise up to 20\ octets of binary coded information
  1949. (see\ Note). The content of the information is unrestricted with respect 
  1950. to the grouping of digits. 
  1951. .PP
  1952. \fINote\fR \ \(em\ The maximum length of 40 decimal digits is derived from 
  1953. the maximum length of the\ OSI Network Service Access Point (NSAP) address 
  1954. defined in Recommendation\ X.213 [see also ISO\ 8348\ AD2]. Exact arrangements 
  1955. for treatment of the OSI\ NSAP address are for further study. 
  1956. .PP
  1957. 6.8.3.3
  1958. Public networks are not required to look at or operate on a
  1959. NAE/subaddress for any purpose including routing; however, some public 
  1960. networks may look at the NAE/subaddress, if they wish. 
  1961. .PP
  1962. 6.8.3.4
  1963. In cases where it is possible, and an arrangement exists between users 
  1964. and public networks concerned, the conveyance of the complete addressing 
  1965. information (i.e.,\ all elements of OSI\ Network Addressing) may be performed 
  1966. without NAE/subaddress mechanism.
  1967. .bp
  1968. .PP
  1969. 6.8.3.5
  1970. Each internetwork interface should simultaneously accommodate the following 
  1971. partitions of the addressing information between existing protocol 
  1972. elements for addressing and NAEs/subaddresses:
  1973. .LP
  1974.     a)
  1975.      All elements of addressing information are contained in the existing 
  1976. protocol elements for addressing; no NAE/subaddress is needed; the 
  1977. complete DTE\ Network Address is contained in the existing protocol elements.
  1978. .LP
  1979.     b)
  1980.      The complete DTE Address is contained in the NAE/subaddress; all elements 
  1981. of addressing information needed by the public networks involved in the 
  1982. call are contained in the existing protocol elements for addressing. The 
  1983. information used by public networks may be derived from the NAE/subaddress. 
  1984. .LP
  1985.      \fINote\fR \ \(em\ In this case, for some OSI Network Addresses, part 
  1986. of the OSI Network Address information may be duplicated in the existing 
  1987. protocol elements for addressing.
  1988. .LP
  1989.     c)
  1990.      The addressing information is split into two elements, one contained 
  1991. in the existing protocol elements for addressing, the other contained in 
  1992. the NAE/subaddress. The complete DTE\ address is the concatenation of the 
  1993. two elements. 
  1994. .LP
  1995.     d)
  1996.     The addressing information is contained in the
  1997. NAE/subaddress only. This case is typical for private networks since public
  1998. networks act typically on X.121/E.164 numbers.
  1999. .PP
  2000. 6.8.3.6
  2001. The use of the NAE/subaddress is either:
  2002. .sp 9p
  2003. .RT
  2004. .LP
  2005.     \(em
  2006.     as defined in Recommendation X.213 (see also
  2007. ISO\ 8348\ AD2) or
  2008. .LP
  2009.     \(em
  2010.     differently.
  2011. .PP
  2012. When the use of the NAE/subaddress is as defined in Recommendation X.213 
  2013. (see also ISO\ 8348\ AD2), case\ c) in \(sc\ 6.8.3.5 does not apply. 
  2014. .sp 2P
  2015. .LP
  2016. \fB7\fR     \fBArrangements for user facilities\fR (see Note 1)
  2017. .sp 1P
  2018. .RT
  2019. .PP
  2020. The internetwork arrangements described in this section relate to the optional 
  2021. user facilities defined in Recommendation\ X.2 and I.250\(hySeries 
  2022. Recommendations (see Note\ 4).
  2023. .PP
  2024. \fINote\ 1\fR \ \(em\ Different terms: in general \fIoptional user facilities\fR 
  2025. is used in X\(hySeries Recommendations, and \fIsupplementary services\fR 
  2026. is used in 
  2027. I\(hySeries Recommendations.
  2028. .PP
  2029. \fINote\ 2\fR \ \(em\ Support of these facilities by the ISDN in other 
  2030. modes of operation than packet\(hymode is for further study (see I.230\(hySeries 
  2031. Recommendations).
  2032. .PP
  2033. \fINote\ 3\fR \ \(em\ General arrangements for treatment of registration
  2034. procedures (e.g.\ Recommendation\ X.32) are for further study.
  2035. .PP
  2036. \fINote\ 4\fR \ \(em\ Alignment/interworking between facilities defined in X.2
  2037. and supplementary services defined in I.250\(hySeries Recommendations is for
  2038. further study.
  2039. .RT
  2040. .sp 1P
  2041. .LP
  2042.     \fIAlphabetical List of Facilities contained in this section\fR 
  2043. .sp 9p
  2044. .RT
  2045. .LP
  2046.     Bilateral closed user group
  2047.     7.4.2
  2048. .LP
  2049.     Called line address modified notification
  2050.     7.3.5
  2051. .LP
  2052.     Call redirection or deflection notification
  2053.     7.3.6
  2054. .LP
  2055.     Charging information
  2056.     7.2.3
  2057. .LP
  2058.     Closed user group
  2059.     7.4.1
  2060. .LP
  2061.     Connect when free and waiting allowed
  2062.     7.6.2
  2063. .LP
  2064.     Deflection of calls
  2065.     7.3.2
  2066. .LP
  2067.     Expedited data negotiation
  2068.     7.6.4
  2069. .LP
  2070.     Fast select
  2071.     7.5.2
  2072. .LP
  2073.     Hunt group
  2074.     7.3.3
  2075. .LP
  2076.     Incoming calls barred
  2077.     7.4.3
  2078. .LP
  2079.     Local charging prevention
  2080.     7.2.2
  2081. .LP
  2082.     Manual answer
  2083.     7.6.1
  2084. .bp
  2085. .LP
  2086.     Network user identification (NUI)
  2087.     7.4.5
  2088. .LP
  2089.     NUI override permission
  2090.     7.4.6
  2091. .LP
  2092.     Outgoing calls barred
  2093.     7.4.4
  2094. .LP
  2095.     Quality of OSI network service and of data transmission
  2096. service
  2097.     7.1.1
  2098. .LP
  2099.     Quality of Serive parameters
  2100.     7.1.2
  2101. .LP
  2102.     Receipt confirmation
  2103.     7.6.3
  2104. .LP
  2105.     Redirection of calls
  2106.     7.3.1
  2107. .LP
  2108.     Reverse charging and reverse charging acceptance
  2109.     7.2.1
  2110. .LP
  2111.     RPOA selection
  2112.     7.3.4
  2113. .sp 1P
  2114. .LP
  2115. 7.1
  2116.     \fIFacilities related to the quality of service (QOS)for the\fR 
  2117. \fIcall\fR 
  2118. .sp 9p
  2119. .RT
  2120. .PP
  2121. This section described arrangements required for quality of service related 
  2122. to the transmission capability. 
  2123. .RT
  2124. .sp 1P
  2125. .LP
  2126. 7.1.1
  2127.     \fIQuality of OSI network service and of data transmission service\fR 
  2128. .sp 9p
  2129. .RT
  2130. .PP
  2131. The term \*QQuality of Service\*U (QOS) refers to the specification of 
  2132. certain characteristics of a Network Connection (NC) as defined in the 
  2133. OSI 
  2134. network service (X.213). However, QOS can also be specified in relation 
  2135. to the data transmission service which is used to support the OSI network 
  2136. service. 
  2137. Each of these QOS specifications, and the relationship between them is
  2138. described in the following sections.
  2139. .RT
  2140. .sp 1P
  2141. .LP
  2142. 7.1.1.1
  2143.     \fIQOS Specification in the OSI network service\fR 
  2144. .sp 9p
  2145. .RT
  2146. .PP
  2147. The OSI network service including a detailed definition of QOS
  2148. parameters is specified in Recommendation\ X.213. The reference points 
  2149. between which the QOS parameters apply are the network service access points 
  2150. (NSAPs). 
  2151. .PP
  2152. The value of QOS applies to an entire NC. When determined or measured at 
  2153. both ends of an NC, the QOS observed by the NS users at the two ends of 
  2154. the NC is the same. This is true even in the case where the Network Connection 
  2155. is provided through the interworking of different types of networks. 
  2156. .PP
  2157. Two interworking categories related to the transmission capabilities exist, 
  2158. i.e.\ interworking at the network layer, and interworking by port access. 
  2159. The reference point between which the QOS parameters apply are in both 
  2160. cases of interworking the two NSAPs involved (see Figures\ 7\(hy1/X.301 
  2161. and 7\(hy2/X.301). 
  2162. However, the method of interworking may impact the value of QOS between the
  2163. reference points.
  2164. .PP
  2165. The Transport Layer may make a request to the OSI network service
  2166. provider for a network layer connection with certain QOS characteristics
  2167. (e.g.\ in order to decide the class of transport protocol to be used). In
  2168. response to such a request, the OSI network service provider may offer a
  2169. network layer connection with QOS characteristics that meet (the margins of)
  2170. the request, or the OSI network service provider may reject the request, 
  2171. if the QOS characteristics cannot be met. 
  2172. .PP
  2173. The QOS Reference Points between which the QOS has to be measured for this 
  2174. instance of communication, are the NSAPs between which the network layer 
  2175. connection has to be established. 
  2176. .PP
  2177. Recommendation X.224 (Transport Protocol) classifies network
  2178. connections in terms of QOS with respect to error behaviour in relation 
  2179. to user requirements; its main purpose is to provide a basis for the decision 
  2180. regarding which class of transport protocol should be used on top of a 
  2181. given network 
  2182. connection.
  2183. .RT
  2184. .sp 1P
  2185. .LP
  2186. 7.1.1.2
  2187.     \fIQOS Specification in the data transmission service\fR 
  2188. .sp 9p
  2189. .RT
  2190. .PP
  2191. Figure 7\(hy3/X.301 illustrates an example of the data transmission
  2192. service in the case where the data transmission service is provided by 
  2193. a public data network (PDN). The QOS parameters which are specified for 
  2194. the data 
  2195. transmission service can be specified in terms of event occurring within the
  2196. network layer at the DTE/DCE interface. The QOS Reference Points are defined 
  2197. to be inside the network layer entities through which the PDN may be accessed 
  2198. (e.g.\ the DCEs) and where these network layer events are observed.
  2199. .PP
  2200. These reference points apply both to interworking at the network layer 
  2201. and to interworking by port access. 
  2202. .bp
  2203. .RT
  2204. .LP
  2205. .rs
  2206. .sp 28P
  2207. .ad r
  2208. \fBFigure 7\(hy1/X.301, p. 9 
  2209. .sp 1P
  2210. .RT
  2211. .ad b
  2212. .RT
  2213. .LP
  2214. .rs
  2215. .sp 16P
  2216. .ad r
  2217. \fBFigure 7\(hy2/X.301, p. 10 
  2218. .sp 1P
  2219. .RT
  2220. .ad b
  2221. .RT
  2222. .LP
  2223. .bp
  2224. .LP
  2225. .rs
  2226. .sp 18P
  2227. .ad r
  2228. \fBFigure 7\(hy3/X.301, p. 11 
  2229. .sp 1P
  2230. .RT
  2231. .ad b
  2232. .RT
  2233. .PP
  2234. 7.1.1.3
  2235. Relationships between OSI network service QOS and data
  2236. transmission service QOS is illustrated in Figure\ 7\(hy4/X.301. The network
  2237. service QOS includes a component which is the data transmission service 
  2238. QOS and also a component which is due to the operation of the network service 
  2239. provider outside the data transmission service (i.e.\ the network service 
  2240. provider 
  2241. between the data transmission service QRPs and the relevant NSAPs). The
  2242. operation of the network service provider outside the data transmission 
  2243. service may have the effect of either devaluing or improving the QOS depending 
  2244. upon the circumstances and the aspect of QOS involved. In any case, for 
  2245. an instance of communication, the QOS of the network service is different 
  2246. from the QOS of the data transmission service. The relationship between 
  2247. such QOS values is the 
  2248. responsibility of the network service provider outside the data transmission
  2249. service.
  2250. .sp 9p
  2251. .RT
  2252. .LP
  2253. .rs
  2254. .sp 20P
  2255. .ad r
  2256. \fBFigure 7\(hy4/X.301, p.\fR 
  2257. .sp 1P
  2258. .RT
  2259. .ad b
  2260. .RT
  2261. .LP
  2262. .bp
  2263. .sp 2P
  2264. .LP
  2265. 7.1.2
  2266.     \fIQOS Parameters\fR 
  2267. .sp 1P
  2268. .RT
  2269. .sp 1P
  2270. .LP
  2271. 7.1.2.1
  2272.     \fIOSI network service QOS Parameters\fR 
  2273. .sp 9p
  2274. .RT
  2275. .PP
  2276. Network service QOS is described by means of QOS parameters. The
  2277. definition of each parameter specifies the way in which the parameter's 
  2278. value is measured or determined, making reference where appropriate to 
  2279. the events 
  2280. represented by service primitives in the network service.
  2281. .PP
  2282. It is in terms of network service QOS parameters that information
  2283. about QOS is exchanged among the network service provider and the NS users.
  2284. .PP
  2285. Examples of QOS parameters which are defined in the network service
  2286. are throughput, transit delay, and residual error rate. Recommendation\ X.213
  2287. contains the definitions of the complete set of QOS parameters which apply 
  2288. to the nework service. 
  2289. .RT
  2290. .sp 1P
  2291. .LP
  2292. 7.1.2.1.1
  2293.     \fIQOS Parameter Values\fR 
  2294. .sp 9p
  2295. .RT
  2296. .PP
  2297. In some circumstances, only a single value for a QOS parameter is conveyed 
  2298. (e.g.\ the target value desired by the network service user or the 
  2299. value being made available by the network service provider). In other cases
  2300. however, it may be possible to specify a pair of values which define an
  2301. applicable range of values (e.g.\ the network service user may be able to
  2302. specify a range bounded by a target value which is desired and the minimum
  2303. acceptable value which the user is willing to agree to.) The number of 
  2304. values which may be conveyed is dependent upon the specific QOS parameter. 
  2305. .RT
  2306. .sp 1P
  2307. .LP
  2308. 7.1.2.1.2
  2309.     \fIQOS Parameter Categories\fR 
  2310. .sp 9p
  2311. .RT
  2312. .PP
  2313. The network service QOS parameters can be divided into two
  2314. categories as follows:
  2315. .RT
  2316. .LP
  2317.     1)
  2318.     Parameters negotiated on a per\(hyconnection basis\ \(em the values
  2319. of these parameters can be conveyed between peer NS users by
  2320. means of the NS during the establishment phase of an NC; as part
  2321. of this conveyance, a three\(hyparty negotiation among the NS\ users
  2322. and the NS\ provider for the purpose of agreeing upon a
  2323. particular QOS parameter value may take place; and
  2324. .LP
  2325.     2)
  2326.     Parameters not negotiated on a \*Qper\(hyconnection\*U basis\ \(emthe
  2327. values of these parameters cannot be conveyed or negotiated
  2328. among the NS users and the NS provider, for these QOS
  2329. parameters, however, information about the values which is
  2330. useful to the NS provider and each NS user may be made known by
  2331. local means.
  2332. .PP
  2333. Only two QOS parameters of the NS, throughput and transit delay, are classified 
  2334. in the first category, and thus are conveyed and negotiated by means of 
  2335. the NS. 
  2336. .PP
  2337. (The negotiation procedures and constraints are described in
  2338. Recommendation\ X.213. The mechanisms related to the negotiation of these
  2339. parameters is described in \(sc\ 7.1.3.1.)
  2340. .PP
  2341. All of the remaining QOS parameters are classified as belonging to the 
  2342. second category. The values of these QOS parameters for a particular NC 
  2343. are not negotiated in a three\(hyparty fashion nor are they directly conveyed 
  2344. from NS user to NS user. As a local matter, however, there may be means 
  2345. by which the values of one or more of these QOS parameters are known and 
  2346. utilized by the NS 
  2347. provider and each NS user.
  2348. .PP
  2349. (The mechanisms related to this category of parameters are described in 
  2350. \(sc\ 7.1.3.2.) 
  2351. .RT
  2352. .sp 1P
  2353. .LP
  2354. 7.1.2.2
  2355.     \fIData transmission service QOS Parameters\fR 
  2356. .sp 9p
  2357. .RT
  2358. .PP
  2359. This section is for further study.
  2360. .RT
  2361. .sp 2P
  2362. .LP
  2363. 7.1.3
  2364.     \fIMechanisms related to QOS\fR 
  2365. .sp 1P
  2366. .RT
  2367. .sp 1P
  2368. .LP
  2369. 7.1.3.1
  2370.      \fITypes of mechanisms related to parameters negotiated on a per\fR \fIconnection 
  2371. basis\fR 
  2372. .sp 9p
  2373. .RT
  2374. .sp 1P
  2375. .LP
  2376. 7.1.3.1.1\ \ Three parties are involved in the specification of these QOS
  2377. parameters:
  2378. .sp 9p
  2379. .RT
  2380. .LP
  2381.     a)
  2382.     The service user at the calling QOS reference point,
  2383. .LP
  2384.     b)
  2385.     The service provider between the QOS reference points,
  2386. .LP
  2387.     c)
  2388.     The service user at the called QOS reference point.
  2389. .bp
  2390. .sp 1P
  2391. .LP
  2392. 7.1.3.1.2\ \ The service user at the calling QOS reference point will initiate 
  2393. these QOS parameters. 
  2394. .sp 9p
  2395. .RT
  2396. .LP
  2397. 7.1.3.1.3\ \ Both the service provider between the reference points and the
  2398. service user at the called QOS reference point may devalue these QOS parameters 
  2399. according to their capabilities. 
  2400. .LP
  2401. 7.1.3.1.4\ \ After possible subsequent devaluation, these QOS parameters 
  2402. will be returned to the service user at the calling QOS reference point 
  2403. without further adjustment. 
  2404. .LP
  2405. 7.1.3.1.5\ \ The returned QOS parameters specify the QOS between the two QOS
  2406. reference points.
  2407. .PP
  2408. \fINote\fR \ \(em\ The guarantee of the QOS during the lifetime of the
  2409. connection between the two QOS reference points is subject for further study.
  2410. .sp 1P
  2411. .LP
  2412. 7.1.3.2
  2413.      \fITypes of mechanisms related to parameters not negotiated on a\fR \fIper\(hyconnection 
  2414. basis\fR 
  2415. .sp 9p
  2416. .RT
  2417. .PP
  2418. Determination of the value of these types of parameters occurs
  2419. somewhere within the service provider but does not require that the values 
  2420. be negotiated between QRPs. Values of these parameters may be requested 
  2421. through 
  2422. the calling QRP by a service user. It is also possible that the service
  2423. provider may convey indications of these values to the service user at the
  2424. calling QRP, called QRP or both QRPs. Unlike the parameters negotiated on a
  2425. per\(hyconnection basis, the values of these parameters are not subject to
  2426. negotiation mechanisms as described in \(sc\ 7.1.3.1.
  2427. .RT
  2428. .sp 1P
  2429. .LP
  2430. 7.1.3.3
  2431.     \fIMinimum and target QOS parameters\fR 
  2432. .sp 9p
  2433. .RT
  2434. .LP
  2435. 7.1.3.3.1\ \ The specification of QOS parameters (if present) always contains 
  2436. a target QOS value. In addition this specification may contain a minimum 
  2437. QOS 
  2438. value.
  2439. .LP
  2440. 7.1.3.3.2\ \ For parameters negotiated on a per\(hyconnection basis, target QOS
  2441. values are subject to negotiation rules specified in \(sc\ 7.1.3.1.
  2442. .LP
  2443. 7.1.3.3.3\ \ Minimum QOS values specify the least value the service user 
  2444. at the calling QOS reference point agrees to for establishment of a connection 
  2445. between the two QOS reference points. The minimum QOS value may be used 
  2446. by the service provider between the QOS reference points to abort the connection 
  2447. establishment, if the target QOS value is devalued to a value less than the
  2448. minimum QOS value in the case of parameters negotiated on a per\(hyconnection
  2449. basis.
  2450. .PP
  2451. \fINote\fR \ \(em\ It is for further study whether the mechanism using
  2452. minimum QOS parameters is a general applicable mechanism for all parameters.
  2453. .sp 1P
  2454. .LP
  2455. 7.1.3.4
  2456.     \fISpecific mechanisms related to QOS\fR 
  2457. .sp 9p
  2458. .RT
  2459. .PP
  2460. Some mechanisms have already been defined that relate to the
  2461. quality of service on a call, (e.g.\ flow control parameters negotiation
  2462. mechanism in Recommendations\ X.25 and\ X.75).
  2463. .PP
  2464. \fINote\fR \ \(em\ It is for further study whether there is a need to introduce 
  2465. new user facilities to request a target quality of service for a call and 
  2466. new network utilities to control that target quality of service. 
  2467. .PP
  2468. The optional user facilities already standardized for different data transmission 
  2469. services, and related to the QOS of the call, are shown in 
  2470. Table\ 7\(hy1/X.301.
  2471. .RT
  2472. .sp 1P
  2473. .LP
  2474. 7.1.3.4.1
  2475.     \fITransit delay\fR 
  2476. .sp 9p
  2477. .RT
  2478. .PP
  2479. For calculation and negotiation of Transit Delay, a number of
  2480. facilities can be utilized:
  2481. .RT
  2482. .LP
  2483.     \(em
  2484.     Transit delay selection and indication (TDSAI)
  2485. .LP
  2486.     \(em
  2487.      End\(hyto\(hyend transit delay negotiation (EETDN), involving three parameters: 
  2488. .LP
  2489.     \(em
  2490.     Cumulative transit delay (CTD)
  2491. .LP
  2492.     \(em
  2493.     Target transit delay (TTD)
  2494. .LP
  2495.     \(em
  2496.     Maximum acceptable transit delay (MATD)
  2497. .bp
  2498. .ce
  2499. \fBH.T. [T4.301]\fR 
  2500. .ce
  2501. TABLE\ 7\(hy1/X.301
  2502. .ce
  2503. \fBOptional user facilities, standardized for different data\fR 
  2504. .ce
  2505.  
  2506. .ce
  2507. \fBtransmission services,\fR 
  2508. .ce
  2509. \fBrelated to the QOS of the call\fR 
  2510. .ps 9
  2511. .vs 11
  2512. .nr VS 11
  2513. .nr PS 9
  2514. .TS
  2515. center box;
  2516. cw(54p) | cw(18p) | cw(30p) | cw(24p) sw(18p) sw(24p) | cw(18p) sw(24p) sw(18p) , ^  | ^  | ^  | c | c | c | c | c | c.
  2517. Optional user facility    Period  of time    Applies  per call    T{
  2518. Applies to circuit switched data
  2519. transmission
  2520. service
  2521. T}    T{
  2522. Applies to packet switched data
  2523. transmission
  2524. service
  2525. T}
  2526.             PTSN    CSPDN    ISDN    ISDN    PSPDN    MSS
  2527. _
  2528. .T&
  2529. lw(54p) | lw(18p) | cw(30p) | lw(24p) | lw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  2530. T{
  2531. Transit delay selection and indication
  2532. T}        X                X    X    X
  2533. .T&
  2534. lw(54p) | lw(18p) | cw(30p) | lw(24p) | lw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  2535. T{
  2536. End\(hyto\(hyEnd transit delay negotiation
  2537. T}        X                X    X    X
  2538. .T&
  2539. lw(54p) | cw(18p) | cw(30p) | lw(24p) | lw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  2540. Throughput class negotiation    X    X  (Note)            FS    X    X    X
  2541. .T&
  2542. lw(54p) | cw(18p) | cw(30p) | lw(24p) | lw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  2543. Minimum throughput class        X                X    X    X
  2544. .T&
  2545. lw(54p) | cw(18p) | cw(30p) | lw(24p) | lw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  2546. T{
  2547. Default throughput class assignment
  2548. T}    X                    X    X    T{
  2549. X
  2550. \fINote\fR
  2551. \ \(em\ This facility cannot be used unless the corresponding facility has
  2552. been agreed for a period of time.
  2553. .parag
  2554. T}
  2555. _
  2556. .TE
  2557. .nr PS 9
  2558. .RT
  2559. .ad r
  2560. \fBTable 7\(hy1/X.301 [T4.301], p.\fR 
  2561. .sp 1P
  2562. .RT
  2563. .ad b
  2564. .RT
  2565. .PP
  2566. Utilization of these facilities, and their mutual relationship is described 
  2567. in the following sections. 
  2568. .sp 2P
  2569. .LP
  2570. 7.1.3.4.1.1
  2571.     \fITransit Delay Selection and Indication\fR 
  2572. .sp 1P
  2573. .RT
  2574. .sp 1P
  2575. .LP
  2576. 7.1.3.4.1.1.1
  2577.     \fIGeneral\fR 
  2578. .sp 9p
  2579. .RT
  2580. .PP
  2581. \fITransit delay selection and indication\fR is an optional user
  2582. facility that permits selection and indication, on a per call basis, of the
  2583. nominal maximum permissible transit delay applicable to that virtual call.
  2584. .PP
  2585. A DTE wishing to select a nominal maximum permissible transit delay
  2586. for a virtual call indicates the desired nominal maximum permissible value 
  2587. in the call request phase. 
  2588. .PP
  2589. During the call request phase, the nominal transit delay applicable to 
  2590. the call will be indicated to the called DTE. This transit delay may be 
  2591. smaller than, equal to, or greater than the desired nominal maximum permissible 
  2592. transit delay requested in the call request phase by the calling DTE. 
  2593. .PP
  2594. During the call confirmation phase, the nominal transit delay
  2595. applicable to the call will also be sent to the calling DTE.
  2596. .PP
  2597. \fINote\fR \ \(em\ This facility specifies the transit delay between the QRPs
  2598. applicable for the data transmission service (see \(sc\ 7.1.1.2). Provision of
  2599. transit delay values applicable for the OSI network service (see \(sc\ 
  2600. 7.1.1.3) may require the use of an additional parameter (see \(sc\ 7.1.3.4.1.2). 
  2601. .PP
  2602. For internetwork communication, two utilities are defined to handle
  2603. these facilities:
  2604. .RT
  2605. .LP
  2606.     1)
  2607.     The nominal maximum permissible transit delay value
  2608. requested by the DTE is signalled between networks by the
  2609. transit delay selection utility in the call request phase.
  2610. .LP
  2611.     2)
  2612.     The accumulated expected nominal transit delay up to, and
  2613. including the outgoing link is signalled in the transit delay
  2614. indication utility in the call request phase. The accumulated
  2615. expected nominal transit delay is signalled back in the transit
  2616. delay indication utility of the call confirmation phase.
  2617. .bp
  2618. .sp 1P
  2619. .LP
  2620. 7.1.3.4.1.1.2
  2621.     \fITransit delay definition\fR 
  2622. .sp 9p
  2623. .RT
  2624. .PP
  2625. This transit delay is the \fIdata\fR packet transfer delay as defined in 
  2626. \(sc\ 3.1 in Recommendation\ X.135, measured between boundaries \fIB\fR\d2\uand 
  2627. \fIB\fR\d\fIn\fR\\d\\u(em\d1\u, as defined in Figure\ 2/X.135 (that means, 
  2628. excluding the access lines), with the conditions given in \(sc\ 3.2 in 
  2629. Recommendation\ X.135, and is 
  2630. expressed in terms of a mean value.
  2631. .PP
  2632. Nominal maximum permissible transit delay and the expected nominal
  2633. transit delay is signalled provisionally in milliseconds and expresses 
  2634. the mean value for the packets (128\ octet size) sent by the user on that 
  2635. call. 
  2636. .PP
  2637. \fINote\ 1\fR \ \(em\ It is for further study whether the transit delay values
  2638. shall apply only for busy hour condition.
  2639. .PP
  2640. \fINote\ 2\fR \ \(em\ The range and the number of reasonable values of the
  2641. nominal maximum permissible transit delay and the expected nominal transit
  2642. delay are for further study.
  2643. .RT
  2644. .sp 1P
  2645. .LP
  2646. 7.1.3.4.1.1.3
  2647.     \fICall request anc call confirmation phases\fR \v'2p'
  2648. .sp 9p
  2649. .RT
  2650. .LP
  2651.     a)
  2652.     In the call request phase a network, when able to do so,
  2653. should allocate resources and route the virtual call in a manner
  2654. such that the nominal transit delay applicable to that call does
  2655. not exceed the desired nominal maximum permissible transit
  2656. delay.
  2657. .LP
  2658.     1)
  2659.     In the call request phase, the calling DTE indicates
  2660. the nominal maximum permissible transit delay in the
  2661. \fItransit delay selection and indication facility\fR ;
  2662. .LP
  2663.     2)
  2664.     In the call request phase on an internetwork link,
  2665. the network shall, if routing on transit delay is
  2666. performed, take into consideration both of the values
  2667. given in the \fItransit delay selection and transit\fR \fIdelay indication\fR 
  2668. utilities. 
  2669. .LP
  2670.     B)
  2671.     The network shall determine the expected nominal transit
  2672. delay for the network part of the vitual circuit in question,
  2673. based on the definition in \(sc\ 7.1.3.4.1.1.2.
  2674. .LP
  2675.     In accordance with the definition of \fIt3c\fR , this includes
  2676. the expected nominal transit delay for all DSEs and links that
  2677. the call passes through, taking into consideration such elements
  2678. as size of DSEs, transmission speed and type of links.
  2679. .LP
  2680.     However, determination of the actual values is a national
  2681. matter.
  2682. .LP
  2683.     If the call in question is resulting from an incoming
  2684. internetwork link call, the determined expected nominal transit
  2685. delay shall be added to the received value in the \fItransit\fR \fIdelay 
  2686. indication\fR utility. 
  2687. .LP
  2688.     1)
  2689.     In the case of an incoming call to a DTE, the expected
  2690. nominal transit delay shall be transmitted to the DTE in the
  2691. \fItransit delay selection and indication\fR facility.
  2692. .LP
  2693.     2)
  2694.     In the case of a call request on an internetwork
  2695. link, the expected nominal transit delay shall be signalled in
  2696. the \fItransit delay indication\fR utility. The transit delay
  2697. originally requested by the DTE is optionally signalled in the
  2698. \fItransit delay selection\fR utility.
  2699. .LP
  2700.     C)
  2701.     The total accumulated expected nominal transit delay is
  2702. signalled back in the \fItransit delay indication\fR utility in the
  2703. call confirmation phase. This value is transferred by the
  2704. originating network to the calling DTE in the \fItransit delay\fR 
  2705. \fIselection and indication\fR facility in the call confirmation
  2706. phase.
  2707. .LP
  2708.     During the call request phase the nominal transit delay
  2709. applicable to the call will be indicated to the called DTE. This
  2710. transit delay may be smaller than, equal to, or greater than the
  2711. desired nominal maximum permissible transit delay requested in
  2712. the call request phase by the calling DTE.
  2713. .LP
  2714.     During the call confirmation phase, the nominal transit
  2715. delay applicable to the call will also be sent to the calling
  2716. DTE.
  2717. .sp 2P
  2718. .LP
  2719. 7.1.3.4.1.2
  2720.     \fIEnd\(hyto\(hyend transit delay negotiation\fR 
  2721. .sp 1P
  2722. .RT
  2723. .sp 1P
  2724. .LP
  2725. 7.1.3.4.1.2.1
  2726.     \fIGeneral\fR 
  2727. .sp 9p
  2728. .RT
  2729. .PP
  2730. End\(hyto\(hyend transit delay negotiation is an optional user facility 
  2731. that permits on a per call basis conveyance of: 
  2732. .RT
  2733. .LP
  2734.     a)
  2735.     Cumulative transit delay
  2736. .LP
  2737.     b)
  2738.     Target transit delay (TTD) (optional)
  2739. .LP
  2740.     c)
  2741.     Maximum acceptable transit delay (MATD) (optional)
  2742. .bp
  2743. .PP
  2744. The TTD corresponds with the target QOS parameter (see \(sc\ 7.1.3.3) for 
  2745. transit delay. 
  2746. .PP
  2747. The MATD corresponds with the minimum QOS parameter (see \(sc\ 7.1.3.3)
  2748. for transit delay.
  2749. .PP
  2750. The CTE accumulates the total transit delay applicable for the call by 
  2751. adding the individual transit delays of the subsequent portions of the 
  2752. connection (which may be presented by the \fItransit delay selection and\fR 
  2753. \fIindication\fR facility; see \(sc\ 7.1.3.4.1).
  2754. .RT
  2755. .sp 1P
  2756. .LP
  2757. 7.1.3.4.1.2.2
  2758.     \fICall request and call confirmation phases\fR 
  2759. .sp 9p
  2760. .RT
  2761. .PP
  2762. The CTD will be conveyed from calling to called DTE during the call request 
  2763. phase. Its values will be incremented by transit delays of individual portions 
  2764. of the connection that may be presented by the \fItransit delay\fR 
  2765. \fIselection and indication\fR facility (see \(sc\ 7.1.3.4.1) or may be 
  2766. obtained from local knowledge. The TTD and MATD may also be conveyed from 
  2767. calling to called DTE during the call request phase, and can be used for 
  2768. comparison with the 
  2769. accumulated value.
  2770. .PP
  2771. The public networks involved in the call are not required to look at or 
  2772. operate on these parameters, e.g.\ for aborting the call; however, some 
  2773. networks may look at the parameters if they wish.
  2774. .PP
  2775. The total accumulated transit delay, when accepted by the called DTE, is 
  2776. conveyed from the called DTE to the calling DTE during the call confirmation 
  2777. phase in the CTE parameter. The TTD and the MATD parameters are not conveyed 
  2778. during the call confirmation phase.
  2779. .PP
  2780. Figure 7\(hy5/X.301 shows an example of the utilization of all transit
  2781. delay parameters.
  2782. .RT
  2783. .LP
  2784. .rs
  2785. .sp 11P
  2786. .ad r
  2787. \fBFigure 7\(hy5/X.301, p.\fR 
  2788. .sp 1P
  2789. .RT
  2790. .ad b
  2791. .RT
  2792. .PP
  2793. The labels (a), (b), (c), (d), (e), (f
  2794. ) and (g) represent
  2795. the various points between the entities involved in the scenario shown
  2796. above at which the transit delay information is visible in the protocol
  2797. information.
  2798. .LP
  2799. .sp 1
  2800. Facility
  2801. Utilities
  2802. EETDN
  2803. TDSAI
  2804. TDS
  2805. TDI
  2806. CTD
  2807. TTD
  2808. MATD
  2809. .LP
  2810. Call Request Phase
  2811. a)
  2812. t\(em2d1 (Note\ 1)
  2813. NA
  2814. NA\fR 2d1
  2815. t
  2816. w
  2817. b)
  2818. p1
  2819. NA
  2820. NA\fR 2d1
  2821. t
  2822. w
  2823. .ce 1000
  2824. c)
  2825. t\(em2d1\(emp1\(em(g1\(emg2)
  2826. NA
  2827. NA\fR 2d1+p1+(g1+g2)
  2828. t
  2829. w
  2830. d)
  2831. NA
  2832. t\(em2d1
  2833. .ce 0
  2834. .ce 1000
  2835. \(emp1
  2836. .ce 0
  2837. .LP
  2838. \(em(g1\(emg2)
  2839. p2\(eme
  2840. 2d1+p1+(g1+g2)
  2841. t
  2842. w
  2843. e)
  2844. p2\(eme\(emp3
  2845. NA
  2846. NA\fR 2d1+p1+(g1+g2)
  2847. t
  2848. w
  2849. .ce 1000
  2850. f
  2851. )
  2852. t\(em(2d1\(emp1\(em(g1\(emg2))
  2853. \(em(g3\(emg4)\(em(p2\(eme\(emp3)
  2854. NA
  2855. NA\fR 2d1+p1+(g1+g2)
  2856. .ce 0
  2857. .ce 1000
  2858. +(p2+e+p3)+
  2859. .ce 0
  2860. .ce 1000
  2861. (g3+g4)
  2862. t
  2863. w
  2864. g)
  2865. p4
  2866. NA
  2867. NA\fR 2d1+p1+(g1+g2)
  2868. .ce 0
  2869. .ce 1000
  2870. +(p2+e+p3)+
  2871. .ce 0
  2872. .LP
  2873. (g3+g4)
  2874. t
  2875. w
  2876. .bp
  2877. .LP
  2878. Facility
  2879. Utilities
  2880. EETDN
  2881. TDSAI
  2882. TDS
  2883. TDI
  2884. CTD
  2885. TTD
  2886. MATD
  2887. .ce 1000
  2888. Call Confirmation Phase (Note\ 2)
  2889. g)
  2890. NA
  2891. NA
  2892. NA\fR 2d1+p1+(g1+g2)
  2893. .ce 0
  2894. .ce 1000
  2895. +(p2+e+p3)+
  2896. .ce 0
  2897. .LP
  2898. (g3+g4)+p4
  2899. NA
  2900. NA
  2901. f
  2902. )
  2903. p4
  2904. NA
  2905. NA\fR \(em
  2906. NA
  2907. NA
  2908. .LP
  2909. e)
  2910. NA
  2911. NA
  2912. NA\fR \(em
  2913. NA
  2914. NA
  2915. d)
  2916. NA
  2917. NA
  2918. p2\(eme\(emp3
  2919. \(em
  2920. NA
  2921. NA
  2922. .LP
  2923. c)
  2924. p2\(eme\(emp3
  2925. NA
  2926. NA\fR \(em
  2927. NA
  2928. NA
  2929. b)
  2930. NA
  2931. NA
  2932. NA
  2933. \(em
  2934. NA
  2935. NA
  2936. .LP
  2937. a)
  2938. p1
  2939. NA
  2940. NA
  2941. \(em
  2942. NA
  2943. NA
  2944. \fINote\ 1\fR \ \(em\ The calling DTE assumes d1 = d2.
  2945. \fINote\ 2\fR \ \(em\ The called DTE may have accepted the call on the 
  2946. basis of: 
  2947. .sp 1P
  2948. .ce 1000
  2949. 2d1+p1+(g1+g2)+(p2+e+p3)+2(g3+g4)+p4\(=w.
  2950. .ce 0
  2951. .sp 1P
  2952. .ce 1000
  2953. .sp 2
  2954. FIGURE\ 7\(hy5/X.301
  2955. .ce 0
  2956. .sp 1P
  2957. .ce 1000
  2958. \fBUtilization of the transit delay parameters\fR 
  2959. .ce 0
  2960. .sp 1P
  2961. .LP
  2962. .sp 2
  2963. .sp 2P
  2964. .LP
  2965. 7.1.3.4.2
  2966.     \fIThroughput\fR 
  2967. .sp 1P
  2968. .RT
  2969. .sp 1P
  2970. .LP
  2971. 7.1.3.4.2.1
  2972.     \fIThroughput class negotiation\fR (see Note)
  2973. .sp 9p
  2974. .RT
  2975. .LP
  2976.     \fINote\fR \ \(em
  2977.     Different terms exist for this facility:
  2978. .LP
  2979.     The present term is as denoted in Recommendations\ X.2, X.25 and
  2980. X.75.
  2981. .LP
  2982.     Recommendation X.213 uses the term \*Qthroughput\*U.
  2983. .LP
  2984.     Recommendation X.140 uses the term \*QUser information transfer
  2985. rate\*U.
  2986. .LP
  2987.     Recommendation Q.931 uses the term \*QInformation rate\*U.
  2988. .bp
  2989. .sp 1P
  2990. .LP
  2991. 7.1.3.4.2.1.1
  2992.     \fIGeneral\fR 
  2993. .sp 9p
  2994. .RT
  2995. .PP
  2996. Throughput class negotiation is an optional user facility that
  2997. permits negotiation on a per call basis of the throughput classes. The
  2998. throughput classes are considered independently for each direction of data
  2999. transmission.
  3000. .PP
  3001. Default values are agreed between the DTE and the Administration (see \(sc\ 
  3002. 7.1.3.4.2.3). The default values correspond to the maximum throughput classes 
  3003. which may be associated with any virtual call at the DTE/DCE interface. 
  3004. .PP
  3005. This facility corresponds with the target QOS parameter (see
  3006. \(sc\ 7.1.3.3) for throughput.
  3007. .RT
  3008. .sp 1P
  3009. .LP
  3010. 7.1.3.4.2.1.2
  3011.     \fIThroughput definition\fR 
  3012. .sp 9p
  3013. .RT
  3014. .PP
  3015. The throughput parameter is defined in Recommendation X.140 (under the 
  3016. term user information transfer rate). 
  3017. .PP
  3018. Throughput is signalled in bits per second. Provisionally, the
  3019. throughput value negotiated for a call, is achieved, as measured over the
  3020. lifetime of the call, in 95% of all cases (calls) during busy hour conditions. 
  3021. Details are for further study. 
  3022. .RT
  3023. .sp 1P
  3024. .LP
  3025. 7.1.3.4.2.1.3
  3026.     \fICall request and call confirmation phases\fR 
  3027. .sp 9p
  3028. .RT
  3029. .PP
  3030. When the calling DTE has subscribed to the \fIthroughput class\fR 
  3031. \fInegotiation\fR facility, it may request the throughput classes of the 
  3032. virtual 
  3033. call in the call request phase for both directions of data transmission. If
  3034. particular throughput classes are not explicitly requested, the DCE will 
  3035. assume that the default values were requested for both direction of data 
  3036. transmission.
  3037. .PP
  3038. When a called DTE has subscribed to the \fIthroughput class negotiation\fR 
  3039. facility, the throughput classes from which DTE negotiation may start will 
  3040. be indicated to the called DTE during the call request phase. These throughput 
  3041. classes are less than or equal to the ones selected at the calling DTE/DCE
  3042. interface, either explicitly, or by default if the calling DTE has not
  3043. subscribed to the \fIthroughput class negotiation\fR facility or has not 
  3044. explicitly requested throughput class values in the call request phase. 
  3045. These throughput classes indicate to the called DTE will also not be higher 
  3046. than the default 
  3047. throughput classes, respectively for each direction of data transmission, at
  3048. the calling and the called DTE/DCE interfaces. They may be further constrained 
  3049. by internal limitations of the network. 
  3050. .PP
  3051. The called DTE may request with a facility in the call confirmation
  3052. phase the throughput classes that should finally apply to the virtual call. 
  3053. The only valid throughput classes in the call confirmation phase are lower 
  3054. than or equal to the ones (respectively) indicated to the call DTE in the 
  3055. call request phase. If the called DTE does not make any throughput class 
  3056. facility request in the call confirmation phase, the throughput classes 
  3057. finally applying to the 
  3058. virtual call will be the ones indicated to the caller DTE in the call request 
  3059. phase. 
  3060. .PP
  3061. If the called DTE has not subscribed to the \fIthroughput class\fR 
  3062. \fInegotiation\fR facility, the throughput classes finally applying to 
  3063. the virtual call are less than or equal to the ones selected at the calling 
  3064. DTE/DCE 
  3065. interface, and less than or equal to the default values defined at the 
  3066. called DTE/DCE interface. 
  3067. .PP
  3068. When the calling DTE has subscribed to the \fIthroughput class\fR 
  3069. \fInegotiation\fR facility, the call confirmation phase of each call will 
  3070. indicate the throughput classess finally applying to the call. 
  3071. .PP
  3072. When neither calling DTE nor called DTE has subscribed to the
  3073. \fIthroughput class negotiation\fR facility, the throughput classes applying 
  3074. to the virtual call will not be higher than the ones agreed as defaults 
  3075. at the calling and called DTE/DCE interfaces. They may be further constrained 
  3076. to lower values by the network, e.g.\ for international service. 
  3077. .PP
  3078. In the case of internetwork calls, any DSE, including the DSEs
  3079. associated with the originating and destination networks, may reduce, but 
  3080. not raise, the throughput class values requested in the call request phase. 
  3081. Thus, the throughput classes from which the negotiation may start with 
  3082. the called DTE will be indicated to the DSE\(hyassociated with the destination 
  3083. network. 
  3084. .bp
  3085. .PP
  3086. If particular throughput classes are not explicitly requested, the
  3087. DSE is assumed to request the default throughput class values agreed between
  3088. both Administrations.
  3089. .PP
  3090. When the called DTE has accepted the call, the DSE associated with the 
  3091. destination network may convey, in the call confirmation phase, the throughput 
  3092. class values that finally apply to the call following the negotiation with 
  3093. the called DTE. 
  3094. .PP
  3095. If particular throughput classes are not explicitly confirmed, the DSE 
  3096. is assumed to confirm the default class values agreed between both 
  3097. Administrations.
  3098. .PP
  3099. \fINote\fR \ \(em\ In the process of determination as whether or not to 
  3100. reduce throughput class values by networks or by the user, different criteria 
  3101. can be envisioned, e.g.\ the resources available. For packet switched data 
  3102. transmission services, flow control parameters like window and packet size 
  3103. may affect the 
  3104. attainable throughput class.
  3105. .RT
  3106. .sp 1P
  3107. .LP
  3108. 7.1.3.4.2.1.4
  3109.     \fICall clearing phase\fR 
  3110. .sp 9p
  3111. .RT
  3112. .PP
  3113. No indication of throughput class should be present during the call clearing 
  3114. phase. 
  3115. .RT
  3116. .sp 2P
  3117. .LP
  3118. 7.1.3.4.2.2
  3119.     \fIMinimum throughput class\fR 
  3120. .sp 1P
  3121. .RT
  3122. .sp 1P
  3123. .LP
  3124. 7.1.3.4.2.2.1
  3125.     \fIGeneral\fR 
  3126. .sp 9p
  3127. .RT
  3128. .PP
  3129. Minimum throughput class is an optional user facility that permits, on 
  3130. a per call basis, conveyance of the minimum acceptable throughput 
  3131. class. The minimum throughput classes are considered independently for each
  3132. direction of data transmission.
  3133. .PP
  3134. This facility corresponds with the minimum QOS parameter (see
  3135. \(sc\ 7.1.3.3) for throughput.
  3136. .RT
  3137. .sp 1P
  3138. .LP
  3139. 7.1.3.4.2.2.2
  3140.     \fICall request and call confirmation phases\fR 
  3141. .sp 9p
  3142. .RT
  3143. .PP
  3144. The minimum throughput class parameter will be conveyed from
  3145. calling DTE to called DTE during the Call Request Phase, and can be used 
  3146. by the called DTE for comparison with the negotiated value of the throughput 
  3147. class 
  3148. negotiation parameter.
  3149. .PP
  3150. The public networks involved in the call are not required to look at or 
  3151. operate on the minimum throughput class parameter, e.g.\ for aborting the 
  3152. call; however some networks may look at the parameter if they wish.
  3153. .PP
  3154. The minimum throughput class parameter is not conveyed during the call 
  3155. confirmation phase. 
  3156. .RT
  3157. .sp 1P
  3158. .LP
  3159. 7.1.3.4.2.3
  3160.     \fIDefault throughput classes assignment\fR 
  3161. .sp 9p
  3162. .RT
  3163. .PP
  3164. \fIDefault throughput classes assignment\fR is an optional user
  3165. facility agreed for a period of time. This facility, if subscribed to, 
  3166. provides for the selection of default throughput classes from the list 
  3167. of throughput 
  3168. classes supported by the Administration. Some networks may constrain the
  3169. default throughput classes to be the same for each direction of data
  3170. transmission. In the absence of this facility, the default throughput classes 
  3171. correspond to the user class of service of the DTE (see Recommendation\ 
  3172. X.1) but does not exceed the maximum throughput class supported by the 
  3173. network. 
  3174. .PP
  3175. The default throughput classes are the maximum throughput classes
  3176. which may be associated with any call at the DTE/DCE interface. Values other
  3177. than the default throughput classes may be negotiated for a call by means of
  3178. the \fIthroughput classes negotiation\fR facility (see \(sc\ 7.1.3.4.2.1). 
  3179. Values other than the default throughput classes may be agreed for a period 
  3180. of time for each permanent virtual circuit. 
  3181. .RT
  3182. .sp 1P
  3183. .LP
  3184. 7.2
  3185.      \fIFacilities relating to the charging conditions applying to the\fR 
  3186. \fIcall\fR 
  3187. .sp 9p
  3188. .RT
  3189. .PP
  3190. The optional user facilities which are standardized for different data 
  3191. transmission services, and are related to the charging conditions applying 
  3192. to the call are shown in Table 7\(hy2/X.301. 
  3193. .bp
  3194. .RT
  3195. .ce
  3196. \fBH.T. [T5.301]\fR 
  3197. .ce
  3198. TABLE\ 7\(hy2/X.301
  3199. .ce
  3200. \fBOptional user facilities, standardized for different data\fR 
  3201. .ce
  3202. \fBtransmission services,\fR 
  3203. .ce
  3204. \fB
  3205. .ce
  3206. related to charging conditions applying to the call\fR 
  3207. .ps 9
  3208. .vs 11
  3209. .nr VS 11
  3210. .nr PS 9
  3211. .TS
  3212. center box;
  3213. cw(54p) | cw(18p) | cw(30p) | cw(24p) sw(18p) sw(24p) | cw(18p) sw(24p) sw(18p) , ^  | ^  | ^  | c | c | c | c | c | c.
  3214. Optional user facility    Period  of time    Applies  per call    T{
  3215. Applies to circuit switched data
  3216. transmission
  3217. service
  3218. T}    T{
  3219. Applies to packet switched data
  3220. transmission
  3221. service
  3222. T}
  3223.             PTSN    CSPDN    ISDN    ISDN    PSPDN    MSS
  3224. _
  3225. .T&
  3226. lw(54p) | lw(18p) | cw(30p) | lw(24p) | cw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  3227. Reverse charging        X        X        X    X    X
  3228. .T&
  3229. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  3230. Reverse charging acceptance    X            X    FS    X    X    X
  3231. .T&
  3232. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  3233. Local charging prevention    X                    X    X    X
  3234. .T&
  3235. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  3236. Charging information    X    X        X        X    X    X
  3237. _
  3238. .TE
  3239. .nr PS 9
  3240. .RT
  3241. .ad r
  3242. \fBTable 7\(hy2/X.301 [T5.301], p.\fR 
  3243. .sp 1P
  3244. .RT
  3245. .ad b
  3246. .RT
  3247. .sp 2P
  3248. .LP
  3249. 7.2.1
  3250.     \fIReverse charging and reverse charging acceptance\fR 
  3251. .sp 1P
  3252. .RT
  3253. .sp 1P
  3254. .LP
  3255. 7.2.1.1
  3256.     \fIGeneral\fR 
  3257. .sp 9p
  3258. .RT
  3259. .PP
  3260. \fIReverse charging\fR is an optional user facility that may be
  3261. requested by the user on a per\(hycall basis. It enables a calling user 
  3262. to request that the call should be charged to the called user. 
  3263. .PP
  3264. \fIReverse charging acceptance\fR is an optional user facility assigned 
  3265. to the user for an agreed contractual period. It enables the user to accept 
  3266. reverse charging calls.
  3267. .PP
  3268. \fINote 1\fR \ \(em\ The international accounting arrangements for reverse
  3269. charging calls and the consequent implications on network capabilities 
  3270. have not yet been defined. 
  3271. .PP
  3272. \fINote 2\fR \ \(em\ All requirements of the \fIreverse charging\fR and 
  3273. \fIreverse\fR \fIcharging acceptance\fR facilities have not yet been covered 
  3274. in the DTE/DCE 
  3275. interface and interexchange signalling specifications.
  3276. .RT
  3277. .sp 1P
  3278. .LP
  3279. 7.2.1.2
  3280.     \fICall set\(hyup procedure\fR 
  3281. .sp 9p
  3282. .RT
  3283. .sp 1P
  3284. .LP
  3285. 7.2.1.2.1\ \ A calling user may request reverse charging by means of a
  3286. facility request over the DTE/DCE interface.
  3287. .sp 9p
  3288. .RT
  3289. .LP
  3290.     a)
  3291.     In the case where reverse charging is allowed by the
  3292. originating network, the call control information forwarded to the succeeding 
  3293. exchange will include a \fIreverse charging request\fR indication. 
  3294. .LP
  3295.     b)
  3296.     In the case where reverse charging is not allowed by the
  3297. originating network, the call is rejected and an \fIinvalid facility request\fR 
  3298. call progress signal is returned to the calling user.
  3299. .sp 1P
  3300. .LP
  3301. 7.2.1.2.2\ \ When receiving a call including a reverse charging request
  3302. indication the destination exchange will act as follows:
  3303. .sp 9p
  3304. .RT
  3305. .LP
  3306.     a)
  3307.     In the case where the called user subscribes to the
  3308. \fIreverse charging acceptance\fR facility, the incoming call information,
  3309. including an indication that reverse charging is requested, is sent to the
  3310. called user.
  3311. .bp
  3312. .LP
  3313.     b)
  3314.      In the case where the called user does not subscribe to the \fIreverse 
  3315. charging acceptance\fR facility, the call is rejected and a \fIreverse\fR 
  3316. \fIcharging acceptance not subscribed\fR signal is sent towards the originating 
  3317. exchange.
  3318. .PP
  3319. The call may also be rejected for other reasons not related to the \fIreverse 
  3320. charging\fR or \fIreverse charging acceptance\fR facilities. 
  3321. .PP
  3322. When the incoming call information is sent to the called user, the
  3323. called user may deny establishment of the call by clearing, if the called 
  3324. user is not willing to accept reverse charging for this particular call. 
  3325. .PP
  3326. \fINote\fR \ \(em\ The DTE/DCE interface arrangements necessary in the
  3327. circuit\(hyswitched service in CSPDNs to allow the called user to deny
  3328. establishment of a reverse charging call, for example after \fIcalling line\fR 
  3329. \fIidentification\fR , have not yet been defined. The procedure chosen 
  3330. is likely to affect the network procedures for reverse charging calls. 
  3331. .RT
  3332. .sp 1P
  3333. .LP
  3334. 7.2.2
  3335.     \fILocal charging prevention\fR 
  3336. .sp 9p
  3337. .RT
  3338. .PP
  3339. \fILocal charging prevention\fR is an optional user facility agreed to 
  3340. for a period of time. This user facility, when subscribed to, authorizes 
  3341. the 
  3342. DCE to prevent the establishment of calls which the subscriber must pay for
  3343. by:
  3344. .RT
  3345. .LP
  3346.     a)
  3347.     not transmitting to the DTE incoming calls which request the
  3348. \fIreverse charging\fR facility, and
  3349. .LP
  3350.     b)
  3351.     insuring that the charges are made to another party whenever
  3352. a call is requested by the DTE. This other party can be
  3353. determined by using any of a number of actions, both procedural
  3354. and administrative. The procedural methods include:
  3355. .LP
  3356.     \(em
  3357.     the use of reverse charging,
  3358. .LP
  3359.     \(em
  3360.      identification of a third party using the \fInetwork\fR \fIuser identification\fR 
  3361. facility (see \(sc\ 7.4.5). 
  3362. .PP
  3363. When the party to be charged has not been established for a call request, 
  3364. the DCE will apply \fIreverse charging\fR to this call. 
  3365. .PP
  3366. \fINote\fR \ \(em\ For an interim period of time, some networks may choose to
  3367. enforce local charging prevention by clearing the call when the party to be
  3368. charged has not been established.
  3369. .RT
  3370. .sp 1P
  3371. .LP
  3372. 7.2.3
  3373.     \fICharging information\fR 
  3374. .sp 9p
  3375. .RT
  3376. .PP
  3377. \fICharging information\fR is an optional user facility which may be
  3378. either agreed for a period of time or requested by the DTE for a given call.
  3379. .PP
  3380. If the DTE is the DTE to be charged, the DTE can request the
  3381. \fIcharging information\fR facility on a per call basis by means of an 
  3382. appropriate facility request in the call request phase or call confirmation 
  3383. phase. 
  3384. .PP
  3385. If a DTE subscribes to the \fIcharging information\fR facility for a
  3386. contractual period, the facility is in effect for the DTE, whenever the 
  3387. DTE is the DTE to be charged, without sending the facility request in a 
  3388. call request phase or call confirmation phase. 
  3389. .PP
  3390. During the call clearing phase, the DCE will send to the charged DTE information 
  3391. about the charge for that call and/or other information which makes it 
  3392. possible for the user to calculate the charge. 
  3393. .PP
  3394. The charging information parameter may be expressed in any of the
  3395. following measures: monetary unit, distance, segment count, call duration.
  3396. .RT
  3397. .sp 1P
  3398. .LP
  3399. 7.3
  3400.      \fIFacilities relating to specific routing conditions requested by\fR 
  3401. \fIthe user of the call\fR 
  3402. .sp 9p
  3403. .RT
  3404. .PP
  3405. The optional user facilities which are standardized for different data 
  3406. transmission services, and are related to specific routing conditions 
  3407. requested by the user of the call are shown in Table\ 7\(hy3/X.301.
  3408. .bp
  3409. .RT
  3410. .ce
  3411. \fBH.T. [T6.301]\fR 
  3412. .ce
  3413. TABLE\ 7\(hy3/X.301
  3414. .ce
  3415. \fBOptional user facilities, standardized for different data\fR 
  3416. .ce
  3417. \fBtransmission services,\fR 
  3418. .ce
  3419. \fBrelated to specific routing conditions requested by the user of\fR 
  3420. .ce
  3421. \fBthe call\fR 
  3422. .ps 9
  3423. .vs 11
  3424. .nr VS 11
  3425. .nr PS 9
  3426. .TS
  3427. center box;
  3428. cw(54p) | cw(18p) | cw(30p) | cw(24p) sw(18p) sw(24p) | cw(18p) sw(24p) sw(18p) , ^  | ^  | ^  | c | c | c | c | c | c.
  3429. Optional user facility    Period  of time    Applies  per call    T{
  3430. Applies to circuit switched data
  3431. transmission
  3432. service
  3433. T}    T{
  3434. Applies to packet switched data
  3435. transmission
  3436. service
  3437. T}
  3438.             PTSN    CSPDN    ISDN    ISDN    PSPDN    MSS
  3439. _
  3440. .T&
  3441. lw(54p) | cw(18p) | lw(30p) | lw(24p) | cw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  3442. Redirection of calls    X            X        X    X    X
  3443. .T&
  3444. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  3445. Deflection of calls        X                X    X    X
  3446. .T&
  3447. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  3448. Hunt group    X            X        X    X    X
  3449. .T&
  3450. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  3451. RPOA selection    X    X        X    FS    X ?    X    X
  3452. .T&
  3453. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  3454. T{
  3455. Called line address modified notification
  3456. T}        X                X    X    X
  3457. .T&
  3458. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  3459. T{
  3460. Call redirection or deflection notification
  3461. T}        X        X        X    X    X
  3462. _
  3463. .TE
  3464. .nr PS 9
  3465. .RT
  3466. .ad r
  3467. \fBTable 7\(hy3/X.301 [T6.301], p.\fR 
  3468. .sp 1P
  3469. .RT
  3470. .ad b
  3471. .RT
  3472. .sp 2P
  3473. .LP
  3474. 7.3.1
  3475.     \fIRedirection of calls\fR 
  3476. .sp 1P
  3477. .RT
  3478. .sp 1P
  3479. .LP
  3480. 7.3.1.1
  3481.     \fIGeneral\fR 
  3482. .sp 9p
  3483. .RT
  3484. .PP
  3485. \fIRedirection of calls\fR is an optional user facility assigned to the 
  3486. user for an agreed contractual period. 
  3487. .PP
  3488. The facility enables a user to have calls to his address redirected to 
  3489. a predetermined address. 
  3490. .PP
  3491. In the case of circuit\(hyswitched service in CSPDNs this shall apply to 
  3492. all calls to the address. In the case of packet\(hyswitched data transmission 
  3493. service in PSPDNs and ISDNs, this shall apply to calls which encounter the
  3494. out\(hyof\(hyorder condition, or optionally other conditions, such as number 
  3495. busy. 
  3496. .PP
  3497. Provision of the facility and registration of the address to which
  3498. calls are to be redirected is controlled by the Administration.
  3499. .PP
  3500. It is for further study whether or not a facility is required to allow 
  3501. user control of the address registered to which calls are to be redirected. 
  3502. .PP
  3503. Depending on the possiblities offered by the Administration, facility activation 
  3504. and deactivation may be made: 
  3505. .RT
  3506. .LP
  3507.     a)
  3508.     by the user by means of user controlled activation and
  3509. deactivation procedures;
  3510. .LP
  3511.     b)
  3512.     by the network at predetermined times;
  3513. .LP
  3514.     c)
  3515.     by the Administration or Recognized Private Operating Agency
  3516. (RPOA) on request of the user;
  3517. .LP
  3518.     d)
  3519.     by the Administration when providing and withdrawing the
  3520. \fIredirection of calls\fR facility from the address.
  3521. .PP
  3522. User controlled procedures for inquiry of the status of the
  3523. facility (i.e.\ whether the facility is activated or deactivated) may also be
  3524. provided.
  3525. .bp
  3526. .PP
  3527. For international calls, redirection may only be made within the
  3528. destination network. Some Administrations may allow redirection between
  3529. networks within the destination country. In general, a call may only be
  3530. redirected once. However, some Administrations may provide for multiple
  3531. redirections of a call in the packet\(hyswitched data transmission service in
  3532. PSPDNs and ISDNs.
  3533. .PP
  3534. The basic service is limited to one call redirection. In addition,
  3535. some networks may offer either one of the following (mutually exclusive)
  3536. capabilities. In the case where DTE\ A is the calling DTE, and DTE\ B is
  3537. originally called DTE:
  3538. .RT
  3539. .LP
  3540.     1)
  3541.     A list of alternate DTE's (C1, C2, .\|.\|.) is stored by the
  3542. network of DTE\ B. Consecutive attempts of call redirection are
  3543. tried to each of these addresses, in the order of the list, up
  3544. to the completion of the call.
  3545. .LP
  3546.     2)
  3547.     Call redirections may be logically chained; if DTE C has
  3548. subscribed to call redirection to DTE\ D, a call redirected from
  3549. DTE\ B to DTE\ C may be redirected to DTE\ D; call redirections and
  3550. call deflections may also be chained.
  3551. .PP
  3552. In any case, networks will ensure that loops are avoided and that the \fICall 
  3553. Request\fR Phase has a limited duration, consistent with a DTE time 
  3554. limit.
  3555. .PP
  3556. The \fIredirection of call\fR facility will not violate the integrity
  3557. of the \fIclosed user group\fR facility.
  3558. .PP
  3559. For the packet switched networks, when the call is redirected, the
  3560. called address of the alternate DTE and the \fIcalled line address modified\fR 
  3561. \fInotification\fR facility, indicating the reason why the called address is
  3562. different from the one originally requested will be indicated to the calling
  3563. DTE during the call confirmation phase or call clearing phase (see \(sc\ 
  3564. 7.3.5). 
  3565. .PP
  3566. When the call is redirected, some networks may indicate to the
  3567. alternate DTE the reason for redirection and the address of the orignally
  3568. called DTE, using the \fIcall redirection notification\fR facility in the call
  3569. request phase (see \(sc\ 7.3.6).
  3570. .PP
  3571. The order of call set\(hyup processing at the originally called DCE as
  3572. well as the alternate DCE will be according to the sequence of call progress
  3573. signals in Table\ 1/X.96. For those networks that provide systematic call
  3574. redirection with the prior request of the called DTE, the systematic call
  3575. redirection request will have the highest priority in the call set\(hyup
  3576. processing sequence at the originally called DCE.
  3577. .PP
  3578. It is for further study whether there is a need for an optional user facility 
  3579. for the calling DTE to indicate whether or not it is permitted to 
  3580. redirect calls originated by this DTE.
  3581. .RT
  3582. .sp 2P
  3583. .LP
  3584. 7.3.1.2
  3585.      \fICall set\(hyup procedure for circuit switched data transmission\fR 
  3586. \fIservices in CSPDNs\fR 
  3587. .sp 1P
  3588. .RT
  3589. .sp 1P
  3590. .LP
  3591. 7.3.1.2.1
  3592.     \fICalls not involving other facilities affecting the procedure\fR 
  3593. .sp 9p
  3594. .RT
  3595. .PP
  3596. Information that a user has the \fIredirection of calls\fR facility
  3597. activated is stored, together with the redirection address, at the exchange 
  3598. to which the user is connected. When such a user is called, the call is 
  3599. set up to the redirection address in accordance with the following. 
  3600. .RT
  3601. .sp 1P
  3602. .LP
  3603. 7.3.1.2.1.1
  3604.     \fIThe redirection address is at the same exchange\fR 
  3605. .sp 9p
  3606. .RT
  3607. .PP
  3608. In this case the destination exchange connects the call to the
  3609. redirection address and returns the \fIredirected call\fR signal unless 
  3610. the call is rejected for one of the reasons indicated below. When receiving 
  3611. the 
  3612. \fIredirected call\fR signal, the originating exchange sends the corresponding 
  3613. call progress signal to inform the calling user that the call has been 
  3614. redirected. 
  3615. .PP
  3616. In the case, where the user at the redirection address also has the
  3617. \fIredirection of calls\fR facility activated, the destination exchange 
  3618. rejects the call and returns the \fIaccess barred\fR call progress signal. 
  3619. The call may also be rejected for other reasons (e.g.\ number busy) in 
  3620. accordance with the ordinary procedures. 
  3621. .bp
  3622. .RT
  3623. .sp 1P
  3624. .LP
  3625. 7.3.1.2.1.2
  3626.     \fIThe redirection address is at another exchange\fR 
  3627. .sp 9p
  3628. .RT
  3629. .sp 1P
  3630. .LP
  3631. 7.3.1.2.1.2.1\ \ In this case, the call is set up to the redirection address 
  3632. in accordance with one of the following procedures depending on the 
  3633. arrangements in the destination network.
  3634. .sp 9p
  3635. .RT
  3636. .LP
  3637. 7.3.1.2.1.2.2\ \ The following procedure is based on the principle that 
  3638. the call is released back within the destination network and then set up 
  3639. to the new 
  3640. destination exchange. In the case of an international call, it is released 
  3641. back to the incoming gateway exchange. In the case of a national call, 
  3642. it is 
  3643. released back to the originating exchange. This procedure can be supported 
  3644. by common channel signalling Recommendation\ X.61. The means necessary 
  3645. to support this procedure are not defined in Recommendations\ X.70 and 
  3646. X.71. 
  3647. .LP
  3648.     i)
  3649.      The first destination exchange returns the \fIredirection\fR \fIrequest\fR 
  3650. signal together with the redirection address towards 
  3651. the controlling exchange (i.e.\ the incoming gateway or
  3652. originating exchange).
  3653. .LP
  3654.     ii)
  3655.     In the case of an international call, the incoming gateway
  3656. exchange upon receipt of the \fIredirection request\fR signal, set
  3657. up a new forward connection to the redirection address. The call
  3658. control information forwarded includes a \fIredirected call\fR indication. 
  3659. The forward connection to the first redirection 
  3660. exchange is released.
  3661. .LP
  3662.     iii)
  3663.     In the case of a national call, the originating exchange
  3664. acts in accordance with\ ii).
  3665. .LP
  3666.     iv)
  3667.     Upon receipt of the redirected call, the new destination
  3668. exchange connects the call or rejects the call in accordance
  3669. with \(sc\ 7.3.1.2.1.1. The forward \fIredirected call\fR indication
  3670. received by the new destination exchange is used to prevent
  3671. further redirection.
  3672. .LP
  3673.     v)
  3674.     In the case where the call is connected to the redirection
  3675. address, the originating exchange will receive the
  3676. \fIredirected call\fR signal. It then sends the \fIredirected call\fR 
  3677. call progress signal to inform the calling user that the call
  3678. has been redirected.
  3679. .sp 1P
  3680. .LP
  3681. 7.3.1.2.1.2.3\ \ The following procedure is based on the principle that the
  3682. connection is extended forward from the first destination exchange to the 
  3683. new destination exchange. This procedure can be supported by common channel 
  3684. signalling and decentralized signalling in accordance with Recommendation\ 
  3685. X.61, and Recommendations\ X.70 and\ X.71 respectively. 
  3686. .sp 9p
  3687. .RT
  3688. .LP
  3689.     i)
  3690.     The first destination exchange sets up the forward
  3691. connection to the redirection address. The call control
  3692. information forwarded will include a \fIredirected call\fR indication.
  3693. .LP
  3694.     ii)
  3695.     Upon receipt of the redirected call, the new destination
  3696. exchange connects or rejects the call in accordance with
  3697. \(sc\ 7.3.1.2.1.1. The received \fIredirected call\fR indication is
  3698. used to prevent further redirection.
  3699. .LP
  3700. \fI\fR     iii)
  3701.     In the case where the call is connected to the redirection
  3702. address, the originating exchange will receive a \fIredirected\fR 
  3703. \fIcall\fR signal. It then sends the \fIredirected call\fR call
  3704. progress signal to inform the calling user that the call has
  3705. been redirected.
  3706. .sp 1P
  3707. .LP
  3708. 7.3.1.2.2
  3709.     \fICalls involving a closed user group facility\fR 
  3710. .sp 9p
  3711. .RT
  3712. .PP
  3713. Redirected calls are subject to the restrictions applying for the closed 
  3714. user group (CUG) facilities. 
  3715. .RT
  3716. .LP
  3717.     a)
  3718.     In the case where the call is a CUG call, or the originally
  3719. called user has a CUG facility, the call is rejected before
  3720. redirection unless the validation check requirements applicable
  3721. for the CUG facility concerned are satisfied.
  3722. .LP
  3723.     b)
  3724.     In the case where the call is a CUG call, or the user at the
  3725. redirection address has a CUG facility, the call is rejected
  3726. unless the validation check requirements applicable for the CUG
  3727. facility concerned are satisfied.
  3728. .LP
  3729.     c)
  3730.     In the case where:
  3731. .LP
  3732.     i)
  3733.     the call is a CUG call, and
  3734. .LP
  3735.     ii)
  3736.     the redirection address is at an exchange other than
  3737. the first destination exchange, and
  3738. .LP
  3739.     iii)
  3740.     the procedure for setting up the call to the
  3741. redirection address is in accordance with \(sc\ 7.3.1.2.1.2
  3742. (i.e.\ the call is released back), the first destination exchange
  3743. has to send the CUG information received (e.g.\ the CUG call
  3744. indication, and the interlock code) back to the controlling
  3745. exchange together with the \fIredirected call\fR signal and the
  3746. redirection address to enable the controlling exchange to
  3747. include this CUG information in the call control information
  3748. sent on the new forward connection.
  3749. .bp
  3750. .sp 1P
  3751. .LP
  3752. 7.3.1.2.3
  3753.     \fIThe calling user has the called line identification facility\fR 
  3754. .sp 9p
  3755. .RT
  3756. .PP
  3757. In the case where a call from a user that has the \fIcalled line\fR 
  3758. \fIidentification\fR facility is redirected, the called line identity sent 
  3759. to the calling user is the data number of the redirection address. 
  3760. .RT
  3761. .sp 2P
  3762. .LP
  3763. 7.3.2
  3764.     \fIDeflection of calls\fR 
  3765. .sp 1P
  3766. .RT
  3767. .sp 1P
  3768. .LP
  3769. 7.3.2.1
  3770.     \fIGeneral\fR 
  3771. .sp 9p
  3772. .RT
  3773. .PP
  3774. \fIDeflection of calls\fR is an optional user facility assigned to the 
  3775. user for an agreed contractual period. 
  3776. .PP
  3777. The facility enables a user to deflect incoming calls to another
  3778. address on a per call basis for use on a packet switched virtual call service.
  3779. .PP
  3780. Upon reception of an incoming call request the originally called DTE responds 
  3781. with a clearing request including address of the DTE to which the call 
  3782. is to be deflected (i.e.\ data transfer phase never takes place between 
  3783. the 
  3784. calling DTE and originally called DTE). The network will consequently initiate 
  3785. an incoming call on the DTE interface to which the call is deflected. 
  3786. .PP
  3787. For international calls, deflection may only be made within the
  3788. destination network. Some Administrations may allow redirection between
  3789. networks within the destination country. In general, a call may only be
  3790. deflected once. However, some Administrations may provide for multiple
  3791. deflections of a call in the packet switched data transmission service in
  3792. PSPDNs and ISDNs.
  3793. .PP
  3794. The basic service is limited to one call deflection. In addition, in some 
  3795. networks call deflections and call redirections may be logically chained. 
  3796. .PP
  3797. In this case, networks will ensure that loops are avoided and that the 
  3798. call request phase has a limited duration, consistent with a DTE time limit. 
  3799. .PP
  3800. The \fIdeflection of call\fR facility will not violate the integrity of
  3801. the \fIclosed user group\fR facility.
  3802. .PP
  3803. For the packet\(hyswitched networks, when the call is deflected, the
  3804. called address of the alternate DTE and the \fICalled line address modified\fR 
  3805. \fInotification\fR facility, indicating the reason why the called address is
  3806. different from the one originally requested will be indicated to the calling
  3807. DTE during the call confirmation phase or call clearing phase (see \(sc\ 
  3808. 7.3.5). 
  3809. .PP
  3810. When the call is deflected, some networks may indicate to the
  3811. alternate DTE the reason for redirection and the address of the originally
  3812. called DTE, using the \fIcall redirection\fR or \fIdeflection notification\fR 
  3813. facility in the call request phase (see \(sc\ 7.3.6). 
  3814. .PP
  3815. It is for further study whether there is a need for an optional user facility 
  3816. for the calling DTE to indicate whether or not it is permitted to 
  3817. deflect calls originated by this DTE.
  3818. .RT
  3819. .sp 2P
  3820. .LP
  3821. 7.3.3
  3822.     \fIHunt group\fR 
  3823. .sp 1P
  3824. .RT
  3825. .sp 1P
  3826. .LP
  3827. 7.3.3.1
  3828.     \fIGeneral\fR 
  3829. .sp 9p
  3830. .RT
  3831. .PP
  3832. The \fIhunt group\fR facility is an optional user facility which
  3833. distributes incoming calls containing a hunt group address across the available 
  3834. DTE/DCE interfaces associated with the facility. 
  3835. .PP
  3836. Once a call is assigned to a DTE/DCE interface, the call is treated as 
  3837. a regular call. 
  3838. .PP
  3839. Calls originated on a DTE/DCE interface belonging to the hunt group
  3840. are handled as normal calls.
  3841. .PP
  3842. \fINote\ 1\fR \ \(em\ One or more addresses may be associated with the 
  3843. facility. If more than one address is associated with the facility, the 
  3844. selection 
  3845. procedure is performed irrespective of the particular called address.
  3846. .bp
  3847. .PP
  3848. \fINote\ 2\fR \ \(em\ A specific address may be assigned to each DTE/DCE
  3849. interface associated with a hunt group. Calls placed directly to these
  3850. specific addresses are treated normally (no distribution of calls). When
  3851. distribution has been performed, and a specific address has been assigned in
  3852. each DTE/DCE interface associated with the hunt group, this address should 
  3853. be returned to the calling DTE (as called line identification) together 
  3854. with an 
  3855. indicator indicating why the called line identification is different from 
  3856. the original called address. 
  3857. .RT
  3858. .sp 1P
  3859. .LP
  3860. 7.3.3.2
  3861.     \fICall set\(hyup procedure\fR 
  3862. .sp 9p
  3863. .RT
  3864. .PP
  3865. When receiving an incoming call having a hunt group address, the
  3866. destination exchange performs the selection of DTE/DCE interface, if there 
  3867. is at least one idle circuit/channel available for incoming calls on any 
  3868. of the 
  3869. DTE/DCE interfaces in the group.
  3870. .PP
  3871. When calls are placed to a hunt group address, in the case specific
  3872. addresses have also been assigned to the individual DTE/DCE interfaces,
  3873. information is transferred to the calling DTE which contains:
  3874. .RT
  3875. .LP
  3876.     1)
  3877.     the called address of the selected DTE/DCE interface, and
  3878. .LP
  3879.     2)
  3880.      the reason why the called address is different from the one originally 
  3881. requested. 
  3882. .PP
  3883. The exact arrangement is for further study.
  3884. .PP
  3885. For packet switching virtual call service, \fIcalled line address\fR 
  3886. \fImodified notification\fR facility is used for this purpose.
  3887. .PP
  3888. Some networks may apply call subscription time user facilities, common 
  3889. to all DTE/DCE interfaces in the hunt group, place a limit on the number 
  3890. of 
  3891. DTE/DCE interfaces in the hunt group, and/or constrain the size of the
  3892. geographic region that can be served by a single hunt group.
  3893. .RT
  3894. .sp 2P
  3895. .LP
  3896. 7.3.4
  3897.     \fIRPOA selection\fR 
  3898. .sp 1P
  3899. .RT
  3900. .sp 1P
  3901. .LP
  3902. 7.3.4.1
  3903.     \fIGeneral\fR 
  3904. .sp 9p
  3905. .RT
  3906. .PP
  3907. This facility is an optional user facility which may be either
  3908. agreed for a period of time or requested by a DTE on a per call basis for 
  3909. use on either circuit switched or packet\(hyswitched virtual call services. 
  3910. .PP
  3911. In the countries that have more than one RPOA transit network, there is 
  3912. a requirement for a user facility which, when requested, allows the calling 
  3913. DTE to select either one or a sequence of more than one RPOA transit network(s) 
  3914. within the originating country. In the case of international calls, this 
  3915. facility, when requested, allows the calling DTE to select a particular
  3916. international RPOA within the country of that calling DTE.
  3917. .PP
  3918. \fINote\fR \ \(em\ The procedure for selection of multiple RPOAs is not yet
  3919. specified in the circuit switching interface Recommendations.
  3920. .RT
  3921. .sp 1P
  3922. .LP
  3923. 7.3.4.2
  3924.     \fICall set\(hyup procedure\fR 
  3925. .sp 9p
  3926. .RT
  3927. .PP
  3928. A user in a network providing the RPOA selection facility may
  3929. request selection of a particular, or a sequence of more than one RPOA 
  3930. transit network within the originating country, either for an agreed period 
  3931. of time 
  3932. or on a per call basis by a facility request including the NI(s) (see
  3933. Recommendation\ X.302) identifying the RPOA transit network(s) selected.
  3934. .PP
  3935. In the case where a calling user request selection of one or more RPOA 
  3936. transit network(s), the originating network will route the call to the 
  3937. gateway exchange of the first RPOA transit network selected. In the case 
  3938. where the call is routed via one or more transit exchanges within the originating 
  3939. network, an RPOA selection request indication and the DNIC(s) identifying 
  3940. the RPOA transit network(s) requested will be included in the internal 
  3941. network call control 
  3942. information forwarded by the originating exchange. In a similar manner, 
  3943. if the calling user selects a sequence of transit networks, the first transit 
  3944. network shall route the call to the gateway exchange of the second RPOA 
  3945. transit 
  3946. network. Furthermore, the sequence of DNICs identifying the RPOAs selected 
  3947. by the user will be passed across the internetwork interface. Pending further 
  3948. study, the facility/utility used to provide this information is subject to
  3949. bilateral agrement between the connecting transit networks.
  3950. .PP
  3951. The call control information sent over the international network will be 
  3952. as for an ordinary call and will not contain any \fIRPOA selection\fR related 
  3953. information.
  3954. .bp
  3955. .PP
  3956. In the case where the selected RPOA transit network cannot accept the call, 
  3957. due to, for example, congestion or network failures, the call is rejected 
  3958. by the gateway exchange and an \fIRPOA out\(hyof\(hyorder\fR signal is 
  3959. returned towards the originating exchange which sends the corresponding 
  3960. call progress signal to the calling user. 
  3961. .RT
  3962. .sp 1P
  3963. .LP
  3964. 7.3.5
  3965.     \fICalled line address modified notification\fR 
  3966. .sp 9p
  3967. .RT
  3968. .PP
  3969. Called line address modified notification is an optional user
  3970. facility used by the DCE in the call confirmation or call clearing phase to
  3971. inform the calling DTE as to why the called address in this phase is different 
  3972. from that specified by the calling DTE in the call request phase. 
  3973. .PP
  3974. When more than one address applies to a DTE/DCE interface, the called line 
  3975. address modified notification facility may be used by the responding DTE 
  3976. in the call clearing phase (when the call is rejected) or in the call 
  3977. confirmation phase, when the called address is presented by the responding 
  3978. DTE and different from that indicated to the DTE in the call request phase. 
  3979. When 
  3980. this facility is received from the responding DTE:
  3981. .RT
  3982. .LP
  3983.     1)
  3984.     The DCE will clear the call if the called address is not one
  3985. of those applying to the interface.
  3986. .LP
  3987.     2)
  3988.     If call redirection has taken place in the PDN or ISDN, the
  3989. DCE will replace the reason contained in the \fIcalled line\fR \fIaddress 
  3990. modified notification\fR facility with the reason 
  3991. reflecting the status of the originally called DTE; otherwise,
  3992. the reason is passed transparently.
  3993. .LP
  3994.     \fINote\fR \ \(em\ The DTE should be aware that a modification of any
  3995. part of the called DTE addresses field without notification by
  3996. the \fIcalled line address modified notification\fR facility may
  3997. cause the call to be cleared.
  3998. .PP
  3999. The following reasons can be indicated with the use of the
  4000. \fIcalled line address modified notification\fR facility in \fIcall confirmation\fR 
  4001. phase or \fIclearing\fR phase and transmitted to the calling DTE:
  4002. .LP
  4003.     1)
  4004.     Call distribution with a hunt group,
  4005. .LP
  4006.     2)
  4007.     Call redirection due to originally called DTE out of order,
  4008. .LP
  4009.     3)
  4010.     Call redirection due to originally called DTE busy,
  4011. .LP
  4012.     4)
  4013.     Call redirection due to prior request from the originally
  4014. called DTE for systematic call redirection,
  4015. .LP
  4016.     5)
  4017.     Called DTE originated, or
  4018. .LP
  4019.     6)
  4020.     Call reflection by the originally called DTE.
  4021. .PP
  4022. In \fIcall conformation\fR or \fIclearing\fR phases, the reason indicated 
  4023. by the responding DTE in conjunction with the use of the \fIcalled line 
  4024. access\fR \fImodified notification\fR facility should be \*QDTE originated\*U. 
  4025. .sp 1P
  4026. .LP
  4027. 7.3.6
  4028.     \fICall redirection or call deflection notification\fR 
  4029. .sp 9p
  4030. .RT
  4031. .PP
  4032. \fICall redirection\fR or \fIdeflection notification\fR is an optional 
  4033. user facility, used by the DCE in the call request phase to inform the 
  4034. alternate DTE that the call has been redirected or deflected, why the call 
  4035. was redirected and the address of the originally called DTE. 
  4036. .PP
  4037. The following reasons can be indicated with the \fIcall redirection\fR 
  4038. or \fIdeflection notification\fR facility: 
  4039. .RT
  4040. .LP
  4041.     1)
  4042.     Call redirection due to originally called DTE out of order.
  4043. .LP
  4044.     2)
  4045.     Call redirection due to originally called DTE busy,
  4046. .LP
  4047.     3)
  4048.     Call redirection due to prior request from the originally
  4049. called DTE for systematic call redirection,
  4050. .LP
  4051.     4)
  4052.     Call deflection by the originally called DTE, or
  4053. .LP
  4054.     5)
  4055.     Call distribution within a hunt group.
  4056. .bp
  4057. .sp 1P
  4058. .LP
  4059. 7.4
  4060.      \fIFacilities related to protection mechanisms requested by the\fR \fIuser 
  4061. of the call\fR 
  4062. .sp 9p
  4063. .RT
  4064. .PP
  4065. The optional user facilities which are standardized for different data 
  4066. transmission services and are related to protection mechanisms requested 
  4067. by the user of the call are shown in Table\ 7\(hy4/X.310. 
  4068. .RT
  4069. .LP
  4070. .sp 6
  4071. .ce
  4072. \fBH.T. [T7.301]\fR 
  4073. .ce
  4074. TABLE\ 7\(hy4/X.301
  4075. .ce
  4076. \fBOptional user facilities, standardized for different data\fR 
  4077. .ce
  4078. \fBtransmission services,\fR 
  4079. .ce
  4080. \fBrelated to protection mechanisms requested by the user of the call\fR 
  4081. .ps 9
  4082. .vs 11
  4083. .nr VS 11
  4084. .nr PS 9
  4085. .TS
  4086. center box;
  4087. cw(54p) | cw(18p) | cw(30p) | cw(24p) sw(18p) sw(24p) | cw(18p) sw(24p) sw(18p) , ^  | ^  | ^  | c | c | c | c | c | c.
  4088. Optional user facility    Period  of time    Applies  per call    T{
  4089. Applies to circuit switched data
  4090. transmission
  4091. service
  4092. T}    T{
  4093. Applies to packet switched data
  4094. transmission
  4095. service
  4096. T}
  4097.             PTSN    CSPDN    ISDN    ISDN    PSPDN    MSS
  4098. _
  4099. .T&
  4100. lw(54p) | lw(18p) | lw(30p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) .
  4101. CUG related facilities:                                
  4102. .T&
  4103. lw(54p) | cw(18p) | lw(30p) | lw(24p) | cw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4104. \(em CUG     X            X        X    X    X
  4105. .T&
  4106. lw(54p) | cw(18p) | lw(30p) | lw(24p) | cw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4107. T{
  4108. \(em
  4109. CUG with outgoing access 
  4110. T}    X            X        X    X    X
  4111. .T&
  4112. lw(54p) | cw(18p) | lw(30p) | lw(24p) | cw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4113. T{
  4114. \(em
  4115. CUG with incoming access 
  4116. T}    X            X        X    X    X
  4117. .T&
  4118. lw(54p) | cw(18p) | lw(30p) | lw(24p) | cw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4119. T{
  4120. \(em
  4121. Incoming calls barred within a CUG
  4122. T}    X                    X    X    X
  4123. .T&
  4124. lw(54p) | cw(18p) | lw(30p) | lw(24p) | cw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4125. T{
  4126. \(em
  4127. Outgoing calls barred within a CUG
  4128. T}    X                    X    X    X
  4129. .T&
  4130. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4131. \(em CUG selection         X (Note)        X        X    X    X
  4132. .T&
  4133. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4134. T{
  4135. \(em
  4136. CUG with outgoing access selection
  4137. T}        X (Note)            FS    X    X    X
  4138. .T&
  4139. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4140. T{
  4141. Bilateral CUG related facilities:
  4142. T}                                
  4143. .T&
  4144. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4145. \(em Bilateral CUG    X            X        X    X    X
  4146. .T&
  4147. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4148. T{
  4149. \(em
  4150. Bilateral CUG with outgoing access
  4151. T}    X            X        X    X    X
  4152. .T&
  4153. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4154. \(em Bilateral CUG selection        X (Note)                X    X    X
  4155. .T&
  4156. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4157. Incoming calls barred    X            X        X    X    X
  4158. .T&
  4159. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4160. Outgoing calls barred    X            X        X    X    X
  4161. .T&
  4162. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4163. NUI    X    X (Note)                X    X    X
  4164. .T&
  4165. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  4166. NUI override permission        X (Note)                X    X    T{
  4167. X
  4168. \fIRemarque\fR
  4169. \ \(em\ These facilities cannot be used unless the corresponding
  4170. facilities are agreed for a period of time.
  4171. .parag
  4172. T}
  4173. _
  4174. .TE
  4175. .nr PS 9
  4176. .RT
  4177. .ad r
  4178. \fBTable 7\(hy4/X.301 [T7.301], p.\fR 
  4179. .sp 1P
  4180. .RT
  4181. .ad b
  4182. .RT
  4183. .LP
  4184. .bp
  4185. .sp 2P
  4186. .LP
  4187. 7.4.1
  4188.     \fIClosed user group\fR 
  4189. .sp 1P
  4190. .RT
  4191. .sp 1P
  4192. .LP
  4193. 7.4.1.1
  4194.     \fIGeneral\fR 
  4195. .sp 9p
  4196. .RT
  4197. .PP
  4198. The closed user group (CUG) facilities enable users to form groups with 
  4199. different combinations of restrictions for access from or to users having 
  4200. one or more of these facilities. The following CUG facilities are all optional 
  4201. user facilities that are assigned to the user for an agreed contracted 
  4202. period (see Note\ 1): 
  4203. .RT
  4204. .LP
  4205.     a)
  4206.     \fIClosed user group\fR \ \(em\ this is the basic facility that
  4207. enables a user to belong to one or more CUGs;
  4208. .LP
  4209.     b)
  4210.     \fIClosed user group with outgoing access\fR \ \(em\ this is an
  4211. extension to a) which also enables the user to make outgoing calls to the 
  4212. open part of the network, and to DTEs having the incoming access capability 
  4213. [see\ c) below]; 
  4214. .LP
  4215.     c)
  4216.      \fIClosed user group with incoming access\fR \ \(em\ this is a variant 
  4217. of\ a) which also enables the user to receive incoming calls from the open 
  4218. part of the network, and from DTEs having the outgoing access capability 
  4219. [see\ b) 
  4220. above];
  4221. .LP
  4222.     d)
  4223.      \fIIncoming calls barred within the closed user group\fR \ \(em\ this 
  4224. is a supplementary facility to\ a), b) or\ c) which, when used, applies 
  4225. per user per CUG; 
  4226. .LP
  4227.     e)
  4228.      \fIOutgoing calls barred within the closed user group\fR \ \(em\ this 
  4229. is a supplementary facility to\ a), b) or\ c) which, when used, applies 
  4230. per user per CUG; 
  4231. .PP
  4232. A user may belong to one or more CUGs. In the case where the user belongs 
  4233. to only one CUG, and the \fIclosed user group\fR facility is subscribed 
  4234. to, it becomes the preferential CUG of that user. In the case where the 
  4235. user 
  4236. belongs to more than one CUG, and the closed user group facility is subscribed 
  4237. to, one of these CUGs is nominated as the preferential CUG of that user. 
  4238. .PP
  4239. Each user belonging to at least one CUG has subscribed to either the \fIclosed 
  4240. user group\fR facility or one of both of the closed user groups with 
  4241. outgoing access and the closed user group with incoming access. When the 
  4242. closed user group with outgoing access and/or the \fIclosed user group 
  4243. with incoming\fR \fIaccess\fR facility is subscribed to, the DTE may choose 
  4244. whether or not to have a preferential CUG. 
  4245. .PP
  4246. For each CUG to which a user belongs, either or none of the
  4247. supplementary facilities incoming calls barred within the closed user group 
  4248. or outgoing calls barred within the closed user group facilities may apply 
  4249. for 
  4250. that user. Different combinations of CUG facilities may apply for different
  4251. users belonging to the same CUG.
  4252. .PP
  4253. The realization of the CUG facilities is done by the provision of
  4254. interlock codes and is based on various validation checks at call set\(hyup,
  4255. determining whether or not a requested call to or from a user having a CUG
  4256. facility is allowed. In particular, a validation check is performed by
  4257. verification that both the calling and called users belong to the same 
  4258. CUG as indicated by interlock codes. 
  4259. .PP
  4260. Membership of closed user groups is controlled by the Administration or 
  4261. RPOA in conjunction with user requests. Assignment of interlock codes is 
  4262. controlled by the Administration or RPOA, and cannot be controlled by the
  4263. user.
  4264. .PP
  4265. The international interlock code of an international CUG is specified in 
  4266. \(sc\ 7.4.1.3. The international interlock code expresses the international 
  4267. CUG number assigned to the CUG in accordance with the administrative rules 
  4268. defined in Recommendation\ X.180. 
  4269. .PP
  4270. The originating network identification utility specified in
  4271. Recommendation\ X.302 may be used for international CUG calls under control 
  4272. of the gateway exchange of the destination network (see \(sc\ 7.4.1.2.2). 
  4273. .PP
  4274. \fINote 1\fR \ \(em\ Outgoing access and/or incoming access applies to an
  4275. individual user and not to a specific closed user group.
  4276. .PP
  4277. \fINote 2\fR \ \(em\ The requirements in \(sc\ 7.4.1.2 include cases which 
  4278. do not 
  4279. necessarily exist in a particular network, either because the Administration
  4280. (or RPOA) has chosen not to offer the full range of CUG facility combinations 
  4281. or because some combinations are not meaningful from the user's point of 
  4282. view. 
  4283. .PP
  4284. \fINote 3\fR \ \(em\ A network should, also in the case where the \fIclosed 
  4285. user\fR \fIgroup with outgoing access\fR facility is not provided, be capable 
  4286. of supporting the signalling necessary to complete incoming calls from 
  4287. users in another 
  4288. network providing that facility.
  4289. .bp
  4290. .PP
  4291. \fINote 4\fR \ \(em\ Private networks, including several different terminals 
  4292. and types of terminals will be connected to the public data network or 
  4293. ISDN. In 
  4294. these private networks, the different terminals may belong to different 
  4295. groups internally in the private networks, and may also have a need to 
  4296. communicate 
  4297. into different CUGs in the public data network or ISDN. The option by the
  4298. private network not to have a preferential CUG when subscribing to the 
  4299. \fIclosed\fR \fIuser group with outgoing access\fR facility and/or the 
  4300. \fIclosed user group with\fR \fIincoming access\fR facility allows for 
  4301. proper interpretation of the CUG 
  4302. facilities.
  4303. .PP
  4304. The signals related to the treatment of calls in relation to CUGs are illustrated 
  4305. in Figure\ 7\(hy6/X.301 and summarized in Tables\ 7\(hy5/X.301, 7\(hy6/X.301 
  4306. and\ 7\(hy7/X.301. 
  4307. .RT
  4308. .sp 2P
  4309. .LP
  4310. 7.4.1.2
  4311.     \fICall set\(hyup procedure\fR 
  4312. .sp 1P
  4313. .RT
  4314. .sp 1P
  4315. .LP
  4316. 7.4.1.2.1
  4317.     \fIOriginating exchange\fR 
  4318. .sp 9p
  4319. .RT
  4320. .PP
  4321. The DTE/DCE interface protocol and the actions at the originating exchange 
  4322. at call set\(hyup from a user belong to a CUG depends on whether the user 
  4323. belongs to one or more CUGs and on the combination of CUG facilities that 
  4324. applies. See also Figure\ 7\(hy7/X.301.
  4325. .RT
  4326. .sp 1P
  4327. .LP
  4328. 7.4.1.2.1.1
  4329.     \fICUG selection\fR 
  4330. .sp 9p
  4331. .RT
  4332. .PP
  4333. For each CUG that a user belongs to, the interlock code assigned to the 
  4334. CUG is stored, and is associated to the user at the local exchange. In 
  4335. the case where a user belongs to more than one CUG, a selection of the 
  4336. CUG 
  4337. preferred, and thus of the corresponding interlock code, is required at call
  4338. establishment. This selection is made on the following criteria.
  4339. .PP
  4340. In the case where the calling user makes a facility request including an 
  4341. index identifying a particular CUG, this CUG is selected by the originating 
  4342. exchange. 
  4343. .PP
  4344. In the case where the calling user belongs to one or more CUGs and has 
  4345. a preferential closed user group, no facility request concerning CUG facilities 
  4346. is made in the case: 
  4347. .RT
  4348. .LP
  4349.     a)
  4350.     where the user belongs to one CUG only;
  4351. .LP
  4352.     b)
  4353.      where a user belonging to more than one CUG with or without outgoing 
  4354. access, makes a call within the preferential CUG; or 
  4355. .LP
  4356.     c)
  4357.      where a user, having the \fIclosed user group with outgoing\fR \fIaccess\fR 
  4358. facility, makes an outgoing access call, or a call within the 
  4359. preferential CUG.
  4360. .PP
  4361. A facility request is always required for a call within any CUG
  4362. other than the preferential CUG.
  4363. .RT
  4364. .LP
  4365. .rs
  4366. .sp 22P
  4367. .ad r
  4368. \fBFigure 7\(hy6/X.301, p. 18 
  4369. .sp 1P
  4370. .RT
  4371. .ad b
  4372. .RT
  4373. .LP
  4374. .bp
  4375. .ce
  4376. \fBH.T. [T8.301]\fR 
  4377. .ce
  4378. TABLE\ 7\(hy5/X.301
  4379. .ce
  4380. \fBCUG signals into the network by the originating exchange\fR 
  4381. .ce
  4382.  
  4383. .ce
  4384. \fBresulting from CUG signals\fR 
  4385. .ce
  4386. \fBby the calling DTE and subscription\fR 
  4387. .ce
  4388.  
  4389. .ce
  4390. \fBparameters of the calling DTE\fR 
  4391. .ps 9
  4392. .vs 11
  4393. .nr VS 11
  4394. .nr PS 9
  4395. .TS
  4396. center box;
  4397. lw(66p) | cw(54p) | cw(54p) | cw(54p) .
  4398. T{
  4399. Signaled by the
  4400. calling DTE
  4401. in the call
  4402. request phase
  4403. (see
  4404. Note 1)
  4405. Subscription
  4406. of the calling
  4407. DTE
  4408. T}    CUG selection facility    CUG/OA selection facility    T{
  4409. No CUG nor CUG/OA selection facility
  4410. T}
  4411. _
  4412. .T&
  4413. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4414. T{
  4415. CUG with preferential
  4416. (see Note\ 2)
  4417. T}    T{
  4418. CUG utility (CUG specified) (see Note\ 3)
  4419. T}    Not allowed (call cleared)    T{
  4420. CUG utility
  4421. (Preferential CUG)
  4422. (see Note\ 3)
  4423. T}
  4424. .T&
  4425. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4426. CUG/OA with preferential    T{
  4427. CUG/OA utility (CUG specified) (see Note\ 3)
  4428. T}    Not allowed (call cleared)    T{
  4429. CUG/OA utility (Preferential CUG)
  4430. (see Note\ 4)
  4431. T}
  4432. .T&
  4433. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4434. CUG/IA with preferential    T{
  4435. CUG utility (CUG specified) (see Note\ 3)
  4436. T}    Not allowed (call cleared)    T{
  4437. CUG utility
  4438. (Preferential CUG)
  4439. (see Note\ 3)
  4440. T}
  4441. .T&
  4442. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4443. CUG/IA/OA with preferential    T{
  4444. CUG/OA utility (CUG specified) (see Note\ 3)
  4445. T}    Not allowed (call cleared)    T{
  4446. CUG/OA utility (Preferential CUG)
  4447. (see Note\ 4)
  4448. T}
  4449. .T&
  4450. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4451. CUG/OA without preferential    T{
  4452. CUG utility (CUG specified) (see Note\ 3)
  4453. T}    T{
  4454. CUG/OA utility (CUG specified) (see Note\ 4)
  4455. T}    No CUG nor CUG/OA utility
  4456. .T&
  4457. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4458. CUG/IA without preferential    T{
  4459. CUG utility (CUG specified) (see Note\ 3)
  4460. T}    Not allowed (call cleared)    Not allowed (call cleared)
  4461. .T&
  4462. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4463. T{
  4464. CUG/IA/OA without preferential
  4465. T}    T{
  4466. CUG utility (CUG specified) (see Note\ 3)
  4467. T}    T{
  4468. CUG/OA utility (CUG specified) (see Note\ 4)
  4469. T}    No CUG nor CUG/OA utility
  4470. .T&
  4471. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4472. No CUG    Not allowed (call cleared)    Not allowed (call cleared)    T{
  4473. No CUG nor CUG/OA utility
  4474. IA\ =\ incoming access.
  4475. .line
  4476. OA\ =\ outgoing access.
  4477. .parag
  4478. \fINote\ 1\fR
  4479. \ \(em\ The inclusion of both CUG and CUG/OA selection facilities is not
  4480. allowed in the call request phase.
  4481. .parag
  4482. \fINote\ 2\fR
  4483. \ \(em\ CUG without preferential is not allowed.
  4484. .parag
  4485. \fINote\ 3\fR
  4486. \ \(em\ If outgoing calls are barred within the preferential, specified CUG or only CUG then the call is cleared.
  4487. .parag
  4488. \fINote\ 4\fR
  4489. \ \(em\ If outgoing calls are barred within the preferential, specified CUG or only CUG then only outgoing access applies. No CUG is signaled into the
  4490. network.
  4491. .parag
  4492. T}
  4493. _
  4494. .TE
  4495. .nr PS 9
  4496. .RT
  4497. .ad r
  4498. \fBTableau 7\(hy5/X.301 [T8.301], p. 19\fR 
  4499. .sp 1P
  4500. .RT
  4501. .ad b
  4502. .RT
  4503. .LP
  4504. .rs
  4505. .sp 3P
  4506. .ad r
  4507. Blanc
  4508. .ad b
  4509. .RT
  4510. .LP
  4511. .bp
  4512. .ce
  4513. \fBH.T. [T9.301]\fR 
  4514. .ce
  4515. TABLE\ 7\(hy6/X.301
  4516. .ce
  4517. \fBCUG signals into the receiving subnetwork by the receiving\fR 
  4518. .ce
  4519.  
  4520. .ce
  4521. \fBinternetwork exchange\fR 
  4522. .ce
  4523. \fBresulting from CUG signals to the\fR 
  4524. .ce
  4525.  
  4526. .ce
  4527. \fBreceiving internetwork exchange and receiving subnetwork\fR 
  4528. .ce
  4529. \fBcapabilities\fR 
  4530. .ps 9
  4531. .vs 11
  4532. .nr VS 11
  4533. .nr PS 9
  4534. .TS
  4535. center box;
  4536. lw(66p) | cw(54p) | cw(54p) | cw(54p) .
  4537. T{
  4538. Signalled to the receiving
  4539. internetwork exchange
  4540. in the call request
  4541. phase
  4542. Capabilities
  4543. of the receiving
  4544. subnetwork
  4545. T}    CUG utility    CUG/OA selection facility    T{
  4546. No CUG nor CUG/OA selection facility
  4547. T}
  4548. _
  4549. .T&
  4550. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4551. T{
  4552. No CUG nor CUG/OA utility is supported
  4553. T}    Access barred  (call cleared)    Access barred  (call cleared)    No CUG nor CUG/OA utility
  4554. .T&
  4555. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4556. T{
  4557. Only the CUG utility is supported
  4558. T}    CUG utility  (CUG specified)    T{
  4559. Access barred\|\ua\d\u)\d
  4560. (call cleared)
  4561. T}    No CUG nor CUG/OA utility
  4562. .T&
  4563. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4564. T{
  4565. Both the CUG and CUG/OA utilities are supported
  4566. T}    CUG utility  (CUG specified)    T{
  4567. CUG/OA utility
  4568. (CUG specified)
  4569. T}    T{
  4570. No CUG nor CUG/OA utility
  4571. OA\ =\ outgoing access.
  4572. .parag
  4573. \ua\d\u)\d\ This entry needs further study for alignment with Table 24/X.25,
  4574. note\ 6.
  4575. .parag
  4576. T}
  4577. _
  4578. .TE
  4579. .nr PS 9
  4580. .RT
  4581. .ad r
  4582. \fBTableau 7\(hy6/X.301 [T9.301], p. 20 
  4583. .sp 1P
  4584. .RT
  4585. .ad b
  4586. .RT
  4587. .LP
  4588. .rs
  4589. .sp 25P
  4590. .ad r
  4591. Blanc
  4592. .ad b
  4593. .RT
  4594. .LP
  4595. .bp
  4596. .ce
  4597. \fBH.T. [T10.301]\fR 
  4598. .ce
  4599. TABLE\ 7\(hy7/X.301
  4600. .ce
  4601. \fBCUG signals to the called DTE by the destination exchange\fR 
  4602. .ce
  4603.  
  4604. .ce
  4605. \fBresulting from CUG signals\fR 
  4606. .ce
  4607. \fBfrom the network and subscription\fR 
  4608. .ce
  4609.  
  4610. .ce
  4611. \fBparameters of the called DTE\fR 
  4612. .ps 9
  4613. .vs 11
  4614. .nr VS 11
  4615. .nr PS 9
  4616. .TS
  4617. center box;
  4618. lw(66p) | cw(54p) | cw(54p) | cw(54p) .
  4619. T{
  4620. Signalled from the network
  4621. to the destination
  4622. exchange in the
  4623. call request
  4624. phase
  4625. Subscription
  4626. of the called
  4627. DTE
  4628. T}    CUG utility    CUG/OA utility    No CUG nor CUG/OA utility
  4629. _
  4630. .T&
  4631. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4632. T{
  4633. CUG with preferential
  4634. (see Note\ 1)
  4635. T}    T{
  4636. CUG sel. fac.
  4637. (CUG specified)
  4638. (see Note\ 2.3.4)
  4639. T}    T{
  4640. CUG sel. fac.
  4641. (CUG specified)
  4642. (see Note\ 2.3.4)
  4643. T}    Access barred  (call cleared)
  4644. .T&
  4645. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4646. CUG/OA with preferential    T{
  4647. CUG sel. fac.
  4648. (CUG specified)
  4649. (see Note\ 2.3.4)
  4650. T}    T{
  4651. CUG sel. fac.
  4652. (CUG specified)
  4653. (see Note\ 2.3.4)
  4654. T}    Access barred  (call cleared)
  4655. .T&
  4656. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4657. CUG/IA with preferential    T{
  4658. CUG sel. fac.
  4659. (CUG specified)
  4660. (see Note\ 2.3.4)
  4661. T}    T{
  4662. CUG sel. fac.
  4663. (CUG specified)
  4664. (see Note\ 4.5.6)
  4665. T}    No CUG nor CUG/OA  sel. fac.
  4666. .T&
  4667. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4668. CUG/IA/OA with preferential    T{
  4669. CUG sel. fac.
  4670. (CUG specified)
  4671. (see Note\ 2.3.4)
  4672. T}    T{
  4673. CUG sel. fac.
  4674. (CUG specified)
  4675. (see Note\ 4.5.6)
  4676. T}    No CUG nor CUG/OA  sel. fac.
  4677. .T&
  4678. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4679. CUG/OA without preferential    T{
  4680. CUG sel. fac.
  4681. (CUG specified)
  4682. (see Note\ 2.3)
  4683. T}    T{
  4684. CUG sel. fac.
  4685. (CUG specified)
  4686. (see Note\ 2.3)
  4687. T}    Access barred  (call cleared)
  4688. .T&
  4689. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4690. CUG/IA without preferential    T{
  4691. CUG sel. fac.
  4692. (CUG specified)
  4693. (see Note\ 2.3)
  4694. T}    T{
  4695. CUG/OA sel. fac.
  4696. (CUG specified)
  4697. (see Note\ 5.6)
  4698. T}    No CUG nor CUG/OA  sel. fac.
  4699. .T&
  4700. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4701. T{
  4702. CUG/IA/OA without preferential
  4703. T}    T{
  4704. CUG sel. fac.
  4705. (CUG specified)
  4706. (see Note\ 2.3)
  4707. T}    T{
  4708. CUG/OA sel. fac.
  4709. (CUG specified)
  4710. (see Note\ 5.6)
  4711. T}    No CUG nor CUG/OA  sel. fac.
  4712. .T&
  4713. lw(66p) | lw(54p) | lw(54p) | lw(54p) .
  4714. No CUG    Access barred  (call cleared)    No CUG nor CUG/OA  sel. fac.    T{
  4715. No CUG nor CUG/OA
  4716. sel. fac.
  4717. \fINote\ 1\fR
  4718. \ \(em\ CUG without preferential is not allowed.
  4719. .parag
  4720. \fINote\ 2\fR
  4721. \ \(em\ If the CUG specified to the destination exchange is not
  4722. subscribed to by the called DTE, then the call is blocked.
  4723. .parag
  4724. \fINote\ 3\fR
  4725. \ \(em\ If incoming calls are barred within the specified CUG, then the call is blocked.
  4726. .parag
  4727. \fINote\ 4\fR
  4728. \ \(em\ If the specified CUG is the preferential CUG then the incoming call may contain no CUG nor CUG/OA facility.
  4729. .parag
  4730. \fINote\ 5\fR
  4731. \ \(em\ 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.
  4732. .parag
  4733. \fINote\ 6\fR
  4734. \ \(em\ If incoming calls are barred within the specified CUG, then Incoming Access applies; the incoming call contains no CUG nor CUG/OA selection
  4735. facility.
  4736. .parag
  4737. T}
  4738. _
  4739. .TE
  4740. .nr PS 9
  4741. .RT
  4742. .ad r
  4743. \fBTableau 7\(hy7/X.301 [T10.301], p. 21 
  4744. .sp 1P
  4745. .RT
  4746. .ad b
  4747. .RT
  4748. .LP
  4749. .rs
  4750. .sp 2P
  4751. .ad r
  4752. Blanc
  4753. .ad b
  4754. .RT
  4755. .LP
  4756. .bp
  4757. .LP
  4758. .rs
  4759. .sp 47P
  4760. .ad r
  4761. \fBFigure 7\(hy7/X.301, p. 22\fR 
  4762. .sp 1P
  4763. .RT
  4764. .ad b
  4765. .RT
  4766. .LP
  4767. .bp
  4768. .PP
  4769. In the case where the calling user belongs to one or more CUGs and
  4770. does not have a preferential closed user group, no facility request concerning 
  4771. CUG facilities is made in the case where a user having the closed user 
  4772. group 
  4773. with outgoing access facility makes an outgoing access call.
  4774. .RT
  4775. .sp 1P
  4776. .LP
  4777. 7.4.1.2.1.2
  4778.     \fICall set\(hyup from a user having the CUG or the CUG with\fR 
  4779. \fIincoming access facility\fR 
  4780. .sp 9p
  4781. .RT
  4782. .PP
  4783. The case where a user has both the \fIclosed user group with\fR 
  4784. \fIincoming access\fR and \fIclosed user group with outgoing access\fR 
  4785. facilities is 
  4786. handled in accordance with \(sc\ 7.4.1.2.1.3.
  4787. .PP
  4788. In this case, CUG selection is performed in accordance with
  4789. \(sc\ 7.4.1.2.1.1.
  4790. .PP
  4791. In the case where the \fIoutgoing calls barred within the closed user\fR 
  4792. \fIgroup\fR facility does not apply for the selected CUG, the call is set\(hyup 
  4793. at the originating exchange. The call control information forwarded to 
  4794. the next 
  4795. exchange then includes the interlock code of the selected CUG together 
  4796. with an indication that the call is a CUG call. 
  4797. .PP
  4798. In the case where the outgoing calls barred within the closed user
  4799. group facility applies for the selected CUG, the call is rejected and the
  4800. access barred call progress signal is returned to the calling user.
  4801. .RT
  4802. .sp 1P
  4803. .LP
  4804. 7.4.1.2.1.3
  4805.      \fICall set\(hyup from a user having the closed user group with\fR \fIoutgoing 
  4806. access facility\fR 
  4807. .sp 9p
  4808. .RT
  4809. .PP
  4810. In the case where the calling user subscribes to the \fIclosed user\fR 
  4811. \fIgroup with outgoing access\fR facility, and has a preferential (or only) 
  4812. CUG, 
  4813. the call is regarded as an outgoing access call and a call within the
  4814. preferential (or only) CUG.
  4815. .PP
  4816. In the case where the \fIoutgoing calls barred within the closed user\fR 
  4817. \fIgroup\fR facility does not apply for the preferential (or only) CUG, 
  4818. the call is set up at the originating exchange. The call control information 
  4819. forwarded to the next exchange then includes the interlock code of the 
  4820. preferential (or 
  4821. only) CUG together with an indication that the call is a CUG call for which
  4822. outgoing access is allowed.
  4823. .PP
  4824. \fINote\fR \ \(em\ With the above procedure it is not necessary to distinguish 
  4825. at the originating exchange between a call within a CUG and an outgoing 
  4826. access call. 
  4827. .PP
  4828. In the case where the \fIoutgoing calls barred within the closed user\fR 
  4829. \fIgroup\fR facility applies for the preferential (or only) CUG, the call 
  4830. is 
  4831. regarded as an outgoing access call. In this case the call is set up at the
  4832. originating exchange and no interlock code or CUG call indication is included 
  4833. in the call control information forwarded to the next exchange. 
  4834. .PP
  4835. In the case where the calling user subscribes to the \fIclosed user\fR 
  4836. \fIgroup with outgoing access\fR facility, and does not have a preferential 
  4837. closed user group, the call is regarded as an outgoing access call, unless 
  4838. the calling user makes a facility request identifying a particular CUG 
  4839. for the call. 
  4840. .RT
  4841. .sp 1P
  4842. .LP
  4843. 7.4.1.2.2
  4844.     \fITransit exchange\fR 
  4845. .sp 9p
  4846. .RT
  4847. .PP
  4848. With the possible exception of some gateway exchanges, each transit exchange 
  4849. set\(hyup a CUG call as an ordinary call. The information related to the 
  4850. CUG facilities received from the preceding exchange (i.e.\ an interlock 
  4851. code, a CUG call indication and possibly an indication that outgoing access 
  4852. is allowed) is forwarded to the succeeding exchange. 
  4853. .PP
  4854. In the case of an international CUG call, no special functions are
  4855. required at the gateway exchange provided that the international interlock 
  4856. code assigned to the international CUG concerned is used in the national 
  4857. network. 
  4858. However, in the case where a national interlock code other than the applicable 
  4859. international interlock code is used within a national network, interlock 
  4860. code conversion is required at the gateway (or corresponding) exchange. 
  4861. .PP
  4862. In the case where a destination network has a requirement for
  4863. identification of the originating network for CUG calls, the originating
  4864. \fInetwork identification\fR utility specified in Recommendation\ X.302 may be
  4865. employed.
  4866. .bp
  4867. .RT
  4868. .sp 1P
  4869. .LP
  4870. 7.4.1.2.3
  4871.     \fIDestination exchange\fR 
  4872. .sp 9p
  4873. .RT
  4874. .PP
  4875. At the destination exchange, a validation check of the
  4876. acceptability of a call is made where either the calling user (as indicated 
  4877. by a CUG call indication in the control information received) or the called 
  4878. user belongs to a CUG. The call is connected only in cases where the information 
  4879. received checks with the information stored at the destination exchange,
  4880. associated to the called user, as specified in the following. In cases 
  4881. where a call is rejected because of incompatible CUG information an \fIaccess 
  4882. barred\fR 
  4883. call progress signal is sent towards the calling user.
  4884. .PP
  4885. The conditions for acceptance or rejection of calls because of the CUG 
  4886. facilities are illustrated in Figure\ 7\(hy8/X.301. 
  4887. .PP
  4888. \fINote\fR \ \(em\ A call may be rejected for reasons other than those 
  4889. related to the CUG facilities. 
  4890. .RT
  4891. .sp 1P
  4892. .LP
  4893. 7.4.1.2.3.1
  4894.      \fICalls to a user having the CUG or the CUG with outgoing\fR \fIaccess 
  4895. facility\fR 
  4896. .sp 9p
  4897. .RT
  4898. .PP
  4899. The case where a user has both \fICUG with incoming access\fR and \fICUG\fR 
  4900. \fIwith outgoing access\fR facilities is handled in accordance with \(sc\ 
  4901. 7.4.1.2.3.2. 
  4902. .PP
  4903. In this case, an incoming call is accepted only when:
  4904. .RT
  4905. .LP
  4906.     a)
  4907.     it is a CUG call, including the case where outgoing access   is allowed, and
  4908. .LP
  4909.     b)
  4910.      correspondence is found between the interlock code received and an interlock 
  4911. code associated with the called user, and 
  4912. .LP
  4913.     c)
  4914.     the incoming calls barred within the closed user group
  4915. facility does not apply for the CUG identified by the interlock code
  4916. received.
  4917. .PP
  4918. If all of the above conditions are not met, the call is rejected.
  4919. .sp 1P
  4920. .LP
  4921. 7.4.1.2.3.2
  4922.     \fICalls to a user having the CUG with incoming access\fR 
  4923. \fIfacility\fR 
  4924. .sp 9p
  4925. .RT
  4926. .PP
  4927. An incoming call is accepted in the cases when:
  4928. .RT
  4929. .LP
  4930.     a)
  4931.     it is an ordinary call, or
  4932. .LP
  4933.     b)
  4934.     it is a CUG call for which outgoing access is allowed, or
  4935. .LP
  4936.     c)
  4937.     it is a CUG for which outgoing access is not allowed, and
  4938. both conditions specified in \(sc\ 7.4.1.2.3.1\ b) and\ c) apply.
  4939. .PP
  4940. In all other cases, the incoming call is rejected.
  4941. .sp 1P
  4942. .LP
  4943. 7.4.1.2.3.3
  4944.     \fICUG calls to a user not belonging to any CUG\fR 
  4945. .sp 9p
  4946. .RT
  4947. .PP
  4948. In the case where the incoming call is:
  4949. .RT
  4950. .LP
  4951.     a)
  4952.     a CUG call for which outgoing access is allowed, it is
  4953. accepted, or
  4954. .LP
  4955.     b)
  4956.     a CUG call for which outgoing access is not allowed, it is   rejected.
  4957. .sp 1P
  4958. .LP
  4959. 7.4.1.3
  4960.     \fIInternational interlock code\fR 
  4961. .sp 9p
  4962. .RT
  4963. .PP
  4964. Each international CUG is assigned a unique International CUG
  4965. Number (ICN) according to the administrative rules defined in
  4966. Recommendation\ X.180.
  4967. .PP
  4968. Each international interlock code includes:
  4969. .RT
  4970. .LP
  4971.     a)
  4972.      four binary coded decimal digits expressing the DCC plus one digit, or 
  4973. DNIC, or the country or network of the coordinating Administration or Recognized 
  4974. Private Operating Agency, i.e.\ the decimal number\ A of the 
  4975. international CUG number; and
  4976. .LP
  4977.     b)
  4978.      a 16\(hyBit code expressing in pure binary representation the value of 
  4979. the decimal number\ B of the international CUG number. 
  4980. .PP
  4981. The interlock code is transferred, DNIC/DCC portion first, in
  4982. accordance with the procedures specified by the relevant Recommendations\ 
  4983. X.61, X.70, X.71 or\ X.75. 
  4984. .PP
  4985. \fINote 1\fR \ \(em\ In some cases of signalling, all, some or none of the
  4986. leading zeros are transmitted; see Recommendations\ X.70 and\ X.71. The binary
  4987. code should then have the same meaning regardless of the number of leading
  4988. zeros.
  4989. .PP
  4990. \fINote 2\fR \ \(em\ It is for further study whether or not the accommodation 
  4991. of international CUGs with members on public networks other than PDNs 
  4992. (e.g.\ ISDNs), will require any additional arrangements for handling
  4993. international CUG interlock codes in PDNs.
  4994. .bp
  4995. .RT
  4996. .LP
  4997. .rs
  4998. .sp 47P
  4999. .ad r
  5000. \fBFigura 7\(hy8/X.301, p.\fR 
  5001. .sp 1P
  5002. .RT
  5003. .ad b
  5004. .RT
  5005. .LP
  5006. .bp
  5007. .sp 2P
  5008. .LP
  5009. 7.4.2
  5010.     \fIBilateral closed user group\fR 
  5011. .sp 1P
  5012. .RT
  5013. .sp 1P
  5014. .LP
  5015. 7.4.2.1
  5016.     \fIGeneral\fR 
  5017. .sp 9p
  5018. .RT
  5019. .PP
  5020. \fIBilateral closed user group\fR and \fIbilateral closed user group\fR 
  5021. \fIwith outgoing access\fR are optional user facilities assigned to the 
  5022. user for 
  5023. an agreed contractual period.
  5024. .PP
  5025. The \fIBilatercal Closed User Group\fR (BCUG) facility is a user facility 
  5026. that enables pairs of users to form bilateral relations allowing access 
  5027. between each other while excluding access to or from other users with which
  5028. such a relation has not been formed. A user may belong to more than one BCUG.
  5029. .PP
  5030. The \fIBilateral Closed User Group with Outgoing access\fR (BCUGOA)
  5031. facility is a user facility that enables a user to form BCUGs as with the
  5032. \fIbilateral closed user group\fR facility, but at the same time allows 
  5033. the user to access by outgoing calls open users not having the \fIbilateral 
  5034. closed user\fR 
  5035. \fIgroup\fR or \fIbilateral closed user group with outgoing access\fR facilities. 
  5036. .PP
  5037. A user may simultaneously have the \fIbilateral closed user group\fR or
  5038. \fIbilateral closed user group with outgoing access\fR facility and one 
  5039. or more of the \fIclosed user group\fR (CUG) facilities. In such cases, 
  5040. a call within a CUG is handled separately from the \fIbilateral closed 
  5041. user group\fR facility and is not regarded as an outgoing access call in 
  5042. relation to the \fIbilateral closed user\fR \fIgroup\fR facility. 
  5043. .PP
  5044. Registration and cancellation of a BCUG of two users to the
  5045. \fIbilateral closed user group\fR or \fIbilateral closed user group with 
  5046. outgoing\fR \fIaccess\fR facilities are controlled 
  5047. by the users concerned by means of automatic registration and cancellation
  5048. procedures.
  5049. .PP
  5050. The \fIbilateral closed user group\fR and \fIbilateral closed user group\fR 
  5051. \fIwith outgoing access\fR facilities, including automatic user controlled 
  5052. facility registration and cancellation, can be supported by common channel 
  5053. signalling 
  5054. (Recommendation\ X.61) for the circuit\(hyswitched data transmission service.
  5055. Decentralized signalling for the circuit\(hyswitched data transmission
  5056. (Recommendations\ X.70 and\ X.71) and for the packet\(hyswitched data transmission 
  5057. service (Recommendation\ X.75) cannot support the facilities. 
  5058. .PP
  5059. The procedures for the \fIbilateral closed user group\fR facility are
  5060. based on the mutual registration method. This method makes use of the features 
  5061. of abbreviated address calling. Thus, a user having the \fIbilateral closed\fR 
  5062. \fIuser group\fR facility uses a local index (i.e.\ an abbreviated address) 
  5063. for each remote user with which a BCUG is formed. In the exchange to which 
  5064. the user is connected, a table associated with that user is available. 
  5065. The local index used to address a remote user corresponds to a position 
  5066. in the table containing the data number (address) of the remote user, the 
  5067. local index used by that remote user to address the local user, and an 
  5068. indication (association bit) about the status of the BCUG. 
  5069. .RT
  5070. .sp 2P
  5071. .LP
  5072. 7.4.2.2
  5073.     \fIRegistration procedures\fR 
  5074. .sp 1P
  5075. .RT
  5076. .sp 1P
  5077. .LP
  5078. 7.4.2.2.1\ \ When requesting registration of a BCUG, the user\ \fIA\fR makes a
  5079. facility request including the data number\ \fIB\fR of the remote user 
  5080. and the local index\ \fIx\fR used for that user. The originating exchange 
  5081. checks whether a data 
  5082. number has been registered or not in the position corresponding to the local
  5083. index\ \fIx\fR received, in the local user\ \fIA\fR table.
  5084. .sp 9p
  5085. .RT
  5086. .LP
  5087.     a)
  5088.     In the case where a data number has not yet been registered
  5089. in position\ \fIx\fR in the user\ \fIA\fR table, the originating exchange
  5090. registers data number\ \fIB\fR in that position. The originating
  5091. exchange then sends a BCUG registration request to the
  5092. destination exchange, including a data number\ \fIB\fR as a
  5093. destination address, data number\ \fIA\fR as a source address and the
  5094. local index\ \fIx\fR 
  5095. .LP
  5096.     b)
  5097.     In the case where data number\ \fIB\fR for the remote user has
  5098. already been registered in position\ \fIx\fR in the user\ \fIA\fR table,
  5099. and its association bit has not yet been set, indicating that
  5100. registration has not yet been completed, the originating
  5101. exchange sends a BCUG registration request to the destination
  5102. exchange, including the same information as described in\ a)
  5103. above.
  5104. .LP
  5105.     c)
  5106.     In the case where data number \fIB\fR for the remote user has
  5107. already been registered in position\ \fIx\fR in the user\ \fIA\fR table
  5108. and its association bit has already been set, the originating
  5109. exchange sends the \fIregistration/cancellation confirmed\fR call
  5110. progress signal to user\ \fIA\fR .
  5111. .LP
  5112.     d)
  5113.     In the case where the data number registered in that
  5114. position is different from the data number\ \fIB\fR received, the
  5115. originating exchange sends the \fIlocal procedure error\fR call
  5116. progress signal to user\ \fIA\fR .
  5117. .bp
  5118. .sp 1P
  5119. .LP
  5120. 7.4.2.2.2\ \ When receiving the BCUG registration request, the destination
  5121. exchange checks the addressed user\ \fIB\fR table.
  5122. .sp 9p
  5123. .RT
  5124. .LP
  5125.     a)
  5126.     In the case where user \fIB\fR has already registered user\ \fIA\fR 
  5127. in a position\ \fIy\fR , where \fIy\fR is the local index used by user\ 
  5128. \fIB\fR 
  5129. for user\ \fIA\fR , and its association bit has not yet been set,
  5130. indicating that registration has not yet been completed, the
  5131. destination exchange sets the association bit and registers
  5132. local index\ \fIx\fR in that position. The destination exchange then
  5133. responds to the originating exchange with a \fIregistration\fR \fIcompleted\fR 
  5134. signal together with the local index\ \fIy\fR . 
  5135. .LP
  5136.     b)
  5137.     In the case where user \fIB\fR has already registered user \fIA\fR 
  5138. in position \fIy\fR and its association bit has already been set, the
  5139. destination exchange checks the local index registered in that
  5140. position. In the case when that local index is equal to the
  5141. local index received, the destination exchange responds to the
  5142. originating exchange as under item\ a) above.
  5143. .LP
  5144.     c)
  5145.     In the case where user \fIB\fR has not registered data
  5146. number\ \fIA\fR in any position, the destination exchange responds to
  5147. the originating exchange with a \fIregistration accepted\fR signal.
  5148. .LP
  5149.     d)
  5150.     In the case where user \fIB\fR does not subscribe to the BCUG
  5151. facility, the destination exchange responds to the originating
  5152. exchange with an \fIaccess barred\fR call progress signal.
  5153. .LP
  5154.     e)
  5155.     In the case where user \fIB\fR is not accessable by user\ A for
  5156. any other reason, the destination exchange responds to the
  5157. originating exchange with the appropriate call progress
  5158. signal.
  5159. .sp 1P
  5160. .LP
  5161. 7.4.2.2.3\ \ When receiving the response to a BCUG registration request 
  5162. from the destination exchange, the action at the originating exchange depends 
  5163. on the signal received. 
  5164. .sp 9p
  5165. .RT
  5166. .LP
  5167.     a)
  5168.     In the case where a \fIregistration completed\fR signal is
  5169. received, the originating exchange sets the association bit and
  5170. registers the local index\ \fIy\fR in position\ \fIx\fR in the user\ \fIA\fR 
  5171. table and send the \fIregistration/cancellation confirmed\fR call
  5172. progress signal confirming registration to user\ \fIA\fR .
  5173. .LP
  5174.     b)
  5175.     In the case where a \fIregistration accepted\fR signal is
  5176. received, no further registration is made at the originating
  5177. exchange and the \fIregistration/cancellation confirmed\fR call
  5178. progress signal is sent to user\ \fIA\fR .
  5179. .LP
  5180.     c)
  5181.     In the case where a signal is received indicating that BCUG
  5182. registration has been rejected by the destination exchange, the
  5183. originating exchange clears all the information in position\ \fIx\fR 
  5184. in the user\ \fIA\fR table and sends the corresponding call progress
  5185. signal to user\ \fIA\fR .
  5186. .sp 1P
  5187. .LP
  5188. 7.4.2.2.4\ \ With the above procedures, registration of a BCUG is completed
  5189. when both users concerned have requested registration of each other and have
  5190. received positive responses.
  5191. .sp 9p
  5192. .RT
  5193. .sp 2P
  5194. .LP
  5195. 7.4.2.3
  5196.     \fICancellation procedure\fR 
  5197. .sp 1P
  5198. .RT
  5199. .sp 1P
  5200. .LP
  5201. 7.4.2.3.1\ \ When requesting cancellation of a BCUG, user\ \fIA\fR makes 
  5202. a facility request, including local index\ \fIx\fR . The originating exchange 
  5203. checks the status of position\ \fIx\fR in the user\ \fIA\fR table. 
  5204. .sp 9p
  5205. .RT
  5206. .LP
  5207.     a)
  5208.     In the case where a data number is registered in
  5209. position\ \fIx\fR , the originating exchange sends a BCUG cancellation
  5210. request with data number\ \fIB\fR as address and including remote
  5211. local index\ \fIy\fR and the calling user number\ \fIA\fR . Also, the
  5212. originating exchange resets the association bit if it was set.
  5213. .LP
  5214.     b)
  5215.     In the case where no data number is registered in
  5216. position\ \fIx\fR , the originating exchange returns the
  5217. \fIregistration/cancellation confirmed\fR call progress signal to
  5218. user\ \fIA\fR .
  5219. .sp 1P
  5220. .LP
  5221. 7.4.2.3.2\ \ When receiving the BCUG cancellation request the destination
  5222. exchange checks the addressed user\ \fIB\fR table.
  5223. .sp 9p
  5224. .RT
  5225. .LP
  5226.     a)
  5227.     In the case where the data number in position \fIy\fR in
  5228. user\ \fIB\fR table is equal to the data number\ \fIA\fR received, the
  5229. destination exchange clears all information in position\ \fIy\fR .
  5230. .LP
  5231.     b)
  5232.     In all other cases, and in particular in the case where the
  5233. data number stored in position\ \fIy\fR is different from the data
  5234. number\ \fIA\fR received, the destination exchange does not alter any
  5235. information stored in the user \fIB\fR \ table.
  5236. .PP
  5237. In cases a) and b), the destination exchange sends a
  5238. \fIcancellation completed\fR signal to the originating exchange.
  5239. .bp
  5240. .sp 1P
  5241. .LP
  5242. 7.4.2.3.3\ \ When receiving the \fIcancellation completed\fR signal in 
  5243. response to a BCUG cancellation request, the originating exchange clears 
  5244. all the 
  5245. information in position\ \fIx\fR in the user\ \fIA\fR table and sends the
  5246. \fIregistration/cancellation confirmed\fR call progress signal to user\ 
  5247. \fIA\fR . 
  5248. .sp 9p
  5249. .RT
  5250. .LP
  5251. 7.4.2.3.4\ \ With the above procedure, a BCUG is cancelled when either of the
  5252. two users concerned has requested cancellation and has received the
  5253. \fIregistration/cancellation confirmed\fR call progress signal.
  5254. .PP
  5255. \fINote\fR \ \(em\ Possible implications of abnormal conditions at
  5256. cancellation may require further study.
  5257. .sp 1P
  5258. .LP
  5259. 7.4.2.4
  5260.     \fITime\(hyout supervision in registration/cancellation procedure\fR 
  5261. .sp 9p
  5262. .RT
  5263. .PP
  5264. At the originating exchange in the facility
  5265. registration/cancellation procedure, it is necessary to wait for receipt 
  5266. of the response from the destination exchange after sending a BCUG 
  5267. registration/cancellation request. The duration of such periods has to be
  5268. controlled by appropriate time\(hyouts.
  5269. .PP
  5270. The following time\(hyouts are necesary:
  5271. .RT
  5272. .LP
  5273.     T1\ \(em
  5274.     The time between the sending of the BCUG registration
  5275. request and receipt of a response in accordance with \(sc\ 7.4.2.2.
  5276. .LP
  5277.     T2\ \(em
  5278.     The time between the sending of the BCUG cancellation
  5279. request and receipt of a \fIcancellation completed\fR signal.
  5280. .PP
  5281. On expiration of time\(hyout T1 or T2, the originating exchange sends the 
  5282. \fInetwork congestion\fR call progress sinal to user\ \fIA\fR thus indicating 
  5283. that the requested registration or cancellation has failed. User\ \fIA\fR 
  5284. then has to 
  5285. repeat the request for registration or cancellation.
  5286. .PP
  5287. The value of T1 and T2 should \fI(provisionally)\fR be 5\(hy10\ seconds.
  5288. .RT
  5289. .sp 2P
  5290. .LP
  5291. 7.4.2.5
  5292.     \fICall set\(hyup procedure\fR 
  5293. .sp 1P
  5294. .RT
  5295. .sp 1P
  5296. .LP
  5297. 7.4.2.5.1
  5298.     \fIOriginating exchange\fR 
  5299. .sp 9p
  5300. .RT
  5301. .sp 1P
  5302. .LP
  5303. 7.4.2.5.1.1\ \ When making a call within a BCUG, the calling user\ \fIA\fR 
  5304. uses the local index\ \fIx\fR as address for the called user (in accordance 
  5305. with the 
  5306. procedure for the abbreviated address calling facility). The originating
  5307. exchange checks the position corresponding to the local index\ \fIx\fR 
  5308. registered in the calling user\ \fIA\fR table. 
  5309. .sp 9p
  5310. .RT
  5311. .LP
  5312.     a)
  5313.     In the case where the association bit is set, indicating
  5314. that the BCUG is registered by both the calling and called users, the
  5315. originating exchange sets up the call towards the destination exchange, 
  5316. using the called user data number\ \fIB\fR stored in the calling user\ 
  5317. \fIA\fR table. The call control information forwarded by the originating 
  5318. exchange includes an 
  5319. indication that the call is a BCUG call.
  5320. .LP
  5321.     b)
  5322.      In the case where the association bit is not set, indicating that the 
  5323. BCUG is not completely registered, the originating exchange rejects 
  5324. the call and sends the \fIaccess barred\fR call progress signal to the calling
  5325. user.
  5326. .sp 1P
  5327. .LP
  5328. 7.4.2.5.1.2\ \ In the case where a user having the \fIbilateral closed user\fR 
  5329. \fIgroup\fR facility makes a call with an ordinary data number or an abbreviated 
  5330. address not registered as a BCUG, the originating exchange rejects the 
  5331. call and sends \fIaccess barred\fR call progress signal to the calling 
  5332. user. 
  5333. .sp 9p
  5334. .RT
  5335. .PP
  5336. \fINote\fR \ \(em\ In the case where the user also belongs to a closed 
  5337. user group (CUG), calls within a CUG are handled independently and are 
  5338. not rejected because of the \fIbilateral closed user group\fR facility. 
  5339. .sp 1P
  5340. .LP
  5341. 7.4.2.5.1.3\ \ In the case where a user having the \fIbilateral closed user\fR 
  5342. \fIgroup with outgoing access\fR facility makes a call with an ordinary 
  5343. data number or an abbreviated address not registered as a BCUG, the call 
  5344. is handled as an outgoing acces call and is set up by the originating exchange 
  5345. in accordance 
  5346. with ordinary call set up procedure.
  5347. .sp 9p
  5348. .RT
  5349. .LP
  5350. 7.4.2.5.1.4\ \ The possibility of transfer of the local index\ \fIx\fR (in the
  5351. forward direction) and local index\ \fIy\fR (in the backward direction) and the
  5352. possibility of additional verification checks at the destination exchange 
  5353. are for further study. 
  5354. .bp
  5355. .sp 1P
  5356. .LP
  5357. 7.4.2.5.2
  5358.     \fITransit exchange\fR 
  5359. .sp 9p
  5360. .RT
  5361. .PP
  5362. A transit exchange handles a BCUG call as an ordinary call.
  5363. .RT
  5364. .sp 2P
  5365. .LP
  5366. 7.4.2.5.3
  5367.     \fIDestination exchange\fR 
  5368. .sp 1P
  5369. .RT
  5370. .sp 1P
  5371. .LP
  5372. 7.4.2.5.3.1\ \ When receiving a BCUG call, the destination exchange may 
  5373. accept the call without checking whether the called user has the \fIbilateral 
  5374. closed\fR \fIuser group\fR facility. 
  5375. .sp 9p
  5376. .RT
  5377. .LP
  5378. 7.4.2.5.3.2\ \ When receiving an ordinary call (i.e.\ not a BCUG call) to a
  5379. user having the \fIbilateral closed user group\fR facility, the destination
  5380. exchange rejects the call and responds with the \fIaccess barred\fR call 
  5381. progress signal to the originating exchange. 
  5382. .LP
  5383. 7.4.2.5.3.3\ \ The call may be rejected for other reasons not related to the
  5384. \fIbilateral closed user group\fR facility. Closed user group calls can 
  5385. be accepted regardless of the above conditions, provided that the requirements 
  5386. of that 
  5387. facility are met (see \(sc\ 2).
  5388. .sp 1P
  5389. .LP
  5390. 7.4.2.5.4
  5391.     \fICombination of BCUG and line or terminal identification\fR 
  5392. \fIfacilities\fR 
  5393. .sp 9p
  5394. .RT
  5395. .PP
  5396. The possible arrangements for combinations of the \fIbilateral\fR 
  5397. \fIclosed user group\fR or \fIbilateral closed user group with outgoing 
  5398. access\fR 
  5399. facilities and the \fIcalling line dentification\fR and/or \fIcalled line\fR 
  5400. \fIidentification\fR facilities and the form of calling or called DTE
  5401. identification of BCUG calls are for further study.
  5402. .RT
  5403. .sp 1P
  5404. .LP
  5405. 7.4.3
  5406.     \fIIncoming calls barred\fR 
  5407. .sp 9p
  5408. .RT
  5409. .PP
  5410. \fIIncoming call barred\fR is an optional user facility agreed for a
  5411. period of time. This facility applies to all calls used at the DTE/DCE
  5412. interface.
  5413. .PP
  5414. This facility, if subscribed to, prevents incoming calls from being
  5415. presented to the DTE. The DTE may originate outgoing calls.
  5416. .PP
  5417. \fINote\fR \ \(em\ Some Administrations may provide a capability that also
  5418. allows a call to be presented to the DTE only in cases where the called 
  5419. address is the address of the calling DTE. 
  5420. .RT
  5421. .sp 1P
  5422. .LP
  5423. 7.4.4
  5424.     \fIOutgoing calls barred\fR 
  5425. .sp 9p
  5426. .RT
  5427. .PP
  5428. \fIOutgoing calls barred\fR is an optional user facility agreed for a period 
  5429. of time. This facility applies to all calls used at the DTE/DCE 
  5430. interface.
  5431. .PP
  5432. This user facility, if subscribed to, prevents the DCE from accepting outgoing 
  5433. calls from the DTE. The DTE may receive incoming calls. 
  5434. .RT
  5435. .sp 1P
  5436. .LP
  5437. 7.4.5
  5438.     \fINetwork User Identification\fR 
  5439. .sp 9p
  5440. .RT
  5441. .PP
  5442. \fINetwork User Identification\fR is an optional user facility agreed for 
  5443. a period of time. This facility, if subscribed to, enables the DTE to 
  5444. provide information to the network for billing, security or network management 
  5445. purpose on a per call basis. This information may be provided by the calling 
  5446. DTE in the call request phase or by the called DTE in the call confirmation
  5447. phase. It may be used whether or not the DTE has also subscribed to the 
  5448. \fIlocal\fR \fIcharging prevention\fR facility (see \(sc\ 7.2.2). If the 
  5449. DCE determines that the 
  5450. network user identifier is valid or not present when required by the network, 
  5451. it will clear the call. 
  5452. .PP
  5453. Network user identification is never transmitted to the remote DTE.
  5454. The calling DTE address transmitted to the remote DTE in the calling DTE
  5455. address field should not be inferred from the network user identification
  5456. transmitted by the DTE in the \fIcall request\fR phase.
  5457. .PP
  5458. The contents and format of the NUI parameter is a national matter.
  5459. .PP
  5460. Use of this feature between networks is subject to bilateral agreement 
  5461. between Administrations. 
  5462. .bp
  5463. .RT
  5464. .sp 1P
  5465. .LP
  5466. 7.4.6
  5467.     \fINUI override permission facility\fR 
  5468. .sp 9p
  5469. .RT
  5470. .PP
  5471. The \fINUI override permission\fR facility is an optional user facility 
  5472. agreed to for a period of time. This facility, if subscribed to, permits 
  5473. an NUI facility, presented in the call request phase, to invoke features 
  5474. subscribed to by the DTE identified by that NUI and associated with the 
  5475. NUI. Facilities 
  5476. associated with the NUI shall override facilities which may apply to the
  5477. interface. This override does not apply to existing calls or subsequent 
  5478. calls on the interface. It remains in effect for the duration of the particular 
  5479. call to which it applies. 
  5480. .PP
  5481. The optional subscription facilities that may be associated with an
  5482. NUI are a national matter.
  5483. .RT
  5484. .sp 1P
  5485. .LP
  5486. 7.5
  5487.      \fIFacilities to convey user data in addition to the normal data\fR \fIflow 
  5488. in the data transfer phase\fR 
  5489. .sp 9p
  5490. .RT
  5491. .PP
  5492. \fINote\fR \ \(em\ Different terms exist; in general \*Quser data\*U is 
  5493. used in X\(hyseries Recommendations, and \*Quser\(hyto\(hyuser information\*U 
  5494. is used in I\(hyseries 
  5495. Recommendations.
  5496. .RT
  5497. .sp 1P
  5498. .LP
  5499. 7.5.1
  5500.     \fIGeneral\fR 
  5501. .sp 9p
  5502. .RT
  5503. .PP
  5504. Conveyance of user data in addition to the normal data flow in the data 
  5505. transfer phase can be considered in the following phases of a 
  5506. call:
  5507. .RT
  5508. .LP
  5509.     a)
  5510.     Call request phase (calling DTE to called DTE),
  5511. .LP
  5512.     b)
  5513.     Call confirmation phase (called DTE to calling DTE),
  5514. .LP
  5515.     c)
  5516.     Call clearing phase (clearing DTE to cleared DTE).
  5517. .PP
  5518. Support of conveyance of user data during these phases is shown in Table\ 
  5519. 7\(hy8/X.301. 
  5520. .LP
  5521. .sp 3
  5522. .ce
  5523. \fBH.T. [T11.301]\fR 
  5524. .ce
  5525. TABLE\ 7\(hy8/X.301
  5526. .ce
  5527. \fBSupport by different networks to convey user data in addition\fR 
  5528. .ce
  5529.  
  5530. .ce
  5531. \fBto the normal data flow in the data transfer phase\fR 
  5532. .ps 9
  5533. .vs 11
  5534. .nr VS 11
  5535. .nr PS 9
  5536. .TS
  5537. center box;
  5538. lw(48p) | cw(42p) | cw(42p) | cw(48p) sw(48p) , ^  | ^  | ^  | c | c.
  5539. Network Phases    CSPDN or PSTN    PSPDN or MSS    ISDN
  5540.             Cicuit switched    Packet switched
  5541. _
  5542. .T&
  5543. lw(48p) | cw(42p) | cw(42p) | cw(48p) | cw(48p) .
  5544. Call request phase    No support    T{
  5545. Up to 16 octets
  5546. or
  5547. Up to 128 octets
  5548. (fast select)
  5549. T}    Up to 128 octets    T{
  5550. Up to 16 octets
  5551. or
  5552. Up to 128 octets
  5553. (fast
  5554. select)
  5555. T}
  5556. .T&
  5557. lw(48p) | cw(42p) | cw(42p) | cw(48p) | cw(48p) .
  5558. Call confirmation phase    No support    T{
  5559. Up to 128 octets
  5560. (fast select)
  5561. T}    Up to 128 octets    T{
  5562. Up to 128 octets
  5563. (fast select)
  5564. T}
  5565. .T&
  5566. lw(48p) | cw(42p) | cw(42p) | cw(48p) | cw(48p) .
  5567. Call clearing phase    No support    T{
  5568. Up to 128 octets
  5569. (fast select)
  5570. T}    Up to 128 octets    T{
  5571. Up to 128 octets
  5572. (fast select)
  5573. \fINote\fR
  5574. \ \(em\ Some networks require conveyance of an integral number of
  5575. octets.
  5576. .parag
  5577. T}
  5578. _
  5579. .TE
  5580. .nr PS 9
  5581. .RT
  5582. .ad r
  5583. \fBTable 7\(hy8/X.301 [T11.301], p.\fR 
  5584. .sp 1P
  5585. .RT
  5586. .ad b
  5587. .RT
  5588. .LP
  5589. .bp
  5590. .PP
  5591. For interworking between networks providing a different level of support 
  5592. of conveying user data in addition to the normal data flow in the data 
  5593. transfer phase, the following principles apply: 
  5594. .LP
  5595.     a)
  5596.      the objective is that in the future all networks can support conveyance 
  5597. of up to 128\ octets user data during the call request phase, call 
  5598. confirmation phase, and call clearing phase, for the provision of data
  5599. transmission services;
  5600. .LP
  5601.     b)
  5602.      in cases where conveyance of user data during these phases is requested, 
  5603. but where no support by the network is provided, an additional 
  5604. protocol mechanism, which is not operated by the network itself should be
  5605. utilized (example: the use of packet procedures over the PSTN);
  5606. .LP
  5607.     c)
  5608.     in cases where rule\ b) fails or is not provided, the data
  5609. calls will be aborted; an appropriate call progress message is returned 
  5610. to the DTE initiating the phase. 
  5611. .sp 1P
  5612. .LP
  5613. 7.5.2
  5614.     \fIFast select\fR 
  5615. .sp 9p
  5616. .RT
  5617. .PP
  5618. The optional user facilities which are standardized for different data 
  5619. transmission services, and are related to fast select are shown in 
  5620. Table\ 7\(hy9/X.301.
  5621. .RT
  5622. .LP
  5623. .sp 1
  5624. .ce
  5625. \fBH.T. [T12.301]\fR 
  5626. .ce
  5627. TABLE\ 7\(hy9/X.301
  5628. .ce
  5629. \fBOptional user facilities standardized for different data\fR 
  5630. .ce
  5631. \fBtransmission\fR 
  5632. .ce
  5633. \fBservices, related to fast select\fR 
  5634. .ps 9
  5635. .vs 11
  5636. .nr VS 11
  5637. .nr PS 9
  5638. .TS
  5639. center box;
  5640. cw(54p) | cw(18p) | cw(30p) | cw(24p) sw(18p) sw(24p) | cw(18p) sw(24p) sw(18p) , ^  | ^  | ^  | c | c | c | c | c | c.
  5641. Optional user facility    Period of time    Applies  per call    T{
  5642. Applies to circuit switched data transmission service
  5643. T}    T{
  5644. Applies to packet switched data transmission service
  5645. T}
  5646.             PSTN    CSPDN    ISDN    ISDN    PSPDN    MSS
  5647. _
  5648. .T&
  5649. lw(54p) | lw(18p) | cw(30p) | lw(24p) | lw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  5650. Fast select        X                X    X    X
  5651. .T&
  5652. lw(54p) | cw(18p) | cw(30p) | lw(24p) | lw(18p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) .
  5653. Fast select acceptance    X                    X    X    X
  5654. _
  5655. .TE
  5656. .nr PS 9
  5657. .RT
  5658. .ad r
  5659. \fBTable 7\(hy9/X.301 [T12.301], p.\fR 
  5660. .sp 1P
  5661. .RT
  5662. .ad b
  5663. .RT
  5664. .PP
  5665. .sp 1
  5666. Calling DTEs can request the \fIfast select\fR \| facility on a per call 
  5667. basis by means of an appropriate facility request in the call request phase. 
  5668. .PP
  5669. The \fIfast select\fR \| facility allows conveyance during the call request 
  5670. phase from calling DTE to called DTE of user data up to 128\ octets. 
  5671. .PP
  5672. If the \fIfast select\fR \| facility indicates \*Qno Restriction on Response\*U, 
  5673. it allows for either during the call confirmation phase or during the call 
  5674. clearing phase or during both phases the conveyance of up to 128\ octets user
  5675. data from called DTE (or clearing DTE) to calling DTE (or cleared DTE).
  5676. .PP
  5677. If the \fIfast select\fR \| facility indicates \*QRestriction on Response\*U, 
  5678. it allows no call confirmation phase and data transfer phase. However, 
  5679. it does 
  5680. allow conveyance during the call clearing phase (if initiated by the called
  5681. DTE) of up to 128\ octets from called DTE to calling DTE.
  5682. .PP
  5683. Where a calling DTE requests a \fIfast select\fR \| facility, the incoming 
  5684. call should only be delivered to the called DTE if that DTE has subscribed 
  5685. to the \fIfast select acceptance\fR \| facility (see \(sc\ 7.5.3). 
  5686. .bp
  5687. .PP
  5688. Where a calling DTE requests the \fIfast select\fR \| facility, and if 
  5689. the called DTE has subscribed to \fIfast select acceptance\fR , the \fIfast 
  5690. select\fR \| 
  5691. facility and whether or not there is a \*QRestriction on Response\*U will be
  5692. conveyed during the call request phase from calling DTE to called DTE.
  5693. .PP
  5694. If the called DTE has not subscribed to the \fIfast select acceptance\fR 
  5695. \| facility, no calls containing the \fIfast select\fR \| facility will 
  5696. be delivered to the called DTE. Such calls will be cleared by the network 
  5697. and a call progress signal \fIfast select acceptance not subscribed\fR 
  5698. will be returned to the calling DTE. 
  5699. .PP
  5700. \fINote\ 1\fR \ \(em\ For an interim period, some networks may not allow 
  5701. a DTE to transmit any user data in the call clearing phase when this phase 
  5702. is not 
  5703. initiated as a response on the call request phase.
  5704. .PP
  5705. \fINote\ 2\fR \ \(em\ The user data conveyed in addition to the normal 
  5706. data flow in the data transfer phase will not be fragmented for delivery 
  5707. across the 
  5708. DTE/DCE interface.
  5709. .PP
  5710. \fINote\ 3\fR \ \(em\ The significance of the call confirmation phase, or the
  5711. call clearing phase conveying the call progress signal DTE originated as a
  5712. direct response to the call request phase where the \fIfast select\fR \| 
  5713. facility has been used, is that the user data in the call request phase 
  5714. has been received by the called DTE. 
  5715. .RT
  5716. .sp 1P
  5717. .LP
  5718. 7.5.3
  5719.     \fIFast select acceptance\fR 
  5720. .sp 9p
  5721. .RT
  5722. .PP
  5723. \fIFast select acceptance\fR \| is an optional user facility agreed for 
  5724. a period of time. This facility, if subscribed to, authorizes the DCE to 
  5725. transmit to the called DTE incoming calls which request the \fIfast select\fR 
  5726. \| facility. In the absence of this facility, the DCE will not transmit 
  5727. to the called DTE 
  5728. incoming calls which request the \fIfast select\fR \| facility.
  5729. .RT
  5730. .sp 1P
  5731. .LP
  5732. 7.6
  5733.     \fIOther facilities\fR 
  5734. .sp 9p
  5735. .RT
  5736. .PP
  5737. The other optional user facilities which are standardized for
  5738. different data transmission services are shown in Table\ 7\(hy10/X.301.
  5739. .RT
  5740. .LP
  5741. .sp 2
  5742. .ce
  5743. \fBH.T. [T13.301]\fR 
  5744. .ce
  5745. TABLE\ 7\(hy10/X.301
  5746. .ce
  5747. \fBOther optional user facilities standardized for different data\fR 
  5748. .ce
  5749. \fBtransmission services\fR 
  5750. .ps 9
  5751. .vs 11
  5752. .nr VS 11
  5753. .nr PS 9
  5754. .TS
  5755. center box;
  5756. cw(54p) | cw(18p) | cw(30p) | cw(24p) sw(18p) sw(24p) | cw(18p) sw(24p) sw(18p) , ^  | ^  | ^  | c | c | c | c | c | c.
  5757. Optional user facility    Period  of Time    Applies  per call    T{
  5758. Applies to circuit switched data transmission service
  5759. T}    T{
  5760. Applies to Packet switched data transmission service
  5761. T}
  5762.             PSTN    CSPDN    ISDN    ISDN    PSPDN    MSS
  5763. _
  5764. .T&
  5765. lw(54p) | cw(18p) | lw(30p) | lw(24p) | cw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) .
  5766. Manual answer    X            X                
  5767. .T&
  5768. lw(54p) | cw(18p) | lw(30p) | lw(24p) | cw(18p) | lw(24p) | lw(18p) | lw(24p) | lw(18p) .
  5769. Connect when free    X            X                
  5770. .T&
  5771. lw(54p) | cw(18p) | lw(30p) | lw(24p) | cw(18p) | cw(24p) | lw(18p) | lw(24p) | lw(18p) .
  5772. Waiting allowed    X            X    FS            
  5773. .T&
  5774. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  5775. T{
  5776. Receipt confirmation selection
  5777. T}        X                X    X    X
  5778. .T&
  5779. lw(54p) | cw(18p) | cw(30p) | lw(24p) | cw(18p) | cw(24p) | cw(18p) | cw(24p) | cw(18p) .
  5780. Expedited data negotiation        X                X    X    T{
  5781. X
  5782. FS\ =\ For further study.
  5783. .parag
  5784. T}
  5785. _
  5786. .TE
  5787. .nr PS 9
  5788. .RT
  5789. .ad r
  5790. \fBTable 7\(hy10/X.301 [T13.301], p.\fR 
  5791. .sp 1P
  5792. .RT
  5793. .ad b
  5794. .RT
  5795. .LP
  5796. .bp
  5797. .sp 2P
  5798. .LP
  5799. 7.6.1
  5800.     \fIManual answer\fR 
  5801. .sp 1P
  5802. .RT
  5803. .sp 1P
  5804. .LP
  5805. 7.6.1.1
  5806.     \fIGeneral\fR 
  5807. .sp 9p
  5808. .RT
  5809. .PP
  5810. \fIManual answer\fR \| is a DTE operating mode allowed by some networks 
  5811. for the circuit\(hyswitched service in CSPDNs. DTEs operating in this mode 
  5812. may, 
  5813. when called, delay responding by the \fIcall accepted\fR \| signal. Information
  5814. indicating that a DTE operates with \fImanual answer\fR \| is stored at 
  5815. the exchange to which the user is connected. 
  5816. .RT
  5817. .sp 1P
  5818. .LP
  5819. 7.6.1.2
  5820.     \fICall establishment procedure\fR 
  5821. .sp 9p
  5822. .RT
  5823. .PP
  5824. In the case of a call to a user DTE operating with \fImanual answer\fR 
  5825. , the destination exchange sends the \fIterminal called\fR \| signal to 
  5826. the originating exchange at connection of the call. At the originating 
  5827. exchange, this results in sending of the \fIterminal called\fR \| call 
  5828. progress signal to the calling user. It also results in extending the value 
  5829. of any time\(hyout applicable to this phase of the call. 
  5830. .PP
  5831. The call is completed as an ordinary call when the \fIcall accepted\fR \|
  5832. signal is received from the called user by the destination exchange and a
  5833. signal indicating that the call has been connected is sent towards the
  5834. originating exchange. If the \fIcall accepted\fR \| signal is not received 
  5835. by the 
  5836. destination exchange within the applicable DCE time\(hyout after sending of the
  5837. \fIincoming call\fR \| signal to the called user, the call is cleared from the
  5838. destination exchange without sending any call progress type backward signal.
  5839. .PP
  5840. \fINote\fR \ \(em\ In the case where the originating network does not allow
  5841. \fImanual answer\fR \| and the called user operates with \fImanual answer\fR 
  5842. , the 
  5843. originating network may charge the calling user for the time from the receipt 
  5844. of the \fIterminal called\fR \| signal. 
  5845. .RT
  5846. .sp 2P
  5847. .LP
  5848. 7.6.2
  5849.     \fIConnect when free and waiting allowed\fR 
  5850. .sp 1P
  5851. .RT
  5852. .sp 1P
  5853. .LP
  5854. 7.6.2.1
  5855.     \fIGeneral\fR 
  5856. .sp 9p
  5857. .RT
  5858. .PP
  5859. \fIConnect when free\fR \| and \fIwaiting allowed\fR \| are optional user
  5860. facilities assigned to the user for an agreed contractual period.
  5861. .PP
  5862. A user subscribing to the \fIconnect when free\fR \| facility is assigned 
  5863. a number of waiting positions at his local exchange at which incoming calls 
  5864. received can wait when the access line(s) to the user is busy. The \fIwaiting\fR 
  5865. \fIallowed\fR \| facility enables a user calling a busy user having the 
  5866. \fIconnect when free\fR \| facility to wait for the completion of the call 
  5867. when the called user becomes free. During waiting, the connection is maintained. 
  5868. .PP
  5869. The two facilities thus provide an opportunity for users having
  5870. certain data traffic characteristics to make more efficient use of the 
  5871. network than in the ordinary case when a call to a busy user is rejected. 
  5872. .PP
  5873. Facility registration is controlled by the Administration or
  5874. Recognized Private Operating Agency.
  5875. .RT
  5876. .sp 2P
  5877. .LP
  5878. 7.6.2.2
  5879.     \fICall establishment procedure\fR 
  5880. .sp 1P
  5881. .RT
  5882. .sp 1P
  5883. .LP
  5884. 7.6.2.2.1\ \ When receiving a call to a busy user (i.e., at least one access 
  5885. line to the called user is occupied by a call in progress) having the 
  5886. \fIconnect when free\fR \| facility, the destination exchange checks the 
  5887. waiting 
  5888. positions at the called user:
  5889. .sp 9p
  5890. .RT
  5891. .LP
  5892.     a)
  5893.     in the case where a free waiting position exists the call
  5894. is placed in the queue and the \fIconnect when free\fR \| signal is
  5895. sent towards the originating exchange;
  5896. .LP
  5897.     b)
  5898.     in the case where all waiting positions the occupied the
  5899. call is rejected and the \fInumber busy\fR \| signal is sent towards
  5900. the originating exchange.
  5901. .PP
  5902. The call may be rejected for other reasons not related to the
  5903. \fIconnect when free\fR \| facility.
  5904. .bp
  5905. .sp 1P
  5906. .LP
  5907. 7.6.2.2.2\ \ The action at the originating exchange depends on whether the
  5908. calling user has the \fIwaiting allowed\fR \| facility and which signal is
  5909. received.
  5910. .sp 9p
  5911. .RT
  5912. .LP
  5913.     a)
  5914.     In the case where the \fIconnect when free\fR \| signal is
  5915. received and the calling user has the \fIwaiting allowed\fR \|
  5916. .LP
  5917. facility, the \fIconnect when free\fR \| call progress signal is
  5918. sent to the calling user. The calling user can then either wait
  5919. for completion of the call or clear the call. In the case
  5920. where the calling user chooses to wait, the connection is
  5921. maintained but is not through\(hyconnected. The normal time\(hyout
  5922. for completion of the call at the originating exchange is
  5923. inhibited. The calling user cannot make or receive another call
  5924. on the same access line during waiting.
  5925. .LP
  5926.     b)
  5927.     In the case where the \fIconnect when free\fR \| signal is
  5928. received and the calling user does not have the \fIwaiting\fR \fIallowed\fR 
  5929. \| facility, the \fInumber busy\fR \| signal is sent to the 
  5930. calling user and the call is cleared.
  5931. .LP
  5932.     c)
  5933.     In the case where the \fInumber busy\fR \| signal is received, the
  5934. \fInumber busy\fR \| call progress signal is sent to the calling
  5935. user and the call is cleared; this is also the case when
  5936. the calling user has the \fIwaiting allowed\fR \| facility.
  5937. .sp 1P
  5938. .LP
  5939. 7.6.2.2.3\ \ When an access line becomes free to the called user, the
  5940. destination
  5941. exchange connects the first call in the queue in the normal manner. A signal
  5942. indicating that the call has been connected is sent towards the originating
  5943. exchange.
  5944. .sp 9p
  5945. .RT
  5946. .LP
  5947. 7.6.2.2.4\ \ When receiving the signal indicating that the call has been
  5948. connected, the originating exchange through\(hyconnects the call in the normal
  5949. manner.
  5950. .LP
  5951. 7.6.2.2.5\ \ The waiting time will be charged. The calling user may send 
  5952. a clear request at any time to terminate the waiting which will result 
  5953. in normal 
  5954. network clearing and removal of the call from the queue. The waiting may 
  5955. also be terminated by the destination exchange in some abnormal situations 
  5956. resulting in a clearing sequence towards the calling user. 
  5957. .PP
  5958. \fINote\fR \ \(em\ The possible provision of a network time\(hyout to limit 
  5959. the waiting time is for further study. 
  5960. .sp 2P
  5961. .LP
  5962. 7.6.3
  5963.     \fIReceipt confirmation selection\fR 
  5964. .sp 1P
  5965. .RT
  5966. .sp 1P
  5967. .LP
  5968. 7.6.3.1
  5969.     \fIGeneral\fR 
  5970. .sp 9p
  5971. .RT
  5972. .PP
  5973. \fIReceipt confirmation selection\fR \| is an optional user facility that 
  5974. permits on a per call basis of whether or not the receipt of data units 
  5975. in the data transfer phase will be confirmed end\(hyto\(hyend. 
  5976. .PP
  5977. \fINote\fR \ \(em\ Realization of this facility in PSPDNs and ISDNs can be
  5978. performed by using the D\(hybit procedures (see Recommendation\ X.25).
  5979. .RT
  5980. .sp 1P
  5981. .LP
  5982. 7.6.3.2
  5983.     \fICall request phase and call confirmation phase\fR 
  5984. .sp 9p
  5985. .RT
  5986. .PP
  5987. The calling DTE may request during the call request phase
  5988. end\(hyto\(hyend acknowledgement of delivery of data units it will be transmitting 
  5989. in the data transfer phase, by setting the receipt selection parameter to
  5990. \fIend\(hyto\(hyend acknowledgement\fR . During the call request phase, 
  5991. any (part of the) network involved in the call, as well as the called DTE, 
  5992. that cannot support 
  5993. this end\(hyto\(hyend acknowledgement will set the receipt selection parameter 
  5994. to 
  5995. \*Qnon end\(hyto\(hyend acknowledgement\*U. The finally resulting value will be
  5996. applicable for the call and will be conveyed by the called DTE to the calling 
  5997. DTE during the call confirmation phase. 
  5998. .RT
  5999. .sp 1P
  6000. .LP
  6001. 7.6.3.3
  6002.     \fIData transfer phase\fR 
  6003. .sp 9p
  6004. .RT
  6005. .PP
  6006. Delivery of data units to the receiving DTE will be confirmed to
  6007. the sending DTE if the receipt confirmation parameter, conveyed in the call
  6008. confirmation phase, had the value \*Qend\(hyto\(hyend acknowledgement\*U.
  6009. .PP
  6010. \fINote\fR \ \(em\ In some cases (e.g. in PSPDNs) end\(hyto\(hyend receipt
  6011. confirmation in this phase could still be applied independent of the presence 
  6012. of the negotiation in the call request phase/call confirmation phase. However, 
  6013. definitions in Recommendation\ X.213 do also require the negotiation. 
  6014. .bp
  6015. .RT
  6016. .sp 1P
  6017. .LP
  6018. 7.6.3.4
  6019.     \fICall clearing phase\fR 
  6020. .sp 9p
  6021. .RT
  6022. .PP
  6023. No end\(hyto\(hyend acknowledgement applies to this phase.
  6024. .RT
  6025. .sp 2P
  6026. .LP
  6027. 7.6.4
  6028.     \fIExpedited data negotiation\fR 
  6029. .sp 1P
  6030. .RT
  6031. .sp 1P
  6032. .LP
  6033. 7.6.4.1
  6034.     \fIGeneral\fR 
  6035. .sp 9p
  6036. .RT
  6037. .PP
  6038. Expedited data negotiation is an optional user facility that
  6039. permits on a per call basis negotiation during the call request phase and 
  6040. call confirmation phase of whether or not expedited data transfer can be 
  6041. applied 
  6042. during the data transfer phase.
  6043. .RT
  6044. .sp 1P
  6045. .LP
  6046. 7.6.4.2
  6047.     \fICall request phase and call confirmation phase\fR 
  6048. .sp 9p
  6049. .RT
  6050. .PP
  6051. The calling DTE may request in the call request phase the
  6052. possibility to use expedited data procedures in the data transfer phase, by
  6053. setting the expedited data parameter to \*Qexpedited data\*U. During the call
  6054. request phase, any (part of the) network involved in the call, as well 
  6055. as the called DTE, that cannot support this expedited data, will set the 
  6056. expedited 
  6057. data negotiation parameter to \*Qno expedited data\*U. The finally resulting 
  6058. value will be applicable for the call and will be conveyed by the called 
  6059. DTE to the calling DTE during the call transfer phase. 
  6060. .PP
  6061. The public networks involved in the call are not required to look at or 
  6062. operate on this parameter; however some networks may look at the parameter 
  6063. if they wish. 
  6064. .RT
  6065. .sp 1P
  6066. .LP
  6067. 7.6.4.3
  6068.     \fIData transfer phase\fR 
  6069. .sp 9p
  6070. .RT
  6071. .PP
  6072. During the data transfer phase expedited data procedures can be
  6073. applied if the expedited data negotiation parameter, conveyed in the call
  6074. confirmation phase, had the value expedited data.
  6075. .PP
  6076. \fINote\fR \ \(em\ Expedited data procedures in PSPDN and ISDN(ps) can be
  6077. performed by using interrupt packet procedures.
  6078. .RT
  6079. .LP
  6080. .rs
  6081. .sp 22P
  6082. .sp 2P
  6083. .LP
  6084. \fBMONTAGE : \(sc 8 SUR LE RESTE DE CETTE PAGE\fR 
  6085. .sp 1P
  6086. .RT
  6087. .LP
  6088. .bp
  6089.