<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 12/2/2013 8:17 PM, Lee Bengston
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAPF_JSJVpyX+zZESt+MbmuHG9cCZsE8ZwB5MdhUAUpY-zbhpTA@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <br>
            </blockquote>
            <div class="gmail_default"
              style="font-family:verdana,sans-serif;font-size:small">Yes,
              the heard list should give the IGate the necessary
              packets, but what about the ability of the IGate to
              determine if a station heard on RF is also directly
              connected to the Internet/APRS-IS?  With no range filter
              (or a very small range filter), wouldn't that create the
              possibility of gating a message via RF addressed to a
              station heard on RF that is also connected to the
              Internet?  Or would the IS server take care of this by not
              sending the message to IGates that have gated RF beacons
              from the message recipient - instead only send the message
              to the addressee?</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    The APRS-IS server(s) not only send messages addressed to the heard
    list stations, but also any posits for those heard stations as
    well.  This allows the IGate to determine #4 in (from
    <a class="moz-txt-link-freetext" href="http://www.aprs-is.net/IGateDetails.aspx">http://www.aprs-is.net/IGateDetails.aspx</a>, emphasis mine):<br>
    <br>
    <blockquote type="cite">
      <p> Gate message packets and associated posits to RF if all of the
        following are true: </p>
      <ol>
        <li>the receiving station has been heard within range within a
          predefined time period (range defined as digi hops, distance,
          or both). </li>
        <li>the sending station has not been heard via RF within a
          predefined time period (packets gated from the Internet by
          other stations are excluded from this test). </li>
        <li>the sending station does not have TCPXX, NOGATE, or RFONLY
          in the header. </li>
        <li>the receiving station has<b> not </b>been heard via the
          Internet within a predefined time period.<br>
          A station is said to be heard via the Internet if <b>packets
            from the station contain TCPIP* or TCPXX* in the header</b>
          or if gated (3rd-party) packets are seen on RF gated by the
          station and containing TCPIP or TCPXX in the 3rd-party header
          (in other words, the station is seen on RF as being an IGate).
        </li>
      </ol>
    </blockquote>
    <br>
    To provide for the determination of #4, my understanding (and
    observation) is that the APRS-IS servers forward any packets sourced
    by the heard stations to the IGate client on the filter port.  This
    is why IGates with no filters will STILL receive packets from the
    APRS-IS that are NOT intended to be transmitted to RF, but provide
    visibility for the IGate to make local gating decisions.<br>
    <br>
    There's (at least) one IGate implementation out there (don't
    remember which one) that blindly transmits 3rd party packets via RF
    for every packet received from the APRS-IS server.  In my
    understanding, this is not proper as the APRS-IS servers forward
    information-providing packets not intended for transmission, but
    instead rely on local IGate intelligence to determine which packets
    should actually be gated from -IS to RF.<br>
    <br>
    Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br>
    <br>
    <br>
    Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br>
    <br>
  </body>
</html>