<div dir="ltr"><div><div>Greetings,</div><div><br></div><div>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: <a href="https://github.com/PhirePhly/aprs_notes/blob/master/digi_behavior.txt">https://github.com/PhirePhly/aprs_notes/blob/master/digi_behavior.txt</a> ).</div><div><br></div><div>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:</div><div><br></div><div><br></div><div>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 (<a href="http://aprs-is.net/Connecting.aspx">http://aprs-is.net/Connecting.aspx</a>):</div><div>"Total length of logins/callsigns may not exceed 9 characters including the SSID if present."</div><div><br></div><div>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 <a href="http://aprs.fi">aprs.fi</a>, through both aprsc and javAPRSSrvr. Should documentation be clarified to allow this or to not allow this?</div><div><br></div><div>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?</div><div><br></div><div>3. Best I can tell, TCPIP is inserted in two scenarios:</div><div>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"</div><div>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"</div><div><br></div><div>Is there a preferred format coming from Internet connected stations than "SRCCALL>TNCID:,Payload"?</div><div>Is my understanding of the TCPIP alias wildly off base?</div><div>Should we be seeing packets on RF with TCPIP in them except third party packets?</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>Full text of my notes ( <a href="https://github.com/PhirePhly/aprs_notes/blob/master/callsigns.txt">https://github.com/PhirePhly/aprs_notes/blob/master/callsigns.txt</a> )</div><div><br></div><div> *** APRS Callsigns ***</div><div><br></div><div>APRS was originally built on top of AX.25, which limited each station to</div><div>a six character callsign with an additional four bit secondary station</div><div>identifier (SSID). This limit still exists on AX.25, but APRS stations</div><div>operating exclusively on the APRS-IS Internet system aren't as limited.</div><div><br></div><div>Callsigns for AX.25 must:</div><div> * Consist of only upper case letters and numbers</div><div> * Have a base callsign before the SSID at least three characters long</div><div> * Have a numeric SSID which falls in 0 - 15</div><div> * Have a base callsign before the SSID no longer than six characters</div><div><br></div><div>Callsigns for APRS must:</div><div> * Consist of only upper case letters and numbers</div><div> * Be at least three characters long preceeding the optional '-SSID'</div><div> * Optionally include one hyphen with a 1-2 character alphanumeric SSID suffix</div><div> * Be no longer than nine characters in total</div><div> * Not include the -0 SSID, since that is implicit in a lack of an SSID</div><div><br></div><div>Callsigns should be:</div><div> * Globally unique</div><div><br></div><div>The APRS limitation of nine characters causes confusion as to if base</div><div>callsigns of lengths 7-9 are allowed.</div><div><br></div><div>In this context alphanumeric is defined as any ASCII values in the range:</div><div> * decimal [65 - 90] - 'A'-'Z'</div><div> * decimal [48 - 57] - '0'-'9'</div><div><br></div><div>In addition to legally identifying callsigns and tactical calls, APRS</div><div>defines additional calls which fall in these categories:</div><div> * Blacklisted callsigns</div><div> * Terminal Node Controller Identifiers</div><div> * Routing aliases</div><div> * Special handling tokens</div><div><br></div><div><br></div><div> *** Blacklisted Callsigns ***</div><div><br></div><div>The following callsigns are used for documentation and should be dropped</div><div>or disallowed as early as possible if a user attempts to use them for their</div><div>station callsign:</div><div> * NOCALL</div><div> * N0CALL</div><div> * MYCALL</div><div><br></div><div><br></div><div> *** Terminal Node Controller Identifiers ***</div><div><br></div><div>The destination station field may optionally be used to identify the hardware</div><div>or software being used, in which case the destination callsign will begin with</div><div>"AP". Experimental devices may use the "APZ" prefix without contacting Bob B.</div><div><br></div><div>Relevant links: </div><div> * <a href="http://aprs.org/aprs11/tocalls.txt">http://aprs.org/aprs11/tocalls.txt</a></div><div> * <a href="https://github.com/hessu/aprs-deviceid">https://github.com/hessu/aprs-deviceid</a></div><div><br></div><div><br></div><div> *** Routing Aliases ***</div><div><br></div><div>Many callsigns may be used in the routing path to request service from</div><div>groups of digipeaters instead of individual specific digipeaters.</div><div>Each of these aliases consists of one (?) to five characters, an 'n' original</div><div>hop specifier, and an 'N' hops remaining specifier as the SSID.</div><div> * Neither n nor N may be greater than seven.</div><div> * n must always be greater than or equal to N</div><div> * N must be decremented by every digipeater handling a packet</div><div><br></div><div>The most widely supported alias is WIDEn-N</div><div><br></div><div>Many regions standardize on additional local aliases, which are often referred</div><div>to as SSn-N aliases, since the idea originated with state-wide groups for</div><div>smaller east coast states. These groups allow local users to flood the network</div><div>with SS7-7 aliases without packets traveling outside the intended service area.</div><div>See your local regional APRS interest group for more information.</div><div><br></div><div>Does anyone care about the HF-to-VHF GATE alias anymore?</div><div><br></div><div><br></div><div> *** Special Handling Tokens ***</div><div><br></div><div>The last hop in a routing path may be a special handling token, which</div><div>instructs other stations to handle the packet in a specific way:</div><div> * RFONLY - Do not I-gate this packet to the APRS-IS backbone</div><div> * NOGATE - Do not I-gate this packet to the APRS-IS backbone</div><div> * TCPIP - Packet originated from Internet source, do not I-gate</div><div> * TCPXX - Packet originated from unverified Internet source (?), do not RF-gate. Do not I-gate. Deprecated?</div></div><div><br></div><br clear="all"><div><div class="gmail_signature">--<br>Kenneth Finnegan, W6KWF<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a></div></div>
</div>