Update on the Raspberry Pi Asterisk Allstar project
Great news, Allstar is running on the Raspberry Pi! I have been working on this over the last few months and testing now for several weeks. It seems to be stable. Audio is great using simpleusb. The project makes it possible to assemble a small, low power, and inexpensive Allstar server and node that fits in the palm of your hand minus the radio.
The project was started by Mihhail, ES1BIS who successfully compiled the code on Pidora FC17 on the Pi. I took that code, optimized it, and made it work well in the real world. I later successfully compiled the code under the latest Raspbien release for the Pi. This was an important transition for a number of reasons as Pidora has been poorly supported recently and does not have direct overclocking and memory management capabilities. It is the Acid release except using Dahdi.
The code is on a 16G SD card and while it would fit on an 8G card the added space at little additional cost are worth it. Using a larger size SD card is also purported to increase the life of the card giving more space for wear levelling. The Pi is run as a “headless” system with ssh access. I also have added the apache2 web browser and my lsnodes remote web display and control program which allows you to monitor and control the server remotely.
The test system is running with a DMK URI USB interface but would work with an inexpensive modified sound FOB. An entire system could be built for around $50 in this way. It would also be possible to write code and build a small interface to allow the Pi GPIO pins control the PTT and COS.
Asterisk typically uses about 10-20% of CPU on the Pi and other operations like web accesses and even a compile going on while Allstar is running caused no glitches. I currently run overclocking at modest (800mhz) but it could be run at much higher speeds if necessary. I have two nodes running on the Pi but only one connected to a radio. If you did not know it was running on the Pi you would not know the difference to any other server.
Things to be done include -
Recompile under USB driver rewrite kernel
A script to install your node information and setup
Test use of a wireless card in the Pi
Test Mobile node applications
Test Additional nodes (2 or more simultaneous nodes)
Test usbradio (it might be possible for one node with overclocking)
Item number one on this list is the most important right now. There is a problem running the USB at full (2.0) speed with USB audio. This shows up as unacceptable distortion in the receive (DAC) audio. Running in USB high (1.1) speed solves the audio problem but causes some minor delay problems. In the scheme of things this is acceptable but I am not completely happy with this and I want to get this running in USB 2.0 mode before I release it. There is currently a complete rewrite of the Pi USB stack going on that hopefully will solve this problem. My plans are to let things settle a little and pick up the new kernel and recompile very soon. So stay tuned for that.
When I do make the image available it will not be plug and play. It will require IP address and port setup for your LAN and editing of rpt.conf and other configuration files. I will put together a checklist of tasks you will need to complete in bringing up your own Pi Allstar server. This is a server and node so you will have to transfer an existing server and node or set up a new one at allstarlink.org If you don’t feel comfortable mucking in Linux this might be a problem but the upside is that you will have the original image to go back to should you mess something up and need to start over. It is always a good idea to save additional image copies after you make significant changes and you are sure it is working. This allows you to go back to prior images that work rather than recreating things from earlier images.
A quick note about SD card life since I know this is a big topic and a question you would ask. First I will say I have several IRLP Pi nodes, one running for 10 months straight, without a failure. I have never had an SD card fail period. Not due to power failure, longevity or any other cause. I also only buy good quality cards like the Sandisk Ultra class 10 or better. That is not to say one won’t fail at some point but that is what backups are for and with an SD card it is easy, pop one out and put the other one that you have burned the image to in. Like anything else it is important to have a backup. I have done most everything practical to minimize writes to the SD card. Only time will tell how long it will last but I have confidence it will be a long time.
I will be setting up a web page for this and there will be additional information as well as image downloads there when they are available. I would be glad to answer any questions you may have.
And finally I saw this statement on an Asterisk site and I though it pointed out how far we have come in the past 15-20 years! “I just received my Raspberry Pi and looking forward to running Asterisk on it. I’ve been in tech for 30 years and I can’t believe what is in front of me. 15 years ago, as a department head, I signed off on a $200K project to upgrade a PBX system with a voicemail system that can email you the sound file and provide web access to your VM messages. Now, I am about to deploy a full PBX system for $50. Maybe a $75 if I buy a case for my Raspberry Pi.”
Update on the Raspberry Pi Asterisk Allstar project
Great news, Allstar is running on the Raspberry Pi! I have been working on this over the last few months and testing now for several weeks. It seems to be stable. Audio is great using simpleusb. The project makes it possible to assemble a small, low power, and inexpensive Allstar server and node that fits in the palm of your hand minus the radio.
The project was started by Mihhail, ES1BIS who successfully compiled the code on Pidora FC17 on the Pi. I took that code, optimized it, and made it work well in the real world. I later successfully compiled the code under the latest Raspbien release for the Pi. This was an important transition for a number of reasons as Pidora has been poorly supported recently and does not have direct overclocking and memory management capabilities. It is the Acid release except using Dahdi.
The code is on a 16G SD card and while it would fit on an 8G card the added space at little additional cost are worth it. Using a larger size SD card is also purported to increase the life of the card giving more space for wear levelling. The Pi is run as a “headless” system with ssh access. I also have added the apache2 web browser and my lsnodes remote web display and control program which allows you to monitor and control the server remotely.
The test system is running with a DMK URI USB interface but would work with an inexpensive modified sound FOB. An entire system could be built for around $50 in this way. It would also be possible to write code and build a small interface to allow the Pi GPIO pins control the PTT and COS.
Asterisk typically uses about 10-20% of CPU on the Pi and other operations like web accesses and even a compile going on while Allstar is running caused no glitches. I currently run overclocking at modest (800mhz) but it could be run at much higher speeds if necessary. I have two nodes running on the Pi but only one connected to a radio. If you did not know it was running on the Pi you would not know the difference to any other server.
Things to be done include -
Recompile under USB driver rewrite kernel
A script to install your node information and setup
Test use of a wireless card in the Pi
Test Mobile node applications
Test Additional nodes (2 or more simultaneous nodes)
Test usbradio (it might be possible for one node with overclocking)
Item number one on this list is the most important right now. There is a problem running the USB at full (2.0) speed with USB audio. This shows up as unacceptable distortion in the receive (DAC) audio. Running in USB high (1.1) speed solves the audio problem but causes some minor delay problems. In the scheme of things this is acceptable but I am not completely happy with this and I want to get this running in USB 2.0 mode before I release it. There is currently a complete rewrite of the Pi USB stack going on that hopefully will solve this problem. My plans are to let things settle a little and pick up the new kernel and recompile very soon. So stay tuned for that.
When I do make the image available it will not be plug and play. It will require IP address and port setup for your LAN and editing of rpt.conf and other configuration files. I will put together a checklist of tasks you will need to complete in bringing up your own Pi Allstar server. This is a server and node so you will have to transfer an existing server and node or set up a new one at allstarlink.org If you don’t feel comfortable mucking in Linux this might be a problem but the upside is that you will have the original image to go back to should you mess something up and need to start over. It is always a good idea to save additional image copies after you make significant changes and you are sure it is working. This allows you to go back to prior images that work rather than recreating things from earlier images.
A quick note about SD card life since I know this is a big topic and a question you would ask. First I will say I have several IRLP Pi nodes, one running for 10 months straight, without a failure. I have never had an SD card fail period. Not due to power failure, longevity or any other cause. I also only buy good quality cards like the Sandisk Ultra class 10 or better. That is not to say one won’t fail at some point but that is what backups are for and with an SD card it is easy, pop one out and put the other one that you have burned the image to in. Like anything else it is important to have a backup. I have done most everything practical to minimize writes to the SD card. Only time will tell how long it will last but I have confidence it will be a long time.
I will be setting up a web page for this and there will be additional information as well as image downloads there when they are available. I would be glad to answer any questions you may have.
And finally I saw this statement on an Asterisk site and I though it pointed out how far we have come in the past 15-20 years! “I just received my Raspberry Pi and looking forward to running Asterisk on it. I’ve been in tech for 30 years and I can’t believe what is in front of me. 15 years ago, as a department head, I signed off on a $200K project to upgrade a PBX system with a voicemail system that can email you the sound file and provide web access to your VM messages. Now, I am about to deploy a full PBX system for $50. Maybe a $75 if I buy a case for my Raspberry Pi.”
We received our RTCM's this week, and I am working to interface them to the Quantar. I've run into a few issues:
1.) AUX TX Audio. I've had success with one machine in getting the audio out of Pin 5 of the Telco connector, but not on the other. Is creating a wildcard table to enable "AUXTX-TX ON" when there is an input on Pin 9 (PTT) the correct method to enable TX audio output on Pin 5?
1.) BEW Mode. My RTCM's show it as unavailable as an option to enable. Is there a trick to enabling it?
2.) I cannot seem to get the squelch calibrated. I get a slow flashing light a little while after I enable squelch cal, which seems to indicate low discriminator noise. I tried enabling jumper JP1 with no change. Does BEW mode need to be enabled to get a proper squelch calibration with the Quantar? Tim suggested that some older firmware version may not provide enough discriminator noise. I want to be sure I've exhausted all options before I hunt for SCM with newer firmware for these machines.
I downloaded the BEW firmware for the RTCM and loaded it on both of our RTCM's. I enabled BEW mode, and attempted to calibrate the squelch again. Still get the slow flashing RX light, but 60-90 seconds into the squelch calibration procedure it finally completed with a squelch cal value of 100-110. The squelch POT lights up the RX light when the POT is turned down to a value of about 150 (post sq cal procedure).
Tim mentioned that older Quantar firmware may have low discriminator levels. The above squelch cal was done with a 800MHz Quantar, no antenna attached, with the latest firmware I've been able to find, 20.14.048.
Is what I'm seeing normal/acceptable for a Quantar?
Also, something I noticed once the BEW firmware was loaded, I no longer have the ability to access the Diagnostics menu on the RTCM. So, I am unable to transmit a 1khz tone, etc. I used the latest BEW SMT FW version (1499) off of the Allstar SVN server.
Thanks,
Caleb
···
On 3/10/2014 1856, Caleb Pal wrote:
Hello all,
We received our RTCM's this week, and I am working to interface them to the Quantar. I've run into a few issues:
1.) AUX TX Audio. I've had success with one machine in getting the audio out of Pin 5 of the Telco connector, but not on the other. Is creating a wildcard table to enable "AUXTX-TX ON" when there is an input on Pin 9 (PTT) the correct method to enable TX audio output on Pin 5?
1.) BEW Mode. My RTCM's show it as unavailable as an option to enable. Is there a trick to enabling it?
2.) I cannot seem to get the squelch calibrated. I get a slow flashing light a little while after I enable squelch cal, which seems to indicate low discriminator noise. I tried enabling jumper JP1 with no change. Does BEW mode need to be enabled to get a proper squelch calibration with the Quantar? Tim suggested that some older firmware version may not provide enough discriminator noise. I want to be sure I've exhausted all options before I hunt for SCM with newer firmware for these machines.
Thanks,
Caleb
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org ohnosec.org
To unsubscribe from this list please visit ohnosec.org 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.
On Mar 12, 2014, at 11:35 PM, Caleb Pal <cleb@defcon-3.net> wrote:
On 3/10/2014 1856, Caleb Pal wrote:
Hello all,
We received our RTCM's this week, and I am working to interface them to the Quantar. I've run into a few issues:
1.) AUX TX Audio. I've had success with one machine in getting the audio out of Pin 5 of the Telco connector, but not on the other. Is creating a wildcard table to enable "AUXTX-TX ON" when there is an input on Pin 9 (PTT) the correct method to enable TX audio output on Pin 5?
1.) BEW Mode. My RTCM's show it as unavailable as an option to enable. Is there a trick to enabling it?
2.) I cannot seem to get the squelch calibrated. I get a slow flashing light a little while after I enable squelch cal, which seems to indicate low discriminator noise. I tried enabling jumper JP1 with no change. Does BEW mode need to be enabled to get a proper squelch calibration with the Quantar? Tim suggested that some older firmware version may not provide enough discriminator noise. I want to be sure I've exhausted all options before I hunt for SCM with newer firmware for these machines.
Thanks,
Caleb
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org ohnosec.org
To unsubscribe from this list please visit ohnosec.org 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.
To update my progress:
I downloaded the BEW firmware for the RTCM and loaded it on both of our RTCM's. I enabled BEW mode, and attempted to calibrate the squelch again. Still get the slow flashing RX light, but 60-90 seconds into the squelch calibration procedure it finally completed with a squelch cal value of 100-110. The squelch POT lights up the RX light when the POT is turned down to a value of about 150 (post sq cal procedure).
Tim mentioned that older Quantar firmware may have low discriminator levels. The above squelch cal was done with a 800MHz Quantar, no antenna attached, with the latest firmware I've been able to find, 20.14.048.
Is what I'm seeing normal/acceptable for a Quantar?
Also, something I noticed once the BEW firmware was loaded, I no longer have the ability to access the Diagnostics menu on the RTCM. So, I am unable to transmit a 1khz tone, etc. I used the latest BEW SMT FW version (1499) off of the Allstar SVN server.
Thanks,
Caleb
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org ohnosec.org
To unsubscribe from this list please visit ohnosec.org 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.
I did not have access to such a codeplug, so I made the below changes to my existing codeplug with RSS 14.10.00:
Hardware Configuration Screen:
Station Type: Analog Only
Wireline: 8 Wire (It only has a 4W board in it)
Wildcard: Enhanced
Phone Patch Interface: Enabled
Channel Information (Basic):
Analog RX Activation: SC=Carrier and PL/DPL
On Mar 12, 2014, at 11:35 PM, Caleb Pal <cleb@defcon-3.net> wrote:
On 3/10/2014 1856, Caleb Pal wrote:
Hello all,
We received our RTCM's this week, and I am working to interface them to the Quantar. I've run into a few issues:
1.) AUX TX Audio. I've had success with one machine in getting the audio out of Pin 5 of the Telco connector, but not on the other. Is creating a wildcard table to enable "AUXTX-TX ON" when there is an input on Pin 9 (PTT) the correct method to enable TX audio output on Pin 5?
1.) BEW Mode. My RTCM's show it as unavailable as an option to enable. Is there a trick to enabling it?
2.) I cannot seem to get the squelch calibrated. I get a slow flashing light a little while after I enable squelch cal, which seems to indicate low discriminator noise. I tried enabling jumper JP1 with no change. Does BEW mode need to be enabled to get a proper squelch calibration with the Quantar? Tim suggested that some older firmware version may not provide enough discriminator noise. I want to be sure I've exhausted all options before I hunt for SCM with newer firmware for these machines.
Thanks,
Caleb
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org ohnosec.org
To unsubscribe from this list please visit ohnosec.org 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.
To update my progress:
I downloaded the BEW firmware for the RTCM and loaded it on both of our RTCM's. I enabled BEW mode, and attempted to calibrate the squelch again. Still get the slow flashing RX light, but 60-90 seconds into the squelch calibration procedure it finally completed with a squelch cal value of 100-110. The squelch POT lights up the RX light when the POT is turned down to a value of about 150 (post sq cal procedure).
Tim mentioned that older Quantar firmware may have low discriminator levels. The above squelch cal was done with a 800MHz Quantar, no antenna attached, with the latest firmware I've been able to find, 20.14.048.
Is what I'm seeing normal/acceptable for a Quantar?
Also, something I noticed once the BEW firmware was loaded, I no longer have the ability to access the Diagnostics menu on the RTCM. So, I am unable to transmit a 1khz tone, etc. I used the latest BEW SMT FW version (1499) off of the Allstar SVN server.
Thanks,
Caleb
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org ohnosec.org
To unsubscribe from this list please visit ohnosec.org 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.
I am doing some troubleshooting on a repeater that uses ACID and two URIs.
Can I swap the two URIs without readjusting gains? Also, I don't know which
version of URI we have; would need S/N range for each version. Can I swap
out a URI with a URIx (new URI) without adjusting gains?
The URI has the capability to use an EEPROM to store the radio settings. The EEPROM is installed inside the cable connector to the radio so the settings are remembered for that radio and in that case when changing the URI it would read the EERPOM data for that radio. The cable would stay with the radio. Most people do not use that method though and I suspect you aren’t either. Without the EEPROM the config values are stored on the computer for the node so if you swap URI’s and restart Allstar it should have the same levels for that node and radio. The config settings are stored in /etc/asterisk. So you can swap URI’s but not radios (unless they were setup exactly the same) without changing anything.
The EEPROM option is an added cost when you buy it but you could buy your own 93C46 and wire it into the connector. The advantage would be that once you stored the configuration for the radio in the EEPROM you could connect that radio and cable to any URI and Allstar computer without further configuration. There is a setting for this in the simpleusb or usbradio config files.
As far as build uniformity, I cannot speak for that but my guess would be they are almost immeasurably close. 73 Doug
WA3DSP WA3DSP Amateur Radio Resources
I am doing some troubleshooting on a repeater that uses ACID and two URIs.
Can I swap the two URIs without readjusting gains? Also, I don’t know which
version of URI we have; would need S/N range for each version. Can I swap
out a URI with a URIx (new URI) without adjusting gains?
To unsubscribe from this list please visit ohnosec.org 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.
The URI has the capability to use
an EEPROM to store the radio settings. The EEPROM is installed inside the
cable connector to the radio so the settings are remembered for that radio and
in that case when changing the URI it would read the EERPOM data for that
radio. The cable would stay with the radio. Most people do not use that
method though and I suspect you aren’t either. Without the EEPROM the config
values are stored on the computer for the node so if you swap URI’s and restart
Allstar it should have the same levels for that node and radio. The config
settings are stored in /etc/asterisk. So you can swap URI’s but not radios
(unless they were setup exactly the same) without changing anything.
The EEPROM option is an added cost when you buy it but you could buy your own
93C46 and wire it into the connector. The advantage would be that once you
stored the configuration for the radio in the EEPROM you could connect that
radio and cable to any URI and Allstar computer without further configuration.
There is a setting for this in the simpleusb or usbradio config files.
As far as build uniformity, I cannot speak for that but my guess would be they
are almost immeasurably close. 73 Doug
WA3DSP WA3DSP Amateur Radio Resources
To unsubscribe from this list please visit ohnosec.org 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.
Thanks for all the replies on my announcement. I got so many that I am sorry I cannot respond to everyone individually. So there definitely is interest in doing this.
I am currently working on compiling it with the latest USB rewrite updates in the 3.10 kernel. While it works OK now there are some slight delay issues I am not happy with. It currently only runs in USB 1.1 mode which on the Pi puts the Ethernet into low speed also. Hopefully the updates will fix that.
I certainly understand the enthusiasm out there for this but I would not want to put out something prematurely that would cause problems. So bear with me for a bit until things are ironed out. In the meantime you can get your RPI, USB FOB, and SD card ready. I would recommend a Sandisk Ultra class 10 16gb or better. 73 Doug
WA3DSP WA3DSP Amateur Radio Resources
···
Date: Mon, 17 Mar 2014 22:04:50 -0500
Subject: Re: [App_rpt-users] Asterisk Allstar on the Raspberry Pi
From: mhebert1975@gmail.com
To: doug@crompton.com
Any update? What do you need help with?
On Mon, Mar 10, 2014 at 12:09 AM, Doug Crompton doug@crompton.com wrote:
Update on the Raspberry Pi Asterisk Allstar project
Great news, Allstar is running on the Raspberry Pi! I have been working on this over the last few months and testing now for several weeks. It seems to be stable. Audio is great using simpleusb. The project makes it possible to assemble a small, low power, and inexpensive Allstar server and node that fits in the palm of your hand minus the radio.
The project was started by Mihhail, ES1BIS who successfully compiled the code on Pidora FC17 on the Pi. I took that code, optimized it, and made it work well in the real world. I later successfully compiled the code under the latest Raspbien release for the Pi. This was an important transition for a number of reasons as Pidora has been poorly supported recently and does not have direct overclocking and memory management capabilities. It is the Acid release except using Dahdi.
The code is on a 16G SD card and while it would fit on an 8G card the added space at little additional cost are worth it. Using a larger size SD card is also purported to increase the life of the card giving more space for wear levelling. The Pi is run as a “headless” system with ssh access. I also have added the apache2 web browser and my lsnodes remote web display and control program which allows you to monitor and control the server remotely.
The test system is running with a DMK URI USB interface but would work with an inexpensive modified sound FOB. An entire system could be built for around $50 in this way. It would also be possible to write code and build a small interface to allow the Pi GPIO pins control the PTT and COS.
Asterisk typically uses about 10-20% of CPU on the Pi and other operations like web accesses and even a compile going on while Allstar is running caused no glitches. I currently run overclocking at modest (800mhz) but it could be run at much higher speeds if necessary. I have two nodes running on the Pi but only one connected to a radio. If you did not know it was running on the Pi you would not know the difference to any other server.
Things to be done include -
Recompile under USB driver rewrite kernel
A script to install your node information and setup
Test use of a wireless card in the Pi
Test Mobile node applications
Test Additional nodes (2 or more simultaneous nodes)
Test usbradio (it might be possible for one node with overclocking)
Item number one on this list is the most important right now. There is a problem running the USB at full (2.0) speed with USB audio. This shows up as unacceptable distortion in the receive (DAC) audio. Running in USB high (1.1) speed solves the audio problem but causes some minor delay problems. In the scheme of things this is acceptable but I am not completely happy with this and I want to get this running in USB 2.0 mode before I release it. There is currently a complete rewrite of the Pi USB stack going on that hopefully will solve this problem. My plans are to let things settle a little and pick up the new kernel and recompile very soon. So stay tuned for that.
When I do make the image available it will not be plug and play. It will require IP address and port setup for your LAN and editing of rpt.conf and other configuration files. I will put together a checklist of tasks you will need to complete in bringing up your own Pi Allstar server. This is a server and node so you will have to transfer an existing server and node or set up a new one at allstarlink.org If you don’t feel comfortable mucking in Linux this might be a problem but the upside is that you will have the original image to go back to should you mess something up and need to start over. It is always a good idea to save additional image copies after you make significant changes and you are sure it is working. This allows you to go back to prior images that work rather than recreating things from earlier images.
A quick note about SD card life since I know this is a big topic and a question you would ask. First I will say I have several IRLP Pi nodes, one running for 10 months straight, without a failure. I have never had an SD card fail period. Not due to power failure, longevity or any other cause. I also only buy good quality cards like the Sandisk Ultra class 10 or better. That is not to say one won’t fail at some point but that is what backups are for and with an SD card it is easy, pop one out and put the other one that you have burned the image to in. Like anything else it is important to have a backup. I have done most everything practical to minimize writes to the SD card. Only time will tell how long it will last but I have confidence it will be a long time.
I will be setting up a web page for this and there will be additional information as well as image downloads there when they are available. I would be glad to answer any questions you may have.
And finally I saw this statement on an Asterisk site and I though it pointed out how far we have come in the past 15-20 years! “I just received my Raspberry Pi and looking forward to running Asterisk on it. I’ve been in tech for 30 years and I can’t believe what is in front of me. 15 years ago, as a department head, I signed off on a $200K project to upgrade a PBX system with a voicemail system that can email you the sound file and provide web access to your VM messages. Now, I am about to deploy a full PBX system for $50. Maybe a $75 if I buy a case for my Raspberry Pi.”
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.