Looks like Ted hit the trifecta on this application using APIs from Tropo, Google Latitude, and Wikipedia! You can call the Moveable History demo at (857) 239-0152!
Moveable History will begin reading from the Wikipedia page of the closest historic location to our John Paul Jones avatar. Each time you press a key on you phone, you will hear about the next-closest location, in ever widening circles.
This is all driven by Google Latitude. John Paul Jones has signed up, and he’s currently located in downtown Portsmouth, NH.
If you would like to have Moveable History track your location, wherever you or your personal avatar roams in the continental United States, sign up here.
Moveable History uses state-of-the-art OAuth, with no passwords involved. You can revoke authorization at any time.
One of the things that makes Tropo truly amazing is it’s support for speech recognition.
Speech recognition is becoming increasingly important in our everyday lives. Smartphones and powerful handheld devices enable multimodality, and there are more and more restrictions placed on our use of phones while doing other things (like driving).
If you want to build cloud-based mobile applications, you’ve got to have speech recognition. Why would anyone use a platform that tied a developer to nothing but DTMF input (touch tone entry using a key pad) – a technology that was initially rolled out to the public when John F. Kennedy was still in the White House.
The screencast below demonstrates how to use Tropo to build a speech recognition application that can capture a caller’s address. All of the code used in this demo can be obtained on GitHub.
If you are building a mobile application and would like to use speech recognition, Tropo provides some nice choices.
If the input you want to collect is relatively simple, you can use one of the prebuilt simple Tropo grammars. In addition, as discussed in the screencast above, you can use industry standard SRGS grammars as well. Tropo also supports advanced grammar features like semantic interpretation.
While this post focused on using speech recognition to collect an address, you can use it for almost anything your application requires. With Tropo, the sky is the limit.
This Christmas, the open government data elves have been busy.
They’ve been building useful applications with data sets from municipal governments, open source software and multi-channel communication platforms like Tropo.
With all of the data that is being released by municipal governments, there are increasing opportunities to build useful and interesting applications that can help people and make their communities better.
Sometimes, however, the format of the data that is released doesn’t always lend itself to easy use.
For example, many governments release geographic data sets in shapefile format – this can be a bit of a hinderance for some developers to work with, particularly if they don’t use it often or don’t know much about this type of format.
Fortunately, there are a growing number of open source tool available that make working with geographic data in general, and shapefiles in particular, much easier.
The video below demonstrates how to quickly create a powerful communication application for citizens in New York City to find library locations near their homes.
This demo application uses data from the New York City Data Mine, GeoCouch, a fork of CouchDB that support geospatial queries of CouchDB documents, shp2geocouch, a Ruby gem developed by Max Ogden to convert ESRI shapefiles into CouchDB databases and the Tropo Scripting platform.
This project – completed in just a few hours – demonstrates the power of Tropo to quickly build sophisticated cloud-based communication applications that can be used on a number of different channels to deliver useful government information to citizens. (Note – this demo application can easily be adapted for use with one of a half dozen different IM networks, Twitter, SMS and even voice.)
Best of all, if you’re interested in working on a project like this yourself, all of the source code for the Tropo scripting application that powers this demonstration is available on GitHub.
As more and more government begin to release geographic data in shapefile format, the opportunities to build useful applications will continue to grow.
With powerful tools like CouchDB, shp2geocouch and Tropo, developers will be limited only by their imaginations in how the use this data to make their communities better.
Consider that in the last few weeks we’ve written one, two, three, four blog posts covering different ways to leverage the unique nature of our scripting platform to build blazing fast, real-time communication apps.
And the promise of speed is one of the things that has us so excited about Node.js – the server side framework for writing JavaScript applications.
We’re constantly adding new features to our Node.js library for building Tropo applications. Just this week we added support for the new Tropo REST APIs that allow you to provision phone/SMS numbers and IM addresses for your apps, and for injecting events into running Tropo apps.
And we’re also working on other goodies to make it easy for Node.js and JavaScript developers to build cutting edge, multi-channel communication apps. You’ll be hearing more about these in the weeks ahead, in future blog posts.
Learning to Node
Node.js is a good candidate for applications that have high concurrency or low latency requirements because of one of it’s chief characteristics – it’s non blocking. When you ask Node.js to perform an operation, it does not wait for the completion of that operation before executing subsequent instructions. This lets you write more efficient (faster) applications because you don’t have to wait for the completion of a specific operation before doing something else.
Node.js is also event-based rather than thread-based. This makes it different from other web technologies (like Apache) that spawn new threads to handle concurrent connections. Node.js uses an event loop instead of threading, which provides a much more efficient approach to concurrency. This makes Node.js particularly well suited for applications that have lots of connections that are non-trivial in length – like real-time applications.
There are add-ons and libraries for other languages that provide a similar construct to building event-based apps; Twisted in Python, EventMachine in Ruby or AnyEvent in Perl.
With Node.js you don’t need to use an external library – events are baked in.
(more…)
Some of the most-requested features for Tropo have arrived. APIs to manage applications, add and remove numbers, and remotely control a running Tropo session are now available. If I were a cliched hack, I’d call this a Christmas gift for Tropo users. But I’m not, so I won’t.
Provisioning – For managing applications, Tropo has a set of new REST APIs that allow you to do with code anything you can do with the Tropo UI. Create applications, add and remove phone numbers, fetch all the contact methods for your application, change URLs. If you’ve set up billing information, you can even move applications to production. All from your code. Even some things you can’t do in the UI can be done from the API (like moving a number between apps or switching an app from Scripting to WebAPI).
Remote Control – A common request is to allow a developer to break a caller out of a conference call, stop hold music, or cancel some long-running operation. Our new event API allows you to send an “exit” signal to any running session and have it interrupt any Tropo function. You can even target that signal at a specific piece of code, useful if you have 10 different say() functions in your app, but only want to stop the one that’s playing hold music.
The event API is available on the servers powering the free development applications now and will be promoted to production applications in about two weeks.
SSL – All APIs are now available over SSL and all examples are being updated to show https urls. Using non-SSL encrypted connections will continue to be available, but we strongly encourage that all API calls be made over SSL. We’ve also added SSL certificates to our WebDAV servers, allowing you to securely update application code over WebDAV.
In addition to these new features, Tropo still offers:
Free developer accounts – Try out Tropo without adding a credit card or keeping track of limited developer credits. Tropo is free for developer usage, including phone numbers around the world.
24×7 Support – Our support team is available around the clock if you have any questions while working on your application.
Worldwide Platform – Phone numbers in 41 countries. Voice recognition and text to speech in 9 languages. Calls and SMS to anywhere in the world. International telephony is hard. We make it easy.
Skype, SIP, iNum, XMPP, and more – Tropo’s way more than just phone numbers. Send text messages, interact over IM, call into your app with Skype or SIP. We provide you with multiple communications channels and the tools to use them.
So get cracking. Build something great with Tropo. We can’t want to see what you do. Don’t have an account? Sign up free.
We continue our focus this week on ways to create real-time interfaces for your users via Tropo for phone calls, instant messaging, SMS and Twitter. As promised in my recent blogpost, WebSockets with Tropo, I would like to build upon Chris Matthieu’s XMPP with Tropo post by throwing BOSH into the mix.
“Bidirectional-streams Over Synchronous HTTP”, or BOSH, provides for two-way communications over HTTP, emulating much of TCP. This allows yet another approach for creating low-latency interfaces to Tropo using the unique capabilities of our scripting platform. With this, you skip the latency inherent in chatty request/response APIs over HTTP REST. Allowing you to have fluid interactions with users in public spaces where their only interface to your application is a phone call.
Tropo has native support for XMPP built right into the standard API. Therefore a call comes into Tropo, we start asking the caller for input and then send those responses to the XMPP user that represents our browser application. In the browser we use JQuery and Strophe.js for the XMPP/BOSH support and then Artisan.js for the HTML5 Canvas tag rendering of the graphics. On the Tropo side we have a Ruby script that looks like this:
require 'json'
loop do
ask "Press a key or push zero to exit.", {
:choices => "[1 DIGITS]",
:onChoice => lambda { |event|
input = { :command => event.value }.to_json
message input, {
:to => "troporiffic@jabber.org",
:network => "JABBER" }
break if event.value == "0"
}
}
end
The simplicity of this is driven home by the fact that the Tropo API is the same for interacting with phone calls or messages (IM, Twitter or SMS), the power of a unified API. You may watch this in action here:
The Tropo script and Javascript/HTML examples may be found on Github here (Tropo script and HTML/Javscript example). And don’t forget to add and enable a Tropo Jabber account on your application:
I was inspired by Jason’s work to try and replicate it with a slightly different kind of technology. I also wanted to use Node.js.
I had come across the very cool faye Node.js library a while ago and wanted to try it out on a small project. This project seemed like the perfect fit.
Having now used faye for this project, I can tell you that I am amazed at how easy it is to use, and how powerful it is.
var faye = require('faye'), sys = require('sys'),
http = require('http'), port = process.ARGV[2] || '8000';
var bayeux = new faye.NodeAdapter({ mount: '/tropo' });
var server = http.createServer(function(request, response) {
response.writeHead(200, {'Content-Type': 'text/plain'});
response.write('Move along. Nothing to see here.');
response.end();
});
bayeux.attach(server);
sys.puts('Server listening on port ' + port + "...");
server.listen(port);
Examine the code for the Bayeux server used in this example above – in less than 15 lines of code I was able to create a server that can act as a real-time DTMF relay between a phone application running in the Tropo cloud, and multiple clients who can consume that input. How awesome is that!
To provide a bit more clarity and some contrast to the approach Jason used in his post, let’s talk about the Bayeux protocol and Comet servers.
Comet is really an overarching term used to describe push technologies in web browsers. Bayeux is one protocol for implementing a Comet server. From the spec:
Bayeux is a protocol for transporting asynchronous messages (primarily over HTTP), with low latency between a web server and a web client. The messages are routed via named channels and can be delivered:
server to client
client to server
client to client (via the server)
Bayeux seeks to reduce the complexity of developing Comet web applications by allowing implementors to more easily interoperate, to solve common message distribution and routing problems, and to provide mechanisms for incremental improvements and extensions.
As Jason described in his post, the WebSocket spec is still in flux and will likely change going forward. How things shake out with the WebSockets spec and where Comet technoloiges fit into the mix is still the subject of some debate.
That aside, it is worth noting that you can use either technology with Tropo, and other real-time technologies as well.
With Tropo, there are a number of options available for building real-time applications across multiple channels.
Would you like to know if your outbound call was answered by a human or an answering machine? Voicemail systems are pervasive today. In fact, they seem to answer the phone more than people do.
In the telecom world, this simple request is called Call Progress Analysis (CPA). To perform CPA correctly like on the Voxeo Evolution enterprise hosting platform, it requires advanced Digital Signal Processing (DSP) and voice activity detection to analyze the audio signal after a call is connected, making it possible to programmatically determine if the answering party is a human speaker, an answering machine, a modem, or even a fax.
Fortunately, Tropo will be able to leverage Voxeo’s years of work in this field and incorporate this technology into our cloud platform soon. Until then, we have a trick to share with you! Most of the telephony services simply measure the length of time of the callee’s answer greeting. If it’s less than 3 seconds like “hello” then return human. If it’s greater than 3 seconds then return machine.
You could even go as far as evaluating the length of time less than 3 seconds to determine if the call is answered by a residence of a business establishment. Typically residences say “hello” which is less than 1.5 seconds while businesses say “How may we help you?” which is typically between 1.5 to 3 seconds.
We recently assisted several Tropo customers with detecting Human vs. Answering Machine so we wanted to share with you the simple Ruby script that we used to successfully make this determination.
call 'tel:+14805551212'
starttime = Time.new
record ".", {
:beep => false,
:timeout => 10,
:silenceTimeout => 1,
:maxTime => 10
}
endtime = Time.now
difference = endtime - starttime
if difference < 3
say "human"
else
say "answering machine"
end
This demo is written using Tropo’s Scripting API and is hosted on our cloud platform for you. It places a phone call when your application invokes our API URL with your token. On connect, it starts the timer. On answer, it records the callee’s greeting until 1 second of silence is detected. On silence, it stops the timer and subtracts the diference to determine the length of the greeting. If it’s less than 3 seconds, you can assume that a human answered the call; otherwise, assume that a real-live robot did!
Interactive applications require low-latency, just like phone calls, in order to make them real-time and natural. While REST drives much of the APIs on the web today, sometimes it just adds too much overhead and therefore introduces latency. In steps WebSockets, a part of the HTML5 standard. WebSockets provide a persistent bi-directional connection between your users and yours services. Now, with Tropo, you may write real-time applications that provide snappy interactions to drive games, interactive billboards and just about any other interactive application that requires a great user experience.
An example of just such an application was one built by Manou Andraos and Melissa Mongiat for the Mutek BlocJam festival in Montreal in June 2010. They projected a musical collaboration interface onto a seven story building in downtown Montreal. Then published a phone number that people on the street could dial with their mobile phones and interact together in a public space to make music in real-time.
This project was built using Adhearsion, a project sponsored by Voxeo Labs, which allows for real-time streaming of user input to an application using Asterisk.
Tropo also allows for real-time streaming of user input from the cloud. While Tropo may do REST just fine, the real power in our platform is Tropo Scripting. By hosting your app on our application servers, you may wire your apps to the web the way you want. So, building on Chris Matthieu’s recent post on using XMPP to speak to the web, and my previous post for using TCP Sockets, we will now walk you through using WebSockets to drive your applications from the Tropo cloud.
We created a prototype that provides an example of how to stream real-time DTMF (those sounds your phone makes when hitting the keys) input from a user to your application over a WebSocket.
In the diagram above you may see that we created a ‘WebSocket Relay’ that takes two inbound WebSocket requests and relays them via a unique session to each other. This allows for applications behind firewalls to establish outbound connections, rather than having to accept inbound requests. For the relay we used EventMachine and the em-websocket gem. And for the Tropo Ruby script we used the web-socket-ruby gem (originally created by Hiroshi Ichikawa) to establish the outbound WebSocket from Tropo to the relay. Here is this scenario in action:
(The source code for the WebSocket Relay, the Tropo Ruby script and the HTML5 web page are available on Github here.)
The Tropo portion of the script that powers this is quite straight forward (full script here):
# Create a connection to the WebSocket server
client = WebSocket.new("ws://sandite.orl.voxeo.net:8082")
loop do
result = ask "Press any digit, or press zero to end the session.", { :choices => "[1 DIGITS]" }
msg = { :type => 'publisher', :id => 'tropo-app1', :data => { :caller_id => '4155551212', :command => result.value } }.to_json
client.send msg
break if result.value == '0' || $currentCall.isActive == false
end
say 'Thank you for playing, goodbye.' if $currentCall.isActive
While the EventMachine WebSocket Relay portion is only 57 lines of code:
class SessionChannels
def initialize
@channels = {}
@mutex = Mutex.new
end
def publish(id, message)
create_channel id if @channels[id].nil?
@channels[id].push message
end
def subscribe(id, socket)
create_channel id if @channels[id].nil?
@channels[id].subscribe { |msg| socket.send msg.to_json }
end
private
def create_channel(id)
@mutex.synchronize { @channels[id] = EM::Channel.new }
end
end
@session_channels = SessionChannels.new
EM::WebSocket.start(APP_CONFIG['websocket']) do |socket|
socket.onopen {
ap "WebSocket connection open"
}
socket.onmessage { |msg|
msg = JSON.parse msg
case msg['type']
when 'subscriber'
@session_channels.subscribe(msg['id'], socket)
when 'publisher'
@session_channels.publish(msg['id'], msg['data'])
end
}
socket.onclose { ap "Connection closed" }
end
Now all that limits you for creating interactive applications is your imagination. If you would like any additional insight or assistance in exploring this approach or others, please do not hesitate to reach out to us on ‘support@tropo.com‘.
Note: Recently a security issue was disocovered in the WebSocket protocol which has caused Firefox to remove WebSockets from their latest beta. While you may still use WebSockets in certain scenarios, the standard now appears to be in flux again. WebSockets will be around, albeit most likely with changes. We will be following this post up with a more detailed overview of how to use XMPP and BOSH from our network, as Tropo natively supports XMPP, to achieve the same real-time capabilities.
Mark Headd recorded an awesome screencast on getting Tropo running on Node.js using the Tropo Node.js library. While libraries make code easier to write, I wanted to see what was happening under the covers when writing a Tropo application using Node.js without any magic.
This experiment was easier that you may think! Since Tropo speaks JSON natively, all you need to do is spin up a node.js server like the hello world demo on the node.js home page. Next substitute “application/json” for Content-Type and send Tropo JSON text in place of hello world as shown below:
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'application/json'});
res.end('{"tropo":[{"say":[{"value":"This call is running from node J.S. Have a nice day. Goodbye."}]},{"hangup":null}]}');
}).listen(3000, "127.0.0.1");
console.log('Server running at http://127.0.0.1:3000/');
Next, deploy this script to your node.js hosting provider or run Tunnlr as demonstrated by Mark and create a new Tropo WebAPI application pointing at the deployed URL. Now call your application and listen to Node.js in action.