Disruptive Telephony

WOW! In companion blog posts today Cisco and Tropo announced Cisco's intent to acquire the Tropo team and platform:

• Cisco blog: Cisco Announces Intent to Acquire Tropo
• Tropo blog: Tropo joins Cisco to Power next-gen collaboration APIs

As someone who was at Voxeo in 2009 and helped launch Tropo (and wrote many of the early blog posts about it[1], as well as some of the python samples), I'm thrilled for the team there now that this is happening.[2]

Congratulations to all involved!

Over the years since leaving Voxeo, I've written about Tropo from time to time and continued to watch its progress. I've continued to be very impressed by what they've done over the years. They've truly made it easy for people to create powerful applications using simple programming languages.

It looks like the Tropo website is struggling right now so here is a snippet of their announcement post:

---

Six years ago we launched Tropo with the idea to make it easy to power phone calls through a simple API. Since then, we’ve empowered thousands of developers to add voice and messaging to their applications.

From our very first sign-up in 2009, to powering thousands of mobile and voice applications, our mission has been the same: to make real-time communications more accessible and productive through great APIs.

Today we’re thrilled to share that Tropo is joining Cisco’s Collaboration Technology Group. Together we’ll enable completely new ways of communicating by opening up Cisco’s collaboration products to every developer on the planet (and maybe some off the planet…hey, they need collaborative tools on the International Space Station!)  :)

---

Knowing a good number of folks at Cisco, too, I think this is a great win for them in that they'll be able to make some of their products and services more accessible to developers.

I remember well back in 2009 when Jonathan Taylor (then CEO of Voxeo) brought in the Adhearsion team and "Voxeo Labs" was set up. Tropo was the first of the Voxeo Labs products, along with a number of others that were released over the following years. I watched as Voxeo Labs was then spun off from Voxeo in 2012 as a separate company and then Voxeo was acquired by Aspect in 2013... and Voxeo Labs was renamed to Tropo.

I watched, too, as the Tropo team continued their heavy involvement with WebRTC and brought that technology even deeper into their various services.

Congratulations to Jonathan Taylor, Jason Goecke, Johnny Diggz and all the rest of the Tropo team on this acquisition!

I look forward to seeing what Tropo and Cisco will do together to make it even easier to create voice, chat, messaging and other kinds of applications!

---

UPDATE #1: Jonathan Taylor has published a post on Facebook that outlines some of the history that led to this announcement. He includes this information related to Cisco:

We were even more surprised when Cisco approached us about acquiring Tropo. Selling Tropo was the last thing on our minds. But the potential was clearly huge for both companies, and over the course of the discussion, the deal terms clearly quite attractive. So here we are today!

UPDATE #2: A number of news stories are appearing on Techmeme.

UPDATE #3: Writing over on NoJitter, Zeus Kerravala dives into more detail about the acquisition based on his pre-briefing with Cisco's Rowan Trollope. Zeus' article: Cisco to CPaaS Providers: Game On!

---

[1] Although in the time since I left in 2011, my account was understandably removed from the Tropo site and the author on all those posts I wrote between 2009-2011 was changed to someone else. :-)

[2] In full disclosure, I should note that I am a very minor shareholder in Tropo after exercising a few options upon leaving Voxeo in 2011. I had no knowledge of this acquisition and have not participated actively with Tropo since leaving in 2011.

Do you want to understand what WebRTC / RTCWEB is all about and why so many people are passionate about its potential for extending real-time communications (voice, video, chat, data-sharing, etc.) into web browsers?

I recently wrote about some of the larger issues of how WebRTC will disrupt telecom, but in this video, "RTCWeb Explained", Cullen Jennings, one of the co-chairs of the IETF's RTCWEB working group, dives down into the technical details to explain how it all works and what the various different components of of the solution are. I particularly like how Cullen covered some areas like "identity" that I haven't seen stressed as much in other pieces about WebRTC. The video comes in at about 39 minutes and is well worth viewing:

For more information, I've put together a page about the broader WebRTC / RTCWEB initiative with links to relevant resources.

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Do you like building telephony apps with Adhearsion? Have you built a really cool app that is worth sharing? Or used Adhearsion in an unusual way? Are you planning to attend AdhearsionConf 2012 in Palo Alto on October 20-21? Or would you attend if you could speak?

If you answered yes to any of the above questions, why not consider applying to be a speaker? The call for speakers is at:

http://adhearsionconf.com/call-for-speakers/

The only catch is ... the deadline is TOMORROW, Saturday, September 8th!

Ever since I first saw Jay Phillips present about Adhearsion back at one of the early ETel conferences in maybe 2006 or so I've been intrigued by how easy Adhearsion made it to develop telecom apps. It's just incredibly simple to make powerful apps.

If you are a Ruby developer (or want to be) and you are interested in building telephony apps, Adhearsion is definitely worth a look... and if you do use Adhearsion, why not consider signing up as a speaker?

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

My friend Mark Headd passionately wants to open up government - and to do so through code. I've known him for years as the author of the VoiceInGov / Vox Populi blog where he has been writing about mashups and so many other ways to open up access to government information via telephony. Back in November 2010, Mark joined me and the others on the rocket ship known as Voxeo and did outstanding work for the Voxeo Labs and Tropo teams.

But just as my passions altered my career last fall, as of just a short time ago Mark is now the Director of Government Relations at Code for America and, with that, changing a bit about the way he is writing online.

His new site is civic.io, where he will be writing on "civic hacking, civic startups and the future of open government". He's brought over to the site many of his relevant older posts, so he's already got a solid amount of content.

The work he and the others at projects like Code For America are doing is incredibly important to help with keeping our networks open. I'm looking forward to reading more of what Mark is up to in the time ahead - and certainly wish him all the best in this new endeavor.

Oh, and of course you can follow him on Twitter at @civic_io.

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

With today's big news in the VoIP / Unified Communications (UC) / telecom space of Avaya's acquisition of Radvision, pretty much all of the coverage has predictably focused on the video angle. While that's certainly important, I have a far bigger question:

What about Radvision's SIP and H.323 stacks?

More specifically -

will Avaya continue to support and promote the strong usage of Radvision stacks by other vendors?

Of all the coverage I've seen so far, only Tom Keating touched on this in his brief post:

They also developed a H.323 stack used in hundreds of VoIP and videoconferencing products before SIP became the dominant VoIP protocol of choice.

Beyond the popular H.323 stack, Radvision's SIP stack has also been used in a good number of products out there - and Radvision also developed stacks for RTP, MGCP and many other VoIP protocols. Just follow the links off of Radvision's developer page at:

http://www.radvision.com/Products/Developer/

to see the wide range of developer solutions they have developed over the years.

For those not familiar with this topic, a "stack" in developer-speak is basically a set of libraries that you can incorporate into your products to enable those products to communicate over a given protocol. So if you want to "SIP-enable" your product, you can license a "stack" from a company like Radvision rather than developing your own stack or using one of the various open source stacks that are out there. Licensing the stack also typically gets you support from the vendor and the ability to request changes/customizations/etc.

Radvision has enabled a good number of companies out there to get into the VoIP world. They have been a supplier of stacks to companies all across the VoIP / UC space.

Now they've been acquired by one of the largest vendors in the VoIP/UC space.

Will Avaya continue to support the widespread usage of Radvision's various stacks by other vendors?

Or will they restrict or reduce the usage? Or increase the costs? If so, what will the other vendor's do?

Can the various vendors using Radvision stacks trust Avaya to continue the developer program? Particularly when they may compete directly against Avaya?

Will there be more attention paid now to other providers of SIP and VoIP stacks?

THAT is the question that I'm most curious about in the midst of this merger...

Other Articles

Some of the pieces worth reading on this topic include:

• Zeus Kerravala on NoJitter: Why Avaya Buying Radvision Makes Sense (Updated: Deal Is Official)
• Henry Dewing's Blog at Forrester: Avaya Acquires Radvision
• Carl Ford on TMCnet: Avaya Buys Radvision for $230 Million
• TechCrunch: RadVision Finally Finds A Home With Telecom Giant Avaya — For $230 Million
• eWeek: Avaya to Buy Radvision, Ramping Competition With Cisco
• TheNextWeb: Done deal: Avaya buys video conferencing tech firm RADVISION for $230m in cash (some useful links)

P.S. Hat tip to Forrester's Henry Dewing, too, for at least recognizing the usage of Radvision's stacks, although he did not ask the question I'm asking here.

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Yesterday morning I did something I haven't done in eons. Many years, probably. (I can't remember.) I fired off a "rant" on an IETF mailing list.

I've been a huge proponent of the "RTCWEB/WebRTC" work going on in the "RTCWEB" Working of the IETF and the "WebRTC" of the W3C. I've mentioned it in many of my presentations. I've advocated for people to join the mailing lists. I've written about it a good bit on Voxeo's standards blog when I was at Voxeo.

We have an opportunity to make it easy for web developers to add "real-time communications" via voice, video, IM, etc., to web applications. We can make that work from directly within the browser.

Think of it... HTML5 with the ability to quickly add voice, video, chat... and without the need for a browser plugin or extension in Flash, Java, etc. (the limitation of all of today's proprietary options).

It's the opportunity to move real-time communications into the very fabric of the Web.

Awesome potential!

The work has been moving along quite rapidly in both the IETF and the W3C. Extremely active (high-volume!) mailing lists. Many Internet-Draft documents being created. Regular conference calls, interim meetings, face-to-face meetings. Some truly brilliant - and passionate - people involved. (Read the RTCWEB overview Internet-Draft for more background.)

But I still can't escape the feeling that the direction isn't quite right... as a friend said to me:

my feeling is that this is being appoached as SIP 5.6.2 - a minor tweak on an established standard - not WebRTC 0.9 - a new dawn in a new world.

I haven't honestly had the time to read all the messages with the crazy amount of traffic (which is good - shows people are passionate about the topic!), but I've felt increasingly frustrated with reading the messages that I have read that we're collectively in the midst of developing something that few developers will actually use.

So I ranted. Will it do any good? Maybe. Maybe not.

What the rant really needs is to be backed up by people who have the time to join in the process and contribute suggestions for how a RTC API that would appeal to "web developers" would look like.

Care to help out? The mailing list is open to anyone to join.

Anyway here's the rant... (and yes, for the truly pedantic, I am very aware that I ended with a </rant> but did not start with a <rant>)...

---

---

NOTE: And, as I suppose must be the case with any good rant, mine was not entirely accurate. As multiple people pointed out (one example), my ending where I ask about whether people would choose the RTCWEB/WebRTC API over Flash/Phono/Twilio/Java/whatever is not entirely on target. The question is really... will vendors creating libraries like Phono choose to use the RTCWEB/WebRTC protocols/APIs or will they continue to use their own proprietary solutions?

As people pointed out, there will be a hundred different JavaScript libraries created (like Phono) that will consume the RTCWEB work... and most web developers will use those libraries and not program directly with the RTWEB/WebRTC APIs and protocols.

Fair enough... but the question remains - will the RTCWEB work make it easy enough for all those JavaScript libraries to blossom?

Others pointed out that I'm really talking about the web API that would be exposed via the W3C's work versus the low-level API coming out of the IETF. And yes, that is perhaps technically true... but the reality is that it is the same set of people working in two different mailing lists... and both efforts are contributing to the end result.

In the end, I want to see a result of all this RTCWEB/WebRTC work that developers will actually deploy and use!

I want open standards to win.

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Stuck somewhere without a computer but with an iPad? My former colleague Chris Matthieu just posted this amusing video today of how he used only his iPad to create and deploy an application using the Tropo cloud communication service. I don't know what amused me more - that he wrote the app using his iPad... or that he filmed himself using his iPhone! Quite a deft bit of handling to make it all work:

You can, of course, register for a free Tropo.com account and start creating your own voice/SMS/IM/Twitter apps using languages like PHP, Python, JavaScript, Groovy and Ruby...

Want to learn more about the Adhearsion framework that lets you easily create telephony and other communication apps using the Ruby language? On tomorrow's VoIP Users Conference (VUC) call at 12 noon US Eastern, Ben Klang from the Adhearsion project will be talking about all that's new in Adhearsion-land, including the upcoming AdhearsionConf 2011 in October in San Francisco.

I've written about Adhearsion before and while I don't do much with Ruby myself, the power of Adhearsion to create powerful telephony apps in a few lines of code is pretty amazing.

If you'd like to join the VUC call live tomorrow, the info is:

• SIP: [email protected] (works with wideband!)
• Skype: vuc.me
• Regular old PSTN phone: +15672522286

There's also a very active IRC backchannel (#vuc on free node) that provides another way to communicate during the call.

Want to build text messaging (SMS) applications for a very cheap price? My colleagues over in Voxeo Labs recently reduced the price of sending or receiving SMS messages to only 1 cent per message. (As a bonus, they also came up with the cute graphic I'm using on the right.)

As Adam Kalsey writes in the Tropo blog post, "Announcing New lower SMS pricing" sending an SMS is a trivial matter in Tropo. His language of choice is PHP, so he shows:

<?php
call('+14155551212', array('network' => 'SMS'));
say('d00d, Penny SMS? ');
?>

But you could obviously do something very similar in Python, Ruby, Groovy or JavaScript in Tropo Scripting... or with any language using the Tropo WebAPI.

Personally, I like seeing what I can do to merge SMS with Twitter... back in December I wrote about how to use Tropo to trigger alerts via SMS based on text in Twitter, which is a variation of an app I do actually use for Twitter monitoring. My colleague Justin Dupree also wrote a cool post about using Node.js to build a Twitter IM/SMS service.

Anyway... all of these SMS apps are now able to be deployed in production for only 1 cent per message to and from US numbers. Text messages to numbers outside the US are still the low 2 cents per message. If you'd like to try it out, Tropo is free for developers to build and try apps... you just have to sign up for an account.

P.S. In case it wasn't crystal clear, Tropo is a service of Voxeo, my employer. However, I wouldn't write about it here if I didn't think it was cool!

---

If you found this post interesting or useful, please consider either:

• subscribing to my email newsletter;
• following me on Twitter; or
• subscribing to the RSS feed

---

Hot on the heels of the new release of the PhonoSDK I wrote about last week, Dave Hoff over in Voxeo Labs came out with a new "Callme Button" demo that's very cool. As he describes in his blog post on the Phono blog, adding a "call me" button to a website is now as simple as adding this snippet of JavaScript to your web page:

$("body").append(
   $("<div/>")
    .css("width","210px")
    .callme({
      apiKey: "C17D167F-09C6-4E4C-A3DD-2025D48BA243",
      numberToDial: "8007773456",
      buttonTextReady: "1-800-777-FILM",
      slideOpen:true
    })
  )

There is a Callme "demo page" online at:

http://s.phono.com/releases/0.2/samples/callme/index.htm

That shows how you could create a button with or without a dialpad and in various themes:

The source code is naturally there for you to play with if you want to do so.

Cool stuff!

---

If you found this post interesting or useful, please consider either:

• subscribing to my email newsletter;
• following me on Twitter; or
• subscribing to the RSS feed

---