Connecting to APRS-IS

To establish a connection to APRS-IS, establish a TCP connection to a port on an APRS-IS server that provides the type of feed you desire. If your client software is bidirectional (sends and receives), turn off the Nagle algorithm when connecting to APRS-IS as it can introduce significant delays (TCP_NODELAY).

All core servers support port 10152 as a full feed port. Use this feed judiciously as the packets per second and the overall bandwidth requirements will quickly overrun most APRS clients and may overrun your ISP's capabilities. Most servers support the HTML status port of 14501 which can be used to inform you of other ports available on that server. Simply connect to that port with a browser (http://aprsserver:14501) to view the page.

All core servers and most second tier servers support port 14580 as a user-defined filter port. This port begins by only sending message packets addressed to the client or addressed to stations gated to APRS-IS by the client. As with ALL bidirectional ports, ALL packets passed from the client are passed to APRS-IS on a verified connection (more on that later). Most javAPRSSrvr servers use javAPRSFilter to provide the server-side filtering capability. javAPRSFilter is an additive filter. In other words, you start by receiving almost nothing. When you add a filter, you now receive the original few packets plus the packets that meet your filter definition. See the Filter Definition page for more information.

WebSocket Protocol (javAPRSSrvr Only)

If a server has a HTTP Send-Only port and it is javAPRSSrvr, it can support the WebSocket protocol. It is currently supported by srvr.aprs-is.net:8080 and ametx.com:8888 (secure) and on the status port, srvr.aprs-is.net:14501. One advantage of using the WebSocket protocol is the built-in support for proxies at the client end. Also, some wireless carriers allow for extended HTTP data vs. inline data. The WebSocket protocol appears to the client just like any other TCP port with the following caveats:

• Supports no protocol indicator, or readwrite or history protocols only.
  The default is readwrite which is the same as a user-defined filter port (port 14580).
• If the history protocol is requested, the port behaves like a user-defined filtered history port where the filter must be defined in the login line.
• The server sends binary messages only due to non-UTF-8 packets. The client can send either text or binary messages.
• The WebSocket protocol has been tested with the HTML5 JavaScript WebSocket API on Chrome, FireFox, Opera, Edge, and Internet Explorer 11.
• Sysops request that the software name in the APRS login sequence be the web site if initiated from a web page or the application name if from a self-contained application.
  The version number is either the version of the application or something to indicate point-of-origin for web page applications (page name or javascript, node.js, etc.)

Recommended Default Ports

The following table contains recommended default ports for public facing servers. All public facing servers should have a port table on their status page indicating which ports are available for that specific server.

Port	Usage	Implementation Notes
14501	HTTP Status Page	javAPRSSrvr may also have HTTP send-only/WebSocket and/or UDP send-only support
10152	TCP Full Feed	May support UDP feed. Core servers must support. Lower tier servers may not support.
14580	User-defined Feed	Limited feed supports IGate messaging except on FireNet servers.
23000	TCP Full Feed	Client MUST specify UDP feed. Core servers must support.
8080	HTTP and/or UDP send-only	Standards-based HTTP port. javAPRSSrvr servers support WebSocket on HTTP ports.

Once you have connected to a server TCP port, you must log in after the server's identification line is displayed (see Server Design ). The login is formatted ([] is optional, underlined words are keywords):

user mycall[-ss] pass passcode[ vers softwarename softwarevers[ UDP udpport][ servercommand]]

• mycall-ss=your unique callsign-SSID (-SSID is optional but equates to zero if omitted, see below). This must be unique throughout APRS and AX.25. See below for formatting restrictions.
• passcode=computed passcode for your callsign. -1 is used for receive-only. It is the responsibility of each software author to provide the proper passcode to their individual users on a request basis. This is to aid in keeping APRS-IS restricted to amateur radio use only.
  While the algorithm to generate the passcode is available from some open-source locations, I will not publish it here. If you are an Amateur Radio operator writing software for APRS-IS, contact me directly for the algorithm; otherwise, contact the software author for your passcode.
• softwarename=one word name of the client software. Do not use spaces.
• softwarevers=version number of the client software. Do not use spaces.
• udpport=UDP port number that the client is listening to
• servercommand=any command string (spaces OK) understood by the server. This will normally be something like
  filter r/33/-96/25
  to cause all packets from stations with 25 km of 33N 96W to be passed to the client.

A sample receive only log in sent to a server TCP port 14580 might be:
user AE5PL-TS pass -1 vers testsoftware 1.0_05 filter r/33.25/-96.5/50

With the release of javAPRSSrvr 4.3.2b76, some servers now support encoding the login line using Base64. While this is NOT secure, it does obscure the login line from plain text sniffers. This was done so javAPRSSrvr properly implements RFC 7235 with the added benefit that any login line can be encoded. This is currently only implemented in javAPRSSrvr 4.3.2b76 and later.

javAPRSSrvr responds to a connection with a line starting with a # and acknowledges the login with another line starting with a # (see Server Design ). Lines starting with # are considered comments and ignored. Most servers will also periodically send lines beginning with a # to check the connection if there has been no activity on the TCP port.

All "packets" sent to APRS-IS must be in the TNC2 format terminated by a carriage return, line feed sequence. No line may exceed 512 bytes including the CR/LF sequence. Only verified (valid passcode) clients may send data to APRS-IS. See the IGate document regarding gating packets to APRS-IS. Packets originating from the client should only have TCPIP* in the path, nothing more or less (AE5PL-TS>APRS,TCPIP*:my packet). For compatibility, the following rules are for any station generating packets:

• q constructs should never appear on RF. Only the qAR and qAO constructs may be generated by a client (IGate) on APRS-IS.
• The I construct should never appear on RF. This is an out-dated IGate construct which should no longer be used.
• Except for within 3rd party format gated packets, TCPIP and TCPXX should not be used on RF.

Login Format Rules

Station logins/callsigns generally follow the TNC2/AEA standards for textual representations.
Logins/callsigns must be alphanumeric ASCII characters only (may be upper/lower/mixed case).
Logins/callsigns may contain a single hyphen followed by one or two alphanumeric ASCII characters.
A SSID of zero is assumed if the callsign does not have a SSID; therefore never explicitly define -0 as a SSID.
SSIDs may be 1 or 2 ASCII alphanumeric characters only.
Total length of logins/callsigns may not exceed 9 characters including the SSID if present.
The minimum length of the callsign only (preceeding the hyphen if present) is 3 characters.
RF and APRS-IS clients may convert lower or mixed case callsigns and SSIDs to upper case.
APRS-IS servers consider all callsigns-SSID combinations as unique regardless of case.
Callsigns (preceeding hyphen if present) are converted to upper case for passcode calculation.
Future APRS-IS servers may restrict logins to international callsign format rules forcing uppercase for the callsign. The regex for international callsigns is:
(?>[1-9][A-Z][A-Z]?+[0-9]|[A-Z][2-9A-Z]?[0-9])[A-Z]{1,4}+

SSID and callsign restrictions vary depending on intended use. Assume that if you are going to message or use a station on RF, the callsign and SSID must be upper case. If you are going to transmit on RF directly (directly to the TNC, not via 3rd party gating), you must use a SSID from 0 to 15 (-0 is never used, no SSID represents a zero SSID) (AX.25 SSID). If you are going to message to some Yaseu radios, you must use an AX.25 SSID as they will not respond to a non-AX.25 SSID even if contained in a 3rd party packet. SSIDs are a maximum of 2 alphanumeric characters, period. This maintains compatibility across all software and hardware. Some software does not differentiate between lower and upper case. Always use upper case for callsign and SSID.