[App_rpt-users] app_rpt updates, upgrades etc.

[Steve Zingman]

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"