[aprssig] APRS message-handling algorithms / libraries

Sun Apr 8 14:33:22 EDT 2012

Hi Greg,

Thanks for the feedback.  My initial plan for validation of IM->APRS 
messages is to take a similar approach to what Winlink's APRSLink is 
doing: the APRS side user must pre-authorize the IM user.  This makes 
double sense in the XMPP case, because XMPP already uses a mutual 
authorization protocol to add someone to your roster.  (Friend A says "I 
want to add friend B", and friend B must accept the request before 
friend A can see presence information.)  This should be pretty effective 
against spam.

I am curious what email gateway you are using.  There are plenty of them 
to send emails from APRS to the Internet, but I have yet to find one 
that works well to send email from Internet to APRS.  Winlink's APRSLink 
can do it, but its lack of real-time notifications to APRS makes it less 
than excellently useful.

Integration with SMS might be possible down the road; it's a bit 
trickier because the SMS gateways out there charge a fee, and the email 
gateways aren't bidirectional (and could already be used 
unidirectionally by one of the many email gateways out there.)

Google Talk runs on a lot of smartphones and can achieve the same 
effect, at least for those people that are already paying for smartphone 
service.

The other nice thing about this is that it works from desktops, wifi, etc.

-- John
KR0L

On 04/08/2012 01:25 PM, Greg Dolkas wrote:
> Hi John,
>
> Your last comment may be the most important...  validating the source 
> of messages going from IM->APRS.  I have totally abandoned the 
> Microsoft IM service because of the constant barage of spam, 
> virus-laden links, unsolicited buddy requests, etc. that appear when I 
> connect.  Some of the other services are not much better, and in my 
> opinion, with the exception of Google's (which is integrated in with 
> their email service and so far spam-free), nearly all are practically 
> worthless to me these days.
>
> I've used the various APRS->Email gateways a number of times, mostly 
> successfully.  With phone text messaging commonly used and often more 
> reliable and accessible than a phone call, and email->text message 
> gateways provided by all of the major carriers, APRS->Phone Text 
> Messaging can be an effective means of communicating when I'm out of 
> cellular range.
>
> The only trick to interoperating with a cell phone is to pick the 
> right ARPS email gateway so that the message comes across formatted 
> well for the phone.  Some add additional information to guide the 
> person on the other end, and this isn't tolerated well by some 
> phones.  (I crashed my daughter's Moto Razr once by doing this...)  
> Others end up with the message text as the subject, etc.  It can be 
> quite confusing to the participants.
>
> So, if I might suggest, a better gateway to write would be for a 
> APRS->Phone Text Messge service.  You'd need to use the carrier's 
> email-text gateways, but both are inherently short-message based, so 
> this should be quite effective if done right.
>
> The biggest issue for both my preference and yours is the scarcity of 
> bi-directional iGates.  Still useful for the "arrived safely" 
> messages, but not what I would like.  Unfortunately, this is not a 
> software problem...
>
> Greg  KO6TH
>
>
>
> On Sun, Apr 8, 2012 at 10:24 AM, John Goerzen <jgoerzen at complete.org 
> <mailto:jgoerzen at complete.org>> wrote:
>
>     Hi folks,
>
>     I am looking to write some APRS software, and I'm hoping to avoid
>     re-inventing the wheel.  I am particularly interested in libraries
>     in any cross-platform language (C, Perl, Python, Java, etc.) that
>     can be used to receive and generate APRS messages.
>
>     In my research, there are quite a few libraries that receive APRS
>     messages, but I have found none that are helpful with generating
>     them.  This seems to be something with some complexity; such as:
>
>         * Splitting data up into packets of the appropriate size
>           (APRSLink for Winlink appears to somehow detect the type of
>           device in use and generates shorter messages for TH-D7A. 
>           Anyone know how to do this, and what are the appropriate
>           sizes for the D7A, D72A, 710, and VX-8GR?)
>         * Processing/generating ACKs, REJs, etc.
>         * Proper timing for retransmit of packets that weren't ACKed.
>
>     None of this is hugely complicated, and the APRS spec is fairly
>     clear on the ACK, REJ, etc. process.  The maximum message sizes
>     appear to be undocumented and I'm hoping someone can help me out
>     there.
>
>     My project, incidentally, is to build a bidirectional APRS-XMPP
>     bridge.  XMPP is the protocol behind the instant messaging tools
>     such as Jabber and Google Talk, and is available for free on every
>     modern platform.  In the spirit of both amateur radio and the Free
>     Software communities I'm a part of, full source code to this
>     project will be available.  I actually already wrote a much
>     simpler piece of related software, letting someone take a
>     connected AX.25 session and bridge it to XMPP, [1] so I do have
>     some experience under my belt.  This is obviously a more complex
>     project, but XMPP looks like an excellent way to bridge APRS to
>     other systems.  I think it is a better fit than the email gateways
>     out there, and in fact, XMPP already has fields for carrying
>     presence information and location information with presence packets.
>
>     Are there any particular notes available to those implementing
>     gateways between APRS and non-APRS sources?  I have taken note of
>     what sites such as OpenAPRS or Winlink do to validate people for
>     access, and plan to do something similar here.
>
>     Thanks,
>
>     -- John
>     KR0L
>
>     [1] source code at https://github.com/jgoerzen/ax25xmpp
>
>
>     _______________________________________________
>     aprssig mailing list
>     aprssig at tapr.org <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20120408/e2623bc0/attachment.html>