In the last two posts, I’ve provided a basic overview of how to create cloud telephony applications using the Tropo platform and CouchDB.
In the first post of this series, I walked through a quick install of CouchDB and provided information on getting a Tropo account set up. In the second post, we created a simple auto attendant Tropo script in PHP that populates a CouchDB database with a call record for each inbound call that is transferred.
I’ll conclude the series with information on how to retrieve information from a CouchDB instance for use in a cloud telephony application, and talk about design documents. This post will also introduce the reader to the concepts of CouchDB Views and Show Functions – powerful tools that can be harnessed to create truly cutting edge cloud phone apps.
First, let’s create a CouchDB database to hold our call settings.
Creating a Call Settings Database
As mentioned in the previous CouchDB posts, you can create a new call settings database using curl from the command line, or using the Futon GUI.
$ curl -X PUT http://your_new_couchdb_ip:5984/call_settings
You should see a response from CouchDB like this:
{“ok”:true}
You can add a record to the call settings database the same way. This time, however, we’ll append the URL for our CouchDB database with a document ID, in this case ‘1000’ – this is the extension that a caller to our cloud telephony app will dial. We’ll use the document ID and and the CouchDB REST API to get all of the settings we’ll need to conduct the transfer – these settings can be seen in the document structure below (feel free to add others to meet your needs or preferences).
$ curl -X PUT http://your_new_couchdb_ip:5984/call_settings/1000 -d ‘{“first_name”:”Joe”,”last_name”:”Blow”,”phone”:”17777777777″,”title”:”Master of Disaster”,”ring_tone”:”audio/ring.wav”}’
You should see a response from CouchDB like this:
{“ok”:true,”id”:”1000″,”rev”:”1-0cf5a7c3a70ac5760f1a5d8dcb8b48d2″}
Let’s add a few more documents to our call settings database (replacing the telephone numbers below with real ones that you want callers to transfer to) and then view all of the documents that we have created.
$ curl -X PUT http://your_new_couchdb_ip:5984/call_settings/2000 -d ‘{“first_name”:”Harry”,”last_name”:”Smith”,”phone”:”18888888888″,”title”:”President of the World”,”ring_tone”:”audio/ring.wav”}’
$ curl -X PUT http://your_new_couchdb_ip:5984/call_settings/3000 -d ‘{“first_name”:”Martin”,”last_name”:”Scorsese”,”phone”:”19999999999″,”title”:”The Departed”,”ring_tone”:”audio/ring.wav”}’
You can view all of the documents in a CouchDB database using the HTTP GET method:
$ curl -X GET http://your_new_couchdb_ip:5984/call_settings/_all_docs
You should see a response from CouchDB like this:
{“total_rows”:3,”offset”:0,”rows”:[
{“id”:”1000″,”key”:”1000″,”value”:{“rev”:”1-0cf5a7c3a70ac5760f1a5d8dcb8b48d2″}},
{“id”:”2000″,”key”:”2000″,”value”:{“rev”:”1-ee2f09516df8b191a89791b01828d788″}},
{“id”:”3000″,”key”:”3000″,”value”:{“rev”:”1-a1399e8218ae75e1efb73ba3f87862ff”}}
]}
Now we need to modify our Tropo PHP script to retrieve the settings we want to use with each transferred call.
Note, for now we’ll keep the logic simple – if a caller enters an extension that does not exist we’ll get a specific HTTP response back from CouchDB – something in the 400 class of responses. If this happens, we’ll just end the call – in the real world you’d want to do something a little more friendly, but you can sort that out when you build your own cloud telephony application. 😉
Modifying the Tropo Script
So, our new Tropo script looks like this:
Note that the getPhoneNumberByExtension() method no longer returns a hard coded phone number – it is using the 4-digit extension entered by the caller to access our CouchDB database using the REST API. The response from CouchDB is a document in JSON format, that we can easily parse using PHP’s handy json_decode() function.
I’ve also modified the value of the $callLog variable to correctly capture some of the variables exposed in the Tropo environment (i.e., the session ID of the call, and the caller ID – see this thread for more information).
So now we have a working cloud telephony application built on Tropo that uses CouchDB to get its call settings, and also to write a call record for billing, reconciliation, etc.
As cool as this is, there is still a lot more we can do with CouchDB in our cloud telephony apps. Note the constants declared at the top of the Tropo script – the last two are blank; one for a design document name, and one for a show function.
define(“COUCH_DB_DESIGN_DOCUMENT_NAME”, “”);
define(“COUCH_DB_SHOW_FUNCTION_NAME”, “”);
Let’s talk about those concepts now, and explore how they could be used in a cloud telephony application.
Getting more out of CouchDB – Design Documents, Map/Reduce and Show Functions
As the title of this post suggests, we’re building cloud-based phone applications without SQL. CouchDB doesn’t use SQL – instead it uses a Map/Recuce framework to index documents in a database.
Map functions can be used to emit a key-value listing of documents in a CouchDB database. Reduce functions are used to aggregate the key-value pairs emitted by a Map function. Map/Reduce functions (or Views) live inside of a special document in a CouchDB database called a “design document“, which has a document ID prefixed with “_design/”.
For example, suppose we have a special design document in our database called “_design/extensions” with a View called “getExtensions” – our View is made up of a Map function and (optionally) a Reduce function. Let’s assume our View has only a Map function to return data on extensions with valid phone numbers to transfer a caller to.
function(doc) {
if(doc.phone.length == 11 && doc.phone.substr(0,1) == ‘1’) {
emit(doc._id, doc.phone);
}
}
Our Map function (which is written in JavaScript, and stored in our design document) has one parameter – doc. This function is called for each document in our database, and the doc parameter represents the document itself. As can be seen, we simply examine each document in the database to see if it has a valid phone number (11 digits, starting with 1).
Views are accessed using a specific URI structure (do note, however, that the REST API for querying Views can change significantly between CouchDB versions), and the response is a set of key-value pairs formatted as JSON.
http://server_ip_address:5984/database_name/_design/design_document_id/_view/view_name
$ curl -X GET http://your_new_couchdb_ip:5984/call_settings/_design/extensions/_view/getExtensions
You should see a response from CouchDB like this:
{“total_rows”:3,”offset”:0,”rows”:[
{“id”:”1000″,”key”:”1000″,”value”:”17777777777″},
{“id”:”2000″,”key”:”2000″,”value”:”18888888888″},
{“id”:”3000″,”key”:”3000″,”value”:”19999999999″}
]}
You can check to see if your Map function is working properly by adding a document with an invalid phone number.
$ curl -X PUT http://your_new_couchdb_ip:5984/call_settings/4000 -d ‘{“first_name”:”Richard”,”last_name”:”Kimble”,”phone”:”4444444″,”title”:”The Fugitive”,”ring_tone”:”audio/ring.wav”}’
Accessing the getExtensions view will return the same results as before, as the phone number for the new document does not pass validation. Using design documents and Views, cloud telephony developers can use CouchDB to build grammars for user input which will significantly enhance the usability of the sample application we’ve used during the last few posts.
But there is even more potential with another piece of functionality in CouchDB – show functions. Show function also live in design documents, alongside Views. Show functions allow a developer to return specifically formatted content from a CouchDB instance, not just data in JSON format.
A basic show function that can be used to return information from our CouchDB database in the format of a SRGS grammar might look like this.
function(doc, req) {
var grammer = ‘<?xml version=”1.0″?><grammar xmlns=”http://www.w3.org/2001/06/grammar”>’;
grammar += ‘<rule id=”R_1″><one-of>’;
grammar += ‘<item>’ + doc.phone + ‘<item>’;
grammar += ‘</one-of></rule></grammar>’;
return grammar;
}
Like Views, Show Functions are accessed using a specific URI structure.
http://{server_ip_address}:5984/{database_name}/_design/{design_document_id}/_show/{show_function_name}/{document_id}
Note that the Show function above is different from the Map function discussed earlier in that it takes two parameters – doc and req. As before, the doc parameter represents the document the function is called against. The req parameter represents a parameter that is sent in with the HTTP request, which can be used inside the function to render output. So a Show function canbe accessed using the above URL with an optional parameter as well, like so.
http://{server_ip_address}:5984/{database_name}/_design/{design_document_id}/_show/{show_function_name}/{document_id}?{parameter}={some_value}
Conclusion
I hope this series of posts has provided a helpful overview of CouchDB, with an emphasis on how it can be used to build cloud telephony applications.
Cloud telephony platforms like Tropo, CloudVox, CallFire and others provide enormous flexibility to developers in building and deploying sophisticated cloud telephony applications.
Pair these tools with CouchDB and you’ve got a powerful combination for building full featured, easy to maintain cloud-based phone apps.
Civic Innovations 