[aprssig] Questions about Callsigns Used in APRS

[Kenneth Finnegan]

Greetings,

As I have been putting more cycles in development of Aprx these days, I've
been collecting notes on various facets of APRS (see my previous file on
digipeater packet handling:
https://github.com/PhirePhly/aprs_notes/blob/master/digi_behavior.txt ).

My next set of notes is on the definition of a callsign in APRS and
APRS-specific callsigns. Like usual, trying to write this all down in one
place has triggered some questions:


1. What is the maximum length of an APRS callsign? AX.25 limits us to 6
characters before the SSID, but APRS is more permissive when AX.25 isn't
involved. The first thing I've found in writing is Pete (
http://aprs-is.net/Connecting.aspx):
"Total length of logins/callsigns may not exceed 9 characters including the
SSID if present."

I read this as saying that a station may have up to a seven character
callsign if they only have a one character SSID, and up to nine character
callsign if they don't have an SSID... There is precedent for >6char
callsigns (see WINLINK, IRLP1234, etc) but others have disagreed with me
that these are allowed. None of these can be AX.25 stations, but it should
be possible to handle them as Internet connected stations which can be
RF-gated as third party packets. Thoughts? Does anyone know of any software
that pukes on longer base callsigns? Nine character base callsigns
certainly at least work for getting from my station to aprs.fi, through
both aprsc and javAPRSSrvr. Should documentation be clarified to allow this
or to not allow this?

2. What is the minimum length for SSn-N aliases? Two? One? Probably two to
meet the APRS minimum of three when the 'n' is appended?

3. Best I can tell, TCPIP is inserted in two scenarios:
a) When an RF-gate generates a third-party packet to gate a packet from
APRS-IS back to the local RF, it assembles
"}SRCCALL>THEIRTNCID,TCPIP,RFGATECALL*:,THEIR INFO FIELD"
b) When a station is inserting a packet directly into the APRS-IS system,
it (should? may? unfortunately does?) uses a path of
"SRCCALL>TNCID:,Payload" and the receiving APRS-IS server rewrites it
before passing it to the APRS-IS mesh as
"SRCCALL>TNCID,TCPIP*,qAC,SERVERCALL:,Payload"

Is there a preferred format coming from Internet connected stations than
"SRCCALL>TNCID:,Payload"?
Is my understanding of the TCPIP alias wildly off base?
Should we be seeing packets on RF with TCPIP in them except third party
packets?

4. Is TCPXX entirely deprecated? It seems to have been used to mark
Internet-sourced packets from unverified stations, but do we even allow
unverified connections to source packets any more? Should developers still
be supporting this alias?

5. Is GATE still a valid special handling token worth documenting and
supporting? Do HF stations requesting GATE actually want to land on
everyone's VHF LANs or do they really only care about getting to the
Internet? Are cross-band digis which aren't I-gates much of a thing any
more?

Full text of my notes (
https://github.com/PhirePhly/aprs_notes/blob/master/callsigns.txt )

 *** APRS Callsigns ***

APRS was originally built on top of AX.25, which limited each station to
a six character callsign with an additional four bit secondary station
identifier (SSID). This limit still exists on AX.25, but APRS stations
operating exclusively on the APRS-IS Internet system aren't as limited.

Callsigns for AX.25 must:
 * Consist of only upper case letters and numbers
 * Have a base callsign before the SSID at least three characters long
 * Have a numeric SSID which falls in 0 - 15
 * Have a base callsign before the SSID no longer than six characters

Callsigns for APRS must:
 * Consist of only upper case letters and numbers
 * Be at least three characters long preceeding the optional '-SSID'
 * Optionally include one hyphen with a 1-2 character alphanumeric SSID
suffix
 * Be no longer than nine characters in total
 * Not include the -0 SSID, since that is implicit in a lack of an SSID

Callsigns should be:
 * Globally unique

The APRS limitation of nine characters causes confusion as to if base
callsigns of lengths 7-9 are allowed.

In this context alphanumeric is defined as any ASCII values in the range:
 * decimal [65 - 90] - 'A'-'Z'
 * decimal [48 - 57] - '0'-'9'

In addition to legally identifying callsigns and tactical calls, APRS
defines additional calls which fall in these categories:
 * Blacklisted callsigns
 * Terminal Node Controller Identifiers
 * Routing aliases
 * Special handling tokens


 *** Blacklisted Callsigns ***

The following callsigns are used for documentation and should be dropped
or disallowed as early as possible if a user attempts to use them for their
station callsign:
 * NOCALL
 * N0CALL
 * MYCALL


 *** Terminal Node Controller Identifiers ***

The destination station field may optionally be used to identify the
hardware
or software being used, in which case the destination callsign will begin
with
"AP". Experimental devices may use the "APZ" prefix without contacting Bob
B.

Relevant links:
 * http://aprs.org/aprs11/tocalls.txt
 * https://github.com/hessu/aprs-deviceid


 *** Routing Aliases ***

Many callsigns may be used in the routing path to request service from
groups of digipeaters instead of individual specific digipeaters.
Each of these aliases consists of one (?) to five characters, an 'n'
original
hop specifier, and an 'N' hops remaining specifier as the SSID.
 * Neither n nor N may be greater than seven.
 * n must always be greater than or equal to N
 * N must be decremented by every digipeater handling a packet

The most widely supported alias is WIDEn-N

Many regions standardize on additional local aliases, which are often
referred
to as SSn-N aliases, since the idea originated with state-wide groups for
smaller east coast states. These groups allow local users to flood the
network
with SS7-7 aliases without packets traveling outside the intended service
area.
See your local regional APRS interest group for more information.

Does anyone care about the HF-to-VHF GATE alias anymore?


 *** Special Handling Tokens ***

The last hop in a routing path may be a special handling token, which
instructs other stations to handle the packet in a specific way:
 * RFONLY - Do not I-gate this packet to the APRS-IS backbone
 * NOGATE - Do not I-gate this packet to the APRS-IS backbone
 * TCPIP - Packet originated from Internet source, do not I-gate
 * TCPXX - Packet originated from unverified Internet source (?), do not
RF-gate. Do not I-gate. Deprecated?


--
Kenneth Finnegan, W6KWF
http://blog.thelifeofkenneth.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20160925/44eb79c8/attachment.html>