home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / troff / 6_11_04.tro < prev    next >
Encoding:
Text File  |  1991-12-13  |  101.8 KB  |  2,751 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. .sp 2P
  23. .LP
  24. \fB5\fR     \fBCircuit\(hyswitched call control procedures\fR 
  25. .sp 1P
  26. .RT
  27. .PP
  28. The call states referred to in this section cover the states
  29. perceived by the network, states perceived by the user and states which are
  30. common to both user and network. Unless specifically qualified, all states
  31. described in the following text should be understood as common (see \(sc\(sc\ 
  32. 2.1.1 
  33. and\ 2.1.2 for user and network call states respectively). An overview 
  34. diagram of call states is given in Figures\ A\(hy2/Q.931 and A\(hy3/Q.931 
  35. (Annex\ A). 
  36. .EF '%    Fascicle\ VI.11\ \(em\ Rec.\ Q.931''
  37. .OF '''Fascicle\ VI.11\ \(em\ Rec.\ Q.931    %'
  38. .PP
  39. Detailed specification and description language (SDL) diagrams for the 
  40. procedures specified in this section are contained in Figures\ A\(hy4/Q.931 
  41. through A\(hy6/Q.931. When there is an ambiguity in the narrative text, 
  42. the SDL diagrams in Figures\ A\(hy4/Q.931 through A\(hy6/Q.931 should be 
  43. used to resolve conflict. 
  44. Where the text and the SDL are in disagreement, the text should be used 
  45. as the prime source. 
  46. .PP
  47. \fINote\fR \ \(em\ This section describes the sequence of messages associated
  48. with the control of circuit\(hyswitched connections. Optional extensions 
  49. to this basic protocol and exceptions that apply in the case of packet\(hymode 
  50. connections or supplementary services are described elsewhere in this Recommendation 
  51. or in Recommendation\ Q.932\ [4]. Annex\ D also contains optional extensions 
  52. to the 
  53. .PP
  54. basic call establishment procedures defined in \(sc\ 5 for symmetric signalling. 
  55. Future enhancements to the procedures defined in \(sc\ 5 are being considered 
  56. to 
  57. obtain symmetric basic call control procedures that can be used, for example, 
  58. in PABX\(hyto\(hyPABX applications. 
  59. .PP
  60. All messages in this Recommendation may contain two types of
  61. information elements, functional and/or stimulus. Functional information
  62. elements are characterized as requiring a degree of intelligent processing 
  63. by the terminal in either their generation or analysis. Stimulus information 
  64. elements, on the other hand, are either generated as a result of single 
  65. event at the user/terminal interface or contain a basic instruction from 
  66. the network to be executed by the terminal. 
  67. .PP
  68. As a general principle, all the messages sent by the network to the
  69. user may contain a display information element whose contents may be displayed 
  70. by the terminal; the content of this information element shall be network 
  71. dependent.
  72. .PP
  73. \fINote\fR \ \(em\ Keypad facility information elements shall only be conveyed 
  74. in the direction user to network. Display information elements shall conveyed 
  75. in the direction network to user. 
  76. .PP
  77. In addition to the messages exchanged as described in the following
  78. sections, INFORMATION messages for call control may be sent by the user 
  79. or by the network only after the first response to a SETUP has been sent 
  80. or received, and before clearing of the call reference is initiated. An 
  81. INFORMATION message received in the release request state may be ignored. 
  82. .PP
  83. In order to accommodate the transfer of Layer 3 messages which exceeds 
  84. the data link layer maximum frame length (i.e.\ defined in 
  85. Recommendation\ Q.921)\ [3], a method of message segmentation and reassembly 
  86. may optionally be implemented as described in Annex\ K. Message segmentation 
  87. shall only be used where all the information comprising the unsegmented 
  88. message is 
  89. available at the time of sending the first message segment.
  90. .PP
  91. \fINote\fR \ \(em\ Message segmentation is not used to replace existing
  92. procedures where information is yet to be provided by call control, e.g.\ 
  93. digit by digit sending in overlap mode, although this may be used in addition. 
  94. Message segmentation shall only be used when the message length exceeds the
  95. value of the N201 parameter defined in Recommendation\ Q.921\ [3].
  96. .RT
  97. .sp 1P
  98. .LP
  99. 5.1
  100.     \fICall establishment at the originating interface\fR 
  101. .sp 9p
  102. .RT
  103. .PP
  104. Before these procedures are invoked, a reliable data link
  105. connection must be established between the user (TE/NT2) and the network. 
  106. All layer\ 3 messages shall be sent to the data link layer using a DL\(hyDATA\(hyREQUEST 
  107. primitive. The data link services described in Recommendations\ Q.920 
  108. (I.440)\ [45] and Q.921\ [3] are assumed.
  109. .RT
  110. .sp 1P
  111. .LP
  112. 5.1.1
  113.     \fICall request\fR 
  114. .sp 9p
  115. .RT
  116. .PP
  117. A user initiates call establishment by transferring a SETUP message across 
  118. the user\(hynetwork interface. Following the transmission of the SETUP 
  119. message, the call shall be considered by the user to be in the call initiated 
  120. state. The message shall always contain a call reference, selected according 
  121. to the procedures given in \(sc\ 4.3. In selecting a call reference, the 
  122. dummy call 
  123. reference value shall not be used. The bearer capability information element 
  124. is mandatory in the SETUP message, even in the case of overlap sending. 
  125. .bp
  126. .PP
  127. If the user knows all appropriate channels controlled by the D\(hychannel 
  128. are in use, it shall not transfer a SETUP message across the user\(hynetwork 
  129. interface. If the user does not monitor the status of channels in use, 
  130. it may send a SETUP during an all channels busy condition. In this case 
  131. the network 
  132. returns a RELEASE COMPLETE message with cause\ No.\ 34, \fIno circuit/channel\fR 
  133. \fIavailable\fR .
  134. .PP
  135. Furthermore the SETUP message may also contain all or part of the call 
  136. information (i.e.\ address and facility requests) necessary for call 
  137. establishment depending on whether en\(hybloc or overlap procedures are 
  138. being used respectively (see \(sc\ 5.1.3). 
  139. .PP
  140. If en\(hybloc sending is used, the SETUP message shall contain all the
  141. information required by the network to process the call, and, in particular,
  142. the called party address information if present, is contained as
  143. follows:
  144. .RT
  145. .LP
  146.     a)
  147.     in the called party number information element possibly
  148. completed by the called party subaddress information element; or,
  149. .LP
  150.     b)
  151.     the keypad facility information element which may also be
  152. used to convey other call information.
  153. .PP
  154. \fINote\fR \ \(em\ The support of a) is mandatory in all networks. Whether 
  155. the support of\ b) is mandatory or optional requires further study. 
  156. .PP
  157. For overlap sending, see \(sc 5.1.3.
  158. .RT
  159. .sp 1P
  160. .LP
  161. 5.1.2
  162.     \fIB\(hychannel selection \(em originating\fR 
  163. .sp 9p
  164. .RT
  165. .PP
  166. In the SETUP message, the user will indicate one of the
  167. following:
  168. .RT
  169. .LP
  170.     a)
  171.     channel is indicated, no acceptable alternative; or
  172. .LP
  173.     b)
  174.     channel is indicated, any alternative is acceptable, or,
  175. .LP
  176.     c)
  177.     any channel is acceptable.
  178. .PP
  179. If no indication is included, alternative c) is assumed. In cases a) and 
  180. b), if the indicated channel is available, the network selects it for 
  181. the call.
  182. .PP
  183. In case b), if the network cannot grant the preferred channel, it
  184. selects any other available B\(hychannel associated with the D\(hychannel. In
  185. case\ c), the network selects any available B\(hychannel associated with the
  186. D\(hychannel.
  187. .PP
  188. The selected B\(hychannel is indicated in the first message returned by 
  189. the network in response to the SETUP message (i.e.\ a SETUP ACKNOWLEDGE 
  190. or CALL PROCEEDING message). After transmitting this message, the network 
  191. shall 
  192. activate the B\(hychannel connection.
  193. .PP
  194. The user need not attach until receiving a CALL PROCEEDING/SETUP
  195. ACKNOWLEDGE/PRO
  196. GRESS/ALERTING message with the progress indicator\ No.\ 8
  197. \fIin\(hyband information or appropriate pattern is now available\fR or 
  198. progress 
  199. indication\ No.\ 1 \fIcall is not end\(hyto\(hyend ISDN; further call progress\fR 
  200. \fIinformation may be available in\(hyband\fR . Prior to this time, the 
  201. network cannot assume that the user has attached to the B\(hychannel. After 
  202. this time, the user shall be connected to the B\(hychannel, provided the 
  203. equipment does not generate local tone. Upon receipt of the CONNECT message 
  204. the user shall attach to the 
  205. B\(hychannel (if it has not already done so).
  206. .PP
  207. In case a) if the specified channel is not available, and in cases b) and 
  208. c) if no channel is available, a RELEASE COMPLETE message with cause\ No.\ 
  209. 44 \fIrequested circuit/channel not available\fR or No.\ 34 \fIno circuit/channel\fR 
  210. \fIavailable\fR , respectively, is sent by the network as described in 
  211. \(sc\ 5.3. 
  212. .RT
  213. .sp 1P
  214. .LP
  215. 5.1.3
  216.     \fIOverlap sending\fR 
  217. .sp 9p
  218. .RT
  219. .PP
  220. If overlap sending is used, the SETUP message contains
  221. either:
  222. .RT
  223. .LP
  224.     a)
  225.     no called number information; or,
  226. .LP
  227.     b)
  228.     incomplete called number information; or
  229. .LP
  230.     c)
  231.     called number information which the network cannot determine to be complete.
  232. .PP
  233. On receipt of such a SETUP message, the network starts timer T302 (the 
  234. value of timer\ T302 is specified in \(sc\ 9.1), sends a SETUP ACKNOWLEDGE 
  235. message to the user, and enters the overlap sending state. In case\ a), the
  236. network will return dial tone, if required by the tone option. In this 
  237. case it may include progress indicator\ No.\ 8 \fIin\(hyband information 
  238. or appropriate\fR 
  239. \fIpattern is now available\fR in the SETUP ACKNOWLEDGE message.
  240. .bp
  241. .PP
  242. \fINote\fR \ \(em\ Some networks which systematically provide the conventional 
  243. telephone dial tone will not generate the progress indicator when providing 
  244. the dial tone. 
  245. .PP
  246. When the SETUP ACKNOWLEDGE message is received, the user enters the
  247. overlap sending state and optionally starts timer\ T304 (the value of timer\ 
  248. T304 is specified in \(sc\ 9.2). 
  249. .PP
  250. After receiving the SETUP ACKNOWLEDGE message, the user sends the
  251. remainder of the call information (if any) in one or more INFORMATION
  252. messages.
  253. .PP
  254. The called party number information may be provided by the user as
  255. follows:
  256. .RT
  257. .LP
  258.     a)
  259.     in the called party number information element; or,
  260. .LP
  261.     b)
  262.     in the keypad facility information element,
  263. exclusively.
  264. .LP
  265. The called party number must be sent in a unique way.
  266. .PP
  267. \fINote\ 1\fR \ \(em\ The support of a) is mandatory in all networks. Whether 
  268. the support of b) is mandatory or optional requires further study. 
  269. .PP
  270. \fINote\ 2\fR \ \(em\ Besides the possible called party number [conveyed by
  271. method a) or b) as described above], the INFORMATION messages may contain
  272. additional call information (i.e.\ for supplementary services). The
  273. interpretation of the contents of keypad facility information elements is
  274. network\(hyspecific, and in accordance with the dialling plan provided to that
  275. user. It should be noted that the user shall transfer all the additional 
  276. call information (contained within the keypad facility information element) 
  277. before the network determines that the called party number (contained within 
  278. the 
  279. called party number information element or the keypad facility information
  280. element) is complete, and terminates the overlap sending procedure using the
  281. CALL PROCEEDING message as recommended in \(sc\ 5.1.5.2.
  282. .PP
  283. If, for symmetry purposes, the user employs timer T304, the user
  284. restarts timer\ T304 when each INFORMATION message is sent.
  285. .PP
  286. The call information in the message which completes the information
  287. sending may contain a \fIsending complete\fR indication, (e.g.\ the ##\ 
  288. character or, as a network option, the sending complete information element) 
  289. appropriate to the dialling plan being used. The network shall restart 
  290. timer\ T302 on the 
  291. receipt of every INFORMATION message not containing a sending complete
  292. indication.
  293. .RT
  294. .sp 1P
  295. .LP
  296. 5.1.4
  297.     \fIInvalid call information\fR 
  298. .sp 9p
  299. .RT
  300. .PP
  301. If, following the receipt of SETUP message or during overlap
  302. sending, the network determines that the call information received from the
  303. user is invalid (e.g.\ invalid number), then the network shall initiate call
  304. clearing as defined in \(sc\ 5.3 with a cause such as one of the
  305. following:
  306. .RT
  307. .LP
  308.     No. 1\ 
  309. \fIunassigned (unallocated) number\fR ;
  310. .LP
  311.     No. 3\ 
  312. \fIno route to destination\fR ;
  313. .LP
  314.     No. 22 \fInumber changed\fR ;
  315. .LP
  316.     No. 28 \fIinvalid number format (incomplete number)\fR .
  317. .sp 2P
  318. .LP
  319. 5.1.5
  320.     \fICall proceeding\fR 
  321. .sp 1P
  322. .RT
  323. .sp 1P
  324. .LP
  325. 5.1.5.1
  326.     \fICall proceeding, en\(hybloc sending\fR 
  327. .sp 9p
  328. .RT
  329. .PP
  330. If en\(hybloc sending is used (i.e. the network can determine that the 
  331. SETUP message contains all the information required from the user to establish 
  332. the call) and if the network can determine that access to the requested 
  333. service is authorized and available, the network shall: send a CALL PROCEEDING 
  334. message to the user to acknowledge the SETUP message and to indicate that 
  335. the call is being processed; and enter the outgoing call proceeding state. 
  336. When the user 
  337. receives the CALL PROCEEDING message, the user shall enter the outgoing call
  338. proceeding state.
  339. .PP
  340. Similarly, if the network determines that a requested service is not authorized 
  341. or is not available, the network shall initiate call clearing in 
  342. accordance with \(sc\ 5.3 with one of the following causes:
  343. .RT
  344. .LP
  345.     a)
  346.     No. 57 \fIbearer capability not authorized\fR ;
  347. .LP
  348.     b)
  349.     No. 58 \fIbearer capability not presently available\fR ;
  350. .LP
  351.     c)
  352.     No. 63 \fIservice or option not available, unspecified\fR ;
  353. or
  354. .LP
  355.     d)
  356.     No. 65 \fIbearer service not implemented\fR .
  357. .PP
  358. \fINote\fR \ \(em\ If a supplementary service is not authorized and is 
  359. not available, the procedure to be used is defined in the supplementary 
  360. service 
  361. control procedures.
  362. .bp
  363. .sp 1P
  364. .LP
  365. 5.1.5.2
  366.     \fICall proceeding, overlap sending\fR 
  367. .sp 9p
  368. .RT
  369. .PP
  370. If overlap sending is used following the occurrence of one of these conditions:
  371. .RT
  372. .LP
  373.     a)
  374.      the receipt by the network of a sending complete indication which the 
  375. network understands; or, 
  376. .LP
  377.     b)
  378.      analysis by the network that all call information necessary to effect 
  379. call establishment has been received. 
  380. .LP
  381. and if the network can determine that access to the requested services and
  382. supplementary service is authorized and available, the network shall: send a
  383. CALL PROCEEDING message to the user; stop timer\ T302; and enter the outgoing
  384. call proceeding state. Similarly if the network determines that a requested
  385. service or supplementary service is not authorized or is not available, the
  386. network shall initiate call clearing in accordance with \(sc\ 5.3 with 
  387. one of the following causes: 
  388. .LP
  389.     1)
  390.     No. 57 \fIbearer capability not authorized\fR ;
  391. .LP
  392.     2)
  393.     No. 58 \fIbearer capability not presently available\fR ;
  394. .LP
  395.     3)
  396.     No. 63 \fIservice or option not available, unspecified\fR ;
  397. or
  398. .LP
  399.     4)
  400.     No. 65 \fIbearer service not implemented\fR .
  401. .PP
  402. \fINote\ 1\fR \ \(em\ The CALL PROCEEDING message is sent to indicate that
  403. the requested call establishment has been initiated, and no more call
  404. establishment information will be accepted.
  405. .PP
  406. \fINote\ 2\fR \ \(em\ If a supplementary service is not authorized or is not
  407. available, the procedure to be used is defined in the supplementary service
  408. control procedures.
  409. .PP
  410. When the user receives the CALL PROCEEDING message, the user shall
  411. enter the outgoing call proceeding state. If, for symmetry purposes, the
  412. calling user employs timer\ T304, the user shall stop timer\ T304 when 
  413. the CALL PROCEEDING message is received. If, for symmetry purposes, the 
  414. calling user 
  415. employs timer\ T304 then, on expiry of T304, the user shall initiate call
  416. clearing in accordance with \(sc\ 5.3 with cause\ No.\ 102 \fIrecovery 
  417. on time\fR 
  418. \fIexpiry\fR .
  419. .PP
  420. An alerting or connect indication received from the called party will stop 
  421. timer\ T302 and cause an ALERTING or CONNECT message respectively to be 
  422. sent to the calling user. No CALL PROCEEDING message shall be sent by the
  423. network. If, for symmetry purposes, the calling user employs timer\ T304, the
  424. user shall stop timer\ T304 on receiving the ALERTING or CONNECT message.
  425. .PP
  426. At the expiration of timer T302, the network shall:
  427. .RT
  428. .LP
  429.     i)
  430.     initiate call clearing in accordance with \(sc 5.3 with
  431. cause\ No.28 \fIinvalid number format\fR (incomplete number) sent to the 
  432. calling 
  433. user and with cause\ No.102 \fIrecovery on timer expiry\fR is sent towards the
  434. called user, if the network determines that the call information is definitely 
  435. incomplete; otherwise, 
  436. .LP
  437.     ii)
  438.     send a CALL PROCEEDING message and enter the outgoing call  proceeding state.
  439. .sp 1P
  440. .LP
  441. 5.1.6
  442.     \fINotification of interworking at the originating\fR 
  443. \fIinterface\fR 
  444. .sp 9p
  445. .RT
  446. .PP
  447. During call establishment, the call may leave an ISDN environment; e.g. 
  448. because of interworking with another network, with a non\(hyISDN user, 
  449. or 
  450. with non\(hyISDN equipment within the calling or called user's premises. 
  451. When such situations occur, a progress indicator information element shall 
  452. be returned to the calling user either: 
  453. .RT
  454. .LP
  455.     a)
  456.      in an appropriate call control message when a state change is required 
  457. (SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING or CONNECT); or 
  458. .LP
  459.     b)
  460.     in the PROGRESS message when no state change is
  461. appropriate.
  462. .PP
  463. One of the following progress description values shall be included in the 
  464. PROGRESS indicator information element in the message sent to the user 
  465. (for further information, see Annex\ I): 
  466. .LP
  467.     1)
  468.     No. 1 \fIcall is not end\(hyto\(hyend ISDN; further call\fR 
  469. \fIprogress information may be available in\(hyband\fR ;
  470. .LP
  471.     2)
  472.     No. 2 \fIdestination address is non\(hyISDN\fR ;
  473. .LP
  474.     3)
  475.     No. 4 \fIcall has returned to the ISDN\fR . Call is now
  476. end\(hyto\(hyend ISDN.
  477. .bp
  478. .PP
  479. If the PROGRESS indicator information element is included in a
  480. call control message, the procedures as described in the rest of \(sc\ 
  481. 5.1 apply. If the PROGRESS indicator information element is included in 
  482. the PROGRESS 
  483. message, no state change will occur but any supervisory timers shall be
  484. stopped. In both cases, if indicated by the PROGRESS indicator information
  485. element, the user shall connect to (if not connected already) and then 
  486. monitor the B\(hychannel for further in\(hyband information. 
  487. .PP
  488. If the interface at which the progress indication originates is the
  489. point at which a call enters the ISDN environment from a non\(hyISDN environment, 
  490. one or more of the following progress indicator information elements shall 
  491. be included in the SETUP message sent to the network: 
  492. .RT
  493. .LP
  494.     i)
  495.     No. 1 \fIcall is not end\(hyto\(hyend ISDN; further call\fR 
  496. \fIprogress information may be available in\(hyband\fR ;
  497. .LP
  498.     ii)
  499.     No. 3 \fIorigination address is non\(hyISDN\fR .
  500. .sp 1P
  501. .LP
  502. 5.1.7
  503.     \fICall confirmation indication\fR 
  504. .sp 9p
  505. .RT
  506. .PP
  507. Upon receiving an indication that user alerting has been initiated at the 
  508. called address, the network shall: send an ALERTING message across the 
  509. user\(hynerwork interface of the calling address; and enter the call delivered 
  510. state. When the user receives the ALERTING message, the user: may begin an
  511. internally\(hygenerated alerting indication and shall enter the call delivered
  512. state.
  513. .RT
  514. .sp 1P
  515. .LP
  516. 5.1.8
  517.     \fICall connected\fR 
  518. .sp 9p
  519. .RT
  520. .PP
  521. Upon receiving an indication that the call has been accepted, the network 
  522. shall: send a CONNECT message across the user\(hynetwork interface to the 
  523. calling user; and enter the active state. 
  524. .PP
  525. This message indicates to the calling user that a connection has been established 
  526. through the network and stops a possible local indication of 
  527. alerting.
  528. .PP
  529. On receipt of the CONNECT message, the calling user: shall stop any
  530. user\(hygenerated alerting indications; may optionally send a CONNECT ACKNOWLEDGE 
  531. message, and shall enter the active state. The network shall not take any 
  532. action on receipt of a CONNECT ACKNOWLEDGE message when it perceives the 
  533. call to be in the active state. 
  534. .RT
  535. .sp 1P
  536. .LP
  537. 5.1.9
  538.     \fICall rejection\fR 
  539. .sp 9p
  540. .RT
  541. .PP
  542. Upon receiving an indication that the network or the called user is unable 
  543. to accept the call, the network shall initiate call clearing at the 
  544. originating user\(hynetwork interface as described in \(sc\ 5.3, using 
  545. the cause 
  546. provided by the terminating network or the called user.
  547. .RT
  548. .sp 1P
  549. .LP
  550. 5.1.10
  551.     \fITransit network selection\fR 
  552. .sp 9p
  553. .RT
  554. .PP
  555. When the transit network selection information element is present, the 
  556. call shall be processed according to Annex\ C. 
  557. .RT
  558. .sp 1P
  559. .LP
  560. 5.2
  561.     \fICall establishment at the destination interface\fR 
  562. .sp 9p
  563. .RT
  564. .PP
  565. This procedure assumes that a data link connection providing
  566. services described in Recommendation\ Q.920 (I.440)\ [3] may not exist 
  567. before the first layer\ 3 message (SETUP) is transferred across the interface. 
  568. However, 
  569. reliable data link connections must be established by each of the users
  570. (terminals and/or NT2s) at the interface before they respond to the SETUP
  571. message.
  572. .PP
  573. Permanent data link connections are not precluded, and may be
  574. recommended as a national option.
  575. .PP
  576. The SETUP message offered on a point\(hyto\(hypoint data link shall be
  577. delivered to layer\ 2 using a DL\(hyDATA\(hyREQUEST primitive. No use shall 
  578. be made of the DL\(hyUNIT\(hyDATA\(hyREQUEST primitive other than for operation 
  579. using the broadcast capability of the data link layer. 
  580. .PP
  581. The call reference contained in all messages exchanged across the
  582. user\(hynetwork interface shall contain the call reference value specified 
  583. in the SETUP message delivered by the network. In selecting a call reference, 
  584. the 
  585. dummy call reference value shall not be used.
  586. .bp
  587. .RT
  588. .sp 1P
  589. .LP
  590. 5.2.1
  591.     \fIIncoming call\fR 
  592. .sp 9p
  593. .RT
  594. .PP
  595. The network will indicate the arrival of a call at the user\(hynetwork 
  596. interface by transferring a SETUP message across the interface. This message 
  597. is sent if the network can select an idle B\(hychannel. In some circumstances 
  598. (e.g.\ provision of other bearer services \(sc\ 6), the SETUP message may 
  599. also be 
  600. sent when no B\(hychannel is idle. The number of calls presented in these
  601. circumstances may be limited.
  602. .PP
  603. In addition to the mandatory information elements, the SETUP message may 
  604. include, as required, the information elements described in \(sc\ 3.1.16 
  605. (e.g.\ display, low layer compatibility).
  606. .PP
  607. If a multipoint terminal configuration exists at the user\(hynetwork
  608. interface, this message shall be sent using a broadcast capability at the 
  609. data link layer. In this case, the SETUP message should contain the appropriate 
  610. part of the called party number as required (e.g.\ for DDI) and/or sub\(hyaddress 
  611. if 
  612. provided. However, if the network has knowledge that a single\(hypoint
  613. configuration exists at the interface, a point\(hyto\(hypoint data link 
  614. shall be used to carry the SETUP message. After sending the SETUP message, 
  615. the network starts timer\ T303. If the SETUP message was sent via a broadcast 
  616. data link, timer\ T312 shall also be started. (The values of timers\ T303 
  617. and\ T312 are specified in 
  618. \(sc\ 9.1.) The network then enters the call present state.
  619. .PP
  620. \fINote\fR \ \(em\ Timer T312 is used to supervise the retention of the call
  621. reference when the SETUP message was transmitted by a broadcast data link. 
  622. The value of timer\ T312 is such that if a network disconnect indication 
  623. is received during the call establishment phase, it maximizes the probability 
  624. that all 
  625. responding users will be released prior to release of the call reference. 
  626. Refer to \(sc\ 5.3.2\ (e) for procedures to be followed on expiry of timer\ 
  627. T312. 
  628. .PP
  629. If en\(hybloc receiving is used, the SETUP message shall contain all the 
  630. information required by the called user to process the call. In this case, 
  631. the SETUP message may contain the sending complete information element. 
  632. .PP
  633. Upon receipt of a SETUP message, the user will enter the call present  state.
  634. .PP
  635. Depending on the contents of the received message, either en\(hybloc
  636. receiving procedure (see \(sc\ 5.2.5.1) or overlap receiving procedure (see
  637. \(sc\ 5.2.4) follows. However, if the SETUP message includes the sending 
  638. complete information element, en\(hybloc receiving procedure shall follow. 
  639. Therefore, those users who support overlap receiving procedure shall recognize 
  640. the sending 
  641. complete information element.
  642. .PP
  643. \fINote\fR \ \(em\ Users supporting only the en\(hybloc receiving procedure 
  644. need 
  645. not recognize the sending complete information element and may directly 
  646. analyze the received SETUP message on the assumption that all the call 
  647. information is contained in the message. 
  648. .PP
  649. If no response to the SETUP message is received by the network before the 
  650. first expiry of timer\ T303, the SETUP message will be retransmitted and 
  651. timers\ T303 and\ T312 restarted.
  652. .PP
  653. \fINote\fR \ \(em\ In the case of overlap sending within the network, the
  654. appropriate part of the called party number as required (e.g.\ for DDI) 
  655. may also be conveyed by means of INFORMATION messages to the called user 
  656. on a 
  657. point\(hyto\(hypoint data link (see \(sc\ 5.2.4).
  658. .RT
  659. .sp 1P
  660. .LP
  661. 5.2.2
  662.     \fICompatibility checking\fR 
  663. .sp 9p
  664. .RT
  665. .PP
  666. A user receiving a SETUP message shall perform compatibility
  667. checking before responding to that SETUP message. Any reference to \*Quser\*U 
  668. in 
  669. \(sc\(sc\ 5.2.3 through\ 5.2.7 implicitly refers to a compatible user equipment. 
  670. Annex\ B defines compatibility checking to be performed by users upon receiving 
  671. a SETUP message. 
  672. .PP
  673. When the SETUP message was delivered via a broadcast data link, an
  674. incompatible user shall either:
  675. .RT
  676. .LP
  677.     a)
  678.     ignore the incoming call; or,
  679. .LP
  680.     b)
  681.     respond by sending a RELEASE COMPLETE message with
  682. cause\ No.\ 88 \fIincompatible destination\fR , and enter the Null state. 
  683. The network processes this RELEASE COMPLETE message in accordance with 
  684. \(sc\ 5.2.5.3. 
  685. .PP
  686. When the SETUP message was delivered via a point\(hyto\(hypoint data
  687. link, an incompatible user shall respond with RELEASE COMPLETE message with
  688. cause\ No.\ 88 \fIincompatible destination\fR , and enter the Null state. 
  689. The network shall process this RELEASE COMPLETE message in accordance with 
  690. \(sc\ 5.2.5.3. 
  691. .bp
  692. .sp 2P
  693. .LP
  694. 5.2.3
  695.     \fIB\(hychannel selection \(em destination\fR 
  696. .sp 1P
  697. .RT
  698. .sp 1P
  699. .LP
  700. 5.2.3.1
  701.     \fISETUP message\fR \fIdelivered by point\(hyto\(hypoint data link\fR 
  702. .sp 9p
  703. .RT
  704. .PP
  705. When the SETUP message is delivered by a point\(hyto\(hypoint data link, 
  706. negotiation for the selection of a B\(hychannel will be permitted between 
  707. the 
  708. network and the user. Only B\(hychannels controlled by the same D\(hychannel 
  709. will be the subject of the selection procedure. The selection procedure 
  710. is as 
  711. follows:
  712. .RT
  713. .LP
  714.     a)
  715.     In the SETUP message, the network will indicate one of the   following:
  716. .LP
  717.     1)
  718.     channel is indicated, no acceptable alternative, or,
  719. .LP
  720.     2)
  721.     channel is indicated, any alternative is acceptable;   or,
  722. .LP
  723.     3)
  724.     any channel is acceptable; or,
  725. .LP
  726.     4)
  727.     no B\(hychannel available.
  728. .LP
  729.     \fINote\fR \ \(em\ Not all networks will support the
  730. \fIno B\(hychannel available\fR condition.
  731. .LP
  732.     b)
  733.      In cases 1) and 2), if the indicated channel is acceptable and available, 
  734. the user selects it for the call. 
  735. .LP
  736.      In case 2), if the user cannot grant the indicated channel, it selects 
  737. any other available B\(hychannel associated with the D\(hychannel, and 
  738. identifies that channel in the first message sent in response to the SETUP
  739. message.
  740. .LP
  741.     In case 3), the user selects any available B\(hychannel
  742. associated with the D\(hychannel, and identifies that channel in the first 
  743. message sent in response to the SETUP message. 
  744. .LP
  745.      If in case 1) the B\(hychannel indicated in the first response message 
  746. is not the channel offered by the network, or in cases\ 2) and\ 3) the 
  747. B\(hychannel indicated in the first response message is unacceptable to the
  748. network, it will clear the call by sending a RELEASE message with cause\ No.6
  749. \fIchannel unacceptable\fR [see \(sc\ 5.3.2 | )].
  750. .LP
  751.     in case 4), the user rejects the call by sending RELEASE
  752. COMPLETE message with cause\ No.\ 34 \fIno circuit/channel available\fR 
  753. unless it is able to proceed with the call. The user wishing to re\(hyuse 
  754. a B\(hychannel it has 
  755. already allocated to another call (e.g.\ by releasing, or holding it, or by
  756. multiplexing packet calls) shall send the appropriate message containing the
  757. channel identification information element, coded as \fIchannel is indicated,\fR 
  758. \fIno alternative acceptable\fR . 
  759. .LP
  760.     c)
  761.      If no channel identification information element is present in the first 
  762. response message, the B\(hychannel indicated in the SETUP message 
  763. will be assumed.
  764. .LP
  765.     d)
  766.      When a B\(hychannel has been selected by the user, that channel may be 
  767. connected by the user. 
  768. .LP
  769.     e)
  770.      In case 1) if the indicated B\(hychannel is not available, or in cases\ 
  771. 2), 3), and\ 4) if no B\(hychannel is available and the user cannot 
  772. proceed with the offered call, the user returns a RELEASE COMPLETE message 
  773. with cause\ No.\ 44 \fIrequested circuit/channel not available\fR or No.\ 
  774. 34 \fIno\fR 
  775. \fIcircuit/channel available\fR , respectively, and returns to the Null
  776. state.
  777. .sp 1P
  778. .LP
  779. 5.2.3.2
  780.     \fISETUP message delivered by broadcast data link\fR 
  781. .sp 9p
  782. .RT
  783. .PP
  784. When the SETUP message is delivered by a broadcast data link the
  785. channel selection procedure, provided in \(sc\ 5.2.3.1, is not applicable. The
  786. network sends a SETUP message with the channel identification information
  787. element indicating one of the following:
  788. .RT
  789. .LP
  790.     a)
  791.     channel indicated, no alternative is acceptable; or,
  792. .LP
  793.     b)
  794.     no channel available.
  795. .PP
  796. The network starts timers T303 and T312.
  797. .PP
  798. In case a), if the user can accept the call on the indicated channel, the 
  799. user shall send the appropriate message (see \(sc\(sc\ 5.2.4 and\ 5.2.5). 
  800. If the 
  801. user cannot accept the call on the indicated channel, the user shall send a
  802. RELEASE COMPLETE message with cause\ No.\ 44 \fIrequested circuit/channel 
  803. not\fR 
  804. \fIavailable\fR .
  805. .PP
  806. The user, in any case, must not connect to the channel until a CONNECT 
  807. ACKNOWLEDGE message has been received. 
  808. .PP
  809. In case b), the user not controlling any channel shall send a RELEASE COMPLETE 
  810. message with cause\ No.\ 34 \fIno circuit/channel available\fR . The user 
  811. wishing to re\(hyuse a B\(hychannel it has already allocated to another 
  812. call (e.g.\ by releasing, or holding it, or by multiplexing packet calls) 
  813. shall send the 
  814. appropriate message containing the channel identification information element, 
  815. coded as \fIchannel is indicated, no alternative acceptable\fR . 
  816. .bp
  817. .RT
  818. .sp 1P
  819. .LP
  820. 5.2.4
  821.     \fIOverlap receiving\fR 
  822. .sp 9p
  823. .RT
  824. .PP
  825. When a user determines that a received SETUP message contains
  826. either:
  827. .RT
  828. .LP
  829.     a)
  830.     no called number information; or,
  831. .LP
  832.     b)
  833.     incomplete called number information; or,
  834. .LP
  835.     c)
  836.     called number information which the user cannot determine to be complete;
  837. .LP
  838. and when the user:
  839. .LP
  840.     d)
  841.     is compatible with other call characteristics (see Annex\ B); and,
  842. .LP
  843.     e)
  844.     implements overlap receiving;
  845. .LP
  846. the user shall: start timer T302; send a SETUP ACKNOWLEDGE
  847. message to the network; and enter the overlap receiving state.
  848. .PP
  849. When the SETUP ACKNOWLEDGE message is received, the network shall: stop 
  850. timer\ T303; start timer\ T304; enter the overlap receiving state; and 
  851. send the remainder of the call information (if any) in one or more INFORMATION 
  852. messages, starting timer\ T304 when each INFORMATION message is sent.
  853. .PP
  854. The called party number information is provided in the called party
  855. number information element.
  856. .PP
  857. The call address information may contain a \fIsending complete\fR 
  858. indication (e.g.\ No. or, as a network option, the sending complete information 
  859. element) appropriate to the dialling plan being used. 
  860. .PP
  861. \fINote\fR \ \(em\ If the network can determine that sufficient call setup
  862. information will be received by the called user by sending the next INFORMATION 
  863. message, it is recommended that the INFORMATION message contains the sending 
  864. complete information element.
  865. .PP
  866. The user shall START TIMER T302 on receipt of every INFORMATION
  867. message not containing a sending complete indication.
  868. .PP
  869. Following the receipt of a sending complete indication which the user understands, 
  870. or the determination that sufficient call information has been 
  871. received, the user shall stop timer\ T302 (if implemented) and send a CALL
  872. PROCEEDING message to the network. Alternatively, depending on internal 
  873. events, the user may send an ALERTING or a CONNECT message to the network. 
  874. .PP
  875. \fINote\fR \ \(em\ The CALL PROCEEDING message in this case will cause 
  876. that the originating exchange to send a CALL PROCEEDING message to the 
  877. originating user, if not already sent (see for example Recommendation\ 
  878. Q.699). 
  879. .PP
  880. At the expiration of timer T302 the user shall:
  881. .RT
  882. .LP
  883.     a)
  884.      initiate clearing in accordance with \(sc 5.3 with cause No. 28 \fIinvalid 
  885. number format (incomplete number)\fR if it determines that the call 
  886. information is definitely incomplete; or,
  887. .LP
  888.     b)
  889.     if sufficient information has been received, send a CALL
  890. PROCEEDING, ALERTING or CONNECT message as appropriate.
  891. .PP
  892. At the expiration of timer T304 the network initiates call
  893. clearing in accordance with \(sc\ 5.3, with cause\ No.\ 28 \fIinvalid number 
  894. format\fR \fI(incomplete number)\fR sent to the calling user, and cause\ 
  895. No.\ 102 \fIrecovery on\fR \fItimer expiry\fR sent to the called user. 
  896. .PP
  897. If, following the receipt of a SETUP message or during overlap
  898. receiving, the user determines that the received call information is invalid
  899. (e.g.\ invalid called party number), it shall initiate call clearing in
  900. accordance with \(sc\ 5.3 with a cause such as one of the following:
  901. .RT
  902. .LP
  903.     No. 1\ 
  904. \fIunassigned (unallocated) number\fR ;
  905. .LP
  906.     No. 3\ 
  907. \fIno route to destination\fR ;
  908. .LP
  909.     No. 22 \fInumber changed\fR ;
  910. .LP
  911.     No. 28 \fIinvalid number format (incomplete number)\fR .
  912. .PP
  913. Upon receipt of the complete call information the user may further perform 
  914. some compatibility checking functions, as outlined in Annex\ B. 
  915. .PP
  916. When the call is offered on a point\(hyto\(hypoint data link, only one 
  917. SETUP ACKNOWLEDGE message can be received in response to the call offering. 
  918. .PP
  919. When the call is offered to the user on a broadcast data link,
  920. multiple SETUP ACKNOWLEDGE messages may be received by the network which 
  921. shall then complete as many overlap receiving procedures as such SETUP 
  922. ACKNOWLEDGE 
  923. messages were received.
  924. .bp
  925. .PP
  926. It is the network responsibility to limit the  number
  927. of overlap receiving procedures to be completed for a given call. The default 
  928. maximum is fixed to eight. Some networks will limit the call offering 
  929. completion in overlap receiving to single data link and will therefore clear
  930. the subsequent responding users after the first SETUP ACKNOWLEDGE message 
  931. has been received, in accordance with the non\(hyselected user clearing 
  932. procedures 
  933. described in \(sc\ 5.2.9.
  934. .RT
  935. .sp 2P
  936. .LP
  937. 5.2.5
  938.     \fICall confirmation\fR 
  939. .sp 1P
  940. .RT
  941. .sp 1P
  942. .LP
  943. 5.2.5.1
  944.     \fIResponse to en\(hybloc SETUP or completion of overlap\fR 
  945. \fIreceiving\fR 
  946. .sp 9p
  947. .RT
  948. .PP
  949. When the user determines that sufficient call setup information has been 
  950. received and compatibility requirements (see Annex\ B) have been satisfied, 
  951. the user responds with either a CALL PROCEEDING, ALERTING, or CONNECT message 
  952. (see Note\ 2), and enters the incoming call proceeding , call received, 
  953. or 
  954. connect request state, respectively.
  955. .PP
  956. \fINote\ 1\fR \ \(em\ The possibility of alternative responses (e.g. in
  957. connection with supplementary services) is for further study.
  958. .PP
  959. \fINote\ 2\fR \ \(em\ A progress indicator information element may be included 
  960. in CALL PROCEEDING, ALERTING, and CONNECT message (e.g.\ when an analogue 
  961. terminal is connected to an ISDN PABX). The CALL PROCEEDING message may 
  962. be sent by the user which cannot respond to a SETUP message with an ALERTING, 
  963. CONNECT, or 
  964. RELEASE COMPLETE message before expiration of timer\ T303.
  965. .PP
  966. When the SETUP message was delivered via a broadcast data link, an
  967. incompatible user shall either:
  968. .RT
  969. .LP
  970.     a)
  971.     ignore the incoming call; or,
  972. .LP
  973.     b)
  974.     respond by sending a RELEASE COMPLETE message with
  975. cause\ No.\ 88 \fIincompatible destination\fR , and enter the Null state. 
  976. The network processes this RELEASE COMPLETE message in accordance with 
  977. \(sc\ 5.2.5.3. 
  978. .PP
  979. When the SETUP message was delivered via a point\(hyto\(hypoint data
  980. link, an incompatible user shall respond with a RELEASE COMPLETE message 
  981. with cause\ No.\ 88 \fIincompatible destination\fR . The network processes 
  982. this RELEASE 
  983. COMPLETE message in accordance with \(sc\ 5.2.5.3.
  984. .PP
  985. A busy user which satisfies the compatibility requirements indicated in 
  986. the SETUP message shall normally respond with a RELEASE COMPLETE message 
  987. with cause\ No.\ 17 \fIuser busy\fR . The network processes this RELEASE 
  988. COMPLETE 
  989. message in accordance with \(sc\ 5.2.5.3.
  990. .PP
  991. If the user wishes to refuse the call, a RELEASE COMPLETE message
  992. shall be sent with the cause\ No.\ 21 \fIcall rejected\fR , and the user 
  993. returns to 
  994. the Null state. The network processes this RELEASE COMPLETE message in
  995. accordance with \(sc\ 5.2.5.3.
  996. .RT
  997. .sp 1P
  998. .LP
  999. 5.2.5.2
  1000.     \fIReceipt of CALL PROCeeding and ALERTing\fR 
  1001. .sp 9p
  1002. .RT
  1003. .PP
  1004. When the SETUP message is delivered on a broadcast data link, the network 
  1005. shall maintain a state machine that tracks the overall progression of the 
  1006. incoming call. The network shall also maintain an associated call state 
  1007. for each responding user as determined by the data link on which a message 
  1008. is 
  1009. received.
  1010. .PP
  1011. Upon receipt of the first CALL PROCEEDING message from a user
  1012. (assuming no other user had previously responded with an ALERTING or CONNECT
  1013. message when the SETUP message has been delivered on a broadcast data link),
  1014. the network shall: stop timer\ T303 (or, in the case of overlap receiving,
  1015. timer\ T304 for that user); start timer\ T310; and enter the incoming call
  1016. proceeding state.
  1017. .PP
  1018. When the SETUP message has been delivered on a broadcast data link,
  1019. the network shall (at a minimum) associate the incoming call proceeding 
  1020. state with each called user that sends a CALL PROCEEDING message as a first 
  1021. response to the broadcast SETUP message prior to expiration of timer\ T312. 
  1022. Actions to be taken when a user sends a first response to an incoming call 
  1023. after the 
  1024. expiration of timer\ T312 are described in \(sc\ 5.2.5.4. Timer\ T310 shall 
  1025. not be 
  1026. restarted.
  1027. .bp
  1028. .PP
  1029. Upon receipt of the first ALERTING message from a user (assuming no
  1030. other user has previously responded with a CONNECT message when the SETUP
  1031. message has been delivered on a broadcast data link), the network shall: 
  1032. stop timer\ T304 for that user (in the case of overlap receiving); stop 
  1033. timer\ T303 or T310 (if running); start timer\ T301 (unless another internal 
  1034. alerting 
  1035. supervision timer function exists; e.g.\ incorporated in call control); enter
  1036. the call received state; and send a corresponding ALERTING message to the
  1037. calling user.
  1038. .PP
  1039. When the SETUP message has been delivered on a broadcast data link,
  1040. the network shall (at a minimum) associate the call received state with each
  1041. called user that sends an ALERTING message either as a first response to the
  1042. broadcast SETUP message or following a CALL PROCEEDING message. Timer\ T304
  1043. shall not be restarted.
  1044. .RT
  1045. .sp 1P
  1046. .LP
  1047. 5.2.5.3
  1048.     \fICalled user clearing\fR \fIduring incoming call\fR 
  1049. \fIestablishment\fR 
  1050. .sp 9p
  1051. .RT
  1052. .PP
  1053. If the SETUP message has been delivered on a point\(hyto\(hypoint data
  1054. link and a RELEASE COMPLETE or DISCONNECT message is received before a 
  1055. CONNECT message has been received, the network shall: stop timer\ T303, 
  1056. T304, T310 or 
  1057. T301 (if running); continue to clear the user as described in \(sc\ 5.3.3, and
  1058. clear the call to the calling user with the cause received in the RELEASE
  1059. COMPLETE or DISCONNECT message.
  1060. .PP
  1061. If the SETUP message has been delivered on a broadcast data link and a 
  1062. RELEASE COMPLETE message is received whilst timer\ T303 is running, the 
  1063. message cause shall be retained by the network. If timer\ T303 expires 
  1064. (i.e.\ if no valid message such as CALL PROCEEDING, ALERTING or CONNECT 
  1065. has been received) the 
  1066. cause previously retained when a RELEASE COMPLETE message was received 
  1067. is sent back to the calling user in a DISCONNECT message and the network 
  1068. shall enter 
  1069. the call abort state. When multiple RELEASE COMPLETE messages are received 
  1070. with different causes, the network shall: 
  1071. .RT
  1072. .LP
  1073.     1)
  1074.     ignore any cause No. 88 \fIincompatible destination\fR ; and,
  1075. .LP
  1076.     2)
  1077.      give preference to the following causes (if received) in the order listed 
  1078. below: 
  1079. .LP
  1080.     (highest)
  1081.     No. 17 \fIuser busy\fR ;
  1082. .LP
  1083.     No. 21 \fIcall rejected\fR ;
  1084. .LP
  1085.     3)
  1086.     any other received cause may also be included in the
  1087. clearing message sent to the originating user (see\ \(sc\ 5.3).
  1088. .PP
  1089. If the SETUP message has been delivered on a broadcast data link and a 
  1090. user which has previously sent a SETUP ACKNOWLEDGE, CALL PROCEEDING or 
  1091. ALERTING message sends a DISCONNECT message to the network, the actions 
  1092. taken by the network depend on whether timer\ T312 is running and whether 
  1093. other called users have responded to the SETUP message. 
  1094. .sp 1P
  1095. .LP
  1096. \fICase\ 1\fR  | \ DISCONNECT received prior to expiry of timer T312
  1097. .sp 9p
  1098. .RT
  1099. .PP
  1100. If timer T312 is running and the network receives a DISCONNECT
  1101. message after having received a SETUP ACKNOWLEDGE, CALL PROCEEDING or ALERTING 
  1102. message from a called user (but before receiving a CONNECT message), 
  1103. timer\ T312, as well as timer\ T310 or T301 (if running), should continue 
  1104. to run. The network shall retain the cause in the DISCONNECT message and 
  1105. shall continue to clear the user as described in \(sc\ 5.3.3. The network 
  1106. shall stop timer\ T304 
  1107. (if running) for this user.
  1108. .PP
  1109. Upon expiration of timer T312, if either:
  1110. .RT
  1111. .LP
  1112.     a)
  1113.     no other users have responded to the incoming call; or
  1114. .LP
  1115.     b)
  1116.      all users that have responded to the incoming call have been cleared 
  1117. or are in the process of being cleared: 
  1118. .LP
  1119. the network shall stop timer T310 or T301 (if running) and shall clear 
  1120. the call to the calling user. If an ALERTING message has been received, 
  1121. the cause sent to the calling user shall be a cause received from the called 
  1122. user, giving 
  1123. preference to (in order of priority): No.\ 21 \fIcall rejected\fR ; any 
  1124. other cause sent by a called user. If only SETUP ACKNOWLEDGE, or CALL PROCEEDING 
  1125. messages have been received, the cause sent to the calling user shall be 
  1126. a cause 
  1127. received from the called user, giving preference to (in order of priority):
  1128. No.\ 17 \fIuser busy\fR ; No.\ 21 \fIcall rejected\fR ; any other appropriate 
  1129. cause sent by a called user. 
  1130. .bp
  1131. .sp 1P
  1132. .LP
  1133. \fICase\ 2\fR  | \ DISCONNECT received after expiry of timer T312
  1134. .sp 9p
  1135. .RT
  1136. .PP
  1137. If timer T312 has expired and the network receives a DISCONNECT
  1138. message from the called user after having received a SETUP ACKNOWLEDGE, CALL
  1139. PROCEEDING or ALERTING message (but before receiving a CONNECT message), the
  1140. network shall continue to clear the user as described in \(sc\ 5.3.3. The 
  1141. network shall stop timer\ T304 (if running) for this user. 
  1142. .PP
  1143. If other called users have responded to the SETUP message with a SETUP 
  1144. ACKNOWLEDGE, CALL PROCEEDING or ALERTING message, and still have the 
  1145. opportunity to accept the call by sending a CONNECT message, the network 
  1146. shall retain the cause in the DISCONNECT message. The network shall continue 
  1147. to 
  1148. process the incoming call for the remaining responding users (T310 or T301, 
  1149. if running, shall continue to run). 
  1150. .PP
  1151. If either:
  1152. .RT
  1153. .LP
  1154.     a)
  1155.     no other users have responded to the incoming call; or
  1156. .LP
  1157.     b)
  1158.      all users that have responded to the incoming call have been cleared 
  1159. or are in the process of being cleared: 
  1160. .LP
  1161. the network shall stop timer T310 or T301 (if running) and shall clear 
  1162. the call to the calling user. If an ALERTING message has been received, 
  1163. the cause sent to the calling user shall be a cause received from the called 
  1164. user, giving 
  1165. preference to (in order of priority): No.\ 21 \fIcall rejected\fR ; or 
  1166. any other 
  1167. cause sent by a called user. If only SETUP ACKNOWLEDGE, or CALL PROCEEDING
  1168. message have been received, the cause sent to the calling user shall be 
  1169. a cause received from the called user, giving preference to (in order of 
  1170. priority): 
  1171. No.\ 17 \fIuser busy\fR ; No.\ 21 \fIcall rejected\fR ; any other appropriate 
  1172. cause sent by a called user. 
  1173. .sp 1P
  1174. .LP
  1175. 5.2.5.4
  1176.     \fICall failure\fR 
  1177. .sp 9p
  1178. .RT
  1179. .PP
  1180. If the network does not receive any response to the retransmitted SETUP 
  1181. message prior to the expiration of timer\ T303, then the network shall 
  1182. initiate clearing procedures towards the calling user with cause\ No.\ 
  1183. 18 \fIno\fR \fIuser responding\fR . 
  1184. .RT
  1185. .LP
  1186.     a)
  1187.      If the SETUP message was delivered by a broadcast data link, the network 
  1188. shall enter the call abort state. 
  1189. .LP
  1190.     b)
  1191.      if the SETUP message was delivered on a point\(hyto\(hypoint data link, 
  1192. the network shall also initiate clearing procedures towards the called 
  1193. user in accordance with \(sc\ 5.3.4, using cause\ No.\ 102 \fIrecovery 
  1194. on timer\fR 
  1195. \fIexpiry\fR .
  1196. .PP
  1197. If the network receives a user's first response to SETUP when in the call 
  1198. abort state but before timer\ T312 has expired, the network shall 
  1199. initiate clearing to the called user as described in \(sc\ 5.3.2 | ), except 
  1200. that 
  1201. the cause\ No.\ 102 \fIrecovery on timer expiry\fR shall be sent. If the 
  1202. network 
  1203. receives a message that is a user's first response to an incoming call after
  1204. timer\ T312 has expired, the network will interpret this message as a message
  1205. received with an invalid call reference value, as described in \(sc\ 5.8.3.2.
  1206. .PP
  1207. If the network has received a CALL PROCEEDING message, but does not
  1208. receive an ALERTING, CONNECT, or DISCONNECT message prior to the expiration 
  1209. of timer\ T310, then the network shall: initiate clearing procedures towards 
  1210. the 
  1211. calling user with cause\ No.\ 18 \fIno user responding\fR ; and initiate 
  1212. clearing 
  1213. procedures towards the called user.
  1214. .RT
  1215. .LP
  1216.     1)
  1217.      If the SETUP message was delivered by a broadcast data link, the called 
  1218. user shall be cleared in accordance with \(sc\ 5.3.2 | ), except that 
  1219. cause\ No.\ 102 \fIrecovery on timer expiry\fR shall be sent.
  1220. .LP
  1221.     2)
  1222.      If the SETUP message was delivered on a point\(hyto\(hypoint data link, 
  1223. the called user shall be cleared in accordance with \(sc\ 5.3.4 using 
  1224. cause\ No.\ 102 \fIrecovery on timer expiry\fR .
  1225. .PP
  1226. If the network has received an ALERTING message, but does not
  1227. receive a CONNECT or DISCONNECT message prior to the expiry of timer\ T301 
  1228. (or a corresponding internal alerting supervision timing function), then 
  1229. the network shall: initiate clearing procedures towards the calling user 
  1230. with cause\ No.\ 19 \fIuser alerting, no answer\fR ; and initiate clearing 
  1231. procedures towards the called user. 
  1232. .LP
  1233.     i)
  1234.      If the SETUP message was delivered by a broadcast data link, the called 
  1235. user shall be cleared in accordance with \(sc\ 5.3.2 | ), except that 
  1236. cause\ No.\ 102 \fIrecovery on timer expiry\fR shall be sent.
  1237. .LP
  1238.     ii)
  1239.      If the SETUP message was delivered on a point\(hyto\(hypoint data link, 
  1240. the called user shall be cleared in accordance with \(sc\ 5.3.4 using 
  1241. cause\ No.\ 102 \fIrecovery on timer expiry\fR .
  1242. .bp
  1243. .sp 1P
  1244. .LP
  1245. 5.2.6
  1246.     \fINotification of interworking at the terminating\fR 
  1247. \fIinterface\fR 
  1248. .sp 9p
  1249. .RT
  1250. .PP
  1251. During call establishment, the call may enter an ISDN environment, e.g. 
  1252. because of interworking with another network, with a non\(hyISDN user, 
  1253. or 
  1254. with non\(hyISDN equipment within the calling or called user's premises. 
  1255. When this occurs, the point at which call enters an ISDN environment shall 
  1256. cause a 
  1257. progress indicator information element to be included in the SETUP message 
  1258. to be sent to the called user. 
  1259. .RT
  1260. .LP
  1261.     a)
  1262.     No. 1 \fIcall is not end\(hyto\(hyend ISDN; further call\fR 
  1263. \fIprogress information may be available in\(hyband\fR ;
  1264. .LP
  1265.      \fINote\fR \ \(em\ On receipt of progress indicator No. 1, the called 
  1266. user shall connect to the B\(hychannel in accordance with the procedures 
  1267. of 
  1268. \(sc\ 5.2.8.
  1269. .LP
  1270.     b)
  1271.     No. 3 \fIorigination address is non\(hyISDN\fR .
  1272. .PP
  1273. In addition, the user shall notify the calling party if the call has left 
  1274. the ISDN environment within the called user's premises, or upon the 
  1275. availability of in\(hyband information/patterns. When such situations occur, a
  1276. progress indication shall be sent by the user to the network either:
  1277. .LP
  1278.     1)
  1279.      in an appropriate call control message when a state change is required 
  1280. (SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING or CONNECT); or 
  1281. .LP
  1282.     2)
  1283.     in the PROGRESS message when no state change is
  1284. appropriate.
  1285. .PP
  1286. One of the following progress description values shall be included in the 
  1287. progress indicator information element in the message sent to the 
  1288. network (for further information, see Annex\ I):
  1289. .LP
  1290.     i)
  1291.     No. 1 \fIcall is not end\(hyto\(hyend ISDN; further call\fR 
  1292. \fIprogress information may be available in\(hyband\fR ;
  1293. .LP
  1294.     ii)
  1295.     No. 2 \fIdestination address is non\(hyISDN\fR ;
  1296. .LP
  1297.     iii)
  1298.     No. 4 \fIcall has returned to the ISDN\fR .
  1299. .PP
  1300. If the progress indicator information element is included in a
  1301. call control message, the procedures as described in the rest of \(sc\ 
  1302. 5.2 apply. If the progress indicator information element is included in 
  1303. the PROGRESS 
  1304. message, no state change will occur but any supervisory timers shall be
  1305. stopped.
  1306. .sp 1P
  1307. .LP
  1308. 5.2.7
  1309.     \fICall accept\fR 
  1310. .sp 9p
  1311. .RT
  1312. .PP
  1313. A user indicates acceptance of an incoming call by sending a
  1314. CONNECT message to the network. Upon sending the CONNECT message the user 
  1315. shall start timer\ T313 (the value of timer\ T313 is specified in \(sc\ 
  1316. 9.2). If an 
  1317. ALERTING message had previously been sent to the network, the CONNECT message 
  1318. may contain only the call reference. 
  1319. .PP
  1320. If a call can be accepted using the B\(hychannel indicated in the SETUP 
  1321. message, and no user alerting is required, a CONNECT message may be sent 
  1322. without a previous ALERTING message.
  1323. .PP
  1324. \fINote\fR \ \(em\ Further study is required on the need for means to avoid
  1325. service degradation (e.g.\ speech clipping) on connections involving an
  1326. NT2.
  1327. .RT
  1328. .sp 1P
  1329. .LP
  1330. 5.2.8
  1331.     \fIActive indication\fR 
  1332. .sp 9p
  1333. .RT
  1334. .PP
  1335. On receipt of the first CONNect message, the network shall: stop
  1336. (if running) timers\ T301, T303, T304 and T310; complete the circuit\(hyswitched 
  1337. path to the selected B\(hychannel; send a CONNECT ACKNOWLEDGE message to 
  1338. the user which first accepted the call; initiate procedures to send a CONNECT 
  1339. message 
  1340. towards the calling user; and enter the active state.
  1341. .PP
  1342. The CONNECT ACKNOWLEDGE message indicates completion of the
  1343. circuit\(hyswitched connection. There is no guarantee of an end\(hyto\(hyend 
  1344. connection until a CONNECT message is received at the calling user. Upon 
  1345. receipt of the 
  1346. CONNECT ACKNOWLEDGE message the user shall: stop timer\ T313 and enter the
  1347. active state.
  1348. .PP
  1349. When timer T313 expires prior to receipt of a CONNECT ACKNOWLEDGE
  1350. message, the user shall initiate clearing in accordance with \(sc\ 5.3.3
  1351. .PP
  1352. A user which has received the SETUP via the broadcast data link, and has 
  1353. been awarded the call, shall connect to the B\(hychannel only after it 
  1354. has 
  1355. received the CONNECT ACKNOWLEDGE message. Only the user that is awarded the
  1356. call will receive the CONNECT ACKNOWLEDGE message.
  1357. .PP
  1358. A user which has received the SETUP via a point\(hyto\(hypoint data link 
  1359. may connect to the B\(hychannel as soon as channel selection has been completed. 
  1360. .bp
  1361. .RT
  1362. .sp 1P
  1363. .LP
  1364. 5.2.9
  1365.     \fINon\(hyselected user clearing\fR 
  1366. .sp 9p
  1367. .RT
  1368. .PP
  1369. In addition to sending the CONNECT ACKNOWLEDGE message to the user selected 
  1370. for the call, the network shall send RELEASE message [as described in \(sc\ 
  1371. 5.3.2 | )] to all other users at the interface that have sent SETUP 
  1372. ACKNOWLEDGE, CALL PROCEEDING, ALERTING or CONNECT messages in response 
  1373. to the SETUP message. These RELEASE messages are used to notify the users 
  1374. that the 
  1375. call is no longer offered to them. The procedures described in \(sc\ 5.3.4 
  1376. are then followed. Any user which having previously sent a CONNECT message 
  1377. and started timer\ T313, and which subsequently receives a RELEASE message, 
  1378. shall stop 
  1379. timer\ T313 and follow the procedures of \(sc\ 5.3.4.
  1380. .RT
  1381. .sp 2P
  1382. .LP
  1383. 5.3
  1384.     \fICall clearing\fR 
  1385. .sp 1P
  1386. .RT
  1387. .sp 1P
  1388. .LP
  1389. 5.3.1
  1390.     \fITerminology\fR 
  1391. .sp 9p
  1392. .RT
  1393. .PP
  1394. The following terms are used in this Recommendation in the
  1395. description of clearing procedures:
  1396. .RT
  1397. .LP
  1398.     \(em
  1399.     A channel is \fIconnected\fR when the channel is part of a
  1400. circuit\(hyswitched ISDN connection established according to this Recommendation. 
  1401. .LP
  1402.     \(em
  1403.     A channel is \fIdisconnected\fR when the channel is no longer
  1404. part of a circuit\(hyswitched ISDN connection, but is not yet available 
  1405. for use in a new connection. 
  1406. .LP
  1407.     \(em
  1408.     A channel is \fIreleased\fR when the channel is not part of a
  1409. circuit\(hyswitched ISDN connection and is available for use in a new connection. 
  1410. Similarly, a call reference that is \fIreleased\fR is available for reuse. 
  1411. .sp 1P
  1412. .LP
  1413. 5.3.2
  1414.     \fIException conditions\fR 
  1415. .sp 9p
  1416. .RT
  1417. .PP
  1418. Under normal conditions, call clearing is usually initiated when
  1419. the user or the network sends a DISCONNECT message and follows the procedures 
  1420. defined in \(sc\(sc\ 5.3.3 and 5.3.4 respectively. The only exceptions 
  1421. to the above 
  1422. rule are as follows:
  1423. .RT
  1424. .LP
  1425.     a)
  1426.     In response to a SETUP message, the user or network can
  1427. reject a call (e.g.\ because of the unavailability of a suitable B\(hychannel) 
  1428. by: responding with a RELEASE COMPLETE message provided no other response 
  1429. has 
  1430. previously been sent (e.g.\ the SETUP ACKNOWLEDGE message in the case of 
  1431. overlap sending); releasing the call reference; and enter the Null state. 
  1432. .LP
  1433.     b)
  1434.     In the case of a multipoint terminal configuration,
  1435. non\(hyselected user call clearing will be initiated with RELEASE message(s) 
  1436. from the network (see \(sc\ 5.2.9). The RELEASE message shall contain cause\ 
  1437. No.\ 26 
  1438. \fInon\(hyselected user clearing\fR .
  1439. .LP
  1440.     c)
  1441.     Clearing of temporary signalling connections will be
  1442. initiated by sending a RELEASE message as described in \(sc\(sc\ 5.3.3 
  1443. and\ 5.3.4. 
  1444. .LP
  1445.     d)
  1446.     Unsuccessful termination of the B\(hychannel selection
  1447. procedure (see \(sc\(sc\ 5.2.3.1 and\ 5.1.2) by the side offering the call is
  1448. accomplished by sending a RELEASE message as described in \(sc\(sc\ 5.3.3 
  1449. and\ 5.3.4. The RELEASE message shall contain cause\ No.\ 6 \fIchannel 
  1450. unacceptable\fR . 
  1451. .LP
  1452.     e)
  1453.     1)
  1454.      In the case of a SETUP message sent via the broadcast data link, if a 
  1455. network disconnect indication is received during call 
  1456. establishment, and prior to the expiry of timer\ T312, timer\ T303 is stopped 
  1457. (if running) and the network enters the call abort state. Any user which 
  1458. has 
  1459. responded, or subsequently responds before timer\ T312 expires, will be 
  1460. cleared by a RELEASE message (with the cause code(s) contained in the network 
  1461. disconnect indication) and the procedures of \(sc\ 5.3.4 are then followed 
  1462. for that user. Upon expiry of timer\ T312, the network shall treat any 
  1463. subsequent 
  1464. responses according to the procedures defined in \(sc\ 5.8.3.2. The network 
  1465. shall enter the Null state upon completion of clearing procedures for all 
  1466. responding users. 
  1467. .LP
  1468.     2)
  1469.      In the case of a SETUP message sent via the broadcast data link, if a 
  1470. network disconnect indication is received during call 
  1471. establishment after expiry of timer\ T312, any user which has responded 
  1472. shall be cleared by a RELEASE message (with the cause code(s) contained 
  1473. in the network disconnect indication) and the procedures of \(sc\ 5.3.4 
  1474. are then followed for that user. The network enters the Null state upon 
  1475. completion of clearing procedures for all responding users. 
  1476. .LP
  1477.     \fINote\fR \ \(em\ A separate state machine exists for each
  1478. responding user.
  1479. .LP
  1480.     f
  1481. )
  1482.     When timer T318 expires, the user initiates
  1483. internal
  1484. call clearing by sending a RELEASE message with cause\ No.\ 102 \fIrecovery 
  1485. on\fR 
  1486. \fItimer expiry\fR ; starting timer\ T308; and continuing as described in
  1487. \(sc\ 5.3.3.
  1488. .bp
  1489. .sp 1P
  1490. .LP
  1491. 5.3.3
  1492.     \fIClearing initiated by the user\fR 
  1493. .sp 9p
  1494. .RT
  1495. .PP
  1496. Apart from the exceptions identified in \(sc\(sc 5.3.2 and 5.8, the user 
  1497. shall initiate clearing by: sending a DISCONNECT message; starting timer\ 
  1498. T305 (the value of timer\ T305 is specified in \(sc\ 9.2); disconnecting 
  1499. the B\(hychannel; and entering the disconnect request state. 
  1500. .PP
  1501. \fINote\fR \ \(em\ When a user initiates call clearing by sending a RELEASE
  1502. message, the procedures described in \(sc\ 5.3.4 are then followed.
  1503. .PP
  1504. The network shall enter the disconnect request state upon receipt of a 
  1505. DISCONNECT message. This message then prompts the network to disconnect 
  1506. the 
  1507. B\(hychannel, and to initiate procedures for clearing the network connection to
  1508. the remote user. Once the B\(hychannel used for the call has been disconnected,
  1509. the network shall: send a RELEASE message to the user; start timer\ T308 (the
  1510. value of a timer\ T.308 is specified in \(sc\ 9.1); and enter the release 
  1511. request 
  1512. state.
  1513. .PP
  1514. \fINote\fR \ \(em\ The RELEASE message has only local significance and 
  1515. does not imply an acknowledgement of clearing from the remote user. 
  1516. .PP
  1517. On receipt of the RELEASE message the user shall: cancel timer T305; release 
  1518. the B\(hychannel; send a RELEASE COMPLETE message; release the call 
  1519. reference; and return to the Null state. Following the receipt of a RELEASE
  1520. COMPLETE message from the user, the network shall: stop timer\ T308; release
  1521. both the B\(hychannel and the call reference; and return to the Null state.
  1522. .PP
  1523. If timer T305 expires, the user shall: send a RELEASE message to the network 
  1524. with the cause number originally contained in the DISCONNECT message; start 
  1525. timer\ T308 and enter the release request state. In addition, the user 
  1526. may indicate a second cause information element with cause\ No.\ 102 \fIrecovery 
  1527. on\fR \fItimer expiry\fR . 
  1528. .PP
  1529. If timer T308 expires for the first time, the network shall:
  1530. retransmit the RELEASE message and timer\ T308 shall be restarted. In addition, 
  1531. the network may indicate a second cause information element with cause\ 
  1532. No.\ 102 \fIrecovery on timer expiry\fR . If no RELEASE COMPLETE message 
  1533. is received from the user before timer\ T308 expires a second time, the 
  1534. network shall: place the 
  1535. B\(hychannel in a maintenance condition; release the call reference; and 
  1536. return to the Null state. 
  1537. .PP
  1538. \fINote\ 1\fR \ \(em\ The restart procedures contained in \(sc 5.5 may 
  1539. be used on 
  1540. B\(hychannels in the maintenance condition.
  1541. .PP
  1542. \fINote\ 2\fR \ \(em\ Other actions which could be taken by the network upon
  1543. receipt of a DISCONNECT message are for further study.
  1544. .RT
  1545. .sp 1P
  1546. .LP
  1547. 5.3.4
  1548.     \fIClearing initiated by the network\fR 
  1549. .sp 9p
  1550. .RT
  1551. .PP
  1552. Apart from the exception conditions identified in \(sc\(sc 5.3.2 and 5.8, 
  1553. the network shall initiate clearing by: sending a DISCONNECT message; and 
  1554. entering the disconnect indication state. The DISCONNECT message is a local
  1555. invitation to clear and does not imply that the B\(hychannel has been disconnected 
  1556. at the user\(hynetwork interface. 
  1557. .PP
  1558. \fINote\fR \ \(em\ When the network initiates clearing by sending a RELEASE
  1559. message, the procedures described in \(sc\ 5.3.3 are followed.
  1560. .RT
  1561. .sp 1P
  1562. .LP
  1563. 5.3.4.1
  1564.     \fIClearing when tones/announcements provided\fR 
  1565. .sp 9p
  1566. .RT
  1567. .PP
  1568. When in\(hyband tones/announcements are provided (see \(sc 5.4), the
  1569. DISCONNECT message contains progress indicator\ No.\ 8 \fIin\(hyband information 
  1570. or\fR \fIappropriate pattern now available\fR . The network shall: start 
  1571. timer\ T306; and enter the disconnect indication state. 
  1572. .PP
  1573. On receipt of the DISCONNECT message with progress indicator No. 8,
  1574. the user may: connect (if not already connected) to the B\(hychannel to receive
  1575. the in\(hyband tone/announcement; and enter the disconnect indication state.
  1576. Alternatively, to continue clearing without connecting to the in\(hyband
  1577. tone/announcement, the user shall: disconnect the B\(hychannel; send a RELEASE
  1578. message; start timer\ T308; and enter the release request state.
  1579. .PP
  1580. If the user connects to the provided in\(hyband tone/announcement, the
  1581. user may subsequently continue clearing (before the receipt of a RELEASE 
  1582. from the network) by: disconnecting from the B\(hychannel; sending a RELEASE 
  1583. message; starting timer\ T308; and entering the release request state. 
  1584. .PP
  1585. On receipt of the RELEASE message, the network shall: stop timer\ T306; 
  1586. disconnect and release the B\(hychannel; send a RELEASE COMPLETE message; 
  1587. release the call reference; and return to the Null state. 
  1588. .PP
  1589. If timer T306 expires, the network shall continue clearing by:
  1590. disconnecting the B\(hychannel; sending a RELEASE message with the cause number
  1591. originally contained in the DISCONNECT message; starting timer\ T308; and
  1592. entering the release request state.
  1593. .bp
  1594. .PP
  1595. In addition to the original clearing cause, the RELEASE message may
  1596. contain a second cause information element with cause\ No.\ 102 \fIrecovery 
  1597. on\fR 
  1598. \fItimer expiry\fR ; this cause may optionally contain a diagnostic field
  1599. identifying the timer that expired.
  1600. .PP
  1601. On receipt of the RELEASE message, the user shall act according to
  1602. \(sc\ 5.3.3.
  1603. .RT
  1604. .sp 1P
  1605. .LP
  1606. 5.3.4.2
  1607.     \fIClearing when tones/announcements not provided\fR 
  1608. .sp 9p
  1609. .RT
  1610. .PP
  1611. When in\(hyband tones/announcements are \fInot\fR provided, the DISCONNECT 
  1612. message does \fInot\fR contain progress indicator\ No.\ 8 \fIin\(hyband 
  1613. information or\fR \fIappropriate pattern now available\fR . The network 
  1614. shall initiate clearing by: 
  1615. sending the DISCONNECT message; start timer\ T305; disconnects the B\(hychannel; 
  1616. and enters the disconnect indication state.
  1617. .PP
  1618. On the receipt of the DISCONNECT message without progress
  1619. indicator\ No.\ 8, the user shall: disconnect the B\(hychannel; send a RELEASE
  1620. message; start timer\ T308; and enter the release request state.
  1621. .PP
  1622. On receipt of the RELEASE message, the network shall: stop timer\ T305; 
  1623. release the B\(hychannel; send a RELEASE COMPLETE message; release the 
  1624. call 
  1625. reference; and return to the Null state.
  1626. .PP
  1627. If timer T305 expires, the network shall: send a RELEASE message to
  1628. the user with the cause number originally contained in the DISCONNECT message; 
  1629. start timer\ T308; and enter the release request state. In addition to 
  1630. the 
  1631. original clearing cause, the RELEASE message may contain a second cause
  1632. information element with cause\ No.\ 102 \fIrecovery on timer expiry\fR .
  1633. .RT
  1634. .sp 1P
  1635. .LP
  1636. 5.3.4.3
  1637.     \fICompletion of clearing\fR 
  1638. .sp 9p
  1639. .RT
  1640. .PP
  1641. Following the receipt of a RELEASE COMPLETE message from the
  1642. network, the user shall: stop timer\ T308; release both the B\(hychannel 
  1643. and the 
  1644. call reference; and return to the Null state.
  1645. .PP
  1646. If a RELEASE COMPLETE is not received by the user before the first
  1647. expiry of timer\ T308, the RELEASE message shall be retransmitted and timer\ 
  1648. T308 shall be restarted. If no RELEASE COMPLETE message is received from 
  1649. the network before timer\ T308 expires a second time, the user may: place 
  1650. the B\(hychannel in a maintenance condition; shall release the call reference; 
  1651. and return to the Null state. 
  1652. .PP
  1653. \fINote\fR \ \(em\ The restart procedures contained in \(sc 5.5 may be used on
  1654. B\(hychannels in the maintenance condition.
  1655. .RT
  1656. .sp 1P
  1657. .LP
  1658. 5.3.5
  1659.     \fIClear collision\fR 
  1660. .sp 9p
  1661. .RT
  1662. .PP
  1663. Clear collision occurs when both the user and the network
  1664. simultaneously DISSCONNECT messages specifying the same call reference 
  1665. value. When the network receives a DISSCONNECT message whilst in the disconnect 
  1666. indication state, the network shall: stop timer\ T305 or T306 (whichever is
  1667. running); disconnect the B\(hychannel (if not disconnected); send a RELEASE
  1668. message; start timer\ T308; and enter the release request state. Similarly, 
  1669. when the user receives a DISCONNECT message whilst in the disconnect request 
  1670. state, the user shall: stop timer\ T305; send a RELEASE message; start 
  1671. timer\ T308; and enter the release request state. 
  1672. .PP
  1673. Clear collision can also occur when both sides simultaneously transfer 
  1674. RELEASE messages related to the same call reference value. The entity receiving 
  1675. such a RELEASE message whilst within the release request state shall: stop 
  1676. timer\ T308; release the call reference and B\(hychannel; and enter, if
  1677. appropriate, the Null state (without sending or receiving a RELEASE COMPLETE
  1678. message).
  1679. .RT
  1680. .sp 1P
  1681. .LP
  1682. 5.4
  1683.     \fIIn\(hyband tones and announcements\fR 
  1684. .sp 9p
  1685. .RT
  1686. .PP
  1687. When in\(hyband tones/announcements not associated with a call state change 
  1688. are to be provided by the network before reaching the active state, a 
  1689. PROGRESS message is returned simultaneously with the application of the 
  1690. in\(hyband tone/announcement. The PROGRESS message contains the progress 
  1691. indicator\ No.\ 8 \fIin\(hyband information or appropriate pattern is now 
  1692. available\fR . 
  1693. .PP
  1694. When tones/announcements have to be provided together with a call
  1695. state change, then the appropriate message (e.g.\ for ALERTING, DISCONNECT\ 
  1696. etc.; see appropriate section) with progress indicator\ No.\ 8 \fIin\(hyband 
  1697. information or\fR \fIappropriate pattern is now available\fR is sent simultaneously 
  1698. with the 
  1699. application of the in\(hyband tone/announcement.
  1700. .PP
  1701. \fINote\ 1\fR \ \(em\ When the network provides CCITT standardized
  1702. telecommunications services, the service requirement for provision of in\(hyband 
  1703. tones/announcements is as indicated in the I.200\ Series of Recommendations. 
  1704. .bp
  1705. .PP
  1706. \fINote\ 2\fR \ \(em\ When the PROGRESS message is used, the user may initiate
  1707. call clearing as a result of the applied in\(hyband tone/announcement, 
  1708. according to the procedures specified in \(sc\ 5.3.3. 
  1709. .PP
  1710. \fINote\ 3\fR \ \(em\ The protocol currently described in \(sc 5.4 applies 
  1711. at the 
  1712. calling user\(hynetwork interface. The protocol to be applied at the internetwork 
  1713. interface and at the called user\(hynetwork interface requires further 
  1714. study. 
  1715. .RT
  1716. .sp 1P
  1717. .LP
  1718. 5.5
  1719.     \fIRestart procedure\fR 
  1720. .sp 9p
  1721. .RT
  1722. .PP
  1723. The restart procedure is used to return channels and interfaces to an idle 
  1724. condition. The procedure is usually invoked when the other side of the 
  1725. interface does not respond to other call control messages or a failure 
  1726. has 
  1727. occurred (e.g.\ following a data link failure, when a backup D\(hychannel 
  1728. can be 
  1729. used; or following the expiry of timer\ T308 due to the absence of response 
  1730. to a clearing message). 
  1731. .PP
  1732. \fINote\fR \ \(em\ Layer 3 procedures and resources associated with those 
  1733. data links with SAPI\ =\ \*Q0000 | 00\*U should be initialized by the restart 
  1734. procedures. 
  1735. .PP
  1736. When:
  1737. .RT
  1738. .LP
  1739.     a)
  1740.      both the user and the network are aware of the configuration of the interface; 
  1741. and 
  1742. .LP
  1743.     b)
  1744.      the interface is a basic access (Recommendation I.430\ [46]) where a 
  1745. point\(hyto\(hypoint configuration exists; or, 
  1746. .LP
  1747.     c)
  1748.     the interface is a primary rate access
  1749. (Recommendation\ I.431\ [27]);
  1750. .LP
  1751. then the user and the network shall implement the procedures of \(sc 5.5. 
  1752. In all other cases, the procedures of \(sc\ 5.5 are optional. 
  1753. .sp 1P
  1754. .LP
  1755. 5.5.1
  1756.     \fISending RESTART\fR 
  1757. .sp 9p
  1758. .RT
  1759. .PP
  1760. A RESTART message is sent by the network or user in order to return channels 
  1761. or interfaces to the Null state. The channel identification 
  1762. information element must be present in the RESTART message when a specified
  1763. channel, or interface other than the one containing the D\(hychannel, is to be
  1764. returned to the idle condition. Absence of the channel identification
  1765. information element indicates that the interface containing the D\(hychannel 
  1766. is to be restarted. 
  1767. .PP
  1768. Upon transmitting the RESTART message the sender enters the restart
  1769. request state, starts timer\ T316, and waits for a RESTART ACKNOWLEDGE 
  1770. message. Receipt of a RESTART ACKNOWLEDGE message stops timer\ T316, frees 
  1771. the channels and call reference values for reuse, and enters the Null state. 
  1772. .PP
  1773. If a RESTART ACKNOWLEDGE message is not received prior to expiry of
  1774. timer\ T316 one or more subsequent RESTART messages may be sent until a 
  1775. RESTART ACKNOWLEDGE message is returned. Meanwhile, no calls shall be placed 
  1776. or 
  1777. accepted over the channel or interface by the originator of the RESTART
  1778. message. A network shall limit the number of consecutive unsuccessful restart 
  1779. attempts to a default limit of two. When this limit is reached, the network 
  1780. shall make no further restart attempts. An indication will be provided 
  1781. to the appropriate maintenance entity. The channel or interface is considered 
  1782. to be in an out\(hyof\(hyservice condition until maintenance action has 
  1783. been taken. 
  1784. .PP
  1785. The RESTART and RESTART ACKNOWLEDGE message shall contain the global call 
  1786. reference value (all zero) to which the restart request state is 
  1787. associated. These messages are transferred via the appropriate point\(hyto\(hypoint 
  1788. data link in the multiple frame mode using the DL\(hyDATA\(hyREQUEST primitive. 
  1789. .RT
  1790. .sp 1P
  1791. .LP
  1792. 5.5.2
  1793.     \fIReceipt of RESTART\fR 
  1794. .sp 9p
  1795. .RT
  1796. .PP
  1797. Upon receiving a RESTART message the recipient shall enter the
  1798. restart state associated to the global call reference and start timer\ 
  1799. T317; it shall then initiate the appropriate internal actions to return 
  1800. the specified 
  1801. channels to the idle condition and call references to the Null state. Upon
  1802. completion of internal clearing, timer\ T317 shall be stopped and a RESTART
  1803. ACKNOWLEDGE message transmitted to the originator, and the Null state entered.
  1804. .PP
  1805. If timer T317 expires prior to completion of internal clearing an
  1806. indication shall be sent to the maintenance entity (i.e.\ a primitive should 
  1807. be transmitted to the system management entity). 
  1808. .bp
  1809. .PP
  1810. \fINote\ 1\fR \ \(em\ Even if all call references are in the Null state, 
  1811. and all channels are in the idle condition, the receiving entity shall 
  1812. transmit a 
  1813. RESTART ACKNOWLEDGE message to the originator upon receiving a RESTART
  1814. message.
  1815. .PP
  1816. \fINote\ 2\fR \ \(em\ If the RESTART message is sent by a user, the network 
  1817. shall return to the Null state only those Q.931 calls which are: 
  1818. .RT
  1819. .LP
  1820.     a)
  1821.      associated with the data link connection endpoint identifier (DLCI; see 
  1822. Recommendation\ Q.920); and 
  1823. .LP
  1824.     b)
  1825.     which correspond to the specified channel(s) or
  1826. interface.
  1827. .sp 1P
  1828. .LP
  1829. 5.6
  1830.     \fICall rearrangements\fR 
  1831. .sp 9p
  1832. .RT
  1833. .PP
  1834. The elements of procedure in this section provide for physical
  1835. layer and/or data link layer rearrangements after a call has entered the 
  1836. active state as defined in \(sc\ 2.2.1.5. The procedure is restricted to 
  1837. use on the same interface structure, and resumption on the same B\(hychannel. 
  1838. .PP
  1839. The activation of this procedure at a user\(hynetwork interface may
  1840. correspond to a number of possible events such as the following:
  1841. .RT
  1842. .LP
  1843.     a)
  1844.     physical disconnection of user equipment and reconnection;
  1845. .LP
  1846.     b)
  1847.     physical replacement of one user equipment by another;
  1848. .LP
  1849.     c)
  1850.     the human user moves from one equipment to another;
  1851. .LP
  1852.     d)
  1853.     suspension of call and its subsequent reactivation at the
  1854. same user equipment.
  1855. .PP
  1856. These procedures have only local significance; i.e. the invocation of call 
  1857. rearrangement affects only states at the originating end, and it does not 
  1858. affect any terminating states. 
  1859. .PP
  1860. The procedures in this section are described in terms of functional
  1861. messages and information elements.
  1862. .PP
  1863. If the procedures for call suspension in this section are not followed 
  1864. prior to the physical disconnection of the terminal from the interface, 
  1865. then 
  1866. the integrity of the call cannot be guaranteed by the network.
  1867. .RT
  1868. .sp 1P
  1869. .LP
  1870. 5.6.1
  1871.     \fICall suspension\fR 
  1872. .sp 9p
  1873. .RT
  1874. .PP
  1875. The procedure is initiated by the user, who shall: send a SUSPEND message 
  1876. containing the current call reference; start timer\ T319; and enter the 
  1877. suspend request state. The user may optionally include in this message 
  1878. a bit 
  1879. sequence (e.g.\ IA5\ characters) to be known by the application or human user,
  1880. and by the network, as the call identity for subsequent reconnection. Where 
  1881. no call identity information is included by the user, (e.g.\ the call identity 
  1882. information element is absent or empty) the network shall store this fact so
  1883. that resumption is possible only by a procedure conveying no call identity
  1884. information.
  1885. .PP
  1886. \fINote\fR \ \(em\ If the call identity information element is present with a
  1887. null length, the message shall be handled as if it was absent.
  1888. .PP
  1889. The default maximum length of the call identity value within the call identity 
  1890. information element is eight octets. If the network receives a call 
  1891. identity value longer than the maximum length supported, the network shall
  1892. truncate the call identity value to the maximum length; take the action
  1893. specified in \(sc\ 5.8.7 and continue processing.
  1894. .RT
  1895. .sp 1P
  1896. .LP
  1897. 5.6.2
  1898.     \fICall suspended\fR 
  1899. .sp 9p
  1900. .RT
  1901. .PP
  1902. Following the receipt of a SUSPEND message the network enters the suspend 
  1903. request state. After a positive validation of the received call 
  1904. identity the network shall: send a SUSPEND ACKNOWLEDGE message; and start
  1905. timer\ T307. (The value of T307 is specified in \(sc\ 9.1.)
  1906. .PP
  1907. At this time, the network shall consider the call reference to be
  1908. released and enter the Null state for that call reference. The call identity
  1909. associated with the suspended call has to be stored by the network and 
  1910. cannot be accepted for another suspension until it is released. 
  1911. .PP
  1912. The B\(hychannel involved in the connection will be reserved by the
  1913. network until reconnection of the call (or until a clearing cause occurs,
  1914. e.g.\ expiry of timer\ T307). A NOTIFY message with notification indicator\ 
  1915. No.\ 0 (user suspended) is sent to the other user. 
  1916. .PP
  1917. When the user receives the SUSPEND ACKNOWLEDGE message, the user
  1918. shall: stop timer\ T319; release the B\(hychannel and call reference; and enter
  1919. the Null state.
  1920. .PP
  1921. Following the receipt of the SUSPEND ACKNOWLEDGE, the user may
  1922. disconnect the underlying data link connection. In any case, if the user
  1923. physically disconnects from the interface without having disconnected the 
  1924. data link connection, standard data link layer procedures are started by 
  1925. the network side of the data link layer supervision, resulting in the release 
  1926. of the data link layer connection. 
  1927. .bp
  1928. .RT
  1929. .sp 1P
  1930. .LP
  1931. 5.6.3
  1932.     \fICall suspend error\fR 
  1933. .sp 9p
  1934. .RT
  1935. .PP
  1936. On receipt of a SUSPEND message, the network will respond by
  1937. sending a SUSPEND REJECT message with cause\ No.\ 84 \fIcall identity in 
  1938. use\fR if 
  1939. the information contained in the SUSPEND message is not sufficient to avoid
  1940. ambiguities on subsequent call re\(hyestablishment. This will apply, in
  1941. particular, when at a given user\(hynetwork interface, a SUSPEND message is
  1942. received with a call identity sequence already in use, or when the SUSPEND
  1943. message does not contain any call identity sequence and the null\(hyvalue call
  1944. identity is already allocated for that interface. On receipt of the SUSPEND
  1945. REJECT message, the user shall: stop timer\ T319; and return to the active
  1946. state. If timer\ T319 expires, the user shall: notify the user application; 
  1947. and return to the active state. 
  1948. .PP
  1949. In these cases the state of the call is not altered within the network 
  1950. (i.e. it remains in the active state). 
  1951. .RT
  1952. .sp 1P
  1953. .LP
  1954. 5.6.4
  1955.     \fICall re\(hyestablishment\fR 
  1956. .sp 9p
  1957. .RT
  1958. .PP
  1959. At the connection end where suspension was initiated, the user may request 
  1960. re\(hyestablishment of a call after physical reconnection of a terminal 
  1961. by sending a RESUME message containing the call identity exactly as that 
  1962. used at the time of call suspension; starting timer\ T318; and entering 
  1963. the resume 
  1964. request state. If the SUSPEND message did not include a call identity
  1965. information element, then the corresponding RESUME message shall also not
  1966. include a call identity information element. The call reference included 
  1967. in the RESUME message is chosen by the user according to the normal allocation 
  1968. of 
  1969. outgoing call reference (see \(sc\ 4.3).
  1970. .PP
  1971. On receipt of a RESUME message, the network enters the resume request state. 
  1972. After a positive validation of the call identity that relates to the 
  1973. suspended call containing a valid identity that relates to a currently
  1974. suspended call, the network shall: send a RESUME ACKNOWLEDGE message to the
  1975. user; release the call identity; stop timer\ T307 and enter the active state.
  1976. The RESUME ACKNOWLEDGE message shall specify the B\(hychannel reserved 
  1977. to the call by the network by means of the channel identification element, 
  1978. coded 
  1979. \fIB\(hychannel is indicated, no alternative is acceptable\fR .
  1980. .PP
  1981. The network shall also send a NOTIFY message with the notification
  1982. indicated \fIuser resumed\fR to the other user.
  1983. .PP
  1984. No memory of the previously received call identity sequence is kept by 
  1985. the network after sending the RESUME ACKNOWLEDGE message. This call identity 
  1986. is now available for another suspension. 
  1987. .PP
  1988. On receipt of the RESUME ACKNOWLEDGE message, the user shall: stop
  1989. timer\ T318 and enter the active state.
  1990. .RT
  1991. .sp 1P
  1992. .LP
  1993. 5.6.5
  1994.     \fICall resume errors\fR 
  1995. .sp 9p
  1996. .RT
  1997. .PP
  1998. If a received RESUME message cannot be actioned by the network
  1999. (e.g. as a result of an unknown call identity, a RESUME REJECT message 
  2000. shall be returned to the requesting user indicating one of the following 
  2001. causes:
  2002. .RT
  2003. .LP
  2004.     a)
  2005.     No. 83 \fIa suspended call exists, but this call identity\fR 
  2006. \fIdoes not\fR ;
  2007. .LP
  2008.     b)
  2009.     No. 85 \fIno call suspended\fR ; or,
  2010. .LP
  2011.     c)
  2012.     No. 86 \fIcall having the requested call identity\fR 
  2013. \fIhas been cleared\fR .
  2014. .PP
  2015. The call identity remains unknown. The call reference contained in the 
  2016. RESUME message is released by both the user and network side. Upon receipt 
  2017. of the RESUME REJECT message the user shall: stop timer\ T318; and enter 
  2018. the 
  2019. Null state.
  2020. .PP
  2021. If timer T307 expires the network shall initiate clearing of the
  2022. network connection with cause\ No.\ 102 \fIrecovery on timer expiry\fR 
  2023. ; discard the call identity; and release the reserved B\(hychannel. 
  2024. .PP
  2025. On release, the call identity can then be used for subsequent call
  2026. suspension. If before the expiry of timer\ T307 the call is cleared by the
  2027. remote user, the B\(hychannel reservation is released but the call identity 
  2028. may be preserved by some networks along with a clearing cause (e.g.\ cause\ 
  2029. No.\ 16 
  2030. \fInormal clearing\fR ).
  2031. .PP
  2032. If timer T318 expires, the user shall initiate internal call clearing with 
  2033. cause\ No.\ 102 \fIrecovery on timer expiry\fR , in accordance with 
  2034. \(sc\ 5.3.2 | ).
  2035. .RT
  2036. .sp 1P
  2037. .LP
  2038. 5.6.6
  2039.     \fIDouble suspension\fR 
  2040. .sp 9p
  2041. .RT
  2042. .PP
  2043. Simultaneous suspension of the call at both ends is possible. The procedures 
  2044. do not prevent this from occurring. If double suspensions are not 
  2045. desired the users must protect against this by other means; e.g.\ higher 
  2046. layer negotiation protocols. 
  2047. .bp
  2048. .RT
  2049. .sp 1P
  2050. .LP
  2051. 5.6.7
  2052.     \fICall re\(hyarrangement notification controlled by an NT2\fR 
  2053. .sp 9p
  2054. .RT
  2055. .PP
  2056. When the call rearrangement is controlled by the NT2, the
  2057. procedures shall be applied by the NT2 at reference point\ S. The NT2 shall
  2058. inform the remote user by sending a NOTIFY message described in \(sc\(sc\ 5.6.2
  2059. and\ 5.6.4 across reference point\ T.
  2060. .RT
  2061. .sp 1P
  2062. .LP
  2063. 5.7
  2064.     \fICall collisions\fR 
  2065. .sp 9p
  2066. .RT
  2067. .PP
  2068. Call collisions as such cannot occur at the network. Any
  2069. simultaneous incoming or outgoing calls are dealt with separately and assigned 
  2070. different call references. 
  2071. .PP
  2072. Channel selection conflicts may occur if an incoming call and outgoing 
  2073. call select the same channel. This is resolved by the network through channel 
  2074. selection mechanisms described in \(sc\(sc\ 5.1.2 and\ 5.2.2. 
  2075. .PP
  2076. In the case of such conflicts, the network shall give priority to the incoming 
  2077. call over the call request received from the user. It shall clear the outgoing 
  2078. call whenever the B\(hychannel cannot be allocated by the network or 
  2079. accepted by the user originating the call.
  2080. .PP
  2081. \fINote\fR \ \(em\ Some terminal adaptors supporting existing non\(hyvoice
  2082. terminals (e.g.\ X.21) may need to resolve double channel selection by 
  2083. clearing the incoming call and reattempting the outgoing call setup in 
  2084. order to satisfy the requirements of the interface at reference point\ 
  2085. R. 
  2086. .RT
  2087. .sp 1P
  2088. .LP
  2089. 5.8
  2090.     \fIHandling of error conditions\fR 
  2091. .sp 9p
  2092. .RT
  2093. .PP
  2094. All procedures transferring signalling information by using the
  2095. protocol discriminator of Q.931 user\(hynetwork call control messages are
  2096. applicable only to those messages which pass the checks described in \(sc\(sc\ 
  2097. 5.8.1 through\ 5.8.7. 
  2098. .PP
  2099. Detailed error handling procedures are implementation dependent and
  2100. may vary from network to network. However, capabilities facilitating the
  2101. orderly treatment of error conditions are provided for in this section and
  2102. shall be provided in each implementation.
  2103. .PP
  2104. Paragraphs 5.8.1 through 5.8.7 are listed in order of
  2105. precedence.
  2106. .RT
  2107. .sp 1P
  2108. .LP
  2109. 5.8.1
  2110.     \fIProtocol discrimination error\fR 
  2111. .sp 9p
  2112. .RT
  2113. .PP
  2114. When a message is received with a protocol discriminator coded
  2115. other than \fIQ.931 user\(hynetwork call control message\fR , that message 
  2116. shall be 
  2117. ignored. \*QIgnore\*U means to do nothing, as if the message had never been
  2118. received.
  2119. .RT
  2120. .sp 1P
  2121. .LP
  2122. 5.8.2
  2123.     \fIMessage too short\fR 
  2124. .sp 9p
  2125. .RT
  2126. .PP
  2127. When a message is received that is too short to contain a complete message 
  2128. type information element, that message shall be ignored. 
  2129. .RT
  2130. .sp 2P
  2131. .LP
  2132. 5.8.3
  2133.     \fICall reference error\fR 
  2134. .sp 1P
  2135. .RT
  2136. .sp 1P
  2137. .LP
  2138. 5.8.3.1
  2139.     \fIInvalid call reference format\fR 
  2140. .sp 9p
  2141. .RT
  2142. .PP
  2143. If the call reference information element octet 1, bits 5 through 8 do 
  2144. not equal\ 0000, then the message shall be ignored. 
  2145. .PP
  2146. If the call reference information element octet 1, bits 1 through 4
  2147. indicate a length greater than the maximum length supported by the receiving
  2148. equipment (see \(sc\ 4.3), then the message shall be ignored.
  2149. .RT
  2150. .sp 1P
  2151. .LP
  2152. 5.8.3.2
  2153.     \fICall reference procedural errors\fR 
  2154. .sp 9p
  2155. .RT
  2156. .LP
  2157.     a)
  2158.     Whenever any message except SETUP, RELEASE, RELEASE
  2159. COMPLETE, STATUS or RESUME is received specifying a call reference which 
  2160. is not recognized as relating to an active call or to a call in progress, 
  2161. clearing is initiated by sending a RELEASE message with cause\ No.\ 81 
  2162. \fIinvalid call\fR 
  2163. \fIreference value\fR and following the procedures in \(sc\ 5.3, specifying 
  2164. the call 
  2165. reference in the received message.
  2166. .LP
  2167.     Alternatively, the receiving entity may send a RELEASE
  2168. COMPLETE message with cause\ No.\ 81 \fIinvalid call reference value\fR 
  2169. and remain in the Null state. 
  2170. .bp
  2171. .LP
  2172.     b)
  2173.     When a RELEASE message is received that specified a call
  2174. reference which is not recognized as relating to an active call or to a 
  2175. call in progress, a RELEASE message with cause\ No.\ 81 \fIinvalid call 
  2176. reference value\fR is returned specifying the call reference in the received 
  2177. message. 
  2178. .LP
  2179.     c)
  2180.     When a RELEASE COMPLETE message is received specifying a
  2181. call reference which is not recognized as relating to an active call or to a
  2182. call in progress, no action should be taken.
  2183. .LP
  2184.     d)
  2185.      When a SETUP or RESUME message is received spcifying a call reference 
  2186. which is not recognized as relating to an active call or to a call in progress, 
  2187. and with a call reference flag incorrectly set to \*Q1\*U, this message 
  2188. shall be ignored. 
  2189. .LP
  2190.     e)
  2191.      When a SETUP message is received specifying a call reference which is 
  2192. recognized as relating to an active call or to a call in progress, 
  2193. this SETUP message shall be ignored.
  2194. .LP
  2195.     f
  2196. )
  2197.      When any message except RESTART, RESTART ACKNOWLEDGE, or STATUS is received 
  2198. using the global call reference, no action should be 
  2199. taken on this message and a STATUS message using the global call reference 
  2200. with a call state indicating the current state associated with the global 
  2201. call 
  2202. reference and cause\ No.\ 81 \fIinvalid call reference\fR shall be returned.
  2203. .LP
  2204.     g)
  2205.     When a STATUS message is received specifying a call
  2206. reference which is not recognized as relating to an active call or to a 
  2207. call in progress, the procedures of \(sc\ 5.8.11 shall apply. 
  2208. .sp 1P
  2209. .LP
  2210. 5.8.4
  2211.     \fIMessage type or message sequence errors\fR 
  2212. .sp 9p
  2213. .RT
  2214. .PP
  2215. Whenever an unexpected message, except RELEASE or RELEASE COMPLETE, or 
  2216. unrecognized message is received in any state other than the Null state, 
  2217. a STATUS message shall be returned with cause\ No.\ 98 \fImessage not compatible\fR 
  2218. \fIwith call state or message type non\(hyexistent or not implemented\fR 
  2219. and the 
  2220. corresponding diagnostic. If a network or user can distinguish between
  2221. unimplemented (or non\(hyexistent) message types and implemented message types
  2222. which are incompatible with the call state, then a STATUS message may be 
  2223. sent with one of the following causes: 
  2224. .RT
  2225. .LP
  2226.     a)
  2227.     cause No. 97 \fImessage type non\(hyexistent or not\fR 
  2228. \fIimplemented\fR ; or,
  2229. .LP
  2230.     b)
  2231.     cause No. 101 \fImessage not compatible with call\fR 
  2232. \fIstate\fR .
  2233. .PP
  2234. Alternatively, a STATUS ENQUIRY message may be sent requesting the call 
  2235. state of the entity (see \(sc\ 5.8.10). No change in state shall be made 
  2236. in 
  2237. either case at this time.
  2238. .PP
  2239. However, two exceptions to this procedure exist. The first exception is 
  2240. when the network or the user receives an unexpected RELEASE message (e.g.\ 
  2241. if the DISCONNECT message was corrupted by undetected transmission errors). 
  2242. In 
  2243. this case no STATUS or STATUS ENQUIRY message is sent. Whenever the network
  2244. receives an unexpected RELEASE message, the network shall: disconnect and
  2245. release the B\(hychannel; clear the network connection and the call to 
  2246. the remote user with the cause in the RELEASE message sent by the user 
  2247. or, if not 
  2248. included, cause\ No.\ 31 \fInormal, unspecified\fR ; return a RELEASE COMPLETE 
  2249. message to the user; release the call reference; stop all timers; and enter 
  2250. the Null 
  2251. state. Whenever the user receives an unexpected RELEASE message, the user
  2252. shall: disconnect and release the B\(hychannel; return a RELEASE COMPLETE 
  2253. message to the network; release the call reference; stop all timers; and 
  2254. enter the Null state. 
  2255. .PP
  2256. The second exception is when the network or the user receives an
  2257. unexpected RELEASE COMPLETE message. Whenever the network receives an
  2258. unexpected RELEASE COMPLETE message, the network shall: disconnect and 
  2259. release the B\(hychannel; clear the network connection and the call to 
  2260. the remote user 
  2261. with the cause indicated by the user or, if not included, cause\ No.\ 111
  2262. \fIprotocol error, unspecified\fR ; release the call reference; stop all 
  2263. timers; and enter the Null state. Whenever the user receives an unexpected 
  2264. RELEASE COMPLETE message, the user shall: disconnect and release the B\(hychannel; 
  2265. release the call reference; stop all timers; and enter the Null state. 
  2266. .RT
  2267. .sp 1P
  2268. .LP
  2269. 5.8.5
  2270.     \fIGeneral information element errors\fR 
  2271. .sp 9p
  2272. .RT
  2273. .PP
  2274. The general information element error procedures may also apply to information 
  2275. elements in codesets other than\ 0. In that case, the diagnostics in the 
  2276. cause information element may indicate information elements other than 
  2277. those in codeset\ 0 by applying the locking or non\(hylocking shift procedures 
  2278. as described in \(sc\ 4.5. 
  2279. .bp
  2280. .RT
  2281. .sp 1P
  2282. .LP
  2283. 5.8.5.1
  2284.     \fIInformation element out of sequence\fR 
  2285. .sp 9p
  2286. .RT
  2287. .PP
  2288. A variable length information element which has a code value lower than 
  2289. the code value of the variable length information element preceding it 
  2290. shall be considered as an out of sequence information element.
  2291. .PP
  2292. If the network or user receives a message containing an out of
  2293. sequence information element, it may ignore this information element and
  2294. continue to process the message. If this information is mandatory, and the
  2295. network or user chooses to ignore this out of sequence information element,
  2296. then the error handling procedure for missing mandatory information elements 
  2297. as described in \(sc\ 5.8.6.1 shall be followed. If the ignored information 
  2298. element is non\(hymandatory, the receiver continues to process the message. 
  2299. .PP
  2300. \fINote\fR \ \(em\ Some implementations may choose to process all the
  2301. information elements received in a message regardless of the order in which
  2302. they are placed.
  2303. .RT
  2304. .sp 1P
  2305. .LP
  2306. 5.8.5.2
  2307.     \fIDuplicated information elements\fR 
  2308. .sp 9p
  2309. .RT
  2310. .PP
  2311. If an information element is repeated in a message in which
  2312. repetition of the information element is not permitted, only the contents of
  2313. information element appearing first shall be handled and all subsequent
  2314. repetitions of the information element shall be ignored. When repetition of
  2315. information elements is permitted, only the contents of permitted information 
  2316. elements shall be handled. If the limit on repetition of information elements 
  2317. is exceeded, the contents of information elements appearing first up to 
  2318. the 
  2319. limit of repetitions shall be handled and all subsequent repetitions of the
  2320. information element shall be ignored.
  2321. .RT
  2322. .sp 2P
  2323. .LP
  2324. 5.8.6
  2325.     \fIMandatory information element errors\fR 
  2326. .sp 1P
  2327. .RT
  2328. .sp 1P
  2329. .LP
  2330. 5.8.6.1
  2331.     \fIMandatory information element missing\fR 
  2332. .sp 9p
  2333. .RT
  2334. .PP
  2335. When a message other than SETUP, DISCONNECT, RELEASE or RELEASE
  2336. COMPLETE is received which has one or more mandatory information elements
  2337. missing, no action should be taken on the message and no state change should
  2338. occur. A STATUS message is then returned with cause\ No.\ 96 \fImandatory\fR 
  2339. \fIinformation element is missing\fR .
  2340. .PP
  2341. When a SETUP or RELEASE message is received which has one or more
  2342. mandatory information elements missing, a RELEASE COMPLETE message with
  2343. cause\ No.\ 96 \fImandatory information element is missing\fR shall be 
  2344. returned. 
  2345. .PP
  2346. When a DISCONNECT message is received with the cause information
  2347. element missing, the actions taken shall be the same as if a DISCONNECT 
  2348. message with cause\ No.\ 31 \fInormal, unspecified\fR was received (see 
  2349. \(sc\ 5.3), with the 
  2350. exception that the RELEASE message sent on the local interface contains
  2351. cause\ No.\ 96 \fImandatory information element is missing\fR .
  2352. .PP
  2353. When a RELEASE COMPLETE message is received with a cause information element 
  2354. missing, it will be assumed that a RELEASE COMPLETE message was 
  2355. received with cause\ No.\ 31 \fInormal, unspecified\fR .
  2356. .RT
  2357. .sp 1P
  2358. .LP
  2359. 5.8.6.2
  2360.     \fIMandatory information element content error\fR 
  2361. .sp 9p
  2362. .RT
  2363. .PP
  2364. When a message other than SETUP, DISCONNECT, RELEASE, or RELEASE
  2365. COMPLETE is received which has one or more mandatory information elements 
  2366. with invalid content, no action should be taken on the message and no state 
  2367. change should occur. A STATUS message is then returned with cause\ No.\ 
  2368. 100 \fIinvalid\fR \fIinformation element contents\fR . 
  2369. .PP
  2370. When a SETUP or RELEASE message is received which has one or more
  2371. mandatory information elements with invalid content, a RELEASE COMPLETE 
  2372. message with cause No.\ 100 \fIinvalid information element contents\fR 
  2373. shall be returned. 
  2374. .PP
  2375. When a DISCONNECT message is received with invalid content of the
  2376. cause information element, the actions taken shall be the same as if a
  2377. DISCONNECT message with cause\ No.\ 31 \fInormal, unspecified\fR was received 
  2378. (see 
  2379. \(sc\ 5.3), with the exception that the RELEASE message sent on the local 
  2380. interface contains cause\ No.\ 100 \fIinvalid information element contents\fR 
  2381. . 
  2382. .PP
  2383. When a RELEASE COMPLETE message is received with invalid content of
  2384. the cause information element, it will be assumed that a RELEASE COMPLETE
  2385. message was received with cause\ No.\ 31 \fInormal, unspecified\fR .
  2386. .PP
  2387. Information elements with a length exceeding the maximum length (given 
  2388. in \(sc\ 3) will be treated as information element with content error. 
  2389. .RT
  2390. .sp 1P
  2391. .LP
  2392. 5.8.7
  2393.     \fINon\(hymandatory information element errors\fR 
  2394. .sp 9p
  2395. .RT
  2396. .PP
  2397. The following sections identify actions on information elements not recognized 
  2398. as mandatory. 
  2399. .bp
  2400. .RT
  2401. .sp 1P
  2402. .LP
  2403. 5.8.7.1
  2404.     \fIUnrecognized information element\fR 
  2405. .sp 9p
  2406. .RT
  2407. .PP
  2408. When a message is received which has one or more unrecognized
  2409. information elements, the receiving entity shall check whether any are 
  2410. encoded to indicate \fIcomprehension required\fR (refer to Table\ 4\(hy3/Q.931 
  2411. for information element identifiers reserved with this meaning). If any 
  2412. unrecognized 
  2413. information element is encoded to indicate \*Qcomprehension required\*U, 
  2414. then the procedures in \(sc\ 5.8.6.1 are followed; i.e.\ as if a \*Qmissing 
  2415. mandatory 
  2416. information element\*U error condition had occurred. If all unrecognized
  2417. information elements are \fInot\fR encoded to indicate \*Qcomprehension 
  2418. required\*U, 
  2419. then the receiving entity shall proceed as follows:
  2420. .PP
  2421. Action shall be taken on the message and those information elements
  2422. which are recognized and have valid content. When the received message 
  2423. is other than DISCONNECT, RELEASE or RELEASE COMPLETE, a STATUS message 
  2424. may be returned containing one cause information element. The STATUS message 
  2425. indicates the call state in which the receiver detected the error. The 
  2426. cause information element shall contain cause\ No.\ 99 \fIinformation element 
  2427. non\(hyexistent or not\fR 
  2428. \fIimplemented\fR , and the diagnostic field, if present, shall contain the
  2429. information element identifier for each information element which was
  2430. unrecognized.
  2431. .PP
  2432. Subsequent actions are determined by the sender of the unrecognized
  2433. information elements. If a clearing message contains one or more unrecognized 
  2434. information elements, the error is reported to the local user in the following 
  2435. manner: 
  2436. .RT
  2437. .LP
  2438.     a)
  2439.      When a DISCONNECT message is received which has one or more unrecognized 
  2440. information elements, a RELEASE message with cause\ No.\ 99, 
  2441. \fIinformation element non\(hyexistent or not implemented\fR , shall be 
  2442. returned. The cause information element diagnostic field, if present, shall 
  2443. contain the 
  2444. information element identifier for each information element which was
  2445. unrecognized.
  2446. .LP
  2447.     b)
  2448.     When a RELEASE message is received which has one or more
  2449. unrecognized information elements, a RELEASE COMPLETE message with
  2450. cause\ No.\ 99, \fIinformation element non\(hyexistent or not implemented\fR 
  2451. , shall be returned. The cause information element diagnostic field, if 
  2452. present, shall 
  2453. contain the information element identifier for each information element 
  2454. which was unrecognized. 
  2455. .LP
  2456.     c)
  2457.      When a RELEASE COMPLETE message is received which has one or more unrecognized 
  2458. information elements, no action shall be taken on the 
  2459. unrecognized information.
  2460. .PP
  2461. \fINote\fR \ \(em\ The diagnostic(s) of cause No. 99 facilitates the
  2462. decision in selecting an appropriate recovery procedure at the reception 
  2463. of a STATUS message. Therefore, it is recommended to provide cause\ No.\ 
  2464. 99 with 
  2465. diagnostic(s) if a layer\ 3 entity expects the peer to take an appropriate
  2466. action at the receipt of a STATUS message, although inclusion of diagnostic(s) 
  2467. is optional. 
  2468. .sp 1P
  2469. .LP
  2470. 5.8.7.2
  2471.     \fINon\(hymandatory information element content error\fR 
  2472. .sp 9p
  2473. .RT
  2474. .PP
  2475. When a message is received which has one or more non\(hymandatory
  2476. information elements with invalid content, action shall be taken on the 
  2477. message and those information elements which are recognized and have valid 
  2478. content. A STATUS message may be returned containing one cause information 
  2479. element. The 
  2480. STATUS message indicates the call state in which the receiver detected the
  2481. error. The cause information element shall contain cause\ No.\ 100 \fIinvalid\fR 
  2482. \fIinformation element contents\fR , and the diagnostic field, if present, 
  2483. shall 
  2484. contain the information element identifier for each information element 
  2485. which has invalid contents. 
  2486. .PP
  2487. Information elements with a length exceeding the maximum length (given 
  2488. in \(sc\ 3) will be treated as an information element with content error. 
  2489. But for access information elements (see Annex\ G; e.g.\ user\(hyuser information 
  2490. element, called party subaddress information element), cause\ No.\ 43 \fIaccess\fR 
  2491. \fIinformation discarded\fR is used instead of cause\ No.\ 100 \fIinvalid 
  2492. information\fR \fIelement contents\fR . However, in some networks, access 
  2493. information elements may be truncated and processed. 
  2494. .RT
  2495. .sp 1P
  2496. .LP
  2497. 5.8.8
  2498.     \fIData link reset\fR 
  2499. .sp 9p
  2500. .RT
  2501. .PP
  2502. Whenever a Q.931 entity is informed of a spontaneous data link
  2503. layer reset by means of the DL\(hyESTABLISH\(hyINDICATION primitive, the 
  2504. following 
  2505. procedures apply:
  2506. .RT
  2507. .LP
  2508.     a)
  2509.     For calls in the overlap sending and overlap receiving
  2510. states, the entity shall initiate clearing by sending a DISCONNECT message 
  2511. with cause\ No.\ 41 \fItemporary failure\fR , and following the procedures 
  2512. of \(sc\ 5.3. 
  2513. .LP
  2514.     b)
  2515.     For calls in the disestablishment phase (states N11, N12,
  2516. N19, N22, U11, U12 and U19), no action shall be taken.
  2517. .LP
  2518.     c)
  2519.      Calls in the establishment phase (states N1, N3, N4, N6, N7, N8, N9, 
  2520. U1, U3, U4, U6, U7, U8 and U9) and in the active, suspend request, and 
  2521. resume request states shall be maintained according to the procedures contained 
  2522. in other parts of \(sc\ 5. 
  2523. .bp
  2524. .sp 1P
  2525. .LP
  2526. 5.8.9
  2527.     \fIData link failure\fR 
  2528. .sp 9p
  2529. .RT
  2530. .PP
  2531. Whenever a Q.931 entity is notified by its data link entity via the DL\(hyRELEASE\(hyINDICATION 
  2532. primitive that there is a data link layer malfunction, 
  2533. the following procedure shall apply:
  2534. .RT
  2535. .LP
  2536.     a)
  2537.      The calls in the overlap sending or overlap receiving states shall be 
  2538. cleared internally. For any call without a timer running (see \(sc\ 9), 
  2539. a timer\ T309 shall be started. 
  2540. .LP
  2541.      \fINote\fR \ \(em\ If timer T309 is already running, it shall not be 
  2542. restarted. 
  2543. .LP
  2544.     b)
  2545.     The Q.931 entity may request layer 2 reestablishment by
  2546. sending a DL\(hyESTABLISH\(hyREQUEST primitive if a call is not in the 
  2547. Null state. 
  2548. Otherwise, the Q.931 entity may clear internally.
  2549. .LP
  2550.      \fINote\fR \ \(em\ If the transfer mode of the call is circuit\(hymode, 
  2551. the Q.931 entity may clear the calls. If the transfer mode of the call 
  2552. is 
  2553. packet\(hymode and layer\ 1 is recognized as normal in spite of the data link
  2554. failure, the Q.931 entity shall not clear the call and shall request data 
  2555. link reestablishment. 
  2556. .LP
  2557.     When informed of layer 2 reestablishment by means of the
  2558. DL\(hyESTABLISH\(hyCONFIRM primitive, the following procedure shall apply:
  2559. .LP
  2560.     1)
  2561.     Stop timer T309.
  2562. .LP
  2563.     2)
  2564.     Optionally, a STATUS message may also be sent to
  2565. report the current call state to the peer entity. Alternatively, a STATUS
  2566. ENQUIRY message can be sent to verify the call state of the peer entity.
  2567. .LP
  2568.     If timer T309 expires prior to data link reestablishment,
  2569. the network shall: clear the network connection and call to the remote user
  2570. with cause\ No.\ 27 \fIdestination out of order\fR ; disconnect and release the
  2571. B\(hychannel; release the call reference; and enter the Null state.
  2572. .PP
  2573. When a backup D\(hychannel is available, the procedures in Annex\ F
  2574. may be used.
  2575. .PP
  2576. \fINote\fR \ \(em\ The implementation of timer T309 in the user side is
  2577. optional. If timer\ T309 expires prior to data link reestablishment, the user
  2578. shall: clear an attached connection (if any) with cause\ No.\ 27 \fIdestination\fR 
  2579. \fIout of order\fR ; disconnect and release the B\(hychannel; release the 
  2580. call 
  2581. reference; and enter the Null state.
  2582. .RT
  2583. .sp 1P
  2584. .LP
  2585. 5.8.10
  2586.     \fIStatus enquiry procedure\fR 
  2587. .sp 9p
  2588. .RT
  2589. .PP
  2590. Whenever an entity wishes to check the correctness of a call state at a 
  2591. peer entity, a STATUS ENQUIRY message may be sent requesting the call 
  2592. state. This may, in particular, apply to procedural error conditions described 
  2593. in \(sc\(sc\ 5.8.8 and\ 5.8.9. 
  2594. .PP
  2595. Upon sending the STATUS ENQUIRY message, timer T322 shall be started in 
  2596. anticipation of receiving a STATUS message. While timer T322 is running, 
  2597. only one outstanding request for call state information shall exist. Therefore, 
  2598. if timer\ T322 is already running, it shall not be restarted. If a clearing 
  2599. message is received before timer\ T322 expires, timer\ T322 shall be stopped, 
  2600. and call clearing shall continue. 
  2601. .PP
  2602. Upon receipt of a STATUS ENQUIRY message, the receiver shall respond with 
  2603. a STATUS message, reporting the current call state and cause\ No.\ 30 
  2604. \fIresponse to STATUS ENQUIRY\fR or No.\ 97 \fImessage type non\(hyexistent 
  2605. or not\fR 
  2606. \fIimplemented\fR (see \(sc\ 5.8.4). Receipt of the STATUS ENQUIRY message 
  2607. does not 
  2608. result in a state change.
  2609. .PP
  2610. The sending or receipt of the STATUS message in such a situation will not 
  2611. directly affect the call state of either the sender or receiver. The side 
  2612. having received the STATUS message shall inspect the cause information 
  2613. element. If the STATUS message contains cause\ No.\ 97 \fImessage type 
  2614. non\(hyexistent or not\fR \fIimplemented\fR , timer\ T322 shall continue 
  2615. to time for an explicit response to 
  2616. the STATUS ENQUIRY message. If a STATUS message is received that contains
  2617. cause\ No.\ 30 \fIresponse to status enquiry\fR , timer\ T322 shall be 
  2618. stopped and the appropriate actiont taken, based on the information in 
  2619. that STATUS message, 
  2620. relative to the current state of the receiver. If timer\ T322 expires and a
  2621. STATUS message with cause\ No.\ 97 \fImessage type non\(hyexistent or not\fR 
  2622. \fIimplemented\fR was received, the appropriate action shall be taken, 
  2623. based on the information in that STATUS message, relative to the current 
  2624. call state of the receiver. 
  2625. .PP
  2626. These further \fIappropriate actions\fR are implementation dependent.
  2627. However, the actions prescribed in the following section shall apply.
  2628. .bp
  2629. .PP
  2630. If timer T322 expires, and no STATUS message was received, the STATUS ENQUIRY 
  2631. message may be retransmitted one or more times until a response is 
  2632. received. The number of times the STATUS ENQUIRY message is retransmitted 
  2633. as an implementation dependent value. The call shall be cleared to the 
  2634. local 
  2635. interface with cause\ No.\ 41, \fItemporary failure\fR , if the STATUS 
  2636. ENQUIRY is 
  2637. retransmitted the maximum number of times. If appropriate, the network shall
  2638. also clear the network connection, using cause\ No.\ 41, \fItemporary\fR 
  2639. \fIfailure\fR .
  2640. .RT
  2641. .sp 1P
  2642. .LP
  2643. 5.8.11
  2644.     \fIReceiving a STATUS message\fR 
  2645. .sp 9p
  2646. .RT
  2647. .PP
  2648. On receipt of a STATUS message reporting an incompatible state, the receiving 
  2649. entity shall: 
  2650. .RT
  2651. .LP
  2652.     a)
  2653.      clear the call by sending the appropriate clearing message with cause\ 
  2654. No.\ 101 \fImessage not compatible with call state\fR ; or, 
  2655. .LP
  2656.     b)
  2657.     take other actions which attempt to cover from a mismatch
  2658. and which are an implementation option.
  2659. .PP
  2660. Except for the following rules, the determination of which states are incompatible 
  2661. is left as an implementation decision: 
  2662. .LP
  2663.     a)
  2664.     If a STATUS message indicating any call state except the
  2665. Null state is received in the Null state, then the receiving entity shall
  2666. either:
  2667. .LP
  2668.     1)
  2669.      send a RELEASE message with cause No. 101 \fImessage\fR \fInot compatible 
  2670. with call state\fR ; and then follow the procedures of \(sc\ 5.3; or, 
  2671. .LP
  2672.     2)
  2673.     send a RELEASE COMPLETE message with cause No. 101
  2674. \fImessage not compatible with call state\fR ; and remain in the Null state.
  2675. .LP
  2676.     b)
  2677.     If a STATUS message indicating any call state except the
  2678. Null state is received in the release request state, no action shall be taken.
  2679. .LP
  2680.     c)
  2681.      If a STATUS message, indicating the Null state, is received in any state 
  2682. except the Null state, the receiver shall release all resources 
  2683. and move into the Null state.
  2684. .PP
  2685. When in the Null state, the receiver of a STATUS message
  2686. indicating the Null state shall take no action other than to discard the
  2687. message and shall remain in the Null state.
  2688. .PP
  2689. A STATUS message may be received indicating a compatible call
  2690. state but containing one of the following causes:
  2691. .RT
  2692. .LP
  2693.     i)
  2694.     No. 96\ 
  2695. \fImandatory information element is missing\fR ;
  2696. .LP
  2697.     ii)
  2698.     No. 97\ 
  2699. \fImessage type non\(hyexisting or not implemented;\fR 
  2700. .LP
  2701.     iii)
  2702.     No. 99\ 
  2703. \fIinformation element non\(hyexistent or not\fR 
  2704. \fIimplemented\fR ; or
  2705. .LP
  2706.     iv)
  2707.     No. 100 \fIinvalid information element contents\fR .
  2708. .PP
  2709. In this case the actions to be taken are an implementation option. If other 
  2710. procedures are not defined, the receiver shall clear the call with the 
  2711. appropriate procedure defined in \(sc\ 5.3, using the cause specified in 
  2712. the 
  2713. received STATUS message.
  2714. .PP
  2715. On receipt of a STATUS message specifying the global call reference
  2716. and reporting an incompatible state in the restart request or restart state,
  2717. the receiving Q.931 entity shall inform layer management and take no further
  2718. action on this message.
  2719. .PP
  2720. When in the null state, then on receipt of a STATUS message with the global 
  2721. call reference no action shall be taken. 
  2722. .PP
  2723. \fINote\fR \ \(em\ Further actions as a result of higher layer activity (e.g.
  2724. system or layer management) and implementation dependent (including the
  2725. retransmission of RESTART).
  2726. .PP
  2727. Except for the above case, the error handling procedures when
  2728. receiving a STATUS message specifying the global call reference are an
  2729. implementation option.
  2730. .RT
  2731. .sp 1P
  2732. .LP
  2733. 5.9
  2734.     \fIUser notification procedure\fR 
  2735. .sp 9p
  2736. .RT
  2737. .PP
  2738. This procedure allows the network to notify a user of any
  2739. appropriate call\(hyrelated event during the active state of a call. It also
  2740. allows a user to notify the remote user of any appropriate call\(hyrelated 
  2741. event during the active state of a call by sending a NOTIFY message containing 
  2742. a 
  2743. notify indicator to the network; upon receipt of this message, the network 
  2744. must send a NOTIFY message containing the same notify indicator to the 
  2745. other user 
  2746. involved in the call. No state change occurs at any of the interface sides
  2747. following the sending or the receipt of this message.
  2748. .RT
  2749. .LP
  2750. .bp
  2751.