Building Cloud Communication Apps with Tropo: Part 1

A few months back, I wrote a series of posts on building NoSQL telephony applications with Tropo and CouchDB. Today I’m going to start a continuation of that series, focusing on how to build cutting edge cloud communications apps with the Tropo WebAPI.

What is the Tropo WebAPI?

The Tropo WebAPI is, in a nutshell, an HTTP/JSON API for building multi-channel communication applications – applications that you interact with via phone, IM, SMS or Twitter. While my earlier series on Tropo focused on building applications in Tropo’s scripting environment (another fine option for developers), this series will focus on building JSON-based applications (generated using PHP) that can be hosted anywhere and executed in the Tropo cloud environment.

Faithful readers will recognize some similarities here to a post I did a while back on the HTTP/JSON API provided by CloudVox, another cloud telephony provider. While the concept behind these two API’s is very similar, there are some key differences that make Tropo a highly attractive option for developers.

First, the Tropo service is truly multi-channel – using the Tropo WebAPI you can build applications that work on a range of different communication channels, not just phones (although you can build some pretty slamming phone apps as well).

Since I’m a phone app developer at heart, some of the features that Tropo provides for phone applications really get me excited. Tropo supports both DTMF entry and speech recognition. It also has broad multilingual support. In addition, Tropo gives phone application developers the ability to manipulate SIP headers, an important feature in building sophisticated cloud communication apps that I hope to demonstrate down the road a bit.

Getting Started

Head on over to and set up a new account (if you don’t have one already). Take a little time to review the documentation for the Tropo WebAPI. For the example applications in this series of blog posts I’ll be using a PHP class library I developed specifically to interact with the Tropo WebAPI.

The crew behind Tropo have provided a Ruby Gem for interacting with the Tropo WebAPI. However, since I like to do my cloud telephony work with PHP I decided to write my own set of classes for doing this. Whether you’re a Ruby-head or a PHP enthusiast, using one of these tools to generate JSON for consumption by the Tropo WebAPI can make build an application significantly easier, particularly as you get into more sophisticated application development.

You can get the PHP Library, as well as some of the sample apps we’ll be looking at, from GitHub:

$ git clone git://

You’ll need to host these classes and the PHP scripts you write with them on a server that can be accessed from the Tropo environment. Any web server that supports PHP will do.

My First Tropo WebAPI Application

Let’s start with the standard Hello World app:

Say("Hello World!");

// Render the JSON for the Tropo WebAPI to consume.


You can look at the rendered JSON in your browser, and you should see something like this:

    "tropo": [
            "say": [
                    "value": "Hello World!"

Go to the Applications section in your Tropo account and set up a new WebAPI application that points to the location of this script.

Create a new Tropo WebAPI application

Assign a URL to your new Tropo WebAPI application

When you create your application, Tropo will automatically provision a Skype number, a SIP number and an iNum. You can additionally add a PSTN number in a range of different area codes at no charge.

You may also notice the section below the provisioned phone numbers entitled “Instant Messaging Networks” – this section allows you to set up any number of different IM accounts (and Twitter!) that your application can use. We’ll dive deeper into this in future posts.

For now, we’ll keep it simple and use the auto provisioned Skype number – when you call this number, you will hear it say “Hello World.”

The next post in this series will focus on a more sophisticated application that uses the TropoPHP classes and the utterly awesome Limonade PHP framework.

Stay tuned…


Book Review: Asterisk 1.6

The folks at Packt Publishing recently sent me a copy of Asterisk 1.6 by David Merel, Barrie Dempster and David Gomillion and I’ve been using it for the past week or so to set up a fresh instance of Asterisk 1.6 on Ubuntu 8.04.

(Note – like many Asterisk books, this one is very CentOS focused, but I found the installation and configuration steps described in it – as well as some of the larger Asterisk management concepts – easily applied to Debian-based distros like Ubuntu.)

This is a solid, well-written book for anyone that wants to start building and managing an Asterisk-based telephony system. I found this book to be very well focused on concepts that would appeal to someone who wants to manage an Asterisk system professionally, and is probably less well suited for someone interested in tinkering with Asterisk as a hobby.

There is a good discussion of some of the key concepts that someone who aspires to be (or already is) an Asterisk professional should have a handle on. It has a very good discussion on hardening an Asterisk server in the chapter on “Maintenance and Security”, and the book begins (very appropriately) with an exercise in developing a deployment plan – again, probably not well suited for an Asterisk or VoIP tinkerer, but critical for someone who is going to deploy an Asterisk server in a production environment and assume responsibility for managing it.

I didn’t see any discussion of some of the more cutting edge features of Asterisk 1.6 that might be of interest to someone wanting in exploring alternative communication protocols (Jabber/Jingle) or some of the less mainstream channel drivers (GTalk, Skype, etc.) There is no mention at all (that I could see) of how to connect Asterisk to Google Talk via Jingle, or to the Skype network via Skype for Asterisk. Nor is there any mention of some of the IM-focused dialplan applications like JabberSend().

This book appears to be designed for someone who wants to set up and manage a more traditional Asterisk-based system. And for that purpose it is very well suited.

Customizing Caller ID with CiviCRM and trixbox

Recently, I had an opportunity to set up a CiviCRM site for a client to use to track contributors.

I think CiviCRM is a great piece of software that can be enormously useful to non-profit organizations, and I’m actually surprised that more don’t opt to use it. It’s powerful, robust, extensible and open source.

The site I set up is running a Red Hat-based LAMP stack with Drupal, CiviCRM and the CiviContribute module. I have the same set up mirrored in a local development environment that lets me test tweaks and upgrades to the site before they get pushed out into production. I also have an instance of trixbox CE running locally, and I decided to try and see if I could set up a trixbox PBX that uses CiviCRM as the data source for looking up caller information on inbound calls. This way, if a non-profit is using both CiviCRM and trixbox they could set their PBX to look up information about clients, donors, volunteers, etc. that call their offices and display this information in either a SIP client or in a screen pop.

The process of setting up trixbox to use CiviCRM as the data source for caller ID lookups couldn’t be easier (note, I used these steps on trixbox version

  1. Log into your trixbox and enter admin mode.
  2. From the toolbar, select PBX >> PBX Settings.
  3. From the FreePBX left-hand side menu (under “Inbound Call Control”), select CallerID Lookup Sources
  4. In the section entitled “Add Source”, enter the Source Description (CiviCRM), and Source Type (MySQL). Using Cache Results will cache the CID lookup in AstDB. Depending on your own set up, you may or may not feel the need to enable this setting.
  5. In the section entitled “MySQL” (appears after you designate the Source Type), enter the Host, Database, Username and Password to access your CiviCRM database.
  6. The section entitled Query is where you will enter the SQL query that will return the information you want to display about on incoming calls. I used the following SQL (you can modify this as you like to alter your display information – note, the special token ‘[NUMBER]’ is replaced with the caller ID of the incoming call):

  7. SELECT CONCAT('CiviCRM: ',display_name) FROM civicrm_contact WHERE id = (SELECT id FROM civicrm_phone WHERE REPLACE(phone, '-', '') = SUBSTRING('[NUMBER]',-10))

  8. Click Submit Changes.
  9. Navigate to Inbound Routes (also under the “Inbound Call Control” section of the FreePBX menu).
  10. Select the route that you would like to use CiviCRM as the data source for.
  11. In the section entitled “CID Lookup Source”, select CiviCRM from the drop down menu.
  12. Click Submit.
  13. Scroll to the top of the page and click on the orange bar that says Apply Configuration Changes and reload the settings.

Thats it!

Now on an inbound call, the name of the CiviCRM contributor in the format CiviCRM: John Doe is displayed in my SIP client whenever a successful lookup occurs. There are all sorts of options that can now be used to display the caller information to non-profit staff, send a screen pop, route the call to a specific destination, etc.

CiviCRM and trixbox are a potent combination. I hope this brief explanation of how to use the two together gets more non-profits excited about using them.

Wanted: One IM/VoIP Client That Does it All

Vacancy Description:

There is an immediate opening in my life for a smart, fast, next-generation IM client that can integrate with multiple social networks, standard XMPP servers, email and POP accounts and VoIP services.

Candidates already evaluated:

Digsby: Digsby is an IM client that connects to AIM, MSN, Yahoo, ICQ, Google Talk, Jabber, and Facebook Chat.


  • Can be used to manage e-mail on different networks (Hotmail, Gmail, Yahoo Mail, AOL/AIM Mail, IMAP, and POP accounts).
  • Integrates with social networks like Facebook (receive friend requests, etc.) and Twitter (change status).


  • Windows only (for now).
  • Can’t use for VoIP phone / video calls.

WengoPhone: A SIP client that also integrates with IM networks such as Google and AIM.


  • Multi-platform (runs on Windows, Linux or Mac).
  • Supports SIP.
  • Support for AIM and Jabber IM accounts.


  • Can’t integrate with social networks like Facebook.
  • Can’t be used to manage e-mail accounts

Meebo: A web-based service that integrates with a host of different IM and social networks, including Facebook and MySpace.


  • Web-based — no install required, and can be accessed from anywhere.
  • Can connect to AIM, Yahoo, Google, MySpace, Facebook, Jabber and ICQ accounts


  • Can’t use for VoIP phone / video calls.
  • Ad supported, so I get asked if I want to watch Miley Cyrus videos on occasion (who doesn’t though…)

This position will remain open until a suitable candidate has been found.

Fonality announces trixBox Pro

Some very cool news today from Fonality, stewards of the trixBox project — trixBox Pro is essentially a blending of trixBox with Fonality’s PBXtra, but the whole definitely seems to be greater than the sum of it’s parts:

With trixBox Pro, users can enjoy both basic and many advanced VoIP features — conferencing, unified messaging, presence features, embedded secure corporate chat, Outlook integration, and more.

Perhaps the most exciting new feature included with trixBox Pro is trixNet, the equivalent of a private VoIP peering service, which essentially connects trixBox Pro users to one another without connecting to the PSTN, regardless of the service provider either party uses. When a user places a call, trixNet quickly checks its database to determine whether the called party is also part of trixNet, and if not, routes the call to the PSTN. Additionally, the system has also been designed to detect connection times and reroute calls to the PSTN if calls are not connected within one second.

What is even cooler — trixNet is expected to be extended to trixBox CE (the stand alone version of trixBox) and to users of Google Talk in the near future.

Nice — can’t wait to get mine!

Top 5 Things to do after intalling Trixbox: #2

Once you’ve got your Trixbox all set up, you need to think about backups – what happens if your system needs to be restored, or if you’re doing and upgrade (say from version 2.0 to 2.2)?

The FreePBX module in Trixbox has a handy “System Backup” feature – in FreePBX, go to Tools->Backup & Restore.

Click on the “Add Backup Schedule” link and name your new schedule – I personally take the simple approach of just doing a weekly backup on Sunday night.

When your backup is created, Trixbox places a “.tar.gz” file in the /var/lib/asterisk/backups/ directory. So, if you created a schedule called “Weekly” your backup file would be placed in the directory /var/lib/asterisk/backups/Weekly/. Here these files will stay – a new one is created each time your scheduled backup is run – unless you do something with them.

For obvious reasons, we want to move these backup files to another server for safe keeping. Additionally, one we’ve successfully moved our backup, we want to clean up the old files from our backup directory.

There are any number of ways of doing this. Here is my preferred method:

Create a new user on your Trixbox machine, and add that user to the “asterisk” group. (The user will need to be a part of this group to access the backups directory.)

useradd -G asterisk backup
passwd backup

Log in as this new user, and create a key pair for ssh connections. When prompted to enter a pass phrase, simply hit enter (blank pass phrase).

ssh-keygen -t dsa

Export your public key to the machine where you will be storing your backups.

scp ~/.ssh/

Make sure you can SSH to the machine where you will store your back up files. You’ll want to make sure that key-based authentication is working (i.e., that your not prompted for a password).


Make sure you can securely copy files to the machine where you will store your back up files (again, make sure that your not prompted for a password).

scp /var/lib/asterisk/backups/Weekly/*

If all of the above steps went successfully, you are now ready to set up your automated process. We’ll use CRON to do this.

Log on as the new backup user on your Trixbox machine.

Create a new crontab for this user.

crontab -e

Insert cron entries to copy backup files to the remote machine, and to clean up old files after they have been moved.

01 0 * * 1 scp /var/lib/asterisk/backups/Weekly/*

01 1 * * 1 rm -f /var/lib/asterisk/backups/Weekly/*

The first entry will move our weekly backup file at 12:01 a.m. on Monday morning to our remote server. The second entry will clear the Weekly directory an hour later. This way, when you go to the office on Monday, all of your backup process are done and your ready to start the week on a good note.

In the next article, we’ll discuss how to monitor your Trixbox to make sure that it is performing properly.

Top 5 Things to do after intalling Trixbox: #1

Today I’ll start a series that I’ve been meaning to commit to writing for some time. The top 5 things to do after you finish installing Trixbox.

Trixbox 2.2 is now out, so if you’ve ever thought about setting up your own VoIP system I would strongly recommend giving Trixbox a try. The Trixbox forums provide a wealth of information, and there is some documentation available from the Trixbox project itself. However, most of the documentation focuses on the installation process, and does not provide a whole lot of information about what to do after your system is installed and running.

With this in mind, I’d like to share some of the things that I think are important to ensuring that your Trixbox system is running smoothly (and securely).

First things first — we need to lock down SSH.

If your not familiar with SSH, you should brush up on this remote connection method. Right out of the gate SSH is a more secure way of connecting to a Linux machine than alternatives like Telnet, but that doesn’t mean it’s perfect.

At a minimum, the following steps should be taken to improve SSH security:

  • Run SSH on an alternate port (the default is port 22).
  • Only use the SSH 2 protocol (SSH 1 is not as secure as 2)
  • Do not allow root logins via SSH (in fact, it’s a much better approach to only allow specifically named users to log in via SSH, but never root).
  • Use public key authentication, instead of passwords.

There are a number of other helpful tips and tricks available here.

Next up, we’ll walk through the process of backing up a Trixbox system and transferring the backup to a remote machine using scp and cron.