Order Tray | Contact Us | Home | SIG Lists

[aprssig] [OT] Re: CB traffic on APRS-IS

Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.to
Wed Feb 15 18:40:22 UTC 2012


I believe this was bandied about here a while back with the conclusion, 
IIRC, of an inability to define what is a "valid call sign".   Pattern 
matching can get you a bunch that MAY be valid, but not all licensing 
agencies publish lists like our FCC does, and worse, I don't see a 
feasible way of keeping every interested party up-to-date on the current 
lists of "valid" call signs globally either.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  If it were easy, it would already be implemented, I'm sure!

On 2/15/2012 1:28 PM, Greg Dolkas wrote:
> Couldn't we take the approach that only packets with valid call signs in them get processed?  Other packets may be legal, due to local context, but that doesn't mean we have to handle them.  There's a higher bar to cross in using a gateway.
>
> Just a thought,
>
> Greg  KO6TH
>
> Sent from my trusty HP iPAQ.
>
> -----Original Message-----
> From: "Lynn W. Deffenbaugh (Mr)"<ldeffenb at homeside.to>
> To: "TAPR APRS Mailing List"<aprssig at tapr.org>
> Sent: 2/15/12 4:57 AM
> Subject: Re: [aprssig] [OT] Re:  CB traffic on APRS-IS
>
> On 2/15/2012 7:40 AM, Dave wrote:
>> Anwyay, re the above snippet.   If somewhere in the packet, even in the
>> payload, there is a Ham call that somehow identifies the originator, it's
>> legal.
>>
> And even worse, not every packet (at least here in the US) needs to have
> that ID.  If you beacon a comment or a status report at least once every
> 10 minutes, you're legal (on the air), so any soft of filtering (that's
> the bush we're all beating around, right?) would have to be stateful and
> remember which stations had a "legal" identification within the past "N"
> minutes where "legal" and "N" are locale-specific and therefore nigh on
> impossible to do on the APRS-IS backbone IMHO.
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> PS.  Now, to figure out how to implement locale-specific filters to
> mitigate the risk to bi-directional IGate operators for third-party
> message transmissions and/or APRS-IS to RF IGate rules...  Especially
> when the first packet that said IGate might see is a message from a
> distant source destined for a recently local station...  And even worse,
> when the message sender is using a tactical station ID and relying on
> comments or status reports to provide legal identification...
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>




More information about the aprssig mailing list