Category: FreeSwitch

I no longer recommend using Asterisk’s Google Voice support — try these methods instead!

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

EDIT (May, 2018): FreePBX and Asterisk users that wish to continue using Google Voice after Google drops XMPP support should go here: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware.

This article was originally written in January of 2012, and has been heavily edited in an attempt to update it a bit.

Not that anyone probably cares what I think, but anyone who regularly reads this blog (or any of the other VoIP-related blog that cover Asterisk) may have noticed that prior to the release of Asterisk 11, Asterisk’s support for Google Voice had become less and less reliable over time, particularly for incoming calls. You have to do all sorts of “tricks” to make it work, and these usually involve adding delays that don’t always fix the problem, inconvenience your callers, and possibly cause more hangups as people get tired of waiting for you to answer the phone.

Therefore, I suggest that if you are using a version of Asterisk earlier than Asterisk 11, you stop using Asterisk’s Google Voice support completely. Assuming that you feel you must keep using an older version of Asterisk, I suggest trying one or more of the following:

  1. Use YATE as a gateway between Asterisk and Google Voice. See Using YATE to overcome Google Voice issues in FreeSWITCH and Asterisk, this article and this forum thread on YATE in a Flash, and this thread on YATE Tips & Tricks). YATE is what powers Bill Simon’s gateway (mentioned below). See comments by Bill and pianoquintet under this article.
  2. Use Bill Simon’s Google Voice-SIP gateway to handle your Google Voice calls. Some people may not want to rely on an external service for this, while others may very much appreciate having the option. I mention it for those in the latter group. For more information see Bill Simon’s Free SIP-to-XMPP Gateway Easily Puts Google Voice on Your VoIP Phone (Voxilla). While the linked articles talk about using the gateway with a SIP device, it can be used as an Asterisk trunk.  EDIT: As of April 7, 2015 the Google Voice Gateway has been relaunched and there is now a one-time fee to sign up.
  3. If your only issue is with incoming calls, you could use a DID to bring the calls into your system.  But keep in mind that Google Voice does not like it when calls are answered the moment they connect, so in your FreePBX Inbound Route be sure to set the “Pause Before Answer” option to at least 1.  I have found that a 1 second pause is sufficient, but I’m not saying that is the correct value for everyone, or even that everyone will need to include such a pause (some DID providers may delay the call sufficiently before connecting through to your system that the pause isn’t needed).

At this point, any of those would likely produce better results than using the Google Voice support in any version of Asterisk prior to Asterisk 11.

EVERYTHING in this article is my personal opinion.  Nothing here should be taken as a statement of fact.

EDIT:  Ward Mundy reports that he just may have found a workaround for the incoming calls issue — see this thread in the PBX in a Flash forum.

Using a dynamic DNS (DDNS) to solve the problem of keeping a firewall open to remote users at changeable IP addresses

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

(Updated July 1, 2011 to include rudimentary test for string returned that doesn’t contain an actual IP address)

One problem faced by Asterisk users (and probably also users of other software PBX’s) is that you want to secure your system by not opening ports up to the entire Internet, but if you have remote users (users not on the same local network as your Asterisk server) you need to make an exception for them to allow them to penetrate your firewall.  If all your external users have fixed IP addresses, it’s not a problem — you simply add a specific rule in your firewall to permit access from each user’s IP address.  However, if their ISP changes their IP address frequently, or if they are using a softphone on a laptop computer, then you can’t just assume they will constantly be at same IP.  And if one of those users happens to be your boss or your mother, they are not going to be happy if they can’t use the phone until they make contact with you, and you enter their new IP address in the firewall.  And they’re probably not going to be real happy if they have to go to a web site or take some other action before they can make and receive calls.

This solution will work for many users in this situation, provided that you are using the iptables firewall. Again, the goal is to keep all your ports closed to outsiders, except for your authorized users. But if you can get each user to set up a Dynamic DNS account and then set their router to do the Dynamic DNS updates (as described here for DD-WRT users), OR failing that if you can get them to install a software Dynamic DNS client on their computer (which is a poorer choice because the computer has to be on for updates to occur), then you can run a script on your Asterisk box every five minutes to check to see if their IP address has changed, and if so, update iptables. I have one script that is called as a cron job every five minutes, and looks like this:

#!/bin/bash
/root/firewall-dynhosts.sh someaddress.afraid.org
/root/firewall-dynhosts.sh someotheraddress.afraid.org
/root/firewall-dynhosts.sh someaddress.no-ip.com

In other words it has one line for each Dynamic DNS host I want to check. For each host it calls a script named firewall-dynhosts.sh which in turn contains this:

#!/bin/bash
# filename: firewall-dynhosts.sh
#
# A script to update iptable records for dynamic dns hosts.
# Written by: Dave Horner (http://dave.thehorners.com)
# Released into public domain.
#
# Run this script in your cron table to update ips.
#
# You might want to put all your dynamic hosts in a sep. chain.
# That way you can easily see what dynamic hosts are trusted.
#
# create the chain in iptables.
# /sbin/iptables -N dynamichosts
# insert the chain into the input chain @ the head of the list.
# /sbin/iptables -I INPUT 1 -j dynamichosts
# flush all the rules in the chain
# /sbin/iptables -F dynamichosts

HOST=$1
HOSTFILE=”/root/dynhosts/host-$HOST”
CHAIN=”dynamichosts” # change this to whatever chain you want.
IPTABLES=”/sbin/iptables”

# check to make sure we have enough args passed.
if [ “${#@}” -ne “1” ]; then
echo “$0 hostname”
echo “You must supply a hostname to update in iptables.”
exit
fi

# lookup host name from dns tables
IP=`/usr/bin/dig +short $HOST | /usr/bin/tail -n 1`
if [ “${#IP}” = “0” ]; then
echo “Couldn’t lookup hostname for $HOST, failed.”
exit
fi

if [ ! `expr “$IP” : ‘([1-9])’` ]; then
echo “Did not return valid IP address, failed.”
exit
fi

OLDIP=””
if [ -a $HOSTFILE ]; then
OLDIP=`cat $HOSTFILE`
# echo “CAT returned: $?”
fi

# has address changed?
if [ “$OLDIP” == “$IP” ]; then
echo “Old and new IP addresses match.”
exit
fi

# save off new ip.
echo $IP>$HOSTFILE

echo “Updating $HOST in iptables.”
if [ “${#OLDIP}” != “0” ]; then
echo “Removing old rule ($OLDIP)”
`$IPTABLES -D $CHAIN -s $OLDIP/32 -j ACCEPT`
fi
echo “Inserting new rule ($IP)”
`$IPTABLES -A $CHAIN -s $IP/32 -j ACCEPT`

echo “Changing rule in /etc/sysconfig/iptables”
sed -i “0,/-A\sdynamichosts\s-s\s$OLDIP\s-j\sACCEPT/s//-A dynamichosts -s $IP -j ACCEPT/” /etc/sysconfig/iptables
# sed -i “s/-A\sdynamichosts\s-s\s$OLDIP\s-j\sACCEPT/-A dynamichosts -s $IP -j ACCEPT/g” /etc/sysconfig/iptables

echo “Sending e-mail notification”
`echo “This is an automated message – please do not reply. The address of dynamic host $HOST has been changed from $OLDIP to $IP. You may need to change the dynamichosts chain in Webmin’s Linux Firewall configuration.” | mail -s “IP address of dynamic host changed on machine name“ recipient@someaddress.com,anotherrecipient@someaddress.net`

As always, copy and paste the above script, so you can see where the line breaks are really supposed to be (the last line in particular is quite long, and will likely be broken up into four or five lines on the screen). Also, beware of WordPress or other software changing the single or double quotation marks to “prettified” versions — only the plain text normal quotation marks will work.

Note that prior to the first run of the script you will need to run the three commented-out commands shown near the top of the script, right after “create the chain in iptables”, to create the chain. For your convenience here they all are in one place, without the interleaved comment lines:

/sbin/iptables -N dynamichosts
/sbin/iptables -I INPUT 1 -j dynamichosts
/sbin/iptables -F dynamichosts

The lines in blue in firewall-dynhosts.sh are custom additions by me. Just in case something goes wrong, I suggest you make a backup copy of /etc/sysconfig/iptables in a safe place before running this script.  My first addition checks the first character of the string returned in $IP to make sure it is actually a number.  This was a quick and dirty addition to keep it from trying to use a string like ;; connection timed out; no servers could be reached as a valid IP address (yes, it really did that).  I’m sure that the test there could be improved upon (for example, to do a full check for a valid IP address rather than just checking the first digit) but as I say this was a quick and dirty fix.  If you have any suggestions on how to improve it, please leave a comment.  I did find this article, Validating an IP Address in a Bash Script, but it seemed like a bit of overkill considering that in this case what I’m really trying to do is simply weed out error messages.

The second set of additions change the address in the dynamichosts chain of /etc/sysconfig/iptables. Please note that this file may be at a different location in some versions of Linux (such as /etc/iptables.up.rules), if so you will need to change this accordingly. This is particularly important if you run both Webmin and fail2ban. If fail2ban is running it will add some lines to the in-memory version of iptables, so you don’t want to do a simple commit to save the in-memory version back to the iptables file. But at the same time, if you use Webmin’s “Linux Firewall” module to maintain iptables, you want any changes in IP addresses to show up the next time you call up Webmin’s Linux Firewall page. So this simply does a search and replace in /etc/sysconfig/iptables on the rule containing the old IP address, and replaces it with the new one. There are two lines in that section that contain the sed command, the first one will replace only the first instance of the old IP address if it’s in iptables more than once, while the second (which is commented out) would replace all instances of the old IP address. Uncomment whichever you prefer and leave the other commented out, but bear in mind that if two or more of your remote extensions might ever be at the same IP address at the same time, you want the first version (the one that is uncommented above) so that when one of those extensions moves to a different IP address it doesn’t change the IP address for all of the extensions.

Note there’s still a possibility of missing a change if you are actually working in Webmin when a change occurs (since you’ll already have loaded a copy of iptables, and if you then make changes and save it out it could overwrite any change made by the script). But, the last two lines of the script send you an e-mail to alert you to that possibility. If you don’t use Webmin and don’t need or want an e-mail notification for some other reason, you can omit those last two lines, otherwise change the parts in red text to sane values for your situation. While editing, pay attention to the backtick at the end of the line (it’s easy to accidentally delete it when editing an e-mail address — don’t do that!).

When you’re all finished, make sure both scripts are executable and the permissions are correct, then create a cron job to call the first script every five minutes.

The only slight drawback to this method is that when an IP address changes it can take up to ten minutes to update (five for the Dynamic DNS to pick it up, and five more for the cron job to fire that gets it from the Dynamic DNS). Fortunately, most ISP’s tend to change IP address assignments in the middle of the night. Note that using the wrong DNS servers can cause the updates to take significantly longer; I set my computers to use Google’s DNS (8.8.8.8 and 8.8.4.4) and that works fairly well. Note that if ALL your Dynamic DNS addresses are from freedns.afraid.org then you may want to change one line in the above script, from

IP=`/usr/bin/dig +short $HOST | /usr/bin/tail -n 1`

to

IP=`/usr/bin/dig +short @ns1.afraid.org $HOST | /usr/bin/tail -n 1`

This change will specify that the afraid.org DNS server is to be used for these lookups (and ONLY for these lookups, not for every DNS request your system makes – don’t want to overload the servers of this free service!). This may be particularly important if the DNS server you normally use is a caching server that doesn’t always do real-time lookups for each DNS request (for example, if you have installed the BIND DNS Server on your system). If some of the Dynamic DNS addresses come from other services then you could use a similar modification that checks a public DNS service that does not cache entries for long periods of time; as I write this Google’s DNS servers seem to update in near real time.

One thing some may not like is that this script basically hands the “keys to the kingdom” to your authorized users, by giving them access to all ports, or at least all ports not explicitly denied by rules higher in priority. It would be easy enough to change the rule that is written to iptables, or even add additional ones, in the above script, so that you could specify access to individual ports. The other problem is it works great for those external users at fixed locations that don’t move around a lot. It might not work quite as well as well for softphone users on laptops due to the delay between the time they turn on the laptop and the time your Asterisk server picks up the new address.

This has actually worked the best for me of anything I’ve tried so far because once you get the external user’s router set up to do the Dynamic DNS updates, they don’t have to think about doing anything else prior to making a call.

EDIT (December, 2015): If it is not possible or appropriate to update the dynamic DNS automatically from the users’ router, there may be another option. If any of your users have Obihai devices (or possibly another brand of VoIP device that includes an accessible “Auto Provisioning” feature that is not currently being utilized), you may want to know that they do not need to run a separate client to update their dynu.com or freedns.afraid.org dynamic IP address, because an Obihai device (and possibly some other brands of VoIP devices) can do that automatically. This is NOT a recommendation for Obihai devices, but if you or one of your users happens to already have one, here is the information as originally found in this thread on the Obihai forum, posted by user giqcass, who wrote:

Rough Draft for hackish DNS updates:

This hack will let your OBi update Dynamic DNS. It isn’t perfect but it works very well. It’s as simple as calling a url to update the DNS at afraid.org. I believe it would be a simple task to add this feature to the OBi firmware directly. So please add this OBiHai. Pretty please. Until then here you go.

Set up a Dynamic DNS host at http://freedns.afraid.org/
Go to the Dynamic DNS tab.
Copy the “direct” update url link.
Open your Obi admin page.
Click the System management page.
Click Auto Provisioning.
Under “ITSP Provisioning” Change the following.
Method = Periodically
Interval = This setting must be greater then 400 so not to over use resources. I use 3667.
ConfigURL = Paste the update link you got from afraid.org (use http://… not https://…)

Press Submit at the bottom of the page. Restart you OBi.

If you use choose to use dynu.com instead of freedns.afraid.org (which you might because dynu.com doesn’t force you to visit their web site periodically to keep your domain), the procedure is the same (after the first line), except that for the ConfigURL you would use:

http://api.dynu.com/nic/update?hostname=YOUR_DYNU_DYNAMIC_DNS&username=YOUR_DYNU_USERNAME&password=MD5_HASH_OF_PASSWORD

Replace YOUR_DYNU_DYNAMIC_DNS with your dynamic DNS domain name, YOUR_DYNU_USERNAME with the username you use to log into your dynu.com account, and MD5_HASH_OF_PASSWORD with the MD5 hash of your dynu.com password OR your IP Update Password if you have set one (which is recommended). To get the MD5 hash of the password you can enter it on this page. To set or update your IP Update Password, use this page.

The advantage of this is that if one of your users travels and takes their VoIP device with them, it would be able to change the dynamic DNS each time they plug in at a new location (not immediately, but after several minutes at most), so that if you use the technique outlined in this article your server will recognize their current address and permit access. Remember that it’s okay to use more than one Dynamic DNS service simultaneously, in case you or your user are already using a different one that doesn’t provide a simple update URL like dynu.com and freedns.afraid.org do. Other brands of VoIP adapters that have a similar “Auto Provisioning” feature may be able to do this as well, but we don’t have specific information for any of them. If you do, please feel free to add that information in a comment.

Note that we are not recommending any particular free dynamic DNS service. If you want to know what your options are, there is an article on the Best Free Dynamic DNS Services that will show you some options. You want one that is reliable and that will not disappear in a few months, but since we don’t have a crystal ball, we can’t tell you which ones might fit that criteria.

Link: Monit: Disk space monitoring

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This article was originally posted in February, 2011 and may be out of date. You may also wish to read Link: How to Install and Setup Monit (Linux Process and Services Monitoring) Program.

A hard disk drive with the platters and motor ...
Image via Wikipedia

Here’s an article that will be helpful to may of you who are running PBX servers under CentOS, especially (but not limited to) those running on virtual machines with low disk storage space.  Note that if you installed from an “all-in-one” distribution ISO, this possibly might already be installed, but may still need to be configured.

One thing you definitely don’t want to happen to your server is for it to run out of disk space, especially the root partition.

There are lots of pieces of open source monitoring software, a popular one being monit.

Below is a quick guide to installing monit and generating alert e-mails for disk space and cpu/memory usage. The installation was done on a SysAdminMan VPS running CentOS 5.5

Full article here (SysAdminMan)

The instructions should work for any system running CentOS 5.5.  You might be tempted to take a shortcut and just do “yum install monit” but please be aware that (at least as of the day I’m writing this) it will get you a much older version of the software, so I suggest you stick with the instructions in the article.  I have just now installed this on one system and have not fully tested it, but it did send an e-mail confirming that it had started.

This is just another tool you can use to make your life a little easier and help you avoid a problem before it becomes a major headache!

Link: Interesting security technique for Asterisk and FreePBX users (may work with other SIP-based PBX’s also)

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This article was originally posted in November, 2010.

NOTE: For some reason WordPress absolutely hates it when I try to edit this post, and turns links and other things into piles of steaming poo.  If things don’t look right here please e-mail me or leave a comment and I’ll check it out.  WordPress, I KNOW how I want my articles to look, why can’t you just leave them alone?

One problem faced by some SIP-based VoIP PBX administrators is the issue of security when you have external extensions (that is, extensions located anywhere in the world that’s not a part of your local network). You want to allow those extensions (the ones you’ve authorized) to connect to your system, but you prefer to keep everyone else out, and preferably not even tip them off that there’s a PBX there. The idea is, if the bad guys that would like to break into PBX’s don’t even realize that there is a PBX at your IP address, they won’t waste any time trying to crack into your system.

There have been other suggestions for how to handle this but many of them require your users to take some additional action(s) that they would not normally have to take, and users hate having to lift a finger to do anything to enhance their security. Which brings us to a rather clever technique that doesn’t require user to do anything other than use their phones as they normally would. It might be a tiny bit of a pain to set up initially, but the results may be worth it. I would call this medium level security because if someone is sniffing your packets, this alone may not keep them out, but most of the lowlifes that try to break into PBX’s don’t actually have sufficient access to sniff your packet stream (and also, they’d have to know the exact technique you’re using to be able to crack this). So without further ado…

Secure your VoIP server with the SunshineNetworks knock

(As of October 24, 2012, the above link appears to be DEAD — see the edit at the end of this article)

Note that while the article recommends changing the SIP port to something other than 5060, their basic technique (the “knock”) should still work even if you feel you need to stay on 5060. My only fear about changing the SIP port would be the possibility of losing communications with VoIP providers and with other systems I legitimately send/receive voice traffic to/from. They’re probably going to keep using 5060 even if I don’t. EDIT: My concern here may be unfounded — note the comment below from Alex of Sunshine Networks, who said that “changing the SIP port is quite safe. Your SIP server will send this SIP port along in it’s first SIP invite registration to the VoIP provider. So unless your VoIP provider is actively blocking out anything else than port 5060, it should work fine. We use this technique with 3 different major SIP providers in Australia and never had problems. So far we haven’t seen any unintended consequences.”

I haven’t personally tested this, so if you do, please consider leaving a comment to let me know how it worked for you. The two things I wonder are, do these rules survive a reboot, and can you have more than one secret phrase that would let people in (in case you want to use a different one for each external extension)? EDIT: Those questions are also addressed in Alex’s comment below. Also, those of you running PBX in a Flash should take note of Ward Mundy’s comment about changing an entry in /etc/sysconfig/iptables in this thread. In that same thread, there appears a method to view the “knock” each extension is currently sending — just do “sip debug” from the Asterisk CLI for an hour or so (long enough for all your endpoints to register, after which you can use “sip no debug” to turn it off), then run this at the Linux command prompt (not from the CLI!):

grep "From: " /var/log/asterisk/full|cut -f1 --delimiter=; | sort -u

For each of your remote extensions, you’ll see a line that looks something like this:

From: The Knock <sip:234@nn.nn.nn.nn>

“The Knock” may or may not be enclosed in quotation marks, but it apparently doesn’t matter (you don’t include them in the iptables rules). If you haven’t used a specific “knock”, it could be the actual user’s name, if you set that up when you first set up the endpoint. Anyway, I’d suggest running this BEFORE you actually implement the iptables rules, so you know ahead of time what each endpoint is sending.

EDIT (Added January 8, 2012): I am now using a slight variation on this technique on one of the systems I administer. Without going into too many specifics, I will just note that some SIP devices and VoIP adapters actually already send a unique string that you can use as a “knock” – you do not have to configure a new one, you just need to find out what the device is already sending and use that. For example, let’s say you have an VoIP device connecting to your Asterisk server as extension 234. All you have to do is go to the Asterisk CLI (NOT the Linux command prompt) and enter this:

sip set debug peer 234

(Replace 234 with the actual extension number). Now, assuming that the device is connecting to your server, you will start to see SIP packets scroll across your screen. Within a few minutes you should see one like this (IP addresses have been xx’ed out):

<--- SIP read from UDP:xx.xx.xx.xx:5061 --->

REGISTER sip:xx.xx.xx.xx:5060 SIP/2.0
Call-ID: e10700c2@xx.xx.xx.xx
Content-Length: 0
CSeq: 56790 REGISTER
From: <sip:234@xx.xx.xx.xx>;tag=SP8f427e45f1e19cb24
Max-Forwards: 70
To: <sip:234@xx.xx.xx.xx>
Via: SIP/2.0/UDP xx.xx.xx.xx:5061;branch=z4b9hGK-4f0473a8;rport
Authorization: DIGEST algorithm=MD5,nonce=”37cd169d”,realm=”asterisk”,response=”a726bfed5db321a7bc967b997b5157c2″,uri=”sip:xx.xx.xx.xx:5060″,username=”234″
User-Agent: xxxxxx/xxxxxx-x.x.x.x
Contact: <sip:234@xx.xx.xx.xx:5061>;expires=60;+sip.instance=”<urn:uuid:nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn>”
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER
Supported: replaces

<————->

If you don’t see this you may need to increase the debug level. After you see a packet like this, you can turn off sip debugging:

sip set debug off

The string you are looking for is in the Contact: string above (the nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn is replaced by a unique string). So, where in the instructions for the “knock” they show a sample string such as:

iptables -I door 1 -p udp --dport 5060 -m string --string "mysecretpass" --algo bm -m recent --set --name portisnowopen

I would change the --dport parameter to 5060:5061 (since an VoIP adapter sometimes uses port 5061 for the second service provider — for an device that allows up to fours service providers, use 5060:5063) and the --string parameter to “<urn:uuid:nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn>”, but using the actual string sent by the device, of course. I know the Sunshine Network people recommend using something other than port 5060 but I just can’t bring myself to go quite that far, and even their examples show 5060.

Some other SIP-compliant devices also send unique strings in their REGISTER packets. One that does NOT do so, as far as I am aware, is the venerable Linksys PAP2. And I also do not believe that any of the Sipura line of devices send such a unique string.

Naturally, if an intruder KNOWS you are using that technique, they could try a brute-force attack on the unique string. So I recommend only using this with “uncommon” extension numbers (not 200 or 1000, for example) and with a VERY strong secret/password on the SIP connection. But it is another line of defense against would-be intruders!

EDIT (Added October 24, 2012): The original article, and most of the original site for that matter, seems to have gone offline. While I’m not going to repost the original article here without permission, I will give you a few more details and a couple of excerpts. First, they advised that you change the SIP port to something other than 5060 – they suggested using something in the range 20001 through 49000, though I am not sure why. They uses port 34122 in their examples, and noted that if you are running PBX software that has a “SIP Settings” module, if your find a setting for “Bind Port”, that would be the one to change. Of course if you do this, you then have to change the SIP port on ALL your SIP-based phones and VoIP adapters.

With regard to the “knock” itself, they said this:

Technical information :
… Technically, our knock consists of a secret passphrase which is sent together with the first SIP packet from the phone to the server. SIP packets are text files, very much readable like http packets are. The SIP headers in a REGISTER invite packet have a lot of information, and one of those headers is called the “Display Name”. This display name is used only internally in your Asterisk server and has no other use, so we figured we could fill in anything and the Asterisk functionality would still work fine. We decided to use it as a port knock password.

How does it work :
The Asterisk administrator sets up a simple iptables rule. The iptables rule checks for a secret phrase inside packets sent to the SIP port ( 5060 by default, 34122 after having changed it ). Unless it finds this secret phrase, it will drop the packets to this port. All the remote phone has to do is fill in the “User Name” SIP property on his SIP phone with the secret phrase, and he will be able to connect.

What you then needed to do was to go to into your Asterisk server and from a Linux command prompt, issue the following command:

iptables -N door

Then for EACH “knock” string you want to use, you would do this from the command prompt (note this is only one line, and note that 34122 is the example port and “mykn0ckstr1ng” is an example “knock”):

iptables -I door 1 -p udp –dport 34122 -m string –string “mykn0ckstr1ng” –algo bm -m recent –set –name portisnowopen

If you have anyone that needs to register with your server but cannot send the “knock”, but is at a fixed IP address, you’d add a line like this for each instance (again the port and ip address would probably need to be changed, and note that an entire subnet can be specified as in this example — just leave off the /24 if it’s a single ip address):

iptables -A INPUT -p udp –dport 34122 –source 10.10.1.0/24 -j ACCEPT

Then you would enter these three lines, but again using the correct port rather than 34122. In the first line you see the number 4000 — that is amount of time in seconds that the port will be open, and should be greater than 3600 because that’s the default registration timeout for many sip phones and VoIP adapters. The original article notes that you could use 86400, which is a full day:

iptables -A INPUT -p udp –dport 34122 -m recent –rcheck –seconds 4000 –name portisnowopen -j ACCEPT
iptables -A INPUT -p udp –dport 34122 -j door
iptables -A INPUT -p udp –dport 34122 -j DROP

And finally, to make iptables use these rules, you’d enter:

service iptables save

The original Sunshine Networks article notes that…

This code keeps port 34122 closed ( DROP ) unless someone has opened the door ( door ) in which case they are allowed to pass the door for a little more than 1 hour ( 4000 seconds ). Each time the phone re-registers , the SIP secret pass header is sent, and the door is reopened for 4000 seconds. Since the default SIP reregistration time on many phones is 3600, the 4000 seconds will make sure that as long as the phone is connected to the SIP server, or needs to be connected, the dynamic firewall rule is always active.

Once you have done this, if you configure the Display Name or User Name setting with the “knock” string, it should be able to get through your firewall. Any phone that doesn’t have this string won’t. Of course you can always make the “knock” something that a phone already sends (in a SIP register packet), as noted in the previous edit, and then you don’t have to reconfigure the phone at all. If a phone or device tries to connect without sending the “knock”, the firewall won’t allow it (assuming you haven’t previously created some other rule that allows the traffic to pass) and the connection will fail, or at least that is how it’s supposed to work (I make no guarantees because I didn’t come up with this).

If you enter the command cat /proc/net/ipt_recent/portisnowopen you will get a list of IP addresses that have successfully used the “knock” to connect. Remember that after you implement this, it can take up to an hour for a device to attempt to reconnect.

If anyone ever spots the original article back online, please let me know and I’ll remove this edit. I’d rather you get the information direct from the original source anyway, and the short excerpts I have provided here don’t give the complete overview that the original article provided.

EDIT (February 23, 2014): It appears that there is an archived copy of that original article on the Wayback Machine, although we do not know if it is the most recent edit of that article prior to the site disappearing.

Link: Using FreeSWITCH to add Google Voice to Asterisk

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

EDIT (2018): This article is extremely out-of-date and in no way useful today, and will probably be removed from this site at some point in the future. You might find this article more useful: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware.

For those of you using Asterisk, Bill over at the PSU VoIP blog has come up with a way to interface Asterisk with Google Voice, by co-installing FreeSWITCH (which also supports Google Voice).  Turns out that Asterisk and FreeSWITCH can co-exist on the same server, though you do have to change the configuration a bit so they don’t compete for the same ports.  Anyway, Bill has come up with a how-to on adding Google Voice integration to current versions of Asterisk, so if that interests you, head on over and have a look:

Using FreeSWITCH to add Google Voice to Asterisk

The bonus is that once you get FreeSWITCH installed you can play around with it and look at some of its other features, if you are so inclined. Of course, the Asterisk folks could backport the Google Voice support to previous versions and make it unnecessary to do things like this, but I’m not holding my breath.

EDIT (January 26, 2012): The Google Voice channel drivers in Asterisk 1.8 have become unreliable enough (in my personal opinion, anyway) that I just used the technique shown in this article, and I must say that it works a LOT better than Asterisk 1.8’s Google Voice support.  I also added some comments to that article (probably too many!) that among other things show how I got it working for multiple Google Voice accounts.  So I would now recommend using this method to bridge Asterisk to Google Voice in preference to using Asterisk 1.8’s native channel drivers (unless you are very short on memory and/or storage space) — it just works, and calls connect faster.  Read the article AND the comments under it first, so you’ll know what to expect, and do be aware that it takes a relatively LONG time to compile and install FreeSWITCH (compared to Asterisk).  At points during the installation it may look like it’s stuck in an endless loop, but it really isn’t. Just go away and take a walk outside or something, and come back in a while and it should be done.

Related articles

Review of FreeSWITCH 1.0.6 by Anthony Minessale, Darren Schreiber, Michael S. Collins (Packt Publishing)

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog. In order to comply with Federal Trade Commission regulations, I am disclosing that he received a free product sample of the item under review prior to writing the review, and that any links to Amazon.com in this article are affiliate links, and if you make a purchase through one of those links I will receive a small commission on the sale.
Cover of FreeSWITCH 1.0.6

In case you’ve never heard of FreeSWITCH, it is a “telephony software engine”, which means it’s in the same category as Asterisk. Over the years I’ve noticed that some Asterisk users have become frustrated with Asterisk due to unfixed bugs and design flaws that mean that the software doesn’t always work as it should. So, for quite some time, I’d hoped that a viable alternative to Asterisk might emerge, if only to keep the Asterisk developers on their toes. Competition between software projects tends to be a healthy thing, and from what I’ve read in this book, it appears that FreeSWITCH just may be the software product that eventually replaces Asterisk as the open source telephony software engine.

Before I begin, as is my custom with such reviews, let’s start with a quick overview of what’s in each chapter (for the complete Table of Contents, see the Packt Publishing web site):

  • Preface
  • Chapter 1: Architecture of FreeSWITCH – includes notes on the FreeSWITCH design and important modules
  • Chapter 2: Building and Installation – how to build and run FreeSWITCH under Linux/Unix, Mac OS X, or Windows
  • Chapter 3: Test Driving the Default Configuration – here you learn how to control FreeSWITCH with the CLI and to make your first call
  • Chapter 4: SIP and the User Directory – includes adding users, setting up voicemail, and setting up a gateway to connect to the world (link is to sample chapter in PDF format at the Packt Publishing site)
  • Chapter 5: Understanding the XML Dialplan – this gets into the “meat” of FreeSWITCH dialplan creation
  • Chapter 6: Using the Built-in XML IVR Engine – here’s where you learn one way to build an IVR (auto-attendant)
  • Chapter 7: Building IVR Applications with Lua – really an example of using a scripting language with FreeSWITCH. A few other languages are supported
  • Chapter 8: Advanced Dialplan Concepts – if Chapter 5 was the hamburger, this is the sirloin
  • Chapter 9: Controlling FreeSWITCH Externally – explains the event system architecture, and how to read and send events
  • Chapter 10: Advanced Features and Further Reading – includes multi-user conferencing, billing, XML/Curl, alternative endpoints, and configuration tools and related projects

There are also two appendices:

  • Appendix A: The FreeSWITCH Online Community
  • Appendix B: The History of FreeSWITCH

The  Packt Publishing web site also has this to say about the book:

What you will learn from this book :

  • Set up a basic system to make and receive phone calls, make calls between extensions, and utilize basic PBX functionality
  • Avoid common implementation mistakes and deploy various features of this telephony system with best practices and expert tips
  • Perform routine maintenance for smooth running and troubleshoot the system when things are not going right
  • Apply regular expressions to unlock unique and powerful call routing scenarios
  • Call your own application(s) when particular events occur and control FreeSWITCH using the powerful Event Socket
  • Set up multi-party conferencing facilities for your system
  • Interact with callers, gather information, and route calls to the appropriate recipient using the automated, built-in XML IVR (Interactive Voice Response) engine
  • Create a flexible dialplan, and allow third-party tools to be quickly and easily created using dialplan parsers other than the default XML Dialplan
  • Park multiple calls in a FIFO queue and unpark them in the order in which they were received, using the mod_fifo module
  • Record an entire phone call or session using the call recording feature
  • Create advanced call control applications with the Lua scripting language
  • Take a peek into the vibrant online community and history of FreeSWITCH

Approach

This book is a step-by-step tutorial with clear instructions and screenshots to guide you through the creation of a complete, cost-effective telephony system. You will start with installation, walk through the different features, and see how to manage and maintain the system.

Who this book is written for

If you are an IT professional or enthusiast who is interested in quickly getting a powerful telephony system up and running using the free and open source application FreeSWITCH, this book is for you. Telephony experience will be helpful, but is not required.

Now, here are my impressions. Please bear in mind that I did not actually attempt to build a working FreeSWITCH installation (I would need yet another spare computer to do that), but I certainly feel as though I could after reading this book. One thing that is somewhat uncommon about this book is that the author of the software is also one of the authors of the book. Too often, when you see a book written about a piece of software, the writer doesn’t fully understand the software and therefore makes guesses and assumptions about how it works, that may lead to problems down the road if you follow their advice. When the software author collaborates on the book, that’s far less likely to happen, and indeed, at no point in this book did I get the feeling that the author was struggling to understand the subject. I will even go so far as to say that this is one of the best written technical books I have read in a long time.

The biggest complaint I had about this book — and it is a very minor one — is that it could have benefited from another proofreader. Occasionally I’d see an obvious error that the proofreader should have caught — nothing major, and nothing I couldn’t figure out with about two seconds of thought, with one exception.  On page 91 of the book, it appears to me as though there is some missing text at the bottom of the page.  It’s discussing making a test call to Music on Hold and then, suddenly and jarringly, it jumps into a time of day example.  I think the disconnect occurs in middle of a sentence: “In our example, call the debug output is as follows:”  The sentence as written does not make sense to me, and it appears a block of text (perhaps a large one) may have been omitted at this point. But that is the only place in the book where I encountered an error of that magnitude. I have submitted the error to Packt Publishing and I’m hoping they will figure out what was supposed to go there and place it in the errata section of their web site.

One other point I will make about a software author writing a book on his own creation is that I think sometimes, it’s difficult for the author to correctly envision how end users will want to use the software.  As an example, virtually all the dialplan examples in this book are in XML.  There may be advantages to using XML, but it’s not going to be very familiar to someone coming from an Asterisk background, and I might have wished for a few non-XML examples.  On pages 158-159, the author notes that,

There is a common misconception that the FreeSWITCH Dialplan is based on, and requires, XML. That is simply not true. If you prefer flat files, you could use them to store your Dialplan configuration. If you prefer YAML, you could use that, too. You just need to load the correct C-based Dialplan module to interpret your stored logic for the particular type of configuration file you want FreeSWITCH to utilize.

This aside, the most common (and currently, the most robust) Dialplan processing mechanism in FreeSWITCH is still the XML-based Dialplan module. Most Dialplan examples that are shipped with FreeSWITCH, or those scattered on the Web are in XML, therefore, they will remain the focus of this chapter. …..

Indeed, there is even an Asterisk dialplan module, albeit with limited capabilities.  From page 199:

If you are used to the Asterisk Dialplan, some basic functionality is provided by the Asterisk Dialplan module, although it is not nearly as feature-rich as the XML engine. You can process contexts and route calls to phones using the Asterisk Dialplan. This module, again, is more of a sample on how to build an alternate Dialplan processing module and should not be utilized as a full, feature-rich Dialplan system.

Yet you won’t find examples using flat files, YAML, or Asterisk Dialplan in the book.  However, the XML examples were clearly written and easy to understand, so I don’t think that there would be a steep learning curve to start writing dialplans in XML, assuming you are a proficient enough coder to write dialplans in the first place.  And, I suspect that XML would be easier for a new user to pick up than any of the other options.

I mention the above to emphasize two points:  FreeSWITCH is different from Asterisk. If you are thinking about moving from Asterisk to FreeSWITCH, you need this book to get you up to speed on the differences.  And second, FreeSWITCH is both more capable than Asterisk, and arguably easier to use, once you get used to the differences (or if you have no prior experience with similar software). FreeSWITCH appears to have been designed from the ground up to avoid the issues that have plagued Asterisk, particularly those that cause Asterisk to fall to its knees under heavy load or heavy call volumes. Even if you’re a long-time Asterisk user, you may want to get this book just to see what you’re missing.  You might decide that it’s worth your effort to set up a test system using FreeSWITCH, to help you understand how much better the next generation of telephony software engines can be.

One other point, in case you are reading this review several months after I wrote it — the author notes this in the preface:

At the time of this writing this book, the FreeSWITCH developers were putting the finishing touches on FreeSWITCH version 1.2. While the examples presented in this book were specifically tested with version 1.0.6, they have also been confirmed to work with the latest FreeSWITCH development versions that form the basis of version 1.2. Do not be concerned about the fact that this material does not cover version 1.2—it certainly does. The FreeSWITCH user interface is very stable between versions; therefore, this text will be applicable for years to come.

There will no doubt be some of you who are reading this that wonder if there are any Web GUI “front ends” (dialplan and configuration file generators) for FreeSWITCH.  Indeed there are, and they are covered in Chapter 10, which briefly explains the differences between WikiPBX, FreePBX v3, FusionPBX, and 2600hz.  Even if you plan on using a Web GUI, there may be times when you find the need to write a bit of custom code, and in that case having this book available would definitely be helpful to you.

One other thing I personally found interesting in this book was Appendix B, “The History Of FreeSWITCH.”  This explains how FreeSWITCH came to be, and along the way offers further explanation on how it is different from Asterisk and why the developers felt the need to start a new project.  What I think I found most interesting (and perhaps unfortunate, depending on your point of view) is that FreeSWITCH could have been the basis for Asterisk version 2, had only the Asterisk developers reacted positively to the idea. I see this sort of thing happen occasionally in the open source community, where the lead developers of a project start to develop an attitude that does not encourage outside contributions (or, they treat contributions or suggestions for improvement as if they were piles of steaming dog poo on their doorstep). Perhaps this should serve as a cautionary tale to such developers that your project can always be replaced by something better, if you do not encourage contributions to your own project from those not currently in your “inner circle” of developers.

As you may know if you have read my previous reviews, it’s rare that I get wildly enthusiastic about a book.  In this case I’ll make an exception, because overall the book is that well-written (my comments above notwithstanding). If you have any interest at all in using FreeSWITCH, or are even just curious about it, you really should buy this book.  It’s available in both traditional softcover dead-tree format, and as a DRM free Adobe PDF eBook, and there’s even a package deal if you want both formats. Don’t forget that you can view a sample chapter (PDF format) prior to purchase. EDIT: Also, there is an online article by the book’s authors entitled FreeSWITCH: Utilizing the Built-in IVR Engine.

FreeSWITCH 1.0.6 by Anthony Minessale, Darren Schreiber, Michael S. Collins (Amazon affiliate link)

Related: Review of FreeSWITCH Cookbook by Anthony Minessale, Michael S Collins, Darren Schreiber, Raymond Chandler (Packt Publishing)

Review of Building Enterprise Ready Telephony Systems with sipXecs 4.0 by Michael W. Picher (Packt Publishing)

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog. In order to comply with Federal Trade Commission regulations, I am disclosing that he received a free product sample of the item under review prior to writing the review, and that any links to Amazon.com in this article are affiliate links, and if you make a purchase through one of those links I will receive a small commission on the sale.

This article was originally published in December, 2009.

Cover of Building Enterprise Ready Telephony Systems with sipXecs 4.0
Cover of Building Enterprise Ready Telephony Systems with sipXecs 4.0

Regular readers of this blog may recall that I recently reviewed another Packt Publishing book, FreePBX 2.5 Powerful Telephony Solutions by Alex Robar, and that my review was generally positive.  However, I have wondered for a while if there was going to be any serious competition for Asterisk and FreePBX that would also be open source, and freely available to anyone that cares to download it.  Well, this book discusses one contender – sipXecs by SIPfoundry.  You can look over their web site to get some idea of what sipXecs is, but in one respect it’s along the same lines as FreePBX, in that it provides a web-based GUI that allows you to do all the work of configuring your phone system from any web browser.  The book is called Building Enterprise Ready Telephony Systems with sipXecs 4.0 by Michael W. Picher.

I’ve never personally so much as laid eyes upon a working sipXecs installation, so this isn’t going to be a review of sipXecs per se.  But I suppose some are wondering what the difference is between sipXecs and FreePBX.  The impression I got from reading this book is that the two have some differences in features, and even where there is feature overlap, there are differences in the way those features are implemented.  If you are just counting features, FreePBX probably offers more, and many of those features have more configuration options.  FreePBX would probably work very well in a home or small office.  sipXecs, on the other hand, seems to have been designed by folks with experience in networking and larger business installations.  If you were trying to link several branches of a medium-sized to large corporation together, and it’s crucial to have 100% uptime (or as close to that figure as possible), sipXecs might be a better choice (at least until someone high in the corporate food chain demands a feature it doesn’t offer).  And if you’re a networking professional, you might find sipXecs more appealing.  This is definitely NOT to say that sipXecs could not be used in a home or small office setting, nor that FreePBX could not be used in a large corporation for that matter, just that each may fill a particular niche better than the other.

So I will concentrate on the book itself, and I’ll let the publisher have the first word.  Here is how they describe this book:

A clear and concise approach to building a communications system for any organization with the open source sipX Enterprise Communications Server

In Detail

Open source telephony systems are making big waves in the communications industry. Moving your organization from a lab environment to production system can seem like a daunting and inherently risky proposition. Building Enterprise Ready Telephony Systems with sipXecs delivers proven techniques for deploying reliable and robust communications systems.

Building Enterprise Ready Telephony Systems with sipXecs provides a guiding hand in planning, building and migrating a corporate communications system to the open source sipXecs SIP PBX platform. Following this step-by-step guide makes normally complex tasks, such as migrating your existing communication system to VOIP and deploying phones, easy. Imagine how good you’ll feel when you have a complete, enterprise ready telephony system at work in your business.

Planning a communications system for any size of network can seem an overwhelmingly complicated task. Deploying a robust and reliable communications system may seem even harder. This book will start by helping you understand the nuts and bolts of a Voice over IP Telephony system. The base knowledge gained is then built upon with system design and product selection. Soon you will be able to implement, utilize and maintain a communications system with sipXecs. Many screen-shots and diagrams help to illustrate and make simple what can otherwise be a complex undertaking. It’s easy to build an enterprise ready telephony system when you follow this helpful, straightforward guide.

What you will learn from this book

• Understand the complexities of an IP Telephony and Voice over IP network
• Build a clear process for migrating existing phone systems to an IP based system
• Deliver a solid foundation for any IP based phone system
• Quickly and easily get a sipXecs open source PBX running
• Deploy phones quickly and easily.
• Utilize Internet Telephony Service Providers to reduce monthly telephony bills
• Develop training materials to help successfully teach your users how to use the system
• Leverage sipXecs Automatic Call Distribution Queues to handle basic Call Center needs
• Operate and Maintain a reliable communications platform

Approach

This book was written to be a step by step approach to building a communications system for any organization. Care was taken to clearly illustrate with diagrams and screen shots all of the steps and concepts along the way. [Emphasis added – I’ll have more to say on that point!]

Who this book is written for

This book is written for network engineers who have been asked to deploy and maintain communications systems for their organizations.

And here’s the chapter list:

Preface
Chapter 1: Introduction to Telephony Concepts and sipXecs
Chapter 2: System Planning and Equipment Selection
Chapter 3: Installing sipXecs
Chapter 4: Configuring Users
Chapter 5: Configuring Phones in sipXecs
Chapter 6: Connecting to the World with sipXecs
Chapter 7: Configuring sipXecs Server Features
Chapter 8: Using sipXecs—The User Perspective
Chapter 9: Configuring Advanced sipXecs Features
Chapter 10: Utilizing the sipXecs ACD Service
Chapter 11: Maintenance and Security
Appendix: Glossary
Index

See the Table of Contents page to get a more detailed chapter breakdown.

Now, when I review a book, the thing I am looking at is whether the author accomplishes what he or she set out to do.  In this case, the intent of the book is to instruct someone in how to set up a working sipXecs PBX.  So, I look at whether the author seems to have a good grasp of his subject matter, and whether he can communicate his knowledge to the reader in a clear and understandable manner.   A third consideration is whether the book is a good value for the money.   Technical books often aren’t inexpensive, so I tend to mark them down if I perceive that there’s a lot of “filler” material in the book.

It’s difficult for me to decide how to rate this book.  Does the author understand his subject matter?  Yes, it certainly appears that he does.  Does he effectively communicate it?  Yes, the book was an easy read — I really didn’t feel like I was in “over my head” at any point in the book.  Could you set up a working sipXecs phone system after reading this book?  I think I could, but I can’t speak for anyone else.  In fact, in many ways, this was one of the clearest and most understandable technical books I’ve read.

You sense a “but” coming, don’t you?

Well, there is, and it’s a big one.  Did you notice above where the publisher said that “Care was taken to clearly illustrate with diagrams and screen shots all of the steps and concepts along the way”?  Well, the book definitely contains screenshots — a LOT of screenshots.  And normally, that would be very good thing, because as the saying goes, a picture is worth a thousand words.  A screenshot would not add value to a book only in the case where it was useless “filler” material, and it’s pretty apparent that none of the screenshots in this book were intended to just be “filler.”

But, for a screenshot to be useful and not “filler”, it has to be readable.  And in that regard, this book has a serious problem.   If you buy the hardcopy edition of the book, I’d strongly urge you to also buy a good magnifying glass, because you’re going to need it to get anything out of those screenshots, unless perhaps you have perfect vision.   Apparently the author (or whoever took the screenshots) has a widescreen monitor, and was running their web browser in full screen (or at least full width) mode.   As a result, most of the text in the screenshots borders on microscopic, and some of the smaller print is unreadable (by me, anyway).   When you take those extra-wide screenshots and reduce them to about five inches in width on a printed page, you need very good eyes (or good glasses) to make out the text.  After trying to decipher the details in those screenshots for a while, I started to get a headache!

At first I thought maybe it was my eyes going bad — I am getting older, after all — but then I opened up some of the other books I have in my collection, including other Packt Publishing books, and none of them suffer from this problem.  Frankly, if I were the publisher I’d stop the presses on this book immediately, and not let another copy go out the door until all the screenshots were re-done, but then that’s just me.

Now, that said, the book is not totally without value.  I think that perhaps the author just might have realized he had a problem, because in many cases he repeats in the text most of what’s in the screenshot (at least the portion to which he’s calling your attention), so not being able to actually read the screenshot isn’t always such a loss — but unfortunately, it also relegates the screenshots more toward the category of “filler.”

So, would I recommend this book? Yes, for two classes of readers in particular:

  • Those thinking about setting up an Asterisk/FreePBX system that would like to know about available alternatives.  It may be that the particular combination of features that you deem essential can only be found in one of either sipXecs or FreePBX, and by reading this book and the aforementioned FreePBX book, you’d have a pretty good idea of the differences in capabilities between the two.
  • Those thinking of installing a VoIP PBX in a larger organization, where reliability and scalability are far more important than the actual feature set.   My impression from the book is that sipXecs is designed with larger businesses and higher call volumes in mind.   That’s no reason that someone with a small business should shy away from it, but if you are very concerned about reliability and high “uptime” then you probably should at least give sipXecs some consideration.  And if your organization is large enough to have people with degrees in computer networking in your employ, they might prefer working with sipXecs.  This is not to say you can’t do a large installation using Asterisk, but now you have another choice, and this book can help you decide which is best in your particular situation.

If it weren’t for the screenshot issue, I’d be giving this book very high marks.  The focus of the book is deployment in a business setting, and the author takes you through the steps for planning and implementing the system, whether you are replacing an existing PBX or starting from scratch.  Having some knowledge of computer networking would be helpful, but as I noted, I’m no networking expert and yet I didn’t feel totally lost.  In fact, if you know telephone systems but don’t know all that much about networking, you’ll find that just about everything you really need to know is explained, but without going into extraneous detail.  You get the information you need to get the job done, but if you want to become a networking guru, you’ll need some other book for that.

I’m just really sorry that the bad screenshots marred an otherwise fine book, but I have to call ’em as I see ’em, and in my opinion they really are that bad.  Whether that would matter to you is something only you can decide.  I should mention that I was provided a hardcopy edition of the book for review, but Packt also offers an e-book edition in Adobe PDF format on their web site, and if you are comfortable reading e-books, I’d definitely go that route with this book, because most PDF readers will let you magnify sections of a page.  So, the nearly unreadable screenshots might actually be very readable in the e-book edition. Also, if you do go the e-book route, be sure to scroll down the page and look for the offer, “Buy this eBook with FreePBX 2.5 Powerful Telephony Solutions eBook and get 50% discount on both. Just enter sip40xecs in the ‘Promotion Code’.”  Seems like a good deal, especially if you’re wanting to compare FreePBX and sipXecs.

Building Enterprise Ready Telephony Systems with sipXecs 4.0 by Michael W. Picher (Packt Publishing link) (Amazon affiliate link)

Linksys and Sipura adapter users – check your RTP Packet Size and Network Jitter Level

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

Edit: Reader Christopher Woods notes in a comment that the following is also applicable to at least some models of Linksys phones, e.g. SPA942 and SPA962.

Do you use a Linksys or Sipura VoIP adapter? Do the people you are talking to ever complain about your voice breaking up, or missing or dropped syllables, or unexplained clicks or noise?

There is an obscure setting in Linksys/Sipura VoIP adapters that is usually set incorrectly for most applications, at least on a factory-fresh adapter. Go to the SIP tab and check the RTP Packet Size – for most users, it should be set to 0.020 rather than the factory preset of 0.030. If you are running a connection where latency is critical (say you have a cable or satellite box that requires a phone connection to “phone home”, or you are trying to use a FAX machine) then you may even wish to set this to 0.010, which further reduces latency, at the expense of using a bit more bandwidth. In any case, the default 0.030 is not the correct setting when using the most commonly-used codecs. For more discussion of this issue, see this thread at DSLreports.com, which discusses how the RTP Packet Size and Network Jitter Level settings can be tweaked to achieve lower latency, along with the tradeoffs.

Be aware that the RTP Packet Size setting is found under the SIP tab, and that setting is applied to all lines served through that adapter. However, the Network Jitter Level can be set individually for each line, under the Line tabs. One interesting comment in the above-mentioned thread is that if a provider forces you to use a low-bandwidth codec, decreasing the RTP Packet Size may increase the quality of your calls, but again at the expense of increasing bandwidth used.

Changing the RTP Packet Size on one VoIP adapter resolved a few strange issues with audio quality. In this case the adapter was being used to connect to an Asterisk box on the same local network, so bandwidth usage wasn’t an issue. We set the RTP Packet Size to 0.020 and the Network Jitter Level to low, and it made a noticeable difference in the reduction of strange noises and breakups heard by the party on the other end of the conversation. However, changing the Network Jitter Level isn’t as critical as changing the RTP Packet Size, and in fact, changing the Network Jitter Level may be entirely the wrong thing to do on certain types of connections (probably not a good idea if your adapter is connected through a Wireless ISP, for example).

I must thank Paul Timmins for being the first to point out that the Linksys PAP2 has a default packet size of 0.030, which is incompatible with the uLaw (G711u) codec (or at least in violation of the standard). With that lead, I then discovered other articles (including the discussion thread linked above) that said essentially the same thing. So check those adapter settings, folks!

(And by the way, this advice probably does apply to some other makes of VoIP adapters, and even some IP telephones, but since I don’t have any readily available to look at, I can’t say for sure. If you know of any others that need to have a similar setting tweaked, please feel free to add a comment to this post).