Follow-Me Phoning: Implementing Bluetooth Proximity Detection with Asterisk, Part III

This is the third and final article in our series showing how to deploy a Bluetooth Proximity Detection system with your Asterisk@Home PBX. Parts I and II are here. Today we finish up and activate everything so that your Asterisk® PBX system will track your whereabouts and automatically transfer incoming calls in your home or office to your cellphone or any other phone whenever you leave home base carrying your bluetooth-enabled cellphone or your bluetooth headset. And, when you return, calls automatically will begin flowing to your local extensions just as they did before you left your home or office. For our Mac users, we'll have a follow-up article some day soon showing you how to tie proximity detection into the home automation server we previously built with Indigo. Then, as you arrive home in the evening, you can turn on your lights, and stereo, and hot tub just by pulling up in front of your house with your Bluetooth headset or cellphone.

NOTE: This article has been updated to take advantage of TrixBox, freePBX, and the iPhone. For the current article, click here.

Last week we showed you how to use your new Asterisk@Home 2 PBX machine to detect the presence or absence of your bluetooth phone or headset. And we used freely available open source tools for Linux to do the tracking. Our game plan for today is to show you how to relay that information from your Bluetooth Proximity Detection system to your main Asterisk system in real time. And then we'll modify the dialplan on your main Asterisk system a bit so that it intelligently routes incoming calls after first deciphering whether you are IN or OUT of your home or office. For purposes of this tutorial, we're assuming that you have taken our advice and implemented a second Asterisk@Home server (the version 2 beta) to take advantage of the bundled CentOS/4 Linux operating system. Our design also assumes that both your main Asterisk machine and your new Asterisk proximity detection system are both behind the same firewall on the same internal network. So we'll begin today by finishing the detection tasks on the new Asterisk server, and then we'll turn our attention to your primary Asterisk server, i.e. the system that takes and makes your phone calls. Update: Now that Asterisk@Home 2.1 is shipping, you may decide you'd prefer to deploy this entire system on a single server. If so, print this article and then go here for the instructions needed for a single server deployment.

Overview of Bluetooth Proximity Detection Design. If you've been following along with the two previous articles in this series, then you already have your Asterisk@Home 2 PBX server running with full Bluetooth support. If not, start there. The real trick to making Bluetooth Proximity Detection work for this project was using hcitool name 00:03:89:43:84:e2 with the actual MAC address of your Bluetooth headset or phone. This utility returns a null string if the Bluetooth device is not found and returns the name of the device if it is found. We'll take advantage of that information to drive our proximity detection system by simply writing the results of this test to a text file once a minute. We then can use a Linux bash script to execute a certain action based upon whether your Bluetooth device is IN range or OUT of range. As usual, we've chosen the easy way. So our plan is to copy a null file to your primary Asterisk server when you're OUT, and we'll copy a one-byte file to your primary Asterisk server when you're IN. Then we can run a similar script on the primary Asterisk server to check whether you're IN or OUT each time a phone call arrives. We'll only upload the null or one-byte file when the status changes to keep the processing load low. If you want to track multiple people with multiple Bluetooth devices, then rename the ruhome file to include the name of the person that's carrying the device, e.g. wardruhome. Then it'll be easy to implement this for multiple people. Just repeat the steps.

Configuring Files for Asterisk 2 Server. The files we'll be using in our Proximity Detection System can be downloaded here and unzipped into the proximity folder on your Desktop. Don't modify null.file or notnull.file because doing so will probably change their file sizes, and then none of this works. We are depending upon the notnull.file remaining a zero byte file! You do need to edit the ruhome file whether you rename it or not. Call it up with a text editor and modify the following settings to match your configuration:

mainasteriskbox=192.168.0.104
deviceuser=WARD
devicemac=00:03:89:43:84:e2

We recommend upper case letters for the deviceuser just so it will be easy to identify. The devicemac is the MAC address of your Bluetooth device to be monitored. And mainasteriskbox is the private IP address of your main Asterisk server. Once you make these changes, save the file in text-only format and then copy the following three files in the proximity folder to the /root directory on your Asterisk2 Proximity Detection Server: ruhome, null.file, and notnull.file. Then log in to your Asterisk2 server as root, and move to the /root folder: cd /root. Now adjust the file permissions on script you put there substituting the name you gave your script: chmod 775 ruhome.

If you read through the ruhome script, you'll notice that it copies either null.file or notnull.file to your primary Asterisk server whenever there's a change in the presence of your bluetooth device, and it names the file to match the assigned deviceuser. To make the copy process work, we need to use the scp utility that is bundled with Linux. There's only one wrinkle. SCP prompts for a password whenever you attempt to log in to your other Asterisk box, and that would preclude our being able to handle this as a background job with no user interaction. Luckily, there's a simple solution: a public/private key pair. If you want the complete tutorial, go here. Otherwise, just do the following. Log in to your new Asterisk@Home 2 server as root. From the command prompt, issue the following command: ssh-keygen -t rsa. Press the enter key three times. You should see something similar to the following. The file name and location in bold below is the information we need:

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
1d:3c:14:23:d8:7b:57:d2:cd:18:70:80:0f:9b:b5:92 root@asterisk1.local

Now copy the file in bold above to your main Asterisk server from your secondary Asterisk2 server using SCP. The command should look like the following (except use the private IP address of your primary Asterisk server instead of 192.168.0.104). Provide the root password to your primary Asterisk server when prompted to do so.

scp /root/.ssh/id_rsa.pub root@192.168.0.104:/root/.ssh/authorized_keys

Once the file has been copied, let's try to log in to your primary Asterisk server from your Asterisk 2 Proximity Server with the following command using the correct IP address, of course:

ssh root@192.168.0.104

You should be admitted without entering a password. If not, repeat the drill or read the complete article and find where you made a mistake. Now log out of the primary server by typing exit.

The final step on the Asterisk2 Proximity Server is to schedule this script to run once a minute to keep track of your comings and goings. While still logged in as root, issue the following commands:

export EDITOR=nano
crontab -e

This will start up the Crontab utility using our favorite editor, Nano. Now enter the command below substituting the correct name of your script:

* * * * * /root/ruhome > /dev/null

If you'd prefer to only run the script every minute between 6 in the morning and 9 at night, the code would look like what's shown below. Just choose the hours desired and remember that your IN and OUT status will be frozen at the exact moment the script completes its run at 8:59 p.m. if you use the settings below. And it won't check your bluetooth proximity again until 6:00 a.m. tomorrow morning.

* 6-21 * * * /root/ruhome > /dev/null

Once you've gotten the entry the way you want it using the actual name of the script you placed in the root folder, save your crontab entry: Ctrl-X, Y, and press Enter key. Now turn on your Bluetooth device and move it within range of your Asterisk2 server, count to 60, and then check the /tmp folder on your primary Asterisk server for a file with the name you specified for deviceuser above, e.g. ls -all /tmp/WARD. The size of the file should be 1 indicating that your specified Bluetooth device is within range of your Asterisk2 server. Now turn the Bluetooth device off and wait another minute or two. Repeat the steps above and make sure the file size has shrunk to 0. When all this works according to plan, you're ready to move on and configure your primary Asterisk server to manage your incoming calls based upon whether you're IN or OUT.

Configuring Your Main Asterisk Server for Proximity Detection. As you learned above, the Asterisk2 proximity detection server will actually do the heavy lifting by figuring out when you're IN and when you're OUT. It then will upload the appropriate file to your primary Asterisk server when your status changes. But we'll still need a little script on your primary Asterisk server to actually check your status whenever an incoming call arrives. That's the job of the homecheck.agi script in the proximity folder you downloaded. Before it will work, the deviceuser specified at the top of this file must match the name you assigned to deviceuser in the ruhome script. So edit the homecheck.agi script and then save the file as plain text. Then copy it to /var/lib/asterisk/agi-bin on your primary Asterisk server. Log in to that server as root and change the ownership of this file: chown asterisk:asterisk /var/lib/asterisk/agi-bin/homecheck.agi. And then set the permissions: chmod 775 /var/lib/asterisk/agi-bin/homecheck.agi.

The remaining tasks on the primary Asterisk server we'll handle using the Asterisk Management Portal (AMP) so, using your favorite web browser, connect to the primary Asterisk server and then choose AMP->Maintenance->Config Edit and click on extensions_custom.conf. If you're using our Stealth Autoattendant, then locate the code in your extensions_custom.conf file. All that we need to modify is the timeout section of the code: exten=>t. So you'll still be able to take advantage of your AutoAttendant even when you're away from your home or office. Here's what we are using:

exten => t,1,Background(pls-hold-while-try)
exten => t,2,AGI(homecheck.agi)
exten => t,3,GotoIf($["${WARD:0:2}" = "OU"]?custom-outhouse,s,1:4)
exten => t,4,Dial(local/222@from-internal,20,m) ; Ring group 222 dials all phones
exten => t,5,VoiceMail(204@default) ; Default voicemail account for your home
exten => t,6,Hangup

NOTE: You can't cut and paste the above code unless you manually change the typographic quotation marks in the third line to normal quotes that Asterisk understands. There are two sets of them! Also change WARD to the deviceuser name you assigned above in your script files. The final piece of code you'll need is the context to actually process the incoming calls when you are out of the house or office, custom-outhouse. Just cut-and-paste it to the bottom of extensions_custom.conf. As usual, you can customize it to your heart's content, but here are a couple ideas from our own system. Once you're finished, save your changes and then reload Asterisk.

[custom-outhouse]
;exten => s,1,Dial(SIP/6781234567@telasip-gw,60,m) ; This approach just quietly sends callers to your cell phone using the telasip-gw trunk
;exten => s,2,VoiceMail(204@default)
;exten => s,3,Hangup

exten => s,1,Wait(1) ; This approach plays a custom message which we previously showed you how to do. Here's the message:
exten => s,2,Background(custom/nothome) ; No one's home. To try our cellphones, press 1 for Mary or 2 for Ward. Or press 3 to leave a message.
exten => s,3,DigitTimeout,4
exten => s,4,ResponseTimeout,5
exten => t,1,VoiceMail(204@default)
exten => t,2,Hangup
exten => i,1,Playback(wrong-try-again-smarty)
exten => i,2,Goto(s,1)
exten => o,1,VoiceMail(204@default) ; if the caller presses 0, then it's off to voicemail they go
exten => o,2,Hangup
exten => h,1,Hangup
exten => 1,1,Background(pls-hold-while-try)
exten => 1,2,Dial(SIP/6781234567@telasip-gw,60,m)
exten => 1,3,VoiceMail(204@default)
exten => 1,4,Hangup
exten => 2,1,Background(pls-hold-while-try)
exten => 2,2,Dial(SIP/6782345678@telasip-gw,60,m)
exten => 2,3,VoiceMail(204@default)
exten => 2,4,Hangup
exten => 3,1,VoiceMail(204@default)
exten => 3,2,Hangup

Well, that should do it. Once you restart your Asterisk server, you can place a call to your home while you're IN and while you're OUT carrying your Bluetooth device to make sure things are doing what they should. Now all you have to do is to remember to recharge your Bluetooth device each night. Enjoy!

There's now a fourth article in this series which you can read by clicking here.

Coming Attractions. No, we haven't forgotten. We still have our incoming fax server to build, and we want to start using Asterisk's built-in Blacklist database tools. Then we'll be turning our attention to using SSH and SCP to build automated backups of your primary Asterisk server using the password trick we learned in the proximity detection article today. And now that you have a second Asterisk server, you might as well learn how to connect them together so that you can make calls to extensions on either server and make outgoing calls using either server. So stay tuned!

Other Asterisk Tutorials. There are numerous additional articles in this Asterisk HOW-TO series to keep you busy. You can read all of them by clicking here and scrolling down the page. We recommend reading at least the first four or five articles from the bottom up so that the learning curve is less painful. Then you can skip around to your heart's content.

Say It Ain't So. Sony reportedly is taking the low road and employing a rootkit to hide copy-protection mechanisms on its latest CDs and your PC, just what every virus creator on the planet has yearned for. Before you buy anything else from Sony/BMG, read this. Update: A recent article indicates that Sony's rootkit may, in fact, "phone home" to Sony with details of your music listening habits as well as your IP address. And what does Sony have to say about the controversy? They apparently don't think most folks are smart enough to know what a rootkit is. And what does Sony think you should be able to do with your newly purchased CD? Read this eye-opener before you hand over any more money to Sony. Let the lawsuits and prosecutions begin.