5i' SECTION 6 RADIOTELEX INTERWORKING Recommendation U.60 GENERAL REQUIREMENTS TO BE MET IN INTERFACING THE INTERNATIONAL TELEX NETWORK WITH MARITIME SATELLITE SYSTEMS (Geneva, 1980; amended at Malaga-Torremolinos, 1984) The CCITT, considering (a) that, with fully automatic working between subscribers in the international telex service, it is desirable that the inter- face between the international telex network and maritime satellite systems be defined; (b) that the CCIR is charged with the task of making Recommen- dations relating to the radio path of maritime satellite systems; (c) that explanation of the detail of the interface between the international telex network and maritime satellite systems would be of assistance to the CCIR; (d) that Recommendation U.61 specifies the detailed interface requirements, unanimously recommends (1) that maritime satellite systems should be capable of interfacing the international telex network with one or more sig- nalling systems in accordance with: - Recommendation U.1: Signalling conditions to be applied in the international telex service (type A and type B sig- nalling); - Recommendation U.11: Telex and gentex signalling on intercontinental circuits used for intercontinental automatic transit traffic (type C signalling); - Recommendation U.12: Terminal and transit con- trol signalling system for telex and similar services on interna- tional circuits (type D signalling); (2) that type D signalling (Recommendation U.12) and, as a second choice, type C signalling (Recommendation U.11) are the pre- ferred signalling systems, when they are available within the national boundaries, for the reasons given in Annex A; (3) that as the maritime signalling from the ship to the coast earth station is in the same relationship as the connection from the subscriber to the originating exchange in the international network, it is necessary that the transit delays inherent in the maritime system should be considered in conjunction with the stan- dards recommended for the international network. (4) that the access of ship earth stations to store-and-forward units, if provided, should be in accordance with the relevant Series F and U Recommendations on international store-and-forward units. ANNEX A (to Recommendation U.60) Signalling systems types C and D A.1 These signalling systems have been developed in CCITT to permit the maximum utilization of the international telex network as well as to simplify the interface problems that exist between Administrations using different signalling systems within their national boundaries. In particular, types C and D signalling sys- tems, which use telex destination codes in accordance with Recommendation F.69 [1], are of assistance in solving the problems of routing to and from maritime satellite systems where multiple access techniques are employed. A.2 Type C signalling (Recommendation U.11) facilitates the use of improved techniques for switching traffic in the interna- tional network. In particular: a) it permits any telegraph circuit capable of car- rying International Telegraph Alphabet No. 2 (ITA 2) to be used without the need to convert supervisory signals to a form capable of being carried by the circuit; b) it permits the automatic testing of the ability of the international circuit to transmit teleprinter characters before the call is established to the distant subscriber; c) it permits the detection of head-on collision of calls and thus permits service protocols to be established in handling such collisions. It may be noted that head-on collisions may occur on telegraph circuits that are operated in the bothway mode due to the fact that the calling signal takes a finite time, depending upon the nature of the transmission path, before the receiving end of the circuit detects the seizure from the outgoing end; d) it permits the efficient use of the interna- tional network with particular reference to the most economical use of automatic alternative routing and, by providing transit centre identification, permits full flexibility in routing as well as international accounting and subscriber billing. A.3 Type D signalling (Recommendation U.12) facilitates the introduction into the international network of the following facil- ities (in addition to the advantages mentioned in S A.2 above): a) user groups; b) network identification signals; c) identification of the calling station without the necessity of using the WRU signal; d) identification of a call relating to service matters, which the international network carries as a non-chargeable call. Reference [1] CCITT Recommendation Plan for telex destination codes , Rec. F.69. Recommendation U.61 DETAILED REQUIREMENTS TO BE MET IN INTERFACING THE INTERNATIONAL TELEX NETWORK WITH MARITIME SATELLITE SYSTEMS (Geneva, 1980; amended at Malaga-Torremolinos, 1984) The CCITT, considering (a) that fully automatic working between subscribers in the international telex service and subscribers to a radiotelex service provided by a maritime satellite system is technically possible; (b) Recommendation U.60, which gives the general requirements to be met in interfacing the international telex network with mari- time satellite systems, unanimously recommends 1 Maritime satellite systems should be capable of detecting the head-on collision condition at the coast earth station between a ship earth station request for call and a terrestrially ori- ginated call for that particular ship earth station and should: - permit the ship-originated call to be connected to the international telex network; and - terminate the call from the international telex network with an appropriate telex service signal (OCC ) and a clear (Recommendation F.60 [1]). 2 Should the head-on collision condition occur in the connec- tions in the terrestrial network between the coast earth station and the telex exchange, then the normal procedures in accordance with the appropriate Series U Recommendations (U.12, S 3.3, U.11, S 2, U.1 S 12.2) should prevail. 3 A call-connected signal or a telex service signal and clear shall be returned as soon as possible after the receipt of the end-of-selection character at the coast earth station for shore-originated calls. The signal return delay shall not exceed 35 seconds. Note - For type C signalling (Recommendation U.11) the end-of-selection (EOS) character is combination No. 26 (+ ) in International Telegraph Alphabet No. 2. For type D signalling (Recommendation U.12) the EOS is character No. 11 in the Control Signalling Code (CSC). For signalling to Recommendation U.1, this signal shall be combination No. 26 (+ ) in International Telegraph Alphabet No. 2. 4 The maritime satellite system returns to the subscriber in the terrestrial network the service signal DER (Recommendation F.60 [1]), followed by a clearing signal when the maritime satellite system detects: - that the ship's station (teleprinter, control logic, radio equipment) is faulty; - failure of the answer-back from the ship's tele- printer. 5 At the termination of the call the requirements of the clearing and clear-confirmation signals shall apply to and from the international network (Recommendations U.1, U.11, U.12); the mari- time satellite system may use different timings in the directions to and from the ship. It is preferred that the total times for such signal exchanges should have a minimum time addition to that quoted for the international network. Note - Automatic calling equipment and subscribers in the international telex network may attempt, under certain conditions, to place a follow-on call to the same ship. Under conditions of long clear and clear-confirmation cycle times, such calls will not be successful. 6 In the first generation INMARSAT system, telex characters are transmitted in synchronous channels using 6-unit frames. A telex character is thus sent as one start element followed by the five information elements of International Telegraph Alphabet No. 2. Speed differences between the on-board teleprinter and the satellite circuit are compensated for by occasionally inserting six elements of Z polarity, i.e., whenever a frame is to be sent on the synchronous channel and there is no complete telex character available. When the characters are retransmitted into the telex network, a stop element nominally 1.5 units long is added. There- fore, a period of Z polarity equal to the duration of a telex char- acter may occasionally appear in the data stream. 6.1 The design of the equipment interfacing the international network should preferably ensure the following: 6.1.1 When type C signalling is employed to connect into the international network, either: - the class-of-traffic and selection signals should all be transmitted into the international network at cadence speed without any periods of Z polarity between the 7 1/2-unit charac- ters; or - the class-of-traffic signal, the class-of-traffic-check signal, the 2 or 3 digits of the destination code of the called network and the first two digits of the called station should be transmitted as a complete block at cadence speed without any periods of Z polarity between the 7 1/2-unit charac- ters. The remaining selection signals for the called number and the EOS signal (+ ) may be transmitted with periods of Z polarity, pro- viding that the signals are not delayed by more than 4 seconds. 6.1.2 When type D signalling is employed to connect into the international network, the class-of-traffic signal(s) or network selection signals and selection signals should be transmitted as a complete block at cadence speed without periods of Z polarity between the Control Signalling Code (CSC) characters. 6.1.3 If these options cannot be exercised, then the provi- sions of Recommendation U.11, S 13, Recommendation U.12, S 3.6 or Recommendation U.1, S 6.6 shall apply. 6.2 When operation to automatic terminals, store-and-forward units, etc., is required, it should be noted that periods of Z polarity may occur within an answerback and text during transmis- sion at cadence speed. (See also Recommendation R.59.) A method for avoiding periods of Z polarity within an answer- back signal is described in Appendix II. 7 Since, for automatic calls in the international telex ser- vice, there are no arrangements for call priorities such as are envisaged for maritime satellite systems and since it is a princi- ple that a telex call should not be broken down without transmit- ting a service signal to the affected terminals, maritime satellite systems should, on exercising the maritime priority: a) attempt to set up the priority call by cutting down a call that is in the process of being set up, i.e. the call-connected signal was not yet transmitted to the international network before cutting down an established call; b) when a call in the process of being set up is cut down, transmit a service signal (NC ) followed by a clear to the international network; c) where it is unavoidable that an established call be cut down, clear the call using the standard international clear- ing procedure. Note - Special signals could be used within the maritime satellite system to reduce the setting-up times of priority calls within that system. Such signals are not required to be related to the time scale of the cut-down of calls from or to the interna- tional network. 8 When the international network is used to permit an author- ized telex terminal to access a coast earth station for the purpose of making a group call to ships , then such a service can be pro- vided technically: a) when the originating network cannot apply selec- tive barring to their subscribers , providing that the coast earth station authenticates the calling terrestrial telex station by the transmission of the WRU signal and checks the status of the charac- ters received from the calling terminal's answerback; It should be noted that the WRU should be transmitted after the call-connected signal and the coast earth station's answerback has been transmitted to the calling terminal; b) when the originating telex network can apply selective barring to its subscribers , providing that the telex selection received by the coast earth station is of the format: D1D2D3X1X2X3 . | | Xk EOS where D1D2D3is the appropriate telex destination code assigned to the Maritime Satellite Service in accordance with Recommendation F.69 [2], and X1X2X3 . | | Xkis the telex number at the coast earth station defining the particular group call request , which, in association with the calling terminal, may be used to identify the appropriate listing of ships to receive the group call. The character X1in combination with the Recommendation F.69 [2] code indicates to the international network that a maritime group call is being made. The character X1shall be the character 0 (zero). (See also Recommendation F.120.) c) when type D systems exist in the connection to the calling telex terminal . In that case the "calling line iden- tification" procedures of that system may be used during the setting-up phase of the connection to the coast earth station to authenticate the calling terminal's identity instead of the use of the WRU and answerback. Where the calling link identification is not available in the terrestrial network the Control Signalling Code (CSC) No. 12 will be received. Under these circumstances the WRU/answerback sequence should be used as detailed in S 7, a). When the request for a maritime group call, from the interna- tional network, is rejected due to lack of authorization, the international network should be cleared with a service signal (NA ) followed by a clearing signal. Note - Group calls may also be set up via a store-and-forward unit associated with the coast earth station. This unit should be accessed by subscribers or other store-and-forward units in accor- dance with the relevant Series F and U Recommendations. The authen- tication of the calling telex subscriber should be done by the store-and-forward unit. 9 The composition of ship terminal's answerback codes should conform to Recommendation F.130 [3]. 10 Appendix I gives the characteristics and timings for INMAR- SAT telex circuits. The example given is based on the implementa- tion at the United States coast earth stations. APPENDIX I (to Recommendation U.61) Signalling characteristics and timing of the INMARSAT telex service I.1 Introduction This Appendix describes the characteristics and time sequences of the international telex service operated over the INMARSAT mari- time satellite communication system via the USA coast earth sta- tion. I.2 Ship Earth Station (SES) originated telex call Figure I-1/U.61 shows the signalling sequence for a telex call originated from an SES terminal in the INMARSAT system. Figure I-2/U.61 illustrates the telex signalling and timing sequence. The following is a general description of the sequence of events in establishing a telex call from an SES to a gateway switch. I.2.1 To initiate a call, the SES sends a telex request mes- sage in the out-of-band request channel. The addressed coast earth station (CES) receiving the valid request message will send back an out-of-band assignment message on its normal TDM channel to the network coordination station (NCS). The NCS will repeat the assignment message on the common TDM channel to which the SES is listening. I.2.2 Upon receipt of a valid out-of-band assignment message from the CES via the NCS, the SES tunes to the normal TDM and can then access its assigned channel. The SES will normally achieve carrier and bit timing synchronization within 0.58 s after receipt of the assignment message. This time includes assignment message decoding, carrier recovery and clock recovery. Transmission will normally start upon frame synchronization, which occurs in less than 5.25 s. Therefore, the normal SES response time will be less than 5.8 s as seen at the SES or 6.6 s as seen at the coast earth station. The time that the assignment message remains active in the coast earth station is in addition to this 6.6 s, allowing enough time for the SES to start transmitting. I.2.3 The coast earth station, which is continually transmit- ting a polarity, makes the transition A to Z polarity indicating call confirmation within one character (150 ms, not counting fram- ing delays) after the assignment message is formatted. In cases of heavy traffic, the assignment message may be delayed in queue until after the transition has occurred, i.e. it is possible for the A to Z transition to be received by the SES before the assignment message. I.2.4 The initial SES transmission is in the A polarity state. When Z polarity is received from the coast earth station, the SES changes its transmission from A to Z polarity. In the case when the A to Z polarity transition on the coast earth station to SES link reaches the terminal before the assignment message, the SES inserts no more than two characters of A polarity in the initial burst. I.2.5 Once the coast earth station has received the SES's A to Z polarity transition, call processing is started between the coast earth station and the gateway switch. The coast earth station presents the Z polarity to the gateway switch and the gateway responds with a call confirmation within 150 ms. Within 3 s after the call confirmation, the gateway returns a call connected signal. The coast earth station then con- nects the gateway switch to the SES. The gateway then sends its header and a WRU to the SES. The SES will send its answerback in response to the WRU from the gateway switch. The SES's answerback is passed through the CES to the gateway switch. Upon verification of the answerback by the gateway switch, it will send a "GA+ " (Go Ahead) and the SES can then send selection digits to the gateway switch. I.2.6 After this connection, the coast earth station does not respond to any data on the line until it detects clearing. I.2.7 The gateway switch, upon receipt of the selection sequence from the SES, proceeds to process the call to the desired terrestrial subscriber. As the INMARSAT system interfaces with various gateway switches, the signalling sequences proceed accord- ing to the protocol between the particular gateway switch and the terrestrial network. Note - The signalling sequences shown between the gateway switch and the terrestrial network in Figure I-1/U.61 illustrates one method of signalling which can be employed. I.3 Terrestrial originated telex call I.3.1 Figures I-3/U.61 and I-4/U.61 illustrate the telex sig- nalling and timing sequences for a telex call originated in a ter- restrial network to an SES via the INMARSAT system. As the signal- ling sequences between the terrestrial networks and each gateway switch are not identical, that portion of the signalling sequences in Figure I-3/U.61 is for illustrative purposes only and no attempt is made to describe all the possible sequences. I.3.2 The following paragraphs provide a description of the sequence of events which occur between a gateway switch and an SES for a telex call originated from the terrestrial network. I.3.2.1 Upon receipt of the selection digits from the terres- trial network, the gateway switch starts the signalling sequence by sending a call request signal on an idle circuit to the coast earth station. Upon receipt, the coast earth station returns both a call confirmation and proceed-to-select signal within the proper inter- vals as shown in Figure I-4/U.61. The gateway switch can then proceed to send the selection digits to the coast earth station. I.3.2.2 The coast earth station checks the validity of the selection digits and if correct, sends an out-of-band assignment message via the NCS to the SES requested. When the assignment message has been transmitted, the signalling proceeds in the same manner as a call from an SES to a coast earth station described in S 2. Once the coast earth station has received the satellite call connect from the SES, it sends a call connected signal to the gate- way switch and cuts through the circuit between the SES and the gateway switch. From this point, the coast earth station is essen- tially transparent to all data on the line until it detects a clearing signal. I.3.2.3 The gateway then sends a WRU to the SES. The SES responds to the gateway's WRU with its answerback. The gateway switch, upon receipt of the SES's answerback, sends its header to the SES and the SES's answerback to the terrestrial network and the call is now in progress. I.4 Telex clearing sequence I.4.1 The coast earth station recognizes a clearing signal as an A polarity condition of 400 to 1000 ms from either the gateway switch or an SES. After recognition of the clearing signal, the coast earth station will disconnect the circuit and send a clear confirmation signal in both directions. I.4.2 Release of the satellite circuit section is under the control of the coast earth station. The SES does not stop transmis- sion of its RF carrier until: a) it has returned a clear confirmation signal fol- lowing the receipt of a clearing signal from the coast earth sta- tion; or b) a clear confirmation signal is received from the coast earth station. In either case, the SES maintains an A polarity signal for a maximum of 3.09 s before transmission is terminated. I.4.3 For 6 seconds after the successful receipt of the clear- ing and clear confirmation signals over a circuit section between the coast earth station and a gateway switch, the coast earth sta- tion will not process any calls on that circuit section. The SES is also considered busy during this 6-second interval. This 6-second guard time is necessary to allow for proper clearing of the SES over the satellite circuit section. If another telex call is received for that SES during the 6-second guard time, the coast earth station will send back an OCC service signal. Once the guard time is past and the SES has been successfully cleared, the CES notifies the NCS that the SES is now idle. FIGURE I-1/U.61, p. 1 FIGURE I-2/U.61, p. 2 FIGURE I-3/U.61, p. 3 FIGURE I-4/U.61, p. 4 APPENDIX II (to Recommendation U.61) Method employed at the Nordic coast earth station to avoid periods of Z polarity within the answerback signal The call set-up procedures employed at the Nordic coast earth station are similar to those shown in Appendix I. The coast earth station acts as an international gateway and is directly intercon- nected with the international telex exchange in Oslo. The ship's answerback is obtained by the coast earth station for both ship originated and shore originated calls as soon as the satellite circuit has been established. The answerback is then stored at the coast earth station with any period of Z polarity omitted. Whenever the coast earth station detects a WRU signal from the international telex network during the conversation phase, the path from the ship earth station is blocked as soon as the WRU signal has been sent to the ship. When the first few characters of the ship's answerback have been received at the coast earth station (in order to verify the continuity of the circuit), the coast earth station transmits the stored answerback into the international telex network at cadence speed. References [1] CCITT Recommendation Operational provisions for the international telex service , Rec. F.60. [2] CCITT Recommendation Plan for telex destination codes , Rec. F.69. [3] CCITT Recommendation Maritime answer-back codes , Rec. F.130. Recommendation U.62 GENERAL REQUIREMENTS TO BE MET IN INTERFACING THE INTERNATIONAL TELEX NETWORK WITH THE FULLY AUTOMATED MARITIME VHF/UHF RADIO SYSTEM (Malaga-Torremolinos, 1984) The CCITT, considering (a) that it is desirable that the interface between the inter- national telex service and the fully automated maritime VHF/UHF radio system be defined; (b) that the CCIR is charged with the task of making recommen- dations relating to the radio path of the fully automated maritime VHF/UHF radio systems; (c) that explanation of the detail of the interface between the international telex network and the fully automated maritive VHF/UHF radio systems would be of assistance to the CCIR, unanimously recommends that the interface between the international telex network and the automatic maritime VHF/UHF service should be in accordance with the following requirements: 1 General 1.1 In this Recommendation, the term mobile-service switching centre (MSC) is understood to mean the interworking point between the international or national telex network and the maritime VHF/UHF system. The MSC may have access to a junction called the location register which contains the current location of the mobile stations. 1.2 Fully automated maritime VHF/UHF radio systems should be capable of interfacing the international telex network in one or more ways: - in accordance with: i) Recommendation U.1, Signalling conditions to be applied in the international telex service (type A and type B sig- nalling); ii) Recommendation U.11, Telex and gentex signal- ling on intercontinental circuits used for intercontinental automatic transit traffic (type C signalling); iii) Recommendation U.12, Terminal and transit con- trol signalling system for telex and similar services on interna- tional circuits (type D signalling); - in accordance with Recommendation F.132, Pro- cedures for use of store and forward facilities in the maritime mobile services for ship-originated calls, - in accordance with Series F and U Recommendations on international store and forward units. 1.3 Type D signalling (Recommendation U.12) and, as a second choice, type C signalling (Recommendation U.11) are the preferred signalling systems, when they are available within the national boundaries, for the reasons given in Annex A to Recommendation U.60. 1.4 The numbering and selection procedures should be in accor- dance with Recommendation F.121. 2 Ship originated calls 2.1 When accessing a store-and-forward unit, the shipboard subscriber should select, in accordance with Recommendation F.121, one of the access codes 21 or 22 possibly followed by the charac- ter "+ " in order to gain access to the store-and-forward facility. 2.2 For direct access to the telex network, the procedures are given in S 3.4 of Recommendation F.121. The following points should be observed: 2.2.1 If the end-of-selection character "+ " is not required for technical reasons on the radio path, it must be inserted by the MSC. 2.2.2 Access codes (possibly followed by additional digits) as defined in Recommendation F.121 for accessing special services or facilities, may be converted by the MSC to an appropriate number in the telex network when the service or facility is terminated at a point in the telex network other than the MSC. 2.3 Any service code generated in the telex network for a par- ticular call should be returned to the calling ship. 3 Shore originated calls 3.1 Interfacing methods The following interfacing methods are possible: a) through a store-and-forward unit associated with one or more MCSs; b) direct real-time access through an MSC. Here, the following sub-categories may exist: i) MSC connected to location registers; ii) MSCs not connected to location registers. The technical solutions, including routing principles, required for each of these interfaces, are given below. 3.2 Store-and-forward facilities 3.2.1 The store-and-forward unit is accessed by normal telex procedures. 3.2.2 Procedures for forwarding messages to the store-and-forward unit and for retransmission of such messages should follow the normal procedures defined in Series F and U Recommendations. 3.2.3 Message should be retained for a period of time as defined in Recommendation F.110, S 4.4. 3.2.4 The store-and-forward unit may be connected to a loca- tion register for routing of calls to ships which are currently operating outside their home area. The routing of such calls are described in Annex A. 3.2.5 For other applications of store-and-forward units, see S 3.3.6 below. 3.3 MSCs connected to location registers 3.3.1 The technical arrangement for location registers is out- lined in Annex A. 3.3.2 A system with MSCs connected to location registers corresponds to the level 3 of operation defined in S 3.2.4 of Recommendation F.121. For simplicity, the MSC in which the ship station is per- manently registered will be referred to as the home MSC. If the ship is not in its home area, the MSC in which the ship station is currently located will be referred to as the visited MSC. 3.3.3 The general selection procedures to be used for setting up calls to ships are given in Recommendation F.121. They may lead to the following possibilities: i) The calling subscribers enters the following number sequence: D1D2(D3)A1A2(A3)MIDX4X5X6 where D1D2(D3) is the Recommendation F.69 destination code of the country in which the home MSC of the called ship is located, A1A2(A3) is the service access code in that country and MIDX4X5X6is the ship station number (MID = maritime identification digit). This can only consist of 6 digits for reasons given in Recommendation F.120. This implies that ship stations with more than 6 digits cannot be accessed automatically. Note - The MID may on a regional basis be replaced by the digits 8Y thus permitting a seventh digit X7of the ship station number (see Recommendation F.120 for details). The call is routed on the international telex network directly to the home MSC of the called ship station. It may also be possible to employ two-stage selection where the first stage is used for accessing the location register in the country of destination and the second stage for transferring the ship station number would allow ship station numbers to consist of up to 9 digits (see note to S 3.4.2). ii) If the country of origin has its own location register and the country of destination has a class-of-traffic assigned to the maritime VHF/UHF service, it would in principle be possible to access a ship by the following selection sequence from the calling subscriber: A1A2(A3)MIDX4 . | | | n where A1A2(A3) is the service access code for maritime ser- vices in the country of origin or a Recommendation F.69 destination code allocated to the maritime VHF/UHF service, and MIDX4 . | | Xnis a ship station number consisting of up to 9 digits. Alternatively, two-stage selection may be used. The first stage is used for accessing the location register and the second stage for transferring the number of the called ship (see note to S 3.4.2). The call is forwarded to the country of destination by the location register in the country of origin. This is done by sending the following address sequence of digits on the international net- work: D1D2(D3)MIDX4 . | | XnC where D1D2(D3) is the destination code of the country of destination and C is a class-of-traffic character identifying mari- time VHF/UHF service in the country of destination. The destination code D1D2(D3) is uniquely determined from the MID part of the ship station number. In order to operate such a system, class of traffic signals need to be defined or type A, C and D signalling. Type B signalling cannot support such a class of traffic signal. 3.3.4 If the called ship is currently located at another MSC than the home MSC, the home MSC may reroute the call to the required destination. The address format inserted by the home MSC for the purpose of rerouting would be one of those given in S 3.3.3 depending on the facilities available. If the call cannot be rerouted, the service code ABS or another more suitable service code should be returned from the home MSC. 3.3.5 When operating a system where rerouting would be required, the following time-outs should be observed: Types A and B signalling (Recommendation U.1) The time from the end of selection, combination No. 26 (+ ), or last selection character received and the return of the call connected signal should not exceed 60 seconds. Type C signalling (Recommendation U.11) The time taken from the end of selection signal, combina- tion No. 26 (+ ), to the call-connected signal should not exceed 60 seconds (see Table 1/U.11, remarks relating to the call-connected signal). Type D signalling (Recommendation U.12) The time taken from the end of selection signal, CSC code No. 11, to the call connected signal should not exceed 90 seconds (see Recommendation U.12, S 3.11). Note - It should be noted that for type A, B and C signal- ling, the same timings pertain to service signals (NP , NC , NA , OCC , etc.), and that in addition for type D signalling the same timing pertains to the last backward path signalling characters and terminating-through connection. 3.3.6 For technical or operational reasons, e.g. when the time-out requirements of S 3.3.5 cannot be met, the home MSC (or home location register) of the called ship station may offer the calling subscriber, by an appropriate service code, a store-and-forward service for forwarding the call to the ship. 3.4 MSCs not connected to location registers 3.4.1 In the case of MSCs not connected to location registers, the calling telex subscriber must know the actual location of the called ship, e.g. country, MSC, coast station. This situation would correspond to the level 2 of operation as described in S 3.2.3 of Recommendation F.121. The required selec- tion procedure is given in Recommendation F.121. 3.4.2 Two-stage selection may be used where the first stage is used for accessing the required MSC (or coast station) and the second stage for transferring the ship station number. This pro- cedure would allow ship station numbers to consist of up to 9 digits. Note - Two-stage selection may be difficult from an automatic terminal. 3.4.3 If the called ship does not respond to the call, the MSC (or coast station) should return the service code ABS or another more suitable service code. 3.5 Service codes For unsuccessful calls, the MSC (or coast station) should return service codes as defined in Recommendation F.131. 3.6 Maritime answerback code The answerback of the ship station should be in accordance with Recommendation F.130. The MSC (or the coast station) should ensure that the answerback which is sent into the telex network consists of 20 consecutive characters sent at cadence speed. 4 Maritime group calls 4.1 The composition of a group call address is defined in Recommendation F.120. 4.2 If group call services are at all permitted in the mari- time VHF/UHF service, the MSCs (or coast stations) should only per- mit such calls from authorized telex subscribers. The authorization may be established in one of the following ways: i) when type A, B or C signalling is used between the MSC (coast station) and the telex network, the WRU answerback sequence should apply, ii) when type D signalling is used, the calling line identification procedure should apply. If Control Signalling Code No. 12 is received, the WRU/answerback procedure defined above should be used. 4.3 Calls from unauthorized subscribers should be cleared with the service code NA . ANNEX A (to Recommendation U.67) Use of location registers in the maritime VHF/UHF service A.1 For the automatic maritime VHF/UHF radiotelephone service, CCIR Recommendation 586 describes the procedures to be used on the radio path for updating of location information. A similar pro- cedure would be applicable for the radiotelex service. The location updating is initiated by the ship station when the station detects a change in the coast station identity after the criteria given in CCIR Recommendation 587. A.2 Each MSC is connected to a location register which keeps an updated list of the current location of all ship stations registered in that MSC (the home MSC of the stations). The home MSC of a ship station should be uniquely determined from the MID and possibly one or two additional digits of the ship station number. The location registers are interconnected for mutual updating of the location of ship stations. A.3 Insofar as routing of telex calls to ships is concerned, there are several possibilities: A.3.1 The telex call is always routed directly to the home MSC by the procedures given in S 3.3.3 i). If the called ship is at another MSC (a visited MSC) than the home MSC, the call is rerouted by the home MSC to the appropriate destination. A.3.2 The call is routed to an MSC or location register in the calling subscriber's country by the method given in S 3.3.3 ii). The further routing of the call may then be done by either of the following methods: i) the call is routed to the home MSC and, if required, rerouted by that MSC as described in S A.3.1 above; ii) the MSC in the country of origin interrogates the home location register of the mobile station in order to obtain the required routing information. If the called ship station is located in some visited MSC, the MSC may then route the call directly to the required destination. Blanc Recommendation U.63 GENERAL REQUIREMENTS TO BE MET IN INTERFACING THE INTERNATIONAL TELEX NETWORK WITH THE MARITIME "DIRECT PRINTING" SYSTEM (Malaga-Torremolinos, 1984) The CCITT, considering (a) that it is desirable that the interface between the inter- national telex service and the maritime "direct printing" system be defined; (b) that the CCIR is charged with the task of making Recommen- dations relating to the radio path; (c) that explanation of the details of the interface between the international telex network and the maritime "direct printing" system would be of assistance to the CCIR, unanimously recommends that the following points should be taken into consideration when interfacing the maritime "direct printing" system to the telex network: 1 General 1.1 The maritime "direct printing" system should be capable of interfacing the international telex network in one or more ways: - in accordance with Recommendations U.1, U.11 and U.12 for direct real-time operation, - in accordance with Recommendation F.132 for ship originated access to maritime store-and-forward units, - in accordance with procedures defined in Series F and U Recommendations for store-and-forward access by terrestrial subscribers. 1.2 Answerback signals from the ship should be obtained both at the beginning and at the end of the call. When such signals are transmitted into the telex network, the coast station should make sure that they consist of 20 consecutive characters and are sent at cadence speed. The answerback should be in accordance with Recommendation F.130. 1.3 If the coast station detects an end of telex message sig- nal from the ship, the existing terrestrial connection (if any) must be cleared down and a new connection established for the next telex message. This should apply also when the next message is intended for the same terrestrial subscriber. 1.4 For ship originated calls, the coast station should be capable of returning to the ship any service codes received from the telex network. 1.5 For land originated calls, service codes should be returned to the telex network in accordance with Recommendation F.131. 2 Special conditions related to ship originated calls 2.1 The selection signals received from the ship should have formats in accordance with Recommendation F.60, S 3.2.2. 2.2 When accessing a maritime store-and-forward unit, the call control procedures should be in accordance with the relevant Recom- mendations in the Series F and U. 2.3 For direct access into the telex network, the normal telex procedures given in Recommendations U.1, U.11 and U.12 should be followed. In particular, the requirements given in these Recommen- dations with regard to the sending of selection signals, end of selection signals and class of traffic signals should be observed: - Recommendation U.1, S 6, - Recommendation U.11, SS 7 and 9, - Recommendation U.12, S 3.5. 3 Special conditions related to land originated calls 3.1 For direct access from the telex network, the time-out requirements of Recommendation U.1, U.11 and U.12 should be observed: Types A and B signalling (Recommendation U.1) The time from the end of selection, combination No. 26 (+ ), or last selection character received and the return of the call connected signal should not exceed 60 seconds. Type C signalling (Recommendation U.11) The time taken from the end of selection signal, combina- tion No. 26 (+ ), to the call-connected signal should not exceed 60 seconds (see Table 1/U.11, remarks relating to the call-connected signal). Type D signalling (Recommendation U.12) The time taken from the end of selection signal, CSC code No. 11, to the call connected signal should not exceed 90 seconds (see Recommendation U.12, S 3.11). Note - It should be noted that for types A, B and C signal- ling, the same timings pertain to service signals (NP , NC , NA , OCC , etc.), and that in addition for type D signalling the same timing pertains to the last backward path signalling characters and terminating-through-connection. 3.2 If the time-out requirements cannot be met, the coast sta- tion may offer the calling subscriber, by an appropriate service code, a store-and-forward unit for forwarding the call to the ship. 4 Maritime group calls The provisions given in Recommendation U.62, S 4 apply. Blanc MONTAGE: PAGE ... = BLANCHE SECTION 7 INTERWORKING BETWEEN NEW INFORMATION SERVICES AND TELEX Recommendation U.70 TELEX SERVICE SIGNALS FOR TELEX TO TELETEX INTERWORKING (Malaga-Torremolinos, 1984) The CCITT, considering (a) that a basic interworking on international connections will be at 50 bauds using an international telex network and that any telex subscriber can call conversion facilities in various countries; (b) that Recommendation F.201 specifies: - that a validation of a called Teletex terminal is mandatory. The validation is performed either by a direct vali- dation call or by a data base access; - that if a message delivery to a Teletex terminal fails in the case of interworking with two-stage selection pro- cedure, the conversion facility should send a non-delivery notifi- cation to a telex terminal; (c) that Recommendation S.90 specifies Teletex requirements for interworking with the telex service and Recommendations S.62 and S.70 specify control procedures and a network-independent basic transport service for a Teletex; (d) that Recommendation X.96 specifies call progress signals in a public data network, unanimously declares the following view 1 Scope This Recommendation defines service signals which are to be sent back to the telex terminal in the event of unsuccessful vali- dation for called Teletex terminal addresses, and service signals of the last delivery attempt to the Teletex terminal which are to be sent to the telex terminal as a part of non-delivery notifica- tion. H.T. [T1.70] .ce MONTAGE: REPRENDRE ORIGINAUX DU LIVRE ROUGE. PAS DE NOUVELLE SAISIE = MAINTENU LIVRE ROUGE .ce H.T. [T1.82] lw(144p) . cw(144p) . Generated by _ cw(72p) | cw(72p) . Originating SFU Destination SFU _ lw(72p) | lw(72p) . UMXU - TT { SMXU - DN SMXU - NDN SMXU - CN } lw(72p) | lw(72p) . SMXU - SRQ SMXU - SRPT _ Table 1/U.70 [T1.70], p.58 LECTURE: Tableau deplace autrement (er40 blanc) Page tres courte 2 Principles The following principles should be taken into consideration: 2.1 Call progress signals arriving from the Teletex network will be converted without changing their original meaning as far as possible. 2.2 A faulty condition between the Teletex network and the conversion facility will be regarded as a faulty condition within the network. 2.3 A faulty condition between the Teletex network and the Teletex terminal will be regarded as a fault of the terminal. 3 Telex service signals 1n general, telex service signals specified in Recommendation F.60 should be used. However, the telex service signals listed below will be used in the following circumstances: 3.1 1f the format of the Teletex address part is incorrect, the service signal NP will be returned. 3.2 1f the direct validation call is unsuccessful, the conver- sion facility will transmit the service signals specified in Table 1/U.70 to the telex terminal. 3.3 If the validation by data base access is unsuccessful, the conversion facility will transmit the service signals specified in Table 2/U.70. 3.4 If the message delivery to the Teletex terminal is unsuc- cessful, the conversion facility will transmit the service signals of the last delivery attempt which are specified in Table 1/U.70, as a part of non-delivery notification to the telex terminal. TABLE 2/U.70 Service signals for unsuccessful validation by data base access Abnormal conditions Service signal Unsuccessful results NP Note - In addition to the case "the number does not exist", other cases, for example, "the number is being temporarily prohibited" or "the number is out of order", might be considered as abnormal con- ditions. But at this moment such conditions and the service signals corresponding to them are for further study. .PS 10 Blanc Recommendation U.74 EXTRACTION OF TELEX SELECTION INFORMATION | FROM A CALLING TELEX ANSWERBACK (Malaga-Torremolinos, 1984; amended at Melbourne, 1988) The CCITT, considering (a) that there is a need for automatic address extraction from a telex answerback (e.g. access to a telex-Teletex conversion facility (CF) or an SFU); (b) that Recommendation F.60 defines a preferred structure for the telex answerback; (c) that different forms of answerbacks exist; (d) that Recommendation F.60 | fIbis defines a structure for a telex answerback associated with an intermediate document storage device, unanimously declares that answerbacks are considered "technically processable" (i.e., the answerback can be interpreted unambiguously to determine the F.69 code and national call number) if they contain the minimum fields defined in Recommendation F.60, separated by detectable del- imiters, with allowance made for the following additions: - F.60 fields may or may not be in the preferred order; - the Telex Network Identification Code (TNIC) should be preceded and succeeded by detectable delimiters: i) preceding delimiters are national call number and space, ii) succeeding delimiters are national call number, space or end of answerback (end of answerback means no more print- able characters); - one hyphen or one space with the national call number is ignored; - the corresponding international access code for the "J" TNIC is: i) 72, if the national call number consists of 5 digits, ii) 720, if the national call number consists of less or more than 5 digits. The international access code for all other TNICs follows Recommendation F.69. For conversion between TNICs and F.69 codes, see also Recommendation F.69. An algorithm which meets the preceding criteria is shown in Figure 1/U.74. Blanc FIGURE 1/U.74 (Sheet 1 of 2), p. FIGURE 1/U.74 (Sheet 2 of 2),p. Note 1 - Check the automatic emitting speed and wait for the end of the answerback. The answerback is considered to have ended after detection of a 300 ms period of idle. Note 2 - "Retry" refers to another attempt to trigger the answer- back. Note 3 - Printable figures are combination No. 17 (1) to combination No. 16 (0). Spaces (combination No. 31), hyphens (com- bination No. 1) and equal signs (combination no. 22) are allowed in this field, but are ignored. Note 4 - Are there one or two printable letters at the end of the answerback, preceded by a space? Note 5 - Are there one or two printable letters following immedi- ately the "national call number" (without space between), with space after them? Note 6 - In the case of a letter code single "J" corresponding F.69 code is: - 72, if the "national call number" is 5 digits long. - 720, if the "national call number" is less or more than 5 digits. Note 7 - Are there one or two printable letters following the "national call number", and is there no further printable character following? One space between "national call number" and network identification code is allowed. Note 8 - Are there one or two printable letters preceding immedi- ately the "national call number" (without space between), but with a space in front of the letter(s). Note 9 - If unsuccessful, perform one retry after 1.5 seconds, if allowed in the protocol. Note 10 - If answerback is not received automatically. Recommendation U.75 AUTOMATIC CALLED TELEX ANSWERBACK CHECK (Malaga-Torremolinos, 1984; amended at Melbourne, 1988) The CCITT, considering (a) that there is a need to check the answerback of the called telex number [e.g. delivery from a telex-Teletex conversion facility (CF)B/F or store and forward unit (SFU)]; (b) that Recommendation F.60 defines a preferred structure for the telex answerback; (c) that different forms of answerback exist, (d) that Recommendation F.60 | fIbis defines a structure for a telex answerback associated with an intermediate document storage device; unanimously declares that the following requirements are recommended for automatic answerback check of a called telex terminal by an administration's equipment: 1 Case 1: reference information for the check is provided by the calling subscriber This information can be in total or part of the called sub- scriber answerback (contiguous printable characters and space). There is no restriction on the number of characters supplied. In this case, the called party answerback check consists of verifying the presence of the provided character string. Consider- ing the information provided in the directories and terminal iden- tifications, allowance is to be made for the following differences: - one character mismatch in the letter part; - one hyphen or one space is ignored in the national call number. 2 Case 2: no information on the answerback of the called terminal is provided by the calling subscriber The reference information for the answerback check is the selection information provided by the calling subscriber. In this case, the called party answerback check consists of: - extracting the national call number and F.69 code from the answerback; - comparing the obtained national call number and F.69 code with the supplied selection information code. Allowance is made for the following cases of mismatch: a) a positive national call number match without a valid telex national identification code (TNIC) match, b) a match between the least significant part of the supplied selection information and the national call number obtained from the called party answerback, considered to be posi- tive if the difference in field length is limited to two characters. 3 An algorithm which meets the preceding criteria for cases 1 and 2 is shown in Figure 1/U.75 In some circumstances, it may be necessary to compare the answerback of the called subscriber with the answerback received and recognized at the beginning of the call. In such cases, if the received string consists of more charac- ters than the previously recognized answerback, then a check should be made as to whether the recognized answerback is part of the received string. FIGURE 1/U.75, p. Note 1 - Check the automatic emitting speed and wait for the end of the answerback. The answerback is considered to have ended after detection of a 300 ms period of idle. Note 2 - "Retry" refers to another attempt to trigger the answer- back. Note 3 - If unsuccessful, perform one retry if allowed in the pro- tocol. Note 4 - The answerback provided could be a contiguous part of the expected answerback or all of it. In case of a return call to the calling subscriber (e.g. PDN (posi- tive delivery notification) or NDN (negative delivery notifica- tion) delivery) the stored calling telex answerback is considered as a "provided" one. Note 5 - This comparison is to verify the presence of the provided character string in the received answerback, allowing one character mismatch in the letter part. Note 6 - A zero in the selection, but not in the answerback in front of the national number is to be ignored. If the received fig- ure group is shorter than the selected one, consider it as match, but make a note in the call record "received figure group is not complete". It is possible that the received figure group includes the F.69 code. Note 7 - Forward message, but make a note "area code-check was not possible" into the call record. Note 8 - If called A/B is not available from previous procedures. Note 9 - If a digit "0" appears at this stage between the F.69 code and the "NCN" it should be ignored. Blanc MONTAGE: PAGE ... = PAGE BLANCHE SECTION 8 TELEX STORE AND FORWARD Recommendation U.80 INTERNATIONAL TELEX STORE AND FORWARD | ACCESS FROM TELEX (Malaga-Torremolinos, 1984; amended at Melbourne, 1988) The CCITT, considering (a) that telex store and forward units exist, and are being introduced increasingly into national networks; (b) that access procedures and protocols differ significantly between different units; (c) that to facilitate international access to store and for- ward units, a standard access procedure would be desirable, unanimously declares the view that the telex access procedure described in this Recommenda- tion should be adopted for all future store and forward units pro- viding incoming international telex access. 1 Scope 1.1 This Recommendation describes a procedure for a telex sub- scriber to gain access to a store and forward unit in a foreign country by using an international telex switched connection. The procedure uses two stage selection. 1.2 This Recommendation is one of a series which define telex store and forward services. The other Recommendations are: - Recommendation F.72: International telex store and forward - General principles and operational aspects. - Recommendation U.81: International telex store and forward - Delivery to telex. - Recommendation U.82: International telex store and forward - Interconnection of telex store and forward units. 2 Outline of service features 2.1 The full range of service features is described in more detail in Recommendation F.72. 2.2 Service principles 2.2.1 The procedure defined in this Recommendation is a two stage selection procedure whereby a calling telex subscriber gains access to a foreign store and forward unit (SFU) in the first stage of selection and inputs the called address(es) and message in the second stage of selection, after the return of a call connected signal. The option of a store and retrieval facility is for further study. 2.2.2 International access to the SFU should be offered on the basis of bilateral agreement between Administrations, and barring facilities should be provided to prevent unauthorised use. The method of barring shall be the responsibility of the Administration of the SFU service and is beyond the scope of this Recommendation. It may also be necessary for Administrations to make provision to selectively bar access to international telex SFU facilities in other countries. 2.2.3 Message input from both manual and automatic emitting devices should be accommodated. It is also possible that messages may be received from another SFU, and this type of input should also be accommodated by bilateral agreement. 2.2.4 For calling subscribers with answerbacks that cannot be processed to obtain the calling address, the SFU shall be able to handle direct input of the address from the subscriber, with or without prompt. 2.2.5 A status enquiry facility should be provided interna- tionally to provide information on message delivery in response to a request from the originator. This message status enquiry point will be accessed by a separate access code to that used for message input. When the SFU provides automatic advice of delivery and non-delivery, or a request for positive delivery can be indicated, then the provision of status enquiry facilities is optional. 2.2.6 Address validation of the called telex subscriber(s) may be provided, however, delivery of the message to a given address cannot be fully guaranteed. 3 Outline of facilities 3.1 The full range of facilities is described in more detail in Recommendation F.72. 3.2 Message input access 3.2.1 Provision should be made for both single and multi-addressed calls. 3.2.2 Messages received by the SFU for delivery to destina- tions not served by that SFU should be given a Non-Delivery Notifi- cation with service code NA for the reason of non-delivery. 3.2.3 The maximum acceptable number of addresses in a multi-address call shall be agreed between Administrations, but should be at least 20. If the maximum number of addresses is exceeded, the SFU shall return the service code TMA and clear the connection. 3.2.4 An attention information field facility should be pro- vided by the SFU which enables each addressee of a multi-address message to have a relevant attention prefix preceding the message. 3.2.5 Three classes of delivery service should be provided by the SFU: a) normal delivery. The SFU delivers the message as soon as operationally feasible after receipt; b) delayed delivery. The delay can be either: i) set by the Administration offering the SFU ser- vice, if the calling customer selects this option, ii) set by the calling subscriber, such that delivery of the message is not attempted until after the expiration of the indicated delay; c) time limited delivery set by the calling sub- scriber, such that delivery of the message is attempted within a specified time limit. The desired class of delivery should be selectable on a desti- nation address basis. 3.2.6 Positive delivery notification (PDN) when provided may be requested by the calling subscriber on a per message or on a per address basis. 3.2.7 Message reference number(s) should be returned to the calling subscriber. 3.2.8 Address correction procedures are considered desirable and may be provided. 3.2.9 Provision should be made to accept follow-on message(s) with their associated address(es) which may be sent as separate block(s) immediately after the first message. Provision should also be made to acknowledge acceptance of messages, if requested by the calling terminal, at any point during a transaction. 3.2.10 The SFU shall not accept the input of a message or follow-on messages (in the message input mode) unless adequate storage is available. The minimum storage available per message text input should be agreed bilaterally between Administrations. However, it is recommended that the minimum storage available on a per message basis should be 24 | 00 characters. For an interim period 12 | 00 characters is acceptable. Longer messages may be accepted if storage continues to be available. 3.2.11 An Input Transaction Accepted for Delivery (ITD) ser- vice signal should be returned to the calling subscriber to indi- cate that the SFU has accepted the message. 3.2.12 The following facilities are not accommodated in the procedures, do not form part of this Recommendation and are for further study: a) use of pre-recorded address lists; b) message editing facilities; c) address collation facilities; d) requests for positive delivery advices; e) transparent mode in message input phase; f ) called address format checks. 3.3 Status enquiry access 3.3.1 Status information on messages should only be available for return to the originator of the message. 3.3.2 Status information may be requested on: a) all addresses associated with a message refer- ence number; b) addresses which have not yet received the mes- sage; c) a specific address. 4 Access procedures 4.1 General 4.1.1 Two basic access procedures should be provided: a) Interactive operation Input from manual calling terminals, where the SFU may return prompt signals. b) Non-interactive operation - Either, input from automatic emitting devices or from subscribers' terminals, where prompt signals from the SFU are not required; - or, input from another SFU Note - detection of this type of access will rely on the identification of the calling SFU answerback, the format of this answerback is for further study. In this case the procedure used is described in Recommendation U.82. 4.1.2 Figure 1/U.80 shows the recommended access procedures. Figure 1/U.80, p. - NE PAS DEPLACER CETTE RESERVATION Note 1 - The WRU is transmitted 800 ms after transmission of the SFU answerback if the forward path remains idle. Note 2 - One additional WRU shall be transmitted by the SFU if: a) there was no response to the first WRU. b) signals were received after the first WRU which could not be identified as an answerback. This second WRU should be transmitted when a 300 ms idle condition has been detected from the calling terminal at least 2 seconds after the transmission of the first WRU. Note 3 - Case A: Procedure when calling address can be determined from the calling terminal answerback. Note 4 - Case B: Procedure when calling address cannot be deter- mined from the calling terminal answerback. Note 5 - The prompt GA and the preceding optional message refer- ence information shall be transmitted three seconds after receipt of the calling terminal answerback. If the caller initiates input within the three seconds timeout, the message reference information and prompt will be withheld. Note 6 - The prompt "ADD" and the precedint optional message reference information shall be transmitted three seconds after receipt of the calling terminal answerback. If the caller initiates input within the three seconds timeout, the reference information and prompt will be withheld. Note 7 - The service request CI is transmitted when the terminal is operating in a non-interactive mode (e.g. an automatic terminal or a manual terminal using a tape transmitter). Note 8 - If the calling address is expected and is not received within 15 seconds of the original "ADD" prompt, a further prompt shall be transmitted. The procedure is shown in Figure 2/U.80. The calling address should be input in the format F.69 destination code followed by the national telex number followed by at least 2 carriage returns, line feed sequences when received in the non-interactive mode. Note 9 - The prompt GA is inhibited if the service request CI has been received or if the caller has initiated input. Note 10 - Several messages can be contained within the same tran- saction and are separated by EOM sequences, as in Figure 3/U.80. Note 11 - The EOM signal may optionally be followed directly by an ACK request signal. The sequence will then be as shown in Figure 4/U.80. Immediately following transmission of an IMA, the SFU shall return reference information for previous unacknowledged messages, the signal <-_vGA <-_ and then be prepared to accept further follow-on messages. Note 12 - Following receipt of the EOT signal the SFU shall operate as shown in Figure 5/U.80. a) If the EOT signal originated from a non-interactive telex terminal, the SFU should wait for up to 2 seconds for a WRU signal. If WRU is received, the SFU should return its answerback followed immediately by the ITD sequence. If WRU is not received in the 2 second period, the SFU should return the ITD sequence; b) If the EOT signal originated from an interactive telex terminal, the SFU should return the ITD sequence as soon as possible; c) The ITD signal and associated reference informa- tion must be returned within 5 seconds of the EOT signal. Note 13 - If a WRU signal is received at any time during the pro- cedure, the SFU shall return its own answerback. FIGURES 2 - 5/U.80, p. 4.2 Telex access 4.2.1 The calling telex subscriber should establish a call to the SFU by means of normal telex procedures. 4.2.2 Following transmission of the SFU answerback, the SFU should not send a WRU immediately. The SFU should monitor the for- ward path and transmit the WRU only when an idle condition has per- sisted for at least 800 ms. If a 800 ms idle condition has not been detected within 15 s of the transmission of the SFU answerback, the call should be cleared. Note - SFU answerback is not returned if the SFU cannot accept the guaranteed message length (see S 3.2.9). In this case OCC is returned. 4.2.3 An additional WRU should be transmitted if: a) there is no response to the first WRU; b) signals were received after the first WRU that could not be identified as an answerback. The second WRU should be sent when a 300 ms idle condition has been received from the calling terminal at least 10 s after the transmission of the first WRU. Note - The 300 ms and 10 s periods suggested here are provi- sional and may need to be changed in the light of experience. If a continuous input of signals is detected for 15 seconds after the return of the SFU answerback, the SFU shall clear the call. 4.3 Message reference information 4.3.1 The message reference information may be returned after a 3 second timeout from receipt of the calling terminals answer- back. If the SFU detects input before timeout, then the message reference information will be withheld. The message reference information may comprise date and time and/or message reference number. 4.3.2 Date and time 4.3.2.1 The date and time of message input may be returned to the calling telex subscriber before message input. 4.3.2.2 The transmitted date and time should be: <-_^YY-MM-DD/HH-NN where YY represents two numeric characters indicating the year; MM represents two numeric characters indicating the month; DD represents two numeric characters indicating the day; HH represents two numeric characters indicating the hour on a 0-24 basis; NN represents two numeric characters indicating the minute. Note - Local time of the SFU should be used. 4.3.3 Message reference number A message reference number may also be returned to the calling telex subscriber before message input. The reference number would comprise up to six numeric charac- ters and should follow immediately after the date and time informa- tion after a one space character. The reference number should cycle through consecutively for follow-on messages within the same transaction. Accommodation should be made to cycle the last two or three digits for follow-on messages. 4.4 Service request 4.4.1 Interactive service request The calling telex subscriber shall be recognized as interac- tive by the omission of the non-interactive service request (see S 4.4.2). 4.4.2 Non-interactive service request The calling telex subscriber should indicate that the transmission is from an automatic terminal by commencing the pro- cedure with the non-interactive service request (characters CI). 4.5 Calling telex address 4.5.1 The SFU shall use an algorithm (see Recommendation U.74) to attempt to determine the calling telex address from the captured calling answerback. If this cannot be achieved the SFU shall return a prompt signal (<-_vADD <-_) to solicit the calling subscriber number. This prompt shall be returned after the optional message reference number, but not before a period of three seconds from receipt of the calling terminals answerback. If the SFU detects input within this time then the prompt will be withheld. 4.5.2 The calling address may be preceded by a CI character sequence which signifies the non-interactive service request (see S 4.4.2). The CI characters sequence may or may not be associated with carriage return, line feed or letter shift characters. 4.5.3 If the calling address is not received within 15 seconds of the original prompt signal (ADD), another prompt shall be returned once more to try to solicit the calling address. If another 15 seconds elapse the connection shall be cleared. 4.5.4 Address input can be cancelled (in the case of mistakes) using the same procedure as S 4.7.10. 4.5.5 The calling address should be input in the format: F.69 code followed by the national telex number and must be followed by at least two carriage return, line-feed sequences when received in the non-interactive operation. Spaces, hyphens, pluses and preced- ing zeros shall be ignored. 4.6 Commence input signal If the calling address is capable of being extracted from the answerback (see S 4.5.1) then the SFU shall return a commence input signal comprising the characters <-_vGA <-_; after the optional message number, but not before a period of three seconds from the receipt of the calling terminals answerback. If the SFU detects input within this time then the prompt will be withheld. If the address is not capable of being extracted from the answerback, the SFU shall not return the GA sequence, but shall return the ADD prompt (see S 4.5.1). In this latter case the GA prompt shall normally be returned immediately after the receipt of the calling address. However, the GA prompt should be inhibited if the service request CI pre- cedes the calling address or the caller has initiated input. If the SFU has not been able to obtain the calling address, by the stage at which address input is expected, then the SFU will require that the first address line is preceded with the keyword "ADD" indicating that the calling address follows. If "ADD" is not found, then the SFU will attempt to interrupt the calling telex subscriber in accordance with Recommendation S.4. If the calling subscriber is interrupted, the service signal "ITR" followed by the clearing signal, shall be sent indicating that the SFU has been unable to obtain the calling subscriber address and the transaction has been terminated. When the calling subscriber cannot be interrupted, the SFU shall forcefully clear the connection. 4.7 Address input 4.7.1 The format of each address line should be as follows: a) address; b) expected answerback or part of answerback; c) attention information; d) delayed delivery; e) positive delivery notification request. However, only field a) is mandatory to the subscriber. Each address line should not be longer than 69 printable or space char- acters. Each address line is normally delimited by carriage return and line feed. Note 1 - Additional shift or carriage control characters have to be ignored. Note 2 - Address lines containing more than 69 characters are for further study. 4.7.2 Each field within an address line should be delimited by different combinations for each field. These combinations will be: Combination No. 26: + End of each address Combination No. 24: / Start of expected answerback or part of answerback Combination No. 11: ( ?04 ?05 Attention line information to be combined within these del- imiters Combination No. 12: ) | Combination No. 14: , Start of other options Note 1 - With the exception of combination No. 26 (+) the other combinations need not be used if the subscriber does not want to use those fields. Note 2 - The optional fields may be input in any order. Note 3 - Handling of abnormal conditions is for further study. 4.7.3 The SFU shall return a service signal (TMA) and clear the connection if the agreed maximum number of addresses is exceeded (see S 3.2.3). 4.7.4 The address line(s) shall be delimited from the message by means of an EOA signal which shall be: <-_vBT When a positive delivery notification is requested on a per message basis, the EOA signal will be extended to include the indi- cator "ACK" separated by Combination No. 14 (,) as follows: <-_vBT , ACK It is acceptable for the EOA signal to appear on the same line as the last address. 4.7.5 Address This field is the only mandatory field of the address line and may be an international telex address (in the format of the Recommendation F.69 destination code and national telex number) or another non-telex service, e.g., Teletex. (The format is left for further study.) To permit the SFU to recognize a Teletex address, it shall be preceded by the identifier "TTX". If address validation is provided, the action to be taken by the SFU, if the address is not received with a valid format, is detailed in S 4.12.5. The address must be terminated by a combination No. 26 (+) whether or not optional fields are used. 4.7.6 Expected answerback or part of answerback The character sequence in this field should be used as an additional check on the called subscriber answerback before the message is delivered. The inclusion of this field is optional. 4.7.7 Attention information This field may convey the name and address of the recipient in a confidential manner. The inclusion of this field is optional. 4.7.8 Delivery indicator This field indicates the type of delivery required. Omission of this field indicates that normal delivery is required. The for- mat of the field should be: a) D if the calling subscriber leaves the period of delay to the discretion of the Administration providing the SFU service; b) DXY where XY are numeric characters which specify the minimum desired delay in hours from 01-23; c) LXY where XY are numeric characters which specify the maximum limit for delivering the message to the addres- see. 4.7.9 When a positive delivery notification is required on a per address basis, the indicator "ACK" separated by Combination No. 14 (,), shall be included as part of the address. 4.7.10 Examples of the format of address lines: a) 41994531+/994531 FUG D, D b) 41662724+(ATTENTION MR S SMITH), D12 c) 41246178+/246178 ADAC D (ATTENTION MR SMITH) d) 4625000+ 4.7.11 Address line editing facilities, if provided, should operate as follows: Any address line entered may be cancelled by the receipt of two consecutive == characters (upper case combination No. 22). 4.8 Called address validation Each address line may be validated as follows: a) that the selection number consists of only numeric characters (non-numeric characters such as space, hyphen or a valid prefix shall be tolerated) and the selection number's length falls within the range of the number of digits accepted by the SFU; b) that the first two or three significant digits constitute a valid F.69 telex country code accepted by the SFU; c) that the remainder of the address line conforms to the format specified in S 4.7. 4.9 Message input 4.9.1 Characters received in the message text (with the excep- tion of Figures D) should be transmitted transparently by the SFU. 4.9.2 Paragraph 6 details the action the SFU should undertake if abnormal conditions are encountered during message input. 4.10 End of message (EOM) signal Normally, if the calling subscriber wants to input more than one message, an end of message signal is used. This may be one of two types as follows: a) four combinations No. 14 (NNNN), which is simply used to separate messages; b) four combinations No. 14, then combinations 1, 3 and 11 (NNNNACK) which is used to separate messages and to request the SFU for an input message acknowledgement (IMA) plus reference information of those messages not previously acknowledged (see S 4.11.4 for format). Once this type of EOM is received the SFU shall accept respon- sibility for delivery of the message, even if the subscriber clears. 4.11 End of transaction (EOT) 4.11.1 The calling telex subscriber should indicate end of transaction by transmitting four combinations No. 26 to the SFU (++++). 4.11.2 This signal is normally used at the end of the last (or single) message input during the transaction. 4.12 Input transaction accepted for delivery signal (ITD) 4.12.1 After receipt of the EOT signal from a non-interactive calling telex subscriber the SFU should wait up to 2 seconds to detect any further signals on the forward path. If a WRU signal is received in this period the SFU should respond with the SFU answer- back followed by the ITD signal. If no further signals are received during this period the SFU should return the ITD signal, plus reference information (as in S 4.3) followed by clear. 4.12.2 After receipt of the EOT signal from an interactive telex terminal the SFU should return the ITD signal as soon as pos- sible. 4.12.3 ITD reference information must be returned within 5 seconds of the EOT signal in S 4.11.1 and S 4.11.2 above to avoid excessive holding times. 4.12.4 The ITD signal should be followed by the date and time, message reference number(s) and an indication of the total number of messages. When more than one message has been received, the reference information returned shall be that of the first and last message, e.g.: ITD YY-MM-DD/HH-NN (XXXABC-XXXDEF) P where XXXABC is the first serial number XXXDEF is the last serial number P is the number of messages acknowledged. 4.12.5 Where address format validation is to be provided, there will be one ITD signal per message. It shall be followed by a list of all rejected addresses, for the corresponding message. Each rejected address may be followed by the appropriate service signal indicating reason for failed validation, e.g.: REJ XXXXX YY where REJ is the service signal indicating rejection of the given address; XXXXX is the rejected address; and YY the appropriate service signal, e.g., NP, FMT, etc. In the case where all addresses have failed validation, then the SFU should attempt to interrupt the calling telex subscriber in accordance with Recommendation S.4. If the calling subscriber can be interrupted, the service sig- nal "ITR", followed by the clearing signal shall be sent indicating that all address validations have failed and the transaction has been terminated. When the calling subscriber cannot be interrupted, the SFU shall forcefully clear the connection. 5 Status enquiry Note - This facility is for further study. 5.1 Status enquiry request 5.1.1 A calling telex subscriber, having selected the status enquiry point (see SS 2.2.5 and 3.3) must give the SFU the follow- ing information: a) the message reference information (see S 4.3); b) an indication of whether the enquiry concerns all addresses associated with a message, or whether the enquiry concerns only address(es) which have not yet received the message, or a specified address. Status report information should be provided for all addresses unless the message reference number is followed by combination No. 22 (=), which signifies that the enquiry concerns only addresses which have not yet received the message. Also, if this character is followed by an address, this shall signify a status request on a specific address. Several reference number lines may be entered each separated by carriage return, line feed. Termination of a status enquiry request will be indicated by the end of status request signal (EOSR), combination No. 26 (+). 5.1.2 If characters are not received on the forward path within 3 seconds of the status enquiry mode being selected, the SFU shall return a prompt signal which shall comprise combination No.2 (?). 5.1.3 If a message reference number is not received either in full, or in part, within 20 seconds of the prompt being returned, the SFU should clear the connection. 5.1.4 If an EOSR signal is not received within 20 s of the message reference number(s) input, the SFU shall continue as if an EOSR signal had been received. 5.2 The status report 5.2.1 The status report format will be consistent with the notification advice format dealt with in Recommendation U.81. Two types of status report are returned: a) delivered; b) not delivered. See Recommendation U.81, S 4.3.6 for report formats. 6 Abnormal conditions during message input 6.1 Telex subscriber clearing during text input without EOT The SFU shall not forward the message to the called telex subscriber(s) The incomplete message should either be cancelled or option- ally sent to an operator assistance position. Messages previously acknowledged in the same transaction shall be transmitted normally. 6.2 Telex subscriber stopping transmission for a certain time without transmitting the EOT signal, or transmitting a partial or invalid EOT signal See Figure 6/U.80. If at any time between the SFU returning the GA prompt (Case A), or the calling address prompt (Case B) and the detection of the EOT signal the SFU detects a 30 second period of idle, the following shall apply: the SFU shall send a GA prompt to the telex subscriber in order to request more information input (text, EOM or EOT). If after a further 30 s no more characters are received, the SFU shall: a) either send BMC service code and clear the call (if the SFU cancels incomplete messages); or b) clear the call (if the SFU sends the message to an operator assistance position). If previous message(s) in the same transaction were delimited by NNNNACK, these shall be transmitted normally. Figure 6/U.80, p. 6.3 Telex subscriber sending WRU to the SFU during text input The SFU should return its answerback after receiving a WRU. In addition, if: a) WRU is followed by text, message input is con- tinued after the SFU answerback. Also, the WRU is deleted from the message text. b) WRU is followed by a clear from telex, the SFU proceeds in S 6.1 above. c) WRU is followed by a lack of transmission (pause), the SFU proceeds as in S 6.2 above. 6.4 Telex subscriber sending text after the EOT signal See Figure 7/U.80. 6.4.1 Any characters received between EOT and ITD (with the exception of WRU) will be ignored. 6.4.2 The SFU should immediately attempt to prevent further characters being sent by transmitting a sequence of TTT | | | characters for a maximum of 20 s. 6.4.3 If the calling terminal stops transmission for 150 ms within a 20 second period, the SFU shall return an ITD service sig- nal followed by a clear. 6.4.4 If the terminal continues to transmit characters after the 20 second period, the SFU should forcefully clear the connec- tion back to the calling terminal. 6.4.5 The SFU should attempt to deliver the message text received before EOT as for a normal message input. Figure 7/U.80, p. 6.5 Telex subscriber clearing after EOT, but before ITD The message shall be forwarded normally by the SFU under these circumstances. 6.6 Telex subscriber sending national variants of ITA No. 2 alphabet (^F, ^G, ^H) Since Recommendation F.60, S A.3.8 recommends that these com- binations should not be used for international communications, the SFU should not monitor for their use and these combinations will be passed on to the called subscribers if received. 6.7 Telex subscriber sending J, Bell combination (^J) The SFU should also transmit this combination if received, to the called party. 6.8 SFU storage capacity overflow during telex message input 6.8.1 If the number of characters received by the SFU during a message input exceeds the available storage to that input (which may be greater than the agreed minimum storage, see S 3.2.9), the SFU should discard the excess characters, no attempt should be made by the SFU to overwrite previously stored characters. 6.8.2 When this occurs the SFU should immediately attempt to prevent the calling telex subscriber from sending further charac- ters by transmitting a sequence of TTT | | | characters for a maximum of 20 s. 6.8.3 If the calling terminal stops transmission for 150 ms within a 20 second period, the SFU should return the message length exceeded indication (LDE) and then wait for the EOT or NNNNACK in accordance with S 6.2. 6.8.4 If the terminal continues to transmit characters after the 20 second period, the SFU should forcefully clear the connec- tion back to the calling terminal. 6.8.5 If an EOT/NNNNACK is received within the 20 second period, the SFU should attempt to deliver the message text, accepted and stored, preceded by a special text prefix to indicate to the called telex subscriber that the message may be incomplete. If an EOT/NNNNACK is not received the SFU shall proceed as in S 6.1. 6.8.6 If the SFU has insufficient storage to receive messages (see S 3.2.9) it should still continue to process status enquiry requests. 6.9 Maximum input duration exceeded If the time taken for a single transaction exceeds 2 hours, the SFU shall act in accordance with S 6.8. 6.10 Repeated characters during message input The SFU shall be capable of detecting continuous reception of one character combination and shall recognize this as a "tape stuck" condition. The SFU shall detect this condition only after receipt of 80 identical combinations received consecutively. The SFU shall attempt to signal the calling terminal by transmitting a sequence of TTT | | | characters for a maximum of 20 s. If the character combinations become different the SFU shall continue with the message input and deliver all characters received. If the "tape struck" condition remains at the end of 20 s, the SFU shall clear the connection and follow the procedure outlined in S 6.1 above. Recommendation U.81 INTERNATIONAL TELEX STORE AND FORWARD - DELIVERY TO TELEX (Malaga-Torremolinos, 1984; amended at Melbourne, 1989) The CCITT, considering (a) that telex store and forward units exist and are being introduced increasingly into national networks; (b) that delivery procedures differ significantly between different units; (c) that a standard delivery procedure would be desirable for international working, unanimously declares the view that the international telex delivery procedure described in this Recommendation should be adopted for all future telex store and forward units. 1 Scope 1.1 This Recommendation outlines procedures for the delivery of international telex messages by a store and forward unit (SFU). 1.2 The Recommendation comprises the following: 1.2.1 Message forwarding procedure. 1.2.2 Delivery re-attempt. 1.2.3 Notification procedure. 1.3 The procedures detailed in this Recommendation specify the minimum requirement that should be provided by the telex SFU. 1.4 The procedures should apply to all classes of message delivery. 1.5 The priority and time of message delivery should be the responsibility of the telex SFU that has accepted the input message for delivery. In the case of international interworking between telex SFUs, the priority and time of message delivery may be controlled by the originating or destination SFU, subject to bilateral agreement between the Administrations concerned. 1.6 This Recommendation is one of a series which define telex store and forward services. These Recommendations are: - Recommendation F.72: International telex store and forward - General principles and operational aspects. - Recommendation U.80: International telex store and forward - Access from telex. - Recommendation U.81: International telex store and forward - Delivery to telex. - Recommendation U.82: International telex store and forward - International interconnection of telex store and for- ward units. 2 Definitions 2.1 The term delivery of messages applies to the forwarding of messages input into a telex SFU by an originating telex subscriber to a destination telex subscriber over an international telex net- work. 2.2 The term notification applies to the forwarding of an advice of delivery/non-delivery of a message to the originating telex subscriber over an international telex circuit. 3 Telex message forwarding procedures 3.1 The sequence of the message forwarding procedure com- ponents are illustrated in Figures 1/U.81 and 2/U.81. 3.2 The components of message forwarding procedures are as follows: 3.2.1 Call set-up Call set-up is the establishment of a connection by an SFU over the telex network up to and including the receipt of the call connect signal. In the event of an unsuccessful call set-up attempt, action shall be taken in accordance with S 5. 3.2.2 Called subscriber answerback validation 3.2.2.1 To ensure security of delivery the answerback of the called subscriber should be compared with the anticipated answer- back of the called subscriber, if supplied by the originating telex subscriber. 3.2.2.2 The evaluation procedure is given in Recommendation U.75. 3.2.3 Store and forward unit identification The telex SFU identification shall comprise: - the service code CI, - an indication that the call is from a telex SFU, - the date and time of transmission (optional). 3.2.4 Message identification The telex SFU should transmit to the called subscriber a mes- sage identification sequence comprising: a) the message reference as allocated and advised to the originating subscriber at the time of input of the telex message for onward delivery; b) the date and time of message input as issued to the originating telex subscriber in accordance with Recommendation U.80. Figure 1/U.81, p. Figure 2/U.81, p. 3.2.5 Answerback of originating telex subscriber The telex SFU shall transmit to the called subscriber the answerback of the originating subscriber as received at the time of message input. 3.2.6 Message text 3.2.6.1 The telex SFU should transmit to the called subscriber any message header information together with the stored message in the format in which it was originated by the calling subscriber. 3.2.6.2 The EOM/EOT separators and WRU shall not be transmit- ted. 3.2.6.3 If any signal is received on the backward path during the message text delivery, transmission of the message text shall be stopped for 2 seconds. If during that time further signals or a clearing condition is received, the call shall be cleared and the message delivery deemed unsuccessful, and action taken in accor- dance with S 5.4. If no further signals are seen on the backward path during that time, transmission of the message text shall be resumed. 3.2.7 Called subscriber answerback comparison 3.2.7.1 The answerback of the called subscriber shall be taken and compared with that received at the start of message delivery. 3.2.7.2 In the event of a mismatch of answerbacks, the answer- back of the called subscriber shall be taken once again, and if there is a match with that received at the start of message delivery, the delivery of the message shall be deemed successful. If there is a second mismatch, the delivery of the message shall be considered as unsuccessful, and further delivery attempts shall be made in accordance with S 5.4. 3.2.8 Answerback of originating telex subscriber The answerback of the originating subscriber, as per S 3.2.5, shall then be sent to the called subscriber. 3.2.9 Call clearing sequence The SFU should clear the call using normal telex clearing pro- cedures. 4 Notification procedures 4.1 General 4.1.1 The advice of non-delivery shall be provided. It should preferably include the list of addresses rejected at the time of address validation. 4.1.2 The advice of delivery over an international telex cir- cuit may be provided subject to bilateral agreement between the Administrations concerned. 4.1.3 Information concerning delivery/non-delivery of messages should be stored and kept available for enquiries from the origina- tor for a pre-defined period of at least 72 hours. 4.1.4 Notification of message delivery/non-delivery may be on a "per message" or "per address" basis. This Recommendation assumes that notification will be returned on a "per message" basis. The provision of a periodic (e.g. daily) notification or jour- nal shall be considered an acceptable form of notification. For a typical, acceptable journal format see Figure 3/U.81. 4.2 The sequence of notification forwarding procedure com- ponents are illustrated in Figures 4/U.81 and 5/U.81. 421000Z UIT CH CI SFU CH TO: 421000 UIT CH HERE IS YOUR JOURNAL FOR 28 APR 1983 REF CALLED ANSWERBACK TOD DURATION 12345 080271666 71666 HKTEL HX 1005 3.1 12987 051261848 261848 THQPH G 1043 2.1 36365 07222500 KDD TOKYO J22500 1240 1.8 36365 0230652464 TRANS A LSA 1240 1.9 36365 02105827847 CDN MARCO MTL 2045 1.8 36365 423635 423635 HERTZ CH -ABW CANCELLED 41696 07514899 14899 CWI HQ PS 1633 6.0 89635 090522222 -ABS PENDING 89777 023232323 232323 RCAEX UR 1731 1.6 89900 02105566412 -DER CANCELLED --------- TOTAL MINS 18.3 TOD 1983 04 29 0401 SFU CH 421000Z UIT CH FIGURE 3/U.81 Typical journal format Blanc Figure 4/U.81, p. Figure 5/U.81, p. 4.3 The components of notification forwarding procedure are as follows: 4.3.1 Call set-up The call set-up should be in accordance with S 3.2.1. 4.3.2 Originating subscriber answerback validation 4.3.2.1 To ensure security of delivery of the notification, the answerback of the originating telex subscriber is taken and compared with the answerback taken from the subscriber at the time of message input. 4.3.2.2 The evaluation procedure is given in Recommendation U.75. 4.3.3 Store and forward unit answerback The answerback of the telex SFU shall be transmitted to the called subscriber. 4.3.4 Store and forward unit identification The telex SFU identification shall be transmitted as per S 3.2.3. 4.3.5 Message identification The telex SFU shall transmit to the called subscriber the mes- sage identification sequence issued at the time of input of the message. The format of the message identification should be in accor- dance with S 3.2.4. 4.3.6 Notification message The notification advice may comprise for each applicable address of a single or multi-address message the following: (See Figure 6/U.81 for example of suggested format.) Example of Delivery Advice 5519751 19751 MIPEN DK Address - Expected A/B DELIVERED 19751 MIPEN DK Advice - Received A/B 18:00 01M 20S Time of Delivery - Duration Example of Non-Delivery 5519751 19751 MIPEN DK Address - Expected A/B NOT DELIVERED Advice - Received A/B (See Note) OCC 4 Reason - No. of Attempts. Note - Only used if incorrect answerback is reason for non-delivery. FIGURE 6/U.81 4.3.6.1 Non-delivery advice - selection information (telex address) - expected answerback (as provided at message input) - notification, i.e. "NOT DELIVERED" - received answerback (if applicable) - reason for non-delivery - number of attempts. 4.3.6.2 Delivery advice - selection information (telex address) - expected answerback (as provided at message input) - notification, i.e. "DELIVERED" - received answerback - date and time of delivery - duration of call. 4.3.7 Called subscriber answerback validation 4.3.7.1 Answerback comparison of the called subscriber shall be in accordance with S 3.2.7. 4.3.8 Telex SFU answerback The answerback of the SFU shall be transmitted to the called subscriber. 4.3.9 Call clear The calling telex SFU should clear the call using normal telex procedures. 5 Delivery re-attempt procedures 5.1. The principles of Recommendation U.40 shall be applied for all delivery/notification re-attempt requirements. 5.2 If the service signal RDI or NCH is received during call set-up more than once in any one message delivery/notification attempt cycle, the message shall be considered undeliverable. 5.3 Recorded message from called subscriber 5.3.1 If the recorded message is followed by clear, the mes- sage shall be considered undeliverable. 5.3.2 Action to be taken by the telex SFU if the recorded mes- sage is not followed by clear, needs further study. 5.4 In the failure of an established connection per cases men- tioned in S 3.2.6.3 or 3.2.7.2 above, one further attempt to deliver the message may be made after an interval of at least 3 minutes; in this case the message text shall be preceded by POS- SIBLE DUPLICATE MESSAGE. 5.5 The action to be taken when a notification cannot be delivered should be the responsibility of the Administration offer- ing the telex SFU service and is a national matter. Recommendation U.82 INTERNATIONAL TELEX STORE AND FORWARD - INTERCONNECTION OF TELEX STORE AND FORWARD UNITS (Malaga-Torremolinos, 1984) The CCITT, considering (a) the need for telex store and forward services; (b) the increasing need to transfer messages of different types and having a variety of formats; (c) that the Series F Recommendations define existing telex and new telematic services, that the Series S of Recommendations define control procedures for new telematic services; (d) that Recommendations X.60, X.61, X.70, X.71, X.75 and X.121 permit international connection between public data networks; (e) that the Series V Recommendations provide the means for data communication over the telephone network; (f ) that the Series X Recommendations define message han- dling systems, unanimously declares the following 1 Scope 1.1 This Recommendation defines the interworking procedures to facilitate the international exchange of messages between computer-based telex store and forward units. 1.2 This Recommendation is one of a series of Recommendations which define international telex store and forward services. These Recommendations are: - Recommendation F.72: International telex store and forward - general principles and operational aspects - Recommendation U.80: International telex store and forward - access from telex - Recommendation U.81: International telex store and forward - delivery to telex - Recommendation U.82: International telex store and forward - interconnection of telex store and forward units 1.3 Definitions The following terms used in this Recommendation have the undermentioned definitions: 1.3.1 store and forward unit (SFU) Computer equipment with associated storage that accepts mes- sages from telex subscribers for subsequent delivery to specified telex address or addresses. Conversational mode operation is not provided. 1.3.2 network management boundary The boundary within which the telex store and forward service is provided by one or more telex SFUs under the control of one Administration. 1.3.3 originating SFU The telex SFU forwarding the telex message. 1.3.4 destination SFU The telex SFU receiving the telex message. 1.3.5 inter-telex SFU messages (IM) Messages transferred between telex SFUs to complete the func- tion of message transfer. 1.3.6 message transfer unit (MXU) The basic element of the inter-telex SFU message transfer pro- cedure. 1.3.7 user message transfer unit (UMXU) Used to carry the message submitted by a telex subscriber for delivery to a specified address. 1.3.8 service message transfer unit (SMXU) Used to convey service information about messages. 1.3.9 text transfer (TT) A type of UMXU used to transfer address information and the subscriber message. 1.3.10 status request (SRQ) A type of SMXU used to request, from a destination telex SFU, the present status of the message. 1.3.11 status report (SRPT) A type of SMXU used to report the status of a message and sent only in response to an SRQ. 1.3.12 delivery notification (DN) A type of SMXU used to provide information on an address or addresses to which a message has been delivered. 1.3.13 non-delivery notification (NDN) A type of SMXU used to provide information on an address or addresses to which the message has not been delivered. 1.3.14 combined delivery/non-delivery notification (CN) A type of SMXU used to provide information on whether a mes- sage has been delivered or not delivered to a number of addresses. 1.3.15 header The portion of the MXU which contains the information to ser- vice the control need of the calling telex SFU. 1.3.16 message block The portion of the MXU which contains the information to be transferred between the telex SFUs. 2 Service outline 2.1 The telex SFU service allows a telex subscriber to deposit single or multi-address messages with a telex SFU for subsequent delivery to the specified address or addresses. (The services and facilities to be offered internationally are the subject of Recommendation F.72) 2.2 In the event of a failure to deliver to any address or addresses, a non-delivery notification is issued to the originating telex subscriber. The requirement to send a non-delivery notifica- tion is mandatory. Transmission of non-delivery notifications may occur on a per address or per multi-address basis. 2.3 A delivery notification for successful delivery and/or subscriber initiated status enquiry information may also be issued. 3 International interconnection 3.1 The extension of telex SFU services beyond the management network boundary of an Administration requires co-operation between telex SFUs across international connections. 3.2 In the international interconnection of telex SFUs the responsibility to deliver single and multi-address messages is transferred from the originating Administration to one or a number of destination Administrations. 3.3 In the basic service, messages addressed to more than one destination telex SFU management network should be separated at the originating management network. 3.4 The possibility of forwarding messages via transit manage- ment networks is for further study. 3.5 In the international interconnection of telex SFUs it is necessary to return delivery/non-delivery status information to the originating telex SFU. This information is compiled on a per address basis at the destination telex SFU either when the message has been delivered or when no further attempts to deliver will be made to that address. 3.6 The return of delivery and non-delivery information to the originating telex SFU may be on a per address or per message basis. 3.7 When information is issued on a per message basis the ori- ginating telex SFU may request interim message delivery status reports by transmitting message status requests. 3.8 Delivery and non-delivery information provided on a per message address basis requires explicit notification to the ori- ginating telex SFU. 3.9 Delivery and non-delivery information provided on a per message basis may require only explicit notification of non-deliveries and implicit notification of deliveries. 3.10 The method employed on an international connection between telex SFUs to transfer delivery/non-delivery status infor- mation should be the subject of bilateral agreement. Account must be taken of the means by which the interconnection is established and the possible effects on service. 3.11 The storage of messages during the specified period for messages (or addresses) requiring delayed delivery should generally be carried out by the originating telex SFU. In this case the delay indicator is omitted in the corresponding message to the destina- tion telex SFU. When the delay action is not carried out in the originating telex SFU, the appropriate delay indicator should be retained. 4 Message transfer 4.1 International connection between telex SFUs may be achieved by use of the following: a) telex network; b) packet switched data networks (PSDN); c) circuit switched data networks (CSDN); d) public switched telephone network (PSTN); e) direct circuits (50 baud and medium speed). 4.2 The cooperation of two or more telex SFUs may be required to complete the function of a message transfer. Such cooperation between telex SFUs is achieved by use of an inter-telex SFU message transfer procedure. 4.3 The general structure of an inter-telex SFU message transfer procedure is described in Figure 1/U.82. Figure 1/U.82, p. 5 Elements of inter-telex SFU message (IM) transfer procedure 5.1 The basic element of the IM transfer procedure is the mes- sage transfer unit (MXU). The MXU is classified as either a user MXU (UMXU) or service MXU (SMXU) allowing easy identification of the function(s) for which cooperation is required. 5.2 UMXUs carry messages submitted by a telex customer for delivery to a specified address or addresses. 5.3 SMXUs do not contain telex customer messages but are used to convey service information about messages. SMXUs of two types have been identified: a) notification (delivery and/or non-delivery) b) status (enquiry/report) Use of other SMXU types is for further study. 5.4 Notification SMXUs are issued automatically by the telex SFU. Status SMXUs are generated by the telex SFU as a result of a customer request or in response to a received status SMXU. 5.5 There are 6 types of MXU used to provide a telex SFU interworking capability. 5.5.1 Text transfer (TT) TT is used to transfer address information and the message as a UMXU. 5.5.2 Status request (SRQ) SRQ is an SMXU and is used to request from a destination telex SFU the present status of message delivery to: a) all addresses b) those addresses to which the message has not been delivered c) specified addresses. 5.5.3 Status report (SRPT) SRPT is an SMXU and is only used in response to an SRQ. 5.5.4 Delivery notification (DN) DN is an SMXU and is used to provide information on an address or addresses to which the message has been delivered. 5.5.5 Non-delivery notification (NDN) NDN is an SMXU and is used to provide information on an address or addresses to which the message has not been delivered. 5.5.6 Combined delivery/non-delivery notification (CN) An SMXU used to provide information on whether a message has or has not been delivered to a number of addresses. 5.6 The originating and destination telex SFUs transmit MXUs in accordance with Figure 2/U.82. Figure 2/U.82 [T1.82] (a traiter comme tableau MEP), p. 6 Methods of interworking 6.1 Administrations may provide telex SFU interworking service by any of three methods. These methods are shown diagrammatically in Figure 3/U.82. The method of interworking should be agreed bilaterally between Administrations. The following paragraphs describe operational procedures and are included for explanatory purposes. Figure 3/U.82, p. 6.1.1 Method 1 6.1.1.1 TT is issued by the originating unit. 6.1.1.2 When the destination unit has completed call process- ing, CN is returned to the originating unit. 6.1.1.3 It may only be necessary to transmit NDN instead of CN since deliveries are implicit (see S 3.9). 6.1.1.4 No SRQ or SRPT MXUs are issued. 6.1.2 Method 2 6.1.2.1 TT is issued by the originating unit. 6.1.2.2 NDN and DN MXUs are issued by the destination unit on a per address basis at the time the destination unit has completed processing for that address. 6.1.2.3 No SRQ or SRPT MXUs are issued. 6.1.3 Method 3 6.1.3.1 TT is issued by the originating unit. 6.1.3.2 SRQ MXUs are issued by the originating unit at the time of a customer demand. 6.1.3.3 SRPT MXUs are issued by the destination unit in response to SRQ MXUs. 6.1.3.4 When the destination unit has completed call process- ing CN is returned to the originating unit. 6.1.3.5 It may only be necessary to transmit NDN instead of CN since deliveries are implicit (see S 3.9). 6.1.4 The preferred operation is method 3. The generation of UMXU-TT, SMXU-CN, SMXU-SRQ and SMXU-SRPT is considered mandatory. The generation of SMXU-DN and SMXU-NDN is optional. 7 Message transfer unit (MXU) formation 7.1 An MXU is composed of a header and a message block. 7.1.1 Header 7.1.1.1 The header refers to the portion of an MXU which con- tains information to serve the control need of the calling telex SFU. 7.1.1.2 For an UMXU the header is constructed by the originat- ing telex SFU at the time a customer telex message is deposited with that unit, while in the case of an SMXU the header is created when the service message is generated. 7.1.1.3 Changing, adding to, or deleting from header informa- tion during the passage of an MXU through the telex SFU is for further study. 7.1.2 Message block 7.1.2.1 The message block contains that information that is to be transferred between telex SFUs and which is the reason the MXU has been generated. 7.1.2.2 The message block in an UMXU contains the text which is the customer message to be transferred from the originating telex subscriber to the specified address or addresses. 7.1.2.3 The customer message is inserted in the message block of an UMXU when a message deposited in a telex SFU is to be transmitted via another telex SFU. The message block is passed through the telex SFU and subsequent telex SFU(s) transparently. 7.1.2.4 The message block of an SMXU contains the service information which is inserted when the service message is gen- erated. This information may or may not be passed transparently through the telex SFU to the message originating customer. The exact use of this information is a national matter and is outside the scope of this Recommendation. 7.1.2.5 Service information required for insertion into the message block of a notification SMXU is stored at the telex SFU and is continually updated until it is automatically released to the originating telex SFU. 7.1.2.6 The information stored at the telex SFU may also be released in its interim form to the originating telex SFU as a status report SMXU. 7.1.2.7 The status report SMXU is an interim version of the resultant notification SMXU. 8 Message transfer unit (MXU) structure 8.1 MXUs may be of two classes: UMXU or SMXU. 8.1.1 SMXUs of two types have been identified: a) notification (delivery and/or non-delivery) b) status (enquiry/report) 8.2 User MXU Text transfer Header: MXU type identifier Message identity Destination telex SFU identity Message code indicator Delivery address Expected answerback Notes 1 and 4 Attention information Delay indication Message block: Subscriber text 8.3 Service MXU a) delivery notification Header: MXU type identifier Message identity (originator) Destination telex SFU identity Message code indicator Transit identities, (Note 2) Message block: Status Called address Received answerback Note 1 Date/time of last attempt (delivery date/time) Chargeable duration b) non-delivery notification Header: MXU type identifier Message identity (originator) Destination telex identity Message code indicator Transit identities (Note 2) Message block: Status Called address Answerback, if received Note 1 Date/time of last attempt Reason c) combined delivery/non-delivery notification Header: MXU type identifier Message identity (originator) Destination telex SFU identity Message code indicator Transit identities (Note 2) Message block: Status Called address Answerback, if received Notes 1 and 3 Date/time of last attempt Reason Chargeable duration d) status request Header: MXU type identifier Message identity (originator) Destination telex SFU identity Message code indicator Message block: either i) request status report on all message addresses associated with message or ii) request status report on addresses to which message has not been delivered or iii) request status report on specified address(es) (Note 5) e) status report Header: MXU type identifier Message identity (originator) Destination telex SFU identity Message code indicator Transit identities (Note 2) Message block: Status Called address Answerback, if received Note 1 Date/time of last attempt Reason Chargeable duration Note 1 - This information may be repeated on a per address basis. Note 2 - The use of transit identities is for further study. Note 3 - Reason and chargeable duration are mutually exclusive. Note 4 - In the absence of any field, the field should be indicated by an end of field delimiter. See Annex A and Appendix I. Note 5 - This message block contains the specified delivery addresses. Blanc 8.4 Table 1/U.82 summarizes the MXU structure. H.T. [1T2.82] TABLE 1/U.82 Message transfer unit structure ___________________________________________________________________________________________________________________________________________________________________________________________________ UMXU SMXU Text transfer (TT) Delivery notification (DN) { { Type Status request (SRQ) Status report (SRPT) ___________________________________________________________________________________________________________________________________________________________________________________________________ Type identity Type identity Type identity Type identity Type identity Type identity ___________________________________________________________________________________________________________________________________________________________________________________________________ Message identity (Note 1) Message identity (Note 1) Message identity (Note 1) Message identity (Note 1) Message identity (Note 1) Message identity (Note 1) ___________________________________________________________________________________________________________________________________________________________________________________________________ { Destination SFU identity (Note 6) } { Destination SFU identity (Note 6) } { Destination SFU identity (Note 6) } { Destination SFU identity (Note 6) } { Destination SFU identity (Note 6) } { Destination SFU identity (Note 6) } ___________________________________________________________________________________________________________________________________________________________________________________________________ Message code indicator Message code indicator Message code indicator Message code indicator Message code indicator Message code indicator ___________________________________________________________________________________________________________________________________________________________________________________________________ Header . Transit identities Transit identities Transit identities . Transit identities ___________________________________________________________________________________________________________________________________________________________________________________________________ . Delivery address (Note 2) ___________________________________________________________________________________________________________________________________________________________________________________________________ . { Expected answerback (Notes 2, 7) } ___________________________________________________________________________________________________________________________________________________________________________________________________ . { Attention information (Notes 2, 7) } ___________________________________________________________________________________________________________________________________________________________________________________________________ . { Delay indication (Notes 2, 7) } ___________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 1/U.82 [1T2.82], p. H.T. [2T2.82] TABLE 1/U.82 (continued) ___________________________________________________________________________________________________________________________________________________________________________________________________ UMXU SMXU Text transfer (TT) Delivery notification (DN) { { Type Status request (SRQ) Status report (SRPT) ___________________________________________________________________________________________________________________________________________________________________________________________________ . . Status Status Status . Status ___________________________________________________________________________________________________________________________________________________________________________________________________ . . Called address Called address Called address . Called address ___________________________________________________________________________________________________________________________________________________________________________________________________ . . Received answerback Answerback if received Answerback if received . Answerback if received ___________________________________________________________________________________________________________________________________________________________________________________________________ Date and time Last attempt Date and time Last attempt Date and time Last attempt . Date and time Last attempt Message block (Note 5) Subscriber text . Reason . Reason (Note 3) . Reason (Note 3) ___________________________________________________________________________________________________________________________________________________________________________________________________ . . { Chargeable duration (Note 3) } . { Chargeable duration (Note 3) } . { Chargeable duration (Note 3) } ___________________________________________________________________________________________________________________________________________________________________________________________________ . . . . . Request type ___________________________________________________________________________________________________________________________________________________________________________________________________ . . . . . { Specified address (Notes 2, 4) } ___________________________________________________________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 1/U.82 [2T2.82], p. 26 9 MXU information fields 9.1 Type Identity Types of MXU are identified by a type code of two numeric characters. The first character identifies the type and the second the function as described in Table 2/U.82. The identification of further types of MXU is for further study. H.T. [T3.82] TABLE 2/U.82 MXU type identity ________________________________________________________________________ Type identity Type MXU description Function 1st digit 2nd digit ________________________________________________________________________ 0 User message transfer Text transfer 0 1 ________________________________________________________________________ Delivery 1 1 Non-delivery 1 2 1 Notification 3 ________________________________________________________________________ Request 2 1 2 Status Report 2 2 ________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - 1st digit is the first digit to be transmitted. Table 2/U.82 [T3.82], p. 9.2 Message identity 9.2.1 The message identity should consist of four fields as shown in Table 3/U.82. H.T. [T4.82] TABLE 3/U.82 ______________________________________________________________________________________________________________________________________ Field Content ______________________________________________________________________________________________________________________________________ Originating country reference F.69 country code ______________________________________________________________________________________________________________________________________ { Originating telex SFU reference } 4-character numeric code ______________________________________________________________________________________________________________________________________ Message serial number { Serial number issued to the subscriber in the format specified in Recommendation U.80 } ______________________________________________________________________________________________________________________________________ Date and time { Date and time of message submission issued to the customer in the format specified in Recommendation U.80 } ______________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 3/U.82 [T4.82], p. 9.3 Destination telex SFU identity 9.3.1 The destination telex SFU identity should consist of two fields as shown in Table 4/U.82: H.T. [T5.82] TABLE 4/U.82 ___________________________________________________________ Field Content ___________________________________________________________ Destination country reference F.69 country code ___________________________________________________________ { Destination telex SFU identity } 4-character numeric code ___________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | Table 4/U.82 [T5.82], p. 9.4 Delivery address(es), expected answerback(s), attention information , and delay indication 9.4.1 The delivery address(es), expected answerback(s), atten- tion information, and delay indication should be in the format specified in Recommendation U.80. Expected answerback, attention information and delay indication are optional fields. 9.5 Message code indicator 9.5.1 This field indicates the format in which the message text is transmitted. The message code is indicated by a single numeric character; the following values have been assigned: International Telegraph Alphabet No. 2 (ITA2) 0 International Alphabet No. 5 (IA5) 1 Recommendation S.61 (Teletex) 2 Additional values of message code are for further study. 9.6 Delivery information 9.6.1 The delivery information should conform to the format and content specified in Recommendation U.81. 9.7 Non-delivery notification 9.7.1 The non-delivery information should conform to the for- mat and content specified in Recommendation U.81. 9.8 Combined delivery and non-delivery information 9.8.1 The combined delivery and non-delivery information should conform to the format and content specified in Recommenda- tion U.81. 9.9 Status request information 9.9.1 The status request information should conform to the content and format specified in Recommendation U.80. 9.10 status report information 9.10.1 The status report information should conform to the content and format specified in Recommendation U.81. 9.11 Status 9.11.1 The status field should indicate whether or not the message has been delivered to a specified address. The status is indicated by a single numeric character; the following values have been assigned: Delivered 0 Non-delivery 1 Additional values of status are for further study. 9.12 Request type 9.12.1 The request type indicates whether a status request is required for all addresses, those to which the message has not been delivered or for those specified addresses included in the SRQ mes- sage block. See S 8.3 d). The following values have been assigned: Request on all addresses 0 Request non-delivery reports only 1 Request report on specified address(es) 2 9.13 Transit identities 9.13.1 The transit identity field is reserved for future use and may be required for administrative purposes. The content and format of the field is for further study. 10 Principles of procedures and coding of inter-telex SFU messages 10.1 Use of the telex network 10.1.1 The principles for message transfers are illustrated graphically in Figures 4/U.82 to 8/U.82. 10.1.2 Call set-up should use normal telex call procedures. 10.1.3 Operation will normally be half duplex. Exceptionally, responses to MXU headers may be transmitted whilst operating in full duplex mode. The capability to operate full duplex is subject to bilateral agreement. 10.1.4 Inter-telex SFU messages should be distinguished from telex subscriber access messages by an interworking service request identifier (IRQ) which will be acknowledged by a service ack- nowledgement signal (IACK). 10.1.5 For link control purposes a preamble should precede the message header. This should consist of a character sequence as a block identity, a 3 alpha character circuit identity and a 3 numeric character serial reference. 10.1.6 The numeric character serial reference should increment sequentially and cyclically for each block transferred. No action is required by an SFU when the numbers received are not sequential, but this may be used nationally by Administrations to indicate pos- sible fault conditions. 10.1.7 An end of message signal should be sent by the ori- ginating telex SFU which should be acknowledged by a message block acknowledgement signal from the destination telex SFU. The ack- nowledgement signal should be a character sequence similar to the preamble detailed in S 10.1.5 indicating the circuit on which the message was originally transmitted and the serial reference. 10.1.8 If the originating telex SFU does not receive both ack- nowledgement signals the original whole message (header and text) should be retransmitted. 10.1.9 Follow-on messages should be indicated by the receipt of a new message header. See Figure 6/U.82. 10.1.10 It should be possible for either telex SFU to interrupt an incoming transmission by using an interrupt transmission signal. 10.1.11 After the reception of the last block acknowledgement, an end of transmission signal should be transmitted by the originating unit before normal telex clearing procedures. 10.1.12 When the receiving telex SFU cannot offer the interworking service or when the telex SFU cannot accept message text transfers, because of storage limitations or failure conditions, the service signal NC followed by a clear signal should be transmitted. 10.1.13 When service signals are to be transmitted by the destina- tion telex SFU to an originating SFU that is itself transmitting, the destination SFU shall transmit an interrupt transmission signal (see Table 5/U.82) until received transmission ceases. This shall be subject to an overall timeout of 20 seconds. The service signal shall then be transmitted following transmission of a mark signal for 3 seconds. 10.1.14 All information should be coded in accordance with ITA2. 10.1.15 The action to be taken in the event of abnormal conditions during the message transfer stage should be the subject of bila- teral agreement. Standardization of this action is for further study. 10.1.16 Table 5/U.82 shows the coding for interworking signals. 10.1.17 The field delimiter for all fields in an MXU should be com- bination No. 26 (+). This should be preceded by combination No. 30 (F/S) when necessary. The delimiters within the fields specified in S 9.4 should be in accordance with Recommendation U.80. 10.1.18 Examples of field coding and content of MXUs when using the telex network are shown in Appendix I. Figure 4/U.82, p. Figure 5/U.82, p. Figure 6/U.82, p. Figure 7/U.82, p. Figure 8/U.82, p. H.T. [T6.82] TABLE 5/U.82 Interworking signals _____________________________________________________________________________________________________ Description Coding ITA2 _____________________________________________________________________________________________________ IRQ { Combination No. 29; combination No. 26; combination No. 3; combination No. 19; combination No. 6 (ZCSF) } _____________________________________________________________________________________________________ IACK { Combination No. 29 followed by combination No. 9, combination No. 7, combination No. 1 (IGA) } _____________________________________________________________________________________________________ Block identity { Combination No. 26; combination No. 3; combination No. 13; combination No. 19 (ZCMS) } _____________________________________________________________________________________________________ Circuit identity 3 alpha characters _____________________________________________________________________________________________________ Serial reference 3 numeric characters _____________________________________________________________________________________________________ End of message block 4 combinations No. 14 (NNNN) _____________________________________________________________________________________________________ Block acknowledgement { Combination No. 26; combination No. 3; combination No. 1; combination No. 11 (ZCAK). See S 10.1.6 } _____________________________________________________________________________________________________ End of transmission 4 combinations No. 26 (ZZZZ) _____________________________________________________________________________________________________ Interrupt transmission { Continuous combinations No. 20 until received transmission ceases (TTTTTT...) } _____________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 5/U.82 [T6.82], p. 10.2 Use of direct circuits for asynchronous transmission 10.2.1 The direct circuit should be used in a half duplex mode to allow for acknowledgements of the information transmitted. The data transmission rate to be used on the international circuit should be agreed bilaterally. 10.2.2 The procedures and coding when using direct circuits for interconnection between telex SFUs should be identical to those in the case of use of the telex network but without the call set-up and call clearing phases. Thus, the procedures commence with the transmission of the IRQ signal. 10.2.3 The characters may be coded in either ITA2 or IA5. The coding should be fixed on a direct circuit basis and the code used should be agreed bilaterally. 10.2.4 Where circuits are used in a bothway mode the telex call collision procedures should be agreed bilaterally. 10.2.5 Call collision should be detected by checking the response to the service request signal (IRQ). In cases where the response is a service request signal from the other unit a call collision situation is indicated. 10.2.6 On circuits used for bothway transmission bilateral agreement will be required to determine usage in each direction to minimize the occurrence of call collisions. 10.2.7 Examples of field coding and content of MXUs when using asynchronous circuits are shown in Appendix I. 10.3 Use of public switched data networks 10.3.1 Asynchronous circuit switched data networks 10.3.1.1 These procedures apply to data networks operating for Recommendation X.1 user classes of service 1 and 2. The data transmission rate to be used should be agreed bilaterally. 10.3.1.2 Call connections between telex SFUs should be established in accordance with Recommendation X.70. 10.3.1.3 Telex SFU addresses used to establish the connection should conform to Recommendation X.121. 10.3.1.4 Calling and called line identifications may be requested to verify correct connection. 10.3.1.5 Following establishment of a connection between telex SFUs, MXUs should be transferred in accordance with the procedures described in S 10.1 for the telex network. 10.3.1.6 Coding should be in IA5 or ITA2 or the character set defined in Recommendation S.61 with the message code indicator set accordingly. The coding used on a connection between any 2 telex SFUs should be agreed bilaterally and should not be negotiable on a per call basis. 10.3.1.7 Access to the interworking service may be restricted by means of closed user group characters. 10.3.1.8 Character conversion between ITA2 and IA5 should be car- ried out by each telex SFU in accordance with Recommendation S.18 and between ITA2 and Recommendation S.61 in accordance with Recommendation S.60. 10.3.1.9 Administrations may, following call set-up, operate in accordance with S 10.3.2. This method of operating is a matter for further study. 10.3.2 Synchronous data networks 10.3.2.1 The procedures described in this section apply to calls established between telex SFUs over data networks operating for Recommendation X.1 user classes 3 to 11. The data transmission rate to be used on the international circuit should be agreed bila- terally. 10.3.2.2 The procedures may also apply to user classes 1 and 2 after call set-up (see S 10.3.1). 10.3.2.3 The call set-up and transport procedures should be gen- erally in accordance with Recommendation S.70 with the following qualifications: i) the network layer should be Recommendation X.75 for PSDNs and Recommendation X.71 for CSDNs; ii) a special class of traffic signal may be used on CSDNs; iii) a special traffic class indication may be used on PSDNs. 10.3.2.4 Control procedures for the transfer of messages between telex SFUs should be based on Recommendation S.62, CCITT Yellow Book , 1980. 10.3.2.5 The preferred operation for the basic telex SFU intercon- nection should be the TWA session mode. The TWA mode is preferable when status reports are requested from the distant telex SFU. The use of the OWC session mode may also be used and should be the sub- ject of bilateral agreement. 10.3.2.6 Telex SFUs may also operate in a TWS session mode in order to increase the speed of interchange when messages are required in both directions. The principle of operating in the TWS session mode should be agreed bilaterally. 10.3.2.7 The MXU should be transferred in session and document ele- ments of procedure. 10.3.2.8 The UMXU should be transferred as a control document con- taining the header, including delivery address(es), expected answerback, attention information and delay indication, in the con- trol text together with an associated normal document containing the message block. 10.3.2.9 The UMXU document structure is shown in Figure 9/U.82. 10.3.2.10 The absence of the document identifier shall indicate the normal document. 10.3.2.11 The UMXU control document shall be transmitted first fol- lowed immediately by the normal document. 10.3.2.12 The SMXU should be transferred as a control document. 10.3.2.13 The SMXU structure is shown in Figure 10/U.82. 10.3.2.14 Any number of control and normal documents may be transferred during a session. Figure 11/U.82 shows an example of a document transfer session. Figure 9/U.82, p. Figure 10/U.82, p. Figure 11/U.82, p. 10.3.2.15 Page boundaries may be transmitted by the originating SFU in a text transfer MXU in the message block. These check points will be recognized by the destination SFU for error recovery pur- poses and may also be included in the message output to the telex subscriber by the insertion of 10 line feeds (ITA2 combination No. 28). 10.3.2.16 When the message block text has no page boundary, error recovery procedures may be based on Annex G of Recommendation S.62. 10.3.2.17 Any one MXU should normally be transferred during a sin- gle session. If a session is interrupted it may be possible to con- tinue the transfer using CDC after setting up a new session. 10.3.2.18 The basic telex SFU interworking connection should only use those PGIs and PIs defined as mandatory in Tables 9/S.62 and 10/S.62. 10.3.2.19 The use of other PGIs and PIs defined in Recommendation S.62 is for further study. 10.3.2.20 Delivery address, expected answerback and attention information should be transferred in a control document immediately following establishment of document level procedures. 10.3.2.21 MXU message blocks should be transferred in normal and control documents as a sequence of characters coded as defined by the message code indicator. Examples of the control text in the control document are shown in Annex A. 10.3.2.22 The control document content may serve two purposes: a) to provide management information that may be used for accounting, statistics, etc. b) to provide subscriber information. To achieve b) the information should be in a format suitable for forwarding directly to the customer. 10.3.2.23 The use of the control document to provide subscriber information is a national matter. 10.3.2.24 The parameter values should be coded in accordance with the rules defined in Recommendation S.62. Thus, sequences of graphic characters will be coded using the character repertoire defined in Recommendation S.61. 10.3.2.25 The assignment of coding to the various parameter values relevant to the mandatory PGIs and PIs defined in Recommendation S.62 is shown below: 10.3.2.25.1 Terminal identifier of the called terminal A sequence of graphic characters as defined in Recommendation U.81. 10.3.2.25.2 Terminal identifier of the calling terminal A sequence of graphic characters as defined in Recommendation U.81. 10.3.2.25.3 Date and time A sequence of graphic characters in the format defined in Recommendation U.81. The values should indicate the time of transmission of the relevant command except for command document continue (CDC) where the date and time will be those in the command document start (CDS) of the first attempt to transmit the document. 10.3.2.25.4 Service identifier Bit 3 of the first octet should be set to 1 with all other bits set to 0 to indicate the telex SFU interworking service. All other codings are for further study. 10.3.2.25.5 All other mandatory parameters In accordance with Recommendation S.62. 10.3.2.26 Assignment of coding for the identifiers contained in the control text of the control document is as follows: 10.3.2.26.1 MXU type identity This parameter is a binary coded field of fixed length of one octet identifying the MXU type as given in Table 6/U.82. The hexadecimal representation of these octets is in accor- dance with Table 2/U.82. All other binary values are reserved for future standardiza- tion. H.T. [T7.82] TABLE 6/U.82 _______________________________________________________________ MXU type { Bit: 8 7 6 5 4 3 2 1 } _______________________________________________________________ Text transfer (TT) { Bit: 0 0 0 0 0 0 0 1 } Delivery notification (DN) { Bit: 0 0 0 1 0 0 0 1 } { Non-delivery notification (NDN) } { Bit: 0 0 0 1 0 0 1 0 } { Combined delivery/non-delivery notification (CN) } { Bit: 0 0 0 1 0 0 1 1 } Status request (SRQ) { Bit: 0 0 1 0 0 0 0 1 } Status report (SRPT) { Bit: 0 0 1 0 0 0 1 0 } _______________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 6/U.82[T7.82], p. 10.3.2.26.2 Message identity A sequence of graphic characters as defined in S 8. 10.3.2.26.3 Destination telex SFU identity A sequence of graphic characters as defined in S 8. 10.3.2.26.4 Transit identities The use of this parameter is for further study. 10.3.2.26.5 Message code indicator A binary encoded field of fixed length of one octet as in Table 7/U.82. All other binary values are reserved for future standardiza- tion. H.T. [T8.82] TABLE 7/U.82 ____________________________________ { Bit: 8 7 6 5 4 3 2 1 } ____________________________________ ITA No. 2 { Bit: 0 0 0 0 0 0 0 0 } IA No. 5 { Bit: 0 0 0 0 0 0 0 1 } S.61 { Bit: 0 0 0 0 0 0 1 0 } ____________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 7/U.82 [T8.82], p. 10.3.2.27 Service Interworking Identifier 10.3.2.27.1 Coding of the interworking identifier is for further study. 10.3.2.28 A formal definition of telex SFU MXUs and the field cod- ing is shown in Annex A. 10.4 Use of the public switched telephone network 10.4.1 Connection between SFUs should be automatically esta- blished using normal telephone procedures. 10.4.2 Following call establishment the procedures should be as defined in S 10.3 for PSDNs but using the data transfer phase of Recommendation X.25. 10.4.3 The normal mode of operation should be full duplex at 2400 bit/s using LAPX or level 2 of Recommendation X.75. 10.4.4 Exceptionally Administrations may agree bilaterally to operate using half duplex and/or at speeds other than 2400 bit/s. 10.5 Use of medium speed direct synchronous circuit 10.5.1 The procedures should be as defined in S 10.3.2 for PSDNs but using the call set-up phase. 10.5.2 The normal mode of operation should be full duplex using LAPX or level 2 of Recommendation X.75. 10.5.3 Links between telex SFUs can be used for multiple ses- sion and bothway working by means of a number of logical channels. ANNEX A (to Recommendation U.82) Examples of field coding and content of MXUs for interconnection of telex SFUs when using the synchronous data network procedures A.1 Introduction This annex specifies the structure and coding of MXUs using the notation defined in Recommendation X.409. This structure should be used when telex SFUs are intercon- nected with each other using the synchronous data network pro- cedures described in S 10.3.2. A number of data types that appear in the formal definition of MXUs are described in more detail in the following paragraphs. The formal definition of MXUs is shown in S A.3 and examples of the coding are shown in Figures A-1/U.82 to A-4/U.82. A.2 Description of data types In general the data types are described in S 9. Certain data types are described below to provide clarification on format. A.2.1 Type identity The MXU type is identified by a type number coded in accor- dance with Table 2/U.82. TypeIdentity ::= [APPLICATION 3] IMPLICIT INTEGE { TT (1),DN (17),ND (18),CN (19),SRQ (33),SRPT (34 } where TT Text transfer DN Delivery notification ND Non-delivery notification CN Combined delivery/non-delivery notification SRQ Status request SRPT Status report A.2.2 Message identity The message identity is described in S 9.2. MessageIdentity ::= [APPLICATION 4] IMPLICIT SEQUENC { origCountryRef NumericString, origSFURef NumericString, messagesSerialNumber NumericString, origTime DateandTim } The originating country reference is the 2 or 3 digits F.69 country code. The originating SFU reference is a 4 character numeric code. Message serial number is a 6 digit number. The originating time is defined as a date and time type and represents the local time at the originating telex SFU. OrigTime ::= DateandTime DateandTime ::= [UNIVERSAL 24] IMPLICIT IA5String Thus an originating (local) time of 12.22 PM on 9 May 1983 which is represented by the value "8305091222" can be encoded as: DateandTime Length Contents 18 | A 38333035303931323232 16 | 16 16 A.2.3 Message code indicador The message code indicator describes the coding of the message text contained in the MXU message block and can be ITA2, IA5 or S.61. MessageCodeIndicator ::= [APPLICATION 6] IMPLICIT INTEGE { ITA(0),IA5(1),S61(2 } It should be noted that the message code indicator only refers to the coding of the MXU message block and is not applicable to any other data types. Although the text coding is also described in the UMXU message block structure (S A.2.4) this indicator is retained for completeness in the structure of an MXU Header. A.2.4 UMXU message block The UMXU message block contains the message text received from the subscriber and can be coded in ITA2, IA5 or S.61. The coding must be in accordance with the message code indicator. UMXUMessageBlock ::= [APPLICATION 1] CHOIC { ITA2String, [0] IMPLICIT S61String [1] IMPLICIT IA5Strin } A.2.5 ITA2 string An ITA2 String represents an ordered set of zero or more char- acters chosen from the set defined by Recommendation F.1 in Table 1/F.1. The ITA2 String is formally defined below. Each octet contains a single 5 unit code. Bits 8-6 of each octet are zero and bits 5-1 correspond to element numbers 5-1 using the F1 element numbering convention. ITA2String :: [APPLICATION 7] IMPLICIT OCTET STRING A.2.6 Delivery information The delivery information contains one data type, delivery address, that will always be present. The remaining data types are optional in the sense that they will be present if and only if the originating SFU has been supplied with the information. DeliveryInformation ::= SEQUENC { deliveryAddress [0] IMPLICIT NumericString, expectedAnswerback [1] IMPLICIT IA5String OPTIONAL, attentionInformation [2] IMPLICIT IA5String OPTIONAL, delayIndication [3] IMPLICIT IA5String OPTIONA } The delivery address is the called international telex address in the format of the F.69 country code and national number. The format of the expected answerback and attention informa- tion should remain as provided by the calling subscriber. The delay indication, when present, describes the type of delivery delay required. The format of this field should be: a) D if the calling subscriber leaves the period of delay to the discretion of the Administration providing the SFU service, b) DXY where XY are numeric characters which specify the minimum desired delay in hours from 01-23. c) LXY where XY are numeric characters (01-24) which specify the maximum time limit for delivering the message to the address. A.2.7 SMXU message block The data values contained in the octets of both the notifica- tion and status report SMXU message block and the status request SMXU message block should be coded in accordance with the message code indicator described in S A.2.4. A.2.8 Notification and status report SMXU message block The notifications and status reports provide information about the delivery status of messages to called addresses. The optional data types will be present if and only if the SFU transmitting the SMXU message block has the required information. NotificationandStatusReportSMXUMessageBlock ::= [APPLI- CATION 8 IMPLICIT SEQUENCE OF SEQUENC { [0] IMPLICIT Status , [1] IMPLICIT CalledAddress, [2] IMPLICIT Answerback OPTIONAL, [3] IMPLICIT LastAttemptTime OPTIONAL, CHOICE [4] IMPLICIT Reason , [5] IMPLICIT ChargeableDuration OPTIONA } A.2.9 Last attempt time The last attempt time represents a time of day local to the SFU which has the responsiblity for delivering the message. The format of the last attempt time is a string of characters YYMMDDHHNN, where YY represents two numeric characters indicating the year MM represents two numeric characters indicating the month DD represents two numeric characters indicating the day HH represents two numeric characters indicating the hour NN represents two numeric characters indicating the minute LastAttemptTime ::= [APPLICATION 10] IMPLICIT OCTET STRING The coding of the octet string should be in accordance with the message code indicator described in S A.2.4. A.2.10 Reason The reason indicates why a delivery attempt has failed. The reason is a string of characters forming the service code that should be returned to the subscriber. Reason ::= [APPLICATION 11] IMPLICIT OCTET STRING The coding of the octet string should be in accordance with message code indicator described in S A.2.4. A.2.11 Chargeable duration The chargeable duration represents the time in minutes and seconds for which the call should be charged. The chargeable dura- tion is a string of 5 characters in the format MMM.M, where MMM represents the time in minutes (0-999) and N represents the time in tenths of minutes (0-9). The separator is a full stop. ChargeableDuration ::= [APPLICATION 14] IMPLICIT OCTET STRING The coding of the octet string should be in accordance with the message code indicator described in S A.2.4. A.2.12 Transit identities The transit identities format is subject to further studies on transit store and forward, but will consist of a sequence of tran- sit identity information for each transit unit used in the order of call establishment. A.3 Format definition of telex SFU MXUs MXU ::= CHOIC { 0] IMPLICIT UMXU , [1] IMPLICIT SMXU } UMXU ::= SEQUENC { fBUMXUHeader, UMXUMessageBlock } UMXUHeader ::= [APPLICATION 0] IMPLICIT SEQUENC { TypeIdentity, MessageIdentity, DestinationSFUIdentity, MessageCodeIndicator, [0] IMPLICIT SEQUENCE OF DeliveryInformation UMXUMessageBlock ::= APPLICATION 1] CHOIC { ITA2String, [0] IMPLICIT S61String, [1] IMPLICIT IA5Strin } - message text received from subscriber, coded in accordance with message code indicator - - various header information - TypeIdentity ::= [APPLICATION 3] IMPLICIT INTEGE { TT (1),DN (17),ND (18),CN (19),SRQ (33),SRPT (34 } MessageIdentity ::= [APPLICATION 4] IMPLICIT SEQUENC { origCountryRef NumericString, origSFURef NumericString, messageSerialNumber NumericString, origTime DateandTim } DestinationSFUIdentity ::= [APPLICATION 5] IMPLICIT SEQUENC { destinationCountryRef NumericString, destinationSFURef NumericStrin } MessageCodeIndicator ::= [APPLICATION 6] IMPLICIT INTEGE { ITA2 (0),IA5 (1),S`1 (2 } DeliveryInformation ::= SEQUENC { deliveryAddress [0] IMPLICIT NumericString, expectedAnswerback [1] IMPLICIT IA5String OPTIONAL, attentionInformation [2] IMPLICIT IA5String OPTIONAL, delayIndication [3] IMPLICIT IA5String OPTIONA } ITA2String ::= [APPLICATION 7] IMPLICIT OCTET STRING SMXU ::= SEQUENC { SMXUHeader, MXUMessageBlock } SMXUHeader ::= [APPLICATION 2] IMPLICIT SEQUENC { TypeIdentity, MessageIdentity, DestinationSFUIdentity, MessageCodeIndicator, TransitIdentities OPTIONA } SMXUMessageBlock ::= CHOIC { NotificationandStatusReportSMXUMessageBlock, StatusRequestSMXUMessageBlock } NotificationandStatusReportSMXUMessageBlock ::= [APPLI- CATION 8] IMPLICIT SEQUENCE OF SEQUENC { [0] IMPLICIT Status , [1] IMPLICIT CalledAddress, [2] IMPLICIT Answerback OPTIONAL, [3] IMPLICIT LastAttemptTime OPTIONAL, CHOICE [4] IMPLICIT Reason, [5] IMPLICIT ChargeableDuration OPTIONA } StatusRequestSMXUMessageBlock ::= [APPLICATION 9] IMPLI- CIT SEQUENC { requestType [0] IMPLICIT INTEGE { requestAllAddresses (0), requestNonDeliveryAddresses (1), requestSpecifiedAddresses (2 } specifiedAddresses [1] IMPLICIT AddressList OPTIONA } - transit identities - - transit identities are for further study - TransitIdentities ::= SEQUENC { firstTrId [0] IMPLICIT NumericString OPTIONAL, secondTrId [1] IMPLICIT NUMERICString OPTIONAL, thirdTrId [2] IMPLICIT NumericString OPTIONAL, fourthTrId [3] IMPLICIT NumericString OPTIONAL, fifthTrId [4] IMPLICIT NumericString OPTIONA } -SMXU Message Block Information - - all octets are coded in accordance with the message code indicator - Status :: INTEGE { delivery (0), nonDelivery (1 } CalledAddress ::= OCTET STRING - called address is restricted to numeric characters - Answerback ::= OCTET STRING LastAttemptTime ::= [APPLICATION 10] IMPLICIT OCTET STRING Reason ::= [APPLICATION 11] IMPLICIT OCTET STRING ChargeableDuration ::= [APPLICATION 12] IMPLICIT OCTET STRING AddressList ::= SET { pecifiedAddress IMPLICIT OCTET STRIN } Blanc Figure A-1/U.82, p. Figure A-2/U.82, p. Figure A-3/U.82, p. Figure A-4/U.82, p. APPENDIX I (to Recommendation U.82) Examples of field coding and content of MXUs for interconnection of telex SFUs when using the telex network, direct circuits and circuit switched data networks using asynchronous transmission Cuadro, (UTMU-TT) [T9.92], p. Cuadro, (UTMS-NE) [T10.82], p. .rs Cuadro (UTMS-NNE) [T11.82], p. Cuadro (UTMS-CN) [T12.82], p. .rs Cuadro (UTMS-PE) [T13.82], p. Cuadro (UTMS-IE) [T14.82], p. BLANC MONTAGE: PAGE ... = PAGE BLANCHE SECTION 9 (Reserved) SECTION 10 (Reserved) SECTION 11 (Reserved) SECTION 12 (Reserved) Blanc