[aprssig] VARA modem replacing APRS tocall

[Lynn W Deffenbaugh (Mr)]

First, I hope both Michael Phelps NA7Q (the person raising the issue) 
and Jose Alberto Nieto Ros EA5HVK (apparently the VARA HF author) are 
members here on the aprssig. This is the definitive venue to discuss 
APRS and APRS-IS implementation issues and questions.

I concur that this is very bad practice and 100% non-APRS-IS-spec 
compliant.   To quote the specification from 
https://aprs-is.net/IGating.aspx

> *No modification of the TNC2 format line should be made* except to add 
> ,qAR,IGATECALL to the end of the path (and the third-party exception 
> noted above). IGATECALL is the callsign-SSID of the IGate and denotes 
> the point of entry for the packet.
Specifications exist to ensure compatibility across independent 
implementations. The so-called "ToCall" (actually the AX.25 destination 
address) is defined in the APRS101.pdf specification to contain (page 
13) one of the following:

The AX.25 Destination Address field can contain 6 different types of 
APRS information:
• A generic APRS address.
• A generic APRS address with a symbol.
• An APRS software version number.
• Mic-E encoded data.
• A Maidenhead Grid Locator (obsolete).
• An Alternate Net (ALTNET) address.

Each of these is further detailed in the following sections of chapter 
4. While it may not be explicitly stated, the ToCall is assigned by the 
originator of the packet. So, if VARA HF is SOURCING the packets, then 
using >APVARA would fit within the specifications.  However, in this 
case the VARA HF modem is choosing to not transmit the ToCall to save a 
few bytes over RF. However, this constitutes a loss important data from 
the original packet and a non-compliant modification of the original 
client APRS packet.

There are many tools that use the packet destination address (ToCall) to 
identify the type of station that originated the packet.  This is used 
to identify client station capabilities (messaging-capable, for 
instance) as well as to identify client hard/firm/software that may be 
generating non-compliant packets.  This is the reason behind the IGate 
specifications. IGates are responsible for relaying the actual received 
packets, without modifications, to the APRS-IS. To do otherwise is to 
invite chaos into the system.

IMHO, the loss of the originating client identity (or worse, a 
conflicting indication of the client identity if the original packet is 
delivered to the APRS-IS outside of VARA HF) is not worth the savings of 
a short bit of RF time. If the destination callsign is considered 
"unnecessary", then who is to say that comment strings, altitudes, 
speed/direction, or other various APRS packet components won't be 
dropped in the future to "save RF time" by some particular protocol.

Lynn (D) - APRS Foundation - Ensuring the Future of APRS

PS.   Most of the above text was originally posted by me in the quoted 
github issue, but is copied here to keep a single discussion thread here.

On 2/15/2024 2:50 PM, Heikki Hannikainen wrote:
>
> Hi,
>
> I've just learned that the VARA HF modem is replacing the APRS 
> destination callsign with "APVARA".
>
> For example, if you use APRSIS32 with a VARA HF modem, APRSIS32 sets a 
> tocall of APWW11 and sends the packet to VARA modem software, which 
> replaces APWW11 with APVARA. This is apparently done to save a few 
> bytes on the slow HF link.
>
> If APRSIS32 is configured to also send the packet to the APRS-IS, 
> there will be two different copies of the packet, both will be 
> received by other APRS stations, and the original APRS software model 
> cannot be detected any more.
>
> https://github.com/aprsorg/aprs-deviceid/issues/123
>
> Just thought this should be brought up for other APRS software 
> developers to discuss, and for awareness of the side effects. I'm not 
> particularly delighted by this implementation choice. Don't shoot the 
> messenger.
>
>   - Hessu
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20240215/cd901cfa/attachment.html>