Have you seen one of these codes before? They’re called QR Codes and can be used on mobile phones to direct your browser to a specific web page or even display more information (4,000 characters) about a product or event. They can also be used to dial phone numbers and send SMS messages too!
Some mobile phones ship with pre-installed QR Code readers on them but more often than not, you will need to go into your phone’s AppStore and download one for your device. Once your your scanner is loaded – point it at this code – I DOUBLE DOG DARE YA!
This code was generated to call a phone number associated with the following Tropo script:
say "http://hosting.tropo.com/13539/www/audio/rickroll.wav"
say "http://the-ppole.com/audio/Hotlinkers.mp3"
This Tropo script is running on our Scripting API and basically announces that you are about to be “Rick Rolled” and then proceeds to play to famous Rick Astley song “Never Gonna Give You Up” from some random MP3 link on the Internet. Imagine the fun that you could have with combining QR Codes with Tropo numbers to route mobile phones to your new killer Tropo application!
I used a QR Code generator from Kaywa to create the image you see above. Here’s an example of how easy it is to create:
Captain Kirk was always demanding more out of his Chief Engineer on Star Trek by saying, “Scotty, we need more power.”
While there is no limit on the number of inbound SMS messages your application can receive, Tropo’s 10 digit numbers are limited by the SMS carriers to sending 10 outbound messages per minute per number (UPDATE – this limit has been improved to 1 message per second, 60 messages per minute as of July 22, 2011). All 10 digit US SMS numbers have such a rate limit but it’s up to each API provider to adhere to their request.
Our SMS Shortcodes, on the other hand, have no limit on outbound SMS messages but there is a leasing fee to acquire these “Warp Speed” numbers. Contact sales@tropo.com if you are interested!
If you feel like Captain Kirk when using 10 digit numbers and you want more power but you are not ready to move up to our SMS Shortcodes, here’s a trick! You can attach an unlimited number of 10 digit voice/sms numbers to your Tropo application. Each number is capable of sending 10 messages per minute per number. Simply spread your outbound SMS messages over a larger pool of 10 digit Tropo numbers!
Here is an example of how I was able to help a customer do this using Ruby:
rate = 10 #per minute
totalmessages = 30
numbers = ["15123330824", "15713575541"]
count = 0
total = 0
starttime = Time.new
while total < totalmessages do
if Time.now - starttime < 60 and count < rate
numbers.each do |number|
# Send SMS
message "hello " + count.to_s, {
:to => "tel:+14803194368",
:callerID => "tel:+" + number,
:network => "SMS"}
end
count = count + 1
total = total + 1
elsif Time.now - starttime > 60
# Reseting counters
starttime = Time.new
count = 0
end
end
In this example, we set the rate limit and the totalmessages that we would like to send out. We attached multiple phone numbers to our Tropo application and list them in the numbers array. Next, we loop through the numbers sending an SMS message for each number until we hit our rate limit for the minute. Finally, we wait for the rest of the minute and reset the timer and counters and loop through the rest of next batch of numbers until our totalmessages are hit.
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…)
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.
One of the great things about Tropo is that it lets you run sophisticated communication applications in the cloud.
Tropo makes it easy to build multi-channel applications in the language of your choice and makes deployment and maintenance easy. We take care of all of the hard stuff.
But what if you want to build an application that stores information? Let’s say you want to create a survey application that sends out messages to registered users and asks them to provide the answer to a question. You’ll want to be able to store responses to your survey and examine the replies from users.
Since Tropo is a cloud communication platform, it pairs easily with other cloud infrastructures. This post will cover one way of pairing Tropo with a cloud-based instance of CouchDB.
This application sends out a message on a specified channel and then saves the response to that question in a CouchDB instance. This example uses instant messaging as the channel, but you could easily tailor this script for other channels as well, like SMS.
Make note of the details of your CouchOne instance – make sure you modify the sample application code to use the details of your instance.
Cloud-Based Survey App
Once you get the code for this example, use it to set up an application in your Tropo account. If you want to use it as is (i.e., just using the IM channel), you’ll need to assign a Jabber IM address to your application – this is easy to do in the Tropo application settings.
Once you are ready to test, you’ll need to use one of your outbound tokens from your account. The following video demonstrates how to test the application, how to check CouchDB for new responses and how to monitor CouchDB for responses that come in from users over time (via the _changes API).
Because Tropo is a true cloud communication platform, you can use it in conjunction with other cloud-based infrastructures, like CouchDB from CouchOne.
Tropo + CouchDB = Cloud Communication Awesomeness!
Are you building real-time gaming applications that use the phone (Voice or DTMF touch-tone) and require immediate response to your application? Ever wondered how to get input from a caller at the speed of light – rather than traditional AJAX API calls?
Tropo’s Scripting API allows you to do all sorts of interesting hacks to make this possible! Earlier, Jason Geocke demonstrated how to do this using real-time TCP sockets in the following blog post: Using Persistent Sockets in Tropo Applications. I recently had a customer asking about a similar request but using XMPP Instant Messaging to relay the DTMF touch-tones to any IM client.
I’m always up for a new challenge but was disappointed to find that this request wasn’t challenging at all. Tropo is ideal for building multi-modal communications apps like this going from Voice to IM in the same application.
Here is a video that demonstrates how this works.
Here is the Tropo Scripting that I used to make this demo possible.
answer
sleep 2
keeprunning = true
while keeprunning
ask "press a key or zero to end", {
:choices => "[1 DIGITS]",
:onChoice => lambda { |event|
message event.value, {
:to => "christoffe@jabber.org",
:network => "JABBER"}
if event.value == "0"
keeprunning = false
end
}
}
end
The only thing left to do is connect your IM bot to your Tropo application by simply creating one dynamically like cmtest@tropo.im. See below:
From a developer’s perspective, one of the most attractive things about the Tropo platform is the array of choices it provides. Choice can empower developers.
In addition to supporting two different methods for running Tropo applications – Tropo Scripting and Tropo WebAPI – developers can use a wide variety of languages to build Tropo applications. Tropo scripting applications can be written in JavaSctipt, PHP, Ruby, Python or Groovy. The Tropo WebAPI lets developers write applications in any language that can parse JSON and speaks HTTP.
A number of libraries exist to assist developers in building WebAPI applications and also for interacting with the Tropo Session API – which lets developers initiate outbound messages over several different channels.
If you are a C# developer, one of the easiest ways to move into developing Tropo applications is to use the Tropo C# library. And while this library is currently focused on building Tropo WebAPI applications, it can also be used to interact with the Tropo Session API to initiate outbound telephone calls and SMS messages.
This post will introduce C# developers to the Tropo C# library and walk through a simple example of using C# to send outbound calls and SMS messages. To keep things simple, we’ll use a very simple Tropo scripting application written in JavaScript.
(more…)