At Voxeo Labs we clearly have an affinity for clouds. Now that we provide the ability to easily push recorded audio files out of the Tropo cloud, we would like to provide an example of how to receive and post these files using other great clouds.
For this example we are going to use Sinatra to create a REST web service application. This application will then be deployed to Heroku where it will receive and then push the recorded audio files from Tropo up to an Amazon S3 account.
First, Sinatra provides a simple domain specific language in Ruby for creating REST web services, or whole web sites if you choose to. In this case we are using Sinatra to write our REST API to receive and then process the audio file. Creating an HTTP resource with Sinatra is as simple as this:
get '/pizza' do
order params['toppings']
# Do some more stuff
end
To get this resource you would then put this in your web browser:
http://www.yourhost.com/pizza?toppings=pepperoni
If we take this a step further, writing the code to receive an audio file and post to Amazon S3 is not much harder:
post '/post_audio_to_s3' do
AWS::S3::S3Object.store(params['file_name'],
File.open(params['filename'][:tempfile].path),
AWS_CONFIG['bucket_name'])
end
In your Tropo app you may then write a script to record and send an audio file:
answer
say 'Welcome to the recording application'
startCallRecording 'http://www.yourhost.com/post_audio_to_s3?file_name=myfilename.wav'
ask 'Do you like chocolate?', { :choices => 'yes, no' }
stopCallRecording
hangup
Now we have our web service, but where to run it? This is where Heroku comes in. Heroku is an ‘instant Ruby platform’ that allows you to deploy an application, via Git, and have it up and running on a scalable infrastructure in minutes. Lucky for us, Heroku excels at running Sinatra apps, and they even have the AWS-S3 library built in. All you need is a Heroku account, which is free to get started with a Blossom, and you are ready to start running your web service.
Last but not least, you will need an Amazon S3 account to store your files. Thats it, you may now start moving your files through the clouds to Amazon, or use this as an example to store them wherever you choose. The full application ready to deploy locally or to Heroku is available at Github here.
No related posts.
I always enjoy learning what other people think about Amazon Web Services and how they use them. Check out my very own tool CloudBerry Explorer that helps to manage S3 on Windows . It is a freeware. http://cloudberrylab.com/
Just tried this on Heroku Jason. Worked like a charm, VERY VERY nice. =)
Didnt work in 2011 on Heroku unless you add .gems file listing sinatra and aws-s3. (Or a Gemfile)
Now, it ALMOST works BUT it IGNORES the filename= you POST in params[] and saves the file to the some internal filename (that is the temp file on Tropo used to hold the audio temporarily while recording and transcribing). The problem is THAT filename is NOT accessible to a webapi app…
so there’s NO way (far as we can tell) for our app to “know” the name of the saved file!
The problem with your example is this: since Tropo is POSTING data (and using the INTERNAL temp filename inside the params['filename'][:filename] the URL parameter you’re showing (with the ?filename=myfilename.wav) is simply ignored by the Sinatra post handler. So the internal filename (which is UNavailable to the originating webapi app) is what is created.
what your simple POST handler example needs to do is take the filename=xyz off of the url and use THAT as the first parameter of the S3Object.store() function. That’s the bug.
Good catch, and thank you. I did have it fixed here:
https://github.com/tropo/tropo-audiofiles-to-s3/commit/f6b551f968176a636c0d5d8b2a9dacd82152108e