Posts categorized "Programming"

Video: What Is WebRTC/RTCWeb All About? How Does WebRTC Work?

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:



AdhearsionConf 2012 Call For Speakers Ends Tomorrow (Sept 8)

Adhearsionconf2012Do 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:



Civic.io - Mark Headd's new site on Civic Hacking and Open Government

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.

Civic io


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



The Big Question On Avaya's Acquisition of Radvision - What About The SIP and H.323 Stacks?

Avaya RadvisionWith 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:

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:



My Rant: Who Are We Building RTCWEB/WebRTC For? Telephony Developers or Web Developers?

IetflogoYesterday 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>)...


Folks,

I need to rant. I've been lurking on this list from the beginning but with a new job I haven't been able to really keep up with the volume of messages... and every time I get ready to reply I find that others like Hadriel, Tim, Neil, Tolga or others have made the points I was going to make...

But I find myself increasingly frustrated with the ongoing discussions and want to ask a fundamental question:

- WHO ARE WE BUILDING RTCWEB/WEBRTC FOR?

Is it for:

1. Telephony developers who are tired of writing code in traditional languages and want to do things in new web ways;

2. Web developers who want to add real-time comms (as in voice, video and chat) to their existing or new web applications;

3. Both 1 and 2.

If the answer is #1, then I think everything is going along just wonderfully. We can go ahead and use the SIP/SDP/etc. stuff that we all in the RAI area are all used to and understand just fine. Heck, let's just all end the discussions about a signalling protocol and agree on SIP... get the browser vendors to agree on baking a SIP UA into their browsers... and call it a day and go have a beer. Simple. Easy. Done.

And the only people who will ever use it will be people who work for RTC/UC/VoIP vendors and random other programmers who actually care about telephony, etc.

But that's okay, because the people who do use it (and their employers) will be really happy and life will be good.

If the answer is #2, then I think we need to step back and ask -

HOW DO "WEB DEVELOPERS" REALLY WANT TO WORK?

Here's the thing... in my experience...

99% OF WEB DEVELOPERS DON'T GIVE A ______ ABOUT TELEPHONY!

Never have. Never will. (In fact, I may be understating that. It may actually be 99.99999%.)

If they are with startups, they want to build nice bright shiny objects that people will chase and use. They want to make the next Twitter or FourSquare or (pick your cool service that everyone salivates over). If they are with more established companies, they want to create easy-to-use interfaces that expose data or information in new and interesting ways or allow users to interact with their web apps in new and useful ways.

And they want to do all this using the "languages of the web"... JavaScript, PHP, Ruby, Python, etc.

They want "easily consumable" APIs where they can just look at a web page of documentation and understand in a few minutes how they can add functionality to their app using simple REST calls or adding snippets of code to their web page. Their interaction with telephony is more along these lines:

"Wow, dude, all I have to do is get an authorization token and curl this URL with my token and a phone number and I can create a phone call!"

And the thing is... they can do this **TODAY** with existing proprietary products and services. You can code it all up in Flex/Flash. You can write it in Java. You can use Voxeo's Phono. You could probably do it in Microsoft's Silverlight. I seem to recall Twilio having a web browser client. A bunch of the carriers/operators are starting to offer their own ways of doing this. On any given week there are probably a dozen new startups out there with their own ideas for a new proprietary, locked-in way of doing RTC via web browsers.

Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time communications between browsers.

It can be done today. Now.

The drawback is that today you need to have some kind of applet/plugin/extension downloaded to the browser to allow access to the mic and speakers and make the RTC actually work. So you have to use some Flash or Java or something. AND... you are locked into some particular vendor's way of doing things and are reliant on that vendor being around.

THAT is what RTCWEB can overcome. Make it so that web developers can easily add RTC to their web apps without requiring any downloads, etc. Make it do-able in open standards that don't lock developers in to a specific product or vendor.

But if we are targeting "web developers", that is who we need to satisfy... and we need to understand that they *already* have ways to do what we are allowing them to do.

If we come out with something that is so "different" from what "web developers" are used to... that requires someone to, for instance, understand all of what SIP is about... that requires a whole bunch of lines of code, etc.... well...

... the web developers out there will NOT launch an "Occupy RTCWEB" movement claiming that they are the "99% who don't care about telephony"... they will simply... not... use.... RTCWEB!

They will continue to use proprietary products and services because those work in the ways that web developers are used to and they make it simple for a web developer to go add voice, video and chat to a web app. Sure... they will still require the dreaded plugin/extension, but so be it... the "open standard" way is far too complicated for them to look at.

And all the work and the zillions of hours of writing emails and I-Ds that this group has done will all be for nothing. Well, not nothing... some of the telephony-centric developers will use them. But the majority of the web developers out there may not because there are other simpler, easier ways to do what they need to do.

So I go back to the question - who are we building RTCWEB for?

Is the goal to enable the zillions of web developers out to be able to use real-time communications in new and innovative ways? Or is it solely to make it so that VoIP/UC/RTC vendors can make a softphone in the browser that calls into their call center software?

RTCWEB *can* enable both... but to me it's a question of where the priority is.

The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so simple and easy that web developers will choose to use it over Flash/Phono/Twilio/Java/whatever to add RTC functions to their web apps?

If the answer is yes, we win. Open standards win. Maybe we upgrade from having a beer to having champagne.

If the answer is no, what are spending all this time for?

</rant>

Dan


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:



Video: Using an iPad to Create Tropo Applications

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...


Adhearsion (and AdhearsionConf) On Tomorrow's VUC Call - Telephony Via Ruby

Adhearsionconf2011Want 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:

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


Tropo.com Lowers SMS Rate to 1 Cent Per Message - Now Super-Cheap To Build SMS Apps

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:



New Phono "Callme Button" Demo Shows Use of Calling Directly from Web Browser

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:

Phonocallmeplugin

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:



Voxeo Unleashes PhonoSDK 0.2, a jQuery Module for Voice and Chat In the Browser

Phono shadow 1How about some echo suppression for voice calls directly from your web browser? That was the big news out of the Voxeo Labs team yesterday with the release of version 0.2 of the PhonoSDK... no more headsets required! Just click the Phono button on your website and start talking!

If you aren't aware of Phono, back in October Voxeo released the Phono SDK, letting you easily add in voice or chat directly into your website. The way to think about is this... traditionally, websites have had a "click-to-call" button that would call you and call a call center and bridge the two calls together. For this to work, you have to typically enter your phone number into the phone.

Phono changes that by running a softphone client directly in your web browser. So instead of entering your phone number, you simply push the button and start talking to your browser. (For those interested, we posted about the architecture, which uses a mixture of XMPP/Jingle and SIP. Phono itself is a jQuery module/library/app/whatever-you-want-to-call-it that you reference in your web page.)

Phono received a good bit of attention and we posted a lot of content about it online, including sample apps, tutorials, videos and more. The source code, too, is all available online.

One thing that always bothered us, though, was that you needed a headset for Phono to really work well... and so we spent a great amount of time working on echo suppression so that people could ditch the headset and just talk to their computer. Given that on the development side we're all Mac users, we're used to apps like Skype where you don't really need a headset. We wanted Phono to be the same.

So now we've done it... PhonoSDK version 0.2 is out! We're thrilled with how it came out and are looking forward to seeing what people build with it. If you want to try it out, simply go to Phono.com, check out the documentation and get started!

Full disclosure: In case the "we" usage above wasn't enough to clue you in, Phono is a product of my employer, Voxeo. But even if that weren't the case, I'd still write about Phono simply because it's cool... and it's disruptive.


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