TRANSCRIBER'S FOREWORD: Items like [1] are their footnotes, and usually follow the table they're in. Items like {1} are my notes, based on my experience implementing from this crummy document, and follow at the end. If you have questions about this, consult your paging vendor's linesmen or engineers, not me. If you just want to say thanks, grumble, or complain, you can reach me at mc!Brad_Hicks@mhs.attmail.com, or at jbhicks@mcimail.com, or (X.400) c=US, admd=ATTMail, prmd=MasterCard, sn=Hicks, gn=Brad.
I work for MasterCard as a senior PC specialist, and that's why their name appears in my X.400 address. This document is 100% my responsibility; if you have a beef, it's with me, not with them.
In order to decrease holding times on input lines to alphanumeric systems, it was desirable to promote input devices which will allow off-line entry of paging information and dump this data quickly after connection to the central paging terminal. This protocol was known as the IXO alphanumeric protocol until it was adopted for the input of paging requests. It is now referred to as the Telocator Alphanumeric Protocol (TAP).
+----------------------+----------------------+----------------------+
| REM. ENTRY DEV. DOES | PAGING CENTRAL DOES | COMMENTS |
+---+----------------------+----------------------+----------------------+
| 1 | Off hook-access DDD | | |
| | line. | | |
| | Await dial tone. | | |
| | Dial stored access | | |
| | number | Ring Answer | |
+---+----------------------+----------------------+----------------------+
| 2 | Carrier up | Carrier up | |
+---+----------------------+----------------------+----------------------+
| 3 | "<CR>" [1] | | <CR> is repeated at |
| | | | two second intervals |
| | | | until paging central |
| | | | responds with ID= at |
| | | | correct baud rate or |
| | | | until three trans- |
| | | | missions have been |
| | | | completed. (This |
| | | | step exists to allow |
| | | | for possible future |
| | | | baud rate recogni- |
| | | | tion). |
| | | | |
| | | | Some systems have |
| | | | chosen to send ID= |
| | | | from the central if |
| | | | they do not receive |
| | | | <CR> in about two |
| | | | seconds. This vari- |
| | | | ation appears to be |
| | | | acceptable as the |
| | | | central continues to |
| | | | respond to <CR>s |
| | | | with ID= s. |
+---+----------------------+----------------------+----------------------+
| 4 | | "ID= " {1} | Request for ID re- |
| | | | turned within one |
| | | | second of receipt of |
| | | | <CR>. Paging central |
| | | | may, at its option, |
| | | | send <CR> or <CR><LF>|
| | | | after ID=. |
| | | | |
| | | | Paging central may |
| | | | optionally choose to |
| | | | send ID= if it does |
| | | | not receive <CR> |
| | | | after an appropriate |
| | | | waiting time. |
+---+----------------------+----------------------+----------------------+
[1] All quotation marks or the symbols <> shown are used for notation and are not transmitted.
Two options exist at this point:
+----------------------+----------------------+----------------------+
| REM. ENTRY DEV. DOES | PAGING CENTRAL DOES | COMMENTS |
+---+----------------------+----------------------+----------------------+
| 5A| For automatic remote | | <ESC> signifies |
| | entry devices. | | entry device intends |
| | | | to talk in automatic |
| | "<ESC>SST" {2} | | dump mode. SS is a |
| | | | set of two alpha- |
| | Typical Example: | | numeric characters |
| | "<ESC>PG1" | | signifying a type of |
| | | | service to be ac- |
| | | | cessed. |
| | | | |
| | | | For a paging service |
| | | | where: |
| | | | Field 1 = 'Pager ID' |
| | | | and |
| | | | Field 2 = 'Message'. |
| | | | |
| | | | SS will be sent as |
| | | | 'PG'. |
| | | | |
| | | | Where T is a single |
| | | | alphanumeric char- |
| | | | acter relate to the |
| | | | type of terminal or |
| | | | device attempting to |
| | | | send the message. |
| | | | |
| | | | T = '1' is a cate- |
| | | | gory using the same |
| | | | protocol. The PETs |
| | | | and IXO devices are |
| | | | members of this |
| | | | category. |
| | | | T = '7,8,9' are re- |
| | | | served for wild card |
| | | | terminals or devices |
| | | | which may relate to |
| | | | a specific users' |
| | | | system. |
+---+----------------------+----------------------+----------------------+
| 6 | "PPPPPP<CR>" {3} | | This 6-character |
| | | | alphanumeric pass- |
| | GL-3000 will ignore | | word comes from |
| | password | | automatic terminals. |
| | | | (Password is optional|
| | Typical password for | | and is, in general, |
| | IXO is "000000" | | reserved for future |
| | | | services. Password |
| | | | may be interpreted |
| | | | as either a caller |
| | | | ID or a system entry |
| | | | key. Length of pass- |
| | | | word, when used, may |
| | | | be different in some |
| | | | systems.) |
| | | | |
| | | | When an incorrect |
| | | | logon sequence |
| | | | beginning with <ESC> |
| | | | is received, the |
| | | | paging central may |
| | | | respond with an ID= |
| | | | if it requires a |
| | | | retransmission. |
+---+----------------------+----------------------+----------------------+
| | | "Message sequence | Logon accepted |
| | | <CR><ACK><CR>" | |
| | | | |
| | | or | or |
| | | | |
| | | "Message sequence | Requested again |
| | | <CR><NAK><CR>" | |
| | | | |
| | | or | or |
| | | | |
| | | "Message sequence | Forced disconnect |
| | | <CR><ESC><EOT><CR>" | |
+---+----------------------+----------------------+----------------------+
* GL-3000 Typical Message Sequence: "Processing - Please Wait" or
"4 pages sent" or
"Bad Phone Line Call Again".
+----------------------+----------------------+----------------------+
| REMOTE ENTRY | PAGING CENTRAL DOES | COMMENTS |
+---+----------------------+----------------------+----------------------+
| | | | A message sequence |
| | | | is defined as a |
| | | | series of short |
| | | | messages separated |
| | | | by <CR>s. A <CR> |
| | | | always follows a |
| | | | message sequence. |
| | | | Message sequences |
| | | | are totally optional.|
+---+----------------------+----------------------+----------------------+
| 6a| | Optional message | Central may insert |
| | | sequence <CR> | short message |
| | | | sequence between |
| | | | steps 6 and 7. |
+---+----------------------+----------------------+----------------------+
| 7 | | "<ESC> [p <CR>" | Message go ahead is |
| | | | sent when paging |
| | | | central is ready for |
| | | | new information. |
| | | | The 'p' is in lower |
| | | | case. |
+---+----------------------+----------------------+----------------------+
| 8 | TRANSACTION #1 | | A block is up to 256 |
| | : "<STX> | | characters in length,|
| | : FIELD #1 <CR> | {4} | with up to 250 char- |
| | BLOCK: FIELD #2 <CR> | {5} | acters of info, plus |
| | #1 : | | 3 control characters |
| | : FIELD #N <CR> | | and a 3 character |
| | : <ETX> | | checksum. The block |
| | : <CHECKSUM> | | carries one trans- |
| | : <CR>" | | action (one set of |
| | | | fields 1 through N) |
| | | | or a portion of one |
| | | | transaction. A block |
| | | | may be less than 256 |
| | | | characters to |
| | | | accommodate short |
| | | | transactions. |
+---+----------------------+----------------------+----------------------+
| | | | A field may be any |
| | | | length and where |
| | | | necessary may be |
| | | | continued in |
| | | | following blocks. |
| | | | A field always ends |
| | | | with a <CR>. The |
| | | | <CR> field delimiter |
| | | | suggests <CR> may |
| | | | not be used within a |
| | | | field. |
| | | | |
| | | | A block always |
| | | | begins with an <STX> |
| | | | and ends with a |
| | | | checksum followed by |
| | | | a <CR>. The char- |
| | | | acters preceding the |
| | | | checksum depends on |
| | | | what, if anything, |
| | | | is continued beyond |
| | | | the block boundary. |
| | | | |
| | | | The <ETX> is used as |
| | | | a block termination |
| | | | indicator if a given |
| | | | transaction (fields |
| | | | 1 through N) ends |
| | | | within the block |
| | | | currently being |
| | | | transmitted. |
+---+----------------------+----------------------+----------------------+
| | TRANSACTION #2 {6} | | The <ETB> is used as |
| | : "<STX> | | a block terminator |
| | : FIELD #1 <CR> | | if the transaction |
| | BLOCK: | | is continued into |
| | #2 : FIELD #J <CR> | | the next block, but |
| | : <ETB> | | the last field in |
| | : <CHECKSUM> | | the current block is |
| | : <CR>" | | complete. |
| | | | |
| | : "<STX> | | If the last field |
| | : FIELD #J+1<CR>| | within the current |
| | BLOCK: | | block is to be |
| | #3 : FIELD #L <US> | | continued in the |
| | : <CHECKSUM> | | next block, no <CR> |
| | : <CR> | | is inserted at the |
| | | | end of the first |
| | : "<STX> | | portion of the field |
| | : FIELD #L | | and the <US> char- |
| | : (CONTINUED) | | acter is used as a |
| | : <CR> | | block termination |
| | BLOCK: | | character. The <CR> |
| | #4 : FIELD <CR> | | terminating the |
| | : <ETX> | | broken field is sent |
| | : <CHECKSUM> | | at the end of the |
| | : <CR> | | field in whatever |
| | | | block the field |
| | | | actually terminates. |
| | | | |
| | | | No limit is estab- |
| | | | lished within the |
| | | | protocol itself |
| | | | regarding the number |
| | | | of transactions, the |
| | | | number of fields or |
| | | | the number of blocks |
| | | | per field; however, |
| | | | a particular user |
| | | | system may have |
| | | | limits on any of |
| | | | these items. |
| | | | |
| | LAST TRANSACTION | | Some systems may be |
| | | | limited to one block |
| | | | per transaction and |
| | | | one transaction per |
| | | | telephone connection.|
| | | | |
| | | | Each checksum is |
| | | | computed by perfor- |
| | | | ming the simple |
| | | | arithmetic sum of |
| | | | the 7-bit values of |
| | | | all values of all |
| | | | characters preceding |
| | | | it in that block. |
| | | | (This means that the |
| | | | STX and ETB/ETX are |
| | | | included in the sum).|
| | | | The checksum is then |
| | | | the least signifi- |
| | | | cant 12 bits of this |
| | | | resulting sum. |
+---+----------------------+----------------------+----------------------+
| | | | The checksum is |
| | | | transmitted as three |
| | | | printable ASCII |
| | | | characters having |
| | | | values between HEX |
| | | | 30 and HEX 3F (the |
| | | | characters 012345678 |
| | | | 9:;<=>?). The most |
| | | | significant four |
| | | | bits of the sum are |
| | | | encoded as the 4 LSB |
| | | | of the third char- |
| | | | cter. See example. |
| | | | |
| | | | A normal paging sys- |
| | : "<STX> | | tem will have two |
| | : FIELD #1 <CR> | | fields only: |
| | LAST : | | |
| | BLOCK: FIELD #N <CR> | | Field 1 = Pager ID |
| | : <ETX> | | (normally up to |
| | : <CHECKSUM> | | eight digits. May |
| | : <CR>" | | include function and |
| | | | check digit). |
| | | | |
| | | | Field 2 = Message |
| | | | |
| | | | Field 1 or field 2 |
| | | | may be empty. For |
| | | | example, when a page |
| | | | is tone only, field |
| | | | 2 will be empty. |
| | | | Even when empty, a |
| | | | field is followed by |
| | | | a <CR>. Some systems |
| | | | will reject trans- |
| | | | actions which have |
| | | | an empty field 2 for |
| | | | a display page or |
| | | | transactions which |
| | | | have an empty field |
| | | | 1. Other systems are |
| | | | less restrictive. |
+---+----------------------+----------------------+----------------------+
| | | | The response to each |
| | | | block is one of four:|
| | | | |
| | | "Message sequence | <ACK><CR> = OK, send |
| | | <CR> <ACK> <CR>" | next block. |
| | | | |
| | | or | |
| | | | |
| | | "Message sequence | <NAK><CR> = checksum |
| | | <CR> <NAK> <CR>" | or transmission |
| | | | error, send last |
| | | | block again. |
| | | or | |
| | | "Message sequence | <RS><CR> = abandon |
| | | <CR> <RS> <CR>" | current transaction |
| | | | and go to next. <RS> |
| | | | may occur when the |
| | | | checksum is OK, but |
| | | | the current trans- |
| | | | action violates a |
| | | | system rule. At the |
| | | | option of the system,|
| | | | it may occur in |
| | | | other cases. |
| | | or | |
| | | | |
| | | "Message sequence | <ESC><EOT><CR> = |
| | | <CR> <ESC> <EOT> | begin disconnect. |
| | | <CR>" | |
| | | | Any of the responses |
| | | | may have an optional |
| | | | message sequence |
| | | | before them, |
| | | | although the system |
| | | | designer should |
| | | | understand the con- |
| | | | sequences to the |
| | | | user with all |
| | | | planned entry |
| | | | devices. |
+---+----------------------+----------------------+----------------------+
| | | | It is expected that |
| | | | many systems will |
| | | | save their message |
| | | | sequence responses |
| | | | until immediately |
| | | | before disconnect. |
| | | | For some entry |
| | | | devices, it may also |
| | | | be desirable that |
| | | | messages describing |
| | | | non-checksum errors |
| | | | associated with a |
| | | | particular trans- |
| | | | action in a PG |
| | | | service will begin |
| | | | with the letter ID |
| | | | followed by the |
| | | | contents of field 1 |
| | | | for that transaction.|
+---+----------------------+----------------------+----------------------+
| 9 | "<EOT> <CR>" | | After reception of |
| | | | an <ACK> or <RS> for |
| | | | the last transaction |
| | | | in a given service, |
| | | | the entry device |
| | | | sends <EOT> <CR> |
| | | | meaning there are no |
| | | | more transactions |
| | | | remaining in this |
| | | | service. |
+---+----------------------+----------------------+----------------------+
|10a| | "<Message sequence> | An optional message |
| | | <CR>" | may be sent at this |
| | | | point to indicate |
| | | | the degree of accep- |
| | | | tability of infor- |
| | | | mation in all trans- |
| | | | actions received |
| | | | during the current |
| | | | interchange. |
| | | | Although optional, |
| | | | this message is |
| | | | highly desirable. |
+---+----------------------+----------------------+----------------------+
|10b| | "<RS> <CR>" | An <RS> <CR> should |
| | | | be sent at this |
| | | | point if the paging |
| | | | central finds any |
| | | | data <ACK> in step 8 |
| | | | to be unacceptable |
| | | | because of content |
| | | | (e.g. an invalid |
| | | | pager number or a |
| | | | message field inap- |
| | | | propriate for the |
| | | | type of pages, etc.) |
| | | | [2] |
+---+----------------------+----------------------+----------------------+
|10c| | "<ESC> <EOT> <CR>" | <ESC> <EOT> = begin |
| | | | disconnect. |
| | | followed by dropping | |
| | | of carrier and | |
| | | hanging up. | |
+---+----------------------+----------------------+----------------------+
|11 | Drops carrier and | | |
| | hangs up. | | |
+---+----------------------+----------------------+----------------------+
[2] It is desirable to catch all types of errors in step 8, but practically, some systems will be too slow to catch content errors as they happen.
+----------------------+----------------------+----------------------+
| REM. ENTRY DEV. DOES | PAGING CENTRAL DOES | COMMENTS |
+---+----------------------+----------------------+----------------------+
| 5M| (For manual remote | | Lack of <ESC> at |
| | entry as opposed to | | at beginning of |
| | Automatic Entry | | response to ID= |
| | shown previously in | | signifies manual |
| | this table under 5A) | | operation where |
| | | | applicable. |
| | "M <CR>" | | |
+---+----------------------+----------------------+----------------------+
| | | "Enter pager ID(s): | Any manual operation |
| | | (Tone only or | is user defined |
| | | voice)" or | after logon. |
+---+----------------------+----------------------+----------------------+
| | e.g. | | Echo transmission is |
| | "1000 2000 1247 400 | | allowed after manual |
| | <CR>" | | conversation is |
+---+----------------------+----------------------+ established. M <CR> |
| | | "Enter Alphanumeric | can be replaced by |
| | | message (alpha):" or | any non-null |
| | | "Enter Numeric | sequence ending in |
| | | message (numeric):" | <CR> and not |
+---+----------------------+----------------------+ beginning with |
| | "Message <CR>" | | <ESC>. |
+---+----------------------+----------------------+ |
| | | "Can't Deliver Page | |
| | | ID xxxxxx" or | |
| | | "Too Slow - Good | |
| | | Bye" (40 second | |
| | | timeout)" or | |
| | | "Too Many Errors - | |
| | | Good Bye" (occurs if | |
| | | 3 or more errors) or | |
| | | "Page Blocked" | |
+---+----------------------+----------------------+----------------------+
For initial implementation of the protocol, it is recommended that Bell 103 compatible modems be used to receive at 300 baud. Additional speeds or modem types may be used if desired.
The standard practice will be ASCII with <XON>/<XOFF> either direction using a 10-bit code (1 start, 7 data, 1 parity, 1 stop) with even parity. {7}
In the case of delays, the paging central shall wait at least four seconds (eight seconds in steps 3 and 4) before disconnecting the remote entry device; the remote entry device shall wait at least ten seconds for a character from the central before hanging up.
The paging central may, at its option, send <CR><LF> in place of <CR> at the end of any sequence.
For initial use of the protocol, the paging central shall be equipped to receive full duplex using a Bell 103 compatible modem at 300 baud. Optionally, certain inputs may be capable of receiving 110 baud Bell 103 full duplex, 300/1200 baud Bell 212 full duplex. No echo shall be employed in full duplex mode. Any attempts at automatic baud rate determination shall be within the restraints of the specified protocol.
Leaving a message TEST for customer #1 Data: 7 Bits/1 Stop Bit/No Even Parity {8}
USER GL-3000
<CR> every 1 second unit ...
ID=
<ESC>PG1<CR>
<ESC>[p<CR>
<STX>1<CR>TEST<CR><ETX>190<CR>
("TEST" is the message) Processing - Please Wait<CR><ACK><CR>
("190" is the Checksum)
+++,,,,,,,,,,ATH0<CR>
Carrier Drop
The following table shows an example of a complete block containing a correct checksum which is: <STX>123<CR>ABC<CR><ETX>17;<CR>
+---------+---------+---------+
| STX *| 000 *| 0010 *|
| 1 | 011 *| 0001 |
| 2 | 011 *| 0010 *|
| 3 *| 011 | 0011 *|
| CR *| 000 *| 1101 *|
| A *| 100 | 0001 *|
| B *| 100 *| 0010 *|
| C *| 100 *| 0011 *|
| CR | 000 *| 1101 *|
| ETX *| 000 *| 0011 *|
| *+---------+---------+
| *| 1 0111 | 1011 |
| *| 1 7 | ; *|
+---------+---------+---------+
Checksum = 17;
Every packet starts with <STX> and ends with a three-byte checksum and <CR>.
The last character before the checksum is:
IF this the last packet in the transaction THEN it's <ETX> ELSE IF the packet ends on a boundary between fields, that is to say, with a <CR>, THEN it's <US> ELSE it's <ETB> END IFHow do you know whether or not to break a field across more than one packet? The easy way is to build the whole transaction, break it into 250 byte chunks, look at the end of each chunk for a <CR>. If you find the <CR>, send <ETB>, else <US>. After the last packet, send <ETX> instead.
repeat with i = 1 to the length of TempPacket add charToNum(char i of TempPacket) to checkSum end repeat put numToChar((checkSum div 256) mod 16 + 48) into checkSumString put numToChar((checkSum div 16) mod 16 + 48) after checkSumString put numToChar(checkSum mod 16 + 48) after checkSumString put checkSumString & <CR> after TempPacket
+-----------------------+-----------------------+ | 00 00 <NUL> | 16 10 <DLE> | | 01 01 <SOH> | 17 11 <XON> | | 02 02 <STX> | 18 12 <DC2> | | 03 03 <ETX> | 19 13 <XOFF>| | 04 04 <EOT> | 20 14 <DC4> | | 05 05 <ENQ> | 21 15 <NAK> | | 06 06 <ACK> | 22 16 <SYN> | | 07 07 <BEL> | 23 17 <ETB> | | 08 08 <BS> | 24 18 <CAN> | | 09 09 <HT> | 25 19 <EM> | | 10 0A <LF> | 26 1A <SUB> | | 11 0B <VT> | 27 1B <ESC> | | 12 0C <FF> | 28 1C <FS> | | 13 0D <CR> | 29 1D <GS> | | 14 0E <SO> | 30 1E <RS> | | 15 0F <SI> | 31 1F <US> | +-----------------------+-----------------------+