- App_rpt-users - lists.keekles.org

Stupid asterisk tricks
by Stacy 15 Sep '16

15 Sep '16

All, For those of you who may want to play with the code I put up at https://github.com/KG7QIN/AllStarLink-Asterisk-1.8 but don't have a radio or anything else they want to /can spare at the moment, there is something else you can do: Setup your console to dial. Once you do this, you can do something like "console dial 42088" and have the audio of your node play on your computer speakers. You could probably even use it to talk, but I don't really recommend it unless you know what you are doing. To set this up, you will need to: 1. Add comment our the noload => chan_alsa.so or noload => chan_oss.so line in your modules conf. 2. Edit your oss.conf or alsa.conf file (depending on which you use, I recommend alsa) to use your console. I use alsa.conf, so here is what the my test node's alsa.conf looks like: [general] autoanswer=no context=radio-control-console ;this needs to correspond to your nodes's number extension=42088 ;aplay -l can list your alsa devices input_device=plughw:0,1 output_device=plughw:0,0 ;default mute state mute=true For your extensions.conf, add this to the end of it so that radio-control-console context has somewhere to go (change the 42088 to match the node number you put in the extensions section in the file above. [radio-control-console] exten => 42088,1,Ringing exten => 42088,n,Wait(3) exten => 42088,n,Answer exten => 42088,n,Set(CALLERID(name)="KG7XXX") exten => 42088,n,Playback(rpt/connected) exten => 42088,n,Playback(rpt/node) exten => 42088,n,Saydigits(${EXTEN}) exten => 42088,n,Rpt(${EXTEN},P,${CALLERID(name)}) You can then startup asterisk, and on the console type "console dial <node>" and watch/listen as your system dials in using phone mode. "console dial <digits>" to dial. "console hangup" to hangup. (Note I have only done this with the 1.8 port I've put up in the github repository). -Stacy KG7QIN

2 2

app_rpt updates, upgrades etc.
by Steve Zingman 15 Sep '16

15 Sep '16

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"

3 3

toy throwing time?
by Steve Wright 15 Sep '16

15 Sep '16

On 12/07/16 07:05, Steve Zingman <szingman(a)msgstor.com> wrote: > There have been discussion as to how to move forward. The people > involved are the people that will do the work. We can not be "left > behind" and the tools needed are available. app_rpt is Open Source, > Asterisk is Open Source. The concepts and methods used by app_rpt are > readily apparent. They can be re-created. > [....] > On 7/11/2016 2:33 PM, Loren Tedford wrote: >> Now where do we begin? I know absolutely nothing about coding however >> I do know if we don't do some thing fast we will be left behind and >> the tools others may have had available to port their stuff through >> may not be available for us.. >> Where do we join this group? Set it up.

17 37

Re: [App_rpt-users] App_rpt-users Digest, Vol 91, Issue 29
by Jeff Carrier 14 Sep '16

14 Sep '16

Thanks for the trip down memory lane Steve. Quite a few things I wasn't aware of. If I hadn't said so lately, a Tremendous thanks to Jim Duuuude, Steve, Steve and the team who made this project possible! You guys provided a way for me to link repeaters in a new way. Sure there were other methods of doing so over IP but app_rpt allowed us to do it on a private IP backbone if we wanted to. Now we have 2 large systems in the state using app_rpt as the linking system...bye bye UHF analog links! There is Allmon courtesy of Tim which is another invaluable tool! Then there's voted receivers and the list goes on and on! Thanks guys!!!! de K0JSC On Wed, Sep 14, 2016 at 10:00 AM, <app_rpt-users-request(a)ohnosec.org> wrote: > Send App_rpt-users mailing list submissions to > app_rpt-users(a)ohnosec.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users > or, via email, send a message with subject or body 'help' to > app_rpt-users-request(a)ohnosec.org > > You can reach the person managing the list at > app_rpt-users-owner(a)ohnosec.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of App_rpt-users digest..." > > > Today's Topics: > > 1. app_rpt updates, upgrades etc. (Steve Zingman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 14 Sep 2016 11:53:50 -0400 > From: Steve Zingman <szingman(a)msgstor.com> > To: 'Allstar app_rpt-users Group' <app_rpt-users(a)ohnosec.org> > Subject: [App_rpt-users] app_rpt updates, upgrades etc. > Message-ID: <f088fcb9-fa59-fb52-9eef-b8e0dac72df8(a)msgstor.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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" > > > ------------------------------ > > _______________________________________________ > App_rpt-users mailing list > App_rpt-users(a)ohnosec.org > http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users > > > End of App_rpt-users Digest, Vol 91, Issue 29 > ********************************************* >

2 1

DIAL and devstr changes
by John Locke 14 Sep '16

14 Sep '16

Hi all, I have a Dial server with 4 URIs. Everything is working ok. Each URI has his own config file Example usbradio_tune_usb01.conf [usb01] ; name=usb01 ; devicenum=1 devstr=3-2:1.0 ... usbradio_tune_usb04.conf [usb04] ; name=usb04 ; devicenum=1 devstr=7-1:1.0 *The problem is that "sometimes" after a reboot, Debian changes the devstr of the USB ports...* I have reconfigured this server 3 times already! Any advise would be very appreciated. Thanks in advance. Regards John

2 3

Latest WX Weather report for DIAL
by Bob Roszkowski 12 Sep '16

12 Sep '16

What is the latest working solution to get WX Weather reports/alerts on DIAL? I found some pages talking about BBB but didn't see anything for DIAL. Sincerely, boB - W5EVH

6 7

Customizing courtesy tones
by Richard Bateman 12 Sep '16

12 Sep '16

Hi, I've been on the fence between using app_rpt and getting an analog controller such as the RC-210 for awhile now; I'd really love to have the flexibility of app_rpt, but there is one feature that the rc-210 gives me that I don't see a way to do with app_rpt. What I eventually plan to do is to have a 440, a 220, and a 2m repeater all linked together more or less permanently -- this is so that members of our club (many of whom are beginners) can try out different bands and learn to use them but still for sure have someone to talk to (220 in particular is pretty dead around here). Anyway, I'd really like to have some easy way for everyone to be able to tell which repeater the transmission came in on; with the RC-210 my plan was to have a different courtesy tone depending on the source. e.g. 2m repeater originating transmissions would have CT1, 440 CT2, 220 CT3. Another need I have is to be able to send a DTMF command code to change the basic CT of the repeater to a double beep to indicate that a net is in progress; I think I can do that using a macro which runs a shell script, changes the config file, and runs "rpt reload". So, my question is this: is it possible to trigger a macro or function or something that I could use to run arbitrary code every time a transmission started which would know which node that transmission came from? Then I could set the CT based on which node is originating the transmission each time. Other ideas for solving the problem would also be welcome. =] I'm a developer with C experience and some background in asterisk so I'm willing to do some work in the app_rpt.c code as well if needed, but I've found diving in without asking first often means solving the problem in a non-ideal way =] Thanks, Richard KD7BBC

2 1

Courtesy tone delay?
by Richard Bateman 12 Sep '16

12 Sep '16

Hi, I'm very very new at this =] I just got a RPi3 working with the default image and built an interface from my URI to my TKR-750 -- and everything seems to be working. I am using usbradio and things work fine w/ either cor and ctcss coming from usb or dsp. the one issue I'm struggling with is that it takes nearly 4 seconds after I release my PTT button before I get the courtesy tone... I was kinda hoping for more like 500ms. Any ideas how I can fix this? Is it normal, something that can be tuned, a misconfiguration, or.... ? Thanks! Richard KD7BBC HamStudy.org

3 2

weather
by Ken 12 Sep '16

12 Sep '16

The Zone forecasts are gone, but you can get a text version of any lat/lon web page and, with a modest amount of cleanup, it will TTS very nicely. I used curl and html2text with -nob (no bold) option. I realized today that the alerts and warnings now require you to use "https:" for the URL . I found I had to add "--no-check-certificate" to the wget line for that to work. Ken

2 1

Re: [App_rpt-users] App_rpt-users Digest, Vol 91, Issue 18
by Greg Thornwall 11 Sep '16

11 Sep '16

I have done a lot of C coding years ago, now I use Java. I wish the code was commented better, it's hard to get a grasp on what's going on. For the projects I have worked on, we would have to comment every function and variables. That way it was easier to bring someone on board or if you went back to code that you hadn't looked at in a long while it was quick to figure out the code. 73 Greg On 09/11/2016 01:06 AM, app_rpt-users-request(a)ohnosec.org wrote: > > Message: 3 > Date: Fri, 9 Sep 2016 16:31:11 -0700 > From: Stacy <kg7qin(a)arrl.net> > To: Bob Brown - W?NQX <bbrown(a)byrg.net> > Cc: Jim Duuuude <telesistant(a)hotmail.com>, app_rpt mailing list > <app_rpt-users(a)ohnosec.org> > Subject: Re: [App_rpt-users] toy throwing time? > Message-ID: <bda748d2-f702-5507-06ad-fca9557154dc(a)arrl.net> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Bob, > > You forgot all the additional restriction that the State of California > puts on everything. :) > > Also, I had posted this to the list a while ago. I did not want the > code to be left stagnant/lost, and some people seemed to be interested. > > The only thing with open source, is that it takes a lot of time and > effort to move forward. > > Both Jim Dixon and Steve Rodgers put a lot of work into the parts that > are used for the AllStar Network. (app_rpt is one example of the work > done). > > I had an inkling for starting a port for a long time, and my initial > attempts were not met with success (the DAHDI driver and a newer Linux > kernel). At first, I didn't have a lot of time to put into this. It > was only when I had started my transition/retirement from my previous > job last October (20 years activey duty Navy, retired 1 Dec 15), that I > had the free time to start on a project like this. > > I have since started a new job, so I do not have all the free time I one > did to work on it. One of the reasons why put it in a Github repository > and posted the announcement here several months ago, was because I feel > there is a desire to move things forward. I saw this old thread today > when cleaning up my inbox and decided to re-post the link to it. > > You are right, this isn't an official release-- yet. As with any major > step forward, testing will be required. The only way to accomplish that > is for the code to be picked up, used, poked at and fixed. This is a > lot for one person to do, especially since there are parts I can't test > right now. App_rpt will run, take/make calls and do its thing. Does > it have bugs? Hell yes. But is it is start. > > And as Jim said before, he loves open source. That being said, the only > person who can officially sanction this is Jim himself (see copyright in > the headers of all the app_rpt and related module source code), and even > he released it under the GPL. Unless this plain crashes any of the > pieces of the AllStar network, nobody will likely know you are running > it. I don't recommend trying to run it as a production node yet, but it > still needs to be run in the environment it will be used in to test it > out and shake the bugs out. > > -Stacy > > KG7QIN > >

1 0