Category: WebRTC

Aug 06

WebRTC “Just Works” Over IPv6…

I love opening up my computer in the morning and seeing tweets like this one:

The text is:

I’ve tested #WebRTC with Chrome talking to a ICE-Lite WebRTC server on IPv6. It just works. Nice.

And THAT is the way it should be.  For all the work we do as a community and industry to advance the deployment of IPv6, in the end the user experience should be exactly that… it should “just work”.  Users shouldn’t notice – or care – that their traffic goes over IPv4 or IPv6.

Kudos to the Chrome team for making it so that WebRTC “just worked” over IPv6.  And kudos to Iñaki Baz Castillo for noticing!

Now, let’s get out there and make everything else “just work” over IPv6! 🙂

If you’d like to get started with making your applications or network work with IPv6, please check out our “Start Here” page to find resources tailored to your type of role and organization – and please let us know if you need more information.

UPDATE: A bit more information about what made the WebRTC application “just work” in Chrome. Per Iñaki Baz Castillo, he had this bit of JavaScript code in the WebRTC app that the browser downloaded:

var pc_constraints = {
mandatory: { googIPv6: true }
};

That bit of code made his app work over IPv6.

The post WebRTC “Just Works” Over IPv6… appeared first on Internet Society.

Aug 06

WebRTC “Just Works” Over IPv6…

I love opening up my computer in the morning and seeing tweets like this one:

The text is:

I’ve tested #WebRTC with Chrome talking to a ICE-Lite WebRTC server on IPv6. It just works. Nice.

And THAT is the way it should be.  For all the work we do as a community and industry to advance the deployment of IPv6, in the end the user experience should be exactly that… it should “just work”.  Users shouldn’t notice – or care – that their traffic goes over IPv4 or IPv6.

Kudos to the Chrome team for making it so that WebRTC “just worked” over IPv6.  And kudos to Iñaki Baz Castillo for noticing!

Now, let’s get out there and make everything else “just work” over IPv6! :-)

If you’d like to get started with making your applications or network work with IPv6, please check out our “Start Here” page to find resources tailored to your type of role and organization – and please let us know if you need more information.

UPDATE: A bit more information about what made the WebRTC application “just work” in Chrome. Per Iñaki Baz Castillo, he had this bit of JavaScript code in the WebRTC app that the browser downloaded:

var pc_constraints = {
mandatory: { googIPv6: true }
};

That bit of code made his app work over IPv6.

Jul 25

IETF Journal – WebRTC: Moving Real-Time Communication into the Web Browser

Webrtc 2Seeking to understand the basics of WebRTC and why there is so much interest in it? There is a new July 2013 issue of the IETF Journal out this week that includes an article I wrote titled "WebRTC: Moving Real-Time Communication into the Web Browser" that looks at WebRTC from a high-level user perspective.

My aim with this IETF Journal article links was to summarize some of the links on my my WebRTC/RTCWEB page and is admittedly similar in style to my 2012 post, "How WebRTC Will Fundamentally Disrupt Telecom (And Change The Internet)", although this newer article focuses on the work happening within the IETF and provides links to get more involved.

On that note, the RTCWEB working group within the IETF will be meeting next week in Berlin (twice, actually) and has an agenda for IETF87 focused primarily on security questions and looking at the "data channel" aspect of WebRTC/RTCWEB. It should, as always, be an interesting session to listen in to.

If you can't get to Berlin, there are audio streams you can listen to remotely and a Jabber chat room where you can raise questions. Links to both can be found on the top of the agenda page. Do keep in mind that the times listed are local to Berlin, Germany.

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

Jun 18

Video: Great WebRTC Tutorial and Demonstrations by Cullen Jennings

Webrtc 2Want to understand more about WebRTC and where it is going? Want to see some demos of new WebRTC apps? At the recent INET event in Bangkok, Thailand, Dr. Cullen Jennings, one of the co-chairs of the IETF's RTCWEB Working Group, gave an excellent presentation that walks through the basics of WebRTC and provided some demos as well:

The presentation is about an hour and is followed by a question period. Well worth watching if you want to understand the current state of WebRTC and how it may impact telecommunications today.

Note, you can also view the video directly on YouTube to better see it in a larger size or on a mobile device.

P.S. For more information about WebRTC, see the links off of my WebRTC/RTCWEB page.

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

Feb 06

WebRTC Passes Huge Milestone In Rewiring The Web – Video Calls Between Chrome and Firefox

WebrtcThis week the WebRTC/RTCWEB initiative passed a HUGE milestone in adding a real-time communications layer to the Web with achieving interoperability between Google Chrome and Mozilla Firefox. Google and Mozilla celebrated with a pair of blog posts:

They also published the video I've embedded below. On the surface, the video doesn't appear terribly exciting: two guys having a basic conversation over video. But consider this:

  • The video conversation was initiated from within web browsers.
  • There were NO plugins used... no Flash, Java or anything else.
  • The entire conversation was securely encrypted.
  • The call used "wideband audio" (also called "HD audio") to provide a much richer experience that far exceeds any kind of conversation you can have on traditional telecom and mobile networks.
  • The call did not have to involve any external telecom networks or services and could have been initiated directly from one browser to the other. (I don't know exactly how they set up this call.)

And perhaps most importantly:

Any web developer can now create this kind of real-time communication using a few lines of JavaScript and other web programming languages.

As I'm said before, WebRTC will fundamentally disrupt telecommunications and add a real-time communications layer to the Internet that is based on open standards and is interoperable between systems. Creating applications that use voice, video and chat is being removed from the realm of "telecom developers" and made truly accessible to the zillions of "web developers" out there.

Congrats to the Google and Mozilla teams... this is a huge step forward for WebRTC!

You can see the video below... and if you are a developer interested in playing with WebRTC further, both the Google and Mozilla blog posts offer pointers to source code. The team over at Voxeo Labs also released a new version of their Phono SDK yesterday with WebRTC support that may be helpful as well.

UPDATE #1: The discussion threads on Hacker News related to the Google and Chrome blog posts make for quite interesting reading and provide many additional links for exploration:

UPDATE #2: Over at Forbes, Anthony Wing Kosner weighed in with a similar piece and proved he can write far more poetic headlines than mine: Google And Mozilla Strike The Golden Spike On The Tracks Of The Real Time Web

UPDATE #3: And over on No Jitter, Tsahi Levant-Levi gets the "wet blanket" award for dampening enthusiasm with his post: WebRTC Browser Interoperability: Heroic. Important. And...Expected

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

Oct 12

Hypervoice – The Fundamental Flaw In The Proposal

MartingeddesI am a huge fan of Martin Geddes, but he and I disagree fundamentally on one key part of what he is now calling "hypervoice".
NOTE: Today's VUC call at 12noon US Eastern will be with Martin discussing his ideas. If you'd like to weigh in on the issue, please join the call. (Unfortunately, I'll be waiting to board a plane home from Mumbai and can't make it... hence this blog post.)

To back up a bit, Martin has always been one of the "big thinkers" in realm of VoIP and telephony/telecom. Way back in mid-2000s when a number of us all started writing about VoIP, Martin's Telepocalypse blog was brilliant. He was always thinking about the "big picture" and drawing connections where they were not already apparent. His work with "Telco 2.0" was excellent and it was no surprise when he went to work for BT looking at their strategy. Now that he is back out on his own as a consultant, I'm a subscriber to his "Future of Communications" email newsletter (subscribe on the sidebar to his site) and enjoy reading his frequent issues.

Recently he gave a closing keynote presentation at the Metaswitch Forum titled "A presentation about Hypervoice" that is available via Slideshare or PDF.

The presentation itself is very well done. In typical Martin style it nicely lays out the history of both telecom and the web and brings them together to talk about what comes next.

I actually agree with almost all of what Martin writes. Much of what he talks about as "hypervoice" I see already happening in so many ways.

But here is where we fundamentally disagree... this slide early on:

Hypervoiceflaw

That includes the text:

"However, the Internet cannot and never will carry society's real-time communications needs. It is fundamentally unsuited to the job."

Martin's argument, which he has made multiple times before, including in a comment he wrote in response to my post about how WebRTC will disrupt real-time communications, is that the Internet as it exists today cannot provide the level of service that is truly needed for real-time communications. He believes we need to have different classes of service on the Internet and separate "flows" of communications. He comes back to this point later in his "Hypervoice" slide deck:

Hypervoice polyservicenetworks 1

This is where he and I part ways. As I said in my own response to Martin's comment to my earlier post:

Martin, yes, I've read your newsletters on this point and while I understand the concern I'm not ready to say that the plain old Internet can't deal with the contention. Back in the early 2000's I was the product manager for Mitel's "remote teleworker" product and there was great concern from the traditional telecom folks within Mitel about this idea that we were going to put an IP phone out at some random point on the Internet where there was no QoS or anything. In fact, some folks wanted us to say that it had "cell-phone voice quality" so that we wouldn't set high expectations about voice quality. The reality was that through appropriate codecs, jitter buffers and other technologies the connections almost always worked and almost always had outstanding quality (usually FAR better than cellphones).

The other reality is that we've seen OTT providers like Skype and others providing excellent services that work the vast majority of the time. We're seeing new and improved codecs coming into the market. We're seeing new traffic shaping technologies. The list goes on...

If the (brief) history of the Internet has shown us anything, it is that the Internet's capacity to adapt and change is boundless. We'll see what happens in the time ahead.

And no, I haven't written off the telcos as having a role in real-time comms. I just don't know that the "role" they may have will necessarily be the one they would like to have! ;-)

I believe fundamentally that the "open" Internet can and will adapt to the needs of carrying real-time communications. I would argue that it already has in so many ways... and it will change even more as we continue to move more and more real-time comms onto the Internet, particularly with WebRTC and other emerging technology.

And yes, you might expect me to say this as a passionate advocate for an open Internet, but I firmly believe this:

We do NOT need separate layers of the Internet based on class of service.

That, to me, is a dangerous path. I want to continue to see an Internet where all nodes are treated equally ... and where real-time communications can work for all.

Martin and I will probably have to agree to disagree on this. It's doubtful he can convince me nor I can convince him.

What do you think? Do we need different layers of the Internet? Or can the Internet adapt without that? Leave a comment here... or join in to today's VUC call and comment there.

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

Oct 05

Today’s VUC Call – Setting Up A Cellular Network In The Desert For Burning Man

TimpantonToday's VoIP Users Conference (VUC) call at 12:00 noon US Eastern should be quite an interesting one. Tim Panton from Voxeo Labs and Tropo will be joining the call to talk about his experience setting up a mobile network in the middle of the desert for this year's Burning Man event.

Tim recently described the experience in a guest post at TechCrunch: "What We Learned Running A Mobile Network At Burning Man" and on the VUC call will talk more about what he did. The FAQ from the Papa Legba camp at Burning Man makes for quite an interesting read. I'm looking forward to hearing more from Tim... and the call is open for anyone to join in.

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. It will be recorded so you can always listen later.

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

Oct 02

Slides: How The Hidden Secret of TCP/IP Affects Real-time Communications

Recently at Voip2day + ElastixWorld in Madrid 2012, Olle E Johansson gave a great presentation outlining where we are at with telecom and VoIP in 2012 - and where we need to go! Olle is a long-time, passionate and tireless advocate for the open Internet, IPv6, SIP and standards and interoperability. I've known Olle for years via Asterisk-related issues, via the VUC calls and via work on SIP over IPv6.

This presentation (slides available) really hits a number of key points about where we are at now:

In particular I was struck by his slides 24-28 that strike the same theme I've been writing about across multiple blogs, namely the way we are reversing the "open Internet" trend and retreating back inside walled gardens of messaging:

This is what customers wanted to avoid

He goes on to walk through what happened with SIP and how the protocol evolved - and evolved away from interoperability. His conclusion is that we as customers need to take back control, avoid vendor lock-in and demand interoperability.

He also points people over to his "SIP 2012" effort where he is undertaking to compile a list of what really defines "SIP" in 2012, i.e. more than just RFC 3261. (I'll note he's looking for feedback on these ideas.)

All in all an excellent presentation... and yes indeed we all collectively do need to "WAKE UP" and demand better solutions!

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

Sep 25

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:

Sep 18

How WebRTC Will Fundamentally Disrupt Telecom (And Change The Internet)

Old phoneIf we step back to before 1993, publishing and finding content on the Internet was a somewhat obscure, geeky thing that a very few people cared about and very few knew how to do. It involved gopher servers, ftp sites, archie, veronica, WAIS, USENET newsgroups, etc., and this "World-Wide Web" service primarily demonstrated via the server at info.cern.ch. It was an amazing period of time for those of us who were there, but the number of users was quite small.

Then NCSA released Mosaic in 1993 ... and suddenly everything changed.

Anyone could create a web page that "regular" people could see on their computers. Anyone could download Mosaic and use it. Anyone could share their sites with the installation of server software.

The Web was truly born into public consciousness... the creation of Web-based content was democratized so that anyone could do it... the creativity of developers was unleashed... a zillion new business models were thought of... and the Internet fundamentally changed.

Fast-forward to today...

... and the "Web" is still predominantly a document-based system. You make HTTP queries to retrieve pages and send HTML and XML documents back and forth between web browsers and web servers.

Separately, we have a world of telecommunication apps that have moved to IP. These are not just voice, but they are also video, instant messaging, data-sharing. They have moved so far beyond what we traditionally think of as "telecommunications". The apps use wideband audio, HD video, white boarding, sharing and so many capabilities that cannot have even been remotely imagined by the creators of the PSTN and all the legacy telcos and carriers. They are "rich communications" applications that have severely disrupted the traditional telco world.

The problem is that creating those rich, real-time communications apps is somewhat of a black art.

It is the realm of "telephony developers" or "VoIP developers" who can understand the traditional world of telcos and can interpret the seven zillion RFCs of SIP (as all the traditional telcos have glommed all sorts of legacy PSTN baggage onto what started out as a simple idea).

Deploying those rich communication apps also involves the step of getting the application into the hands of users. They have to download an application binary - or install a Flash app or Java plugin into their browser. Or on a mobile device install an app onto their mobile smartphone.

The world of rich communication experiences is held back by development problems and deployment problems.

Enter WebRTC/RTCWEB

Suddenly, any web developer can code something as easy as this into their web page: 

------
$.phono({   
   onReady:   function()   {
       this.phone.dial("sip:9991443046@sip.example.net")
 } } );
------

Boom... they have a button on their web page that someone can click and initiate a communications session ... in ANY web browser. [1 - this is not pure "WebRTC" code... see my footnote below.]

Using JavaScript, that pretty much every web developer knows... and using the web browsers that everyone is using.

And without any kind of Flash or Java plugins.

Boom... no more development problems. Boom... no more deployment problems. [2]

WebRTC is about baking rich, real-time communications into the fabric of the Web and the Internet so that millions of new business models can emerge and millions of new applications can be born.

It is about unleashing the creativity and talent of the zillions of web developers out there and turning the "Web" into more than just a document-based model but instead into a rich communications vehicle. It's about moving these apps from an obscure art into a commonplace occurrence.

We really have absolutely no idea what will happen...

... when we make it as simple for ANY developer to create a rich, real-time communications experience as it is to create a web page.

But we're about to find out... and done right it will fundamentally change the Internet again.

If we think the legacy telco crowd are upset now about how "VoIP" has screwed them over (from their point of view), they haven't seen anything yet. WebRTC/RTCWEB doesn't need any of their legacy models. It bypasses all of that in ways that only the Internet enables. It is NOT shackled to any legacy infrastructure - it can use new peer-to-peer models as well as more traditional models. And it goes so far beyond what we think of as "communication" today. [3]

I see it as the next stage of the evolution of the Internet, disrupting to an even greater degree the business models of today and changing yet again how we all communicate. The Internet will become even more critical to our lives in ways we can't even really imagine.

THAT is why RTCWEB (in the IETF) and WebRTC (in W3C) are so critically important ... and so important to get deployed.

[1] The code I'm showing is for a library, "Phono", that in fact will sit on top of the WebRTC/RTCWEB protocols. It is an example of the new apps and business models that will emerge in that it makes it simple for JavaScript developers to create these apps. Underneath, it will use the rich communications protocols of WebRTC/RTCWEB. Someone else will come up with other ways to do this in JavaScript... or python... or ruby... or whatever language. But because they will all use the WebRTC/RTCWEB protocols, they will interoperate... and work in any browser.

In full disclosure I should also note that Phono is a service of Voxeo, my previous employer.

[2] And BOOM... there go the heads exploding within the legacy telco crowd when they start to fully understand how badly the Internet has rendered them even MORE irrelevant!

[3] Note that a WebRTC app certainly can communicate with the traditional PSTN or other legacy systems. My point is that it is not required to do so. One usage of WebRTC will, I'm sure, be to "web-enable" many VoIP systems (ex. IP-PBXs) and services. But other uses will emerge that are not connected at all to the PSTN or any legacy systems.

Image credit: dmosiondz on Flickr

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