Communication Specification (i-Telex)

Aus wiki.telexforum.de
Zur Navigation springen Zur Suche springen

i-Telex

Communication Specification

Content

This document describes the communication used at the IP port of the i-Telex system. There are basically two channels:

  1. The communication between two i-telex users (stations).
  2. The communication between the calling i-telex user (stations) and the i-telex subscriber server, which is performed to get the IP address of the called station.

Communication Between i-Telex Stations

i-Telex stations try to enable stations to simply interconnect two telexes through the Internet. The Protocol is TCP-based and follows the same rules as the normal telex does.

It may be reflected by a state machine with the states “disconnected”, “connected unknown”, “connected proposed”, “connected”, “texting ASCII”, “texting baudot” and “disconnected baudot”.

State Diagram of an i-Telex Host

In the state Disconnected the i-Telex service waits for incoming connections on the designated TCP port.

As soon as there is an incoming TCP connection, the state changes to Connected. In the Connected phase the following packets are allowed: “Version”, “Direct Dial”, “Remote Config”, “Self-test”, “Reject”, “End” and plain ASCII characters.

When in Connected state, the first packet starting with a character in the range 0x20 to 0x7E or 0xA0 to 0xFF or 0x0D or 0x0A triggers the Texting ASCII state. In this state all characters sent will be interpreted as pure ASCII transmission to be sent to the teleprinter.

A change from Texting ASCII mode to Texting Baudot or vice versa is not recommended, although current i-Telex implementations allow this change.

In Texting Baudot mode either a “Baudot Data”, “Acknowledge” or “Heartbeat” packet must be sent at least every 15 s. If no packet is received for more than 30 s, the TCP connection should be dropped and the state switched to Disconnected Baudot.

When in a Texting Baudot state, the reception of a “reject” or “end” end package returns the i-Telex service to the Disconnected state and terminates the TCP session.

In the state Disconnected Baudot the station waits for a connect from the very same IP address as before. All other connection attempts will be rejected. If a connection from the same IP address arises, the previous state is restored. If there is no subsequent connection within 30 s, the state changes to Disconnected.

When in Texting ASCII state a termination of the TCP session changes the state to Disconnected.

Basic Characteristics

The communication is based on the TCP protocol. The port can be chosen individually; the existing systems use port 134.

The transmitted data are symmetric, i.e. the caller and the called stations use one and the same protocol.

The transmitted data are organized in packets. Each packet is structured as follows:

i-Telex Packet Structure
Length / bytes Content
1 Command
1 data length / bytes
n data

Exception: In texting ASCII state, the byte codes 0A, 0D, 20-7E and A0 to FF (hex) are treated as plain ASCII resp. ISO 8859-1 codes if they are not part of the data block as specified above.

Please note that according the TCP specification all received data shall be treated as a stream. So a data block received from the TCP stack may contain an incomplete i-Telex packet. So, the TCP data input should be buffered and treated at first as byte stream.

The calling station always initiates the data transfer, so the calling station always sends the first data. The called station is ‘silent’ up to the first reception. The called station determines the protocol type according the first received data: If the first byte is a 0A, 0D or in range of 20-7E or A0 to FF (hex), it’s ASCII mode, if not it’s Baudot mode.

The following control codes are defined:

Code (hex) Function
0A Line Feed
0D Carriage return
05 Who are you (triggers the answerback mechanism)
07 Bell
0E Letters shift
0F Figures shift
10 third level (national characters) shift

Because the protocol is designed to allow also “maintenance communication” using the same port, the called station shall start the connected printer not before receiving an appropriate data packet (see below).

If a station receives a packet with unknown command code, the packet should be discarded. The length byte determines where the next packet starts.

If the data length of a received i-telex-packet is higher than expected (i.e. the “direct dial” packet was received with two bytes of data), the extra data must be discarded.

In Texting Baudot state at least every 14 s a packet should be sent (either a “Baudot Data”, “Heartbeat” or an “Acknowledge”, see below).

In Texting Baudot mode, any station may close the existing TCP connection, then the calling station should try to reconnect within 30 seconds without any influence to the communication handshake. This feature allows seamless reconnection in case of an unintended cut-off.

Except certain packets (mentioned then) there is no defined order or handshake procedure. So both stations may send any packet at any time, and should accept any packet at any time but should not rely on the order of packets as presented in the examples.

General Information About Remote Server

Generally, each i-Telex client should have a dedicated public IP V4 address. Due to limtations this is not always possible. Those i-Telex clients without public IP V4 address are called “limited clients” subsequently.

For limited i-Telex clients the “remote server” (sometimes also called “Centralex”) was invented. The limited client holds a point-to-point connection to this remote server, the remote server opens a server TCP port designated for this limited client and acts as the “call destination” for other i-Telex clients. As soon as the remote server encounters an incoming connection, it will signal this event to the limted client. See here for a complete example.

The connection from the limited i-Telex client to the remote server uses port 49491 at the server side.

Limited i-Telex clients must have a directory entry of type “DynIP” (see type code 5 at chapter Peer reply).

Packet Types

Overview

Command (hex) Use Version Data Standard data length (decimal)
00 Heartbeat X, R None 0
01 Direct dial 1, 2 Local number 1
02 Baudot data 1, 2 Baudot codes 1 to 50
03 End X
R
None (normal i-Telex connection)
Cause of closure (remote server stand-by connection)
0
0 to 20
04 Reject X, R Cause of rejection 0 to 20
05 (reserved)
06 Acknowledge 1, 2 Number of received and processed baudot codes or ascii characters 1
07 Version X Version number 1 to 20 / 1 to 6 (see Version Packet)
08 Self test 1 random payload 2 to 254
09 Remote config 1 PIN + sub command + config data 3 to 254
0A (reserved)
0B Ascii data 2 ASCII codes 1 to 50
0C-10 (reserved)
1E (reserved)
81 Connect remote R Own Number + PIN 6
82 Remote confirm R None 0
83 Remote call R None 0
84 Accept remote call R None 0

Remarks:

  • Version "X" means any version, even future definitions.
  • Version "R" means to be used during “standby phase” of remote server connection

Heartbeat Packet

This packet type is used for periodic transmission if nothing else is to transmit. The receiver awaits periodic data to check if the connection is stable or not. Instead of this packet also the acknowledge packet is preferred (if applicable). There is no reponse packet to be sent for a heartbeat packet. The heartbeat packet may be used while in “connected” or in “texting baudot” state.

  • Example: 00 00
  • Meaning: nothing to do

This packet is also used for the remote server connection of limited clients in both directions.

Direct Dial Packet

This packet is used to address a specific teleprinter, if the called station has more than one connected printer. The (one and only) data byte is the internal dial number of the “extension”. If a non-existing extension number is transmitted, the called station SHOULD use the main machine. Another option in case of an invalid extension is to send a “reject packet” and subsequently drop the TCP connection. This packet shall be sent before the first “baudot data packet” or “acknowledge packet”.

  • Example: 01 01 22 (hex)
  • Meaning: try to connect the local printer with extension number 34 (decimal).

Because the i-Telex-System supports single digit extension numbers as well as double digit extension numbers the following coding rules apply:

Extension number in i-Telex-System Code value (decimal) Code value (hex)
00 100 64
01 1 01
02 2 02
99 99 63
0 110 6E
1 101 65
2 102 66
... ... ...
9 109 6D
none 0 00
invalid > 110 > 6E

The called station shall start the addressed printer after reception of this packet. The called station shall send either an baudot data packet or an acknowledge packet when (and not before) the printer is successfully started.

If there is any failure, the called station shall respond with a reject packet.

The calling station shall send the direct dial packet before the first baudot data packet and before the first acknowledge packet.

Note: the standard i-Telex sends this direct dial packet together with the version packet, because the direct dial packet is expected to be 'understood' in any version.

Baudot Data Packet

With a “baudot data” packet the “real” data is transferred. The baudot data (5 data bits; LSB is the last bit transmitted; MSB is the first transmitted bit on the telex line) are padded with zero bits to 8 bits. The length must not be more than 50 bytes.

  • Example: 02 07 1F 01 10 14 01 02 08 (hex)
  • Meaning: print <Ltrs> T E S T <CR> <LF>

Regarding the interpretation of the serial data it is important to know, that the first data bit sent by the teleprinter is interpreted as the most significant bit (bit 4) and the last bit send as last significant bit (bit 0). See the letter “T” sent as code 01.

The data is buffered at the receiving i-telex station. To prevent a buffer overflow, the sender should not cause a condition in which there are more than 254 bytes unacknowledged (See the chapter acknowledge packet).

If the called station didn't receive a direct dial packet before the first baudot data packet it shall activate the default printer device.

ASCII Data Packet

With a “ASCII data” packet the “real” data is transferred. The ASCII data is transmitted in its natural representation. All codes 0x00 to 0xff are allowed. The character encoding for codes with the 8th bit set is undefined. The length must not be more than 50 bytes.

  • Example: 0B 07 48 65 6C 6C 70 20 21 (hex)
  • Meaning: print H e l l o <SP> !

The data is buffered at the receiving i-telex station. To prevent a buffer overflow, the sender should not cause a condition in which there are more than 254 bytes unacknowledged (See the chapter acknowledge packet). It is NOT recommended that both Baudot and ASCII packets are used in one connection.

If the called station didn't receive a direct dial packet before the first ASCII packet it shall activate the default printer device.

Communication End Packet

This packet indicates a normal termination of a connection (“hang-up”). The receiving station should switch off the printer and should close of the TCP connection. This packet can be sent by both stations (caller or called), whichever station wants to terminate the connection at first.

  • Example: 03 00 (hex)
  • Meaning: connection will be closed

The sending station shall wait for the opposite station to close the TCP connection. The station which receives this packet may immediately close the TCP connection.

This packet is also used for the remote server connection of limited clients. With this packet the client indicates, that the client doesn’t need the standby-connection anymore, for example to establish an outgoing connection. In this case the payload of this packet shall contain the reason of disconnection as ASCII letters, e. g. “occ” because of own activity or “abs” when intentionally switched off.

Communication Reject Packet

This packet indicated an abnormal termination, for example a busy sign or an error message. The receiving station should close the connection. The data within this packet consists of ascii codes.

  • Example: 04 03 6F 63 63 (hex)
  • Meaning: the called station is momentary in use.

The following reject codes are defined, but other codes may be used.

Code (ASCII) Code (hex) Meaning
occ 6F 63 63 Occupied by another call
abs 61 62 73 i-telex station temporarily disabled
na 6E 61 Not allowed (called extension is not allowed for external connections)
nc 6E 63 Not connected (called extension is temporarily switched off)
der 64 65 72 Derailed (the i-telex station works not properly)

It’s not necessary to answer the communication reject packet, the station which receives this packet may immediately close the TCP connection.

This packet is also used by the remote server in case the “login” data given in the Connect Remote Packet is not valid. In this case the payload is generally empty (telegram content 04 00).

And (also for remote server application) the limited i-Telex client may send this packet to reject an incoming call indicated by the Remote Call Packet, in this case the payload shall be filled according the table above.

Acknowledge Packet

Using this packet, the station indicates the number of baudot or ASCII characters (as received by the baudot data packet or by the ASCII data packet or by “plain” ascii characters) which were printed since establishing the connection. Printed means that any characters or codes buffered in any way shouldn't be included in the counting value. On the other hand not only printable codes are counted, but every 5-bit-codegroup, including shift codes.

This packet has the purpose that a (sending) station may determine if all sended data was already processed by the receiving station or (if not) how many characters are currently buffered at the receiving station. So, this data packet allows to optimize the sending speed according to the printing speed of the opposite station.

The counting of characters resp. codes is independent of the communication direction, so both directions shall use own counters.

  • Example: 06 01 51 (hex)
  • Meaning: currently 81 (decimal) baudot or ASCII codes have been processed by the printer since establishing the connection.

If the number of processed codes exceeds 255, the counting starts at 0 again.

It is allowed to send an acknowledge packet with the same value of the data byte if the receiving buffer of that station is empty.

It is not necessary to transmit an acknowledge packet for each processed byte. It is recommended to send the acknowledge packet as soon the receive buffer runs empty.

This acknowledge packet shall not be send in case the local printer device is not running. Especially the called station shall not send any acknowledge packet before reception of a direct dial packet or baudot data packet.

On the other hand, the called station must send an acknowledge packet after starting the printer device in case the called station does not send any baudot data after startup.

As an example, the standard i-Telex station processes this telegram in the following way:

  • For the sending direction, the i-Telex at first buffers all typed characters in a buffer. The count of buffered codes is N_buffer.
  • The time since the last typed character is measured (T_typingpause)
  • The i-Telex counts the transmitted baudot codes (N_trans).
  • The value of the (last) acknowledge packet received from the opposite station is stored locally (N_ack).

The baudot or ASCII data packet will be sent, if:

  • (N_buffer > 0) and (T_typingpause >= 1 second)
  • OR (N_buffer > 0) and (N_ack == N_trans)
  • OR (N_buffer >= 16)

Note: Nomally the called i-Telex station prints out the current date and time after starting the local printer. To indicate that there is some data to print the first acknowledge data packet sent by the called station doesn't start with data byte of 0. But as soon as this locally generated text is completely printed the called station sends the acknowledge data packet with value 0 (so 06 01 00).

If the calling station started to transmitting data before the locally generated text was printed, the acknowledge packet with data byte 0 may be omitted.

To be presice, the i-Telex considers a character or code as printed, when the start-bit is beeing sent to the printer device.

Version Packet

Using this packet, the connected stations can handle out which version of the i-telex protocol is supported. Currently, there are versions 1 and 2 defined, but in future there may be enhanced versions. Version 1 indicates the use of 5-bit-codes while version 2 is used for 8-bit codes.

If a station receives a version packet with a version number it can handle, the station must “answer” with a version packet including the same version number as received (unless the station already has sent t version packet with that version ID). If the station does not support that version, it must respond with a version packet including a version number it supports or send a reject packet. Caution: It may occur that this “proposal” is again denied by the “original” station and another (“lower”) version will be handled out.

The version number is the first byte in the data block. The data block may contain further information, but this info is currently not relevant regarding the protocol. It may be used in future to signal available minor protocol extensions.

  • Example: 07 05 01 35 32 34 00 (hex)
  • Meaning: protocol version 1, additional info “524” (ascii code).
  • Example: 07 06 02 55 54 4F 38 00 (hex)
  • Meaning: protocol version 2, additional info “UTF8” (ascii code).

The version packet should be sent before any other packet. Only packet types defined for version 1 are allowed without preceding version handshake.

The length (2nd byte) value of this packet may be from 1 to 20 (total length 3 to 22 bytes), although it's recommended to use only values between 1 and 6, due to a bug in some i-Telex's ethernet board firmware versions (865 to 877).

Self-Test Packet

This packet is used like a “ping” signal to determine if the connection to the world wide web is working, especially regarding the port-forwarding for “incoming calls”.

  • Example: 08 02 45 6B (hex)
  • Meaning: ping signal with random number 6B45 (hex).

Note: The self test is performed by sending this data packet to itself (to the own station, so to check if a known public IP address is still routed to the i-telex-station performing this test). So, if any implementation has no need to perform the check, there is no need to implement the functionality for sending or receiving the self test package.

Remote Configuration Packet

This packet is only used for i-telex internal functions. It can be discarded. But this is the reason behind the rule not to start the printer device before reception of direct dial packet oder baudot data packet.

Connect Remote Packet

This packet is sent by the “limited i-Telex client” (see here) to perform a “login” at the remote server.

  • Example: 81 06 4D 97 53 00 21 B4
  • Meaning: Client with number 5478221 and PIN 46113 wants to establish a “stand-by connection” to the remote server.

The remote server will use the transferred login information to check the validity of the client at one of the subscriber servers. The remote server will select an own free port and will send an Client update packet to the subscriber server. In case of a positive answer, it will confirm this to the client by the Remote confirm packet. In case of authentification failure the remote server will send a reject packet.

If (unlikely) the authentification procedure exceeds 20 seconds, the remote server shall send heartbeat packets inbetween, also the i-Telex client.

Remote Confirm Packet

This packet is sent by the remote server once in case of successful login.

  • Example: 82 00

Remote Call Packet

This packet is sent by the remote server when it encounters an incoming TCP connection at that port the server has assigned to the client. The remote server generally won't evaluate the content of the incoming data but store it and forward it directly to the limited client as soon he has confirmed the connection with the Accept remote call packet

  • Example: 83 00

Accept Remote Call Packet

This packet is send by the limited i-Telex client to the remote server after reception of the “Remote call packet” (see above) in the (default) case if the client accepts this call. When the remote server receives this “accept” packet, it will transparently forwards any TCP packet of the incoming call to the i-Telex client and vice versa.

  • Example: 84 00

The i-Telex client may also rejects the incoming connection by sending a reject packet.

Examples

The following example shows the data exchange in a standard connection. A is the calling station; B is the called station.

A --> B (hex) B --> A (hex) Meaning
07 05 03 38 37 35 00 A calls B with protocol version 3 (and some additional data)
07 01 02 B replys that this station only supports protocol version 2 or lower.
07 01 01 A replys that it wants to use the basic protocol (e. g. if it supports only versions 3 and 1)
07 01 01 B confirms the use of protocol version 1
01 01 22 A selects the printer device extension number 34 (decimal) at the “B” side.
06 01 00 B confirms the successful start of the local printer device

Alternativly a baudot data packet with “greetings” may be sent

02 07 1F 01 10 14 01 02 08 06 01 00 A itself starts the local printer device

A sends text “test” with <CR> and <LF> to B and also states that no baudot data was received yet

06 01 02 B states that the local printer is running but only two characters had been printed yet.
06 01 00 A sends acknowledge of zero processed codes (and maybe waits for B to process the data)
06 01 07 B states that 7 codes were processed.
00 00 Alternative for sending “acknowledge” is “heartbeat”.
02 02 02 08 B sends itself <CR> <LF>.
06 01 02 A states that <CR> <LF> were sent to the printer.
06 01 07 B repeats “7 codes processed”
06 01 02 obviously at the moment nobody wants to send anything
03 00 B announces the close of the connection
(close) A closes the TCP connection and stops the local printer device

After the announcement of a connection close the opposite station may disconnect the TCP connection immediately.

The following example is simplified for a connection, where only the sender transmits data to be printed.

A --> B (hex) B --> A (hex) Meaning
07 01 01 A calls B with protocol version 1
07 01 01 B confirms the use of protocol version 1
02 07 1F 01 10 14 01 02 08 A sends text “test” with CR and LF to B
B shall start the local default printer device
06 01 02 B states that the local printer is running but only two characters had been printed yet.
00 00 A sends “heartbeat” (should occur each 4 seconds or alternatively as a reply to each packet received from B
06 01 07 B states that 7 codes were processed.
00 00 A sends “heartbeat”
06 01 07 B repeats “7 codes processed”
03 00 A announces the close of the connection
(close) B stops the local printer device and closes the TCP connection.

The following example explains the “remote server” connection for limited clients. The limited client using this remote server is “Client A”, the calling client is “Client B”.

Client A ->
Remote Server (hex)
Remote Server
-> Client A (hex)
Meaning
81 06 4D 97 53 00 21 B4 Limited i-Telex client with number 5478221 and PIN 46113 wants to establish a link
Remote server contacts the subscriber server to check the validity of the client number and assigns a port with a new port number for this client. The subscriber server entry will be updated with the ip address of the remote server and the newly assigned port number.
82 00 Remote server confirms the positive “login” to the client. This shall occur at least 30 seconds after “login”, the client will disconnect after 35 seconds
00 00 Heartbeat (expected at least every 30 seconds)
00 00 Heartbeat (expected at least every 30 seconds)
00 00 Heartbeat (expected at least every 30 seconds)
Client B has established a connection to the remote server.
83 00 Server indicates Client A an incoming call
84 00 Client A accepts the call
07 01 01 Server sends data received from Client B literally.

(See previous example with swapped roles)

07 01 01 ...see previous example
02 07 1F 01 10 14 01 02 08 ...see previous example
...see previous example
03 00 Client B sended “communication end packet”, server forwards this packet
(close) Client A closes connection
Server will also close TCP connection to Client B
(5 seconds pause)
81 06 4D 97 53 00 21 B4 Client A reconnects to server as shown at the start of this table.
82 00 Remote server checked the “login” successfully and opened a port for incoming calls assigned to the client.
00 00 Heartbeat (expected at least every 30 seconds)
00 00 Heartbeat (expected at least every 30 seconds)
03 03 6F 63 63 Client A wants to disconnect from the remote server (e.g. to make an outgoing call).
(close) Server stores the “occ” and will send this code to any calling client.
(Client A acts independent from the remote server)
81 06 4D 97 53 00 21 B4 …and reconnects as shown at the start of this table.
82 00 Remote server checked the “login” successfully and opened a port for incoming calls assigned to the client.
Example for invalid login:
81 06 4D 97 53 00 21 B4 Client with number 5478221 and PIN 46113 wants to establish a link
04 00 Remote server checked the “login” and refuses the connection attempt.

Reference i-Telex System

As a reference the following table lists the reactions for received telegrams resp. the conditions for sending telegrams.

Telegram
(hex)
Reaction on receipt Conditions for transmission
00
Heartbeat
Restart 30 seconds timeout counter, this is done on any received telegram No transmission of any telegram for 15 seconds
01
Direct dial
Start the selected teleprinter, discard telegram if already started. When opening TCP socket “client side” immediately after version packet
02
Baudot data
Push baudot data to printer send queue.
Count received symbols in “N_Received”
When (buffered) data is ready for sending AND...
  • typing pause of more then 1 second is detected OR
  • the number of acknowledged symbols (“N_ack”) is equal to the number of already sent symbols OR
  • the number of buffered symbols exceeds 16
03
End
Stop the activated printer and close TCP socket When local printer is switched off.
04
Reject
Printout reject code / information on local printer, stop printer and close socket. When own station is busy or (directly) dialled printer is busy or disturbed or not allowed for direct call.
06
Acknowledge
Store the acknowledged number of printed symbols in “N_ack” When local printer is running:
  • every 3,5 seconds OR
  • last received and buffered symbol has been sent to printer.
07
Version
Store version ID locally and check it.
If same ID as already transmitted, save version ID as “agreed”.
If not, send own version telegram (see right).
  • If station is TCP “client” side (caller), send highest supported version ID immediately after opening TCP socket.
  • When version packet received:
    • If unsupported version ID telegram was received, send next lower possible version ID.
    • Else if no version ID was transmitted yet (station is TCP “server” side) or own last sent ID was higher than received one: send same ID as received and store this version ID as “agreed”.
08
Self test
Check reveived payload against sended data. Peridically (e.g. each 200 seconds) opens TCP socket to own public IP address and send random data.
09
Remote config
Check content and change settings if necessary. i-Telex never sends this.
0B
Ascii data
Ignore data. i-Telex never sends this.
81
Connect remote
Undefined Immediately after opening socket to “remote server”.
82
Remote confirm
Handle remote server connection as “active”. i-Telex never sends this.
83
Remote call
Check if coming connection is allowed (i. e. own station is not busy) and handle existing socket to remote server like “incoming call”. i-Telex never sends this.
84
Accept remote call
Undefined Immediately after successful reception of “Remote call” (else send “reject” packet).

Communication Between i-Telex Station and Subscriber Server

This chapter describes the necessary data exchange between the i-telex stations and the i-telex “nameserver”. The communication is based on the TCP protocol. The port which is used is 11811. Examplex are given with hex values.

Basic Characteristics

Every Packet has the same outline:

  • Packet type (1 byte)
  • Length (1 byte)
  • Data (length bytes)
  • Multiple byte integer values are sent with the least significant byte first (little endian).
  • Strings are terminated by a NUL character (C style)

Exception: To provide a simple way for third-party systems the query of a peer is also supported in ASCII-Format. See Peer query in ASCII format.

Packet Types

Overview

Command Use Version Data Allowed data length (decimal)
0x01 Client_update 1 <Call-number 4b> <PIN 2b> <Port 2b> 8
0x02 Address_confirm 1 <IPAdr 4b> 4
0x03 Peer_query 1 <Call-number 4b> <Version 1b> 5
0x04 Peer_not_found 1 - no data - 0
0x05 Peer_reply_v1 1 <Call-number 4b> <Name 40b> <Flags 2b> <Type 1b> <Addr 40b> <IPAdr 4b> <Port 2b> <Extension 1b> <DynPin 2b> <Date 4b> 100
0x06 Sync_FullQuery 1 <Version 1b> <ServerPIN 4b> 5
0x07 Sync_Login 1 <Version 1b> <ServerPIN 4b> 5
0x08 Acknowledge 1 - no data - 0
0x09 End_of_List 1 - no data - 0
0x0a Peer_search 1 <Version 1b> <Search pattern 40b> 41
0xFF Error All <Diagnostic message> <NUL 1b> 1 to 100

4b means 4 bytes.

Integer values are coded with the least significant byte at first position ("little endian")

Client_update

This packed is used by a client to (if necessary) update the own IP address stored at the subscriber list. (a very simplified version of a “Dynamic DNS Server”). The data is structured as following:

  • 1 byte Packet type: 01
  • 1 byte length: 08
  • 4 byte call-number: The own number of the client as a 32 bit integer value
  • 2 byte PIN number: A number chosen by the user to authentificate
  • 2 byte port number: The port number opened for incoming calls (usually 134).
  • Example: 01 08 16 AA 34 00 34 12 86 00 (hex)
  • Meaning: update the (dynamic) IP for the peer with number 3451414 with authentification PIN 4660 and port 134.

Address_confirm

This packet is sent by the server as a reply to a Client_update packet. The data is structured as following:

  • 1 byte Packet type: 02
  • 1 byte length: 04
  • 4 byte IP address: The IP address of the sender of packet “Client_update” which is stored in the subscriber list.
  • Example: 02 04 xx xx xx xx (hex) TODO
  • Meaning: The sender has IP address xx xx.

Peer_query

This packet is sent by the client to query a subscriber server for contact details of a subscriber number. The data is structured as following:

  • 1 byte Packet type: 03
  • 1 byte length: 05
  • 4 byte call-number: The (unique) number of the peer as a 32 bit integer value
  • 1 byte version number: The highest version ID supported by the client. But currently the server supports only version 1.
  • Example: 03 05 16 AA 34 00 01 (hex)
  • Meaning: get the details of the peer with the number 3451414 with reply format version 1.

When sending this packet to a subscriber server the subscriber server replys either with a peer_not_found or a peer_reply_v1.

Note: Older clients do not provide the 1 byte version number. In this case version 1 is valid and the length byte is 04.

Peer_not_found

This packet is a possible reply to peer_query or peer_search packtes. It is sent if the requested peer cannot be found or the result set of a peer search is empty.

  • 1 byte Packet type: 04
  • 1 byte length: 0
  • Example: 04 00 (hex)
  • Meaning: unable to find requested peers

Peer_reply_v1

This packet is the standard reply to a peer_query or peer_search packet, if the version number is 1 or the server does not support higher versions. The data is structured as following:

  • 1 byte Packet type: 05
  • 1 byte length: 64 (hex)
  • 4 byte call-number: The (unique) number of the peer as a 32 bit integer value
  • 40 byte name: The “long” identification of the peer (as shown in the subscriber list), coded in ASCII resp. ISO 8859-1.
  • 2 byte flags: Special “attributes” of the peer, encoded as a bit-masks in a 16 bit integer value:
    • Bit 0 (mask 0x01): always 0 (internally used to mark local entries which are not subject of “synchronisation” with the server)
    • Bit 1 (mask 0x02): always 0 (internally used to mark hidden (or “locked”) entries)
  • 1 byte type: connection type of the peer:
    • 0: peer was deleted from the list
    • 1: peer able to support the “texting baudot” protocol, accessible by a host name (known by public DNS servers)
    • 2: peer able to support the “texting baudot” protocol, accessible by a given IP address (IPv4)
    • 3: peer only supporting “ascii texting” (or a standard telnet client), accessible by a host name (known by public DNS servers)
    • 4: peer only supporting “ascii texting” (or a standard telnet client), accessible by a given IP address (IPv4)
    • 5: same as 2, but IP address may change frequently (“DynIP”-type)
    • 6: not a real peer, but a regular email address.
  • 40 byte host name:
    • if “type” is 1 or 3: host name of the peer, encoded in ASCII resp. ISO 8859-1.
    • if “type” is 6: email address, encoded in ASCII resp. ISO 8859-1.
    • Invalid for other “types”.
  • 4 byte IP address:
    • if “type” is 2, 4 or 5: IP address of the peer, coded as a 32 bit integer value. TODO: define byte order.
    • Invalid for other “types”.
  • 2 byte port number:
    • If “type” is 1 to 5: port to be used for the connection (standard 134), coded as a 16 bit integer value.
    • Invalid for other “types”.
  • 1 byte extension:
    • if “type” is 1, 2 or 5: desired extension ID (see chapter 2.3.2, especially the coding!) or 0 if this entry is assigned to the main machine of the subscriber.
    • Invalid for other “types”.
  • 2 bytes PIN: always 0 (internally used for communication between the subscriber servers)
  • 4 byte date: Timestamp of the last change of this entry, encoded as a 32 bit integer value (seconds since 1900-01-00 00:00:00)
  • Example:
    05 64 1b d0 01 00 41 75 74 6f 6d 61 74 69 73 63 68 65 20 41
    75 73 6b 75 6e 66 74 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 01 73 65 72 76 69 63 65 2e 64 76 73
    38 38 31 38 2e 64 65 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 04 10 00 00 00 5e 7b
    b9 e2
  • Meaning:
    Number 118811
    Name Automatische Auskunft
    Type 1
    Host service.dvs8818.de
    Port 4100
    Extension none
    Last change 2020-07-15 14:55

Sync_FullQuery

This packet is used only for the synchronisation between the subscriber servers. This packet initiates a full query of all entries stored at the “opposite” server station The data is structured as following:

  • 1 byte Packet type: 06
  • 1 byte length: 05
  • 1 byte version number: The highest version ID supported by the server. But currently the server supports only version 1.
  • 4 byte Server-PIN: This PIN is unique for all “approved” servers. Server will answer only in case of correct PIN.
  • Example: 06 05 01 16 AA 34 00 (hex)
  • Meaning: Start the full query of the server with the authorisation PIN 3451414 and reply with format version 1.

Sync_Login

This packet is used only for the synchronisation between the subscriber servers. This packet initiates the update of a newly changed or added entry. The data is structured as following:

  • 1 byte Packet type: 07
  • 1 byte length: 05
  • 1 byte version number: The highest version ID supported by the server. But currently the server supports only version 1.
  • 4 byte Server-PIN: This PIN is unique for all “approved” servers. Server will answer only in case of correct PIN.
  • Example: 07 05 01 16 AA 34 00 (hex)
  • Meaning: “Login” to the neighbored server with the authorisation PIN 3451414.

Acknowledge

This packet has to be sent as a general “ok”, for example by the client after the reception of a Peer_reply_v1 packet to request the next entry. Only to be used if the request was initiated by a Peer_search packet, Sync_FullQuery packet or Sync_Login packet.

  • 1 byte Packet type: 08
  • 1 byte length: 00
  • Example: 08 00 (hex)
  • Meaning: Last reply received and processed, request to send next peer data according to query.

End_of_List

This packet is sent by the server either after a Peer_search packet or Acknowledge packet to indicate that all enties matching the requested name pattern were already transmitted.

  • 1 byte Packet type: 09
  • 1 byte length: 00
  • Example: 09 00 (hex)
  • Meaning: No further peer matches to to the query (or no match at all).

Peer_serach

This packet is sent by the client to query a subscriber server for contact details matching a given “name”.

  • 1 byte Packet type: 0a (hex)
  • 1 byte length: 29 (hex)
  • 1 byte version number: The highest version ID supported by the client. But currently the server supports only version 1.
  • 40 byte name: A part of the identification of the peer which should match the name as shown in the subscriber list, coded in ASCII resp. ISO 8859-1.
  • Example: 0A 29 01 53 31 30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (hex)
  • Meaning: search for subscribler list entries containing “T100”.

Error message

This packet indicates any error. In most cases the connection will be terminated directly after sending the error message.

  • 1 byte Packet type: ff (hex)
  • 1 byte length: variable
  • x byte message string: any diagnostic message encoded in ASCII resp. ISO 8859-1.
  • 1 byte null terminating character: 00 (hex)

The length field will contain (as usual) the full length of the message telegram, so the length of the diagnostic message incremented by 3 (x+3).


Sequence Examples

Unlike the i-Telex protocol for “normal” communication the server related protocol is always a kind of “ping pong”. In the following examples “O” stands for the originating part of the connection and “A” for the answering part. “A” is always a subscriber server, “O” may be a client or a server.

Client “DynIP” update:

O: Client_update
A: Address_confirm
(O terminates the connection)

Client query for specific entry:

O: Peer_query
if (entry found)
 A: Peer_reply_v1
else
 A: Peer_not_found
(O terminates the connection)

Client query according search pattern:

O: Peer_search
for each corresponding entry:
 A: Peer_reply_v1
 O: Acknowledge
next
A: End_of_List
(O terminates the connection)

Full query between servers:

O: Sync_FullQuery
for each stored entry
 A: Peer_reply_v1
 O: Acknowledge
end while
A: End_of_List
(O terminates the connection)

Update of some entries from server to server:

O: Sync_Login
A: Acknowledge
for each stored entry
 O: Peer_reply_v1
 A: Acknowledge
end while
O: End_of_List
(O waits 3 seconds and terminates the connection)

Peer query in ASCII format

To simplfy queries of subscribers for third party systems the following way is implemented:

Send the letter q and the required number in ASCII format followed by CR and LF (0D 0A) to port 11811 and the server will answer also in ASCII the following lines (also separated by CR and LF):

Example reply Explanation
ok Indication that subscriber number was found
781272 Repetation of the subscriber number
Fred, Braunschweig T100 Subscriber’s name
1 Type on entry:
  • 1: peer able to support the “texting baudot” protocol, accessible by a host name (known by regular DNS servers)
  • 2: peer able to support the “texting baudot” protocol, accessible by a given IP address (IPv4)
  • 3: peer only supporting “ascii texting” (or a standard telnet client), accessible by a host name (known by regular DNS servers)
  • 4: peer only supporting “ascii texting” (or a standard telnet client), accessible by a given IP address (IPv4)
  • 5: same as 2, but IP address may change frequently
  • 6: not a real peer, but an regular email address.
sonnibs.no-ip.org Host name for types 1 and 3
IP address for types 2, 4 and 5
Email address for type 6
134 Port number
33 Extension number, - for no extension
Note: observe the number of digits, 01 is a different extension compared to 1
+++ Marker for end of data