<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    EXCELLENT!!<br>
    <br>
    I was actually okay with the default behaviour - I was just using
    this as a bridge into an Echolink conference, so I just initiated
    the link from the conference server... which actually works even
    better because then I don't have to register (and burn) one of my
    Echolink numbers for the link - I have Asterisk (chan_echolink)
    listening on the second IP (el1) and just have the conference server
    connect to that IP address - no registration required (both handy
    and insecure). <br>
    <br>
    But I really appreciate you adding this change as I could see a
    benefit to being able to control outbound traffic as such.<br>
    <br>
    In regards to the Echolink channel driver, it works exceptionally
    well. There are really only a few "issues" that I think keep it from
    taking over in the roll of an Echolink conference - the primary is
    the lack of the "chat" feature. I've looked over the chan_echolink
    driver; but don't know enough about the echolink "protocol" to make
    any sort of educated attempt at adding that feature. I have noted,
    that Asterisk has it's own messaging system (of what complexity I
    have no idea); but it would be nice if the Echolink driver could put
    chat messages on that stack - then I could see all the chats on my
    SIP phone, just like we see all of the node connect/disconnect
    messages. That's really the only show stopper...  just a thought -
    things are working great as-is right now...<br>
    <br>
    Thanks again - I'll grab the update shortly.<br>
    <br>
    73<br>
    <br>
    - Jeremy, KD0EAV<br>
    <br>
    On 07/31/11 15:44, Jim Duuuude wrote:
    <blockquote cite="mid:BLU155-W8999FC7A17886709068C6B1390@phx.gbl"
      type="cite">
      <style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
      <div dir="ltr">
        okay Kyle... we'll keep you all happy n stuff... :-)<br>
        <br>
        What I did to attempt to address both of these needs is add a <br>
        parameter in each node stanza in 'rpt.conf', called<br>
        'eloutbound'. If, in rpt.conf for a particular node, you<br>
        specify 'eloutbound=el1', *that* node will make its<br>
        outbound echolink connections through el1. Any/other<br>
        nodes that do not have 'eloutbound' specified will do<br>
        the default thing (use el0). This is available in the<br>
        app_rpt.c that will be publically accessible when the<br>
        SVN updates at 14:15 PDT today.<br>
        <br>
        JIM WB6NIL<br>
        <br>
        <br>
        <div>> From: <a class="moz-txt-link-abbreviated" href="mailto:yokshs@sbcglobal.net">yokshs@sbcglobal.net</a><br>
          > To: <a class="moz-txt-link-abbreviated" href="mailto:app_rpt-users@ohnosec.org">app_rpt-users@ohnosec.org</a><br>
          > Date: Sun, 31 Jul 2011 15:21:46 -0500<br>
          > Subject: Re: [App_rpt-users] Multiple Echolink Nodes<br>
          > <br>
          > > Secondly, *all* outbound connections from app_rpt
          originate from el0.<br>
          > <br>
          > This works beautifully for my purposes. I have 2 RF nodes
          and a hub node <br>
          > here.. To provide Echolink functionality for both nodes,
          I have Echolink <br>
          > connected to the hub node (2210). Outbound connections
          from either RF node <br>
          > work seamlessly.<br>
          > <br>
          > Inbound Echolink calls hit the hub node only, unless a RF
          node is <br>
          > specifically connected to the hub node. I'm able to avoid
          the Echolink <br>
          > "drive-by" connect/disconnects in this way.<br>
          > <br>
          > I can understand others wanting a different
          configuration, such as the <br>
          > multiple IP setup that Jeremy described, but hopefully
          the current <br>
          > configuration will also remain? Please don't "fix" this!
          hi hi<br>
          > <br>
          > 73.<br>
          > <br>
          > Kyle<br>
          > K0KN<br>
          > <br>
          > <br>
          > --- Original Message ---<br>
          > <br>
          > ok.. first of all, echolink protocol requires a
          one-on-one correspondence <br>
          > between node number<br>
          > and public IP address. The "multiple instance"
          architecture of chan_echolink <br>
          > is only for systems<br>
          > that have multiple public IP addresses on them.<br>
          > <br>
          > Secondly, *all* outbound connections from app_rpt
          originate from el0.<br>
          > <br>
          > JIM WB6NIL<br>
          > <br>
          > <br>
          > <br>
          > _______________________________________________<br>
          > App_rpt-users mailing list<br>
          > <a class="moz-txt-link-abbreviated" href="mailto:App_rpt-users@ohnosec.org">App_rpt-users@ohnosec.org</a><br>
          > <a class="moz-txt-link-freetext" href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a><br>
        </div>
      </div>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
App_rpt-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:App_rpt-users@ohnosec.org">App_rpt-users@ohnosec.org</a>
<a class="moz-txt-link-freetext" href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a>
</pre>
    </blockquote>
  </body>
</html>