Tropo is part of CiscoLearn More

How Gists can help for Tropo Scripting Development

Posted on June 2, 2016 by Steve Sfartz

When you go to production, you want the Tropo Scripting Platform to host your scripts so that you get all the scalability and robustness for free as these lay on Tropo operations’ shoulders, 24/7. This is the best practice to handle heavy workload, and this makes Tropo unique for serious communications business logic.

For that to happen, your scripts are deployed at several locations, and synchronized behind the scenes. This is how Tropo delivers communications worldwide, any mobile phone, any country, bi-directional, both calls and SMS.

When you’re developing, however, you are constantly changing your code, and this distribution feature means that any change to your script will take from a few dozen to hundreds of seconds to be active.

Now, let’s see how to reflect your changes immediately at development time.

Tropo downloads your script from a public web server and executes it on our servers. Each time Tropo runs your app, it will fetch the latest version of your script. So a best practice for development is to host your script on a public address, allowing Tropo to skip the distributing the file across our entire network.

I find it very practical to leverage gists for Developement, here’s how.

  1. Create a secret gist, with an extension that reflects the language you’re using (Tropo uses this information to run your script on the right env). A secret gist is publicly available, but doesn’t show up in Github’s search, so adds a bit of privacy.
  2. Grab the URL of your gist, and append /raw/<your-gistname>. For the sake of this example, we’ll go with
  3. In your Tropo application, reference the URL above. Your changes will be immediately reflected (…or in a matter of seconds).


Transcription Fees are coming starting June 1. (Really.)

Posted on May 17, 2016 by JP Shipherd

For a while now, our pricing page has said that our optional feature that allows developers to get transcriptions for a call recording has a cost of 5 cents per minute. In reality we haven’t been passing that cost onto you as we’ve worked to move this from an experimental feature into a production-ready capability.

As of June 1, that will change, and you can expect to see the costs for transcriptions added to your service fees. As advertised, those fees will be 5 cents per minute for each recording that you request a transcription for.

If you’ve been using transcription heavily, this may significantly increase your monthly invoice as transcription is generally more expensive than most of Tropo’s per-minute rates for voice calls. We believe that our ability to provide transcriptions of recorded calls adds value to your Tropo based solutions and checked that the price we charge for transcription is at a fair value in the market.

We are working hard to add new features that make Tropo easier and better to use. Keep watching our blog announcements or follow us on Twitter. Feel free to post comments or reach out to with any questions.

A Simple Call Center sample application

Posted on May 10, 2016 by Tim Scheuering

The challenge of building a basic call center application using Tropo might seem a bit overwhelming, so over the next few weeks, we’ll build one from a basic starting point we have here, to something that will demonstrate how a small business can use Tropo to answer, queue, and route their calls.

In this first part, we’ll have an inbound call from a customer that triggers an outbound call to an agent and places them both in the same conference. We’ve received many requests for a tutorial on how to record all conference participants, so this guide includes a simple recording function as well.

Why a conference instead of a transfer? A conference will let us do some interesting things later on, like adding a listen only mode for a supervisor or splitting the agent and caller legs to let them act separately.

Here’s the major components of this application (and provided info to help familiarize yourself with RESTful events) to try and make it simpler.

First, let’s create an overview of what we need:

  • A call director, to separate logic based on session type
  • An agent function, to handle agent joins/parts
  • An inbound caller function, to handle the initial call

Because JavaScript has no built in HTTP client, we’ll use a snippet from the knowledge base to simplify the REST calls:

function httpGet(url){ //Performs GET requests here 
	connection = new;
	connection.setRequestProperty(&quot;Content-Type&quot;, &quot;text/plain&quot;);
	connection.setRequestProperty(&quot;charset&quot;, &quot;utf-8&quot;);

	dis = new;
	while (dis.available() !== 0) {
		line = dis.readLine();

This will be the platform for all REST GET requests used in our application.

Because we need to record audio and launch user applications, we want to set some variables early on:

//Predefined Variables

var token = &quot;MYTOKEN&quot;;
var launchURL = &quot;;token=&quot;;
var ftpAddress = &quot;;
var ftpUserName = &quot;USERNAME&quot;;
var ftpPassword = &quot;PASSWORD&quot;;
var queueNumber = &quot;+13215556677&quot;;

You need to change the values above to match those specific to your applications.

Next, we need to set up the basic call director structure:

var incoming = false; //Variable Constructor

if(currentCall){ //If the call is inbound, set incoming to true
 incoming = true;

if (incoming) {
	InboundLeg(currentCall.sessionId + &quot;&quot;, token, launchURL, ftpAddress, ftpUserName, ftpPassword, queueNumber);
} else if (theCall == &quot;agent&quot;) {
	call(&quot;+&quot; + theAgentNumber);
	AgentLeg(currentCall.sessionId, theConfID, ftpAddress, ftpUserName, ftpPassword);
} else {
	log(&quot;xxxxxxxxxxLOGxxxxxxxxxx - ERROR: NO DIRECTION&quot;);

Notice in the above code, variables like theAgentNumber and theCall are passed parameters. More on parameters can be found in our Quickstart Documentation:

Now that we configured which direction the call is going before any real logic is performed, let’s generate the logic for each leg:

function InboundLeg(mySessionID, myToken, myLaunchURL, myFTP, myUN, myPW, myNumber) { //For Inbound Portion of Call
	startCallRecording(&quot;ftp://&quot; + myUN + &quot;:&quot; + myPW + &quot;@&quot; + myFTP + &quot;INBOUND-&quot; + mySessionID + &quot;.wav&quot;);

	say(&quot;Thank you for contacting the Call Center Template application.&quot;);

	say(&quot;We are connecting you to an agent now.&quot;);

	httpGet(myLaunchURL + myToken + &quot;&amp;theConfID=&quot; + mySessionID + &quot;&amp;theCall=agent&amp;theAgentNumber=&quot; + myNumber);


function AgentLeg(mySessionID, myConfID, myFTP, myUN, myPW) { //For Agent Portion of Call
	log(&quot;xxxxxxxxxxLOGxxxxxxxxxx - &quot; + mySessionID);
	startCallRecording(&quot;ftp://&quot; + myUN + &quot;:&quot; + myPW + &quot;@&quot; + myFTP + &quot;INBOUND-&quot; + myConfID + &quot;-AGENT-&quot; + mySessionID + &quot;.wav&quot;);

	say(&quot;Connecting you to a caller now&quot;);


You may notice the passed arguments to the AgentLeg function contain both the original caller’s sessionID (called myConfID at this point), as well as its own sessionId, to distinguish all interactions with the user from others.

At this point, the basic application is complete. A user calls in and is directed to an inbound leg. This leg then relaunches your application with agent leg details in place using the HTTP GET request with your application’s launch token. The agent leg then calls into the queue’s main number first, but can be changed to call into any number via a REST launch parameter. This allows you to transfer or connect new agents to the current inbound caller at will.

The complete, functioning code is available on Github.