Unlocked & Loaded: Voxeo’s Upcoming Customer Summit

In mid-October in Orlando, Florida, Voxeo (the company behind Tropo, Phono and SMSified) is bringing together customers, partners and developers for a summit to discuss the future of unlocked communications.

Voxeo Customer Summit 2011

On October 10th-12th, the Voxeo Customer Summit will take place at the JW Marriott Orlando Great Lakes. This conference will be packed with great speakers and cutting edge presentations providing details on the future of Voxeo’s product offerings.

We’ll be doing deep dives into the awesomeness that is Tropo, Phono and SMSified. If you’re already a user of these platforms, you’ll glean new details of how they can benefit your business and get to pick the brains of the engineers and technologists behind them.

If you’re just starting out with one of these platforms, you’ll quickly build your knowledge of how to use them, how they can benefit you and how you can build cutting edge communication apps.

You’ll be rubbing elbows with other Voxeo customers, large and small and hanging out with other developers who are using our platforms and APIs to run their businesses.

The event will be MC’d by the always engaging Chris Pirillo, of Lockergnome fame.

It’s like getting a front row seat for a show about the future of telephony and unified communications. And you’re invited!

To register to attend, just click here. The event is also on Lanyard.

Hope to see you there!

©2011 The Tropo Blog. All Rights Reserved.

.

Related posts:

  1. Tropo Goes To “Raleighwood”
  2. Come meet Tropo at an upcoming event
  3. Customer Testimonials Make Everything Worth It!

Speaking in Whispers: Creating a “Whisper” Dialog Using a Tropo Conference

We often get a common request to create a “whisper” dialog, where an inbound call is transferred to a second contact, and that contact has the option to decline the call or accept it. While our transfer doesn’t have that level of functionality, there is a relatively straightforward method using a conference to mimic it.

The following app is written in PHP and intended for Tropo Scripting; it also utilizes our REST API to submit an interrupt signal, which we’ll get into in more detail shortly.

We’ll need to initially describe what the app does, as it loops back on itself, making code breakouts difficult to explain linearly. Essentially, the app has if/else logic built into to handle an inbound call and an outbound call. When an inbound call comes in, Tropo drops the user into a conference and lets them sit for a few moments. While they wait, Tropo relaunches the same app using the curl REST client for PHP and makes an outbound call to a second contact. When this contact picks up, they’re prompted to accept or decline a call – if they say yes, they’re dropped into the same conference as the inbound caller. If they say no, Tropo disconnects the original conference with the inbound caller using a signal and then disconnects the outbound call as well.

With the general explanation out of the way, we’ll move on to the code. First, we define a couple of functions:

<?php

function choiceFCN($event) {
    global $session;
    if ($event->value == "yes") {
        conference("1337");
    }
    else {
        $curl_handle=curl_init(); 
        curl_setopt($curl_handle,CURLOPT_URL,'https://api.tropo.com
/1.0/sessions/'.$session.'/signals?action=signal&value=exit'); 
        curl_setopt($curl_handle,CURLOPT_CONNECTTIMEOUT,2); 
        curl_exec($curl_handle); 
        curl_close($curl_handle);
        say("You declined, disconnecting");
    }
}

function badChoiceFCN($event) {
    say("I’m sorry,  I didn’t understand that. You can say yes or no");
}

These functions determine what to do when the outbound call recipient says yes or no, or something completely different like “okay”. choiceFCN is the more complicated of the two – if the recipient says ‘yes’, then you can see where the conference is connected. If they say ‘no’, curl is utilized to submit a signal to the inbound caller’s conference to disconnect it, and then disconnects the outbound call as well.

Next, we have the if/else functionality, which is the bulk of the app:

if ($currentCall->callerID == null) {
    call("+14075550100");
    ask("Do you want to connect to ".$caller."?", array(
        "choices" => "yes, no",
        "timeout" => 10.0,
        "attempts" => 3,
        "onChoice" => "choiceFCN",
        "onBadChoice" => "badChoiceFCN"
        )
    );
}
else {
    $token = 'your_token';
    $callerID = $currentCall->callerID;
    $sessionID = $currentCall->sessionId; 
    $curl_handle=curl_init(); 

    curl_setopt($curl_handle,CURLOPT_URL,'http://api.tropo.com/1.0/
sessions?action=create&token='.$token.'&caller='.$callerID.'
&session='.$sessionID); 
    curl_setopt($curl_handle,CURLOPT_CONNECTTIMEOUT,2); 
    curl_exec($curl_handle); 
    curl_close($curl_handle); 

    say("please hold while we connect your call");
    conference("1337", array(
        "allowSignals" => "exit"
        ));
    say("The recipient declined the call.  Goodbye.");
    }
?>

The inbound/outbound detection is done through the use of “callerID” – no callerID means the app was launched using a token, and therefore outbound. So if callerID is null, trigger the outbound portion of the app; if there is a callerID, launch the inbound portion.

The outbound portion is relatively straightforward – call out to a number, ask the user if they want to connect, use the onChoice and onBadChoice handlers to define which function to use in each case. The inbound, on the other hand, is a little more complex. There’s several variables to start:

$token = 'your_token';
$callerID = $currentCall->callerID;
$sessionID = $currentCall->sessionId;

First variable is the token for your app, which is found beneath the URLs when you’re looking at your app in the Tropo UI. Second is saving the callerID of the inbound user for use during the outbound session, and then the sessionID as well for use in the signaling.

Once the variables are locked in, the curl to relaunch the app for the outbound call is started, and then the inbound caller is dropped into the conference. Note in the URL for the curl we add in the variable from earlier – this passes them into the outbound portion of the app as variables that we can then use. Also note in the actual conference the inbound caller is added to, there’s an extra variable in there called “allowSignals”. This is where you define a keyword (or “signal”) that can be used by the REST API to interrupt the conference, dropping the caller back to the application. If the outbound user says “no” and the signal is sent (defined in the URL

https://api.tropo.com/1.0/sessions/'.$session.'/signals?action=signal&value=exit

shown in the earlier portion of code), the conference will disconnect and the inbound user will hear “The recipient declined the call. Goodbye.”

That’s the extent of it; hope it helps someone! You can find the complete app on my Github, feel free to use it and abuse it as you see fit.

©2011 The Tropo Blog. All Rights Reserved.

.

Related posts:

  1. Building a full-featured conference call application with Tropo and PHP
  2. Conference Call Apps Made Easy with Tropo
  3. New SMS Features Deployed

Jailbreaking OpenVBX

Remember when the iPhone was only available on AT&T?   That was true until October 11, 2009 when a young coder named geohot (and friends) released the first iPhone/iPod jailbreak.  Suddenly iPhones weren’t tied to to just AT&T…now you could give AT&T the boot and choose Verizon or T-Mobile as your service provider.  Score!

In the spirit of geohot’s jailbreaking efforts, the rapscallions at Disruptive Technologies took on the the task of “jailbreaking” OpenVBX.

OpenVBX is a web-based open source phone system. It’s essentially a virtual PHP/MySQL PBX  and it’s available for download from GitHub.   Users of OpenVBX can make phone calls, send text messages…all very cool.

The catch is…you’re locked into one service provider: Twilio.  There’s no way to choose to use another cloud telephony provider…until now.

Today we’re pleased to announce a new fork of OpenVBX that adds support for Tropo.  For the first time, users of OpenVBX will have a choice of multiple platforms on which to run it, making it REALLY OpenVBX.

The coders at Disruptive Technologies added full support for the the Tropo API and Phono SIP-based VoIP web phone to the communications layer of the OpenVBX project. Of course, when selecting the Tropo API, users will now get access to all of the more advanced features of the Tropo network: speech recognition and text-to-speech in 24 languages, phone numbers in over 40 countries, international SMS, in/outbound SIP VoIP support, inbound Skype support, multiple phone numbers per callflow script, improved conferencing.

Disruptive Technologies also extended OpenVBX with the VoiceVault API to support Voice Biometrics in password resets. After adding VoiceVault credentials on the API Accounts Tab, the password reset dialog will provide an option to request a phone call to reset your OpenVBX account password.

The OpenVBX fork with Tropo can be found on GitHub.  We have sent the maintainer of the OpenVBX project a pull request to merge these updates into the project. The following features and bugfixes have been added to the OpenVBX package:

  • Fixed a redirect bug. OpenVBX no longer incorrectly redirects users to 404 pages.
  • Fixed bug in Twilio client. 60 seconds after the user has been “inactive”, the client is no longer able to be called for that user. This prevents calling the client if the user has closed their browser. (This also works for the Phono Client)
  • Added support for the Tropo API. You can now add a “Tropo API account” on the system settings page, and from the installer. Either a Tropo or Twilio account is required. Included in the new Tropo API additions are:
    1. Support for Tropo domestic and international phone numbers, on the “numbers” page.
    2. All applets in the “flows” page now support Tropo JSON as well as TwiML. Any number can be assigned any flow – so a tropo number and a twilio number can both be assigned the same flow.
    3. Support for existing Tropo numbers & applications. If the user prefers to set up their numbers initially in Tropo.com, the application will see these numbers and they can be assigned a flow within the application.
    4. Recordings, and Voicemail, as well as outbound dialing with Tropo.
  • Several theme changes. The OpenVBX logo has been modified to include both the Tropo and Twilio logo. If only one of the accounts is active, only that logo will show in the VBX logo – so if a user only has a Twilio account, only the Twilio logo will show, and vice versa. Other minor theme changes:
    1. Several pages in the System Settings tabs have been reworked.  Notibly the API accounts page, which now has each API accounts logos.
    2. Step 3 of the installation has been reworked.
    3. Several Twilio-specific content has been changed to be more ambiguous.
  • Added support for “Phono” browser phone, in addition to the Twilio Client. Any non-Twilio based numbers will use the new Phono browser phone.

©2011 The Tropo Blog. All Rights Reserved.

.

Related posts:

  1. My Voice is My Password. Verify Me.
  2. Routing GoogleVoice to Tropo and OpenVoice
  3. How to Build a VoIP-Based Baby Monitor

Creating an internationalized Restaurants Finder application in minutes with Grails and Tropo

Grails Logo In a previous blog post I already showed how we could pretty quickly create applications in Grails with the Tropo Grails Plugin and host them in Cloud Foundry with almost no effort. In this blog post I’m going to show a more ellaborated example. But, hey! In Tropo and Grails ellaborated examples don’t take more than 100 lines of code :)

One of the advantages of Tropo against its competitors is speech recognition and several internationalization features. Tropo understands 24 languages, so I thought that it would be pretty cool to create an application to find restaurants in a non-English speaking country as most of our blog posts are commonly focused on English. To implement my restaurants finder application I used the 11870 API service which is a Spanish web service that gives you the names, phone numbers and reviews of many services across any city in Spain (pretty cool).

So whats the idea around this restaurant finder? Basically imagine that you are on holidays with your wife in a city that you don’t know. And back in the hotel you made a reservation to a nice restaurant. Then you go through the day to visit the city and when it is time to go to the restaurant you realize that you don’t know where it is. Damn, you forgot the map! You don’t have any tourist service nearby, locals don’t know the restaurant location and you don’t have internet connection or an smartphone at hand. And of course your wife is starving! What do you do? Your marriage and peaceful holidays are at risk! Hopefully my restaurants finder could help you here :) Basically you dial a phone number, say the name of the city you are in, say the name of the restaurant and the application will tell you the phone number of the restaurant (it would be a one-liner change in the application to actually transfer your call to the restaurant’s phone).

But let’s look to some of the code. A first Grails action loads the name of all the cities with population bigger than 10.000. I’ve got a list from the Internet and just built a comma-separated list of cities. I use that list to create my choices statement that instructs Tropo to only accept one of those cities:


def index = {

    def citiesFile = applicationContext.getResource(
                            'classpath:cities.txt').file
    def citiesString = new String(IOUtils.toByteArray(
                            new FileInputStream(citiesFile)))
    def cities = citiesString.tokenize(',')

    def tropo = new TropoBuilder()
        tropo.tropo {
            say(value:"Bienvenido al servicio de información...", 
                  voice:"carmen")
            ask(name:'city',mode:"speech",
                         recognizer:"es-es", voice:"carmen") {
                say(value:"Diga el nombre de una ciudad")
                choices(value:citiesString)
            }
            on(event:'continue',next:'/tropo/restaurant')
        }
        tropo.render(response)	
}

That will prompt the user for the name of the city. Once the user says the name of a city a second Grails action will be triggered. In that action we call the 11870 API to fetch the list of available restaurants in that city. With that list I create another choices attribute that will instruct Tropo to only accept restaurants with a name in that list.

def restaurant = {

    def tropoRequest = request.JSON
    def place = tropoRequest.result.actions.value

    def map = restaurantMap(place)
    session["restaurants"] = map
    def restaurants = restaurantList(map)

    def tropo = new TropoBuilder()
    tropo.tropo {
        ask(name:'restaurante', mode:'speech', 
                      recognizer:'es-es', voice:'carmen') {
	    say(value:"Diganos el nombre de un restaurante en ${place}")
	    choices(value:restaurants)
	}
	on(event:'continue',next:'/tropo/info')
    }
    tropo.render(response)
}

In the code above, the method restaurantMap takes the name of the place and returns a map with all the restaurants in that place and their phone numbers. That map is stored in the HTTP session so later can be used to retrieve the phone number for the restaurant that the user has told. This is the actual code that invokes 11870 API and builds the map:

def restaurantMap(def place) {

    def query = "http://api.11870.com/api/v2/search?appToken=..."

    def feed = new XmlParser().parse(query)

    def restaurants = []
    def map=[:]
    feed.entry.each {
        restaurants &lt;&lt; it.title.text()
        map.put(it.title.text(),it.'oos:telephone'.text())
    }
    map
}

Finally, once the user says the name of a restaurant, one last action will take the input and will use it to find the phone number of the restaurant:

def info = {

    def tropoRequest = request.JSON
    def restaurant = tropoRequest.result.actions.value

    def map = session["restaurants"]
    def phone = map.get(restaurant)

    def tropo = new TropoBuilder()
    tropo.tropo {
        say(value:"El teléfono de ${restaurant} es ${phone}...", 
              voice:"carmen")
        hangup()
    }
    tropo.render(response)		
}

That was pretty easy, wasn’t it? In very few lines of code we get a quite useful application. Provided you have an API to fetch restaurants from and a list of cities of a country then it would be fairly simple to add support for extra countries to this little example. There is many other things that could be done like handling nomatches and timeouts to make the application more reliable and user friendly, or dial the phone number of the restaurant and transfer the call. I hope you don’t mind if I leave these as exercises to the reader.

But wait, do you want to see the app in action? I’ve recorded a short video that goes through the source code and also shows the application working.

And that is it. I hope you liked it!

©2011 The Tropo Blog. All Rights Reserved.

.

Related posts:

  1. Voice powered applications with Grails (Screencast)
  2. New Grails based WebApi implementation
  3. Deploying Tropo based applications to CloudFoundry with Grails

SMSified’s New REST API Explorer

Voxeo Labs, the creators of SMSified, Tropo, Phono, IMified, and other innovative communications services and technologies, has partnered with Apigee to introduce the new SMSified API Explorer!  Now developers can experiment with the SMSified REST API without writing a single line of code!  Yes, it’s that easy and here’s a video to prove it.

Get started with adding inbound and outbound SMS text messaging to your application today.  Using SMSified makes it super simple and it only costs $1 per month for the phone number and only $.01 per message.

©2011 SMSified. All Rights Reserved.

.

Getting Ready for Node Knockout

With the Node Knockout event just over the horizon, I thought it would be interesting to show how easy it is to build a really powerful SMS application using Node.js and CouchDB.

(Our sister platform, Tropo, is a sponsor of the event as is CouchBase, makers of the CouchDB software used in this demo.)

If you want to use SMSified in your Node Knockout application, simply sign up for an account (it’s free). Then just install the SMSified Node.js module:

npm install smsified

The screen cast below demonstrates an SMS application that accepts an inbound text message through SMSified and sends a response.

All of the details of the exchange are efficiently logged in CouchDB, including the phone number of the sender, the number sent to, the data time of the message and the result of calling the SMSified API to send an SMS response.

The code for this demo app can be found on GitHub.

Note, you’ll need to have the Node.js cradle module for CouchDB installed for this application to work in your environment. You’ll also need an instance of CouchDB.

This application makes use of the CouchDB _changes API – this is a powerful feature of CouchDB that separates it from other NoSQL databases. You can read more about the _changes API here.

Node.js and CouchDB are a potent combination, and if you want to build an SMS application there is no easier platform to integrate with that SMSified.

SMSified + Node.js + CouchDB = A Knockout!

©2011 SMSified. All Rights Reserved.

.

Team Attendance Tracking Using an SMS Application

As with any for-fun softball/baseball/kickball/handball league, the availability of players can vary widely from week to week. Life has a habit of interfering, especially if you have kids, so ensuring there’s enough players to field a full team can be a difficult process. Such was the case with the Voxeo softball team, but we’re just not the type of people to let a problem like that go unsolved – especially when we have incredibly easy tools like SMSified just sitting there, asking to be used.

This post will walk through the creation of an SMS application – using SMSified, Ruby and Google Spreadsheets – that requests and then stores the expected game attendance for each member of a team of players. The app is written in Ruby, since there’s both a sweet gem for interacting with Google spreadsheets (no reinventing the wheel!) and an SMSified Ruby Library.

We’ll break it down into pieces, since there’s a few different sections – as usual, the requires:

require "google_spreadsheet"
require "sinatra"
require "json"
require "smsified"

The use for “google_spreadsheet” should be pretty obvious; we use “sinatra” as the webserver and framework; “json” is brought in so we can parse the incoming text message data from SMSified and “smsified” should also be obvious. Next portion of the app defines our Sinatra route and a few variables:

post '/' do
   response = JSON.parse(request.env["rack.input"].read)

   message =  response["inboundSMSMessageNotification"]["inboundSMSMessage"]["message"]
   callerID =  response["inboundSMSMessageNotification"]["inboundSMSMessage"]["senderAddress"]
   trigger = message[0..1]
   datetime = message[3..message.length]

The beginning, post '/' do, defines our route as the root of our URL that we add to our phone number in SMSified, which we do here:

The rest of the section is parsing out JSON and setting some variables with the extracted data. We pull out the message and the sender’s callerID, then run a couple Ruby tricks on the message data. We yank out the first two characters and define it as trigger, and then set the rest of the message content as the datetime. Why we do this is exemplified in the next portion of code:

   if trigger == "Go"

    smsified = Smsified::OneAPI.new(:username => 'sms_user', :password => 'sms_pass')
    smsified.send_sms :sender_address => '13215550100', :address => ['14075550100', '19545550100', '13055550100'], :message => "Can you make it to the game on #{datetime}?"

We’re using the trigger to tell the app this text message is the “trigger” message, which in turn tells SMSified to send an outbound text message to the defined list of numbers; we then include datetime in the message that goes out. To explain this a little better, the initial activation text message sent to the SMSified number might look like this:

Go 6/21 @ 6:30

This activates the app, which then splits up the body of the text into two parts: “Go” (which tells SMSified to send the text message to all the recipients) and “6/21 @ 6:30″ (the date & time for the game, which is inserted into the outbound message). The code to actually send the text message is handled by the SMSified Ruby Library; you just populate the necessary (and clearly named) fields and it sends the POST to SMSified with the data. Note that :sender_address is your SMSified number, which you can access under your Account and then Phone Numbers.

The next portion of code uses the “google_spreadsheet” gem to connect to a particular Google Spreadsheet:

   else
    session = GoogleSpreadsheet.login("goog_user", "goog_pass")
    ws = session.spreadsheet_by_key("YOUR_SPREADSHEET_KEY").worksheets[0]

The spreadsheet key is located in the URL for your Google Spreadsheet, I’ll bold it in this pseudo URL:

https://spreadsheets.google.com/spreadsheet/pub?hl=en_US&hl=en_US&key=1234ABCDyvaLmdLmNQ05DSVAzMXc3THFfa3Y0&output=html

The last section also uses the “google_spreadsheet” gem to update particular fields, based on the callerID value:

    if callerID == "tel:+14074095231" 
      ws[2, 1] = message
      ws.save()
    elsif callerID == "tel:+19545550100" 
      ws[2, 2] = message
      ws.save()
    elsif callerID == "tel:+13055550101" 
      ws[2, 3] = message
      ws.save()
    else
      p "Not on the list"
    end

  end

end

In order to start the app, we sent it the “Go 6/21 @ 6:30″ message, which then sent out an message that said “Can you make it to the game on 6/21 @ 6:30?”; we should start getting replies back now with “Yes”, “No”, “Maybe” and we want to save that info to our spreadsheet. This part of the app is assigning a field value to a callerID – a person’s reply to a specific cell on the spreadsheet. If Justin is 14075550100, Kevin is 19545550100 and Dave is 13055550100, our spreadsheet should look something like this:

Honestly, that’s it. You shouldn’t even need to publish your spreadsheet; you’re using your Google login, so the document can be completely hidden from anyone else if you prefer. This could easily be adjusted to a survey app – send a text to a list of clients, record their answer in a private spreadsheet for your personal review.

Complete app can be downloaded from Github here, use it however you’d like. Questions or concerns? As always, hit us up on the forum.

©2011 SMSified. All Rights Reserved.

.

Keeping a Text Log of Received Messages

While receiving text messages is pretty simple – tie a URL to your phone number, any SMS that comes through is automatically redirected to that URL – what you do with the SMS information once it arrives is a different story all together. We already showed you how to work with CouchDB to create a full SMS Management system, but that might be more complex than you really need.

An easier and far simpler example would be a basic app that takes the redirected SMS content sent to your URL by SMSified, interprets it, formats the content so it’s easier to read and then writes the details into a plain text file. Every language has a way to do that, but since we currently have SMSified libraries available in PHP, Ruby and Node.js, we’ll show you how to do it in each of those languages. Each works a little differently, especially since the PHP SMSified library includes a couple shortcut functions to extract info out of the JSON content.

Since PHP is the unique case, we’ll start there:

<?php 
require 'smsified-php/inbound.class.php';

$json = file_get_contents("php://input");

$inbound = new InboundMessage($json);

$time = $inbound->getTimeStamp();
$message = $inbound->getMessage();
$sender = $inbound->getSenderAddress();

$text = "From: ".$sender."n"."Message: ".$message."n"."Date & Time: ".$time."nn";

$fh = fopen('log.txt', 'a');
fwrite($fh, $text);

?>

The app first requires inbound.class.php from the PHP SMSified library, retrieves the content of the JSON sent to the app by SMSified when an inbound message comes through, then splits it up into the time the message was sent, the message that was sent and who sent it. It then adds those together for one formatted variable, which is then added to a text file called log.txt using fopen and fwrite. Note the inclusion of n, which gives us some clean newline formatting both after each line and to space between records.

The Ruby library doesn’t have the same shortcut options available yet, but it’s still pretty short:

require 'sinatra'
require 'json'

post '/smsified.rb' do

  response = request.env["rack.input"].read
  response = JSON.parse(response)

  message =  response["inboundSMSMessageNotification"]["inboundSMSMessage"]["message"]
  callerID =  response["inboundSMSMessageNotification"]["inboundSMSMessage"]["senderAddress"]
  time =  response["inboundSMSMessageNotification"]["inboundSMSMessage"]["dateTime"]

  text = "From: #{callerID} nMessage: #{message}nDate & Time: #{time}nn"

  File.open('log.txt', 'a') {|f| f.write(text) }

end

The app initially requires sinatra and json, to run the webserver and interpret JSON respectively, and then reads and interprets the JSON sent to the app by SMSified, parses it into individual fields, rebuilds the data into a single formatted variable and writes the content to log.txt using File.open and fwrite.

The Node.js app is probably the most complex, mostly because the file open/file write portion is a little heavier than it is in the other languages:

var http = require('http');
var fs = require('fs');

var server = http.createServer(function (request, response) {

    request.addListener('data', function(data){
        json = data.toString();
    });

    request.addListener('end', function() {

        var sms = JSON.parse(json);
        var sender = sms.inboundSMSMessageNotification.inboundSMSMessage.destinationAddress;
        var message = sms.inboundSMSMessageNotification.inboundSMSMessage.message;
        var time = sms.inboundSMSMessageNotification.inboundSMSMessage.dateTime;

        var text = "From: "+sender+"n"+"Message: "+message+"n"+"Date & Time: "+time+"nn";

        fs.open("log.txt", "a", undefined, function(err, fd) {
            if (err) throw err;
            fs.write(fd, text, null, "utf8", function(err, written) {
                if (err) throw err;
                fs.closeSync(fd);
            });

            response.end();

        });
    });
}).listen(8000);

The app requires http to create the webserver and fs for the file open and file write portion. It then creates the server, adds a couple listeners to pull in the JSON and parses it into individual fields. The app next combines the fields into a single formatted variable and then writes them to the log.txt file.  Assuming we used each of these apps to send to the same file, the output should look like this:

From: tel:+14075550100
Message: PHP Test
Date & Time: 2011-06-21T18:22:33.946Z

From: tel:+14075550100
Message: Ruby Text
Date & Time: 2011-06-21T19:42:42.820Z

From: tel:+14075550100
Message: Node Test
Date & Time: 2011-06-21T20:14:53.389Z

Bam, quick and easy logging for inbound messages in three different languages. Let us know in the forums if you have any trouble with the apps or suggestions, we’re happy to help.

©2011 SMSified. All Rights Reserved.

.

Sending SMS messages with C# and SMSified

Here on the SMSified blog, we’ve provided lots of examples of how to use the SMSified API to quickly and easily send outbound text messages.

Using C# to send SMS messages

If you review some of our previous posts, you’ll see lots of good examples and tutorials on using PHP, Ruby and Node.js to send outbound SMS messages. With all of that in mind, I thought it was time to work up a quick example for our friends that use C#.

While we don’t yet have a C# library for working with our API (we’re working on one), it’s really easy to send outbound text messages with C# using SMSified.

The only potentially confusing issue with using C# with SMSified has to do with how the C# HttpWebRequest class uses authentication credentials.

When you use the Credentials property on the HttpWebRequest class, your application will expect to receive a challenge for credentials via an HTTP 401 response with an authentication realm. SMSified will not return an authentication realm with a 401 response, so trying to authenticate this way to send an outbound SMS message will fail.

The proper way to authenticate with SMSified is to send your credentials (via HTTP basic authentication) in a header on the original HTTP request. This is pretty straightforward in C#:

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url);
string authInfo = "username:password";
authInfo = Convert.ToBase64String(Encoding.Default.GetBytes(authInfo));
req.Headers["Authorization"] = "Basic " + authInfo;

In the above example, “username” and “password” would be replaced with your SMSified credentials.

A full working example of sending an outbound text message in C# using SMSified can be found here.

We’ll be announcing the release of our C# library in the near future, but if you would like to incorporate SMS messages into your C# application, this post and sample code will get you started.

©2011 SMSified. All Rights Reserved.

.

Want to Learn About SMSified? Join the VUC Call on Friday, June 17, at 12noon US Eastern

Want to learn all about SMSified and how you can build “nearly any SMS application you can imagine“? If so, join the VoIP Users Conference call tomorrow to learn all about SMSified and what you can do. Voxeons Chris Matthieu and Dan York will both be on the call, as may be a few others. The folks joining the VUC calls are a fun group and the discussion is usually both enjoyable and wide-ranging.

The call is tomorrow, Friday, June 17, 2011, at 12:00noon US Eastern.

You can join the live call via SIP, Skype or the regular old PSTN. There is also an IRC backchannel that gets heavy usage during the call.

The call will be recorded so you can always listen later if you are unable to attend live.

©2011 SMSified. All Rights Reserved.

.