Interfacing AllStar node to existing system over LAN
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. 73 de VK3JED / VK3IRL http://vkradio.com
Tony Langdon, VK3JED wrote:
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.
73 de VK3JED / VK3IRL http://vkradio.com
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
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. Steve WA6ZFT
At 09:39 AM 4/12/2010, Stephen Rodgers wrote:
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. :) 73 de VK3JED / VK3IRL http://vkradio.com
Tony Langdon, VK3JED wrote:
At 09:39 AM 4/12/2010, Stephen Rodgers wrote:
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. :)
73 de VK3JED / VK3IRL http://vkradio.com
_______________________________________________ App_rpt-users mailing list App_rpt-users@qrvc.com http://qrvc.com/mailman/listinfo/app_rpt-users
Some clues: radios*CLI> help rpt fun Usage: rpt fun <nodename> <command> Send a DTMF function to a node -- 49 - Disable incoming connections (control state noice) 50 - Enable incoming connections (control state noicd) -- 987149=cop,49 ; Incoming connection disable 987150=cop,50 ; Incoming connection enable -- [root@radios ~]# asterisk -rx "rpt fun 2010 *987150" -- See http://app-rpt.qrvc.com/node/42 Steve WA6ZFT
At 02:06 PM 4/12/2010, Stephen Rodgers wrote:
Some clues:
radios*CLI> help rpt fun Usage: rpt fun <nodename> <command> Send a DTMF function to a node
Thanks, I'll give that a shot, looks like this is exactly what I'm looking for. :) 73 de VK3JED / VK3IRL http://vkradio.com
At 09:39 AM 4/12/2010, Stephen Rodgers wrote:
1. There are optional scripts which can be called on connect and disconnect events take a look in app_rpt.c
Just took a quick look. My only problem is not being a C programmer, what do I look for in the 21,000 lines of code? ;) 73 de VK3JED / VK3IRL http://vkradio.com
participants (2)
-
Stephen Rodgers -
Tony Langdon, VK3JED