[aprssig] APRS-IS and I-gating

[Lynn W. Deffenbaugh (Mr)]

On 11/5/2016 1:51 AM, Kenneth Finnegan wrote:
> I haven't been following the thread on the Direwolf list very closely, 
> but if this blanket RF-gate everything behavior is default for 
> Direwolf, that is VERY concerning and arguably incorrect.

Novice IGate implementors often have the mis-understanding that the 
APRS-IS server is responsible for deciding what the IGate should gate 
back to RF.  That is completely wrong as is pointed out in this thread.  
The APRS-IS servers will typically provide packets that the IGate MIGHT 
be interested in.  The IGate software itself is responsible for the 
final decision.

APRSISCE/32 by default only gates from -IS to RF packets matching the 
following criteria:

1) Messages addressed to stations received from RF within the past 30 
minutes
     a) But not if the addressee was also heard on the APRS-IS
     b) Not if the addressee was heard with more than 2 hops used
2) The next posit from message source stations that had a message gated 
to RF via (1)
     a) But not if that source station was heard on RF

Stations further are not considered "heard on RF" if they had NOGATE or 
RFONLY anywhere in their path.

The APRS-IS server will typically provide a LOT more packets than the 
criteria above.  Most interesting is the fact that an IGate will receive 
all packets for stations that were "recently" (typically 30 minutes) 
gated from RF to the APRS-IS.  This means that if your IGate copies a 
single packet station that is transmitting on RF and the APRS-IS, then 
you will receive ALL packets generated by that station for the next 30 
minutes.  Obviously these packets are NOT intended to be transmitted on 
RF but are provided to SUPPRESS further RF transmissions by providing 
the IGate visibility to the APRS-IS-connectedness (or not) of the 
originally gated station.

Additionally, posits from stations which generated messages addressed to 
gated stations will continue to be provided for some time after the 
message packet.  Again, this is to provide the IGate with the ability to 
intelligently decide whether or not to forward these to RF to provide 
information to the recipient of the message. Again, "good" (whatever 
that means to you) IGate software won't forward all of these packets to 
RF, but only enough to be relatively certain that the message recipient 
received the information.

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