[aprssig] APRX aprs-is filtering

[Randy Love]

The issue I have with this is duplicate tactical calls in different RF
areas.

On more than one occasion, I have run into events outside my RF area using
the same tactical calls on ARPS as my event, typically along the lines of
SAG-3 and MED-2, for example. As it is now, there is some advantage to all
MED-* units receiving the same message, however, when the med units outside
your event also receive it, it can cause issues. Ideally, you would run your
local event on a dedicated channel and/or use NOGATE in your paths, but
sometimes due to geographic needs, you use the existing APRS infrastructure,
including APRS-IS and two-way Igates.

I understand the idea that any station for CALL should receive all messages
send to it, and that only the specific CALL-SSID should ack, but what do you
do in the case of a club call that is used at 7 different hospitals?

If one call would always equal one ham, this scheme makes since, but in the
cases of tactical events, where several base calls are using different
SSID's for actually different stations, then this method tends to add
confusion instead of adding functionality.

Yes, training of operators would go a long way in elevating this concern,
but in the heat of battle, little nuances like this get overlooked and
confusion/misinformation can set in.

Just an observation.

73,
Randy
WF5X


On Sat, Aug 7, 2010 at 10:36 PM, Stephen H. Smith <wa8lmf2 at aol.com> wrote:

>  On 8/7/2010 5:54 PM, Bob Bruninga wrote:
>
>>
>> Yes, "recently-heard" still applies...  Today, for example, I am in Utah
>> at a conference with my WB4APR-7 HT.  I drove to the airport in my WB4APR-9
>> and my home station or work station are also on the air.  I expect a message
>> sent to ANY of my WB4APR stations (if seen by an Igate near me) to send it
>> out to RF including my HT in UTAH.  I use "expect" in the future sense,
>> because as we are learning, this is not presently the case).
>>
>> I DO agree with the need for an option (defaults to ON) so that someone
>> can turn off the delivery of messages to some SSID's.. though that adds even
>> more complexity..
>>
>
>
> I would propose that this be implemented in a manner similar to call
> forwarding on phone numbers, or auto-forwarding between email accounts.
> "OFF" unless explicitly set, perhaps by a message to the APRS server,
> similar to what is sent to select port 14580 filters or the CQSVR.
>  Perhaps an auto-expire of 24 or 48 hours or so, so that forwarding set for
> a short out-of-area trip will cancel itself if forgotten.
>
> On the other hand, is all this complexity worth it???     How often have
> you had an urgent message sent to an APRS address that would actually
> matter, if you missed it due to being away from a particular SSID?
>
>
>
>
> -------------------------------------------------------------------------------
>
> --
>
> Stephen H. Smith    wa8lmf (at) aol.com
> EchoLink Node:      WA8LMF  or 14400    [Think bottom of the 2M band]
> Skype:        WA8LMF
> Home Page:          http://wa8lmf.net
>
> NEW!    *** HF APRS over PSK63 ***
>   http://wa8lmf.net/APRS_PSK63/index.htm
>
> Universal HF/VHF/UHF Antenna Mounting System
>  http://wa8lmf.net/mobile/UniversalAntMountSystem.htm
>
> "APRS 101"  Explanation of APRS Path Selection & Digipeating
>  http://wa8lmf.net/DigiPaths
>
>
>
>
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20100807/5d1d62a2/attachment.html>