The "q-construct" is implemented on APRS-IS to add the following capabilities to
the Internet APRS transport mechanism.
- APRS-IS Entry Identification
- Support for a Future Authorization Algorithm
- Support for Loop Detection
- Support for Automatic Loop Protection
- Compatibility with Existing IGate and Client Software
- Only Server Support Needed for Implementation
The currently defined q constructs are:
Server Generated:
- qAC - Packet was received from the client directly via a verified
connection (FROMCALL=login). The callSSID following the qAC is the
server's callsign-SSID.
- qAX - Packet was received from the client directly via a unverified
connection (FROMCALL=login). The callSSID following the qAX is the
server's callsign-SSID. This
construct is in addition to the TCPIP*/TCPXX* construct currently in place.
TCPXX and qAX have been depricated on APRS-IS.
- qAU - Packet was received from the client directly via a UDP connection.
The callSSID following the qAU is the server's callsign-SSID.
- qAo - (letter O) Packet was received via a client-only port, the FROMCALL
does not match the login, and the packet contains either a ,I or qAR construct
where the indicated IGate matches the login.
- qAO - (letter O) Packet was received via a client-only port and the
FROMCALL does not match the login.
- qAS - Packet was received from another server or generated by this
server. The latter case would be for a beacon generated by the server. Due to
the virtual nature of APRS-IS, use of beacon packets by servers is strongly
discouraged. The callSSID following the qAS is the login or IP address of the
first identifiable server (see algorithm).
- qAr - Packet was received indirectly (via an intermediate server) from an
IGate using the ,I construct. The callSSID following the qAr it the callSSID of
the IGate.
- qAR - Packet was received directly (via a verified connection) from an
IGate using the ,I construct. The callSSID following the qAR it the callSSID of
the IGate.
Client Generated:
- qAR - Packet is placed on APRS-IS by an IGate from RF. The callSSID
following the qAR is the callSSID of the IGate.
- qAO - (letter O) Packet is placed on APRS-IS by a receive-only IGate from RF. The callSSID
following the qAO is the callSSID of the IGate.
Note that receive-only IGates are discouraged on
standard APRS frequencies. Please consider a bidirectional IGate that only gates to
RF messages for stations heard directly.
- qAZ - Packet is generated by the server/client/IGate and should not be
propagated. The callSSID following the qAZ is the callSSID of the
server/client/IGate. This is normally used for connection messages such as
messages to USERLIST.
- qAI - Trace packet. This packet tells each server to add login
identification to the packet. This packet starts with the callSSID of the
originating station following the qAI. See algorithm for more details.
Client generated q constructs will be verified if a new authorization algorithm
is created.
Servers MUST have unique logins from
any other server/IGate/client that insert data onto APRS-IS.
This is to prevent packets from being erroneously detected as looping. For
instance, if my server's login is AE5PL and my weather client is AE5PL, my
server will see ,qAC,AE5PL and consider this packet a looped packet. As
logins can be any combination of 9 alphanumeric characters, this should not pose
a problem.
IGates which append IGATECALL,I to the end of packets and which are directly
connected to a server which supports the q construct will have the IGATECALL,I
converted to qAR,IGATECALL, qAr,IGATECALL, or qAo,IGATECALL to support the
extended capabilities of the q construct.
Servers will have the ability to selectively enable tracing on all packets
through server configuration. This must be used judiciously and only when
a loop condition is suspected due to the increased bandwidth demands that
tracing creates.
q constructs will only appear on APRS-IS and are not to be used elsewhere due to
bandwidth considerations.
For example, this is what happens to a packet without a q construct which enters
the system via a verified connection:
Original packet:
AE5PL>APRS,TCPIP*:payload
Packet leaving the server if trace is off:
AE5PL>APRS,TCPIP*,qAC,AE5PL-JS:payload
or, if trace is on:
AE5PL>APRS,TCPIP*,qAI,AE5PL,AE5PL-JS:payload
Here is a similar example where the packet is gated to APRS-IS from RF:
Original packet:
AE5PL>APRS,WIDE1*:payload
Packet leaving the server if trace is off:
AE5PL>APRS,WIDE1*,qAR,AE5PL-10:payload
or, if trace is on:
AE5PL>APRS,WIDE1*,qAI,AE5PL-10,AE5PL-JS:payload
Logins used on APRS-IS must not consist of exactly 8 characters from 0 to 9
or A to F as this would indicate a server generated IP address for the q
construct.