This is an old revision of the document!
Table of Contents
This is the start page.
Blog:
Raspberry Pi Speaker/PA Phone
First, this little project is not as capable as the serious hardware you get from https://www.cyberdata.net , https://www.algosolutions.com/ or other vendors. But if you don't mind experimenting with a Raspberry Pi or similar hardware, this is a fun useful project that will create a VoIP/SIP endpoint that auto answers as a phone extension that allows you to feed into a PA system, loud speaker, etc. You should have some basic skills with an rPi, a text editor and linux. There is no security, implicit or implied, but if you practice sane PBX/SIP Server configs and put a real password on your rPi user and root accounts, you should be ready to go. Depending on your PBX, it might be possible that outside callers find this extension and say rude things loudly.
Build your device. Lots of options here, we are using basic Raspian aka Raspberry Pi OS without a GUI. Command Line Only. My reference build is an rPi 3, but this should work on any variations. rPi's have sound out, but no microphone in via the 3.5mm jack. Because of this, we need to install the snd-dummy driver via modprobe. Just plug something loud into the 3.5mm plug.
Step 1:
Install the needed things. I like Joe as an editor, nano and pico and vi work as well. mpg321 is mostly so you can test audio out without a call. We are using the console/command line version of Twinkle, a powerful softphone application. Expect and screen are optional. I use them because I do.
apt install twinkle-console joe mpg321 openssh-server expect screen
Step 2:
Run Twinkle and configure it how you would like. alsa:plughw:1,0 is the snd-dummy driver microphone. Important parts of my reference configs:
/root/.twinkle/twinkle.sys
# AUDIO dev_ringtone=alsa:plughw:0,0 dev_speaker=alsa:plughw:0,0 dev_mic=alsa:plughw:1,0 validate_audio_dev=no
/root/.twinkle/twinkle.svc
dnd=no auto_answer=yes
/root/.twinkle/twinkle.cfg example values, not real. Use the IP address or FQDN of your SIP server
user_name=142 user_domain=192.168.1.22 user_display=142 user_organization= auth_realm= auth_name=142 auth_pass=42-put-realpasswdhere-42 auth_aka_op=00000000000000000000000000000000 auth_aka_amf=0000 # SIP SERVER outbound_proxy=192.168.1.22 all_requests_to_proxy=no non_resolvable_to_proxy=no registrar= register_at_startup=yes registration_time=1200 reg_add_qvalue=no reg_qvalue=1
Step 3:
Next, run twinkle-console and test. You can put the snd-dummy module in /etc/modules as well.
*/root/runtwinkle.sh
/usr/sbin/modprobe snd-dummy /usr/bin/twinkle-console
Step 4:
One tested, configure so this runs automatically at boot. Twinkle needs a console, and there are lots of ways to do this. This is one way and is easy to troubleshoot.
I like to add this to /etc/rc.local so it runs on bootup.
/usr/sbin/modprobe snd-dummy /usr/bin/amixer set Headphone 90% /usr/bin/mpg123 /root/iamalive.mp3
I'm not sure if twinkle-console will run forever or not, this is a hack method. I created a script and run it from crontab every 10 minutes.
/etc/crontab
- /10 * * * * root /root/keepitallrunning.sh
/root/keepitallrunning.sh
#!/usr/bin/bash ps -axf | grep twinkle | grep -v grep if [ "$?" == "0" ]; then echo "twinkle found" else echo restart attempt /root/star.expect & sleep 2 fi ps -axf | grep twinkle | grep -v grep if [ "$?" == "0" ]; then echo "TWINKLE IS ALIVE" else echo "TWINKLE NOT ALIVE" fi
Expect runs star.expect (twinkle twinkle little star)
#!/usr/bin/expect
#not proud of this, but sometimes you gotta make things work the hard way.
set timeout 720
spawn /usr/bin/twinkle-console
expect "# " { send "help" }
interact
So, in the end, you have a little Raspberry Pi plugged into an amplifier of some kind, that connects to your PBX (Asterisk/FreeSwitch/3CX/Hello Hub) that on boot up plays an MP3 file (a speaker test) then connects to the PBX as a phone extension/endpoint with auto answer turned on. If you dial the extension you have configured, it will auto answer and you can holler whatever you want over the PA system. This project has worked for me, at least twice. I've given variations of them to grateful ring-u customers. What I wrote up here is a starting point. Your methods and results may vary. –Mike–
Mesh, Sonos and VoIP
This is an edited version of an email from Phil (The “CEO”) to a customer that has at least 1 mesh network (maybe 2) and constant VoIP issues. He's using Luxul and Eero.com mesh WiFI trying to cover a large building without installing proper ethernet cables and solid real multi-use Access Points (Ubiquiti as an example). Add Sonus speakers, with a lot of chatter.. and you got issues.
The email
Chris,
I don’t have much to report other than a rethink on something we already discussed.
You said that you took one of the phones down and plugged it into a switch/router/ethernet port directly. This didn’t change the behavior, still poor sound quality.
I didn’t catch this at the time but here’s the thing:
The phones have 2 MAC addresses, 1 for the wifi side, the other for the wired side. To actually get the phone to work, you have to plug it in via ethernet, then add a new extension in our interface, and THEN turn off the wifi on the phone, turning it into a “wired only” device. Following this procedure is the ONLY way to test the wired vs wifi thesis. If you do this and you have good, or even improved sound quality it helps us to find the correct solution.
My gut says that the only way to fix this properly is with an IT person on site, and possibly the creation of a separate wifi network that would use conventional wifi tech such as the access points made by Ubiquiti (Ubiquity Uni-Fi) and others. You have a large and complex network, that needs active management to set it up properly for SIP/VoIP use.
Suggestions: (some may not apply as I do not know what equipment you have)
1. Do not use a modem/router provided by your service provider. Far better to use a cable modem from Motorola, Netgear etc ($50-100), and a separate router (Ubiquiti Edgerouter or other semi-enterprise grade gear $80-200). We are happy to make suggestions.
2. Your network needs to be flat: Only 1 device can be set up for DHCP. (Yours may be, we haven’t gotten that deep yet).
3. Mesh networks and VoIP are not the best of friends. Better to run the VoIP side off of traditional wifi via access points.
4. Some of the network segmentation may be possible using v-lans instead of a physically segmented network, but this part will very much depend on your network map/topology.
5. There are a fair number of people in the Sonus forums that have consistent network issues. Let me explain why: Sonos is the best at what they do for many reasons, one of which is that the music being streamed to multiple endpoints remaines in perfect sync, not even a millisecond delay or lag. If there were lag, it would create an echo/surround effect changing the music considerably. The only way to keep multiple endpoints in perfect sync is to have them talk to each other over the network constantly and check/adjust their “timing”. This creates an enormous amount of continual “chatter” on the network. This can be particularly troublesome on the wifi side of the network. When you disconnected the Sonus endpoints did you get ALL of them including the “master” at the head of the system? If a single unit is left on it will try and find all of the other units that it used to be speaking to in order to maintain sync. It is also possible that the Sonus is NOT the issue.
The advantage of implementing these suggestions is that anyone’s devices and services should work properly if these steps are followed and maintained.
We really do want to help you, but there is very little we can actually do regarding your network.
This can be very frustrating. I know from personal experience of chasing gremlins in my own network.
Reach out if/when you need further assistance. If you decide to hire an IT guy we are happy to work with them, or even speak to them before you hire them. There are a lot of IT folk that are not very well acquainted with SIP/VoIP and best practices.
Phil Sieg
Sonicwall, outgoing faxes and pain
A variant of a common email to people with Sonicwall firewalls.
The email:
Good Afternoon! I'll call in a minute as well.. what we see at is consistent with what we have seen at other locations with SonicWall and similar advanced firewalls. We can initiate an outgoing fax call, seems to be working well, until at exactly 1 minute and 6 seconds (very consistently) the UDP stream is blocked effectively hanging up the outgoing call. Mostly likely a 60 second timeout somewhere. This is often due to rules for SPI (Stateful Packet Inspection) or DDoS protection, dropping a mostly uni-directional UDP packet stream at a certain timeout threshold. For Sonicwall's specifically, the basic things to check are:
- Turn off “SIP Transformations” aka SIP ALG.
- Enable “Consistent NAT” with a timeout of several minutes. (likely problem)
- Set “SIP Media” and “SIP Signaling” timeouts to several minutes.
Helpful links:
Taxes Frelling Taxes/Fees in Texas
Just got asked a common question: We are in zip code 7606X.. and a Tax Exempt Church.. What would our bill be for 3 lines?
Real answer: We don't know until we bill you.
Almost real answer: Oh. You are in Texas. Probably more than anywhere else.
How ring-u calculates and pays taxes
Unless you are one of the really big guys (AT&T, etc..) who have their own people that do this. Ring-u pays taxes like everyone else, we pay for a tax compliance calculation service and pay what they tell us to pay. We use a real-time billing API from wolterskluwer.com for every invoice (and hopefully payment) we create. They keep track of every taxing authority in the country and when we bill, make sure we charge for every little tax and fee every tax creating state, county and municipality governmental agency plus the federal government. It changes constantly, because in Acme County next Tuesday the local E911 charge increases to $1.1225 per line but the right of way charge drops 0.25. You get the idea, things are always changing.
When we bill someone, the system talk to each other and calculate the taxes. We pay taxes calculated into a big bucket, and from their, they pay every taxing authority out there. We pay when we bill, because that's when the liability is created. Collections is our problem. Welcome to Capitalism 101. 99.99% of the time this works really well.
Because of this, we really don't know until we bill you. A combination of your address and your primary phone number us used to determine “situs”, a tax lawyer term for who gets to tax you. And next Tuesday, or the 1st of next month, it all changes.
Most places
Our basic plan customers are charged $59.95 per month. When taxes and fees are added, their bill usually comes to less than $70.00 per month. Not bad. Eh? $68 and $69 bills are very common.
Texas
Let me explain. I love Texas. My son Ryan was born in Ft. Worth and is a citizen of the Republic of Texas as well as the United States of America. Taxes in Texas are complicated and expensive. Let me share two examples, one, like the recent question is a Church. Texas is BIG. Larger than most countries.
Example 1:
This is a business in Texas, see that $10.56 per month fee? That's because Texas is spread out and the cost to bring you high speed internet is insane. All of those miles of muni-right of way to bury fiber on are a “revenue creation opportunity” as well as a real and valid expense. They charge you for it.
Example 2: Dallas is worse.
This is a big mega church in Dallas Yes, that $22.32 for the same thing. They also have 3 lines, a full suite of services and a couple of extra phone numbers. Ever done anything in Dallas? It's expensive.
Wireless VoIP/DECT Phone Ramble
We get asked about this a lot. This is a slightly cleaned up and generic version of an email I just sent out. Seems I sent something like this out once a month or more. It was time to add it to the Wiki.
Generic version of a common email
John,
We feel your pain with the basic Grandstream WP720/750 combo's. We stopped promoting them on our website… enough said? They work… mostly… the base box (the WP750) goes brain dead. It needs rebooting. We've seen better results with the newer WP752 base station, even with the older phones. Once subscribed to a new base they'll update firmware which will help. And even newer firmware on the WP750 may help. But.. they aren't my fav.
Yealink W60P/W56H
The Yealinks work a lot better than the Grandstreams as a DECT phone. There is even a high end version of the Yealinks for campus wide roaming across base stations (W80). But the W60 and W56H I have at home works well. I wish it had a better “clip”, I put a lanyard on it and use it when working from home outside. It's got great range. I hate the 2.5mm headphone jack… but as a phone it works very well and has good sound for a small handset. We have other customers using them and they are not getting negative comments like we have with the Grandstream 750/720
Grandstream WP820
Next interesting option is a GrandStream WP820. Once configured, this Android based WIFI (no base station) phone is awesome within your wifi coverage area. We have one in the office and it's what gets used when out and about in the office. We are in a commercial metal building, it does not reach our parking lot. Sound quality is very good and it works like a good VoIP phone should. Transfer, hold, etc.. features work well and it has a standard 3.5mm headphone jack.
We have issues getting them to configure sometimes. They go to deep sleep when not configured and we have to get someone to fiddle with the buttons to keep them awake. Once configured they are fine as they don't go to deep sleep. They can also be manually configured easily.
WP820's last over a weekend not plugged in.. If you have good WiFi coverage (and not a “mesh”) these are awesome. Our office has Ubiquiti AP's, but any good WiFi AP should work well.
Cisco 8821
You asked about the Cisco 8821. I've never seen a Cisco 8821, not even sure if it handles generic SIP in all flavors. If it does generic VoiP SIP then it will work, it'll just be an experiment figuring out a few settings. It's usually extension #, SIP server (Hello Hub) IP Address and a password. Cisco's sometimes need a few extra boxes checked. If you want to try, we will help.
Other
Same goes for any wireless VoIP phone. If it'll do industry generic SIP/VoIP, it'll probably be working in 5 minutes. Maybe 10 if we chat a lot.
Other mobile options: Generic “POTS” wireless phones plugged into a Grandstream HT802 ATA (POTS) phone adapters and cheap android phones mobile phones on WiFi using a VoiP “app” like Grandstream Wave or Zoiper. There are a lot of ways to make good dedicated wireless phones work. –Mike–