I've been watching the back and forth concerning updating app_rpt to run on "a more current version" of Asterisk in hopes of a number if improvements. Some of these improvements do have value, others not so much. A little history is in order here. I have been using and supporting AllStar for the past 10 years. Like most, I used ACID to get up and running. Centos is not my preferred Linux distribution. I prefer Debian and pretty quickly built what I needed to run AllStar on Debian for myself. Debian is not "bleeding edge" It's not meant to be. It's rock solid stable. About 1.5 years ago I started seeing a increasing number of people reporting issues with installing ACID on newer hardware. No network drivers etc. Since I did not have those issues running current Debian, I decided to see if I could do something about the problem. I took the current Debian netinst image and using the ability to "preseed" the answers required for a base install of Debian. From there it was a simple task to automate the download of the most current source from the "official" SVN compile and install it. Building the kernel modules for DAHDI had to be done also. With that, we had AllStar running on a distribution with up to date drivers and a fairly current kernel. With the apt system of Debian a user could update the OS easily. Pulling updates from the SVN for Asterisk can be done manually or via a pretty simple script. I now had what I called "Bare Metal Install" Could AllStar be turned into installable Debian programs? Yes a repository could be built. Scripts could be built to automate the package creation. To be honest I don't think AllStar changed that often to make this worthwhile. Someone could take this on. A couple of the things bothered me about ACID. First was that Asterisk loaded every conceivable module at startup. No matter if you needed the module or not. This worked and the user usually did not care. It put a lot of bogus errors in the log and to some extent, ate memory that was not needed. I tried to build every module, even if it was not needed but did not enable the module in modules.conf. The other thing that bothered me was that the sample rpt.conf and other config files were not complete. Most everything was there, but some thing were missing and I felt it was better to try to include all options AND add comments detailing all possible values. Nothing is ever perfect, but I tried and continue to add things I missed. Jim approached me and asked if I was willing to turn BMI into the official AllStar x86 distribution. I agreed and added the scripts to support the web portal for creation and backup of configs. Jim came up with a name DIAL. At the same time, Jim had heard I built a image for the Raspberry Pi using Debian Jessie. He asked if we could also us it as official PIi version. I agreed added the scripts and DIAL for the RPi was born. This image does not build on the fly as did BMI but the update path was the same. DIAL relies on the official Asterisk source for the SVN. No more no less. I do not believe in fluff being part of a official distribution. Sure, it can be added. I just don't want people to have to remove things. There are quite a few great add on features and programs available for AllStar. I'll continue to make sure they work, but I don't think they should be part of the distribution. All of my work for building DIAL and scripts to support more platforms is kept in a GIT repository along with links to the "release candidate" for amd64, i386 and the RPi. <https://github.com/N4IRS/AllStar> The reason for this romp down memory lane is just to point out that DIAL is independent of the official source. I don't care is it is in a SVN or GIT repository. As long as I can get to the current source, DIAL is good. For me, I could care less if appt_rpt is ported to a more current version of Asterisk. To me the current version is fine as a repeater controller, remote base and voter. I think the current attack surface is small and still be reduced within the host OS. If I want a PBK I'll spin up the current Asterisk and connect the 2. The time available for people that can work on app_rpt is limited. I think that time at least at first should be spent on app_rpt.c and the channel drivers. There is a LOT of code there and if more people understood it, the more people could maintain and enhance it. First that means comments! A push to comment the existing code would go a long way. Who knows what might be found while commenting the existing code. There are some parts of app_rpt that have a very limited audience. The support for the Uchameleon comes to mind. I'm not saying kill it. I'm saying break it out as a module and allow the user to load it if the user has one and wants to use it. Other areas that can get the same treatment could be the remote base. I know others have done work with Hamlib. It should be leveraged. I think it could be more of a module, not a set of scripts that need to be pasted together. Integrate it and let the user decide to enable it. The channel drivers could use some attention. Right now we have the PCI quad card and USB sound. Other devices are due in the future. Break out the "digital IO" from the channel driver. Move the PTT, COS and CTCSS and other digital IO away from the dependence on the CM1xx. I'm not saying remove it. Make it more modular. If I want the GPIO on the CM1xx great. If I want to use the GPIO of the RPi fine. If I want to use the parallel port on the PC, fine. This way only the Digital IO module needs to be modified, not the whole channel driver. Combine the simpleUSB and USBradio channel drivers. I know of at least one fork that did this with success. and future channel drivers are doing this soon. One less channel driver to maintain. Expand the capability of chan_usrp. We use this channel driver for the DMRGateway project with great success. Being able to pass more data between app_rpt and the outside world (and back) would enhance the abilities of both. Think of passing a MDC ID through to DMRGateway or D-StarGateway. I could go on and on. There are a ton of feature and enhancements people have asked for. All of this requires the "buy in" of Jim. Without it, it's just another fork. Just one off the top of my head. 73, Steve N4IRS -- "No, INAD is not JUST I need a drink"