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.
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.
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
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.
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
Any chance of a allstar client (mobile/PC) that could be java based for PC? That way we can get away from the echolink client?
Leon
···
Sent from my iPhone
On Jul 31, 2011, at 4:44 PM, Jim Duuuude <telesistant@hotmail.com> 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
> ohnosec.org
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org ohnosec.org
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.
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
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.
As usual, the service here is amazing! Thanks, Jim!
···
----- Original Message ----- From: Jim Duuuude To: yokshs@sbcglobal.net ; app_rpt mailing list Sent: Sunday, July 31, 2011 3:44 PM
Subject: RE: [App_rpt-users] Multiple Echolink Nodes
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.
