home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Telecom
/
1996-04-telecom-walnutcreek.iso
/
technical
/
ixo.program.scripts
/
ixo.doc
< prev
next >
Wrap
Text File
|
1993-02-14
|
9KB
|
219 lines
Here is a summary of the IXO protocol. All typos and
misinterpretations are mine. This is based on reading the Glenayre
Electronics book. I have not yet implemented the automatic protocol,
but I have implemented the manual one.
You are "remote entry device" and the system that you dial into is
"paging central".
(1) Remote sends CR at two second intervals until paging central
responds with ID= at correct baud rate or until three transmissions
have been completed. (This step exists to allow for possible future
baud rate recognition).
Some systems have chosen to send ID= from the central if they do not
receive CR in about two seconds. This variation appears to be
acceptable as the central continues to respond to CR's with ID='s.
(2) Central sends ID=. Request for ID returned 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 appropriate waiting time.
FOR AUTOMATIC REMOTE ENTRY:
At this point you can start following 2A or 2M depending on which
sub-protocol you want to use.
(2A) Remote sends ESC SST (typically ESC PG1)
ESC signifies entry device intends to talk in automatic dump mode.
SS is a set of two alphanumeric charactoers signifying a type of
service to be accessed:
For a paging service where:
Field 1 = Pager ID
Field 2 = Message
SS will be sent at "PG".
Where T is a single alphanumeric character relating to the type of
terminal or device attempting to send the message. T = "1" is a
category of entry devices using the same protocol. The PETs and IXO
devices are members of this category. T = "7" or "8" or "9" are
reserved for wild card terminals or devices which may relate to a
specific users' system.
(3A) Remote sends 6-char alphanumeric password then CR. (Password is
optional and is, in general, reserved for future services. Password
may be interpreted as either a caller ID or a system entry key.
Length of password, 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.
(4A) Central responds with a message sequence (lines of text, each one
followed by a CR). (Typical messages are "Processing - Please Wait",
"4 pages sent" or "Bad Phone Line Call Again".
(5A) Central then sends one of three sequences:
CR ACK CR This means "logon accepted"
CR NAK CR This means "requested again"
CR ESC EOT CR This means "Forced disconnect"
(6A) Central may then send another message sequence (optional).
(7A) Central sends ESC [p CR
Message go ahead is sent when paging central is ready for new
information. The "p" is lowercase.
(8A) Remote sends STX field1 CR field2 CR field3 CR ... fieldn CR
EEE <CHECKSUM> CR
You can send as many fields as you wish. PG terminals send the
pager-id in field1 and the message in field2. (no other fields are
defined). This entire message can be a max of 250 bytes. 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 a STX and ends with a checksum followed by a CR. The characters
preceding the checksum depends on what, if anything, is continued
beyond the block boundary.
EEE can be an ETX, ETB, or RS.
The ETX is used as a block termination indicator if a given
transaction (fields 1 through N) ends within the block being
transmitted.
The ETB is used as a block terminator if the transaction is continued
into the next block, but the last field in the current block is
complete.
If the last field within the current block is to be continued in the
next block, no CR is inserted at the end of the first portion of the
field and the US character is used as a block termination character.
The CR terminating the broken field is sent at the end of the field in
whatever block the field actually terminates.
No limit is established 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.
Some systems may be limited to one block per transaction and one
transaction per telephone connection.
Each checksum is computed by performing the simple arithmetic sum of
7-bit 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 significant 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 0123456789:;<=>?).
The most significant four bits of the sum are encoded as the 4 LSB of
the third chacter. See example.
A normal paging system will have two fields only:
Field 1 = Pager ID
(normally up to eight digits. May 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 transactions which have an empty field 2 for
a display page or transactions which have an empty field 1. Other
systems are less restrictive.
(9A) The response to each block is one of four:
Message sequence CR ACK CR = OK, send next block.
Message sequence CR NAK CR = Checksum or transmission error, send last
block again.
Message sequence CR RS CR = Abandon current transaction and go to next.
RS may occur when the checksum is OK,
but the current transaction violates a
system rule. At the option of the
system, it may occure in other cases.
Message sequence CR ESC EOT CR = Begin disconnect.
Any of the responses may have an optional message sequence before
them, although the system designer should understand the consequences
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 message describing non-checksum
error assocaiated with a particular transaction in a PG service will
begin with the letter ID followed by the contents of field 1 for that
transaction.
(10A) Remote sends 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.
(11A) Optional: Central sends a message sequence CR.
Although optional, it is highly desirable.
(12A) Central sends RS CR
An RS CR should be sent at this point if the paging central finds any
data ACK in previous steps by the system to be unacceptable because of
content (e.g. invalid pager number or a message field inappropriate
for the type of pages, etc.)
(13A) Central sends ESC EOT CR
then hangs up.
(14A) stop.
(2M) Remote sends M CR (capitol M then CR)
Lack of ESC at beginning of response to ID signifies manual operation
where applicable. From here on it's undefined, but most systems ask
(in English) for the info they need and then return you to step (1).
NOTES:
Bell 103 300bps modem is standard, others may be used. Protocol is
ASCII with XON, XOFF either direction using 10-bit code (1 start, 7
data, 1 parity, 1 stop) with even parity.
In the case of delays, the paging central shall wait at least four
seconds (eight seconds for (1) (2) (2A)) before disconnecting the
remote entry device. The remote entry device shall wait at least 10
seconds for a character from the central before hanging up.
Paging central may, at its option, send CR LF in place of CR at the
end of any sequence.
For inital use of 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.
SAMPLE Checksum Example:
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
10111 1011
1 7 ;
So, the checksum is "17;"
There is also a really nice flowchart, which I can't reproduce here
without much too much trouble. ...and you wouldn't have known it
existed if I hadn't told you. :-)