<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Hello, Robert.<br><br>With all due respect, I had no intention of breaking backwards compatibility of the _existing_ messages for announcing to end-user radios where the gateways were. My suggestion (however clumsily stated) was for an additional (not a replacement) message routed _only_ over the Internet from the gateways (IRLP, Echolink, Allstar, whatever) to the AVRS server to timely report state changes in the operational state of and virtual circuits between gateways, as an alternative to awkward and high-latency polling of gateway status by the AVRS server. Certainly, what we have works nicely for the end-users, but it seems awkward and inefficient to keep the AVRS server up-to-date by it having to repeatedly poll for "have you changed yet?" reports from every gateway on the planet (or proxy servers that do the same job) when the AVRS server could be notified asynchronously and immediately of each gateway's state changes. Plus, the AVRS server has no RF connectivity of its own, so it is only going to find out about gateway status over the Internet anyway.<br><br>Now, this may be impractical, from what others have said regarding what it would take to make appropriate tweaks to the various voice networks' gateway software. However, assuming the software changes are possible, it would behave no differently than existing Internet network management protocols (such as SNMP) reporting node state changes to a central server that monitors the state of remote network nodes, and would not clog the airwaves with spurious messages because these messages would not be sent over the air. Furthermore, it would actually make AVRS more reliable, because it would be working with current information, not stale data from the last poll. The only issue with this suggestion is getting the gateways to play along (and I admit that might be a deathknell to my proposal).<br><br>Now, if the existing RF beacon messages also contain all the virtual voice circuit establishment and teardown information (due to promptly-updated beacon transmissions when the virtual circuits are opened and closed), then my suggestion is unneeded, and so is the AVRS server's polling; the AVRS server could merely monitor APRS-IS for those messages to keep its gateway database up-to-date. If the existing messages do _not_ contain all of this additional information, then obviously the AVRS server needs the missing data from somewhere (and earlier messages in this e-mail thread imply the AVRS server gets it by polling for dynamically-updated XML files from specified proxy servers on the Internet).<br><br>So please don't take my suggestion as an attempt to break what you've been coordinating for the last decade, because that was very carefully and deliberately _not_ my intent. It was merely an idea for a possibly more efficient way of doing AVRS.<br><br>Andrew Pavlin, KA2DDO<br><br><div><div id="SkyDrivePlaceholder"></div>> From: bruninga@usna.edu<br>> Date: Mon, 17 Sep 2012 22:13:12 -0400<br>> To: aprssig@tapr.org<br>> Subject: Re: [aprssig] Automatic Voice RFelay System (AVRS) and ALLSTAR STANDARD<br>> <br>> > Perhaps a new APRS message could be defined specifically<br>> > to beacon such gateways with the relevant parameters<br>> > (most of which are in the standard position message anyway).<br>> <br>> Not only *no* but "heck no"!!!<br>> <br>> We have tens of thousands of mobiles out there with a perfectly good APRS<br>> radio that can already display ALL relevant VOIP information to the mobile<br>> operator. The format is an APRS FREQUENCY OBJECT. Then not only do the<br>> radios display the information, but they can also TUNE to that VOIP node<br>> with the press of a single TUNE or QSY button.<br>> <br>> This FREQUENCY OBJECT has been the #1 focus of APRS since 2001 and<br>> finalized in the spec since 2004, and built into all new radios since<br>> 2007?<br>> <br>> Do not even think of "inventing" a new format when we have already gotten<br>> every player in this game (the APRS standard, and the APRS radio<br>> manufacturers producing radios) coming on board, with the AVRS engine, the<br>> last piece of the pie, being the most critical link.<br>> <br>> The format has been well defined since 2004. It is a FREQUENCY object.<br>> Please do not throw away almost a decade of work, with knee jerk ideas.<br>> <br>> Thanks<br>> Bob, WB4APR<br>> <br>> ------Original Message------<br>> From: Bill Vodall<br>> To: aprssig@tapr.org<br>> Sent: Sep 17, 2012 1:49 PM<br>> Subject: Re: [aprssig] Automatic Voice RFelay System (AVRS) and ALLSTAR<br>> <br>> <br>> > I.e. I need callsign, node number, lat/lon of node, RF characteristics<br>> > (freq/offset/tone), and status (connected, listening, down, etc)<br>> > Given that data I can poll it, update a local DB, map the nodes, and<br>> make<br>> > AllStar part of the AVRS protocol.<br>> <br>> Will this info be generally available on the APRS-IS so we can easily<br>> bring it to the RF domain without doing Internet magic... (Yes - I<br>> know APRS-IS == Internet but there is a subtle difference...)<br>> <br>> 73<br>> Bill - WA7NWP<br>> <br>> _______________________________________________<br>> aprssig mailing list<br>> aprssig@tapr.org<br>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig<br>> <br>> <br>> Sent from my Verizon Wireless BlackBerry<br>> <br>> _______________________________________________<br>> aprssig mailing list<br>> aprssig@tapr.org<br>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig<br>> <br>> _______________________________________________<br>> aprssig mailing list<br>> aprssig@tapr.org<br>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig<br></div> </div></body>
</html>