Where are the IVR Games?

March 29, 2011

It strikes me as odd that IVR technology has been used exclusively for business purposes. Here at Plum, we’ve worked on applications that were intended for entertainment purposes, but none of those apps were games. With the explosion of mobile gaming, you’d think there’d be more games that could be played not on your phone but through your phone.

The few IVR games I’ve seen fall into a couple camps. The first type shoehorns a game that’s better served via a visual medium into something over the phone. IVR blackjack is an example of this. It works okay because there aren’t that many cards to keep track of but it’s still pushing the limits of what’s reasonable over a phone (imagine trying to play Texas Hold’em over the phone.) Trivia games are another type of game that have made it onto the phone. While trivia does, in fact, translate well into a phone application, they’re not really games per se. They’re more like a survey. There’s no gameplay or strategy involved.

The problem here is that phone games have been derivative of games better suited for another medium. We might be better off considering what VoiceXML IVRs are actually good at. The two compelling capabilities of a good IVR platform are speech recognition and data integration. Unfortunately the only thing I can come up with, given those two features, is a game where you’d learn incantations that you’d have to speak into your phone which could be used to trigger events in the real world. Imagine Ali Baba saying “open sesame” into his cell phone to automatically open his garage door: the IVR would listen for “open sesame” as well as a set of other possible incantations (e.g. “close sesame”, “presto change-o”, “abracadabra”) and, upon recognizing the phrase, makes a call to a web service running on a web server with X-10 controls which would, in turn, open the garage door.

That’s a bit more of a toy than a game though, but I think there’s some kernel of a game in there.

-

2

-

Playing with Packet Sniffers

May 2, 2011

Recently one of our customers encountered a strange problem with their VoiceXML application. Their application had three pages: a start page that attempted to fetch a dynamic page and an end page that would be fetched in case the dynamic page took too long to process. Ideally the following should’ve occurred whenever the dynamic page failed to return:

  1. The Plum IVR platform fetches the start page and sees the VoiceXML directive instructing it to fetch the dynamic page.
  2. The IVR platform tries to fetch the dynamic page but after a short timeout, gives up.
  3. The platform then fetches the end page and plays the message telling the caller that the service is currently unavailable.

For some reason, once the platform failed to fetch the dynamic page, it also failed to fetch the end page.

Now at first, we weren’t certain what the source of the problem was. We wrote a similar application on our own servers and failed to replicate the behavior. Fortunately our customer’s setup did fail reliably (which addressed the number one tool for troubleshooting: a way to trigger the bug over and over.)

After trying to use some pretty weak tools to debug the issue (including typing in “netstat -an” over and over), we broke out a packet sniffer. Specifically, we broke out tcpdump. With tcpdump, we were then able to trace the HTTP sessions between the IVR and our customer’s web server. And what did we find? To fetch the end page, our platform was attempting to reuse the socket that was hung on the dynamic script. This, of course, wouldn’t work. It’s all fine and well to reuse a socket for another request if the previous request has completed, otherwise the IVR is shouting at deaf ears on the customer web server.

Having thus isolated the problem to unexpected reuse of a busy socket, we knew the problem actually came from one of the libraries against which our platform is compiled: libcurl.

Now before I continue, it should be said that libcurl is awesome. We used to use libwww and found it to be an unmanageable mess. libcurl is simple, fast, full-featured, and well-documented. But sometimes even the best software has a bug or two. Well, in this case just one.

We decided to write a small test application in PHP that would, using the curl interface embedded in PHP, attempt to fetch those three pages in succession. This is the number two tool for troubleshooting: a simplified analogue of the problem that can reliably reproduce the bug. Sure enough our test application reproduced the issue and now, by using a scripting language like PHP, we could insert all manner of debugging information into our test script and immediately retest.

With debugging turned on, we discovered that libcurl was quite intentionally reusing the socket. Since libcurl itself was printing the debugging messages, we searched the libcurl source code (because it’s Open Source) for where this debugging message came from. And what did we discover? A slight flaw in the libcurl logic where they should’ve typed “!=” (i.e. not equal to) instead of “==”. We changed one character and “voila” we fixed the bug.

Mind you, after the “voila” comes a couple days of testing, building a patch kit, scheduling system maintenance across our infrastructure, and deploying the fix to production — but we’re discussing debugging today, not operations.

The marketing moral of this story? In addition to owning the platform source code in-house which allows us to instate patches within days of identifying a bug, we also take advantage of open source libraries which allows us to fix bugs in third-party software to which our platform links. The benefits of being able to quickly and directly modify our IVR platform code aren’t confined to bug fixes either. We have, in the past, added VoiceXML extensions based on customer requests. When our marketing team says that we own our IVR platform, now you know why it’s important.

-

2

-

Buzzkill: SaaS

March 29, 2011

The problem with buzzwords is that, by their very nature, they get overused and overextended and eventually lose all meaning altogether. And then people still use those buzzwords and it irritates me. It’s kind of like people who use big words to sound erudite. It’s pretentious and usually it’s a feeble attempt to obfuscate their ignorance. </sarcasm>

Today I’m going to pick on SaaS: Software as a Service. It’s a blatant relabeling of ASP. I read an article where the writer extols the superiority of the SaaS model over the ASP model — as if the inherent business models and not execution, available technology, and market conditions spelled failure for ASPs and imminent success for any company that promotes SaaS.

The first set of lame arguments: “ASPs were not necessarily concerned about providing shared services to multiple tenants.” and that ASPs lacked “the required amount of application and business domain knowledge regarding the applications they were running.” The first argument is a bit contradictory: so if an ASP isn’t concerned with providing shared services to multiple tenants, does that mean that it’s providing shared services to one tenant — so the one tenant is sharing it with…whom precisely? Seems more like a pathetic ASP that could only find one customer than the standard model by which ASPs operated. And since when is an ASP defined as a business that’s run by people who don’t know the business they’re serving? That’s just a bad business. I’m certain there are SaaS businesses that are similarly run by people without “the required amount of…knowledge”

The second set of lame arguments state that ASPs had simple HTML interfaces whereas SaaS solutions are better because they’re designed specifically for the web. Look, if you could write a simple HTML interface in 1997 that meant you were building something specifically for the web. Just because developers have access to a far richer set of web client tools and capabilities now than were available 10 years ago doesn’t indicate a better business model. It indicates better tools. ASPs in ‘97 and today’s SaaS solutions both use web technology. The difference isn’t the model, it’s the tools.

Finally, the writer argues that ASPs rushed their products to market before taking into consideration “performance, security, customization and integration issues”. This is a corollary to one of the first arguments. And my counter is the same: ASPs aren’t defined by how products are released to market. They’re defined by what they sell and how they sell not how well they sell. Any company that rushes a product to market without concern for their infrastucture is in trouble.

Both ASP and SaaS vendors sell software that’s delivered to the customer over the Internet from a vendor’s data center. This data center infrastructure is shared across many of the vendor’s customers and is even frequently shared by many different vendors. Any nuanced differences between ASPs and SaaS solutions are not only marginal, but usually not even understood by the suits spouting these buzzwords. So do me a favor, quit worrying about what something’s called and try to actually say something meaningful. Thanks.

-

2

-

Survey this!

March 29, 2011

We just rolled out our new app: a survey building tool. We recognized an underserved market: people who need a tool to build IVR surveys as easily as they can build web surveys. The market is absolutely crowded with competitors in the web survey space mostly because, like most web technologies, it’s cheap and easy to build such a tool and it’s cheap and easy for all of your competitors to build such a tool as well.

A recent article in Business Week discusses the pitfalls of relying on web surveys. Because the sample set is both self-selecting and confined to Internet users, the resulting data can be skewed. Telephone surveys avoid many of these sampling issues because a) most everyone has a phone and b) surveys can be initiated by the sampler, rather than the samplee (yeah, I know that might not be a real word).

Anyway, we now have a powerful survey building tool that allows you to create surveys that can be administered via the web and the phone. And we’re lucky that we’re in the particular market space that we’re in: competitors in the web survey market won’t be able to compete with our IVR and telephony experience and infrastructure while competitors in the IVR space really don’t care about the application needs of small- and medium-sized businesses.

Check it out: http://www.plumvoice.com/landing/surveys.php

-

2

-