• Respondents appear to love Adhearsion – it’s true. (We have not missed the fact that the only people who knew about the survey may have been Adhearsion fans by definition as subscribers of our dist list…but, still!)
• While Asterisk is still the most-used platform, FreeSWITCH shows a lot of growth in a short amount of time, and many people appear to be considering a move from Asterisk to FreeSWITCH
• Roughly half of you have moved an application from some other solution (mostly Asterisk dialplan or Perl scripts) to Adhearsion
• Dynamic IVR and Dynamic routing are the most popular uses of Adhearsion, compared to their static counterparts
• Manual integration testing is still the most common approach, with automated unit testing second in line
• A large majority of people have found that Adhearsion has saved them time and/or money compared to alternatives they used or considered
• You guys love Ruby, but don't love our documentation. We are still trying to figure out where the gap lies - is it that people are not finding the long-form documentation that was launched with Adhearsion 2, or our API documentation? Or is this documentation easy enough to find, but unsatisfactory to you. In either event, this is a great way to contribute to the project in a non-technical way. Please do feel free to file documentation bug reports or even pull requests
• Most of you work in small teams (between 1-3 people) on Adhearsion projects
• A lot more of you use JRuby than we had realised - this is awesome
• A Web UI is a very popular app component, but native (desktop & mobile) apps are rare
• There are still a lot of Asterisk pre-1.8 deployments out there. This is surprising, since Asterisk 1.6.2 was EOL'ed more than a year ago. You guys who admitted to still using something prior to 1.8, be wary! There are known security issues and other bugs. The longer you wait to upgrade, the harder that upgrade will be. For those of you using Asterisk 1.8, note that 11 is now the current LTS release. We know from experience that the upgrade is pretty straightforward, especially if you are using Asterisk with Adhearsion exclusively. You'll also benefit from a bunch of bugs fixed that are still present in 1.8, along with many other improvements (notably ConfBridge!).

Over the next few weeks and months we'll be studying this data in more detail to extract any lessons we can, and apply those to our decision-making process with regards to the future of the project. This is an exciting time, and we look forward to where this may lead us, as well as keeping you all in the loop.

Please don't hesitate to continue to send us feedback about Adhearsion whenever you like. You can post on the mailing list, file feature requests or bug reports or get in touch with Mojo Lingo to discuss how we might help your project further.

Go ahead and take a look through the results for yourself. Let us know if you spot anything interesting.

The post Adhearsion Survey Results appeared first on Mojo Lingo.

"can anyone recommend a fast time-to-market development platform for voice apps? (Not LAMP + Asterisk)"

My answer: It depends a bit on your requirements. Let's take a look at two high-level options: Cloud vs. Premise.

Cloud

For a pure-cloud system, lets take a look at the likes of Tropo or Twilio.

Pros

• Nice feature list. Especially for Tropo, you have immediate, no-extra-cost Text-to-speech and Speech Recognition, phone numbers in area codes around the world, and support for several programming languages
• Simple pricing. Last I checked they're both around $0.03/min -- yes, that's expensive relative to wholesale SIP, but you have no other costs
• No infrastructure to run. Combine something like Twilio or Tropo with an app running on Heroku and you have zero infrastructure to manage. In Tropo's case, you can even run the app directly on their servers
• Best for simple apps. Low complexity lends itself to small, self-contained functionality, like a simple IVR or a call recording feature

Cons

• Service/pricing options limited. In both cases you can't bring in 3rd party providers. We've had customers in the past who wanted DIDs from regions not served by the cloud host. There's no (good) way around that: you get whatever service they provide, nothing more. You also cannot shop around for better termination rates, or make quality/cost tradeoffs
• Limited to simple applications. Twilio covers probably 80% to 90% of telephony use cases, but that leaves a lot of interesting applications out in the cold. Tropo is better about this, but there are still limits to the API. Call progress analysis (answering machine detection) is one example: it's not available on either platform. Twilio also does not allow some interesting interactions between two live calls that are possible when you control the whole stack like a premise system

Premise

For many people, the right choice is to run the infrastructure themselves. Here are some reasons why. We will focus on Adhearsion in tandem with one of the supported telephony engines: Asterisk, FreeSWITCH or PRISM.

Pros

• Functionality. Really sophisticated voice apps are possible in a real programming language (as opposed to extensions.conf or dialplan.xml). This means modern practices like unit testing, functional testing, access to a HUGE library of pre-built functionality (Rubygems), and easy integration with web services and/or databases, including databases behind your firewall
• Control. Provides the most control possible over phone calls. You can bridge two calls together, tear them apart, redirect them, record media, play media, do ASR and TTS, integrate with instant messaging and web dashboards, etc.
• Self-hosted or cloud. Adhearsion apps can run on your own infrastructure, if that is a requirement (for PCI or SOX or other compliance reasons, or simply as a matter of choice). Note that while you can self-host, you can also run Adhearsion in the cloud. We've done it on both Amazon AWS and Heroku
• Shop around for rates. You can purchase VoIP services from whatever service providers you choose, and you can mix-and-match. Especially important at high volume or in obscure markets, or when you need different origination and termination providers

Cons

• Learning Curve. You may already be familiar with Asterisk or FreeSWITCH. You may have to learn Adhearsion. These packages have a steeper curve (due to their capabilities) than either cloud offering above
• Infrastructure costs. Most people who chose to employ Adhearsion end up running it themselves, whether hosted at facility or in their offices. Someone will need to manage these servers
• Too much power. I'm not being flippant here: For some jobs the simpler tool is the right one. We use and love Adhearsion for most of our apps, but we're usually doing more complicated things that need the functionality. I probably wouldn't start out with Adhearsion if all I wanted to do was make a simple call recording app
• Licenses needed for ASR and TTS. There are no good open source/free ASR or TTS engines available. If you need them, you'll have to license them

Know Thyself

Informed decisions are the best decisions. Hopefully the above provides a starting point for more discussion about your own needs. Knowing exactly what features you need, and what regulatory or policy requirements to meet, will help guide the decision. Not every voice application is created equal, and not one size will fit all.

Want to hear more?

The post Cloud vs. Premise: How to choose a Voice Application Platform appeared first on Mojo Lingo.

What is git bisect?

Git bisect will iterate through each commit between two points, but rather than going sequentially, hitting every single commit, it intellegently divides them - it will start halfway through the begin and end commit, and then iterate by halving the distance between the known good commit and the known bad commit. In computer science terms, this technique is sometimes called a "binary search". The point, though, is that it will save you a lot of time over inspecting every commit to find the one that breaks.

An example: Upgrading Adhearsion

Here’s a real issue I encountered not long ago. It happened to me when I moved from Adhearsion 2.1 to 2.2, but to make the example more dramatic, let’s upgrade all the way from 2.0.0 to 2.2.1. Say you're running along on 2.0 in production, all your tests pass, and there are no known issues. But when you upgrade to 2.2.0 to get a new feature, all hell breaks loose. Suddenly, you notice that certain conditions cause the logger to quit logging, and you get no feedback on your app. Here's how to use git bisect to track down which change to the Adhearsion project broke it.

Step 1: Check out gem sources

This should work for any gem which:

1. Uses git; and,
2. Has a checked in gemspec

The gemspec is needed so that Bundler can treat the checkout as a gem. For the purposes of our example, we'll use Adhearsion:

git clone git://github.com/adhearsion/adhearsion.git

Step 2: Edit your project's Gemfile

Open up your project's Gemfile, and change the line that brings Adhearsion into the project to read:

gem "adhearsion", path: "/home/jaiken/gems/adhearsion" 

Be sure to put in the actual path to which you have cloned Adhearsion

At this point, it's probably helpful to have two terminal tabs open: one in your project and one in the directory in which you cloned Adhearsion.

Step 3: Find the last known "good" version's commit hash

Finding the commit where the bug began requires knowing two points: one "good" (working, non-broken) version, and one "bad" (broken) version. Hopefully the project you are using has tagged releases, like Adhearsion does. If not, you may need to look through the Git commit logs to find the hashes that correspond to the version release. For example, here is a small list of commit hashes that go with each Rubygems release for Adhearsion:

• 2.2.1 - 9542998
• 2.2.0 - c46473d
• 2.1.3 - 63b1201
• 2.1.2 - 1f342fd
• 2.1.1 - 94a601c
• 2.1.0 - f843284
• 2.0.1 - 372237d
• 2.0.0 - e6e1d6e

In the Adhearsion tab, you'll want to checkout a known good commit. Since we started with a working application on version 2.0.0, let’s use that hash to start:

git checkout e6e1d6e

In the terminal tab for your own app, we'll run bundle install on your project to bring that first version of Adhearsion into the review. Now either run your tests or start up your app and verify that everything works. It should, since your project Gemfile is using that same version of Adhearsion that you were using before.

Step 4: Check out the first known "bad" commit

Now head back to the Adhearsion tab in your terminal, and checkout the commit where something went wrong. If it were the latest version you tried, in our example Adhearsion 2.2.1, you'd do

git checkout 9542998 

Back in your application tab, you can run the test suite or start the app up and try it out. This step should fail.

Step 5: Set up git bisect

At this point, we have a choice. We can manually checkout each commit between where we were and where we are, checking each one for errors. This can be a lengthy process - especially if a simple test suite run doesn’t reveal the problem and you’re forced to go through a 5-minute process to recreate the bug. Unfortunately for me, this is exactly what I did before I knew about git bisect. It made for a very long afternoon!

To begin the process the git bisect way, enter these 3 commands:

git bisect
git bisect good e6e1d6e # the commit hash from Adhearsion 2.0.0
git bisect bad 9542998 # the commit hash from Adhearsion 2.2.1

For bisect good, we put the hash for the known working one, and for bisect bad we put the hash of the version we first noticed causing a problem. Immediately after entering the git bisect bad command into the terminal, git checkouts a commit halfway between the two. Flip over to the tab for your application and run the app/tests to determine whether this is a good or bad commit. Occasionally, you may run into a dependency issue if the Adhearsion .gemspec has changed and requires gems that conflict with versions requested in your application - in this case, you can fix it with a bundle install. Fortunately these case are rare. Once your tests results are back, flip to the Adhearsion tab and inform git of the results of your test:

• If the tests pass, type git bisect good
• If the tests fail, type git bisect bad

By narrowing down the commits by halving, Git bisect will take 4 or 5 attempts before it finds the first bad commit—not the 20 to 30 attempts it would take manually.

Step 6: Use git bisect to iterate through commits

Now we can begin the process of using git bisect's intelligent iteration to find the first known bad commit. Whenever you inform git of whether the current iteration is good or bad, it immediately checks out a new commit for you to try. Keep bouncing back and forth between rebundling, testing your app, and informing git of whether it's good or bad. Stop when git recognizes the first bad commit:

357646fa193b0f431a1ae5298c61f3c8c9efe6ff is the first bad commit 

Now we have a nice pointer to a single commit where the error occurred. Since most commits (and hopefully the one you just found) are relatively small amounts of code, this should make troubleshooting much easier.

Step 7: Do your civic duty

Adhearsion is Open Source, and you've just found a bug. Since this bug probably affects other people too, you can help out your fellow developer by letting the gem's maintainers know. Extra credit (and glory, and fame!) if your report includes a fix. For our example, Adhearsion uses Github to track such problems. You might file an Adhearsion issue on Github or pull request that identifies the problem.

With that done, you can stop the bisecting process with:

git bisect reset

Don't forget to restore your app's Gemfile to point to the correct version of Adhearsion!

The post Using `git bisect` to troubleshoot Ruby gems appeared first on Mojo Lingo.

In an effort to help my fellow developers and their clients, I want to describe the VoIP platforms supported by Adhearsion — Asterisk, FreeSWITCH, and Voxeo PRISM — and highlight the key differences between them. Hopefully by providing an overview of the main decision points, you’ll be able to arrive at the most sensible choice of platform for your Adhearsion project.

Asterisk

Asterisk is the quintessential open-source PBX. Ask a non-telephony person about open-source telephony and chances are he’ll know about Asterisk. Asterisk has been around for a very long time, and is used by an extraordinary number of people to implement SOHO PBXs, as well as some larger projects. Asterisk is very easy to install, with several appliance-like distributions available such as FreePBX and Elastix. Most people who use Asterisk set it up once and — with the exception of occasionally adding extensions — never touch it again. Used for basic call routing, voicemail, inbound queues and occasionally IVRs, Asterisk can be utilized for more complex scenarios. Unfortunately, elaborate applications (and external integrations) quickly become un-maintainable and/or too complex to understand. And some things are just plain impossible with Asterisk.

Adhearsion, which began as a “niceness” layer on top of Asterisk (helping to avoid the frustration caused by trying to write complex applications in extensions.conf), has always supported Asterisk; in fact, v1 only supported Asterisk. The advent of Adhearsion meant developers could write sophisticated Asterisk applications in a real programming language, with all the attendant benefits.

Then developers, myself included, starting asking for FreeSWITCH support.

FreeSWITCH

FreeSWITCH is ‘the other' open source PBX. While it began as a fork of Asterisk, FreeSWITCH is more than just another open source PBX. A "soft-switch", FreeSWITCH is designed for flexibility. It’s highly configurable, and can be bent to be almost anything you want it to be, although this sometimes means writing C/C++ code.

As a result of the platform-independent design of Adhearsion 2 and Punchblock, FreeSWITCH support was added in Adhearsion 2.1. And it was easy to add, thanks in part to the incredibly clean and comprehensive API of FreeSWITCH (EventSocket). There are, however, still some things incomplete in our implementation, and work is underway to improve this support (Further details on this work will be available soon, so sit tight.). The good news is that, in the near future and over time, FreeSWITCH support will become more comprehensive.

Voxeo PRISM

Voxeo PRISM is a communications application server with support for SIP, HTTP & XMPP, as well as a rich media server for TTS and ASR, among other things. Produced by Voxeo Labs, a sister company of Voxeo Corporation, one of the biggest providers of IVR technology in the world, Voxeo PRISM is a commercial product and comes with all that being a commercial product entails.

Unlike Asterisk and FreeSWITCH, PRISM is not a PBX, although it is possible to write applications for PRISM to provide PBX features such as voicemail, intelligent routing, queuing, and so forth. In the Adhearsion 2.0 release by way of the Rayo protocol, we added support for PRISM. Many of the apps mentioned above can now be written using Adhearsion rather than by dropping down to SIP servlets. Of the three platforms I’ve mentioned — Asterisk, FreeSWITCH and PRISM, users of PRISM enjoy the most comprehensive set of features currently available in Adhearsion.

Questions to Help You Choose a Platform

Are reliability, good support and an SLA more important to you than cost?

If the answer is “Yes”, go for PRISM or be sure to find a support provider for one of the other platforms. Keep in mind that your Adhearsion application will likely not be covered under a platform deal. This is because Adhearsion uses an abstraction on top of the Asterisk and FreeSWITCH APIs that many support providers are unfamiliar with or unable to support. Consider taking out support contracts with a provider that will cover your whole stack, including your application code.

Do you have a philosophical affinity with Open Source software or require the ability to make modifications to your platform in-house?

If yes, use Asterisk or FreeSWITCH. While Asterisk has the longer open-source legacy, in our experience, getting patches in to FreeSWITCH tends to be quicker and the code easier to understand and modify.

Do you need easy integration with ASR and TTS engines?

If so, go with Voxeo PRISM or maybe FreeSWITCH (though be aware that not all combinations are known to work, we'll provide more details on this soon). The most comprehensive support for ASR and TTS in Adhearsion is currently only available on Voxeo PRISM; we do not yet support MRCP-based ASR on Asterisk or FreeSWITCH, although this is coming very soon. Unfortunately, Asterisk's UniMRCP adapter is missing several features, and getting it compiled is difficult. The situation is improving, but the other platforms have a head start here.

Do you need free simple TTS?

Then consider FreeSWITCH. It comes bundled with flite, which produces fairly terrible text to speech, but is completely free.

Do you have a large deployed infrastructure or significant level of in-house experience with a particular platform?

While it is tempting to 'go with the flow' on new projects, it is my firm belief that your company’s history and comfort level with a particular platform should be carefully and critically weighed against the technical fit of the platform and project. This mostly applies to choosing between Asterisk and FreeSWITCH, and I strongly suggest that anyone tempted to use Asterisk simply out of habit give FreeSWITCH a try and evaluate the fit. One of the benefits of Adhearsion’s platform independence is that the same application should be deployable to any of the supported platforms and should work similarly, save a small collection of differing features (for example, Asterisk and FreeSWITCH currently do not support mixers or whisper functionality). And note also that multiple platforms can happily coexist in a datacenter; just because your other apps run on one platform doesn't mean the next one couldn't run on another

If any of you have input or feel differently about my logic, leave a comment; I’d love to hear from you. Likewise if anyone feels they need further help choosing the correct platform for their application or selecting any other components of their stack, feel free to reach out to us at Mojo Lingo to see how we can help your project succeed.

The post Adhearsion Voice Platforms: A Comparison appeared first on Mojo Lingo.

David was a visible and energetic member of the Adhearsion community, having presented at both the 2011 and 2012 AdhearsionConfs as well as contributing lots of testing, feedback, pull requests, documentation fixes, and more to the Adhearsion platform.  What makes this news even harder for us at Mojo Lingo is that David had accepted our offer of employment just days earlier, and was scheduled to be in Atlanta in less than two weeks.  We were all very impressed by David and excited to have his skills and easygoing humor join our small team.

As a memorial to his legacy, I've included the video from his presentation at AdhearsionConf 2012.  In addition to infusing his creative and genuine style throughout the presentation, he talks a lot about how he improved his skills through applied practice in Ruby, and how important the process of continual improvement is to being a good developer.  Perhaps David was providing us more than a lesson for development, and we are grateful he shared it with us.

Lessons Learned from 1.x to 2.x - David Ryder from Adhearsion Foundation, Inc. on Vimeo.

The Adhearsion community has lost a great resource and a great friend.  Our hearts and prayers go to his family, especially his wife and very young son, at this most difficult time.

The post In Memorial: David Ryder appeared first on Mojo Lingo.

Some of you that have been following along closely, may already have noticed our involvement with Tropo.com. We worked closely with Voxeo at the inception of Tropo which was subsequently launched at eComm in March of 2009. The goal of Tropo.com is to bring a scalable telephony cloud infrastructure to the broadest group of developers by allowing development directly in dynamic languages. Languages included are: Javascript, Groovy, PHP, Python and Ruby. We will now be focused on bringing Tropo and Adhearsion together to offer the power of Adhearsion with the scale of Tropo, while extending capabilities in the other languages.

Jay and I as founding members of Voxeo Labs is no accident. The DNA of Voxeo Labs is a commitment to open-source. Adhearsion will continue to evolve as an open-source framework with continued support for Asterisk along with Tropo and others. Our goal is to provide the widest possible set of deployment choices for the Adhearsion community, while eliminating friction for those who want effortless deployment and scaling.

Stay tuned as we have lots of interesting announcements just around the corner. In the meantime, thanks to the entire Adhearsion community for the support that allowed us to pursue this next step.

Here are the slides:

While attending Euruko several weeks ago, I had the opportunity to see @aslak_hellesoy present the Cucumber Behavior Driven Development (BDD) framework. BDD is a part of Agile software development focused on bringing the domain expert into the specification process through the use of natural language. This is done through the users and developers creating a story that is directly parsed by the code for tests.

Aslak’s presentation was well done, giving some compelling reasons to adhere to BDD principals, showing that using Cucumber made it a joy. Thing is, Cucumber is already a part of testing for  the Adhearsion framework and some specific projects we are working on. What was new to me, was a lightning talk given at the end of the day on Cucumber-Nagios.

Cucumber-Nagios is a project developed by @auxesis that bridges Cucumber test results into the Nagios monitoring tool. This allows you to take any test you have written and allow the steps to become part of an on-going systems monitoring strategy. While Cucumber-Nagios is geared towards web application testing, you may use this beyond to test virtually any application.

Naturally I have started using Cucumber-Nagios to create a series of tests to do application level monitoring of Adhearsion and Asterisk. This now allows one to not only ensure that these processes are running, but they are working as defined by the BDD specification.

To start, I created a couple of features that will connect to Adhearsion and/or Asterisk. Then ping the Asterisk Manager Interface (AMI) looking for a corresponding pong, ensuring the systems are still responsive.

The feature to ping the AMI uses the straight forward Gherkin language to create a feature file with the test specification:

The feature file is then parsed by the steps definitions as set out in the step file:

The methods called in the step definitions then invoke the system testing library I wrote specifically for these telephony systems. The result is having a standalone test framework that may provide direct input at an application level to Nagios, as well as provide plain English feedback to anyone looking to track down the cause of the problem.

First, if Asterisk is down we may see the result of running the Cucumber plain English test:

Then the corresponding Cucumber-Nagios test that also fails with a ‘Critical’ error:

Now, if Asterisk is up and all is fine we may see these same tests pass. First, for Cucumber all is green:

Then for Cucumber-Nagios we see all 3 tests passed:

The great thing about this approach is that it may be used to test systems using a standard open source dynamic language like Ruby. These tests are not limited to testing Ruby systems though, as you may see in this case I am testing the Asterisk open source telephony engine. Further, I may test not only the standard interfaces of various systems, but that the behavior of my application deployed within these systems is behaving as required from a specification perspective. This is a powerful approach to systems monitoring and troubleshooting, pulling the system administrators directly into the development process.

You may check out my telephony-system-tests project on Github. My plan is to greatly extend this system testing framework over time in order to have a stable of standard tests for Adhearsion, Asterisk, Freeswitch and others in the future. One of the next steps will be to integrate SIPr into the framework for testing SIP dialogs as well.

Another interesting item from Euruko that I will be posting about soon is Chef, which was presented by Joshua Sierles of 37Signals at the conference. So much more to come on this front.

“…I needed to leverage ‘all the work’ done in .Net…As I discovered, the marriage of .Net and Adhearsion was lovely, thanks to the RESTful RPC [API of Adhearsion]“

So David created an example and has graciously shared it with the rest of us. The example includes a component in Adhearsion that has this method extending the ‘methods_for :rpc’:

def launch_call_rpc(vars)
  ahn_log.ami vars   
  
  channel = vars["src"]
  exten = vars["dest"]
  options = { "Channel" => channel,
              "Context" =>  "callback",
              "Exten" =>    exten,
              "Priority" => “1”,
              "Callerid" => “33333” }
  result = Adhearsion::VoIP::Asterisk.manager_interface.originate options
  
  ahn_log.ami "status: call Queued" 
  ahn_log.ami result   
end

Following the full README and example here, this C# code may then be used to invoke the Adhearsion REST API:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using JSONSharp;
using System.Net;
using System.IO;

namespace adhearsion
{//adhearsion server is http://192.168.1.62:5000
    class Program
    {
        static void Main(string[] args)
        {
            Program.connect();
        }
        static void connect()
        {
            try
            {     
                ahnparams ahn = new ahnparams();
                ahn.src = @"SIP/4031234567@192.168.1.200";
                ahn.dest = @"7801234567";
                //Pass it to our static reflector, which will build
                JSONReflector jsonReflector = new JSONReflector(ahn);   //JSONSharp converts the class to JSON format
                //Console.WriteLine(jsonReflector.ToString());
                NetworkCredential myCred = new NetworkCredential("jicksta", "roflcopterz");

                CredentialCache myCache = new CredentialCache();

                myCache.Add(new Uri("http://192.168.1.62:5000"), "Basic", myCred);


                WebRequest request = WebRequest.Create("http://192.168.1.62:5000/launch_call_rpc");
                request.Credentials = myCache;
                string postData = "["+jsonReflector.ToString()+"]";  //had to add the [] for it to work with restful_rpc just like php json
                Console.WriteLine(postData);
                request.Method = "POST";
                byte[] byteArray = Encoding.UTF8.GetBytes(postData);
                // Set the ContentType property of the WebRequest.
                request.ContentType = "application/x-www-form-urlencoded";
                // Set the ContentLength property of the WebRequest.
                request.ContentLength = byteArray.Length;
                // Get the request stream.
                Stream dataStream = request.GetRequestStream();
                // Write the data to the request stream.
                dataStream.Write(byteArray, 0, byteArray.Length);
                // Close the Stream object.
                dataStream.Close();

                WebResponse response = request.GetResponse();
                // Display the status.
                Console.WriteLine(((HttpWebResponse)response).StatusDescription);
                // Get the stream containing content returned by the server.
                dataStream = response.GetResponseStream();
                // Open the stream using a StreamReader for easy access.
                StreamReader reader = new StreamReader(dataStream);
                // Read the content.
                string responseFromServer = reader.ReadToEnd();
                // Display the content.
                Console.WriteLine(responseFromServer);
                // Clean up the streams.
                reader.Close();
                dataStream.Close();
                response.Close();
            }
            catch (Exception e)
                {
                    throw e;
                }

        }
    }
}

This is a great example of the cross-platform capabilities of Adhearsion that you get for free via REST. You do not have to be a Ruby-ist to take advantage of adding voice capabilities to your web applications. You may use virtually any language and platform that may consume web services.

We definitely appreciate it when our community takes the time to share their Adhearsion experiences with the rest of us. Thanks David, and for the rest of you the full example with his README is available here.

Of course you could setup routing rules in your phone system each time you move to a new timezone, but good luck remembering to do this. Tripit now makes a blog badge available that reports your current location based on city, state or country:

My Tripit Adhearsion Comonponent on Github allows you to mashup the details from your badge and use them in your dialplan. Now, you may add this component to your project and add something like this to your Adhearsion dialplan:

adhearsion {
  user_time = tripit_user_time?('jdoe')
  if user_time
    ahn_log.tripit.debug user_time
  else
    ahn_log.tripit.debug 'Error'
  end
}

You may then use this information to decide whether to dial your mobile at your destination, or send it straight to voicemail. This is a great example of using Adhearsion to mashup data available on the web and use it to control your communications.

To this end we have now migrated the Adhearsion website, wiki and API docs to Amazon EC2. Leveraging S3 and EBS we have a great solution that allows us to quickly fire up more servers if and when needed. The cloud is great.

We have also moved the Sandbox to a new hosted server. Our friends at Voxeo have provided a great server for us and are now sponsoring the Adhearsion Sandbox. It is great to have a visionary leader in the telephony cloud space involved with the Adhearsion community.

I would like to take this opportunity to remind folks what the Adhearsion Sandbox provides. We have provided a hosted system that takes away the need to install your own Asterisk to get started developing Adhearsion applications. Simply install Adhearsion, sign-up for a Sandbox account and get started writing apps. Our goal is to lower all the barriers to make it easy for developers to realize the possibilities of voice in modern web development.

Enjoy the new servers!

I used a combination of Rack and Passenger, since they make the process so easy and production ready. To this end I have updated the README and Click To Call component I covered in my previous blog post to include the how to and Rack configuration file required.

To get this up and running do the following:

• Install the Apache Webserver
• sudo gem install rack
• sudo gem install passenger (follow instructions here for compiling the Apache module)

Copy the files and directories in ~ahn-project/components/restful_clicktocall/web directory to the appropriate file system location for your Apache web server. Add these virtual host settings to your Apache configuration (ie – /etc/httpd/conf/httpd.conf):

<VirtualHost *:80>
  ServerName ec2-174-129-89-20.compute-1.amazonaws.com
  DocumentRoot /var/www/restful_clicktocall_web/public
</VirtualHost>

Stay tuned for the upcoming Amazon Machine Image!