Difference between revisions of "IAX Text Protocol"

From "PTTLink Wiki"
Jump to navigation Jump to search
m (Added category)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Category:Software]]
+
 
 +
{{Infobox PTTLink
 +
| image = Binary-code.jpg
 +
| caption = Image of binary code
 +
| category = Software
 +
}}
 
[[Category:Development]]
 
[[Category:Development]]
= app_rpt IAX Text Protocol =
+
'''app_rpt IAX Text Protocol'''
  
 
app_rpt application relies on IAX text frame to extend its protocol capabilities and exchange information with other nodes or clients.  There does not seem to be any existing documentation for this. This page details the various type of commands in existence as observed "in the wild". This is based a compilation of reading the source code of app_rpt, and reverse engineering of known clients such as IAXRpt and WebTransceiver. As such it's likely to contain errors or misunderstandings. If you have knowledge in some of these areas, please contribute your edits.
 
app_rpt application relies on IAX text frame to extend its protocol capabilities and exchange information with other nodes or clients.  There does not seem to be any existing documentation for this. This page details the various type of commands in existence as observed "in the wild". This is based a compilation of reading the source code of app_rpt, and reverse engineering of known clients such as IAXRpt and WebTransceiver. As such it's likely to contain errors or misunderstandings. If you have knowledge in some of these areas, please contribute your edits.

Latest revision as of 04:31, 6 September 2021

IAX Text Protocol
Binary-code.jpg
Image of binary code

app_rpt IAX Text Protocol

app_rpt application relies on IAX text frame to extend its protocol capabilities and exchange information with other nodes or clients. There does not seem to be any existing documentation for this. This page details the various type of commands in existence as observed "in the wild". This is based a compilation of reading the source code of app_rpt, and reverse engineering of known clients such as IAXRpt and WebTransceiver. As such it's likely to contain errors or misunderstandings. If you have knowledge in some of these areas, please contribute your edits.

T: Telemetry

Format

T <NODE_NB> <CMD>,<PARAMS>
  • NODE_NB Node sending message
  • CMD Telemetry command ALLCAPS
  • PARAMS Optional comma separated list of command specific parameters

Complete

Example

T 51696 COMPLETE

Status

Report connection status for the node. Sent in response to *70 status DTMF command.

Format

T <NODE_NB> STATUS,<NODE_1>,0,<NODE_LIST>
  • NODE_NB Node sending message
  • NODE_1 Node reporting status
  • 0 Unknown
  • NODE_LIST List of nodes connected to NODE_1. Each node number is prefixed by a connection mode as follow:
    • T Transceive mode, send and receive audio
    • R Receive audio only
    • C Connection is pending

Example

T 51696 STATUS,51696,0,TWH6GJL-P,R29277

Connected

Node connection succeeded

Format

T <NODE_NB> CONNECTED,<NODE_1>,<NODE_2>
  • NODE_NB Node sending message
  • NODE_1 Node initiating connection
  • NODE_2 Other node connected to

Example

T 51696 CONNECTED,51696,29277

Disconnected

Remote node disconnected

Example

T 51696 REMDISC,29277

Removed Already Connected

Remote node is already part of the network. Note that it could be a direct connection or it could be the node is connected via other nodes.

Example

T 51696 REMALREADY

Connection Failed

Remote node can't be connected to.

Example

T 522540 CONNFAIL,51696

Version

app_rpt module version.

Example

T 51696 STATS_VERSION,161.327

Unknown

T 522540 ARB_ALPHA,123#

L: Linked

Sent periodically by a node to broadcast all node linked to it.

Format

L <MODE><NODE_NB>,<MODE><NODE_NB>,...
  • MODE Each node number is prefixed by a connection mode as follow:
    • T Transceive mode, send and receive audio
    • R Receive audio only
    • C Connection is pending
  • NODE_NB Linked node

If no other nodes are connected, the list is empty and only L is sent.

K: Key

Sent by a node to update its keyed status

Format

K <TO> <NODE_NB> <KEYED> <LAST_KEYED_X_SEC_AGO>
  • TO Destination to broadcast this message to. Usually * seems to indicate all connected nodes.
  • NODE_NB Node reporting its keyed status
  • KEYED 1 = node is keyed, 0 = node is not keyed
  • LAST_KEYED_X_SEC_AGO Number of second since node was last keyed

Example

K * 51696 1 2

Key Query

Message to request other nodes to report their keyed state. Initiating this command results in all connected nodes replying with their keyed status.

Format

K? <TO> <NODE_NB> 0 0
  • TO Destination to broadcast this message to. Usually * seems to indicate all connected nodes.
  • NODE_NB Node requesting status? Could be * here as well

Example

K? * 51696 0 0

M: Message

Text message. Can be sent as node to node or broadcast to all nodes.

Format

M <TO> <FROM> <BODY>
  • TO Destination node number. 0 indicates all connected nodes
  • FROM Source node number
  • BODY Message content

Example

M 0 51696 Reminder net starts at 10:00 pm PST tonight.

J: ?

Status message reporting repeater frequencies. Seems to be only used in the context of the WebTransceiver client.

Format

J Remote Frequency \n<FREQ> FM\n<OFFSET> Offset\n<POWER> Power\nTX PL <TXPL>\nRX PL <RXPL>\n

Miscellaneous signaling

There are several messages being exchanged that alter the behavior of the app_rpt application. It's unclear as to their purpose.

New Key

Seems that this is meant to be some sort of handshake. When a party receives this command it should send it back.

!NEWKEY!

New Key1

Seems that this is meant to be some sort of handshake. When a party receives this command it should send it back.

!NEWKEY1!

IaxKey

Seems that this is meant to be some sort of handshake. When a party receives this command

!IAXKEY!

it should reply with

!IAXKEY! 1 1 0 0

Disconnect

!!DISCONNECT!!