home *** CD-ROM | disk | FTP | other *** search
/ Telecom / 1996-04-telecom-walnutcreek.iso / technical / ixo.program.scripts / ixo.doc < prev    next >
Text File  |  1993-02-14  |  9KB  |  219 lines

  1. Here is a summary of the IXO protocol.  All typos and
  2. misinterpretations are mine.  This is based on reading the Glenayre
  3. Electronics book.  I have not yet implemented the automatic protocol,
  4. but I have implemented the manual one.
  5.  
  6. You are "remote entry device" and the system that you dial into is
  7. "paging central".
  8.  
  9. (1) Remote sends CR at two second intervals until paging central
  10. responds with ID= at correct baud rate or until three transmissions
  11. have been completed.  (This step exists to allow for possible future
  12. baud rate recognition).
  13.  
  14. Some systems have chosen to send ID= from the central if they do not
  15. receive CR in about two seconds.  This variation appears to be
  16. acceptable as the central continues to respond to CR's with ID='s.
  17.  
  18. (2) Central sends ID=.  Request for ID returned within one second of
  19. receipt of CR.  Paging central may, at its option, send CR or CR LF
  20. after ID=
  21.  
  22. Paging central may optionally choose to send ID= if it does not
  23. receive CR after appropriate waiting time.
  24.  
  25. FOR AUTOMATIC REMOTE ENTRY:
  26. At this point you can start following 2A or 2M depending on which
  27. sub-protocol you want to use.
  28.  
  29. (2A) Remote sends ESC SST  (typically ESC PG1)
  30. ESC signifies entry device intends to talk in automatic dump mode.
  31.  
  32. SS is a set of two alphanumeric charactoers signifying a type of
  33. service to be accessed:
  34.  
  35. For a paging service where:
  36. Field 1 = Pager ID 
  37.  
  38. Field 2 = Message
  39. SS will be sent at "PG".
  40.  
  41. Where T is a single alphanumeric character relating to the type of
  42. terminal or device attempting to send the message.  T = "1" is a
  43. category of entry devices using the same protocol.  The PETs and IXO
  44. devices are members of this category.  T = "7" or "8" or "9" are
  45. reserved for wild card terminals or devices which may relate to a
  46. specific users' system.
  47.  
  48. (3A) Remote sends 6-char alphanumeric password then CR.  (Password is
  49. optional and is, in general, reserved for future services.  Password
  50. may be interpreted as either a caller ID or a system entry key.
  51. Length of password, when used, may be different in some systems.)
  52.  
  53. When an incorrect logon sequence beginning with ESC is received, the
  54. paging central may respond with an ID= if it requires a
  55. retransmission.
  56.  
  57. (4A) Central responds with a message sequence (lines of text, each one
  58. followed by a CR).  (Typical messages are "Processing - Please Wait",
  59. "4 pages sent" or "Bad Phone Line Call Again".
  60.  
  61. (5A) Central then sends one of three sequences:
  62. CR ACK CR         This means "logon accepted"
  63. CR NAK CR         This means "requested again"
  64. CR ESC EOT CR     This means "Forced disconnect"
  65.  
  66. (6A) Central may then send another message sequence (optional).
  67.  
  68. (7A) Central sends ESC [p CR
  69. Message go ahead is sent when paging central is ready for new
  70. information.  The "p" is lowercase.
  71.  
  72. (8A) Remote sends STX field1 CR field2 CR field3 CR ... fieldn CR
  73. EEE <CHECKSUM> CR
  74. You can send as many fields as you wish.  PG terminals send the
  75. pager-id in field1 and the message in field2.  (no other fields are
  76. defined).  This entire message can be a max of 250 bytes.  A field may
  77. be any length and where necessary may be continued in following
  78. blocks.  A field always ends with a CR.  The CR field delimiter
  79. suggests CR may not be used within a field.  A block always begins
  80. with a STX and ends with a checksum followed by a CR.  The characters
  81. preceding the checksum depends on what, if anything, is continued
  82. beyond the block boundary.
  83.  
  84. EEE can be an ETX, ETB, or RS.
  85.  
  86. The ETX is used as a block termination indicator if a given
  87. transaction (fields 1 through N) ends within the block being
  88. transmitted.
  89.  
  90. The ETB is used as a block terminator if the transaction is continued
  91. into the next block, but the last field in the current block is
  92. complete.
  93.  
  94. If the last field within the current block is to be continued in the
  95. next block, no CR is inserted at the end of the first portion of the
  96. field and the US character is used as a block termination character.
  97. The CR terminating the broken field is sent at the end of the field in
  98. whatever block the field actually terminates.
  99.  
  100. No limit is established within the protocol itself regarding the
  101. number of transactions, the number of fields or the number of blocks
  102. per field; however, a particular user system may have limits on any of
  103. these items.
  104.  
  105. Some systems may be limited to one block per transaction and one
  106. transaction per telephone connection.
  107.  
  108. Each checksum is computed by performing the simple arithmetic sum of
  109. 7-bit values of all characters preceding it in that block.  (This
  110. means that the STX and ETB/ETX are included in the sum).  The checksum
  111. is then the least significant 12 bits of this resulting sum.
  112.  
  113. The checksum is transmitted as three printable ASCII characters having
  114. values between HEX 30 and HEX 3F (the characters 0123456789:;<=>?).
  115. The most significant four bits of the sum are encoded as the 4 LSB of
  116. the third chacter.  See example.
  117.  
  118. A normal paging system will have two fields only:
  119.  
  120. Field 1 = Pager ID
  121. (normally up to eight digits.  May include function and check digit).
  122.  
  123. Field 2 = Message
  124. Field 1 or field 2 may be empty.  For example, when a page is tone only,
  125. field 2 will be empty.  Even when empty, a field is followed by a CR.
  126. Some systems will reject transactions which have an empty field 2 for
  127. a display page or transactions which have an empty field 1.  Other
  128. systems are less restrictive.
  129.  
  130. (9A) The response to each block is one of four:
  131. Message sequence CR ACK CR   = OK, send next block.
  132. Message sequence CR NAK CR   = Checksum or transmission error, send last 
  133.  
  134.                                block again.
  135. Message sequence CR RS CR    = Abandon current transaction and go to next.
  136.                                RS may occur when the checksum is OK,
  137.                                but the current transaction violates a
  138.                                system rule.  At the option of the
  139.                                system, it may occure in other cases.
  140. Message sequence CR ESC EOT CR   = Begin disconnect.
  141.  
  142. Any of the responses may have an optional message sequence before
  143. them, although the system designer should understand the consequences
  144. to the user with all planned entry devices.
  145.  
  146. It is expected that many systems will save their message sequence
  147. responses until immediately before disconnect.  For some entry
  148. devices, it may also be desirable that message describing non-checksum
  149. error assocaiated with a particular transaction in a PG service will
  150. begin with the letter ID followed by the contents of field 1 for that
  151. transaction.
  152.  
  153. (10A) Remote sends EOT CR
  154. After reception of an ACK or RS for the last transaction in a given
  155. service, the entry device sends EOT CR meaning there are no more
  156. transactions remaining in this service.
  157.  
  158. (11A) Optional: Central sends a message sequence CR.
  159. Although optional, it is highly desirable.
  160.  
  161. (12A) Central sends RS CR
  162. An RS CR should be sent at this point if the paging central finds any
  163. data ACK in previous steps by the system to be unacceptable because of
  164. content (e.g. invalid pager number or a message field inappropriate
  165. for the type of pages, etc.)
  166.  
  167. (13A) Central sends ESC EOT CR
  168. then hangs up.
  169.  
  170. (14A) stop.
  171.  
  172. (2M) Remote sends M CR (capitol M then CR)
  173. Lack of ESC at beginning of response to ID signifies manual operation
  174. where applicable.  From here on it's undefined, but most systems ask
  175. (in English) for the info they need and then return you to step (1).
  176.  
  177. NOTES:
  178. Bell 103 300bps modem is standard, others may be used.  Protocol is
  179. ASCII with XON, XOFF either direction using 10-bit code (1 start, 7
  180. data, 1 parity, 1 stop) with even parity.
  181.  
  182. In the case of delays, the paging central shall wait at least four
  183. seconds (eight seconds for (1) (2) (2A)) before disconnecting the
  184. remote entry device.  The remote entry device shall wait at least 10
  185. seconds for a character from the central before hanging up.
  186.  
  187. Paging central may, at its option, send CR LF in place of CR at the
  188. end of any sequence.
  189.  
  190. For inital use of protocol, the paging central shall be equipped to
  191. receive full duplex using a Bell 103 compatible modem at 300 baud.
  192. Optionally, certain inputs may be capable of receiving 110 baud Bell
  193. 103 full duplex, 300/1200 baud Bell 212 full duplex.  No echo shall be
  194. employed in full duplex mode.  Any attempts at automatic baud rate
  195. determination shall be within the restraints of the specified
  196. protocol.
  197.  
  198.  
  199. SAMPLE Checksum Example:
  200.  
  201. STX   000 0010
  202. 1     011 0001
  203. 2     011 0010
  204. 3     011 0011
  205. CR    000 1101
  206. A     100 0001
  207. B     100 0010
  208. C     100 0011
  209. CR    000 1101
  210. ETX   000 0011
  211.     10111 1011
  212.     1   7   ;
  213.  
  214. So, the checksum is "17;"
  215.  
  216. There is also a really nice flowchart, which I can't reproduce here
  217. without much too much trouble.  ...and you wouldn't have known it
  218. existed if I hadn't told you. :-)
  219.