EXCELLENT!!

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).

But I really appreciate you adding this change as I could see a benefit to being able to control outbound traffic as such.

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...

Thanks again - I'll grab the update shortly.

73

- Jeremy, KD0EAV

On 07/31/11 15:44, Jim Duuuude wrote:
okay Kyle... we'll keep you all happy n stuff... :-)

What I did to attempt to address both of these needs is add a
parameter in each node stanza in 'rpt.conf', called
'eloutbound'. If, in rpt.conf for a particular node, you
specify 'eloutbound=el1', *that* node will make its
outbound echolink connections through el1. Any/other
nodes that do not have 'eloutbound' specified will do
the default thing (use el0). This is available in the
app_rpt.c that will be publically accessible when the
SVN updates at 14:15 PDT today.

JIM WB6NIL


> From: yokshs@sbcglobal.net
> To: app_rpt-users@ohnosec.org
> Date: Sun, 31 Jul 2011 15:21:46 -0500
> Subject: Re: [App_rpt-users] Multiple Echolink Nodes
>
> > Secondly, *all* outbound connections from app_rpt originate from el0.
>
> This works beautifully for my purposes. I have 2 RF nodes and a hub node
> here.. To provide Echolink functionality for both nodes, I have Echolink
> connected to the hub node (2210). Outbound connections from either RF node
> work seamlessly.
>
> Inbound Echolink calls hit the hub node only, unless a RF node is
> specifically connected to the hub node. I'm able to avoid the Echolink
> "drive-by" connect/disconnects in this way.
>
> I can understand others wanting a different configuration, such as the
> multiple IP setup that Jeremy described, but hopefully the current
> configuration will also remain? Please don't "fix" this! hi hi
>
> 73.
>
> Kyle
> K0KN
>
>
> --- Original Message ---
>
> ok.. first of all, echolink protocol requires a one-on-one correspondence
> between node number
> and public IP address. The "multiple instance" architecture of chan_echolink
> is only for systems
> that have multiple public IP addresses on them.
>
> Secondly, *all* outbound connections from app_rpt originate from el0.
>
> JIM WB6NIL
>
>
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users@ohnosec.org
> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users