What Matters in Cloud Telephony

The landscape of cloud telephony continues to change.

I was heartened this week to see some of the sharpest minds I know in cloud telephony and unified communications get together with the acquisition of Teleku by Voxeo. Teleku and Voxeo’s Tropo service are complimentary ones that offer lots of goodies for developers, and I’m anxious to see what these guys will be cooking up now that they have joined forces. Congrats to all involved!

While there is lots of discussion about what this acquisition means for the constantly changing landscape of cloud telephony, this move validates (in my mind) some of the important trends that will determine which cloud telephony companies will be around for the long-term and how developers will use their services.

None of this is new – I’ve said it all before. It is worth noting, however, that all of the trends that I’ve observed before that are going to make the difference in the cloud telephony space are ones that both Tropo and Teleku do very well.

Portability – underscored not only by Teleku’s support for the open standard VoiceXML, but also the Tropo crew’s involvement in the Asterisk world, and the defacto standard for building Asterisk apps in Ruby – Adhearsion.

SIP integration – remember this kids: true cloud telephony has SIP baked in – the rest is just marketing fluff. Both Tropo and Teleku support SIP interoperability and make it very easy for developers to use SIP as part of their applications.

Multi-channel / multi-modality – Both Tropo and Teleku have big multi-modal chops. Being able to interact with users on multiple communication channels from one code base is a key tenet of unified communications and cloud telephony, and this will become increasingly important in the future.

Speech recognition – cloud telephony isn’t your grandfather’s way to build a phone app, so why should users be restricted to their grandfather’s way of interacting with a phone app? Speech recognition is fully supported in both Tropo and Teleku, and this will matter more and more to cloud telephony developers going forward.

So if you’re wondering what the next change in the cloud telephony landscape will be, you can bet that one of these trends will dictate the change.

Until then, I’ll be hacking on some cloud-based, speech rec enabled UC apps. 😉

Automatic for the People

Like lots of others, I think its worth noting San Francisco’s innovative use of Twitter. San Francisco residents can now use Twitter to send a message to an operator at the City’s 311 call center and receive a Tweet back.

This is exactly the type of interactive use of Twitter by governments I had in mind when I wrote about Twitter 2.0 for the public sector a few months ago. Still, now that I see an actual use of Twitter by a government to interact with citizens, I’m wondering if this approach can be improved upon, to make it more efficient for governments and still user friendly for citizens.

While San Francisco’s use of Twitter is indeed convenient for citizens, it has many of the same cost implications for government. Tweets to 311 operators must still be processed “manually” – someone has to read the content of a Tweet (even if its prefiltered based on message content) and assign a follow up action, or respond directly if its been assigned to them. And even though San Francisco is reportedly using the very interesting Twitter-CRM product CoTweet to make this process more efficient, I wonder if there isn’t a better way to do this.

I think this would be a perfect scenario to deploy an interactive IM/SMS BOT. Citizens could interact with an application to report common 311 service requests – potholes, traffic-light outages, abandoned vehicles, etc. As long as certain keywords / hashtags are used in the message content (something that probably needs to be done if Twitter is used instead anyway) it should be pretty easy to process reliably in an automatic way. Moreover, using an IM/SMS BOT would allow the process to have multiple steps, where the application and the citizen could exchange information successively.

For example, a citizen using a BOT to report a traffic signal outage could receive a an automated response asking if there are any noticeable power outages in the vicinity, or telling them to send a follow up message when the repair crew arrives (to audit response times). The possibilities are enormous.

Requests that could not be processed automatically could be routed to a live operator and handled the traditional way. This would more efficiently allocate the finite resource of 311 operators — human operators would only intervene in the processing of 311 service requests when they could not be processed automatically.

Here’s hoping that someday very soon, we’ll see a government go “automatic for the people” with 311 service requests.

Voxeo Announces New Tropo Hotness: COBOL!

Several weeks ago, Voxeo rocked the voice application development world by introducing Tropo, a new platform that allows developers to build voice applications in a variety of different languages.

Tropo lets developers build voice applications in JavaScript, Ruby, Python, PHP and more. I mentioned Tropo briefly in my last post, where I describe a voice application I built using VoiceXML/PHP — I’ll be porting this app to Tropo shortly so that it will be close to 100% PHP and running on the Tropo platform.

Voxeo announced today that they are adding support for yet another development language to Tropo — COBOL. This is big – it brings the total number of languages supported to a half dozen. I can’t wait to see what Voxeo has in store for Tropo next!

Let me tell you something – you go into a bar and drop some hints that you are coding your Tropo app in COBOL and you will not be leaving alone.

I guarantee it!

Facebook Drama in Maryland

Seems the Maryland Legislature will once again have access to Facebook:

Five days after sparking protests from lawmakers over his decision to block access to the popular networking site from legislative computers, the head of the assembly’s information technology office said yesterday that he will reopen access to Facebook in the next day or two.

It seems concerns over viruses and malware prompted the ban in the first place. The Director of the Maryland Legislature’s Information Services, Mike Gaudiello, now says that his office has “put in place tools to scan legislative computers for the viruses and harmful software that prompted the block…”.

That raised my eyebrows a bit – while Facebook can be (and has been) used to propagate viruses, the biggest threat to government computers is undoubtedly still regular old e-mail. If you’ve got safeguards in place to protect state computers from e-mail propagated viruses, I’m guessing that you’re probably covered as far as Facebook is concerned.

As social networking tools become more integral to the communications between elected officials and their constituents, a host of thorny issues are likely to arise. I’m curious to see how governments will address these issues:

  • Are the direct messages that people can send via Facebook and Twitter subject to public record requirements?
  • Are direct messages that people can send via Facebook and Twitter FOIA-able?
  • Do status updates in Facebook or Tweets meet the requirements for public meeting notices?

It will be interesting to watch as this continues to develop.

BTW, Hats off to @mmahaffie for the link to the article.

Verizon Launches Hosted VoiceXML Platform

A friend just sent this to me:

Verizon Business today launched Open Hosted Speech Services (OHSS), a speech platform that allows customers to create and host their own speech applications…[the platform includes] a hosted IVR application, a VoiceXML interpreter, text-to-speech capabilities, and a speaker verification application.

Hey, Verizon… 2001 called for you. Its wants its idea back.

Companies like Voxeo, BeVocal (now owned by Nuance) and TellMe (now owned by Microsoft) have been doing this for a long time.

A Look at Google’s FCC Auction Strategy

The NY Times has a really interesting article detailing the strategy of Google executives bidding on wireless spectrum in the recent FCC auction.

Google’s legacy from this historic auction is that it helped ensure that a portion of the spectrum purchased would be subject to specific requirements of openness. The “C Block” of spectrum that the FCC will require be managed under the tenants of openness was ultimately won by Verizon Wireless.

Even though Google didn’t “win” the auction for the C Block outright, there are those that believe that their strategy of opening up the world of wireless communication may have been served nonetheless:

“If Google had won a license, there was only downside risk for them,” said Gregory L. Rosston, a former F.C.C. official and senior fellow at the Stanford Institute for Economic Policy Research. “Now they can just spend $1 million a year on a law firm to ensure Verizon lives up to the openness requirements.”