I'm in the process of resurrecting my AllStar node, which has been down for an extended period of time. I have installed ACID and put my old registration data into the setup script. The system is showing as registered on the allstar.org status page, so it looks like that phase has worked.
Now, the next (and more difficult phase) comes. For a variety of technical and cosmetic reasons, I would like to interface the AllStar system to a highly modified EchoIRLP node (it runs thelinkbox in a unique configuration), and have the EchoIRLP node and the AllStar node share status information, so I can implement interlocks (i.e. when IRLP or Echolink is busy, lock out AllStar, and vice-versa). While I can hack this on thelinkbox side, by de-linking the AllStar port (in tlb) when there's other traffic, this is an ugly hack that puts AllStar at a major disadvantage.
What I need to know are:
1. Is there any event that is generated when an AllStar node connects or disconnects, that can be used to call an external shell script?
2. Is it possible to set an AllStar node as "busy" on the fly?
3. Can chan_irlp or chan_echolink be used to make outbound connections without being a part of the IRLP or Echolink networks respectively? I'd need to use one of these methods to make the audio link across the LAN. The old chan_rtpdir was quite good for this style of operation, though it was GSM only. Running app_rpt on the same machine is not feasible at this time. It has been tried in the past and caused major grief - need some serious hardware upgrades, but that in turn needs some planning.
Also, if I can resolve (1) and (2), this would go a _long_ way to making app_rpt/AllStar more acceptable to the IRLP community, by bringing it into line with IRLP policies. I feel this would in turn be a good thing for app_rpt and AllStar overall.
I'm in the process of resurrecting my AllStar node, which has been
down for an extended period of time. I have installed ACID and put
my old registration data into the setup script. The system is
showing as registered on the allstar.org status page, so it looks
like that phase has worked.
Now, the next (and more difficult phase) comes. For a variety of
technical and cosmetic reasons, I would like to interface the AllStar
system to a highly modified EchoIRLP node (it runs thelinkbox in a
unique configuration), and have the EchoIRLP node and the AllStar
node share status information, so I can implement interlocks (i.e.
when IRLP or Echolink is busy, lock out AllStar, and
vice-versa). While I can hack this on thelinkbox side, by de-linking
the AllStar port (in tlb) when there's other traffic, this is an ugly
hack that puts AllStar at a major disadvantage.
What I need to know are:
1. Is there any event that is generated when an AllStar node
connects or disconnects, that can be used to call an external shell script?
2. Is it possible to set an AllStar node as "busy" on the fly?
3. Can chan_irlp or chan_echolink be used to make outbound
connections without being a part of the IRLP or Echolink networks
respectively? I'd need to use one of these methods to make the audio
link across the LAN. The old chan_rtpdir was quite good for this
style of operation, though it was GSM only. Running app_rpt on the
same machine is not feasible at this time. It has been tried in the
past and caused major grief - need some serious hardware upgrades,
but that in turn needs some planning.
Also, if I can resolve (1) and (2), this would go a _long_ way to
making app_rpt/AllStar more acceptable to the IRLP community, by
bringing it into line with IRLP policies. I feel this would in turn
be a good thing for app_rpt and AllStar overall.
1. There are optional scripts which can be called on connect and disconnect events take a look in app_rpt.c
2. Yes, using "asterisk -rx rpt fun node ...." and the appropriate COP mapping to prohibit incoming connections.
3. chan_irlp and chan_echolink are made to interact with the appropriate protocols. Modifying chan_rtpdir to make a
transparent driver ala chan_thelinkbox is probably the best way to so move forward, but I'm no expert with channel
drivers, that's a question/request for Jim, WB6NIL.
1. There are optional scripts which can be called on connect and disconnect events take a look in app_rpt.c
Thanks, I'll take a look. I'm no C programmer, but I have a good chance of identifying the calls.
2. Yes, using "asterisk -rx rpt fun node ...." and the appropriate COP mapping to prohibit incoming connections.
OK, this I will need some more help/documentation on. In any case, it looks like the cross system lockouts are possible, so we could make Asterisk compliant with IRLP guidelines, with a bit of work.
3. chan_irlp and chan_echolink are made to interact with the appropriate protocols. Modifying chan_rtpdir to make a
transparent driver ala chan_thelinkbox is probably the best way to so move forward, but I'm no expert with channel
drivers, that's a question/request for Jim, WB6NIL.
Well, thelinkbox still supports chan_rtpdir (v 0.5, I think), so hopefully Jim will consider working with Skip on updating chan_rtpdir support to the new "chan_tlb". Needless to say, I'm putting my hand up to beta test it! You've confirmed my suspicion that full protocol support is required for the IRLP and Echolink channel drivers to work, and that resurrecting chan_rtpdir is the way to go for point to point links between thelinkbox and app_rpt.
The rest is just hacking with the pieces provided, which I'm no stranger to.
Anyway, thanks for your help Steve, you've given me a lot to work with. Hopefully Jim will pick up on this thread as well.
1. There are optional scripts which can be called on connect and
disconnect events take a look in app_rpt.c
Thanks, I'll take a look. I'm no C programmer, but I have a good
chance of identifying the calls.
2. Yes, using "asterisk -rx rpt fun node ...." and the appropriate
COP mapping to prohibit incoming connections.
OK, this I will need some more help/documentation on. In any
case, it looks like the cross system lockouts are possible, so we
could make Asterisk compliant with IRLP guidelines, with a bit of work.
3. chan_irlp and chan_echolink are made to interact with the
appropriate protocols. Modifying chan_rtpdir to make a
transparent driver ala chan_thelinkbox is probably the best way to
so move forward, but I'm no expert with channel
drivers, that's a question/request for Jim, WB6NIL.
Well, thelinkbox still supports chan_rtpdir (v 0.5, I think), so
hopefully Jim will consider working with Skip on updating chan_rtpdir
support to the new "chan_tlb". Needless to say, I'm putting my hand
up to beta test it! You've confirmed my suspicion that full
protocol support is required for the IRLP and Echolink channel
drivers to work, and that resurrecting chan_rtpdir is the way to go
for point to point links between thelinkbox and app_rpt.
The rest is just hacking with the pieces provided, which I'm no
stranger to.
Anyway, thanks for your help Steve, you've given me a lot to work
with. Hopefully Jim will pick up on this thread as well.
In any case, it looks like the cross system lockouts are possible, so we could make Asterisk compliant with IRLP guidelines, with a bit of work.