<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I concur that this is very bad practice
and 100% non-APRS-IS-spec compliant. To quote the specification
from <a class="moz-txt-link-freetext" href="https://aprs-is.net/IGating.aspx">https://aprs-is.net/IGating.aspx</a><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">
<blockquote type="cite"><span
style="color: rgb(101, 109, 118); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Noto Sans", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji"; font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;"><b>No
modification of the TNC2 format line should be made</b>
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.</span></blockquote>
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:<br>
<br>
The AX.25 Destination Address field can contain 6 different types
of APRS information:<br>
• A generic APRS address.<br>
• A generic APRS address with a symbol.<br>
• An APRS software version number.<br>
• Mic-E encoded data.<br>
• A Maidenhead Grid Locator (obsolete).<br>
• An Alternate Net (ALTNET) address.<br>
<br>
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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
<br>
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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Lynn (D) - APRS Foundation - Ensuring
the Future of APRS</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 2/15/2024 2:50 PM, Heikki
Hannikainen wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ec501ee-e24e-4d8b-39bd-fba7949ccf@hes.iki.fi">
<br>
Hi,
<br>
<br>
I've just learned that the VARA HF modem is replacing the APRS
destination callsign with "APVARA".
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/aprsorg/aprs-deviceid/issues/123">https://github.com/aprsorg/aprs-deviceid/issues/123</a>
<br>
<br>
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.
<br>
<br>
- Hessu
<br>
<br>
<br>
_______________________________________________
<br>
aprssig mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a>
<br>
</blockquote>
<p><br>
</p>
</body>
</html>