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