functionality for radio-oriented Asterisk channels.
The idea here is that certain radio applications lend themselves
to needing a "generic" (passes audio and tx/rx keying completely
transparently) to and from two or more endpoints.
An example of such an appication might be replacing (or providing
equivlent new functionaliy of) one or more full-duplex UHF control
links with an IP-based one(s).
app_radbridge allows multiple instances of radio-oriented channels
transparently "bridged" together.
The config file (radbridge.conf) allows specification of each
"bridging" instance and what radio-oriented Asterisk channels
are to be associated with it. There is no need for any other
specificaiton of configuration.
The file format for radbridge.conf departs somewhat from the standard
usage (at least for radio stuff) of the Asterisk config file architecture.
In most other radio-oriented cases, an instance of whatever it is
gets defined as a "Stanza" in the config file. In this case, because
of limitations in the way that Asterisk parses config files, that
was not possible. Instead, all config information goes into the
[general] stanza, and each line of config info defines a different
instance of radio bridging. For example:
[general]
instance1 = Voter/1234,Radio/5678
instance2 = Voter/1235,Radio/5679
This example would define two radio bridging instances "instance1"
and "instance2", each with 2 channels associated with them.
The supported channel types are "Voter" (chan_voter), "Radio"
(chan_usbradio), "SimpleUsb" (chan_simpleusb), and "Zap" ("Dahdi")
(chan_dahdi, for the couple of devices that use this channel
driver, such as the PCIRadio card, and separate analog channels
using an ARIB board or such).
Rather then "adding" (which would actually be a lot of *removing*
optionally) this functionality in app_rpt, it made more sense to
create a separate application specifically for this purpose. In
addition, this allows for a system that is merely provided for
doing this bridging application and nothing else radio-oriented,
to not have to run app_rpt at all.
*/
So as it stands I have a one node system. I have another URI on the way and will have BBB soon. The eventual plan is to have a few repeaters and some simplex nodes at people's houses for RF hot spot access.
What is the best way to tie these together? I understand you can set permanent links that will reestablish connection if lost.
Is there other ways of accomplishing this? I only ask because I have my one node setup with email, autopatch and all other kinds of bells and whistles. I'd like to be able to do all of this from other RF locations and I wonder if I need to just set each node up accordingly or can one node be the workhorse and the other nodes just be dumb connections.
Did I make any sense with that question?
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button"
You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.