The future of two way radio is digital.

As of writing, TV broadcasters in the other areas of spectrum are required to be full digital and shut down their analog transmitters in Feb. 2009.  The only spectrum broadcasters are required to vacate are channels 64 thru 69 that will become the new "700 MHZ band" that is being auctioned off by the FCC.  The vacated areas of this spectrum will be utilized for: Public Wireless deployment (Cellular/PCS); A wide-band private data network that will be shared between public safety and paying customers; and new spectrum for public safety that will butt right up to the re-located NPSPAC National Public Safety Planning Advisory Committee band being moved to 806-809/851-853 by Sprint/NEXTEL.  All non-public safety stations to operate on channels with a bandwidth of 12.5 kHz or less beginning January 13, 2013. Until 2013 (maybe), public safety users may continue to use 25 (wide band) kHz equipment. Phase 2, which becomes mandatory (maybe) in 2018 would require radios capable of operating at 6.25 kHz. (Digital Non-analog FM). The future of two way radio is digital, and we must also advance in this direction. The digital premise is that it generally allows more use in a more efficient/flexible use of band space.

Initially there seemed to be two full blow approaches for ham radio.  APCO-25 and D-Star.  There is controversy over which one should become mainstream.  One of the major down falls in my mind with the D-Star is that the D-Star repeaters such as the ICOM ID-RP4000V for VHF is that it's Not reverse compatible with existing analog FM.  It only supports D-Star digital voice.  Where as a P-25 repeater system can be configured to repeat analog FM and P-25 digital voice.   If public safety uses APCO-25, and we are supposed to be interoperate with or assist them at times of emergency wouldn't this be easier if we were also supporting APCO-25?  Audio of P25 systems is reported as better quality.   The D-Star architecture is open and offers the greatest flexibility to hams.  The IMBE codec used on P25 is not sold in small quantity chip solutions, where the AMBE codec for D-Star is.   Mototrbo, yet another digital variant, not only interoperates with digital and analog, but can support two simultaneous conversations, but the protocol is probably the most locked down.

There is now a new digital system called NXDN digital (aka Kenwood NEXEDGE, Icom IDAS).  Reports are that it really does a fine job, sounds better than Mototrbo and P25 Phase 1 Digital.   It really looks quite promising, cost wise as well.  Nexedge / Idas repeaters like P25 systems are also capable of mixed mode, reverse compatible with existing analog FM. 

There are a few open source D-Star software and hardware projects that showed up in 2007.  A completely home brew hardware and software 2-meter D-STAR radio was demonstrated at Dayton 2007 as well as the makings of a controller (full decoding of hardware handshake with the Icom repeaters and line protocols for the repeater - controller - gateway connections).

Looks like part of the reverse engineering of the D-Star protocol started with Moe, AE4JY, see his Digital Voice Transceiver Project.  Also see some of his notes.

Here Satoshi Yasuda, 7M3TJZ/AD6GZ took the UT-118 digital voice module and adapted it to work on any radio with a packet port.

A couple other good resources are; http://opendstar.org and the Texas Interconnect Teams forums.

These are all good, because the show an interest in D-Star to other vendors and manufactures.  As of writing Icom is the only manufacture selling D-Star capable radios in the US.  There are rumors that in Japan, Kenwood has a rebadged Icom on the market.  A bit of competition could help bring the price down and further the innovation of further advancements and features.

VOIP applications and ham radio

Most present day government communication centers that use analog systems happen to have a VOIP based dispatch console.  Many remote sites are tied together using over fiber.  This analog to VOIP patching is something that we are presently also embracing in ham radio with IRLP, EchoLink, Yeasu WIRES II, and the like.  (See VoIP and Amateur Radio overview By Steve Ford, WB8IMY from QST Feb 2003)

A different hardware board for each of these proprietary VOIP systems that you want to support is required.  You also need a need a multi-port repeater controller, to support each hardware boards analog breakout. This seems redundant to me, and is something that slows the advancement.  IRLP seems to be the system of choice because it runs on the Linux operating system.  This is because Linux is much more stable that Windows, and is an open source development.

Background look at Open source/protocol and ham radio

While IRLP holds promise, a large part of the hold up on outside and additional developments for IRLP seems to be related to the fact that parts of the IRLP system (the binaries that talk to his hardware board) are not open source.  This to me doesn't seem to be in the true spirit of amateur radio.  I also read rumors (July 06) that the IRLP system designer (David Cameron, VE3LTD) had developed a similar system to IRLP that is being used commercially, and this to may be part of his proprietary design reasoning.  Another reason the board design is unpublished is that the board is the IRLP designers only source of funding to keep things alive.  Also to cut down on the number of questions/problems from the non-technical savvy.  While neither of these are bad, it still doesn't let technical savvy people do much more than talk over the network.  I & others could be developing and contributing ideas though experimentation. 

IRLP started in 1997 with Windows and VocalTec's iPhone and a WB2REM interface.  David, VE3LTD realized in 6 months time that iPhone was not very stable nor is it controllable.  He also ran into a road black when source code for iPhone was not available.  David looked for an alternative, and he started getting into using Linux as an operating system and Speak Freely as a client/server.  SpeakFreely was open source and he was able modify the source code to his liking to create what we now have today for IRLP.  He then designed his own hardware board for PTT & COR logic.

EchoLink natively runs on the Windows operating system and was developed by Johnathan, K1RFD, released in 2002..    He approached this whole concept initially with a view to improving a system then running called "iLINK" (The iLINK system, first appeared around May 2001, was developed by Graeme Barnes, M0CSH, in Kent England), which was an enhanced development from a voip system called IPhone, as was IRLP. But read on.

Initially "Echolink" was un-named, but Johnathan K1RFD, and David, G3VFP started development  to provide an alternative graphical user front end to what was then the "iLINK" voip ham system,  sometime in late 2001, or early 2002.  Unfortunately through no fault of Jonathans, as he tried hard over quite a few months to communicate, with the owner of iLINK. It proved a near  impossibility, and reputedly it was stated by the author of iLINK that no third party software would be allowed on iLINK.  So Jonathan decided to form another peer to peer voip system completely, using his graphical interface. Which by the way was years ahead of the iLINK  GUI.

Open source versions of the EchoLink software are available for Macintosh (EchoMac) and Linux (echoLinux aka CQiNet or SvxLink/Qtel), but they may have limited features compared to the Windows version. At least when comparing the desktop applications.

CQiNet provides "theBridge", which is code that allows one to talk to EchoLink network from Linux or a Mac platform.  The primary purpose is to use the Internet to link Ham repeaters with a secondary purpose of providing remote access for users.   CQiNet is a family of programs that combine Ham Radio with the Internet using Voice over IP (VoIP) technology. Two programs are currently in the family, "theBridge" and echoLinux.  Thebridge is a iLink/EchoLink compatable conference bridge that runs under various versions of Unix as well as Windows EchoLinux is a EchoLink client program for the Linux operating system.  Compatibility with EchoLink and IRLP is a goal.  

Johnathan, K1RFD tolerates thebridge and EchoIRLP partly because he does not sell EchoLink or any boards that are needed to make it work. Since Dave, VE3LTD derives income from IRLP it should not be surprising that he's less tolerant.

While IRLP is not 100% open, some clever people working with David Cameron, the IRLP system designer have managed to adapt theBridge so that one can have the inter-operability of EchoLink and IRLP using the IRLP hardware.  This is called EchoIRLP.   Both networks are capable of GSM audio compression (standard for EchoLink and is an option for IRLP as it normally uses ADPCM), and the transport protocols are quite similar. 

 In this case, those who worked with David, worked out the details where the IRLP binaries are talking to The Bridge which is in turn talks to the Echolink network.  

The iLink protocols (the basis of EchoIRLP) were reverse engineered by Tom, WD4NMQ and Skip, WB6YMH without the author of iLINK Graeme, M0CSH (G7BHM) blessing. Without reverse engineering there would be no EchoIRLP.

Taking this one step forward, Svxlink is another step in the right direction.  The Svxlink project allows configuration a variety of existing  economical radio to PC interfaces, such as the VA3TO interface.  What's notable about Svxlink is they have a schematic also released under the GPL so one can homebrew their own radio to PC interface.

Imagine how smoothly and fast things would have unfolded if everything was open source, and no one had to waste time reverse engineering other peoples secrets.

The ARRL made a Interoperability statement in October 2007.  This is a pretty serious issue as there a number of proprietary digital voice radio systems out there.  None of them natively talk to each other.

There are some keys to consider when it comes to interoperability.  The lowest common denominator (aside from frequency) would seem to be the modulation type. D-Star is GMSK, APCO-25 and pretty much everything else is 4FSK modulation.  Upon that you have a MAC layer level access protocol, then the actual codec converting the voice to digital.  Electronics is so PIC/chip based, modulation changes can be changed without necessarily changing components.

As long as there is a hardware common ground modulation type or ability to speak/receive multiple types (like they did with 802.11b & g - DSSS/OFDM), firmware should be able to be written to take care of any MAC layer differences.  Transcoding can take care of the differences between the various codecs.   This is where a platform like Asterisk shines.

One Step Further - Asterisk & Ham Radio

Asterisk is an Open Source PBX & Telephony Platform. It’s often labeled as the future of telephony.

In my case, ham radio first introduced me to VOIP, with Echolink and IRLP in the late 90's. Since that time, I've been playing with Asterisk.  Asterisk is some very powerful stuff, perfect anyone who is familiar with Linux and likes to tinker.  

I have a 2.4 GHz ZyXel WiFi phone.  It already operating on overlapping ham frequencies.  Fits in well with my interest in using Part 15 802.11 wireless devices under Part 97.  On my Asterisk sever I have extensions on can dial to hear Amateur Radio Newsline, ARRL audio news, etc.  I also have extensions for weather reports.  I've created backdoors into repeaters utilizing analog telephone adaptors and the reverse autopatch control-op listen/break-in mode.  I've experimented with a IAX link over 900 MHz using proprietary wireless hardware. 

Polycom and Cisco have WiFi phones that also has a Nextel like two-way walkie talkie/PTT functionality.  Very cool.  I'd also like to tie my Asterisk network in a more direct way to a repeater.   I also have my fingers crossed that one of these WiFi phones will have open firmware or possible be based on the Atheros chipset to allow greater frequency freedom.

Developments for an application layer to allow an existing IRLP systems to have added functionality to speak (SIP/IAX2) to an Asterisk system could be a very beneficial contribution to ham radio.

Asterisk with app_rpt can be connected to almost any radio transceiver and network if you have the skills and patience to make the necessary interface and configurations.

Asterisk with app_rpt provides the following for Amateur Radio stations and systems: A Full Function Repeater Controller, Touch Tone Command and Control, Autopatch - Reverse and VOX Operation, CTCSS Decode/Encode Functions, A SIP Telephone Exchange, Voice Mail and Announcements, Contact Closure Telemetry, Non-Proprietary Software and Hardware,
PC/Linux Operating System Based, Remote Base Client, Fully Configurable and Programmable Communications Solution

Several different radio makes and models are well supported by vendors who provide ready made interfaces and cables.

For frequency agile remote applications, app_rpt can control a multi-band, frequency programmable radio transceiver such as the Icom IC-706. 

Even consumer grade GMRS and FRS radios are supported using the DingoTel USB  adapter. Though originally sold for use on the DingoTel network, the hardware device is compatible with Asterisk app_rpt. Note that these connections use a Voice Operated Transmit (VOX) method to detect when the remote radios are transmitting and this impairs several features and the general operating quality of connections.

The DingoTel 2Way that lets you use any handheld 2-way radio and do push to talk over the internet.  http://www.dingotel.com/2way/index.asp   They also make a phone call service that runs on standard SIP but they have.   http://www.dingotel.com/Pc/sipt.asp

Radio Transceiver To Asterisk Interfaces

We will now describe two well supported hardware solutions for interfacing PTT radios to Asterisk.

QUAD RADIO PCI - This was the second interface that was devised. This card is installed in a computer's PCI slot. It supports up to four (4) simplex or full duplex radios. It has CTCSS/DCS encoder/decoders on-board. Audio level adjustments are accomplished via a group of internal, multi-turn potentiometers for each channel. One advantage of the Quad Radio PCI card is that it supports the serial control of frequency agile amateur radio transceivers.

Also see a homebrew schematic version of this from Francois, F6HQZ

USB RADIO ADAPTER (URA) - The third and most recently developed radio interface is the USB Radio Adapter. The principle advantage of this device is that it has a low cost. For example you can build your own radio cable by attaching it to a $7.00 off-the-shelf commercial USB Sound Adapter. With the USB Radio Adapter, CTCSS and other signaling encoding and decoding is done in the software. And, signal level setting is done in software so there are no physical adjustments to make that require access to the computer and taking the covers off to reach the potentiometers. Additionally, the URA can determine the received signal level in software and use it for squelch and other features.

usbradio.org - To facilitate Asterisk applications using app_rpt, AllStar Link and the "chan_usbradio" channel driver.  AllStarLink released a USB controller in Feb 2008 thru DMK Engineering  This is proposed as a Universal Radio Interface, based in the CM108 chipset.  Dec 2006 - Dave, VE7LTD had reportedly started working on a USB solution for IRLP as parallel ports are starting to disappear from computers.

With all of these interfaces, the best and preferred radio connection is directly to a radio's unsquelched and unfiltered receiver audio signal and its flat transmitter audio modulation point. Of course a transmitter activate or PTT connection is required. Connection to a carrier or signaling tone detection point is required for use with the ARIB and QUAD RADIO interfaces and optional for the URA interface.

A nice Linux platform with a nice audio platform like Asterisk and the USB dongle for the hardware interfacing.... those are all a great start towards a whole software based repeater controller.  And if it had a modular GUI front end like FreePBX, if think this would really be something.  A nice web-based GUI front end setup for CW ID's, voice messages using text
to speech, a scheduler etc.  (See the IRLP Visual Admin Console and Micro Node, these are GUI projects)

Many hams have, and already support the IRLP hardware, and that also runs on Linux. Wouldn't it be nice if there was an application that would provide the inter-operability in much the same manor we have added support for Echolink?   (As I've mentioned, the idea of having to have different hardware board for each VOIP system you want to support seems redundant.)

A different hardware board for each of these proprietary VOIP systems that you want to support is required.  You also need a need a multi-port repeater controller, to support each hardware boards analog breakout. 

The reason is all these systems take an analog audio mixing approach.  And this feeds the need for a multi-port repeater controller, to support each hardware boards analog breakout. 

Asterisk is the best foundation for digital mixing.    Their MeetMe conferencing application is a good example.  It uses a hardware timing base/source.  When it comes to mixing digital audio streams its often necessary to have a this to ensure that all packets are "in phase" or "sync" with the remote end.  Without this digital distortion can be very noticeable, jittery, choppy sound.

IRLP lacks this digital mixing foundation and this is why you can only make/take one connection at a time.  You connect to a reflector to be in conference.  With EchoLink you can conference independently, but as noted above it usually sounds choppy.

If you want to drive the IRLP board with any other software, its circuitry is fairly simple, because it just talks to the parallel port.  Someone would need to code a driver to spy on the parallel port and sound card inputs and outputs so that IRLP or Echolink can be run without modification.

From what I understand the logic signals PTT/COR toggle the "call on hold" field and that's how the standard signaling is sent over a standard SIP/IAX stream. 

Configuring two SIP extensions isn't the worst. The part I don't like with the original is the hardware approach. That's why I think it would great of there was a GPL command line SIP client such as "linphonec"  that could be torn apart and made to talk to the IRLP hardware board, since most of use are already using that hardware.

Getting something to talk to the IRLP board is step number one, from there it seems to me it should talk in SIP (preferred) or IAX. In my mind, once you have this just about anything is possible, and allows an world of tinkering;

It could allow one to possibly build their own reflector or cross connect IRLP/Allstarlink/Echolink using meetme.  

Some repeater systems use phone lines to connect remote receive sites, one might be able configure this as drop in replacement to save telco charges where there happens to be a network connection.

The possibility to support (autopatch) connections to the outside telephone network, such as for 911, instead of having to have a dedicated line at a site.

Some remote repeaters still use their autopatch to call and play newsline.  Here is how to stream Amateur Radio Newsline over a Asterisk extension.  A simple ATA could save some telephone charges. 

Just a thought. I'm not sure what would all be involved, but I would like to get a clearer picture of that.  However lets focus with something that can talk to the IRLP hardware and speak SIP.  Being able to incorporate IRLP audio onto Asterisk systems could be useful. I suspect we'd need a shim application (app_speakfree? ;) ).

When you take a digital radio platform like D-Star, this is where integrating Asterisk could be very powerful.  Since the call sign is part of every packet, this could be assigned to a direct inward dialing number (DID) or extension.

References:
http://tech.groups.yahoo.com/group/rtpDir/
http://groups.yahoo.com/group/asterisk_radio/
https://allstarlink.org/
http://asteriskpbx.org/
http://www.zapatatelephony.org/app_rpt.html

Notes:
When questioned in November 2006, about Asterisk and Allstarlink, David Cameron, ( VE7LTD) IRLP system designer said they are currently not working or supported pieces of IRLP, although they may be in the future.   Dave reported 12/06 & 11/07 that he is working on USB based solution, or a non parallel port IRLP interface card as these are being faded out in modern computers, even more so in embedded systems.

A bit of history about IRLP:

David Cameron, VE7LTD, is the guy that originated IRLP and  "pieced together" the code himself. Not being a professional programmer he said he was aware that the code was not going to be the most elegant in the world.  When he put it up the GPL license his email was besieged daily by folks flaming him about why he did something this way or that without providing any alternative. Finally in disgust he removed it from the GPL  license and continued doing it his "own" way.  Thats why the IRLP looks "quite horrible" as it does.

Toward Software Defined Radios and Digital Voice

Obviously you gravitate towards things.  You don't just expect to, like a light switch, convert everyone to purely digital radio.  

It would be logical at this day in age if you're planning on upgrading a repeater system to ensure that it can repeat analog and some form of digital.   P-25 systems and Motorobo systems can do just this.  Just as if you are considering a new HT or mobile to purchase something that is digital capable like the IC-91AD or the alike.

Technology is ever changing, which makes standards hard to set.  This is why open standards are so very important.  It expedites production and advancements , as you are effectively working together or sharing information.  Be wary of  any thing proprietary, as this impedes technology and is terribly unhealthy for the hobby.  

Protocols and standards need to be dynamic as possible to avoid equipment obsolesce.  This is where the software defined radio (SDR) concept is key.  However once again between here and there, manufactures should highly consider flash/field upgradeable firmware.

Just about everything has this, from phones to PDA's to routers.  An upgrade can fix a bug or give you added functionality.  The most classic example I can think of is the Linksys WRT-54G.  They grasped the open source concept and made a product that so many people have written after-market firmware for that has unlocked a wealth of added functionality.

Why don't we have more of this?  We are hobbyist and tinkerers that are supposed to be advancing the radio art.    Societies electronics evolvement has made traditional homebrewing difficult. Components are smaller and harder to work with, things are designed more throw away. However homebrewing should and will continue. It will evolve to a more modular and software level than component level.  As things progress increasingly more digital, the emphasis need to be on firmware upgradeable, open source, and user end flexibility. 

Yeasu and others seem to rush radios to the stores probably to beat the competitors, but they often suffer some firmware bugs.    The only way to have these resolved is to send the radio in.  Unless others follow in the footsteps like Kenwood apparently did.  http://www.kenwood.com/i/products/info/amateur/software_download.html

In summary an emphasis should be on dynamic protocols, and products that provide a capability bridge as well as upgradeable platforms.  Products that lack in these key areas are potential road blocks to the future.  I'm certainly not buying expensive radios every year, so a little foresight is all we need.

Having systems that are open to 3rd party developers, have an active developer and user community, and use open protocols have the best chance of succeeding. Hams like to tinker and also to have someone else to talk to when they need to test their tinkering.

Be wary of any product that isn't built with dynamic architecture.   Built-in obsolescence or proprietary features are excuses to force acquisition of new products.

Misc. Ideas and Interrelated Things of Interest

Here are a few potential software ideas that could potentially augment the hobby.

IRLP Related:

Repeater activity graph - Use IRLP hardware to create an automatic daily graph of system activity.

IRLP Node Administration via Web - Simple web admin php script for your IRLP node.

IRLP web announcer - web/php based announcement scheduler idea, an extension of the above

Echolink made easier - UPnP support idea for EchoLink

Virtual channels  - Use of sub-audible tones  for virtual channels for remote base configurations and sub-audible paging

IRLP-Repeater script - More info on useing IRLP as a repeater.  Includes configurable repeater hang time,  courtesy tones, timeout timer. SCCW for morse IDs, DTMF muting provisions, and anything else you can script.  

http://www.irlp.net/ 
http://groups.yahoo.com/group/irlp/
http://groups.yahoo.com/group/irlp-devel/
http://groups.yahoo.com/group/EchoIRLP/

Misc:

N3GLV is trying to get some of the AMPR.ORG activity back up for ham-voip, contact him (n3glv1963 [at] gmail.com if interested and/or e-mail WB6CYT brian [at] ucsd.edu)

TheLinkBox - beta program to support serial & parallel-port interfaces as well as USB dongles. A full featured multiport hub or repeater controller as well as a VoIP application.

rptDir - (Real Time Protocol Director) to bridge EchoLink, IRLP, and Asterisk.  Multiple interface support.

Digital RLC from Link Communications - Digital Linux repeater controller in same box as IRLP.  The RLC-DSP404 unveiled at Dayton 2007

Weather Alert Interfacing and Scripts - Hardware and Software approaches to warn of bad weather and provide reports.

DV Related:

Digital Voice Amateur Radio Association - For comparison audio samples P25, D-Star, MotoTRBO and more

More notes about D-Star and open codec's, dynamic flexibility. and technical info of various codec's and audio samples. 

The DV dongle  is an important development.  It was started by AE4JY and AA4RC.   It contains the ability to process AMBE full duplex.  Presently software applications exist to use this to communicate from a computer to a D-Star gateway.  Further development are expected so that it can be interfaced to a radio's packet radio port that has the necessary discriminator connections.  This may be a huge milestone.  The ability to retrofit an existing repeater could be possible with this.  Not only that, but you may be able to retrofit it in such a way that it can be useable in analog and for D-Star.  Something to keep an eye on!

There are a few referenced to Phase II D-Star out there.  Folks are working on that now.  Many of those people don't see a Phase 2 DSTAR that will force obsolescence of the initial DSTAR products and cause production and support of the initial phase to go away.

This Phase II terminology can get confusing.   Interesting enough D-Star uses DVSI's AMBE codec.  AMBE is slated to replace the IMBE codec in Phase 2 of APCO 25.  That is not a coincidence or accident on the part of the JARL or Icom.  Many are sure they looked at open source.  One, it puts us as ham radio operators into state-of-the-art in communications for the first time in about 10 years.   It's so nice to say that.   We appear to be Icom's lab rat for their rollout of commercial P-25 Phase-2 products.

Two, it gives us a common platform with professional public safety personal.  When they catch up.  Actually I think AMBE is backwards compatible capable with IMBE.

http://groups.yahoo.com/group/dstar_digital/
http://groups.yahoo.com/group/dstarsoftware/
http://groups.yahoo.com/group/DVDongle/
http://openp25.org/ - Consideration is being given to enhancing Asterisk app_rpt to support a low-level P25 radio interface.

Asterisk Related:

Steaming Newsline over an Asterisk extension - new use for your autopatch using a simple analog telephone adaptor

Simple FXS to simplex radio interface - from F6HQZ

Cheap Asterisk radio interface - consists of a modified USB sound device.  See usbradio.org  A channel driver exists in Asterisk that enables certain Cmedia CM108 based USB sound devices to provide the hardware interface between both commercial and amateur private land mobile radio equipment.   A pre-fab version is available from DMK Engineering.

Asterisk with app_rpt provides the following for Amateur Radio stations and systems: A Full Function Repeater Controller, Touch Tone Command and Control, Autopatch - Reverse and VOX Operation, CTCSS Decode/Encode Functions, A SIP Telephone Exchange, Voice Mail and Announcements, Contact Closure Telemetry, Non-Proprietary Software and Hardware,
PC/Linux Operating System Based, Remote Base Client, Fully Configurable and Programmable Communications Solution

Southeastern Asterisk Radio Network http://searn.alertradio.net

Asterisk Radio Networks / Asterisk Amateur Radio Network  by Mars Reed, NØPCO  http://www.alertradio.net   http://asteriskradio.net/

Asterisk Wireless Interoperability Demo http://www.xelatec.com/asterisk/  http://www.xelatec.com/w9sh/asterisk/

Allstar Link Network http://allstarlink.org

Asterisk now supports Bluetooth channels.  chan_mobile allows one to use Bluetooth cell / mobile phones as FXO devices.   Yaesu came out with a Bluetooth ready 2m/440 FT-10R Mobile.  And the Yaesu VX-8 has optional bluetooth. Can the two be written to talk to each other?  One would think so.

Alert Interface - This device connects a receiver, such as an "All Hazards" warning receiver, to an Asterisk PBX. The intended purpose is to allow the warning messages to be broadcast over the Asterisk paging system.

RadioGrid RG-4 Radio Gateway can control up to four repeaters or link radios. Each repeater or link radio can be linked to any other port on the RG-4, or, through the internet, to repeater or link radio ports on other RG-4 Radio Gateways. Any port can operate independently or be linked to one or more ports, on the same RG-4, another RG-4 on the same LAN, or to other RG-4s through public or private IP networks. The RG-4 is built around Asterisk open source PBX technology. Telephony integration is built-in, and fully integrated. Radios gatewayed through the RG-4 can be allowed to originate and receive VoIP telephone calls from your local network, and (with appropriate external hardware or by using an internet telephony provider) to and from the public telephone network.  Features; 500 MHz Blackfin processor. 64 MB RAM, 4 MB Flash memory, 1 GB SD Card

RtpDir bridge software (Real Time Protocol Director)  by Scott, KI4LKF.  Basic features:  Runs as Echolink/Echolink conference, IRLP reflector/Echolink conference, Echolink+IRLP or a private net.  Graphical environment.  DTMF control from Windows or Linux.  Remote text command control using ssh/Linux or PuTTY/Windows.  Can TX/RX IRLP messages without the IRLP board. Any station can connect to rtpDir bridge. It does not have to be IRLP or Echolink.  GSM, ADPCM, LINEAR codecs are supported.  Protocol conversion between IRLP, Echolink and SOON TO ARRIVE *Asterisk* PBX.  ADPCM ---> GSM, GSM ---> ADPCM transcoder included.  DTMF processing internal(built-in) or External(hardware).  Morse code IDs or Voice.  COS "sensing" or VOX or both.  Support for all link interfaces(sound mode or ASCII mode, VA3TO, WB2REM, G3VFP, G4CDY,...Rigblasters, MFJ, SignalLink,...)  Mark a station as "Mute", "Deaf" or "Mute and Deaf".  Timeouts for login, download, connection.  Activity reporting.  Audio recording and playback. RF station identification(audio, CW).  Welcome message(audio, CW or text). Convert text to CW. Runs as server or client. Interfaces with external scripts. Runs with or without a soundcard. Audio signal strength indicator.