If you use snom phones it’s worth having a read though this security announcement dated 13/1/15 –
http://www.securityfocus.com/archive/1/534462/30/0/threaded
If your phones are in an untrusted public environment or accessible over the internet (it looks like it’s mainly the web interface that has issues) then it’s going to be absolutely critical that you update the firmware.
I’ve been using a Acer Chromebook C720 as my travel laptop for a few months now. It’s a really nice machine for web browsing and e-mail. It’s lightweight, keyboard is OK and battery lasts for ages.
It will play video fine and the screen is bright and responsive, but you obviously wouldn’t want to use it for anything too intensive.
It’s a Chromebook so just has the Chrome browser available by default. There are a couple of ways to get Linux running on it though. The first way, and the way I’ve been doing it for the past few months is Crouton – https://bicklp.wordpress.com/2014/04/29/c720-chromebook-installing-ubuntu-using-crouton/
This installs LInux on top of Chrome OS. So to run Linux you first boot into Chrome OS, then type a couple of commands in the terminal to start Linux. There are a couple of downsides … first it’s a bit fiddly to start Linux and second it relies on the drivers of Chrome OS. So the network, sound, screen etc are all setup inside Chrome OS, and then your Linux instance just uses those connections. I found that you couldn’t use it as an OpenVPN client because of this. Also I had issues with the sound and screen brightness sometimes conflicting because of the Chrome OS settings. Continue reading
Yesterday Schmooze announced a security update for FreePBX. This is an important vulnerability as it allows remote code execution (RCE).
For more information about the alert see here – http://www.freepbx.org/node/92822
By default SysAdminMan VPSs include additional security that means they are not vulnerable to this exploit. Additionally all SysAdminMan VPSs have been scanned to ensure the ARI interface is not publicly accessible.
It is still recommended that SysAdminMan customers update their systems with security updates released, including this one.
FOP2 makes a great addition to FreePBX, especially if you use your phone system in a sales environment. FOP2 is a web based panel for managing live calls on your PBX.
I’m going to write a few posts going over some of the features, and this post is designed to give you an overview of what FOP2 is and how it works.
My test phone system has 3 extensions linked to a SysAdminMan hosted FreePBX system –
FreePBX 12 is currently in beta testing but there is an option on FreePBX v2.11 called “FreePBX Upgrader” to allow upgrading to FreePBX 12. It is not overly obvious that this currently upgrades you to a beta version.
If you are running on CentOS 5 it is recommended that you do not run this update as it will break your FreePBX install.
This is caused by the way that the module update routine checks for available updates (using wget -q).
There is no intention to fix this issue so FreePBX 12 will not run on CentOS 5 (without some manual intervention). More details about this can be found here – http://issues.freepbx.org/browse/FREEPBX-7994
This post looks at reports from last year which I must admit had passed me by. They show how using a SIP device with a vulnerable router could leave you seriously exposed to VOIP fraud calls.
The reports focus on the BT Home Hub 3, but now that I’ve read it’s possible with one router, I have concerns that others could be affected.
When you have a SIP phone at home (or in the office) this is what you would expect to happen –
What actually happens on the HH3 (at least the firmware in the reports, this could have been resolved in later firmware) is this –
The difference is fairly subtle, but the result is not. This means that while your phone (SIP device) is switched on and connected to a remote Asterisk server or call provider, any SIP scanning against your public IP will get forwarded to the phone.
If the dial plan on the phone allows calls to be placed, then those calls would be completed. This could result in expensive VOIP fraud calls.
What should you do?
I recommend that everyone run a SIP scan on their public IP (this is your home/office IP) to ensure that no SIP devices respond. If they do and you are a SysAdminMan customer then please open a support ticket to discuss this more.
You can run a SIP scan from this site – http://sipscanner.voicefraud.com/
If you find any affected routers that are not the BT HH3 please post a comment.
You can find more info here –
Thanks, Matt
Getting some routers working with VOIP can be a pain. The problem is caused by NAT, and the translation of a private IP address (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) in to a IP address that works on the internet.
This is difficult with SIP/VOIP because IP addresses are not only included in the packet header, but also inside the packet itself. There are various methods that can be used to try and resolve this issue, and various places that ‘fixes’ can try and work.
The issue is this …
There are a few different methods to try and ‘fix’ the issue
The 3 things working above can cause chaos, and failed calls!
The most difficult to troubleshoot is the firewall SIP ALG one as a packet will go in from the local network, some changes will be made!, and then the packet will be forwarded to the internet device. Some routers do a better job making changes to the packets than others.
I came across a great list written by Vonage including many routers and steps that can be taken to try and get them working with VOIP/SIP – https://support.vonagebusiness.com/app/answers/detail/a_id/21546
Setting up a trunk to a SIP call provider in Asterisk can be a pain. Even for me – and I do it a lot!
When we set up a SIP call provider in Asterisk (a SIP trunk) and send calls to them our Asterisk server will send the call provider a SIP INVITE. Their system could respond in many different ways – decline the call, ask for user info, silently drop the call, process the call ….
Sometimes the call provider will send back information in the SIP reply as to why the call has failed. Maybe you have no credit, maybe the codec is not supported, maybe you have the number in the wrong format … but often they will not, they will just not process the call and send back a generic response.
At this point you need some help from the call provider. You need them to tell you why the call is not completing correctly.
Recently I was helping a customer set up a trunk to didlogic. His Asterisk server was sending the call to didlogic, but their system was responding with a fairly generic reply, indicating the SIP credentials were incorrect.
They seemed either unable or unwilling to investigate why this was. Even after being provided with SIP traces they showed no interest, just replying with generic suggestions that were no help.
It turned out that creating a new SIP account in the didlogic web portal resolved the issue. The old SIP credentials didn’t work, the new SIP credentials did.
I get asked a lot for call provider recommendations, and this is the only experience I have with didlogic, but based on it I couldn’t recommend them.
If you are having issues sending SIP calls to them (and getting just s SIP 407 back) maybe try creating a new set of SIP credentials in the didlogic portal.
Update 30/5/2014
I had a response to this post from DIDLOGIC which sounds encouraging. This was the reply –
Hello Matt,
Thanks very much for taking the time to detail these issues. It has been a couple of months and we have made our maximum effort to get a handle on the situation with authentication errors related to various flavors of Asterisk.
We apologize for causing your such inconvenience. Please be advised that there is now much more scope for troubleshooting these rare occurrences, as we have invested heavily in improving our support and customer service.In case you ever run into such difficulty again, please send a short message to [email protected] and CC the engineer assigned to your account. All system builders and VoIP consultants integrating our SIP trunking solutions for their clients get a dedicated point of contact and such trivial issues are dealt with immediately.
Thanks again for trying our services.
A little while ago I wrote some instructions for setting up a DDI with UKDDI. At the time this involved forwarding the call to a SIP URI and setting up a couple of trunks.
The nice folks at UKDDI have made this process much easier. Now we can register our FreePBX server with them, and they will send the calls to our registered IP address. The process of registration tells the remote provider who we are and what our IP address is, so that they can send calls to us.
Setting up our number in UKDDI
First we need to tell UKDDI that we will be registering with them and how to send the call to us.
Edit the number you want to use and set ‘Route’ to be ‘register’. You can also choose the codecs allowed. I suggest leaving this on G711 as it’s the best call quality, and G729 may not be available on your system
UKDDI route
Microtik RB750GL
For a while now SysAdminMan has been offering FreePBX/A2Billing hosting with OpenVPN server already installed on the server. What I really want to find is the perfect client/router that’s simple to configure and easy to deploy. We’ve been recommending OpenWRT for a while now but it can be a pain to flash the firmware and get OpenVPN configured.
I’ve also used Microtik routers for a while and they are very powerful routers in such a small, reasonably priced, package. This test was done using a Microtik RB750GL
I wasn’t sure how it would work though as Microtik routers only support OpenVPN over TCP, not UDP. This means all the VOIP traffic will be running over a TCP connection which, in theory, is not ideal.
This performance testing was done using –
We start off with 10 concurrent calls, then 20 and finally 40.
10 CONCURRENT CALLS
Here you see we have sipp generating 9 G711 calls with audio
sipp 9 calls